35
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

Compliance im Oracle Umfeld - Wie schützte ich die Daten ... · PDF fileZentrales Auditing, nicht nur für Datenbanken (z.B. RSA enVision) DOAG SIG - Compliance im Oracle Umfeld 10

Embed Size (px)

Citation preview

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!