11. Februar 2014

Hands-on: Einführung in den Aufbau einer sicheren Oracle Datenbank

Im Dezember 2013 habe ich in Potsdam einen DB Security Hands-on Workshop durchgeführt. Ziel dieser Veranstaltung war es eine sichere Oracle Datenbank aufzubauen.

Aus den Ausführungen unserer DB Security Reviews für Kunden erfahren wir oft, dass untersuchte Datenbankumgebungen selten den notwendigen Schutzbedarf implementiert haben, den diese untersuchten DBs eigentlich erfordern.
Hinzu kommt, dass die Anforderungen an Datensicherheit und Datenschutz stetig steigen. Das deutsche Gesetz kennt insbesondere bei Sozial- und personenbezogenen Daten kein Pardon.

Der Oracle DB Security Hands-on Workshop zeigt an realen Beispielen, wie man Konzepte richtig aktiviert und welche Konzepte man implementieren muss. Es werden anhand der realen Beispiele Best Practices an Live-Datenbanken implementiert und mit den neuen Konzepte der DB 12c verlinkt.

Ich erstellte einen Lab-Guide mit dem sich Teilnehmer an einer Oracle 11.2.0.4 Datenbank ausprobieren konnten. Inhaltlich fokussierten wir uns in dem Workshop auf:
1. Wissen und AKVs
2. Mindestsicherheit
3. Zugriffskontrolle und Zwecktrennung
4. Erhöhte Komplexität
5. Verfügbarkeit
6. Audit und Überwachung
a) Spezielle Hands-on Übungen, um die Datenbank in den genannten 6
     Bereichen sicherer zu machen
b) Wir behandeln 11g Datenbanken und verweisen aber auch auf neue
    Funktionalitäten der 12c Datenbank
c) Ausblick besonderer DB 12c Security Lösungen

Beiliegend finden Sie nun den Lab-Guide, damit Sie mit dem Aufbau einer sicheren Oracle Datenbank beginnen können. Führen Sie die Labs aus und entwickeln Sie Ihr ganz eigenes Konzept zur Erhöhung der Datenbank Sicherheit.

Lab-Guide

Nachfolgend finden Sie Übungen, die die Sicherheit der Datenbank erhöhen. Die meisten der Labs adressieren eine Mindestsicherheit, die es zu aktivieren gilt.
Zusätzlich werden Lösungen aufgezeigt, die für einen erhöhten Schutzbedarf angewendet werden können und sollten.
Weitere Informationen:
Oracle Security in Depth Reference Architecture: http://www.oracle.com/technetwork/topics/entarch/oracle-wp-security-ref-arch-1918345.pdf

Setup der Umgebung

Importieren Sie als erstes das Database Image (wir nutzten eine DB 11.2.0.4, dieses Image haben Sie leider nicht zur Verfügung, daher müssen Sie ein eigenes Image aufbauen) in Ihre Vbox-Umgebung. Prüfen Sie bitte, wo genau die virtuellen Platten installiert werden. Falls Sie damit nicht einverstanden sind, ändern Sie den Pfad. Stimmen Sie dem Workshop-Lizenzsatz zu. Der Import-Vorgang dauert ca. 6 Minuten
Bevor Sie nun das importierte Image starten, konfigurieren wir einen Shared Folder:
1.    Auf Ändern klicken und unter gemeiname Ordner ein lokales Verzeichnis mappen.
2.    Wählen Sie Ihr lokales Verzeichnis aus und mappen diesen als gemeinsamen Ordner unter dem Namen Workshop mit vollen Zugriff
Nun können wir das Image starten. Die Linux Maschine fährt hoch.
Sobald das Loginfenster erscheint, melden wir uns als oracle/oracle an (root hat auch das Passwort oracle).
Akivieren Sie in dem Vbox-Menü >Geräte > gemeinsame Zwischenablage > bidirektional
Nun setzen wir als erstes den Shared Folder und kopieren dann das Zip-Archiv mit den Labs auf das Linux-Image. Öffnen Sie ein Terminalfenster und geben hierfür folgende Kommandofolge ein:
[oracle@localhost ~]$ su -
[oracle@localhost ~]$ mkdir /mnt/Workshop
[oracle@localhost ~]$ mount -t vboxsf Workshop /mnt/Workshop
[oracle@localhost ~]$ exit
[oracle@localhost ~]$ cd labs
[oracle@localhost ~]$ cp /mnt/Workshop/Hands-on_Labs.zip .
[oracle@localhost ~]$ unzip Hands-on_Labs.zip 

Die vorbereiteten Scripte haben Sie nun nicht zur Verfügung, daher müssen Sie die Statements aus dem Blockeintrag kopieren.

Lab1: Mindestsicherheiteinstellen

In dieser Übung adressieren wir die Mindestsicherheit. Oracle liefert hier bereits Vorgaben. Zu nennende Quellen sind der Oracle Database Security Guide (in der entsprechenden Version) wie auch dokumentierte Projekte z.B. das Lockdown-Projekt.
In dieser Übung stellen Sie nun folgende Mindestsicherheit ein:
•    Netzwerkverschlüsselung
•    Init.ora Parameter, die die Sicherheit anheben
•    SQL*Net Konfiguration
Natürlich muss eine Mindestsicherheit immer den Anforderungen der Unternehmung folgen. Die hier dargestellten Vorgaben können als gute Grundlage genutzt werden, sollten aber den Anforderungen entsprechend angepasst werden.

Netzwerksicherheit einstellen

Als oracle Linux User ein Terminalfenster öffnen und den Listener sowie die Datenbank hochfahren:
[oracle@localhost ~]$ lsnrctl start
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> startup
SQL> exit;
TNSNames-Alias erstellen. Wir nutzen nicht den Network Configuration Manager (netca), sondern ändern manuell:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora
orcl =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.world)
    )
  )
und Naming Service auf Local Naming einstellen (manuell):
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle
Wir erstellen nun ein Sample-Schema:
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> create user scott identified by tiger default tablespace users;
SQL> grant connect, resource to scott;
SQL> exit;
Nun wollen wir testen, welche Daten aus dem Netzwerkverkehr mitlesen können. Dazu öffnen wir ein neues Terminalfenster und melden uns als root an. Root startet dann ein tcpdump und liest somit mit, was über das Netz gesendet wird:
[oracle@localhost ~]$ su -
Password:
[oracle@localhost ~]$ /usr/sbin/tcpdump -Xs 1518 -i lo port 1521
Im alten Terminalfenster melden wir uns als Scott an und ändern das Passwort. Dieses Passwort kann im Klartext mitgelesen werden:
[oracle@localhost ~]$ sqlplus scott/tiger@orcl
SQL> alter user scott identified by tiger;
SQL> Exit;
>>Tcpdump sollte nun das Kommando mitgelesen haben
Jetzt erzwingen wir eine Netzwerkverschlüsselung für die gesamte Oracle-Kommunikation über SQL*Net. Hierfür wird die sqlnet.ora angepasst:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, 3DES168)

Übrigens der Parameter SQLNET.CRYPTO_SEED wird mittlerweile igoniert (seit 10g glaube ich). Der Seed wird automatisch erzeugt.
Starten Sie den Listener durch und führen ein paar SQL Abfragen ab, um zu prüfen, ob die Netzwerkverschlüsselung aktiv ist:
[oracle@localhost ~]$ lsnrctl
LSNRCTL > reload
LSNRCTL > services
LSNRCTL > status
LSNRCTL > exit;

[oracle@localhost ~]$ sqlplus scott/tiger@orcl
SQL> alter user scott identified by tiger;
SQL>exit;
Im root Terminalfenster (tcpdump) wird alles verschlüsselt. Sehen Sie das?
Nun prüfen wir den Network Service Banner, ob der Netzverkehr verschlüsselt wird (Achten Sie auf den Algorithmus AES256 und SHA1):

[oracle@localhost ~]$ sqlplus system/oracle@orcl
SQL> set lines 200
SQL> column username format a30
SQL> column network_service_banner format a120
SQL> select distinct substr(a.username,1,30) USERNAME,
                 b.network_service_banner
 from v$session a,
      v$session_connect_info b
 where a.sid=b.sid
 and   a.serial#=b.serial#;
## Achten Sie auf den Algorithmus
Dokumentation: Doku: http://docs.oracle.com/cd/E11882_01/network.112/e10746/asoconfg.htm#ASOAG020
Oracle sagt im CPU Okt. 2013: Network encryption (native network encryption and SSL/TLS) and strong authentication services (Kerberos, PKI, and RADIUS) are no longer part of Oracle Advanced Security and are available in all licensed editions of all supported releases of the Oracle database. To remediate this security vulnerability, customers should configure network encryption in their clients and servers to protect sensitive data sent over untrusted networks. Refer to http://docs.oracle.com/cd/E11882_01/license.112/e47877/options.htm#CIHFDJDG - "Oracle Advanced Security section" of "Oracle Database Licensing Information 11g Release 2 (11.2)" for details of this licensing change.

Init.ora Parameter anpassen

In diesem Abschnitt betrachten wir nun die init.ora Parameter. Um die Sicherheit zu erhöhen, macht es Sinn bestimmte Parameter einzuschalten.
SQL> show parameter
NAME                                                       VALUE
O7_DICTIONARY_ACCESSIBILITY    FALSE        KORREKT
audit_sys_operations                                  FALSE        auf TRUE setzen
audit_trail                                                   DB,EXTENDED    besser XML, lassen wir aber
                                                                   auf DB
control_files                                               ....ctl    besser mehrere verteilt auf
                                                                   verschiedene Platten lassen
                                                                   wir aber so.
db_ultra_safe                                             OFF        wir setzen den Parameter
                                                                   auf DATA_ONLY, damit sind
                                                                   die nachfolgenden 3 Parameter auch gesetzt
**************************
Wird durch db_ultra_safe automatisch gesetzt
DB_BLOCK_CHECKING                         FALSE        set to MEDIUM besser FULL,
                                                                     wenn Performance OK.
DB_LOST_WRITE_PROTECT                 NONE        set to TYPICAL
DB_BLOCK_CHECKSUM                       TYPICAL    set to FULL
**************************
enable_ddl_logging                                     FALSE        set to TRUE
local_listener                                               wird später registriert
open_links                                                   4        auf 0 setzen
open_links_per_instance                             4        auf 0 setzen
os_authent_prefix                                        ops$        auf RUL$ setzen, nie Default belassen
remote_login_passwordfile                         EXCLUSIVE    brauchen wir das?
resource_limit                                              FALSE        auf TRUE setzen
sec_protocol_error_further_action              CONTINUE    auf DEPLAY oder DROP
sec_protocol_error_trace_action                 TRACE        LOG oder ALERT
sec_return_server_release_banner               FALSE        TRUE setzen
smtp_out_server                                          ACHTUNG anpassen
                                                                     Diesen Parameter passen wir in diesem LAB nicht an
