computerwoche.de

Archiv

Lichtblick im Passwort-Dschungel

15.05.2001
Von in Sabine
Single-Sign-On-Lösungen nehmen Anwendern eine Bürde ab: Sie befreien von der Last, sich für jede Applikation ein eigenes Passwort merken zu müssen, indem sie die Anmeldevorgänge zu einer einzigen Abfrage zusammenfassen. Angenehmer Nebeneffekt: Unternehmen sparen Geld, weil am Helpdesk weniger Anrufe wegen vergessener Passwörter eingehen.

Ob Verzeichnisdienst, SAP oder Lotus Notes - viele Anwendungen verlangen eine gesonderte Anmeldung. Oft genug muss das Passwort dann auch noch aus Sicherheitsgründen in regelmäßigen Abständen gewechselt werden und bestimmten Anforderungen genügen (zum Beispiel Buchstaben und Ziffern enthalten). Ergebnis: Früher oder später wird ein Anruf beim Helpdesk fällig, weil sich der Benutzer nicht mehr an sein Kennwort erinnert. Pessimistischen Schätzungen zufolge betreffen 70 bis 80 Prozent aller Helpdesk-Anfragen verlorene Passwörter.

Die Schweizer Bankgesellschaft UBS beispielsweise verzeichnete früher 8600 Passwort-Probleme pro 10000 Benutzer im Monat. Nach Einführung einer Smartcard-basierten Single-Sign-On-Lösung von Itsec aus Mönchengladbach sank diese Quote auf monatlich 750 Fälle, in denen User Pin-Codes vergessen hatten. Die Banker freut´s, weil die Betriebskosten für das Helpdesk gesunken sind.

Doch Single Sign-On beschert Firmen noch weitere Vorzüge: Der Administrator gewinnt eine bessere Übersicht, wer welche Anwendungen nutzt. Das ist zum Beispiel wichtig, wenn ein Mitarbeiter aus dem Unternehmen ausscheidet, denn oft bleiben aus Versehen Zugriffsrechte erhalten, die eigentlich getilgt werden müssten. Solche Versäumnisse stellen eine Sicherheitslücke dar.

Generell verleitet die übliche Passwortflut dazu, ein einheitliches Kennwort zu wählen oder es sich an leicht auffindbaren Stellen zu notieren. Diesem Manko schiebt eine Single-Sign-On-Lösung einen Riegel vor. Andererseits öffnet sie auch neue Schwachstellen. Da der Zugriff auf viele Applikationen mit nur einem Passwort erfolgt, empfehlen Berater, das Login um biometrische Methoden - wie Fingerabdruck oder Iris-Scan- oder Token-Karten zu erweitern. "Eine Anmeldung nur mit Passwort ist riskant", bestätigt auch Roland Holtkämper, Partner und Projektbereichsleiter Security Consulting bei Secunet in Essen. "Deswegen werden oft Kartenleser gewünscht."

Ist die Entscheidung für oder gegen Single Sign-On (SSO) im Unternehmen getroffen, bleibt zu klären, welcher Typ von Lösung angeschafft werden soll. Was sich technisch hinter dem Begriff verbirgt, ist nämlich mitunter recht unterschiedlich. Manche Lösungen synchronisieren alle Passwörter, so dass tatsächlich für die verschiedenen Applikationen ein und dasselbe Passwort benutzt wird. Als Beispiel hierfür kann "Passgo" von Symantec (ehemals Axent) dienen. Es handelt sich dabei um eine rein Server-basierende Lösung, die ohne Installation einer Komponente auf dem Client auskommt.

Dadurch verläuft die Installation in der Regel unproblematisch und benötigt keine großen Ressourcen. Auf der anderen Seite besteht bei dem Ansatz der Passwortsynchronisation eine gewisse Sicherheitsgefahr. Da tatsächlich mit einem einzigen Passwort diverse Anwendungen zugänglich sind, darf dieses auf keinen Fall unverschlüsselt übertragen werden.

