Risiko Mitarbeiter – 10 Tipps für mehr Datensicherheit
Tipp 2 – Datenbank-eigenen Tools und Logs im Zweifelsfall misstrauen
03.02.2010 | Autor / Redakteur: Brian Contos und Stephan Augsten / Stephan Augsten
Jede Datenbank bietet eigene Tools und Log-Daten, die man gerne zur Analyse von Sicherheitsvorfällen und Datenverlusten heranzieht. Aber sollte man sich überhaupt auf die Auditing- und Reporting-Funktionen einer angegriffenen Datenbank verlassen? In diesem Tipp gehen wir auf mögliche Gefahren und technische Mängel der Datenbank-Tools ein.
Grundsätzlich sollte man den Sicherheitsinformationen von IT-Systemen misstrauen, die Ziel eines Angriffs waren. Dieser Grundsatz gilt vor allem dann, wenn mehrere privilegierte Mitarbeiter wie Datenbank- und System-Administratoren auf eine Plattform und ihre Audit-Funktionen zugreifen können.
Ein Event-Log ist nunmal nutzlos, wenn ein böswilliger Insider es unter Umständen manipulieren kann. Das wäre so, als wenn ein Krimineller mit der Klärung seines eigenen Verbrechens beauftragt wird. Es ist recht einfach, forensische Beweise und nützliche Informationen zu unterschlagen.
Dies ist ein Paradebeispiel dafür, warum die Aufgabentrennung ein Muss im Unternehmen ist: sie ist gleichzusetzen mit der Gewaltenteilung einer Demokratie. IT-Sicherheit und der (sichere) Betrieb müssen klar voneinander abgegrenzt sein.
Ist die Gefahr einer möglichen Manipulation eingedämmt oder nicht gegeben, darf man aber nicht die technischen Unzulänglichkeiten vergessen, die mit den meisten Datenbank-Tools einhergehen:
- In vielen Fällen ist das integrierte Datenbank-Auditing schlichtweg nicht aktiviert.
- Das Freischalten nativer Audit-Funktionen erfolgt manuell und ist somit fehleranfällig; der Datenbank-Administrator könnte ein mangelhaftes Auditing veranlassen.
- Integrierte Auditing-Funktionen sind berüchtigt für ihren massiven Informationsüberfluss; native Audits können die Ressourcen einer Datenbank-Umgebung auslasten und somit die Produktivität des Systems beeinflussen.
- Wird nicht für jede Datenbank-Anfrage eine neue Verbindung erstellt, sondern eine bestehende offene Verbindung wiederverwendet (Connection Pooling), kann man auch nicht eindeutig den Verantwortlichen einer Aktion bestimmen (mehr dazu im noch ausstehenden Tipp: „Eine IP-Adresse haftet nicht für Datendiebstahl“).
- Verschiedene Datenbanken bieten unterschiedliche Auditing-Möglichkeiten; in heterogenen Umgebungen ist es sehr Ressourcen-intensiv, das Auditing für jede Datenbank zu aktivieren. Noch dazu liefern alle Datenbank-Versionen und -Typen einen unterschiedlichen und möglicherweise unvollständigen Output. Wenn man sich nicht mit sämtlichen Datenbank-Varianten auskennt, führt das zu Fehlinterpretationen.
- Zahlreiche Datenbanken sind nicht dazu in der Lage, böswillig manipulierte SQL-Anfragen abzufangen. Entsprechend der SQL Injection über eine Web-Anwendung ist ein interner Angreifer durchaus dazu in der Lage, eine ihm eigentlich unzugängliche Datenbank auszuspähen. Solche Datenbank-Abfragen bleiben den internen Audit-Tools leider verborgen.
Das Sammeln und Aufbereiten von Datenbank-Protokollen sollte dementsprechend unabhängig von nativen Tools erfolgen. Hier bietet sich beispielsweise eine Logfile-Sammlung mithilfe eines Syslog Daemon an, der auch heterogene Umgebungen unterstützt. Dadurch gewährleistet man eine strikte Aufgabentrennung, steigert die Datenbank-Performance, erhält aufbereite Details und kann die User besser in die Verantwortung ziehen.
Brian Contos ist Chief Security Strategist bei Imperva.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2043201)
