DOAG Deutsche ORACLE-Anwendergruppe e.V.
|  
   

„Es geht darum, den DBA zu entlasten“

Mit der Version 12c der Oracle Datenbank kommen auch neue Funktionen im Sicherheitsbereich hinzu. Alexander Kornbrust, Geschäftsführer von Red-Database-Security, wird in seinem zweitägigen Expertenseminar „Härten von Orcale 12c Datenbanken“ im Detail darauf eingehen. Im Interview erklärt er vorab, mit welchen typischen Problemen Oracle-DBAs konfrontiert werden und dennoch für eine sichere Datenbank sorgen können.

Herr Kornbrust, mit welchen Herausforderungen müssen Sie sich am häufigsten beschäftigen?

Das sind die üblichen Themen: Unsichere Standardkonfigurationen, unsicheres PL/SQL, das vom Kunden selbst geschrieben wird, und immer wieder schwache Passwörter. Das ist typisch Mensch: Zuerst benutzt man ein einfaches Passwort. Wenn das System läuft, kommen Bedenken, ob das Passwort nachträglich geändert werden soll. Ein Beispiel: Sie haben eine Anwendung mit dem Namen GRIPS geschrieben, dann wird die Datenbank GRIPS genannt, der User heißt GRIPS und für das Passwort nimmt man auch GRIPS. Das kommt sehr häufig vor: Etwa 20 Prozent aller Passwörter sind schwach, kommen in einem Wörterbuch vor oder noch schlimmer: Das Passwort ist der Benutzername.

Was thematisieren Sie in Ihrem Expertenseminar „Härten von Oracle 12c Datenbanken“?

Es geht darum, zuerst einmal die typischen Sicherheitsprobleme mit Oracle Datenbanken kennenzulernen und die Datenbank regelmäßig zu kontrollieren – im Idealfall mit einem automatischen Prozess. Denn solange IT-Sicherheit nur eine Geschichte auf Papier ist, bringt das kein Unternehmen weiter. Sicherheitstests müssen regelmäßig und automatisiert ablaufen, um Schwachstellen zu eliminieren.

Lohnt sich ein Upgrade auf 12c nur aus Sicherheitsgründen?

Grundsätzlich sind in der Datenbank 12c viele Sicherheitslücken korrigiert worden, die noch in der Version 11 vorhanden waren. Es sind aber auch neue Funktionen hinzugekommen. Bei 12c ist zum Beispiel die Passwortsicherheit wesentlich verbessert worden. Ein sinnvolles neues Feature ist die Inherit-Privileges-Funktion, die die Privilegieneskalation via SQL Injection in PL/SQL Packages wesentlich erschwert. Auch Unified Auditing und Audit Policies sind für Kunden, die das Oracle Native Auditing verwenden sehr sinnvoll, auch wenn es aktuell noch an der einen oder anderen Stelle hakt. Es sind aber nicht die einzigen Alleinstellungsmerkmale, die ein Upgrade rechtfertigen würden. Die Datenbank allgemein muss sicher sein. Mir ist eine gut abgesicherte Datenbank 11 lieber als eine noch nie überprüfte 12c. Eine neue Version bedeutet immer auch Unsicherheit, das darf man nicht vergessen.

Security Benchmarks können die Datenbank-Sicherheit erhöhen. Welche Schwierigkeiten ergeben sich bei der Umsetzung?

Die Benchmarks sind Best Practices aus der Security-Welt. Sie geben Handlungsanweisungen, wie ein System konfiguriert werden sollte, damit es sicherer ist. Hier gibt es verschiedene Organisationen, die solche Standards definieren. Die bekannteste und größte dieser Organisationen ist das Center for Internet Security (CIS), eine Non-Profit-Organisation. In der CIS kommen Experten aus aller Welt zusammen und definieren Security-Benchmarks. Je mehr Praktiker daran arbeiten, desto besser und realistischer werden diese Tests, so dass sie auch umsetzbar sind. Das Problem: Man kann die Tests nicht eins zu eins übernehmen, sondern muss noch Anpassungen an die eigene individuelle Konfiguration vornehmen. Diese Abweichungen sollten aber immer gut dokumentiert werden, damit Dritte oder Auditoren bei einer Überprüfung auch verstehen, warum der Standard aus dem Benchmark geändert wurde.

Wie läuft denn eine Auditierung ab?

Bei einer Auditierung werden kritische Aktivitäten in der Datenbank überprüft. Das kann zum Beispiel der Aufruf von bestimmten Funktionen oder das Anlegen eines neuen Benutzers sein. Die Auditing-Technologien, sei es das Native Auditing oder die Lösung eines Drittherstellers, sollten in die individuelle Umgebung des Kunden eingepasst werden. In größeren Unternehmen werden ja nicht nur Oracle-Datenbanken verwendet, sondern auch DB2, SQL-Server oder MySQL. Die Technologie muss im Unternehmen verankert werden. Und das kann zu Problemen führen, wenn verschiedene Datenbanken gleichzeitig genutzt werden. Hier gilt es zu überlegen, welche Strategie man verfolgt und auch, wofür die Audit-Daten weiter genutzt werden sollen.

Die Datenbank ist nicht die einzige gefährdete Schnittstelle in einem Unternehmen. Wo können weitere Risiken entstehen?

Der Datenbankadministrator hat erstaunlicherweise relativ wenig mit der Datenbanksicherheit zu tun. Die größeren Probleme kommen aus der Anwendungsentwicklung. Sie können die Datenbank noch so sicher konfigurieren. Wenn die Anwendung unsicher entwickelt wurde, dann kann der DBA auch nichts machen. Ein Passwort ist schnell geändert, aber wenn sie eine ganze Applikation anpassen und überprüfen müssen, sind sie unter Umständen jahrelang damit beschäftigt.

Warum liegt der Fokus in dem Seminar auf Datenbankadministratoren?

Mein Fokus für das Expertenseminar ist, dass die Teilnehmer das gelernte Wissen in die Praxis umsetzen können. Security-Themen belasten den DBA oft mit viel Arbeit. Im Seminar möchte ich zeigen, wie der DBA entlastet werden kann. Wenn Benchmark-Tests einmal im System implementiert sind, dann wird die Überprüfung von Sicherheitsstandards erleichtert.

07.02.2017 Datenbank, Database 12c, Security
Von: DOAG Online