Andere Lösungen umgehen dieses Problem, indem sie auf dem Server in einem geschützten Bereich Benutzerprofile und User Accounts hinterlegen. Agenten auf den Clients können dann dort die Passwörter für beliebige Applikationen abfragen. Solche auf Verzeichnisdiensten basierenden Lösungen stammen etwa von Novell ("Novell Single Sign-On"), Computer Associates ("E-Trust Security") und Tivoli ("Global Sign On").

Bei Novell heißt der abgeschottete Bereich der Novell Directory Services (NDS) "Secret Store". Nicht einmal der Administrator, nur der Benutzer hat Zugriff darauf. Nach einem Login kann er diese verschlüsselten Informationen auslesen. Eine abgespeckte SSO-Version, die nur eine eingeschränkte Zahl an Websites und Applikationen unterstützt, erfordert lediglich die Installation von Secret Store und der Verschlüsselungskomponenten auf dem Server. Die knapp 50 Dollar je Benutzer teure Vollversion dagegen benötigt auch Komponenten auf dem Client, zum Beispiel einen Konnektor für Lotus Notes. Andere Hersteller verwenden statt dem Verzeichnisdienst NDS meist LDAP.

Auch Public-Key-Verfahren lassen sich für die Anmeldung an Computersystemen einsetzen. Sie ermöglichen keinen Single Sign-On im eigentlichen Sinne, weil immer wieder eine neue Authentisierung erforderlich ist. Sie adressieren jedoch dasselbe Problem. PKIs benutzen zum Verschlüsseln einer Nachricht einen anderen Schlüssel als zum Entschlüsseln. Ihre Aufgabe ist es, die Schlüssel zum Verschlüsseln (öffentliche Schlüssel) zu verteilen, beglaubigen und zu sperren sowie die privaten Schlüssel zu schützen. Beglaubigte Schlüssel werden auch als digitale Zertifikate bezeichnet.

Die gängigste Form der PKI sieht eine Zentralstelle als wichtigsten Bestandteil vor. Das Trust-Center ist für die Ausgabe und Sperrung von digitalen Zertifikaten zuständig. Für ein Unternehmen bedeutet das, dass ein neuer Mitarbeiter sich beim Trust-Center des Unternehmens anmelden muss, um ein digitales Zertifikat und den zugehörigen privaten Schlüssel zu erhalten. Scheidet ein Mitarbeiter aus, wird sein Schlüsselpaar gesperrt. Damit öffentliche Schlüssel für alle Mitarbeiter und Kommunikationspartner zugänglich sind, gehört zu einem Trust-Center meist auch eine Datenbank (Verzeichnisdienst), die digitale Zertifikate allgemein zugänglich speichert.

Laut Martin Steinkopf, Senior Business Consultant bei Iplanet, einem Joint Venture von Sun und Netscape in Hallbergmoos, liegt das Zertifikat auf dem Client. Der Server fordert es dort an und prüft seine Gültigkeit anhand der zentralen Datenbank. Dieses Verfahren gilt zwar als sehr sicher, billig ist die Anschaffung einer PKI allerdings nicht. Auch Legacy-Anwendungen sind schwer einzubinden. Eine Zertifikat-basierende Lösung eignet sich daher nach Angaben von Steinkopf weniger für Netze mit Hosts als für Browser.

Ebenfalls keinen SSO im eigentlichen Sinne bieten Lösungen, die auf sich öffnende Authentisierungsfenster ("HTTP: Basic Authentication") warten und diese blitzschnell ausfüllen. Solche Produkte haben allerdings einen Vorteil: Sie setzen keine Änderungen an Anwendungen voraus. Roland Holtkämper, Projektbereichsleiter bei Secunet, argumentiert, so gingen auch keine Garantieansprüche verloren. Der Pferdefuß: Diese Tools lassen sich leicht hacken. Sobald sich ein Fake-GUI öffnet, trägt die Lösung Benutzernamen und Passwort dort ein.

