Okta hat sich verpflichtet, seinen Kunden ein Höchstmaß an Sicherheit zu bieten. Wir gehörten zu den ersten Technologieanbietern, die sich zu den sieben Secure by Design-Prinzipien der U.S. Cybersecurity and Infrastructure Security Agency (CISA) bekannt haben, und vor einem Jahr haben wir das Okta Secure Identity Commitment ins Leben gerufen.
Im Rahmen dieser Initiativen haben wir eine Reihe wesentlicher Funktionen und Upgrades für unsere Unternehmensinfrastruktur und unser Produktportfolio angekündigt und bereitgestellt. Dies beinhaltet die Ermutigung der Kunden, eine der wirksamsten verfügbaren Sicherheitsmaßnahmen zu nutzen: einen starken und konsistenten Ansatz für die Multi-Faktor-Authentifizierung (MFA). Um das Sicherheitsniveau für alle zu erhöhen, haben wir 2024 mit der Erzwingung von MFA für alle Okta Admin Console-Logins begonnen. Es ist ein intelligenter, notwendiger Schritt in unserem gemeinsamen Engagement für Identity-First Security.
Heute sind wir stolz darauf, bekannt zu geben, dass Okta innerhalb eines Jahres eine 100-prozentige MFA-Durchsetzung für die Okta Admin Console für alle bestehenden Okta-Mandanten erreicht hat. Und für alle neuen Mandanten ist MFA eine standardmäßige und unveränderliche Voraussetzung für Zugriffsrichtlinien für die Okta Admin Console.
Warum wird MFA für die Okta Admin Console erzwungen?
Die Okta Admin Console ist der zentrale Knotenpunkt für die Verwaltung von Okta-Benutzern, Okta-geschützten Anwendungen und Okta-Sicherheitsrichtlinien. Unbefugter Zugriff auf diese Konsole kann verheerende Folgen haben, darunter:
- Datenschutzverletzungen: Angreifer konnten auf sensible Benutzerinformationen und Anwendungsdaten zugreifen.
- Systemkompromittierung: Bedrohungsakteure können Sicherheitseinstellungen ändern, Hintertürkonten erstellen und kritische Sicherheitsfunktionen deaktivieren.
- Serviceunterbrechung: Unbefugte Änderungen können zu Ausfällen und eingeschränkter Funktionalität für Endbenutzer führen.
- Reputationsschaden: Ein Sicherheitsvorfall kann das Geschäft und die Marke eines Unternehmens erheblich beeinträchtigen.
MFA reduziert das Risiko dieser Ergebnisse erheblich, indem zusätzlich zu einem Passwort ein zweiter Verifizierungsfaktor erforderlich ist, z. B. ein zeitbasiertes Einmalkennwort (TOTP) von einer mobilen Authentifizierungs-App, ein Fingerabdruck-Scan oder ein Hardware-Token. Während Okta nur MFA mit zwei Wissens-, Besitz- oder Inhärenzfaktoren vorschreibt, empfiehlt Okta Administratoren dringend, von Passwörtern wegzukommen und die sichersten verfügbaren Authentifikatoren zu aktivieren, darunter Phishing-resistente Authentifikatoren wie Okta Verify FastPass und FIDO2 WebAuthn Authentifikatoren.
Okta bietet robuste Funktionen, um MFA für den administrativen Zugriff zu erzwingen. Alle Okta-Mandanten verfügen über eine Basisanzahl unterstützter Faktoren wie Okta Verify TOTP, FastPass und E-Mail zusätzlich zu Passwörtern. Okta bietet auch eine flexible Richtlinie, mit der Administratoren MFA speziell für die Okta Admin Console erzwingen können.
Die Anwendungsrichtlinie für die Konsole hat schon immer standardmäßig Multi-Faktor-Authentifizierung (MFA) erfordert. Allerdings durften Administratoren die Einstellung auf Ein-Faktor-Authentifizierung (1FA) herabstufen, was viele aus verschiedenen Gründen taten. Jetzt verhindert Okta, dass diese Standard-Sicherheitsvorkehrung herabgestuft wird, und wir haben allen bestehenden Kunden geholfen, ihre Sicherheitslage mit MFA zu verbessern.
Wie wir Okta-Kunden davon überzeugt haben, MFA zu erzwingen
Sehen wir uns an, wie wir Administratoren geholfen haben, ihr tatsächliches und vermeintliches Bedürfnis nach der Beibehaltung von 1FA-Richtlinien zu überwinden und MFA einzuführen, um den Zugriff auf die Okta Admin Console zu sichern. Im Allgemeinen akzeptierten die Kunden, dass MFA eine gute Sache ist, die man einführen sollte. Es gab jedoch mehrere häufige Gründe, warum sie glaubten, dass sie auf dem 1FA-Sicherheitsniveau bleiben mussten:
- Administratoren wussten nicht, dass sie Richtlinienregeln hatten, die 1FA-Zugriff ermöglichten.
- Admins dachten, sie bräuchten keine MFA, da sie ihre Passwörter sicher verwahrten und sie bei jeder Verwendung rotierten.
- Administratoren führten MFA mit einem anderen Identity Provider (IdP) als Okta durch und wurden in die Okta Admin Console eingebunden.
- Administratoren verfügten über automatisierte Testkonten, die sich an der Konsole anmelden mussten.
- Administratoren waren besorgt über Lightweight Directory Access Protocol (LDAP)- und Active Directory (AD)-Agentenoperationen.
Wir haben uns große Mühe gegeben, auf jedes dieser Hindernisse und Bedenken einzugehen. Das letzte Problem ließ sich mit einer einfachen Bestätigung beheben, dass es keine Auswirkungen auf den normalen Agentenbetrieb geben würde.
Was den Rest betrifft, haben wir zunächst Warnungen an Administratoren veröffentlicht, wenn sie einen Mandanten mit Regeln hatten, die den 1FA-Zugriff über unsere HealthInsights-Funktion ermöglichten.
Wir haben auch Warnungen von der Okta Admin Console-Richtlinie veröffentlicht, die diese anstößigen Regeln hervorheben.
Für Administratoren, die glaubten, dass sie keine Multi-Faktor-Authentifizierung (MFA) benötigen, da sie ihre Kennwörter regelmäßig in Tresoren verwahrten und rotierten, haben wir bekräftigt, dass der MFA-Schutz überlegen ist. Während Kunden ihre Geheimnisse weiterhin in Tresoren verwahren und rotieren sollten, sollten sie auch eine zusätzliche Faktoranforderung hinzufügen, insbesondere einen Besitz- oder biometrischen Faktor. Wenn Tresorkennwörter mit mehreren Benutzern geteilt wurden, haben wir empfohlen, dass jeder Benutzer ein eigenes Konto hat.
Was andere Kunden betrifft, so haben sich einige dafür entschieden, MFA auf einem externen IdP durchzuführen und sich in die Okta Admin Console zu integrieren. Bis vor kurzem behandelte Okta diese eingehende Föderation als einen einzigen Faktor. Wir haben jetzt jedoch eine neue Funktion namens Claims Sharing. Der IdP kann standardbasierte AMR-Claims innerhalb der SAML- oder OIDC-Antwort senden, und Okta wird die mit dem anderen IdP abgeschlossenen Faktoren als für die MFA-Zusicherung ausreichend anerkennen. Damit wurde eine weitere Hürde beseitigt.
Für Kunden mit automatisierten Testkonten, die sich bei der Konsole angemeldet haben, um Tests durchzuführen, waren die Administratoren der Ansicht, dass die Bereitstellung eines zusätzlichen Faktors für solche Konten nicht möglich wäre. Okta hat dieses Problem behoben, indem empfohlen wurde, dass sich die Testkonten für einen TOTP-Faktor registrieren und das gemeinsame Geheimnis zusammen mit dem Passwort speichern. Nachdem das Passwort ausgecheckt wurde, kann auch das Shared Secret ausgecheckt und verwendet werden, um den TOTP zum Zeitpunkt der Anmeldung programmatisch zu generieren.
Nachdem all diese Herausforderungen der Kunden gelöst waren, waren unsere Kunden bereit, Maßnahmen zu ergreifen.
Vorbereitung der Einführung von Änderungen
Angesichts der großen Anzahl von Okta-Mandanten, mit denen wir es zu tun hatten, von kostenlosen Test- und Entwickler-Mandanten bis hin zu Mandanten mit großen und komplizierten Implementierungen, war es notwendig, die Einführung zu staffeln, um eine minimale Beeinträchtigung des normalen Betriebs zu gewährleisten. Daher haben wir verschiedene Taktiken angewendet, um MFA in der Okta Admin Console sorgfältig durchzusetzen:
- Initiative ankündigen: Zusätzlich zu öffentlichen Ankündigungen und einem Blog, der auf die bevorstehende Durchsetzung MFA hinweist, haben wir integrierte Anleitungen und Banner auf dem Okta Entwickler- und Supportportal veröffentlicht und gezielte E-Mail-Adressen an Administratoren gesendet, um sie über die bevorstehenden Änderungen zu informieren.
- Verhindern Sie die Erstellung aller neuen 1FA-Zugriffsrichtlinien: Als ersten Schritt hat Okta Änderungen an allen Mandanten vorgenommen, sodass keine neuen 1FA-Zugriffsrichtlinien erstellt werden konnten. Die Idee bestand darin, die Blutung zu stoppen, bevor die vollständige Lösung eingeführt wurde.
- Unterteilen Sie Kunden in Kohorten für die MFA-Erzwingung: Um das Risiko einer Flut von Support-Tickets an Okta zu mindern und unnötige Administratoraussperrungen zu verhindern, haben wir diese Änderung nach Kundenkohorten eingeführt. Wir haben zunächst die Konfigurationen jedes Mandanten untersucht und sie basierend auf den Korrekturmaßnahmen gruppiert, die sie zur Durchsetzung von MFA benötigen würden. Dann wählten wir verschiedene Erzwingungsdaten für jede Kohorte aus und erstellten spezifische Korrekturanweisungen.
Die Administratoren wurden angewiesen, ihre Okta Admin Console-Richtlinien wie folgt zu ändern:
- Regeln mit reiner Passwortsicherheit sollten so geändert werden, dass ein Passwort und ein weiterer Faktor erforderlich sind.
- Regeln mit einer 1FA-Zusicherung oder einer Zusicherung nur des Besitzfaktors sollten so geändert werden, dass zwei Faktoren erforderlich sind.
Nach der Änderung durften Administratoren kein Downgrade auf 1FA Assurance mehr durchführen. Wenn ein Administrator keine Maßnahmen ergriff, erzwang Okta MFA für den Mandanten auf der Konsole zu einem klar kommunizierten Datum.
Okta-Kunden legen sofort mit MFA los
Innerhalb der ersten vier Monate nach der Einführung schloss Okta die Durchsetzung von MFA bei 99 % aller anwendbaren Mandanten ab. Die restlichen 1 % waren Mandanten, die zusätzliche Unterstützung von Okta benötigten, entweder in Form von Funktionserweiterungen, wie z. B. Claims Sharing, oder Zeit, um verschiedene Prozesse zu aktualisieren, um auf dieser neuen, erforderlichen Sicherheitsstufe zu arbeiten. Okta blieb mit dieser Gruppe von Kunden in Kontakt, um ihre Pain Points genau zu verstehen und mit ihnen zusammenzuarbeiten, bis sie zuversichtlich waren, diesen neuen Weg einzuschlagen.
Mit der 100-prozentigen MFA-Erzwingung für die Okta Admin Console nutzen Administratoren jetzt eine Vielzahl von Faktoren und Authentifikatoren, um sich bei der Konsole anzumelden. Die drei am häufigsten verwendeten Faktoren sind Passwort, Okta Verify Push-Benachrichtigungen und Okta FastPass. Gängige Kombinationen dieser Faktoren, die zur Erledigung einer MFA-Challenge verwendet werden, sind Passwort und Okta Verify Push sowie Passwort und Okta FastPass.
Heute ist der MFA-Zugriff auf die Okta Admin Console eine unabdingbare Voraussetzung für alle aktuellen und neu hinzugekommenen Okta-Administratoren. Indem Kunden diese sichere Haltung standardmäßig übernehmen, profitieren sie von einer reduzierten Angriffsfläche und einem besseren Schutz der kritischen Identitätsinfrastruktur.
Erfahren Sie mehr über das Okta MFA-Produkt auf der Adaptive MFA webpage. Behalten Sie im Auge, was Okta unternimmt, um identitätsbasierte Angriffe zu bekämpfen, indem Sie sich über das Okta Secure Identity Commitment informieren.
