1 Hintergrund

Verursacht durch die Veranderung unsererUnternehmen hin zu immer dynamische-ren Organisationseinheiten, die das Inter-net und die Extranets zum Aufbau von Be-ziehungen mit den verschiedensten Part-nern nutzen, werden hohe Anforderungenan die zugehorige Infrastruktur gestellt. Soist es notwendig, Partnern Zugriff auf be-stimmte unternehmensinterne Ressourcenzu gewahren. Insbesondere im Entwick-lungsbereich, zukunftig aber auch in vielenanderen Bereichen werden Teams zur Be-waltigung bestimmter Aufgaben unterneh-mensubergreifend zusammenarbeiten. DieUnternehmensgrenzen „verschwimmen“,Unternehmen entwickeln sich immer mehrzu virtuellen Organisationen.Die Notwendigkeit, zu diesem Zweck

interne Ressourcen wie Netzwerke undDaten zu „offnen“ und einen flexibleren

Zugriff zu ermoglichen, geht einher mit ge-steigerten Sicherheitsanforderungen. Diesegehen uber den Schutz von herkommlicherHardware und Software hinaus und umfas-sen u. a. Gebaudesicherheit, Identitats-schutz und Markenschutz.Hierzu notwendig ist ein unternehmens-

weites, teilweise auch unternehmensuber-greifendes, zentral koordiniertes Berechti-gungsmanagement. Mit diesem sollen& der Zugriff auf Ressourcen transparent

gesteuert, kontrolliert und dokumentiertwerden,

& die Implementierung und Umsetzungdurchgangiger Sicherheitsrichtlinienmoglich werden und

& durch die starkere Aufgabenteilung eineSenkung von Entwicklungskosten und-zeiten erreicht werden [Davi02].

Wird einer Person ein Recht in bzw. an ei-ner Ressource gewahrt, so erfolgt diesdurch einen zweistufigen Prozess, beste-hend aus Authentification und Authoriza-

tion. Beim Authentification-Prozess wirdeiner physischen Einheit (Nutzer) eineelektronische Einheit (Nutzer-Account)durch Verfahren auf Basis von Biometrie,Passwortern und Public Key Infrastructure(PKI) zugeordnet. Die Zuordnung vonRechten in bzw. an einer Ressource erfolgtdann zu dieser elektronischen Einheitdurch den Authorization-Prozess mittelsMechanismen wie Access Control Lists(ACL) und Role Based Access Control(RBAC).

Wahrend die im Rahmen des Authentifi-cation-Prozesses eingesetzten Verfahrenweitgehend etabliert und verbreitet sind,gilt dies nur zum Teil fur die im Authoriza-tion-Prozess eingesetzten Mechanismen.Die Forschung hierzu begann in den 1960erund 1970er Jahren und fokussierte sichschnell auf Mandantory Access Control(MAC) [FeKC03, 39f.] und DiscretionaryAccess Control (DAC) [FeKC03, 35f.]. Alsder dominierende Mechanismus in den

WIRTSCHAFTSINFORMATIK 46 (2004) 4, S. 289–294

Die Autoren

Volker HerwigLars Schlabitz

Dr. Volker HerwigLars SchlabitzSiemens AGInformation and Communication NetworksHofmannstr. 5181359 Munchen{Volker.Herwig | Lars.Schlabitz}@siemens.com

UnternehmensweitesBerechtigungsmanagement

Kernpunkte

Ein zentral koordiniertes Berechtigungsmanagement ist vor allem fur Unternehmen, die inkooperativen Prozessen mit anderen Unternehmen zusammenarbeiten, eine wichtige Vor-raussetzung. Entscheidend ist dabei die Berucksichtigung der mit der „�ffnung“ einher-gehenden Sicherheitsbedurfnisse der Unternehmen.

& Das zentral koordinierte Berechtigungsmanagement ist fur Unternehmen zum Schutz ihrerRessourcen unverzichtbar.

& Um das Berechtigungsmanagement uber das rein technische Umfeld hinaus auch direktan den Unternehmenszielen orientiert betrachten zu konnen, bedarf es erweiterter Kon-zepte – wie die Role Based Access Control (RBAC).

