Da Cyberbedrohungen an Komplexität und Häufigkeit zunehmen, war die Notwendigkeit einer robusten Identity Security noch nie so wichtig wie heute. Identitätsbasierte Angriffe, wie z. B. kompromittierte Anmeldedaten und unbefugter Zugriff, stellen ein erhebliches Risiko für Unternehmen dar. Der Schutz vor diesen Bedrohungen erfordert einen proaktiven und intelligenten Ansatz, der verdächtige Aktivitäten erkennt und darauf reagiert und sich nahtlos in bestehende Sicherheitsmaßnahmen integriert.
Entdecken Sie Okta Identity Threat Protection mit Okta AI, eine hochmoderne Lösung, die entwickelt wurde, um die Identity Security Ihres Unternehmens zu stärken. Okta Identity Threat Protection kombiniert die Leistungsfähigkeit künstlicher Intelligenz (KI) mit umfassendem Identitätsschutz und bietet Echtzeit-, kontinuierliche Bedrohungserkennung und Reaktionsfähigkeiten, die auf die besonderen Herausforderungen der modernen Cybersicherheit zugeschnitten sind.
Eine der leistungsstärksten Funktionen von Okta Identity Threat Protection mit Okta AI ist die Integration mit Okta Workflows. Diese Workflows dienen dazu, Automatisierung zu schaffen und Ihre Sicherheitsinfrastruktur in die Lage zu versetzen, dynamisch und effektiv auf Bedrohungen zu reagieren. Mit anpassbaren, richtlinienbasierten Aktionen können Okta Workflows verwendet werden, um kompromittierte Konten zu deaktivieren oder unter Quarantäne zu stellen, die Multi-Faktor-Authentifizierung (MFA) für risikoreiche Aktivitäten zu erzwingen und Sicherheitsteams auf potenzielle Verstöße aufmerksam zu machen – und so Ihre Abwehrmaßnahmen aktiv und reaktionsfähig zu gestalten.
Lassen Sie uns untersuchen, wie Okta Identity Threat Protection mit Okta AI und Okta Workflows, unserer Low-Code-Automatisierungsplattform, Ihnen helfen kann, Ihre Sicherheits- und Geschäftsziele besser zu erreichen.
Maßgeschneiderte Automatisierung für Okta Identity Threat Protection
Nachfolgend finden Sie eine vereinfachte Ansicht von Okta Identity Threat Protection mit Okta AI. Signale und Ereignisse von Okta und Partnern werden ständig in Okta eingespeist, und die Identity Threat Protection Risk Engine ermittelt Risiken und führt die entsprechenden Richtlinien aus.
Diese Richtlinien können Korrekturmaßnahmen auslösen, wie z. B. die Durchführung eines Universal Logout oder das Aufrufen eines delegierten Flows in Okta Workflows. In diesem Artikel werden wir diese als richtlinieninitiierte Workflows bezeichnen.
Die Risikobewertung kann auch Aktionen innerhalb von Okta auslösen, z. B. die Erhöhung des Benutzerrisikolevels (als Entity Risk Level bezeichnet). Eine Änderung des Benutzerrisikolevels ist nur eines von vielen Ereignissen im Zusammenhang mit Identity Threat Protection, die in die Okta-Systemprotokolle geschrieben werden, zusammen mit Dingen wie der Neubewertung von Richtlinien, Änderungen des Sitzungskontexts, dem Empfang eines Risikosignals von einem Drittanbieter und vielem mehr. Fast jede Aktivität innerhalb von Okta wird im Systemprotokoll protokolliert. Es ist üblich, Workflows von berechtigten Ereignissen mithilfe von Ereignis-Hooks oder dem integrierten Okta Connector innerhalb von Workflows auszulösen. In diesem Artikel werden wir diese ereignisinitiierten Workflows nennen.
Richtlinieninitiierte Workflows
Aus der Produktdokumentation: Wenn Identity Threat Protection mit Okta AI ein Risiko aufdeckt und das Behebungsereignis über das universelle Abmelden hinaus zusätzliche Maßnahmen erfordert, können Sie automatisch einen delegierten Workflow ausführen.
Die über Okta Workflows Connectors bereitgestellten Drittanbieter-Apps und -Dienste bieten zahlreiche mögliche Abhilfemaßnahmen.
- Benachrichtigen Sie Benutzer oder Administratoren über Slack oder E-Mail
- Benutzer deaktivieren
- Einen Benutzer aus einer privilegierten Gruppe entfernen
- Einen Benutzer in eine neue eingeschränkte Gruppe verschieben
- Gerät unter Quarantäne stellen
- Senden Sie ein Incident-Ticket an eine Warteschlange
- Konfigurieren Sie verschiedene Flows für verschiedene Risikoszenarien basierend auf Ihren Anforderungen.
Zusätzlich können Sie die in fast allen Konnektoren enthaltenen Custom API Action -Karten verwenden, um benutzerdefinierte Aktionen zu erstellen, die mit beliebigen API-Endpunkten von Drittanbietern interagieren können.
Die Okta Identity Threat Protection-Dokumentation veranschaulicht mehrere Workflow-Beispiele, die von bestimmten Richtlinien initiiert werden könnten, wie z. B.:
- Senden Sie eine Slack-Nachricht, um eine Richtlinienverletzung anzuzeigen
- Benutzersitzungen löschen und eine E-Mail-Benachrichtigung senden, um das Risiko zu reduzieren
- Entfernen Sie den Benutzer aus allen Mitgliedschaften und deaktivieren Sie sein Konto
Daher sind richtlinieninitiierte Workflows nützlich für die Automatisierung in Verbindung mit bestimmten Risiken, die von Identity Threat Protection generiert werden, da Workflows an bestimmte Richtlinien gebunden sind. Wenn Sie die Automatisierung auf der Grundlage allgemeinerer Situationen vorantreiben möchten, z. B. einer Änderung des Benutzerrisikoniveaus, sind ereignisinitiierte Workflows besser geeignet.
Beispiele für ereignisgesteuerte Workflows
Nachfolgend finden Sie drei Beispiele für das Auslösen von Workflows aus Ereignissen im Okta-Systemprotokoll, die verschiedene Anwendungsfälle abdecken.
- Eine Änderung des Benutzerrisikolevels löst ein Ticket in ServiceNow und die Zuweisung zu einer Hochrisikogruppe in Okta aus.
- Wenn ein Benutzer einer risikoreichen Anwendung zugewiesen wird, überprüft ein Workflow das Risiko des Benutzers und erlaubt oder widerruft den neuen Zugriff.
- Wenn ein Benutzer einer risikoreichen Anwendung zugewiesen wird, überprüft ein Workflow das Risiko des Benutzers und ermöglicht oder löst eine User Access Review in Okta Identity Governance aus.
1. Erfassung eines ServiceNow-Tickets und Zuweisung eines Benutzers zu einer Hochrisikogruppe
In diesem Beispiel verwenden wir einen Event-Hook, der bei user.risk.detect abonniert ist Ereignisse, um einen Workflow auszulösen. In diesem Szenario benachrichtigen wir unser Sicherheitsteam über das Ereignis in Slack mit nützlichen Details und senden eine E-Mail an den Manager des Benutzers, dessen Risikostufe sich geändert hat.
In Fällen, in denen das Risikoniveau eines Benutzers HOCH ist, erstellen wir auch einen ServiceNow-Vorfall, fügen den Benutzer einer Hochrisikogruppe in Okta hinzu, reichern unsere Benachrichtigung mit einem Link zum ServiceNow-Vorfall an und geben an, dass der Benutzer der Gruppe hinzugefügt wurde. Wenn das Risikoniveau des Benutzers sinkt, wird er aus der Hochrisikogruppe entfernt.
Der Workflow wird:
- Durch das user.risk.detect Ereignis im Okta-Systemprotokoll ausgelöst werden. Wir verwenden einen Event-Hook, der auf einen API Endpoint-Flow verweist. (Weitere Informationen finden Sie unter Verarbeiten von Okta-Ereignis-Hooks mit Workflows.)
- Parse the event details
- Liest den Benutzer anhand der ID, um Informationen aus seinem Profil zurückzugeben und einen Link zu einer Systemprotokollabfrage zu erstellen, die sich auf das Ereignis bezieht.
- Bestimmen Sie das Risikoniveau des Benutzers:
- Wenn es jetzt „HIGH“ ist
- Erstellen Sie einen ServiceNow-Vorfall
- Fügen Sie den Benutzer einer risikoreichen Okta-Gruppe hinzu
- Senden Sie eine E-Mail an den Vorgesetzten des Benutzers
- Chat-Benachrichtigungen mit Kontext zu den oben genannten Aktionen anreichern
- Wenn es von „HIGH“ gesunken ist:
- Entfernen Sie den Benutzer aus der Okta-Hochrisikogruppe
- Chat-Benachrichtigungen mit Kontext zu den oben genannten Aktionen anreichern
- Wenn es jetzt „HIGH“ ist
- Benachrichtigungen zu allen user.risk.detect Ereignissen senden:
- Slack- (oder Teams-)Nachricht an einen Sicherheitskanal für alle user.risk.detect-Ereignisse Ereignisse
- Fügen Sie Informationen zum Hinzufügen/Entfernen von Gruppen hinzu und verlinken Sie gegebenenfalls mit dem ServiceNow-Vorfall.
Lassen Sie uns den Ablauf durchgehen. Zuerst analysieren wir die Payload von user.risk.detect. Ereignis und weisen einige Werte zu, die wir später in unserem Flow verwenden werden. Anschließend schließen wir die Verbindung zum Event-Hook mit dem Statuscode 200.
Als Nächstes rufen wir einige Helper-Flows auf. Einer wird uns helfen, das DebugData.risk-Ereignis weiter zu analysieren, um die aktuellen und vorherigen Risikostufen zu erhalten. Der andere ruft einige Profilinformationen über den Benutzer ab, dessen Risikostufe erhöht wurde, und erstellt einen Link zu einer Systemprotokollabfrage zu dem Ereignis.
Wenn das Risiko des Benutzers jetzt „HOCH“ ist, werden wir
- Fügen Sie sie der Okta-Hochrisikogruppe hinzu
- Senden Sie eine E-Mail an den Vorgesetzten des Benutzers
- Erstellen Sie einen Vorfall in ServiceNow
- Passen Sie unsere Slack-Benachrichtigung an, die bei jeder Änderung des Risikolevels gesendet wird, um unser Team darüber zu informieren, dass der Benutzer der Gruppe hinzugefügt wurde, und fügen Sie einen Link zum ServiceNow-Vorfall hinzu. Die Nachricht zeigt auch an, wenn die ServiceNow-Aktion „Vorfall erstellen“ fehlschlägt.
Schließlich werden wir die dynamisch aufgebauten Nachrichten aufnehmen, die Folgendes anzeigen
- Der Benutzer wurde zur Okta-Hochrisikogruppe hinzugefügt oder daraus entfernt
- ServiceNow-Vorfall und -Link (oder Link zur Untersuchung, wenn die Vorfallerstellung fehlgeschlagen ist)
Wir werden diese mit den übrigen Risikoveranstaltungsdetails kombinieren, die wir standardmäßig mit jedem user.risk.detect senden. Ereignis und senden unsere Benachrichtigung.
Die Implementierung eines solchen Ablaufs nutzt die Leistungsfähigkeit von Workflows und Okta Identity Threat Protection, um Ihrem Team kontinuierlich in Echtzeit Einblick in die in Ihrem Okta Tenant erkannten Risikosignale zu geben. Es ermöglicht Ihnen, verschiedene Plattformen zu integrieren, die Sie zum Senden von Benachrichtigungen, Erstellen von Tickets und Automatisieren von Antworten verwenden, z. B. das Quarantänisieren des Benutzers in einer Hochrisikogruppe oder das Auslösen eines Vorfalls mit einer SLA zur Reaktion in einer anderen Plattform. Die Okta-Gruppe „Hohes Risiko“ kann strengen Richtlinien unterliegen, die den Zugriff eines Benutzers einschränken, bis Ihr Team die Möglichkeit hatte, Nachforschungen anzustellen. Das Hinzufügen von Benutzern zu der Gruppe könnte andere Flows auslösen, oder Sie könnten sogar strengere Richtlinien innerhalb von Identity Threat Protection haben, die für die Gruppe gelten.
2. Überprüfung des Benutzerrisikos bei der Zuweisung von Anwendungen mit hohem Risiko
In diesem Beispiel haben wir eine risikoreiche Anwendung in Okta (wie das PAM -Produkt, Okta Advanced Server Access), und wenn ein Benutzer dieser Anwendung zugewiesen wird, möchten wir die Risikostufe des Benutzers überprüfen. Wenn der Benutzer eine niedrige Risikostufe hat, ist der App-Zugriff erlaubt. Der Zugriff ist erlaubt, wenn das Risiko mittel ist, aber eine Slack-Nachricht wird geschrieben, um dies hervorzuheben. Wenn das Risiko hoch ist, wird der Anwendungszugriff zurückgesetzt.
Der Workflow wird:
- Wird durch das application.user_membership.add-Ereignis im Okta-Systemprotokoll ausgelöst. Dies ist ein Standardereignis, das in den Okta Workflows Connector integriert ist.
- Den Benutzer anhand der ID suchen, um Details zu erhalten, falls eine Slack-Nachricht erforderlich ist
- Benutzerrisiko bestimmen. In diesem Fall wird eine Abfrage der Gruppen des Benutzers durchgeführt, um festzustellen, ob er sich in einer Hoch- oder Mittelrisikogruppe befindet, dann
- Wenn das Benutzerrisiko niedrig ist, ermöglicht es den App-Zugriff (d. h. es tut nichts)
- Wenn das Benutzerrisiko mittel ist, erlaubt dies den App-Zugriff, formatiert aber eine Slack-Nachricht und sendet sie an das Admin-Team
- Wenn das Benutzerrisiko hoch ist, wird die Benutzerzuweisung zur Anwendung entfernt.
Lassen Sie uns den Ablauf durchgehen. Zuerst haben wir ein Ereignis, das anzeigt, dass ein Benutzer, John Smith, zur Okta Advanced Server Access-App hinzugefügt wurde.
Es werden Johns Details und die Gruppen, denen er angehört, nachgeschlagen, um sein Risiko zu bestimmen.
Wenn John ein mittleres Risiko aufweist und sich somit in der entsprechenden Gruppe für mittleres Risiko befindet (die von Workflows zugewiesen wird, wenn sich sein Risiko durch ein Identity Threat Protection-Ereignis von niedrig auf mittel geändert hat), wird eine Nachricht an Slack geschrieben.
Wenn John ein hohes Risiko aufweist und sich in der entsprechenden Hochrisikogruppe befindet, wird seine Zuweisung durch eine andere Okta-Aktion rückgängig gemacht.
Dies kann in den Okta-Systemprotokollereignissen für die Anwendung (oder den Benutzer) eingesehen werden.
Dies ist ein ziemlich einfaches – und sehr leistungsfähiges – Beispiel für die Verwendung des Benutzerrisikos zur Steuerung des Anwendungsrisikos.
3. Überprüfung des Benutzerrisikos bei der Zuweisung von Hochrisikoanwendungen mit Benutzerzugriffsüberprüfung
Als Nächstes werden wir das vorherige Szenario erweitern. Anstatt den Zugriff automatisch zu widerrufen, wenn einem Hochrisikobenutzer Zugriff auf eine Hochrisikoanwendung gewährt wird, werden wir nun eine User Access Review in Okta Identity Governance auslösen.
Der Ablauf ist im Grunde derselbe wie zuvor, aber anstatt im letzten Schritt den App-Zugriff zu entfernen, erstellt und startet der Workflow eine Benutzerzugriffsüberprüfung (Zugriffszertifizierung) mithilfe der Campaigns API in Okta Identity Governance und der benutzerdefinierten API-Aktionskarte im Okta Connector (die Details sind in einem Helper-Flow verborgen).
Wie zuvor leitet das Benutzerrisikolevel (Hoch) den Workflow zu einem Helper-Flow weiter, der die relative URL und den RequestBody erstellt, die zum Erstellen und Starten der Access Certification-Kampagne benötigt werden, wenn der Benutzer der App zugewiesen wird.
Dies wird dem Manager des Benutzers zur Überprüfung zugewiesen, und wenn sich der Manager bei Okta anmeldet, sieht er, dass es eine Kampagne zur Überprüfung gibt
Beim Überprüfen der Details sehen sie alle John Smith zugewiesenen Anwendungen.
Sie überprüfen den Zugriff, entscheiden, dass John die Okta Advanced Server Access-App nicht benötigt, und klicken auf die Schaltfläche „Revoke“.
Dies führt zur Entfernung der Anwendung, wie in den Systemprotokollereignissen dargestellt.
Dieser Ansatz bietet mehr Flexibilität. Benutzer haben möglicherweise einen legitimen Grund, auf eine risikoreiche Anwendung zuzugreifen. Eine Benutzerzugriffsüberprüfung durch den Vorgesetzten ist daher eine revisionssichere Möglichkeit, diese zu verwalten (natürlich könnten Sie auch Access Request-Flows anwenden, aber das ist ein Thema für einen anderen Artikel).
Der Bedrohungslandschaft immer einen Schritt voraus sein
Durch die Nutzung dieser Okta-Funktionen können Sie eine höhere Sicherheit und betriebliche Effizienz erzielen und Ihre Sicherheitsprotokolle an Ihren Geschäftszielen ausrichten. Ob die Durchsetzung von MFA für verdächtige Aktivitäten, die Deaktivierung oder Quarantäne kompromittierter Konten oder die Benachrichtigung von Sicherheitsteams über potenzielle Verstöße – Okta Identity Threat Protection und Workflows ermöglichen es Ihrem Unternehmen, widerstandsfähig gegen identitätsbasierte Angriffe zu bleiben.
Während wir uns in den Komplexitäten der modernen Cybersicherheit bewegen, erweist sich Okta Identity Threat Protection mit Okta AI als ein wichtiges Werkzeug in Ihrem Sicherheitsarsenal. Es schützt Ihr Unternehmen besser und verbessert Ihre Fähigkeit, schnell und effektiv auf Bedrohungen zu reagieren. Durch die Integration dieser Dienste halten Sie nicht nur mit der sich entwickelnden Bedrohungslandschaft Schritt, sondern bleiben ihr einen Schritt voraus.
Nutzen Sie die Zukunft der Identity-Sicherheit mit Okta und ermöglichen Sie Ihrem Unternehmen, die Herausforderungen von heute und morgen zu bewältigen. Mit Okta Identity Threat Protection und Okta Workflows können Sie Ihre digitale Landschaft besser schützen, Ihre wertvollen Vermögenswerte schützen und Ihre Geschäftsziele sicher verfolgen.
Erfahren Sie mehr über Okta Identity Threat Protection with Okta AI und Okta Workflows.
Diese Materialien dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Unternehmensberatung dar.
