Nel 2025 il mercato italiano della cybersecurity ha raggiunto i 2,78 miliardi di euro, con una crescita del 12% rispetto all’anno precedente. Nel banking, questa accelerazione si inserisce in un contesto ancora più esigente: dal 17 gennaio 2025 il regolamento DORA è applicabile agli operatori finanziari europei, mentre le linee guida EBA sulla gestione dei rischi ICT e di sicurezza rafforzano l’esigenza di un approccio coerente al governo del rischio tecnologico. Per far fronte a un quadro simile, l’Identity Access Managementg (IAM) deve integrarsi con applicazioni, infrastrutture, ambienti ibridi, identità privilegiate e processi di audit.
Il dialogo con i sistemi di controllo accessi fisico diventa rilevante soprattutto nelle facility amministrative e negli ambienti critici, come data center, sale server, control room, locali tecnici, caveau o aree presidiate da fornitori ICT. In questo articolo vediamo come progettare un modello IAM capace di collegare identità digitali, autorizzazioni, titoli di accesso fisico, monitoraggio e governance in banca.
Takeaways
-
L’IAM nel banking non governa solo l’autenticazione degli utenti, ma identità, privilegi, policy, autorizzazioni e ciclo di vita degli accessi su ambienti ibridi.
-
L’integrazione tra IAM e ACS è rilevante soprattutto nelle facility amministrative e negli ambienti critici, dove il controllo fisico protegge infrastrutture, dati, processi sensibili o responsabilità operative.
-
RBAC e ABAC consentono di assegnare permessi e titoli di accesso fisico in modo più coerente: il primo in base al ruolo, il secondo in base ad attributi e contesto operativo.
-
Un modello IAM maturo deve collegare identità digitale, titolo di accesso, policy, approvazione, durata, utilizzo, revisione e revoca.
-
La correlazione tra eventi IAM, PAM, ACS, SIEM/SOC e sistemi applicativi rende più solide le attività di monitoraggio, audit e verifica delle autorizzazioni.
L’Identity Access Management è l’insieme di processi e tecnologie che consente di governare identità digitali, attributi, autenticazione, autorizzazioni e ciclo di vita degli accessi. Nel banking, però, il perimetro si estende oltre il login applicativo: governa identità, attributi, autorizzazioni, privilegi e ciclo di vita degli accessi in un ecosistema fatto di applicazioni core, sistemi legacy, cloud, SaaS, infrastrutture critiche e terze parti. Quando il controllo fisico protegge facility amministrative o ambienti ad alta criticità, anche il titolo di accesso - badge, credenziale temporanea o abilitazione a un varco - deve essere ricondotto allo stesso modello di governance.
Da questa capacità dipendono sicurezza, accountability e compliance.
Le criticità dell’IAM nel banking: frammentazione, privilegi e ambienti ibridi
Nel banking, la complessità dell’Identity Access Management nasce dalla stratificazione dei sistemi e dalla varietà degli accessi da governare. Applicazioni core, piattaforme legacy, cloud, SaaS, API, ambienti di test, strumenti amministrativi, sistemi di pagamento, outsourcer, fornitori ICT e infrastrutture fisiche possono avere logiche autorizzative differenti. Quando questi domini non sono ricondotti a un modello comune, il controllo accessi in banca diventa difficile da applicare e monitorare.
La prima criticità riguarda la frammentazione delle identità. Molte organizzazioni finanziarie gestiscono ancora anagrafiche, ruoli e privilegi su sistemi differenti: directory aziendali, applicazioni verticali, database legacy, sistemi HR, piattaforme cloud e strumenti di terze parti. In assenza di una fonte autorevole e di un processo di sincronizzazione affidabile, lo stesso utente può avere profili incoerenti tra ambienti diversi. Il problema non riguarda solo l’efficienza operativa: un’identità non allineata può generare privilegi eccessivi, autorizzazioni non revocate o accessi non più coerenti con il ruolo. Un caso tipico è il cambio di ruolo: se il passaggio organizzativo non attiva una revisione automatica dei privilegi, l’utente può mantenere accessi non più coerenti con il nuovo incarico.
Un secondo punto critico è il privilege creep, cioè l’accumulo progressivo di autorizzazioni non più necessarie. Nel tempo, progetti temporanei, trasferimenti e modifiche organizzative possono stratificare accessi che avrebbero dovuto essere ridotti o revocati, aumentando l’esposizione operativa e rendendo più difficile dimostrare l’applicazione del principio del minimo privilegio.
La terza criticità riguarda gli accessi privilegiati. Amministratori di sistema, DBA, operatori infrastrutturali, team di sicurezza, outsourcer e fornitori applicativi operano spesso su ambienti critici. Senza integrazione tra IAM e PAM (Privileged Access Management), gli accessi elevati rischiano di restare permanenti, condivisi, poco tracciati o non associati a un owner chiaro. Laddove molte funzioni critiche dipendono da sistemi e servizi gestiti anche da terze parti, questa opacità può diventare un problema di sicurezza, compliance e accountability.
A questo si aggiunge la gestione delle identità non umane: service account, API client, bot, automazioni, workload cloud e integrazioni machine-to-machine. In architetture bancarie sempre più API-first, queste identità possono avere privilegi rilevanti e accesso a dati o servizi critici. Per questo, devono essere governate con owner, finalità, scadenze, secret management, rotazione delle credenziali, logging e revisione periodica.
Infine, c’è il tema della correlazione degli eventi. Un evento IAM, una sessione PAM, un accesso VPN, una chiamata API, un’anomalia applicativa e un ingresso fisico in una sala tecnica possono essere segnali collegati. Se i log restano distribuiti tra sistemi non integrati, la banca perde visibilità e aumenta il tempo necessario per analisi, audit e risposta agli incidenti.
La maturità dell’IAM banking dipende quindi dalla capacità di ricondurre identità, autorizzazioni, privilegi ed eventi a un modello leggibile e verificabile.
Con quali tecnologie deve integrarsi l’Identity Access Management in banca
Una guida operativa all’integrazione dello IAM deve partire dalla mappatura dei domini che concorrono al controllo degli accessi. I sistemi HR e le anagrafiche aziendali rappresentano la fonte primaria per identità, ruolo, sede, stato contrattuale e appartenenza organizzativa. Directory e Identity Provider gestiscono autenticazione, attributi, gruppi e Single Sign-On. IGA e PAM presidiano rispettivamente richieste, approvazioni, recertificazioni, access review, account privilegiati e sessioni amministrative.
Accanto a questi sistemi, restano i domini applicativi e infrastrutturali: core banking, piattaforme legacy, cloud, SaaS, API, workload automation e strumenti di sicurezza. Nei sistemi moderni l’integrazione può avvenire tramite federazione, API o provisioning automatico; nei sistemi legacy possono servire connettori dedicati, sincronizzazioni controllate, file exchange o procedure di riconciliazione. Il punto centrale è la coerenza tra identità, attributi, policy, autorizzazioni e monitoraggio.
Il controllo accessi fisico entra in questo modello solo dove ha un impatto diretto su sicurezza, compliance o continuità operativa: facility amministrative, data center, sale server, control room, locali tecnici, caveau, aree compliance o spazi presidiati da fornitori ICT. In questi contesti, l’ACS può ricevere dallo IAM identità, ruoli, attributi, stato utente, scadenze e policy; allo stesso tempo può restituire eventi fisici utili per audit, SIEM/SOC e workflow di sicurezza.
Si pensi, per esempio, ad un fornitore ICT autorizzato a intervenire su una sala server: il sistema HR o vendor management registra l’identità esterna, l’IAM la collega a uno sponsor interno e a una scadenza, l’IGA (Identity Governance and Administration) gestisce l’approvazione, il sistema ACS abilita l’accesso fisico solo nella finestra prevista, mentre il SIEM o la control room possono ricevere gli eventi utili per audit e monitoraggio. Senza questa catena, badge, utenza applicativa, accesso VPN e autorizzazione operativa vengono gestiti separatamente.
In un contesto bancario, lo IAM agisce quindi come livello di coerenza tra identità, attributi e policy, mentre i singoli sistemi applicano il controllo nel proprio dominio. La qualità dell’integrazione si misura nella capacità di rendere tracciabile il passaggio tra identità, autorizzazione, enforcement e monitoraggio.
In un contesto bancario, lo IAM agisce come livello di coerenza tra identità, attributi e policy, mentre i singoli sistemi applicano il controllo nel proprio dominio. La qualità dell’integrazione si misura nella capacità di rendere tracciabile il passaggio tra identità, autorizzazione, enforcement e monitoraggio.
Best practice per integrare IAM e controllo accessi nel banking
Le best practice per l’integrazione IAM nel banking devono partire dal perimetro in cui il dialogo con i sistemi ACS produce valore reale. La convergenza tra identità digitale e controllo accessi fisico non riguarda indistintamente tutte le sedi bancarie, ma soprattutto le facility amministrative e gli ambienti critici. In questi contesti, lo IAM fornisce all’ACS le informazioni necessarie per assegnare, modificare o revocare un accesso; l’ACS restituisce eventi utili per monitoraggio, sicurezza, audit e workflow operativi.
Da qui derivano le principali best practice:
-
Definire il perimetro e integrare IAM e ACS nella gestione dei titoli di accesso
-
Definire la fonte autorevole dell’identità
-
Normalizzare gli attributi
-
Disegnare il ciclo joiner-mover-leaver
Assunzioni, cambi ruolo, trasferimenti, sospensioni, cambi fornitore e cessazioni devono attivare workflow di provisioning, modifica, recertificazione o revoca. Questo vale per gli accessi applicativi, per quelli privilegiati e, dove rilevante, per gli accessi fisici a data center, sale server, control room, locali tecnici e aree compliance. La revoca tempestiva resta uno dei controlli più importanti: un account digitale non disattivato, una credenziale privilegiata ancora valida o un badge fisico non revocato possono trasformarsi in vulnerabilità operative. -
Integrare IGA, PAM e processi ITSM
L’IGA consente di governare richieste, approvazioni, segregation of duties e campagne di access review; il PAM presidia account privilegiati, sessioni amministrative, escalation temporanee, accessi break-glass, credenziali tecniche e rotazione dei secret. Nei contesti bancari più strutturati, questi controlli dovrebbero dialogare anche con i processi di IT Service Management, così da collegare accessi, ticket, change, incident, approvazioni operative e audit trail. -
Applicare MFA e autenticazione adattiva agli accessi ad alto rischio
VPN, console cloud, applicazioni critiche, sessioni amministrative e operazioni sensibili richiedono controlli proporzionati al contesto, al dispositivo, alla rete, alla geografia e al comportamento dell’utente. La stessa logica può estendersi agli accessi fisici più critici: nella virtualizzazione del badge, per esempio, il rilascio di una credenziale su smartphone può essere subordinato alla verifica dell’identità tramite SSO o identity provider aziendale, con assegnazione dell’accesso in base a ruolo, policy e durata dell’autorizzazione. -
Centralizzare monitoraggio ed evidenze
Gli eventi IAM devono alimentare SIEM e SOC insieme ai log PAM, cloud, applicativi, VPN, API e, dove pertinente, fisici. Questa correlazione permette di individuare anomalie che un singolo sistema non vedrebbe: un accesso privilegiato fuori orario, una sessione VPN anomala, una chiamata API non coerente o un ingresso fisico in un’area tecnica possono assumere un significato diverso se analizzati.
Il primo passaggio è stabilire dove l’integrazione tra IAM e Access Control System è realmente necessaria. Nel banking non ha senso estendere questa logica in modo indistinto a tutte le sedi o alle agenzie: il valore emerge soprattutto dove l’accesso fisico protegge infrastrutture, dati, processi sensibili o responsabilità operative.
Definire il perimetro significa identificare quali aree richiedono un controllo fisico collegato all’identità digitale, quali ruoli possono accedervi, quali attributi devono essere valutati, quali autorizzazioni devono avere una scadenza e quali eventi devono rientrare nei flussi di monitoraggio e audit.
Una volta definito il perimetro, l’integrazione tra IAM e ACS deve basarsi su un dialogo bidirezionale. L’IAM fornisce al sistema ACS identità, ruoli, attributi, stato dell’utente, scadenze e policy; l’ACS applica queste informazioni ai varchi fisici e restituisce eventi utili per audit, monitoraggio e sicurezza.
Il modello più tradizionale è l’RBAC, Role-Based Access Control: l’accesso viene determinato dal ruolo che l’utente ricopre nell’organizzazione, con conseguente assegnazione di permessi e titoli coerenti con la funzione aziendale. È una logica utile per accessi ricorrenti e standardizzabili, per esempio distinguendo tra personale IT, funzioni compliance, operatori di sicurezza, manutentori o fornitori autorizzati. Nei contesti più critici, però, il ruolo può non essere sufficiente, due utenti con la stessa funzione possono avere autorizzazioni diverse in base alla sede, al turno, all’area da raggiungere, alla durata dell’intervento, al livello di riservatezza della risorsa o a una condizione di emergenza. In questi casi diventa rilevante l’ABAC, Attribute-Based Access Control: l’accesso viene valutato in tempo reale sulla base di attributi dell’utente, della risorsa e del contesto, come reparto, stato contrattuale, luogo, orario, livello di rischio o finestra temporale autorizzata.
Per una banca, questo significa che ogni titolo di accesso può essere collegato a una catena verificabile: identità, attributo, policy, approvazione, durata, utilizzo, revisione e revoca. Il valore dell’integrazione IAM-ACS sta quindi nel rendere un accesso fisico coerente con il modello di governance delle identità, tracciabile nel tempo e più facilmente revocabile quando ci sono cambiamenti.
Per i dipendenti, questa funzione è normalmente svolta dai sistemi HR; per fornitori, outsourcer e consulenti, può essere necessario integrare sistemi di vendor management o contractor management. Per service account e identità tecniche servono registry dedicati, owner espliciti e collegamento agli asset o alle applicazioni che li utilizzano. Senza questa distinzione, lo IAM può propagare informazioni incomplete o incoerenti verso applicazioni, infrastrutture e sistemi fisici.
Ruolo, unità organizzativa, sede, tipologia contrattuale, livello di rischio, owner, data di inizio, data di fine e stato dell’identità devono essere coerenti tra IAM, directory, applicazioni, sistemi fisici e piattaforme di audit. Gli attributi sono la base delle policy: se non sono aggiornati o governati, anche un modello avanzato di access control può produrre autorizzazioni errate.
Infine, l’integrazione deve produrre evidenze auditabili: ogni autorizzazione dovrebbe poter essere ricostruita lungo tutto il suo ciclo: richiesta, approvazione, assegnazione, utilizzo, revisione e revoca. Questo aspetto è centrale anche rispetto all’evoluzione del quadro regolatorio europeo: DORA richiede agli operatori finanziari un governo strutturato dei rischi ICT, mentre le linee guida EBA sulla gestione dei rischi ICT e di sicurezza richiamano la necessità di controlli documentati, responsabilità definite e presidi verificabili nel tempo.
Conclusione
Per integrare l’IAM nel banking biogna prima di tutto superare una gestione degli accessi costruita per silos e passare a un modello in cui identità, privilegi, applicazioni, infrastrutture, sistemi fisici e processi di audit siano governati in modo coerente. La sfida principale riguarda la capacità di collegare ogni accesso a un ruolo, a una responsabilità, a una policy, a una durata e a un’evidenza verificabile.
In un ecosistema finanziario sempre più ibrido, regolato e interconnesso, l’Identity Access Management diventa quindi una leva di sicurezza e governance operativa. La sua efficacia dipende dalla qualità delle integrazioni: con HR, directory, IGA, PAM, cloud, API, SIEM/SOC, sistemi legacy e controllo accessi fisico. Solo così il controllo accessi in banca può diventare un processo realmente tracciabile e coerente con i requisiti di resilienza del settore.
