Oracle Database Security: Wie viel darf es denn sein?

Transkript

1 Oracle Database Security: Wie viel darf es denn sein? Oracle Database Security Seminar Stefan Oehrli Senior Consultant Discipline Manager Trivadis AG 08 / 09 Februar 2012, Düsseldorf + Berlin BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN

2 Trivadis Facts & Figures 11 Trivadis Niederlassungen mit über 550 Mitarbeitern Hamburg Finanziell unabhängig und nachhaltig profitabel Kennzahlen 2010 Düsseldorf ~180 MA Umsatz CHF 101 / EUR 73 Mio. Frankfurt Dienstleistungen für über 700 Kunden in mehr als Projekten Über 170 Service Level Agreements Stuttgart Freiburg München Wien Mehr als 5'000 Trainingsteilnehmer Basel Bern Zürich Lausanne ~350 MA ~20 MA Forschungs- und Entwicklungsbudget: CHF 5.0 / EUR 3.6 Mio. 2

3 Das Besondere Kundenindividuelle Lösungskompetenz und Herstellerunabhängigkeit Technologiekompetenz Lösungs- und Integrations-Know-how Begleitung über den gesamten IT-Projekt- Lifecycle bietet fundierte Methodenkenntnisse und eigenentwickelte Vorgehensweisen garantiert wiederholbare Qualität und Realisierungssicherheit hat über 17 Jahre Expertise in Oracle und Microsoft verfügt über ein eigenes Technology Center und setzt auf technologische Exzellenz hat eine breite, branchenübergreifende Kundenbasis und jährlich über 1800 Projekte verbindet technologisches Spezialisten Wissen mit dem Verständnis für die Business-Spezifika des Kunden begleitet den gesamten IT-Projekt-Lifecycle mit einem modularen Dienstleistungsportfolio bietet für jeden Reifegrad die passende Dienstleistungs- und Lösungskombination 3

4 AGENDA 1. Übersicht 2. Risikoanalyse und Kategorisierung 3. Risikomatrix 4. Risikominimierung 5. Überprüfung 4

5 Einleitung Fragen Oracle bietet innerhalb der Datenbank diverse Features, um die Datensicherheit zu gewährleisten VPD, ASO, TDE, DBV, AV,... J Ein Teil ist nur in der Enterprise Edition vorhanden, ein Teil ist zusätzlich lizenzpflichtig Außerdem gibt es von Oracle noch weitere, externe Produkte Und natürlich auch Lösungen von Dritthersteller... Was brauche ich davon aber in meiner Datenbank? Und wenn ich viele (unterschiedliche) Datenbanken habe? 5

6 Einleitung Fragen Kennen Sie Ihre Daten? Beziehungsweise deren Sensitivität? Wie ist der Anteil von öffentlichen, vertraulichen, internen, geheimen,... Daten So? oder eher so? 6

7 AGENDA 1. Übersicht 2. Risikoanalyse und Kategorisierung 3. Risikomatrix 4. Risikominimierung 5. Überprüfung 7

8 Risikoanalyse Der Besitzer der Daten (bzw. der Applikation) muss die Sensitivität seiner Daten definieren Das ist nicht immer ganz einfach, da jeder davon ausgeht, seine Daten sind die wichtigsten, kritischsten,... Deshalb empfiehlt sich die Durchführung einer Risikoanalyse Wir benutzen dazu die Trivadis First Cut Risikoanalyse Einfach durchzuführen In "Business-Sprache" Gefährdungen werden schnell erkannt Geht nicht in die (technische) Tiefe, aber danach ist bekannt, vorauf man sich konzentrieren muss 8

9 First Cut Risikoanalyse - Inhalt Abgefragt werden (u.a.): Werden Personendaten oder sogar besonders schützenswerte Personendaten (Gesundheit, Religion, Strafmaßnahmen,...) verarbeitet? Was geschieht bei Verlust der Vertraulichkeit? (Wettbewerbsnachteile, Geschäftsschädigung, Störung des öffentliches Vertrauens, Haftung,...)? Was geschieht bei Verlust der Integrität? (falsche Management Entscheide, zusätzliche Kosten, Geschäftsunterbruch)? Was geschieht bei Verlust der Verfügbarkeit (Wiederherstellung,...)? Der Dateneigentümer bewertet alle diese Punkte in einer 3-stufigen Skala (von nicht kritisch über kritisch bis geschäftskritisch) Hier können auch Werte für den materiellen Schaden hinterlegt werden, dass hilft häufig für die Einschätzung 9

