Autor: Jürgen Esser

Performance

Database Activity Monitoring kann erheblichen Einfluß auf die Performance der Datenbanksysteme haben. Wenn alle Auditmöglichkeiten auf alle Objekte innerhalb der Datenbank aktiviert sind, kann der Performance Impact sehr hoch sein. Daher ist es unbedingt notwendig im Vorfeld festzulegen, welche Events auditiert werden sollen und welcher Performance Impact sich daraus ergibt. Hierbei sollte der Fokus primär auf sensiblen Daten liegen. Dies ist umso wichtiger, wenn das Database Activity Monitoring in Echtzeit arbeiten soll. Einige 3rd Party Lösungen bieten hierzu innovative Konzepte zum Umgang mit diesem Problem.

Protokollierungsebene

Um eine umfassende Sicherheit zu bieten, sollte die Database Activity Monitoring Lösung in der Lage sein Datenbankaktivitäten auf zwei Ebenen zu erfassen: Netzwerk Ebene (z.B. SQL Befehle, Angriffe auf Passworte und Benutzerinformationen), Datenbank Ebene (z.B. Column/Row, Tabellen, Views etc.). Native Database Activity Monitoring Lösungen sind meistens auf die Datenbankebene beschränkt, während 3rd Party Lösungen beide Ebenen abdecken.

Komfort

Führende kommerzielle Datenbankanbieter bieten native Auditfunktionalitäten in ihren Produkten. Während diese Funktionalitäten einerseits sehr leistungsfähig sind, sind diese andererseits aber häufig sehr schwierig zu konfigurieren. Es nimmt meistens viel Zeit in Anspruch, um alle richtigen Einstellungen zu aktivieren und die Falschen zu deaktivieren. Zudem muß diese Konfiguration für jeden Datenbankserver individuell durchgeführt werden, was in einer Enterprise-Umgebung mit häufig mehreren hundert Systemen vollkommen unwirtschaftlich und fehleranfällig ist. Die meisten 3rd Party Lösungen bieten hier wesentlich intelligentere Konfigurationsmöglichkeiten in ihren Produkten.

Bereinigung

Bereinigung durch Modifikation und Verschlüsselung von Auditinformation dient der Sicherheit der Daten gegenüber Änderungen der Informationen, abhängig vom jeweiligen User, dessen Informations-Level und den Ergebnissen. Der Bereinigungprozeß entfernt alle Informationen, die nicht relevant sind oder deren Informations-Level höher ist, als der auf den der jeweilige User Zugriff haben darf. Database Activity Monitoring Lösungen sollten in Lage sein die Auditdaten auf Basis der definierten Policies und der Zugriffsebenen der Auditoren zu bereinigen.

Sicherheit der Audit Logs

Audit Logs stellen ein attraktives Ziel für Angriffe dar, weil ein Angreifer hier die Spuren seines Angriffs komplett wieder entfernen kann. Zum Schutz des Audit Logs, müssen die Logdaten gegen Modifikationen geschützt sein. In diesem Zusammenhang muß unbedingt die Forderung nach einer Trennung der Verantwortlichkeiten („Separation of Duties“) berücksichtigt werden, damit selbst privilegierte Datenbank-Accounts keinen Einfluß auf die Logdaten nehmen können.

Datenbankbedrohungen

Vor der intensiven Nutzung des Internets waren Datenbanken gut geschützt, wobei der Zugriff per Standardverfahren wie Views und SQL Authorisierung erfolgte. Aber mit der rasanten Entwicklung von Webapplikationen, steigt die Zahl von Angriffen auf Datenbanken sprunghaft an und zeigt, dass die bestehenden Zugriffskontollmechanismen für web-bassierte Systeme nicht mehr ausreichend sind. Ein anderes ungelöstes Problem stellen die Insider Angriffe dar. Zwar wurden verschiedene Data-Mining Methoden zur Lösung des Problems entwickelt, wenn aber der Insider ein DBA ist, sind diese Methoden nicht einsetzbar, da der DBA alle Auditmechanismen deaktivieren kann. Die in dem Artikel Top-Datenbankbedrohungen genannten Punkte zeigen, dass die Entwicklung und Implementierung von geeigneten Lösungen gegen solche Arten von Angriffen eine dringende Herausforderung darstellen.