sql92_security                FALSE        auf TRUE setzen
So, nun die init.ora Datei ändern:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> select value from v$parameter where name='spfile';
SQL> create pfile = '/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/mypfileorcl.ora' from spfile = '/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/spfileorcl.ora';
exit;
Mypfile editieren:
[oracle@localhost ~]$ vi $ORACLE_HOME/dbs/mypfileorcl.ora
orcl.__db_cache_size=230686720
orcl.__java_pool_size=4194304
orcl.__large_pool_size=8388608
orcl.__oracle_base='/home/oracle/app/oracle'#ORACLE_BASE set from environment
orcl.__pga_aggregate_target=222298112
orcl.__sga_target=369098752
orcl.__shared_io_pool_size=0
orcl.__shared_pool_size=117440512
orcl.__streams_pool_size=0
*.audit_file_dest='/home/oracle/app/oracle/admin/orcl/adump'
*.audit_trail='db_extended'
*.compatible='11.2.0.4.0'
*.control_files='/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_96kwtdsb_.ctl'
*.db_block_size=8192
*.db_create_file_dest='/home/oracle/app/oracle/oradata'
*.db_domain='world'
*.db_name='orcl'
*.diagnostic_dest='/home/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.memory_target=591396864
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'

# Anpassungen fuer die Sicherheit
audit_sys_operations=TRUE
db_ultra_safe=DATA_ONLY
enable_ddl_logging=TRUE
open_links=0
open_links_per_instance=0
os_authent_prefix=RUL$
resource_limit=TRUE
sec_protocol_error_further_action=DELAY
sec_protocol_error_trace_action=LOG
sec_return_server_release_banner=TRUE
sql92_security=TRUE
Datenbank runterfahren, neues pfile aktivieren und prüfen:
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> shutdown immediate
SQL> create spfile='/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/spfileorcl.ora' from pfile='/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/mypfileorcl.ora';
SQL> startup
SQL> show parameter
SQL> exit;
Fertig. Prüfen Sie, ob Einstellungen aktiv sind.

Netzwerkkonfiguration (SQL*Net) anpassen

SQL*Net Konfiguration anpassen:
[oracle@localhost ~]$ lsnrctl stop
sqlnet.ora anpassen:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle
# Encryption
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, 3DES168)
#Irgendwelcher Input
SQLNET.CRYPTO_SEED="lökjlkjklafsdölkaqweürwüskldfäasdfäöaskdf)()(=)()="
# Security
SQLNET.INBOUND_CONNECT_TIMEOUT=7
SQLNET.OUTBOUND_CONNECT_TIMEOUT=10
SEC_USER_AUDIT_ACTION_BANNER=/home/oracle/app/auditwarning.txt
SEC_USER_UNAUTHORIZED_ACCESS_BANNER=/home/oracle/app/unauthwarning.txt
SQLNET.ALLOWED_LOGON_VERSION=12
SQLNET.EXPIRE_TIME=10
WALLET_OVERRIDE=TRUE
Editieren Sie die auditwarning.txt und unauthwarning.txt nach belieben. Diese Banner können Sie verwenden, um bestimmte Warnungen zu der Datenbank auszusprechen (Beispiele liegen bei).
Kopieren Sie die Dateien aus lab1 /home/oracle/labs/lab1/*warning.txt in das Verzeichnis /home/oracle/app
[oracle@localhost ~]$ cp /home/oracle/labs/lab1/*warning.txt /home/oracle/app
[oracle@localhost ~]$ ll /home/oracle/app/*.txt
listener.ora anpassen (wir stellen um auf Port 1522):
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/listener.ora
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1522))
    )
    (DESCRIPTION =
      (ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
    )
  )
SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (GLOBAL_DBNAME=orcl.world)
      (ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_2)
      (SID_NAME=orcl)
     )
   ) 
ADR_BASE_LISTENER = /home/oracle/app/oracle
# Security
ADMIN_RESTRICTIONS_LISTENER=ON
INBOUND_CONNECT_TIMEOUT_LISTENER=5
SECURE_REGISTER_LISTENER = (IPC)
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=OFF
LOGGING_LISTENER = OFF
WALLET_LOCATION =
  (SOURCE =
   (METHOD = FILE)
    (METHOD_DATA =
     (DIRECTORY = /home/oracle/app/oracle/oradata/ORCL/wallet)
    )
  )
Ändern Sie den Port in der tnsnames.ora auf 1522:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora
orcl =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.world)
    )
  )
Listener wieder starten und in der DB registrieren:
[oracle@localhost ~]$ lsnrctl start
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> alter system set local_listener = '(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=REGISTER)))' scope = BOTH;
SQL> shutdown immediate
SQL> startup
SQL> exit;
Fertig. Prüfen Sie die Zusatznachrichten und Einstellungen ob diese aktiv sind.
Weitere Informationen:
Using Class of Secure Transport (COST) to Restrict Instance Registration (Doc ID 1453883.1)

Lab 2: Eine Mindestauditierung aktivieren

In der Übung 1 haben wir bereits das Auditing in der Datenbank aktiviert. Es werden nun alle SYS Aktivitäten auditiert, sowie 2 weitere wichtige Aktivitäten, die in der Datenbank überwacht werden sollten.

SYS Auditing

Der init.ora Parameter AUDIT_SYS_OPERATIONS trägt in unserer Datenbank den Wert TRUE. Diesen Parameter haben wir in LAB1 bereits verändert. Mit dieser Einstellung werden alle Aktivitäten protokolliert, die unter einem SYSDBA oder SYSOPER in der Datenbank arbeiten. Die Protokolle werden im Betriebssystem abgelegt bzw. unter Windows in den Event Viewer Log.
In unserer Datenbank werden die Aktivitäten in $ORACLE_BASE/admin/$ORACLE_SID/adump abgelegt. Falls Sie einen anderen Pfad haben wollen, muss der init.ora Parameter AUDIT_FILE_DEST angepasst werden.
Damit Sie sehen was alles protokolliert wird, führen Sie bitte folgende Schritte aus:
1.    Öffnen Sie ein Terminal (Fenster1) und melden sich als SYSDBA an
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> show parameter audit
2.    Öffnen Sie ein weiteres Terminal (Fenster2) und wechseln in den Audit-Bereich auf dem Filesystem und öffnen die letzte Audit-Datei mit „tail“:
[oracle@localhost ~]$ cd /home/oracle/app/oracle/admin/orcl/adump/
[oracle@localhost ~]$ ls -ltr
Wir öffnen die letzte angezeigte Datei
[oracle@localhost ~]$ tail -f „letzte angezeigte .aud Datei“
3.    Gehen Sie zurück ins Terminal (Fenter1) und führen einige Kommandos als SYSDBA aus:
SQL> alter system switch logfile;
SQL> select name, spare4 from sys.user$ order by 1;
4.    Schauen in das Terminal (Fenster2), dort sollten Sie alle ausgeführten Kommandos sehen:
...
Wed Nov 27 16:10:28 2013 +01:00
LENGTH : '181'
ACTION :[27] 'alter system switch logfile'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/2'
STATUS:[1] '0'
DBID:[10] '1357437676'

Wed Nov 27 16:11:39 2013 +01:00
LENGTH : '188'
ACTION :[34] 'select name, spare4 from sys.user$'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/2'
STATUS:[1] '0'
DBID:[10] '1357437676'
PS: Status:[1] 0 heißt, dass das Kommando korrekt ausgeführt wurde und keine Fehler auftraten. Probieren Sie einfach ein fehlerhaften Kommando aus.
Typischerweise würde man für die Sammlung der Aktivitäten einen zentralen Protokollserver aufbauen. Hierfür kann man verschiedene Lösungen aufbauen, wie einen zentralen Syslog Dienst oder Oracle Audit Vault und weitere Lösungen.
Beachten Sie bitte, dass deutsche Gesetze (BDSG) und Datenschutzrichtlinien (DSV) eine Protokollierung der Administratoren fordern.
Weitere Informationen:
Siehe My Oracle Support: Audit SYS User Operations (How to Audit SYSDBA) (Doc ID 174340.1),
Online Documentation: http://docs.oracle.com/cd/E11882_01/network.112/e16543/auditing.htm#DBSEG0611

Mindesteinstellung der Überwachung von Systemprivilegien

Gesetze wie das Bundesdatenschutzgesetz fordern eine Protokollierung, daher sollte diese geforderte Protokollierung auch aktiv sein. Ein Audit in der Datenbank erzeugt einen gewissen Overhead.
Siehe http://www.oracle.com/technetwork/database/audit-vault/learnmore/twp-security-auditperformance-166655.pdf
Im Security Guide der Oracle Datenbank findet man einen Vorschlag, welche Privilegien als minimal Anforderung überwacht werden sollten.
Weitere Informationen:
Oracle Security Guide, Guidelines für Auditing: http://docs.oracle.com/cd/E11882_01/network.112/e16543/guidelines.htm#DBSEG90008
Die dort beschriebenen Vorgaben, werden wir jetzt umsetzen und erweitern diese mit der Überwachung von der Anlage PUBLIC SYNONYME, da Public Synonyme gerne für Root-Kits genutzt werden:
1.    Öffnen Sie ein Terminal und melden sich als SYSDBA an:
[oracle@localhost ~]$ sqlplus / as sysdba
2.    Führen Sie Ihre Audit Policy der Systemprivilegien aus (siehe auch lab2/ audit_policy_systemprivs.sql):
SQL> AUDIT ALTER ANY PROCEDURE  BY ACCESS ;
SQL> AUDIT ALTER ANY TABLE  BY ACCESS ;
SQL> AUDIT ALTER DATABASE  BY ACCESS ;
SQL> AUDIT ALTER SYSTEM  BY ACCESS ;
SQL> AUDIT CREATE ANY EDITION  BY ACCESS ;
SQL> AUDIT CREATE ANY JOB  BY ACCESS ;
SQL> AUDIT CREATE ANY LIBRARY  BY ACCESS ;
SQL> AUDIT CREATE ANY PROCEDURE  BY ACCESS ;
SQL> AUDIT CREATE ANY TABLE  BY ACCESS ;
SQL> AUDIT CREATE EXTERNAL JOB  BY ACCESS ;
SQL> AUDIT CREATE PUBLIC SYNONYM BY ACCESS ;
SQL> AUDIT DROP ANY EDITION BY ACCESS ;
SQL> AUDIT DROP ANY PROCEDURE  BY ACCESS ;
SQL> AUDIT DROP ANY TABLE  BY ACCESS ;
SQL> AUDIT ALTER PROFILE  BY ACCESS ;
SQL> AUDIT ALTER USER  BY ACCESS ;
SQL> AUDIT AUDIT SYSTEM  BY ACCESS ;
SQL> AUDIT CREATE PUBLIC DATABASE LINK  BY ACCESS ;
SQL> AUDIT CREATE SESSION  BY ACCESS ;
SQL> AUDIT CREATE USER  BY ACCESS ;
SQL> AUDIT DROP PROFILE  BY ACCESS ;
SQL> AUDIT DROP USER  BY ACCESS ;
SQL> AUDIT EXEMPT ACCESS POLICY  BY ACCESS ;
SQL> AUDIT GRANT ANY OBJECT PRIVILEGE  BY ACCESS ;
SQL> AUDIT GRANT ANY PRIVILEGE  BY ACCESS ;
SQL> AUDIT GRANT ANY ROLE  BY ACCESS ;
SQL> AUDIT ROLE  BY ACCESS ;
SQL> AUDIT DATABASE LINK  BY ACCESS ;
SQL> AUDIT DIRECTORY  BY ACCESS ;
SQL> AUDIT PROFILE  BY ACCESS ; 
SQL> AUDIT PUBLIC SYNONYM  BY ACCESS ;
SQL> AUDIT SYSTEM AUDIT  BY ACCESS ;
SQL> AUDIT SYSTEM GRANT  BY ACCESS ;
3.    Überprüfen Sie Ihre Policy in der Datenbank und führen dafür folgendes Kommando aus:
SQL> set lines 120
SQL> select user_name,
       proxy_name,
       privilege,
       case
        when        privilege = 'ALTER ANY PROCEDURE' OR
                    privilege = 'ALTER ANY TABLE'     OR
                    privilege = 'ALTER DATABASE'      OR
                    privilege = 'ALTER SYSTEM'        OR
                    privilege = 'CREATE ANY EDITION'  OR
                    privilege = 'CREATE ANY JOB'      OR
                    privilege = 'CREATE ANY LIBRARY'  OR
                    privilege = 'CREATE ANY PROCEDURE'OR
                    privilege = 'CREATE ANY TABLE'    OR
                    privilege = 'CREATE EXTERNAL JOB' OR
                    privilege = 'CREATE PUBLIC SYNONYM' OR
                    privilege = 'DROP ANY EDITION'    OR
                    privilege = 'DROP ANY PROCEDURE'  OR
                    privilege = 'DROP ANY TABLE'      OR
                    privilege = 'ALTER PROFILE'       OR
                    privilege = 'ALTER USER'          OR
                    privilege = 'AUDIT SYSTEM'        OR
                    privilege = 'CREATE PUBLIC DATABASE LINK'  OR
                    privilege = 'CREATE SESSION'      OR
                    privilege = 'CREATE USER'         OR
                    privilege = 'DROP PROFILE'        OR
                    privilege = 'DROP USER'           OR
                    privilege = 'EXEMPT ACCESS POLICY'OR
                    privilege = 'GRANT ANY OBJECT PRIVILEGE' OR
                    privilege = 'GRANT ANY PRIVILEGE' OR
                    privilege = 'GRANT ANY ROLE'      OR
                    privilege = 'ROLE'                     then 'ORA-Recommend' 
        else 'Customer'
      end ORA_REC   
  from dba_priv_audit_opts order by 3;
Ihre Audit Policy ist hiermit aktiv. Nun können Sie diese testen:
SQL> connect system/oracle
SQL> create user peter identified by pan;
SQL> column username format a15
SQL> column obj_name format a15
SQL> column action_name format a30
SQL> select username, obj_name, action_name
       from dba_audit_trail where action_name like 'CREATE USER' 
      order by timestamp;
Probieren Sie selber weitere Aktionen aus. Vielleicht im SQL Developer dort ist die Ergebnismenge übersichtlicher.

Entfernte DB Link Zugriffe erkennen

Der Zugriff von DB Links in die Datenbank ist ein Risiko. In der Regel werden die kompletten Credentials in der entfernten Datenbank gespeichert und über diese DB Links dürfen dann alle berechtigten DB Benutzer auf die entfernte Datenbank zu greifen. Wenn es sich um einen Public DB Link handelt, dann dürfen alle DB Benutzer zu greifen.
Wie kann man nun in der Datenbank sehen, welche überwachten Systemprivilegien von entfernten Benutzern über einen Datenbank Link ausgeführt wurden?
Hierfür müssen wir einen Datenbank Link anlegen und diesen Database Link nutzen und dann schauen wir in die DBA_AUDIT_TRAIL und prüfen, ob ein DB Link genutzt wurde.
1.    Als erstes legen wir ein neues Table-Objekt im Benutzer SCOTT an und befüllen es:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn scott/tiger@orcl
SQL> create table criticaldata (nr number, citData varchar2(100));
SQL> insert into criticaldata values (1, 'Patent zur Herstellung von Coca Cola');
SQL> insert into criticaldata values (2,'Geodata fuer naechste Erdoelbohrung');
SQL> commit;
2.    Nun legen wir als SYSTEM einen neuen Benutzer und geben diesem Benutzer das Recht sich anzumelden und ein Recht Database Links anzulegen:
SQL> conn system/oracle@orcl
SQL> create user dblinkusr identified by oracle;
SQL> grant create session, create database link to dblinkusr;
3.    Nun legen wir den DB Link an und schauen auf das neue Objekt von SCOTT:
SQL> conn dblinkusr/oracle@orcl
SQL> create database link scott_link connect to scott identified by tiger using 'orcl';
4.    Bevor wir den Datenbank Link nutzen können, müssen wir den init.ora Parameter OPEN_LINKS auf 1 setzen, ansonsten würde folgende Fehlermeldung angezeigt werden; ORA-02020: too many database links in use
SQL> conn / as sysdba
SQL> alter system set OPEN_LINKS=1 scope=SPFILE;
SQL> shutdown immediate
SQL> startup
SQL> show parameter open_links
5.    Datenbank Link nutzen, d.h. der benutzer schaut über den Link in die Objekte, ohne eine direkte Berechtigung Daten aus diesem Objekt zu lesen;
SQL> conn dblinkusr/oracle@orcl
SQL> select * from criticaldata@scott_link;
6.    Nun schauen wir in der DBA_AUDIT_TRAIL nach und schauen mal, wie man sieht ob ein enterfernter DB Link etwas in unserer Datenbank ausführte:
SQL> conn system/oracle@orcl
SQL> select username, obj_name, action_name, comment_text
          from dba_audit_trail
        where comment_text like '%DBLINK_INFO%'
 order by timestamp desc;
Alternativ nutzen Sie den SQL Developer

Mindesteinstellung der Überwachung von Objektprivilegien

Zu jeder Mindestsicherheit gehört die Überwachung von wichtigen SYS-Objekten. Hierzu zählen die Tables SYS.USER$, SYS.LINK$ und SYS.USER_HISTORY$
Zusätzlich überwachen wir den Zugriff auf unser wichtiges Objekt SCOTT.CRITICALDATA.
1.    Audit für die wichtigen SYS-Objekte einstellen:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> AUDIT SELECT,update,delete,insert ON SYS.LINK$ BY SESSION;
SQL> AUDIT SELECT,update,delete,insert ON SYS.USER_HISTORY$ BY SESSION;
2.    Normalerweise sollte man die SYS.USER$ Table auch überwachen, die wird aber für einen WARM-Start benötigt (in 11g DBs). Somit sollte an dieser Stelle der Zugriff auf diese Tabelle eingeschränkt sein. Seit 12c kann man die SYS.USER$ überwachen:
    /*12c audit policy's definition */
    CREATE AUDIT POLICY pol1 ACTIONS select ON sys.user$;
    /* Enabled audit policy for ALL users */
    AUDIT POLICY pol1;