& Erste Softwareprodukte, die das RBAC-Konzept fur ein zentral koordiniertes Berechti-gungsmanagement nutzen, sind auf dem Markt und einsatzreif.

Stichworte: Berechtigungsmanagement, Rechteverwaltung, Identification-Management,Authentifizierung, Autorisierung

WI – Innovatives Produkt

1990er Jahren und wohl auch der Zukunftetablierte sich die Role Based Access Con-trol (RBAC) [Sand01, 1]. Vorangetriebenwird RBAC vom National Institute ofStandards and Technology (NIST).

2 Praxiserfahrungen

Beide Stufen des Prozesses erfolgen jedochgerade in heterogenen Umgebungen starkdifferenziert und nicht untereinander abge-stimmt. Beispielsweise werden in verschie-denen Systemen fur denselben Nutzer ver-schiedene Nutzer-Accounts angelegt. DieVerbindungen eines solchen Nutzer-Ac-counts zu der dazugehorigen naturlichenoder juristischen Person werden oft nur ein-malig abgebildet und �nderungen, die sichdurch den Lebenszyklus der Person erge-ben, werden in den verschiedenen Systemennicht oder nur ungenugend gepflegt. Ebensoverhalt es sich mit den Rechten, die demNutzer-Account zugeordnet sind. Diesewerden einmalig zumZuordnungszeitpunkt

vom Ressourcenverantwortlichen gepruftund danach oft nie wieder verandert. Soexistieren teilweise in Systemen Nutzer-Ac-counts, die Personen zugeordnet sind, diedas Unternehmen langst verlassen haben.Dadurch erhoht sich der Umfang und

oft auch die Anzahl der lokalen Datenban-ken und Verzeichnisse, in denen diese In-formationen gespeichert werden. Sie ent-halten haufig inkonsistente, nicht mehr inihrer Qualitat und Aktualitat beschreibbareDatenbestande. Hierdurch erhoht sich derKlarungsbedarf, das Fehlerpotential steigt,es ergeben sich Sicherheitslocher, die Ak-zeptanz seitens der Nutzer sinkt und dieVerwaltungsaufwande fur mehrfach (proSystem) durchzufuhrende, wiederkehrendeRoutinetatigkeiten steigen stark an. Das di-rekte Einsparungspotenzial, das durch denWegfall dieser Mehraufwande entsteht, istaber selten unmittelbar erkennbar, da dieKosten seitens der Serviceanbieter oder derSystembetreuer nicht explizit ausgewiesenwerden.Besonders in Großunternehmen außert

sich das beschriebene Problem durch die

komplexe Heterogenitat der Infrastruktur.Ihr wird nach heutigem Erkenntnisstandauf drei Arten begegnet:– Homogenisierung der Systemlandschaftan sich (mit der Gefahr, von einem oderwenigen Systemlieferanten extrem ab-hangig zu werden);

– wechselseitige Systemintegrationen (mitteils undurchsichtigen Einzelprozessenohne gesamtheitlichen Losungsansatz.)

– Bildung von Synchronisationsebenendurch Extraktion der Systemintegratio-nen in eine Meta-Schicht zur transparen-ten Abbildung der Datenflussprozesse(was lediglich zur Verlagerung der kom-plexen Relationen zwischen den Unter-nehmensressourcen, nicht jedoch zurOptimierung der Relationen fuhrt.)

Rein technisch hat sich in den letzten Jah-ren gezeigt, dass die Kopplung der entspre-chenden Unternehmensressourcen nurproprietar erfolgen kann. Standards setzensich nur langsam durch, es bedarf individu-eller Konnektoren, die abhangig vom Stan-dardisierungsgrad und der Schnittstellen-stabilitat der Ressourcen / Systeme beiWeiterentwicklungen teuer in Entwicklungund Betreuung werden konnen.Die Schnittstellen- und Synchronisa-

tionsproblematik wird aber durch die zu-nehmende Verbreitung standardisierterSchnittstellensprachen wie Directory Ser-vices Markup Language (DSML), eXtensi-ble Access Control Markup Language(XACML) und Service Provisioning Mark-up Language (SPML) vereinfacht. Diesedienen als erste Hilfsmittel fur performan-tes Provisioning, einer speziellen Form derSynchronisation.Dennoch fehlt in den Unternehmen eine

