Enterprise User Security

von der Business Rolle bis in die Datenbank

Marcel Pils ACT IT-Consulting & Services AG

Niederkassel

Andre Lünsmann Barmenia Versicherungen

Wuppertal

Schlüsselworte

Identity & Access Management , Enterprise User Security, Oracle Unified Directory, Microsoft Active Directory, Oracle Identity Analytics, Oracle Virtual Directory, Oracle Internet Directory, Business Rolle, Oracle Datenbank, Authentifizierung, Autorisierung Enterprise Manager Plug-in for OUD

Einleitung

Der Vortag bezieht sich auf ein Identity und Access Management Projekt zur Implementierung einer zentralisierten Benutzerverwaltung für Oracle Datenbanken. Es werden die fachlichen Anforderungen erläutert, die betrachteten Lösungsvarianten dargestellt und auf besonderer Erfahrungen während des Proof of Concepts, der Definition der Business Rollen und der Produktivstellung eingegangen. Dieses Manuskript bietet einen exemplarischen Einblick in die Votragsinhalte.

Identity & Access Management (IAM)

Im Kontext eines Unternehmens existieren verschiedene Personengruppen, die mit unterschiedlichen Bedürfnissen zur Erfüllung Ihrer Aufgaben oder Anliegen mit den IT-Systemen des Unternehmens interagieren. Zu diesem Zweck werden ihnen für einen begrenzten Zeitraum als Benutzer bestimmter Anwendungen, Daten und IT-Ressourcen die benötigten Berechtigungen gewährt.

Die Verwaltung dieser technischen Identitäten unterliegt in Bezug auf die reale Identität einer Person einem natürlichen Lebenszyklus. Berechtigungen werden beantragt, geplant, überprüft, genehmigt, vergeben bzw. entzogen und in regelmäßigen Intervallen vom Management (Führungskräfte, Data Owner) überprüft und bewertet.

In der Verantwortung des Unternehmens liegt es, die dafür benötigten Prozesse in Übereinstimmung mit bestehenden Gesetzen und Regularien konsistent, verfügbar, verlässlich und nachvollziehbar zu gestalten. Es wird somit eine Identity & Access Management Lösung benötigt, die zu den Geschäfts-anforderungen des Unternehmens passt und den richtigen Personen zum richtigen Zeitpunkt hinrei-chende Zugriffsrechte auf die erforderlichen Ressourcen erteilt.

Ein umfassendes Identity und Access Management sollte unter Anderem folgende Anforderungen erfüllen:

• Alle Identitäten werden zentral verwaltet

• Keine Rechtevergabe außerhalb der zentralen Verwaltungsstelle

• Alle technischen Berechtigungen sind in Geschäftsregeln (Business Rollen) zusammengefasst

• Möglichkeit der bitemporalen Verwaltung von Identitäten, Rechte und Rollen

• Automatisierte Umsetzung (De-/Provisioning) von Berechtigungen und Identitäten

• Gewährleistung konsistenter Pflege der Identitäten, Rechte und Rollen

• Regelmäßiger Soll-Ist-Abgleich (Reconcilation) und Reporting

• Inkonsistenzen werden erkannt und behoben bzw. verhindert

• IDM Prozesse sind standardisiert, automatisiert und dokumentiert

• User Self Service zur Verwaltung von Identitäten und Berechtigungen

• Workflows zur Verwaltung der IAM relevanten Informationen (Genehmigung, Wiedervorlage, Implementierung, De-/Aktivierung, Rückmeldung an den Antragsteller)

• Revisionssicherheit in Bezug auf Bestand, Historie und Verarbeitung der IAM Informationen

• Nachweis zur Einhaltung von Compliance Anforderungen

• Nutzung von Single Sign On Mechanismen

Es gibt - leider - nicht das eine, richtige IAM. Jedes Unternehmen hat spezifische Prozesse, seine eigenen Historie und eine dementsprechend mehr oder weniger komplexe IT-Landschaft. Anspruchsvolle IAM Lösungen bestehen deshalb aus unterschiedlichen Komponenten, die je nach Bedarf eingesetzt, miteinander verzahnt und inhaltlich mit Leben gefüllt werden müssen.

