DOAG SIG Security Vortrag 2013: Wann haben Sie das letzte Mal Ihre Datenbank auf Sicherheit...


Wann haben Sie das letzteMal die Sicherheit IhrerDatenbank geprüft?

Carsten Mützlitz (Oracle)


YOUR FUTURESECURE


AGENDA

15:00


CONTROLCONTROL

GEHT es EIGENTLICH bei der


SECURITYINSIDEOUT

RISIKEN sind unter KONTROLLERISIKEN sind unter KONTROLLE

REALITÄT oder WUNSCH?REALITÄT oder WUNSCH?

BEDROHUNGEN VERHINDERNBEDROHUNGEN VERHINDERN


SECURITYBETWEEN SYSTEMS

SECURITYAT EACH LAYER

SECURITYBETWEEN 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 defendinformation is information!


Vorweg II: You even a

Siehe Beispiel Spiegel – Onlinehttp://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örternmit 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

http://www.spiegel.de/netzwelt/web/carna-botnet-internet-zensus-mit-hacker-methoden-a-890225.html


SERVICE

Verfügbarkeit

ComplianceNachhaltig-

keitKonfiguration

Zugriffs-kontrolle

MonitoringAudit

aus vielen

Konzepte sind vorhanden. Aber leider teilweise gar nicht oder falsch implementiert!


• Sichere Konfiguration?

• Verfügbarkeit umgesetzt?

• Überwachung eingestellt?

• Zugriffskontrolleimplementiert?

• Compliance undNachhaltigkeitvorbereitet?

zeigen einen neutralenaber besorgten Blick aufdie

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 nichtdefiniert und Daten seltenklassifiziert

• Kaum Wissen über gesetzlicheAnforderungen

• Kaum wirkliches Wissen über dennotwendigen Schutzbedarf

• Wenig definierte Verantwortung

• Kaum Wissen über neueFunktionen/Konzepte undabgelaufene 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 mitAccounts 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.htm12.1: Keeping your database secure: http://docs.oracle.com/cd/E16655_01/network.121/e17607/guidelines.htm#CHDCEBFA

http://docs.oracle.com/cd/E25054_01/network.1111/e16543/guidelines.htm

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 bedienensind, sollte man im Vorfeld entscheiden,wann gepatched werden muss

http://www.oracle.com/us/support/assurance/leveraging-cpu-wp-164638.pdf



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 übernimmtmeistens 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 PrivilegedUsers

Public DB Links, DB Linksauf 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 Grantsan Public und DB Links

Komplexität beherrscht die Zugriffskontrolle:


Komplexe und kaum3.

• Berechtigungen an Rollen undUser

• keine einheitlichen Konzepteimplementiert

• Entstehung von Redundanzen• Kontrolle in komplexen

Umgebungen sehrunwahrscheinlich

• Keine Rollen, nur direkte Grants= Mehraufwand wenn gleicherZugriff für mehr als ein Usernotwendig

Komplexität beherrscht die Zugriffskontrolle:


Komplexe und kaum3.

• Anwendungsowner und –userwerden nicht korrekt getrennt

• Anwendungsowner bekommenzu viele Berechtigungen

• Keine Kontrolle unerlaubterZugriffe z.B.

- Anwendung oder

- SQL Developer greift zu

• Konzepte werden nichterzwungen

• Zwecktrennung wird nichtbeachtet

• Audit wird nicht eingeschaltet• DBAs sind nicht zuständig

Hochprivilegierte Anwendungsowner:

SchemaSchemaOOwnerwner

SchemaSchemaAPPUSERAPPUSER

RELEASERELEASEManagerManager Install and change

objectsAdmins

EndbenutzerApps-Server

mit DBA Rolemit DBA Role

Falsches Setup

Hat man keinen Ein-fluß dieses Setup zuändern, sollte manfür eigene Setups wieDB Links, Reporting-user etc. Anwend-ungsuser aktivieren,die minimale Rechtebesitzen.


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 DBzu

• DB Links nicht sicherkonfiguriert (MOS Doc ID264872.1 bekannt oder Hinweis imLicense-Guide?)

DB Links:

host10.de

….

host2.de

host1.de

DB

Zugriffe über DBLinks zu entfernten

DBs

Zugriffe über DBLinks zu entfernten

DBsZugriffe von entfernter

DB über denDBLINK-User

Zugriffe von entfernterDB über denDBLINK-User

