Identity Management und generische Benutzerkonten

Im klassischen Identity Management werden Identitäten betrachtet, sprich reale Personen, ihre Zugriffsrechte, Aufgabenbereiche, erforderliche Arbeitsmittel, etc. Im Idealfall werden bei einem Abteilungs- oder Projekt-wechsel die Berechtigungen angepasst, sprich nicht nur erforderliche Rechte erteilt, sondern auch nicht erforderliche wieder gelöscht. Das zentrale Verzeichnis, heute oftmals Microsoft Active Directory® ist generell so gut angebunden und verwaltet, dass Benutzerkonten bei Personalbewegungen, wie z.B. Verlassen des Unternehmens auch entsprechend gesperrt und gelöscht werden. Im Idealfall (und bei einem implementierten Identitäts-Management) rutschen auch keine personenbezogenen Konten in anderen Systemen (LDAP, UNIX, NIS, Mainframe, SAP, etc.) durch dieses Raster.

Eine ganz andere Herausforderung stellen nicht-benannte, anonyme Benutzerkonten dar. Im besten Fall gibt es pro generischem Konto einen Verantwortlichen, der für die regelmäßige Passwort-Änderung und ggf. auch die Verteilung zuständig ist. Wie aber wird sichergestellt, dass der Verantwortliche auch darüber informiert ist, wenn ein Kollege das Unternehmen verlässt, oder die Abteilung wechselt und daher keine Zugriffsberechtigung mehr auf das generische Konto hat. Im ungünstigsten Fall ist eben jenem Kollegen das Passwort noch für weitere 90 Tage bekannt (vorausgesetzt, bei generischen Konten wird eine Passwortrichtlinie umgesetzt, die eine Änderung des Passworts alle 90 Tage beinhaltet).

Das aber ist nur eine Herausforderung und auch nur einer der Gründe, warum viele Unternehmen generische Benutzerkonten gerne gänzlich abschaffen würden.

Das ist allerdings ebenso unwahrscheinlich wie für alle Systeme ein einziges Benutzerkonto pro Mitarbeiter zu haben. In jedem Betriebssystem, jedem Datenbanksystem, vielen Applikationen, usw. gibt es von Natur aus schon generische Konten. Diese sind auch zur Installation des Systems notwendig und in einigen Fällen erfüllen sie noch weitere, wichtige Funktionen. Viele Applikationen erfordern außerdem ein Benutzerkonto, unter dem ein Service läuft, oder es werden Konten in Applikationen genutzt, um auf andere Ressourcen zugreifen zu können.

In vielen Unternehmen sind solche sogenannten Service-Accounts von der Passwort-Richtlinie ausgenommen, weil die regelmäßige Passwort-Änderung ein nicht unbedeutendes Problem darstellt. Muss doch nicht nur das Passwort geändert werden, sondern auch dafür gesorgt werden, dass die entsprechenden Services auf den Systemen mit dem neuen Passwort versorgt werden, die Applikationen in der Konfigurationsdatei, oder gar im Quellcode geändert werden. Je nach Größe und Komplexität der IT-Landschaft kann das erhebliche Auswirkungen auf den täglichen Betrieb haben, ganz abgesehen von der Zeit, die ein Systemadministrator mit der Änderung und der Aktualisierung auf den verschiedenen Systemen verbringt. Geht dann bei der Dokumentation auch noch etwas schief, kann man in Teufels Küche kommen. Gerade bei komplexen Passworten genügt eine kleine Unaufmerksamkeit und das dokumentierte Passwort entspricht nicht dem gesetzten.

Ähnlich problematisch sind privilegierte, native Accounts, wie z.B. der lokale Administrator unter Windows, root auf UNIX, Linux und Mac Systemen, sys unter Oracle, sa bei MS SQL, etc. Es liegt in der Natur der Sache, dass gerade diese Konten von einer regelmäßigen Passwort-Änderung nicht ausgenommen sein sollten. Allerdings verbringt ein Administrator mit diesen Änderungen gut und gerne einige Stunden. Und damit sind immer noch nicht alle gesetzlichen, oder internen Anforderungen erfüllt. Sobald mehr als eine Person das Passwort kennt, gibt es keine Möglichkeit mehr eine individuelle Zuordnung von Tätigkeiten mit diesem Account sicher zu stellen. Aus der Not heraus gibt es Unternehmen, die den Passwort-Wechsel dann von zwei Administratoren durchführen lassen. Der eine ist für die erste Hälfte zuständig, der andere für die Zweite. Damit wird der Arbeitsaufwand gleich verdoppelt. Die Fehler-Anfälligkeit allerdings auch.

Die Dokumentation birgt eine weitere Herausforderung. In manchen Firmen kommt der Zettel mit dem Passwort für einen Account in einen versiegelten Umschlag und landet in  einem Safe. Wird das Passwort benötigt, steht ein Papier-Prozess bereit und dann muss nur noch der Mann mit dem Schlüssel zur richtigen Zeit am richtigen Ort sein. Und natürlich hofft man auch, dass bei der Dokumentation des Passworts niemandem ein Fehler unterlaufen ist. In anderen Fällen gibt es eine Datenbank, die das Passwort nach Vier-Augen-Prinzip entschlüsselt. Das Bangen um die Richtigkeit der Dokumentation ist auch hier nicht weniger angebracht. Sobald das Passwort dann einmal genutzt wurde, muss es natürlich wieder geändert werden. Siehe oben.

