Oracle 12c - Das umfassende Handbuch

Kapitel 19

Erweiterte Sicherheitsthemen

462

Ein sehr sinnvolles Feature, das leider seit der Einführung auch von dem einen

oder anderen Bug begleitet wurde. So wurden in bestimmten Situationen Sperren

im Row Cache oder Library Cache nicht wieder aufgehoben, sodass sich der Benut-

zer gar nicht mehr anmelden konnte. In diesem Fall steht der Datenbankadminis-

trator vor dem Problem, den Zugriff wieder zu ermöglichen. Ein Neustart der

Datenbank ist eine Option, die mit viel Aufwand und Nebeneffekten verbunden

ist.

Das Vorgehen ist auch sinnvoll, wenn Sie die Verzögerung aus anderen Gründen

verhindern wollen. Beachten Sie jedoch, dass damit Angriffe erleichtert werden,

und treffen Sie zusätzliche Maßnahmen, um diese zu erschweren. Durch Entfer-

nen des Events wird das Feature wieder eingeschaltet und der Standard herge-

stellt:

19.4 Datenbankaudits

Die Durchführung von Datenbankaudits steht in allen größeren Unternehmen

auf dem Plan und wird durch Corporate Governance-Prozesse forciert. Die Art

und Weise der Durchführung variiert sehr stark von Unternehmen zu Unterneh-

men.

Beachten Sie an dieser Stelle, dass die Umsetzung von Sicherheitspolicen und

Unternehmensstandards zwar einen hinreichend guten Schutz für Standardda-

tenbanken gewährleisten, allerdings für kritische und sensitive Daten nicht ausrei-

chend ist. Bedenken Sie dabei, dass die Oracle-Datenbank, so wie sie vom

SQL*Plus: Release 12.1.0.1.0 Production on Sat Mar 29 19:57:50 2014

Copyright (c) 1982, 2013, Oracle. All rights reserved.

SQL> ERROR:

ORA-01017: Benutzername/Kennwort ungültig; Anmeldung abgelehnt

. . .

SQL> Sat Mar 29 19:58:00 AST 2014

SQL*Plus: Release 12.1.0.1.0 Production on Sat Mar 29 19:58:00 2014

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Tipp

Es gibt die Möglichkeit, durch Setzen des Events 28401 das Feature abzuschalten

und damit die Sperren aufzuheben:

SQL> ALTER SYSTEM SET EVENTS '28401 trace name context forever, level 1';

Listing 19.7: Den Verzögerungsmechanismus für fehlerhafte Logins ausschalten.

SQL> ALTER SYSTEM SET EVENTS '28401 trace name context off';

19.4

Datenbankaudits

463

Hersteller standardmäßig ausgeliefert wird, angreifbar ist. Der vorige Abschnitt

hat das eindeutig demonstriert. Aus diesem Grund sollte ein Datenbank-Audit

eine Doppelstrategie enthalten:

쐽 Überprüfung aller Datenbanken auf Einhaltung der Policies und Standards.

쐽 Überprüfung der unternehmenskritischen Datenbanken und der Datenban-

ken mit sensitiven Daten auf die Erfüllung erhöhter Sicherheitsanforderun-

gen.

Der erste Teil kann relativ einfach erfolgen. In der Regel wählt man Datenbanken

zufällig aus und überprüft diese mit einem automatischen Scan-Programm.

Der zweite Punkt erfordert mehr Aufwand und tiefgehendes Fachwissen. Dieser

Teil sollte deshalb von einem Sicherheitsspezialisten erledigt werden. Der Einsatz

eines externen Auditors hat außerdem den Vorteil, dass dieser unvorbelastet und

ohne Kenntnis der internen Besonderheiten an die Prüfung herangeht. Ein simu-

lierter Hackerangriff auf eine Testdatenbank bringt zusätzliche Informationen

über den realen Sicherheitsstatus.

Auf der Internetseite des Bundesamt für Sicherheit in der Informationstechnik (BSI)

