Manche Fragen erfordern nur eine Ja- oder Nein-Antwort. Wenn Sie ein Restaurant anrufen und fragen: "Kann ich eine Reservierung für 14:00 Uhr vornehmen?", wären einige vernünftige Antworten "Ja", "Nein" oder "Wir haben nur Sitzplätze im Freien verfügbar. Ist das in Ordnung?
Sie wären wahrscheinlich überrascht, Folgendes zu hören: "Ja, aber eine Gruppe mit ungeraden Zahlen sollte einen Platz vorne im Restaurant reservieren, während eine Gruppe mit geraden Zahlen einen Platz hinten reservieren sollte. Bitte tragen Sie außerdem weiße Kleidung und betreten Sie das Restaurant mit dem linken Fuß, da Sie sonst abgewiesen werden."
Die Überraschung wäre hier zweifach: Erstens haben Sie eine so lange Antwort nicht erwartet, und zweitens scheint es nicht so, als ob diese Bedingungen überhaupt existieren sollten.
Es stellt sich heraus, dass die Durchsetzung der Multi-Faktor-Authentifizierung (MFA) ähnlich funktioniert. Während man erwarten würde, dass die Frage "Ist dieses Konto durch MFA geschützt?" eine einfache Ja/Nein-Antwort hat, ist die Realität oft viel komplizierter. Oft erzwingen einige Szenarien MFA für den App-Zugriff, während andere Szenarien den Zugriff ohne MFA erlauben – manchmal absichtlich, aber oft nicht.
Das Problem mit der Fragmentierung
Eines der wichtigsten Merkmale einer Lösung wie Okta Identity Security Posture Management ist die Fähigkeit, alle Authentifizierungsszenarien zu verfolgen, die zu jedem Konto in Ihren SaaS-Apps führen, und den Schutzstatus zu verstehen, den jedes einzelne beinhaltet.
Dies ist eine einfache Aufgabe, wenn nur ein einziger Identitätsanbieter die Authentifizierung einer Anwendung ermöglicht. Es wird jedoch viel komplexer, wenn man verschiedene Authentifizierungsrichtlinien, Migrationen von früheren Identitätslösungen, Hub-and-Spoke-Modelle und unterschiedliche SaaS-Anwendungen hinzufügt, die unterschiedliche Regeln für direkte Anmeldungen und die Durchsetzung von MFA anwenden. All dies führt zu einer Vielzahl von Anmeldeszenarien, wodurch es schwieriger wird, diese zu verfolgen – und zu schützen.
In diesem Blogbeitrag werden wir viele dieser Ursachen der Fragmentierung genauer unter die Lupe nehmen und ihre potenziellen Auswirkungen untersuchen.
Authentifizierungsrichtlinien
Authentifizierungsrichtlinien, oft auch als Conditional Access Policies bezeichnet, werden verwendet, um Faktor-Anforderungen durchzusetzen, wenn sich Benutzer bei Apps anmelden oder bestimmte Aktionen ausführen.
Es gibt viele Gründe, verschiedene Arten von Faktoren zuzulassen (oder sich sogar ohne MFA anzumelden):
- Verschiedene Plattformen ermöglichen die Verwendung verschiedener Faktoren (und infolgedessen sind einige Plattformen möglicherweise nur für bestimmte Anwendungen zugänglich).
- Unterscheidung zwischen firmeneigenen Geräten und BYOD (Bring Your Own Device)
- Ausnahme für Servicekonten und nicht-personenbezogene Identitäten
- Keine MFA beim Zugriff auf nicht sensible Ressourcen zu verlangen, um die MFA-Müdigkeit zu reduzieren
Natürlich müssen diese Unterschiede in den Anforderungen berücksichtigt werden, wenn der Durchsetzungsstatus eines Kontos angezeigt wird.
Versehentliche Lücken in der Richtlinienkonfiguration
Verschiedene Identitätsanbieter ermöglichen es Ihnen, Authentifizierungsrichtlinien auf unterschiedliche Weise zu konfigurieren.
Während Okta ein prioritätsbasiertes Modell für die Einrichtung von Authentifizierungsrichtlinien verwendet, konfigurieren andere Anbieter „globale“ Richtlinien, wobei die „schwerwiegendste“ Aktion wirksam wird.
Obwohl beide Methoden oberflächlich betrachtet gleichwertig erscheinen, erschwert die zweite Methode das Herausarbeiten von Ausnahmen von allen Richtlinien erheblich, was oft zu Sicherheitslücken führt.
Obwohl dieses Beispiel simpel und unwahrscheinlich ist, wenn nur wenige Richtlinien konfiguriert werden, sollte man sich Folgendes merken:
- Große Unternehmen haben oft Dutzende von Richtlinien, wodurch es wahrscheinlich ist, solche Fälle zu übersehen (wir stoßen in der Praxis häufig auf diese Lücken, wenn wir bedingte Zugriffsrichtlinien analysieren, die in anderen Identitätsanbietern eingerichtet sind).
- Obwohl es unwahrscheinlich ist, dass sich jemand über ungewöhnliche Plattformen anmeldet, werden Plattformbedingungen anhand des User-Agent ausgewertet, der bei Credential-Stuffing-Kampagnen leicht und häufig gefälscht wird.
Alternative Anmeldemethoden
Während die treibende Kraft hinter Single Sign-On (SSO) darin besteht, dass der Zugriff auf alle Anwendungen von einem einzigen Ort aus verwaltet werden kann, gibt es oft mehrere Möglichkeiten, auf ein bestimmtes Konto in einer bestimmten Anwendung zuzugreifen. Lassen Sie uns einige dieser Fälle überprüfen.
Direkte Anmeldung
Oft können sich Konten, die über SSO auf eine Anwendung zugreifen können, auch direkt bei der Anwendung anmelden (entweder über eine Kombination aus Benutzername und Kennwort oder über Zugriffsschlüssel).
Obwohl dies oft eine bewusste Entscheidung ist (z. B. um im Notfall einen Administratorzugriff zu ermöglichen oder während der Anwendungseinrichtung), kann es manchmal unbeabsichtigt geschehen. In einigen Diensten muss der Kennwortzugriff möglicherweise pro Benutzer deaktiviert werden, selbst wenn SSO eingerichtet ist. In anderen Diensten können sich Administratorkonten immer direkt anmelden, ohne dass es eine Möglichkeit gibt, dies zu deaktivieren.
Das Wichtigste, was Sie verstehen müssen, ist, dass sich jede Anwendung anders verhält und es kein einheitliches Verhalten gibt, auf das man sich verlassen kann. Wenn MFA für ein Konto konfiguriert ist, werden einige Anwendungen weiterhin dazu auffordern, selbst wenn sich der Benutzer über Single Sign-On (SSO) anmeldet, während einige nur dann zur MFA auffordern, wenn sich der Benutzer direkt angemeldet hat. Andere Dienste könnten sogar die Konfiguration erlauben, welches der beiden Verhaltensweisen eintreten soll.
Mehrere SSO-Anbieter
In vielen Fällen kann auf bestimmte Konten in einer Anwendung über mehrere Identitätsanbieter zugegriffen werden. Solche Fälle können auftreten aufgrund von:
- Verschiedene Tochtergesellschaften oder Abteilungen verwenden verschiedene Identitätsanbieter, mit potenziellen Überschneidungen dazwischen.
- Überbleibsel von früheren Identitätslösungen, bei denen eine Migration den neuen Identitätsanbieter aktiviert, aber den alten nie deaktiviert hat.
- Testkonfigurationen, die für bestimmte Konten verwendet werden oder bevor die gesamte Organisation registriert wird
Manchmal sind diese mehreren Anbieter bekannt und berücksichtigt; andere Male sind diese Einstellungen versteckt und leicht zu übersehen.
Faktorstärke
Bisher hat alles, was wir besprochen haben, „MFA/Kein-MFA“ als binäre Frage behandelt, aber die Realität ist komplizierter.
Da SMS-Nachrichten anfällig für Übernahmen und Phishing-Angriffe sind, zieht es Ihre Organisation möglicherweise vor, nur phishing-resistente Faktoren durchzusetzen oder sogar traditionelle MFA ganz aufzugeben und stattdessen passwortlos zu werden.
Eine solche Bemühung erfordert das Durchforsten dieser verschiedenen Authentifizierungsszenarien, da es darum geht, die Authentifizierungsstärke in jedem einzelnen zu verstehen.
In diesem Blogbeitrag haben wir die Komplexität der MFA-Erzwingung aufgedeckt. Faktoren wie Authentifizierungsrichtlinien, mehrere SSO-Provider und Unterschiede im Anwendungsverhalten machen sie zu allem anderen als einem einfachen Ja/Nein-Status.
Um die Herausforderungen zu meistern, die diese Komplexität mit sich bringt, empfehlen wir die Einführung einer umfassenden Strategie zur Aufrechterhaltung des Authentifizierungsstandards Ihres Unternehmens und zur regelmäßigen Überprüfung, ob alle Konten ordnungsgemäß geschützt sind. Okta Identity Security Posture Management hilft Ihnen, Einblick in unerwartete Authentifizierungsabläufe zu gewinnen und einen einheitlichen Standard für die Authentifizierung in Ihrem Unternehmen sicherzustellen.
Haben Sie Fragen zu diesem Blogbeitrag? Kontaktieren Sie uns unter eng_blogs@okta.com.
Entdecken Sie weitere aufschlussreiche Engineering-Blogs von Okta, um Ihr Wissen zu erweitern.
Möchten Sie unserem leidenschaftlichen Team von außergewöhnlichen Ingenieuren beitreten? Besuchen Sie unsere Karriereseite.
Schöpfen Sie das Potenzial eines modernen und ausgefeilten Identity Managements für Ihr Unternehmen aus. Kontaktieren Sie den Vertrieb für weitere Informationen.
Dieser Blog und alle darin enthaltenen Empfehlungen stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. Dieser Blog dient nur allgemeinen Informationszwecken und spiegelt möglicherweise nicht die aktuellsten Sicherheits-, Datenschutz- und Rechtsentwicklungen oder alle relevanten Themen wider. Sie sind dafür verantwortlich, Rechts-, Sicherheits-, Datenschutz-, Compliance- oder Geschäftsberatung von Ihrem eigenen Anwalt oder einem anderen professionellen Berater einzuholen, und sollten sich nicht auf die hierin enthaltenen Empfehlungen verlassen. Okta haftet Ihnen gegenüber nicht für Verluste oder Schäden, die aus Ihrer Implementierung von Empfehlungen in diesen Materialien resultieren. Okta gibt keine Zusicherungen, Garantien oder andere Zusagen in Bezug auf den Inhalt dieser Materialien.
