Lifecycle- & Security Management für Oracle

DatenbankenBedeutung für sicheres Business und Lösungsansätze zur Umsetzung

Ein White Paper der avato consulting ag

update

Seite 2/15

update

Control Table

Change History

Gegenstand

Dieses Dokument beschreibt die Anforderungen an die Security bei Oracle-Datenbanken, sowie pragmatische Umsetzungen und zeigt Strategien im Oracle Lifecycle Management auf

Version Date Revision Description Revision Details, Authors

1.0 27.03.2012 Lifecycle Management Lutz Fröhlich

1.1 02.12.2012 Zusammenführen der Whitepaper zu

Lifecycle Management und Security

Ronny Egner, Lutz Fröhlich, Ralph

Baumbach

Contact Person: Ronny Egner

Lutz Fröhlich

Classification White Paper Lifecycle- & Security Management für Oracle Datenbanken

Functional Applicability:

Last Revision Date: 02.12.2012

Version: 1.1

Seite 3/15

update

Inhalt1 Lifecycle-Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Release-Policy und Release-Planung für Oracle-Datenbanken . . . . . . . . . . . . . . . 5 1.2 Database Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Sicherheit von Datenbank-Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Configuration-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Bedeutung von IT-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Sicherheitsaspekte bei Oracle-Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Härtung von Datenbanksystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Trennung der Zuständigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Autorisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 Verschlüsselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7 Anonymisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.8 Auditierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.9 Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten. . . . . . . . . . . 14 3.10 Schutz gegen „Einschleusen“ unerwünschter Codes . . . . . . . . . . . . . . . . . . . . . . 14 4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

5 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Seite 4/15

update

1 Lifecycle- & Security

Auf den ersten Blick haben beide Themen nicht viel miteinander zu tun. Betrachten wir zunächst das Lifecyc-le-Management. Im Lifecycle einer Datenbank spielt das Release-Management eine signifikante Rolle. Nach ITIL wird das Release-Management strikten Prozessen unterworfen (siehe Abbildung 1). Danach ist es unum-gänglich, mit einer Release-Policy zu arbeiten und eine konsequente Release-Planung zu verwenden.

Abbildung 1 Release-Management nach ITIL

Auf den ersten Blick hat das Prinzip, die Version einer Datenbank möglichst wenig zu ändern, einen gewissen Charme. Das System läuft stabil, es entstehen keine Kosten für Upgrade oder Regressionstests und keine Downtime. Was, wenn jetzt eine Sicherheitslücke geschlossen werden muss, die alle Datenbanken betrifft? Im Umfeld einer größeren Anzahl von Datenbanken können Sie mit dieser Strategie in eine Situation kommen, in der in kurzer Zeit viele Datenbanken auf den neuesten Stand gebracht werden müssen. Häufig fehlen dann die Vor-aussetzungen und Kapazitäten. Ein aktives Release-Management zahlt sich in solchen Fällen aus.

Doch was ist zum Beispiel die Situation einer Oracle-Datenbank der Version 8, die seit 10 Jahren läuft im ak-tuellen Umfeld:

• Die Version ist vom Hersteller nicht mehr supported.• Zwei kritische Sicherheitspatches stehen nicht zur Verfügung.

Seite 5/15

update1.1 Release-Policy und Release-Planung für Oracle-Datenbanken

Welche Release-Policy ist also zu empfehlen? Die Oracle-Datenbankversion ist nach dem folgenden Schema aufgeteilt: A.B.C.D.E (z.B. 11.2.0.2.5).

• A: Major Release Number• B: Maintenance Release Number• C: Application Server Release Number (für Datenbanken immer „0“)• D: Component Specific Release Number• E: Platform Specific Release Number (Patch Set Number)

Für die Major Release Number sollte man generell warten, bis sich die Software auf dem Markt etabliert hat, zumal ein Major-Release-Wechsel immer einen kompletten Regressionstest und die Zertifizierung des Ven-dors der Applikation voraussetzt. In den letzten Jahren hat Oracle genau zwei Maintenance Releases heraus-gebracht. Viele Kunden verfolgen die Strategie, die Version 1 zum Kennenlernen der neuen Features und zur Weiterbildung der Techniker zu benutzen und mit der Version 2 dann produktiv ins Rennen zu gehen.Innerhalb der Maintenance Release Number ist zu empfehlen, zeitnah auf das letzte Component Specific Release zu migrieren. Damit erhöht sich unter anderem die Verfügbarkeit von zusätzlichen Patches. Und was passiert dazwischen?Für das Release-Management zwischen der Component Specific Release Number bietet Oracle Critical Patch Updates (CPU) und Patch Set Updates (PSU) an. Bei den CPUs handelt es sich um eine Zusammenfassung kritischer Sicherheitspatches, die zeitnah eingespielt werden sollten, um Sicherheitslücken zu schließen. Sie erscheinen quartalsweise. Ein PSU ist eine Sammlung von wichtigen Patches und erscheint unregelmäßig. Ein PSU enthält immer den letzten verfügbaren CPU und kann als weiteres Zwischen-Release angesehen werden.Eine sinnvolle Strategie ist, das letzte verfügbare PSU stets zeitnah einzuspielen und dazwischen jeden CPU zu bewerten und dann einzuspielen, wenn er aus Sicht der Security-Policy des Unternehmens kritische Sicher-heitslücken schließt.Mit Hilfe des Oracle Enterprise Manager ist es möglich, das Patchen und das Upgrading von Datenbanken weitgehend zu automatisieren.

