Man muss Richard David Precht nicht mögen, ihn nicht mal kennen – aber sein Buchtitel „Wer bin ich – und wenn ja, wie viele“ passt auf viele Fragestellungen, auch jenseits der Philosophie. Besonders gut passt er auf „Identity Management“, kurz IDM. Schließlich sollte man im Unternehmen wissen, wer sich an den Rechnern und Applikationen anmelden kann und über welche Gruppen er welche Zugriffsrechte erhält. Das gilt für alle Systeme und Accounts, erst recht, wenn der Mitarbeiter ausscheidet.
Diese vermeintliche Selbstverständlichkeit wird in der Realität erstaunlich oft ignoriert. Auf den ersten Blick ist es ja auch verlockend, für eine intern installierte Fachanwendung kurzerhand eigene Logins zu nutzen, statt das neue System sauber in den Bestand zu integrieren. Aus der einen Anwendung werden viele, und jeder Benutzer darf sich dutzende Accounts und Passwörter merken. Das allein hat schon handfeste negative Folgen. Jeder Admin kennt die leidige Diskussion: „Warum brauche ich da überhaupt ein Passwort? Und warum muss es so kompliziert sein? Ich hab ja nix zu verbergen, und überhaupt: meine Assistentin soll sich ja auch in meinen Account einloggen können wenn ich gerade auf Dienstreise bin“. Dass mit laschen oder fehlenden Passwörtern auch Malware einfaches Spiel hat, dringt zu der Klientel nicht mehr durch.
Es soll nur einen geben
Admins kommen aus der Nummer nur raus, wenn sie die Menge an Accounts und Passwörtern reduzieren – im Idealfall auf genau einen Account pro Anwender. Dann kann man es den Kollegen auch zumuten, Passwörter zu wählen, die deutlich sicherer als das beliebte „123456“ sind und sich diese dann auch tatsächlich zu merken. Wer nun denkt, damit das Security-Mantra „jeder Dienst braucht sein eigenes Passwort“ zu verletzen, sollte genauer hingucken: entscheidend ist, wer das Passwort prüft und im Zweifelsfall sogar speichert. Bei anonymen Cloud-Anbietern ist Vorsicht angebracht, schließlich weiß man nie, wie deren Admins mit den Daten umgehen. Wenn sich da jemand nicht an die Regeln hält, sollte sich das keinesfalls auf andere Accounts bei anderen Anbietern auswirken.
Beim IDM geht es aber um den eigenen Arbeitgeber, und damit in IT-Sprech um eine gemeinsame administrative Domäne. Hier ist ein gemeinsames Passwort für alle Dienste klar von Vorteil, und zwar für alle Beteiligten:
- Benutzer müssen sich nur einen Account und ein Passwort merken
- Sie müssen das Passwort nur an einer Stelle ändern, wenn sie es wechseln wollen
- Das neue Passwort gilt sofort auf allen Systemen
- Admins müssen den Benutzer-Account nur einmal anlegen
- Hat der User sein Passwort vergessen, müssen sie es auch nur einmal zurücksetzen
- Soll ein User gesperrt werden, dann genügt auch dafür ein Haken in einer Verwaltungssoftware
Gerade der letzte Punkt wird gern unterschätzt. Wer es nicht schafft, ein zentrales IDM zu etablieren, wird auch kaum Buch führen über jeden manuell eingerichteten Zugang. Dann hat der abtrünnige Vertriebler nach seinem Rauswurf gemütlich Zeit, um im Wiki der Firma Inhalte zu verdrehen und sich an der Kundendatenbank zu bedienen.
Neu erfundene Räder
Es braucht also eine zentrale Verwaltung aller Accounts und Gruppen. Das könnte man nun reichlich komplex mit SAML, OAuth, JWT und anderen Frameworks aufbauen. Sehr viel pragmatischer ist das gute alte LDAP: Ob nun im allseits bekannten Microsoft Active Directory (AD) oder OpenLDAP, FreeIPA oder Samba 4: sie alle verwenden im Kern ein LDAP-Verzeichnis. Entscheidend ist, dass die Accounts und Passwort-Hashes an dieser zentralen Stelle verwaltet werden. Dazu müssen alle internen Rechner und Dienste an das IDM angebunden werden. Für LDAP haben die allermeisten Produkte seit langem eine Integrationsmöglichkeit.
Unser eigene Lösung CoreBiz Directory geht genau diesen Weg: Im Kern ist es ein Active-Directory-kompatibles Samba 4 mit eigener Verwaltungsoberfläche. Alle unsere eigenen Produkte sind in diesen Verzeichnisdienst integriert, sogar eine Kombination mit einem Microsoft-AD-Server ist möglich. In dem Szenario replizieren beide Server ihre Daten, sodass man Accounts in beiden Diensten nutzen und verwalten kann. Entscheidend ist, dass jede integrierte Anwendung das CoreBiz Directory auch als Authentifizierungsservice verwendet, damit das Passwortmanagement klappt.
Ich bins wirklich
Wer den Betrieb eines entsprechenden Dienstes scheut, kann ihn jederzeit in die Cloud verlagern – zum Beispiel mit dem CoreBiz365 Directory Server und den bei Bedarf im Verbund mit einem internen CoreBiz Directory Server verwenden. Egal welche Variante: Für Anwender ist der Vorteil enorm. Um „wer bin ich“ zu klären, müssen sie sich nur einen Benutzernamen und ein Passwort merken statt viele.