Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2
Wann haben Sie das letzte
Mal die Sicherheit Ihrer
D...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.3
YOUR FUTURE
SECURE
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.4
AGENDA
15:00
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.5
CONTROLCONTROL
GEHT es EIGENTLICH bei der
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.6
SECURITY
INSIDE
OUT
RISIKEN sind unter KONTROLLERISI...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.7
SECURITY
BETWEEN SYSTEMS
SECURITY
AT EACH LAYER
SECU...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.8
The best weapon with which to defend
information is ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.9
SERVICE
Verfügbarkeit
Compliance
Nachhaltig-
keit
Ko...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.10
• Sichere Konfiguration?
• Verfügbarkeit umgesetzt?...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.11
Nichts, was man nicht besser machen kann
1. Kaum Wi...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.12
• Schutzbedarf der Daten nicht
definiert und Daten ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.13
• Kein Mindest-Audit eingestellt
• Kein Password-Ma...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.14
Keine eigene implementiert
Nicht, wie oft gepachted...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.15
Keine eigene implementiert
Pro Benutzergruppem ein ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.16
Keine eigene implementiert
Aktivieren Sie eine defi...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.17
Implementieren Sie diese 10 Schritte und erweitern ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.18
• Kein least Privileg Konzept
• Zugriffskonzepte au...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.19
Komplexe und kaum3.
• Zu komplexe Rollen Konzepte
•...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.20
Komplexe und kaum3.
• Berechtigungen an Rollen und
...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.21
Komplexe und kaum3.
• Anwendungsowner und –user
wer...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.22
Komplexe und kaum3.
• Wer greift auf die DB zu?
• D...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.23
Komplexe und kaum3.
• Zu viele ANY Grants
(kein Lea...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.24
Komplexe und kaum3.
• Password-File ist erstellt
• ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.25
Komplexe und kaum3.
• Trotz Forderung aus Gesetzen
...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.26
Komplexe und kaum3.
• Keine personalisierten DBAs
•...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.27
Komplexe und kaum3.
• Keine Trennung entsprechend
A...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.28
Komplexe und kaum3.
• Autorisierung nur in der
Anwe...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.29
Lösung transparentes ILM
• Falsche Konzepte erhöhen...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.30
Erhöhte und4.
0101101110101010010100100100001000
10...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.31
Erhöhte und4.
31
Ein Vier-Augenprinzip kann z.B. mi...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.32
• Umgang mit sensiblen Daten
• Kein oder wenig Date...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.33
Risiken und Anforderungen
müssen bekannt sein, nur ...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.34
Gesetze erfordern eine
Protokollierung!
• Trotz ges...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.35
YOUR FUTURE
SECURE
Hat das einen Nutzen?
Warum?
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.36
Source: Darwin Underwriters Insurance: Data Loss Ca...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.37
Technologie
Lösungen
Geschäfts-
anforderungen
Produ...
gering
Hoch
Hoch
Reactive
Tactical
Transparent
Strategic
Enterprise
Kosten,Aufwand,Risiko
Agilität
Legende
Maturity
Levels...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.39
KONTROLLIEREN
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.40
VERHINDERN
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.41
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.42
YOUR FUTURE
SECURE
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.43
• 1-Tages-Workshop in Potsdam
• Die Top Issues im B...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.44
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.45
• Eine vollständig dokumentierte
Vorgehensweise die...
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.46
Upcoming SlideShare
Loading in …5
×

DOAG SIG Security Vortrag 2013: Wann haben Sie das letzte Mal Ihre Datenbank auf Sicherheit überprüft?

611 views
501 views

Published on

Reale Beispiele von nicht optimalen DB Security Konfigurationen.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
611
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DOAG SIG Security Vortrag 2013: Wann haben Sie das letzte Mal Ihre Datenbank auf Sicherheit überprüft?

  1. 1. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1
  2. 2. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2 Wann haben Sie das letzte Mal die Sicherheit Ihrer Datenbank geprüft? Carsten Mützlitz (Oracle)
  3. 3. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.3 YOUR FUTURE SECURE
  4. 4. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.4 AGENDA 15:00
  5. 5. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.5 CONTROLCONTROL GEHT es EIGENTLICH bei der
  6. 6. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.6 SECURITY INSIDE OUT RISIKEN sind unter KONTROLLERISIKEN sind unter KONTROLLE REALITÄT oder WUNSCH?REALITÄT oder WUNSCH? BEDROHUNGEN VERHINDERNBEDROHUNGEN VERHINDERN
  7. 7. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.7 SECURITY BETWEEN SYSTEMS SECURITY AT EACH LAYER SECURITY BETWEEN LAYERS 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 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 Vorweg I muss betrachtet werden FOKUSFOKUS
  8. 8. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.8 The best weapon with which to defend information is information! Copyright © 2013, Oracle and/or its affiliates. All rights reserved.8 Vorweg II: You even a Siehe Beispiel Spiegel – Online http://www.spiegel.de/netzwelt/web/carna-botnet-internet-zensus-mit-hacker-methoden-a-890225.html • 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 420.000 Rechnern zur Vermessung des Internets
  9. 9. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.9 SERVICE Verfügbarkeit Compliance Nachhaltig- keit Konfiguration Zugriffs- kontrolle Monitoring Audit aus vielen Konzepte sind vorhanden. Aber leider teilweise gar nicht oder falsch implementiert!
  10. 10. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.10 • Sichere Konfiguration? • Verfügbarkeit umgesetzt? • Überwachung eingestellt? • Zugriffskontrolle implementiert? • Compliance und Nachhaltigkeit vorbereitet? zeigen einen neutralen aber besorgten Blick auf die Hunderte DB Sec. Reviews
  11. 11. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.11 Nichts, was man nicht besser machen kann 1. Kaum Wissen und keine Verantwortungen (AKVs) definiert Copyright © 2013, Oracle and/or its affiliates. All rights reserved.11 2. Selten eigene Mindestsicherheit implementiert 3. Schwache Zugriffskontrolle und Zwecktrennung 4. Erhöhte Komplexität / falsche Konzepte 5. Verfügbarkeit entsprechend Anforderungen? 6. Schwaches oder kein Audit/Überwachung und zusammengefasst
  12. 12. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.12 • 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 Kaum über den notwendigen Organisatorische Lösung innerhalb der Unternehmung ist gefordert. 1.
  13. 13. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.13 • 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 Keine eigene implementiert Secure DB Configuration in der Online Dokumentation nutzen und anpassen. 2. 11.2: Keeping your database secure: http://docs.oracle.com/cd/E25054_01/network.1111/e16543/guidelines.htm 12.1: Keeping your database secure: http://docs.oracle.com/cd/E16655_01/network.121/e17607/guidelines.htm#CHDCEBFA
  14. 14. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.14 Keine eigene implementiert Nicht, wie oft gepachted werden muss, sondern wann gepachted werden muss! Graceperiode beachten! 2. Patching: Oracle Patch Management Best Practice http://www.oracle.com/us/support/assurance/leveraging-cpu-wp-164638.pdf Auch wenn Tausende Instancen zu bedienen sind, sollte man im Vorfeld entscheiden, wann gepatched werden muss
  15. 15. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.15 Keine eigene implementiert Pro Benutzergruppem ein Profil. Password-Komplexität einstellen mind. 9 Zeichen. 2. Profiling/PW-Mgmt:
  16. 16. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.16 Keine eigene implementiert Aktivieren Sie eine definierte Mindestsicherheit für alle Datenbanken. 2. Sicheres DB Link Setup Endanwender sichtbar PW-Änderungen ... ... Die Autorisierung übernimmt meistens die Anwendung, denn nur die kennt den Enduser
  17. 17. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.17 Implementieren Sie diese 10 Schritte und erweitern Sie diese entsprechend des Schutzbedarfs. 1. Password für SYS / SYSTEM • Passwords ändern und starke Komplexität wählen 2. Lock, expire und PW ändern für ungenutzte User • Installieren Sie nur das, was benötigt wird • Siehe hierzu Note 472937.1 3. 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 1347470.1 - Master Note For Privileges And Roles 5. Revoke Privileges from Public • Vorsichtige Vergabe von Privilegien an PUBLIC 6. Data Dictionary schützen • O7_DICTIONARY_ACCESSIBILITY=FALSE 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 10 Schritte für eine Mindestsicherheit: 10 Basic Steps to Make Your DB Secure from Attacks [ID 1545816.1] Keine eigene implementiert2.
  18. 18. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.18 • Kein least Privileg Konzept • Zugriffskonzepte ausgehebelt • Standardrollen (wie RESOURCE) • Public übermächtig • Falsches Rollenverständnis (DBA) • Keine Zwecktrennung (Apps- Owner, DBAs greifen auf APP zu, Account-Mgmt. über viele User) Komplexe und kaum Trotz implementierter Zugriffskontrolle wird diese ausgehebelt und Gesetze nicht erfüllt. 3. Zwecktrennung Privileged Users Public DB Links, DB Links auf die gleiche DB und Grants an Public
  19. 19. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.19 Komplexe und kaum3. • 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 Komplexität beherrscht die Zugriffskontrolle:
  20. 20. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.20 Komplexe und kaum3. • 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 Komplexität beherrscht die Zugriffskontrolle:
  21. 21. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.21 Komplexe und kaum3. • 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 Hochprivilegierte Anwendungsowner: SchemaSchema OOwnerwner SchemaSchema APPUSERAPPUSER RELEASERELEASE ManagerManager Install and change objects Admins Endbenutzer Apps-Server mit DBA Rolemit DBA Role Falsches Setup Hat man keinen Ein- fluß dieses Setup zu ändern, sollte man für eigene Setups wie DB Links, Reporting- user etc. Anwend- ungsuser aktivieren, die minimale Rechte besitzen.
  22. 22. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.22 Komplexe und kaum3. • Wer greift auf die DB zu? • DB Link Setup entsprechend Least Privileg? • Public DB Links sind sehr gefährlich • Zwecktrennung implementiert? - DBA greift auf Anwendungs- objekte in einer entfernten DB zu • DB Links nicht sicher konfiguriert (MOS Doc ID 264872.1 bekannt oder Hinweis im License-Guide?) DB Links: host10.de …. host2.de host1.de DB Zugriffe über DB Links zu entfernten DBs Zugriffe über DB Links zu entfernten DBs Zugriffe von entfernter DB über den DBLINK-User Zugriffe von entfernter DB über den DBLINK-User Teilweise starke Privilegien. Keine Protokollierung! Teilweise starke Privilegien. Keine Protokollierung! Mit 12c besseres Audit möglich, auch die entfernten DB Link Zugriffe (auch mit 11g) können überwacht werden
  23. 23. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.23 Komplexe und kaum3. • 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 Gefährliche Privilegien: DB Privilege Analysis mit 12c Create… Drop… Modify… DBA role APPADMIN role SELECT ANY… ALTER USER… BECOME USER… EXP_FULL_DB… DBA role …
  24. 24. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.24 Komplexe und kaum3. • 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? Password-Datei: DB …………… …………… …………… …………… … PASSWORD-File INIT.ORA REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE Admins Administration immer über die Konsole als „oracle“ Unix-User: sqlplus / as sysdba Eingeschaltete Multithreading Architektur in 12c erfordert eine Password-Datei für die SYS- Authentisierung. ALTER SYSTEM SET threaded_execution=TRUE SCOPE=SPFILE;
  25. 25. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.25 Komplexe und kaum3. • 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? Personalisierung: SYSSYS SYSTEMSYSTEM DBADBA NameName Kunden DBA Standard SYSDBA Standard DBA Kunde DBA Standard Oracle DBA Standard Oracle SYSDBA Falsches Setup
  26. 26. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.26 Komplexe und kaum3. • Keine personalisierten DBAs • DB Links mit vollem Zugriff • Apps-Owner für Anwendung und Tools wie SQL Developer in Gebrauch • 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) Unerlaubte Zugriffe/Zwecktrennung: APPS-Owner Endbenutzer Apps-Server APPS-User Endbenutzer Apps-Server Falsches SetupRichtiges Setup Hat man keinen Ein- fluß dieses Setup zu ändern, sollte man für eigene Setups wie DB Links, Reporting- user etc. Anwend- ungsuser aktivieren, die minimale Rechte besitzen.
  27. 27. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.27 Komplexe und kaum3. • 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 Zwecktrennung:
  28. 28. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.28 Komplexe und kaum3. • Autorisierung nur in der Anwendung • Anwendungssicherheit muss perfekt sein • Es wird auf den Anwendungsowner mit all seinen Berechtigungen operiert • Endbenutzer nicht bekannt Autorisierung in der Anwendung: Mögliche Schutzmaßnahme: DB Firewall oder Enduser sichtbar machen und in DB autorisieren. Schema OSchema Ownerwner Schema APPUSERSchema APPUSER DBA SYSTEMDBA SYSTEM Administratiert die DB Shared Admins CONNECT APPS APPSAPPS Gesicherte Leitung, Zugriff über die Anwendung Endusers Client: Browser oder Fat Client Installation Application Server Berechtigungen: CONNECT RESOURCE UNLIMITED TABLESPACE SELECT ANY, DELETE ANY... Connection autorisiert für den kompletten Datenzugriff (DML, DDL) Unerlaubte Zugriffe nicht sichtbar, kein Audit aktiviert Falsches Setup
  29. 29. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.29 Lösung transparentes ILM • Falsche Konzepte erhöhen die Komplexität bzgl. der Zugriffskontrolle erheblich • Keine Autorisierung in der DB, kein garantierter Schutz in der Anwendung • Kein übergreifender Schutz von Daten auch außerhalb der DB Erhöhte und Komplexe Konzepte im Umgang mit Daten generieren eine kaum mögliche Kontrolle. 4. APPS-Database APPS-Schema: APPS-Schema Copy:
  30. 30. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.30 Erhöhte und4. 0101101110101010010100100100001000 1010101101001011010011100001010010 Archive Data 011100001010001011011 101010100101001001000 010001010101101001011 010101001010010010001 30 Hot Data Aktueller Datenbestand Warm Data 1010101011101010011010111000010100 0101101110101010010100100100001000 1010101101001011010011100001010010 0101000010010000100010101011010010 Datenbestand im mittleren Zugriff 1000010100100101001010110111000010 101010101110101001101011100001010001011011 101010100101001001000010001010101101001011 010011100001010010010100001001000010001010 101010101110101001101011100001010001011011 Archivierte Daten 01110101010010 10000100010101 01011100001010 10101010111010100110101 11000010100010110111010 10100101001001000010001 01010110100101101001110 00010100100101000010010 00010001010101110011010 10100101001001000010001 1110010100100101001010110111011010 101010101110101001101011100001011101011001 Automatische Datenoptimierung mit 12c/11g (Information Lifecycle Mgmt.): Transparente Konzepte nutzen, die nicht die Sicherheit und Kontrolle komplexer machen. Eine Table
  31. 31. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.31 Erhöhte und4. 31 Ein Vier-Augenprinzip kann z.B. mit DB Vault erzwungen werden. organisatorisches Vieraugenprinzip ½ PASSWORD xxyyzz ½ PASSWORD ssttuu Procurement Finance Export Datapump Data Unloader 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 CONNECT for export Data Data Loader Approver CONNECT for approvalCONNECT for export Data HR erzwungenes Vieraugenprinzip
  32. 32. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.32 • 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 Erhöhte und Datenschutz für sensible Daten einstellen, gerade dann wenn die Daten die DB verlassen. 4. Datenschutz einstellen?
  33. 33. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.33 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) entsprechend Anforderungen Verfügbarkeitsanforderungen erfüllen und nicht nur vor ungeplanten Ausfallzeiten schützen. 5.
  34. 34. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.34 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 Schwaches oder kein Audit ist unerläßlich, damit man die Kontrolle nicht verliert. Es gibt keine Ausreden! 6. Gesetzliche Anforderungen erfüllt?
  35. 35. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.35 YOUR FUTURE SECURE Hat das einen Nutzen? Warum?
  36. 36. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.36 Source: Darwin Underwriters Insurance: Data Loss Calculator. http://www.tech-404.com/calculator.html Beispiel: 50.000 gestohlene Datensätze Generelle Aussage: Ein Datendiebstahl wird immer hohe Aufwände erzeugen. Kostenrahmen $6,6 - 9,9 Million 50.000 gestohlene Datensätze kosten ein Unternehmen durchschnittlich > 1 Mill. € Interne Analyse Kunden Info Strafen Poneman Institut sagt 88%88% der DatendiebstähleDatendiebstähle entstehen nicht durch Cracker, sondern sind auf NachlässigkeitNachlässigkeit zurückzuführen! Quelle: http://www.computerwoche.de/a/datendiebstahl-kommt-opfer- immer-teurer-zu-stehen,1886090
  37. 37. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.37 Technologie Lösungen Geschäfts- anforderungen Produktivität erhöhen Risiko vermindern Finden Sie Ihren Return on Investment 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 Transpa- renz dadurch bessere Entscheidungen • Vereinfachtes Compliance Reporting • Frühzeitige Erkennung von Bedrohungen durch
  38. 38. gering Hoch Hoch Reactive Tactical Transparent Strategic Enterprise Kosten,Aufwand,Risiko Agilität Legende Maturity Levels Business Drivers: Effizienz, Kosteneinsparung, Architektur, Rationalisierung. • Zentrale Sicht auf Sicherheit und Identifäten, Single source of Truth • Kritscher Datenschutz wird erzwungen • Reaktives Daten und User Manage- ment • Manuelles und Aufwand- intensives Audit • Ineffizient, Overhead, Redundanzen • User Lifecycle Management • Standardi- siertes Schutz- framework • Sicherer Infoaustausch • Real-time Auditing, Alerting und automatische Korrekturen • Nachhaltige und transpa- rente Sicher- heits security Praktiken Unterschied zw. und
  39. 39. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.39 KONTROLLIEREN
  40. 40. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.40 VERHINDERN
  41. 41. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.41
  42. 42. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.42 YOUR FUTURE SECURE
  43. 43. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.43 • 1-Tages-Workshop in Potsdam • Die Top Issues im Bereich DB Sicherheit und wie man diese beseitigt • Am 11.Dezember bei Oracle Potsdam Hands-on Workshop
  44. 44. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.44
  45. 45. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.45 • Eine vollständig dokumentierte Vorgehensweise die Sicherheit der DB zu überprüfen • Vollgestopft mit Best Practices, Tools und vielen Erkenntnissen • Ab Okt. 2013 im Handel erhältlich Werbung in eigener Sache
  46. 46. Copyright © 2013, Oracle and/or its affiliates. All rights reserved.46

×