Integriert in den Enterprise Manager Grid Control bietet das Provisioning & Patch Automation Pack u.a. folgende Leistungen:

• Automatisiertes Patchen von Oracle-Produkten und des Betriebssystems• Patch-Empfehlungen• Software-Bibliothek• Integration in My Oracle Support• Flexible Deployment-Prozeduren• Automatisierung von Rolling Patches und Upgrades im Hochverfügbarkeits-Umfeld

Seite 6/15

update

1.2 Release-Planung am BeispielNehmen wir an, in Ihrem Unternehmen wird die Entscheidung getroffen, dass der CPU Januar 2012 für alle Datenbanken einzuspielen ist. Am Anfang der Planung steht die Bestandsaufnahme der vorhandenen Daten-bank-Versionen. Wertvolle Unterstützung liefert hier der Oracle Enterprise Manager, der eine Gesamtüber-sicht zur Verfügung stellt.

Database Installations Targets Installations

Interim Patches Applied

Oracle Database 10g 10.2.0.2.0 0 2 YesOracle Database 10g 10.2.0.3.0 71 92 YesOracle Database 10g 10.2.0.4.0 158 165 YesOracle Database 11g 11.1.0.7.0 26 46 YesOracle9i 9.2.0.8.0 0 3 Yes

Abbildung 2 Versionsübersicht im Enterprise Manager

Im weiteren Verlauf sollte man sich eine Übersicht der zur Verfügung stehenden Patches verschaffen. Für den CPU Januar 2012 sehen Sie unten eine Liste in Tabelle 1. In der letzten Spalte finden Sie die Patch-Nummer, mit deren Hilfe der Patch schnell zu identifizieren ist. Die Tabelle enthält die letzten Versionen. Die Patches für weitere Versionen liefern wir gerne auf Anfrage.

Zu patchende Version Verfügbarer Patch Patch-Nummer11.2.0.3 CPU Januar 2012 1346680111.2.0.3 PSU 11.2.0.3.1 (enthält CPU Jan 2012) 1334343811.2.0.3 (Windows) Bundle Patch 1 (enthält CPU Jan 2012) 13413168 (64 bit)

13413167 (32 bit)11.2.0.2 CPU Januar 2012 1334324411.2.0.2 PSU 11.2.0.2.5 (enthält CPU Jan 2012) 1334342411.2.0.2 (Windows) Bundle Patch 15 (enthält CPU Jan 2012) 13413155 (64 bit)

13413154 (32 bit)11.2.0.1 CPU Januar 2012 nicht verfügbar11.1.0.7 CPU Januar 2012 1334345311.1.0.7 PSU 11.1.0.7.10 (enthält CPU Jan 2012) 1334346111.1.0.7 (Windows) Bundle Patch 44 (enthält CPU Jan 2012) 13460956 (64 bit)

13460955 (32 bit)11.1.0.6 CPU Januar 2012 nicht verfügbar

Tabelle 1 Verfügbare Patches für CPU Januar 2012

Seite 7/15

update

1.3 Sicherheit von Datenbank-LinksKommen wir auf die am Anfang gestellte Frage nach der Gemeinsamkeit von Release-Management und Se-curity zurück. Die Erfahrung zeigt, dass durch ein aktives Release-Management die Sicherheit der Datenban-ken signifikant erhöht wird. Umgekehrt ist das zeitnahe Einspielen von Sicherheits-Patches wesentlich einfa-cher, wenn ein aktives Release-Management praktiziert wird. Stark diskutiert wird aktuell in diesem Zusammenhang die Sicherheit von Datenbank-Links.Grundsätzlich lässt sich sagen, dass aus technologischer Sicht Datenbank-Links absolut sicher sind. Ein Link verbindet sich über einen Datenbank-Benutzer in die Zieldatenbank und muss sich dort über Benutzername und Passwort authentifizieren. Das Problem liegt eher darin, dass in großen Umgebungen mit vielen Daten-banken über Jahre hinweg Datenbank-Links großzügig angelegt wurden und im Laufe der Zeit die Übersicht verloren gegangen ist, auf welche Datenbanken über Datenbank-Link zugegriffen wird. In Zusammenhang mit der aktuellen Sicherheitsdiskussion hat das Thema einen neuen Stellenwert bekommen.

