Integriertes Identity Management

Ordnungsmerkmale

erschienen in: <kes> 2003^#4, Seite 57

Rubrik: Management und Wissen

Schlagwort: Identity Management

Zusammenfassung: Mobile Mitarbeiter und externe Partner erfordern heute eine große Menge von Zertifikaten für alle möglichen Zwecke von Authentifizierung bis Verschlüsselung. Unser Autor schildert anhand eines Praxisbeispiels, wie ein dazu benötigtes Identity-Management-System nahtlos mit Verzeichnisdienst und PKI integriert werden kann.

Autor: Von Uwe Post, Gelsenkirchen

Die Zeiten der großen IT-Hypes sind vorbei – "Buzzwords" und Trendthemen gibt es aber natürlich immer noch. Identity Management ist ein solches Schlagwort, das viele Fortschritte für große, heterogene Netze verspricht. Die Notwendigkeit für viele Anwender von vielen Orten, inner- und außerhalb eines Unternehmens, den Zugriff auf zentrale Daten zu regeln, bedeutet eine große Herausforderung für die aufzubauenden Sicherheitsstrukturen.

Die Skepsis vor dem Aufbau einer Firmen-PKI als eigenständige Struktur ist groß aufgrund von Berichten über hohe Kosten und technische Probleme bei der Integration. Auf der anderen Seite stoßen klassische Sicherheitsmaßnahmen von Unternehmen an ihre Grenzen, sobald offene Netze entstehen und von verschiedenen externen Stellen auf schutzwürdige Daten zugegriffen werden soll. Passwörter genügen nicht mehr, die Notwendigkeit starker Authentifizierung tritt viel stärker in den Mittelpunkt. Dabei sollen möglichst keine hohen Schulungs- und Entwicklungskosten anfallen.

Gefragt ist daher eine Lösung, welche die intakte Infrastruktur des Unternehmens nutzt, erweitert und die Funktionen des Identity Management möglichst unauffällig und reibungslos integriert, ohne die Arbeitsabläufe neu zu definieren. Wo Benutzerdaten bereits strukturiert in Verzeichnisdiensten abgelegt sind, entfällt eine redundante Datenhaltung, wenn Public-Key-Infrastructure-(PKI-)Dienste direkt auf dem Verzeichnis arbeiten.

Was muss aber eine PKI leisten, die in eine Identity-Management-Lösung eingebunden ist? Im Hintergrund muss natürlich eine Certificate Authority (CA) zur Verfügung stehen, die Schlüssel und Zertifikate ausstellen und signieren kann. Eingebettet in einen Verzeichnisdienst, muss ein authentifizierter Benutzer aber optimalerweise nur einen einzigen Knopf drücken, um ein Zertifikat für sich anzufordern: Seine persönlichen Daten sind sowieso schon im Verzeichnis hinterlegt und werden einfach an die CA weitergereicht. Und die Identität des Benutzers ist durch die Authentifizierung beim Verzeichnisdienst sichergestellt.

Abbildung 1: Eine integrierte browserbasierte Benutzeroberfläche zur Zertifikatsanforderung, hier im Novell iManager, liefert dem Anwender PKI-Funktionen innerhalb seiner gewohnten Arbeitsumgebung.

Um die PKI für Benutzer zugänglich zu machen, sind unterschiedliche Wege denkbar. Ein proprietärer Client verursacht hohe Verteilungs-, Support- und Schulungskosten, wohingegen eine browserbasierte Anwendung fast nur Vorteile bringt: Ein Browser ist auf praktisch jeder Workstation vorhanden, unabhängig vom Betriebssystem. Die Systemanforderungen sind vergleichsweise gering, und nicht zuletzt entfällt der Administrationsaufwand für die Installation zusätzlicher Software. In vielen Fällen existiert bereits ein Intranet, in das ein PKI-Web-Frontend eingebunden werden kann. Gehorcht diese Integration den lokalen Styleguides, findet sich ein Benutzer schnell in den neuen Funktionen zurecht; da der Nutzerkreis oft zu einem guten Teil aus im Umgang mit komplexer Software weniger versierten Anwendern besteht, sollte man diesen Vorteil nicht unterschätzen. Das SSL-Protokoll ermöglicht zudem eine transparente sichere Übertragung selbst kritischer Daten per HTTP. Eine darauf basierende Lösung bindet sich auch in mobile Systeme nahtlos ein – die Benutzerschnittstelle muss lediglich die betreffenden Endgeräte unterstützen, beispielsweise in Form von CompactHTML- oder WML-Seiten (Wireless Markup Language).