Ein wesentlicher Punkt im Rahmen der Data Security ist die Überwachung der Unternehmensdatenbanken zur frühzeitigen Erkennung von ungewöhnlichen Aktivitäten, die auf Angriffe oder Missbrauchsversuche hinweisen können.

Zur Bewältigung dieser Aufgabe werden neben herstellerspezifischen (native) Auditmechanismen der verschiedenen Datenbanksysteme heute vermehrt herstellerneutrale (Third Party) Database Activity Monitoring Tools (DAM) angeboten und eingesetzt.

• • Mit Database Activity Monitoring Lösungen lassen sich Datenschutzrichtlinien in Unternehmen besser durchsetzen, der Schutz vor internen Bedrohungen verbessern und die Einhaltung von Vorschriften wie zum Beispiel BASEL II, BDSG, Sarbanes-Oxley (SOX) oder PCI-DSS sicherstellen.
  • Die Lösungen bieten umfangreiche Auditfunktionalitäten, Unterstützung zahlreicher Datenquellen, revisionssichere Speicherung der Auditdaten und performanceneutrale Auditmechanismen.
  • Unautorisierte Aktivitäten, die gegen Sicherheitsrichtlinien und die Grundsätze ordnungsgemäßer Unternehmensführung verstoßen, lassen sich automatisch und schnell erkennen.
  • Die Generierung von Alerts und Compliance-Berichten erfolgt weitgehend automatisiert und die Integration eines Ticketsystems zur Nachverfolgung von Auffälligkeiten läßt sich über vorbereitete Schnittstellen herstellen.

Bei aller Euphorie für solche Tools sind jedoch grundsätzlich immer die Einschränkungen von Logging & Monitoring Maßnahmen zu beachten. Siehe hierzu auch die Ausführungen im Artikel „Möglichkeiten und Grenzen von Logging & Monitoring„.

Der Betrieb von IT-Systemen beinhaltet immer das Risiko eines vorsätzlich missbräuchlichen Zugriffs. Im Vordergrund der Data Security sollte somit immer das Verhindern von Angriffen stehen!

Daher sind präventive Maßnahmen immer der erste und wichtigste Schritt hin zur Verbesserung der Sicherheit. Solche Maßnahmen verringern das Risiko erheblich, ohne es jedoch in jedem Fall auf ein akzeptables Niveau zu bringen. Im Rahmen des normalen Applikationszugriffs kann dem Datenmissbrauch z.B. durch geeignete Schwellwerte entgegen gewirkt werden. Ein Missbrauch erweiterter Zugriffsreche z.B. von Administratoren und Power-Usern, erfordert jedoch neben dem Einsatz von Verfahren z.B. zur Abschottung von administrativen Accounts von den Daten auch ein datenzugriffsbezogenes Logging & Monitoring. Zudem können Hacker-Angriffe bzw. -Versuche nur durch Speichern und Korrelieren von Logdaten wie Zugriffe, IP-Adressen etc. erkannt und nachverfolgt werden.

Sobald es bereits zu einem Security Vorfall gekommen ist, ist eine Beweisfähigkeit und Nachvollziehbarkeit des Vorgehens eines Angreifers dringend erforderlich, was nur durch den Einsatz von Logging & Monitoring Maßnahmen gewährleistet werden kann. Darüber hinaus ist zu klären wie privilegierte Benutzer, z.B. Administratoren und Power-User, zu ihrem eigenen Schutz sowie zur Einhaltung von Gesetzen und Richtlinien in ein umfassendes Überwachungskonzept eingebunden werden können.

Normen, wie der Data Security Standard der Kredikartenindustrie (PCI DSS), fordern zudem z.B. das Aufzeichnen von Zugriffen auf bestimmte Daten. Somit ergeben sich unterschiedliche Aufgaben, die man mit Logging- und Monitoring-Konzepten und Maßnahmen größtenteils bewältigen kann.

