Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Transkript

1 1

2 Wann haben Sie das letzte Mal die Sicherheit Ihrer Datenbank geprüft? Carsten Mützlitz (Oracle) 2

3 SECURE YOUR FUTURE 3

4 AGENDA 15:00 4

5 GEHT es EIGENTLICH bei der CONTROL 5

6 RISIKEN sind unter KONTROLLE SECURITY INSIDE OUT BEDROHUNGEN VERHINDERN REALITÄT oder WUNSCH? 6

7 Vorweg I muss betrachtet werden SECURITY AT EACH LAYER SECURITY BETWEEN LAYERS SECURITY BETWEEN SYSTEMS S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y FOKUS S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y S E C U R I T Y 7

8 Vorweg II: You even a Siehe Beispiel Spiegel Online Ziel das Internet zu vermessen: Telnet Scanner scannt die Router im Internet ab mit Standard-Kennwörtern mit root:root, admin:admin Scans an beliebige IP-Adressen - Hat bei Hunderttausenden von Rechnern funktioniert Ergebnis: Aufbau eines Botznets mit Rechnern zur Vermessung des Internets The best weapon with which to defend information is information! 8

9 aus vielen Verfügbarkeit Monitoring Audit Compliance Nachhaltigkeit Zugriffskontrolle Konfiguration SERVICE Konzepte sind vorhanden. Aber leider teilweise gar nicht oder falsch implementiert! 9

10 Hunderte DB Sec. Reviews zeigen einen neutralen aber besorgten Blick auf die Sichere Konfiguration? Verfügbarkeit umgesetzt? Überwachung eingestellt? Zugriffskontrolle implementiert? Compliance und Nachhaltigkeit vorbereitet? 10

11 und zusammengefasst 6. Schwaches oder kein Audit/Überwachung 5. Verfügbarkeit entsprechend Anforderungen? 4. Erhöhte Komplexität / falsche Konzepte 3. Schwache Zugriffskontrolle und Zwecktrennung 2. Selten eigene Mindestsicherheit implementiert Nichts, 1. Kaum Wissen und keine Verantwortungen (AKVs) definiert was man nicht besser machen kann 11

12 1. Kaum über den notwendigen Schutzbedarf der Daten nicht definiert und Daten selten klassifiziert Kaum Wissen über gesetzliche Anforderungen Kaum wirkliches Wissen über den notwendigen Schutzbedarf Wenig definierte Verantwortung Kaum Wissen über neue Funktionen/Konzepte und abgelaufene Funktionen Organisatorische Lösung innerhalb der Unternehmung ist gefordert. 12

13 2. Keine eigene implementiert Kein Mindest-Audit eingestellt Kein Password-Management Kein Profiling/Resourcen-Mgmt. Unsicherer Umgang mit Accounts und Privilegien Kein Patching Konzept Falsches (Public) DB Links Setup Keine sichere Konfiguration Viele Default Einstellungen Secure DB Configuration in der Online Dokumentation nutzen und anpassen : Keeping your database secure: : Keeping your database secure:

14 2. Keine eigene Patching: Auch wenn Tausende Instancen zu bedienen sind, sollte man im Vorfeld entscheiden, wann gepatched werden muss implementiert Oracle Patch Management Best Practice Nicht, wie oft gepachted werden muss, sondern wann gepachted werden muss! Graceperiode beachten! 14

15 2. Keine eigene Profiling/PW-Mgmt: implementiert Pro Benutzergruppem ein Profil. Password-Komplexität einstellen mind. 9 Zeichen. 15

16 2. Keine eigene implementiert Die Autorisierung übernimmt meistens die Anwendung, denn nur die kennt den Enduser Sicheres DB Link Setup Endanwender sichtbar PW-Änderungen Aktivieren Sie eine definierte Mindestsicherheit für alle Datenbanken. 16

