Vorwort „Oracle Security in der Praxis“

Vorwort
zu
„Oracle Security in der Praxis“
von Carsten Mützlitz
ISBN (Buch): 978-3-446-43869-9
ISBN (E-Book): 978-3-446-43923-8
Weitere Informationen und Bestellungen unter
http://www.hanser-fachbuch.de/978-3-446-43869-9
sowie im Buchhandel
© Carl Hanser Verlag München
1
Vorbemerkung
Bevor ich gemeinsam mit Ihnen in die Details gehe und Ihnen zeige, wie man die Sicherheit
einer Oracle-Datenbank überprüft, möchte ich ein persönliches Anliegen vorwegnehmen.
Wir alle sitzen im gleichen Boot, wenn es um unsere Daten geht. Ob wir nun Bäcker, Maler,
Angestellte, Datenschutzbeauftragte, Vorstände, normaler Bürger oder Datenbank-Administratoren (DBAs) sind. Wir alle sind davon betroffen, dass unsere Daten in irgendeiner Datenbank eines Unternehmens oder einer Behörde gespeichert sind. Sobald wir einen Vertrag
mit einer Firma/Versicherung/Bank abschließen oder einen Kauf im Internet tätigen,
­können wir davon ausgehen, dass unsere Daten in einer Datenbank gespeichert werden.
Das ist eine Tatsache und betrifft uns alle, die wir Verträge und Geschäfte mit Dritten
abschließen.
Glücklicherweise haben wir in Deutschland und der Europäischen Union (EU) Gesetze wie
das Landesdatenschutzgesetz und das Bundesdatenschutzgesetz sowie einige Richtlinien,
die vorschreiben, wie der Schutz personenbezogener Daten einzuhalten ist. Diese Gesetze
sind kein Wunschkonzert, sondern müssen durch die Betreiber von Datenspeichern und
Anwendungen umgesetzt werden. Für die IT-Abteilungen bedeutet das, Maßnahmen zu
implementieren, um die Gesetze zu erfüllen und dadurch den bestmöglichen Datenschutz
für unsere Daten zu gewährleisten. Ziel dieser Gesetze ist es, unsere Daten zu schützen. Das
sollte jedem Verantwortlichen klar sein. So weit, so gut, aber warum erfährt man so oft aus
der Presse, dass Daten gestohlen werden? Sind unsere Gesetze nicht gut oder die definierten Maßnahmen schlecht?
Meiner Meinung nach sind nicht die Gesetze in Frage zu stellen. Mittlerweile definieren
diese Gesetze relativ gute Maßnahmen. Eher bin ich der Meinung, dass teilweise das fehlende Wissen und die Ignoranz einiger Menschen diese Vorfälle möglich machten. In den
vielen Sicherheitsüberprüfungen von Datenbanken, die ich in den letzten 15 Jahren durchgeführt habe, ist mir immer wieder eines aufgefallen: „Unsere Daten könnten sehr viel besser
geschützt sein. Anforderungen und Maßnahmen aus den Gesetzen sind teilweise nicht implementiert oder durch ungeeignete Konzepte ausgehebelt.“ Es gibt viele Gründe für diese Aussage, doch der wichtigste Grund ist, dass der konsequente Blick auf die Sicherheit und den
Datenschutz fehlt. Die Konzepte existieren. Gerade eine Oracle-Datenbank kann out-of-thebox alle Gesetzesanforderungen sofort realisieren. Aber leider werden die Konzepte nicht
konsequent oder gar nicht umgesetzt.
2 1 Vorbemerkung
Dieser Zustand macht mich sehr traurig und gleichzeitig betroffen, denn wie gesagt, es geht
um unsere und somit auch um meine Daten. Das sollte sich jeder Datenbank-Administrator
und Sicherheitsverantwortliche in den IT-Abteilungen bewusst machen.
Mit diesem Buch möchte ich erreichen, dass Ihre Daten besser geschützt werden, d. h., Sie
werden viele Hinweise erhalten, wie man eine optimale Sicherheit einstellt. Die OracleDatenbank hat einen ungefähren Marktanteil von 50 %, d. h., jede zweite Datenbank, in der
unsere Daten gespeichert werden, könnte eine Oracle-Datenbank sein. Somit möchte ich
mit diesem Buch erreichen, dass zumindest jede zweite Datenbank in naher Zukunft eine
erhöhte Sicherheit und Datenschutz implementiert und somit unsere Daten besser ge­­
schützt sind.
In diesem Buch finden Sie Konzepte und praktische Beispiele, die ich in den letzten Jahren
entwickelt habe bzw. normale Empfehlungen als Oracle-Best-Practices darstellen. Diese
Konzepte sind teilweise unabhängig von der Datenbankversion und auch dem jeweiligen
Hersteller. Meinen Fokus in diesem Buch lege ich auf die Oracle-Datenbank in den Ver­
sionen 12c und 11g. Vieles funktioniert aber auch noch mit der Version 10g. Zusätzlich
sollten Sie wissen, dass Sie in diesem Buch keine detaillierten Ausführungen zu altbekannten Konzepten finden werden. Ich möchte mich nicht zum tausendsten Male wiederholen,
sondern setze voraus, dass Sie als Leser gewisse Grundkenntnisse im Umgang mit Oracle
Datenbanken besitzen. Wenn nicht, finden Sie in der Oracle-Onlinedokumentation (siehe
http://docs.oracle.com) genügend Lesestoff, um sich fehlende Grundkenntnisse anzueignen. Geschriebene Worte sind schnell veraltet, daher sind in diesem Buch die aktuellen
Links aus der Oracle-Onlinedokumentation zur weiteren Vertiefung eingearbeitet.
Der Aufbau dieses Buchs ist sehr einfach gehalten. Als Erstes führe ich Sie in die Grundbedrohungen und Grundlagen der Datenbanksicherheit ein. Anschließend an diese Ausführungen beschreibe ich wichtige Lösungen, sogenannte Best Practices, für einen Standardbetrieb mit erhöhtem Schutz. In diesem Abschnitt finden Sie auch die herausragenden neuen
Konzepte für die 12c-Oracle-Datenbank beschrieben. Im dritten Abschnitt des Buchs zeige
ich Ihnen detailliert, welche Informationen von einer Oracle-Datenbank benötigt werden,
um eine Aussage zu dem Datenbank-Sicherheitszustand machen zu können. Zusätzlich
erfahren Sie, welche Erkenntnisse man gewinnen kann und welche Lösungen abgeleitet
werden können. Darüber hinaus nehme ich eine Bewertung vor, die den Sicherheitszustand
der Datenbank nach CVSS1 bewertet. Und schließlich erfahren Sie, wie man die Tools ausführt, die zu einer Überprüfung der Sicherheit genutzt werden können. Die Tools ermög­
lichen es Ihnen, die Überprüfungen automatisiert auszuführen, und führen zu einem
schnellen Ergebnis (siehe Hanser-Download-Bereich).
Danach sind Sie in der Lage, den Zustand Ihrer Datenbanken selbst zu bewerten und das
Risiko kompakt an die verantwortliche Person in Ihrer Unternehmung zu melden, die dafür
verantwortlich ist, Maßnahmen einzuleiten.
Das Ziel ist erreicht, wenn alle Oracle-Datenbanken, in denen personenbezogene oder
andere sensible Daten gespeichert sind, einen erhöhten und gesetzeskonformen Datenschutz implementiert haben, sowie Prozesse aufweisen, die den guten Zustand der Datenbank erhalten.
1
CVSS: Common Vulnerability Scoring System siehe http://www.first.org/cvss oder die Oracle-Erklärung zur
Risikomatrix: http://www.oracle.com/technetwork/topics/security/cvssscoringsystem-091884.html
1 Vorbemerkung 3
Installierte Security-Technologien! Was ist mit der Datenbanksicherheit?
Ist der Ort der unternehmenskritischen Datenablage angemessen geschützt?
Schützenswerte
Daten
Schutzbedarf und Risiko
bestimmen
Maßnahmen implementieren
und Sicherheitszonen aktivieren
Kennen Sie die Art der zu speichernden Daten, bestimmen Sie den notwendigen Schutzbedarf
und implementieren Sie Maßnahmen, um das vorhandene Risiko abzuschwächen.
Bild 1 .1 ■Datenbanksicherheit entsprechend dem Schutzbedarf einstellen
Bild 1.1
Bereits im Vorwort muss ich erwähnen, wie begeistert ich von der neuen Oracle-Datenbankversion 12c bin. Ich arbeite mit Oracle-Datenbanken seit der Version 6. Somit sind OracleDatenbanken seit über 20 Jahren ein wesentlicher Bestandteil meiner Beratertätigkeit. Es
gibt wohl derzeit keine vergleichbare Datenbank am Markt, die aktuell über so hervorragende Sicherheitsfeatures und nutzbringende Konzepte verfügt wie die Oracle-Datenbank
12c. Es ist eine komplette Gewaltenteilung implementiert, die Netzwerkverschlüsselung
und auch die starke Authentisierung (Kerberos, SSL, RADIUS) kann mit jeder Datenbankedition genutzt werden. Außerdem vorhanden sind eine hervorragende Mandantenfähigkeit (Oracle Multitenant) gerade mit den Pluggable Databases sowie viele zusätzliche Features, die die Sicherheit, Zuverlässigkeit und Verfügbarkeit abrunden und damit erheblich
erhöhen, aber auch vereinfachen.
Trotz der vielen eindrucksvollen Funktionen und Konzepte einer Oracle-Datenbank ist es
immer wichtig, diese korrekt anzuwenden und über das Wissen zu verfügen, was geht und
was geht nicht. Oder sagen wir mal, was geht anders und besser. Und genau darum geht es
in diesem Buch.
Ich möchte gerne mit den Worten eines bekannten Hackers die nächsten Kapitel einleiten:
„You don’t need even a basic skill level to get in.“2 Damit meinte Kevin Poulsen 1998, dass man
kein Experte sein muss, um unerlaubten Zugriff auf Systeme zu erlangen. Diese Weisheit ist
richtig, umso wichtiger ist es für die Administratoren, die Kontrolle über ihre Systeme zu
behalten. Und hierfür ist die beste Maßnahme, wie Stephen Cobb bereits richtig formulierte:
„The best weapon with which to defend information is information.“3 Damit meinte Stephen
Cobb, dass man sich mit Wissen schützen kann.
2
3
Kevin Poulsen, Internet Week, 23. März 1998
Stephen Cobb, The NCSA Guide to PC and LAN Security, 1996
Ein scharsinniger Kunde sagte einmal zu mir: „Kaum macht man es richtig, schon funktioniert es!“ In diesem Sinne viel Freude mit den nachfolgenden Seiten und den mitgelieferten
Tools, die Sie unter dieser URL finden:
http://downloads.hanser.de
4 1 Vorbemerkung
Leseprobe
zu
„Oracle Security in der Praxis“
von Carsten Mützlitz
ISBN (Buch): 978-3-446-43869-9
ISBN (E-Book): 978-3-446-43923-8
Weitere Informationen und Bestellungen unter
http://www.hanser-fachbuch.de/978-3-446-43869-9
sowie im Buchhandel
© Carl Hanser Verlag München
5
Sicherheit einer OracleDatenbank prüfen
Die Einführung in die Best Practices und die neuen 12c-Features führt uns jetzt zum Hauptthema: die Sicherheitsüberprüfung einer Oracle-Datenbank.
Jede Datenbankuntersuchung konzentriert sich auf drei wesentliche Grundbedrohungen:
Verlust der Integrität, Verlust der Vertraulichkeit sowie Verlust der Verfügbarkeit. Diese
drei Verlustarten nutzt auch das standardisierte Bewertungssystem für Schwachstellen,
kurz CVSS1 (Common Vulnerability Scoring System), zur Bewertung eben dieser Schwachstellen. Und auch Oracle nutzt diese Grundbedrohungen und Verlustarten, um in den Risikomatrizes2, bekannt aus den Oracle-Veröffentlichungen zu Security Alerts und kritischen
Patches (siehe http://www.oracle.com/technetwork/topics/security/alerts-086861.html), die
Auswirkungen auf die Systeme klarzustellen.
Innerhalb dieser Grundbedrohungen werden in meiner Datenbanküberprüfung fünf
wesentliche Kategorien untersucht, die zusammen ein Bild über den Sicherheitszustand
einer Datenbank ergeben. Diese Kategorien sind allgemeingültig und gelten auch für andere
Datenbankhersteller.
ƒƒ Konfiguration der Datenbank:
Ist die Datenbank sicherheitstechnisch optimal konfiguriert?
ƒƒ Überwachung der Datenbank:
Wurden wesentliche Policies aktiviert, um die wichtigen Datenbankaktivitäten zu protokollieren? Sind die Objekte mit den unternehmenskritischen Daten in die Überwachung
eingebunden? Existiert ein Reporting für die einfache Auswertung der Protokolle bzw.
Tools zur Verbesserung der Nachhaltigkeit?
ƒƒ Verfügbarkeit der Datenbank:
Reicht das Setup aus, um die Datenbank vor dem geforderten Verlust der Verfügbarkeit zu
schützen? Wenn beispielsweise ein Datenverlust von maximal 30 Minuten gefordert ist,
kann diese Anforderung erfüllt werden?
Erklärung und Beschreibung: http://www.first.org/cvss; Kalkulator für Datenbankschwachstellen nach CVSS:
http://www.security-database.com/cvss.php
2
Beispiel: Critical Patch Update (CPU) April 2013, http://www.oracle.com/technetwork/topics/security/
cpuapr2013-1899555.html und nach unten blättern, bis die Risikomatrizes erscheinen.
1
122 5 Sicherheit einer Oracle-Datenbank prüfen
Konfiguration
Compliance,
Policies und
Nachhaltigkeit
Zugriffskontrolle
Überwachung
Verfügbarkeit
Bild 5 .1 ■Untersuchte Kategorien
ƒ Zugriffskontrolle der Datenbank:
Bild 5.1
Wer greift auf meine Datenbank zu und welche Konzepte sind implementiert, die eine
Policy durchsetzen nach dem Prinzip „Jeder bekommt die Rechte, die er benötigt, nicht
mehr und nicht weniger (Least Privilege)“?
ƒ Compliance/Nachhaltigkeit der Datenbank:
Die Datenbank muss als wesentlicher Teil einer Anwendung auch in die Betrachtung der
Compliance-Anforderungen einbezogen werden. Hier wird untersucht, ob wesentliche
nachhaltige Konzepte implementiert wurden. Es geht im Wesentlichen um Transparenz
und Kontrolle. Zusätzlich wird die Erfüllung externer Einflüsse wie Gesetze geprüft.
Auf Basis der Auffälligkeiten, die in diesen Kategorien gefunden werden, lässt sich sehr gut
der Sicherheitszustand der Datenbank in Bezug auf den Schutzbedarf bestimmen. Welche
Untersuchungen in den einzelnen Kategorien sinnvoll sind, wird in den nachfolgenden
Abschnitten detailliert beschrieben.
Die nachfolgenden Abfragen und Untersuchungen selektieren Informationen aus der Datenbank. Deshalb ist es auch wichtig, parallel zu den Untersuchungen in der Datenbank ein
Interview durchzuführen, welches das komplette Bild, in dem die Datenbank eingebettet ist,
vervollständigt. Ziel ist es, sich mit dem System vertraut zu machen und dessen Zweck,
externe Einflüsse sowie Architektur zu kennen. Ein Datenbankbetreiber, der sich mit seinem System auskennt, braucht lediglich die nachfolgenden Skripts (siehe Abschnitt 5.7)
auszuführen. Alles Weitere, beispielsweise welche Prozesse außerhalb der Datenbank existieren, sollte bekannt sein. Für jene Leser dieses Buchs, die die zu untersuchende Datenbank nicht kennen, habe ich ein paar Fragen, die helfen sollen, das Bild der Datenbank zu
vervollständigen, als Beispiel in den Anhang übernommen.
5.1 Datenbankkonfiguration 123
Nutzen Sie das Buch als Nachschlagewerk für die einzelnen Untersuchungen,
die für die Überprüfung des Sicherheitszustands einer Oracle-Datenbank be­
nötigt werden. Alle aufgezeigten SQL-Abfragen und Skripts finden Sie im Download-Bereich vom Hanser Verlag http://downloads.hanser.de/. Es sind Skripts
vorbereitet, die Daten automatisch aus den Datenbanken lesen. Die einzige zu
erledigende Aufgabe nach der Ausführung ist die korrekte Interpretation der
Daten in den generierten Log-Dateien.
Nachfolgend finden Sie die einzelnen Abfragen in den einzelnen Kategorien. Ich werde die
einzelnen Abfragen genau erklären und meine Erkenntnisse und weiterführende Fragen
aufzeigen.
Mit der neuen Version 12 c der Oracle-Datenbank hat sich die Architektur der Datenbank
verändert. Es gibt nun sogenannte Container. Ich gehe mal davon aus, dass nach der Ver­
öffentlichung der Version 12c erst mal nur Non-CDB-Datenbanken existieren, die von Version 11g auf Version 12c umgezogen sind oder sogar migriert wurden. Für solche Datenbanken werden die nachfolgenden Abfragen (bzw. das Tool aus dem Download-Bereich) einmal
gegen die Datenbank ausgeführt, gleichgültig, um welche Version der Datenbank (10g, 11g,
12c) es sich handelt.
Existieren in der 12c-Datenbank bereits verschiedene Container (also CDB und PDBs), muss
der Security Check gegen alle Container-Datenbanken ausgeführt werden. Die Trennung
zwischen dem Root-Container und den pluggable Datenbanken der Anwendungen sollte
dann ersichtlich sein. Eine 12c-Datenbank mit einem Root und zwei PDBs muss den Security Check also drei Mal ausführen, so dass jeder Container untersucht wird.
Es gibt Abfragen für Datenbanken der Versionen 10g, 11g und 12c. Alle diese
Datenbanken befinden sich derzeit im aktiven Betrieb. Natürlich gibt es auch
ältere Versionen, die sich im Einsatz befinden, doch das sollten nur noch ganz
wenige sein.
■■5.1 Datenbankkonfiguration
Als erster Untersuchungsbaustein wird die Konfiguration der Datenbank überprüft. Insbesondere werden die SQL*Net-Konfiguration, der Aufbau der Datenbank (Datenbankdateien,
init.ora, Umgebung etc.), das Patching und die Prüfung vorhandener Konzepte untersucht.
Hier sind verschiedene Abfragen notwendig, die in den nachfolgenden Abschnitten vorgestellt werden.
124 5 Sicherheit einer Oracle-Datenbank prüfen
5.1.1 Abfrage 1001: erste Datenbankinformationen
Die nachfolgende Abfrage liefert Informationen über die Oracle-SID, das Erstelldatum,
Archive LOG, den Flashback und die Standby-Datenbank.
Für 12c wird zusätzlich die Spalte CON_ID angezeigt. Diese Spalte ist in der Abfrage auskommentiert.
Listing 5.1 ABFRAGE 1001 (10g, 11g, 12c)
set heading on echo off feedback off verify off underline on timing off;
set linesize 400
prompt
prompt --1001
prompt Database Information
prompt =============================
column name format a8
column log_mode format a12
column platform_name format a30
column guard_status format a10 heading Guard|Status
column flashback_on format a9 heading flashbank|on
column controlfile_type format a11 heading controlfile|type
column open_mode format a11 heading open|Mode
column protection_mode format a11 heading protect|mode
column database_role format a11 heading DB|role
column switchover_status format a11 heading switch|Status
column force_logging format a11 heading Force|logging
select name,
created,
log_mode,
platform_name,
guard_status,
flashback_on,
controlfile_type,
open_mode,
protection_mode,
database_role,
switchover_status,
force_logging
from v$database;
column name clear
column log_mode clear
column platform_name clear
column guard_status clear
column flashback_on clear
column controlfile_type clear
column open_mode clear
column protection_mode clear
column database_role clear
column switchover_status clear
column force_logging clear
Ein typisches Ergebnis würde sich wie folgt darstellen:
5.1 Datenbankkonfiguration 125
Listing 5.2 Ergebnis 1001:
--1001
Database Information
=============================
Guard flaank
NAME CREATED LOG_MODE PLATFORM_NAME Status bank on
---- --------- ---------- ------------- ------ -------ORCL 30-OCT-09 NOARCHIVE Linux IA
NONE NO
LOG
(32-bit)
contrile open protect
filetype Mode mode
--------- ----- ------CURRENT READ MAXIMUM
WRITE PERFORMANCE
DB
role
------PRIMARY
switch
Status
-------NOT
ALLOWED
Erkenntnis
Die Datenbank wurde am 30.10.2009 erstellt und hat die SID=ORCL. Sie wird
auf einem Linux-System betrieben, verfügt über keine Standby-Datenbank­
anbindung und eine Flashback-Datenbank ist nicht aktiviert. Des Weiteren
­werden keine Archive Logs geschrieben. Es sind keine Funktionen für eine bessere Verfügbarkeit und auch kein Schutz gegen menschliche Fehler vorhanden
(Flashback-Datenbank).
Weiterführende Fragen:
ƒƒ Wie schützt man sich vor menschlichen Fehlern (z. B. truncate Table (also ein
Entleeren des Tabelleninhalts ohne die Möglichkeit eines Rollback) ohne
Flashback-Datenbank?
ƒƒ Ist eventuell doch eine Standby-Datenbank notwendig aufgrund von Hardware- oder Performance-Anforderungen (z. B. Auslagern des Reportings oder
Backups auf die Standby-Datenbank)?
ƒƒ Ohne Archive Logs ist ein schnelles Recovery nicht möglich und ein Daten­
verlust abhängig von der Backup Methode sehr wahrscheinlich, ist das so
gewollt?
5.1.2 Abfrage 1001.1: Datenbankinformationen zu 12c (Container)
Die nachfolgende Abfrage zeigt erste Informationen zu den Containern in einer 12c-Datenbank. Oracle unterscheidet in der Version 12c prinzipiell zwischen drei Arten von Datenbanken:
ƒƒ NON-CDB
Das sind die Datenbanken, also die Single-Instanzen, die wir bis zu der 11g-Datenbankversion kennen. Mit der 12c nennen wir diese Instanzen Non-CDB.
ƒƒ CDB
Das ist die Container-Datenbank, also das ROOT.
ƒƒ PDB
Pluggable Datenbank, die in einem Container ROOT angelegt ist.
Force
logging
------NO
Stichwortverzeichnis
zu
„Oracle Security in der Praxis“
von Carsten Mützlitz
ISBN (Buch): 978-3-446-43869-9
ISBN (E-Book): 978-3-446-43923-8
Weitere Informationen und Bestellungen unter
http://www.hanser-fachbuch.de/978-3-446-43869-9
sowie im Buchhandel
© Carl Hanser Verlag München
Index
A
Abwärtskompatibilität 138
Access Control 206
Access Control List der Network Packages 380
Accounts 321
Account-Management 114, 264, 323, 344, 360
Account-Management-Privilegien 362
Account-Manager 67, 347
Active Data Guard 302
Admin-Option 346
Advanced Security Option (ASO) 38, 61, 102, 105, 136,
407, 412
AES256 413
AFTER LOGON-Trigger 55
Alerts 317
Alert.log 319
ALTER SESSION 49, 362
Anonymisierung 59
Anwendungsowner 53, 57, 67, 272, 354
Anwendungsrollen 342
Anwendungs-User 53
ANY-Privilegien 354 f.
APEX (Oracle Application Express) 207, 210, 452
– embedded Gateway 210
Application-Owners 263
Archivierungssysteme 106
ASM 306
Attestierung 73, 354
Attestierungsprozesse 356
Audit 23, 69, 78, 87, 93, 279 ff., 427
AUDIT_ADMIN 89
Audit-Daten 88
Audit-Konzept 89, 94
Audit Policy 92, 227, 232, 237
AUDIT-Privilegien 332
Audit-Trail 221
AUDIT_VIEWER 89
Audit Warehouse 70
Aufgaben, Kompetenzen und Verantworlichkeiten (AKV)
66
Ausfallszenarien 283
Auswertung des Listener-Log 453
Authentisierung 23, 26
AUTHID CURRENT_USER 47
Automatic Storage Management (ASM) 306 f.
Automatische Datenoptimiertung (ADO) 118
automatisierte Provisionierung 475
Autorisierung 23
Availability (Verfügbarkeit) 75
B
Backdoors 267
Backups 300
Backup-Konzept 298, 300
Backup & Recovery 284
Batchdatei 442
BDSG 68
Bedrohungs- und Risikoanalysen 12
Beispieluser 390
Benutzergruppe 80, 184, 263, 330, 476
Benutzerverwaltungen 33
Berechtigungen 321
– für wichtige Datenbankobjekte 390
Berechtigungskonzept 46, 71, 99
Betriebssystemgruppen 95
Bewertungen nach CVSS 467
Bewertungskriterien 461
Bruteforce 42, 249
Bundesamt für Sicherheit in der Informationstechnik
(BSI) 9, 324
Bundesdatenschutzgesetz 66, 218, 320
Business-Rolle 321, 333
BY ACCESS 228, 235
C
CDB 107
Centralized User Administration for Databases
(CUA4DB) 183
CheckOraDBSec.ba 441
CheckOraDBSec.sh 441
486
Index
CIA
– Business-Impact-Matrix 13
– Triade 11
Client-Identifier 91
Cloud 43
Cloud Computing 63, 114
Cloud Control 71
COMMON USER 109, 324
Compliance Dashboard 71
Compliance/Nachhaltigkeit der Datenbank 122
Confidentiality (Vertraulichkeit) 75
Configuration Management Packs 43, 423
CONNECT 48, 369
Container 81, 93, 125, 245
Container-Clause 114
Container Database 106
CONTEXT 54, 396
CPU Resource Management 63
Critical Patch Updates (CPU) 163, 423
CSV-Dateien 444
CURRENT_USER 87, 410
CVSS 75, 121, 466
D
Database App Development VM 445
Database Control 248
Database Link 26, 146, 162, 188, 347
Database Vault 48, 96, 105, 232 f., 345
Database Vault Auditing 88
Data Dictionary 6, 334
Dataguard 309
Data Masking 62
Data Pump 93 f.
Data Redaction 101, 103, 406
Daten
– Sozialdaten 5
– Unternehmensdaten 5
Datenanonymisierung 23
Datenbankaktivitäten 69
Datenbankjobs 427
Datenbank-Links 49
Datenbankprofile 28
Datenbanküberprüfung 121
Datenbank-Upgrade 38
Datenintegrität 482
Datenklassifikation 11
Datenlabels 415
Daten-Lifecyle 117
Datenloads 446
Datenmodell 446
Datenqualität 274
Datenschutz 1, 5, 20, 26, 104, 394
Datenschutzregeln 25
Datentypen 416
Datenverlust 125
Datenverschlüsselung 23
DBA-Account 49
DBA-Rolle 329
DB-Creation-Script 130
DB-Link-Sicherheit, Database Link 49
DB-Link-Users 49
DB Vault 67, 69, 93 f., 390
DB-Vault-Owner 424
DB-Vault-Sicherheitszonen 424
Default-Kennwort 166, 179 f.
Definer Rights 83
Denial of Service (DoS) 56
– Attacken 10, 311
Diagnosability Infrastructure 69
Diagnoseeinstellungen 277
Dictionary managed 290
Directories 400
direkte Berechtigungsvergabe 319
Disaster Recovery 309
Disk Flooding 56
Downtime Calculator 480
DR-Konzept 309
E
eigenes Rollenkonzept 372
EM Express 248
Enterprise Manager 43, 71, 135, 248
Enterprise Manager Repository 317
Enterprise-Rollen 35
Enterprise-User 35
Enterprise User Security 33 f.
Erhalt des guten Sicherheitszustands 26
Erhaltung der Sicherheit 73
erhöhtes Risiko 381
erhöhte Sicherheit (Datenschutz) 2
Erkennung und Identifizierung 479
EUS (Enterprise User Security) 33, 66
EvaluationDBSetup 460
Evaluierungsdashboard 450
Evaluierungsdatenbank 450
EXECUTE-Berechtigungen 387
Export-Dumps verschlüsselt 61
Extended Audit Information 91
Extensibility Frameworks 81
external Procedures 403
External Procedure Call 81
Externer Passwort-Speicher 189
F
Fast Recovery Area 287
feingranulare Zugriffsrechte 205
FGA Policy 92
Fine-grained Auditing 69, 87
Fragenkatalog 470
Fragmentierung 152, 289
Full-Database-Backup 150
Index
G
gefährliche Library 419
gehärtete Datenbank 142
geheimer Schlüssel 413
Genehmigungsprozesse 354, 356
Gesetze 1, 15, 28, 62, 69, 104, 122, 329
– § 91 Abs. 2 des Aktiengesetzes 19
– § 611 BGB 17
– Aktiengesetz 16
– BDSG 19
– Bundesdatenschutzgesetz (BDSG) 1, 5, 15, 19, 42, 66,
218, 320
– Bundesschutzgesetze 19
– Compliance 14
– Gesetz zur Bekämpfung der Wirtschaîskriminalität
15, 28
– Gesetz zur Kontrolle und Transparenz (KontraG) 16
– GmbH-Gesetz 16, 18
– Handelsgesetzbuch 19
– KonTraG 16
– Landesdatenschutzgesetz 364
– Richtlinien 1
– StrÄndG 21
gesetzeskonform 102
– gesetzeskonformer Betrieb 243
gesetzliche Anforderungen 68
gewachsene Datenbank 40, 47
Gewaltenteilung 38, 63, 78, 81, 94, 427
Glaube 469
– und Realität 43
– und Wahrheit 6
globale Standardrolle 339
glogin.sql 44
GoogleChart-Owner-Hierarchie 451
Graceperiode 77
GRANT 45
Grundbedrohungen 9, 121, 283
Grundschutz 43
H
HA-Anforderung 125
Haîungsrisiken 76
Härten 40
Härtung 6, 43
Hashverfahren 324
Health Checks 26, 73
Heatmap 118
hochprivilegierte Accounts 329
hochprivilegierte Rechte 53
hochverfügbare Mindesteinstellung 284
I
Identitäten 71, 329
Identity-Management-Lösung 183
Identity Management System 71
ILM-Konzept 116
ILM-Policies 192
Immediate-Write-Modus 89
IMP/EXP_FULL_DATABASE 48
Implementierter Schutzbedarf, Beispiel 11
Information Lifecycle Management 116, 192
INHERIT (ANY) PRIVILEGES 80
init.ora-Parameter 38
Instance Caging 310
Integrationspunkte 49
Integrität 9, 75
– der Systeme 480
Interaktive Reports 452
invalide Objekte 292
Invoker-Rechte 411
Invoker Rights 47, 83
IT Sicherheit 9
J
Java-Permissions 398
Java-VM 430
K
Keine Installation 442
Kennwort siehe Passwort
Kennwortmanagement siehe Passwortmanagement
Kerberos 37 f., 78, 323
Klassifikation siehe Datenklassifikation
Klassifizierung 5, 100, 415
Komplexität 34, 38, 45, 78, 88, 116, 162, 237, 308, 319,
333, 352, 388
Komprimierung 119, 300
Konfiguration 461 f.
– der Datenbank 121, 123
Konsolidierung 114
Kontrolle 68, 78
– der Daten 63
– und Transparenz 43
Korrelierung 239
korrupte Datenbackups 300
korrupte Datenblöcke 301 f.
Kriminalität 28
L
Label Security 105
LAST_LOGIN 79, 254, 326
LDAP 51
Least Privilege 40, 46 f., 51, 53, 95 f., 98, 319, 354, 356,
372, 381
Least Soîware-Install 129
Lifecycle Management Packs 43, 71, 423
Lizenz-Compliance 49, 100
487
488
Index
LOCAL USER 109, 324
Log-Dateien 444
M
Management Packs 43
Mandantenfähigkeit 60, 106
Maskierung 102
menschliche Fehler 125
Mindestanforderung 65
Mindestprotokollierung 69
Mindestsicherheit 40, 224, 289
– Härtung 6, 26
Missbrauch 43
Mixed Mode, Audit 89
Monitoring/Auditing 462
MS Active Directory 33, 66
multiplexed 148, 288
Multiplexing 149, 287, 289
Multi-Tier-Anwendungen 104
N
Nachhaltigkeit und Compliance 465
Nachweisbarkeit 43
Network Packages 193, 195, 376
Netzwerkverschlüsselung 3, 60
New Feature Guide 38
Nicht-Patching 74
NON-CDB 107, 123
O
Object-Owner 45, 275 f.
Objektprivilegien 45, 80, 319
opatch 423
OPEN_LINK 50, 146
OPS$%-Accounts 323
ORA_ACCOUNT_MGMT 90, 221
ORA_DATABASE_PARAMETER 90, 221
ORA_SECURECONFIG 42, 90, 221, 224
Oracle Advanced Security Option 60
Oracle Audit Vault 70
Oracle Data Pump 114
Oracle Database Firewall 53
Oracle Database Vault 362
Oracle Datenbank Developer VBOX 445
Oracle Enterprise Manager 75
Oracle Enterprise User Security 26, 51
Oracle Identity Manager 72
Oracle Listener 61
Oracle Managed Files 287
Oracle Network Configuration Manager 38
Oracle Privileged Account Manager 329
Oracle Real Application Security 104
Oracle Resource Manager 65
Oracle-Standard-Datenbankbenutzer 261
Oracle-Standardinstallation 335, 394
Oracle Standard Schema 166
Oracle Wallet 413
Owner 45, 57, 84
Owner-Objekte 230
P
Packs 135
Password-File 263, 331
PASSWORD-Verify-Funktion 183
Passwort
– cracken 27
– Hashes 80, 181
– Komplexität 29, 79
– Management 25 f., 28, 186
– Richtlinie 28
– Verschlüsselung 32
Passwortdatei 181
Passwortversion 324
Patches 42, 217, 264
Patch-Advisor 75
Patching 26, 74, 478
Patching-Prozesse 76
Patching-Strategie 77
Patchset 164, 423
PCI-DSS 100, 394
PDB Historie 128
personalisierte Accounts 329
personalisierter DBA 329
personenbezogene Daten 1, 20, 68, 229, 232
pluggable Datenbanken 106
pluggable DB 245
Policy 52
Privileganalyse 47, 408
Privileged Account Management 181
Privilegien 75, 78, 114
– Capture 96
– in der XML DB ACL 383
privilegierte Benutzer 253
Produktionsumgebung 323
Produktivitätssteigerungen 34
Profile 65, 67, 183 f., 266
Protokollieren 93
Protokollierung 66, 68
– Audit 20, 26, 42, 218
Provisionierungsprozess 71
Provisioning 354
Proxies 397
Prüfsummenbildung 10
Pseudonymisierung 23, 59
PUBLIC DB Link 51, 187
Public Synonyme 162
punktuelle Sicherheitslösungen 6
Index
Q
Queued-Write-Modus 89
R
Real Application Security 78, 279 f.
Realität 469
Rechenzentrum 482
Reconciliation 73
Recovery Manager 296
Redundanzen 237, 352, 388, 403, 415
Referenzdatenbank 41, 43
Referenz-DB-Erstellungsskript 41
Regelbibliothek 43
Release-Manager 358
Remote Listening 61
Reorganisation 290
Resource Manager 310, 312
RESOURCE-Rolle 39
Ressourcen 48, 63, 369
Ressourcenmanagement 29, 63
Ressourcenverbrauch 64, 184
Ressourcenverbrauch-Policy 303 ff.
Retention Policy 297
revisionssicheres Audit 70
REVOKE 45
Rezertifizierung 319
Risiko 74, 187 f., 213
Risikoabschwächung 7, 81
Risikofaktor 43, 75, 467
Risikomanagement 6
Risikomatrix 75, 121
Risikominimierung 7, 43
RMAN 93, 294, 298, 421
Rollen an PL/SQL 402
Rollenhierarchie 352
Rollenkonzepte 319
Rollenmanagement 26, 48, 78
Rootkit 221, 267
Row Level Security 59
Royalty 49, 252
S
sanîes Härten 42
Scheduler-Credentials 429
Schutzbedarf 11, 52, 122, 263, 473
Schutzmaßnahme 104
Schwachstellen 75, 121
SCN-Headroom 435
Secure Application Role 57, 339
Secure Password Store 189
security cost of ownership (SCO) 120
Security Patch Updates 423
Security Updates 74, 76
Seggration of duty 331
SELECT-Sammlung 459
sensible Spalten 101
Separation of Duties 94
Serverkonsolidierung 310
SHA-2 324
Shared Accounts 243, 253, 329
Shared DB Accounts 244
shared library 417
Shell-Script 442
sicherer Datenbankbetrieb 471
sichere Datenbankkonfiguration 23
sichere Konfiguration 483
Sicherheitsdesign 5
Sicherheitspatches 43
Sicherheitspolicy 52
Sicherheitsstandard 43
Sicherheitsüberprüfung 121
Sicherheitsuntersuchung 121
Sicherheitszonen 57
Sicherheitszustand 71, 460
Single Sign-On 38
Slider 462
SoD 71 f., 78, 94, 107, 327, 344
SQL INJECTION 53, 221, 376
SQL-Scripte 442
SSL Handshake 51
Standardeinstellung 394
Standardkennwort 40
Standardrollen 48, 242, 333, 342, 372
Standard-User 276
Standby 308
starke Authentisierungsverfahren 26
starke Privilegien 188
Subsetting 63
Synonyme 293
Syntaxsuche 101
SYS-Objekte 337
SYSBACKUP 94
SYSDBA 94, 264
SYSDG 94
SYSKM 94
SYSLOG-Server 221
System Global Area 434
Systemprivilegien 45, 69, 224, 227, 234 f., 240, 319, 349,
451
T
TABLESPACE QUOTA UNLIMITED 39
total cost of ownership (TCO) 120
Transient logical Standby 284
Transparent Data Encryption (TDE) 412
Transparent Sensitive Data Protection 100
transparente Datenverwaltung 119
transparente Verschlüsselung 61
Transparenz 91
– und Kontrolle 74, 122
Trennung von Verantwortlichkeiten 354
TSDP 100
489
490
Index
U
Überwachen 57
Überwachung 80, 97, 218
– der Datenbank 121
– des Listener.log 282
– von Systemprivilegien 228
Umgebungen 474
Umsatzausfälle 480
unerlaubter Zugriff 69
Unified Audit 94, 278
UNIFIED_AUDIT_TRAIL 89
Unified Auditing 78, 88, 219, 221
unlimited Ouota 366
UNLIMITED QUOTA 49, 80
Unsichtbare Benutzer 266
Unsichtbare Rollen 268
unsichtbare Standardrollen 269
– _NEXT_USER 269
– PUBLIC 269
Untersuchungsmöglichkeiten 441
unverschlüsseltes Backup 300
– von Regeln 69
– gegen die Zwecktrennung 390
Vertraulichkeit 9
Virtual Private Database 191, 394
– Row Level Security 59
– VPD 59, 365
virtuelle Umgebung 43
VPD 101
VPD Policy 60
W
Wallets 189
Wichtigkeit
– der Daten 473
– der IT-Sicherheit 471
Windows-Umgebung 38
Wissen 469
X
XML-DB-ACL-Dateien 383
V
Verbindlichkeit 9
Vereinfachung 34
Verfügbarkeit 9, 283, 300, 463
– der Datenbank 121
Verlust
– der Integrität 10, 121, 273, 480
– der Kontrolle 372
– der Verbindlichkeit 11
– der Verfügbarkeit 10, 121, 303 ff., 311, 416, 479
– der Vertraulichkeit 10, 121, 273
Verschlüsselung 59, 78, 105, 144, 300
versteckte Oracle-init.ora-Parameter 142
Verstoß
Z
Zero-Downtime 284
Zertifikate 323
Zugriffskontrolle 319, 463 f.
– der Datenbank 122
Zugriffskonzept 160, 162, 350
– für Directories 401
Zugriffsrechte 337
Zugriffsschutz 58
– auf Zeilenebene 395
Zwecktrennung 26, 57, 66, 264, 320, 330, 333, 345, 358
– SoD 67