Lifecycle- & Security Management für Oracle Datenbanken

Transkript

1 Lifecycle- & Security Management für Oracle Datenbanken Bedeutung für sicheres Business und Lösungsansätze zur Umsetzung Ein White Paper der avato consulting ag

2 Seite 2/15 Gegenstand Dieses Dokument beschreibt die Anforderungen an die Security bei Oracle-Datenbanken, sowie pragmatische Umsetzungen und zeigt Strategien im Oracle Lifecycle Management auf Control Table Contact Person: Classification Ronny Egner Lutz Fröhlich White Paper Lifecycle- & Security Management für Oracle Datenbanken Functional Applicability: Last Revision Date: Version: 1.1 Change History Version Date Revision Description Revision Details, Authors Lifecycle Management Lutz Fröhlich Zusammenführen der Whitepaper zu Lifecycle Management und Security Ronny Egner, Lutz Fröhlich, Ralph Baumbach

3 Seite 3/15 Inhalt 1 Lifecycle-Management Release-Policy und Release-Planung für Oracle-Datenbanken Database Instance Sicherheit von Datenbank-Links Configuration-Management Bedeutung von IT-Security Sicherheitsaspekte bei Oracle-Datenbanken Härtung von Datenbanksystemen Trennung der Zuständigkeiten Authentifizierung Autorisierung Zugriffskontrolle Verschlüsselung Anonymisierung Auditierung Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten Schutz gegen Einschleusen unerwünschter Codes Zusammenfassung Links & Literatur

4 Seite 4/15 1 Lifecycle- & Security Auf den ersten Blick haben beide Themen nicht viel miteinander zu tun. Betrachten wir zunächst das Lifecycle-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 unumgä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 Voraussetzungen 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 aktuellen Umfeld: Die Version ist vom Hersteller nicht mehr supported. Zwei kritische Sicherheitspatches stehen nicht zur Verfügung.

5 Seite 5/ 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 ). 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 Vendors der Applikation voraussetzt. In den letzten Jahren hat Oracle genau zwei Maintenance Releases herausgebracht. 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 Sicherheitslü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

6 Seite 6/ Release-Planung am Beispiel Nehmen 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 Datenbank-Versionen. Wertvolle Unterstützung liefert hier der Oracle Enterprise Manager, der eine Gesamtübersicht zur Verfügung stellt. Database Installations Targets Installations Interim Patches Applied Oracle Database 10g Yes Oracle Database 10g Yes Oracle Database 10g Yes Oracle Database 11g Yes Oracle9i 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-Nummer CPU Januar PSU (enthält CPU Jan 2012) (Windows) Bundle Patch 1 (enthält CPU Jan 2012) (64 bit) (32 bit) CPU Januar PSU (enthält CPU Jan 2012) (Windows) Bundle Patch 15 (enthält CPU Jan 2012) (64 bit) (32 bit) CPU Januar 2012 nicht verfügbar CPU Januar PSU (enthält CPU Jan 2012) (Windows) Bundle Patch 44 (enthält CPU Jan 2012) (64 bit) (32 bit) CPU Januar 2012 nicht verfügbar Tabelle 1 Verfügbare Patches für CPU Januar 2012

7 Seite 7/ Sicherheit von Datenbank-Links Kommen wir auf die am Anfang gestellte Frage nach der Gemeinsamkeit von Release-Management und Security zurück. Die Erfahrung zeigt, dass durch ein aktives Release-Management die Sicherheit der Datenbanken signifikant erhöht wird. Umgekehrt ist das zeitnahe Einspielen von Sicherheits-Patches wesentlich einfacher, 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 Datenbanken ü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-Management Hier kommt ein Aspekt des Configuration-Managements zum Tragen, der in der Vergangenheit gerne vernachlä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 Benutzername und Passwort einer Datenbank an Dritte weitergegeben haben, dann können Sie nicht mehr kontrollieren, 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 Lap3 (J000) tt.dbexperts.com (J000) tt.dbexperts.com (J000) tt.dbexperts.com (J001) tt.dbexperts.com (TNS V1-V3) tt.dbexperts.com SOURCE_GLOBAL_NAME= DB2.world, DBLINK_NA- ME=DB1.WORLD, SOUR- CE_AUDIT_SESSIO- NID= Listing 1 Audit-Tabelle zum Identifizieren von eingehenden Datenbank-Links

8 Seite 8/15 Diese 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. Damit ist es möglich, das Netzwerk der Datenbank-Links zu konsolidieren. Datenbank-Links wurden in der Vergangenheit als wenig sicherheitsrelevant eingestuft, solange ein kontrollierter Umgang vorhanden war. Schließlich sind sie ja nichts anderes als eine ankommende Datenbank-Verbindung mit der Besonderheit, dass der Client eine Oracle-Datenbank ist. Die Privilegien sind über den Datenbank-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 Datenbank-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 Unternehmen Security-Lösungen für Datenbanken, die wichtige und business-kritische Daten beinhalten, nur unzureichend implementiert? Zu den zentralen Ursachen gehören sicher ein Mangel an Wissen über die genauen Anforderungen an IT-Security 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 Administratoren führt. Dennoch wird kein Applikationsverantwortlicher und kein DBA die Notwendigkeit von Sicherheitsmaßnahmen grundsätzlich verneinen. Ein weiterer Punkt ist, dass Security-Implementierungen meistens eine Anpassung von Prozessen und Arbeitsweisen erfordern. Die Trennung von Aufgaben und Tätigkeiten in verschiedene Personengruppen ( Segregation 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.

9 Seite 9/15 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 Datenbanksystemen Die Härtung von Datenbanksystemen bedeutet eine Implementierung eines unternehmerischen Mindestsicherheitsstandards. 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 E ). 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-Assessment kann hierbei helfen, die sinnvollen Maßnahmen zu identifizieren. 3.2 Trennung der Zuständigkeiten Ein zentrales Thema bei Sicherheitskonzepten ist die Trennung der Aufgaben und Zuständigkeiten, insbesondere für Aufgaben, die hohe Privilegien benötigen. So sollte der DBA zwar die Datenbank, nicht aber die Daten 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.

