Test: Datenbank-Extrusion-Prevention-Systeme (DBEP):
Dringeblieben, oder ich schieße

von Dirk Jarzyna

03.03.2008

Heutigen Hackern geht es nicht mehr um Ruhm, sondern immer häufiger um Geld. Und sie wissen, dass am Ende einer SQL-Query fette Beute wartet. Die Systeme schützen vor dem Datendiebstahl.

Network Computing testete im Verlauf der vergangenen sechs, sieben Monate fünf DBEP-Systeme. Crossroads Systems, Guardium, Imperva und »RippleTech« stellten Appliances zur Verfügung, Pyn Logic lieferte Software. Application Security, »IPLocks«, Symantec, Tizor Systems und Trancparency Software zogen es vor, am Test nicht teilzunehmen.

Imperva SecureSphere

DBEP-Systeme haben viele gemeinsame Stärken und Schwächen: Ihre Schutzschemata sind manchmal eher Pudel als Rottweiler. Zu empfehlen ist ein System, das von den normalen Nutzungsmustern lernt. Impervas »SecureSphere Database Security Gateway G4«, das gemeinsam mit dem optionalen MX-Management-Server getestet wurde, ist ein lernender Rottweiler. Das System merkte sich das Benutzerverhalten und zahlreiche Signaturen. Damit war es in der Lage, bekannte Angriffe gegen die Datenbank und das darunter liegende Betriebssystem zu blockieren. Der Securesphere-DSG lässt sich allein einrichten und verwalten, aber der MX-Server bietet einen handlichen, zentralen Einstiegspunkt.

Für das Management sind in der MX-Server-Web-Schnittstelle Servergruppen zu erzeugen. Für den Test wurden zwei solcher Gruppen erstellt, die Microsoft-SQL- und Oracle-Server enthielten. Um eine Baseline – die Grundlage – zu erhalten, wurden verschiedene Ruby-Scripts und I-Macros automatisiert. Sie liefen in Intervallen, um Benutzeraktivitäten zu simulieren, und zwar direkt in Richtung Datenbank sowie durch eine E-Commerce-Web-Site.

Imperva nutzt so genanntes Dynamic-Profiling, um Baselines zu erzeugen und zu lernen, was als normales Benutzerverhalten zu betrachten ist. Administratoren können auch manuell Profile erzeugen und Tabellen definieren, aber es ist viel effizienter, dies dem DSG zu überlassen.

Sobald die Profile eingerichtet sind, beginnt der Spaß. Im Test wurde nun definiert, was das System als Database-Extrusion ansehen soll. Organisationen, denen es auch um PCI-Compliance geht, werden nicht enttäuscht: Imperva bietet verschiedene definierte Regelsammlungen, die Kreditkarten-Lecks entdecken. Mit bis zu 200 Regeln für jeden großen Anbieter wird es aber rasch unübersichtlich. Und alle Regeln sind in der Voreinstellung eingeschaltet.

Beim Auditing des Benutzerverhaltens arbeitet der DSG deutlich feinerfühlig als die meiste Datenbankserver-Software. Aktuelle Antworten von der Datenbank lassen sich in ein Log schreiben, um zu sehen, welche Daten die Alerts generierten. Dies ist einerseits nützlich, andererseits eine potenzielle Verletzung. Man stelle sich vor: Ein Angreifer war in der Lage, 1500 Kreditkartennummern aus dem System zu ziehen, und diese Nummern stehen nun in der Logdatei – damit hat der Administrator ein PCI-Compliance-Problem.

Glücklicherweise bietet Imperva die Option, rohe Queries nicht protokollieren zu lassen. Außerdem kümmert sich Imperva um die Compliance, indem es die Aufgaben separiert und das Datenbank-Logging aus dem Machtbereich des Datenbankadministrators verschiebt.