17 2. Keine eigene implementiert 10 Schritte für eine Mindestsicherheit: 10 Basic Steps to Make Your DB Secure from Attacks [ID ] 1. Password für SYS / SYSTEM Passwords ändern und starke Komplexität wählen 6. Data Dictionary schützen O7_DICTIONARY_ACCESSIBILITY=FALSE 2. Lock, expire und PW ändern für ungenutzte User Installieren Sie nur das, was benötigt wird Siehe hierzu Note Zugriff auf Oracle Home und Files einschränken Der oracle Account sollte alle Files besitzen Kein Benutzer außerhalb der Oracle Gruppen sollte Zugriff auf die Files haben 4. Review Database Privileges Das Konzept least privilege sollte angewendet sein Siehe Note Master Note For Privileges And Roles 5. Revoke Privileges from Public Vorsichtige Vergabe von Privilegien an PUBLIC 7. Set REMOTE_OS_AUTHENT to FALSE (8i, 9i, 10g) DB wird keiner Client-Authentizierung trauen 8. Listener und Netzwerkverbindungen schützen Listener schützen auf Basis der Oracle Guidelines Netzwerk verschlüsseln mit jeder DB Edition 9. Datenbank Host schützen Firewall nutzen Gehärtete Betriebssysteme (Windows/Unix) Patches zeitnah einspielen (CPU und Security Alerts) 10. Prüfung der Oracle Security Alerts und CPUs Neuste Informationen abonnieren Jedes Security Patch Update überprüfen und wenn nötig zeitnah einspielen Implementieren Sie diese 10 Schritte und erweitern Sie diese entsprechend des Schutzbedarfs. 17

18 3. Komplexe und kaum Zwecktrennung Privileged Users Kein least Privileg Konzept Zugriffskonzepte ausgehebelt Standardrollen (wie RESOURCE) Public übermächtig Public DB Links, DB Links auf die gleiche DB und Grants an Public Falsches Rollenverständnis (DBA) Keine Zwecktrennung (Apps- Owner, DBAs greifen auf APP zu, Account-Mgmt. über viele User) Trotz implementierter Zugriffskontrolle wird diese ausgehebelt und Gesetze nicht erfüllt. 18

19 3. Komplexe und kaum Komplexität beherrscht die Zugriffskontrolle: Zu komplexe Rollen Konzepte Zu viele nicht notwendige Grants Nutzung von Standardrollen Doppelte Rollen Redundante Privilegien Komplexität ist die Grundbedrohung der Kontrolle Trotz komplexem Konzept Aushebelung, z.b. durch Grants an Public und DB Links 19

20 3. Komplexe und kaum Komplexität beherrscht die Zugriffskontrolle: Berechtigungen an Rollen und User keine einheitlichen Konzepte implementiert Entstehung von Redundanzen Kontrolle in komplexen Umgebungen sehr unwahrscheinlich Keine Rollen, nur direkte Grants = Mehraufwand wenn gleicher Zugriff für mehr als ein User notwendig 20

21 3. Komplexe und kaum Endbenutzer Apps-Server Admins Hochprivilegierte Anwendungsowner: Schema Owner Schema APPUSER RELEASE Manager Install and change objects Falsches Setup mit DBA Role Hat man keinen Einfluß dieses Setup zu ändern, sollte man für eigene Setups wie DB Links, Reportinguser etc. Anwendungsuser aktivieren, die minimale Rechte besitzen. Anwendungsowner und user werden nicht korrekt getrennt Anwendungsowner bekommen zu viele Berechtigungen Keine Kontrolle unerlaubter Zugriffe z.b. - Anwendung oder - SQL Developer greift zu Konzepte werden nicht erzwungen Zwecktrennung wird nicht beachtet Audit wird nicht eingeschaltet DBAs sind nicht zuständig 21

22 3. Komplexe und kaum DB Links: Zugriffe von entfernter DB über den DBLINK-User Teilweise starke Privilegien. Keine Protokollierung! Zugriffe über DB Links zu entfernten DBs DB host1.de host2.de. host10.de Mit 12c besseres Audit möglich, auch die entfernten DB Link Zugriffe (auch mit 11g) können überwacht werden Wer greift auf die DB zu? DB Link Setup entsprechend Least Privileg? Public DB Links sind sehr gefährlich Zwecktrennung implementiert? - DBA greift auf Anwendungsobjekte in einer entfernten DB zu DB Links nicht sicher konfiguriert (MOS Doc ID bekannt oder Hinweis im License-Guide?) 22

23 3. Komplexe und kaum Gefährliche Privilegien: SELECT ANY ALTER USER BECOME USER EXP_FULL_DB DBA role DB Privilege Analysis mit 12c Create Drop Modify DBA role APPADMIN role Zu viele ANY Grants (kein Least Privileg Konzept?) Zu viele Grants gefährlicher Rollen (IMP FULL DB) Kein Schutz für gefährliche Rollen (Secure Application Roles) implementiert Keine Überwachung der Nutzung gefährlicher Privilegien 23

