Identity & Access Management

Breve riepilogo

IAM è un insieme di processi, regole e strumenti che permettono a chi di accedere a cosa, a quali condizioni e come esso è controllato. Obiettivi: ridurre al minimo i diritti ridondanti, ridurre la superficie di attacco, accelerare il controllo e la verifica, soddisfare i requisiti (PCI DSS, GDPR, ecc.) e misurare l'affidabilità dell'accesso.

Concetti di base

Identità: persona (dipendente, appaltatore), servizio/applicazione, dispositivo.
Autenticazione ( ) - Verifica «chi» (password MFA): diagrammi FIDO2/passkeys senza parolo.
Autorizzazione (AuthZ) - Soluzione consentita (RBAC/ABAC/ReBAC, criteri).
Credenziali - Password, chiavi, token, certificati (mTLS).
KMS/HSM/Vault, rotazioni, TTL brevi, segreti dinamici.
Ciclo di vita - Joiner-Mover-Leaver (JML) - Crea, modifica dei ruoli, revoca.

Architettura IAM di destinazione

• SSO, MFA, catalogo, federazione (OIDC/SAML), politiche di rischio.
• PDP/PEP: Decection/Enforcement - Motore di regole (OPA/Cedar) + punti di applicazione (API gateway, proxy, servizio-mesh).
• Cataloghi/sistema HR: fonte di verità su dipendenti e ruoli.
• Provider: SCIM/Automation per creare/modificare/richiamare la disponibilità.
• Controllo: loghi centralizzati, UEBA, report sui ruoli e sulle disponibilità.

• SSO (+ MFA) → del token (OIDC/JWT/SAML) → PEP controlla il token/contesto del → PDP decide in base al criterio (ruolo/attributi/rischio) → l'applicazione rilascia/disattiva l'accesso.

Autenticazione da password a passkeys

Password: solo con gestori password, almeno 12-14 caratteri, senza rotazione calendario, ma obbligatorio in caso di incidente.
MFA predefinito: TOTP/WebAuthn/Push; evitare SMS come fattore principale.
Ingresso senza parolo: FIDO2/passkeys per domini critici.
adattiva: prendere in considerazione il segnale di rischio (geo, ASN, dispositivo, anomalie) per richiedere un fattore aggiuntivo/bloccare.

Autorizzazione: RBAC, ABAC, ReBAC

RBAC: ruoli corrispondenti alle funzioni (Support, Finance, DevOps). Semplice e comprensibile, ma in crescita.
ABAC: regole relative agli attributi (reparto, livello di rischio, tempo, zona, etichette di risorse). Scalabile.
ReBAC: relazione «chi ha a che fare» (proprietari dei progetti, membri dei comandi). Utile per gli script multi-generici.

• Combina RBAC (griglia base) + ABAC/ReBAC (contesto/limite).
• JIT (Just-In-Time) - Consente di rilasciare privilegi temporanei tramite query/appro, revoca automatica.
• JEA (Just-Enough Access) - Autorizzazioni minime per l'operazione.
• PAM: disponibilità isolate «forti» (admini di database/cloud) con broker di sessioni, scrittura di schermate/comandi e rilascio di crediti di breve durata.

Federazione e SSO

Protocolli: OIDC (token JWT), SAML 2. 0 (XML asserzioni) - per provider/partner esterni.
SSO: punto di ingresso unico con MFA, riduzione del phishing, recensione centralizzata.
B2B/B2C: federazione con partner, limitazione delle aree, regole di dominio.
mTLS/m2m: utilizzare x.509 (SPIFFE/SVID) o OAuth2 Client Credentials per i servizi.

Ciclo di vita (JML) e provider

Joiner: abilitazione automatica SCIM dei dati e dei ruoli di base da HR/directory.
Movimento - I ruoli cambiano automaticamente in base agli attributi (divisione, progetto, posizione).
Leaver: recensione immediata di SSO, chiavi, token, accesso a repository/cloud/CI/CD.
Processi: richieste di accesso (ITSM), matrice di SoD (separazione dei compiti), access review periodica.

Segreti, chiavi e rotazioni

KMS/HSM: memorizza le chiavi radici/critiche e attiva il controllo delle operazioni.
Responsabili Vault/Secret - Crediti dinamici (DB, cloud), riva automatica al termine di TTL.
Rotazioni: token OAuth, chiavi di firma JWT, password servizi pianificate e in caso di incidenti.
mTLS: certificati di breve durata (ore/giorni), reimpostazione automatica.

Regole e motore delle soluzioni