Da sich der DSG inline platzieren lässt, kann er als Firewall und IPS arbeiten. Neben den Signaturen zur Bestimmung normalen Verkehrs enthält das System Signaturen bekannter Attacken und Protokoll-Decoder. Damit entdeckt es Protokollabnormitäten, die auf einen Angriff hindeuten könnten. Da die meisten Organisationen sicherlich schon eine Firewall eingerichtet haben, wird dies eins der weniger genutzten Features sein. Trotzdem ist es gut, dieses zu haben, denn es hilft beim Aufbau eines vielschichtigen Verteidigungssystems.

Im Test wurden ein paar SQL-Injection-Angriffe probiert. Die Signaturen entdeckten einige davon, aber nicht alle. Dann wurden die Signaturen ausgeschaltet, damit zu sehen war, ob das Profil des Web-Benutzers die Änderung im Verhalten entdeckt. Das tat es.

Imperva liefert mit dem DSG eine vollständige Assessment-Komponente, welche die Sicherheit eines Datenbankservers einschätzt. Die Funktion prüft generelle Datenbank-Sicherheitsfeatures, testet auf aktuelle Datenbank-Sicherheitsanfälligkeiten und verifiziert die Sicherheit des darunter liegenden Betriebssystems. Getestet wurde das Assessment gegen Standardinstallationen von Microsoft-SQL-Server. Wie gehofft, fand der Scanner all die Sicherheitsanfälligkeiten, die in den Standardinstallationen dieser Produkte zu erwarten sind.

Sämtliche Managementaufgaben führt der Administrator direkt über die leicht benutzbare MX-Management-Server-Schnittstelle aus. Änderungen sind mit einem Mausklick an die verwalteten Geräte zu verteilen. Für Organisationen mit vielen geographisch verteilten Datenbankservern ist der MX-Server eine gute Wahl, denn er bietet zentrales Management und zentrale Richtlinien. Impervas DSG ist ein solides Produkt.


Pyn Logic Enzo 2006

Unternehmen installieren Datenbank-Extrusion-Monitore aus viele Gründen: Bedrohungen durch Insider, Datenlecks durch fehlerhafte Web-Applikationen, Angriffe von außen, oder einfach Compliance. Pyn Logic möchte all dies abdecken und preist ihr Enzo-2006 als Universallösung an. Die Funktionen reichen von DBEP bis zu feinfühliger Zugriffssteuerung für Datenbankserver. Um dies zu erreichen, sitzt Enzo zwischen den Clients und dem Datenbankserver und arbeitet als Proxy für alle Verbindungen in beide Richtungen.


Da Enzo auf Software basiert, unterscheidet es sich vom üblichen DBEP-Appliance-Modell – und das ist nicht immer gut. Vorteilhaft ist diese Lösung aber für IT-Abteilungen, die nicht noch eine weitere Black-Box in den Serverraum quetschen können, oder für Organisationen, die an Virtualisierung interessiert sind. Enzo läuft unter Windows, für Testzwecke wurde das Produkt also auf einem Windows-Server-2003-System installiert.

Enzo akzeptiert, verarbeitet und sendet Anfragen direkt. Der Prozess ist zwar für den Client vollkommen transparent, macht Enzo aber auch zu einem Single-Point-of-Failure, der den Zugriff auf Datenbankserver verhindern könnte. Außerdem könnte die Box unter hoher Last zu einem Performance-Flaschenhals werden. Vor dem Kauf sind gründliche Tests angesagt.

Enzo besteht aus drei treffend bezeichneten Komponenten: einer Director-Management-Schnittstelle fürs Monitoring und die Administration, einem Windows-Dienst, der einen Port abhört und das Management der Engine vom Director aus ermöglicht, und einer Engine-Proxy- und Enforcement-Komponente, die mit den im Director definierten Regeln arbeitet.