1.4 Configuration-ManagementHier kommt ein Aspekt des Configuration-Managements zum Tragen, der in der Vergangenheit gerne ver-nachlässigt wurde: Wie sollen Datenbank-Links dokumentiert werden? Während es auf der einen Seite recht einfach ist, ausgehende Datenbank-Links zu kontrollieren (man kann sie einfach entfernen oder verifizieren), ist weniger bekannt, wie eingehende Kommunikation über Links überwacht werden kann. Wenn Sie Benut-zername und Passwort einer Datenbank an Dritte weitergegeben haben, dann können Sie nicht mehr kontrol-lieren, ob die Verbindung über einen „normalen“ SQL-Client oder einen Datenbank-Link erfolgt.Mit Hilfe eines LOGON-Triggers ist es möglich, ankommende Verbindungen zu überwachen und Sessions, die über einen Datenbank-Link geöffnet werden, zu identifizieren.

SQL > SELECT program, current_scn, machine, dblink FROM aud_logon;PROGRAM CURRENT_SCN MACHINE DBLINK SQL Developer

14336616185794

Lap3

oracle@tt.dbexperts.com (J000) 14336616185804 tt.dbexperts.comoracle@tt.dbexperts.com (J000) 14336616185839 tt.dbexperts.comoracle@tt.dbexperts.com (J000) 14336616185852 tt.dbexperts.comoracle@tt.dbexperts.com (J001) 14336616185862 tt.dbexperts.com oracle@tt.dbexperts.com

(TNS V1-V3) 14336616185883 tt.dbex-perts.com SOURCE_GLOBAL_NAME= DB2.world, DBLINK_NA-ME=DB1.WORLD, SOUR-CE_AUDIT_SESSIO-NID=4294967295

Listing 1 Audit-Tabelle zum Identifizieren von eingehenden Datenbank-Links

Seite 8/15

updateDiese Informationen können verwendet werden, um eingehende Datenbank-Links zu kontrollieren. Die Quell-Datenbank kann mittels Servername (IP-Adresse) und Global Database Name identifiziert werden. Da-mit ist es möglich, das Netzwerk der Datenbank-Links zu konsolidieren.Datenbank-Links wurden in der Vergangenheit als wenig sicherheitsrelevant eingestuft, solange ein kontrol-lierter Umgang vorhanden war. Schließlich sind sie ja nichts anderes als eine ankommende Datenbank-Ver-bindung mit der Besonderheit, dass der Client eine Oracle-Datenbank ist. Die Privilegien sind über den Daten-bank-Account geregelt.Mit der aktuellen Diskussion über das Wachstum der System Change Number erscheint das Thema in einem anderen Licht. Die Angleichung der SCN über einen Datenbank-Link hat zur Folge, dass selbst ein Daten-bank-Link mit einem wenig privilegierten Account in der Lage ist, die SCN auf der anderen Seite zu erhöhen. Eine Überwachung der Links ist damit zur notwendigen Maßnahme geworden.

2 Bedeutung von IT-Security

Gerade in der Diskussion zu dem Thema Cloud- und Mobile-Computing rückt wieder der Themenbereich IT-Security in den Mittelpunkt vieler Diskussionen von IT-Verantwortlichen. Warum aber sind in vielen Unter-nehmen Security-Lösungen für Datenbanken, die wichtige und business-kritische Daten beinhalten, nur un-zureichend implementiert? Zu den zentralen Ursachen gehören sicher ein Mangel an Wissen über die genauen Anforderungen an IT-Se-curity sowie die Möglichkeiten, die mit der Implementierung verbundenen Aufwände und Kosten abschätzen zu können. Zudem scheuen viele Unternehmen die aus Security-Implementierungen eventuell resultierenden Einschränkungen in der Benutzbarkeit („Usability“) und Administrierbarkeit („Manageability“), da gerade ein Ungleichgewicht zwischen diesen Bereichen zu Akzeptanzproblemen bei den Benutzern und den Administra-toren führt. Dennoch wird kein Applikationsverantwortlicher und kein DBA die Notwendigkeit von Sicher-heitsmaßnahmen grundsätzlich verneinen.Ein weiterer Punkt ist, dass Security-Implementierungen meistens eine Anpassung von Prozessen und Ar-beitsweisen erfordern. Die Trennung von Aufgaben und Tätigkeiten in verschiedene Personengruppen („Seg-regation of Duties“) hat fast immer Änderungen an den existierenden Prozessen zur Folge. Und diese sind vielfach nur schwer im Unternehmen umzusetzen.Da gerade in Oracle Datenbanken umfangreiche und oft sensitive Datenbestände verwaltet werden, müssen hier von Anfang an auch Dinge bezüglich der Datensicherheit berücksichtigt werden. Im Folgenden werden die wichtigsten Punkte beschrieben, die bei Oracle Datenbanken zum Thema Datenbanksicherheit betrachtet werden sollten.