finden Sie nützliche Informationen zur Durchführung von Audits sowie zur Ein-

stufung von Sicherheitslücken. Unter anderem finden Sie dort Material zu den

zusätzlichen Anforderungen für das Finanz- und Versicherungswesen. Die BSI-

Webseiten finden Sie unter

http://www.bsi.de.

Wie bereits mehrfach diskutiert, kann die Sicherheitsüberprüfung einer Oracle-

Datenbank aufgrund ihrer immer stärker werdenden Integration in andere Berei-

che der IT-Infrastruktur nicht ohne Einbeziehung des weiteren Umfelds stattfin-

den. Neben speziellen branchenbezogenen Anforderungen an Audits haben sich

einige auf die Architektur bezogene Betrachtungsweisen weltweit durchgesetzt:

쐽 OWASP Top Ten Most Critical Web Application Security Vulnerabilities.

Website:

http://www.owasg.org.

쐽 SANS Top Twenty Most Critical Internet Security Vulnerabilities.

Website:

http://www.sans.org.

Die Standards und Empfehlungen auf diesen Webseiten werden ständig aktuali-

siert und den sich verändernden Bedingungen angepasst und sollten im Audit

berücksichtigt werden.

Wichtig ist, dass vor dem Start des Audits Klarheiten über die Einstufung der

Sicherheitslücken herrschen. Ein nachträgliches Verschieben von Einstufungen

erweckt den Anschein von Manipulation und entspricht nicht den Richtlinien für

ein Audit. Das BSI unterscheidet die folgenden Risikoklassen. Wenn in Ihrem

Unternehmen eigene Risikoklassen verwendet werden, dann sollten diese ent-

sprechend zugewiesen werden.

Kapitel 19

Erweiterte Sicherheitsthemen

464

Unabhängig von der Einstufung in Risikoklassen sind die folgenden Ergebnisse

als Mängel zu betrachten:

쐽 Es wurde festgestellt, dass mit einfachen Mitteln eine erfolgreiche Kompromit-

tierung von Systemen stattfinden kann.

쐽 Es ist kein geeigneter Passwortschutz gegeben.

쐽 Der Authentifizierungsprozess kann umgangen werden.

쐽 Sensitive Daten konnten unberechtigt ausgelesen werden.

쐽 Es besteht die Möglichkeit, mit einfachen Mittel den Betriebsablauf zu stören.

쐽 Es liegt eine Verletzung von Sicherheits-Policies und -Standards des Unterneh-

mens vor.

In jedem Fall sollte ein Abschlussbericht erstellt werden, der den beteiligten Berei-

chen zur Verfügung gestellt wird. Erstellen Sie ein vollständiges und anonymisier-

tes Exemplar des Berichts. Die anonymisierten Dokumente dürfen keine

Passwörter oder Informationen enthalten, die die aktuelle Sicherheit kompromit-

tieren. Das Original sollte unter Verschluss aufbewahrt werden.

Eine festgestellte Sicherheitslücke sollte mindestens die folgenden Charakteristi-

ken enthalten. Bedenken Sie dabei, dass die Berichte nicht nur von technischen

Spezialisten gelesen werden.

쐽 Beschreibung der Sicherheitslücke

쐽 Risikoklasse

쐽 Ausnutzbarkeit (komplex, einfach)

쐽 Impact und Aufwand für die Beseitigung

쐽 Detaillierte technische Beschreibung

쐽 Referenzen (White Paper, Bug-Nummer)

쐽 Angreifergruppe (Hacker, Experten, Innentäter)

쐽 Notwendiges Wissen

쐽 Erforderliche Gegenmaßnahmen

쐽 Prüfungsmöglichkeiten

쐽 Nachweis (Log-Dateien)

Gefährdungsklasse Kritikalität

Kritisch Konzern Hoch

Kritisch Unternehmen Hoch

Nicht kritisch Mittel

Informativ Niedrig

Keine Keine

Tabelle 19.1: Risikoklassen des BSI