3.    Audit für die Scott Tabelle
SQL>AUDIT SELECT,update,delete,insert ON SCOTT.CRITICALDATA BY SESSION;
4.    Zusätzlich können Sie gerne eigene Objekte überwachen
5.    Mit diesem Select können Sie alle Objekt-Privilegien (ausser PUBLIC) ansehen, am besten SQL Developer benutzen:
SQL> select a.owner,
       a.grantor,
       a.grantee,
       CASE
        WHEN (SELECT 'X' from dba_users
              where username = a.grantee) IS NOT NULL THEN 'USER'
        WHEN (SELECT 'X' from dba_roles
              where role = a.grantee) IS NOT NULL THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.table_name,
       max(decode(privilege,'SELECT','X')) "SELECT",
       max(decode(privilege,'INSERT','X')) "INSERT",
       max(decode(privilege,'UPDATE','X')) "UPDATE",
       max(decode(privilege,'DELETE','X')) "DELETE",
       max(decode(privilege,'ALTER','X')) "ALTER",
       max(decode(privilege,'REFERENCES','X')) "REFERENCES",
       max(decode(privilege,'INDEX','X')) "INDEX",
       max(decode(privilege,'EXECUTE','X')) "EXECUTE"
from dba_tab_privs a
where a.grantee != 'PUBLIC'
group by a.owner, a.grantor, a.grantee, a.table_name
order by a.grantee,a.owner,a.table_name;

Netzwerk überwachen

Wenn Sie wollen, dass die unerwarteten Fehler im SQL*Net Verkehr mitprotokolliert werden,schalten Sie nachfolgenden Schalter an.
1.    Network auf unerwartete Fehler überwachen
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> AUDIT NETWORK;

Fine grained Auditing (FGA)

FGA nutzt man, wenn man eine Auditierung detaillieren möchte wie z.B. eine Überwachung des Zugriffs auf nur eine Spalte oder man auditiert nur dann, wenn eine bestimmte Bedingung zutrifft und nicht zutrifft.
Weitere Informationen:
Auditing Specific Activities with Fine-Grained Auditing: http://docs.oracle.com/cd/E11882_01/network.112/e16543/auditing.htm#DBSEG525
How to Avoid Common Flaws and Errors Using Fine Grained Auditing (Doc ID 199419.1)
SCRIPT: How To Apply the Same Fine Grained Audit Policy To All Tables In A Schema. (Doc ID 469007.1)
SCRIPT: How To Implement The Equivalent Of BY SESSION Auditing Using FGA on Objects? (Doc ID 1269970.1)
Wir legen jetzt einen simplen Case an, der nur protokolliert, wenn mit einem bestimmten Tool auf unsere wichtige Tabelle im Scott Schema zugegriffen wird.
1.    Als Erstes wird ein FGA Admin angelegt, der alle notwendigen Rechte besitzt:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> CREATE USER FGA_ADMIN IDENTIFIED BY oracle;
SQL> GRANT CREATE SESSION TO fga_admin;
SQL> GRANT EXECUTE ON DBMS_FGA TO fga_admin;
SQL> GRANT CREATE PROCEDURE TO fga_admin;
SQL> GRANT SELECT on sys.v_$session TO fga_admin;
2.    Als FGA_ADMIN anmelden und notwendige Policies und Funktionen anlegen:
Als erstes eine Funktion die das verwendete Tool beim Login prüft:
SQL> conn fga_admin/oracle@orcl
SQL> create or replace function getProgram return varchar is
         l_program varchar2 (500) := NULL;
        begin
         select Program into l_program from v$session 
          where SID = sys_context('USERENV','SID');
         return l_program;
        exception when others then
         return NULL;
        end;
