![[Abb. 1]](64-1.gif)
Abbildung 1: Prinzipielle Arbeitsweise der RBAC-Werkzeuge
Die BMW Group entwickelt derzeit zahlreiche Web-basierte IT-Anwendungen für Endkunden, Lieferanten, Vertriebspartner und Konzernmitarbeiter. Die zugehörige Benutzer- und Rechteverwaltung soll basierend auf Infrastruktur-Plattformen für E-Business-Anwendungen bereitgestellt werden. Derzeit verwaltet die zentrale BMW Administration mehr als 200 000 Zulassungen von Mitarbeitern, Vertriebspartnern und Fremdkräften. Die Berechtigungen betreffen weit über 1 000 Serversysteme und circa 1 500 Anwendungssysteme. Durch den Zuwachs und die stärkere Verflechtung der Anwendungen im E-Business-Umfeld wächst der Bedarf nach übergreifenden Berechtigungslösungen, wie sie ein rollen- oder policy-basierter Ansatz bieten kann.
Bei der BMW Group wurde daher ein Projekt initiiert, um ein unternehmensweites, plattformübergreifendes Rollenmodell zu konzipieren (vgl. [1]) und die am Markt verfügbaren Werkzeuge zu sichten. Dieser Beitrag stellt die wichtigsten Werkzeuge für Betriebssysteme sowie in einem zweiten Teil für Web- und Applikationsserver kurz vor und zeigt die Randbedingungen ihrer Positionierung in einer bestehenden Access-Management-Architektur.
Die klassische identitätsbasierte Verwaltung von Benutzerrechten arbeitet mit einer direkten Zuordnung der Berechtigungen von Benutzern oder Benutzergruppen (Subjekten) zu Objekten (Dateien, Methoden, Drucker etc.). Aufgrund der schwachen Bündelung ergibt sich eine Vielzahl von zu verwaltenden Berechtigungen. Die rollenbasierte Rechteverwaltung (RBAC-Ansatz) bündelt die Berechtigungen eines Benutzers aufgabenbezogen in Rollen. Zusätzlich kann man normalerweise die Objekte noch in Ressourcen bündeln.
Die Aggregation von Elementen mit dem Ziel, die Anzahl der Beziehungen zwischen den Elementen zu reduzieren, ist charakteristisch für den rollenbasierten Ansatz. Mit Blick auf die Rechteverwaltung bedeutet dies, dass Administratoren notwendige Rechteänderungen an wenigen Rollen und Ressourcen statt an einer Vielzahl betroffener Gruppen und Objekte vornehmen.
Diese Vereinfachung lässt sich allerdings nur umsetzen, wenn man die Eigenschaften in einem Rollenmodell geeignet festlegt (siehe [1]) und über ein Werkzeug verfügt, das die Aggregation unterstützt und die Abbildung des Modells auf die Berechtigungssysteme automatisiert.
Bei mehreren zehntausend Benutzern führt die herkömmliche Rechteverwaltung bei Betriebssystemen zu einer kaum nachvollziehbaren Zuordnung der Berechtigungen, schlechter Wartbarkeit und unzureichender Aktualität. Im Web-Umfeld ist die Zahl der potenziellen Nutzer noch weitaus höher.
Zentrales Ziel des übergreifenden, rollenbasierten Ansatzes ist eine Vereinfachung und Verbesserung der bestehenden benutzer- und gruppenbasierten Rechteverwaltung. Einzelne Berechtigungssysteme sollen durch ein übergreifendes, rollenbasiertes System abgelöst werden, das eine hierarchische verteilte Delegation von Administrationsaufgaben ermöglicht. Ein weiteres Ziel ist die Wiederverwendung übergreifend definierter Rollen über unterschiedliche Anwendungen und Systeme hinweg. Hierzu ist die Konsolidierung bestehender Gruppen und Berechtigungen sowie die Definition neuer Rollen notwendig (vgl. [3]).
Da Unternehmen in zunehmendem Maße Web-Portale für Mitarbeiter, Kunden und Lieferanten aufbauen, die eine personalisierte Sicht auf Anwendungen und Informationen bieten sollen, besteht auch dort ein entsprechender Bedarf, die Personalisierung mit den Zugriffsrechten zu verknüpfen.
----------Anfang Textkasten----------
Eine Rolle bündelt die Kompetenzen, die zur Bearbeitung von Aufgaben innerhalb eines IT-gestützten Geschäftsprozesses benötigt werden. Sie beschreibt somit, für welche Aufgabe man mit welchen Rechten auf welche Ressourcen zugreift.
Eine Gruppe fasst hingegen nur eine Menge von Benutzern zusammen, ohne dass damit unmittelbar etwas über deren Berechtigungen oder Kompetenzen ausgesagt würde.
Der Begriff Kompetenz unterscheidet sich von "Berechtigung" oder "Zugriffsrecht" im Wesentlichen dadurch, dass Kompetenzen aus der fachlichen Sicht abgeleitet werden und nicht aus der technischen Sicht des zugrunde liegenden Berechtigungssystems.
In unterschiedlichen Facetten wird der Begriff Policy gebraucht. Im Kontext "Access Management" handelt es sich um eine Menge von Regeln, die systemübergreifend oder systemspezifisch für den Zugangs- und Zugriffsschutz vereinbart werden. Policies können somit auch Rollenbeschreibungen enthalten.
Der Begriff Zielsystem wird hier für ein IT-System gebraucht, auf dem IT-Anwendungen ablaufen oder das Daten bereitstellt. Zielsysteme können beispielsweise Betriebssysteme, Datenbanken, Web- oder Application-Server sein.
Ein Berechtigungssystem ist der Systemanteil eines Zielsystems, der die Rechteprüfung durchführt, etwa der Betriebssystem-Kern.
Die Rechteverwaltung ist die konzeptionelle und administrative Zuordnung von Subjektrechten, zum Beispiel die Zuordnung von Benutzern zu Gruppen. Die rollenbasierte Rechteverwaltung übernimmt die Umsetzung der definierten Aufgaben in abstrakte, von Berechtigungssystemen unabhängige Kompetenzen.
Die Rechtezuweisung ist die Verknüpfung der definierten Subjektrechte mit den entsprechenden Objekten, also z.B. das Zuweisen von Zugriffsrechten an einem Objekt. Über die rollenbasierte Rechtezuweisung erfolgt die Abbildung der abstrakten Rollen und Kompetenzen auf die Benutzer(gruppen) und technischen Zugriffsberechtigungen des jeweiligen Zielsystems.
Die Rechteprüfung ist generell die Prüfung der Berechtigung zum Zeitpunkt einer Zugriffsanforderung eines Subjekts auf ein Objekt.
----------Ende Textkasten----------
Ein geeigneter Ansatzpunkt, um plattformübergreifend Änderungen der Zugriffsrechtepolitik durchzusetzen, ist die Betriebssystemebene. Da Betriebssysteme bis auf wenige Ausnahmen keine generische Unterstützung für rollenbasierte Zugriffskontrolle bieten, muss man zur Realisierung jedoch auf zusätzliche (betriebssystemnahe) Werkzeuge zurückgreifen.
RBAC-Werkzeuge setzen eine zentrale rollenbasierte Rechteverwaltung auf verschiedenen angebundenen Zielsystemen um, indem sie die Einstellungen der Zugriffsrechte auf den Zielsystemen geeignet anpassen und nachverfolgen.
Die Techniken, die diese Werkzeuge einsetzen, sind in der Regel recht einfach. Sie übersetzen die Sprache des Rollenmodells in die Sprache des jeweiligen Zielsystems, ohne hierbei allerdings Wunder zu vollbringen. Machbar ist nur, was das jeweilige Zielsystem selbst umsetzen kann.
Im Prinzip setzen alle Werkzeuge auf einem Trägersystem auf und binden von dort aus die Berechtigungssysteme verschiedener Zielsysteme – Betriebssysteme oder Anwendungen – ein (vgl. Abb. 1). Auf dem Trägersystem wird die Rollenverwaltung und die rollenbasierte Rechteverwaltung durchgeführt (Markierung 1 in der Abb.).
Abbildung 1: Prinzipielle Arbeitsweise der
RBAC-Werkzeuge
Man kann zwischen Werkzeugen unterscheiden, die die Rechtezuweisung (2) oder Rechteprüfung (3) auf dem Zielsystem selbst durchführen, und solchen Werkzeugen, welche die Prüfung zentral durchführen. Bei letzteren muss das Zielsystem bei jeder Zugriffsanforderung in der Berechtigungsdatenbasis des Werkzeugs nachfragen. Dieser Ansatz hat Nachteile, weil hierzu der Zugriffskontrollmonitor des Zielsystems modifiziert werden muss (in der Regel im Betriebssystemkern) und besondere Vorkehrungen zur Gewährleistung der Verfügbarkeit von Trägersystem und Netzanbindung nötig sind.
Anwendungen lassen sich über eine Programmierschnittstelle (API) des RBAC-Systems anbinden, sofern sie nicht als Zielsystem über einen speziellen Adapter verfügen. Üblicherweise steht dann ein LDAP-Abfragedienst zur Verfügung, damit Anwendungen Rollen- und Rechteinformationen auslesen können.
Grundsätzlich gilt, dass man eine veränderte Zugriffsrechtepolitik, wie sie RBAC darstellt, auf einem Betriebssystem nur umsetzen kann, indem man die Zugriffskontrolle des Betriebssystemkerns modifiziert, oder – wie die RBAC-Werkzeuge – versucht, die neue Politik auf den Zielsystemen mit den dortigen "Bordmitteln" durchzusetzen.
Das Zielsystem selbst arbeitet nicht mit der Rollen-Sicht, die Rolleneigenschaften bleiben ihm verborgen. Das Werkzeug bildet die Semantik des rollenbasierten Ansatzes auf die Semantik der Zugriffskontrolle des Zielsystems ab. Dabei gehen zwangsläufig höherwertige Modellierungsmöglichkeiten verloren: Man kann auf dem Zielsystem nichts umsetzen, was sich dort nicht auch mit den etablierten Mitteln der Zugriffskontrolle umsetzen ließe. Der große Vorteil ist die automatische Umsetzung dieser komplexen Abbildung durch das Werkzeug.
Mit Betriebssystemen, die zumindest Benutzergruppen und Zugriffskontrolllisten (ACLs) kennen, lassen sich verschiedene auch nicht-triviale Zugriffsrechtepolitiken und die grundlegenden Eigenschaften eines Rollenmodells umsetzen. Komplexe Möglichkeiten von Rollenmodellen, wie (echte) Vererbung oder Wechselwirkungen zwischen Rollen zur Laufzeit, sind aber nicht darstellbar.
Die wesentlichen Funktionen der RBAC-Werkzeuge sind die Rollenbereitstellung, -verwaltung und rollenbasierte Rechteverwaltung einschließlich der Rechtezuweisung übergreifend für verschiedene Arten von Betriebssystemen, Datenbanken und so weiter.
Darüber hinaus bieten RBAC-Werkzeuge:
Zusatzprodukte innerhalb der jeweiligen Produktfamilie sorgen in der Regel für ein übergreifendes Single Sign-On über mehrere Zielsysteme und Anwendungen sowie für Methoden und Werkzeuge zur Definition von Rollen.
Kompetenzen und Ressourcen können bei RBAC-Werkzeugen sehr vielfältig und komplex definiert werden: Kompetenzen sind beispielsweise Zutritts-, Zugangs- oder Zugriffsrechte, aber auch anwendungsspezifische Berechtigungen und Systemprivilegien. Ressourcen können IT-Systeme, Geräte, Dateien, Verzeichnisse, IT-Dienste und -Anwendungen sowie anwendungsspezifische Elemente sein.
Nicht jedes Zielsystem kann die ganze Bandbreite von Rolle- und Rechteverwaltung bis hin zur Rechtezuweisung nutzen. Für Zielsysteme, bei denen das RBAC-Werkzeug direkt das Berechtigungssystem anbinden kann, stehen alle Funktionsstufen zur Verfügung. Dies sind primär Betriebssysteme und solche Anwendungen, die die Rechtezuweisung auf Betriebssystemebene auswerten, im Sinne der RBAC-Anbindung offene Anwendungen.
Anwendungen, mit eigener Rechteverwaltung/-zuweisung können nur die Rollenverwaltung nutzen, im Sinne der RBAC-Anbindung sind dies gekapselte Anwendungen. Falls es hierfür allerding ein API seitens des RBAC-Tools gibt, stehen wieder alle Nutzungsmöglichkeiten offen. Microsoft Office wäre nach dieser Definition zum Beispiel eine "offene" Anwendung, da es direkt auf Windows NT aufsetzt und somit die Rechteeinstellungen des NT-Betriebs- und Dateisystems übernehmen kann.
Für jede gekapselte Anwendung, die ein Werkzeug abdecken soll, muss es einen entsprechenden Adapter vorsehen, der die Übersetzung vornimmt. Entsprechend bauen die Werkzeughersteller Adapter vorrangig für solche Ziel- und Berechtigungssysteme, die einen großen Kundenkreis versprechen, weil sie entsprechend weit verbreitet sind.
![[Abb. 2]](64-2.gif)
Abbildung 2: Integration eines RBAC-Werkzeugs
Abbildung 2 zeigt die mögliche Integration eines zentralen RBAC-Werkzeugs in einer IT-Umgebung mit Anbindung der primären Zielsysteme, der Datenquellen und Datenablagen unter Einbeziehung von Administration und Antrags-Workflow. Das "Rollensystem" setzt hierbei ein definiertes Rollenmodell mittels eines zentralen RBAC-Werkzeugs um. Über die Rechtezuweisung werden die rollenbasierten Rechte auf verschiedenen Zielsystemen eingestellt. Für die Definition der Rollen benötigt man zahlreiche vorhandene Datenquellen. Die Administration lässt sich an die Fachstellen delegieren, wobei die Endbenutzer jedoch Rollen und Rechte zentral über einen Workflow beantragen.
Das Angebot an Werkzeugen, die plattformübergreifend einsetzbar und konzeptionell ausgereift sind, zugleich aber auch die genannten Funktionsklassen abdecken, ist überschaubar (vgl. [2]).
Dieser Hersteller war bereits bei den Anfängen der RBAC-Arbeiten des NIST involviert (vgl. [1]). Insofern hat das Produkt die längste Historie bezüglich dieser Technologie. Entsprechend gibt es für seinen Einsatz zahlreiche Referenzkunden. SAM setzt auf dem Host als Trägersystem auf: Auch wenn es verschiedene dezentrale Zielsysteme unterstützt, ist das Produkt derzeit eher Host-orientiert – auch im Hinblick auf durchgängige Administrationsfunktionen. Eine Version mit Unix als Trägersystem ist jedoch angekündigt.
Auch dieses Produkt weist als Teil der Produktfamilie "In-Control" eine starke RBAC-Funktionalität auf und verfügt über sehr gute Referenzen. Control-SA geht zurück auf die Zusammenarbeit zwischen New Dimension Software und dem Hersteller Memco (SeOS). SeOS ist der gemeinsame Kern mehrerer RBAC-Produkte: Neben Control-SA sind dies der Security Manager (TACF) von Tivoli und eTrust Access Control von Computer Associates.
Control-SA nutzt Unix als Trägersystem, deckt aber sowohl den Host-Bereich als auch das dezentrale Umfeld gut ab. Dies gilt besonders für die Administrationsfunktionen und Schnittstellen. Partnerschaften mit Herstellern von Web-Access-Management-Lösungen sind angekündigt.
Die Produktsuite "Tivoli Secureway" von IBM/Tivoli ist eine Systemmanagementumgebung für Host- und dezentrale Systeme. Das Modul "Security Manager" ermöglicht die zentrale Verwaltung von sicherheitsrelevanten Elementen in einer verteilten Umgebung. Die Funktionen der rollenbasierten Rechteverwaltung sind auf Betriebssysteme konzentriert und setzen den Einsatz des Tivoli Management Frameworks voraus.
Neben diesen drei Produkten kommen für den RBAC-Einsatz noch eTrust Access Control von Computer Associates, Global Security von Norcom, Access Master von Evidian (Bull), enRole (RAS) von Access360 und Entact!Role von Entact in Betracht.
Während diese "klassischen" RBAC-Werkzeuge vor allem auf Betriebssysteme als Zielsysteme setzen, sind mittlerweile Werkzeuge auf dem Vormarsch, die ihren Fokus auf Web- und Application-Servern haben. Einen Überblick über ihre Arbeitsweisen, Möglichkeiten und Produkte finden Sie im zweiten Teil dieses Artikels in der KES 2001/5.
Andreas Fritsch ist der Informationssicherheit bei der BMW AG in München.
![[externer Link]](../../../../images/link.gif)
www.systor.com/core/esm/sam/index.html www3.ca.com/Solutions/Product.asp?ID=154 www.tivoli.com/products/solutions/security/products.html© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2001, Seite 64
