SSO aziendale e VPN: Entra ID, Keycloak, ALD Pro — guida completa 2026

Introduzione: perché è importante proprio ora

L’accesso remoto non è più un’opzione, è diventato lo standard operativo. Tra il 2020 e il 2026, la percentuale di dipendenti che lavorano almeno un giorno alla settimana fuori ufficio si è stabilizzata tra il 40 e il 55%, secondo le ricerche di settore. Nel frattempo, oltre il 60% degli incidenti su dispositivi remoti deriva da autenticazioni deboli o dall’assenza di verifica contestuale della sicurezza. La combinazione di SSO aziendale e VPN risolve questo problema: un account unico e politiche di accesso, autenticazione a più fattori, controllo dello stato dei dispositivi e monitoraggio end-to-end.

In questa guida avrai una panoramica completa: dai concetti base a schemi pratici con Microsoft Entra ID, Keycloak e ALD Pro. Analizzeremo passo dopo passo le architetture SAML e OIDC, EAP-TLS con RADIUS, integrazione con MDM e PKI, oltre agli errori tipici, strumenti e casi reali. L’obiettivo è prepararti all’implementazione di un’architettura di produzione scalabile, auditabile e resistente agli attacchi del 2026.

Fondamenti: concetti chiave indispensabili

SSO e ruoli coinvolti

SSO (Single Sign-On) significa accesso unico per applicazioni e servizi. I ruoli principali sono: IdP (Identity Provider) — fornitore dell’identità, e SP/RP (Service Provider/Relying Party) — servizio che si fida dell’IdP. Nel nostro contesto, lo SP è un gateway VPN o un broker di accesso remoto, in grado di affidarsi agli attributi provenienti dall’IdP (Entra ID, Keycloak, ALD Pro tramite federazione).

Protocolli: SAML, OIDC, OAuth2

• SAML 2.0 — scambio di asserzioni basate su XML. Spesso supportato nativamente dai gateway VPN aziendali.
• OIDC — livello di identità sopra OAuth2. Ideale per broker web e portali moderni di configurazione VPN, inclusi token temporanei.
• OAuth2 — autorizzazione delegata, utilizzato come trasporto in OIDC.

RADIUS e famiglia EAP

RADIUS è il protocollo classico per autenticazione e autorizzazione all’accesso di rete. Sopra RADIUS si applicano i metodi EAP (Extensible Authentication Protocol). Per il livello enterprise consigliamo EAP-TLS (autenticazione mutua con certificati), meno frequente PEAP/EAP-TTLS con password. La combinazione EAP-TLS + RADIUS offre il miglior equilibrio tra sicurezza e gestibilità.

Protocolli VPN e il loro ruolo

• WireGuard — moderno, leggero, veloce. Non ha SSO nativo, ma si integra tramite broker e orchestrazione delle chiavi.
• OpenVPN — flessibile, basato su TLS, ecosistema sviluppato, plugin nativi SAML/OIDC in vari prodotti.
• IKEv2/IPsec — standard per accesso aziendale, ideale con EAP-TLS e gateway hardware. Supportato su OS e dispositivi mobili.
• L2TP/SSTP — eredità da compatibilità retroattiva, ma verso il 2026 sarà sostituito da IKEv2 e soluzioni basate su SSL.

Zero Trust e accesso condizionale

Zero Trust Network Access (ZTNA) e Conditional Access prevedono: non fidarsi mai di default, valutare il contesto (utente, dispositivo, geografia, rischio), applicare MFA. Nel 2026 la tendenza è la rivalutazione continua della sessione (Continuous Access Evaluation): se un dispositivo non rispetta più le politiche, l’accesso viene limitato dinamicamente.

Approfondimento: aspetti avanzati per architetti

Identità utente e dispositivo

L’autenticazione forte riguarda non solo la persona, ma anche la device identity. La pratica migliore è assegnare un certificato al dispositivo (tramite MDM/Intune) e all’utente SSO con MFA. Il gateway VPN verifica entrambi: EAP-TLS convalida il dispositivo, SAML/OIDC l’utente e il suo rischio.

PKI e ciclo di vita dei certificati

• Scelta dell’authority radice: AD CS, EJBCA, HashiCorp Vault PKI.
• Emissione automatica via SCEP/NDES/Intune, rinnovo automatico 30–45 giorni prima della scadenza.
• CRL/OCSP, controllo obbligatorio di revoca. Per laptop dietro NAT — OCSP stapling o proxy.