Seite 9/15

update

3 Sicherheitsaspekte bei Oracle Datenbanken

Wenn sensitive und personenbezogene (BDSG §3 (1)) Informationen in Datenbanken gespeichert werden, so müssen diese vor unberechtigtem Zugriff geschützt werden. Für ein durchgängiges Sicherheitskonzept zum Schutz sensitiver Daten in Oracle Datenbanken müssen einige Themen beachtet werden.

Security-relevante Themen:

• Härtung von Datenbanksystemen (Mindestsicherheit)• Trennung der Zuständigkeiten („Segregation of Duties“)• Authentifizierung, ggf. Kopplung mit bestehenden Infrastrukturen (z. B. „Single-Sign-On“)• Autorisierung (Berechtigungen, Rollen, dedizierte Privilegien)• Zugriffskontrolle (Berechtigung auf Objekte wie z. B. Tabellen)• Verschlüsselung (Netzwerk, Datensatz, Export-Dump, Backup und File)• Anonymisierung von sensitiven Informationen• Auditierung für Reporting und Dokumentation der Aktivitäten• Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten („Wie war ein ebstimmter Wert

vor einem Jahr?“)• Schutz gegen „Einschleusen“ unerwünschter Codes über die Applikation (SQL-Injection)

3.1 Härtung von DatenbanksystemenDie Härtung von Datenbanksystemen bedeutet eine Implementierung eines unternehmerischen Mindestsi-cherheitsstandards. Oracle selber empfiehlt eine entsprechende Härtung auf Basis des Kapitels 10 „Keeping Your Oracle Database Secure“ des Oracle Database Security Guides (11g Release 2, Part Number E16543-11). In den meisten Fällen kann unter Berücksichtigung der vorliegenden Systemumgebung durch Härtung der DB mit geringem Aufwand die Sicherheit des Unternehmens wesentlich gesteigert werden. Ein Security-Assess-ment kann hierbei helfen, die sinnvollen Maßnahmen zu identifizieren.

3.2 Trennung der ZuständigkeitenEin zentrales Thema bei Sicherheitskonzepten ist die Trennung der Aufgaben und Zuständigkeiten, insbeson-dere für Aufgaben, die hohe Privilegien benötigen. So sollte der DBA zwar die Datenbank, nicht aber die Da-ten administrieren können. Eine klare Trennung zwischen Bereitstellung und Administration der Infrastruktur (Datenbank) auf der einen Seite und Verarbeitung der Geschäfts- bzw. Applikationsdaten auf der anderen Seite verhindert den Missbrauch von Rechten. Kritische Änderungen sollten durch ein solches Rechtemodell nur nach dem Vier-Augen-Prinzip durchgeführt werden können.

Seite 10/15

updateDa „Segregation of Duties (SoD)“ ein wichtiger Bestandteil von Security ist, sind bereits Mechanismen in den Oracle Security Produkten wie z.B. Database Vault implementiert. So wird mit der Aktivierung von Database Vault automatisch dem DBA das Recht des „Account-Managements“ (Anlegen, Ändern und Löschen von Ac-counts) entzogen und statt dessen dieses Privileg in die Hände einer neuen Gruppe („Account-Manage-ment-Team“) gelegt. Diese Gruppe besitzt zwar das Recht des Anlegens, Änderns und Löschens von Accounts, jedoch besitzt sie keine weiteren Rechte innerhalb der Datenbank. Sie hat weder Zugriff auf DB-interne Ob-jekte, noch auf die Applikationsdaten. Die Berechtigung, das Sicherheitsregelwerk („Security-Policies“) anzu-legen oder zu ändern liegt wiederum in der Obhut einer anderen Gruppe („Security-Administratoren“). Diese dürfen als einzige das Sicherheitsregelwerk anlegen, ändern oder löschen, besitzen aber analog zum Ac-count-Management-Team keine weitere Rechte innerhalb der DB.

Folgende Aufteilung hat sich als sinnvoll erwiesen, wobei die Details in der Privilegienverteilung von den Ge-gebenheiten und Möglichkeiten der Organisation und der vorhandenen Systeme abhängig gemacht werden sollten:

• System-Administratoren (Server-Team)Verantwortlich für Bereitstellung und Betrieb der Server-Infrastruktur (Hardware und OS). In einigen Fällen können sie auch für den Betrieb des Backup-Management-Systems zuständig sein und somit neben dem DBA-Team Verantwortung für das Backup der Datenbanken tragen.