10 First Cut Risikoanalyse Analyse 10

11 First Cut Risikoanalyse - Konsolidierung 11

12 Klassifizierung Durch die Risikoanalyse erfolgt die Einteilung der Daten(-banken) in Sicherheitsklassen Typischerweise benutzt man folgende Klassen: Öffentlich (Daten sind z.b. im Internet sichtbar dürfen dort aber sicherlich nicht manipuliert werden) Intern (Daten dürfen von allen Mitarbeitern gesehen werden) Vertraulich (Daten dürfen nur von einem definierten Kreis von Mitarbeitern gesehen werden) Geheim (Wenn diese Daten verloren gehen, ist die Existenz der Firma gefährdet, z.b. das Rezept von Coca Cola) 12

13 AGENDA 1. Übersicht 2. Risikoanalyse und Kategorisierung 3. Risikomatrix 4. Risikominimierung 5. Überprüfung 13

14 Risikomatrix (1) Der Kopf der Matrix definiert die Klassen und die zu reduzierenden Risiken: 14

15 Risikomatrix (2) Im weiteren werden dann die Maßnahmen definiert, mit denen die definierten Risiken reduziert werden sollen: 15

16 Risikomatrix (3) Wichtig ist, auch die Konsequenzen (und Kosten) zu definieren: 16

17 AGENDA 1. Übersicht 2. Risikoanalyse und Kategorisierung 3. Risikomatrix 4. Risikominimierung 5. Überprüfung 17