Segmentazione e privilegi minimi

La VPN non deve riportarci a una rete flat. Si consiglia micro-segmentazione e policy-based routing: gli utenti accedono a intervalli IP in base ai ruoli (RBAC/ABAC). L’accesso ai servizi avviene tramite ACL di gruppo, non con allow-all statico.

Monitoraggio e compliance

I log di autenticazione da IdP, RADIUS e concentratore VPN si aggregano in SIEM. Report automatici mostrano chi, quando, da dove e a quali subnet ha avuto accesso. Per normative come la 152-FZ/localizzazione, conserva i log personali in Russia, usa la rotazione e schemi WORM per validità legale.

Prestazioni e affidabilità

• Crittografia: suite moderne (TLS 1.2/1.3, AES-GCM/ChaCha20-Poly1305), divieto di protocolli obsoleti.
• Scalabilità: cluster active-active, BGP/ECMP, delega di responsabilità RADIUS.
• Disponibilità globale: regioni vicine all’utente, Anycast DNS, design che considera restrizioni geopolitiche del traffico.

Pratica 1: pattern architetturali e scelta strategica

Pattern A: SAML/OIDC sul gateway VPN

Ideale se il gateway ha plugin nativi SAML/OIDC. L’utente fa SSO via browser (MFA, CA), il gateway riceve asserzioni, mappa gruppi in profili (indirizzi, rotte, ACL). Avvio rapido e UX elevata.

Pattern B: RADIUS + EAP-TLS

Il gateway delega la verifica certificati al RADIUS. Perfetto per IKEv2. Usa MDM per certif. client. Gli attributi da RADIUS definiscono pool e politiche.

Pattern C: combinazione di SSO utente e trusted device

All’accesso si usa EAP-TLS (dispositivo). Per risorse specifiche si controlla l’utente via SAML/OIDC su proxy applicativi o portali. Segmentazione su entrambi gli assi.

Checklist di progettazione

• Definisci il perimetro: quali subnet e app servono da remoto, quali no.
• Scegli IdP: Entra ID, Keycloak, ALD Pro (direttamente o tramite federazione).
• Decidi PKI ed emissione certificati.
• Tipo di VPN e client: IKEv2/OpenVPN/WireGuard con supporto dispositivi.
• Politiche di accesso: gruppi, attributi, conformità dispositivi, geozone, rischio.
• Logging: tracciamento autenticazioni end-to-end, retention e analytics.
• HA/DR: cluster gateway, replica IdP, RADIUS fault-tolerant.

Pratica 2: Microsoft Entra ID — tre scenari operativi

Scenario 2.1: SAML da Entra ID direttamente al gateway VPN

Ideale per: FortiGate, Palo Alto, Cisco, piattaforme OpenVPN con SAML e broker di accesso remoto.

Passi di configurazione

1. In Entra ID crea Enterprise Application tipo SAML. Inserisci Identifier e Reply URL forniti dal tuo gateway VPN (entità SP).
2. Configura mappature asserzioni: nome (NameID), gruppi (es. groups con filtro su security groups), eventualmente department, deviceid.
3. Attiva MFA e politiche Conditional Access: conformità dispositivo (Intune compliant), blocco da TOR/VPN, restrizioni geografiche.
4. Importa metadati IdP nel gateway VPN (certificato firmatario, URL SSO), associa gruppi a politiche: gruppo A - subnet Dev, gruppo B - ERP, ecc.
5. Pilota con 5–10 utenti, verifica SSO, MFA, autorizzazioni e log. Poi rollout graduale.

Checklist di validazione

• Firme SAML corrette e validità asserzione (clock skew entro 2–3 minuti).
• Gruppi rientrano nella dimensione del token (per molti gruppi usa filtri o claims per app role).
• Connessioni registrate nei log di Entra ID e nel SIEM della VPN.

Scenario 2.2: Entra ID + NPS Extension MFA (RADIUS)

Ideale per: gateway che supportano RADIUS/EAP ma non SAML. Aggiungi NPS con Extension MFA per forzare secondo fattore e accesso condizionale.

Passi di configurazione

1. Installa Windows NPS, configura NPS Extension for Azure MFA, associa a Entra ID.
2. Crea politiche RADIUS: richiedi EAP-TLS o PEAP (minimo), abilita log in testo e Event Log.
3. Imposta NPS come server AAA RADIUS sul gateway VPN. Definisci timeout MFA (30–60 secondi).
4. Configura Conditional Access in Entra ID per richiedere MFA o conformità dispositivo all’autenticazione RADIUS.