• Datenbank-Administratoren (DBA-Team)Verantwortlich für Bereitstellung und Betrieb der Datenbank-Infrastruktur wie beispielsweise Instal-lation, Patching und Tuning der DB. Das Tuning von SQL-Statements muss unter Umständen in Zu-sammenarbeit mit den Applikationsverantwortlichen durchgeführt werden. Die Sicherung der Da-tenbanken wird gegebenenfalls gemeinsam mit den Backup-Verantwortlichen durchgeführt. Das Account-Management fällt nicht mehr in das Aufgabengebiet eines DBAs.

• Account-Management-Team (User Provisioning)Verantwortlich für das Anlegen, Ändern und Löschen der Accounts innerhalb der Datenbanken. Diese Rolle sollte immer von der DBA-Tätigkeit getrennt werden. Über eine Applikation (Self-Services einer Identity Management Lösung) kann eine Einbindung des DB Account-Managements in einen Work-flow realisiert werden. In manchen Fällen wird diese Tätigkeit auch von der Applikationsbetreuung oder der Security-Administration durchgeführt.

• Security-AdministratorenVerantwortlich für die in den Systemen implementierten Sicherheits-Regelwerke. Die Sicherheitsre-geln innerhalb der Datenbanken werden zusammen mit der Applikationsbetreuung festgelegt. Die Umsetzung selbst erfolgt durch dieses Team. Es besitzt innerhalb einer Datenbank nur das Privileg, Zugriffsregeln zu setzen oder zu ändern. Alle anderen Rechte innerhalb der Datenbank fehlen. Dieses Team hat weder Zugriff auf die Systemtabellen noch auf die Applikationsdaten.

Seite 11/15

update• Applikationsbetreuung

Verantwortlich für Installation und Betrieb der Applikation selbst. Wie bei den zuvor genannten Teams sollte selbstverständlich auch bei der Applikationsbetreuung mit personalisierten Accounts gearbeitet werden. Der Zugriff auf die Applikationsobjekte sollte den Mitgliedern des Teams gemäß ihrer Aufgaben möglichst über Rollen zugeordnet werden. Das entsprechende Regelwerk wird durch dieses und das Team der Security-Administratoren festgelegt.

• Applikations-Objekt-EigentümerDieser Account wird keiner Person zugeordnet und dient ausschließlich dem Zweck, als Eigentümer der Applikationsobjekte zur Verfügung zu stehen. Er sollte keine weiteren Rechte innerhalb der Da-tenbank besitzen und zudem im Normalbetrieb gelockt sein. Nur für die Installation und die Updates sollte dieser Account kurzzeitig freigeschaltet und benutzt werden.Oft existiert keine Trennung zwischen der Applikationsbetreuung und dem Applikations-Objekt-Ei-gentümer. Die Mitglieder der Applikationsbetreuung nutzen dann gemeinsam den Applikations-Ob-jekt-Eigentümer-Account. Dieses Vorgehen stellt ein erhöhtes Sicherheitsrisiko dar.

• Applikationsuser (Proxy-User / User des Applikationsservers)Je nach Design der Applikation wird mit personalisierten oder gemeinsamen Accounts gearbeitet. Bei gemeinsam durch die Applikation genutzten Accounts sollten Mechanismen genutzt werden, um den Endanwender eindeutig identifizieren zu können. Nur so ist bei gemeinsamen DB-Accounts eine Rechtevergabe abhängig vom Endanwender möglich.

3.3 AuthentifizierungDie Authentifizierung ist der Nachweis (Verifizierung) einer behaupteten Eigenschaft einer Partei6, z.B. einer Person oder eines Systems. Bei Oracle Datenbanken weist sich der Benutzer oder die Applikation der Daten-bank gegenüber, üblicherweise mit Hilfe eines Usernamens und eines Passworts (Authentifizierung über Wis-sen), aus. Bis Oracle 10g wurde der „Passwort-Hash“ mit einem „Unsalted Hash“ verglichen. Da beim „Unsal-ted Hash“ leicht durch Rainbow-Table-Vergleiche unsichere Passwörter identifiziert werden können, wurde mit 11g ein neues, stärkeres Verschlüsselungsverfahren eingeführt, welches zudem Salt verwendet. Aller-dings wird, um abwärtskompatibel zu 10g Client-Anwendungen zu bleiben, in den meisten 11g Datenbanken der alte und neue Verschlüsselungsalgorithmus parallel betrieben. Somit ist in den meisten 11g Datenbanken die Sicherheit der Authentifizierung nicht höher als in den 10g Datenbanken, da immer der alte Authentifizie-rungsmechanismus genutzt werden kann.Alternativ oder zusätzlich können jedoch auch andere, sichere Authentifizierungsmechanismen wie z.B. To-ken (Authentifizierung über Besitz) verwendet werden. Diese erhöhen die Sicherheit, benötigen aber weitere Aufwände und Investitionen. Zusätzlich kann man bestehende Authentisierungsdienste in einer Unternehmung auch für die Datenbanken anwenden. Ein erkennbarer Trend ist die Nutzung eines zentralen Unternehmens-LDAP-System für die Au-thentifizierung.

