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. info@trivadis.com. 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. info@trivadis.com. 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!). info@trivadis.com. 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. info@trivadis.com. 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. info@trivadis.com. 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 Schema- info@trivadis.com. 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. info@trivadis.com. 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 Tel: +41-31-928 09 60 CH-3014 Bern Fax: +41-31-928 09 64 Internet: www.trivadis.com Mail: konrad.haefeli@trivadis.com info@trivadis.com. www.trivadis.com. Info-Tel. 0800 87 482 347. Datum 01.06.2007. Seite 8 / 8