Enzo verlangt weder Baselines noch Geschäftslogik oder erweitertes Wissen über die zu Grunde liegende Datenbankstruktur. Das Produkt setzt basierend auf MAC- oder IP-Adressen, einem vom Administrator definierten Schedule, der Client-Identität oder der Applikation einfach die eingestellten Regeln durch. Man kann sich das eher als eine Stateful-Datenbank-Firewall vorstellen, weniger als ein Pakete untersuchendes IPS oder IDS. Der Administrator erledigt die schweren Regeldefinitionen. Ein wenig Hilfe erhält er dabei von den auf Hosts oder dem Netzwerk basierenden ACLs.

Die einzigartige Feature-Sammlung des Produkts dreht sich um die Client-Authentifizierung. Der Administrator definiert Zugriffsrechte über ein Alias, das sich völlig von dem in der Datenbank selbst verwendeten unterscheiden kann. Nehmen wir einmal an, der Client-Zugriff ist in Enzo unter Verwendung des in Active-Directory existierenden Kontos »John Doe« definiert. Greift der Client nun durch Enzo als John Doe auf die Datenbank zu, übersetzt Enzo die Verbindung in eine andere Client-Identität, um die Transaktion durchzuführen. Das ist nützlich, wenn Applikationen, die mehrere IDs nutzen, über ein einzelnes Konto mit der Datenbank kommunizieren, das Unternehmen aber trotzdem eine genaue Protokollierung aller Client-Aktivitäten benötigt. Enzo erledigt die Übersetzung und liefert einen Audit-Trail.

Das Produkt unterstützt die Zwei-Faktoren-Authentifikation mit RSA und Cryptocard. Für den Test stand ein Kit von Cryptocard zur Verfügung. Das zusätzliche Setup war nicht der Rede wert. Der einzige Nachteil dieser Lösung mit dem Client-Alias und der Zwei-Faktoren-Authentifizierung ist, dass das Produkt Oracle nicht unterstützt.

Enzo unterstützt wie Securesphere die Benachrichtigung via Syslog und SMTP-Server. Sind auf den empfangenden Servern gescheite Filter und Regeln eingerichtet, können Administratoren bösartige Aktivitäten fast in Echtzeit erkennen. Enzo protokolliert alle Ereignisse über eine ODBC-Verbindung auch in einer Datenbank.

Die eingebauten Berichtsfähigkeiten sind schlicht, das Produkt bietet aber eine schnelle Übersicht, was aktuell mit jeder Enzo-Engine vor sich geht. Die meisten Unternehmen werden einen Security-Information-Manager (SIM) einrichten, um die durch Syslog oder ODBC verfügbaren Logs zu nutzen.

Kleinere Organisationen werden Enzo-2006 passend finden. Ihnen liefert das Produkt feingliedrigen Client-Zugriff, Konto-Aliasing und eine zusätzliche Schicht Sicherheit zwischen Clients und Datenbankservern. Dem Produkt fehlen aber Features, beispielsweise SSL-Verschlüsselung, Regeln für die Entdeckung aktueller Datenlecks und eine automatische Aufzählung von Datenbanken, Clients und Nutzungsmustern. Unternehmen mit einer riesigen Anzahl von Datenbanken und mehreren Tausend Clients werden bei Enzo einige vermissen.


RippleTech Informant

Informant ist ein Tipp für Unternehmen, denen tiefgreifende Datenbank-Logging-Fähigkeiten fehlen. Wer nicht genau weiß, was als anormales Verhalten zu gelten hat, ist mit Informant ebenfalls gut bedient. Das Produkt schützt wichtige Daten, ohne die Bank zu sprengen.

Informant läuft unter Linux. Rippletech offeriert nicht nur die Software, sondern auch Appliances mit verstärkter Linux-Installation und installierter sowie optimierter Informant-Software. Getestet wurde die Appliance-Version.

Selbst mit rund 5000 Dollar für die Appliance-Version ist Informant noch das preiswerteste DBEP-System. Trotzdem fehlt es nicht an Funktionalität. Gegenwärtig unterstützt Informant Oracle, Microsoft-SQL-Server, DB2 und MySQL. Das Produkt überwacht auch HTTP-Verkehr.