Seite 12/15

update

3.4 AutorisierungAutorisierung ist die Zuweisung und Überprüfung von Zugriffsrechten auf Daten7. Die Autorisierung erfolgt meist nach einer erfolgreichen Authentifizierung über Gruppenzugehörigkeiten (Rollen ohne Passwort). In bestimmten Situationen ist es jedoch sinnvoll, zusätzliche Berechtigungen nur über mit Passwort geschützte Rollen zu vergeben. Insbesondere wenn es sich um Gruppen-Accounts handelt, kann die Rechtevergabe mit zusätzlichen Bedingungen durch die Applikation verknüpft werden. Dieses Verfahren führt zwar zu höherer Sicherheit, setzt aber zusätzliche Aufwände in der Applikation voraus.Diverse Produkte von Oracle unterstützen unterschiedliche Authentifizierungs- und Autorisierungsmechanis-men. Unter anderem ist die Einbindung von LDAP und AD möglich, um einen integrierten Authentifizierungs- und Autorisierungsprozess zu nutzen. So kann mit Hilfe des Oracle Identity Management Systems unter ande-rem „Single-Sign-On“ für die Anmeldung an der Datenbank genutzt werden.

3.5 ZugriffskontrolleInnerhalb der Datenbank werden Lese- oder Schreibberechtigungen zunächst über die Autorisierung durch Rollen oder durch dediziert vergebene Rechte bestimmt. Durch zusätzliche Mechanismen (Optionen bzw. Produkte) können weitere Kriterien zur Freigabe von Zugriffen verwendet werden. Damit kann selbst „Pow-er-Usern“ oder DBAs der Zugriff auf sensitive Daten verwehrt werden, ohne sie in ihrer Arbeit unverhältnis-mäßig zu behindern. Um solche Lösungen zu implementieren, bedarf es im ersten Schritt eines durchdachten Zugriffs- und Rechte-konzeptes (SoD). Oracle bietet aktuell drei Produkte mit unterschiedlichen Schwerpunk-ten bei der Zugriffskontrolle an: Label Security (LS), Database Vault (DV) sowie Virtual Private Database (VPD).Label Security (LS) bietet Möglichkeiten, unterschiedliche Zugriffsrechte auf Datensätze einer Tabelle zu de-finieren. Mit Database Vault (DV) ist die Zugriffskontrolle auf verschiedene Objekte (z.B. Tabellen) möglich, abhängig von einer breiten Palette verschiedener Faktoren (Kriterien). So ist mit diesem Produkt z.B. eine Einschrän-kung des DBAs auf Tätigkeiten der DB-Administration möglich, ohne ihm die Rechte geben zu müssen, auch auf die Daten der Anwendung selbst (lesend und schreibend) zugreifen zu dürfen. Database Vault nutzt intern Label Security und kann zusätzlich mit weiteren LS- Funktionen kombiniert werden.Mit Virtual Private Database sind unterschiedliche Sichtweisen in Abhängigkeit von den Rechten auf die glei-chen Objekte möglich. So kann das gleiche Select Statement auf dieselbe Tabelle mit VPD unterschiedliche Ergebnisse liefern. Ein typisches Einsatzfeld von VPD ist beispielsweise der Aufbau einer sicheren und wir-kungsvoll geschützten Mandantenfähigkeit einer Applikation, in der jeder Mandant nur seine eigenen Daten-sätze sieht.

Seite 13/15

update

3.6 VerschlüsselungNeben dem Schutz vor unberechtigtem Zugriff auf sensitive Daten innerhalb der Datenbank muss auch der Zugriff außerhalb des RDBMS-Systems durch direkte Lese- oder Schreibvorgänge verhindert werden. Eine Möglichkeit, das Datenbanksystem zu umgehen, ist der direkte lesende oder schreibende Zugriff auf File-Ebe-ne. Eine andere Möglichkeit ist das Mitlesen des Netzwerk-Traffics mittels eines Netzwerk-Sniffers. Auch ge-gen derartige Angriffe sollten entsprechende Schutzmechanismen implementiert werden. Durch Verschlüs-selung („Encryption“) kann verhindert werden, dass am RDBMS vorbei auf sensitive Daten zugegriffen werden kann. In folgenden Bereichen können Verschlüsselungstechniken verwendet werden:

