Die Datenbanksicherheit wird in vielen Unternehmen immer noch recht stiefmütterlich behandelt – und das obwohl heute eine solide Datenbank von zentraler Bedeutung für eine gut organisierte und konsolidierte IT-Landschaft ist und nicht autorisierte Zugriffe leicht zu einem Abfluss von Informationen oder zu Missbrauch und Löschung wichtiger Daten führen können mit häufig existenzbedrohenden Auswirkungen für das Unternehmen.
Wegen vermehrtem Datenmissbrauch durch Insider, Angriffen mit finanziellen Motiven, welche insbesondere durch die Anbindung von Unternehmensnetzen an das Internet und die intensive Nutzung von Webapplikationen erheblich erleichtert worden sind sowie gesetzlichen Vorgaben wie SOX, PCI-DSS und Datenschutzgesetze (z.B. § 9 BDSG und Anlage zu § 9 Satz 1 Satz 2 Nummer 3 (Zugriffskontrolle), 4 (Weitergabekontrolle) und 5 (Eingabekontrolle)) wären Unternehmen jedoch gut beraten, neue Wege zur Absicherung ihrer sensiblen Daten zu gehen.
Da ein Großteil der umfangreichen und oft sensiblen Unternehmensdaten in kommerziellen Datenbanksystemen wie Oracle, Microsoft SQL Server, IBM DB2 und Sybase Datenbanken gehalten werden, stellen diese Systeme zunehmend ein lukratives Ziel für kriminelle Aktivitäten dar. Stand bisher die Absicherung der Netzwerkperimeter und der Clientsysteme (Firewalls, IDS/IPS, Antivirus etc.) im Fokus der IT Sicherheitsaktivitäten, sollte nun die nächste Phase, die den Schutz der Unternehmensdatenbanken vor Sicherheitslücken und unbefugten Zugriffen und Änderungen zum Gegenstand hat, folgen.
Zur Absicherung von Datenbanken sowie zur Einhaltung von gesetzlichen Vorgaben insbesondere, wenn sensitive und personenbezogene Daten gem. § 3 (1) BDSG innerhalb der Datenbanken gespeichert werden, die vor unberechtigten Zugriffen geschützt werden müssen, lässt sich auf Basis der nachfolgenden Best Practices zur Datenbanksicherheit, die eine ganzheitliche Methodik bilden, recht einfach ein durchgängiges Sicherheitskonzept zum Schutz sensitiver Daten in Datenbanken aufbauen.
1. Entdeckung
Da sich nur das absichern lässt, was auch bekannt ist, wird eine umfassende Abbildung der sensiblen Assets wie Datenbankinstanzen in der Produktions-, Referenz-, Test-, Abnahme- sowie Staging-Umgebung sowie der sensiblen Daten innerhalb dieser Datenbanken benötigt.
Hierbei müssen auch sich laufend ändernde Standorte von sensiblen Daten aufgrund neuer oder veränderter Anwendungen, Fusionen etc. berücksichtigt werden. Daher sollte die Bestandsaufnahme idealerweise regelmäßig und automatisiert mittels eines geeigneten Tools durchgeführt werden.
Solche Tools leisten zudem wertvolle Dienste beim Aufspüren der sensiblen Daten selbst, indem sowohl Meta-Daten wie z.B. Tabellen- und Feldnamen als auch der Datensatzinhalt ausgewertet werden, um einen möglichst realistischen Überblick zu den vorhandenen sensiblen Daten zu gewinnen.
2. Schwachstellen- und Konfigurationsbewertung
Mittels spezialisierter Tools lassen sich Datenbanken nach bekannten Schwachstellen und Konfigurationsmängeln einfach durchsuchen, um so einen ersten Status zur Sicherheit der eingesetzten Datenbanksysteme sowie Handlungsempfehlungen als ersten Schritt zur Absicherung und Implementierung eines Mindestsicherheitsstandards der Datenbank zu erhalten.
Sowohl diese Handlungsempfehlungen als auch herstellerspezifische Empfehlungen zur Datenbanksicherheit sollten nun Bestandteil von konkreten Sicherheitsanforderungen für Datenbanksysteme im Unternehmen werden.
Siehe hierzu auch die Artikel: Systemsicherheit
3. Absicherung – Systemhärtung
Durch die Umsetzung der konkreten Sicherheitsanforderungen für Datenbanksysteme kann nun unter Berücksichtigung der vorliegenden Systemumgebung durch Härtung der Datenbanksysteme die Sicherheit des Unternehmens mit recht wenig Ressourcenaufwand sichergestellt werden.
Zu den Härtungsmaßnahmen gehören u.a.:
-
- Abschalten von nicht benötigten Diensten/ Softwarepaketen
- Sichere Dateisysteme und Dateiberechtigungen
- Einrichtung von Zugriffsbeschränkungen
- Vermeidung unsicherer Dienste und Kommunikationsprotokolle
- Aktualisierung der Software- und Versionsstände
Siehe hierzu auch die Artikel: Database Hardening
4. Änderungsaudit – Security Reporting
Nach der Erstellung einer abgesicherten Konfiguration ist es nun ratsam diese in regelmäßigen Abständen zu überprüfen, um sicherzustellen, dass sie im Laufe der Zeit nicht von der sicheren Konfiguration abweicht.
Das Security Reporting stellt hierzu technische Informationen über den Sicherheits- und Compliance-Status zur Verfügung und generiert Warnmeldungen, sobald Änderungen erfolgt sind, welche die Sicherheit der Datenbanken beeinträchtigen könnte.
Hierzu gehören:
-
- Systemhärtungs-Reports der Datenbanksysteme in denen ein Abgleich der sicherheitsrelevanten Konfiguration mit den Sicherheitsanforderungen für Datenbanksysteme durchgeführt wird
- Basis-System Security Scans (von innen und außen), um bekannte Schwachstellen der eingesetzten Systeme aufzudecken. Hiermit werden tatsächlich vorhandene Schwachstellen identifiziert, die ein Angreifer ausnutzen könnte. Als Ergebnis werden sowohl fehlende Security-Patche der Server als auch extern wirksame Schwachstellen der Serverkonfiguration aufgedeckt.
Siehe hierzu auch den Artikel: Oracle Security Tools
5. Audit der Datenbankaktivität
Neben den bereits beschriebenen Maßnahmen zur Datenbanksicherheit, sollte auch nicht auf das Audit der Datenbankaktivität („Database Activity Monitoring (DAM)“) zur Gefahrenbegrenzung verzichtet werden, wodurch Eindringversuche und Datenmissbrauch zeitnah erkannt werden können.
Ein DAM erkennt und meldet z.B. ungewöhnliche Zugriffsmuster, die auf einen SQL Injektionsangriff, unberechtigte Änderungen an sensiblen Unternehmensdaten, mögliche Umgehungen von Sicherheitseinstellungen, die Gewährung von umfangreichen Zugriffsberechtigungen und Konfigurationsänderungen durch SQL-Befehle hinweisen. Daneben ist die Überwachung privilegierter Benutzer auch eine Anforderung von SOX und PCI DSS, was auch zur Erkennung unbefugter Zugriffe führt, da Angriffe häufig dazuführen, dass der Angreifer privilegierte Zugriffsrechte erhält.
Da sich mit einem DAM auch traditionelle, statische Bewertungen um dynamische Bewertungen von Verhaltensschwachstellen erweitern lassen, liefert ein DAM auch einen entscheidenden Beitrag zur Schwachstellenbewertung. Hierzu gehört z.B. die gemeinsame Nutzung von privilegierten Accounts durch mehrere Benutzer oder eine ungewöhnlich hohe Zahl fehlgeschlagener Datenbankanmeldungen. Einige DAM-Technologien ermöglichen zudem die Überwachung auf Anwendungsschicht. Damit wird auch ein Betrug über mehrschichtige Anwendungen wie z.B. SAP, PeopleSoft und Oracle e-Business Suite statt nur über Direktverbindungen zur Datenbank erkennbar.
Zu allen Datenbankaktivitäten, mit Auswirkungen auf Sicherheit und Datenintegrität oder bei denen sensible Daten angezeigt werden, ist die Erstellung von sicheren und nicht anfechtbaren Prüfprotokollen notwendig. Diese differenzieren Prüfprotokolle sind neben ihrer Schlüsselrolle für die Erfüllung gesetzlicher Vorgaben auch für forensische Untersuchungen sehr hilfreich.
In den meisten Unternehmen erfolgt die Überwachung der Datenbankaktivitäten derzeit jedoch noch manuell indem traditionelle, native Datenbankprotokollfunktionen genutzt werden. Häufig sind diese Verfahren sehr komplex und verursachen durch manuellen Aufwand hohe Kosten. Zudem sind hohen Performanceeinbußen, mangelnde Aufgabenteilung (DBAs sind problemlos in der Lage Inhalte von Datenbankprotokollen zu manipulieren, was zur Beeinträchtigung der Unanfechtbarkeit führt) und die Notwendigkeit großer Datenspeicherkapazitäten zur Bewältigung der großen Mengen ungefilterter Transaktionsdaten dafür verantwortlich, dass diese Verfahren als unzulänglich und nachteilig anzusehen sind.
Neue Generationen von DAM-Lösungen schaffen hier Abhilfe. Diese Lösungen bieten differenzierte, vom DBMS unabhängige Audits bei minimaler Beeinträchtigung der Performance und führen zu einer merklichen Senkung der Betriebskosten durch Automatisierung, zentralisierte und DBMS-übergreifende Regelungen und Audit-Depots, Filterung und Komprimierung.
Im Rahmen von notwendigen Sicherheits-Audits leistet ein DAM zudem wertvolle Hilfe zum schnellen Nachweis der Einhaltung von Regeln und Regularien, wodurch sich die Anschaffungs- und Lizenzkosten für ein Auditsystem im Vergleich zum Mehraufwand bei einem Audit ohne Softwareunterstützung schnell amortisieren.
Siehe hierzu auch den Artikel: Database Activity Monitoring zum Schutz vor Datenmissbrauch
6. Trennung von Zuständigkeiten
Zentrales Thema eines Sicherheitskonzpts ist die Trennung von Zuständigkeiten für Aufgaben und Tätigkeiten („Segregation of Duties“). Dies gilt insbesondere für Aufgaben, die umfassenden Privilegien benötigen. Z.B. sollte ein DBA die Datenbank, aber nicht die Daten administrieren können. Solch eine klare Trennung zwischen Infrastrukturbereitstellung/-administration und der Verarbeitung der Daten dient der Verhinderung von Rechtemissbrauch.
7. Authentifizierung, Autorisierung, Zugriffskontrolle und Berechtigungsmanagement
Eine Authentifizierung (Identifizierung und Legitimierung des Zugriffs) ist sicherzustellen.
Die Autorisierung (Festlegung und Überprüfung der Zugriffsrechte) erfolgt in der Regel nach einer erfolgreichen Authentifizierung über Gruppenzugehörigkeit (Rollen). Zusätzliche Privilegien sollten nur über per Passwort geschützte Rollen vergeben werden.
Im Rahmen der Zugriffskontrolle als integraler Bestandteil der Datenbanksicherheit sollten die per Autorisierung vergebenen und überprüften grundlegenden Lese- und Schreibberechtigungen auf Daten durch zusätzliche Mechanismen weiter eingeschränkt werden, wobei diese Zugriffsrechte auch bei den am höchsten privilegierten Datenbankbenutzern durchzusetzen sind. Dadurch kann auch Power-Usern und Datenbankadministratoren der Zugriff auf sensitive Daten verwehrt werden, ohne diese Benutzergruppen bei der Durchführung ihrer Aufgaben übergebührend zu behindern. Zur Implementierung solcher detaillierten Zugriffs-Mechanismen ist jedoch ein umfassendes Zugriffs- und Rechtekonzept i.V.m. einem leistungsfähigen Berechtigungsmanagements unabdingbare Voraussetzung.
Im Rahmen eines Berechtigungsmanagements ist die Rechtesituation auf den Datenbankinstanzen regelmäßig zu erheben, um dem Need-to-know-Prinzip Rechnung zu tragen, so wie es die meisten Compliance Richtlinien anfordern, damit sichergestellt ist, dass jeder User nur die Rechte auf den Datenbanken besitzt, die er auch für die Erfüllung seiner Aufgaben benötigt. Neben dem statischen Rollen- und Berechtigungskonzept muß dieser Punkt unbedingt durch ein geeignetes Tool unterstützt werden, das jederzeit eine aktuelle Übersicht zu den eingerichteten Rollen und Rechten auf einer Datenbank liefern kann und zudem auch Bereinigungen der Rechtesituation und laufende Änderungen in der Rollen- und Rechtestruktur protokolliert und damit nachvollziehbar macht.
Siehe hierzu auch den Artikel: Berechtigungskonzepte
8. Verschlüsselung der Daten
Damit kein Angreifer von außen unberechtigt auf sensible Daten zugreifen kann, sind diese Daten mittels Verschlüsselung unlesbar zu machen. Hierzu gehört neben der Verschlüsselung der Datenübertragung, um zu verhindern, dass der Angreifer auf der Netzwerkschicht mitlauschen kann (Network-Sniffing) und damit auf Daten zwischen DB-Client und Datenbank gesandt werden, zugreifen kann auch die Verschlüsselung der Daten auf Mediendateien. Die vorhandenen Verschlüsselungstechniken lassen sich in den nachfolgenden Bereichen verwenden, wobei sich die Techniken auch gut kombinieren lassen:
-
- im Rahmen der Applikation
- im Datensatz, Speicher und Mediendatei
- im Netzwerk
- im Rahmen von Recordexports und Backups
9. Anonymisierung von Daten
In Test- und Abnahmeumgebungen muß grundsätzlich mit den gleichen Datenbeständen wie in der Produktion gearbeitet werden. Solche Daten sind unbedingt zu anonymisieren, indem sie unwiderruflich verändert werden, damit sie in solchen Umgebungen genutzt werden dürfen, ohne dass noch zusätzliche Schutzmaßnahmen notwendig wären. Das gleiche gilt für den Fall, dass aus vorgelagerten Prozessen sensitive Daten bezogen, aber für die Weiterverarbeitung nicht unbedingt benötigt werden.
Mit der Anonymisierung lassen sich sämtliche sensitiven Daten aus Produktionssystemen unkenntlich machen, ohne dass sich das Verhalten ändert oder die Vergleichbarkeit mit der Produktionsumgebung verloren geht. Z.B. identische Ausführungspläne der SQL-Statements auf den Test- und Abnahmesystemen mit anonymisierten Daten sowie den zugehörigen Produktivsystemen. Im Data Warehouse Umfeld werden zwar für Auswertungen auch häufig entsprechende Produktionsdaten benötigt, aber nicht die kritischen Bestandteile, wie z.B. Kreditkartennummern, die daher problemlos durch ungültige Informationen ersetzt werden können.
Siehe hierzu auch den Artikel: Datennutzung im Rahmen von Softwaretests
10. Rückgriff und Wiederherstellung von historischen Daten
Häufig ist es notwendig darüber Auskunft geben zu können, welchen Wert ein Datenfeld zu einem bestimmten Zeitpunkt z.B. vor einer Datenänderung gehabt hat. Dieses Erfordernis gilt häufig in Bereichen mit rechtlicher Relevanz. Der Zugriff auf solche historischen Daten kann mit gewissem Entwicklungsaufwand innerhalb von Applikationen realisiert oder mittels entsprechender Datenbankmechanismen genutzt werden.
11. Schutz vor Angriffen durch SQL-Injection
Insbesondere im Rahmen von Web-Applikationen muß dem Schutz vor Angriffen auf die Datenbank durch SQL-Injection ein besonderes Augenmerk geschenkt werden. Da in vielen unsicheren Anwendungen die über Eingabemasken eingegebenen Zeichenketten zusammen mit SQL-Befehlen lediglich zu kompletten SQL-Statements zusammengesetzt und direkt auf der Datenbank ausgeführt werden, können Angreifer durch bestimmte Eingaben das resultierende SQL-Statement so manipulieren, dass unerwünschte Code in den Datenbanken ausgeführt werden.
Neben der unbedingt ratsamen Nutzung von Funktionen zur Überprüfung der in Eingabemasken von Web-Applikationen eingegebenen Daten, läßt sich als zusätzlicher Schutz gegen SQL-Injection zwischen Datenbank und Applikation ein System integrieren, das alle Statements, die an die Datenbank übermittelt werden, auf kritischen Code hin untersucht. Dadurch lassen sich unerwünschte und gefährliche SQL-Statements identifieren und abwehren, sofern das eingesetzte Systemdie SQL-Statements auch verstehen („parsen“) kann.
Etablierung eines geeigneten und individuellen Datenbank-Sicherheitsniveaus!