24 3. Komplexe und kaum Password-Datei: Administration immer über die Konsole als oracle Unix-User: sqlplus / as sysdba DB Admins PASSWORD-File INIT.ORA REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE Password-File ist erstellt Remote-Administrierung wird nicht ausgeführt Die DBAs nutzen ein Terminal am lokalen Server (ssh/telnet)? Wofür braucht man dann eine Password-Datei? Eingeschaltete Multithreading Architektur in 12c erfordert eine Password-Datei für die SYS- Authentisierung. ALTER SYSTEM SET threaded_execution=true SCOPE=SPFILE; 24

25 3. Komplexe Personalisierung: und kaum Standard SYSDBA Standard DBA SYS SYSTEM Standard Oracle SYSDBA Standard Oracle DBA Falsches Setup Trotz Forderung aus Gesetzen (DSV/LDSG) sind DBAs selten personalisiert Gearbeitet wird stattdessen als oracle, SYS und SYSTEM Wofür wird SYS und wofür SYSTEM genutzt? Kunde DBA DBA Name Kunden DBA 25

26 3. Komplexe Unerlaubte Zugriffe/Zwecktrennung: und kaum Keine personalisierten DBAs DB Links mit vollem Zugriff Endbenutzer Apps-Server Apps-Owner für Anwendung und Tools wie SQL Developer in Gebrauch Hat man keinen Einfluß dieses Setup zu ändern, sollte man für eigene Setups wie DB Links, Reportinguser etc. Anwendungsuser aktivieren, die minimale Rechte besitzen. APPS-Owner APPS-User Falsches Setup Richtiges Setup Endbenutzer Apps-Server DB-Accounts mit vollem Zugriff auf alle Objekte Keine Trennung entsprechend AVKs Keine Zwecktrennung im Auditing (FGA) Jeder DB User darf alles machen (PUBLIC GRANTS) 26

27 3. Komplexe und kaum Zwecktrennung: Keine Trennung entsprechend AVKs Gerade in der Administration kann jeder DBA alles machen DBA Separation of Duty nicht implementiert Keine delegated Administration Kein einheitliches Account- Management 27

28 3. Komplexe und kaum Endusers Autorisierung in der Anwendung: Client: Browser oder Fat Client Installation Gesicherte Leitung, Zugriff über die Anwendung Application Server Connection autorisiert für den kompletten Datenzugriff (DML, DDL) CONNECT APPS Shared Admins Schema Owner APPS Schema APPUSER DBA SYSTEM Administratiert die DB Falsches Setup Berechtigungen: CONNECT RESOURCE UNLIMITED TABLESPACE SELECT ANY, DELETE ANY... Autorisierung nur in der Anwendung Anwendungssicherheit muss perfekt sein Es wird auf den Anwendungsowner mit all seinen Berechtigungen operiert Endbenutzer nicht bekannt Unerlaubte Zugriffe nicht sichtbar, kein Audit aktiviert Mögliche Schutzmaßnahme: DB Firewall oder Enduser sichtbar machen und in DB autorisieren. 28

29 4. Erhöhte und APPS-Schema: APPS-Database APPS-Schema Copy: Falsche Konzepte erhöhen die Komplexität bzgl. der Zugriffskontrolle erheblich Lösung transparentes ILM Keine Autorisierung in der DB, kein garantierter Schutz in der Anwendung Kein übergreifender Schutz von Daten auch außerhalb der DB Komplexe Konzepte im Umgang mit Daten generieren eine kaum mögliche Kontrolle. 29

30 4. Erhöhte und Automatische Datenoptimierung mit 12c/11g (Information Lifecycle Mgmt.): Hot Data Warm Data Archive Data Eine Table Aktueller Datenbestand Datenbestand im Archivierte Daten mittleren Zugriff Transparente Konzepte nutzen, die nicht die Sicherheit und Kontrolle komplexer machen. 30