uber alle Unternehmensressourcen wirken-de gemeinsame Rechteverwaltung. Auchdie ubergreifende betriebswirtschaftlicheSicht auf die im Unternehmen zur Ver-fugung stehenden Ressourcen und ihresGe- bzw. Missbrauchs ist nicht zu finden.Um in diesem Sinne Berechtigungsver-

waltung uber das rein technische Umfeldhinaus auch direkt an den Unternehmens-zielen orientiert betrachten zu konnen, be-darf es erweiterter Konzepte – wie dieRole Based Access Control (RBAC) in Zu-sammenhang mit Provisionierung – undihrer konsequenten Umsetzung.

3 Ansatz

In leichter Abstraktion kann das als Basisder Role Based Access Control (RBAC)dienende Rollenkonzept als eine Weiter-

WIRTSCHAFTSINFORMATIK 46 (2004) 4, S. 289–294

physischeEinheit

elektronischeEinheit

Rechte in/anRessourcen

Authentification Authorization

Bild 1 Rechtezuordnung

Users Roles

Sessions

Permissions

UserSessions

SessionRoles

PermissionAssignment

UserAssignment

Role Hierarchy

Bild 2 Role-Based-Access-Control-Modell

290 Volker Herwig, Lars Schlabitz

entwicklung des Gruppenkonzepts angese-hen werden, bei dem eine Anzahl von Nut-zern zu Nutzergruppen zusammengefasstwird [Seuf02, 3].Beim Rollenkonzept wird die Rechte-

zuordnung komplett vom Nutzer entkop-pelt, indem zwischen Nutzer und Rechteneine Art Zwischenschicht – die Rolle – ein-gefugt wird. Diese Zwischenschicht be-schreibt die Schnittstelle zwischen den be-triebswirtschaftlichenAnforderungen (z. B.durch die Geschaftsprozesse formuliert),denen ein Nutzer zur Ausubung seiner Ta-tigkeit gerecht werden soll, und den dafurbenotigten Ressourcenzugriffen. Dazubundelt die Rolle eine Anzahl von Rechten(Permissions), die nun ausschließlich uberRollen den Nutzern zugeordnet (Permis-sion Assignment) werden. Aufgrund vonEigenschaften wie Arbeitsplatzbeschrei-bungen und Kompetenzblattern (siehehierzu auch Rollendefinition) erhaltenNutzer die Mitgliedschaft in benotigtenRollen (User Assignment). Wahrend derAusubung bestimmter Tatigkeiten befindetsich der Nutzer in Sessions, in denen er ineiner oder mehreren Rollen aktiv ist.Zur Vorbereitung von Nutzerzugriffen

auf Ressourcen sind beim Einsatz des Rol-lenkonzepts verschiedene Vorarbeiten er-forderlich.Bei der Umstellung auf die rollenbasierte

Unterstutzung des Authorization-Prozes-ses mussen die Ressourcen bzw. Systeme,an denen sich ein Nutzer autorisiert (d. h.in denen er eine Session eroffnet), mit denentsprechenden Rechten versorgt werden.Dieser Versorgungsprozess wird auch Pro-visionierung genannt. Provisioniert werdenInformationen uber Nutzer (Accounts)und deren Zuordnung zu Rechten entspre-chend den zu versorgenden Systemen. Die-se Provisionierungsinformationen sind Er-gebnis des technischen Rollenauflosungs-prozesses, der auf Basis der in einemRollenmanagementsystem vorgehaltenenRollen erfolgt.Ein mogliches (und sehr effektives) zu

provisionierendes System kann dabei einSingle-sign-on-System sein, das Nutzer-Sessions fur eine Vielzahl von Ressourcenverwaltet. Diese mussen hierdurch nichtindividuell mit Rechten versorgt werden.Untersuchungen haben gezeigt, dass sich