Teilweise starkePrivilegien. KeineProtokollierung!

Teilweise starkePrivilegien. KeineProtokollierung!

Mit 12c besseres Audit möglich, auch die entfernten DBLink Zugriffe (auch mit 11g) können überwacht werden


Komplexe und kaum3.

• Zu viele ANY Grants(kein Least Privileg Konzept?)

• Zu viele Grants gefährlicherRollen (IMP FULL DB)

• Kein Schutz für gefährlicheRollen (Secure ApplicationRoles) implementiert

• Keine Überwachung derNutzung gefährlicher Privilegien

Gefährliche Privilegien:

DB

Privilege Analysis mit 12c

Create…Drop…Modify…DBA roleAPPADMIN 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.ORAREMOTE_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 seltenpersonalisiert

• Gearbeitet wird stattdessen als„oracle“, SYS und SYSTEM

• Wofür wird SYS und wofürSYSTEM genutzt?

Personalisierung:

SYSSYS

SYSTEMSYSTEM

DBADBANameName Kunden DBA

StandardSYSDBA

StandardDBA

KundeDBA

Standard Oracle DBA

Standard Oracle SYSDBA FalschesSetup


Komplexe und kaum3.

• Keine personalisierten DBAs• DB Links mit vollem Zugriff• Apps-Owner für Anwendung

und Tools wie SQL Developer inGebrauch

• DB-Accounts mit vollem Zugriffauf alle Objekte

• Keine Trennung entsprechendAVKs

• Keine Zwecktrennung imAuditing (FGA)

• Jeder DB User darf alles machen(PUBLIC GRANTS)

Unerlaubte Zugriffe/Zwecktrennung:

APPS-Owner

EndbenutzerApps-Server

APPS-UserEndbenutzerApps-Server

Falsches SetupRichtiges Setup

Hat man keinen Ein-fluß dieses Setup zuändern, sollte manfür eigene Setups wieDB Links, Reporting-user etc. Anwend-ungsuser aktivieren,die minimale Rechtebesitzen.


Komplexe und kaum3.

• Keine Trennung entsprechendAVKs

• Gerade in der Administrationkann jeder DBA alles machen

• DBA Separation of Duty nichtimplementiert

• Keine delegated Administration• Kein einheitliches Account-

Management

Zwecktrennung:


Komplexe und kaum3.

• Autorisierung nur in derAnwendung

• Anwendungssicherheit mussperfekt sein

• Es wird auf denAnwendungsowner mit allseinen 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 SYSTEMAdministratiertdie DB

SharedAdmins

CONNECTAPPS

APPSAPPS

GesicherteLeitung,Zugriff überdieAnwendung

Endusers

Client:Browser oderFat ClientInstallation

ApplicationServer

Berechtigungen:CONNECTRESOURCEUNLIMITED TABLESPACESELECT ANY, DELETE ANY...

Connection autorisiert fürden komplettenDatenzugriff (DML, DDL)

Unerlaubte Zugriffe nichtsichtbar, kein Audit aktiviert

FalschesSetup


Lösung transparentes ILM

• Falsche Konzepte erhöhen dieKomplexität bzgl. derZugriffskontrolle erheblich

• Keine Autorisierung in der DB,kein garantierter Schutz in derAnwendung

• Kein übergreifender Schutz vonDaten auch außerhalb der DB

Erhöhte und

Komplexe Konzepte im Umgang mit Daten generieren eine kaum mögliche Kontrolle.

4.

APPS-DatabaseAPPS-Schema: APPS-Schema Copy:


Erhöhte und4.

0101101110101010010100100100001000

1010101101001011010011100001010010

Archive Data

011100001010001011011101010100101001001000010001010101101001011010101001010010010001

30

Hot Data

Aktueller Datenbestand

Warm Data1010101011101010011010111000010100

0101101110101010010100100100001000

1010101101001011010011100001010010

0101000010010000100010101011010010

Datenbestand immittleren Zugriff

1000010100100101001010110111000010

101010101110101001101011100001010001011011

101010100101001001000010001010101101001011

010011100001010010010100001001000010001010

101010101110101001101011100001010001011011

Archivierte Daten

011101010100101000010001010101011100001010

10101010111010100110101110000101000101101110101010010100100100001000101010110100101101001110000101001001010000100100001000101010111001101010100101001001000010001

1110010100100101001010110111011010

101010101110101001101011100001011101011001

