Utilizzo delle campagne di revisione degli accessi in Oracle Access Governance

Utilizzare Campagne per avviare un processo di revisione degli accessi. Per utilizzare le revisioni degli accessi in modo efficace, comprendere il ciclo di vita della campagna, insieme a concetti cruciali, come l'autocertificazione degli accessi e il meccanismo di fallback quando viene rilevato un revisore o un proprietario non valido. Utilizza linee guida o best practice mentre lavori con le campagne per garantire che venga condotto un processo di revisione efficace.

Accedi a fasi campagna revisione

In qualità di amministratore o amministratore campagna, per certificare i privilegi di accesso, impostare e schedulare le campagne di revisione degli accessi. Durante il suo ciclo di vita, una campagna segue corsi attraverso vari stati di revisione degli accessi. I task che è possibile eseguire dipendono dallo stato o dallo stato di una campagna.

In qualità di amministratore o amministratore campagna, avviare il processo di revisione degli accessi creando una campagna nella sezione Revisioni accessi. È possibile impostare una campagna ad hoc o schedulare una campagna periodica, formando una serie di campagne. Una campagna procede attraverso varie fasi o stati nel suo ciclo di vita. Ciò comporta la definizione dell'ambito, l'impostazione dei flussi di lavoro di approvazione, la selezione dei proprietari delle campagne e la schedulazione delle campagne. Una volta avviato, i revisori possono accettare o revocare i privilegi di accesso. Le decisioni prese sono soddisfatte nell'ambito del processo di bonifica a circuito chiuso.

Di seguito sono riportati gli stati di certificazione per le campagne di revisione degli accessi.
Accedi a fasi campagna revisione

  • Bozza: quando viene creata o aggiunta una nuova campagna di revisione dell'accesso, ma non ancora avviata. Nello stato Bozza è possibile:
    • Visualizza dettagli campagna
    • Modifica una campagna
    • Elimina una campagna
  • Pianificata: quando una campagna di revisione degli accessi viene creata per essere lanciata in un momento specifico in futuro. Lo stato Pianificato consente di:
    • Visualizza dettagli campagna
    • Modifica una campagna
    • Duplica una campagna
    • Termina una campagna
    • Termina serie campagna
  • In corso: quando viene avviata una campagna di revisione degli accessi. I revisori della campagna ricevono una notifica tramite e-mail. I revisori possono prendere decisioni sui task di revisione assegnati accettando o revocando i privilegi di accesso per soddisfare definitivamente la decisione nell'ambito del processo di correzione a ciclo chiuso. In uno stato In corso è possibile effettuare le seguenti operazioni.
    • Visualizza dettagli campagna
    • Duplica una campagna
    • Termina una campagna
    • Termina serie campagna
    • Visualizza report
    • Modifica proprietà campagna
    • Scarica dati CSV
  • Pronto per approvazione: quando i task di revisione sono stati completati o la data di scadenza della campagna è scaduta, la campagna passa allo stato Pronto per l'approvazione. Se sono presenti elementi di revisione in sospeso, le azioni suggerite fornite nel flusso di lavoro di approvazione vengono prese in considerazione automaticamente. Ad esempio, approvare tutti i task di revisione degli accessi non revisionati. Lo stato Pronto per l'approvazione consente di:
    • Visualizza dettagli campagna
    • Duplica una campagna
    • Termina una campagna
    • Termina serie campagna
    • Visualizza report
    • Scarica dati CSV
    • Modifica proprietà campagna
  • Approvata: quando il proprietario di una campagna approva e approva una campagna con l'opzione Azioni, viene contrassegnata come Approvata. La campagna passa dalla coda le mie campagne in corso alla coda le mie campagne precedenti. Lo stato Approvato consente di:
    • Visualizza dettagli campagna
    • Duplica una campagna
    • Visualizza report
    • Scarica dati CSV
  • Terminato dal sistema: quando si verifica un errore imprevisto, la campagna può essere interrotta portando allo stato Terminato dal sistema. Lo stato Terminato dal sistema consente di visualizzare i dettagli della campagna, duplicare una campagna, visualizzare un report o scaricare il report CSV. Alcune possibili cause sono:
    • Quando si verifica un errore di sistema interno, ad esempio un errore nella generazione di Insights o un errore nella convalida dei criteri della campagna.
    • Tutte le campagne Bozza e Pianificate create prima del rilascio di giugno 2023 vengono automaticamente interrotte e contrassegnate come Terminate dal sistema.

    • Quando un'istanza del servizio Oracle Access Governance viene eliminata, tutte le campagne in tale istanza del servizio vengono interrotte e contrassegnate come Terminato dal sistema.
    • Quando si verifica un errore di sistema durante la cessazione di una campagna, la campagna viene interrotta e il risultato è lo stato Terminato dal sistema.
  • Terminato: quando una campagna viene terminata da un amministratore campagna o da un proprietario della campagna. È possibile terminare una campagna quando si trova nello stato Pianificato, In corso o Pronto per l'approvazione. Una campagna viene terminata anche quando:
    • Il revisore non è attivo e la gerarchia di gestione non dispone di un utente attivo oppure il proprietario della campagna non è attivo.
    • Il processo di failback non assegna un proprietario o un revisore della campagna appropriato. La campagna è Terminata dal sistema.
    • Il numero di membri nella raccolta identità è inferiore ai revisori definiti per il flusso di lavoro di approvazione della raccolta identità.
    Lo stato Terminato consente di:
    • Visualizza dettagli campagna
    • Duplica
    • Visualizza report
    • Scarica dati CSV