Durch Beobachtung der Datenbankaktivität über einen Span-Port inspiziert Informant den gesamten SQL-Verkehr. Das schließt Benutzer- und administrative Aktivitäten ein, nicht aber die von SQL-Queries gelieferten Inhalte. Letzteres ist beachtenswert, denn zu wissen, was die Datenbank zurückgeliefert hat, kann dabei helfen, den Erfolg oder Misserfolg eines Angriffs zu bestimmen. Das Produkt ist aber nicht besonders gehindert durch diesen fehlenden Einblick in Inhalte, denn glücklicherweise kann es, basierend auf der Anzahl der zurückgelieferten Zeilen, alarmieren. Somit zeigt es bei SQL-Injection- oder bösartigen Insider-Angriffen, die in einer großen Menge Daten resultieren, die rote Flagge, ohne dass es dabei Daten enthüllt.

Informant verfolgt nicht nur die Netzwerkaktivität, sondern überwacht auch lokales Datenbank-Management. Dazu nutzt das Produkt auf Hosts basierende Agenten, die für Redhat-Enterprise-Server, »CentOS«, Solaris 8 und 9 (Sparc) sowie AIX 5.2 und 5.3 verfügbar sind. Für Windows gibt es noch kein lokales Monitoring.

Die wahre Kraft von Informant versteckt sich in den Ausdrücke nutzenden Regeln. Administratoren können Regeln manuell konfigurieren oder definierte Regelsammlungen verwenden. Definierte Regeln basieren entweder auf dem Typen der überwachten Datenbank oder dem Zweck des Monitorings, beispielsweise Compliance, Sicherheit, Performance oder Auditing. Für die meisten IT-Gruppen lassen sich die Regeln feinkörnig genug schreiben. Für den Test wurden Regeln geschrieben, die klaglos viele Aufgaben erledigten. Beispielsweise wurde das System veranlasst, einen Alarm auszulösen, wenn über eine unbekannte IP-Adresse versucht wird, auf eine bestimmte Tabelle zuzugreifen oder mehr als zehn Zeilen abzurufen.

Informant funktionierte prima bei Angriffen, bei denen es um Massendaten-Transfers ging, aber weniger gut bei kleineren Mengen leckender Daten. Angriffe von der E-Commerce-Site entdeckte Informant, sobald die Datenbank mehr als eine Zeile zurücklieferte. Erfolgreich war der Angriff, als die Datenbank langsam Satz für Satz durchsucht wurde. Für die Windows-Plattform stand kein Agent zur Verfügung. Somit konnten Insider-Angriffe unter Verwendung der lokalen Konsole nicht getestet werden. Allerdings lösten alle Versuche, Daten abzurufen, die durch die Privilegien des aktuellen Benutzers nicht erlaubt waren, den Regelmechanismus aus.

Informant enthält deutlich mehr Logging-Features als die Produkte von Imperva und Pyn Logic. Die Protokollierung und Alarmierung erfolgt über Standard-Syslog, SNMP-Traps, SMTP-Nachrichten, die Ausführung von benutzerdefinierten Scripts oder Einfügung in Microsoft-SQL-Server. Es gibt kein Dashboard für das Monitoring von Alerts. Unternehmen können ein externes Siem nutzen, einen Syslog/SNMP-Monitor implementieren oder sich auf das Logging zum Microsoft-SQL-Server verlassen. Für den Test wurde der letzte Weg gewählt. Die entsprechende SQL-Server-Instanz nutzte Rippletechs Log-Caster für das Log-Management und die Reporting-Dienste von SQL-Server-2005 für das Ereignis-Monitoring, Compliance-Reporting und forensisches Auditing. Dies erwies sich als kraftvolle Kombination für Berichterstellung und Auditing.