Zur Realisierung einer zentralen IAM Verwaltung reicht es nicht aus, alle Identitäten in ein zentrales LDAP Verzeichnis zu migrieren. In gewachsenen Umgebungen müssen heterogene ID-Quellsysteme integriert und Regeln definiert werden, welche die vorhandenen technischen Identitäten auf ihre reale Identität der bezogenen Person mappen. Für eine bitemporale Abbildung von Identitäten und Berechtigungen werden Workflows benötigt, die nach erfolgter Genehmigung eines Antrages den IAM Datensatz für einen gegebenen Zeitraum speichern und die darin enthaltenen Berechtigungen für den definierten Gültigkeitszeitraum automatisiert aktivieren oder deaktivieren.

Je weiter man im Katalog der IAM Anforderungen voranschreitet, desto umfassender und komplexer werden die damit in Verbindung stehenden Herausforderungen und Implementierungsprojekte. Mit dem Umfang eines Projektes steigt aber auch die Gefahr, dass das angestrebte Ziel nicht erreicht wird. Die Herausforderung bei der Durchführung von IAM Projekten liegt darin, sie in geeignete Teilprojekte zu untergliedern und mit dem Blick auf das endgültige Ziel mit überschaubaren Ressourcen und Aufwänden Quick Win’s zu generieren und damit Schritt für Schritt den nächsten Reifegrad einer umfassenden IAM Lösung zu erreichen.

Projektanforderungen

Der Umfang des im nachfolgenden betrachteten IAM Projektes wurde bewusst begrenzt auf die Anbindung der im Unternehmen vorhandenen Oracle Datenbanken an das als zentrale Identitätsquelle definierte Active Directory und Auslagerung der Authentifizierung und Autorisierung personalisierter Datenbankbenutzer in das LDAP Verzeichnis. Die technischen Datenbankbenutzer, die für den Zugriff der Applikationen oder Schnittstellen benötigt werden, wurden außer Acht gelassen, da sich deren Zu-griffsrechte selten verändern und das Passwort nur im Ausnahmefall geändert wird. Sie können ggf. nachgelagert in das AD eingebunden werden, wenn mit der umgesetzten Lösung ausreichend Erfah-rungen bestehen. Als kleinster gemeinsamer Nenner aller Benutzerwerkzeuge sollte eine passwort-basierte Authentifizierung unterstützt werden. Zudem sollte die gewählte Lösung bei der Konsolidie-rung bestehenden Berechtigungsstrukturen sowie der Bildung von Geschäftsregeln (Business Rollen) unterstützen und Reports für Compliance relevante Audits generieren. Andere gewünschte IAM Merkmale wie einem Single Sign On, einem automatischen Provisioning und Reconcilation der Identitäten oder der Integration weitere Identitätsquellen wurden als zweitrangig bedeutsam bewertet und damit aus dem Projekt Scope herausgenommen mit dem Auftrag auf einer nachträgliche Erweiterung der gewählten Lösung zu achten.

Lösungsportfolio

Zur Realisierung der Projektanforderungen wurden in dem von Oracle angebotenen umfangreichen IAM Portfolio folgende Produkte identifiziert. Einschränkend muss man dabei allerdings die notwendigen Lizenzierungen beachten.

Abbildung 1: Zentralisiertes User-Management per EUS oder der OIM Lösung CUA4DB

Enterprise User Security ist ein Feature der Oracle Datenbank Enterprise Edition, das es der Datenbank ermöglicht, die zur Authentifizierung und Autorisierung benötigten Informationen anstelle des eigenen DB-Dictionary aus einem spezifischen LDAP Verzeichnis abzufragen. Zur

Implementierung dieses Verzeichnisdienstes bietet Oracle aufgrund der verschiedenen Zukäufe der letzten Jahre unterschiedliche Produkte an, die alle für sich bestimmte Vor- und Nachteile aufweisen und entweder als eigenständiges LDAP Verzeichnis oder auch als Proxy zu einem im Unternehmen bereits bestehenden LDAP Dienst eingesetzt werden können.

Bei der Centralized User Administration for Databases handelt es sich um eine von Oracle auf Basis des Oracle Identity Managers (OIM) erstellten Lösung. Als Krake in der Mitte führt sie auf Basis hinterlegter Policies proaktiv Änderungen an den in den angeschlossenen Datenbanken oder Applika-tionen hinterlegten Benutzer- und Berechtigungsinformationen durch. Die zur Authentifizierung und Authorisierung erforderlichen Informationen verbleiben in den angeschlossenen Systemen. Der OIM dient also als zentrale Verwaltungsinstanz, der seine Informationen mit den angeschlossenen Syste-men (Datenbanken, Anwendungen, LDAP Verzeichnisse) entsprechend abgleicht. Dieses mächtige Produkt bietet neben der Policy basierten Provisionierung und Reconcilation von Informationen auch einen User Self Service, Workflows, Reports und andere Features.