/
SQL> grant execute on fga_admin.getProgram to PUBLIC;
Nun können wir die Policy anlegen und protokollieren, wenn SQL Developer benutzt wird und auf die Spalte CITDATA zugegriffen wird:
SQL> BEGIN   -- erst droppen, falls schon vorhanden
      DBMS_FGA.DROP_POLICY(
      object_schema      => 'SCOTT',
      object_name        => 'CRITICALDATA',
      policy_name        => 'CRITICALDATA_POLICY');
     END;
/

BEGIN
  DBMS_FGA.ADD_POLICY(
   object_schema      => 'SCOTT',
   object_name        => 'CRITICALDATA',
   policy_name        => 'CRITICALDATA_POLICY',
   enable             =>  TRUE,
   audit_condition    =>
       'fga_admin.GetProgram=''SQL Developer''',
   audit_column       => 'citdata',
   statement_types    => 'SELECT,INSERT,DELETE,UPDATE',
   audit_trail        =>  DBMS_FGA.DB+DBMS_FGA.EXTENDED);
END;
/
Überprüfen Sie bitte, ob die Policy existiert:
SQL> conn / as sysdba
SQL> SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES;
3.    Nun wechseln Sie in den SQL Developer als User Scott und selektieren die Tabelle (auf dem Desktop auf das SQL Developer Icon doppelklicken):
SQL Developer> Connection für scott/tiger@orcl Port: 1522 sdid=orcl anlegen (oben links auf das grüne PLUS klicken)
SQL Developer> select * from criticaldata;
4.    Melden Sie sich als DBA an und Sie prüfen ob der Zugriff protokolliert wurde:
SQL> conn / as sysdba
SQL> select * from DBA_COMMON_AUDIT_TRAIL where AUDIT_TYPE='Fine Grained Audit' order by extended_timestamp desc;
Im Audit Type wird FGA gekennzeichnet. Prüfen Sie die Aussagen.
Im Verzeichnis LAB2 finden Sie einen SQL-Script fga_anlegen.sql zur Anlage der FGA Policy.

Audit Daten säubern

Bei der Überwachung mittels Audit entstehen Daten, die in bestimmten Abständen zu säubern sind. Definieren Sie sich Ihren eigenen Plan, wann die Daten veraltet und überprüft sind.
Oracle Support hat in seiner Knowledge Base einen Script vorbereitet, der eine Retention Time von einer Woche vorsieht.
SCRIPT: Basic example to manage AUD$ table in 11.2 with dbms_audit_mgmt (Doc ID 1362997.1)
Diese Übung werden wir nicht durchführen.

Audit Policy generieren

Das nachfolgende Script generiert, die eingestellte Audit Policy (Systemprivilegien) in der Datenbank.
SCRIPT: Generate AUDIT and NOAUDIT Statements for Current Audit Settings (Doc ID 287436.1).
Diese Übung werden wir nicht durchführen.

Audit in der Datenbank härten

Es gibt verschiedene Möglichkeiten ein Audit zu härten. Oracle hat hier in seiner Knowledgebase Informationen zur Verfügung gestellt. Fragen Sie hierzu Ihren Oracle Sales Consultant.
Natürlich können Sie auch Audit Vault nutzen, dann werden die Auditdaten in einem zentralen und revisionssicheren Audit Warehouse verwaltet. Darüber hinaus werden die Daten in den Zieldatenbanken zentral und automatisiert gesäubert, Policies zentral provisioniert und einiges mehr.

Lab 3: Schutz der Daten durch Verschlüsselung

Für verschiedenene Schutzmaßnahmen, die eine Verschlüsselung fordern, kennen wir verschiedenen Business Cases:
1.    Die Daten verlassen die Datenbank z.B. über einen Export-Dump oder Backup
2.    Schutz vor Nicht-Datenbankbenutzern wie ROOT, Storage-Admins, Hoster etc.
3.    Physikalischer Datendiebstahl (Rechnerdiebstahl)

Data Encryption mit DataPump:

Es ist keine Installation und keine Konfiguration notwendig. Die einzige Voraussetzung ist das Vorhandensein eines DIRECTORY-Objektes. Zusätzlich muss der Benutzer berechtigt sein, in das Directory zu schreiben.
1.    Prüfen Sie, ob Directories vorhanden sind und wer Zugriff hat:
[oracle@localhost ~]$ sqlplus system/oracle@orcl
SQL> select a.owner,
       a.table_name as DIRNAME,
       b.directory_path,
       a.grantor,
       a.grantee,
       CASE
        WHEN (SELECT 'X' from dba_users where username = a.grantee)
             IS NOT NULL THEN 'USER'
        WHEN (SELECT 'X' from dba_roles where role = a.grantee)
             IS NOT NULL THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.privilege,
       a.grantable,
       a.hierarchy
  from dba_tab_privs a,
       dba_directories b
 where  a.table_name = b.directory_name
 order by a.table_name, a.grantee, a.privilege;
2.    Wir wollen nun als SCOTT die Objekte exportieren und müssen SCOTT ein WRITE Recht auf DATA_PUMP_DIR geben:
SQL> grant write, read ON DIRECTORY DATA_PUMP_DIR to SCOTT;
3.    Daten als USER SCOTT exportieren. Einmal mit Passwort, d.h. die Daten werden verschlüsselt. Das angegebene Passwort braucht man auch für den späteren Import.
Als Linux oracle User im Terminal nachfolgende Kommandos ausführen:
[oracle@localhost ~]$ expdp scott/tiger TABLES=scott.criticaldata DIRECTORY=DATA_PUMP_DIR FILE=scott.dmp ENCRYPTION_PASSWORD=welcome1
[oracle@localhost ~]$ ll /home/oracle/app/oracle/admin/orcl/dpdump/
4.    Rufen Sie den „vi“ mit dem Export-Dump auf und versuchen Sie sinnvolle Werte abzuleiten:
[oracle@localhost ~]$ vi /home/oracle/app/oracle/admin/orcl/dpdump/scott.dmp
5.    Ein Import würde nachfolgend funktionen (führen wir aber nicht aus):
[oracle@localhost ~]$ impdp scott/tiger TABLES=scott.criticaldata DIRECTORY= DATA_PUMP_DIR FILE=scott.dmp ENCRYPTION_PASSWORD=welcome1
Anstelle des Passwords können auch Wallets verwendet werden.
OPTIONAL: Wiederholen Sie die Schritte 3 und 4 ohne den ENCRYPTION_PASSWORD-Parameter und durchsuchen Sie den Export Dump nach "Coca Cola".

Data Encryption mit Tablespace Verschlüsselung

Nun verschlüsseln wir einen Tablespace und schieben in diesen neuen Tablespace unsere wichtige Tabelle CRITICALDATA aus dem SCOTT Schema.
1.    Wallet Location muss in der sqlnet.ora definiert sein.
Editieren der $ORACLE_HOME/network/admin/sqlnet.ora und hinzufügen, des neuen Parameters:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
ENCRYPTION_WALLET_LOCATION =
(SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
    (DIRECTORY =
     /home/oracle/app/oracle/oradata/ORCL/wallet)))
2.    Wallet Verzeichnis anlegen (zu den Datenfiles):
[oracle@localhost ~]$ mkdir $ORACLE_BASE/oradata/ORCL/wallet
3.    Listener durchstarten
[oracle@localhost ~]$ lsnrctl
LSNRCTL> reload
LSNRCTL> exit
4.    Wallet mit Master Key erstellen. Passwort dient dem Schutz des Wallets:
[oracle@localhost ~] sqlplus / as sysdba
SQL> alter system set encryption key identified by "welcome1";
5.    Wallet öffnen, falls es noch nicht bereits geöffnet ist (ist schon geöffnet).
SQL> alter system set encryption wallet open identified by "welcome1";
6.    Nun können wir einen verschlüsselten Tablespace erstellen:
SQL> create tablespace enc256_ts datafile
'/home/oracle/app/oracle/oradata/ORCL/datafile/enc256_ts.dbf'
          size 10M autoextend on next 1M encryption
          using 'AES256' default storage (encrypt);
7.    Wir betrachten uns nun, ob der Tablespace wirklich verschlüsselt ist:
SQL> select tablespace_name,encrypted from dba_tablespaces;
8.    Nun können wir das SCOTT Objekt in diesen verschlüsselten Bereich verschieben. Die Daten sind dann transparent verschlüsselt:
SQL> alter table scott.criticaldata move tablespace enc256_ts;
SQL> select owner, table_name, tablespace_name from dba_tables
where owner='SCOTT' and table_name='CRITICALDATA';
9.    Optional: Mit dem Parameter close schließt man das Wallet und dadurch kann keiner mehr (auch die berechtigten User nicht mehr) auf die verschlüsselten Daten (im Tablespace) zugreifen.
SQL> alter system set encryption wallet close identified by "welcome1";
10.    Optional: Wenn man AutoOpen Wallet erstellen/nutzen will:
[oracle@localhost ~]$ orapki wallet create –wallet /home/oracle/app/oracle/oradata/ORCL/wallet/ewallet.p12 -auto_login
oder mit Hilfe vom Oracle Wallet Manager
Weitere Informationen:
TDE Best Practices: http://www.oracle.com/technetwork/database/security/twp-transparent-data-encryption-bes-130696.pdf

Lab 4: Zwecktrennung – Segregation of Duties (SoD)

Die Zwecktrennung wird z.B. auch in den Gesetzen gefordert z.B. in der Anlage zum §9 Bundesdatenschutzgesetz
“...8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können...“.
Nicht der Gesetze sondern auch der eigenen Sicherheit und Kontrolle wegen, empfiehlt sich eine sinnvolle Zwecktrennung in der Datenbank. Das schafft eine klare Übersicht und bessere Kontrolle. Abweichungen der Zwecktrennung wären sofort sichtbar.
Unsere Erfahrung zeigt, dass eine unkontrollierte Mentalität in der Datenbank, wo jeder alles machen darf, dazu führt, dass durchaus gute Konzepte gar nicht oder nur halb umgesetzt werden. Das ist natürlich für die Sicherheit in der Datenbank nicht mehr kontrollierbar.
Eine saubere Zwecktrennung in der Datenbank sollte immer folgende Punkte berücksichtigen:
  • Eine saubere Trennung der Aufgaben in der Datenbank ist zu implementieren.
    Idealerweise bekommt jeder Mitarbeiter eine AKV (Aufgaben, Kompetenzen und Verantworlichkeiten) Matrix vorgelegt, diese sollte in der DB erzwungen werden.
    Die Datenbank 12c bietet eine voreingestellt Zwecktrennung out-of-the-box. Es werden verschiedene SYS User, Audit User und andere Rollen deployed, damit die Zwecktrennung bereits von Anfang an auf ein Mindestmaß eingestellt ist.
  • Überlegen Sie, welche Systeme und Rollen in der Unternehmung man für die Zwecktrennung bereits verwenden könnte.
    Beispiel: MS AD Admin. Für die Benutzerverwaltung in der DB wird ein bestehendes System mittels EUS (Enterprise User Security) genutzt. Rund um das System wie z.B. MS Active Directory bestehen Rollen, die auch für die Datenbank genutzt werden.
  • Zur Zwecktrennung gehört auch das Setup von Anwendungsowner und Anwendungsusern
  • Machen Sie die Zwecktrennung in Ihrer Datenbank auch sichtbar. Das macht man sehr einfach mittels Profilen. Zusätzlich kann man sich eine Syntax auch für Benutzernamen ausdenken. Schalten Sie Banner, die darauf hinweisen, dass hier protokolliert wird (haben wir ja bereits schon gemacht)!
  •  

