Schließen der Governance-Lücke

Im modernen Tech-Stack ist Snowflake das Kronjuwel. Wenn Unternehmen wachsen, wird die Verwaltung dessen, wer worauf Zugriff hat – und vor allem die Sicherstellung, dass dieser Zugriff wieder entzogen wird – jedoch zu einer hochriskanten Compliance-Herausforderung. Wenn Sie ausschließlich die nativ von Okta bereitgestellten SCIM-Konnektoren nutzen, wissen Sie wahrscheinlich, dass diese nur die halbe Miete sind. Die Konnektoren können Benutzer:innen erstellen, haben jedoch Schwierigkeiten, den komplexen Lebenszyklus von Snowflake-Rollen und die Lizenzrückforderung zu verwalten.

Dieser Leitfaden stellt eine anspruchsvolle Architektur mit drei Workflows unter Verwendung von Okta Identity Governance (OIG) und Okta Workflows (Stand: April 2026) vor, um die „letzte Meile“ der Snowflake-Administration zu automatisieren.

Das Problem: Warum Okta-Integrationskonnektoren nicht ausreichen

Die Standardintegration zwischen Okta und Snowflake konzentriert sich in der Regel auf die Benutzerprovisionierung. Das klärt zwar die Frage, ob Personen tatsächlich Benutzer:innen sind, scheitert jedoch an zwei entscheidenden Punkten:

1. Granulare Rollenverwaltung: Der Zugriff auf Snowflake wird durch Rollen definiert (z. B. SYSADMIN, DATA_ENGINEER). Standardkonnektoren lösen als Reaktion auf OIG-Zugriffsanfragen nicht nativ rollenspezifische SQL-Befehle aus.
2. Bereinigung von Berechtigungen: Wenn eine OIG-Anfrage abläuft oder die Zuweisung einer App für Benutzer:innen aufgehoben wird, bleibt der Benutzerdatensatz in Snowflake oft bestehen. Dies führt zu „Zombie“-Accounts, die Lizenzen verbrauchen und Ihre Sicherheitsangriffsfläche vergrößern.

Die Lösung besteht darin, Okta Workflows als Orchestrierungs-Engine einzusetzen, die nach OIG-Ereignissen sucht und mit Snowflake kommunizieren kann.

Einrichtungsleitfaden für Konfigurationsanforderungen

Bevor wir zur vorgeschlagenen Lösung für Okta OIG und Workflows kommen, müssen wir einige Konfigurationsänderungen in Snowflake, OIG und Slack vornehmen, um das Workflows-Paket (Snowflake Delegated Flow, Unassigned Entitlements und User Unassigned Cleanup) nutzen zu können. Sie müssen diese spezifischen Konfigurationsschritte auf allen vier Plattformen abschließen. Im Folgenden finden Sie den umfassenden Leitfaden zur Einrichtung der Kernanforderungen:

Snowflake-Anforderungen

Snowflake dient als Zielsystem für die Verwaltung von Rollen und Benutzer:innen.

1. Provisioner-Rolle erstellen: Erstellen Sie eine dedizierte Rolle (z. B. OKTA_PROVISIONER), die Okta übernimmt, um Aktionen auszuführen.

2. SCIM-Integration konfigurieren: Erstellen Sie eine SCIM-Sicherheitsintegration, um Okta die Kommunikation mit Snowflake zu ermöglichen.

3. SCIM-Token generieren: Generieren Sie das Autorisierungstoken, um es in Okta einzufügen.

4. Netzwerkrichtlinie: Stellen Sie sicher, dass die Netzwerkrichtlinie von Snowflake eingehenden Datenverkehr von Okta-IP-Adressen zulässt.

Okta-Anforderungen (Core und Workflows)

Okta ist der zentrale Identity-Anbieter und der Motor, der die Automatisierung antreibt.

SCIM-Integration der Snowflake-App

1. Fügen Sie die Snowflake-App aus dem Okta Integration Network hinzu.
2. Aktivieren Sie auf der Registerkarte „Provisioning“ (Provisionierung) die API-Integration und fügen Sie das Snowflake-SCIM-Token ein.
3. Aktivieren Sie „Create Users“ (Benutzer:innen erstellen), „Update User Attributes“ (Benutzerattribute aktualisieren) und „Deactivate Users“ (Benutzer:innen deaktivieren).