Abbildung 2: Oracle Identity Analytics (OIA)

Das Oracle Identity Analytics ist ein Produkt zur Unterstützung bei der Konsolidierung und Rezertifi-zierung bestehender Berechtigungsstrukturen. Auf Basis der importierten IAM Informationen fungiert dieses Produkt im Sinne eines Identity Warehouses. Es verfügt über Funktionalitäten für das Mining im Datenbestand, erstellt Vorschläge zur Bündelung von Zugriffsrechten und bietet Dashboards und Reports für ein Auditing der vergebenen Berechtigungen.

Nach erfolgter Bewertung dieser Lösungen anhand der gegebenen Projektziele fiel die Entscheidung auf die Durchführung von Proof of Concepts für den Einsatz der Enterprise User Security in Kombi-nation mit Oracle Identity Analytics.

Systemarchitektur für Enterprise User Security

Zur Umsetzung der Enterprise User Security können von Oracle verschiedene Produkte verwendet werden. Eines davon ist das Oracle Internet Directory, ursprünglich Oracle’s einziges LDAP Verzeichnis. Das OID benötigt zur Speicherung seiner Daten eine externe Oracle Datenbank und kann neben dem anzubindenden Active Directory auch keine weitere Identitätenquelle integrieren. Aus diesem Grund wurde im Projekt auf den Einsatz des Oracle Virtual Directories (OVD) gesetzt. Eine

schlanke Lösung, die im Sinne eines Proxies Informationen aus unterschiedlichen Quellen in einen eigenen virtuellen Verzeichnisbaum integriert.

Da das OVD aber ausschließlich externe Informationen mappt und nicht durch eigenständig verwaltete Daten anreichern kann, müssen alle zur Bereitstellung der EUS Funktionalität benötigten Informationen als sogenannter Oracle Context (siehe CTX in der Grafik) im Active Directory abgelegt werden. Da die Oracle Datenbank zur Ausführung der Benutzerauthentifizierung den Oracle Passwort-Hash mit dem im AD hinterlegten Passwort vergleicht, muss das im AD hinterlegt Benutzerpasswort in der Oracle Hash Variante verschlüsselt hinterlegt werden und bei jedem Passwortwechsel entsprechend aktualisiert werden.

Für die Umsetzung der EUS wurden also im Rahmen des POC folgende drei Änderungen am Active Directory angefragt:

• Schemaerweiterung für die Oracle Context Informationen

• Schemaerweiterung für ein zusätzlichen Passwort Attribut am Benutzerdatensatz

• Installation einer Passwortfilter DLL auf jedem AD Controller

Dies hat aufgrund der Bedeutung eines unternehmenszentralen Verzeichnisdienstes und den von der AD Administration geäußerten Bedenken für eine erhebliche Projektverzögerung geführt. Die Liste der Vorbehalte reichte von Support Problemen mangels Zertifizierung von Schemaerweiterung und Passwortfilter über Befürchtungen der Kollision mit anderen Schemaerweiterungen bis hin zu Betriebsfragen der Integration in den Windows Dateischutz und DLL Versionskontrolle.

Abbildung 3: EUS Architekturvarianten

Die einzige Alternative, die umfangreiche Schemaerweiterung für den Oracle Context aus dem AD auszulagern, war zu diesem Zeitpunkt der Aufbau einer eigenen OID Instanz ausschließlich für diesen Zweck. Ein Variante, die die zu betreibende Infrastruktur insbesondere unter Berücksichtigung von High Availability Anforderungen erheblich vergrößern würde.

Als dann jedoch in das OUD mit der Version 11.1.2.1 die EUS Unterstützung implementiert wurde, stand eine neue und schlanke Variante zur Verfügung, die Proxy- und Directory Server Funktionalitä-ten in einem kombiniert und aufgrund der Speicherung lokaler DataStores in Berkeley DB Files keine externe Datenbank benötigt. Mit dieser Architektur konnte der größte Schmerz der AD Administration beseitigt und ein neuer POC erfolgreich durchgeführt werden.

Abbildung von Business Rollen

Sollen die Benutzerrechte in Eigenverantwortung der Fachbereiche durch die jeweilige Führungskraft oder den Data Owner gepflegt werden, müssen für alle Nutzungsfälle die benötigten technischen Rechte (Resource Rolle) in verständliche, fachlich abstrahierte Business Rollen gekapselt werde. Folgt man dabei einer intuitiven Vorgehensweise, sind folgende Merkmale denkbar:

• Verschachtelungen und Verzweigungen

• Mehrfachzuordnungen

• Zuweisung von einzelnen Benutzern oder Organisationeinheiten

Die Definition dieser Mappings sollte zusammen mit den Resource Rollen zentral an einer Stelle erfolgen. Das Active Directory ist dafür bestens geeignet, da es alle aufgezählten Merkmale unterstützt.

Abbildung 4: Intuitive Abbildung von Business Rollen

Die Herausforderung besteht jedoch darin, dass eine Vererbung von Benutzerzuweisungen über mehrere AD-Gruppen von der Enterprise User Security nicht unterstützt wird und ein Enhancement der Funktionalitäten aktuell nicht geplant ist. Der jeweilige AD-User muss entweder direkt im OUD der jeweiligen Enterprise Role zugeordnet werden oder direkt Mitglied der AD-Gruppe sein, die im OUD der jeweiligen Enterprise Role zugeordnet wird.

Man muss also die Vor- und Nachteile abwägen und entscheiden, wo man das Mapping von Business Rollen auf technische Datenbankrechte/Rollen durchführt.

• Vorgelagert zum AD durch Abbildung im User Self Service was jedoch zu Konflikten bei Mehrfachzuordnungen führen kann.

• Nachgelagert im OUD beim Mapping auf entsprechende Globale Datenbank Rollen oder

• am Ende der Kette durch Zuweisung der Global Roles auf die Local Roles der Datenbank.

Im Projekt hat man sich für die letzte Variante entschieden also dem 1 zu 1 Durchschleifen der definierten Business Rollen bis auf die Globalen Datenbankrollen. Hauptgrund ist, dass man den Nutzern des User Self Services eine einfache, möglichst globale Rechtevergabe ermöglichen möchte. Das erfordert zwangsläufig, dass die Differenzierung erst später auf dem Weg zum AD stattfindet.

Monitoring der Infrastruktur

Für das Monitoring des Oracle Unified Directories bietet Oracle ein eigenes Plugin für den Enterprise Manager Cloud Control an, dessen kostenpflichtige Nutzung mit der Lizenzierung des „Management Pack Plus for Identity Management“ abgedeckt wird. Die Installation des Plug-in erfolgt über ein einf-aches Download und Deployment im Plug-ins Dialog des Enterprise Managers 12c. Beim Deployment für das OUD Server Montoring Target wird ausgewählt, ob es sich dabei um einen Proxy Server, einen Directory Server oder ein Replication Gateway handelt. Da der OUD in unserem Fall als Proxy Instanz aufgesetzt ist, wählt man hier den Proxy Server aus. Nach der Verteilung des Agenten auf den OUD Host sollte man einige Minuten warten bevor man mit dem Discovery der OUD Instanz fortfährt. Auf diese Weise wird gewährleistet, dass alle Metriken beim Agenten ankommen, bevor dieser genutzt wird. Wer das berücksichtigt, hat innerhalb von 15 Minuten eine funktionierende OUD Proxy Überwachung im Enterprise Manager implementiert.

Abbildung 5: Enterprise Manager Plug-in for Oracle Unified Directory

Mit 572 Metriken in 33 Gruppen bietet das OUD Proxy Plug-in eine Menge Informationen bezüglich Health State, Ressourcenverbrauch und Performance der Instanz wie auch der angebundenen Remote Verzeichnisdienste (in diesem Fall 3 AD Controller). Bei genauer Betrachtung fällt jedoch auf, dass lokale OUD LDAP Stores wie der für den Oracle Context vom Proxy Plug-in nicht überwacht werden. Ein naheliegender Workaround wäre ein zusätzliches Monitoring Target für die gleiche OUD Instanz mit den Eigenschaften eines Directory Server zu discovern. Ein solcher Versuch schlägt in der aktuel-len ersten Version des Plug-ins aber fehl. Der Agent erkennt, dass die OUD-Instanz als Proxy konfigu-riert ist und verteilt deshalb die benötigten Directory Server Metriken nicht. Nahezu alle Anzeigen des resultierenden OUD Directory Server Targets bleiben leer.

Es wurde beim Support ein Enhancement Request erstellt, der für das nächsten Release geplant ist. Ein konkretes Release Datum ist derzeit aber nicht bekannt.

Bug 18717725 : EM12C OUD PLUGIN - NEEDS TO MONITOR THE LOCAL LDAP DATA STORE

