Manche Fragen erfordern lediglich eine Ja- oder Nein-Antwort. Wenn Sie in einem Restaurant anrufen und fragen: „Könnte ich eine Reservierung für 14:00 Uhr vornehmen?“, wären einige sinnvolle Antworten „Ja“, „Nein“ oder „Wir haben nur Sitzplätze im Freien zur Verfügung. Ist das in Ordnung?
Sie wären wahrscheinlich überrascht, das zu hören: "Ja, aber eine Gruppe mit ungerader Anzahl von Personen sollte einen Platz im vorderen Bereich des Restaurants reservieren, während eine Gruppe mit gerader Anzahl einen im hinteren Bereich reservieren sollte." Bitte tragen Sie außerdem weiße Kleidung und betreten Sie das Restaurant mit dem linken Fuß; andernfalls werden Sie abgewiesen."
Die Überraschung hier wäre zweifach: Erstens haben Sie keine so lange Antwort erwartet, und zweitens... scheint es nicht so, als ob diese Bedingungen überhaupt existieren sollten.
Es stellt sich heraus, dass die Multi-Faktor-Authentifizierung (MFA) ähnlich funktioniert. Während Sie erwarten würden, 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 ermöglichen – manchmal absichtlich, aber oft nicht.
Das Problem mit der Fragmentierung
Eines der wichtigsten Merkmale, auf die Sie bei einer Lösung wie Okta Identity Security Posture Management achten sollten, ist die Möglichkeit, 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 zulässt. Es wird jedoch viel komplexer, wenn man unterschiedliche Authentifizierungsrichtlinien, Migrationen von früheren Identitätslösungen, Hub-and-Spoke-Modelle und verschiedene SaaS-Anwendungen hinzufügt, die unterschiedliche Regeln für direkte Anmeldungen und MFA-Erzwingung anwenden. All dies führt zu vielfältigen Anmeldeszenarien, wodurch es schwieriger wird, diese zu verfolgen – und zu schützen.
In diesem Blogbeitrag werden wir uns eingehender mit vielen dieser Fragmentierungsquellen befassen und ihre potenziellen Auswirkungen untersuchen.
Authentifizierungsrichtlinien
Authentifizierungsrichtlinien, die oft als Richtlinien für bedingten Zugriff bezeichnet werden, 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 sogar die Anmeldung ohne MFA zu ermöglichen):
- 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
- Ausnahme für Servicekonten und nicht-menschliche Identitäten
- Keine MFA (Multifaktor-Authentifizierung) erforderlich, wenn auf nicht sensible Ressourcen zugegriffen wird, um die MFA-Müdigkeit zu verringern.
Natürlich müssen diese unterschiedlichen 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 Herausfiltern von Ausnahmen von allen Richtlinien erheblich, was häufig zu Sicherheitslücken führt.
Obwohl dieses Beispiel vereinfacht und unwahrscheinlich ist, wenn nur wenige Richtlinien konfiguriert werden, sollte man sich Folgendes merken:
- Große Unternehmen haben oft Dutzende von Richtlinien eingerichtet, wodurch es wahrscheinlich ist, solche Fälle zu übersehen (wir stoßen häufig auf diese Lücken in der Praxis, wenn wir in anderen Identitätsanbietern eingerichtete Richtlinien für bedingten Zugriff analysieren).
- Es ist zwar unwahrscheinlich, dass jemand ungewöhnliche Plattformen bei der Anmeldung verwendet, aber die Plattformbedingungen werden anhand des User-Agent bewertet, der bei Credential-Stuffing-Kampagnen leicht und häufig gefälscht wird.
Alternative Anmeldemethoden
Die treibende Kraft hinter Single Sign-On (SSO) ist zwar, dass der Zugriff auf alle Anwendungen von einem einzigen Ort aus verwaltet werden kann, aber es gibt oft mehrere Möglichkeiten, auf ein bestimmtes Konto in einer bestimmten Anwendung zuzugreifen. Lassen Sie uns einige dieser Fälle betrachten.
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 Benutzername-Passwort-Kombination oder über Zugriffsschlüssel).
Obwohl dies oft eine bewusste Entscheidung ist (z. B. um einen Notfall-Administratorzugriff zu ermöglichen oder während der Anwendungseinrichtung), kann dies manchmal unbeabsichtigt geschehen. In einigen Diensten muss der Passwortzugriff möglicherweise pro Benutzer deaktiviert werden, selbst wenn SSO eingerichtet ist. In anderen Diensten können Administratorkonten immer direkt angemeldet werden, ohne dass es eine Möglichkeit gibt, dies zu deaktivieren.
Das Wichtigste ist zu verstehen, dass sich jede Anwendung anders verhält und es kein allgemeingültiges Verhalten gibt, auf das man sich verlassen kann. Wenn MFA für ein Konto konfiguriert ist, werden einige Anwendungen trotzdem 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 erlauben möglicherweise sogar das Konfigurieren, 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önnten auftreten aufgrund von:
- Verschiedene Tochtergesellschaften oder Abteilungen verwenden unterschiedliche Identitätsanbieter, wodurch es zu Überschneidungen kommen kann.
- Überbleibsel von früheren Identitätslösungen, bei denen eine Migration den neuen Identitätsanbieter aktiviert, aber den alten nie deaktiviert hat.
- Testen von Konfigurationen, die für bestimmte Konten verwendet werden oder bevor die gesamte Organisation registriert wird
Manchmal sind diese mehreren Anbieter bekannt und werden berücksichtigt; andere Male sind diese Einstellungen versteckt und leicht zu übersehen.
Faktorstärke
Bisher haben wir alles, was wir besprochen haben, als eine binäre Frage „MFA/Kein-MFA“ behandelt, aber die Realität ist komplizierter als das.
Da SMS-Nachrichten anfällig für Übernahmen und Phishing-Angriffe weit verbreitet sind, zieht es Ihre Organisation möglicherweise vor, nur Phishing-resistente Faktoren durchzusetzen oder sogar traditionelle MFA ganz aufzugeben und stattdessen Passwortlos zu werden.
Ein solches Unterfangen erfordert das Durchforsten dieser verschiedenen Authentifizierungsszenarien, da es das Verständnis der Authentifizierungsstärke in jedem einzelnen beinhaltet.
In diesem Blog-Beitrag haben wir die Komplexität hinter der MFA-Erzwingung aufgedeckt. Faktoren wie Authentifizierungsrichtlinien, mehrere SSO-Anbieter und Unterschiede im Anwendungsverhalten machen sie alles andere als einen einfachen Ja/Nein-Status.
Um die Herausforderungen dieser Komplexität zu meistern, empfehlen wir die Einführung einer umfassenden Strategie zur Aufrechterhaltung des Authentifizierungsstandards Ihrer Organisation 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 konsistenten Standard für die Authentifizierung in Ihrem gesamten 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 passionierten Team von außergewöhnlichen Ingenieuren beitreten? Besuchen Sie unsere Karriereseite.
Schöpfen Sie das Potenzial eines modernen und ausgefeilten Identitätsmanagements 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 können. Okta gibt keine Zusicherungen, Gewährleistungen oder andere Zusagen bezüglich des Inhalts dieser Materialien.
