Ich hatte bereits angekündigt oder viel mehr angedroht mich mit dem Thema Benutzermanagement auseinander zu setzen. Anfangen möchte ich damit zu erläutern was ich darunter verstehe bzw. was meine Ziele hierbei sind. Ein Benutzer soll meiner Definition eines guten Benutzermanagement nach eindeutig identifiziert werden und sich mit möglichst viel Komfort und Sicherheit dort anmelden können, wo er berechtigt ist und eben nur dort.
Klingt ja eigentlich ganz einfach, aber als Einstieg denkt nun bitte jeder mal zurück an seinen ersten Arbeitstag und überlegt wie viele Kennungen/Passwort-Briefe er damals bekommen hat. Die wenigsten werden die Frage wohl damit beantworten können genau eine Kennung mit zugehörigem Passwort erhalten zu haben. Nun denkt weiter an die ersten Arbeitswochen und überlegt wie oft noch fehlende Berechtigungen oder lokale Benutzerkonten und Passwörter nachträglich erstellt werden mussten. Und nun einfach mal wie oft am aktuellen Arbeitstag eine Passworteingabe erforderlich war oder den letzten Tag an dem eine Passwortänderung fällig war. Wenn ich damit schon das persönliche Horrorszenario von jemand beschrieben habe, dann versetzt sich derjenige bitte in die Rolle des Consultants, denn mir geht es üblicherweise jede Woche so.
Anlass für diesen Post ist dann der Kunde bei dem folgende Konstellation hatte:
* Kryptische Windowsanmeldung mit Passwort aus dem AD
* Gleiche Kennung mit Passwort aus RACF für den Proxy
* Linuxkennung (ebenso kryptisch aber eine andere) mit Passwort aus RACF für Testumgebung, Sudo-Regeln für gewisse Kommandos und Benutzerwechsel zu root
* Linuxkennung mit Passwort aus LDAP für Produktion, andere Sudo-Regeln für Kommandos und Benutzerwechsel zu anderen unpriviligierten Benutzern
* Mailaccount in lokalem Client mit eigenem Passwort
Da nun natürlich auch jede Umgebung andere Passwort-Policies hatte läuft es also auf 3 Accounts und 5 Passwörter zu merken, richtig zuzuordnen und täglich gefühlt tausend mal einzutippen heraus.
Aber ich will mich ja nicht nur beschweren, denn dann könnte ich dies meinem Psychiater erzählen, sondern Lösungsvorschläge machen.
Die erste Herausforderung ist es den Benutzer eindeutig zu identifizieren. Hier sehe ich zwei Möglichkeiten überall die gleichen Informationen verfügbar zu machen, beide mit Vor- und Nachteilen. Persönlich tendiere ich immer dazu Benutzerinformationen über einen zentralen Verzeichnisdienst verfügbar zu machen. Hier ist LDAP klar mein Favorit, da mit verschiedenen Schemas, Overlays und Clients eine breite Unterstützung zur Verfügung steht. Die Alternative ist es sicherzustellen, dass überall die gleichen Informationen lokal vorhanden sind. Dies will man üblicherweise nicht händisch machen und sollte auf Konfigurationsmanagement wie zum Beispiel Puppet setzen. Der Vorteil hiervon ist die Unabhängigkeit der Anmeldung von der Verfügbarkeit eines zentralen Dienstes, egal ob für Ausfallszenarien oder auch nicht direkt verbundene Zonen wie DMZ oder Internetauftritt. Nachteil ist hierbei natürlich der Pflegeaufwand, da so ein Lösung immer etwas selbst gestricktes hat und beispielsweise Namensänderungen oder kurzfristiges Sperren nicht einfach umzusetzen sind. Und wir reden hierbei nur von der Authentifizierung soll so eine Lösung auch die Autorisierung abbilden wird es ungleich komplexer.
Für die Autorisierung gibt es mehrere Ansätze. Lokale Passwörter möchte ich direkt aufgrund des Pflegeaufwands (und da es kaum möglich ist eine Passwort-Policy umzusetzen) ausschließen. SSH-Keys sind nur auf Linux/Unix möglich und überlassen dem Anwender und/oder der zur Generierung/Verteilung verwendeten Software die Sicherheit. Es möchte an dieser Stelle niemand wissen wie viele SSH-Keys ohne Passphrase ich schon auf Netzlaufwerken gefunden habe oder in Versionskontrolle/Backup verfügbar sind. LDAP auch als Backend für Passwörter zu verwenden klingt spätestens dann sinnvoll wenn man das Passwort-Policy-Overlay zur Verfügung hat oder im Fall von Active Directory die Policy zumindest Samba-seitig umgesetzt ist. Nun hat der Benutzer wenigstens überall das gleiche Passwort muss sich aber immer noch jedes mal gegenüber diesem Verzeichnisdienst anmelden. Möchte man dem Benutzer den Komfort eines Single-Sign-On bieten, heißt die Lösung Kerberos. Der Benutzer erhält hierbei nach erfolgreicher Anmeldung ein Ticket mit dem er sich dann weiter autorisiert.
Leider unterstützt nicht jede Anwendung Kerberos, aber auch die Auswahl von Software, die es erlaubt ein entsprechendes Anmeldekonzept umzusetzen gehört zu dem Konzept. Ebenso muss man sich Gedanken über Ausfallsicherheit und Überwachung machen, wenn die Anmeldung aller Benutzer an einer zentralen Komponente hängt. Auch das Thema Sicherheit ist natürlich nicht zu vernachlässigen!
Apropos Sicherheit die Erweiterung der Rechte zum Zwecke der Administration darf nicht vernachlässigt werden. Auf Windows gibt es hierfür mittlerweile den Rechtsklick “als Administrator ausführen”, unter Linux/Unix schon seit langem die Befehle su und sudo. Sudo hat hier klar die Nase vorn, da der Benutzer nur ausführen darf wofür entsprechende Regeln vorhanden sind und zwar autorisiert durch sein eigenes Passwort. Soll der Administrator aber nun nicht ständig sein Passwort angeben, geht dies auch ohne, dann sollte aber der Autorisierung entsprechend vertraut werden können. Auch bei den Regeln sollte man entsprechendes Fingerspitzengefühl walten lassen, so ist beispielsweise aufgrund der Nachvollziehbarkeit im Log eine Regel vorzuziehen, die es erlaubt einen Befehl als jemand anderes auszuführen, als eine die es erlaubt zu dem Benutzer zu werden. Wer berechtigterweise davor zurückschreckt zu viel zu erlauben, kann sich noch SELinux und Confined User anschauen.
Auch die Wahl der richtigen Passwort-Policy sollte verschiedenes beachten, denn bei zu hohen Komplexitätsanforderung neigt der Benutzer zum Aufschreiben, zu kurzer Gültigkeit zum einfachen Hochzählen, keiner Mindestlaufzeit zum schnellen Durchrotieren, aber Mindestlaufzeit dazu dass bekannt gewordene Passwörter nicht geändert werden können, etc. Natürlich sollte der sicherheitsbewusste Benutzer auch nicht durch die Software-Lösung beschränkt werden, beispielsweise erlaubt RACF nur eine Kategorie Buchstaben und Zahlen bei genau 8 Zeichen Länge! 🙁
Wer nun eine Softwareempfehlung wünscht wird sich wundern, dass ich tatsächlich das Active Directory empfehle wenn die Umgebung mehrheitlich aus Windows besteht. Zwar gefällt mir dort die Nutzung von Kerberos nicht, da sie in vielen Dingen nicht weit genug geht oder zu sehr an bestimmte Voraussetzungen geknüpft ist. Aber mit den Unix-Extensions und einer entsprechenden Anbindung der Linux-Systeme mit Hilfe des SSSD lässt sich schon gut arbeiten.
Wer dagegen primär mit Linux-Systemen unterwegs ist sollte sich den FreeIPA anschauen. Dieser setzt auf Opensource um ein Gegenstück zum Active Directory zu bilden, dass Linux wesentlich besser unterstützt indem es auch Sudo-Regeln und SELinux-User zentral verwalten kann. Auch die Anbindung einzelner Windows-Syteme ist möglich oder die Anbindung ans Active Directory um für beide Welten das jeweils beste Werkzeug zu verwenden.
0 Comments