![[Ablaufschema]](86-1.gif)
Abbildung 1: Integration eines proxy-basierten EAM-Werkzeugs
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. Angesichts der Menge von Anwendern und Systemen 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. Der zweite Teil dieses Beitrags stellt die wichtigsten Werkzeuge für Web- und Application-Server kurz vor und zeigt die Randbedingungen ihrer Positionierung in einer bestehenden Access-Management-Architektur. Im ersten Teil ging es neben Grundlagen des Rollenmanagements (Role Based Access, RBAC) um Werkzeuge für die Rechteverwaltung auf Betriebssystemebene (s. KES 2001/4, S. 64).
Während die "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 (EJB bzw. CORBA). Damit zielt man vor allem auf die E-Business-Welle. Applikationen, die sich an anderen Standards orientieren und der Back-End-Bereich werden nicht unterstützt (so genannte Legacy Applications).
Nach Gartner sind die so genannten Extranet Access Management-(EAM-)Werkzeuge "Lösungen, die für Web-basierte Anwendungen eine vereinheitlichte Authentifizierung (Single Sign-on) von Benutzern bieten und deren Zugriffsrechte auf Anwendungen und Daten regeln und prüfen" [6]. Da die Produkte dieser Kategorie ihre Zielsysteme aber nicht nur für Extranet-, sondern genauso für Internet- und Intranet-Anwendungen unterstützen, erscheint ein Begriff wie "Web-Access(-Management)" anstatt "EAM" allerdings geeigneter.
EAM-Werkzeuge setzen eine zentrale Zugangs- und Zugriffsrechteverwaltung auf verschiedenen angebundenen Zielsystemen um, indem sie die Rechteprüfung von den Zielsystemen auf ein zentrales System (Policy-Server) über einen Proxyserver oder Plug-ins (Agenten) umlenken. Die Rechteverwaltung basiert auf übergreifenden Policies, die prinzipiell rollenbasierte Ansätze unterstützen.
Die Produkte verfolgen unterschiedliche Architektur-Ansätze, auch wenn die Funktionalität und Arbeitsweise prinzipiell bei allen gleich ist. In der Regel sind die Entscheidungsfunktionen und die hierzu benötigten Datenquellen auf mehrere Server verteilt. Für die Authentifizierung und zur Anbindung von Datenquellen für Benutzer- und Rechteinformationen müssen auch Server und Technologien anderer Hersteller geeignet eingebunden werden.
Abbildung 1: Integration eines proxy-basierten
EAM-Werkzeugs
Abbildung 1 zeigt den Ablauf der Zugriffsrechteprüfung beim Einsatz von EAM-Werkzeugen. Bei einer Zugriffsanforderung auf eine Web-Ressource (1) wird – unabhängig davon, ob die Anforderung über Internet/Extranet oder aus dem Intranet heraus erfolgt – zuerst der Proxy des EAM-Werkzeugs angesprochen. Falls die Ressource geschützt ist, läuft als nächster Schritt (2) die Authentifizierung und Autorisierung über den Policy-Server. Hierzu verwendet dieser die Regelungen der Policy-Datenbank (3). Zur Authentifizierung (3a) sind weitere Server eingebunden, zum Beispiel ACE- oder Radius-Server. Für die Autorisierung ist der Rückgriff auf Berechtigungsinformationen (3b) notwendig. Das Ergebnis der Prüfung leitet das System schließlich an den Web- oder Application-Server weiter (4), der dann den Zugriff gewährt oder ablehnt.
Bei einer EAM-Architektur mit Agenten statt Proxy ist der Ablauf derselbe, man kann sich in der Abbildung den Proxy dann als integrierten Bestandteil von Web- oder Application-Server vorstellen. Manche Hersteller bieten für die Einbindung des Policy-Servers auch eine Programmierschnittstelle (API) an.
Die Regeln, wie die Authentifizierung und Autorisierung in Abhängigkeit von der Benutzeridentität durchzuführen sind, werden in Policies festgelegt. Die meisten Produkte leiten hierbei Benutzergruppen aus LDAP-Directory-Zweigen oder hinterlegten Benutzerattributen ab. Die einzelnen Attributausprägungen innerhalb einer Regel lassen sich mit logischen Operatoren verknüpfen. Bei der Zugriffsentscheidung steht im Allgemeinen auch ein Satz von Standardattributen wie etwa Wochentag, Uhrzeit, Client-IP-Adresse, Client-Domain etc. zur Verfügung.
Da die Zielsysteme der EAM-Werkzeuge selbst keine Zustandsinformationen für die Benutzersitzungen halten (HTTP-Protokoll), müssen die Werkzeuge die Berechtigungsinformationen in einem eigenen Session-Kontext aufrechterhalten. Hierzu werden in der Regel verschlüsselte und signierte Cookies (Credentials) oder SSL-Sitzungen genutzt.
Wesentliche Architektureigenschaften der EAM-Produkte sind Hochverfügbarkeit und Skalierbarkeit, da bei einer Störung oder bei Durchsatzproblemen des Policy-Servers die Rechteprüfung sämtlicher Zielsysteme betroffen wäre. Üblicherweise nutzt man hierzu Komponenten wie IP-Load-Balancing, redundante Auslegung, Caching und optimierte Entscheidungsbäume bei der Regelauswertung. Mit dem Caching ist zugleich das Problem verbunden, dass die Rechteprüfung sich dabei möglicherweise auf veraltete Daten bezieht (time-of-check / time-of-use).
Die wesentlichen Funktionen der Web-Access-Werkzeuge sind:
Darüber hinaus bieten sie
EAM-Werkzeuge unterstützen ausschließlich webbasierte Applikationen, wobei auch die Anbindung von Application-Servern vielfach noch sehr beschränkt ist. Alle anderen Applikationen und insbesondere Legacy-Systeme werden nicht unterstützt.
Entsprechend dem Fokus der Werkzeuge müssen alle zu schützenden Ressourcen über eine URL oder beispielsweise Enterprise Java Beans (EJB) identifizierbar sein. Deshalb finden systemspezifische Berechtigungen (zum Beispiel NT-Privilegien) und Berechtigungen von Nicht-Web-Anwendungen keine Berücksichtigung. Kompetenzen sind einfache Dateizugriffsberechtigungen im Falle von Web-Ressourcen und anwendungsabhängig bei Application-Servern.
Da die EAM-Werkzeuge keine Rechtezuweisung/-prüfung auf den Zielsystemen durchführen, muss ein Policy-Server die Rechteprüfung zentral durchführen. Um diese ausgelagerte Rechteprüfung bei den Zielsystemen zu erzwingen, kann man grundsätzlich zwischen zwei Varianten wählen: Agenten oder Proxies.
Bei der Proxy-Lösung gehen alle Anfragen an die Zielsysteme zuerst an den Proxy-Server, der dann seinerseits den Policy-Server abfragt. Die Proxy-Lösung ist bei bestehenden komplexen Netzwerkstrukturen schwieriger zu integrieren und in der Gesamtarchitektur ein weiterer Durchsatz-Engpass. Mithilfe eines Proxies kann man auch solche Webserver unterstützen, für die noch kein Agent verfügbar ist.
Bei der Agenten-Lösung ist ein Eingriff in die Berechtigungssysteme auf allen Instanzen der Zielsysteme nötig. Die unterstützten Zielsysteme müssen dazu eine Konfigurationsmöglichkeit bieten, die im Austausch gegen das originäre Berechtigungssystem eine DLL oder Shared Library des Werkzeugs zur Rechteprüfung einbindet. So kann man zum Beispiel den Netscape Webserver dergestalt konfigurieren, dass er beim Zugriff auf eine geschützte Seite die Zugriffsprüfung an den Policy-Server-Agenten weiterleitet.
Sowohl beim Agenten- als auch beim Proxy-Ansatz laufen die Anfragen an den Policy-Server, der auch mehrfach ausgelegt sein kann. Beim Proxy-Ansatz laden manche Produkte ganze Policy-Sätze vorab "auf Verdacht", sodass der Proxy Anfragen auch selbst beantworten kann. Entsprechend behalten manche Agenten zur Performance-Steigerung Antworten auf Zugriffsanfragen im Cache parat. Einige Hersteller bieten sowohl den Ansatz über Agenten als auch über Proxies an.
Bei EJB-Application-Servern gibt es ähnliche Schnittstellen für die Verfahren zur Zugriffsprüfung. Manche Werkzeuge verwenden auch bei Application-Servern einen Proxy-Ansatz: Hier werden die EJBs zum Beispiel durch eine "Proxy-Bean" gekapselt, die alle Aufrufe zunächst abfängt und an den Policy-Server weiterleitet. Dazu ist allerdings der Einsatz eines proprietären Java-Precompilers des Herstellers notwendig, was zu Abhängigkeiten führt.
Der Markt für entsprechende Werkzeuge ist noch relativ neu. Bislang sind praktisch ausschließlich spezialisierte Tools entstanden, die in den meisten Fällen nicht Teil einer größeren Produkt-Suite sind. Hersteller wie etwa Microsoft oder Sun bieten bislang noch keine Lösungen, es wird aber erwartet, dass künftige Architekturen (zum Beispiel Hailstorm/Passport) diese Thematik adressieren. Die Produktbewertung im BMW-Projekt basiert im Wesentlichen auf Informationen aus [3], [5] und [6].
Zahlreiche Hersteller und Anwender von Security-Werkzeugen und E-Business-Plattformen haben sich in der Organisation for the Advancement of Structured Information Standards (OASIS, [7]) zusammengeschlossen, die Industriestandards zur Beschreibung strukturierter Informationen basierend auf XML und SGML definieren will. Der Standardentwurf zur Security Assertion Markup Language (SAML) dient der Spezifikation von Authentifizierungs- und Autorisierungsinformationen, wie sie zum Beispiel Policy-Server und Zielsystem austauschen. Übergeordnet definiert der Standardentwurf zur Extensible Access Control Markup Language (XACML) ein XML-Schema, das alle Beschreibungselemente von Access-Management-Policies abdecken soll.
Netegrity verfügt über zahlreiche volumenstarke Referenzinstallationen und diverse Allianzen mit Herstellern von Portal-Lösungen. Das Produkt bietet bei seinem Policy-Ansatz auch die Möglichkeit, in Abhängigkeit von der Zugriffsentscheidung andere Aktionen anzustoßen, und geht somit über die reine Rechteprüfung hinaus. Siteminder unterstützt sowohl den Proxy- als auch den Agenten-basierten Ansatz.
Auch ClearTrust Secure Control unterstützt sowohl den Proxy- als auch den Agenten-basierten Ansatz. Besonders ausgefeilt ist die delegierte Administration. Zur Performance-Steigerung werden die Inhalte vorhandener Quellen zu Benutzerdaten im Policy-Server repliziert, was gute Durchsatz-Ergebnisse liefert [3]. Der ursprüngliche Hersteller Securant wurde von RSA Security übernommen.
Dieses Produkt bietet neben dem Ansatz über Agenten ein leistungsfähiges API für Java-Anwendungen, sodass sich die Policy-Auswertung in den Anwendungskontext integrieren lässt. Es unterstützt unter anderem den verbreiteten EJB-Application-Server "WebLogic" von BEA. Assurce Access basiert auf NetCrusader von Gradient; dieses Unternehmen wurde von Entegrity übernommen.
Neu in der Produktsuite "Tivoli Secureway" ist das Modul "Policy Director", das ergänzend zum Security Manager die entsprechende Access Management Funktionalität für Webserver bietet. Der Policy Director beruht auf Intraverse von Dascom; einer Firma, die von Tivoli übernommen wurde. Derzeit können über ein zusätzliches Tivoli-Modul auch CORBA-basierte Application-Server – aber noch keine EJB-Server – angebunden werden. Beim Policy Director wird den Zielsystemen generell ein Proxy (WebSeal) vorgeschaltet. Eine Agenten-Lösung ist noch nicht verfügbar.
Wenn man die verfügbaren Werkzeuge in eine bestehende Access Management Architektur integrieren will, ist es notwendig, neben einer technisch-funktionalen Positionierung auch die gewünschte Skalierung der Einsatzbreite und -tiefe umzusetzen. Zu berücksichtigen sind hierbei neben Kostenaspekten auch etablierte Standards und Lösungen im Unternehmen sowie die möglichst überlappungsfreie und weitgehende Abdeckung von Zielgruppen und geforderter Funktionalität.
Bei der Skalierung gilt es, verschiedene Komplexitätsdimensionen zu unterscheiden (vgl. Abb. 2). Man kann die einzelnen Werkzeuge/Lösungen unterschiedlich "intensiv" einsetzen. Je weiter man sich auf den jeweiligen Achsen in Abbildung 2 vom Ursprung wegbewegt, desto höher ist die Komplexität.
![[Vier Dimensionen beim Werkzeugeinsatz]](86-2.gif)
Abbildung 2: Skalierungsraum des
Access-Werkzeug-Einsatzes
Die Anzahl der Mandanten entspricht der Anzahl der einzelnen Ausprägungen oder Kunden des Rollenmodells (vgl. [1]). Auf der Achse sind einzelne Unternehmensbereiche aufgeführt, beginnend mit der zentralen IT. Statt hier die Mandanten als unterschiedliche Fachbereiche (FB1 etc.) zu sehen, lassen sich diese auch im Sinne von E-Business-Zielgruppen betrachten. Entsprechend kann man im naheliegendsten Fall von B2E-Anwendungen, dann mit höherer Komplexität von B2B- und letztlich von B2C-Anwendungen ausgehen.
Die nächste Dimension ist die Anzahl der Zielsystemklassen. Hier geht es nicht um die einzelnen Zielsysteme, sondern um die Anzahl unterschiedlicher Arten. Im einfachsten Fall wird man zunächst nur Betriebssysteme unterstützen (zum Beispiel das RACF-Berechtigungssystem auf dem Host). Der aufwändigste Fall ist die Anbindung einer Anwendung ohne vorgesehene Schnittstelle.
Ein weiteres Komplexitätsmerkmal ist die Anzahl der genutzten Rollenklassen (dies ist eine neue Dimension und kein Gegensatz zu den Mandanten). Im einfachsten Fall geht man nur von der Zugangsverwaltung (Zulassungen) aus. Die nächsten Stufen würden unterschiedliche Basisrollen und schließlich spezifische Rollen einschließen.
Zuletzt sind die Funktionsstufen der Zugriffskontrolle relevant (siehe KES 2001/4, S. 64). Rollenbereitstellung und -verwaltung ist die einfachste Funktionsstufe, die komplexeste ist die Rechtezuweisung beziehungsweise Rechteprüfung.
Bei der gemeinsamen Positionierung von RBAC- und EAM-Werkzeugen wird deutlich, dass es keine einzelne Lösung gibt (vgl. Abb. 3). Die RBAC-Werkzeuge werden zwar grundsätzlich einem übergreifenden Anspruch gerecht, erfüllen aber heute nicht die Bedürfnisse einer marktgetriebenen Anwendungslandschaft, die eine generell auf Betriebssystemebene ansetzende Lösung nicht nachfragt. Deshalb ist es sinnvoll, eine entsprechende Funktionalität (von der Rechteverwaltung bis hin zur Rechtezuweisung) konkret nur für Betriebssysteme und stark übergreifende Rollen (Basisrollen) einzusetzen. In Abbildung 3 steht hierfür exemplarisch der eigene Ausbau eines vorhandenen zentralen User-Managements um die entsprechende RBAC-Funktionalität. Hier kann man natürlich auch ein Kauf-Produkt einsetzen.
![[Illustration]](86-3.gif)
Abbildung 3: Positionierung der
Werkzeuge/Ansätze
Die EAM-Werkzeuge unterstützen heute nur einen sehr eingeschränkten Kreis von Zielsystemen, die aber ihrerseits ein großes Volumen an Daten und Anwendungen abdecken. Entsprechend ist in der Abbildung 3 ein EAM-Werkzeug so positioniert, dass es auf den Fokus "Web Content" abzielt.
Das "Java Security Framework" schließlich bietet für eigenentwickelte Web-/Java-Anwendungen Funktionsbibliothek, Datenquellen und Administrationswerkzeuge. Es unterstützt sowohl die Authentifizierung als auch die Autorisierung. Im Fall der BMW Group wird es als eine selbst bereitgestellte Lösung neben Industriestandards (Java Authentication and Authorization Service, JAAS [8]) auch internen Anforderungen gerecht.
Die unterschiedlichen Werkzeuge nutzen verschiedene Datenquellen, die entsprechend zu koppeln sind. Für den RBAC-Anteil kann auf der Datenbasis des zentralen User-Managements für Basisrollen aufgesetzt werden (ausgehend vom Legacy-System).
Als Directory ist im Beispiel ein zentrales LDAP-Directory im Einsatz, das konzernweit Informationen über Mitarbeiter zur Verfügung stellt (siehe [4]). In Verbindung mit dem zentralen User-Management liefern die hinterlegten Benutzerattribute Informationen zur Definition von Rollen. Zugleich dient das Directory als Quelle und Ablage von übergreifenden anwendungsbezogenen Rollen.
Das EAM-Werkzeug nutzt einen eigenen Policy-Store (nicht eingezeichnet), greift aber bei der Policy-Definition – ebenso wie das RBAC-User-Management bezüglich der Rollen – auf Informationen des zentralen Directory zurück. Das Java-Security-Framework besitzt zur Ablage der übergreifenden anwendungsbezogenen Rechte eine eigene zentrale Datenbasis. Für die Ablage und den Zugriff auf Rollen nutzt das Framework das zentrale Directory.
Letztlich werden unterschiedliche Produkte und Eigenlösungen gemeinsam eingesetzt. Dies entspricht einem Best-of-Breed-Ansatz, der übergreifend über mehrere Lösungsvarianten und Hersteller die geforderte Gesamtabdeckung bieten soll.
Im Vergleich zu den RBAC-Werkzeugen ist der Fokus bei EAM-Werkzeugen wesentlich enger, aber dem derzeitigen Markt entsprechend angepasst. Der wesentliche Unterschied zu den RBAC-Werkzeugen ist – neben der anderen Auswahl der Zielsysteme –, dass die Rechteprüfung nicht mehr dezentral auf den Zielsystemen, sondern zentral über den Policy-Server läuft. Entsprechend entfällt auch die Rechtezuweisung an die Zielsysteme. Der Gedanke der expliziten Modellierung übergreifender Rollen ist bei den meisten RBAC-Werkzeugen, aber weniger bei den Policy-basierten Werkzeugen zu finden.
Problematisch ist, dass die EAM-Produkte zwar eine Vielzahl neu entwickelter Anwendungen einbeziehen, aber schon von ihrer Basistechnologie her nicht durchgängig alle Anwendungen innerhalb eines Geschäftsprozesses abdecken können. Es gilt hier, die Kluft zur Benutzer-/Rechteverwaltung der nicht-webbasierten Anwendungen zu überbrücken. Da die RBAC-Werkzeuge auf Betriebssystemebene ansetzen, bieten sie ja grundsätzlich die Möglichkeit, alle Arten von Anwendungen abzudecken (nicht nur webbasierte).
RBAC-Werkzeuge sind vor allem für Betriebssysteme als Zielsysteme geeignet. Je nachdem, welcher Prozentsatz der Anwendungen im Unternehmen unmittelbar auf einem der unterstützen Betriebssysteme aufsetzt, kann sich auch ein hoher Nutzeffekt auf der Anwendungsseite ergeben (in der Regel bei Host-Anwendungen). Allerdings geht der Trend heute zu Anwendungssystemen, die ihrerseits auf einer komplexen Middleware aufsetzen (Java-Frameworks und Application-Server, Webserver).
Ergänzend zu den RBAC-Werkzeugen und den Web-Access-Werkzeugen gewinnen auch directory-basierte Lösungen an Bedeutung. Diese passen gut in die moderne Schnittstellen-Landschaft (LDAP), ermöglichen aber nur eine Bereitstellung von Rolleninformationen oder einzelnen Attributen zu Rollen. Da Directories als Datenquellen konzipiert sind, fehlen zunächst die Verwaltungswerkzeuge und vor allem die Integrations- und Verteil-Funktionen zur Rechteprüfung oder Rechtezuweisung an Zielsysteme. Im Gegensatz zu einer Directory-Lösung decken RBAC- und EAM-Werkzeuge prinzipiell alle Funktionsstufen von der Rollenverwaltung bis hin zur Rechteverwaltung und -zuweisung ab.
Andreas Fritsch ist Mitarbeiter der Informationssicherheit bei der BMW AG in München.
![[externer Link]](../../../../images/link.gif)
www.rsbac.org/models.htm www.oasis-open.org http://java.sun.com/products/jaas/ www.netegrity.com/products/index.cfm?leveltwo=SiteMinder www.rsasecurity.com/products/cleartrust/ www.tivoli.com/products/solutions/security/products.html© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2001, Seite 86