Beim Aufbau einer Logging- und Monitoring Umgebung sollte grundsätzlich immer zuerst festgelegt werden, welche Ereignisse zu protokollieren sind, wie sich missbräuchliche Handlungen erkennen lassen und auf welche Weise das Auditing überwacht wird.

Solche Ereignisse stellen i.d.R. Abweichungen von der Norm dar und sollten nicht massenhaft auftreten. Bei einer zu großzügigen Definition der Filter kann die Anzahl der Log-Einträge jedoch massiv ansteigen und die Systemperformance stark beeinträchtigen. Daher sollten die zu überwachenden Ereignisse sorgfältig ausgewählt und die Log-Datenmenge im Sinne von „Handhabbarkeit“, „Datensparsamkeit“, „Reduktion von Performance-Auswirkungen auf hoch frequentierte Systeme“, „Schutz der Arbeitnehmer vor falschen Verdächtigungen“ sowie „Verhinderung von Leistungs- und Verhaltenskontrollen der Arbeitnehmer“ minimiert werden ohne jedoch das eigentliche Ziel der Maßnahmen und mögliche gesetzliche Anforderungen aus den Augen zu verlieren.

Grundsätzlich ist beim Einsatz von Logging & Monitoring Maßnahmen jedoch immer zu beachten, dass falls z.B. verdächtige Aktivitäten von Accounts aufgefallen sind, die Frage, ob tatsächlich die Person, der dieser Account gehört, die Aktion durchgeführt hat oder ob sich nicht ein Fremder dieses Accounts für seine Aktivitäten bedient hat, nicht zweifelsfrei beantwortet werden kann. Denn ein intelligenter interner Angreifer wird i.d.R. nicht mit seinem eigenen Account Datenmißbrauch betreiben. Ein Externer Angreifer kann sogar nur mit fremden Accounts arbeiten, nachdem er sich Zugang zu deren Logon-Informationen verschafft hat.

Somit kann Logging & Monitoring nur im Nachhinein Angriffe erkennen und evtl. die Wege von Angreifern nachvollziehbar machen und damit evtl. Sicherheitslücken in Zukunft schließen, aber weder Prävention gegen Datenmißbrauch leisten, noch Aktivitäten zweifelsfrei auf ganz bestimmte Personen zurückführen, sondern nur Hinweise auf einen möglichen Täter liefern. Für einen zweifelsfreien Nachweis sind daher weitergehende Maßnahmen wie z.B. forensische Untersuchungen des PCs von dem der Angriff erfolgt ist, Benutzerbefragungen etc. notwendig.

Die wesentlichen Regelungen des Data Security Standard der Kredikartenindustrie (PCI DSS) für den Bereich Data Security sind:

1. Build and Maintain a Secure Network

• • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other
    security parameters

2. Protect Cardholder Data

• • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks

3. Maintain a Vulnerability Management Program

• • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications

4. Implement Strong Access Control Measures

• • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data

5. Regularly Monitor and Test Networks

• • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes

6. Maintain an Information Security Policy

• • Requirement 12: Maintain a policy that addresses information security

Weitere Informationen zum Data Security Standard der Kredikartenindustrie (PCI DSS) finden Sie hier.

Basel II bezeichnet die Gesamtheit der Eigenkapitalvorschriften, die vom Basler Ausschuss für Bankenaufsicht in den letzten Jahren vorgeschlagen wurden, wobei (IT-)Sicherheitsmaßnahmen, die maßgeblich Risiken für das Unternehmen mindern und sich nach Basel II somit positiv auf mögliche Kreditkonditionen auswirken können.

Die Regeln müssen gemäß den EU-Richtlinien 2006/48/EG und 2006/49/EG seit dem 1. Januar 2007 in den Mitgliedsstaaten der Europäischen Union für alle Kreditinstitute und Finanzdienstleistungsinstitute (= Institute) angewendet werden.