Pro e contro

• Pro: compatibile con molti gateway hardware, centralizza MFA.
• Contro: no browser SSO, UX dipende da metodo MFA e EAP supportati. PEAP ha vulnerabilità password maggiori rispetto a EAP-TLS.

Scenario 2.3: EAP-TLS via Intune + IKEv2/SSL

Ideale per: controllo rigoroso del dispositivo. Certificati via Intune (SCEP/PKCS). Supporto Windows, macOS, iOS, Android.

Passi di configurazione

1. Implementa PKI (AD CS o esterna), configura NDES/SCEP per Intune.
2. In Intune crea profili certificati (client auth), distribuiscili ai gruppi dispositivi.
3. Attiva EAP-TLS in RADIUS (FreeRADIUS o NPS), imposta CA radice e EKU permessi.
4. Configura IKEv2 o profilo SSL-TLS sul gateway VPN con richiesta certificato client. Mappa attributi RADIUS a pool indirizzi/ACL.
5. Implementa verifica dello stato dispositivo via Intune Compliance e CA: dispositivi non conformi non ottengono certificati o sono bloccati da policy.

Controllo qualità

• Revoca certificati aggiornata su CRL/OCSP entro 5–10 minuti.
• Rotazione certificati aggiorna tunnel senza intervento utente.
• Segmentazione basata su OU/gruppi dispositivi via politiche RADIUS.

Pratica 3: Keycloak come IdP universale per VPN

Quando scegliere Keycloak

Serve flessibilità, on-prem, open source, estendibilità, federazione con LDAP/AD/ALD Pro, mapper attributi, WebAuthn/TOTP. Keycloak consente configurazioni dettagliate di ruoli e flussi di autenticazione, inclusi modelli basati sul rischio e politiche contestuali.

Scenario 3.1: SAML/OIDC verso OpenVPN/Pritunl/gateway SSL

1. Implementa Keycloak HA (2–3 nodi, cluster DB esterno), abilita backup e monitoraggio dello stato.
2. Crea Realm, configura client: tipo SAML o OIDC per il tuo gateway VPN o broker (es. OpenVPN Access Server, Pritunl, molte UTM).
3. Configura mapper: gruppi, ruoli, reparto, clearance. Ottimizza dimensione token (OIDC UserInfo + micropolicies).
4. Attiva MFA: WebAuthn primario, TOTP backup. Definisci step-up per rischi elevati.
5. Importa metadati IdP nel gateway, associa gruppi a profili tunnel.

Scenario 3.2: federazione Keycloak con LDAP/AD/ALD Pro

1. Attiva User Federation: connessione LDAP a AD o ALD Pro (solo LDAPS), sincronizza a schedule o on-demand.
2. Verifica schema attributi: memberOf, departmentNumber, attributi custom per mapping policy VPN.
3. Facoltativo: SCIM provisioning da HR/IdM esterno a Keycloak.

Scenario 3.3: WireGuard con chiavi effimere via portale

Poiché WireGuard non supporta SSO nativamente, usa un portale OIDC/SAML dove l’utente fa SSO e riceve configurazione/chiave WireGuard temporanea (rotazione ogni 8–24 ore). Il server aggiorna automaticamente la chiave pubblica del client. In produzione, aggiungi binding a dispositivo e certificato OS.

Mini checklist

• Il portale conserva pochi segreti, le chiavi sono one-time o a breve durata.
• Tutti gli artefatti sono loggati, disponibili per audit, con revoca forzata.
• Gruppi Keycloak -> policy-set WireGuard (rotte, DNS, ACL server).

Pratica 4: ALD Pro — integrazione directory con RADIUS e IKEv2

Caratteristiche di ALD Pro

ALD Pro è directory aziendale e servizio di dominio ecosistema Astra Linux, con supporto LDAP/Kerberos, politiche di ruolo e account unificati. Spesso usato in VPN con FreeRADIUS + LDAP verso ALD Pro e IKEv2 su strongSwan o gateway hardware.

Scenario 4.1: FreeRADIUS + EAP-TLS

