doag sig security 2014 in hamburg: enterprise user security for dbas #eus4dbas

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Wie erfülle ich innerhalb einer Stunde Compliance- Anforderungen Carsten Mützlitz

DOAG SIG Security in Hamburg 17.9.2014

DOAG SIG Security in Hamburg 17.9.2014


Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

DOAG SIG Security in Hamburg 3 17.9.2014


“Kaum macht man es richtig, schon funktioniert’s.”

Carsten Mützlitz, Master Principal Sales Consultant, Oracle Germany



Kurze Einführung Schutz von Datenbanken



Einführung in den Schutz von Datenbanken Vorbeugende (preventive) Sicherheit und aufspürende Kontrollen

Sicherheitsworkshop für B.Braun in Melsungen 6 11. Juni 2014


Apps

Users

Advanced Security Data Redaction

Data Masking

Database Vault Privilege Analysis

Database Vault Privileged User Controls

OS & Storage Directories Databases Custom

Audit Data & Event Logs

Database Firewall

Oracle Maximum Security Architecture Core Components

Reports

Alerts

Audit Vault

Policies

Events Advanced Security

TDE



Oracle Maximum Security Architecture

• Audit von sensiblen Aktivitäten

– Standard Audit Policies auf Basis Oracle Database 11g

– Angepasste Policies mit der Oracle Database 12c

• Überwachung von Konfigurationen und verhindern von Änderungen – Überwachung von Konfiguration-Referenzen um Drifts zu vermeiden

– Konfiguration mittels Database Vault, um unautorisierte Änderungen zu verhindern durch interne User

– Alert von DB und Apps Änderungen mittels Audit Vault Alerts

Oracle empfohlene Best Practices



Oracle Maximum Security Architecture

• Oracle Emfehlungen für eine sichere Konfiguration folgen

– Expire and lock Default und nicht genutzte Accounts

– Password Komplexität und Account-Ablauf Policies erzwingen

• Zentralisierte Administration von DB Admin Accounts – Enterprise User Security für DBA Accounts verwenden

– Personalisierte DBA Accounts – keine Shared User verwenden

• Proxy Authentisierung für Verantwortlichkeiten nutzen

– Command line Proxy seit Oracle Database 10g Release 2

– User Proxy Authentisierung für Anwendungszugriffe

Oracle empfohlene Best Practices



Gesetze, Regularien, externe Einflüße Compliance



Es geht immer um mögliche Grundbedrohungen ...

Corporate Network

INTERNET

Corporate Network

Mobile Computing

Teleworking

Verlust der Integrität

- Verarbeitungs-, Übertragungs- und Speicherfehler

- Manipulation von Daten z. B. durch spoofing attacks:

o ip spoofing (IP fälschen)

o DNS spoofing

o Web spoofing (Webseiten fälschen)

Verlust der Vertraulichkeit

- Netzverkehr abhören (sniffer attacks)

- „Knacken“ kryptographischer Schlüssel und Verfahren (code breaking/key recovery)

- Angriffe auf Kennwörter (password guessing/ cracking)

- Falsche Rechte-Konzept

Verlust der Verfügbarkeit

- Ausfall

- Zerstörung

- Unterbrechung von Diensten (denial of service) durch:

oping of death

o ICMP attacks

oSYN flooding, etc.

Verlust der Verbindlichkeit

- Rechtsverbindlichkeit elektronisch abgeschlossener Verträge, wie z.B. Fax, EMail

- Electronic Commerce

- Gesetzesauflagen

- Risiko-Früherkennung

- Authentizitätscheck (Who)

Schlagwörter, die als Bedrohung eingestuft werden, sind: • Hacker, Fremdpersonal,

eigenes Personal, • Fehler, Ausfälle, • Fernwartung und • Wirtschaftsspionage • u.v.m.

Sicherheitsworkshop für B.Braun in Melsungen 11. Juni 2014


Welchen externen Einflüßen sind wir ausgesetzt? Compliance, Regularien, Gesetze, Business Anforderungen etc.


Unternehmens-Organisation

Basel II, Solvency II, KontraG, AktG, HGB,

BilReG

Branchen- oder Größenspezifisch

WpHG, BAFin, FdA, GMP, MARisk, EU-

Vermittlerrichtlinie

Datensicherheit & Datenschutz

§3, §9, §11 ff. BDSG

Rechtsgrundlagen

Landesspezifische Gesetze

8.-EU-Richtlinie, SOX, APAG

Arbeitsrecht BetrVG: §§80 (1+2),

§87(6), BildschirmarbV

Rechnungslegung, Buchführung, Archivierung,

Prüfung GoBS, GoB, HGB, GDPdU,