18 Risikominimierung - Authentifizierung Benutzer melden sich mit nur einem Sammelbenutzer an Jeder Benutzer hat seinen eigenen, persönlichen Benutzer Sowohl in der Datenbank als auch auf OS Ebene Es existiert eine zentrale Benutzerverwaltung Verwaltung in einem zentralen Verzeichnis Anmeldung über dieses Verzeichnis - z.b. Enterprise Users oder Provisionierung der Benutzer in die Datenbanken - z.b. CUA4DB (Centralized User Administration for Database Starke Authentifizierung (mehr als nur Benutzername und Passwort) Risiko Achtung: Authentifizierung ist die Grundlage für alles weitere! 18

19 Risikominimierung - Passwörter Es existieren keine Passwortregeln Passwörter unterliegen Komplexitätsregeln Minimale Länge Benutzer von numerischen Zeichen, Sonderzeichen,... Keine gebräuchlichen Wörter Alle Passwörter müssen regelmäßig geändert werden Dürfen nicht wiederbenutzt werden Müssen sich auf definierte Art vom alten Passwort unterscheiden Nicht interaktiv benötigte Accounts werden gelockt (oder auf unmögliches Passwort gesetzt) Gilt auch (oder gerade) für Oracle Default Schemata Risiko 19

20 Risikominimierung - Datenzugriff Benutzer können alle Daten lesen/ändern Benutzer haben nur Zugriff auf Daten, für die sie Berechtigungen haben (auf Tabellenebene): Rollenkonzept Keine Public Grants Risiko Benutzer haben nur Zugriff auf Daten, für die sie Berechtigungen haben (auf Zeilenebene): Virtual Private Database (Security Policies) Label Security Auch Administratoren haben nur Zugriff auf berechtigte Daten Database Vault Verschlüsselung vor der Datenbank (durch die Applikation oder Verschlüsselungslösungen wie z.b. von Safenet) Tokenization 20

21 Risikominimierung - Datenzugriff - Bemerkungen Wichtig dabei ist zu erkennen, auf welche Art jemand Zugriff auf Daten erlangen kann: Owner der Tabelle Direkter Grant auf die Tabelle Über eine (geschachtelte) Rolle Public-Berechtigung Über eine View oder ein Package Über ein Systemprivileg (select any table) Über hoch privilegierte Rollen (dba, sysdba) An Rollenwechsel denken (Praktikanten haben die meisten Rechte...) Tools für die Analyse benutzen wie z.b. Oracle Identity Analytics 21

22 Risikominimierung - Auditing Auditing ausgeschaltet Nur grundlegende Operationen werden auditiert (z.b. Connect) Kritische Operationen werden auditiert Benutzung von ANY Privilegien Benutzer- und Berechtigungsmanagement Operationen von SYSDBAs Zugriffe auf kritische Objekte werden auditiert Definition der kritischen Objekte Definition der Regeln, wann ein Zugriff auditiert werden soll Zentrales Auditing Oracle Audit Vault SYSLOG Auditing McAfee Database Activity Monitoring Risiko 22

23 Risikominimierung - Auditing - Bemerkung Häufig will man den Zugriff auf Tabellen nur bei bestimmten Bedingungen überwachen Einsatz von Fine Grained Auditing (FGA) Daten müssen regelmäßig ausgewertet Reporting Funktionen bei einem Zentralen Auditing mit Oracle Audit Vault Auswertung / Tools bei einem SYSLOG Server Manuelles Reporting in der Datenbank Alarmierung bei Problemen / Verstößen! Und wie lange sollen diese Aufbewahrt werden? Definition der Aufbewahrungszeiten für Rohdaten und Reports. Automatisiertes Housekeeping Archivierung 23

24 Risikominimierung - Patching Kein Einspielen von Security-Paches und Patch-Sets Regelmäßiges Einspielen der Patch-Sets ( ) Regelmäßiges Einspielen von CPUs oder PSUs Zeitnahes Einspielen jedes CPUs bzw. PSUs Z.B. max. ein Monat nach Erscheinen des CPUs Virtuelles Patching McAfee Database Activity Monitoring (zusätzlicher Schutz zum CPU/PSU) Risiko 24

25 Risikominimierung Oracle Software & Optionen Beliebige Software und Optionen sind installiert Nur benötigte Optionen sind in der Datenbank installiert Kritsch z.b. Java, XDB,... Nur benötige Software ist im Oracle Home installiert Die benötigten Optionen werden gehärtet Keine Grants an Public (wie es standardmäßig häufig der Fall ist) Rollenkonzept, nur Berechtigungen an Benutzer, die Funktionalität brauchen Network Callouts (Mail, TCP,...) werden eingeschränkt Risiko 25

26 Risikominimierung Parameter Initialisierungsparameter stehen beliebig Definition einer Baseline für sicherheitskritische Parameter, z.b. 07_DICTIONARY_ACCESSIBILITY AUDIT_SYS_OPERATIONS, AUDIT_TRAIL DB_BLOCK_CHECKING REMOTE_OS_AUTHENT REMOTE_OS_ROLES UTL_FILE_DIR Durchsetzen der Baseline Ausnahmen (eventuell durch Applikation gefordert) sind begründet und dokumentiert Risiko 26

27 Risikominimierung weitere Möglichkeiten Netzwerk: Database Firewall (Oracle, Imperva) Verschlüsselung (Advanced Security Option) Zonenkonzept Release Management: Wer hat wann Zugriff auf Schema Owner (die ja gelockt sein sollen) Dokumentation der Prozesse Anonymisierung von Testdaten (Oracle Data Masking) Schutz von Datenfiles, Exports, Dump s, Backups durch Verschlüsselung 27

28 AGENDA 1. Übersicht 2. Risikoanalyse und Kategorisierung 3. Risikomatrix 4. Risikominimierung 5. Überprüfung 28

29 Überprüfen dieser Massnahmen Die Einhaltung dieser Massnahmen sollte regelmässig und möglichst automatisch überprüft werden Dazu bietet sich das Trivadis Tool Tvd-SecAudit an 29

30 Fazit: Security muss ganzheitlich an vielen Stellen durchgesetzt werden. Zuerst einmal muss ich wissen, was ich brauche. Das ist nicht immer einfach... Aber wir unterstützen Sie gern J 30

31 ? Fragen? 31

32 VIELEN DANK. Trivadis AG Stefan Oehrli Europa-Strasse 5 CH-8152 Glattbrugg Tel stefan.oehrli@trivadis.com BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN