Sie sind der »Dirty Harry« der Datenbanksicherheit: DBEP-Systeme weisen Angreifer in die Schranken und verraten den Administratoren Dinge, die sie nie geahnt hätten. Wir zeigen, welche DBEP-Systeme es gibt und worauf Anwender achten sollten.

Kundenlisten, Umsatzzahlen, Kreditkartennummern … Die Liste von Daten, die unter keinen Umständen an die Öffentlichkeit gelangen dürfen, ist lang. Warum also wählen die meisten Organisationen Datenbanken, um die Anforderungen anderer Applikationen, beispielsweise ERP-Systeme, zu befriedigen, statt sich auf die Sicherheit zu konzentrieren?

Selbst wenn die Undurchdringlichkeit ein Verkaufsargument wäre, fänden Sicherheitsprofis wahrscheinlich allzu schnell heraus, dass das Security-Modell des Datenbank-Herstellers nicht zur Real-World-Netzwerk-Infrastruktur passt.

Dies ist eine der Situationen, die Sicherheitsspezialisten weinen lässt, während die Produzenten sich glücklich fühlen. Laut Forrester ist der Markt für Security von Datenbanken aktuell 600 Millionen Dollar wert. Im Jahr 2009 wird er wahrscheinlich eine Milliarde übersteigen.

Ein Teil davon wird für Datenbank-Extrusion-Prevention/-Detection ausgegeben werden. Die Fähigkeiten dieser Produkte variieren, aber deren gemeinsamer Nenner ist, dass sie Benutzeraktivitäten verfolgen und bei feindlichem Verhalten Alarm schlagen.

Datendiebstahl vorbeugen

Einige wenige Produkte gehen einen Schritt weiter: Sie blockieren potenzielle Diebstähle, bevor ein Datenleck auftaucht. Welcher Grad von Sicherheit für ein Unternehmen richtig ist, lässt sich nicht so einfach beantworten. Denn es ist der Zusammenhang zwischen unautorisierter Datenenthüllung und dem Blockieren legitimer Benutzer-Queries zu beachten.

Ein weiterer Punkt: In den guten alten Zeiten wurden Datenbanken durch Anfälligkeiten in der Datenbank-Software selbst ausgebeutet. Heute ist es wahrscheinlicher, dass Angreifer Lücken in schlecht geschriebenen Web-Applikationen nutzen – es ist einfacher, einen einzelnen Browser zu aktualisieren, als zwanzig verschiedene Client-Applikationen zu pflegen.

Falls irgendetwas auf Web-Technik übertragen werden kann, wird dies früher oder später geschehen. Und das schließt die Leitungen zu den Datenbanken ein.

Es geht hier nicht etwa um einen einzelnen Hersteller von Datenbanken. Ja, ein Wurm namens SQL-Slammer und Fehler wie leere »sa«-Passwörter machten Microsoft-SQL-Server-2000 zum Darling der Sicherheitsgemeinschaft. Aber alle Datenbanken sind problematisch. Oracles beispielsweise veröffentlichte im Januar ein Critical-Patch-Update, das 26 neue Security-Fixes enthielt.

Die Büchse der Pandora schließen

Datenbankschutzschemata reichen von ineffizient und angenehm unaufdringlich bis zum Äquivalent von »bei Sicht wird sofort geschossen«. Man denke nur an die in der Datenbanksoftware eingebauten Logging-Fähigkeiten – Datenbank-Auditing ist ein notorisch hartnäckiges Problem, und die Situation wird ohne Intervention in naher Zukunft auch nicht besser werden.

Natürlich gibt es Transaktions-Logs schon lange, aber diese erfüllen nur einen Zweck: Sie sollen Datenverlust verhindern, wenn ein Server während einer Datenaktualisierung herunterfährt, bevor die Änderungen bestätigt (committed) sind. Sie sind nicht dafür vorgesehen, bösartige Aktivitäten zu erkennen oder gar zu verhindern.

Was bedeutet das für Unternehmen? Zunächst: Bestimmte Aktivitäten werden während des Logging-Prozesses übersehen. Beim Microsoft-SQL-Server-2000 kann der Administrator beispielsweise das Auditing ausschalten, einige Aktionen durchführen und das Auditing dann wieder einschalten. Und in den Logdateien ist davon nichts zu sehen. Dies ist ein perfektes Beispiel dafür, warum Sarbanes-Oxley die Aufgabentrennung vorschreibt.

Datenbankaktivität überwachen

Zur Protokollierung von Benutzeraktivitäten und für SOX-Compliance-Zwecke können Unternehmen Datanbankaktivitäts-Monitoring-Appliances, beispielsweise Appradar von Application Security, einsetzen. Diese Systeme überwachen die Datenbankaktivität, indem sie entweder inline oder auf einem Span-Port sitzen und den Verkehr vom und zum Datenbankserver erschnüffeln.

So lassen sich aber keine direkt auf dem Datenbankserver durchgeführten Aktivitäten sehen. Dies ermöglichen aber auf Hosts basierende Agenten, die auf dem Datenbankserver sitzen und an ihre Managementkonsolen berichten. Sowohl die Appliance als auch der Agent würden das Ein- und Ausschalten des Loggings erkennen.

Zusätzlich lässt sich auch die Aufgabentrennung erreichen, denn das Auditing ist nun auf eine separate Plattform verschoben. Das Sicherheits- oder Compliance-Team kann Benutzeraktivitäten prüfen, ohne dass der Datenbankadministrator durch Ein- oder Ausschalten des Loggings auf dem Server Einfluss darauf hat.

Schlupfloch Web-Anwendungen

Das klingt gut. Bis Web-Applikationen ins Spiel kommen. Diese verbinden sich typischerweise über nur einen oder zwei Konten mit der Datenbank. Ein Auditing-Albtraum. Imperva hat erkannt, wie schwerwiegend dieses Problem ist, und ihrem Securesphere-Database-Security-Gateway ein Web-Applikations-Firewall-Produkt hinzugefügt. Damit lassen sich IP-Adressen und authentifizierte Benutzer der Web-Applikationen ihren Datenbankaktivitäten zuordnen. Zuvor war das eine arbeitsreiche Aufgabe, die Sicherheitsprofis manuell durchführen mussten.

1. Rauchende Colts
2. Netzwerkverbindung unterbrechen