Logo Oracle Deutschland   DBA Community  -   Juni 2016
Härtung der Datenbank: Security Technical Implementation Guide (STIG)?
von Michael Fischer, Oracle Deutschland B.V. & Co. KG

Eine Standardinstallation einer (Oracle) Datenbank versucht möglichst viele Funktionalitäten (wie Schematas) bereitzustellen und erlaubt die Übernahme von "default" Einstellungen (bei Benutzern, Passwörtern etc.) um einfach durch die Installation zu kommen. Diese Arten von Installationen eignen sich nur bedingt für produktiven Einsatz und/oder schützenswerte Services/Daten. Viele Firmen oder Datenbankadministratoren haben über die Jahre eigene Vorgaben (auch "Härtung/Hardening" oder "Best Practices") bzgl. des Betriebs in der Produktion entwickelt. Die Umsetzung ist entweder gescripted oder liegt ganz in der Hand des jeweiligen Administrators. Beim Hardening der Datenbank selbst können auch "Best Practices" und Compliance Frameworks, die von Oracle bereitgestellt werden, herangezogen werden. Diese werden beispielsweise über den Enterprise Manager zur Verfügung gestellt. "Best Practices" gibt es natürlich auch in Form von Skripten die speziell für Assessments von Oracle oder anderen Firmen entwickelt wurden.
Der folgendende Artikel betrachtet eine dieser Best Practices Sammlungen, "STIG".

Prüfungen
Unterliegt eine Firma Auditprüfungen werden abhängig von den Skills des beauftragten Auditors auch die firmeneigenen Vorgaben oder Best Practices überprüft. Die Auditoren prüfen dabei entweder auf umgesetzte Standards (wie ISO27001 oder STIG) oder bei Nichtvorhandensein die Einzelregeln. Dazu haben Auditfirmen technisches KnowHow u.a. im Bereich Datenbanken aufgebaut.

Abgrenzung
Ein Hardening der Datenbank umfasst neben der Datenbank die weiteren beteiligten Komponenten wie Host und Netzwerk sowie ein auf "least privilege" zugeschnittenes User- und Rechtemanagement, das zudem kontext-basiert agieren kann. Diese Punkte werden hier nicht betrachtet.

Was ist STIG?

Die United States Defense Information Systems Agency (DISA) erstellt und pflegt eine Sammlung von Security Leitfäden für das amerikanische Verteidungsministerium (Department of Defense , DOD). Diese Leitfäden (sogenannte Security Technical Implementation Guides, abgekürzt und im Folgenden STIGs) enthalten Empfehlungen, um die Sicherheit von Systemen hinsichtlich der Konfiguration und Installation zu erhöhen.
STIG adressiert verschiedene Produkte mehrerer Hersteller, im Fall von Oracle sind dies Solaris, Oracle Linux und die Oracle Datenbank. Siehe Liste A-Z der DISA. Die Leitfäden können hier heruntergeladen werden und gegen die Systeme getestet werden. Die entsprechende Anwendung um die Scripte zu starten, bzw. die manuellen Aktionen durchzuführen, ist über den enthaltenen StigViewer möglich (Selektion, Ausführung und Auswertung). Eine Auswertung zeigt, unterschieden nach drei Kritikalitäten, die erkannten Verletzungen. Diese können nach Relevanz klassifiziert werden, um in einem Report bzw. bei Folgeaktivitäten nur tatsächlich relevante Punkte weiter zu verfolgen (Open, Not a Finding, Not Applicable).

Das BSI hat mit dem Grundschutzkatalog ein eigenes schriftliches Regelwerk erstellt in dessen Kommentierung Oracle mit dem BSI die entsprechenden technischen Werkzeuge (Database Options) dagegen gelegt hat. Zur Zeit erfolgt eine Aktualisierung auf Oracle 12c. Eine Ausarbeitung auf Katalogebene (Prüfskripte etc.) ist dem Einzelfall mit einer manuellen Überprüfung überlassen. Ebenso das Hinterlegen geeigneter Massnahmen zur "Heilung".

Auch für das manuelle Vorgehen gibt es Hilfestellungen vom Oracle Database Security Guide bis hin zu Vorgehensvorschlägen, beispielsweise das Projekt Lockdown von Oracle.

STIG bei Oracle Datenbanken

Im Falle der Oracle Datenbanken finden sich bzgl. der Kritikalitäten folgende Anzahl an Regeln: Kategorie High(I): 10, Kategorie Medium(II): 194 und Kategorie Low (III): 11.
Hier ein Beispiel einer Regel aus dem STIG Viewer der DISA. Die Verletzung ist als "mittel" eingestuft und prüft ob bei privilegierten Datenbankbenutzern/Rollen ein nicht protokollierter Zugriff auf Funktionen oder Objekte, die nicht securitybezogen sind, möglich ist. Beispielsweise auf eine HR Tabelle. Es geht nicht darum dass ein privilegierter Benutzer/Rolle nicht zugreifen kann sondern dass es protokolliert wird. Das Auditlog ist entsprechend zu schützen (siehe Regel V-52211 The DBMS must protect audit data records and integrity by using cryptographic mechanisms).
V-52389: 
Rule Title: All use of privileged accounts must be audited.
Severity: CAT II

This is intended to limit exposure, 
by making it possible to trace any unauthorized access, 
by a privileged user account or role that has permissions 
on security functions or security-relevant information, 
to other data or functionality.
Beschreibung der Überprüfung:
Review auditing configuration. If it is possible for a privileged 
user/role to access non-security functions or information, 
without having the action recorded in the audit log, this is a finding.
Abhilfevorschlag:
Configure DBMS auditing so that all use of privileged accounts 
is recorded in the audit log.