mit den durch die Verwendung eines sol-chen Rollenkonzepts moglichen Verein-fachungen enorme Kosteneinsparungen er-reichen lassen [FeBJ91; Davi02]. DieseKosteneinsparungen ergeben sich vor allembei der Administration. So ist es bei Ver-wendung eines Rollenkonzepts wesentlicheinfacher, einem neuen Mitarbeiter Zu-

griffsrechte auf Ressourcen zu gewahren.Wahrend es bisher notwendig war, ihm injeder Applikation einzeln Rechte zu ge-wahren, mussen ihm nun lediglich Rollen,die bereits mit den entsprechend dazuge-horigen Rechten verknupft sind, zugewie-sen werden. Auf die gleiche Art und Weisevereinfacht sich auch die Integration vonPartnern, was durch die notwendigen se-lektiven Zugange bisher besonders aufwan-dig war. Durch zeitnahes De-Provisionie-ren (automatischer Rechteentzug in denbetroffenen Ressourcen infolge des Entzie-hens von Rollen) sinkt die Zahl von inakti-ven Nutzer in Ressourcen bzw. Systemen.Doch auch auf Seite der Nutzer lassen

sich Vorteile realisieren. Im Wesentlichenergeben sie sich aus der Reduzierung deroft hohen Zahl an Passwortern durch dieeinfache Ermoglichung von Single-sign-onim Rahmen des Authentication-Prozesses.Um die Administration der Rollen weiter

zu vereinfachen, wird allgemein die Ver-wendung von Rollenbaumen, mit denenHierarchien zwischen Rollen abgebildetwerden, als geeignet angesehen [Guir95;ScMJ01, 7f.; FeKC03, 37ff.].

4 Rollendefinition

Ein wichtiger, wenn nicht der wichtigsteTeil bei Einsatz des RBAC-Modells imRahmen des Authorization-Prozesses istdie Definition der notwendigen Rollen undihre Verknupfung sowohl zu Rechten aufRessourcen als auch ihre Verknupfung zuNutzern. Durch die angesprochene Ver-wendung von Hierarchien und die damitverbundene Nutzung von Vererbungs-und Aggregationsmechanismen vereinfachtsich die spatere Administration der Rollenund deren Verknupfungen.

Die Definition von Rollen setzt meistbei den Nutzern an und betrachtet bei-spielsweise ihre(n)& Funktion am Arbeitsplatz (z. B. Soft-

wareentwickler, Hardwareentwickler,Content-Manager),

& Position im Unternehmen (z. B. Service-manager, Projektmanager),

& Status im Unternehmen (z. B. internerMitarbeiter, Businesspartner),

& Organisationsmitgliedschaft (z. B. Abt.Rechnungswesen C1, Abt. ControllingE3),

& speziellen, meist temporaren Aufgaben(z. B. Projektmanager, Projekt-Review-Partner).

Um die durch ein zentrales Berechtigungs-management erreichbar erscheinenden Ver-

einfachungen realisieren zu konnen, ist beider Definition von Rollen zu beachten,dass sie keinen haufigen �nderungen un-terliegen. So kann der Administrationsauf-wand fur die Rollen auf ein Maß be-schrankt werden, das eine Senkung der Ge-samtadministrationskosten erreicht.

Im Folgenden soll ein einfaches Beispieleiner Rollenhierarchie fur den Entwick-lungsbereich vorgestellt werden. Aus-gangspunkt ist die Rolle des Arbeitneh-mers im Unternehmen, an die sich Rechte,beispielsweise fur den Zugriff auf ein Zeit-erfassungssystem, einen Standardcomputerund den Zugang zu einem Parkplatz knup-fen. Aus der Rolle Entwicklungsabteilung,die in der Rollenhierarchie der Rolle Ar-beitnehmer untergeordnet ist, ergibt sichbeispielsweise das Recht auf den Zugangzu bestimmten Gebauden. Die speziellenRollen Entwickler und Entwicklungsleiterweisen jeweils wieder spezielle Rechte aufRessourcen auf, usw.