Weitere Informationen zu Basel II finden Sie hier.

Ziel ist es grundsätzlich lesende und ändernde Zugriffe auf schützenwerte Daten auf Datenbankebene zu protokollieren, um die Gesamtmenge der Auditdaten auf das Wesentliche zu begrenzen und damit überhaupt ein effizientes Monitoring zu ermöglichen.

Lokalisierung von vorhandenen Datenbankinstanzen

Die Datenschutzinitiative sollte grundsätzlich damit beginnen, die vorhandenen Datebankinstanzen ausfindig zu machen, da nur das geschützt werden kann, was auch bekannt ist. Hierbei sollten nicht nur die Netzwerksegmente, sonderen auch die Datenbankinstanzen des Recovery & Deasaster-, Test- und Staging-Umfelds betrachtet werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.

Definition und Lokalisierung von schützenswerten Daten

Da nicht jede Datenbankinstanz für das Datenbank Activity Monitoring interessant ist, sollte in diesem Schritt pro Datenbank bzw. Applikation überprüft werden, ob überhaupt sensible und schützenwerte Daten in der Datenbank vorhanden sind erfasst werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.

Die Informationen zur Existenz von sensiblen Daten in der Datenbank zusammen mit Informationen zum Härtungsstatus der Datenbank aus den Datenbank-Scans lassen nun die Ableitung eines Risikos für die schützenswerten Datenbanken zu. Ein errechneter Risikowert auf einer Skala von 1 bis 10 bietet nun einen guten Überblick darüber, wo der größte Handlungsbedarf besteht.

Datenklassifizierung

Das Database Activity Monitoring ist erst effizient, wenn die Anzahl der “false positives” und “false negatives” sowie der Umfang der Auditdaten minimal sind. Zur Erzielung dieser Effizienz müssen in diesem Schritt die Speicherobjekte mit sensitiven Daten identifiziert und klassifiziert werden. Eine Klassifizierung der sensiblen und schützenswerten Daten kann z. B. in unterschiedliche Datentypen wie Personaldaten, Finanzdaten, Kreditkarten Informationen, User Credential etc. erfolgen.

Regeldefinition

Im Anschluß an die Datenklassifizierung sind zu den einzelnen Datenklassen entsprechende Regeln/Policies zu definieren, die bei einem Zugriff auf die Daten der zugrunde liegenden Datenklasse anschlagen. Solche Policies müssen klar und eindeutig formuliert und gleichzeitig flexibel gegenüber regelmäßigen Änderungen in den Systemen, Datenobjekten, Benutzerrollen, den Regularien und den strategischen Unternehmensrichtlinien und -zielen sein. Beispiele von möglichen Policies sollen nachfolgend beschrieben werden:

• • Financial Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Finanzdaten monitoren.
  • Personal Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Personaldaten monitoren.
  • Schema Change Policy – Das Database Activity Monitoring System sollte jede Änderung von Datenbankchemata und Benutzerkonten monitoren.
  • Large Data Set Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf große Mengen von z.B. Kundendaten erkennen und monitoren.
  • Failed Login Policy – Das Database Activity Monitoring System sollte alle fehlgeschlagenen Verbindungsversuchen zum Datenbankserver monitoren.

Das Database Activity Monitoring System muß hierzu in der Lage sein bei der Regeldefinition die relevanten Daten-banken, Tabellen, Objekte und Felder entsprechend zu konfigurieren. Z. B. sollte es möglich sein eine Regel auf einer definierten Datenbank für eine bestimmte Tabelle für eine bestimmt Aktion zu erstellen.

Datenerhebung

Abhängig von den definierten Regeln kommen u.a. nachfolgende Daten in Frage, die von einem Database Activity Monitoring System erhoben werden können:

• • Anmeldeinformationen an den Datenbanken
  • Aktivitäten auf der Datenbank mit welchen Privilegien

Implementierung der entsprechenden Regeln/Policies

