28. Dezember 2011

DB-Härtung oder Aufbau von sicheren Referenzdatenbanken

Derzeit planen oder implementieren viele Kunden den Aufbau von privaten und virtuellen Datenbank Clouds, um Kosten durch Konsolidierung und Standardisierung zu sparen. Bei diesen Projekten wird oft vergessen einen wesentlichen Augenmerk auf die Sicherheit zu legen. Durch eine Konsolidierung werden alle Daten zentral auf einer Hardware-Plattform zusammengeführt, was zu einer erhöhten Risikobewertung führen kann, wenn unterschiedliche Daten mit verschiedenen Sicherheitsanforderungen zusammengeführt werden. Diesbezüglich kein besonderes Augenmerk auf die Implementierung von Sicherheit zu legen, kann fahrlässig sein. In diesem Artikel soll die Härtung von Datenbanken beschrieben werden, um eine Grundsicherheit für private Datenbank Clouds zu erreichen. 


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.

Fahrplan für eine DB Härtung

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.

Manuelle oder tool-unterstützte Datenbank-Härtung
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