So genau wie in diesem Beispiel Rollendem Entwicklungsbereich zugeordnet wur-den, lassen sich Rollen jedoch nicht immerinhaltlich abgrenzen und bestimmten Berei-chen zuordnen. Zudem stellen diese inhalt-lichen Bereiche keineswegs abgeschlosseneSysteme dar. So lasst sich unser BeispielEntwicklungsbereich mit einem Rollen-bereich fur Unterschriften verknupfen, indem die Unterschriftsberechtigungen (ab-hangig von Volumen und Geschaftsre-levanz) als Rollen modelliert sind. Derdargestellte Projektleiter konnte in seinerbetrieblichen Funktion die Rolle Unter-schriftenkreis und damit alle Unterschrifts-berechtigungen besitzen. Ein Softwareent-wickler erhalt dagegen im Rahmen seinerAufgaben nur eine Unterschriftsberechti-gung vom Typ 2, die fur Softwarebestellun-gen bis 1.000 a gilt. Weitere Verknupfun-gen zu hier nicht dargestellten Rollenberei-chen sind moglich.

Ausgehend von den dargestellten An-satzpunkten zur Rollendefinition lasst sicheine Vielzahl von Rollen modellieren. In ei-ner extremen Auspragung konnte die An-zahl der Rollen sogar auf gleichem Niveauliegen, wie die Kombination aus der An-zahl der Nutzer und der Anzahl an Rech-ten auf Ressourcen. Erwartungen, die be-reits durch Praxisbeispiele bestatigt wur-den, gehen aber davon aus, dass die Anzahlan Rollen in einem rollenbasierten Systembei 3–4% der Anzahl der Nutzer liegt[ScMJ01]. Dies ist jedoch von Branche undGroße des Unternehmens abhangig. Bei ei-nem verantwortungsvollen Einsatz desRBAC-Modells entsteht also keinesfalls ei-ne unuberschaubare Zahl von verschie-

WIRTSCHAFTSINFORMATIK 46 (2004) 4, S. 289–294

Unternehmensweites Berechtigungsmanagement 291

densten Rollen, die nach einiger Zeit alleinaufgrund ihrer Anzahl enorme Adminis-trationskosten erfordern.

5 Einsatz

Der Einsatz des RBAC-Modells im Unter-nehmen ist in einen Gesamtzusammenhangeinzubetten, der sich folgendermaßen dar-stellt:& Verwendung eines Resource-Provisio-

ning-Systems fur das Access Manage-ment,

& das mit einem Meta Directory fur voll-standiges Identity Management inte-griert ist und

& zur Separierung von Benutzeradminis-tration und Rechteadministration einRole Management (RBAC) nutzt.

Dabei lassen sich drei Funktionsbereicheunterscheiden& Management,& Provisionierung und& Repository.Die Nutzer und ihre Identitaten werden ineinem zentralen Repository (Directory Ser-vice, beispielsweise DirX [Siem03]) verwal-tet. Dieses zentrale, unternehmensinterneRepository ubernimmt im Sinne einesMaster / Meta Directorys [Part02] die Syn-chronisation zwischen den verschiedenenunternehmensinternen Directorys und Da-tenbanken, in denen entsprechende Datenverwaltet werden. Damit bildet es den zen-tralen Kontrollpunkt fur die entsprechen-den Daten, wodurch ihre konsolidierteund so konsistente Verwaltung moglichwird.Die eigentliche Synchronisation und

Provisionierung von Systemen wird durch

ein Resource Provisioning System (bei-spielsweise DirXmetahub) ubernommen,das auf dem zentralen Repository aufsetzt.Das Management der Rollen und ihre

Verknupfung einerseits zu Nutzern undandererseits zu Rechten wird durch einRole and Access Management System (bei-spielsweise DirXmetaRole [Siem03]) reali-siert.

6 Identity und AccessManagement mit derDirXSolutions-Produktsuite

Ein erstes Produkt, das die Meta-Direc-tory-Technologie fur das Provisioning aufBasis von RBAC nutzt, ist das bereits er-wahnte DirXmetaRole von Siemens Infor-mation Communication Networks (ICN).Vollstandig RBAC-konform unterstutzt esdie grafische m-n-Zuweisung von Nutzernzu Rollen und Rollen zu Rechten.DirXmetaRole ist eine wesentliche Kern-