Das Management von Informant ist extrem simpel. Zu verdanken ist das der für Konfiguration und Management genutzten Web-Schnittstelle. Wer sich für die Appliance entscheidet, wird die Open-Source-Webmin-Software für das System-Management finden.

Informant ist ein kraftvolles Werkzeug, das zeigt, was in den Unternehmensdatenbanken vor sich geht. Der Preis des Produkts ist unter den getesteten Systemen gegenwärtig der niedrigste.

Guardium SQL Guard

Guardium wirft nahezu jedes Feature in die Schlacht, das Administratoren benötigen, um wertvolle Daten zu verriegeln. Lediglich ein sich kümmernder, sympathischer Auditor fehlt.

SQL-Guard kam auf einem saftigen Dell-1HE-Server, der entweder inline oder out-of-band eingesetzt werden kann. In beiden Fällen arbeitet SQL-Guard als echtes Extrusion-Prevention-System, das inline Verkehr fallen lässt und out-of-band TCP-Reset-Pakete zum Angreifer und zur Datenbank sendet. Während des Tests gab es mit keiner Variante Schwierigkeiten. Das alltägliche Management war dank einer gut entworfenen Web-Schnittstelle eine Kleinigkeit. Aber so intuitiv sich die Schnittstelle auch bedienen lässt, die schiere Anzahl der auf jeder Seite verfügbaren Features verlangt gelegentlich den Griff zur Dokumentation.

SQL-Guard unterstützt Oracle-8i, -9i und -10G, Microsoft-SQL-Server-2000 und -2005, Sybase-ASE/IQ, IBM-DB2 und Informix. Die primäre Methode, Datenbankaktivität zu analysieren, ist das Monitoring des Netzwerkverkehrs zum Datenbankserver. Das funktioniert hervorragend, wenn die Topologie das Hinzufügen einer Netzwerk-Appliance unterstützt. Wo dies ein Problem ist, unterstützt Guardium das Monitoring der Datenbankaktivität mit ihrer S-TAP-Software-Probe. S-TAP kann sowohl Netzwerk-Datenbankaktivität als auch die Aktivität der lokalen Konsole beobachten. Die Probe unterstützt HP-UX, Solaris, Linux, AIX, OSF1 und Windows-Betriebssysteme.

Für den Test wurde S-TAP ohne Probleme auf einem Windows-Server-2003-R2-System installiert. SQL-Guard berichtete über sämtliche durch die lokale SQL-Managementkonsole generierte Datenbankaktivität.


Die Automation ist eine der Stärken von SQL-Guard. Nahezu jede Aufgabe, von der Datenbankserver-Entdeckung bis zur Klassifizierung der Daten, lässt sich automatisieren. Im Test wurde das System für einen täglichen Scan des Netzwerks konfiguriert, um neue Datenbankserver zu entdecken und entsprechende Profile zu erzeugen. Zuerst führte SQL-Guard für definierte IP-Adressen und Ports einen Port-Scan durch. Danach bestimmte das Produkt, welcher Typ von Datenbankserver auf den Port hört. Diese Informationen schrieb SQL-Guard in einen Bericht.

Da sich die Inhalte von Datenbankservern kontinuierlich ändern, ist von keinem Sicherheitsprofi, Auditor oder Datenbankadministrator zu erwarten, dass er jede einzelne Instanz privater oder gemeinsamer Daten kennt. SQL-Guard 6.0 enthält glücklicherweise eine automatische Klassifizierung, die sich auf Datenmuster, Spalten- und Zeilennamen oder Berechtigungen stützt. Die Testserver enthielten Sozialversicherungs- und Kreditkartennummern. Also wurden Klassifizierungsaufgaben definiert, die diese Daten unter Verwendung regulärer Ausdrücke suchten. SQL-Guard identifizierte die Daten korrekt.