Diese Regel ist textuell beschrieben, andere Regeln sind mit den entsprechenden Prüf- und Fixstatements hinterlegt. Ein erklärender Text ist in jedem Fall in englisch vorhanden.

Manche Regeln sind deutlich komplexer, andere auch einfacher wie beispielsweise Netzwerkverschlüsselung. Die Regelwerke überprüfen sowohl die Datenbank selbst als auch das Oracle Home. Werden Patches eingespielt kann es notwendig sein die Regelwerke erneut dagegen zu testen.

Einsatzmöglichkeiten von STIG

Auch wenn die spezifischen Regelwerke von STIG aus den USA kommen, sind sie inhaltlich natürlich auch für in Deutschland betriebene Datenbanken sinnvoll und können hier auch angewendet werden. Oracle Datenbanken haben auf Grund der unterschiedlichen Konfigurations- und Einsatzmöglichkeiten keinen "Schalter" für eine sichere Konfiguration sondern viele Möglichkeiten die Sicherheit spezifisch zu erhöhen. Da Sicherheit ein fortwährender Prozess ist, gibt es nur Momentaufnahmen bzgl. einer Konfiguration. Eine fortwährende Überwachung der Systeme hinsichtlich der getroffenen Vorgaben ist sinnvoll. Nebeneffekt der Überwachung ist, dass im Falle eines Audits die Nachweise vorhanden sind. Im Prinzip bleibt es jedem Verantwortlichen überlassen dieses Regelwerk (STIG) als Basis oder Teil seines Konzepts zu verwenden. Noch attraktiver wird es wenn neben der Datenbank weitere Komponenten (Oracle oder 3rd party) in der Verantwortung liegen wie z.B. auch Betriebssysteme, Webserver etc. und damit weitere Regelwerke von STIG genutzt werden. Da der Einsatz mit dem von der DISA bereitgestellten STIGViewer einen hohen Automatisierungsgrad bzgl. der Überprüfung der Datenbank abdeckt, ist damit ein schneller Einstieg in das Thema Härtung oder nur Überprüfung/Assessment der Datenbank möglich. Um den Automatisierungsgrad weiter zu erhöhen, kann das Monitoring diesbezüglich auch dem Enterprise Manager überlassen werden.

Seit Oracle Enterprise Manager Cloud Control 12.1.0.4 sind die Oracle STIG Rules im Enterprise Manager enthalten. Oracle hat die STIG Rules auch teilweise ergänzt. Ein Vermerk welche Änderungen durchgeführt wurden ist in der Dokumentation enthalten.
Beispiel:
DO3689: 
Object permissions granted to PUBLIC should be restricted.
select privilege||' on '||owner ||'.'|| table_name ||' is granted to PUBLIC.' 
from dba_tab_privs
where grantee = 'PUBLIC'
and owner not in
('SYS', 'CTXSYS', 'MDSYS', 'ODM', 'OLAPSYS', 'MTSSYS',
'ORDPLUGINS', 'ORDSYS', 'SYSTEM', 'WKSYS', 'WMSYS',
'XDB', 'LBACSYS', 'PERFSTAT', 'SYSMAN', 'DMSYS',
'EXFSYS','APEX_030200', 'DBSNMP', 'ORDDATA')

Change to STIG Rule: Added default users and roles.

Beispiel einer STIG Rule aus dem Enterprise Manager:





Weitere Informationen zum Vorgehen zum Enterprise Manager mit STIG in der Dokumentation oder als Video.
Die benötigte Lizenz ist das Lifecycle Management Pack.
Neben den Einzelkomponenten kommt das Konzept mit STIG bei Oracle Engineered Systems optional zum Tragen, um dort unter anderem damit eine Grundhärtung herzustellen. Beispiel STIG bei Engineered Systems, hier SuperCluster: Oracle SuperCluster T5-8 Security Technical Implementation Guide (STIG) Validation and Best Practices on the Database Servers.

Fazit

Eine default Installation würde man in einer produktiven Umgebung nicht betreiben. Um diese abzusichern gibt es viele Möglichkeiten, z.B. eigene "Best Practices", mit Hilfe existierender Richtlinien oder externer Unterstützung. Bei eigenen Best Practices ist eine der grossen Herausforderungen die stetige Weiterentwicklung hinsichtlich der Produktversionen (z.B. Oracle 9->12) und laufend neuer Kompromittierungsmöglichkeiten. Richtlinien werden stetig weiterentwickelt und erlauben eine Adaption auf die eigenen Belange. Solche Richtlinien sind z.B. die "Security Technical Implementation Guides (STIGs)", die von einer unabhängigen Organisation entwickelt wurden und im militärischen Bereich der USA Vorgabe sind. Damit ist ein Grundschutz im Bereich Oracle auch in Deutschland umsetzbar, der zudem durch den hohen Automatisierungsgrad (fertige Regelwerke mit Skripten und Anleitungen) eine "einfache" Einführung ermöglicht. Wird der Enterprise Manager eingesetzt kann diese Automatisierung inkl. einem Monitoring weiter gesteigert werden. Durch den Enterprise Manager können auch eigene Compliance Regelwerke definiert werden, für die STIG und die Oracle Security Best Practices dann ein Teil darstellen. Durch die enthaltenen Berichte sind auch Nachweise für eventuelle Audits vorhanden.
Unabhängig davon welche Vorgehensweise oder welches Tool eingesetzt wird, macht es Sinn den Datenbankschutz im Auge zu behalten. Laut Verizon erfolgen 66% der Angriffe gegen eine Datenbank und viele davon sind oder wären erfolgreich.

Weitere Informationen

Zurück zur Community-Seite