komponente der DirXSolutions-Produkt-suite. Es ermoglicht die zentralisierte platt-formubergreifende rollenbasierte Berechti-gungsadministration. Als Datenrepositoryverwendet DirXmetaRole den DirXServer,ein LDAP/X.500 Directory. Es enthalt allenotwendigen Daten, wie Nutzer, Rollen,Rechte (Permissions) und Konfigurations-daten.Als Synchronisations- und Provisionie-

rungskomponente dient DirXmetahub. Esautomatisiert einerseits die Synchronisa-tionsprozesse, die die Daten angebundenerDirectories (Human Ressources, Werks-schutz et al.) in den Directoryserver inForm von globalen Eintragen integrieren.DirXmetahub identifiziert, filtert undtransformiert einerseits also alle Informa-tionen aus den angeschlossenen Verzeich-nissen, die zu einem globalen Directoryein-trag gehoren, konsolidiert sie und stellt sieim Standardformat eines Meta Directoryzur Verfugung. Andererseits automatisiertDirXmetahub die Provisionierungsprozes-se, die Accessinformationen in die unter-schiedlichen zu provisionierenden Zielsys-teme transportieren und validieren. AlsKonnektoren zu den einzelnen Zielsystemedienen Agenten. Die Workflowdaten furdie Provisionierungsprozesse, die auch alsDirXmetahub-Workflows bezeichnet wer-den, werden imDirXServer gespeichert.Bild 4 stellt die wesentlichen Komponen-

ten des Identity- und Access-Managementsmit den Produkten der Siemens DirX-Solu-tion-Produktsuite dar. Die einzelnen Funk-tionalitaten, Identitys und Accessinforma-

WIRTSCHAFTSINFORMATIK 46 (2004) 4, S. 289–294

Arbeitnehmer

Entwicklungsabt.

Entwickler

SoftwareentwicklerHardwareentwickler

Entwicklungsleiter

WebDesignerDatenbank-entwickler

USB Typ 1

Unterschriftenkreis

USB Typ 2 USB Typ 3

EntwicklungsbereichUnterschriftenbereich

Bild 3 Beispiel einer Rollenhierarchie

DirectoryService

Users, identities

DirXmetaRoleRole-basedaccess management,Provisioning

Provisioning

Agent Agent Agent Agent Agent

ADS/NT/Exchange

SAP R/3 Database WebServices others

DirXmetahub

Bild 4 Identity- und Access-Management-Komponenten

292 Volker Herwig, Lars Schlabitz

tionen zu managen, konnen neben derManagementoberflache auch durch eineWeboberflache genutzt werden.Zur Abbildung des rollenbasierten un-

ternehmensweiten Autorisationsmodellsverwendet DirXmetaRole die folgende En-titaten: Nutzer (User), Rolle (Role), Recht(Permission), Account, Gruppe (Group),Zielsysteme (Target System).Der DirXmetaRole-Account bezieht

sich auf den im speziellen Zielsystem be-nutzte Nutzer-Account. Ein DirXmetaRo-le-Nutzer kann Accounts in verschiedenenSystemen haben. Die DirXmetaRole-Gruppe bezieht sich auf eine im Zielsystemgultige Gruppe.

Der Prozess, die fur einen Nutzer not-wendigen Nutzer-Accounts und derenGruppenmitgliedschaften fur samtliche an-geschlossene Zielsysteme zu generieren,nennt sich Rollenauflosung. Dazu werdendie dem Nutzer zugewiesenen Rollen aus-gewertet. Selbstverstandlich kann das auch– z. B. bei Entzug einer Rolle oder bei ver-anderten Rollendefinitionen – zum Entzugvon Gruppenmitgliedschaften oder zumDeaktivieren/Loschen von Nutzer-Ac-counts fuhren.Im Rollenauflosungsprozess unterstutzt

DirXmetaRole Rollenhierarchien (sieheAbschnitt 4) und Rollenparameter sowohlauf den Nutzer als auch auf die Zielsyste-me bezogen. Rollenparametern (z. B. furStandort oder Landerspezifika) dienen da-bei der exakten Bestimmung von Grup-penmitgliedschaften in Zielsystemen.Um das Ergebnis des Rollenauflosungs-