IDW PS, Email-Archivierungsvorschr.

§

§

Compliance Bedrohungen


Motivationslage der Unternehmungen Rechtliche Vorgaben und Entscheidungsspielräume


Rechtliche Vorgaben für IT-Sicherheit durch...

Entscheidungsspielräume

Verträge Gesetze Haftungs-

risiken

Eigen-interesse

Von Ihnen verlangte IT-Sicherheit

Von Ihnen gewollte IT-Sicherheit


Landesdatenschutzgesetz und Datenschutzverordnung Wir betrachten mal nur einen kleinen Ausschnitt

14

17.9.2014

Auschnitt LDSG §6 Abs. 2....

... Für eine ordnungsgemäße Datenverarbeitung nach aktuellem Stand der Technik ist es zwingend notwendig, dass die administrativen Tätigkeiten nachvollziehbar sind. Das LDSG und die DSVO stellen hierfür konkrete Anforderungen. Bei jeder administrativen Tätigkeit muss stets der Ausführende ermittelt werden können ...

...Ermittlung von Risikofaktoren für den Missbrauch der Daten (bei sensibler Datenverarbeitung nach § 11 Abs. 3 LDSG Risikoanalyse als VS-nfd) unter Berücksichtigung der Schutzbedürftigkeit der Daten (§ 5 Abs. 1 u. 2 LDSG)...

DOAG SIG Security in Hamburg


Was wäre die Lösung? Also, DBAs sichtbar machen, weil welches Risiko besteht?


Wer?

DBA

Welches Risiko und welchen

Schutzbedarf leitet sich daraus ab?

Alle DBAs werden in allen (wichtigen) Datenbanken personalisiert.


Komplexitätsberechung einer typischen Umgebung Komplexität bedeutet auch Verlust der Kontrolle


ComplexDBAMGMT = Count(DBAs) x Count (DB Instances)

Zur Erinnerung: Das LDSG und die DSVO stellen hierfür konkrete Anforderungen. Bei jeder administrativen Tätigkeit muss stets der Ausführende ermittelt werden können. Auch Oracle empfiehlt den Einsatz von personalisierten DBAs. SYS wird nur in Ausnahmenfällen genutzt und SYSTEM wird gesperrt. Hinzu kommt, dass bestimmte Zertifizierungen (wie z.B. BSI) eine regelmäßige Änderung der Passwörter fordert.

Gegeben (Ist-Situation):

Eine Unternehmung betreibt 100 Datenbanken inkl. Entwicklung, Test, Integration und Abnahme DBs. Diese Datenbanken werden von 10 DBAs betreut. Jeder DBA ist in jeder DB lokal angelegt. Zusätzlich zu den Datenbanken besteht ein zentrales Benutzerrepository (MS Active Directory)

10 DBAs x 100 DB Instances ComplexDBAMGMT =

1000 ComplexDBAMGMT =

Die Komplexitätszahl 1000 sagt nun aus, dass insgesamt 1000 Accounts für 10 DBAs zu betrachten sind.


Also, wie sieht die Realität aus? Personalisierung ist zu komplex


Anonym!

DBA SYS oder SYSTEM

Wegen der Komplexität werden wichtige Maßnahmen nicht implementiert!

Wesentliche Maßnahmen für einen sicheren Datenbank-Betrieb werden nicht implementiert 1. Regelmäßiges Ändern von

Kennwörtern 2. Keine Zwecktrennung 3. Keine personalisierten DBAs, alle

DBAs arbeiten mit SYS und SYSTEM.

4. Etc.


Komplexität auflösen Die genannten Compliance Anforderungen implementieren wir nun mit minimalem Aufwand und maximalen positiven Benefits



