Datenbank-Härtung – was ist das?
Unter
dem Härten von Datenbanken
wird eine Konfiguration verstanden, die ausschließlich die Funktionen zuläßt,
die die Anwendung benötigt. Nicht mehr und nicht weniger. Zusätzlich wird
überprüft, ob Standardfunktionen bzw. notwendige Zusatzfunktionen entsprechend den
Anforderungen sicher eingestellt sind, wie z.B. keine Nutzung von
Standardkennwörtern, Zurücknahme von nicht notwendigen Privilegien,
Zugriffskontrolle auf sensible Daten, Datenverschlüsselung etc..
Zu
diesem Thema existieren bereits verschiedene Artikel, die auch in der DOAG News veröffentlicht wurden. Betrachten Sie diesen vorliegenden Artikel als
eine aktuelle Erweiterung mit Bezug auf das Hype-Thema „Private and Virtual
Database Clouds“ und einer tool-gestützten Härtung von Oracle Datenbanken.Private Database Clouds
Viele meiner Kunden verlassen den Pfad der dedizierten Datenbank
pro Anwendung mit eigener Hardware, Peak-Load-Sizing und kostspieliger
Administration. Dabei bewegen sich diese Kunden nunmehr in Richtung
Konsolidierung. Sie virtualisieren vorhandene Applikationen auf virtuelle
Hardwareplattformen, um damit die Flexibilität zu erhöhen, eine bessere
Auslastung und Effizienz zu erlangen. Es entsteht eine sogenannte „Shared“ Infrastructure, die eine
Mandantenfähigkeit für Anwendungen unterstützt. Applikationen wie eine
Datenbank können in diese neue Infrastruktur schnell provisioniert werden, z.B.
vollautomatisch via Self-Services mittels Cloning-Verfahren im Enterprise
Manager oder als Oracle VM Templates. Das ermöglicht u.a. einen schnellen
Aufbau von Test- und Entwicklungsumgebungen und erhöht die Agilität eines
Unternehmens .
 |