Informazioni sulle barriere di autocertificazione

L'autocertificazione è un processo di approvazione o certificazione dei propri diritti di accesso senza l'intervento di un revisore esterno. Si tratta di un processo aziendale valido istituito per ridurre gli oneri amministrativi o per altre giustificazioni aziendali appropriate. Tuttavia, l'autocertificazione di solito non è raccomandata per gli accessi ad alto rischio che coinvolgono dati critici o in cui è coinvolto un potenziale beneficio personale. Oracle Access Governance consente di abilitare o disabilitare il processo di approvazione automatica.

In base al tipo di flusso di lavoro di approvazione, Oracle Access Governance abilita o disabilita i guardrail di autocertificazione per una campagna.
  • Se si seleziona il workflow Utente personalizzato, Raccolta identità o Proprietario, è possibile scegliere di abilitare o disabilitare il processo di autocertificazione. Se si sceglie il workflow Beneficiario, è inoltre possibile approvare automaticamente gli accessi.
  • Se si seleziona un altro flusso di lavoro o si sceglie di disabilitare il processo di autoapprovazione, il sistema avvia un meccanismo di fallback appropriato per assegnare automaticamente il task di revisione al successivo revisore valido disponibile.

Introduzione al meccanismo di fallback: metodi per prevenire l'interruzione della campagna

Durante l'utilizzo delle campagne, è possibile scegliere il revisore desiderato selezionando uno dei modelli di approvazione definiti nella funzione Flussi di lavoro approvazione di Oracle Access Governance. Il servizio Campagne avvierà un meccanismo di fallback nel caso in cui venga rilevato un revisore non valido o un proprietario di campagna non valido per impedire la cessazione di una campagna.

Di seguito viene indicato quando Oracle Access Governance contrassegna un revisore come non valido.
  • Quando un'identità Oracle Access Governance inattiva viene selezionata come revisore.
  • Quando un'identità attiva con il tipo di utente Consumer è selezionata come revisore.
  • Quando l'autoapprovazione è disabilitata nel modello di approvazione selezionato e il revisore è lo stesso del beneficiario i cui accessi sono in fase di revisione o certificazione.

Meccanismo di fallback per un revisore non valido

Se il revisore previsto non è valido, Oracle Access Governance avvia il seguente meccanismo di fallback, nell'ordine indicato, per assegnare un revisore valido:

Revisore direttoCatena di gestione del revisore desideratoProprietario campagnaQualsiasi utente selezionato in modo casuale con il ruolo Amministratore Access Governance.

  • Revisore previsto
  • Manager immediato del revisore, fino alla catena di gestione definita finché non viene trovato un revisore valido.
  • Se non viene trovato alcun manager attivo, il revisore viene impostato come proprietario della campagna.
  • Se l'autoapprovazione non è consentita, non vengono trovati manager attivi, il proprietario della campagna è il beneficiario, quindi qualsiasi utente, scelto in modo casuale, con i ruoli Amministratore viene assegnato automaticamente come revisore della revisione degli accessi.

Meccanismo di fallback per un proprietario campagna non valido

I proprietari di campagne non validi possono essere utenti inattivi, utenti consumer o utenti non inclusi nel flusso di lavoro di approvazione.

Se il proprietario della campagna desiderato non è valido, Oracle Access Governance avvia il seguente meccanismo di fallback per assegnare un proprietario della campagna valido:

Proprietario campagna mirataCatena di gestione del proprietario della campagnaQualsiasi utente selezionato in modo casuale con il ruolo Amministratore governance accessi.

  • Catena di gestione del proprietario della campagna.
  • Se non viene trovato alcun manager valido, qualsiasi utente, scelto in modo casuale, con il ruolo Amministratore viene assegnato automaticamente come proprietario della campagna.

Esempio 1 - Comprendere il meccanismo di fallback quando è consentita l'autocertificazione

Scenario: come amministratore della campagna e proprietario della campagna, Sarah avvia le revisioni periodiche degli accessi identità per il proprio reparto. Seleziona il modello del flusso di lavoro di approvazione Proprietario e consente l'autoapprovazione delle revisioni degli accessi. Vengono generate due revisioni degli accessi, con il tipo di assegnazione Conto come indicato di seguito.
  • Beneficiario: John Doe e Proprietario account come Sarah
  • Beneficiario: Sarah e proprietario account come Sarah
Utilizzando il modello Proprietario con autocertificazione abilitata, il revisore previsto per questa campagna sarà il proprietario dell'account, come indicato di seguito.
  • Beneficiario come John Doe e revisore come Sarah
  • Beneficiario come Sarah e revisore come Sarah

