Genehmigungsworkflows in Oracle Access Governance
Genehmigungsworkflows sind strukturierte Prozesse zur Automatisierung von Genehmigungen auf Basis vordefinierter Workflows. Diese Workflows stellen sicher, dass Zugriffsanfragen, Mikrozertifizierungen und Zugriffsprüfungen von den entsprechenden Stakeholdern geprüft und genehmigt werden, was die Sicherheit und Compliance verbessert.
Beispiel: Wenn ein Benutzer über ein Self-Service-Modul Zugriff auf ein Zugriffs-Bundle anfordert, löst der mit dieser Anforderung verknüpfte Genehmigungsworkflow eine Benachrichtigung per E-Mail an die Genehmiger aus, die dann die Anforderung prüfen und beschließen, sie zu genehmigen, abzulehnen oder weitere Informationen anzufordern. Das Ergebnis des Genehmigungsprozesses wird aktualisiert, und Provisioning-Aktivitäten werden im bestimmten orchestrierten System ausgelöst. Informationen zum Erstellen und Verwalten von Genehmigungsworkflows finden Sie unter Genehmigungsworkflows erstellen und Genehmigungsworkflow verwalten.
Integrierte Genehmigungsworkflowvorlagen
Oracle Access Governance bietet Genehmigungsworkflowvorlagen, die Sie als Grundlage für das Design der benutzerdefinierten Workflows verwenden können. Sie können mehrere Vorlagen parallel oder sequenziell kombinieren, um eigene Genehmigungsworkflows zu erstellen.
Begünstigter
Die Genehmigungsanforderung wird an die Identität gesendet, die den Zugriff erhält (der Begünstigte), sodass sie eine bestimmte Berechtigung selbst genehmigen kann. Der Benutzer, der den Zugriff anfordert, muss ihn selbst genehmigen. Geeignet für Berechtigungen mit geringem Risiko, bei denen dem Begünstigten vertraut wird, dass er seinen eigenen Zugriff genehmigt
Beispiel: Hier können Sie den Zugriff auf vorab genehmigte, nicht lizenzierte Unternehmenssoftware anfordern, bei der der der Begünstigte die Anforderung selbst genehmigt.
Manager des Begünstigten
Die Genehmigungsanforderung wird an den Manager des Begünstigten gesendet. Verwenden Sie diese Option, um zu prüfen, ob der Zugriff angemessen, relevant oder innerhalb des Geschäftsbereichs liegt.
Beispiel: Verwenden Sie dieses Beispiel, wenn Sie Zugriff auf ein lizenziertes Tool eines Drittanbieters anfordern.
Primäreigentümer
Die Genehmigungsanforderung wird an den primären Verantwortlichen der Ressource gesendet. Sie können konfigurieren, dass Sie die Selbstgenehmigung zulassen oder ablehnen. Wenn die Selbstgenehmigung auf Ja gesetzt ist, können Genehmiger und Begünstigter dieselbe Identität aufweisen.
Beispiel: Senden einer Genehmigungsanforderung an den primären Eigentümer des Zugriffs-Bundles, um datenbankbezogene Berechtigungen in einem Zugriffs-Bundle zu genehmigen.
Eigentümer
Die Genehmigungsanforderung wird an die Ressourceneigentümer (primäre und zusätzliche Eigentümer) gesendet, um die ordnungsgemäße Nutzung der Ressource sicherzustellen. Sie können konfigurieren, dass Sie die Selbstgenehmigung zulassen oder ablehnen. Wenn die Selbstgenehmigung auf Ja gesetzt ist, können Genehmiger und Begünstigter dieselbe Identität aufweisen.
Beispiel: Senden einer Genehmigungsanforderung an die Eigentümer des Zugriffs-Bundles, um Zugriffsanforderungen an das Zugriffs-Bundle zu genehmigen.
Benutzerdefinierter Benutzer
Die Genehmigungsanforderung wird an eine bestimmte, vordefinierte Identität weitergeleitet, in der Regel zur zentralen Kontrolle. Geeignet für Szenarien, für die eine spezielle Genehmigungsberechtigung erforderlich ist.
Beispiel: Senden einer Genehmigungsanforderung an einen IT-Administrator, wenn ein Auftragnehmer Zugriff auf eine Anwendung für die Zusammenarbeit im Unternehmensteam anfordert.
Managementkette
Die Genehmigungsanforderung folgt einer hierarchischen Struktur. Sie beginnt beim Manager des Begünstigten und geht bei Bedarf nach oben. Geeignet für geschäftskritische Berechtigungen, die Genehmigungen auf mehreren Ebenen erfordern.
Beispiel: Verwenden Sie dieses Beispiel, wenn eine Identität eine Berechtigung für die Rolle "Beitragende" anfordert, Updates auf einem clientseitigen Speichersystem zu veröffentlichen und herunterzuladen.
Identitäts-Collections
- Mindestanzahl von Genehmigungen, die erforderlich sind, um mit der Anforderung fortzufahren.
- Vetorecht, den Antrag abzulehnen, wenn ein Mitglied dies ablehnt.
- Eskalierte Identitätserfassung, die die Anforderung nach Ablauf der ursprünglichen Anforderungszeitleiste erhält.
Wenn der Gruppe genügend Mitglieder fehlen, wird die Anforderung abgebrochen. Siehe Große Gruppen in Genehmigungsworkflows verwalten.
Beispiel: Verwenden Sie dieses Beispiel, wenn eine Identität Zugriff auf die Datenbank-Admin-Berechtigung anfordert, um eine Anforderung an die Identitäts-Collection des Datenbank-Admins weiterzuleiten.Bearbeitung von Eskalationen in Genehmigungsworkflows
Bei der Konfiguration Ihrer Genehmigungsworkflows können Sie eine Eskalationszeit festlegen – die Anzahl der Tage, die gewartet werden muss, bevor die Genehmigungsanforderung an den nächsten Genehmiger eskaliert wird. Dies liegt daran, dass der ursprüngliche Genehmiger nicht innerhalb der konfigurierten Zeit geantwortet hat.
Gilt für: Begünstigter, Manager des Begünstigten, Eigentümer, Benutzerdefinierter Benutzer, Management Chain-Vorlagentypen
Die erste Eskalation erfolgt, wenn eine Genehmigungsaufgabe nicht rechtzeitig abgeschlossen wurde. Sucht die Managementkette des ursprünglichen Genehmigers nach dem ersten verfügbaren aktiven Manager. Nachfolgende Eskalationen werden ausgeführt, wenn selbst der eskalierte Genehmiger keine Aktion ausführt. Nun beginnt das System seine nächste Suche mit dem Manager der letzten Person, der die Aufgabe hatte, und setzt die Kette fort.
Jedes Mal, wenn der Eskalationstimer für eine Anforderung abläuft, folgt Oracle Access Governance einem strukturierten Prozess, um die Aufgabe voranzutreiben. Eine Benachrichtigungs-E-Mail wird an den eskalierten Genehmiger (Manager oder ein Identitätsteil der eskalierten Identitätserfassung) gesendet, um ihn über die eskalierte Aufgabe zu informieren.
- Erste Eskalation: Durchsucht die Managementkette des Genehmigers, um den ersten aktiven Manager zu finden, der in Oracle Access Governance enthalten ist.
- Nachfolgende Eskalationen: Sucht den Manager des letzten Genehmigers, an den die Aufgabe eskaliert wurde, und setzt die Managementkette fort.
- Ersatzbetrachtung: Wenn eine Eskalationsobergrenze (maximale Anzahl von Hierarchieebenen) festgelegt ist, stoppt die Suche eine Ebene, bevor sie erreicht wird.
- Sucht jeden Elementteil der eskalierten Identitäts-Collection und weist die Aufgabe jedem zu, der sie noch nicht erhalten hat. Wenn die Aufgabe bereits an alle eskaliert wurde, wird keine weitere Aktion ausgeführt. Wenn eine Eskalationsobergrenze (maximale Anzahl von Hierarchieebenen) festgelegt ist, stoppt die Suche eine Ebene, bevor sie erreicht wird.
Großgruppengenehmigungen bearbeiten: Limit und Kriterien für Mitglieder
Wenn Sie eine Identitätserfassung für einen beliebigen Teil des Genehmigungsworkflows auswählen, wie Genehmigungen, Eskalationen oder Delegationen, setzt Oracle Access Governance ein Elementlimit durch.
Sie können eine Identitäts-Collection jeder Größe auswählen, aber nur maximal 25 Mitglieder können Aufgaben aktiv empfangen und genehmigen. Oracle Access Governance wählt die ersten 25 ACTIVE/WORKFORCE-Mitglieder aus.
ACTIVE/WORKFORCE-Elemente verfügbar sind, wird CONSUMERS hinzugefügt, um das Limit von 25 Elementen zu erreichen. Allerdings erhält kein CONSUMER-Element eine Genehmigungsaufgabe. Stattdessen wird wie folgt ein Fallback-Mechanismus gestartet.- Zugriffsprüfungen finden Sie unter Fallback Mechanism in Access Review.
- Bei Zugriffsanforderungen durchsucht Oracle Access Governance die Managementkette des Genehmigers, bis eine
ACTIVE/WORKFORCEgefunden wird, die dann als Genehmiger zugewiesen wird.Hinweis
Bei eskalierten oder delegierten Genehmigungsworkflows werden Consumer-Mitglieder nicht berücksichtigt, und der Fallback-Mechanismus gilt nicht.
Mitgliedschaftsänderung in Genehmigungszuweisung
Die Prüfungsaufgaben bleiben immer bei den zugewiesenen 25 Mitgliedern. Wenn ein Mitglied aus einer Identitäts-Collection entfernt wird oder zu INACTIVE/CONSUMER wird, werden die Aufgaben an ein anderes Mitglied in der Gruppe übergeben, um die Anzahl der 25 Mitglieder beizubehalten.
Matrizen und Kriterien für die automatische Genehmigung
In der folgenden Tabelle werden die Schlüsselkriterien für die automatische Genehmigung in beiden Matrizen zusammengefasst.
| Genehmiger ist Anforderer oder Workflow hat IC für die automatische Genehmigung, und Anforderer ist Mitglied? | Workflow ermöglicht die automatische Genehmigung, wenn AGR- oder SOD-Verstöße vorhanden sind? | Workflow ermöglicht Selbstgenehmigung? | Ist der Genehmiger Begünstigter? | Sind Verstöße vorhanden? | Aktion zur automatischen Genehmigung |
|---|---|---|---|---|---|
| Ja | Nein | Nein | Nein | Nein | Genehmigen |
| Ja | Nein | Nein | Nein | Ja | Keine Aktion |
| Ja | Nein | Nein | Ja | Nein | Keine Aktion |
| Ja | Nein | Nein | Ja | Ja | Keine Aktion |
| Ja | Nein | Ja | Nein | Nein | Genehmigen |
| Ja | Nein | Ja | Nein | Ja | Keine Aktion |
| Ja | Nein | Ja | Ja | Nein | Genehmigen |
| Ist der Workflow so konfiguriert, dass er automatisch genehmigt wird, wenn keine AGR- oder SOD-Verstöße ermittelt werden? | Sind Verstöße vorhanden? | Aktion zur automatischen Genehmigung |
|---|---|---|
| Ja | Nein | Genehmigen |
| Ja | Ja | Keine Aktion |