Ein vollständiges Monitoring des OUD ist mit dem Enterprise Manager Plug-in derzeit nicht möglich. Zumindest für die lokalen LDAP Stores des OUD und deren Replizierung müssen eigene Überwach-ungsskripte erstellt werden.

Indentifizierung des Enterprise Users im Session Kontext

Eine Authentifizierung des Login Users gegen das Active Directory erfolgt dann, wenn die Datenbank für EUS konfiguriert ist und der Login User nicht als lokaler (gewöhnlicher) Datenbankbenutzer exis-tiert. Wird für diesen Enterprise User seitens der DBAs kein eigener „private Schema User“ erstellt, taucht er in der Datenbank als der eine „Shared Schema User“ auf. Die Information über den eigent-lichen AD-User geht dem DBA in den v$session Informationen verloren. Da zur Reduzierung der administrativen Aufwände die Nutzung eines gemeinsamen Shared Schema Users angeraten ist, muss man diese Kontext-Information mittels Logon Trigger in die v$session Informationen übernehmen.

CREATE OR REPLACE TRIGGER EUS_LOGON_TRIGGER

AFTER LOGON ON DATABASE

declare

l_client_info varchar2(4000);

l_ad_user varchar2(4000);

BEGIN

DBMS_APPLICATION_INFO.READ_CLIENT_INFO(l_client_info);

if length(l_client_info) > 0 then

l_client_info := ', '||l_client_info;

end if;

l_ad_user := sys_context('userenv','external_name');

l_ad_user :=

regexp_substr(sys_context('userenv','external_name'),'[^.*(cn=)][^(,)]*');

DBMS_APPLICATION_INFO.SET_CLIENT_INFO(l_ad_user||l_client_info);

End;

Auditierung von Enterprise Usern

Da der Enterprise User als Shared Schema User in der Datenbank agiert, stellt sich die Frage, ob die Information über den AD-User auch beim Auditing verloren geht. Der folgende Testfall zeigt, dass das nicht der Fall ist. Es muss lediglich über den Audit Session Key der zugehörige Login Datensatz aufgerufen werden. Dieser enthält die benötigten Informationen.

SQL> select sid, username, schemaname, client_info

from v$session

where username in

('GLOBAL_TEST_USER', 'LOCAL_TEST_USER') order by 1

# Enterprise User Connect

SQL> conn "240531"

Enter password:

Connected.

SQL> show user

USER is "GLOBAL_TEST_USER"

# Activate DML Auditing

SQL> conn / as sysdba

SQL> audit insert table, delete table by "GLOBAL_TEST_USER" by access;

Audit succeeded.

# Execute DML

SQL> conn "240531"

SQL> insert into table1 values (1,'eins');

1 row created.

SQL> delete from table1;

1 row deleted.

Verweise

• Enterprise User Security Dokumentation http://docs.oracle.com/cd/E11882_01/network.112/e10744/toc.htm

• Oracle Unified Directory Dokumentation http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

• Enterprise Manager Plug-in for OUD Dokumentation http://docs.oracle.com/cd/E24628_01/nav/plugins.htm

• Directory Services Integration with Database Enterprise User Security http://www.oracle.com/technetwork/database/security/dirsrv-eus-integration-133371.pdf

• MOS 1376365.1: MASTER NOTE FOR ENTERPRISE USER SECURITY

• MOS 18717725 – RFE BUG: EM12C OUD PLUGIN - NEEDS TO MONITOR THE LOCAL LDAP DATA STORE

# Check Audit Entries

SQL> select a.sessionid, a.entryid, aa.action, aa.name, a.userid, a.comment$text

from sys.audit_actions aa, sys.aud$ a

where a.action# = aa.action

and a.userid='GLOBAL_TEST_USER'

order by sessionid desc,entryid desc;

Kontaktadresse:

Marcel Pils

ACT IT-Consulting & Services AG

Rudolf-Diesel-Straße, 18

D-53859 Niederkassel

Telefon: +49 (0) 228-97125 0

Fax: +49 (0) 228-97125 40

Mobil: +49 (0) 173-730 8854

E-Mail marcel.pils@actgruppe.de

Internet: www.actgruppe.de

Kontaktadresse:

Andre Lünsmann

Barmenia Versicherungen

Barmenia-Alle, 1

D-42119 Wuppertal

Telefon: +49 (0) 202-438 2662

Fax: +49 (0) 202-438 032662

E-Mail andre.luensmann@barmenia.de

Internet: www.barmenia.de