Cloudflare Zero Trust: accedi alle applicazioni interne senza VPN

La VPN aziendale non ha fallito perché è stata implementata in modo inadeguato. Ha fallito perché era costruito su un presupposto che non è più vero: che basta essere all'interno della rete aziendale per fidarsi di qualcuno. Quando un dipendente si connette da casa, dalla rete di un hotel o da un bar con la stessa VPN del team dell’ufficio, il perimetro di rete come concetto di sicurezza non esiste più. Ciò che rimane è un’illusione di controllo sostenuta dall’inerzia operativa.

Cloudflare Zero Trust parte da una premessa diversa: identità, dispositivo e contesto della richiesta determinano l'accesso, non l'indirizzo IP di origine. La concreta attuazione di ciò coinvolge tre componenti che hanno ruoli distinti e spesso vengono confusi anche da chi li ha già messi in produzione.

Accesso, Tunnel e WARP: cosa fa ciascuno

Cloudflare Access è un gateway di identità per le applicazioni. Quando una richiesta arriva al dominio interno pubblicato tramite Cloudflare, Access la intercetta prima che la richiesta raggiunga l'origine. L'utente esegue l'autenticazione con il provider di identità configurato: Okta, Azure AD, Google Workspace o qualsiasi provider SAML 2.0 e OIDC. Solo dopo l'autenticazione e la valutazione della politica il traffico procede verso l'origine. L'applicazione non riceve mai una richiesta non autenticata.

Cloudflare Tunnel, gestito dal demone cloudflared, opera lato server. Crea una connessione in uscita crittografata dal server al perimetro Cloudflare, senza aprire le porte del firewall in entrata. Il flusso completo: l'utente si autentica tramite Accesso → Cloudflare edge convalida → il traffico arriva attraverso il tunnel al servizio interno. Il server interno non necessita di un IP pubblico, non necessita di una regola di accesso al gruppo di sicurezza e non è direttamente esposto a Internet.

WARP è il client del dispositivo. In modalità Zero Trust, instrada il traffico del dispositivo attraverso il perimetro Cloudflare tramite il protocollo WireGuard. Ciò consente controlli di postura (crittografia del disco, versione del sistema operativo, agente di sicurezza installato) e consente ai criteri di accesso di includere lo stato del dispositivo come condizione. Per le applicazioni Web a cui si accede tramite il browser, WARP spesso non è necessario. Per i protocolli non HTTP come SSH e RDP instradati attraverso il tunnel, è obbligatorio.

Come funziona il flusso di autenticazione

La sequenza concreta per uno sviluppatore che accede a un servizio interno: l'utente accede a app.empresa.com. Access rileva che non esiste una sessione valida e reindirizza al provider di identità. L'utente esegue l'autenticazione: con MFA se i criteri lo richiedono. L'IdP ritorna ad Access con identità e attributi di gruppo confermati. Access valuta la policy: questo utente appartiene al gruppo con autorizzazioni per questa app? Se approvato, emette un JWT di sessione e la richiesta va all'edge, scendendo lungo il Tunnel fino al servizio sulla rete interna.

Per i protocolli non HTTP, ad esempio SSH, il flusso passa attraverso WARP. Il cliente stabilisce il tunnel WireGuard, la policy di postura viene controllata e il traffico SSH viene instradato attraverso Cloudflare fino alla destinazione tramite il tunnel.

Identità e provider supportati

Access supporta più provider di identità contemporaneamente nella stessa organizzazione. Un'applicazione può consentire l'autenticazione tramite Google Workspace per i dipendenti e tramite GitHub per i collaboratori esterni. Un altro potrebbe richiedere esclusivamente Okta con MFA obbligatoria. I gruppi IdP sincronizzati (team di ingegneri, squadre specifiche, dipartimenti) alimentano direttamente le policy di accesso, senza sincronizzazione manuale degli elenchi.

Oltre agli esseri umani, Access gestisce l'accesso da macchina a macchina tramite token di servizio. A una pipeline CI/CD che deve raggiungere un endpoint interno autenticato vengono assegnati un ID client e un segreto, che sostituiscono il flusso SSO umano. Ogni accesso, umano o automatizzato, genera un evento di audit con identità, timestamp, IP, dispositivo e decisione presa, esportabile tramite Logpush su SIEM, Splunk o Datadog.

Cosa non fa Zero Trust

Cloudflare Zero Trust controlla chi arriva a cosa, ma non è una soluzione per crittografare i dati in transito all'interno dell'applicazione: questa rimane responsabilità dell'applicazione stessa tramite HTTPS. Inoltre, l'accesso non sostituisce un firewall per il traffico est-ovest tra i servizi all'interno del data center o del VPC. Per la comunicazione interna tra microservizi, mTLS o service mesh rimane il meccanismo appropriato.

Un punto che manca nelle implementazioni iniziali: il Tunnel protegge il percorso tra il perimetro Cloudflare e il server di origine, ma il server deve comunque fidarsi solo delle connessioni che passano attraverso cloudflared. Se la porta 443 è aperta a Internet all'esterno del tunnel, l'accesso può essere bypassato. La pratica corretta è bloccare tutto il traffico in entrata sul server tranne quello generato dal demone Tunnel locale.

Cosa cambia a livello operativo con l'adozione

Il cambiamento più significativo non è tecnico: riguarda il modello mentale di chi gestisce l’accesso. Con la VPN, il team della rete configura percorsi e tunnel divisi; Con Zero Trust, il team di identità configura le policy per applicazione. La gestione degli accessi lascia il livello di rete ed entra nel livello di identità. Per le organizzazioni con team di rete e sicurezza separati, ciò comporta la negoziazione delle responsabilità.

Il livello gratuito (fino a 50 utenti con Accesso, Tunnel, WARP e Gateway di base) è sufficiente per la convalida della produzione. Il piano Team costa $ 7 per utente al mese e aggiunge log di controllo e gateway con filtro HTTP. Enterprise aggiunge l'isolamento del browser, la DLP e la sicurezza della posta elettronica, con prezzi negoziati. Per i team con più di 50 utenti che hanno già consolidato Okta o Azure AD, l'impegno di distribuzione raramente supera le quattro settimane di lavoro effettivo.

Cosa valutare prima della migrazione

La decisione di passare a Zero Trust non riguarda la tecnologia: riguarda dove si trova oggi il più grande rischio per la sicurezza. Se la tua attuale VPN garantisce un ampio accesso alla rete dopo l'autenticazione, una credenziale compromessa espone l'intera rete interna. Zero Trust limita il raggio d'azione: l'accesso compromesso raggiunge solo l'insieme di applicazioni esplicitamente consentite per quell'identità, con la postura del dispositivo come controllo aggiuntivo.

Iniziare con l'applicazione con il rischio di esposizione più elevato e il costo più elevato in caso di perdita. La prima migrazione, con policy limitate al gruppo e comportamento obbligatorio del dispositivo, convalida il modello completo in produzione con un impatto controllabile. Il modello testato lì viene replicato per il resto del portafoglio.