Noch ist Single Sign-On eher wenig verbreitet. Bauchschmerzen bereiten die oft noch heterogenen Welten mit diversen Plattformen und Applikationen. Reine Windows-Umgebungen bringen weniger Schwierigkeiten mit sich. "95 Prozent aller Windows-Anwendungen lassen sich abdecken", schätzt Thomas Gertler, Systems Engineer bei Novell in Eschborn.

Auch Web-Seiten und Terminalemulationen sind SSO-fähig. Telnet, SAP und Oracle gehören zum Standardprogramm. Schwierig wird es etwa, wenn Unix im Einsatz ist. Manche konventionellen Lösungen berücksichtigen auch noch keine Java-Anwendungen. Teils müssen die Anwender von ihren ursprünglichen Anforderungen abweichen, wenn sie sich als unrealistisch herausstellen und beispielsweise nur 75 Prozent der Arbeitsplätze anbinden.

Ein weiteres Hindernis besteht im weitgehenden Fehlen großer Beispielinstallationen in Deutschland. Helmut Griehl, Senior Technical Consultant bei NK Network & Services in Berlin, vermutet, dass die Anwender keine Versuchskaninchen spielen wollen. Seiner Erfahrung nach befinden sich durch die immer kürzeren Produktzyklen häufig Fehler in der Software. Möglicherweise haben die Lösungen einfach die Ansprüche noch nicht erfüllt. Außerdem taugen fertige Lösungen nur für einfache Netze. Die Anpassung an die tatsächlich vorhandenen Verhältnisse, zum Beispiel das Programmieren von Konnektoren, bringt nach Angaben von Manfred Rothkugel, Senior Consultant bei Controlware in Dietzenbach, einen hohen Aufwand mit sich.

Sollte das Budget knapp sein, wird ein Unternehmen womöglich andere Prioritäten setzen. Schließlich funktioniert die DV auch mit vielen Passwörtern, wenn auch vielleicht nicht so effizient. Das Management investiert zuerst in die Behebung jener Probleme, die das meiste Kopfzerbrechen verursachen. Nach einer Flaute durch den zurückliegenden Jahrtausendwechsel erzeugt derzeit der elektronische Handel eine Nachfrage nach SSO-Lösungen. Entsprechend werden auch viele SSO-Produkte für das Web angeboten.

Hat ein Unternehmen mobile Anwender, sollte es bei der Auswahl eines SSO-Produkts darauf achten, dass auch diese Nutzer unterstützt werden. Oft speichern solche Lösungen die Passwörter lokal auf dem Notebook zwischen. Das Cashen auf dem Client kann auch kürzere Ausfälle des Servers überbrücken. Eine längere Ausfallzeit oder Überlastung des SSO-Servers muss jedoch vermieden werden, weil sich sonst niemand mehr einloggen kann und der Betrieb stillsteht. Besonders heikel ist die Zeit zwischen halb neun und halb zehn morgens, weil sich dann die SSO-Vorgänge häufen.

Diese maximale Last muss der Server verkraften. In der restlichen Zeit liegen unbenötigte Ressourcen brach. Als Lösung für dieses Problem bieten sich laut Holtkämper von Secunet Cluster oder dezentrale Server an. Sie verteilen die Last auf mehrere Punkte.

Für die Einführung empfiehlt der Berater, zuerst eine Teststellung vorzunehmen. Da sich die Last schlecht testen lässt, rät er hier zu einer Simulation. Dann können Pilotbereiche ausgewählt werden. Aus dem Dialog mit den Pilotanwendern ergeben sich in der Regel Anregungen für ein Redesign. "Ein Rollout in Etappen ist sinnvoll, er sollte sich aber nicht über Jahre hinziehen", so Holtkämper. Horst Leber, Program Manager bei Computer Associates in Darmstadt, schlägt vor, die Benutzer vor der Implementierung der Lösung in Gruppen mit gleichen Profilen einzuteilen. Im Falle einer PKI-Lösung sollte die Installation auf jeden Fall mit der zentralen Instanz anfangen.