Dichiarazione: conserva i criteri in Git; Controllare in CI (policy-test).
Contesto: tempo/posizione/ASN/livello di rischio/stato del dispositivo (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Monitoraggio, SLO e controllo

• Successo del AuthN/AuthZ (%), p95 tempo login/decisione, percentuale MFA/ingressi senza targa.
• Scala JIT/PAM, durata media dei privilegi.
• Rivestimento di dispositivi compliant, una percentuale di segreti a breve vita.

• Disponibilità 99. 95% al mese.
• p95 AuthZ decision ≤ 50 мс.
• Spegnere l'account al 100% per 15 minuti dopo l'offboarding.
• Controllo e UEBA: loghi non modificabili centralizzati (disponibilità, modifiche ai ruoli, input falliti, soluzioni PDP), analisi comportamentali e allarmismi per anomalie.

Incidente-rispetto in IAM

Compromissione di token/chiavi: recensione immediata, logout forzato, rotazione delle chiavi di firma, e-issue segreti di breve durata.
Abuso dei diritti: sospende l'elenco, blocca JIT/JEA, esegue l'access review nelle entità adiacenti.
IdP non disponibile: modalità offline (convalida della cache temporanea dei token a TTL corto), procedure di ripristino prioritarie.
Phishing: MFA obbligatorio, risk check sessioni, notifiche agli utenti, formazione.

Nuvole e Kubernets (pattern)

Pubblica Cloud IAM - Utilizzare i ruoli nativi con il principio least private; al posto delle chiavi «eterne», i carichi di lavoro con la Federazione OIDC al cloud (IRSA/Workload Identity).
Kubernets: RBAC per Neimspace/ruoli, limitare cluster-ammin; i segreti tramite manager esterni; servizio-mesh + OPA per le regole L7; Controller admissi (immagini firmate, proibizione latest).
Gateway API - Controllo delle JWT/mTLS, limitazione delle velocità, firma delle query (HMAC) per gli endpoint sensibili.

Pratica per iGaming/Fintech

Domini di accesso: pagamenti, antifrode, PII, provider di contenuti - isolare ruoli e segmenti di rete.
SoD Impedisce la combinazione dei ruoli in conflitto (ad esempio, creazione di promo + approvazione dei pagamenti).
PAM e JIT: per l'accesso a PSP/banche e prod-BD - solo attraverso il broker di sessioni, con registrazione e recensione automatica.
Compagine: PCI DSS - MFA, privilegi minimi, segmentazione della zona CHD; GDPR - Principio di minimizzazione dei dati e logici di accesso a PII a punti.
Partner e provider di contenuti: federazione e per-tenant policy; i token a breve vita e IP/ASN allow-list.

Errori tipici

Chiavi e token eterni: nessuna rotazione e TTL per il rischio elevato di fuoriuscite.
Offboarding manuale: ritardi nel ritiro dei diritti di accesso fantasma.
Ruoli monoliti: un ruolo «super» al posto della composizione e degli attributi.
MFA solo in admink: MFA deve essere per tutti gli ingressi e le operazioni critiche.
Loghi da nessuna parte: nessuna centralizzazione e UEBA in seguito rilevamento degli incidenti.

Road map per l'implementazione di IAM

1. Inventario utenti/servizi/risorse; mappa dei dati e della sensibilità.
2. SSO + MFA per tutti, includere fattori phishing-resistant.
3. Modello di ruolo: RBAC base + attributi (ABAC) per il contesto matrice di SoD.
4. Abilitazione SCIM: automatizzazione/modifica/revoca dei diritti da HR/directory; iscrizioni e accessi in ITSM.
5. PAM e JIT/JEA: accesso privilegiato scrittura delle sessioni, TTL brevi.
6. Segreto-gestione: rifiuto delle chiavi statiche; segreti dinamici, rotazioni, mTLS con brevissimi certificati.
7. Criteri in Git + CI: test delle regole, controllo delle modifiche, implementazioni canarie delle regole.
8. Osservazione e SLO: dashboard, alert, access review regolari.

Esempi di manufatti

AWS IAM Policy (minimo per la lettura dei report S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernets RBAC (sviluppatore namespace-scoped)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: approvazioni per ABAC (esempio)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Un criterio può richiedere «device _ compliant = true» e «tenant» corrispondenti a una risorsa.

Elenco di controllo (check-list)

• SSO abilitato per tutte le applicazioni MFA predefinito, passkeys è la priorità.
• RBAC definito; ABAC/ReBAC aggiungono il contesto; implementato da JIT/JEA.
• PAM protegge le disponibilità privilegiate Registrazione delle sessioni in corso.
• il provider SCIM da HR; offboarding completamente automatizzato.
• Segreti dinamici, con TTL breve; le rotazioni sono automatizzate.
• I criteri vengono versionati in Git, testati in CI; Ci sono i canarini.
• Dashboard e SLO per AuthN/AuthZ; login centralizzati e UEBA.
• Controlli periodici di access review e SoD rapporti per la compilazione.

FAQ

Tutti hanno bisogno di aiuto?
No, no. RBAC + ABAC sono sufficienti per ambienti semplici. ReBAC è utile per la complessa gerarchia di proprietà e multi-generalità.

Possiamo lasciare gli account locali?
Solo per break-glass e script offline, con vincoli rigidi e controlli periodici.

Come ridurre l'esplosione dei ruoli?
Aumentare la granularità delle risorse, utilizzare i modelli AVAS, automatizzare la gelosia e rinunciare ai ruoli inutilizzati.

Totale

Architettura IAM matura: SSO + MFA, diritti minimi necessari, JML automatizzato, regole centralizzate e osservabilità. Combinando RBAC con modelli di attributi e relazionali, applicando JIT/JEA e PAM e automatizzando le rotazioni dei segreti, si ottiene un accesso gestito, collaudabile e scalabile per soddisfare i requisiti di sicurezza e business.