| Abbildung 1: Cloud Computing |
Die Zusammenführung von
Datenbanken auf eine gemeinsame und zentrale Hardware-Plattform muss bei der
Planung ebenso den Aspekt der bestehenden Risiken und notwendigen
Sicherheitsanforderungen beinhalten. Um die Administrationsaufwendungen zu
reduzieren, ist es zu empfehlen für bestimmte Datenbanktypen einen
Unternehmensstandard zu etablieren, der die notwendigen
Sicherheitsanforderungen berücksichtigt. Ein praktikabler Ansatz ist die
Definition von Referenzdatenbanken über ein Konfigurationstemplate, die dann
per Knopfdruck mittels Enterprise Manager implementiert werden können. Ist
dieser Standard implementiert, sind alle neu implementierten Datenbanken mit
dem notwendigen Sicherheitsstandard ausgestattet und als gehärtet zu betrachten.
Es gibt verschiedene Vorlagen von
Oracle, wie eine
Datenbank gehärtet, also sicher konfiguriert wird. Nutzen Sie diese Vorlagen,
um die notwendigen Maßnahmen für Ihre Unternehmensanforderungen umzusetzen. Zwei
wesentliche Punkte möchte ich gerne ergänzen. Aus meiner Erfahrung werden viele
produktive Datenbanklandschaften mit sensiblen Daten ohne das einfache Auditing
der Datenbank (Standardfunktion) verwendet. Doch das BDSG und andere Regularien
wie PCI DSS fordern ganz klar eine Protokollierung von wesentlichen Zugriffen
auf Ihr Datenbanksystem, wenn personenbezogene oder andere sensible Daten dort
abgelegt sind. Audit-Funktionalität ist eine Standardfunktion innerhalb der
Datenbank, die eingeschaltet werden kann. Somit können automatisiert
verschiedene Aktivitäten in der Datenbank protokolliert und überwacht werden.
Unabhängigkeit vom BDSG sollten immer folgende Audit-Einstellungen eingestellt sein
- Fehlerhafte DB-Logins:
audit create session whenever not successful;
- Hochprivilegierte DB Aktivitäten
der SYSDBAs protokollieren:
Hierzu den Init.ora Parameter audit_sys_operations=TRUE einstellen
Ein weiterer wichtiger Punkt, der
z.B. auch im PCI DSS Standard definiert ist, ist die Forderung nach aktuellen
Patches. Auch dieser Punkt wird oft vernachlässigt. Oracle liefert
viertel-jährlich sogenannte kritische Sicherheitspatches (CPU). Diese Patches
gilt es einzuspielen, wenn das Scoring des Patches entsprechend
sicherheits-kritisch durch Oracle eingestuft wurde (siehe Risk Matrix). Für das Härten von
Datenbanken heisst das, dass aktuelle Patches in den Produktivsystemen
einzuspielen sind. Hierfür ist es notwendig eine geeignete Planung und Konzept
zu definieren, um die Datenbanken in einen sicheren Zustand zu halten.
Anforderungen aus bestehenden gesetzlichen
Regularien sind eine gute Grundlage, um auch eigene Sicherheitsstandards abzuleiten.
Denn was für Kreditkarten- oder personenbezogenen Daten gilt, ist für sensible
Unternehmensdaten sicherlich auch relevant.
In der Regel entwerfen
Unternehmungen einen Sicherheitsstandard und setzen diesen manuell um. Die
Erfahrung zeigt aber eindeutig, dass entsprechende Sicherheitsverantwortliche,
wie der CSO oder Datenschutzbeauftragte, keine Transparenz und Kontrolle über die
Durchsetzung von den definierten Sicherheitsstandards im Unternehmen haben.
Daraus folgt, dass der Glaube eine höhere Sicherheitsumsetzung vermutet - die Realität
jedoch eine andere Wahrheit spricht.
Diese Lücke zwischen Glaube und
Realität kann u.a. toolbasiert gelöst werden. Gerade in Bezug auf
Datenbank-Härtung bzw. „sichere Konfiguration“ bietet Oracle eine umfangreiche „Regelbiobliothek“
an, die hier unterstützen kann und die aktuelle Konfiguration einer Datenbank
auf Sicherheit prüft. Diese Funktionalität verbessert die Kontrolle und
Transparenz bei der Durchsetzung von unternehmensweiten Sicherheitsstandards. Die
Regelbibliothek ist Bestandteil des Enterprise Managers und wird im
Funktionsumfang des Configration Management Pack angeboten.
Configuration Management
Das Configuration Management Pack
sammelt Systemdaten des Hosts und der Datenbank und legt diese Information in
das Enterprise Manager Repository. Somit lassen sich Berichte über den
Systembestand sowie Vergleiche der Systembestände durchführen. Idealerweise
definiert man eine Baseline über eine Referenz-Datenbank und vergleicht damit die
produktiven Systeme, um somit die Einhaltung auf den Unternehmensstandard
aufzuzeigen. Für die Härtung von Datenbanken ist insbesondere der Policy
Manager interessant. Der Fokus liegt hier auf der Überwachung der Unternehmens-
und Sicherheitspolicies. Das Configuration Management Pack beinhaltet viele
hundert automatisch ablaufbare Regeln für Überprüfung der Sicherheit der
Datenbank und deren Host. Diese Regeln können durch eigene Regeln erweitern
werden. Es genügt ein Klick im Enterprise Manager, um einen Überblick der sicheren
Konfiguration all seiner Datenbanken zu erhalten (siehe Abb. 2). Der
Administrator oder Sicherheitsverantwortliche erhält einen Überblick, gegen
welche Regeln verstossen wurde, wie sich die Compliance über einen Zeitraum
verändert hat und welche Security Patches unbedingt eingespielt werden sollten.
 |
| Abbildung 2: Ausschnitt der DB Security zusammengefasst ( EM 11g) |
Eine Policy Group für die sichere
DB Konfiguration fasst wesentliche Regeln zusammen. Diese Policy-Group („Secure
Configuration for Oracle DB“) überprüft z.B. das Vorhandensein
auf Standard-Kennwörter, Einstellungen der File Permissions (Unix, Windows) von
Oracle Dateien, Init.ora Parameter, Audit-Einstellungen, Kennwort-Policies sowie
die Zugriffskontrolle auf DB Objekte wie Tables.
 |
