Die Zukunft von Web Access Management

Zürich, 15.08.2014 – Martin Burkhart

Fachartikel für security-zone.info

 

Identity und Access Management (IAM)-Lösungen sind aktuell mit zwei schwierigen Herausforderungen konfrontiert. Erstens betreiben Unternehmen vermehrt Teile ihrer Infrastruktur in der Cloud. Dies reduziert Kosten, erhöht die Flexibilität bezüglich Speicher- und Ressourcenbedarf und vereinfacht Backup- und Recovery-Prozesse. Typischerweise werden jedoch nach wie vor Teile der Infrastruktur lokal betrieben. Dadurch erhöht sich die Komplexität für den Betrieb, der sich plötzlich mit einer hybriden Architektur konfrontiert sieht. Dies verkompliziert insbesondere das Access Management, da die Benutzer ein nahtloses Zusammenspiel der verschiedenen Dienste erwarten, egal wo diese betrieben werden. Zweitens müssen sich Unternehmen zusehends mit föderierten Benutzeridentitäten auseinandersetzen. Für die eigenen Mitarbeitenden besteht meist bereits die Möglichkeit, entweder aus dem Intranet oder von unterwegs auf Dienste zuzugreifen. Zusätzlich müssen Konten für Kunden, Partner oder einmalige Zugriffe, z.B. für die Teilnahme an einem Onlinewettbewerb, verwaltet werden. Gerade für einmalige Zugriffe möchten die Besucher nicht noch ein zusätzliches Benutzerkonto mit Passwort erstellen müssen. Ist Ihr IAM bereit, den Kunden mit seinem Facebook-Konto einloggen zu lassen?

Lokal oder in der Cloud?

Damit die Herausforderungen von Cloud-Infrastrukturen und föderierten Benutzeridentitäten erfolgreich gemeistert werden können, braucht es eine Access-Management-Lösung, die von den Applikationen entkoppelt ist.

 

Die Web Application Firewall (z.B. Airlock) dient als zentraler Einstiegspunkt ins Firmennetzwerk und inspiziert den Verkehr zwischen Benutzern und den Webapplikationen. Dabei werden bösartige Aktionen und Angriffe gefiltert. Zusätzlich können einige WAFs eine vorgelagerte Authentisierung und Autorisierung von Benutzersessions erzwingen. Dies bedeutet, dass nur Anfragen von berechtigten Benutzern an die Applikationen weitergeleitet werden. Die Authentisierung und Autorisierung wird an den IAM-Server (z.B. Medusa) delegiert, der die Benutzeridentitäten verwaltet und an bestehende Benutzerverzeichnisse angeschlossen ist. Die Identität von authentisierten Benutzern wird zusammen mit ihren Berechtigungen mittels Identity Propagation an die Applikationen weitergeleitet. Eine Web Application Firewall in der Cloud zu installieren, ist ein logischer Folgeschritt, da die Applikationen in der Cloud denselben Schutz wie im lokalen Betrieb benötigen. Nur mit einer WAF in der Cloud ist zudem sichergestellt, dass die Cloud-basierten Applikationen unabhängig von der lokalen Infrastruktur skaliert werden können. Bevor man allerdings das Management der Benutzeridentitäten in die Cloud verlagert, muss genau geklärt werden, ob dies aufgrund der Sensitivität der Daten zulässig und wünschenswert ist. Airlock und Medusa können in hybriden Architekturen eingesetzt werden und folgen den Applikationen bei Bedarf in die Cloud. Airlock kann beispielsweise in der Amazon EC2 installiert werden. Medusa ist komplett in Java geschrieben und kann daher ebenfalls auf den meisten Cloud-Plattformen betrieben werden. Die Zugriffe auf einen Airlock in der Cloud können bei Bedarf über eine VPN-Verbindung an eine bestehende lokale Medusa-Instanz zur Authentisierung weitergeleitet werden, wie in Abbildung 1 illustriert. Damit erreicht man ein zentrales Access Management für hybride Infrastrukturen mit lokaler Verwaltung aller sensitiven Benutzerinformationen. Die Benutzer können nahtlos auf alle Applikationen zugreifen. Die Tatsache, dass Applikation E in der Cloud und Applikation A lokal betrieben wird, ist für den Benutzer völlig transparent.

Cross-domain Single Sign-on (SSO)

Wird die IT-Infrastruktur durch Cloud-basierte Elemente ergänzt, befinden sich Benutzer plötzlich ein einem Cross-domain Szenario. Mitarbeitende aus dem internen Netzwerk möchten beispielsweise auf einen Dienst zugreifen, der in der Cloud betrieben wird. Mitarbeitende, die von zuhause arbeiten, sollten wiederum auf Dienste eines Partners zugreifen können. Kunden eines Partners sollen ohne zusätzliches Konto beim eigenen Wettbewerb mitmachen können, der auf lokalen Servern läuft. Ein wichtige Voraussetzung für flexible SSO-Lösungen ist die Entkoppelung der Benutzerauthentisierung von der Identity Propagation (siehe Abbildung 2). Ist die Technik zur Benutzerauthentisierung unabhängig von den Standards, mit denen Benutzer gegenüber Applikationen repräsentiert werden (Identity Propagation), eröffnet sich plötzlich eine Vielzahl möglicher Zugriffsszenarien.

 

Wenn der IAM-Server die neuen Standards SAML 2.0, OAuth 2.0 und OpenID Connect unterstützt, wird echter Cross-domain Single Sign-on möglich. Zuerst muss die Identität und die Berechtigung eines Benutzers überprüft werden. Die Mittel dazu sollten je nach Benutzer und Einstiegspunkt variabel sein können. Interne Benutzer sind dem Netzwerk durch den Login am Arbeitsplatz vielleicht bereits bekannt und können implizit durch ein Kerberos-Ticket authentisiert werden. Für den Zugriff von externen Mitarbeitenden wird oft zusätzlich zum Passwort ein OTP-Token eingesetzt, während sich Geschäftspartner mit einer SAML-Assertion ausweisen können. Ist die Benutzeridentität festgestellt, hängt die Art der gewählten Identity Propagation wiederum vom erwünschten Zugriff ab. Für interne Applikationen kann beispielsweise ein JAAS-Ticket verwendet werden. Für externe Dienste kommt vielleicht eine SAML-Assertion oder OAuth 2.0 in Frage. Die Entkopplung von Authentisierung und Identity Propagation ermöglicht diverse Kombinationen von Benutzertypen, Einstiegspunkten und Zieldiensten – auch in Cross-domain Szenarien. Ein modernes Web Access Management System muss sicheren Zugriff auf Applikationen gewährleisten, egal

 

1. ob Applikationen lokal oder in der Cloud laufen
2. woher die Benutzer kommen
3. wie sich Benutzer authentisieren
4. wohin die Benutzer wollen.