Datenbank Profile

Ordnen Sie jeder Benutzergruppe das passende Profile zu, um diese Benutzergruppe eindeutig zu identifizieren und im Profile die passenden Paramter für diese Benutzergruppe zu setzen.
In unserem Beispiel, werden wir zwei Profile anlegen. Ein Profil für die Admins und eines für alle anderen Benutzer. Standardmäßig existiert immer ein Default-Profile. Dieses Profil bleibt erhalten und wird für alle nicht-Admins weitergenutzt.
1.    Als erstes installieren wir die Verfiy_Function, diese können Sie gerne nach Ihren Vorstellungen anpassen. Wir empfehlen auch für 11g Umgebungen, die Verify_Function, die mit 12c mitgeliefert wird, zu verwenden (machen wir hier nicht).
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/utlpwdmg.sql
Schauen Sie sich auch gerne den Inhalt des SQL-Scriptes an.

2.    Nun legen wir ein Profile für die Admins an:
SQL> CREATE PROFILE PRFL_ADMINS LIMIT
   FAILED_LOGIN_ATTEMPTS 5    
   PASSWORD_LIFE_TIME 60       
   PASSWORD_REUSE_TIME 60  
   PASSWORD_REUSE_MAX 5    
   PASSWORD_VERIFY_FUNCTION verify_function
   PASSWORD_LOCK_TIME 2        
   PASSWORD_GRACE_TIME 10   
   SESSIONS_PER_USER 1        
   COMPOSITE_LIMIT 5000000
   CONNECT_TIME 30            
   IDLE_TIME 30              
   CPU_PER_CALL UNLIMITED
   CPU_PER_SESSION UNLIMITED
   LOGICAL_READS_PER_CALL     UNLIMITED
   LOGICAL_READS_PER_SESSION  UNLIMITED
   PRIVATE_SGA                UNLIMITED;
3.    Nun prüfen wir welche DBAs in der Datenbank existieren (SYS und SYSTEM):
SQL> set lines 200
SQL> select rp.grantee ,
 (select 'YES' from dba_users where username=rp.grantee) IS_USER,
 (select 'YES' from dba_roles where role=rp.grantee) IS_ROLE,
 CASE
 WHEN (select 'YES' from dba_roles where role=rp.grantee) = 'YES'
 THEN (select count(*) from dba_role_privs a
  where a.granted_role=rp.grantee
    and a.grantee in (select username from dba_users)
 )
 END AMOUNT_GRANTED_USERS,
 rp.granted_role,
 rp.admin_option,
 rp.default_role
from dba_role_privs rp
where rp.granted_role='DBA';
4.    Die dargestellten DBAs (SYS und SYSTEM) bekommen nun das neue Profile zugeordnet:
SQL> ALTER USER SYS PROFILE PRFL_ADMINS;
SQL> ALTER USER SYSTEM PROFILE PRFL_ADMINS;
5.    Überprüfen Sie, welche Benutzer welche Profile aufweisen:
SQL> select username,
       account_status,
       profile
from dba_users order by 1;
6.    So bringen Sie Ordnung in Ihre Datenbank und kennzeichnen die verschiedenen Benutzergruppen.
7.    Das Default Profile sollte jetzt entsprechend Ihren Anforderungen angepasst werden. (Lassen wir hier aber aus).
Da der init.ora Parameter RESOURCE_LIMIT auf TRUE steht, werden die Kernel-Parameter in den Profilen aktiv genutzt.

Wer ist für das Account Management zuständig?

Prüfen Sie bitte selber, wer alles in der Datenbank für das Account Management zuständig ist. Das macht man am besten mit nachfolgendem SELECT:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn system/oracle@orcl
SQL> select grantee
     , count(granted_role) "Roles w/AdmOption"
     from dba_role_privs
    where grantee in (select username from dba_users)
      and admin_option ='YES'
    group by grantee
    order by 2 desc,1;
Das aufgezeigte Statement zeigt an, wer Rollen angelegt hat. Ist diese Verteilung auf verschiedene DB-Benutzer gewollt? Schaffen Sie in Ihrer Datenbank eindeutige Rollen, die für die entsprechenden Aufgaben z.B. eben für das Accountmanagement ausgestattet werden. Dann haben auch nur diese Rollen die Berechtigung, die man für das Account Management braucht, wie CREATE|ALTER...USER, CREATE ROLE...

Umgang mit SYS und SYSTEM – personalisierte DBAs