Esempio 2 - Comprendere il meccanismo di fallback quando l'autocertificazione non è consentita

Scenario: come amministratore della campagna e proprietario della campagna, Sarah avvia le revisioni ad hoc degli accessi alle identità per le funzioni critiche nelle applicazioni ad alto rischio per il suo reparto. Seleziona il modello del flusso di lavoro di approvazione Proprietario e non consente l'autoapprovazione delle revisioni degli accessi. Genera due revisioni degli accessi con il tipo di assegnazione Autorizzazione come indicato di seguito.
  • Beneficiario: John Doe e proprietario autorizzazione come Sarah
  • Beneficiario: Sarah e proprietario autorizzazione come Sarah
Poiché l'autocertificazione è disabilitata, il revisore previsto per questa campagna non può essere uguale al beneficiario. Pertanto, il meccanismo di fallback verrà avviato come segue:

Revisore direttoCatena di gestione del revisore desideratoProprietario campagnaQualsiasi utente selezionato in modo casuale con il ruolo Amministratore Access Governance.

Si supponga che non sia stato trovato alcun manager valido nella catena di gestione, quindi che il proprietario della campagna successivo debba essere assegnato come revisore. In questo esempio, il proprietario della campagna è uguale al beneficiario con autocertificazione disabilitata, quindi il revisore dell'accesso viene scelto in modo casuale, con il ruolo Amministratore, che in questo esempio è Carol Beck. I revisori degli accessi saranno pertanto i seguenti:

  • Beneficiario come John Doe e revisore come Sarah
  • Beneficiario come Sarah e revisore come Carol Beck

Best practice: linee guida da considerare durante l'utilizzo delle campagne

Durante l'esecuzione delle campagne, è necessario attenersi ad alcune best practice e linee guida per garantire un processo efficace di revisione degli accessi.

Di seguito sono riportate alcune linee guida da seguire durante l'esecuzione delle campagne.
  • Le campagne possono essere create solo dall'amministratore o dall'amministratore campagna di Oracle Access Governance.
  • Tutte le campagne possono essere gestite solo dall'amministratore di Oracle Access Governance. Amministratore campagna può gestire le campagne create. I proprietari della campagna possono gestire la campagna di loro proprietà.
  • È possibile eseguire revisioni delle identità in base alle autorizzazioni concesse direttamente nei sistemi gestiti (noti anche come autorizzazioni riconciliate) senza doverne eseguire il provisioning da Oracle Access Governance. Tuttavia, per gestire gli accessi a livello granulare, utilizzare i bundle accessi ed eseguire il provisioning delle autorizzazioni da Oracle Access Governance.
  • È possibile certificare rapidamente i privilegi eseguendo le revisioni degli accessi alle identità dal sistema Oracle Access Governance in base alle autorizzazioni assegnate direttamente. Le autorizzazioni o gli account di cui è stato eseguito il provisioning tramite criteri o gli account di identità Oracle Identity Governance (OIG) e Oracle Cloud Infrastructure (OCI) non sono coperti dalla presente revisione. Per ulteriori informazioni sull'esecuzione delle revisioni in base alle autorizzazioni riconciliate, vedere Revisioni di accesso alle identità per le autorizzazioni assegnate direttamente nei sistemi gestiti.
  • In una singola campagna non è possibile combinare due diversi tipi di revisioni degli accessi. Ad esempio, se si crea una campagna per rivedere i criteri, i criteri per le revisioni degli accessi alle identità o le revisioni della raccolta di identità non sono più applicabili e sono disabilitati.
  • Le campagne possono essere certificate da qualsiasi utente attivo associato a un flusso di lavoro di approvazione specifico. I revisori possono visualizzare solo i task di revisione associati. Un revisore non associato ad alcun flusso di lavoro di approvazione non può eseguire task su alcuna revisione.
  • Se non vengono generate revisioni, verrà automaticamente impostato lo stato Pronto per l'approvazione.
  • Proprietario campagna:
    • deve essere un utente attivo di Oracle Access Governance.
    • può ricevere notifiche e-mail ogni volta che una campagna passa attraverso vari stati della campagna.
    • può essere un revisore della revisione degli accessi basato sul meccanismo di fallback se il revisore originale previsto non è valido.
    • Può gestire una campagna di cui è proprietario.
  • È possibile approvare o autocertificare gli accessi utilizzando il modello Utente personalizzato, Raccolta identità o Proprietario. È inoltre possibile approvare automaticamente gli accessi quando si utilizza il modello di approvazione Beneficiario.
  • È possibile certificare i privilegi di accesso per gli utenti consumer, ma un utente consumer non può essere un revisore dell'accesso.
  • Per le revisioni dei criteri, non è necessario modificare il criterio dopo che le campagne sono state pianificate. Ciò comporterà il mancato completamento della richiesta di misura correttiva. Le istruzioni dei criteri devono essere coerenti durante tutto il processo della campagna.
  • Per le revisioni della raccolta di identità, non è necessario modificare i membri dopo la schedulazione delle campagne. Ciò comporterà il mancato completamento della richiesta di misura correttiva. L'elenco dei membri deve essere coerente durante tutto il processo della campagna.