Compliance im Oracle Umfeld - Wie schützte ich die Daten vor dem DBA

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 Basel Baden Brugg Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien Agenda Überblick Verschlüsslung Database Vault Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Audit Vault Weitere Tools Empfehlungen 2 1

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 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 Instanz Datenbank Files End User, Developer, DBA 4 2

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 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 Virtual Private Database Database Vault Secure Application Roles Um Schutz vor hochpriviligierten Benutzern (DBAs) zu gewährleisten, braucht es aber eine spezielle Option Database Vault 6 3

Zugriffsschutz (4) Hacker Instance Database Files AAA oder Database Vault schützen die Daten nicht vor direkten Zugriffen auf die Datenfiles oder die Backups Backups Transparent Data Encryption RMAN Backup Encryption 7 Zugriffsschutz (5) End User, Developer, DBA Oracle Net Database Server Advanced Security Die Daten werden über das Netzwerk standardmässig unverschlüsselt übertragen Hacker 8 4

Zugriffsschutz (6) Eventuell reicht das Auditing in der Datenbank oder auf dem Server nicht aus Oracle Audit Vault 9 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) 10 5

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) 11 Agenda Überblick Verschlüsslung Database Vault Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Audit Vault Weitere Tools Empfehlungen 12 6

Motivation (1) Endbenutzer, Entwickler, DBA Zugriff auf die Instanz ist geschützt durch Datenbank Authentifizierung, Autorisierung und Auditing (AAA) Hacker Instanz Datenbank Files RMAN Und was ist mit Backups? Und Exports? 13 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 14 7

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 15 Transparent Data Encryption ENCRYPT Klausel Die Verschlüsselung kann für jede Spalte einzeln definiert werden Release 2 Unterstützte Verschlüsselungsalgorithmen AES128 AES192 (Default) AES256 3DES168 16 8

Transparent Data Encryption - Einschränkungen 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 17 Tablespace Encryption 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!! 18 9

Vorgehen Identisch wie bei TDE wird mit folgendem Befehl ein Master-Key in einem Wallet erstellt: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY {password} 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: ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY {password} 19 Tablespace erzeugen Nun können verschlüsselte Tablespaces erzeugt werden Beispiel: CREATE TABLESPACE enc_test DATAFILE SIZE 50M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT) Als Verschüsselungsalgorithmen können 3DES168, AES128, AES192 oder AES256 gewählt werden 20 10

Auswirkungen Performance 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): Operation CPU-Verbrauch ist höher Impact Massen-Insert (zeilenweise) 10% Massen-Deletes/Updates 10% Massen-Insert (IDL) 1% Full-Table Scan 1% Index-Scan <1% Grösse der Datenfiles ändert sich bei Verschlüsselung nicht 21 Auswirkungen Tools EXP exportiert keine Daten aus verschlüsselten Tablespaces: 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... 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! 22 11

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 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) Encryption Appliance Database 24 12

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 Agenda Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Überblick Verschlüsslung Database Vault Audit Vault Weitere Tools Empfehlungen 26 13

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 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 14

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 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 15

Separation of Duties Task Betrieb der DB und der Instanz (Erzeugen, Parametriseren, Instanztuning, Patching, Updates, Tablespace- Management, ) Security Management Anlegen von Realms, Definition der zu schützenden Objekte Verantwortlich 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 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 16

Nicht durch DBV abgedeckt Risiko Daten in Datafiles im Klartext (OS- und SAN- Admin sowie Oracle-Unix-Account kann Daten lesen) Massnahme 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 Nicht durch DBV abgedeckt Risiko Während Patching (z.b. CPUs) sowie Migrationen muss DBV ausgeschaltet werden Daten im Klartext über Netzwerk bzw. Interconnect bei RAC) Massnahme Personifizierte Accounts auf Unix und Sudo- Konzept Überwachung auf Betriebssystemebene (inode+ctime Checks, z.b. manuell, Nimbus,iwatch (Linux, basierend auf inotify)) 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 17