Die Empfehlung lautet wie folgt:
SYS nur in Notfällen verwenden z.B. für Patches, SYSTEM wird gesperrt und jeder DBA erhält eine eigene Kennung. Idealerweise nutzt man für die personalisierten DBAs eine Kerberos Authentisierung, um den Passwortwechsel über MS AD zu nutzen und eine automatische Passwort-Synchronisation zu haben. Somit existiert eine einheitliche und bestehende Passwort-Policy (über das MS AD oder einen anderen unternehmensweiten LDAP Dienst). Für einen professionellen Betrieb mit wenig Aufwand empfiehlt es sich auch für Admins Enterprise User Security mit Kerberos aufzusetzen.
In unserem Beispiel setzen wir nun die Empfehlung um und legen einen personalisierten DBA an.
1.    SYSTEM wird gesperrt:
[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> alter user SYSTEM account lock;
2.    Nun legen wir einen personalierten DBA an (Achtung wir haben nun die PASSWORD-Policy angelegt, also > 8 Zeichen ):
SQL> CREATE USER <IhrName> identified by MeinOracle1
     temporary tablespace temp default tablespace SYSAUX;
SQL> GRANT DBA to <IhrName>
SQL> alter user <IhrName> profile PRFL_ADMINS;
Admins sind zu personalisieren. So fordert es z.B. die Datenschutzverordnung.

Umgang mit dem Password-File

In der Regel findet man für die Datenbank folgenden Umgang mit dem Password-File:
1.    Der Init.ora Parameter REMOTE_LOGIN_PASSWORDFILE wird auf den Wert EXCLUSIVE getzt werden. Das bedeutet, dass das Password File nur für eine DB genutzt werden kann.
2.    Im Password-File befindet ein SYSDBA (SYS):
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> select * from V$PWFILE_USERS;
Diese Einstellung bedeutet nun, dass sich ein SYSDBA remote an die Datenbank anmelden kann. Er wird dann über das Password-File authentisiert, auch wenn die Datenbank nicht verfügbar ist.
Ist es das was Sie wollen? Remote zu administrieren?
Wenn nein, sollten Sie das Password-File on-Demand anlegen, d.h. nur wenn Sie eine Remote-Administration vornehmen wollen bzw. müssen. Für alle anderen Fälle existiert die Passwort-Datei nicht. In unserem Fall brauchen wir keine Remote-Administration und löschen das Password-File einfach:
1.    Password-Datei löschen:
$ cd $ORACLE_HOME/dbs
$ rm orapworcl
2.    Nun kann man sich trotzdem über die Console an die Datenbank anmelden, da der „oracle“ user der OS-<dba> Gruppe angehört:
[oracle@localhost ~]$ sqlplus / as sysdba
3.    Braucht man nun doch ein Password-File legt man es einfach an:
[oracle@localhost ~]$ orapwd FILE=orapworcl ENTRIES=1
Enter password for SYS:  (hier bitte oracle eingeben)
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> select * from V$PWFILE_USERS;
4.    Der User SYS wird automatisch eingetragen.

Apps-Owner und Apps-User Setup

Auch eine Zwecktrennung für das Anwendungssetup in der Datenbank ist ein wichtiges Thema. Hierbei ist das Least Privilege – Prinzip anzuwenden.
1.    Der Apps-Owner verwaltet die Objekte und hat keine hochprivilegierten Privilegien. Außerdem wird der Owner gesperrt. Wir geben dem Appsowner 1MB Quota auf den Tablespace USERS:
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> create user appsowner identified by Ooracle9923911 temporary tablespace temp default tablespace users account lock;
SQL> alter user appsowner quota 1M on users;
2.    Das Deployment wird von einem Release Manager durchgeführt. Bei uns ist das heute der personalisierte DBA:
SQL> conn <IhrName>/MeinOracle1@orcl
SQL> create table appsowner.anwendung (nr number, text varchar2(100));
3.    Der Apps-User wird angelegt und bekommt alle Privilegien, die er benötigt. Das Account Management übernimmt auch der personalisierte DBA:
SQL> conn <IhrName>/MeinOracle1
SQL> create user appsuser identified by MeinOracle1 temporary tablespace temp default tablespace users;
SQL> grant create session to appsuser;
SQL> grant select, insert, delete, update on appsowner.anwendung to appsuser;
4.    Der Apps-User kann sich nun anmelden und auf den Objekten des Apps-Owners operieren:
SQL> conn appsuser/MeinOracle1@orcl
SQL> insert into appsowner.anwendung values (1,'Zeile1');
SQL> insert into appsowner.anwendung values (2,'Zeile2');
SQL> insert into appsowner.anwendung values (3,'Zeile3');
SQL> commit;
SQL> select * from appsowner.anwendung;
So würde ein richtiges Apps-Owner und Apps-User Konzept/Setup aussehen. Natürlich sehr vereinfacht. Im Idealfall hat man mehrere Apps-User für unterschiedliche Aufgaben mit unterschiedlichen Berechtigungen. Die Berechtigungen werden natürlich in Rollen zusammengefasst.

Lab 5: Datenschutz auf Zeilenebene

In diesem Bereich stellt Oracle verschiedene Mechanismen zur Verfügung. Wir betrachten hier insbesondere
  • Row Level Security(RLS) oder Virtual Private Database (VPD)
  • Data Redaction, also das Redigieren von Informationen
  • Data Masking, die Pseudonymisierung von Daten bevor diese ausgetauscht werden, z.B. Produktionsdaten für das Development (behandelt wir hier nicht)

Virtual Private Database (VPD)

VPD schränkt den Zugriff auf Daten zur Laufzeit sein, in dem durch geeignete Policies Bedingungen zur Laufzeit ausgeführt werden. Hierfür führen wir folgendes Beispiel (lab5/VPD_Demo.sql)aus:
1.    Als SYS legen wir die User für das VPD Beispiel an
Melden Sie sich als <IhrName> an und erstellen Sie die notwendigen Benutzer. Einen Apps-Owner und zwei Endbenutzer:
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> CREATE USER orasec IDENTIFIED BY MeinOracle1
          DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session, create table TO orasec;
SQL> alter user orasec quota 1M on users;
SQL> CREATE USER orasec1 IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orasec1;
SQL> CREATE USER orasec2 IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orasec2;
2.    Als Apps-Owner orasec die Objekte erstellen
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE TABLE VPD_CUSTOMERS (
          "CUSTOMER_ID"      NUMBER(6) NOT NULL,
"CUST_FIRST_NAME"  VARCHAR2(20) NOT NULL,
"CUST_LAST_NAME"   VARCHAR2(20) NOT NULL,
"CUST_EMAIL"       VARCHAR2(30),
CONSTRAINT "CUSTOMERS_PK" PRIMARY KEY("CUSTOMER_ID")
USING INDEX);
SQL> CREATE TABLE VPD_ORDERS (
"ORDER_ID"       NUMBER(12) NOT NULL,
"ORDER_DATE"     TIMESTAMP(6) WITH LOCAL TIME ZONE NOT NULL,
"CUSTOMER_ID"    NUMBER(6) NOT NULL,
"ORDER_STATUS"   NUMBER(2),
"ORDER_TOTAL"    NUMBER(8, 2),
"REP_ID"      NUMBER(6) NOT NULL,
CONSTRAINT "ORDERS_CUSTOMER_ID_FK" FOREIGN KEY("CUSTOMER_ID")
REFERENCES "VPD_CUSTOMERS"("CUSTOMER_ID"),
CONSTRAINT "ORDER_PK" PRIMARY KEY("ORDER_ID") USING INDEX)
LOGGING ;
SQL> CREATE TABLE VPD_ITEMS (
"ORDER_ID" NUMBER(12) NOT NULL,
"LINE_ITEM_ID" NUMBER(3) NOT NULL,
"PRODUCT_ID" NUMBER(6) NOT NULL,
"UNIT_PRICE" NUMBER(8, 2),
"QUANTITY" NUMBER(8),
CONSTRAINT "ORDER_ITEMS_ORDER_ID_FK" FOREIGN KEY("ORDER_ID")
REFERENCES "VPD_ORDERS"("ORDER_ID") ON DELETE CASCADE NOVALIDATE,
CONSTRAINT "ORDER_ITEMS_PK" PRIMARY KEY("ORDER_ID", "LINE_ITEM_ID") USING INDEX)
LOGGING ;
3.    Erstelle die Tabelle für das Mapping. Die Salesreps werden in der Order Tabelle gemappt:
SQL> CREATE TABLE VPD_REPS
(id          NUMBER(6)    NOT NULL,
 ouser       VARCHAR2(30) NOT NULL,
 first_name  VARCHAR2(50) NOT NULL,
 last_name   VARCHAR2(50) NOT NULL);
4.    Fülle die Tabellen mit Daten:
SQL> INSERT INTO vpd_reps VALUES (0,'ORASEC','Schema','Owner');
SQL> INSERT INTO vpd_reps VALUES (1,'ORASEC1','John','Hansen');
SQL> INSERT INTO vpd_reps VALUES (2,'ORASEC2','David','Tolosana');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (1,'Peter','Pan','peter.pan@disney.com');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (2,'Donald','Duck','donald.duck@disney.com');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (3,'Dagobert','Duck','dagobert.duck@disney.com');
SQL> Insert into VPD_ORDERS (ORDER_ID,ORDER_DATE,CUSTOMER_ID,ORDER_STATUS,ORDER_TOTAL,REP_ID) values (1,to_timestamp('29-NOV-13 01.14.28.926000000 PM','DD-MON-RR HH.MI.SSXFF AM'),1,1,100,1);
SQL> Insert into VPD_ORDERS (ORDER_ID,ORDER_DATE,CUSTOMER_ID,ORDER_STATUS,ORDER_TOTAL,REP_ID) values (2,to_timestamp('29-NOV-13 01.14.56.275000000 PM','DD-MON-RR HH.MI.SSXFF AM'),2,1,200,2);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (1,1,1,50,1);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (1,2,2,10,5);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (2,1,1,50,2);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (2,2,3,10,10);
SQL> Commit;
5.    Erstellen Sie die Zugriffsrechte an die Endbenutzer. Normalerweise würden wir Rollen anlegen:
SQL> GRANT SELECT ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT SELECT ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT SELECT ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_ITEMS TO orasec1, orasec2;
6.    So, das Daten-Modell steht. Erteilen Sie nun ORASEC Privilegien für das Anlegen der späteren VPD Policies :
SQL> CONNECT / as sysdba
SQL> GRANT create any context, create public synonym, create procedure TO orasec;
SQL> GRANT EXECUTE ON SYS.DBMS_RLS TO orasec;
7.    ORASEC erstellt den Context, der später beim Login gefüllt wird, darüber wird der Endbenutzer identifiziert und in der VPD Policy eindeutig zugeordnet:
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE CONTEXT orasec USING orasec.Context_Package;
SQL> CREATE OR REPLACE PACKAGE Context_Package AS
          PROCEDURE Set_Context;
          END;
/
SQL> CREATE OR REPLACE PACKAGE BODY Context_Package IS
   PROCEDURE Set_Context IS
    v_ouser  VARCHAR2(30);
    v_id     NUMBER;
  BEGIN
    DBMS_Session.Set_Context('ORASEC','SETUP','TRUE');
    v_ouser := SYS_CONTEXT('USERENV','SESSION_USER');   
    BEGIN
      SELECT id  INTO   v_id 
        FROM   vpd_reps 
       WHERE  ouser = v_ouser;     
      DBMS_Session.Set_Context('ORASEC','REP_ID', v_id);
    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        DBMS_Session.Set_Context('ORASEC', 'REP_ID', 0);
    END;
    DBMS_Session.Set_Context('ORASEC','SETUP','FALSE');
  END Set_Context;
END Context_Package;
/
SQL> GRANT EXECUTE ON orasec.Context_Package TO PUBLIC;
SQL> CREATE PUBLIC SYNONYM Context_Package FOR orasec.Context_Package;
8.    Der SYS erstellt den Logon-Trigger in dem der Context dem Benutzer zugewiesen wird.
SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> CREATE OR REPLACE TRIGGER orasec.Set_Security_Context
AFTER LOGON ON DATABASE
BEGIN
  orasec.Context_Package.Set_Context;
END;
/
9.    Der Anwendungsowner legt nun die VPD Policy an. Die Policy ermittelt über den Context den aktuellen Benutzer und garantiert, dass nur die Kundendaten gelesen und verändert werden können, die dieser Benutzer betreuit. D.h. die Table VPD_ORDERS wird immer mit der REP_ID auf den aktuellen Benutzer eingeschränkt
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE OR REPLACE PACKAGE Security_Package AS
  FUNCTION User_Data_Security(Owner VARCHAR2, Objname VARCHAR2)
    RETURN VARCHAR2;
  END Security_Package;
/
SQL> CREATE OR REPLACE PACKAGE BODY Security_Package IS
  FUNCTION User_Data_Security(Owner VARCHAR2, Objname VARCHAR2)
  RETURN VARCHAR2 IS
    Predicate VARCHAR2(2000);
  BEGIN
    Predicate := '1=2';
    IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'ORASEC') THEN
      Predicate := NULL;
    ELSE
      Predicate := 'REP_ID = SYS_CONTEXT(''ORASEC'', ''REP_ID'')';
    END IF;
    RETURN Predicate;
  END User_Data_Security;
END Security_Package;
/
SQL> GRANT EXECUTE ON orasec.Security_Package TO PUBLIC;
SQL> CREATE PUBLIC SYNONYM Security_Package FOR orasec.Security_Package;
SQL> BEGIN
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_SELECT_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'SELECT');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_INSERT_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'INSERT');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_UPDATE_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'UPDATE');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_DELETE_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'DELETE');
END;
/
10.    VPD ist fertig konfiguriert. Der Anwendungsowner sieht alle Daten, die Endbenutzer sehen nun nur die Daten der betreuten Kunden. Testen Sie selber:
SQL> connect orasec/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> connect orasec1/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;
SQL> connect orasec2/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;
11.    Was passiert nun, wenn wir einen neuen Benutzer anlegen, sieht der überhaupt etwas, wenn keine Zuordnung besteht. Testen Sie selber:
SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> CREATE USER orauser IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orauser;
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> GRANT SELECT ON VPD_CUSTOMERS TO orauser;
SQL> GRANT SELECT ON VPD_ORDERS TO orauser;
SQL> GRANT SELECT ON VPD_ITEMS TO orauser;
SQL> CONNECT orauser/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;
12.    Ja, tatsächlich der Benutzer hat zwar eine SELECT-Berechtigung kann aber keine Daten sehen, da er selber kein Salesrep ist. Nun, wie kann man die VPD Policy aushebeln?
SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> GRANT EXEMPT ACCESS POLICY to orauser;
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;
13.    Also immer schön aufpassen, wer welche Privilegien bekommt. Achten Sie darauf, dass die Privilegien ordentlich verteilt werden. Am besten immer einen Extra-Account definieren, der Policies anlegt. Zusätzlich die Vergabe von wichtigen Privilegien überwachen.

Data Redaction

Data Redaction ist eine neue Funktion in der Datenbank Versionen 12c bzw. 11.2.0.4, die lizenztechnisch zu der Advanced Security Option gehört. Diese Funktion erlaubt eine Maskierung von Daten auf Datenbankebene und zeigt diese Maskierung dann durchgehend an, egal wie auf die Daten zugegriffen wird und wer zugreift. Data Redaction ist besonders wertvoll in der Nutzung mit Anwendungen. Sobald eine Data Redaction Policy deployed ist, werden die entsprechenden Daten geschützt und geschützt an die Anwendung weitergegeben.
Für die Anwendung einer Data Redaction Policy ist folgendes Szenario gegeben:
Der Anwendungsowner und Sicherheitsbeauftragte „orasec“ hat die Richtlinie ergeben, dass alle Kreditkarten-Daten in den Bestellungen nur für die Sales Reps sichtbar sind. (siehe lab5/REDACTION.sql)
1.    Der SYS erteilt dem orasec User die Berechtigung Data Redaction anzuwenden:
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> grant execute on DBMS_REDACT to orasec;
2.    Nun ändern wir die Order Table und fügen eine Spalte für die Kreditkarten ein:
SQL> connect orasec/MeinOracle1@orcl
SQL> alter table vpd_orders add creditcard varchar2(12);
SQL> update vpd_orders set creditcard='990457 4556';
SQL> commit;
3.    Nun legt der OraSec Benutzer die Redaction Policy an. Sie besagt, dass nur die Sales Reps die Kreditkarten Ihrer Kunden sehen, sonst keiner. Redigiert wird FULL, aber mit der PARTIAL Funktion, die dann aber die komplette Syntax mit „* Sternchen“ versieht
SQL> BEGIN
 DBMS_REDACT.ADD_POLICY(
   object_schema   => 'orasec',
   object_name     => 'VPD_ORDERS',
   column_name     => 'CREDITCARD',
   policy_name     => 'CREDITCARD_DBA',
   function_type   => DBMS_REDACT.PARTIAL, --DBMS_REDACT.FULL,
   function_parameters  => 'VVVVVVFVVVV,VVVVVV-VVVV,*,1,10',
   expression      =>
       'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') NOT IN
                    (''ORASEC1'',''ORASEC2'')'
 );