Eine einfache Zentralisierung der Benutzer fasst Oracle unter dem Begriff „Enterprise User Security“ zusammen Enterprise User Security für DBAs (#EUS4DBAs)


Typisches Kunden-Szenario

DB1

DB4

User1 DB2

DB3

DB5

User2

User4

User3

• DBA1, Kennwort, Rollen • DBA2, Kennwort, Rollen • DBA3 Kennwort, Rollen • DBA4 Kennwort, Rollen

Viele Datenbanken mit jeweils lokaler Benutzerverwaltung

DB1 DB4 DB2 DB3 DB5

Zentrale Benutzerverwaltung für DBs

Benutzer gehören ins LDAP

DBA1-4

Das Ziel für die DBAs in der

Nutzung einer zentralen

Benutzerverwaltung:

1. Kennwörter raus aus der DB

und zentralisiertes PW-

Management,

2. Rollen ins LDAP Repository,

d.h. Autorisierung über LDAP

Abfragen

3. Single-Sign-on (starke

Authentisierung mittels

Kerberos),

4. Zwecktrennung

(DBA=Berechtigung in der DB,

MS AD Admin=Account

Management)

• DBA1, Kennwort, Rollen




• Globale Rollen

• Globale Schema





Komplexität wäre somit aufgelöst, richtig?


EUS über OUD mit MS AD und Kerberos Vorhandenes Benutzerrepository nutzen


Windows Client Windows Client

Ethernet

orcl

db.de.oracle.com ad.de.oracle.com

ACTIVE DIRECTORY

oud.de.oracle.com

Ablauf:

1. Authentisierung an die Datenbank via Kerberos

2. DB verifiziert via Kerberos TGT

3. Datenbank fordert Benutzereintrag beim LDAP an

4. LDAP liefert den Benutzereintrag an die Datenbank zurück und fragt hierzu MS AD

5. Datenbank fordert Schemamapping und Enterprise Role an

6. LDAP liefert Schemamapping und Enterprise Role an die Datenbank zurück

7. DB autorisiert Nutzer mit der richtigen Berechtigung (Rolle)

(2) Zugriff mit Desktop Client unter Benutzung TGT

EUS-LDAP Operationen

(1) Benutzer bekomt Kerberos TGT (Ticket Granting Ticket)

OUD-Proxy

EUS-Deployment: OUD und MS AD Integration

• EUS wird mit Oracle Unified Directory aufgesetzt

• Bestehendes MS AD wird via OUD-Proxy integriert – Benutzer aus MS AD werden im OUD virtuell sichtbar gemacht

• Authentisierung via Kerberos – Benutzer authentisiert sich nur am Windows Desktop (SSO)

Unified Directory


Vorgehen dieser Lösung ist für meine Umgebung sehr trival Kaum macht es richtig, schon funktioniert es


1 Download 4 SW-Komponenten (OUD, WLS, ADF, Java, (Patch))

2 Installation SW Komponenten

3 OUD-Proxy aufsetzen mit Anbindung an MS AD

4 Kerberos für die Datenbank aktivieren

5 EUS auf dem DB Server aktivieren und Mapping des AD<->DB

Detaillierte Beschreibung: http://cmuetzli.blogspot.co.uk/2014/08/oracle-db-security-enterprise-user.html

http://cmuetzli.blogspot.co.uk/2014/08/oracle-db-security-enterprise-user.html










1 Stunde Installation und Konfiguration für EUS4DBAs Leider nicht live, aber dafür in Farbe


• Installation Software Komponenten (Bring up OUD)

– OUD 11gR2

– WLS 11g (10.3.6)

– ADF 11g

– Create ODSM Domain

– Neuer Bundle Patch OUD

– Create OUD-Proxy

– MS AD Einstellungen übernehmen

• Konfiguration Kerberos und EUS (DB anpassen)

– SPN in MS AD einstellen

– Keytab erstellen

– Auf DB krb5 Config Dateien erstellen

– Sqlnet.ora anpassen

– Global Schema und Rolle erstellen

– Mapping in OEM LDAP <->DB

37 Minuten 18 Minuten


37 Minuten Installation – Aufbau OUD



18 Minuten Kerberos und EUS Setup – Anpassung DB



ORA DB

ORA DB

Zusammenfassung: Mehrwerte, Sinn und Zweck Warum das Ganze? Echter Kundenfall


Zentraler Userstore

ACTIVE DIRECTORY

Oracle Unified Directory ORA DB

ORA DB

• 15 DBAs • 300 Oracle DB Instanzen

– D.h. 4500 personalisierte DBA Accounts in den DBs (mehrfach redundant)

– 300 PW Policies – Tausende Passwords (Resets) – Tausende Users – Viele hundert Autorisierungsregeln Sehr hoher Aufwand!

• Plus alle anderen Poweruser Benutzergruppen

Kerberos (starke Authentisierung)

DBA1

DBA1

Redundante Benutzer und PW-verwaltung Redundante Benutzerverwaltung, zentrales PW EUS4DBAs: Eine Benutzerwaltung mit allen Policies, keine PWs, User und Policies in der DB

lesend

OUD-Proxy

EUS: DB LDAP enabled

LDAP<->DB

EUS4DBAs: Eine Benutzerwaltung mit allen Policies, keine PWs, User und Policies in der DB und Zwecktrennung

Zwecktrennung Account Management

MS AD ADMIN DB Roles

Autorisierung

• User • Gruppen • Policies

doag sig security 2014 in hamburg: enterprise user security for dbas #eus4dbas

Software

oracle andor

sole discretion of oracle

datenbankendoag sig

konfigurationen und

gangepasste policies

g release

email archivierungsvorschr

kaum macht man es richtig