Agenda Überblick Verschlüsslung Database Vault Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Audit Vault Weitere Tools Empfehlungen 35 Übersicht 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 36 18

Komponenten Folgende Komponenten werden benötigt: Audit Vault Agent Audit Vault Server zu überwachende zu überwachende Datenbank Datenbank Source DBAUD Collector OSAUD Collector REDO Collector Data Collection Warehouse Reports Alerts Management Security MSSQL Collector Sybase Collector DB/2 Reporting Alerts Management 37 Auditdefinition (1) 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 38 19

Auditdefinition (2) Zuerst müssen die aktuellen Definitionen empfangen werden: 39 Auditdefinition (3) Danach werden die zu überwachenden Ereignisse innerhalb Audit Vault definiert: 40 20

Auditdefinition (4) Diese sind dann noch nicht "in use" Und müssen erst appliziert (exportiert oder provisioniert) werden 41 Auditdefinition (5) Audit Vault und Datenbank sind synchronisiert: 42 21

Auswertungen (1) 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 43 Auswertungen (2) Ausserdem existieren diverse vordefinierte Reports 44 22

Auswertungen (3) Diese können dann nach diversen Kriterien eingeschränkt werden: 45 Auswertungen (4) Die Ergebnisse werden tabellarisch dargestellt mit der Möglichkeit, ins Detail zu verzweigen 46 23

Auswertungen (5) Details 47 Auswertungen (6) Bessere Anzeigemöglichkeiten durch Highlighting 48 24

Auswertungen (7) Bessere Anzeigemöglichkeiten durch Charts 49 Alarme Jedes Audit-Event kann auch als Alarm oder Warning definiert werden, diese werden dann auf der Homepage dargestellt: 50 25

MS SQL Connector (1) 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 51 MS SQL Connector (2) Übersicht der Ereignisse einer SQL-Server 2005 Datenbank 52 26

MS SQL Connector (3) Detailanzeige 53 Agenda Überblick Verschlüsslung Database Vault Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Audit Vault Weitere Tools Empfehlungen 54 27

HR CRM DB Sentrigo Hedgehog 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 55 Monitoring All Activity in the Database Corporate Firewall ERP Authentication & Access Control All database transactions (externally- or internallyinitiated) go via the shared memory 56 D B Local Connection Network Connection Commercially Classified Listener Bequeath DBMS Shared Memory Data Stored Proc. Trigger View Quelle: Sentrigo 28

Sentrigo Hedgehog Dashboard und Detail-Informationen Technocircle Compliance: Weitere Tools und Möglichkeiten 57 Sentrigo Hedgehog und virtuelles Patching 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 58 29

Centralized User Administration for Database 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! Technocircle Compliance: Weitere Tools und Möglichkeiten 59 Vergleich CUA4DB und Enterprise User Quelle: Oracle Technocircle Compliance: Weitere Tools und Möglichkeiten 60 30

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 Agenda Überblick Verschlüsslung Database Vault Daten sind immer im Spiel. Aber sie müssen auch geschützt werden! Audit Vault Weitere Tools Empfehlungen 62 31

Schutz der Daten vor dem DBA Empfehlungen Oracle Database Vault 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) 63 Schutz der Daten vor dem DBA Empfehlungen Verschlüsslung der Daten in der Applikation 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 64 32

Schutz der Daten vor dem DBA Empfehlungen Sentrigo Hedgehog 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 65 Schutz der Daten vor dem DBA Empfehlungen CUA4DB Schützt allein nicht vor dem DBA Sinnvoll in Kombination mit Database Vault Kann als IAM-Lösung aber viel mehr Technocircle Compliance: Fazit 66 33

Zentrales Auditing Empfehlungen Sentrigo Hedgehog 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 67 Zentrales Auditing Empfehlungen Oracle Audit Vault 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 68 34

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" 69 Vielen Dank! Basel Baden Brugg Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien 35