END;
/
4.    Nun wird getestet:
SQL> connect orasec/MeinOracle1@orcl
SQL> select customer_id, creditcard from vpd_orders;
SQL> connect orasec1/MeinOracle1@orcl
SQL> select customer_id, creditcard from orasec.vpd_orders;
SQL> connect orasec2/MeinOracle1@orcl
SQL> select customer_id, creditcard from orasec.vpd_orders;
SQL> connect / as sysdba
SQL> select customer_id, creditcard from orasec.vpd_orders;
Sehen Sie als SYS die Kreditdaten? Wenn ja, warum ist das wohl so?
Der SYS hat natürlich die Rolle DATAPUMP_EXP_FULL_DATABASE und diese beinhaltet die Berechtigung EXEMPT REDACTION POLICY, daher kann SYS die Daten im Orginal sehen. Achten Sie in Ihrem Konzept, wer was tun darf und trennen Sie die Aufgaben ordentlich, dann verlieren Sie nie oder selten die Kontrolle.

Lab 6: Zugriffskontrolle

Kommen wir zu der letzten Übung an diesem Tag. Die Zugriffskontrolle ist ein sehr wichtiger Baustein einer Oracle Datenbank. Hierüber steuert man, wer was in der Datenbank tun darf. Tatsächlich zeigt die Realität sehr komplexe Zugriffskonzepte, die viele tausende Grants benötigen und nur noch schwer zu kontrollieren sind. Darüber hinaus werden nicht nur komplexe Konzepte implementiert, sondern auch viele Fehler eingebaut. Es entstehen Redundanzen und teilweise auch Konzeptaushebelungen.
Darum ein Appell an dieser Stelle: Halten Sie Ihr Zugriffskonzept so einfach wie möglich. Einige grundlegende Regeln sind nachfolgend aufgeführt:
  • Nur Oracle Standard-Accounts haben Oracle Standard-Rollen
  • Alle anwendungsbezogenen Accounts erhalten speziell dafür angelegte Rollen. Diese Rollen wurden bewußt angelegt und der Inhalt der Berechtigungen in den Rollen ist bekannt.
  • Rollen wie CONNECT und RESOURCE werden nicht vergeben.
  • Nur die Admins erhalten eine Standardrolle wie DBA
  • Achten Sie darauf, dass man Privilegien nicht doppelt vergibt. Es reicht z.B. dem DBA die Rolle DBA zu gehen. CONNECT und RESOURCE braucht er nicht, da er mit der Rolle DBA alle Privilegien aus CONNECT und RESOURCE bereits besitzt.
  • Achten Sie darauf ausschließlich Rollen zu verwenden und nicht dem Account direkte Grants zuzuweisen (sofern das geht, mit 12c sollte das keine Probleme machen. In unseren Übungen haben wir der Einfachheit wegen direkte Grants verwendet).
  • Und ganz wichtig kennen Sie das Zugriffskonzept Ihrer Datenbank

Zugriffskontrolle transparent machen

Als Erstes schauen wir uns die eingestellte Zugriffskontrolle an. Dafür haben wir einige SELECT Statements vorbereitet:
1.    Alle DBAs in der Datenbank
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> col GRANTEE format a30
SQL> col IS_USER format a4 heading is|User
SQL> col IS_ROLE format a4 heading is|Role
SQL> col AMOUNT_GRANTED_USERS heading AMOUNT|GRANTED|USERS
SQL> col granted_role format a7 heading granted|Role
SQL> col ADMIN_OPTION format a5 heading ADMIN|Option
SQL> col DEFAULT_ROLE format a6 heading DEFAULT|Role
SQL>select rp.grantee ,
       (select 'YES' from dba_users where username=rp.grantee) IS_USER,
       (select 'YES' from dba_roles where role=rp.grantee) IS_ROLE,
       CASE
         WHEN (select 'YES' from dba_roles where role=rp.grantee) = 'YES'
         THEN (select count(*) from dba_role_privs a
                where a.granted_role=rp.grantee
                  and a.grantee in (select username from dba_users)
              )
       END AMOUNT_GRANTED_USERS,
       rp.granted_role,
       rp.admin_option,
       rp.default_role
  from dba_role_privs rp
where rp.granted_role='DBA'
/
Es sollten drei DBAs existieren und SYSTEM ist gelocked. Prüfen Sie das nochmal.
2.    Wer hat Zugriff auf SYS-Objekte wie sys.user$:
SQL> col "GRANTEE" format a25
SQL> col IS_USER format a4 heading is|User
SQL> col IS_ROLE format a4 heading is|Role
SQL> col AMOUNT_GRANTED_USERS heading AMOUNT|GRANTED|USERS
SQL> col "SYS-OBJECT" format a25
SQL> SELECT DISTINCT a.GRANTEE ,
       (select 'YES' from dba_users where username=a.grantee) IS_USER,
       (select 'YES' from dba_roles where role=a.grantee) IS_ROLE,
       CASE
         WHEN (select 'YES' from dba_roles where role=a.grantee) = 'YES'
         THEN (select count(*) from dba_role_privs b
                where b.granted_role=a.grantee
                  and b.grantee in (select username from dba_users)
              )
       END AMOUNT_GRANTED_USERS,
       'SYS.'||table_name "SYS-OBJECT"
 FROM DBA_TAB_PRIVS a
WHERE a.OWNER LIKE 'SYS'
  AND a.TABLE_NAME LIKE '%$'
order by 1;
Was fällt Ihnen auf? XDB und APEX haben Zugriff auf SYS:USER$ und können somit alle Hashwerte der Passwörter auslesen. Ist das ok?
3.    Wer hat welche System-Privilegien in der Datenbank?
SQL> set lines 200
SQL> col grantee format a30
SQL> col grantee_typ format a7 heading Grantee|Typ
SQL> col privilege format a40
SQL> select a.GRANTEE,
       CASE
       WHEN (SELECT 'X' from dba_users where username = a.grantee) IS NOT NULL
          THEN 'USER'
       WHEN (SELECT 'X' from dba_roles where role = a.grantee) IS NOT NULL
         THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.PRIVILEGE,
       a.ADMIN_OPTION
 from dba_sys_privs a
where a.grantee not in ('DBA','SYS')
order by 1,2,3;
Fällt Ihnen etwas auf? Es existieren hauptlich Standard Vergaben an Oracle Standard Account. Einige Accounts und Rollen sind sehr mächtig und weisen sogenannte ANY Privilegien wie SELECT ANY TABLE auf. Diese hoch privilegierten Rollen wie EXP_FULL_DATABASE gilt es zu schützen.
4.    Schauen wir gleich, ob diese Rolle geschützt ist:
SQL> col name format a30
SQL> col PROTECTED_ROLE format a15   heading Protected|Role
SQL> select name,
       decode(password, null, 'NO',
                       'EXTERNAL', 'EXTERNAL',
                       'GLOBAL', 'GLOBAL',
                       'APPLICATION','APPLICATION',
                       'PASSWORD') PROTECTED_ROLE
from  sys.user$
where type# = 0  and password is not null
order by 1;
Es gibt nur eine globale Standardrolle. Die Rolle, mit der man die komplette Datenbank exportieren kann, ist leider nicht geschützt.
Tipp: Eine gute Variante die Zugriffsberechtigung zu analysieren ist die Privilege Analyse, die Oracle mit der 12c Datenbank eingeführt hat.

Secure Application Roles

In dieser Übung wollen wir nun den Schutz einer wichtigen Rolle simulieren. Dafür legen wir eine eigene Rolle HR_ADMIN an.
Zu allererst legen wir eine Policy in Form von PL/SQL an:
1.    Prozedur erstellen, die für bestimmte Personen und zu einer bestimmten Uhrzeit die Nutzung der HR_ADMIN Rolle erlaubt:
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> CREATE OR REPLACE PROCEDURE SYS.ROLE_CHECK
           AUTHID CURRENT_USER
  AS
BEGIN
  IF (SYS_CONTEXT ('userenv','session_user')='ORASEC1')
    AND (TO_CHAR (SYSDATE, 'HH24') BETWEEN 8 AND 20)
  THEN
     EXECUTE IMMEDIATE 'SET ROLE HR_ADMIN';
  END IF;
END;
/
Die Policy sagt aus, dass ORASEC1 zwischen 8 und 20 Uhr diese Berechtigung nutzen darf.
2.    Nun legen wir die secure Application Role an und weisen dieser Rolle Berechtigungen zu.
SQL> create role HR_ADMIN identified using sys.ROLE_CHECK;
SQL> grant select on sys.user$ to HR_ADMIN;
SQL> grant HR_ADMIN to orasec1;
SQL> grant execute on SYS.ROLE_CHECK to orasec1;
3.    Nun probieren wir dieses Konstrukt aus:
SQL> conn orasec1/MeinOracle1
SQL> execute sys.ROLE_CHECK;
SQL> select * from sys.user$;
Die Rollenzuweisung hat funktioniert. Das Setzen der Rolle kann man geschickter machen, für die Übung reicht dieses Prinzip jedoch.

4.    Nun verändern die Policy und schränken den Zugriff auf 19-20 Uhr ein.
SQL> connect / as sysdba
SQL> CREATE OR REPLACE PROCEDURE SYS.ROLE_CHECK
           AUTHID CURRENT_USER
  AS
BEGIN
  IF (SYS_CONTEXT ('userenv','session_user')='ORASEC1')
    AND (TO_CHAR (SYSDATE, 'HH24') BETWEEN 19 AND 20)
  THEN
     EXECUTE IMMEDIATE 'SET ROLE HR_ADMIN';
  END IF;
END;
/
5.    Nun probieren wir dieses Konstrukt aus:
SQL> conn orasec1/MeinOracle1
SQL> execute sys.ROLE_CHECK;
SQL> select * from sys.user$;
Der Zugriff wurde verweigert.

Endbenutzer in der Datenbank sichtbar machen