| Abbildung 3: Policy Group "Secure Configuration for DB" ausgeführt |
Eine weitere Policy Group („Host
best-practice security settings“). Es werden
offene Ports, unsichere Services und Filesystem-Einstellungen überprüft.
In der Summe bieten diese
Policy-Gruppen einen „best-practice“ Ansatz, um die Überprüfung der DB
Konfiguration auf gängige Sicherheitsaspekte zu kontrollieren. Der Policy Manager
kann Regeln und Regelgruppe automatisiert ablaufen lassen und liefert einen
aktuellen Zustand der sicheren Konfiguration. Zusätzlich werden Trends
abgeleitet, die eine Verbesserung bzw. Verschlechterung der Zustände visualisert.
Für die Härtung sind grundsätzlich
vier Regel-Kategorien anzuwenden (im EM 11g), die in vier Policy Groups zusammengefasst
sind:
- Database Instance Security Policies (Anzahl der Regeln 122)
- RAC Database Security Policies (Anzahl der Regeln 50)
- Host Security Policies (Anzahl der Regeln 4)
- Listener Security Policies (Anzahl der Regeln 36)
Jede dieser Regeln kann einzeln und
automatisiert ablaufen (via Scheduler). Um den Automatisierungsgrad zu erhöhen,
kann für jede Regeln zusätzlich eine automatische Korrektur bei Verletzung
dieser Regel implementiert werden. Beispiel: Zwei Sample-Accounts werden in der
Datenbank mit dem Status „OPEN“ gefunden. Dieses Sicherheitsrisiko soll
automatisch gelöst werden. Hierfür wird die Security-Regel „Well known
Accounts“ editiert und eine automatische Korrektur implementiert, wenn eine
Verletzung der Policy auftritt. Die automatisierte Korrektur einer Verletztung
fügen wir der Policy hinzu und legen ein SQL Script bei, das alle bekannten
Sample-Accounts sperrt und das Kennwort „expired“.
Es können auch eigene Policies implementieren
werden, um somit einen unternehmensweiten Standard für die sichere
Konfiguration von Oracle Datenbanken zu definieren.
Dieser kurze Einstieg in das
Configuration Management Pack zeigt auf, wie einfach unternehmensweite Sicherheit-Policies
für Datenbanken automatisiert durchgesetzt und überwacht werden können. Neben
einer automatisierten sicheren DB Konfiguration („Härtung“) wird automatisch
die Produktivität vieler Mitarbeiter erhöht, die sich im Unternehmen mit
Security befassen.
Standardberichte
Der Enterprise Manager beinhaltet
ebenfalls eine Vielzahl von Standardauswertungen. Beispielsweise kann pro
Datenbank ein Überblicksreport ausgeführt werden. Dieser zeigt wesentliche
Informationen einer DB Instance an.
Ein weiterer guter
Standardbericht ist die Konfigurationszusammenfassung einer DB Instance, um den
Zustand nach Fertigstellung einer DB-Installation automatisch per Knopfdruck zu
dokumentieren.
Zusatzfunktionalität für das Datenbank-Härten
Natürlich bietet Oracle weitere
Lösungen an, die die Sicherheit der Datenbank wesentlich erhöhen:
- Für eine starke Authentisierung wie Kerberos, Datenverschlüsselung und Netzwerkverschlüsselung gibt es die Lösung Oracle Advanced Security Option
- Für die Funktionstrennung (Segregation of Duties) und Durchsetzung diesbzgl. implementierter Policies bietet Oracle die Lösung Oracle Database Vault an
- Eine zentrale Protokollierung von Datenbank-Aktivitäten und Ablage der Protokolle in einem revisionssicheren Repository ermöglicht Oracle Audit Vault
- Die Klassifizierung von Daten, um einen Zugriffsschutz auf Datenebene zu erzielen, kann durch Oracle Label Security erlangt werden
- Die Überwachung von Datenbankzugriffen und Blockierung unerlaubter Zugriffe auf die Datenbank gewährleistet die Oracle Database Firewall
Zusammenfassung
Eine Härtung des Datenbanksystems
hat zwei wesentliche Ziele: Risikominimierung und Nachweisbarkeit. Zum einen
soll eine kontrollierte Vorgehensweise definiert werden, die eine DB den
Anforderungen entsprechend konfiguriert. Dieses Vorgehen implementiert einen
Grundschutz und verfolgt das zweite Ziel, nämlich die Verringerung des Risikos
vor Missbrauch. Somit wird eine sichere Grundlage in einer virtuellen Umgebung
geschaffen, die das Provisionieren von sicheren Referenzdatenbanken in der DB
Cloud erlaubt. Eine tool-basierte Unterstützung kann hier wesentlichen Mehrwert
schaffen. Standards werden durchgesetzt und automatisiert überwacht. Eine
bessere Kontrolle und Transparenz der Realität ist gegeben. Verletzungen von
Policies können automatisiert korrigiert werden.
Weitere Informationen:
[1] DOAG News, 2007 Q3, Heinz-Wilhelm Fabry, Härten –
effektiver Grundschutz für Datenbanken: http://www.doag.org/pub/docs/Publikationen/DOAGNews/2007/2007-3/12_Haerten_DNQ3_07.pdf
[2] BSI, M 2.363 Schutz gegen SQL-Injection, hier
Beschreibung zur Härtung von Datenbanken: https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m02/m02363.html
[3] Oracle Project Lockdown, http://www.oracle.com/technetwork/articles/index-087388.html