Autorisierung und Import des Workflows-Konnektors

Der Kern des Systems basiert auf zwei Hauptkomponenten: Okta Access Requests und Okta Workflows. Okta Workflows werden verwendet, um spezifische Geschäftsfunktionen zu erstellen, wie beispielsweise die manuelle Provisionierung, den Versand von Benachrichtigungen oder die Erstellung von Support-Tickets. Diese Workflows sind als Delegated Flows konfiguriert, die von Okta Access Requests genutzt werden können. Führen Sie die folgenden Schritte aus, um diese Workflows zu aktivieren:

1. Zugriff autorisieren

• Autorisieren Sie den Snowflake-Konnektor in der Workflows-Konsole mit dem Access-Token in der Snowflake-Anwendung. Dadurch wird es möglich, API-Aufrufe an die Snowflake-Anwendung durchführen.
• Okta-Konnektor: Stellen Sie sicher, dass die Verbindung autorisiert ist.

• Gewähren Sie der Okta Workflows OAuth-App in der Okta Admin-Konsole (unter „Applications“ (Anwendungen) -> Okta Workflows OAuth-App) den Berechtigungsbereich okta.governance.entitlements.manage.

2. Workflows-Paket importieren

Hinweis: Um diesen Schritt abzuschließen, müssen Sie diese Workflow-Paketdatei herunterladen.

Importieren Sie das angehängte Workflows-Paket in der Admin-Konsole unter „Workflows“ -> „Flows: Snowflake Entitlement Management“ -> „Okta Workflows“:

• Erstellen Sie einen neuen Ordner und benennen Sie ihn „Snowflake Entitlement Management“ (Snowflake-Berechtigungsmanagement). Wählen Sie dann im Dropdown-Menü die Option „Import“ (Importieren) aus.

• Es gibt drei Haupt-Workflows: Snowflake Delegated Flow (Assignment), Unassign Entitlements und User Unassigned from Snowflake. Wir erläutern die Funktion jedes Workflows im nächsten Abschnitt. 
  

  Aktivieren Sie diese Anwendungsverbindungen in jedem der drei Flows (z. B. die Snowflake-Karte im Flow „Unassign Entitlements“ (Berechtigungen entziehen)).

3. Delegated Flow einrichten

Um den delegierten Snowflake-Flow zu nutzen, müssen Sie zunächst Okta Workflows in Access Requests aktivieren. Dies stellt sicher, dass nach der Genehmigung einer Zugriffsanfrage für die Snowflake-Anwendung der delegierte Snowflake-Flow eine API-Anfrage auslöst, um Berechtigungen zuzuweisen.

• Aktivieren Sie dies in Access Requests unter „Settings“ (Einstellungen) -> „Feature“ (Funktion) -> „Okta Workflows actions“ (Okta Workflows-Aktionen).

• Erstellen Sie eine benutzerdefinierte Rolle und Ressource, damit Access Requests die verfügbaren Workflows anzeigen und ausführen können.

• Erstellen Sie ein Ressourcenset und weisen Sie ihm Workflows zu.

• Gehen Sie zurück zum delegierten Ressourcensatz, um die Administrator-Berechtigungen zuzuweisen.

• Navigieren Sie unter Identity Governance zu „Access Requests“ -> „Settings“ (Einstellungen) -> „Resources“ (Ressourcen) -> „Workflows“ (Workflows), um zu bestätigen, dass die delegierten Workflows für die Ausführung über die Access Requests aktiviert sind.Wenn alles erfolgreich ausgeführt wurde, werden „delegierte Workflows“ angezeigt.

4. Event-Hook erstellen

Richten Sie einen Event-Hook ein, um Event-Daten von Okta an den API-Endpoint im delegierten Flow zu senden, wenn ein OIG-Ereignis auftritt:

• Wechseln Sie unter „Workflows“ zur Registerkarte „Event Hooks“ (Event-Hooks), um einen neuen Event-Hook zu erstellen.

Stellen Sie nun sicher, dass die Systemprotokolle ein OIG-Ereignis für „Updated user's entitlements in a resource“ (Aktualisierte Benutzerberechtigungen in einer Ressource) erkennen und an die API-Endpoint-Karte senden, indem Sie die Aufruf-URL aus dem Workflow „Unassign Entitlements“ (Berechtigungen entziehen) im Feld „Endpoint URL“ (Endpoint-URL) zuweisen und anschließend dieses Ereignis im Event-Hook auswählen:

• Gehen Sie zum Workflow „Unassign Entitlements“ (Berechtigungen entziehen) und rufen Sie die Endpoint-Einstellungen auf.

• Kopieren Sie die Endpoint-URL und fügen Sie sie in das Feld „Endpoint URL“ (Endpoint-URL) des neuen Event-Hooks ein.

• Wählen Sie im Event-Hook „Updated user's entitlements in a resource“ (Aktualisierte Benutzerberechtigungen in einer Ressource) aus.

• Sobald der Event-Hook konfiguriert ist, können wir ihn auf der Registerkarte „Preview“ (Vorschau) testen.

Anforderungen an Okta Identity Governance (OIG)

OIG stellt die granulare Berechtigungsebene bereit, die im Synchronisierungsablauf verwendet wird.

1. Governance-Engine aktivieren: Stellen Sie sicher, dass die Okta Identity Governance-Engine für Ihr Unternehmen aktiviert ist.
2. Berechtigungsmanagement aktivieren: Gehen Sie zur Snowflake-App in Okta, rufen Sie die Registerkarte „Governance“ auf und klicken Sie auf „Enable entitlement management“ (Berechtigungsmanagement aktivieren). Bevor Sie das Berechtigungsmanagement aktivieren oder deaktivieren, müssen Sie zunächst die Provisionierung deaktivieren.

3. Richten Sie benutzerdefinierte Berechtigungen in der Snowflake-App auf der Registerkarte „Governance“ ein. Wie bereits erwähnt, werden die Berechtigungen von Snowflake nicht automatisch über den Konnektor von Okta übernommen. Daher müssen wir benutzerdefinierte Rollen und Berechtigungen einrichten.
   
   Dies sind die Rollen, die in der Snowflake-Anwendung existieren:

Wir müssen diese Rollen in der Okta Platform abgleichen: Sobald sie abgeglichen sind, werden diese Rollen (wie ORGADMIN oder SYSADMIN) in „anforderbare“ Objekte umgewandelt, wodurch sie für Benutzer:innen im Access Requests-Katalog sichtbar werden.

• Gehen Sie zur Registerkarte „Governance“.

• Fügen Sie eine Berechtigung hinzu.

• Fügen Sie eine Berechtigung namens „ROLES“ (Rollen) hinzu.

• Fügen Sie Benutzerrollen hinzu, die wir in Zugriffsanfragen verwenden werden.

Nach der Erstellung sehen sie so aus:

• Erstellen Sie für jede Rolle ein Paket.

Wenn Sie die Erstellung der Pakete abgeschlossen haben, sieht dies wie folgt aus:

• Verwenden Sie diese Pakete, um für jede Rolle in der Snowflake-App auf der Registerkarte „Access Requests“ eine Zugriffsanfrage zu erstellen.

• Scrollen Sie ganz nach unten und wählen Sie „Approval Sequence“ (Genehmigungssequenz) -> „Select Sequence“ (Sequenz auswählen).

• Bearbeiten Sie die Sequenz „Business Justification“ (Geschäftliche Begründung).

• Klicken Sie unmittelbar unter dem Schritt „Approval for Requester’s manage“ (Genehmigung für Manager:in von Anforderer:in) auf „+“, um einen neuen Workflow-Schritt in der Sequenz hinzuzufügen.

• Fügen Sie einen Workflow-Schritt hinzu und wählen Sie den delegierten Workflow aus, den wir aus dem Workflows-Paket importiert haben.

• Benennen Sie die Sequenz nach dem Hinzufügen in „Snowflake Approval Sequence“ (Snowflake-Genehmigungssequenz) um und speichern Sie sie.

• Wählen Sie die Sequenz „Snowflake Approval Sequence“ aus, die wir gerade gespeichert haben, um den delegierten Snowflake-Flow während des Zugriffsanforderungsprozesses aufzurufen.

• Aktivieren Sie Zugriffsanfragen für jede Rolle.

• Gehen Sie zum Endbenutzer-Dashboard und wählen Sie „Request Access“ (Zugriff anfordern) -> Snowflake, um abschließend zu prüfen, ob der:die Benutzer:in diese Rollen anfordern kann.

