Oracle Database Vault, damit der DBA den

Werbung
Oracle Database Vault, damit der DBA den Jahresabschluss
nicht vor dem CEO kennt
Häfeli, Konrad . Principal Consultant . 30.05.2007
Die Enterprise Edition von Oracle stellt mehrere zum Teil kostenpflichtige Optionen zur
Verfügung, um bis auf Zeilenebene und abhängig von der Art und Zeit der Verbindung die
Zugriffsrechte auf die Daten zu vergeben. Ausgeklügelte Sicherheitskonzepte definieren die
Sicht und Manipulation der Daten innerhalb der Datenbank, resp. die Verschlüsselung der
Daten in den Datenfiles, während dem Transport sowie auf den Backupsets. Dieser Aufwand
ist aber wertlos, wenn der Connect zur Datenbank mit einem DBA oder SYSDBA privilegierten
Account geschieht.
1.
Einführung
Damit man verstehen kann wie Oracle Database Vault die Daten schützt, muss man die Risiken
sehen, denen eine Datenbank ausgesetzt ist und zugleich die Funktionalitäten kennen, die uns
helfen diese zu minimieren. Herkömmliche Authentisierung, Autorisierung und Auditing (die drei
„A“s der Security) ermöglichen mit Virtual Private Database und Label Security
Zugriffsbeschränkungen bis auf Zeilenebene. Mit Secure Application Roles kann u.a. dynamisch
der Zeitpunkt (z.B. nur Bürozeiten), die Art der Netzwerkverbindung (z.B. nur via TCPS) oder der
Zugriffsort (Client-IP) beschränkt werden. Dies schützt aber noch nicht vor Manipulationen oder
Diebstahl der Daten auf dem Transportweg oder beim direkten betriebsystemprivilegierten Zugriff
auf die Datenfiles resp. in das Shared Memory oder auf dem Backuproboter . Dazu bietet Oracle
Advance Security mit Transparent Data Encryption an, sowie Verschlüsselung der Backupsets
durch RMAN Backup Encryption via Secure Backup.
2.
Problematik
All diese Sicherheitskonzepte lassen ausser acht, dass (zu) hoch privilegierte Administratoren
dennoch auf die Daten zugreifen können. Dies weil ja jemand die entsprechenden
Konfigurationen machen muss und dem zufolge meist nach belieben wieder ausschalten kann.
Die hohen Rechte werden aber nur zu Installationszeit der Software oder beim Zugreifen auf den
Datadictionary benötigt, das hat mit den Applikationsdaten nichts zu tun. Dies wurde aber von
Oracle nicht berücksichtigt, sodass jemand der vollen Dictionaryzugriff hat ebenfalls vollen
Datenzugriff hatte. Die kritischen Privilegien sind die ANY Systemprivilegien
•
•
•
•
•
•
SELECT ANY TABLE
UPDATE ANY TABLE
DELETE ANY TABLE
INSERT ANY TABLE
EXECUTE ANY PROCEDURE
…
Viele dieser Privilegien sind an Rollen gebunden, und somit an den Datenbankadministrator
vergeben, damit diese ihrer Arbeit nachkommen können. Im Weiteren ist das SYSDBA Privileg
vorhanden, welches diese ANY Privilegien per default besitzt und von denen sie auch nicht
weggenommen (revoke) werden können. Für die meisten Fälle könnte auf das SYSOPER Privileg
ausgewichen werden, welches alle Systemfunktionen hat wie SYSDBA ausser drop/create
database und Einschränkungen beim Recovery.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 1 / 8
Für folgende Komponenten ist eine SYSDBA Verbindung aber unabdingbar:
•
•
•
•
Recovery Manager (RMAN) für Backup und Recovery
Data Guard (DG) für Datenververfügbarkeit
Real Application Clusters (RAC) für Service Verfügbarkeit
Automatic Storage Management (ASM) für Storage Management
Somit wird man in den meisten Umgebungen nicht darum herumkommen, die Verbindung als
SYSDBA zu ermöglichen.
3.
Ziele
Mit dem Produkt Database Vault will Oracle:
1. Den Zugriff von DBAs auf Applikationsdaten unterbinden
2. Verhindern, dass der Applikations DBA Zugriff auf andere Applikationsdaten hat
und die Datenbank manipulieren kann
3. Kontrolle darüber wer, wann auf welche Applikationsdaten zugreifen kann
Dies soll mit einer strengen Unterteilung der Pflichten (Separation of duty) geschehen.
4.
Verfügbarkeit
Database Vault ist aktuell für Oracle 10.2.0.3 und auch als Packport für 9.2.0.8 via Oracle
Technet (http://www.oracle.com/technology/software/products/database_vault/index.html)
verfügbar. Nach der Installation ist das Produkt nicht unter DBA_REGISTRY ersichtlich sondern
nur unter v$option.
SQL> SELECT value
2 FROM v$option
3 WHERE parameter = 'Oracle Database Vault';
VALUE
---------------------------------------------------------------TRUE
5.
Database Vault Funktionalität
Für die Lösung der oben genannten Problematiken und um die Ziele zu erreichen hat Oracle eine
neue Option, die Database Vault (Tresor), eingeführt. Es wurde eine neue Ebene für die
Autorisierung eingeführt. Objekte können dadurch auch von Benutzern mit dem ANY Privileg
nicht mehr gelesen und manipuliert werden, indem alle DML und DDL Statement abgefangen
und überprüft werden bevor sie zur Ausführung gelangen. Dies wird durch definierbare Realms
(Bereiche) gemacht, die Zugriffe welche mittels ANY Privilegien gemacht werden zusätzlich
prüfen.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 2 / 8
5.1 Komponenten
Damit eine Aufteilung der Aufgaben funktioniert (Datenbankadministrator ist verantwortlich für
die Datenbank und der Applikationsverantwortliche für die Daten), darf der DBA natürlich diese
Realms nicht verwalten können. Dafür werden bei der Installation bereits drei wichtige Realms
definiert und geschützt.
•
•
•
Database Vault Account Management
o Für User und Profile Mamagement
Oracle Data Dictionary
o Für Catalog Schemas (SYS, SYSTEM, SYSMAN, MDSYS,…)
Oracle Database Vault
o Für Database Vault Schemas (DVSYS, DVF, und LBACSYS)
Zusätzlich werden neue geschützte Rollen erstellt:
•
•
•
•
DV_OWNER (Database Vault Owner Role)
o höchste Rechte auf das DVSYS Schema
o besitzt DV_ADMIN, DV_SECANALYST Rollen
DV_ADMIN (Database Vault Configuration Administrator)
o Execute Recht auf DVSYS.DBMS_MACADM (access control
configuration)
o besitzt DV_SECANALYST Rolle
DV_SECANALYST (Database Vault Security Analyst)
o Select Recht auf DVSYS schema objects
o kann Konfigurationen prüfen
o Kann Reports lesen und Database Vault monitoren
DV_ACCTMGR (Database Vault Account Manager)
o Erstellt und unterhält Datenbank Accounts und Profiles (ausser das
Schema DVSYS)
o CREATE | DROP | ALTER USER
o CREATE | DROP | ALTER PROFILE
Bei der Installation von Database Vault werden zwei Accounts abgefragt die mit den Rollen
DV_OWNER und DV_ACCTMGR versehen werden. Diese beiden User werden die Verwaltung
von Database Vault und das Usermanagement anstelle des DBAs machen. Damit aber der
Datenbankadministrator nicht einfach das Passwort eines dieser Benutzer ändern kann, wird das
ALTER/CREATE USER Kommando abgefangen (durch eine Command Rule). Dies darf nur noch
durch den Account-Manager durchgeführt werden (also NICHT der DBA!).
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 3 / 8
5.2 Flussdiagramm
Im nachfolgenden Diagramm ist der Ablauf für das Ausführen eines SQL Statements mit Database
Vault aufgezeigt.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 4 / 8
5.2.1 System Privileg für die Ausführung?
Das Ablaufdiagramm zeigt, dass jegliche SQL Statements die ausgeführt werden, mindestens die
Command Rule Engine durchlaufen müssen. Diese Integration der erweiterten Autorisierung
wurde direkt im Oracle Binary integriert und ist somit nicht mehr zu umgehen.
5.2.2 Object in einem Realm definiert?
Ein Realm definiert einen Bereich mit Objekten für welche eine weitere Autorisierung stattfindet,
wenn mit einem ANY Privileg darauf zugegriffen wird. Bei der Autorisierung können Benutzer
oder Rollen angegeben werden, welche als Owner oder Participants gelten. Die Autorisierung
kann dabei durch ein Rule Set bedingt durchgeführt werden.
Der Realm ist noch nicht eingeschalten wenn keine Objekte darin enthalten sind.
-- Create Realm / Role: DV_OWNER or DV_ADMIN
DBMS_MACADM.CREATE_REALM(
realm_name => 'Scott Schema Realm',
description => 'Realm for all SCOTT Objects',
enabled => 'YES',
audit_options => 1);
-- Add Objects
DBMS_MACADM.ADD_OBJECT_TO_REALM(
realm_name => 'Scott Schema Realm',
object_owner => 'SCOTT',
object_name => '%',
object_type => '%');
5.2.3 Owner oder Participant des Realms?
Ein Realm Owner kann keine neuen Benutzer zum Realm hinzufügen, dies muss der
DV_OWNER oder DV_ADMIN machen:
DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'Scott Schema Realm',
grantee => 'SYSTEM',
auth_options => 0); -- 0 Participant / 1 Owner
Ein Realm Participant kann auf die Objekte mit den normalen Standardrechten von Oracle
zugreifen. Ein Realm Owner kann diese Rechte direkt oder durch Rollen einem Participant
zuteilen (grant ) oder wegnehmen (revoke).
5.2.4 Autorisierung durch Rule Set?
Ein Rule Set definiert verschiedene Rules welche für die Autorisierung bei Realms, Command
Rules und Secure Application Role benutzt werden können.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 5 / 8
DBMS_MACADM.CREATE_RULE_SET(
rule_set_name => 'ScottSecure',
description => 'Only SSL Connection allowed',
enabled => 'YES',
eval_options => 1, --ALL
audit_options => POWER(2,1), --Audits whenever the rule set is used
fail_options => 1,
fail_message => NULL,
fail_code => NULL,
handler_options => NULL,
handler => NULL);
Eine Rule wird innerhalb eines Rule Sets definiert. Je nach Einstellung (ALL oder ANY) evaluiert
ein Rule Set nur zu TRUE wenn alle Rules TRUE zurückgeben, oder entsprechend, wenn
mindestens eine Rule TRUE zurückgibt.
-- Create a Rule with a default factor
DBMS_MACADM.CREATE_RULE(
rule_name => 'SecureClientConnection',
rule_expr => 'GET_FACTOR(''Network_Protocol'') = ''tcps''');
-- Add Rule to the Ruleset
DBMS_MACADM.ADD_RULE_TO_RULE_SET(
rule_set_name => 'ScottSecure',
rule_name => 'SecureClientConnection',
rule_order => 2,
enabled => 'YES');
Factors sind eigentlich Variabeln, wie z.B. die Client-IP Adresse. Die Zuweisung dieser Variabeln
kann entweder pro Zugriff oder beim Eröffnen einer Session geschehen.
DBMS_MACADM.CREATE_FACTOR(
factor_name => 'Network_Protocol',
factor_type_name => 'Authentication Method',
description => 'Network protocol begin used for communication',
rule_set_name => NULL,
get_expr => NULL,
validate_expr => 'UPPER(SYS_CONTEXT(''USERENV'',''IP_ADDRESS''))',
identify_by => 1,
--By Method
labeled_by => 0,
--By Self
eval_options => 0,
--By Session
audit_options => POWER(2,0),
--Always audits
fail_options => POWER(2,0)); --Shows an error message.
5.2.5 Evalutaion des Rule Set erfolgreich?
Je nach Einstellung des Parameters (eval_option bei DBMS_MACADM.CREATE_RULE_SET) TRUE
wenn alle oder mindestens eine der Rules erfüllt.
5.2.6 Command rule vorhanden die einschränkt?
Eine Command rule kann ein SELECT, ALTER SYSTEM, DDL oder DML Befehl auf ein oder
mehrere Objekte zur Laufzeit autorisieren. Die Einschränkungen können auf Schema oder
Objekte davon gemacht werden. Ausserdem kann eine Command rule helfen, auch dem [email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 6 / 8
Owner den Zugriff auf seine Daten zu verbieten. Für ihn wirkt nämlich die Prüfung des Realms
nicht!
DBMS_MACADM.CREATE_COMMAND_RULE(
command => 'CREATE USER',
rule_set_name => 'Can Maintain Accounts/Profiles',
object_owner => '%',
object_name => '%',
enabled => 'YES');
So besteht die Möglichkeit, Command Rules so zu setzen, dass sich niemand mehr an die
Datenbank anmelden kann. Geschieht dies, muss Database Vault deinstalliert werden um wieder
einen Zugriff zu erhalten. Aus den gemachten Tests geht hervor, dass es möglich ist, die
Datenbank mit einem Binary aus einem ORACLE_HOME zu starten, welches die Database Vault
Option nicht installiert hat.
6.
Installation
Die Installation von Database Vault wird mit dem Oracle Universal Installer (OUI) gemacht.
Zu berücksichtigen gibt es, dass nebst neuen Binaries (mit der Command Rule Engine codiert) per
default auch keine SYSDBA Zugriffe mit diesem ORACLE_HOME mehr gemacht werden können.
Das Passwortfile wird mit Option
nosysdba=y
neu erstellt, ebenfalls sind keine OS authentisierten User (OPS$) mehr möglich.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 7 / 8
Damit wieder mit SYSDBA verbvunden werden kann (z.B. RMAN Backup) muss das Passwortfile
wieder neu erstellt werden:
orapwd file=<File> password=<PW> nosysdba=n
Dabei bleiben die Database Vault Sicherheitsfunktionen immer noch aktiv (auch für den
SYSDABA), nur die SYSDBA–Anmeldung ist wieder möglich. Vorgängige SYSDBA User müssen
wieder privilegiert werden.
Beim Upgrade der Datenbank von10.2.0.2 auf 10.2.0.3 musste Database Vault ausgeschaltet
werden.
7.
Fazit
Oracle Database Vault bringt nicht allzu viele neuen Funktionen, die meisten waren vorher auch
schon bekannt. Das Spezielle aber ist die Implementierung der Command Rule Engine in das
Binaryprogramm, somit sind ANY Privilegien nicht mehr dasselbe (ANY != ANY). Durch diese
neue Schicht ist es möglich, auch Benutzer, welche oftmals Restriktionen umgehen konnten,
abzufangen. Das heisst, Objektzugriffe können weiter geschützt werden, auch für die
höchstprivilegierten Benutzer wie ein SYSDBA. Durch das Vorhandene GUI
(http://<host>:<port>/dva) können die zum Teil recht aufwändigen Konfigurationen sehr
einfach und schnell gemacht werden. Interessant ist sicher, dass das Konzept auch auf bestehende
Applikationen transparent angewendet werden kann, wenn diese das Usermanagement innerhalb
Oracle belassen.
Viel Erfolg beim Einsatz von Trivadis-Know-how und einen sichern Betrieb ihrer
Datenbankumgebungen wünscht Ihnen
Konrad Häfeli
Trivadis AG
Papiermühlestrasse 73
CH-3014 Bern
Internet: www.trivadis.com
Tel:
Fax:
Mail:
+41-31-928 09 60
+41-31-928 09 64
[email protected]
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.06.2007 . Seite 8 / 8
Herunterladen