Eine automatisierte Lösung würde also nicht nur Arbeitszeit, und die damit verbundenen Kosten sparen, sondern bietet auch ein höheres Maß an Sicherheit. Es gibt aktuell einige Anbieter, die solche Lösungen auf dem Markt platzieren. Die Entscheidung für die richtige Lösung muss mit Sicherheit individuell getroffen werden und sollte wohl durchdacht sein.

Ein weiterer Aspekt bei der Verwaltung generischer Konten ist Logging. Was ist während der Verwendung eines generischen Kontos passiert? Um das herauszufinden, gibt es ebenfalls mehrere Möglichkeiten. Native Logs sind in fast allen Systemen Standard, die Frage ist, wie aufschlussreich sind diese und wie viel Aufwand muss betrieben werden, um ein Menschen-lesbares Format zu erreichen, dass zudem noch Abhängigkeiten darstellen kann und entsprechend sortiert ist. Natürlich kann man über verschiedene Lösungen eine Auswertung und Visualisierung der nativen Logfiles erreichen, aber viele der aktuellen Lösungen im Bereich Privileged Account, Identity oder auch User Management (PAM/PIM/PUM/PxM) bieten Video-Aufzeichnungen der Sessions. Zu dem Zweck wird nicht selten die Verbindung über die Oberfläche der Lösung initiiert und so ist es dann auch möglich, eine Verbindung zum Zielsystem herzustellen, ohne dass dem Endbenutzer das Passwort zum genutzten Konto jemals bekannt ist.

Die Möglichkeit eine Session live mit zu verfolgen hat auch Vorteile, wenn Service Techniker sich auf ein System verbinden. Es gibt durchaus Anforderungen die ein Monitoring von betriebsfremden Usern auf sensiblen Systemen verlangen. Muss also kein Mitarbeiter dem Techniker physisch über die Schulter schauen, sondern kann dies ebenfalls aus der Ferne erledigen spart man wiederum einiges an Aufwand.

Eine Video-Aufzeichnung alleine hat natürlich einige Nachteile. Will man herausfinden, was passiert ist, muss man sich entweder doch wieder in die Logfiles einlesen und die entsprechenden Zeitfenster abgleichen, so dass man gleich in der Aufnahme zum Zeitpunkt der Aktion springt, oder man schaut sich das Video ganz an, was allerdings sehr zeitaufwendig ist. Einen großen Vorteil bieten hier Lösungen, die auch Meta-Daten zu den Aufzeichnungen speichern und so auch eine Suche nach bestimmten Events zulassen.

Nach dem Prinzip der geringsten Berechtigung sollte auch eine Delegation von Teilrechten gegeben sein, selbst wenn man mit einem hochprivilegierten Konto angemeldet ist. Vielleicht ist einer Gruppe von Administratoren sehr wohl erlaubt sich mit vollen lokalen Admin-Rechten auf einem Windows-Server zu bewegen, eine andere Gruppe soll aber auf jenem Server nur das MSSQL Management Studio starten können, wiederum eine andere Gruppe soll lediglich kein Regedit verwenden dürfen, ansonsten aber volle Berechtigungen haben.

Um erneut auf die Diskussion um generische Benutzerkonten zurück zu kommen, hier noch ein Denkanstoß. Die Nutzung einer PAM/PIM/PUM/PxM Lösung entschärft die Thematik ungemein, dennoch ist es natürlich in vielen Fällen sinnvoll, Administratoren mit eigenen Admin-Accounts arbeiten zu lassen und nicht etwa nur generische Konten zu nutzen. Dies sollte ebenfalls von der Lösung berücksichtigt werden, aber natürlich müssen diese Accounts vom Passwort-Management ausgenommen sein. Es ist nur sehr eingeschränkt sinnvoll, das Passwort eines persönlichen Kontos von einem Tool verwalten zu lassen. Das Konto gehört letzten Endes einer Person und die Person sollte auch für dieses Konto verantwortlich sein. Inklusive Passwort-Änderung und Verwaltung. Die Absicherung solcher Konten sollte entweder über eine Multi-Faktor-Authentisierung, oder einer komplexeren Passwort-Richtlinie erfolgen.

Für Managed Service Provider (MSP) haben generische Admin-Accounts für die eigenen Mitarbeiter auch durchaus Vorteile. Wird die PAM/PIM/PUM/PxM Lösung von Seiten des MSP betrieben, ist jedes genutzte, generische Konto nicht mehr anonym, sondern kann für die Zeit der Nutzung einem Mitarbeiter zugeordnet werden. Auf diesem Weg erfordert es für den MSP dann keine persönlichen Konten mehr in der Kunden-Umgebung und das bedeutet sowohl für den Kunden, als auch für den MSP weniger Arbeit mit der Konten-Verwaltung.

Wie zuvor schon erwähnt stellt jede Umgebung eigene Anforderungen und man sollte sich, bevor man ins Blaue hinein plant mit den verschiedenen Lösungen auseinander-, und sich auch mit den Herstellern zusammensetzen. Es erspart viel Zeit und Aufwand, wenn man vor der Planung den Funktionsumfang kennt und die Ratschläge der Hersteller in die eigene Planung einbezieht. Die haben schließlich in den meisten Fällen schon einige Erfahrung in dem Bereich.