von Redaktion IT-A…
Lesezeit
2 Minuten
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.
ln/Guido Grillenmeier, Chief Technologist bei Semperis
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.
| Seite 1 von 2 | Nächste Seite >> |
ln/Guido Grillenmeier, Chief Technologist bei Semperis
