Identity Management – Mal anders gedacht

Was ist ein IDM?

Bei einem Identity Management / Identitätsmanagement (IDM) handelt es sich um eine zentrale Lösung, mit der die Identität von Nutzern für personengebundene Zugänge und Services sichergestellt werden soll. Eine Identität ist hier mit einem digitalen Ausweis vergleichbar – ein IDM verknüpft also eine Person mit einem Ausweis und überprüft dessen Gültigkeit. Dies soll zentral sicherstellen, dass sich hinter einer Identität tatsächlich genau die Person verbirgt, die berechtigt ist, sich zu authentifizieren. In der Regel wird ein IDM gemeinsam mit einem Access Management, das der Autorisierungsprüfung dient, betrieben. Über das Access Management werden die Identität und ihre Berechtigungen übertragen.

Der klassische Ansatz: Microsoft Active Directory

Ein klassisches Beispiel für ein Identity Management, das gemeinsam mit einem Access Management betrieben wird, ist das Active Directory (AD) von Microsoft. Gerade im Unternehmenskontext ist ein Verzicht darauf schwer denkbar. Unternehmen verwenden nahezu immer eine Domäne und bilden ihre Betriebsstrukturen darin ab.

Komponenten des Active Directory

Ein AD besteht im Wesentlichen aus den folgenden Komponenten:

• SMB/CIFS (Gruppenrichtlinien)
• Kerberos (Authentifizierung)
• LDAP (Datenbank für Nutzer- und Gruppeninformationen)

Innerhalb des AD werden über die SYSVOL-Freigaben (SMB/CIFS) Gruppenrichtlinien (Group Policy Objects, GPO) verbreitet. Hierüber können viele Einstellungen gesetzt werden, sodass sich verschiedene Maschinen nach der Installation sehr schnell in einem gehärteten Zustand befinden. Die Verwaltung der lokalen Administratorgruppe ist ein geeignetes Beispiel. Mitglieder dieser Gruppe können über GPO gesetzt oder gelöscht werden, und es kann so zentral verwaltet werden, welche Benutzer sich über das Remote Desktop Protocol (RDP) auf der Maschine anmelden können.

Kerberos bietet eine ticketbasierte Authentifizierung innerhalb der Domäne und fungiert als vertrauenswürdiger Dritter. Nutzer (und Computer) können sich hier zentral anmelden und erhalten einen Ausweis (Ticket Granting Ticket, TGT). Mit diesem können sie erneut an den Domänencontrollern (hier: Key Distribution Center, KDC) anmelden und mit ihrem TGT ein Serviceticket für einen konkreten Dienst beantragen. Der Dienst kann das Ticket überprüfen und dem Nutzer entsprechende Rechte geben.

LDAP bietet die Datenbasis für die beschriebenen Operationen. Hier werden die Benutzer und Gruppen in verschiedenen Strukturen (Organizational Units (OUs), Site, Gruppen …) gespeichert und können von berechtigten Diensten (oder Nutzern) abgefragt werden.

Grenzen des AD/ADFS

Alle drei oben aufgeführten Dienste sollten nicht direkt im Internet angeboten werden. Diese Dienste unterstützen teilweise nur veraltete Standards (Kerberos ist im Wesentlichen nur symmetrisch verschlüsselt), sind wiederholt für zahlreiche Schwachstellen bekannt geworden (MS17-010) oder bieten nur rudimentären Schutz gegen Brute-Force-Angriffe.

Als Lösung hierfür wurde ADFS bzw. SAML eingeführt. Hierüber ist eine zentrale Authentifizierung über standardisierte Dienste möglich. Webseiten Dritter (zum Beispiel extern gehostete Webseiten) können hierüber eine Authentifizierung und Autorisierung von Nutzern durchführen. Aktuellere Dienste verwenden hier allerdings OAuth2 bzw. OpenID Connect (OIDC). Auch mithilfe dieser Methoden können Authentifizierung und Autorisierung vertrauenswürdig an Dritte übertragen werden.

Freie Möglichkeiten

Aber auch abseits von Microsoft existieren Möglichkeiten, ein Identitätsmanagement zu betreiben.

In der Linux-Welt gibt es die Open-Source-Implementierung Samba, die große Teile der AD-Welt lizenzfrei in Anlehnung an ein AD implementiert. Insbesondere ist hier ein LDAP-, Kerberos- und SMB/CIFS-Server enthalten. Gruppenrichtlinien können mit Samba gut verbreitet, allerdings nicht so einfach erstellt werden.

Die Installation von Samba selbst findet in der Regel über die üblichen Paketmanager statt (apt, rpm, yum, yast …). Anschließend muss noch die Promotion zum Domänencontroller (DC) erfolgen und gegebenenfalls das Domain Name System (DNS) entsprechend eingerichtet werden.

Analog zu AD/ADFS besteht auch hier die Problematik, dass die Komponenten LDAP, Kerberos und SMB/CIFS nur innerhalb von Unternehmensnetzen verwendet werden (sollten). Lösungen über standardisierte Protokolle wie SAML sind auch hier denkbar und können ähnlich verwendet werden.

Auch unter Linux kann eine Anbindung über OAuth2 bzw. OIDC erfolgen und nahezu nahtlos integriert werden.

OAuth2

