1
Basel · Baden Brugg · Bern · Lausanne · Zürich · Düsseldorf Frankfurt/M. · Freiburg i. Br. · Hamburg · München Stuttgart · Wien
Compliance im Oracle Umfeld - Wie schützte ich die Daten vor dem DBA
Sven Vetter Trivadis AG
Technology Manager SEC Principal Consultat, Parter
Bonn, 22.09.2009
© 2009 DOAG SIG - Compliance im Oracle Umfeld 2
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
2
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Database Security ist mehr als die Datenbank
Um eine sichere Datenbank zu haben, braucht es mehr als ein Benutzer und Rollenkonzept
Datendiebstahl und Datenmanipulation kann auf vielen Ebenen geschehen (z.B. Netzwerk, Datenfiles, Backups, Exports, …)
Deswegen müssen all diese Ebenen konsistent geschützt werden
Oracle bietet dazu diverse Optionen, wichtig ist, die richtige Kombination daraus für die eigenen Bedürfnisse zu ermitteln und einzusetzen
Aber auch Fremdhersteller bieten Tools für den Zugriffsschutz und die Überwachung an
3
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Zugriffsschutz (1)
Der "normale" Zugriff auf die Daten über die Instanz ist geschützt durch Database Authentication und Authorizing
Die kann überwacht werden durch Auditing innerhalb der Datenbank (Standard-, triggerbasierendes und Fine Grained Auditing)
"Standardschutz" durch AAA
Datenbank Files
Datenbank Instanz
End User, Developer,
DBA
4
3
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Zugriffsschutz (2)
Die Autorisation kann auch auf Zeilenebene definiert werden
Z.B. um Mandantenfähigkeit zu erreichen
Jeder Benutzer kann das gleiche Statement ausführen, sieht aber nur die Daten, für die er berechtigt ist
Virtual Private
Database
Label Security
5
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Database Vault
Zugriffsschutz (3)
Es können weitere Kriterien (z.B. Zeit, Protokoll, IP-Adresse, Programm, 4-Augen-Prinzip, …) hinzugezogen werden, um den Zugriff zu gestatten / zu verbieten
Um Schutz vor hochpriviligierten Benutzern (DBAs) zu gewährleisten, braucht es aber eine spezielle Option
Database Vault
Virtual Private
Database
Secure Application
Roles
6
4
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Zugriffsschutz (4)
Database Files
Instance Hacker
AAA oder Database Vault schützen die Daten nicht vor direkten Zugriffen auf
die Datenfiles oder die Backups
Transparent Data
Encryption
Backups
RMAN Backup
Encryption
7
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Zugriffsschutz (5)
End User, Developer, DBA
Database Server
Oracle Net
Hacker
Advanced Security
Die Daten werden über das Netzwerk standardmässig unverschlüsselt übertragen
8
5
© 2009
Zugriffsschutz (6)
Eventuell reicht das Auditing in der Datenbank oder auf dem Server nicht aus
DOAG SIG - Compliance im Oracle Umfeld
Oracle Audit Vault
9
© 2009
Weitere Möglichkeiten
Neben diesen Oracle Tools bzw. Features gibt es noch eine Reihe weiterer Möglichkeiten, z.B.
Verschlüsselung durch die Applikation eventuell mit Unterstützung durch Hardware Security Module (HSM)
Verschlüsselung vor der Datenbank durch Hardware Lösungen (z.B. SafeNet Database Encryption)
Zugriffsschutz, Auding, Virtuelles Patching durch Sentrigo Hedgehog
Zentrales Auditing, nicht nur für Datenbanken (z.B. RSA enVision)
DOAG SIG - Compliance im Oracle Umfeld 10
6
© 2009
Nicht vergessen
Bis jetzt haben wir nur über die Oracle Datenbank und deren direkte Umgebung gesprochen
Genauso wichtig sind aber Punkte wie: Sicherheit der Applikation "Secure Programming" durch "Security by Design" Hardening des Servers Personifizierte Accounts Anonymisierung beim Erzeugen von Testdatenbanken (z.B. Oracle
Data Masking) …
DOAG SIG - Compliance im Oracle Umfeld 11
© 2009 DOAG SIG - Compliance im Oracle Umfeld 12
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
7
© 2009 DOAG SIG - Compliance im Oracle Umfeld 13
Motivation (1)
Datenbank Files
Instanz
Zugriff auf die Instanz ist geschützt durch Datenbank Authentifizierung, Autorisierung und Auditing (AAA)
Endbenutzer, Entwickler, DBA
Hacker
Und Exports?
RMAN
Und was ist mit Backups?
© 2009 DOAG SIG - Compliance im Oracle Umfeld 14
Motivation (2)
Verschlüsselung in Datenfiles, Backups und Exports erhöht die Sicherheit: Wenn die Backups gestohlen werden Wenn jemand direkten Zugriff auf die Datenfiles hat
(z.B. auf SAN/NAS ohne Zugriff auf dem Server) Wenn Datenfiles über das Netzwerk geschickt werden
Hilft nicht: Wenn sowohl Datenfiles als auch Wallet (mit Auto Login)
gestohlen werden
Empfehlung: Speichern Sie Ihre Datenfiles an anderen Location als Ihre Wallets
8
© 2009 DOAG SIG - Compliance im Oracle Umfeld 15
Verschlüsselung in Datenfiles
Transparent Data Encryption (TDE) ermöglicht die Ver- und Entschlüsselung von sensiblen Daten so dass sie auch nach dem Zurückschreiben auf die Datenfiles vor unberechtigten Zugriffen geschützt sind
Basis sind Encryption Keys, die in- und ausserhalb der Datenbank gespeichert werden Jede Tabelle hat ihren eigenen Encryption Key Die Keys werden mit einem Master Key verschlüsselt und im Data
Dictionary abgespeichert (SYS.ENC$) Der Master Key wird in einem Wallet gespeichert
Information über verschlüsselte Spalten liefern die DD-Views all|dba|user_encrypted_columns
© 2009 DOAG SIG - Compliance im Oracle Umfeld 16
Transparent Data Encryption – ENCRYPT Klausel
Die Verschlüsselung kann für jede Spalte einzeln definiert werden
Unterstützte Verschlüsselungsalgorithmen AES128 AES192 (Default) AES256 3DES168
Release 2
9
© 2009 DOAG SIG - Compliance im Oracle Umfeld 17
Es können nur einzelne Spalten verschlüsselt werden – und nicht alle Datentypen (Long, LOB)
Während Operationen waren die Daten nicht verschlüsselt, so dass eventuell unverschlüsselte und vertrauliche Daten im TEMP-Tablespace oder im REDO sichtbar waren
Ausschliesslich B*Tree Indizes werden unterstützt (keine FBI) – und Index Range Scans werden nur bei Abfragen auf Gleichheit unterstützt
Fremdschlüssel können nicht auf verschlüsselten Spalten definiert werden
Alle diese Einschränkungen wurden mit Oracle Database 11g und Tablespace Encryption aufgehoben
Transparent Data Encryption - Einschränkungen
© 2009 DOAG SIG - Compliance im Oracle Umfeld 18
Es können nun Tablespaces komplett verschlüsselt werden
Ist nur beim Anlegen des Tablespaces einschaltbar
Alle Daten im Tablespace (einschliesslich Lobs, Indexes, ...) sind verschlüsselt – ausser BFILES
Daten bleiben verschlüsselt bei Dateioperationen wie Joins und Sorts, damit sind sie auch verschlüsselt in UNDO, REDO und TEMP
Aber – im Gegensatz zu TDE – nicht in den Memory-Bereichen !!
Tablespace Encryption
10
© 2009 DOAG SIG - Compliance im Oracle Umfeld 19
Identisch wie bei TDE wird mit folgendem Befehl ein Master-Key in einem Wallet erstellt:
Existiert noch kein Wallet, wird ein neues erzeugt, wenn der Pfad $ORACLE_BASE/admin/$ORACLE_SID/wallet existiert
Im Wallet muss Autologin eingeschaltet sein – oder es muss nach dem Mounten (oder Öffnen) der Datenbank geöffnet werden:
Vorgehen
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY {password}
ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY {password}
© 2009 DOAG SIG - Compliance im Oracle Umfeld 20
Nun können verschlüsselte Tablespaces erzeugt werden
Beispiel:
Als Verschüsselungsalgorithmen können 3DES168, AES128, AES192 oder AES256 gewählt werden
Tablespace erzeugen
CREATE TABLESPACE enc_test DATAFILE SIZE 50M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT)
11
© 2009 DOAG SIG - Compliance im Oracle Umfeld 21
Daten müssen beim Schreiben verschlüsselt, beim Lesen entschlüsselt werden – dies benötigt Ressourcen...
Folgender Performance-Impact wurde gemessen (Tabelle mit 150'000 Zeilen, Tablespace verschlüsselt mit AES256):
CPU-Verbrauch ist höher
Grösse der Datenfiles ändert sich bei Verschlüsselung nicht
Auswirkungen – Performance
Operation Impact Massen-Insert (zeilenweise) 10% Massen-Deletes/Updates 10% Massen-Insert (IDL) 1% Full-Table Scan 1% Index-Scan <1%
© 2009 DOAG SIG - Compliance im Oracle Umfeld 22
EXP exportiert keine Daten aus verschlüsselten Tablespaces:
EXPDP exportiert die Daten unverschlüsselt in das Dump-File
RMAN lässt den Tablespace verschlüsselt Das bedeutet, beim Restore muss das Wallet vorhanden sein!
Auswirkungen – Tools
exp enc_test/manager file=test.dmp tables=test_enc ... EXP-00111: Table TEST_ENC resides in an Encrypted Tablespace ENC_TEST and will not be exported ...
12
© 2009
Alternative 1: Verschlüsslung in der Applikation
Vorteile: Datenbank- und Betriebssystemadministratoren sehen die Daten nie
unverschlüsselt Keine Änderung im Arbeitsablauf der Administratoren Nach erstem initialen Aufwand leicht in andere Applikationen zu
implementieren
Nachteile: Geht nur für eigene Applikationen Felder können zwar indexiert werden, aber Index kann nur für Equal-
Scans benutzt werden Key Management muss gelöst werden
23 DOAG SIG - Compliance im Oracle Umfeld
© 2009
Alternative 2: Verschlüsslung vor der Datenbank
Hardware-Appliance, welche definierte Felder verschlüsselt
Beispiel: SafeNet DataSecure (http://www.safenet-inc.com/products/database_encryption/index.asp)
Data- base Encryption
Appliance
24 DOAG SIG - Compliance im Oracle Umfeld
13
© 2009
Alternative 2: Verschlüsslung vor der Datenbank
Vorteile: Datenbank- und Betriebssystemadministratoren sehen die Daten nie
unverschlüsselt Keine Änderung im Arbeitsablauf der Administratoren Keymanagement gelöst (innerhalb Appliance) Verfügbar auch für andere DBs (SQL Server, DB/2) und andere
System (Application Server, OS, ...) Geht auch für gekaufte Applikationen
Nachteile: Felder können zwar indexiert werden, aber Index kann nur für Equal-
Scans benutzt werden Datenmodell oder Applikation muss geändert werden
25 DOAG SIG - Compliance im Oracle Umfeld
© 2009 DOAG SIG - Compliance im Oracle Umfeld 26
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
14
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Lösung ?
Oracle Database Vault provides a solution to help customers address the most difficult security problems remaining today – Source: Oracle Database Vault Data Sheet
Reicht aber Oracle Database Vault aus, um eine Oracle Umgebung komplett abzusichern?
27
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Massnahmen
Mit Database Vault führt Oracle 3 grundsätzlich neue Funktionen ein, um die Daten zu schützen:
Schutz vor "Spezialbenutzer" (SYSDBA)
Neue Rollen für Benutzer- und Berechtigungsmanagement
Neue Art des Zugriffsschutzes auf Objekte
28
15
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Neue Rollen (1)
DV_OWNER (Database Vault Owner Role) Owner des Dictionaries von Database Vault Subrollen: DV_ADMIN, DV_SECANALYST
DV_ADMIN (Database Vault Configuration Administrator) Definiert zu schützenden Objekte und gestattet den Zugriff darauf Subrollen: DV_SECANALYST
DV_SECANALYST (Database Vault Security Analyst) Kann das Data Dictionary von Database Vault abfragen Kann Konfiguration überprüfen Kann Auditing und Monitoring von Database Vault durchführen per
GUI durchführen
29
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Neue Rollen (2)
DV_ACCTMGR (Database Vault Account Manager) Kann Benutzer erstellen, bearbeiten und löschen Kann Profiles erstellen, bearbeiten und löschen Kann nicht das Schema DVSYS bearbeiten
30
16
© 2009
Separation of Duties
Task Verantwortlich Betrieb der DB und der Instanz (Erzeugen, Parametriseren, Instanztuning, Patching, Updates, Tablespace-Management, …)
Security Management Anlegen von Realms, Definition der zu schützenden Objekte
Zuteilen der Benutzer zu Realms Anlegen von applikatorischen Rollen Zuordnen von Objektprivilegien zu Rollen/Benutzern Account Management + Zuweisen von Rollen
Anlegen von technischen Rollen, Initiales zuordnen von Systemprivilegien zu Rollen (nicht applikatorische Rollen!)
31 DOAG SIG - Compliance im Oracle Umfeld
© 2009 DOAG SIG - Compliance im Oracle Umfeld
Architektur
Database Vault fügt zusätzlichen Layer in den Oracle Kernel
Kommt nur bei System-Privilegien zum Zuge SELECT ANY TABLE INSERT ANY TABLE ALTER ANY TABLE ALTER USER ...
Kein Impact bei Objekt-Grants (ausser durch Command Rules)
Die Ausführung jedes SQL Statements kann eingeschränkt werden
SELECT, DML, DDL, DCL
32
17
© 2009
Nicht durch DBV abgedeckt
Risiko Massnahme Daten in Datafiles im Klartext (OS- und SAN-Admin sowie Oracle-Unix-Account kann Daten lesen)
Verschlüsselung der Datafiles durch TDE (10g auf Spaltenebene, 11g auf Tablespace-Ebene)
Daten in Backups und Exports im Klartext Verschlüsslung durch RMAN bzw. Datapump
SYS-Account muss offen sein für RAC und RMAN Dieser ist nicht komplett durch DBV abgesichert
Personifizierte Accounts auf Unix und Datenbank + Sudo-Konzept Benutzung von SYSOPER Zulassen von SYSDBA-Connections nur zur RMAN-Connect-Zeit
33 DOAG SIG - Compliance im Oracle Umfeld
© 2009
Nicht durch DBV abgedeckt
Risiko Massnahme Während Patching (z.B. CPUs) sowie Migrationen muss DBV ausgeschaltet werden
Personifizierte Accounts auf Unix und Sudo-Konzept Überwachung auf Betriebssystemebene (inode+ctime Checks, z.B. manuell, Nimbus,iwatch (Linux, basierend auf inotify))
Daten im Klartext über Netzwerk bzw. Interconnect bei RAC)
Einsatz von ASO zur Verschlüsslung des Netzwerkes
Direkte Object Grants Bestehende Grants müssen bekannt sein bzw. kontrolliert werden
Applikatorische Exportmöglichkeiten Können nur auf Applikations-Ebene überprüft werden, eventuell Einschränkungen über Rules (anhand IP, …)
34 DOAG SIG - Compliance im Oracle Umfeld
18
© 2009 DOAG SIG - Compliance im Oracle Umfeld 35
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
© 2009 DOAG SIG - Compliance im Oracle Umfeld 36
In einer zentraler Oracle Datenbank werden Auditeinträge verschiedener Quellen gesammelt
Aus einem Warehouse sind die Daten abfragbar (z.B. durch BO)
Für Auswertungen stehen über eine Weboberfläche (ähnlich Oracle Enterprise Manager) komfortable Reports zur Verfügung
Alarme können definiert werden, um bei aussergewöhnlichen Ereignissen schnell informiert zu werden
Übersicht
19
© 2009 DOAG SIG - Compliance im Oracle Umfeld 37
Folgende Komponenten werden benötigt:
Komponenten
zu überwachende
Datenbank zu
überwachende Datenbank
Audit Vault Agent
Source DBAUD Collector
OSAUD Collector
REDO Collector
Audit Vault Server
Dat
a C
olle
ctio
n Warehouse Reports Alerts Management Security
Reporting Alerts Management
MSSQL Collector
Sybase Collector
DB/2
© 2009 DOAG SIG - Compliance im Oracle Umfeld 38
Standardmässig werden keine Auditereignisse von Audit Vault gesammelt
Diese müssen pro Datenbank zuerst definiert werden
Um die Arbeit etwas zu erleichtern, können die Auditdefinitionen einer Datenbank auf eine andere kopiert werden
Im Managementinterface werden diese Informationen komfortabel verwaltet
Auditdefinition (1)
20
© 2009 DOAG SIG - Compliance im Oracle Umfeld 39
Zuerst müssen die aktuellen Definitionen empfangen werden:
Auditdefinition (2)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 40
Danach werden die zu überwachenden Ereignisse innerhalb Audit Vault definiert:
Auditdefinition (3)
21
© 2009 DOAG SIG - Compliance im Oracle Umfeld 41
Diese sind dann noch nicht "in use"
Und müssen erst appliziert (exportiert oder provisioniert) werden
Auditdefinition (4)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 42
Audit Vault und Datenbank sind synchronisiert:
Auditdefinition (5)
22
© 2009 DOAG SIG - Compliance im Oracle Umfeld 43
Auf der Homepage von Audit Vault steht eine Übersicht zur Verfügung:
Von hier oder über die Report-Page kann beliebig in die Tiefe verzweigt werden
Auswertungen (1)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 44
Ausserdem existieren diverse vordefinierte Reports
Auswertungen (2)
23
© 2009 DOAG SIG - Compliance im Oracle Umfeld 45
Diese können dann nach diversen Kriterien eingeschränkt werden:
Auswertungen (3)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 46
Die Ergebnisse werden tabellarisch dargestellt – mit der Möglichkeit, ins Detail zu verzweigen
Auswertungen (4)
24
© 2009 DOAG SIG - Compliance im Oracle Umfeld 47
Auswertungen (5) Details
© 2009 DOAG SIG - Compliance im Oracle Umfeld 48
Bessere Anzeigemöglichkeiten durch Highlighting
Auswertungen (6)
25
© 2009 DOAG SIG - Compliance im Oracle Umfeld 49
Bessere Anzeigemöglichkeiten durch Charts
Auswertungen (7)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 50
Jedes Audit-Event kann auch als Alarm oder Warning definiert werden, diese werden dann auf der Homepage dargestellt:
Alarme
26
© 2009 DOAG SIG - Compliance im Oracle Umfeld 51
Die sicherlich grösste Neuerung seit Patchset 10.2.3.0 ist die Möglichkeit des zentralen Auditings auch für Microsoft SQL Server Datenbanken (aber nur für Versionen 2000 und 2005)
Folgende Log-Typen können gesammelt werden: C2 audit logs Server-side trace logs Windows Event log
MS SQL Connector (1)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 52
Übersicht der Ereignisse einer SQL-Server 2005 Datenbank
MS SQL Connector (2)
27
© 2009 DOAG SIG - Compliance im Oracle Umfeld 53
Detailanzeige
MS SQL Connector (3)
© 2009 DOAG SIG - Compliance im Oracle Umfeld 54
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
28
© 2009 DOAG SIG - Compliance im Oracle Umfeld 55
Tool für Überwachung von Datenbanken
Kann aber mehr als zentrales Auditing: Killen von Session (damit indirekt auch Autorisierung) Quarantäne von Benutzern Virtuales Patching Überwachung von Compliance (vorkonfigurierte Regeln für SOX, PCI)
Leicht zu installieren und zu konfigurieren
Sentrigo Hedgehog
Monitoring All Activity in the Database
DB
DB
CRM
HR
ERP
Corp
orat
e Fi
rew
all
Au
th
en
ti
ca
ti
on
&
A
cc
es
s
Co
nt
ro
l
Stored Proc.
Trigger
View Data
Shared Memory
DBMS
List
ener
Be
quea
th
Local Connection
Network Connection
All database transactions (externally- or internally-initiated) go via the shared memory
Commercially Classified 56 Q
uelle
: Se
ntri
go
29
Technocircle Compliance: Weitere Tools und Möglichkeiten 57
und Detail-Informationen…
Sentrigo Hedgehog – Dashboard
© 2009 DOAG SIG - Compliance im Oracle Umfeld 58
Viele Firmen spielen die quartalsweise erscheinenden CPUs nicht ein…
Sentrigo bietet hier mit dem "Virtual Patching" eine Alternative
Die Sicherheitslücken von Oracle Datenbanken sind im Allgemeinen bekannt, ebenfalls, wie sie ausgenutzt werden können
Hedgehog fängt nun die Befehle ab (Benachrichtigung, Session killen), die so eine Lücke ausnutzen würden
Update der Regeln erfolgt online auf dem Server kein Downtime notwendig
Sentrigo Hedgehog und virtuelles Patching
30
© 2009 Technocircle Compliance: Weitere Tools und Möglichkeiten 59
Neues Oracleprodukt – oder besser existierendes Produkt (Oracle Identity Manager) + zusätzliche Module
Konzept: Mitarbeiterinformationen sowie Rollen/Gruppen werden aus
führendes System (z.B. HR-Applikation, Active Directory) gelesen und in CUA4DB gespeichert
Anhand der Rollen/Gruppen wird über Regeln entschieden, in welcher Datenbank der Benutzer mit welchem Namen angelegt wird
Es sind also echte Datenbankbenutzer Für alle Datenbanken hat ein Mitarbeiter immer das gleiche Passwort Passwort-Management ("Self-Service") erfolgt zentral über eine
Weboberfläche Dabei werden Passwort-Policies durchgesetzt Keine Änderung in der Datenbank!
Centralized User Administration for Database
© 2009 Technocircle Compliance: Weitere Tools und Möglichkeiten 60
Q
uelle
: Ora
cle
Vergleich CUA4DB und Enterprise User
31
© 2009
SYS und SYSTEM
Der Zugriff von SYS und SYSTEM ist wie folgt geregelt: Im Normalfall weiss niemand das Passwort dieser Benutzer Wird dies für eine Wartungsarbeit benötigt, wird der Zugriff beantragt
(Genehmigungsprozess) Für die beantragte Dauer wird dann das Passwort auf das des
beantragendes Benutzers gesetzt – und dieser kann seine Arbeiten durchführen
Dies wird protokolliert, so dass immer klar ist, wer zu welcher Zeit an welcher Datenbank SYS oder SYSTEM war
Achtung: Dies funktioniert nur, wenn auch auf Betriebsystem-Seite personifizierte Accounts benutzt werden
Technocircle Compliance: Weitere Tools und Möglichkeiten 61
© 2009 DOAG SIG - Compliance im Oracle Umfeld 62
Agenda
Daten sind immer im Spiel. Aber sie müssen auch geschützt werden!
Überblick
Verschlüsslung
Database Vault
Audit Vault
Weitere Tools
Empfehlungen
32
© 2009 DOAG SIG - Compliance im Oracle Umfeld 63
Zuverlässiger Schutz möglich, aber nicht allein durch Database Vault (siehe Matrix im entsprechenden Kapitel)
4-Augen-Prinzip möglich (durch eigene Programmierung)
Eventuell Änderungen in der Applikation notwendig (wenn diese selbständig Benutzer und Rechte verwaltet)
Rollentrennung unbedingt notwendig (DBA, Account-Management, Security Management, Datenowner)
Muss für einige Tasks (z.B. Patchen ausgeschaltet werden)
Schutz der Daten vor dem DBA – Empfehlungen Oracle Database Vault
© 2009 DOAG SIG - Compliance im Oracle Umfeld 64
Sicherer Schutz
Geht nur für eigene Applikationen
Greifen mehrere Applikationen auf gleiche Daten zu, müssen diese gleich verschlüsselt werden
Performanceeinbussen möglich (Index-Range-Scan)
Keymanagement muss gelöst werden
Schutz der Daten vor dem DBA – Empfehlungen Verschlüsslung der Daten in der Applikation
33
© 2009 DOAG SIG - Compliance im Oracle Umfeld 65
Schutz nicht 100% sicher
Dafür werden Zugriffe aber 100%ig protokolliert
Keine Änderung in Applikationen notwendig
Muss für Patching nicht ausgeschaltet werden
Am Leichtesten zu installieren und zu konfigurieren
Zusatz: Zentrales Auditing + vPatch
Schutz der Daten vor dem DBA – Empfehlungen Sentrigo Hedgehog
© 2009 Technocircle Compliance: Fazit 66
Schützt allein nicht vor dem DBA
Sinnvoll in Kombination mit Database Vault
Kann als IAM-Lösung aber viel mehr…
Schutz der Daten vor dem DBA – Empfehlungen CUA4DB
34
© 2009 DOAG SIG - Compliance im Oracle Umfeld 67
Auditdatendiebstahl nahezu unmöglich
Vom Oracle Account nicht zu beeinflussen
Sehr gutes Benachrichtigungskonzept
Online-Aktualisierung (wenn gewünscht)
Geringer Performance-Overhead
Am Leichtesten zu installieren und zu konfigurieren
Zusatz: eingeschränkter Schutz vor DBA + vPatch
Zentrales Auditing – Empfehlungen Sentrigo Hedgehog
© 2009 DOAG SIG - Compliance im Oracle Umfeld 68
Auditdatendiebstahl nahezu unmöglich
Am tiefsten integriert in Oracle Datenbanken (einschliesslich Fine Grained Auditing und Capturing der Redo Logs)
Alarmierung sehr schwach (nur in Weboberfläche, kein Fax, E-Mail, SNMP)
Komplexe Konfiguration
Zentrales Auditing – Empfehlungen Oracle Audit Vault
35
© 2009
Oracle Datenbank Security: Kernaussagen
Es gibt viele Produkte, um eine Datenbank abzusichern, aber selten reicht ein Tool aus, um die spezifischen Ansprüche abzudecken
Deswegen ist eine sehr gute Abklärung wichtig
Voraussetzung ist immer, dass die Risiken bekannt sind und richtig bewertet werden
Die Oracle Tools sind in den aktuellen Versionen durchaus einsetzbar
Trivadis hilft gern weiter
UND: Besuchen Sie unseren TechnoCircle "Compliance"
DOAG SIG - Compliance im Oracle Umfeld 69
Basel · Baden Brugg · Bern · Lausanne · Zürich · Düsseldorf Frankfurt/M. · Freiburg i. Br. · Hamburg · München Stuttgart · Wien
Vielen Dank!