Flussi di lavoro di approvazione in Oracle Access Governance
I flussi di lavoro di approvazione sono processi strutturati progettati per automatizzare le approvazioni in base a flussi di lavoro predefiniti. Questi flussi di lavoro garantiscono che le richieste di accesso, le micro-certificazioni e le revisioni degli accessi vengano esaminate e approvate dagli stakeholder appropriati, migliorando la sicurezza e la conformità.
Ad esempio, quando un utente richiede l'accesso a un bundle accessi tramite un modulo self-service, il flusso di lavoro di approvazione associato a tale richiesta attiva una notifica via e-mail agli approvatori, che quindi rivedono la richiesta e decidono di approvarla, rifiutarla o richiedere ulteriori informazioni. Il risultato del processo di approvazione viene aggiornato e le attività di provisioning vengono attivate nel sistema orchestrato specifico. Per creare e gestire i workflow di approvazione, vedere Crea workflow di approvazione e Gestisci workflow di approvazione.
Modelli flusso di lavoro approvazione integrati
Oracle Access Governance offre modelli di flusso di lavoro di approvazione che è possibile utilizzare come base per progettare i flussi di lavoro personalizzati. È possibile combinare più modelli in parallelo o in sequenza per creare flussi di lavoro di approvazione personalizzati.
Beneficiario
La richiesta di approvazione viene inviata all'identità che riceve l'accesso (il beneficiario), consentendo loro di approvare autonomamente un'autorizzazione specifica. L'utente che richiede l'accesso deve approvarlo autonomamente. Adatto per autorizzazioni a basso rischio in cui il beneficiario è affidabile per approvare il proprio accesso
Esempio: utilizzare questa opzione per richiedere l'accesso a software enterprise preapprovato e non con licenza, in cui il beneficiario approva automaticamente la richiesta.
Responsabile del beneficiario
La richiesta di approvazione viene inviata al manager del beneficiario. Utilizzare questa opzione per verificare se l'accesso è appropriato, pertinente o nell'ambito aziendale.
Esempio: utilizzare questo quando si richiede l'accesso a uno strumento di terze parti concesso in licenza.
Proprietario principale
La richiesta di approvazione viene inviata al proprietario principale della risorsa. È possibile configurare per consentire o non consentire l'autoapprovazione. Se l'autoapprovazione è impostata su Sì, l'approvatore e il beneficiario possono avere la stessa identità.
Esempio: invio di una richiesta di approvazione al proprietario primario del bundle accessi per approvare le autorizzazioni correlate al database all'interno di un bundle accessi.
Proprietari
La richiesta di approvazione viene inviata ai proprietari delle risorse (proprietari principali e aggiuntivi) per garantire l'uso corretto della risorsa. È possibile configurare per consentire o non consentire l'autoapprovazione. Se l'autoapprovazione è impostata su Sì, l'approvatore e il beneficiario possono avere la stessa identità.
Esempio: invio di una richiesta di approvazione ai proprietari del bundle accessi per approvare le richieste di accesso al bundle accessi.
Utente personalizzato
La richiesta di approvazione viene indirizzata a un'identità predefinita specifica, in genere per il controllo centralizzato. Adatto a scenari che richiedono un'autorità di approvazione specializzata.
Esempio: invio di una richiesta di approvazione a un amministratore IT quando un collaboratore esterno richiede l'accesso a un'applicazione di collaborazione del team aziendale.
Catena manageriale
La richiesta di approvazione segue una struttura gerarchica, a partire dal manager del beneficiario e spostando la catena in base alle esigenze. Adatto per autorizzazioni business-critical che richiedono approvazioni multilivello.
Esempio: utilizzare questa opzione quando un'identità richiede l'autorizzazione del ruolo "Contributori" per pubblicare e scaricare gli aggiornamenti in un sistema di storage lato client.
Raccolte di identità
- Numero minimo di approvazioni necessarie per procedere con la richiesta.
- Veto potere di negare la richiesta, se un membro rifiuta.
- Raccolta di identità escalata che riceve la richiesta alla scadenza della sequenza temporale della richiesta originale.
Se il gruppo non dispone di membri sufficienti, la richiesta viene annullata. Vedere Gestione di grandi gruppi nei flussi di lavoro di approvazione.
Esempio: utilizzare questa opzione quando un'identità richiede l'accesso con privilegi di amministratore del database per instradare una richiesta alla raccolta di identità di amministratore del database.Gestione escalation nei flussi di lavoro di approvazione
Durante la configurazione dei flussi di lavoro di approvazione, è possibile impostare un tempo di escalation, ovvero il numero di giorni di attesa prima di escalare la richiesta di approvazione all'approvatore successivo. Ciò accade perché l'approvatore originale non ha risposto entro il tempo configurato.
Si applica a: tipi di modello Beneficiario, Manager del beneficiario, Proprietario, Utente personalizzato, Catena di gestione
La prima escalation si verifica quando un task di approvazione non è stato completato in tempo. Cerca la catena di gestione dell'approvatore originale per il primo manager attivo disponibile. Le escalation successive si verificano se anche l'approvatore escalato non esegue alcuna azione. Ora, il sistema avvia la ricerca successiva dal manager dell'ultima persona che ha avuto il task, continuando la catena.
Ogni volta che il timer dell'escalation scade per una richiesta, Oracle Access Governance segue un processo strutturato per far avanzare il task. Un messaggio e-mail di notifica viene inviato all'approvatore escalato (manager o parte dell'identità della raccolta di identità escalata) per informarlo del task escalato.
- Prima escalation: consente di cercare la catena di gestione dell'approvatore per trovare il primo manager attivo incluso in Oracle Access Governance.
- Escalation successive: ricerca il responsabile dell'approvatore più recente a cui il task è stato escalato, collegando la catena di gestione.
- Considerazioni sul tetto retributivo: se è impostato un massimale di escalation (numero massimo di livelli di gerarchia), la ricerca arresta un livello prima di raggiungerlo.
- Cerca ogni parte membro della raccolta di identità escalata e assegna il task a chiunque non lo abbia già ricevuto. Se il task è già stato escalato a tutti, non verranno intraprese ulteriori azioni. Se è impostato un massimale di escalation (numero massimo di livelli di gerarchia), la ricerca arresta un livello prima di raggiungerlo.
Gestione delle approvazioni di grandi gruppi: limite e criteri dei membri
Quando si seleziona una raccolta di identità per qualsiasi parte del flusso di lavoro di approvazione, ad esempio approvazioni, escalation o deleghe, Oracle Access Governance applica un limite di membri.
È possibile selezionare una raccolta di identità di qualsiasi dimensione, ma solo un massimo di 25 membri possono ricevere e approvare attivamente i task. Oracle Access Governance seleziona i primi 25 membri ACTIVE/WORKFORCE.
ACTIVE/WORKFORCE, vengono aggiunti CONSUMERS per raggiungere il limite di 25 membri. Tuttavia, nessun membro CONSUMER riceve un task di approvazione, mentre un meccanismo di fallback viene attivato come segue.- Per le revisioni degli accessi, vedere Fallback Mechanism in Access Review.
- Per le richieste di accesso, Oracle Access Governance cerca la catena di gestione dell'approvatore finché non trova un
ACTIVE/WORKFORCE, che viene quindi assegnato come approvatore.Nota
Per i flussi di lavoro di approvazione escalati o delegati, i membri consumer non vengono presi in considerazione e il meccanismo di fallback non è applicabile.
Modifica appartenenza in assegnazione approvazione
I task di revisione rimangono sempre con i 25 membri assegnati. Se un membro viene rimosso da una raccolta di identità o diventa INACTIVE/CONSUMER , i task vengono passati a un altro membro del gruppo per mantenere il conteggio dei 25 membri.
Matrici e criteri di approvazione automatica
Le tabelle seguenti riassumono i criteri chiave per l'approvazione automatica nelle due matrici.
| L'approvatore è un richiedente o il flusso di lavoro ha un IC di approvazione automatica e il richiedente è un membro? | Workflow consente l'approvazione automatica se sono presenti violazioni AGR o SOD? | Il flusso di lavoro consente l'autoapprovazione? | L'approvatore è beneficiario? | Sono presenti violazioni? | Azione di approvazione automatica |
|---|---|---|---|---|---|
| Sì | N | N | N | N | Approva |
| Sì | N | N | N | Sì | Nessuna azione |
| Sì | N | N | Sì | N | Nessuna azione |
| Sì | N | N | Sì | Sì | Nessuna azione |
| Sì | N | Sì | N | N | Approva |
| Sì | N | Sì | N | Sì | Nessuna azione |
| Sì | N | Sì | Sì | N | Approva |
| Il flusso di lavoro è configurato per l'approvazione automatica se non vengono rilevate violazioni AGR o SOD? | Sono presenti violazioni? | Azione di approvazione automatica |
|---|---|---|
| Sì | N | Approva |
| Sì | Sì | Nessuna azione |