Hybride Identitäten als Sicherheitsherausforderung
Die wachsende Zahl an mobilen und Home-Office-Nutzern sowie Cloudanwendungen hat die traditionellen Netzwerkabgrenzungen nahezu aufgelöst: Wichtigster Kontrollpunkt ist die Benutzeridentität geworden. Hier kommt das Active Directory ins Spiel, das vielerorts die zentrale Instanz für das Management von Identitäten darstellt. Der Fachartikel zeigt, warum bei der Integration von Active Directory und Azure Active Directory – also dem Aufkommen hybrider Identitäten – ein Umdenken beim Sicherheitsmanagement nötig ist.
Eine hybride Identität erlaubt die Steuerung des Zugriffs der Mitarbeiter sowohl auf lokal betriebene Anwendungen im eigenen Rechenzentrum als auch auf cloudnative Anwendungen, die Cloud-Serviceprovider betreiben. Beispiele aus den beiden Welten wären einerseits eine lokale .NET-Anwendung und andererseits Microsoft Teams, das aus der Cloud heraus verfügbar ist. Bei dieser Konstellation müssen sich Unternehmen mit hybriden Identitäten auseinandersetzen – speziell mit den unterschiedlichen Authentifizierungsprotokollen, die hier zum Einsatz kommen.
Unterschiedliche Benutzerauthentifizierung
On-Premises-Applikationen im lokalen Rechenzentrum nutzen oft das Active Directory für die Kerberos-Authentifizierung, was sich jedoch als sicherheitsanfällig erwiesen hat. Teilweise kommt sogar das noch ältere und stärker gefährdete NLTM-Protokoll (NT LAN Manager) aus Windows-NT-Zeiten zum Einsatz. Beide Protokolle stammen aus der Vor-Cloud-Ära und gehen von einer direkten Erreichbarkeit des Anmeldeservers beim Anmelde- und Berechtigungsprozess aus. Dies bedeutet, dass sich sowohl das Endbenutzergerät als auch das Zielsystem in einem direkt per DNS oder WINS adressierbarem Netzwerk befinden, wo auch der Anmeldeserver stationiert ist. In dieser Konstellation wäre dies der Domaincontroller der internen AD-Umgebung.
Solange die Applikationen im eigenhändig kontrollierten Netzwerk verwaltet werden, lässt sich die Benutzerauthentifizierung – als Nachweis der Benutzeridentität – problemlos mit den Protokollen der AD-Implementierung durchführen. Die Autorisierung, also Berechtigung zur Nutzung lokaler Applikationen oder Daten, erfolgt über Protokolle, indem ein Benutzer über seinen Token die nötigen Gruppenmitgliedschaften bestätigt, die das Zielsystem überprüft. Entscheidend ist dabei, dass sämtliche Zugriffsprozesse im selbst verwalteten Netzwerk geschehen.
Cloudapplikationen wie Microsoft Teams aus der Azure Cloud werden außerhalb des lokalen Rechenzentrums vorgehalten, was einen anderen Anmeldeprozess erfordert. Das Kerberos-Protokoll zur Anmeldung und Berechtigung für die Applikationen kommt hier nicht zum Einsatz. An dessen Stelle treten neue, aus webbasierten Methoden hervorgegangene Protokoll zur Authentifizierung und Autorisierung über das lokale Netzwerk hinaus. Hierfür haben sich das XML-Framework SAML, das offene Authentifizierungsprotokoll OpenID Connect und das Autorisierungs-Framework OAuth 2.0 durchgesetzt.
Mehrfache Identitäten als Notlösung
Je nachdem, ob die jeweilige Anwendung im eigenen Rechenzentrum oder in der Cloud läuft, müssen Benutzer auf unterschiedliche Protokolle zurückgreifen. Im Fall von Microsoft Teams könnte sich ein lokaler AD-Nutzer nicht direkt anmelden, weil die lokale AD-Implementierung die erforderlichen Protokolle für eine Cloudanmeldung nicht unterstützt. Unternehmen behelfen sich, indem sie ein weiteres Nutzerkonto in einem Cloud-Directory erstellen, in diesem Fall Azure Active Directory (AAD). AAD stellt die erforderlichen Protokolle zur Authentifizierung und Autorisierung für die Cloud-Apps bereit. Auf diese Weise erfolgt der Zugang zu gängigen Clouddiensten, was für jeden Mitarbeiter eine neue ID und ein weiteres Passwort bedeutet. Im Optimalfall ist der Prozess noch mit Multifaktor-Authentifizierung (MFA) geschützt.
Mehrfache Identitäten auf verschiedenen Plattformen, die zudem separat verwaltet werden müssen, sind aber nicht das, was mit hybriden Identitäten eigentlich gemeint ist. So ist Single Sign-on für verschiedene Applikationen nicht gegeben und die Zwischenspeicherung der Zugangsdaten im Browser ist ebenfalls nicht der optimale Weg.
Hybride Identitäten richtig umgesetzt
Eine hybride Identität setzt eine direkte Beziehung zwischen den lokalen AD-Nutzer und einem entsprechenden Referenzobjekt des gleichen Nutzers im Cloud-Directory, also hier Azure AD, voraus. Entscheidend ist, dass hierfür keine separate Verwaltung des lokalen Zugriffs und des Cloudzugriffs nötig ist. Deswegen gilt es, Nutzerkennungen, Gruppen, Mitgliedschaften oder Arbeitsplätze zwischen beiden Verzeichnissen kontinuierlich zu synchronisieren, was mit Microsoft Azure AD Connect erfolgt. Microsoft hat dieses Tool laut eigenen Angaben entwickelt, um Hybrididentitätsziele zu erfüllen und zu erreichen.
Azure AD Connect bietet Kennwort-Hash-Synchronisierung für das lokale AD-Kennwort eines Benutzers mit Azure AD und Passthrough-Authentifizierung, um Benutzern die Verwendung des gleichen Kennworts lokal und in der Cloud zu ermöglichen. Die Verbundintegration dient dabei zum Konfigurieren einer Hybridumgebung mithilfe einer lokalen AD-FS-Infrastruktur. Die Synchronisierung als weiteres Funktionsmerkmal ist verantwortlich für das Erstellen von Benutzern, Gruppen und anderen Objekten und stellt auch sicher, dass Identitätsinformationen für lokale Benutzer und Gruppen denen in der Cloud entsprechen. Eine Systemüberwachung ist zudem optional mit Azure AD Connect möglich.
Drei Authentifizierungsmethoden zur Wahl
Der wichtigste Vorteil richtig umgesetzter hybrider Identitäten ist, dass Benutzer kein separates Passwort eingeben müssen. Die Anmeldung erfolgt laut Microsoft wahlweise mit drei Authentifizierungsmethoden: Passwort-Hash-Synchronisierung (PHS), Pass-Through-Authentifizierung (PTA) oder Federation (AD-FS oder andere Federation-Services).
Bei der ersten Methode, der Passwort-Hash-Synchronisierung, wird das Passwort des Nutzers aus dem lokalen AD mittels einer weiteren Verschlüsselung, dem Hash des Hashs, an Azure AD übermittelt. Bei der Anmeldung an Teams gibt der Nutzer in der Regel als Kennung seine E-Mail-Adresse an und kann sich dann mit dem gleichen Passwort wie dem seiner lokalen AD-Kennung bei Azure AD zur Nutzung von Teams anmelden. Bei einer Änderung des lokalen AD-Passworts verändert sich auch das Passwort in AAD. Durch eine zusätzliche MFA-Prüfung lässt sich die Sicherheit noch erhöhen.
Die Synchronisierung der Passwörter ist aus mehreren Gründen sinnvoll. Sie ermöglicht die Überprüfung der Passwortsicherheit und die Erkennung kompromittierten Nutzerkennungen. Ebenso können Unternehmen auf diese Methode zurückgreifen, wenn Probleme mit den anderen zwei Methoden auftreten. Diese Probleme können die erforderliche Infrastruktur betreffen, also den Server mit dem PTA-Agenten, die Federation-Server oder die AD-Verfügbarkeit infolge eines Ransomware-Angriffs, bei dem alle Domaincontroller außer Gefecht gesetzt wurden.
Die zweite Methode, die Passthrough-Authentifizierung, erfordert ein oder mehrere Hilfssysteme in der lokalen Umgebung, um die Anmeldung der AAD-Nutzer an das lokale AD zur Passwortprüfung weiterreichen zu können. Nutzer melden sich somit mit ihrer AAD-Kennung bei Teams an. Die Validierung des eingegebenen Passworts erfolgt aber durch lokale AD Domain Controllern. Die AAD-Anmeldung lässt sich zusätzlich mit einer MFA-Prüfung koppeln, was aus Sicherheitsperspektive einen Pluspunkt darstellt.
Für Federation – als dritte Methode – ist eine noch umfangreichere Infrastruktur erforderlich. Der komplette Anmeldevorgang wird hierbei von den lokalen Federation-Servern gesteuert, die im Hintergrund die Authentifizierung der Nutzer am lokalen AD vornehmen. Nach der Anmeldung erfolgt eine Rückmeldung an AAD. Bei einer Anmeldung an Microsoft Teams sehen die Nutzer auf ihrem Bildschirm somit die unternehmensinterne Federation-Webseite. Zu den Federation-Services zählt auch die Abwicklung der MFA-Prüfung zur Anmeldung an AAD.
Die Gemeinsamkeit der drei beschriebenen Methoden liegt in einer direkten Verknüpfung zwischen den lokalen AD-Nutzern und deren synchronisierten Pendants in Azure AD, was als hybride Identitäten bezeichnet wird.
Umdenken und völlig neuer Ansatz erforderlich
Anhand der beschriebenen Thematik soll auch deutlich werden, dass es für den Anmeldeprozess nicht auf den Standort einer Applikation ankommt, sondern darum, welche Protokolle eine Applikation unterstützt. Dies bedeutet, dass eine .NET-Applikation durch die Migration einer virtuellen Maschine vom lokalen Rechenzentrum in die Cloud nicht mit modernen Web-Authentifizierungsprotokollen zurechtkommt. Es handelt sich weiterhin um eine herkömmliche Anwendung der Vor-Cloud-Ära und zur Verwaltung ist weiterhin die Anmeldung an das lokale AD erforderlich. Selbst wenn ein Unternehmen alle lokalen AD Domain Controller in der Cloud hosten würde, unterstützen diese weiterhin nur Kerberos und sind damit angreifbar
Fazit
Seit mehr als zwei Jahrzehnten ist Microsofts Active Directory die gängige Methode zur Authentifizierung und Autorisierung von Benutzern, damit diese auf Computer, Hardwareperipherie und Anwendungen zugreifen können. Das AD punktet mit umfassender Kompatibilität mit verschiedenen Anwendungen und Windows-Editionen, was jedoch auch von Nachteil sein kann. Der Verzeichnisdienst zentralisiert den Zugriff auf geschäftskritische Daten. Ein Angreifer, dem es gelingt, ins Netzwerk einzudringen, kann somit erheblichen Schaden anrichten. Unternehmen, die auf eine hybride Umgebung umsteigen, sehen sich mit einer komplexen Herausforderung konfrontiert. Die Erweiterung von der bisherigen ausschließlich lokalen AD-Nutzung auf Cloudauthentifizierung erfordert daher ein Umdenken und einen völlig neuen Ansatz.
Autor: Guido Grillenmeier, Chief Technologist bei Semperis