Die Regeln von SQL-Guard bieten viel Flexibilität. Jede Kombination von auf Datenbankaktivitäten bezogenen Informationen lässt sich als Auslöser nutzen. Dazu zählen Informationen wie die Client- oder Server-IP-Adresse, der Datenbankname, der Datenbankbenutzer, Datenmuster, SQL-Kommandos, die Quell-Applikation und mehr. Eines der nützlichsten Features zur Regelerzeugung war der Policy-Simulator, der Regeln gegen aktuell in SQL-Guard protokollierte Daten testet. Beim Erzeugen von Regeln mit regulären Ausdrücken überprüft ein nützliches Werkzeug in der Web-Schnittstelle, ob diese regulären Ausdrücke korrekt sind.

Auch SQL-Guard behandelte Angriffe gut, wenn große Mengen von Daten aus der Datenbank gesaugt wurden. Im Test wurde eine Regel erzeugt, um den Diebstahl von Informationen von der E-Commerce-Web-Site zu entdecken, selbst wenn diese Informationen einen Satz nach dem anderen gestohlen werden. Das funktionierte. Allerdings könnte diese Regel für einen großen Online-Shop unpraktisch sein, denn sie stützte sich auf eine Mindestanzahl von Ereignissen innerhalb eines spezifischen Zeitintervalls, der in Minuten zu definieren war. Ein paranoider Angreifer könnte leicht ein Tool schreiben, das alle fünf Minuten oder gar jede Stunde einen einzelnen Satz stiehlt.

Mehr als 100 konfigurierte Berichte sollten jeden Administrator, Auditor und Boss befriedigen können. Benutzerdefinierte Berichte zu erzeugen, bedarf simpler Drag-and-Drop-Aktionen. Die Berichte lassen sich drucken, als CSV-Dateien speichern oder als PDFs exportieren. Angesichts der extensiven Berichtsfähigkeiten und zahlreichen Status-Dashboards werden viele Organisationen ohne externes Siem auskommen. SQL-Guard unterstützt aber auch gleich Produkte wie Arcsight und Network-Intelligence.

Guardium hat eine solide Feature-Sammlung zusammengestellt, die Sicherheitsprofis, welche die Kontrolle über Datenbankaktivitäten zurückerlangen wollen, gefallen wird. Mit verschiedenen Deployment-Optionen, extensiven Regeln, flexibler Berichterstellung und automatischer Datenklassifizierung und Datenbankentdeckung liefert SQL-Guard 6.0 wahre Datenbank-Extrusion-Prevention.

Crossroads StrongBox DB Protector

Strongbox-DB-Protector zeigte die am einfachsten zu nutzende Benutzungsschnittstelle und viele attraktive Grafiken, die auf den oberen Etagen gefallen werden. Dem Produkt fehlen aber einige Features, beispielsweise führt es weder ein Datenbank-Security-Assessment durch, noch blockiert es Out-of-band-Verkehr.

DB-Protector traf als 2HE-.Appliance in den Real-World Labs ein. Nach dem Einbau ins Rack war die anfängliche Konfiguration schnell und einfach. Die Einrichtung des Systems erfolgt inline oder out-of-band unter Verwendung eines Switch-Monitoring-Ports, der sämtlichen Verkehr des Datenbankservers beobachtet. Die Einrichtungsmethoden sind zwar mit denen von Guardium und Imperva gleich, blockieren kann DB-Protector aber nur dann, wenn die Appliance inline installiert ist. Auch Host-Agenten sind gegenwärtig nicht verfügbar. Also geht jede Aktivität auf der lokalen Datenbankserver-Konsole verloren.