Ein Beispiel für eine browserbasierte Benutzeroberfläche ist der iManager von Novell, der alle Standardaufgaben, die zur Benutzung und Administration des Novell-Verzeichnisdienstes eDirectory anfallen, unter einer einheitlichen Oberfläche anbietet, die unterschiedliche Endgeräte unterstützt. Es muss nur für jede Aufgabe ein entsprechender Satz von Webseiten existieren, zum Beispiel einmal für normale Browser und einmal für WML-fähige Geräte. Der iManager lässt sich über so genannte Gadgets beliebig erweitern: Dabei handelt es sich um Sammlungen von Servlets und Java Server Pages (JSP). iManager setzt auf der Apache-Applikation Tomcat auf, die Java Servlets 2.3 und JSP 1.2 implementiert. Dieser verbreitete Open-Source-Webserver verschlingt keine Lizenzgebühren und läuft unter Linux, Windows und NetWare.

Üblicherweise begrenzt man zwar ohnehin die Laufzeit von Zertifikaten. Im Falle von Personalwechsel oder Kompetenzerweiterung des Inhabers müssen Zertifikate aber auch vor ihrem Ablaufdatum gesperrt oder neu ausgestellt werden können. Administratoren benötigen daher entsprechende Funktionen auf Benutzerzertifikate; aber auch der Anwender selbst muss seinen, womöglich kompromittierten, Schlüssel zurückziehen können. Ebenfalls erforderlich ist eine Funktion zum Erneuern ablaufender Zertifikate. Und nicht zuletzt bedarf es eines Verzeichnisdienstes, um Anwenderzertifikate, beispielsweise zur E-Mail-Verschlüsselung, bereitzustellen.

Ein Identity-Management-System nach dem beschriebenen Verfahren ist in der Praxis bei der StarAlliance, einem weltweiten Dachverband großer Fluggesellschaften, bereits im Einsatz. Als Verzeichnisdienst arbeitet das Novell eDirectory in Version 8.7, als Verwaltungstool kommt der browserbasierende iManager 2.0 zum Einsatz, der von der cryptovision durch Gadgets für die Zertifikatsverwaltung erweitert wurde. Auf der Serverseite läuft als CA der cv act ca/server, angeschlossen über Novells DirXML-Engine. Daneben beantwortet der cv act ocsp/responder on-the-fly Anfragen zur Gültigkeit von Zertifikaten. Die PKI-Struktur ermöglicht Sicherheitsanwendungen, wie E-Mail-Verschlüsselung, digitale Signatur oder Login-Vorgänge und kann unter Anbindung des cv act sc/interface für den Gebrauch von Smartcards oder Token erweitert werden (in der Grafik Grün dargestellt sind cryptovision-Komponenten, rote Elemente stammen von Novell, hellgrüne befinden sich noch in der Entwicklung).

Serverkomponenten

Wichtig für die Auswahl einer CA ist ihre Flexibilität bei der Anbindung an den Application Server. Die CA muss Anforderungen für Zertifikate entgegennehmen, verarbeiten und dem Benutzer das Resultat über den Verzeichnisdienst zur Verfügung stellen. Im Fall des Novell eDirectory bietet sich die Anbindung über DirXML-Treiber an. Diese Technologie nutzt bestimmte, vorab definierte Attribute in den Benutzerobjekten des Verzeichnisses. Startet der Benutzer über seine Web-Oberfläche beispielsweise eine Zertifikatsanforderung, so schreibt das iManager-Gadget die Parameter der Anforderung sowie einen Trigger in die Benutzerattribute. Die DirXML-Engine reagiert auf den Trigger und reicht die Daten im XML-Format an den CA-Connector weiter. Wenn die CA ein Kommando verarbeitet hat, schreibt sie über DirXML-Treiber und Publisher-Stylesheets ihre Ausgaben in die richtigen Attribute des Benutzerobjekts zurück, von wo aus sie über das Web-Frontend abgerufen werden können. Dabei kommen automatisch die Zugriffsrechte des Benutzers im Verzeichnisdienst zum Tragen, sodass eine zusätzliche Policy-Infrastruktur unnötig ist.

Die Lösung verwaltet alle ausgestellten Zertifikate zentral in einem Repository im Verzeichnisbaum. Wird ein Zertifikat zurückgezogen oder gesperrt, so wird es dort entsprechend gekennzeichnet. Gleichzeitig kümmert sich die CA um die Erstellung jeweils aktueller X.509 Certificate Revocation Lists (CRL). Eine sinnvolle Erweiterung ist der OCSP-Responder (Online Certificate Status Protocol, RFC 2560), der auf das HTTP-Protokoll aufsetzt und aktuelle Anfragen nach dem Gültigkeitsstatus von Zertifikaten beantwortet. Damit entfällt die lästige Verwaltung von Listen zurückgezogener Zertifikate auf der Client-Seite.

Sicherheit

