C'è una confusione ricorrente tra i team che stanno adottando Cloudflare Zero Trust: trattare Access e Tunnel come parti intercambiabili dello stesso sistema, quando in pratica sono prodotti con responsabilità completamente diverse. Un tecnico che configura il Tunnel e presuppone che l'autenticazione sia risolta pubblica un servizio privato senza alcuna porta di identità. Comprendere cosa fa ciascun elemento e quando vale la pena utilizzarne uno senza l'altro è ciò che separa un'implementazione ben architettata da una scappatoia in attesa di essere sfruttata.
Cosa fa Cloudflare Access
L'accesso è un proxy di identità. Si trova davanti a un nome host, ad esempio app.empresa.com, e intercetta ogni richiesta prima che raggiunga l'origine. Quando l'utente non dispone di una sessione valida, Access reindirizza al provider di identità configurato. Dopo aver eseguito con successo l'autenticazione, Access valuta la policy associata a tale applicazione: l'utente appartiene al gruppo consentito? L'autenticazione ha utilizzato l'MFA? Il dispositivo è conforme? Se tutte le condizioni sono soddisfatte, Access emette un JWT di sessione e la richiesta va all'origine.
La fonte può essere qualsiasi cosa: un server con un IP pubblico, un servizio interno, un tunnel. All'accesso non importa dove sia la fonte; gli importa di chiunque stia cercando di arrivarci. Questa distinzione è importante perché fa sì che Access funzioni davanti ad applicazioni che già dispongono di un IP pubblico, senza bisogno di un Tunnel. Se disponi di un'applicazione con un IP pubblico che necessita del controllo dell'accesso basato sull'identità aziendale, Access risolve questo problema senza spostare l'applicazione o installare cloudflared.
Cosa fa Cloudflare Tunnel
Tunnel risolve un problema diverso: come rendere un server privato raggiungibile su Internet senza aprire gateway nel firewall. Il demone cloudflared, installato sul server o in un contenitore sulla stessa rete, stabilisce una connessione in uscita crittografata al perimetro Cloudflare. Da lì, Cloudflare funge da intermediario: il traffico in entrata raggiunge il confine e viaggia lungo il tunnel già stabilito fino al servizio interno.
Il risultato è che il server interno non ha un IP pubblico, non ha la porta 80 o 443 aperta su Internet e non necessita di una regola di ingresso nel gruppo di sicurezza o nel firewall. L'unico traffico che entra è quello che proviene dal processo cloudflared stesso eseguito localmente. Un server completamente isolato dall'accesso esterno diretto è ora raggiungibile dagli utenti autorizzati attraverso l'edge di Cloudflare.
cloudflared può essere configurato come servizio systemd, contenitore Docker o distribuzione Kubernetes. La configurazione moderna utilizza la dashboard di Cloudflare per gestire il tunnel: nessun file YAML locale, con configurazione propagata tramite API. Un singolo processo cloudflared può esporre più servizi su nomi host diversi: app1.empresa.com va localmente alla porta 3000, app2.empresa.com va alla porta 4000, db-admin.empresa.com va a pgAdmin sulla porta 5050.
Quando utilizzare Tunnel senza accesso
Il tunneling senza accesso è uno scenario valido e comune: desideri instradare il traffico da un'applicazione pubblica attraverso il perimetro Cloudflare per la protezione DDoS e CDN, senza autenticazione aggiuntiva. Il servizio è accessibile pubblicamente, ma il traffico raggiunge il server solo tramite Cloudflare, senza esposizione diretta dell'IP di origine. Cloudflare protegge dagli attacchi volumetrici e il server è nascosto.
Altro utilizzo: sviluppo locale condiviso. Uno sviluppatore vuole mostrare un prototipo in esecuzione localmente a qualcuno al di fuori della rete. cloudflared tunnel --url localhost:3000 crea un URL temporaneo accessibile pubblicamente senza configurazione DNS o firewall. Nessun accesso, nessuna autenticazione, ma utile per il caso specifico.
Il rischio è dare per scontato che Tunnel implichi protezione. Non implica. Il tunnel è connettività. Senza Access in front, qualsiasi richiesta che raggiunge il nome host configurato in Cloudflare raggiunge il tuo servizio interno.
Quando utilizzare l'Accesso senza Tunnel
L'accesso senza tunnel ha senso quando la sorgente ha già un IP pubblico: un server su EC2 con un IP elastico, un'applicazione su PaaS, un endpoint API con un indirizzo pubblico. L'accesso funge da proxy d'identità davanti a questo indirizzo pubblico, senza bisogno di cloudflared.
Il dettaglio operativo critico in questo scenario: l'origine deve accettare il traffico solo dal perimetro Cloudflare. Se il server continua ad accettare richieste da qualsiasi IP, l'accesso può essere bypassato semplicemente accedendo direttamente all'IP. La pratica corretta è configurare il server per accettare il traffico solo dagli intervalli IP di Cloudflare o utilizzare un'intestazione autenticata che Access inserisce e l'applicazione verifica.
La combinazione che offre davvero Zero Trust
La combinazione dei due è ciò che implementa il modello Zero Trust completo: il Tunnel rende il server privato raggiungibile tramite Cloudflare; L'accesso richiede l'autenticazione e la valutazione delle politiche prima di consentire a qualsiasi richiesta di passare attraverso il tunnel. Il server interno non ha mai un'esposizione diretta a Internet e non riceve mai richieste non autenticate.
Il flusso: l'utente accede al nome host → Sessione di controlli di accesso, reindirizza all'IdP se necessario → dopo l'autenticazione e il controllo della policy, l'accesso inoltra la richiesta all'edge → l'edge scende nel tunnel → cloudflared la consegna al processo locale. Il server interno vede solo il traffico già autorizzato da Access.
Per l'accesso da macchina a macchina (pipeline CI/CD, agenti di monitoraggio, integrazioni) L'accesso rilascia token di servizio: un ID client e un segreto che sostituiscono il flusso SSO umano. Il servizio automatizzato include questi token nell'intestazione della richiesta e Access li riconosce come identità di servizio attendibile, applicando la policy associata. Ogni accesso tramite token di servizio genera anche un evento di audit.
La visione di chi progetta il sistema
Un punto che è stato trascurato durante la fase di progettazione: il tunnel non ha costi di uscita su Cloudflare. Al traffico che passa attraverso cloudflared non viene addebitata la larghezza di banda nel piano Team. Ciò ha implicazioni in termini di costi reali rispetto alle alternative che addebitano un costo per GB trasferito e influenza la decisione di utilizzare Cloudflare Tunnel rispetto a soluzioni di tunneling simili.
La decisione architetturale centrale quando si adottano entrambi i componenti è: dove sono le politiche di accesso? L'accesso ti consente di creare policy granulari per applicazione: un gruppo ha accesso al pannello di amministrazione, un altro ha accesso in sola lettura al monitoraggio, i collaboratori esterni accedono solo al portale della documentazione. Questa granularità non esiste nelle VPN tradizionali. Il costo per mantenere questa granularità è la gestione continua delle policy man mano che i team cambiano e le applicazioni si evolvono. Automatizzarlo tramite Terraform o l'API di Cloudflare è il passaggio che trasforma la gestione degli accessi da un'attività manuale in un processo controllato.