Lab · 12 / 16
Ogni accesso ha un motivo.
Ada deve approvare pagamenti nell’ERP. Segui la sua richiesta dal catalogo all’app, poi guarda la revisione trimestrale toglierle l’accesso quando non le serve più.
- User
- un dipendente che ha bisogno di un accesso
- IGA
- la piattaforma di governance
- Manager
- approva e rivede gli accessi
- App
- il sistema di destinazione, qui un ERP
- richiesta: Payment approver
Passo 1 di 8
Ada chiede un ruolo dal catalogo
In parole semplici Come ordinare da un menu: le voci hanno nomi comprensibili e aggiungi una breve motivazione.
Invece di un ticket a testo libero, l’utente sceglie un ruolo di business da un catalogo. Dietro il nome comprensibile ci sono i permessi tecnici: gruppi, ruoli ERP, autorizzazioni.
POST /requests { "requestedFor": "ada.lovelace", "item": "ERP · Payment approver", "justification": "Covering for the AP lead in Q4", "endDate": "2026-12-31" } - approvi? SoD ✓
Passo 2 di 8
Controllo di policy, poi instradamento
In parole semplici Prima che qualcuno dica sì, il sistema controlla una regola: la stessa persona non deve poter creare un fornitore e anche pagarlo.
Lo IGA valuta le regole di segregazione dei compiti (SoD) rispetto a ciò che Ada ha già. Nessun conflitto, quindi la richiesta va al suo manager. Un conflitto la bloccherebbe o richiederebbe un’eccezione documentata.
rule SOD-AP-01 "Create vendor" ✕ "Approve payment" ada.lovelace has: ERP · Invoice viewer result: no conflict ✓ → route to manager - approvato
Passo 3 di 8
Il manager approva
In parole semplici Il manager firma il via libera, e la firma resta per gli auditor.
Chi ha approvato, quando e perché resta salvato con la richiesta. Per i ruoli sensibili spesso c’è un secondo approvatore, il responsabile del ruolo o dell’applicazione.
- provisioning del ruolo
Passo 4 di 8
Provisioning verso l’app
In parole semplici Il sistema fa la modifica da solo, così nessuno deve ricordarsi di farla a mano.
Un connettore, SCIM o una chiamata API aggiunge il ruolo nel sistema di destinazione. Le app senza connettore ricevono un ticket per una persona, più lento e da verificare.
PATCH /scim/v2/Users/2819c223 { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "add", "path": "roles", "value": [{ "value": "PAYMENT_APPROVER" }] }] } - aggregazione account
Passo 5 di 8
Riconciliazione
In parole semplici Ogni notte il sistema conta chi c’è davvero dentro e lo confronta con la lista di chi dovrebbe esserci.
Lo IGA rilegge account e ruoli dall’app. Tutto ciò che è stato dato direttamente nell’app, fuori dallo IGA, emerge come differenza da correggere o giustificare.
ERP · Payment approver ada.lovelace ✓ requested and approved mrossi ✕ not found in IGA → flagged - revisione: mantieni o revoca?
Passo 6 di 8
La revisione trimestrale degli accessi
In parole semplici Ogni pochi mesi il manager riceve una lista: "a queste persone serve ancora?".
Una campagna di certificazione chiede ai responsabili di confermare ogni accesso. Il rischio è approvare tutto senza guardare: le campagne fatte bene mostrano il contesto, come ultimo utilizzo e confronto con i colleghi, e si concentrano sugli accessi a rischio.
- revoca
Passo 7 di 8
Ad Ada non serve più
In parole semplici Il periodo di sostituzione è finito, quindi il manager dice no.
La decisione resta registrata con la campagna. Un accesso con data di fine scadrebbe anche da solo, senza aspettare la revisione.
- rimozione del ruolo
Passo 8 di 8
Il deprovisioning chiude il cerchio
In parole semplici Il badge viene disattivato, e resta traccia di chi l’ha chiesto, chi l’ha approvato e chi l’ha tolto.
Lo IGA rimuove il ruolo e la riconciliazione successiva conferma che non c’è più. Richiesta, approvazione, revisione e rimozione insieme sono le evidenze che chiedono gli auditor.
Flusso completato.
Domini e valori d’esempio. Nulla esce dal tuo browser.