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

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

YOUR FUTURE
SECURE

AGENDA
15:00

CONTROLCONTROL
GEHT es EIGENTLICH bei der

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

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

The best weapon with which to defend
information is information!
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

SERVICE
Verfügbarkeit
Compliance
Nachhaltig-
keit
Konfiguration
Zugriffs-
kontrolle
Monitoring
Audit
aus vielen
Konzepte sind vorhanden. Aber leider teilweise gar nicht oder falsch implementiert!

• 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

Nichts, was man nicht besser machen kann
1. Kaum Wissen und keine Verantwortungen (AKVs) definiert
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

• 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.

• 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

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

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

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

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.

• 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

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:

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:

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.

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

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
…

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;

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

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.

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:

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

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:

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

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

• 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?

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.

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?

YOUR FUTURE
SECURE
Hat das einen Nutzen?
Warum?

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

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

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

KONTROLLIEREN

VERHINDERN

YOUR FUTURE
SECURE

• 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

• 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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie DOAG SIG Security Vortrag 2013: Wann haben Sie das letzte Mal Ihre Datenbank auf Sicherheit überprüft? (20)

Mehr von Carsten Muetzlitz

Mehr von Carsten Muetzlitz (7)

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