10 Seite 10/15 Da 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 Accounts) entzogen und statt dessen dieses Privileg in die Hände einer neuen Gruppe ( Account-Management-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 Objekte, noch auf die Applikationsdaten. Die Berechtigung, das Sicherheitsregelwerk ( Security-Policies ) anzulegen 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 Account-Management-Team keine weitere Rechte innerhalb der DB. Folgende Aufteilung hat sich als sinnvoll erwiesen, wobei die Details in der Privilegienverteilung von den Gegebenheiten 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 Installation, Patching und Tuning der DB. Das Tuning von SQL-Statements muss unter Umständen in Zusammenarbeit mit den Applikationsverantwortlichen durchgeführt werden. Die Sicherung der Datenbanken 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 Workflow realisiert werden. In manchen Fällen wird diese Tätigkeit auch von der Applikationsbetreuung oder der Security-Administration durchgeführt. Security-Administratoren Verantwortlich für die in den Systemen implementierten Sicherheits-Regelwerke. Die Sicherheitsregeln 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.

11 Seite 11/15 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ümer Dieser 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 Datenbank 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-Eigentümer. Die Mitglieder der Applikationsbetreuung nutzen dann gemeinsam den Applikations-Objekt-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 Authentifizierung Die 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 Datenbank gegenüber, üblicherweise mit Hilfe eines Usernamens und eines Passworts (Authentifizierung über Wissen), aus. Bis Oracle 10g wurde der Passwort-Hash mit einem Unsalted Hash verglichen. Da beim Unsalted 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. Allerdings 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 Authentifizierungsmechanismus genutzt werden kann. Alternativ oder zusätzlich können jedoch auch andere, sichere Authentifizierungsmechanismen wie z.b. Token (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 Authentifizierung.

12 Seite 12/ Autorisierung Autorisierung 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 Autorisierungsmechanismen. 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 anderem Single-Sign-On für die Anmeldung an der Datenbank genutzt werden. 3.5 Zugriffskontrolle Innerhalb 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 Power-Usern oder DBAs der Zugriff auf sensitive Daten verwehrt werden, ohne sie in ihrer Arbeit unverhältnismäß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 Schwerpunkten 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 definieren. 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änkung 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 gleichen 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 wirkungsvoll geschützten Mandantenfähigkeit einer Applikation, in der jeder Mandant nur seine eigenen Datensätze sieht.

13 Seite 13/ Verschlüsselung Neben 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-Ebene. Eine andere Möglichkeit ist das Mitlesen des Netzwerk-Traffics mittels eines Netzwerk-Sniffers. Auch gegen derartige Angriffe sollten entsprechende Schutzmechanismen implementiert werden. Durch Verschlüsselung ( 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 Komprimierung ( Compression ) eröffnet zahlreiche Möglichkeiten. Gerade hierzu bestehen viele Missverständnisse 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 Fileebene bzw. auf dem Storage, dem Backup und auf der Netzwerk-Ebene entsprechende Verschlüsselungen zu nutzen. 3.7 Anonymisierung Systeme, die aus vorgelagerten Prozessen sensitive Daten erhalten, diese aber nicht unmittelbar für die Weiterverarbeitung benötigen, können durch Anonymisierung (irreversible Veränderung der sensitiven Datensätze)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 machen, 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 Anonymisierung also nicht verloren. Das Gleiche gilt für Datenbanken im Data-Warehouse-Bereich, die für bestimmte Auswertungen zwar die originären Datenbestände der Produktion benötigen, aber nicht auf sicherheitskritische 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 Informationsanteil, der eine Kreditkarte z.b. als Visa- oder Amex-Karte auszeichnet, zu verändern.

14 Seite 14/15 Eine Anonymisierung macht sensitive Informationen irreversibel unkenntlich, ohne jedoch durch ungeeignete Transformationsalgorithmen die wichtigen und notwendigen Informationsbestandteile zu beeinflussen. Die Datensätze müssen nach der Transformation weiter alle Informationsanteile besitzen, die für die Weiterverarbeitung 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 anonymisierten Daten sollten identisch zu denen in der Original-Datenbank sein. 3.8 Auditierung Auch bei der Implementierung einer wirkungsvollen Zugriffskontrolle als integralem Bestandteil der Datenbank-Security sollte auf eine Auditierung der wesentlichen Aktivitäten innerhalb der DB nicht verzichtet werden. Zum einen schützt dies, sofern Fehler innerhalb der Regel-Implementierungen (Unwirksamkeit) begangen 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 ) benö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 Mehraufwendungen für die Durchführung eines Audits ohne Software-Unterstützung können leicht mit den Anschaffungs- 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 Durchführen von Sicherheits-Audits gewährleisten und schafft Transparenz für eine bessere Kontrolle der DB Sicherheit. 3.9 Rückverfolgbarkeit und Wiederherstellbarkeit historischer Daten In 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 Relevanz 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. Oracle 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 Schutz gegen Einschleusen unerwünschter Codes Ein 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-Angriffe möglich.

15 Seite 15/15 Eine 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 Aufbau 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 gehaltenen 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 Security-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 für Oracle Datenbanken, Hanser Verlag, ISBN 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