prozesses dann auf die spezifischen Ziel-system-Entitaten abzubilden kommt derDirXmetahub zum Einsatz. Wie ein Ziel-system provisioniert wird, ist dazu imDirXmetaRole in so genannten Policyshinterlegt. So ist sichergestellt, dass auchtatsachlich die Zielsystemspezifika abgebil-det werden.Durch die flexiblen Integrationsmoglich-

keiten der Directorytechnologie in die IT-Landschaft stellt DirXmetaRole ein idealesMigrationswerkzeug dar. Es konnenschrittweise die verschiedensten Systeme(Identity-Management-Quellsysteme, mitAccess-Information zu provisionierendeZielsysteme) angeschlossen werden, ohnebestehende Ablaufe zu behindern. Dazukonnen neben den systemspezifischenRechten auch lokale Policys und Regelnder Systeme abgebildet werden, um siedann im zweiten Schritt systemubergrei-fend weiterzuentwickeln und methodischauf Provisionierung umzustellen. Auf dieseWeise wachst bottom-up das konsequentedem RBAC-Modell sauber folgende Be-

rechtigungsmanagement, bringt top-downuber Rollendefinitionen betriebswirtschaft-liche Anforderungen in die IT-Landschaftein und lost eine Vielzahl der teuer admi-nistrierten technischen Prozesse ab.Erste Nutzungserfahrungen zeigen, dass

sich das Berechtigungsmanagement wegvon administrativen IT-Tatigkeiten hin zueiner echten geschaftlichen Aufgabe ent-wickelt. Die unternehmensintern genutztenBerechtigungen haben einen Abstraktions-grad erreicht, der mehr Geschafts(prozess)-bezogen und damit wesentlich losgelostervon einzelnen IT-Anwendungen ist. Flexi-bel wachsende und wechselnde Geschafts-felder, schnelllebiges E-Business, Portale

und Single-sign-on verlangen nach effek-tivst funktionierendem Berechtigungs-management.Dabei zeigt sich die durch DirXSolu-

tions gewahrleistete einzigartige Durch-gangigkeit, durch den gesamtheitlichenZusammenschluss der mit dem zentral ko-ordinierten Berechtigungsmanagement ver-bundenen Komponenten, als unvergleichli-cher Vorteil.

Einerseits werden einfacheWhite und Yel-low Pages (Verzeichnisse uber Mitarbeiter,Partner, Lieferanten, Kunden, etc.) hoch-aktuell gehalten. Andererseits empfind-lichste Security Daten und Anforderungensorgfaltig behandelt (Single-sign-on, Public-

WIRTSCHAFTSINFORMATIK 46 (2004) 4, S. 289–294

AccessManagement

(DirXmetaRole)

AccessManagement

(DirXmetaRole)

Access Control

(Target System)

Access Control

(Target System)

Access Control(Target System)

Group GroupGroup Group

User Role Permission

ResourceResource Resource

User Role Permission

ResourceResource Resource

AccountAccount

Access Management(DirXmetaRole)

Bild 5 Entitaten des DirXmetaRole-Authorization-Modells

Abstract

Corporate Access Control Management

The central coordination of access control management is crucial especially for companiesthat are engaged in cooperative processes with other companies. Most critical is to respectthe security needs that arise with the “opening” towards other partners.

& The central coordination of access control is indispensable in order to protect the compa-ny’s resources.

& If access control management is to be oriented directly towards the corporate goals incontrast to a merely technical view there is a need for extended concepts – like role basedaccess control (RBAC).

& The first software products that make use of the RBAC-concept for a centrally coordinatedaccess control management are available and can be used in practice.

Keywords: Access Control Management, Rights Management, Identification Management,Authentification, Authorization

Unternehmensweites Berechtigungsmanagement 293

Key-Infrastruktur, E-Business). Umfangrei-ches Netz-, User- und Berechtigungsmana-gement erganzt die Anwendungspalette(Benutzerprofile, Ressourcenmanagement,Enterprise-Information-Management, Pro-visioning). Die Durchgangigkeit reicht biszu bestimmten Geschaftsprozessen, wieCall-Center-Kundenbetreuung, Vertriebs-und CRM-Unterstutzung, in denen ein Be-rechtigungsmanagement die zentrale Infor-mationsbasis ist.Fur alle drei Funktionsbereiche zum Ein-