Wenn eine PKI das Erzeugen von Verschlüsselungszertifikaten übernimmt, so wird auch Key Recovery zu einem kritischen Aspekt. Wenn eine Workstation samt privater Schlüsseldatei in die ewigen digitalen Jagdgründe eingeht, ist sonst guter Rat teuer. Folglich sollten an geschützter Stelle Kopien der geheimen Schlüssel vorliegen, am besten im ohnehin verwendeten Verzeichnisbaum. Um Fremdzugriff, sei es durch Fehlkonfiguration von Benutzerrechten oder andere Schwächen, zu vermeiden, ist ein erweiterter Zugriffsschutz sinnvoll. Novell bietet mit dem SecretStore eine Erweiterung zum eDirectory, die diese Vorgaben erfüllt. Ein als "Secret" im Benutzerobjekt gespeicherter Schlüssel kann nur der Benutzer selbst abrufen, weil es mit seinem Passwort verschlüsselt wird; auch Administratorrechte gewähren keinen Zugriff auf solche "Secrets".

Eine weitere wichtige Sicherheitsfrage ist die Übertragung der Zugangsinformationen für neue Schlüssel. Nachdem ein Benutzer ein Schlüsselpaar angefordert hat, erhält er nach wenigen Sekunden Zertifikat und geheimen Schlüssel, gewöhnlich im PKCS#12-Format verpackt in einer pfx-Datei. Um den Schlüssel verwenden zu können, fehlt aber noch die PIN oder Passphrase. Um Missbrauch vorzubeugen, werden solche Daten gerne postalisch versendet oder jedenfalls auf einem unabhängigen Weg mehr oder weniger persönlich übermittelt. Damit der Benutzer, vor allem wenn er mehrere Schlüssel (z. B. für Authentifizierung, Signatur, Verschlüsselung) beantragt hat, die PINs der richtigen pfx-Datei zuordnen kann, müssen beide hinreichende Angaben tragen. Als Unterscheidungskriterium bietet sich in den meisten Fällen der Verwendungszweck an, da ein Benutzer gewöhnlich nicht mehrere Schlüsselpaare für dasselbe Szenario haben sollte. Falls doch, so kann die Seriennummer in Verbindung mit dem Namen der CA (falls mehrere verwendet werden) als eindeutiges Kriterium dienen. Natürlich muss ein System zum Identity Management auch in der Lage sein, mehrere Schlüssel pro Benutzer zu speichern.

Alternativ zur Schlüsselerzeugung durch die CA kann man diese auch dem Client-System überlassen. Windows bringt eine solche Funktion von Haus aus mit und macht sie in Form eines ActiveX-Controls im Internet Explorer zugänglich. Wo ActiveX-Controls aus Sicherheitsgründen nicht zugelassen sind, kommen Enrollment-Komponenten von Drittanbietern für den Internet Explorer in Betracht. So oder so: Der Schlüssel verbleibt in diesem Fall auf dem lokalen Rechner, während CA und Verzeichnisdienst nur Zertifikate erstellen, verwalten und anderen Benutzern zur Verfügung stellen.

Auf Client-Seite ist ein derart erzeugter Schlüssel leicht zu handhaben, weil er automatisch in der Windows-Zertifikatsverwaltung landet und Programmen wie Outlook ohne Weiteres zur Verfügung steht. Andererseits besteht bei einem Datenverlust auf dem Client die Gefahr, dass der Schlüssel unwiederbringlich verloren ist – Chiffrierschlüssel sollte man also lieber der sicheren Verwaltung durch die CA anvertrauen, da sie dort im Verzeichnis liegen und gewöhnlich ohnehin in einen Backup-Prozess eingebunden sind.

Fazit

Die Vorteile einer engen Kombination von PKI und Verzeichnisdienst zu einem leistungsfähigen Identity Management ergeben sich durch die einfache Wartbarkeit und nahtlose Einbindung in vorhandene, browserbasierende Benutzeroberflächen, die keine Umgewöhnung für die Benutzer bedeuten und somit sowohl kurz- als auch langfristig ein großes Einsparpotenzial bieten.

Ein weiterer Vorteil solcher Lösungen liegt in der optimalen Skalierbarkeit: Egal ob 5 000 oder 500 000 User angeschlossen sind, das System funktioniert immer nach den gleichen Vorgaben, demselben Ablauf und Sicherheitsniveau. Ausschlaggebend ist letztlich nur die Leistungsfähigkeit des Directory Service. Durch zentrale Eingabe kann in diesem Umfeld zudem die Sicherheits-Policy des Unternehmens in kürzester Zeit aktualisiert und an neue Anforderungen angepasst werden.

Uwe Post ist Software-Entwickler bei der cv cryptovision gmbh ( [externer Link] www.cryptovision.de).