Die konkrete Implementierung der entsprechenden Regeln/Policies ist vollständig abhängig von der Database Activity Monitoring Lösung und ist in einem gesonderten Dokument zur Lösung zu beschreiben.

Etablierung eines geeigneten und individuellen Datenbank-Sicherheitsniveaus!

Kontroverse Diskussionen hinsichtlich der Sicherheit von Datenbanken sind inzwischen allgegenwärtig. Dennoch konzentrieren sich viele Unternehmen primär auf den Schutz ihrer Applikationen. Dabei wird aber häufig die Sicherheit der Datenbanken mit den wertvollen Informationen eines Unternehmens vernachlässigt, wodurch große Sicherheitslücken entstehen können.

Zudem ergeben sich weitere Anforderungen an die Sicherheit von Daten aus relevanten Gesetzen und Regularien (z.B. für personenbezogenen Daten Daten Bundesdatenschutzgesetz (BDSG) und Datenschutzgrundverordnung (DSGVO), für Kreditdaten PCI-DSS, für Banken und Finanzinstitute Basel II/III).

Ursachen hierfür sind häufig mangelndes Wissen zu den Anforderungen an IT-Sicherheit sowie Probleme bei der Abschätzung der damit verbundenen Aufwände und Kosten. Oft scheut man aber auch nur die z.T. mit Sicherheitsimplementierungen einhergehenden Einschänkungen in der Benutzbarkeit und Administrierbarkeit von Systemen sowie die notwendige Anpassung von Prozessen und die Trennung von Aufgaben, welche in Unternehmen vielfach nur schwer umzusetzen sind.

Best Practices zur Datenbanksicherheit

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 von Best Practices zur Datenbanksicherheit, die eine ganzheitliche Methodik bilden, recht einfach ein durchgängiges Sicherheitskonzept zum Schutz sensitiver Daten in Datenbanken aufbauen. … Weiterlesen

Weitere Informationen zu den wichtigsten Aspekten der Datenbanksicherheit sowie Details zu den Best Practices der Datenbanksicherheit finden Sie auch in unserem Whitepaper der Datenbanksicherheit (PDF – 109 KB)

Umfang der Datenbanksicherheit

Obwohl Sicherheit in den meisten Unternehmen intensiv diskutiert wird, hapert es immer noch an der Umsetzung und der nachfolgenden Überprüfung. Selten werden als notwendig erachtete Anforderungen konsequent durch Maßnahmen umgesetzt, obwohl die Realisierung eines entsprechenden Sicherheitskonzeptes von allen Verantwortlichen grundsätzlich befürwortet wird. … Weiterlesen

Die Gründe dafür sowie die Vor- und Nachteil im Rahmen der Umsetzung erfahren Sie hier und in unserem Whitepaper zum Umfang der Datenbanksicherheit (PDF – 167 KB)

Datenbanksicherheits- und Risk-Assessment

Im Rahmen von Datenbanksicherheits- und Risk-Assessments erfolgt die Analyse der bestehenden Sicherheitsmaßnahmen. Diese werden den Best Practice Maßnahmen gegenübergestellt und so Schwachstellen aufgezeigt.

Hierzu gehören:

• • Erfassung des Ist-Zustands mit automatisierten und manuellen Systemchecks
  • Dokumentation des Ist-Zustands und Erstellung von Schwachstellen-Reports
  • Präsentation der Analyseergebnisse und Erörterung von geeignete Schutzmaßnahmen

Vorteile auf einen Blick:

• • Kenntnis des Ist-Zustands und vorhandener Schwachstellen
  • Kenntnis von geeignete Schutzmaßnahmen

Weitere Details zu den Datenbanksicherheits- und Risk-Assessments finden Sie hier.

Schulungen zur Förderung der Akzeptanz und des Bewusstseins bei den Mitarbeitern hinsichtlich Sicherheit im Unternehmen runden diese Maßnahmen ab, denn nur so wird Sicherheit im Unternehmen tatsächlich gesteigert, ein Sicherheitskonzept auch erfolgreich umgesetzt und gelebt.

