Die Datenbanksicherheit wird in vielen Unternehmen immer noch recht stiefm\u00fctterlich behandelt \u2013 und das obwohl heute eine solide Datenbank von zentraler Bedeutung f\u00fcr eine gut organisierte und konsolidierte IT-Landschaft ist und nicht autorisierte Zugriffe leicht zu einem Abfluss von Informationen oder zu Missbrauch und L\u00f6schung wichtiger Daten f\u00fchren k\u00f6nnen mit h\u00e4ufig existenzbedrohenden Auswirkungen f\u00fcr das Unternehmen.<\/p>\n
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\u00a0SOX<\/a>,\u00a0PCI-DSS<\/a>\u00a0und Datenschutzgesetze (z.B.\u00a0\u00a7 9\u00a0BDSG<\/a>\u00a0und Anlage zu \u00a7 9 Satz 1 Satz 2 Nummer 3 (Zugriffskontrolle), 4 (Weitergabekontrolle) und 5 (Eingabekontrolle)) w\u00e4ren Unternehmen\u00a0jedoch gut beraten, neue Wege zur Absicherung ihrer sensiblen Daten zu gehen.<\/p>\n Da ein Gro\u00dfteil 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\u00fcr kriminelle Aktivit\u00e4ten dar. Stand bisher die Absicherung der Netzwerkperimeter und der Clientsysteme (Firewalls, IDS\/IPS, Antivirus etc.) im Fokus der IT Sicherheitsaktivit\u00e4ten, sollte nun die n\u00e4chste Phase, die den Schutz der Unternehmensdatenbanken vor Sicherheitsl\u00fccken und unbefugten Zugriffen und \u00c4nderungen zum Gegenstand hat, folgen.<\/p>\n Zur Absicherung von Datenbanken sowie zur Einhaltung von gesetzlichen Vorgaben insbesondere, wenn sensitive und personenbezogene Daten gem. \u00a7 3 (1) BDSG innerhalb der Datenbanken gespeichert werden, die vor unberechtigten Zugriffen gesch\u00fctzt werden m\u00fcssen, l\u00e4sst sich auf Basis der nachfolgenden Best Practices zur Datenbanksicherheit, die eine ganzheitliche Methodik bilden, recht einfach ein durchg\u00e4ngiges Sicherheitskonzept zum Schutz sensitiver Daten in Datenbanken aufbauen.<\/p>\n Da sich nur das absichern l\u00e4sst, 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\u00f6tigt.<\/p>\n Hierbei m\u00fcssen\u00a0auch sich laufend \u00e4ndernde Standorte von sensiblen Daten aufgrund neuer oder ver\u00e4nderter Anwendungen, Fusionen etc. ber\u00fccksichtigt werden. Daher sollte die Bestandsaufnahme idealerweise regelm\u00e4\u00dfig und automatisiert mittels eines geeigneten Tools durchgef\u00fchrt werden.<\/p>\n Solche Tools leisten zudem wertvolle Dienste beim Aufsp\u00fcren der sensiblen Daten selbst, indem\u00a0sowohl Meta-Daten wie z.B. Tabellen- und Feldnamen\u00a0als auch der Datensatzinhalt ausgewertet werden, um einen m\u00f6glichst\u00a0realistischen \u00dcberblick zu den vorhandenen sensiblen Daten zu gewinnen.<\/p>\n Mittels\u00a0spezialisierter Tools lassen sich Datenbanken nach bekannten Schwachstellen und Konfigurationsm\u00e4ngeln einfach durchsuchen, um so einen ersten Status zur Sicherheit der eingesetzten\u00a0Datenbanksysteme sowie Handlungsempfehlungen als ersten Schritt zur Absicherung und\u00a0Implementierung eines Mindestsicherheitsstandards der Datenbank zu erhalten.<\/p>\n Sowohl diese Handlungsempfehlungen als auch\u00a0herstellerspezifische Empfehlungen zur Datenbanksicherheit sollten\u00a0nun Bestandteil von konkreten Sicherheitsanforderungen f\u00fcr Datenbanksysteme im Unternehmen werden.<\/p>\n Siehe hierzu auch die Artikel:\u00a0Systemsicherheit<\/a><\/p>\n Durch die Umsetzung\u00a0der konkreten Sicherheitsanforderungen f\u00fcr Datenbanksysteme kann nun unter Ber\u00fccksichtigung der vorliegenden Systemumgebung durch H\u00e4rtung der Datenbanksysteme die Sicherheit des Unternehmens\u00a0mit recht wenig Ressourcenaufwand sichergestellt werden.<\/p>\n Zu den H\u00e4rtungsma\u00dfnahmen geh\u00f6ren u.a.:<\/p>\n Siehe hierzu auch die Artikel:\u00a0Database Hardening<\/a><\/p>\n Nach der Erstellung einer abgesicherten Konfiguration ist es nun ratsam\u00a0diese in regelm\u00e4\u00dfigen Abst\u00e4nden zu \u00fcberpr\u00fcfen, um sicherzustellen, dass\u00a0sie im Laufe der Zeit nicht von der sicheren Konfiguration abweicht.<\/p>\n Das Security Reporting stellt hierzu technische Informationen \u00fcber den Sicherheits- und Compliance-Status zur Verf\u00fcgung und generiert\u00a0Warnmeldungen, sobald\u00a0\u00c4nderungen erfolgt sind, welche die Sicherheit der Datenbanken beeintr\u00e4chtigen k\u00f6nnte.<\/p>\n Hierzu geh\u00f6ren:<\/p>\n Siehe hierzu auch den Artikel:\u00a0Oracle Security Tools<\/p>\n Neben den bereits\u00a0beschriebenen Ma\u00dfnahmen zur Datenbanksicherheit, sollte auch nicht auf das Audit der Datenbankaktivit\u00e4t\u00a0(\u201eDatabase Activity Monitoring (DAM)\u201c) zur Gefahrenbegrenzung verzichtet werden, wodurch Eindringversuche und Datenmissbrauch zeitnah erkannt werden k\u00f6nnen.<\/p>\n Ein DAM erkennt und meldet z.B. ungew\u00f6hnliche Zugriffsmuster, die auf einen SQL Injektionsangriff, unberechtigte \u00c4nderungen an sensiblen Unternehmensdaten, m\u00f6gliche Umgehungen von Sicherheitseinstellungen, die Gew\u00e4hrung\u00a0von umfangreichen Zugriffsberechtigungen und Konfigurations\u00e4nderungen durch SQL-Befehle hinweisen. Daneben ist die \u00dcberwachung privilegierter Benutzer auch eine Anforderung von SOX und PCI DSS, was auch zur Erkennung unbefugter Zugriffe f\u00fchrt, da Angriffe h\u00e4ufig dazuf\u00fchren, dass der Angreifer privilegierte Zugriffsrechte erh\u00e4lt.<\/p>\n 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\u00f6rt z.B. die gemeinsame Nutzung von privilegierten Accounts durch mehrere Benutzer oder eine ungew\u00f6hnlich hohe Zahl fehlgeschlagener Datenbankanmeldungen. Einige DAM-Technologien erm\u00f6glichen zudem die \u00dcberwachung auf Anwendungsschicht. Damit wird auch ein Betrug \u00fcber mehrschichtige Anwendungen wie z.B. SAP, PeopleSoft und Oracle e-Business Suite statt nur \u00fcber Direktverbindungen zur Datenbank erkennbar.<\/p>\n Zu allen Datenbankaktivit\u00e4ten, mit Auswirkungen auf Sicherheit und Datenintegrit\u00e4t oder bei denen sensible Daten angezeigt werden, ist die Erstellung von sicheren und nicht anfechtbaren Pr\u00fcfprotokollen notwendig. Diese differenzieren Pr\u00fcfprotokolle sind neben ihrer Schl\u00fcsselrolle f\u00fcr die Erf\u00fcllung gesetzlicher Vorgaben auch f\u00fcr forensische Untersuchungen sehr hilfreich.<\/p>\n In den meisten Unternehmen erfolgt die \u00dcberwachung der Datenbankaktivit\u00e4ten derzeit jedoch noch manuell indem traditionelle, native Datenbankprotokollfunktionen genutzt werden. H\u00e4ufig sind diese\u00a0Verfahren sehr komplex und verursachen\u00a0durch manuellen Aufwand hohe\u00a0Kosten.\u00a0Zudem sind\u00a0hohen Performanceeinbu\u00dfen, mangelnde Aufgabenteilung (DBAs sind problemlos in der Lage Inhalte von Datenbankprotokollen zu manipulieren, was zur Beeintr\u00e4chtigung der\u00a0Unanfechtbarkeit f\u00fchrt) und die Notwendigkeit gro\u00dfer Datenspeicherkapazit\u00e4ten zur Bew\u00e4ltigung der gro\u00dfen Mengen ungefilterter Transaktionsdaten daf\u00fcr verantwortlich, dass\u00a0diese Verfahren als\u00a0unzul\u00e4nglich und nachteilig anzusehen sind.<\/p>\n Neue Generationen von DAM-L\u00f6sungen schaffen hier Abhilfe. Diese L\u00f6sungen bieten differenzierte, vom DBMS unabh\u00e4ngige Audits bei minimaler Beeintr\u00e4chtigung der Performance und f\u00fchren zu einer merklichen Senkung der Betriebskosten durch Automatisierung, zentralisierte und DBMS-\u00fcbergreifende Regelungen und Audit-Depots, Filterung und Komprimierung.<\/p>\n Im Rahmen von notwendigen Sicherheits-Audits leistet\u00a0ein DAM zudem wertvolle Hilfe zum schnellen Nachweis der Einhaltung von Regeln und Regularien, wodurch sich die Anschaffungs- und Lizenzkosten f\u00fcr ein Auditsystem im Vergleich zum Mehraufwand bei einem Audit ohne Softwareunterst\u00fctzung schnell amortisieren.<\/p>\n Siehe hierzu auch den Artikel:\u00a0Database Activity Monitoring zum Schutz vor Datenmissbrauch<\/a><\/p>\n Zentrales Thema eines Sicherheitskonzpts ist die Trennung von Zust\u00e4ndigkeiten f\u00fcr Aufgaben und\u00a0T\u00e4tigkeiten (\u201eSegregation of Duties\u201c). Dies gilt insbesondere f\u00fcr Aufgaben, die umfassenden Privilegien ben\u00f6tigen. Z.B. sollte ein DBA die Datenbank, aber nicht die Daten administrieren k\u00f6nnen. Solch eine klare Trennung zwischen Infrastrukturbereitstellung\/-administration\u00a0und der Verarbeitung der Daten dient der Verhinderung von Rechtemissbrauch.<\/p>\n Eine\u00a0Authentifizierung (Identifizierung und Legitimierung des Zugriffs) ist sicherzustellen.<\/p>\n Die\u00a0Autorisierung (Festlegung\u00a0und \u00dcberpr\u00fcfung der Zugriffsrechte) erfolgt in der Regel nach einer erfolgreichen Authentifizierung \u00fcber Gruppenzugeh\u00f6rigkeit (Rollen). Zus\u00e4tzliche Privilegien sollten nur \u00fcber per Passwort gesch\u00fctzte Rollen vergeben werden.<\/p>\n Im Rahmen der Zugriffskontrolle als integraler Bestandteil der Datenbanksicherheit sollten die per\u00a0Autorisierung vergebenen\u00a0und \u00fcberpr\u00fcften grundlegenden Lese- und Schreibberechtigungen auf Daten durch zus\u00e4tzliche Mechanismen weiter\u00a0eingeschr\u00e4nkt werden, wobei diese Zugriffsrechte auch bei den am h\u00f6chsten privilegierten Datenbankbenutzern durchzusetzen sind. Dadurch kann auch Power-Usern und Datenbankadministratoren der Zugriff auf sensitive Daten verwehrt werden, ohne diese Benutzergruppen bei der Durchf\u00fchrung ihrer Aufgaben \u00fcbergeb\u00fchrend zu behindern. Zur Implementierung solcher detaillierten Zugriffs-Mechanismen ist\u00a0jedoch ein umfassendes Zugriffs- und Rechtekonzept i.V.m. einem leistungsf\u00e4higen Berechtigungsmanagements unabdingbare Voraussetzung.<\/p>\n Im Rahmen eines Berechtigungsmanagements ist die Rechtesituation auf den Datenbankinstanzen regelm\u00e4\u00dfig 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\u00fcr die Erf\u00fcllung seiner Aufgaben ben\u00f6tigt.\u00a0Neben dem statischen Rollen- und Berechtigungskonzept mu\u00df dieser Punkt unbedingt durch ein geeignetes Tool unterst\u00fctzt werden, das jederzeit eine aktuelle \u00dcbersicht zu den eingerichteten Rollen und Rechten auf einer Datenbank liefern kann und zudem auch Bereinigungen der Rechtesituation und laufende \u00c4nderungen in der Rollen- und Rechtestruktur protokolliert und damit nachvollziehbar macht.<\/p>\n Siehe hierzu auch den Artikel:\u00a0Berechtigungskonzepte<\/a><\/p>\n Damit kein Angreifer von au\u00dfen unberechtigt auf sensible Daten zugreifen kann, sind diese Daten mittels Verschl\u00fcsselung unlesbar zu machen. Hierzu geh\u00f6rt neben der Verschl\u00fcsselung der Daten\u00fcbertragung, um zu verhindern, dass der Angreifer auf der Netzwerkschicht mitlauschen\u00a0kann (Network-Sniffing) und damit auf Daten zwischen DB-Client und Datenbank gesandt werden, zugreifen kann auch die Verschl\u00fcsselung der Daten auf Mediendateien. Die vorhandenen Verschl\u00fcsselungstechniken lassen sich in den nachfolgenden Bereichen verwenden, wobei sich\u00a0die Techniken auch gut kombinieren lassen:<\/p>\n In Test- und Abnahmeumgebungen mu\u00df grunds\u00e4tzlich mit den gleichen Datenbest\u00e4nden wie in der Produktion gearbeitet werden. Solche Daten\u00a0sind unbedingt zu anonymisieren, indem sie\u00a0unwiderruflich ver\u00e4ndert werden, damit\u00a0sie in solchen Umgebungen genutzt werden d\u00fcrfen, ohne dass noch zus\u00e4tzliche Schutzma\u00dfnahmen notwendig w\u00e4ren. Das gleiche gilt f\u00fcr den Fall, dass\u00a0aus vorgelagerten Prozessen\u00a0sensitive Daten bezogen, aber f\u00fcr die Weiterverarbeitung nicht unbedingt ben\u00f6tigt werden.<\/p>\n Mit der Anonymisierung\u00a0lassen sich\u00a0s\u00e4mtliche sensitiven Daten aus Produktionssystemen unkenntlich machen, ohne dass sich das Verhalten \u00e4ndert oder die Vergleichbarkeit mit der Produktionsumgebung\u00a0verloren geht.\u00a0Z.B. identische Ausf\u00fchrungspl\u00e4ne der SQL-Statements auf den Test- und Abnahmesystemen mit anonymisierten Daten sowie den zugeh\u00f6rigen Produktivsystemen. Im Data Warehouse Umfeld werden zwar f\u00fcr Auswertungen auch h\u00e4ufig entsprechende Produktionsdaten ben\u00f6tigt, aber nicht die kritischen Bestandteile, wie z.B. Kreditkartennummern, die daher problemlos durch ung\u00fcltige Informationen ersetzt werden k\u00f6nnen.<\/p>\n1.\u00a0\u00a0\u00a0 Entdeckung<\/strong><\/h4>\n
2.\u00a0\u00a0\u00a0 Schwachstellen- und Konfigurationsbewertung<\/strong><\/h4>\n
3.\u00a0\u00a0\u00a0 Absicherung \u2013 Systemh\u00e4rtung<\/strong><\/h4>\n
\n
\n
4.\u00a0\u00a0\u00a0 \u00c4nderungsaudit \u2013 Security Reporting<\/strong><\/h4>\n
\n
\n
5.\u00a0\u00a0\u00a0\u00a0Audit der Datenbankaktivit\u00e4t<\/strong><\/h4>\n
6.\u00a0\u00a0\u00a0 Trennung von Zust\u00e4ndigkeiten<\/strong><\/h4>\n
7.\u00a0\u00a0\u00a0 Authentifizierung, Autorisierung, Zugriffskontrolle\u00a0und Berechtigungsmanagement<\/strong><\/h4>\n
8.\u00a0\u00a0\u00a0 Verschl\u00fcsselung der Daten<\/strong><\/h4>\n
\n
\n
9.\u00a0\u00a0\u00a0 Anonymisierung von\u00a0Daten<\/strong><\/h4>\n