• direkt aus der Applikation heraus• im Datensatz, Storage oder File• auf dem Netzwerk• beim Export von Records• beim Backup

Die Kombination verschiedenster Techniken - gegebenenfalls auch mit anderen Technologien wie der Kompri-mierung („Compression“) – eröffnet zahlreiche Möglichkeiten. Gerade hierzu bestehen viele Missverständnis-se und Fehleinschätzungen. Diese werden wir in einem separaten Whitepaper behandeln.In der Advanced Security Option (ASO) sind diverse Möglichkeiten der Verschlüsselung enthalten, um auf Fi-leebene bzw. auf dem Storage, dem Backup und auf der Netzwerk-Ebene entsprechende Verschlüsselungen zu nutzen.

3.7 AnonymisierungSysteme, die aus vorgelagerten Prozessen sensitive Daten erhalten, diese aber nicht unmittelbar für die Wei-terverarbeitung benötigen, können durch Anonymisierung (irreversible Veränderung der sensitiven Datensät-ze)8 von der Notwendigkeit, zusätzliche Schutzmechanismen nutzen zu müssen, entbunden werden. Oracle Data Masking (DM) bietet viele Möglichkeiten, eine Anonymisierung von Daten durchzuführen und trotzdem ein vergleichbares Verhalten wie vor der Anonymisierung zu erzielen.So lassen sich mit Data Masking bei Abnahme- oder Testumgebungen, die grundsätzlich mit den gleichen Datenbeständen wie die Produktions-Datenbanken arbeiten müssen, alle kritischen Daten unkenntlich ma-chen, ohne das Verhalten zu ändern oder die Vergleichbarkeit mit dem Produktivsystem zu verlieren. Diese Systeme benötigen keine weiteren Schutzmechanismen, da keine Daten mehr schützenswerte Informationen enthalten. Der Vorteil vergleichbarer Bedingungen (z.B. vergleichbare Ausführungspläne) geht mit der Ano-nymisierung also nicht verloren. Das Gleiche gilt für Datenbanken im Data-Warehouse-Bereich, die für be-stimmte Auswertungen zwar die originären Datenbestände der Produktion benötigen, aber nicht auf sicher-heitskritische Bestandteile, wie z.B. Kreditkartennummern für die Verarbeitung angewiesen sind. So können zum Beispiel die ursprüngliche Kreditkartennummern durch ungültige ersetzt werden, ohne aber den Infor-mationsanteil, der eine Kreditkarte z.B. als Visa- oder Amex-Karte auszeichnet, zu verändern.

Seite 14/15

updateEine Anonymisierung macht sensitive Informationen irreversibel unkenntlich, ohne jedoch durch ungeeigne-te Transformationsalgorithmen die wichtigen und notwendigen Informationsbestandteile zu beeinflussen. Die Datensätze müssen nach der Transformation weiter alle Informationsanteile besitzen, die für die Weiter-verarbeitung erforderlich sind, und darüber hinaus ein „vergleichbares Verhalten“ zeigen, wie es auch bei der Verwendung der Originaldatensätze zu beobachten wäre. Die Ausführungspläne der Statements auf die ano-nymisierten Daten sollten identisch zu denen in der Original-Datenbank sein.

3.8 AuditierungAuch bei der Implementierung einer wirkungsvollen Zugriffskontrolle als integralem Bestandteil der Daten-bank-Security sollte auf eine Auditierung der wesentlichen Aktivitäten innerhalb der DB nicht verzichtet wer-den. Zum einen schützt dies, sofern Fehler innerhalb der Regel-Implementierungen (Unwirksamkeit) began-gen wurden, zum anderen zeigt es mögliche Umgehungen von Sicherheitseinstellungen auf. Weiterhin wird Auditierung auch als Nachweis für die Einhaltung von Regeln („Policies“) und Regularien („Compliance“) be-nötigt. So hilft ein gutes Audit-System, um notwendige Sicherheits-Audits schnell und aufwandsminimierend durchzuführen. In diesem Spezialfall kann hier ein Return-on-Investment berechnet werden. Die Mehrauf-wendungen für die Durchführung eines Audits ohne Software-Unterstützung können leicht mit den Anschaf-fungs- und Lizenzkosten für ein Audit-System verglichen werden.Oracle Datenbanken bieten bereits Audit-Funktionalitäten als integralen Bestandteil des RDBMS-Systems. Mittels Audit Vault können diese Datensätze in einem zentralen Repository abgespeichert und mit flexiblen Report-Funktionalitäten ausgewertet werden. Ein solches System kann ein schnelles und erfolgreiches Durch-führen von Sicherheits-Audits gewährleisten und schafft Transparenz für eine bessere Kontrolle der DB Si-cherheit.

