Una grande organizzazione conta migliaia di utenti, centinaia di sistemi e decine di migliaia di autorizzazioni di accesso. Un dipendente che cinque anni fa lavorava nell'ufficio crediti e oggi è nel marketing probabilmente conserva ancora le vecchie abilitazioni. Un fornitore il cui progetto è terminato potrebbe avere ancora un account attivo. Gli account di servizio creati per un'integrazione temporanea restano per anni con la stessa password. Nessuno di questi casi è di per sé un disastro, ma insieme generano un livello di rischio che nessun revisore trascurerà e che nessun team di sicurezza può gestire manualmente.
Qui è essenziale distinguere due concetti. La gestione delle identità e degli accessi (IAM) risponde alla domanda se questa persona sia chi dichiara di essere e se sia autorizzata a svolgere questa operazione in questo momento: autenticazione, single sign-on, verifica multifattore ed emissione di token. La governance e amministrazione delle identità (IGA) affronta una domanda più profonda: se questa persona debba avere questo accesso, chi lo abbia approvato e quando debba essere rivisto. Le organizzazioni che dispongono solo dell'IAM chiudono bene la porta d'ingresso, ma non tengono traccia di chi abbia ricevuto una chiave.
L'architettura preferibile progetta i due ambiti come livelli complementari su un'unica fonte di identità condivisa. Al centro si trova una directory delle identità alimentata dal sistema HR e dall'anagrafica master dei soggetti, che segue ogni identità lungo il suo ciclo di vita dall'ingresso all'uscita. Il livello IAM, basato su standard aperti come OpenID Connect e SAML, gestisce l'autenticazione e l'emissione dei token per ogni applicazione, API e agente. Il livello IGA gestisce ruoli, policy, workflow di richiesta e approvazione, revisioni periodiche degli accessi e separazione dei compiti, e traduce il risultato in abilitazioni concrete nei sistemi di destinazione.
La prima considerazione pratica riguarda la progettazione del modello dei ruoli. I ruoli devono derivare dalla struttura reale dell'organizzazione e dalle mansioni, non dagli accessi esistenti; altrimenti tutte le autorizzazioni in eccesso accumulate in passato vengono formalizzate come ruoli. Un approccio praticabile combina ruoli di base assegnati per unità e posizione con abilitazioni richieste individualmente. Ad esempio, ogni dipendente di filiale riceve automaticamente il ruolo di base della filiale, ma l'accesso all'approvazione di finanziamenti oltre una soglia definita richiede una richiesta, l'approvazione di un responsabile e una data di scadenza.
La seconda considerazione riguarda l'automazione del ciclo di vita. Il controllo di sicurezza più efficace è la rimozione tempestiva degli accessi, ed è affidabile solo se collegato agli eventi HR. Quando il record di un dipendente passa allo stato di cessato, in quel preciso momento gli account devono essere disattivati, i token revocati e le abilitazioni ritirate. Un trasferimento tra unità deve rimuovere il vecchio ruolo e assegnare quello nuovo, non limitarsi ad aggiungere il nuovo. Questo collegamento guidato dagli eventi sposta il carico di lavoro del team di sicurezza dalla revisione manuale alla supervisione delle eccezioni.
La terza considerazione riguarda le identità non umane. Servizi, job pianificati, dispositivi IoT e, sempre più spesso, agenti di IA hanno tutti bisogno di un'identità, di un insieme di abilitazioni e di un responsabile designato. Queste identità devono seguire lo stesso ciclo di vita e la stessa revisione periodica degli utenti umani. Un agente che agisce per conto di un utente dovrebbe disporre di un token con ambito ristretto e durata breve, e ogni sua azione dovrebbe essere attribuita a entrambe le identità, l'agente e l'utente, così che l'audit trail non perda traccia di nessuna delle due.
In questo ambito le insidie sono numerose. Primo, partire da uno strumento anziché dal modello dei dati e dal processo; nessun prodotto può definire ruoli che nessuno ha definito. Secondo, revisioni degli accessi puramente formali, in cui i manager approvano tutto senza leggere; il rimedio è mostrare il contesto, ad esempio quando ciascuna abilitazione è stata usata l'ultima volta, e mantenere ogni revisione breve. Terzo, ignorare i sistemi legacy privi di interfacce standard, ancora gestiti tramite file e accesso diretto al database. Quarto, riunire IAM e IGA in un unico enorme progetto che perde credibilità prima di produrre il primo valore.
In Niadad, la piattaforma Shanasa («شناسا») fornisce il livello di identità e accessi basato su standard aperti: autenticazione centralizzata, single sign-on, verifica multifattore ed emissione di token per utenti, servizi e agenti. La piattaforma Parsa («پارسا») si occupa del livello di policy e governance: definizione dei ruoli e delle policy di accesso, workflow di richiesta e approvazione, revisioni periodiche e separazione dei compiti. Nel programma bancario di Niadad queste due piattaforme si affiancano all'anagrafica master dei soggetti Ashna e all'API gateway, affinché l'identità sia gestita come un'unica catena coerente dalla fonte al punto di applicazione.
La sicurezza aziendale si riduce in definitiva a una semplice domanda: siete in grado di dire, in qualsiasi momento, chi ha accesso a cosa e perché? L'IAM risponde al chi; l'IGA risponde al perché. Un'organizzazione che dispone di entrambi non solo supera gli audit, ma può aprire con fiducia i propri sistemi a nuovi utenti, partner e agenti senza perdere il controllo. Il lavoro non è mai concluso, perché le organizzazioni cambiano continuamente; ma con l'architettura giusta, tenere il passo diventa una routine anziché un'emergenza periodica.