Suchen Sie nach mehr Granularität bei der Verwaltung der Konfiguration des Identitätsbedrohungsschutzes mit Okta AI? Wir verstehen, dass Sicherheit eine Teamleistung ist und verschiedene Administratoren unterschiedliche Verantwortlichkeiten haben. Um den Zugriff besser an diese Verantwortlichkeiten anzupassen und das Prinzip der minimalen Rechte zu wahren, hat Okta eine neue Funktion veröffentlicht, um benutzerdefinierte Administratorrollen auf neue Berechtigungen und Ressourcentypen für den Identitätsbedrohungsschutz mit Okta AI zu erweitern.
Was ist Identity Threat Protection mit Okta AI?
Identity Threat Protection mit Okta AI ist ein Produkt, das innerhalb von Okta Workforce Identity ausgeführt wird. Es unterliegt dem administrativen Modell, bei dem Benutzer/Gruppen Admin Roles zugewiesen sind.
Zuvor haben wir die Funktion "Administratorrollen" erweitert, um die Erstellung von Benutzerdefinierte Administratorrollen zu ermöglichen. Dies umfasste zwei Teile:
- Die Freigabe von Rollenzuweisungen, die in die Standard-Admin-Rollen integriert waren, sodass benutzerdefinierte Rollen definiert werden konnten. Diese Berechtigungen beschreiben Vorgänge, die an Objekten durchgeführt werden können, wie z. B. „Benutzer verwalten“, „Benutzer erstellen“ und „Lifecycle-Status von Benutzern bearbeiten“.
- Das Hinzufügen von Ressourcensets mit Ressourcen ermöglicht es, Administratorrollen auf bestimmte Datensätze zu beschränken. Sie könnten beispielsweise ein Ressourcenset für alle Benutzer, ihre Gruppen und Apps in einer bestimmten Abteilung haben, um Administratorrollen nur auf diese Objekte zu beschränken.
Wir haben diese Funktionalität nun erweitert, um neue Berechtigungen für Operationen im Zusammenhang mit Identity Threat Protection und neuen Ressourcen einzubeziehen. Dies ist keine neue Funktion, sondern eine Erweiterung des bestehenden Funktionsumfangs mit mehr Berechtigungen und Ressourcentypen.
Rollen und Berechtigungen
Wir haben keine neuen Rollen hinzugefügt, aber es sind neue Berechtigungen verfügbar, darunter die Möglichkeit:
- Benutzerrisiko anzeigen und verwalten
- Anzeigen und Verwalten von Shared Signals Framework (SSF) Empfänger-Streams
- Richtlinien anzeigen und verwalten
- Berichte anzeigen
- Logout konfigurieren
- Workflow erstellen
Bei der Definition von Rollen sollten Sie erwägen, Berechtigungen einzubeziehen für:
- Benutzer anzeigen oder ändern: Beinhaltet den Zugriff zum Anzeigen oder Ändern von Benutzern
- Benutzersitzungen löschen: Bietet Administratorzugriff zum Löschen von Benutzersitzungen
- Gruppen anzeigen: Erforderlich für Administratoren, um Gruppenzuweisungen in der Entitätsrisikorichtlinie und der Post-Auth-Sitzungsrichtlinie anzuzeigen
- Anwendungen verwalten: Gibt Administratoren die Möglichkeit, Universal Logout für eine App zu konfigurieren
- Delegierten Flow ausführen: Ermöglicht die Ausführung eines delegierten Flows zur Verwendung in der Entitätsrisikorichtlinie oder der Sitzungsrichtlinie nach der Authentifizierung.
- Delegierten Fluss anzeigen: Ermöglicht die Anzeige eines delegierten Flusses
- Anpassungen verwalten: Erforderlich für Administratoren, um die Post-Auth-Sitzungsrichtlinie zu verwalten
Sie können diese neuen Berechtigungen verwenden, um benutzerdefinierte Administratorrollen für Identity Threat Protection zu erstellen. Sie können beispielsweise die Möglichkeit, Risiken anzuzeigen und zu eskalieren, auf Ihre Benutzeradministratoren ausweiten, aber separate Rollen für die Verwaltung von Richtlinien und SSF-Integrationen haben.
Für einen Vergleich der Rollenberechtigungen für verschiedene Administratorrollen sehen Sie sich die Produktdokumentation an.
Ressourcensätze
Ressourcensätze sind Sammlungen von Ressourcen, die Administratorrollen zugeordnet sind, um administrativen Zugriff zu gewähren. Eine Rolle definiert, was ein Benutzer tun kann (Operationen), und ein Ressourcensatz definiert, auf welchen Daten diese Rolle operieren kann.
Für diese Funktion wurden zwei neue Ressourcentypen hinzugefügt:
- Shared Signals Framework (SSF) Receiver
- Richtlinien (z. B. Entity Risk Policy, Session Protection Policy)
Diese können mit anderen Ressourcentypen (wie Benutzern, Anwendungen, Gruppen und Workflows) kombiniert werden, um ein delegiertes administratives Modell zu unterstützen.
Beispiel für eine benutzerdefinierte Administratorrolle
Sehen wir uns ein Beispiel für eine benutzerdefinierte Administratorrolle für einen Identity Threat Protection-Administrator an, die alle Aspekte von Identity Threat Protection abdeckt, jedoch nicht auf der Ebene einer Okta Super Admin-Rolle.
Die Rolle hat die folgenden Berechtigungen:
- Benutzer
- Benutzer deaktivieren
- Benutzer sperren
- Sitzungen der Benutzer löschen
- Risiko der Benutzer verwalten
- Gruppe
- Eine Gruppe und ihre Details anzeigen
- Anwendung
- Eine Anwendung und ihre Details anzeigen
- Workflow
- Einen delegierten Fluss anzeigen
- Führen Sie einen delegierten Ablauf aus
- Shared Signals Framework Receiver
- Shared Signals Framework (SSF)-Empfängerströme verwalten
- Richtlinien
- Richtlinien verwalten
In diesem Szenario bietet die Rolle dem Benutzer eingeschr änkten Zugriff – die M öglichkeit, die Apps und Gruppen des Benutzers anzuzeigen (aber nicht zu ändern) und das Benutzerrisiko anzuzeigen (aber nicht auf das Benutzerprofil oder die Ger äte zuzugreifen).
Die Erweiterung von benutzerdefinierten Administratorrollen innerhalb von Identity Threat Protection ermöglicht eine detailliertere Kontrolle über Administratorberechtigungen. Durch das Hinzufügen neuer Berechtigungen und Ressourcentypen können Unternehmen spezifische Rollen erstellen, die auf die Verwaltung von Identity Threat Protection zugeschnitten sind, ohne sich ausschließlich auf Super Admin-Rechte verlassen zu müssen. Diese Verbesserung erhöht die Sicherheit und reduziert Risiken, indem sie die präzise Zuweisung administrativer Verantwortlichkeiten ermöglicht, was letztendlich zu einer sichereren Okta-Bereitstellung führt.
Erweiterte Funktionen ermöglichen das Löschen der Benutzersitzungen, das Erhöhen des Risikos und das Sperren/Deaktivieren des Benutzers.
Dieses Update ermöglicht auch den Zugriff auf Gruppen, Apps, Sicherheitsrichtlinien und einige andere gängige Admin-Funktionen sowie die Möglichkeit, SSF-Empfänger zu verwalten. Es erlaubt jedoch nicht die Konfiguration von Universal Logout für eine App.
Die Admin-Rolle kann dann nach Ressourcen in einem Ressourcensatz begrenzt werden: Bestimmte Anwendungen, Benutzer (nach Gruppe), Workflows, Richtlinien und Gruppen. In Kombination mit den neuen (und bestehenden) Berechtigungen können Sie entsprechend berechtigte Administratoren definieren und die Notwendigkeit der Super Admin-Rolle eliminieren, wodurch die Risiken dieser Rolle für Ihre Okta-Bereitstellung verringert werden.
Möchten Sie mehr erfahren? Sehen Sie sich die Dokumentation in unserer Knowledge Base an oder entdecken Sie weitere neue Identity Threat Protection mit Okta AI Funktionen in unserem neuesten Blog-Post.