3.9 Rückverfolgbarkeit und Wiederherstellbarkeit historischer DatenIn manchen Fällen ist es erforderlich, genau sagen zu können, welcher Datensatz wann geändert wurde und welchen Wert ein Datum zu einem bestimmten Zeitpunkt besaß. Gerade in Bereichen mit rechtlicher Rele-vanz kann Nachvollziehbarkeit von Änderungen und Bestimmbarkeit von Werten zu bestimmten Zeitpunkten wichtig sein. Die Speicherung solcher historischen Daten kann durch die Applikation selbst erfolgen, erfordert in der Regel aber hohen Programmieraufwand. Es können aber auch entsprechende Mechanismen innerhalb der Oracle Datenbanken genutzt werden, um mit Daten unterschiedlicher Versionsstände zu arbeiten. Orac-le Datenbanken bieten die Flashback Funktionalitäten, um auf Datensätze aus der Vergangenheit zugreifen zu können. Mit Total Recall, Teil der Advanced Compression, bietet Oracle einen Mechanismus an, um selbst auf Daten zurückgreifen zu können, die weit in der Vergangenheit liegen.

3.10 Schutz gegen „Einschleusen“ unerwünschter CodesEin wichtiges Thema - gerade für Anwendungen, die auch über das Internet erreichbar sind - ist der Schutz vor SQL-Injection-Angriffen. Viele Anwendungen setzen die über die Masken eingegebenen Zeichenketten mit SQL-Befehlsteilen zu kompletten SQL-Statements zusammen (dynamisches SQL) und führen diese dann in den Datenbanken aus. Angreifer können durch geschickte Wahl der Eingabezeichen erreichen, dass andere, so von der Entwicklung nicht vorgesehene, SQL-Statements entstehen und dadurch unerwünschte Codes in den Datenbanken zur Ausführung kommen. Auch wenn durch bestimmte Techniken (wie z.B. Verwendung von Bind-Variablen) das Risiko minimiert werden kann, so sind trotzdem in einigen Fällen SQL-Injection-An-griffe möglich.

Seite 15/15

updateEine Schutzmöglichkeit gegen SQL-Injection besteht darin, zwischen Datenbank und Anwendung ein System zu setzen, welches die Statements, die an die DB geschickt werden, auf kritische Codes untersucht. Mit einem solchen System können SQL-Statements herausgefiltert werden, die als bedenklich eingestuft werden. Viele solcher Systeme arbeiten mit Suchmustern (vergleichbar mit Virenscannern). Diese Systeme können jedoch durch Änderung des SQL-Statements leicht ausgetrickst werden. Systeme, die allerdings die SQL-Statements parsen („verstehen“), können nicht so leicht überlistet werden. Die Auswirkung (z.B. ein Select auf die Tabelle emp) ist hier das Entscheidungskriterium und nicht das Statement, welches sehr unterschiedlich aufgebaut sein kann.Die Oracle Database Firewall (nicht zu verwechseln mit einer herkömmlichen Firewall) parst die Statements, die von der Anwendung an die Datenbank geschickt werden. Ein Lernmodus ermöglicht einen schnellen Auf-bau von White- oder Blacklists. So kann sehr genau unterschieden werden, welche Statements erwünscht (von der Applikation kommend) und welche unerwünscht sind.

4 Zusammenfassung

Ein wesentlicher Punkt bei der Betrachtung von IT-Security ist eine Bedarfsanalyse. In Abhängigkeit der gehal-tenen Daten und ihrer Schutzbedürftigkeit werden hier geeignete Schutzmechanismen definiert. Konzept und Implementierung müssen dabei stets auch Aufwand und Kosten berücksichtigen. Die gewählten Securi-ty-Lösungen dürfen die Benutz- und Administrierbarkeit nur in einem vertretbaren Maße beeinträchtigen. Durch Schulungen muss die Akzeptanz und das Bewusstsein bezüglich Datensicherheit bei den Mitarbeitern gefördert werden. Nur dann wird die Sicherheit im Unternehmen gesteigert und ein Security-Konzept auch erfolgreich umgesetzt und gelebt.

5 Links & Literatur• Lutz Fröhlich und Christian Wischki “ITIL & ISO/IEC 20000 für Oracle Datenbanken“, ©Hanser

Verlag, ISBN 978-3-446-41978-0• EU Data Protection Directive (offiziell Directive 95/46/EC „on the protection of individuals with

regard to the processing of personal data and on the free movement of such data“)• Bundesdatenschutzgesetz (BDSG)• PCI DSS (PCI Data Security Standard) • Basel II und Basel III und deren Relevanz für die IT-Security• Oracle Identity Management (IdM)• Begriff Authentifizierung• Begriff Autorisierung• Begriffsabgrenzung Anonymisierung zu Pseudonymisierung