31 4. Erhöhte und ½ PASSWORD xxyyzz organisatorisches Vieraugenprinzip ½ PASSWORD ssttuu Export Datapump Data Unloader CONNECT for export Data Procurement HR Finance DUAL Connect Check Rule Set: Dual Connect for Unloader and Approver Rule 1: Check if approver and Unloader is logged in Rule 2: Allow Connect for other users Map Command: Map command CONNECT to Rule Set Data Loader Approver CONNECT for approval erzwungenes Vieraugenprinzip Ein Vier-Augenprinzip kann z.b. mit DB Vault erzwungen werden. 31

32 4. Erhöhte und Datenschutz einstellen? Umgang mit sensiblen Daten Kein oder wenig Datenschutz eingestellt Daten außerhalb der Datenbank nicht geschützt Keine Sicherheitszonen definiert Keine Überwachung des Zugriffs Kontrollverlust, wenn die Daten die DB verlassen Datenschutz für sensible Daten einstellen, gerade dann wenn die Daten die DB verlassen. 32

33 5. entsprechend Anforderungen Risiken und Anforderungen müssen bekannt sein, nur dann kann man sich schützen HA Anforderungen nicht immer definiert Glaube vs. Wissen Backup falsch aufgesetzt Wenig Schutz vor geplanten Ausfallzeiten (Transient logical Standy, Rolling Upgrades) Verfügbarkeitsanforderungen erfüllen und nicht nur vor ungeplanten Ausfallzeiten schützen. 33

34 6. Schwaches oder kein Gesetzliche Anforderungen erfüllt? Gesetze erfordern eine Protokollierung! Trotz gesetzlicher Anforderungen kein Audit eingestellt Objektzugriffe, werden nicht oder sehr selten protokolliert Wichtige SYS-Objekte werden nicht überwacht Unerlaubte Zugriffe werden nicht erkannt Keine Überwachung des Zugriffs auf sensible Objekte wie SYS.% und Anwendungsobjekte Audit ist unerläßlich, damit man die Kontrolle nicht verliert. Es gibt keine Ausreden! 34

35 SECURE YOUR FUTURE Warum? Hat das einen Nutzen? 35

36 gestohlene Datensätze kosten ein Unternehmen durchschnittlich > 1 Mill. Beispiel: gestohlene Datensätze Interne Analyse Kunden Info Poneman Institut sagt 88% der Datendiebstähle entstehen nicht durch Cracker, sondern sind auf Nachlässigkeit zurückzuführen! Quelle: Strafen Kostenrahmen $6,6-9,9 Million Source: Darwin Underwriters Insurance: Data Loss Calculator. Generelle Aussage: Ein Datendiebstahl wird immer hohe Aufwände erzeugen. 36

37 durch Technologie Lösungen Produktivität erhöhen Finden Sie Ihren Return on Investment Risiko vermindern Geschäftsanforderungen Direkter monetärer ROI Menschlichen Aufwand verrringern Kostenintensive Verzögerungen verringern Kosten für Compliance/Security verringern Indirekter monetärer ROI Produktivität erhöhen und Risiken verringern Wissen erlangen (weg von GLAUBEN) Erhöhung der Kontrolle durch Transparenz dadurch bessere Entscheidungen Vereinfachtes Compliance Reporting Frühzeitige Erkennung von Bedrohungen 37

38 und Unterschied zw. Hoch Legende Kosten, Aufwand, Risiko gering Reactive Reaktives Daten und User Management Manuelles und Aufwandintensives Audit Ineffizient, Overhead, Redundanzen Tactical Zentrale Sicht auf Sicherheit und Identifäten, Single source of Truth Kritscher Datenschutz wird erzwungen Strategic User Lifecycle Management Standardisiertes Schutzframework Agilität Enterprise Sicherer Infoaustausch Real-time Auditing, Alerting und automatische Korrekturen Transparent Nachhaltige und transparente Sicherheits security Praktiken Hoch Maturity Levels Business Drivers: Effizienz, Kosteneinsparung, Architektur, Rationalisierung.

39 KONTROLLIEREN 39

40 VERHINDERN 40

41 41

42 SECURE YOUR FUTURE 42

43 Hands-on Workshop 1-Tages-Workshop in Potsdam Die Top Issues im Bereich DB Sicherheit und wie man diese beseitigt Am 11.Dezember bei Oracle Potsdam 43

44 44

45 Werbung in eigener Sache Eine vollständig dokumentierte Vorgehensweise die Sicherheit der DB zu überprüfen Vollgestopft mit Best Practices, Tools und vielen Erkenntnissen Ab Okt im Handel erhältlich 45

46 46