Hintergründe zu Pro und Contra von Maßnahmen zur Datenbanksicherheit

Debatten zur Sicherheit und Standardisierung werden schon immer geführt und dienen auch der Eindämmung des Wildwuchses. Leider werden diese Themen innerhalb der Unternehmen oft mit Einschränkungen und Behinderungen in Verbindung gebracht. In der Diskussion um Cloud- und Mobile-Computing rückt neben der Standardisierungsdebatte auch das Thema Sicherheit wieder in den Mittelpunkt.

Obwohl Sicherheit in den meisten Unternehmen intensiv diskutiert wird, hapert es immer noch an der Umsetzung und der nachfolgenden Überprüfung. Selten werden als notwendig erachtete Anforderungen konsequent durch Maßnahmen umgesetzt, obwohl die Realisierung eines entsprechenden Sicherheitskonzeptes von allen Verantwortlichen grundsätzlich befürwortet wird.

Die wesentlichen Ursachen der zögerlichen Implementierung von Datenbanksicherheit lauten:

• • Relevante Vorschriften und Regularien sowie die daraus resultierenden Anforderungen an die Datenbanksicherheit sind häufig nicht bekannt.
  • Dem mit den Sicherheitsmaßnahmen einher gehende finanzielle und personelle Aufwand stehen keine direkten Einsparungen oder Verbesserungen im Betrieb gegenüber und ein Return-on-Investment ist kaum berechenbar. Somit sind die anfallenden Kosten sehr schwer zu rechtfertigen.
  • Häufig sind Sicherheitsmaßnahmen mit Einschränkungen bei der Nutzung und Administration verbunden mit der Folge, dass bei vielen konkreten Maßnahmen die Akzeptanz der betroffenen Personen fehlt.

Grundsätzlich beginnen Sicherheitsanforderungen und Schutzbedürfnis bei den Daten

Obwohl Datenbankadministratoren und Applikationsverantwortliche die Notwendigkeit von Sicher­heitsmaßnahmen nie grundsätzlich verneinen werden und in allgemeinen Diskussionen sogar oft sehr hohe Anforderungen an die Datenbanksicherheit stellen, reduzieren sie doch ihre Anforderungen spätestens dann, wenn Aufwände und Kosten thematisiert werden.

Zur Umsetzung einen sinnvollen Sicherheitsniveaus ist zu allererst eine Aufstellung erforderlich, welche Daten in welchen Systemen überhaupt vorhanden sind und welche Schutzbedürfnisse mit der Verarbeitung und Speicherung dieser Daten verbunden sind. Relevante Gesetze und Regularien (z.B. für personenbezogenen Daten Bundesdatenschutzgesetz (BDSG) und Datenschutzgrundverordnung (DSGVO), für Kreditdaten PCI-DSS, für Banken und Finanzinstitute Basel II/III) müssen hierzu bekannt sein und ihre Relevanz muss zunächst für die in den jeweiligen Systemen vorliegenden Daten geprüft werden.

Somit ist der erste Schritt zum Ausbau der Datenbanksicherheit eine Sicherheits-Klassifizierung der Daten nach Verfügbarkeit, Vertraulichkeit, Integrität (Korrektheit) und Nachweisbarkeit der Informatio­nen. Sehr hilfreich für die Kategorisierung und Klassifizierung der Daten sind die IT-Grundschutz Unterlagen und Tools vom Bundesamt für Sicherheit in der Informationstechnik (BSI).

Im Rahmen dieser Arbeiten werden Daten den genannten Kategorien entsprechend ihrer Relevanz zugeordnet. Auf Basis dieser Klassifizierung lassen sich nun die notwendigen Schutzmaßnahmen ableiten und geeignete Sicherheits-Lösungen auswählen.

Ist die Datenbanksicherheit nur ein Kostenfaktor ohne jeden finanziellen Nutzen?

Zunächst einmal ist Sicherheit ein Kostenfaktor und abgesehen von einzelnen Spezialfällen lassen sich weder Einsparungen noch Effektivitätssteigerungen erzielen.

In Analogie zu einer Versicherung dienen Sicherheitsmaßnahmen lediglich der Absicherung für den Schadenfall und die anfallenden Kosten für die Sicherheit müssen immer im Verhältnis zur Eintrittswahrscheinlichkeit und möglichen Schadenshöhe betrachtet werden.

So lange kein Angriff erfolgt und auch niemand außerhalb seiner Berechtigungen Zugriff auf Systeme ausübt, wären auch keine umfangreichen Sicherheitsmaßnahmen notwendig. Kommt es jedoch zu einem Schadensfall, übersteigen in der Regel die Kosten ein Vielfaches der für die Sicherheitsmaß­nahmen angefallen Kosten. Hinzu kommt, dass bei Verstößen gegen Regularien zudem noch hohe Strafen gegen die Geschäftsführung verhängt werden können und ein Sicherheits-Schadensfall im Extremfall sogar das Ende für ein Unternehmen bedeuten kann.

Sicherheitsmaßnahmen unter Berücksichtigung von Administrierbarkeit und Benutzbarkeit

Häufig sind Sicherheitsmaßnahmen mit Einschränkungen bei der Nutzung und Administration verbun­den mit der Folge, dass bei vielen konkreten Maßnahmen die Akzeptanz der betroffenen Personen fehlt.

Eine wesentliche Sicherheitsmaßnahme ist z.B. die Trennung von Zuständigkeiten für Aufgaben und Tätigkeiten zwischen verschiedenen Rollen bzw. Personen („Segregation of Duties“). Grundsätzlich sollten sicherheitsrelevante Änderungen immer auf mindestens zwei Rollen verteilt werden, die durch unterschiedliche Personengruppen abgebildet werden. Dies gilt insbesondere für Aufgaben, die umfassende Privilegien benötigen. Ein Administrator sollte z.B. die Datenbank, aber nicht die Daten administrieren können. Solch eine klare Trennung zwischen Infrastrukturbereitstellung/-Administration und der Verarbeitung der Daten verhindert, dass vorhandene Privilegien missbraucht werden und unzulässige Zugriffe auf oder Änderungen von sensitiven Informationen erfolgen können.

Hierbei wird deutlich, dass bei der Umsetzung von Sicherheitsmaßnahmen auch immer die Aspekte Administrierbarkeit und Benutzbarkeit zwingend berücksichtigt werden müssen, um eine ausgewo­gene Balance zwischen diesen drei Bereichen und damit einen optimalen Einsatz der IT zu ermögli­chen sowie die Akzeptanz von Sicherheitsmaßnahmen bei Nutzern und Administratoren zu gewähr­leisten.

Sicherheitsaspekte bei Datenbanken

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 Best Practices zur Datenbanksicherheit, die eine ganzheitliche Methodik bilden, recht einfach ein durchgängiges Sicherheitskonzept zum Schutz sensitiver Daten in Datenbanken aufbauen.

Die wesentlichen Aspekte im Rahmen der Datenbanksicherheit lauten:

• • Härtung der Datenbanksysteme
  • Trennung der Zuständigkeiten (Segregation of Duties)
  • Authentifizierung, Autorisierung, Zugriffskontrolle und Berechtigungsmanagement
  • Verschlüsselung (Netzwerk, Datensatz, Export, Backup und File)
  • Anonymisierung von sensitiven Daten für Test und Abnahme
  • Audit der Datenbankaktivität
  • Rückgriff und Wiederherstellung von historischen Daten
  • Schutz vor Angriffen durch SQL-Injection

Um ein sinnvolles Maß an Sicherheit für Datenbanken zu erreichen, ist in der Regel eine Kombination aus organisatorischen und technologischen Anforderungen umzusetzen. Sowohl die Datenbankher­steller als auch Drittlieferanten bieten hierzu zahlreiche Funktionen und Produkte an, die technolo­gisch optimal auf die jeweilige Datenbank abgestimmt sind.

Weitere Informationen zu den Best Practices der Datenbanksicherheit finden Sie hier.

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.