• Sie sollten alle Rollen aufgelistet sehen, die Benutzer:innen anfordern können.

Slack-Anforderungen

Slack stellt die Benachrichtigungsebene für die Workflows bereit.

1. Berechtigungsbereiche und Berechtigungen: Benutzer:innen, die den Slack-Konnektor in Okta Workflows autorisieren, müssen über die Berechtigung verfügen, dem Workspace Apps hinzuzufügen.
2. App-Autorisierung: Autorisieren Sie die Okta Workflows-App in Ihrem Slack-Workspace.
3. Channel-ID: Ermitteln Sie die spezifische Slack-Channel-ID (z. B. #security-alerts oder #it-ops), in der der Workflow Nachrichten posten soll. 

Nachdem die grundlegenden Anforderungen nun erfüllt sind, werden wir das Workflows-Paket entpacken und das Architektur-Setup detailliert beschreiben.

Die Architektur: Detaillierte Informationen zur Drei-Workflow-Lösung

In diesem Abschnitt schlüsseln wir auf, was jeder der drei Haupt-Workflows bewirkt:

1. Snowflake Delegated Flow (Zuweisung) 
2. Zuweisung von Berechtigungen aufheben 
3. Benutzerzuweisung für Snowflake aufheben

Ansehen: So verwenden Sie OIG und Workflows zur Verwaltung von Rollen in Snowflake

Dieses Video zeigt, wie OIG und Workflows eingesetzt werden, um Snowflake-Rollen in großem Maßstab ohne die Einschränkungen herkömmlicher Integrationskonnektoren zu verwalten. Sie erfahren, wie diese Integration Aufgaben automatisiert, Daten absichert, die Governance-Lücke schließt und dabei das Risiko menschlicher Fehler reduziert.

1. Der Flow für delegierte Zuweisungen: Die „Vordertür“

Dieser Flow ist für die delegierte Verwaltung konzipiert und ermöglicht es Admins, Rollenzuweisungen auszulösen, ohne die Workflows-Konsole aufrufen zu müssen.

• Logik- und Sicherheitskontrollen: Der Flow beginnt mit der Annahme einer userEmail und einer requestedRole. Vor der Ausführung führt es eine readUser -Prüfung in Okta und eine getAssignedUserForApplication -Prüfung durch, um den aktuellen Benutzerstatus zu überprüfen.
• Die „Provisioned“-Anforderung: Eine „Continue If“-Karte fungiert als Gatekeeper und stellt sicher, dass der Status der Benutzer:in in der Snowflake-App ausdrücklich PROVISIONED lautet.
• Vermeidung von Race Conditions: Wir haben eine 5-Sekunden-„Wait“-Karte implementiert. Bei Tests haben wir festgestellt, dass Snowflake manchmal einige Sekunden benötigt, um neue Benutzer:innen zu registrieren, bevor es einen GRANT ROLE-Befehl akzeptieren kann.
• Ausführung: Nach der Validierung verwendet es die Snowflake-Karte „Grant Role to User“ (Rolle für Benutzer:in gewähren) und benachrichtigt das Team über einen Slack-Kanal.

Delegierter Flow: Karten zur Zuweisung von Benutzerrollen 

1. START: Delegiertes Flow-Ereignis

   1. Eingaben: requestedRole, userEmail, AccessLevelName.

2. Okta - Benutzer lesen

   1. Ruft die Details des Benutzerprofils (Vorname, Nachname) anhand der angegebenen E-Mail-Adresse ab.

3. Zeichenfolge - Verketten

   1. Kombiniert Benutzernamen zu Dokumentationszwecken.

4. Steuerung - Warten

   1. Pausiert den Flow für 5 Sekunden, damit die vorgelagerte Provisionierung abgeschlossen werden kann.

5. Okta - Zugewiesene:n Benutzer:in für Anwendung abrufen

   1. Überprüft den Zuweisungsstatus des:der spezifischen Benutzer:in für die Snowflake-Anwendung.

6. Steuerung - Fortfahren, wenn

   1. Bedingung: Nur fortfahren, wenn der Status PROVISIONED (Bereitgestellt) ist.

   2. Andernfalls: Abbruch mit Fehler „ Error granting a role to the user“ (Fehler beim Zuweisen einer Rolle an den:die Benutzer:in).

7. Snowflake – Rolle an Benutzer:in zuweisen

   1. Führt die Rollenzuweisung in Snowflake aus.

8. Zeichenfolge - Verketten

   1. Erstellt die Erfolgsmeldung für Slack.

9. ENDE: Slack – Nachricht an Kanal senden

   1. Gibt Bestätigung aus: „[Benutzer:in] was successfully assigned the role of [Rolle]“ ([Benutzer:in] wurde die Rolle [Rolle] erfolgreich zugewiesen).

2. Zuweisung von Berechtigungen aufheben: Die OIG-API-Integration

Dies ist das „Gehirn“ des Ganzen. Es übernimmt die komplexe Aufgabe, bestimmte Rollen zu widerrufen, wenn eine OIG-Berechtigung abgelehnt wird oder abläuft.

• Der „Golden Thread“ (grantId): Wenn OIG einen Widerruf auslöst, wird ein Webhook an den API-Endpoint dieses Flows gesendet. Wir verwenden eine „Object Pick“-Karte, um die grantId aus dem JSON-Code zu extrahieren: data.events.0.debugContext.debugData.grantId.
• Der OIG-API-Callback: Im anfänglichen Webhook fehlt oft der spezifische Rollenname. Der Flow verwendet eine benutzerdefinierte API-Aktion, um die OIG-API aufzurufen: /governance/api/v1/grants/{{grantId}}?include=full_entitlements.
• Parsen verschachtelter Berechtigungen: Mit „At“- und „Get“-Karten navigiert der Flow durch die zurückgegebene Liste, um den genauen Rollennamen zu finden, der sich unter values.0.name befindet.
• Das „DENY“-Logikgatter: Um versehentliche Widerrufe während der Genehmigungszyklen zu verhindern, überprüft eine „Continue If“-Karte, ob die OIG-Aktion genau DENY entspricht.

Flow-Karten zum Aufheben von Berechtigungszuweisungen 

1. START: API-Endpoint (Webhook)

   1. Empfängt Body-Daten, die Grant- und Zielinformationen enthalten.

2. Objekt – Mehrere abrufen (Auswählen)

   1. Extrahiert die grantId und das target -Objekt aus den Ereignisdaten.

3. Objekt – Abrufen

   1. Extrahiert die Alternate ID (Benutzer-ID) aus dem Zielobjekt.

4. Okta - Benutzer lesen

   1. Ruft das vollständige Profil für den:die identifizierte:n Benutzer:in ab.

5. Zeichenfolge - Verketten

   1. Erstellt eine relative URL für die IGA-API: /governance/api/v1/grants/[grantId]?include=full_entitlements.

6. Okta IGA - Benutzerdefinierte API-Aktion

   1. Führt eine GET-Anforderung aus, um die vollständigen Details der spezifischen Berechtigung abzurufen.

7. Steuerung - Fortfahren, wenn

   1. Bedingung: Fahren Sie nur fort, wenn die action „DENY“ lautet (was auf eine Entfernungsanfrage hinweist).

8. Liste - Bei

   1. Ruft die spezifische Berechtigung aus der zurückgegebenen Liste ab.

9. Objekt – Abrufen

   1. Extrahiert den Rollennamen aus dem Berechtigungsobjekt.

10. Verketten - Vorname + Nachname

    1. Erstellt einen Benutzernamen aus dem Vor- und Nachnamen des:der Benutzer:in für die Zuordnung in Snowflake.

11. Snowflake - Rolle von Benutzer:in widerrufen

    1. Entfernt die Rolle des:der Benutzer:in in Snowflake.

12. Verketten – Slack-Ausgabe

    1. Erstellt eine Nachricht zur Ausgabe in Slack.

13. ENDE: Slack – Nachricht an Kanal senden

    1. Gibt Bestätigung aus: „[Benutzer:in] was successfully unassigned from the role [Rolle]“ ([Benutzer:in] wurde die Rolle [Rolle] erfolgreich entzogen).

3. Vollständiges Offboarding: Entfernen des:der Benutzer:in

Wenn Benutzer:innen vollständig aus der Snowflake-Anwendung in Okta entfernt werden, reicht es nicht aus, Rollen zu entziehen; die Benutzer:innen selbst sollten entfernt werden, um die Lizenz freizugeben.

• Der Auslöser: Der Flow startet, wenn die Zuweisung eines:einer Benutzer:in zur Snowflake-Anwendungsinstanz in Okta aufgehoben wird.
• Asynchrone Verarbeitung: Sie verwendet eine Async-Each-Schleife zur Verarbeitung der Zuweisungsaufhebung und ruft für jede:n entfernte:n Benutzer:in einen Helper-Flow auf.
• Der letzte Schritt: Der Helper-Flow führt den Befehl Drop User in Snowflake aus. Dies stellt sicher, dass der:die Benutzer:in vollständig aus der Snowflake-Umgebung entfernt wird, und automatisiert eine Aufgabe, die normalerweise manuelle SQL-Eingriffe erfordert.

Offboarding-Flow-Karten 

Übergeordneter Flow

1. START: Okta - Benutzer:in von Anwendung entfernt

   1. Überwacht application.user_membership.remove-Ereignisse für die Snowflake-App.

2. List - For Each (Async Each)

   1. Sendet jede:n nicht zugewiesene:n Benutzer:in zur Verarbeitung an den Helper-Flow.

Helper-Flow

1. START: Aufrufbares Ereignis

   1. Empfängt Benutzerdaten vom übergeordneten Flow.

2. Objekt – Erweitern

   1. Extrahiert die Alternate ID (typischerweise den Benutzernamen).

3. Snowflake - Drop User

   1. Löscht den Benutzer-Account in Snowflake.

4. ENDE: Slack – Nachricht an Kanal senden

   1. Benachrichtigt das Team, dass der: die Snowflake-Benutzer:in gelöscht wurde.

Testen der Einrichtung von OIG und Workflows

Testen der „Access Request-to-Role“ 

Die Zugriffsanforderung (Benutzeraktion)

1. Melden Sie sich als Standard-Testbenutzer:in an. Navigieren Sie zum Okta-Benutzer-Dashboard -> „Request access“ (Zugriff anfordern).
2. Stellen Sie eine Anfrage für den Anfragetyp „Snowflake Role“ (Snowflake-Rolle). Wählen Sie die spezifische Rolle (z. B. USERADMIN). 
3. Überprüfen Sie den Verlauf der Zugriffsanforderungen, um sicherzustellen, dass die Anforderung erstellt und die richtige genehmigende Person (Manager:in) zugewiesen wurde.

Genehmigung und Provisionierung (Aktion durch Administrator:in/Manager:in)

1. Melden Sie sich als genehmigende:r Administrator:in an und klicken Sie auf „Approve“ (Genehmigen).
2. Übertragen Sie die Rolle an Snowflake: OIG Approval (OIG-Genehmigung) → Okta Assigns Entitlement to User (Okta weist Benutzer:in die Berechtigung zu) → Okta SCIM.
3. Gehen Sie in Okta zum Profil des:der Benutzer:in -> „Applications“ (Anwendungen) -> „Snowflake“, um zu bestätigen, dass die Rolle unter „Entitlements“ (Berechtigungen) angezeigt wird.
4. Führen Sie ähnliche Prüfungen in Snowflake durch, um zu überprüfen, ob dem:der Benutzer:in eine entsprechende Rolle zugewiesen wurde.

Der:die Benutzer:in sollte sich nun bei Snowflake anmelden und die zugewiesene Rolle sehen können.

Testen des Widerrufs von Berechtigungen 

Berechtigungsentzug (Governance-Aktion)

Es gibt zwei Möglichkeiten, die Snowflake-Rollenberechtigung zu widerrufen:

1. Navigieren Sie zu „Identity Governance“ > „Access Certifications“ (Zugriffszertifizierungen) (oder zum Profil des:der Benutzer:in).
2. Navigieren Sie zu „Applications“ (Anwendungen) -> „Snowflake“ -> „Assignments“ (Zuweisungen) und klicken Sie auf „Test_user“ -> „Manage Entitlements“ (Berechtigungen verwalten).

Ausführungsablauf

1. Das OIG-Ereignis löst den API-Webhook Unassign Entitlements aus.
2. Workflow-Start: Der Flow empfängt die grantId und das target (Benutzer:in).
3. IGA-API-Aufruf: Der Workflow ruft /governance/api/v1/grants/[id] auf, um zu überprüfen, ob als Action (Aktion) DENY festgelegt ist.
4. Snowflake-Widerruf: Der Workflow führt die Karte Revoke Role from the User in Snowflake aus.
5. Slack-Audit: Eine Nachricht wird an den IT-Channel gesendet.

Verifizierung und Erfolgskriterien

1. Workflows-Verlauf: Öffnen Sie den Flow-Verlauf für das Aufheben von Berechtigungen.
   1. Erfolgsprüfung: jede Karte (Object Pick, IGA API, Snowflake Revoke) sollte ein grünes Häkchen haben.
2. Führen Sie in Snowflake SHOW GRANTS TO USER "TEST_USER"; aus. Die Rolle darf nicht mehr vorhanden sein.
3. Bestätigen Sie in Slack die Nachricht: [Benutzer:in] was successfully unassigned from the role [Rolle] ([Benutzer:in] wurde die Rolle [Rolle] erfolgreich entzogen).

Testen der Bereinigung „Drop User“ (Benutzer:in löschen) für das Offboarding

1. Heben Sie die Zuweisung dem:der Testbenutzer:in zur gesamten Snowflake-Anwendung in Okta auf.
2. Ausführungsablauf: Okta Unassignment (Okta-Zuweisungsaufhebung) → Parent Flow: User Unassigned (Übergeordneter Flow: Benutzerzuweisung aufgehoben) → Helper Flow: Drop user (Helper Flow: Benutzer:in löschen).
3. Bestätigen Sie in Okta, dass sich der:die Benutzer:in nicht mehr in der Zuweisungsliste der Snowflake-App befindet.
4. Führen Sie in Snowflake SHOW USERS LIKE 'TEST_USER%'; aus. Der:die Benutzer:in sollte keine Ergebnisse zurückgeben (gelöscht).
5. Bestätigen Sie in Slack die Benachrichtigung „Snowflake user has been dropped“ (Snowflake-Benutzer:in wurde gelöscht).

Erkenntnisse aus der Automatisierung von OIG-Workflows

Die Entwicklung dieser Automatisierung zeigte mehrere entscheidende Nuancen in der Kommunikation zwischen OIG und Snowflake auf:

Status- und Aktionszuordnung

Einer der häufigsten Fehler, auf die wir gestoßen sind, war, dass der Flow in der falschen Phase des Governance-Lebenszyklus ausgelöst wurde. Wir haben eine strikte Zuordnung für die „Continue If“-Gates festgelegt:

String-Formatierung für Snowflake

Snowflake unterscheidet zwischen Groß- und Kleinschreibung und erwartet oft ein bestimmtes Format für den Benutzernamen. Wir haben Concatenate-Karten verwendet, um firstName und lastName aus Okta zusammenzuführen, damit sie exakt den Anforderungen für den user_name in Snowflake entsprechen, zum Beispiel: JOHNDOE.

Der Wartezustand

Ohne die Wait-Karte würde der „Delegated Assignment“-Flow zeitweise mit dem Snowflake-Fehler „User Not Found“ (Benutzer:in nicht gefunden) fehlschlagen, selbst wenn der:die Benutzer:in gerade erst erstellt wurde. Eine Verzögerung von 5 Sekunden behob 100 % dieser Race-Condition-Fehler.

Erreichen echter Identity Governance

Indem Sie über den Standard-Konnektor hinausgehen und die Okta Identity Governance API in Kombination mit Workflows nutzen, schaffen Sie ein geschlossenes System, das wichtige Vorteile für die Identity Governance bietet:

• Sicherheit: Rollen werden sofort widerrufen, wenn Berechtigungen ablaufen.
• Kosteneffizienz: Snowflake-Benutzer:innen werden entfernt, wenn sie nicht mehr benötigt werden, und Lizenzen werden automatisch zurückgefordert.
• Compliance: Jede Aktion, von der OIG-Anfrage bis zum Snowflake-SQL-Befehl, wird im Ausführungsverlauf des Workflows protokolliert und ist überprüfbar.

Kostenlos testen: Lernen Sie die Vorteile der umfassenden Automatisierung komplexer Identity-Management-Prozesse mit Okta Identity Governance und Workflows kennen. Starten Sie Ihre 30-tägige kostenlose Testphase.