DB-Protector unterstützt IBM-DB2 8.1 und 8.2, Microsoft-SQL-Server-2000 und -2005 sowie Oracle 9i und 10g. Bevor das System diese Datenbanken schützen kann, muss es sie mappen, um das Datenbank-Layout zu verstehen. Der Mapping-Prozess ist simpel: Der Administrator muss lediglich Anmeldeinformationen für alle zu schützenden Datenbanken eingeben. Das Produkt importiert dann Informationen über Tabellenstrukturen, Benutzer, gespeicherte Prozeduren und mehr. Da viele Auditoren interne Namenskonventionen nicht verstehen werden, liefert Crossroads etwas, das Business-Objects heißt. Dabei handelt es sich im Wesentlichen um Alias-Namen, die nach dem Mapping definiert werden können, um die Richtlinienentwicklung und Auditbewertung benutzerfreundlicher zu machen.

Organisationen, die unter dem Druck von Compliance und Regulierungen stehen, werden die fein unterscheidbaren Rollen in DB-Protector zu schätzen wissen. Ein Appliance-Administrator könnte beispielsweise Privilegien besitzen, nur um die Appliance zu konfigurieren und Berichte zu sehen, welche die Gesundheit des Systems betreffen. Auditoren können Reviewer-Privilegien erhalten, die ihnen ausschließlich Zugriff auf Berichte über Datenbankaktivitäten gewähren. Überraschender Weise fehlt die Unterstützung externer Verzeichnisse. Das bedeutet, dass alle Benutzer, die auf DB-Protector zugreifen, lokale Konten haben müssen.

Die Benutzungsschnittstelle basiert auf Java und wurde sehr gut entworfen. Menüs sind intuitiv angelegt, das Dashboard mit Diagrammen und Grafiken ist attraktiv, und die Online-Hilfe geht ans Eingemachte. Ein tiefer Einstieg in die verschiedenen Grafiken und Diagramme ist möglich. Doppelklicks liefern detaillierte Einträge für Benutzer-, Tabellen-, Spalten- und Richtlinienaktivitäten.

Die Richtlinien von DB-Protector sind als ein- oder ausschaltend definiert. In der Standardeinstellung blockiert das System zunächst sämtliche Aktivitäten. Später erlaubt es sie durch die Erzeugung von einschaltenden Richtlinien. Crossroads empfiehlt, die einschaltenden Richtlinien ein wenig breit anzulegen, die ausschaltenden spezifischer. Ist extrem hohe Sicherheit erforderlich, empfehlen wir allerdings, die einschaltenden Richtlinien so präzise wie möglich zu gestalten. Dabei ist aber darauf zu achten, nicht zu viel administrativen Overhead durch zu komplexe Richtlinien zu erzeugen.

Zunächst erschienen die Parameter für die Richtlinienerzeugung sehr eingeschränkt. Bei fortschreitender Arbeit mit der Schnittstelle und Erzeugung mehrere Regeln zeigte sich jedoch, dass dies nicht der Fall ist. Richtlinien erzeugt der Administrator mit einem kontextsensitiven Assistenten, der nur die Parameter zeigt, die jeweils relevant sind. Was relevant ist, entscheidet der Assistent abhängig davon, ob die Richtlinie Datenbankobjekte, Datenbankantworten, genutzte Applikationen, die Uhrzeit, SQL-Auswirkungen (access, modify, execute) oder zurückgelieferte Zeilen betrifft.

DB-Protector schlug sich bei der Konfrontation mit Angriffen so gut (oder schlecht) wie die anderen Testkandidaten. Das Produkt bemerkte den Abruf einer großen Anzahl von Datensätzen über die E-Commerce-Applikation, schlief aber, als ein Satz nach dem anderen geklaut wurde. Inline eingesetzt, blockierte die Appliance entdeckte Angriffe, out-of-band sendete sie einen Alarm.

Crossroads Schnittstellen-Entwicklungsteam hat beeindruckende Arbeit geleistet und DB-Protector extrem benutzerfreundlich gemacht. Organisationen, die ein Datenbank-Extrusion-Prevention-System suchen, sollten DB-Protector mit auf die Liste der zu prüfenden Angebote setzen.
dj@networkcomputing.de

Verwandte Artikel