Zugriffssteuerung mit Conditional Access

Conditional Access ist aus gutem Grund das meistgenutzte Produkt der Enterprise Mobility Suite (EMS) von Microsoft: Die Identität ist in einer Cloud- und servicebasierten IT-Infrastruktur der Dreh- und Angelpunkt der Sicherheit. Alle Dienste werden über die Identität abgesichert. Das bedeutet einerseits, dass ein Angreifer mit der richtigen gestohlenen Identität alle Absicherungen und Verschlüsselungen aushebeln kann – aus Sicht des Dienstes darf der Angreifer ja auf alles zugreifen und alles entschlüsseln. Umgekehrt gibt es keine Server und Netzwerke mehr, die ein Angreifer übernehmen könnte – nur ständig gewartete und rund um die Uhr von Sicherheitsspezialisten überwachte Cloud-Systeme.

In diesem Blog-Artikel geht es darum, was Conditional Access ist, warum und wie man es einsetzt.

Authentifizierung gestern und heute

Ein weit verbreitetes Protokoll zwischen Mailclients und -servern ist IMAP. Es ist einfach, zu einem IMAP Server zu verbinden, einzuloggen, die Inbox zu selektieren und wieder auszuloggen:

john@host:~$ telnet 172.16.1.2 143
Trying 172.16.1.2...
Connected to 172.16.1.2.
Escape character is '^]'.

OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.

a001 login john secretpassword

a001 OK [CAPABILITY ...] Logged in

a002 select inbox

FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
0 EXISTS
0 RECENT
OK [UIDVALIDITY 1550581823] UIDs valid
OK [UIDNEXT 1] Predicted next UID
a002 OK [READ-WRITE] Select completed (0.000 + 0.000 secs).

a003 logout

BYE Logging out
a003 OK Logout completed (0.000 + 0.000 secs).

Connection closed by foreign host.
john@host:~$

Entscheidend für die Authentifizierung ist eine kurze Zeile:

a001 login john secretpassword

Mehr als der Benutzername (john) und das Passwort (secretpassword) wird für die Authentifizierung nicht benötigt. So wie in diesem Beispiel bei IMAP reichte in der Vergangenheit ein kompromittiertes Paar aus Benutzername und Passwort in vielen Fällen aus, um an die Daten eines Benutzers zu gelangen.

Neben dem schwachen Schutz der Identität nur durch ein Passwort haben solche und ähnliche als Legacy Authentication bezeichneten Authentifizierungsvorgänge einen weiteren erheblichen Nachteil: Eine unternehmensinterne, zentrale Identitätsverwaltung, wie zum Beispiel Active Directory, hat technische Grenzen, die nicht überschritten werden können. Daraus resultiert eine Fragmentierung bei der Verwaltung von Identitäten auf verschiedenen Systemen; Benutzernamen und Passwörter müssen an verschiedenen Stellen gepflegt werden.

Neuere Authentifizierungsprotokolle adressieren die Bedürfnisse einer modernen IT Landschaft.

• Ein weltweit erreichbares zentrales System zur Verwaltung von Identitäten, mit denen auch der Zugriff auf Fremddienste möglich ist. Ziel ist, alle Zugriffe über eine einzige Identität zu autorisieren (Single Sign-on).
• Absicherung der Authentifizierungsvorgänge durch einen zweiten Faktor, so dass ein kompromittiertes Paar aus Benutzername und Passwort alleine nicht mehr für einen Angriff ausreicht.
• Administratoren können zusätzliche schwächere oder stärkere Bedingungen für die Authentifizierung definieren, je nach Schutzbedarf der Dienste und Daten.

Die Lösung sind tokenbasierte, claims-orientierte Authentifizierungsprotokolle. Frühere Implementierungen solcher Protokolle, wie WS-Federation und SAML, sind teilweise noch weit verbreitet und werden auch von Microsoft Azure AD unterstützt, aber nicht mehr innovativ weiterentwickelt. OAuth2 und OpenID Connect sind aus heutiger Sicht die Protokolle der Zukunft.