Automatische Datenoptimierung mit 12c/11g (Information Lifecycle Mgmt.):

Transparente Konzepte nutzen, die nicht die Sicherheit und Kontrolle komplexer machen.

EineTable


Erhöhte und4.

31

Ein Vier-Augenprinzip kann z.B. mit DB Vault erzwungen werden.

organisatorischesVieraugenprinzip

½ PASSWORDxxyyzz

½ PASSWORDssttuu

Procurement

Finance

ExportDatapump

Data Unloader

DUAL Connect Check

Rule Set: Dual Connect for Unloaderand Approver

• Rule 1: Check if approver andUnloader is logged in

• Rule 2: Allow Connect for otherusers

• Map Command: Map commandCONNECT to Rule Set

CONNECT for export Data

Data LoaderApprover

CONNECT for approvalCONNECT for export Data

HR

erzwungenesVieraugenprinzip


• Umgang mit sensiblen Daten

• Kein oder wenig Datenschutzeingestellt

• Daten außerhalb der Datenbanknicht geschützt

• Keine Sicherheitszonen definiert

• Keine Überwachung des Zugriffs

• Kontrollverlust, wenn die Datendie DB verlassen

Erhöhte und

Datenschutz für sensible Daten einstellen, gerade dann wenn die Daten die DB verlassen.

4.

Datenschutz einstellen?


Risiken und Anforderungenmüssen bekannt sein, nur dann

kann man sich schützen

• HA Anforderungen nicht immerdefiniert

• Glaube vs. Wissen

• Backup falsch aufgesetzt

• Wenig Schutz vor geplantenAusfallzeiten (Transient logicalStandy, Rolling Upgrades)

entsprechend Anforderungen

Verfügbarkeitsanforderungen erfüllen und nicht nur vor ungeplanten Ausfallzeiten schützen.

5.


Gesetze erfordern eineProtokollierung!

• Trotz gesetzlicher Anforderungen keinAudit eingestellt

• Objektzugriffe, werden nicht oder sehrselten protokolliert

• Wichtige SYS-Objekte werden nichtüberwacht

• Unerlaubte Zugriffe werden nichterkannt

• Keine Überwachung des Zugriffs aufsensible Objekte wie SYS.% undAnwendungsobjekte

Schwaches oder kein

Audit ist unerläßlich, damit man die Kontrolle nicht verliert. Es gibt keine Ausreden!

6.

Gesetzliche Anforderungen erfüllt?


YOUR FUTURESECURE

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

InterneAnalyse

KundenInfo

Strafen

Poneman Institut sagt88%88% der DatendiebstähleDatendiebstähle entstehen nicht

durch Cracker, sondern sind aufNachlässigkeitNachlässigkeit zurückzuführen!

Quelle: http://www.computerwoche.de/a/datendiebstahl-kommt-opfer-immer-teurer-zu-stehen,1886090

http://www.tech-404.com/calculator.html

http://www.computerwoche.de/a/datendiebstahl-kommt-opfer-


TechnologieLösungen

Geschäfts-anforderungen

Produktivitäterhöhen

Risikovermindern

Finden Sie IhrenReturn 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

StrategicEnterprise

Kos

ten,

Auf

wan

d, R

isik

o

Agilität

Legende

MaturityLevels

Business Drivers: Effizienz, Kosteneinsparung, Architektur, Rationalisierung.

• Zentrale Sichtauf SicherheitundIdentifäten,Single sourceof Truth

• KritscherDatenschutzwirderzwungen

• ReaktivesDaten undUser Manage-ment

• Manuelles undAufwand-intensivesAudit

• Ineffizient,Overhead,Redundanzen

• User LifecycleManagement

• Standardi-siertesSchutz-framework

• SichererInfoaustausch

• Real-timeAuditing,Alerting undautomatischeKorrekturen

• Nachhaltigeund transpa-rente Sicher-heits securityPraktiken

Unterschied zw.und


KONTROLLIEREN


VERHINDERN


YOUR FUTURESECURE


• 1-Tages-Workshop in Potsdam

• Die Top Issues im Bereich DBSicherheit und wie man diesebeseitigt

• Am 11.Dezember bei OraclePotsdam

Hands-on Workshop


• Eine vollständig dokumentierteVorgehensweise die Sicherheitder 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...

Technology

Transcript of DOAG SIG Security Vortrag 2013: Wann haben Sie das letzte Mal Ihre Datenbank auf Sicherheit...