Gegenwärtig wird statt einer Anbindung mittels SAML gerne OAuth2 verwendet. Dies ist ein aktueller Standard, auf dem OIDC aufbaut. Hierbei werden mittels bestimmter Authentifizierungsabläufe – sog. "Flows" – Anmeldungen durchgeführt. Die eigentliche Authentifizierung des Nutzers erfolgt gegen die zentrale Instanz (Provider). Dies kann auf unterschiedlichen Wegen geschehen und je nach Flow auch unterschiedlich konfiguriert werden. Zusätzlich zum reinen Zugriffsmanagement können hier auch weitere Daten freigegeben werden. Bekannt ist in diesem Zusammenhang z. B. die Zahlung via Amazon Pay, bei der direkt auch Name und Adressdaten übertragen werden können, oder auch die "Anmeldung via Facebook" bzw. "Anmeldung mit Google".

Keycloak

Keycloak ist eine Open-Source-Identitäts- und Zugriffsmanagementlösung und setzt auf OIDC.

Diese Lösung dient dazu, gängige Authentifizierungs- und Autorisierungsmethoden nachzubauen. Die Software selbst dient hier nur als Beispiel und sollte vor einem eventuellen Einsatz unbedingt technisch und konzeptionell überprüft werden.

Alle standardmäßigen Authentifizierungsabläufe sind mittels Keycloak möglich. Die Anbindung kann direkt an einen LDAP- oder sonstigen Dienst gebunden werden. Alternativ kann auch eine Benutzerverwaltung in Keycloak selbst angelegt werden. Die eigentlichen Berechtigungen werden dann über Rollen abgebildet.

Für die jeweiligen Rollen bzw. die Flows können auch besondere Authentifizierungsmethoden gewählt werden. So kann für kritische Vorgänge eine Zwei-Faktor-Authentifizierung (2FA) forciert werden.

Standardmäßige Abläufe sind also mit OAuth2 abbildbar. Aber kann es auch für komplexere Methoden verwendet werden?

Anbindung von SSH an Keycloak

Am hier vorgestellten Beispiel wird versucht, eine SSH-Verbindung über Keycloak zu authentifizieren. Ein Benutzer soll in der Lage sein, sich auf einem Rechner anzumelden. Die Zugangsdaten sollen nicht auf der Maschine lokal liegen (dort wären sie natürlich entsprechend gesichert, müssten aber erst auf die jeweiligen Maschinen kopiert werden).

Hier kommt der Device Flow zum Einsatz. Dieser ist eventuell von der Verbindung mit einer App auf dem Fernseher bekannt. Hier startet man die Anmeldung am Fernseher und erhält einen relativ kurzen Code. Diesen gibt man dann auf einem Gerät, auf dem man bereits angemeldet ist, ein und kann hierüber die Anmeldung auf das TV-Gerät übertragen.

Dies ist auch mittels SSH möglich. Über ein zentrales Image bzw. das Provisioning muss der Device Flow konfiguriert sein. Allerdings müssen Benutzer dem System nicht bekannt sein und können über reine HTTPS-Anfragen überprüft werden. Kritische Dienste wie LDAP müssen nicht im Internet exponiert sein. Benutzer können einfach wie bisher den SSH-Befehl eingeben:

---------------------------------------------------------

% ssh user@192.0.2.10

bzw.:

% ssh user@mein.ssh.server.intern

--------------------------------------------------------

Hier wird statt der Abfrage des Passworts ein QR-Code angezeigt. Diesen kann man mit dem Smartphone scannen und dort die Authentifizierung durchführen. Dabei kann z. B. auch die Authentifizierung forciert werden – z. B. durch den mittels Fingerabdruck geschützten Speicher von Smartphones.

War diese Authentifizierung erfolgreich und ist der Nutzer autorisiert, diesen speziellen Flow zu verwenden, geht der Ablauf weiter und der Nutzer erhält direkt die Shell.

Zusammenfassung

Ein sinnvolles und strukturiertes IDM lohnt sich. Zum einen müssen die Daten nur an einer Stelle gepflegt werden und können dann von verschiedenen Clients verwendet werden. Hierbei ist die Wahrscheinlichkeit, dass Daten fehlerhaft manuell übertragen werden, sehr gering. Änderungen sind in Echtzeit möglich (bestehende Sitzungen ausgenommen). Die Verwaltung kann über Gruppen erfolgen, die dann auch die Rechte auf Maschinen regeln können. Eine Verteilung von lokalen Administratorrechten ist so in der Regel nicht nötig. Zusätzlich passieren alle Anmeldungen eine zentrale Stelle und können dort erfasst werden. So können auch ein Missbrauch oder laterale Ausbreitungen von Angreifern leichter erkannt werden.

Gerade in Zeiten, in denen die Empfehlungen in Richtung Zero Trust-Netze gehen, ist eine gute Verwaltung von Identitäten und deren Sicherheit sehr wichtig. Besonders der Charme von eigenen Flows macht OIDC interessant, sowohl in der Windows- als auch in der Linux-Welt. Die SySS empfiehlt generell zu prüfen, ob eine flächendeckende 2FA forciert wird, da häufig Zugänge, die nur auf Benutzername und Passwort basieren, für Angriffe missbraucht werden. Über eine zentrale Verwaltung bei einem Identity und Access Management können solche Konfigurationen schnell erkannt und leicht geändert werden. Auch können Zugänge hierdurch zentral gesperrt werden, sobald ein Mitarbeiter / eine Mitarbeiterin das Unternehmen verlässt. Häufig werden sonst lokale Zugänge des Mitarbeiters / der Mitarbeiterin vergessen oder die geteilten Passwörter von funktionalen Accounts werden nicht geändert. Hier lohnt es sich, einen Blick über den Tellerrand zu werfen und sich mit anderen Methoden vertraut zu machen.

Disclaimer: Mit den hier vorgestellten Methoden gibt die SySS keine Empfehlung ab. Die Beispiele dienen ausschließlich dazu, unterschiedliche Konzepte aufzuzeigen.