Anwendungen sind meist in einer Dreischichten Architektur aufgebaut. D.h. die Anwendung wird über einen Client aufgerufen, der eine Anwendung auf dem Application Server ausführt und diese Anwendung meldet sich mit einem sogenannten Shared Account an die Datenbank an. In der Datenbank erkennt man leider nicht den Endbenutzer (der, der sich an der Anwendung angemeldet hat), sondern man sieht nur, dass der Application Server also die Anwendung angemeldet ist.
Diese Art der Konfiguration ist heute nicht mehr ausreichend. Endbenutzer sollten in der Datenbank sichtbar gemacht werden. Die Konfiguration ist sehr einfach. D.h eine technische Begründung warum Endbenutzer in der Datenbank nicht sichtbar, gilt heute nicht mehr.
Die Frage ist natürlich, warum sollen Endbenutzer sichtbar gemacht werden? Weill nur dann zusätzlichen Schutzmöglichkeiten aktiviert werden können. Kennt man den Endbenutzer, kann man zusätzliche Autorisierungsregeln definieren, die in der Anwendung nicht vorgegeben sind (empfiehlt sich gerade, wenn die Anwendung hochprivilegierte Benutzer wie DBAs benutzt), oder man kennt alle Benutzer, die sich lange Zeit nicht anmeldeten und kann diese de-aktivieren.
Wir haben zwei Beispiele mitgebracht, die den Endbenutzer in der Datenbank sichtbar machen. Einmal mittels einer JDBC-Verbindung (Java-Code) und das andere Beispiel nutzt sogenannte Proxy-Benutzer.
Eine weitere Möglichkeit ist das Setzen von CONTEXTS, wie im VPD Beispiel. Diese Möglichkeit werden wir in diesem Abschnitt nicht behandeln.

Endbenutzer im Java-Code vorbereiten

In diesem Beispiel werden wir zwei Codebeispiele durchspielen. Als erstes machen wir eine normale JDBC Connection auf und gucken, was wir in der DB sehen. Im zweiten Codebeispiel setzen wir den Client-Identifier und schauen nach, was wir in der DB sehen.
OracleJDBC.java: 
// einfachen Java-Beispiel
import java.sql.*;
import java.util.*;
 
public class OracleJDBC {
  public static void main(String[] argv) {
   System.out.println("-------- Oracle JDBC Connection Testing ------");
   try {
    Class.forName("oracle.jdbc.driver.OracleDriver");
   } catch (ClassNotFoundException e) {
    System.out.println("Where is your Oracle JDBC Driver?");
   e.printStackTrace();
   return;
  }
  System.out.println("Oracle JDBC Driver Registered!");
  Connection connection = null;
  Statement stmt = null;
  try {
   connection = DriverManager.getConnection(
     "jdbc:oracle:thin:@localhost:1522:orcl", "scott", "tiger");
   } catch (SQLException e) {
   System.out.println("Connection Failed! Check output console");
   e.printStackTrace();
   return;
  }
  if (connection != null) {
   System.out.println("You made it, take control your database now!");
      try{
        stmt = connection.createStatement();
     System.out.println("SELECT USER FROM DUAL");
        ResultSet rs = stmt.executeQuery("SELECT USER FROM DUAL");
        while(rs.next()){
          String username = rs.getString("user");
          //Display values
          System.out.println("Username: " + username);
       }
       try{
        System.out.println("> Continue with ENTER...");
          System.in.read(); // => This line is just to stop until you press enter. 
       }catch(Exception e){
         e.printStackTrace();
      }
     }catch(SQLException se){
       se.printStackTrace();
     }
    System.out.println("\n============="); 
  } else {
   System.out.println("Failed to make connection!");
  }
 }
}

OracleJDBCEndbenutzer.java:
// einfachen Java-Beispiel
import java.sql.*;
import java.util.*;
import oracle.jdbc.OracleConnection;

 
public class OracleJDBCEndbenutzer {
  public static void main(String[] argv) {
   System.out.println("-------- Oracle JDBC Connection Testing ------");
   try {
    Class.forName("oracle.jdbc.driver.OracleDriver");
   } catch (ClassNotFoundException e) {
    System.out.println("Where is your Oracle JDBC Driver?");
   e.printStackTrace();
   return;
  }
  System.out.println("Oracle JDBC Driver Registered!");
  Connection connection = null;
  Statement stmt = null;
  try {
        String URL = "jdbc:oracle:thin:@localhost:1522:orcl";
        Properties info = new Properties();
        info.put("user","scott");
        info.put("password","tiger");
        info.put("v$session.program","Test-JDBC");
        info.put("v$session.osuser","oracle");
     connection = DriverManager.getConnection(URL, info);
   } catch (SQLException e) {
   System.out.println("Connection Failed! Check output console");
   e.printStackTrace();
   return;
  }
  if (connection != null) {
   System.out.println("You made it, take control your database now!");
      String[] metrics = new String[OracleConnection.END_TO_END_STATE_INDEX_MAX];
     //client Identifier setzen
     metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = "carsten Muetzlitz, wohnhaft in Potsdam";
     try{
       ((OracleConnection)connection).setEndToEndMetrics(metrics,(short)0);
     }catch(Exception oe){
       oe.printStackTrace();
     }
     try{
      stmt = connection.createStatement();
   System.out.println("SELECT USER FROM DUAL");
      ResultSet rs = stmt.executeQuery("SELECT USER FROM DUAL");
      while(rs.next()){
       String username = rs.getString("user");
      //Display values
      System.out.println("Username: " + username);
     }
     try{
      System.out.println("> Continue with ENTER...");
      System.in.read(); // => This line is just to stop until you press enter. 
     }catch(Exception e){
       e.printStackTrace();
     }
    }catch(SQLException se){
      se.printStackTrace();
    }
    System.out.println("\n============="); 
  } else {
   System.out.println("Failed to make connection!");
  }
 }
}

1.    Den beiliegenden Javacode kompilieren:
hierzu den $ORACLE_HOME/jdbc/lib/ojdbc6.jar in Ihr Beispiel Directory (/home/oracle/labs/lab6) kopieren und den Java Code (OracleJDBC.java) kompelieren. Es entsteht unsere Java-Class
[oracle@localhost ~]$ cd /home/oracle/labs/lab6
[oracle@localhost ~]$ cp $ORACLE_HOME/jdbc/lib/ojdbc6.jar .
[oracle@localhost ~]$ javac OracleJDBC.java
2.    Das Java Program ausführen:
[oracle@localhost ~]$ java -cp /home/oracle/labs/lab6/ojdbc6.jar:/home/oracle/labs/lab6 OracleJDBC
Das Programm bleibt stehen. Bitte öffnen Sie nun ein zweites Terminal und melden sich als sysdba in der Datenbank an:
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL>
Jetzt können Sie die Sessions in der DB prüfen
Zurück in das andere Terminal folgendes Statement prüfen:
SQL> set lines 200
SQL> select username, program, client_identifier from v$session where username='SCOTT';
Im anderen Terminal bitte das Java Programm mit ENTER schliessen.

3.    Wie Sie sehen, sieht man nur den angemeldeten User und den Programm Namen.
4.    So nun wollen wir den Benutzer sichtbar machen.
Hierzu kompilieren Sie bitte den beigefügten OracleJDBCEndbenutzer.java Code:
[oracle@localhost ~]$ javac -classpath $ORACLE_HOME/jdbc/lib/ojdbc6.jar OracleJDBCEndbenutzer.java
Als nächsten Schritt führen wir das Java-Programm aus:
[oracle@localhost ~]$ java -cp /home/oracle/labs/lab6/ojdbc6.jar:/home/oracle/labs/lab6 OracleJDBCEndbenutzer
und führen das SQL Statement im SQL*Plus Fenster erneut aus
SQL> r
5.    Wie Sie sehen, sehen wir nun den Endbenutzer und den richtigen Programmnamen.

Die Aussage ist:
Jede Java-Anwendung kann den Endbenutzer in der DB sichtbar machen. Mit 10g konnte man den Client-Identifier mit setClientIdentifier setzen, heute nutzt man die Oracle JDBC Extension mit OracleConnection.END_TO_END_CLIENTID_INDEX und setzt den aktuell angemeldeten Endbenutzer.
Siehe auch Method setClientIdentifier() Not Found In Interface oracle.jdbc.OracleConnection for JDBC 10g (Doc ID 369236.1)
Teilweise sind viele Anwendungen bereits so vorbereitet, dass man ohne Programmieraufwand den aktuell angemeldeten Benutzer bis zur Datenbank durchreichen kann. Z.B. die Oracle Lösungen Business Intelligence, eBusiness Suite und viele andere Lösungen, die auf einem Application Server ablaufen.

Endbenutzer meldet sich über einen Proxy User an

Nun will ich die sogenannten Proxyuser einführen. Oracle nennt dieses Konzept Lightweight Session Proxy Authentication. Um dieses Beispiel in der Praxis anzuwenden, führen wir folgende Schritte durch:
1.    SQL*Plus aufrufen und als sysdba anmelden
[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
2.    Jetzt erstellen wir in der Datenbank einen Anwendungsuser „App-User“ und den Enbenutzer „Joe“:
SQL> create user appuser identified by MeinOracle2;
SQL> create user joe identified by MeinOracle1;
3.    Wir geben nur dem Endbenutzer entsprechende Berechtigung:
Er soll sich an die Datenbank anmelden können und darf die Tabelle scott.criticaldata lesen:
SQL> GRANT CREATE SESSION to joe;
SQL> GRANT SELECT on scott.criticaldata to joe;
4.    Nun erlauben wir dem Apps-User sich über Joe an die Datenbank anzumelden
SQL> alter user joe grant connect through appuser;
5.    Wir melden uns über den Appsuser an die Datenbank an (PW vom Appsuser) und schauen, was uns die DB sagt:
SQL> conn appuser[joe]/MeinOracle2@orcl
SQL> select * from scott.criticaldata;
SQL> select sys_context('userenv','current_user') from dual;
SQL> select sys_context('userenv','proxy_user') from dual;

Weitere Informationen:
http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/proxy/index.html
oder
Proxy Users and Auditing Proxy Users (Doc ID 782078.1)

Gut zu wissen - abschließendes Statement

Die Übungen, die wir hier durchspielten, sind kein vollständiges Ergebnis für Ihre Datenbanksicherheit, sondern nur ein Anfang. Oracle liefert vielfältige Informationen in der Online-Dokumentation, in der Knowledge Base vom Oracle Support sowie in einigen Whitepapern. Nutzen Sie diesen Anfang, um nun Ihre Datenbanksicherheit zu erhöhen und damit unsere Daten besser schützen.
Eine konsolidierte Zusammenfassung, wie die Sicherheit einer Datenbank überprüft werden kann, und aus der Überprüfung, die richtigen Maßnahmen für einen erhöhten Schutz abzuleiten, finden Sie z.B. sehr gut dokumentiert in dem neuen Buch „Oracle Security in der Praxis“, welches seit dem 1.Okt. 2013 im Buchhandel erhältlich ist.

http://www.amazon.de/dp/3446438696/
Sichere Oracle Datenbanken aufbauen

Eingestellt von um
Labels: , , , , ,

Keine Kommentare:

Kommentar veröffentlichen

Abonnieren Kommentare zum Post (Atom)