Microsoft setzt mit Azure AD als Identitätsprovider voll auf OAuth2 und OpenID Connect. Azure AD bietet mit Conditional Access ein Gerüst, mit dem flexibel die Bedingungen für die Authentifizierung bei unterschiedlichen Diensten definiert werden können.

Sinnvolle Regeln

Bei der Sicherung der Identität bietet Conditional Access mit jeder weiteren Regel einen Sicherheitsgewinn, mal in kleinen, mal in größeren Schritten. Mit ein paar Klicks aktiviert man schon die vordefinierte Regel, die Multifaktorauthentifizierung für Administratoren erzwingt.

Eine andere sinnvolle Regel wäre es, für die Anmeldung außerhalb des Unternehmensnetzes entweder ein modernes, sicheres Gerät (“Compliant Device”) zu verlangen oder MFA. Veraltete Authentifizierugsmethoden, etwa IMAP, die gar keine Prüfung auf das “Compliant Device”-Flag und MFA zulassen, sollte man mit einer weiteren Regel ausschalten.

Fallstricke

Ein gut abgestimmtes Gesamtregelwerk zu definieren, hat aber auch seine Tücken. Zum Beispiel kann der Account für AAD Connect kein MFA, wodurch die Synchronisation zwischen dem AD on-premises und dem AAD in der Cloud nicht mehr funktioniert, wenn der entsprechende Account nicht aus den Regeln ausgenommen wird.

Im letzten November fiel Microsofts MFA-Dienst mehrere Tage aus. Eine Anmeldung mit Administrator-Konten war deswegen unmöglich, normale Nutzer konnten meist noch halbwegs weiterarbeiten, solange kein MFA erforderlich wurde. Microsoft setzte danach verschiedene Maßnahmen zur Qualitätsverbesserung um. Aber sollte man deswegen einfach die Daumen drücken und hoffen, dass so ein Problem nicht erneut auftritt? Schon vor dem Ereignis empfahl Microsoft bei den Administratoren einen sogenannten Break-Glass-Account vom MFA-Zwang auszunehmen. Mit diesem Account kann man fix die MFA-Regel ausschalten und somit ein paar Tage ohne MFA arbeiten.

Umsetzung

Aus unserer Erfahrung sollte man zur Konfiguration eines Conditional-Access-Regelwerks zunächst klar definieren, welche Anforderungen man hat: Welche Arten von Mobilgeräten sind zugelassen? Dürfen Nutzer ihre privaten Systeme nutzen, sei es zu Hause oder von öffentlichen Terminals? Gibt es “unsichere” Altgeräte, die keine modernen Authentifizierungsprotokolle unterstützen, aber Cloud-Dienste nutzen sollen?

Diese Anforderungen kann man zunächst unabhängig von der konkreten Umsetzung in Conditional Access aufstellen. Wahrscheinlich sehen die Regeln in Conditional Access später anders aus. Manche Regel, die in natürlicher Sprache klar abgegrenzt wirkt, bildet in Conditional Access besser ein Regelpaar. Andere Regeln lassen sich in Conditional Access zusammenfassen, wodurch sie allgemeingültiger werden und dadurch einerseits einfacher zu verstehen sind, andererseits robuster gegenüber zukünftigen Veränderungen sind.

Grundregelwerk

Wir haben gute Erfahrungen damit gemacht, unseren Kunden ein Grundregelwerk zu empfehlen, das je nach Anforderungen noch im Detail angepasst wird. Mit unseren Kollegen tauschen wir uns dazu regelmäßig aus und pflegen in unserem G&K-Cloud-Blueprint ein ständig aktualisiertes “Musterregelwerk”. So fließen Erfahrungen der Kunden zurück in das Musterregelwerk und kommen auch anderen Kunden zu Gute. Außerdem fällt es uns als Gruppe leichter, die zahlreichen Entwicklungen bei Conditional Access und anderen Cloud-Produkten nachzuvollziehen und mit entsprechenden Conditional-Access-Regeln umzusetzen.

Mehr zu Conditional Access

In den nächsten Wochen werden wir einen ausführlicheren, technischen Artikel zur Umsetzung von Conditional Access veröffentlichen und in einem Webcast erklären. Mehr demnächst auf glueckkanja.com!