Datenbank-Administration mit personalisierten Accounts Markus Behrendt Bayer Business Services GmbH Leverkusen Schlüsselworte: Oracle Internet Directory, Enterprise User Einleitung Die Administration von Oracle Datenbanken wird häufig mit administrativen Accounts wie sys und system durchgeführt. Dies ist in größeren Umgebungen aus sicherheitstechnischen Gründen, wie der Nachvollziehbarkeit von Systemänderungen oder bei Aufgabenwechsel eines Administrators, nicht gewollt. Mit der Enterprise User Security (EUS) ist es möglich, ein zentralisiertes Usermanagement für Administratoren ohne weitere Lizenzkosten einzurichten. In dem Vortrag berichte ich über meine Erfahrungen bei der Implementation einer Datenbank-Administration mit personalisierten Accounts. Rahmenbedingungen Firmeninterne Sicherheitsrichtlinien fordern für administrative Tätigkeiten die Verwendung von personalisierten Accounts. Mithilfe dieser ist es möglich, eine Nachvollziehbarkeit der DBA-Tätigkeiten zu realisieren. Desweiteren ist es nötig, ein Rechtemanagement zu etablieren mit der Möglichkeit, dass es ermöglicht bei Abteilungswechsel eines DBAs die Rechte zentral zu entziehen oder zu vergeben. Ein regelmäßiges Ändern von sys und system Passwörtern kann realisiert werden, da diese User nicht mehr für die Anmeldung an eine Datenbank benötigt werden. Zudem ist die Verwendung von personalisierten Accounts eine Arbeitserleichterung für die Administratoren, da sie keine Passwörter mehr nachschlagen müssen, sondern ihren Usernamen und ihr persönliches Passwort auf allen Datenbanken beim Zugriff mit jeglichem Tool verwenden. Aus historischen Gründen sind die Datenbanken über eine große Anzahl von Domänen verteilt. Die Domänen haben größtenteils heute keine funktionale Bedeutung mehr, werden jedoch in der Namensauflösung und in Datenbank-Links und somit in vielen Applikationen verwendet. Als letzte Rahmenbedingung sei die Anforderung an eine sehr hohe Verfügbarkeit genannt, da das System ebenfalls weltweit zur Namensauflösung verwendet wird.
Generelle Funktionsweise der Enterprise User Zur Verwendung der Enterprise User Funktionalität wird in jeder Datenbank ein sogenannter globaler User und eine globale Rolle erstellt. Zusätzlich wird ein Oracle Internet Directory (OID) benötigt. In diesem Directory werden die Informationen gehalten, die für ein Mapping von Usern und Rollen im OID zu den globalen Usern und globalen Rollen in der Datenbank nötig sind. Bei einem Connect an die Datenbank erfolgt dann die Prüfung von Username und Passwort zuerst gegen die bestehenden Datenbankuser und im zweiten Schritt gegen die im Directory vorhandenen User. Dabei wird das verschlüsselte Passwort vom OID an die Datenbank gesendet, die dann die Korrektheit des Passwortes prüft. Hochverfügbarkeit des Oracle Internet Directories Als Hochverfügbarkeitslösung wurde eine Konfiguration mit einem IAS-Cluster und einem davor geschalteten Load-Balancer gewählt. Die Metadata Repository Datenbank wurde in eine RAC-Datenbank installiert. Für interkontinentale Zugriffe sind wegen der negativen Auswirkungen der Latenz weitere Internet Directories an anderen Standorten nötig. Der Abgleich der Repositories erfolgt mit Hilfe eines speziellen Replizierungstool (Directory Integration Toolkit - DIT). Installation des Oracle Internet Directories Die Installation der Hochverfügbarkeitslösung ist zweigeteilt. Zum einen wird zuerst die RAC Datenbank mit der Companion CD in der Version 10.2 und aktuellen Patchstand aufgebaut. In diese Datenbank wird dann mit Hilfe des Metadata Repository Creation Assistent (mrca) das Repository in der Datenbank installiert. Als zweiter Schritt erfolgt die Installation der Infrastructure Komponenten. auf beiden Systemen, die über einen Load Balance eine hohe Verfügbarkeit gewährleisten. Auch diese Installationen müssen noch gepatcht werden. Erstellen weiterer Contexte innerhalb des Oracle Internet Directories Bei der Installation des Internet Directories wird eine Default-Domäne angegeben, die im OID einen sogenannten Context erzeugt. Dieser Context enthält verschiedene Informationen, die notwendig sind, um Oracle-spezifische Eigenschaften in einem LDAP-Directory zu speichern. Als Beispiel sei die Registrierung einer Datenbank genannt. Um weitere Domänen nutzen zu können, ist es notwendig, weitere Contexte anzulegen. Dazu erzeugt man mit dem Directory Manager eine neue Domäne mit der create like Funktion. Einen vollständigen Context generiert man zuerst als Textfile mit dem Programm flattenlst.pl : perl flattenlst.pl -i oidsubscribercreate.lst -o context_template.txt Mit dem Programm ldifmigrator ist es möglich, die Domänen im erstellten Textfile auszutauschen:
ldifmigrator input_file="context_template.txt " output_file="firma2com.txt" s_subscriberobjectclass="domain" s_subscribernamingattribute="dc" s_subscribername= firma2" s_subscriberparentdn="dc=com" s_subscriberdn="dc=firma2,dc=com" s_rootoraclecontextdn="cn=oraclecontext" s_oraclecontextdn="cn=oraclecontext,dc=firma2,dc=com" s_oraclecontextparentdn="dc=firma2,dc=com" s_currentuserdn="cn=orcladmin" s_groupsearchbase="cn=groups, dc=firma2,dc=com Danach lädt man das geänderte Textfile mit folgendem Befehl wieder in das OID: ldapmodify -h "oidhost" -p "389" -D "cn=orcladmin" -w passwort" -c -f "firma2com.txt Die Erstellung der Contexte muss für alle benötigten Domänen durchgeführt werden. Bei der Erstellung weitere Contexte sollte man wissen, dass viele Oracle Tools nur eine Root- Domäne und eine weitere Hierachie-Ebene unterstützen. Daher kann die vorgesehene Webseite zur Useradministration (http://<oidhost>:7778/oiddas) nicht mehr verwendet werden. Es ist daher notwendig, ein Usermanagement zum Anlegen von EUS Benutzern im OID selbst zu entwickeln. Modul zur Useradministration Oracle stellt in den Metalink Notes 277770.1, 277771.1, 277775.1, 312063.1, 334939.1 eine Reihe von Beispiel-PL/SQL-Prozeduren zur Verfügung, mit denen über das DBMS_LDAP Package User und Gruppen im OID angelegt, gelöscht und geändert werden können. Mit diesen Beispielen lassen sich Packages entwickeln, die über eine APEX-Applikation das Usermanagement ermöglichen. Wichtig ist, dass alle User in allen benötigten Domänen angelegt werden, da es für User einer Domäne nicht möglich ist, von einer Datenbank einer anderen Domäne authentifiziert zu werden. Registrieren der Datenbank im OID Nachdem die Administratoren im OID eingepflegt sind, müssen im nächsten Schritt die Datenbanken im OID registriert werden. Dazu muss eine Datei namens ldap.ora für die Datenbank erreichbar sein, mit der Information, wo das OID abgefragt werden kann. Beispiel ldap.ora: DEFAULT_ADMIN_CONTEXT = "dc=firma1,dc=com"
DIRECTORY_SERVERS= (OID-Hostname:389:636) DIRECTORY_SERVER_TYPE = OID Abb. 1: Registrierung der Datenbank im OID Eine silet-registrierung ist mit folgendem Befehl möglich: dbca -silent -configuredatabase -sourcedb <source database sid> -sysdbausername <user name with SYSDBA privileges> -sysdbapassword <password for sysdbausername user name> -registerwithdirservice true -dirserviceusername <user name for directory service> -dirservicepassword <password for directory service > -walletpassword <password for database wallet > Globale User und Rollen in der Datenbank anlegen Als nächster Schritt legt man Enterprise User und Rollen in der Datenbank an. Enterprise User und Rollen werden durch das Schlüsselwort IDENTIFIED GLOBALLY gekennzeichnet. CREATE USER FIRMAADMINUSER PROFILE "DEFAULT" IDENTIFIED GLOBALLY AS '' DEFAULT TABLESPACE "USERS" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK; GRANT CREATE SESSION TO "FIRMAADMINUSER"; CREATE ROLE "FIRMADBAROLE" IDENTIFIED GLOBALLY;
GRANT "DBA" TO "FIRMADBAROLE"; Mapping der globalen User mit den Usern im OID Im letzten Schritt erfolgt das Mapping der User oder Rollen im OID mit den zuvor angelegten globalen Usern und globalen Rollen in der Datenbank. Das Mapping erfolgt mit dem Enterprise Security Manager. Auch dieses Tool zeigt die erstellten Domänen in verwirrender Weise. Abb. 2: ESM User Mapping Abb. 3: ESM Role mapping
Auswirkungen auf die Applikation Bei einem Connect an die Datenbank mit einem globalen User meldet sich die Datenbank bei show user mit dem globalen User der Datenbank. Um den wirklichen Benutzer abzufragen, ist die Funktion sys_context zu verwenden. SQL> connect userid@musterdb Enter password: Connected. SQL> show user USER is "FIRMAADMINUSER" SQL> select sys_context('userenv','external_name') from dual; cn=userid,cn=users,dc=firma2,dc=com Bei Anmeldungen von Usern, die weder Datenbank-User noch OID-User sind, wird die Meldung ORA-28273 zurückgegeben und nicht wie erwartet ORA-1017. SQL> connect user@musterdb Enter password: ERROR: ORA-28273: No mapping for user nickname to LDAP distinguished name exists. Warning: You are no longer connected to ORACLE. SQL> connect userid@musterdb Enter password: ERROR: ORA-01017: invalid username/password; logon denied Das Recht sysdba kann nicht an einen Enterprise-User gegranted werden. Dies ist in der Regel auch nicht notwendig, da Stoppen und Starten der Datenbank von dem Datenbankrechner aus über Skripte erfolgt, die zusätzlich Aufgaben ausführen wie z.b. das Setzen von Blackouts. SQL> grant sysdba to FIRMAADMINUSER; grant sysdba to FIRMAADMINUSER * FEHLER in Zeile 1: ORA-01997: GRANT failed: user 'FIRMAADMINUSER' is identified externally
Fazit Die Enterprise-Userfunktionalität ist für die administrativen Accounts eine kostengünstige zentrale Lösung, um eine personalisierte Anmeldung durchzuführen. Eine Ausdehnung auf weitere Usergruppen ist möglich, sie hat jedoch zwei Nachteile. Erstens: Eine Anmeldung an die Datenbank ist abhängig von der Verfügbarkeit des OID. Zweitens: Die unübersichtliche Domainstruktur erschwert bei vielen Usern und vielen Gruppen die Useradministration. Für Administratoren sind diese Nachteile nicht so gravierend, da eine Administration immer noch über die User sys und system möglich ist. Zum anderen ist die Anzahl der Administratoren in der Regel überschaubar. Andere Nutzergruppen sollten eher Provisioning Tools wie das Oracle Identity Management nutzen, das allerding weitere Lizenzkosten erfordert. Kontaktadresse: Markus Behrendt Bayer Business Services GmbH C 152/2 4.15 51368 Leverkusen, Deutschland Telefon: +49(0)214-30 52179 Fax: +49(0)214 30 9623967 E-Mail markus.behrendt@bayerbbs.com Internet: www.bayerbbs.com