1. Implementa CA (interna o esterna), emetti certificati client per dispositivi business. Gestisci CRL/OCSP.
2. Configura FreeRADIUS: attiva moduli eap/ttls/tls, importa catena CA. Aggiungi modulo LDAP verso ALD Pro (ldaps://), filtra con attributi di gruppo.
3. Configura strongSwan IKEv2 con leftauth=pubkey, rightauth=eap-tls. Imposta RADIUS come backend AAA, mappa gruppi in pool e policy install.
4. Client: Windows/macOS/iOS/Android con profili IKEv2 che richiedono certificato client, verifica CN/SAN nominativo.

Scenario 4.2: FreeRADIUS + PEAP/TTLS (opzione transitoria)

Se la PKI non è pronta, puoi temporaneamente usare password tramite PEAP/EAP-TTLS con backend LDAP ad ALD Pro. Obbligatorio: password forti, MFA al livello IdP (es. Keycloak frontend), TLS pinning per server RADIUS. Piano di migrazione a EAP-TLS entro 3–6 mesi.

Scenario 4.3: federazione ALD Pro -> Keycloak -> VPN

ALD Pro come sorgente utenti (LDAP), Keycloak come IdP (SAML/OIDC) e VPN gateway come SP. Ottieni SSO e MFA avanzate, mentre account e gruppi rimangono in ALD Pro.

Domande di sicurezza

• Crittografia solo LDAPS, verifica validità certificato directory.
• Limitazione bind LDAP per IP e permessi.
• Sincronizzazione tempestiva disabilitazioni utenti e revoca VPN.

Pratica 5: politiche di accesso, segmentazione e DNS

Gruppi, ruoli e autorizzazioni basate su attributi

Definisci gli insiemi minimi di privilegi necessari: sviluppatori, contabilità, appaltatori, amministratori. Trasforma in politiche su RADIUS/VPN gli attributi IdP (gruppo, dipartimento, etichette di rischio). Per le zone sensibili usa step-up: MFA aggiuntivo o tunnel dedicati.

Split-tunnel e routing

• Di default lo split-tunnel con solo subnet necessarie riduce il carico.
• Per maggior rigore usa full-tunnel per ruoli amministrativi o alto rischio.
• Sperimenta ACL dinamiche basate sul rischio dagli attributi IdP.

DNS e nomi interni

Consigliato DNS aziendale dentro il tunnel, DNSSEC se possibile, filtraggio sinkhole per domini dannosi. Controlla assenza di DNS-leak. Per deployment multi-region usa resolver geodistribuiti e zone split proximate.

Pratica 6: MFA, accesso condizionale e conformità

MFA: WebAuthn standard 2026

WebAuthn/FIDO2 come metodo base, TOTP/SMS solo come riserva. Per amministratori richiedi due fattori indipendenti. Imposta politiche di rischio: dispositivo sconosciuto o geografia anomala richiedono step-up obbligatorio.

Conformità dispositivo

Integra MDM/Intune: crittografia disco, EDR attivo, aggiornamenti recenti, assenza processi vietati. Dispositivi non conformi non ricevono certificati (EAP-TLS) o hanno accesso limitato ai gruppi.

Valutazione continua dell’accesso

Abilita Continuous Access Evaluation dove possibile: in caso di compromissione dell’account o perdita del dispositivo, il accesso viene revocato in tempo reale, il tunnel chiuso e chiavi invaldate.

Pratica 7: gestione, audit e risposta

Monitoraggio e metriche

• Livelli: Accessi IdP, autenticazioni RADIUS, statistiche sessioni VPN, netflow.
• SLO: tasso successo autenticazioni, tempo medio handshake, tasso caduta, uptime tunnel.
• Anomalie: picchi accessi falliti, geografie sconosciute, accessi amministrativi notturni.

Rotazione segreti e certificati

Chiavi server VPN – rotazione ogni 6–12 mesi, certificati client 6–12 mesi con rinnovo automatico 30–45 giorni prima. Test di penetrazione regolari e revisione suite crittografiche. In fase di cambiamenti usa Change Requests e rollback precisi.

Piano di risposta

• Compromissione account: revoca immediata sessioni IdP, blocco utente, revoca manuale VPN se serve.
• Perdita dispositivo: inserimento in blocklist, revoca certificato, esecuzione playbook EDR.
• Guasto cluster: ridistribuzione con GSLB/Anycast, test DR semestrali.

Errori tipici: cosa compromette sicurezza e UX

• MS-CHAPv2 senza TLS: vulnerabile al recupero password offline. Minimo consigliato PEAP, meglio EAP-TLS.
• Singolo fattore: senza MFA phishing e furti token sono inevitabili.
• Reti flat: accesso full per tutti. Applica segmentazione e ACL per ruoli.
• Nessun controllo revoca: tunnel attivi con certificati revocati. Configura CRL/OCSP.
• Split-tunnel errato: leak DNS, bypass DLP/EDR. Verifica routing e resolver.
• Crittografie deboli: supporto a protocolli vecchi per “compatibilità” apre porte ad attacchi.
• Assenza di logging: senza log end-to-end l’investigazione è quasi impossibile.
• Token sovraccarichi (gruppi SAML): asserzioni troppo grandi bloccano l’accesso. Usa app roles e filtri.
• Mancanza HA/DR: singolo punto di fallimento IdP/RADIUS/VPN.

Strumenti e risorse: da cosa comporre la soluzione

Concentratori VPN e stack

• IKEv2/IPsec: strongSwan, Libreswan, gateway hardware enterprise.
• OpenVPN: OpenVPN Access Server, molte implementazioni con supporto SAML/OIDC.
• WireGuard: implementazioni pure o broker con orchestrazione chiavi, integrazione SSO tramite portali.
• SSL/DTLS: compatibili OpenConnect, alcuni UTM/NGFW.

Identità e federazione

• Microsoft Entra ID: SAML/OIDC, Conditional Access, SCIM, NPS Extension MFA.
• Keycloak: piattaforma open, WebAuthn/TOTP, mapper flessibili, federazione LDAP.
• ALD Pro: directory e servizi di dominio, integrazione LDAP/Kerberos, connessione RADIUS.

RADIUS e PKI

• FreeRADIUS, NPS: autenticazione, autorizzazione con attributi, audit.
• PKI: AD CS, EJBCA, HashiCorp Vault, automazione SCEP/NDES.

Gestione dispositivi e sicurezza

• MDM/EMM: Intune, soluzioni aziendali UEM.
• EDR/SIEM: integrazione log VPN/IdP/RADIUS, correlazione eventi.

Piloti rapidi e POC

In fase pilota è cruciale ottenere un VPN con SSO operativo in poche ore, non settimane, evitando lunghi cicli di acquisto. Qui è utile valutare il servizio vpn.how come startup veloce: server VPN personale non condiviso con IP dedicato, supporto WireGuard, OpenVPN, IKEv2, L2TP, SSTP (scelto in base all’esigenza), server ubicati in città chiave in Russia e all’estero (Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San José, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenaghen, Stavanger), pagamenti con carte russe (inclusi Tinkoff e Ozon), SBP e criptovalute (USDT/BTC), tariffe da 490 ₽ al giorno e da 2490 ₽ al mese con sconti, avvio automatico in ~5 minuti dall’acquisto, nessun logging. Ideale per piloti e POC focalizzati sull’integrazione con IdP (Entra ID/Keycloak/ALD Pro); per produzione è preferibile passare a infrastrutture proprie o soluzioni tipo ГОСТ-VPN secondo normativa.

Casi di studio e risultati: cosa funziona davvero

Caso 1: azienda internazionale, 1500 dipendenti

Obiettivo: accesso unico ad applicazioni aziendali e cluster Kubernetes con segmentazione per ruolo e latenza minimizzata.

Soluzione: Pattern A — SAML da Entra ID a FortiGate e portale sviluppatori, Conditional Access per dispositivi Intune. Routing split-tunnel, Anycast DNS. Pool IP e ACL legate a gruppi Entra ID.

Risultati (6 mesi): tempo di connessione iniziale ridotto da 25 a 7 minuti, richieste al Service Desk VPN diminuite del 48%, zero leak da DNS-leak, uptime 99,97%.

Caso 2: gruppo industriale, 6000+ postazioni, distribuzione geografica Russia

Obiettivo: conformità a standard interni, IdP on-prem, controllo rigoroso dispositivi.

Soluzione: Pattern B — EAP-TLS su IKEv2/strongSwan, FreeRADIUS con LDAP verso ALD Pro. Certificati PKI aziendali con emissione automatizzata. Segmentazione per subnet impianti e uffici, step-up MFA tramite Keycloak per accesso a processi produttivi.

Risultati (9 mesi): zero incidenti di compromissione credenziali VPN, investigazioni accesso ridotte a un terzo grazie ai log end-to-end, zero downtime dovuti a revoca certificati.

Caso 3: fintech startup, 220 dipendenti, multi-cloud

Obiettivo: accesso rapido sicuro ad API interne e admin panel, modello flessibile basato su ruoli e attributi.

Soluzione: Keycloak come IdP, SSO in Pritunl (OpenVPN e WireGuard), portale config WireGuard effimere via OIDC con rotazione chiavi ogni 12h. Device-check tramite MDM, accesso a production solo da laptop registrati.

Risultati (3 mesi): onboarding nuovo dipendente in 30 minuti, tentativi di accesso falliti diminuiti del 65% con attivazione WebAuthn, audit API in SIEM quasi in tempo reale.

FAQ: domande avanzate

Si può fare SSO con WireGuard?

Nativamente no. Il metodo funzionale è broker/portale: l’utente fa SSO via SAML/OIDC, riceve config e chiave WireGuard a breve durata, il server aggiorna la chiave pubblica client. Aggiungi binding dispositivo e audit.

Cosa è più veloce: WireGuard o IKEv2?

Su hardware equivalente WireGuard offre latenza e carico CPU inferiori grazie alla crittografia semplificata (ChaCha20), ma IKEv2 è più nativo per EAP-TLS e integrato nei sistemi operativi. La scelta dipende dall’ecosistema client e dai requisiti di compliance.

Serve mantenere L2TP/SSTP per compatibilità?

Solo come soluzione temporanea. Entro il 2026 questi protocolli saranno obsoleti. Pianifica migrazione a IKEv2/OpenVPN/WireGuard.

Come scalare l’autenticazione?

Divide le responsabilità: cluster IdP, RADIUS active-active, caching attributi, CDN per risorse IdP statiche, VPN cluster con ECMP/BGP. Mantieni i tempi MFA entro 1–2 secondi.

Si può fare senza certificati?

Technicamente sì, ma sconsigliato. Password e anche MFA sono più vulnerabili al phishing. EAP-TLS o certificato dispositivo più SSO utente aumentano molto la resilienza.

Come gestire MFA offline?

Prevedi fallback: chiavi hardware con firma offline, codici mono-uso di riserva, politiche grace con privilegi ridotti. Tutti i casi offline devono essere loggati e limitati temporalmente.

E IPv6?

Pianifica dual-stack: assegna indirizzi v4/v6, ACL e rotte per entrambe, DNS64/NAT64 se servono. Verifica che politiche di crittografia e filtro siano equivalenti su v6.

Quanto spesso ruotare chiavi server?

Ogni 6–12 mesi, più rinnovi immediati in caso di sospetto compromesso. Client 6–12 mesi con rinnovo automatico.

Come integrare ZTNA sopra la VPN?

Mantieni la VPN come trasparente verso subnet minime necessarie, pubblica accesso applicazioni tramite proxy con SSO e politiche applicative. Così combini segmentazione di rete e applicativa.

Dove conservare i log per audit?

Centralizza in SIEM, con retention di almeno 6–12 mesi. Per dati personali applica localizzazione secondo normativi, accesso su base ruoli e storage immutabile per validità legale.

Conclusione: dal pilota alla produzione

Abbiamo percorso dalla base a schemi avanzati con Entra ID, Keycloak e ALD Pro, esplorato SAML/OIDC, EAP-TLS, RADIUS, segmentazione, Conditional Access e operation. Passi successivi:

• Definisci modelli di accesso per ruoli e applicazioni.
• Scegli pattern architetturale: SAML sul gateway, EAP-TLS, o combinazione.
• Determina strategia IdP: Entra ID per flessibilità cloud, Keycloak per on-prem personalizzato, ALD Pro come directory aziendale con RADIUS.
• Lancia pilota su perimetro dedicato, misura UX e sicurezza.
• Formalizza politica PKI e automazione emissione/revoca certificati.
• Pianifica HA/DR e implementa logging end-to-end.
• Classifica applicazioni e abilita step-up MFA per aree sensibili.

La cosa più importante è disciplina e iterazioni. Inizia con un pilota con metriche rigorose, prosegui con rollout graduale e pentest regolari. Usa metodi solidi (EAP-TLS, WebAuthn), segmenta l’accesso e automatizza il ciclo di vita. Nel 2026 vincono le architetture dove identità e contesto fanno la differenza e la rete è solo un token di fiducia.