satz des RBAC-Modells im Unternehmen(siehe Abschnitt 5) existieren auch Soft-wareprodukte anderer Anbieter. Diese Soft-wareprodukte bedienen jedoch segmentiertausschließlich einzelne Bereiche. Es fehltdie integrative Losung uber alle Funktions-bereiche. DirXSolutions ist ein Konzept, ei-ne Losung und ein abgestimmtes Toolkon-glomerat, das diese Integration verwirk-licht. In ihr liegt der Erfolg, sowohl fur dieITals auch fur die Unternehmen als ganzes.

7 Ausblick

Vor dem Hintergrund der eingangs dar-gestellten Notwendigkeit, interne Ressour-cen wie Netzwerke und Daten zu offnenund einen flexibleren Zugriff zu ermogli-chen, liegt die Herausforderung vor allemim Authorization-Prozess.Modelle wie das hier vorgestellte RBAC,

die eine abstrakte Zwischenschicht als In-strument fur das Management der im Rah-men des Authorization-Prozesses anfallen-den Daten verwenden, sind gerade im Hin-blick auf die Administration dieser Datenklar im Vorteil.Wie dargestellt, setzt die Definition von

Rollen meist bei den Nutzern und ihrenbetrieblichen Bestimmungen an, oftmalswerden Rollen bereits im Rahmen vonProzesserhebungen aufgenommen. So istdie Rolle als abstrakte Zwischenschicht im-mer nahe an den betrieblichen Gegebenhei-ten, wodurch sich die Moglichkeit bietet,eine starker betriebswirtschaftliche Sicht indie IT im Unternehmen zu verankern.Vor allem die von unternehmensextern

kommenden Anforderungen, die sich durchPartnerschaften ergeben, sind die Ursacheein unternehmensweites Identity-Manage-ment als Grundlage fur ein unternehmens-weites Berechtigungsmanagement ein-zufuhren. Dabei wird oft ubersehen, dassdie Notwendigkeit hierzu schon seit lange-rem existiert. Doch wie bereits angespro-chen sind die hohen Kosten des fehlendenunternehmensweiten Berechtigungsmana-

gements meist nicht transparent, allerdingsauch die fur die Realisierung entstehendenAufwande unterschatzt.

Literatur[AlBa01] Aldous, J; Bankaitis, D.: Web Applica-

tions in the Microsoft .NET Framework. Micro-soft Press 2001.

[Davi02] Davis, D. M.: Secure Relationship Man-agement Solutions For Healthcare. Massachu-setts Health Data Consortium, 02/2002.

[Guir95] Guiri, L.: Role-based access control: anatural approach. In: First ACM Workshop onRole-Based Access Control. New York, USA,ACM Press 1995, S. 11–18.

[FeBJ91] Ferraiolo, D. F.; Barkley, J. F.; Jun, D. R.:A role-based access control model and referenceimplementation within a corporate Intranet. In:ACM Trans. Inform. Syst. Security 2 (1991) 1,S. 34–64.

[FeKC03] Ferraiolo, D. F.; Kuhn, D. R.; Chandra-mouli, R.: Role-Based Access Control. ArtechHause, Norwood 2003.

[Part02] Parthier, U.: Die Zukunft der Meta Direc-tories. IT Research 2002.

[Sand01] Sandhu, R.: Future Directions in Role-Based Access Control Models. MMS ConferenceProceedings, 2001.

[ScMJ01] Schaad, A.; Moffett, J.; Jacob, J.: TheRole-Based Access Control System of a Eur-opean Bank – A Case Study and Discussion.SACMAT 2001, 6th ACM Symposium on Ac-cess Control Models and Technologies. ACMpress, New York 2001.

[Seuf02] Seufert, S. E.: Der Entwurf strukturierterrollenbasierter Zugriffskontrollmodelle. In : In-formatik Forschung und Entwicklung (2002) 17,S. 1–11.

[Siem03] Siemens AG: DirX Solutions – TotallyIntegrated Identity Management. White Paper2003.