Cloudflare Tunnel come alternativa all'apertura delle porte

Spiegazione di Cloudflare Tunnel senza apertura delle porte

In una configurazione classica di apertura delle porte, un client esterno si connette direttamente all’indirizzo IP pubblico del router o del server. Il router inoltra quindi il traffico in entrata a un servizio nella rete interna. Un Cloudflare Tunnel inverte questo processo di connessione: il Connector cloudflared funziona sulla rete interna accessibile e stabilisce autonomamente connessioni in uscita verso Cloudflare.

Se un utente accede, ad esempio, a un portale di amministrazione, Cloudflare riceve la richiesta relativa al nome host e la inoltra al connettore tramite una connessione tunnel già esistente. Quest’ultimo raggiunge il servizio di destinazione configurato, ad esempio http://localhost:8080. Per Origin non è quindi necessario né un indirizzo IP accessibile direttamente da Internet né un'autorizzazione in entrata nel firewall per questo servizio.

Ciò non significa che le regole di rete vengano meno. L'host con cloudflared Cloudflare deve poter comunicare con l'esterno. Cloudflare specifica a tal fine la porta 7844 su TCP o UDP; in questo caso vengono utilizzati rispettivamente HTTP/2 e QUIC. Il traffico in uscita deve essere consentito nel firewall locale, nel router e, se necessario, tramite un proxy aziendale. Questo è il limite pratico che si cela dietro l’affermazione „senza apertura di porte“.

Una voce DNS da sola non è sufficiente a creare questo canale di connessione protetto. Il DNS si limita ad associare un nome a un indirizzo di destinazione; non avvia alcuna connessione dalla rete privata né fornisce alcun servizio locale. Il connettore in uscita è la componente fondamentale: conosce il servizio di destinazione interno e mantiene aperto il percorso da esso verso l’esterno. È necessario configurare separatamente quali utenti sono autorizzati a utilizzare questo percorso.

Il tunnel non costituisce una protezione dell'accesso

Un tunnel riduce la visibilità diretta in rete dell’origin, ma non decide autonomamente in merito alle autorizzazioni. Se un pannello di amministrazione web viene instradato tramite un nome host pubblico, in linea di principio può essere consultato da qualsiasi utente Internet senza un’applicazione Access a monte. Cloudflare raccomanda pertanto di configurare Access prima del percorso del tunnel in produzione. Il tunnel è la via di trasporto, non il controllo degli accessi.

Per un pannello di amministrazione privilegiato, dovrebbe esserci una Politica di accesso Consentire l'accesso solo a persone o gruppi chiaramente definiti. Oltre ai criteri Include, Require ed Exclude, sono disponibili azioni quali Allow, Block, Bypass e Service Auth. L'autenticazione a più fattori (MFA) può essere imposta tramite un provider di identità collegato o come fattore aggiuntivo. Una regola generica valida per tutti gli account di un dominio di posta elettronica è solitamente troppo ampia per le interfacce con privilegi elevati.

Il livello di accesso integra, ma non sostituisce, la protezione dell’applicazione. Il pannello di amministrazione richiede comunque un accesso sicuro, aggiornamenti tempestivi, regole di sessione adeguate e un'assegnazione parsimoniosa dei diritti. Anche gli account utente locali, i ruoli e i diritti di amministrazione rimangono fondamentali: se un utente ottiene l'accesso all'applicazione dopo aver effettuato l'accesso tramite Access, a tale persona non devono essere automaticamente concessi ulteriori diritti amministrativi all'interno dell'applicazione.

Inoltre, occorre verificare se l’applicazione convalida i token di accesso o se utilizza l’opzione “tunnel” prevista a tale scopo per la verifica dei token. Ciò vincola l’applicazione alla verifica dell’identità a monte e riduce i rischi derivanti da un percorso di accesso alternativo involontario all’origin. È opportuno adottare un approccio a più livelli: pubblicazione restrittiva, verifica dell’identità con MFA, diritti minimi per l’applicazione e un servizio di destinazione accessibile internamente, non esposto al pubblico.

Classificare HTTP, SSH, RDP e TCP

Le applicazioni HTTP(S) e i protocolli di amministrazione presentano modelli di accesso diversi. Un’interfaccia web interna può essere pubblicata tramite un nome host e protetta con Access prima dell’Origin. Anche SSH, RDP e determinati servizi TCP possono essere raggiungibili tramite tunnel, ma richiedono, a seconda del metodo utilizzato, software aggiuntivo sul lato client o un accesso basato su browser. Il fatto di effettuare l’accesso tramite web non implica automaticamente un accesso di rete nativo di qualsiasi tipo.

Per SSH con il solito terminale locale, è possibile utilizzare il client cloudflared stabilire la connessione insieme ad Access. Cloudflare documenta inoltre l’SSH renderizzato dal browser come percorso di accesso a sé stante. Entrambe le varianti differiscono per quanto riguarda il flusso di lavoro del client, la configurazione SSH locale e il funzionamento; pertanto non sono intercambiabili in modo generalizzato. Le indicazioni relative a modelli di infrastruttura o certificati più avanzati devono essere incluse nella pianificazione solo se la relativa documentazione aggiornata e pertinente è stata verificata separatamente.

Un terminale SSH visualizzato tramite browser può rivelarsi utile per l’assistenza tecnica o per un accesso di emergenza in cui il tempo è un fattore critico, qualora non sia disponibile un client SSH locale. Prima dell’utilizzo, tuttavia, è necessario valutare i requisiti di audit, le procedure operative, i metodi di crittografia locali e i trasferimenti di file. Anche RDP e altri servizi TCP dovrebbero essere valutati caso per caso, anziché trattarli in modo generico come un’interfaccia web.

Tunnel non è un sostituto a tutti gli effetti per ogni tipo di collegamento di rete. I protocolli avviati dal server, come VoIP o SIP, non sono supportati; anche le sessioni TCP di lunga durata e sensibili alle interruzioni richiedono una verifica di idoneità. Inoltre, per SSH, RDP e TCP, l’Origin non vede l’IP originale del client, ma il connettore. Per HTTP, un’applicazione può CF-Connecting-IP valutare. Le liste di autorizzazione basate su IP e i log forensi devono tenere conto di questo limite.

Assegnare in modo sicuro più servizi

Un file Ingress locale associa ogni nome host pubblicato a una sola destinazione interna. Per il pannello di amministrazione e SSH è opportuno utilizzare nomi distinti: in questo modo, i permessi, i log e le modifiche successive rimangono chiaramente separati l’uno dall’altro. Cloudflared valuta le regole dall’alto verso il basso; la prima regola corrispondente determina la destinazione.

L'esempio seguente è un modello di configurazione per un tunnel gestito localmente. Utilizza intenzionalmente example.invalid e non contiene né dati di accesso né un dominio reale. Il servizio web rimane su localhost:8080 raggiungibile; la connessione SSH viene inoltrata al servizio SSH locale.

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

L'ultima regola è quella Regola "catch-all". È necessaria per i file Ingress locali e in questo caso garantisce, con http_status:404 per evitare che un nome host sconosciuto finisca per errore al primo servizio o a un altro servizio interno. Un inoltro standard su larga scala rappresenterebbe un rischio inutile, soprattutto nel caso di destinazioni amministrative.

Il file definisce esclusivamente il percorso dal tunnel a Origin. Non configura le voci DNS né protegge i nomi tramite Cloudflare Access. Prima di impostare un percorso operativo, è quindi necessario configurare separatamente il nome host e la politica di accesso. Anche a livello locale, le porte di destinazione dovrebbero essere accessibili solo dove Cloudflare ne ha effettivamente bisogno.

Prima dell'avvio è possibile verificare l'ordine senza modificare le impostazioni. Il primo comando convalida la configurazione di Ingress; il secondo mostra quale regola verrebbe applicata all'indirizzo specificato.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Selezionare in modo mirato gli accessi SSH

L'accesso SSH tramite tunnel non è un metodo di accesso standard. La variante più adatta dipende dal fatto che gli amministratori continuino a utilizzare il proprio terminale locale o debbano lavorare senza un client predisposto in caso di guasto. I modelli disponibili si differenziano per client, identità e procedura operativa; la configurazione concreta di SSHD e la gestione dei diritti locali rimangono separate da questi aspetti.

Per un piccolo team che lavora regolarmente con strumenti locali ben noti, spesso Cloudflare lato client è la soluzione ideale: la porta SSH rimane interna, mentre Access aggiunge un ulteriore livello di autenticazione prima che venga stabilita la connessione. Tuttavia, ciò non equivale a una gestione centralizzata di tutte le autorizzazioni SSH.

L'accesso tramite browser va considerato come una procedura a sé stante. Può rivelarsi utile in caso di assistenza tecnica o di accesso non pianificato, poiché non richiede la configurazione di un client SSH. Tuttavia, non rappresenta un metodo di amministrazione migliore in assoluto: il trasferimento di file, le consuete procedure con chiavi locali e i requisiti di audit possono rendere più indicato l'uso di un client terminale o di un accesso privato.

Indipendentemente dal percorso, gli strati di protezione locali rimangono inalterati. Account Linux, Regole di sudo, la configurazione dell'SSHD e i diritti sul sistema di destinazione continuano a determinare ciò che un utente che ha effettuato correttamente l'accesso è autorizzato a fare. Il tunnel non sostituisce né queste regole né l'assegnazione limitata dei diritti.

Per i servizi non HTTP pubblicati, potrebbe essere necessario l'uso di cloudflared sul lato client; SSH offre inoltre un accesso tramite browser. RDP e altri servizi TCP non dovrebbero quindi essere pianificati affrettatamente seguendo il modello SSH, ma tenendo conto dei rispettivi requisiti relativi ai client e al sistema operativo.

Tunnel, VPN, bastione o apertura delle porte

La scelta non riguarda solo la questione se una porta sia aperta, ma anche l'ambito di accesso desiderato. Cloudflare Tunnel è particolarmente adatto per un numero limitato di servizi chiaramente identificati. Chi invece deve accedere a molti sistemi interni e segmenti di rete, di solito necessita di un modello per l'accesso alla rete privata piuttosto che di un insieme di singole pubblicazioni.

Una classica apertura delle porte non è di per sé sbagliata. Può essere adeguata per un servizio volutamente pubblico, in cui la protezione delle applicazioni, il funzionamento del firewall e l’accessibilità pubblica siano gestiti in modo mirato. Al contrario, nel caso del tunnel, il connettore stabilisce la connessione dall’interno della rete interna; non è necessario rivolgersi direttamente all’origine da Internet.

Per un singolo pannello di amministrazione o un numero limitato di obiettivi di manutenzione, è consigliabile una pubblicazione basata sui servizi con accesso basato sull'identità di solito più facile da circoscrivere rispetto a un tunnel di rete completo. Ciò non esime dalla verifica del protocollo: i protocolli avviati dal server non sono supportati e le sessioni TCP lunghe e sensibili alle interruzioni possono richiedere modelli di connettività diversi.

Una VPN rimane utile quando i collaboratori necessitano di diverse applicazioni private, intervalli di indirizzi o dipendenze interne. Un bastion host, invece, concentra gli accessi SSH in un unico punto di ingresso, che a sua volta deve essere accuratamente protetto e gestito. Un proxy inverso, a sua volta, costituisce un livello per la terminazione TLS e la distribuzione delle applicazioni; non risponde da solo alla domanda su come raggiungere l’origin privato. I ruoli di proxy, server applicativo e gestore di processi possono essere svolti anche nel Confronto tra NGINX Unit e PHP-FPM capire.

La decisione pratica inizia quindi con una delimitazione: quali persone devono avere accesso a quale servizio e con quale client? Più la risposta è circoscritta, più è facile gestire un tunnel con nomi host e regole precisi. Esigenze di rete estese, protocolli speciali o requisiti elevati in termini di stabilità della sessione richiedono invece una valutazione a parte.

Garantire la sicurezza dei tunnel durante l'esercizio

Un tunnel attivo non consiste in una singola connessione occasionale. Cloudflare documenta, per ogni tunnel cloudflared, quattro connessioni in uscita di lunga durata verso almeno due dei propri data center. Se un singolo percorso di connessione dovesse interrompersi, le richieste potrebbero quindi passare attraverso un altro percorso esistente. Ciò riduce le dipendenze lungo il percorso tra il Connector e Cloudflare, ma non rende il servizio interno di per sé altamente disponibile.

Per le applicazioni critiche, più istanze di cloudflared possono utilizzare lo stesso tunnel come repliche. Ciò crea percorsi aggiuntivi dalla rete Cloudflare alla rete privata, ma non sostituisce né un'applicazione ridondante né una strategia relativa al database o all'host. Se, ad esempio, l'unico server con il pannello di amministrazione non è raggiungibile, ulteriori connettori su questo o su altri host sono d'aiuto solo se riescono effettivamente a raggiungere il servizio di destinazione funzionante. percorso di collegamento La disponibilità del personale e quella dei servizi devono quindi essere pianificate separatamente.

Se è necessario controllare in modo mirato più origini, aggirarle in caso di malfunzionamenti o distribuirle secondo determinate regole, è necessario un bilanciamento del carico aggiuntivo con controlli di integrità (health checks) e reindirizzamento del traffico (traffic steering). Un tunnel da solo non è in grado di prendere queste decisioni in modo approfondito. L’architettura dovrebbe inoltre definire come ripristinare il servizio di destinazione dopo un guasto e se durante l’interruzione siano ancora necessari accessi amministrativi.

La disponibilità non si limita al software. Se il connettore e il sistema di destinazione si trovano in un locale tecnico dedicato, anche l’alimentazione elettrica, il raffreddamento, la qualità dell’aria e i controlli periodici devono essere inclusi nel piano operativo. L’analisi relativa a Ventilazione di una sala server in cantina. Tali misure non sostituiscono i replicati, ma impediscono che tutti i percorsi di connessione previsti falliscano a causa della stessa dipendenza dall'infrastruttura locale.

Gli aggiornamenti di cloudflared devono essere effettuati durante una finestra di manutenzione pianificata: comportano un riavvio e possono quindi influire sul traffico in corso. Cloudflare indica il bilanciamento del carico o l'utilizzo di più istanze di cloudflared come opzioni per effettuare gli aggiornamenti senza interruzioni. La scelta del metodo di aggiornamento più adatto dipende dal tipo di installazione e dall'ambiente operativo e dovrebbe essere documentata prima della finestra di manutenzione.

Per ogni aggiornamento, documenta la versione installata, l’host responsabile, un percorso di ripiego e un test di raggiungibilità per il servizio di destinazione. Dopo il riavvio, verifica non solo lo stato del tunnel, ma anche se la regola di ingress definita raggiunge il servizio previsto e se il livello di accesso previsto continua a essere efficace. In questo modo, il connettore, il servizio di destinazione e il percorso di autorizzazione rimangono tracciabili come attività operative distinte.

Individuare tempestivamente le configurazioni errate più comuni

Prima del go-live, è necessario verificare il funzionamento del connettore: l’host deve poter raggiungere Cloudflare in uscita tramite la porta 7844 via TCP o UDP. È prevedibile che non vi sia un'apertura della porta in entrata, ma non un firewall in uscita che blocchi in modo indiscriminato. Solo quando cloudflared riesce a stabilire le connessioni in uscita, vale la pena esaminare il DNS, i nomi host e le regole di accesso a livello di applicazione.

1. Verifica dell'accessibilità locale: il servizio indicato nella regola Ingress deve essere accessibile dall'host cloudflared tramite l'endpoint locale o interno specificato.
2. Sincronizzare DNS e Ingress: il nome host pubblico deve corrispondere al percorso del tunnel previsto; l'ordine delle regole deve far sì che la regola specifica relativa al servizio venga applicata prima di quelle più generiche.
3. Test del catch-all: una regola finale con http_status:404 impedisce che i nomi host non previsti vengano inoltrati a un servizio predefinito.
4. Configurare Access prima del rilascio in produzione: solo in seguito sarà possibile verificare in modo controllato il percorso esterno utilizzando un account autorizzato e uno non autorizzato.

Un errore di sicurezza comune è un percorso troppo ampio: invece di autorizzare l’accesso solo a un pannello di amministrazione o a un servizio SSH ben definito, viene resa accessibile un’area di rete più ampia. Altrettanto rischiose sono le regole generiche relative ai domini e-mail per le interfacce privilegiate. Per gli accessi amministrativi, gruppi ristretti e verificabili, criteri di richiesta adeguati e l’autenticazione a più fattori (MFA) dovrebbero rispecchiare l’effettiva cerchia di persone autorizzate. Autorizzazione minima significa anche non raggruppare inutilmente nomi host e servizi di destinazione distinti.

La configurazione dei tunnel e quella delle autorizzazioni svolgono compiti diversi. La regola di ingresso (Ingress) determina dove viene instradata una connessione già accettata; la regola di accesso (Access) decide chi viene autenticato e autorizzato prima di tale connessione. Senza un’applicazione di accesso adeguata, un nome host HTTP pubblicato potrebbe essere raggiungibile da Internet. Anche gli account locali, le regole sudo, le impostazioni SSHD e il rafforzamento della sicurezza dell’applicazione rimangono quindi elementi da verificare separatamente.

Per i log e gli audit è importante il limite dell’IP di origine: in caso di SSH, RDP e altri accessi TCP, il server di origine non vede l’IP originale del client, ma il contesto del connettore. Le liste di autorizzazione basate sull’IP sul sistema di destinazione non costituiscono quindi un’assegnazione affidabile degli utenti. Le applicazioni HTTP possono valutare l’header CF-Connecting-IP, a condizione che la loro registrazione e la loro catena di fiducia ne tengano conto in modo consapevole.

Scegliere la soluzione di accesso più adatta

Cloudflare Tunnel è adatto per un singolo pannello di amministrazione web, qualora si desideri che il servizio sia raggiungibile tramite un nome host univoco, senza fornire un IP di origine pubblico né autorizzazioni in entrata. La configurazione ottimale prevede una destinazione ristretta, preceduta da un’applicazione di accesso con un gruppo di identità ristretto e autenticazione a più fattori (MFA). Questa procedura protegge il percorso di rete, ma non sostituisce né la gestione sicura delle sessioni né il controllo dei diritti nel pannello di amministrazione.

Un piccolo team amministrativo abituato a lavorare con il terminale può utilizzare SSH tramite Cloudflare e Access sul lato client. L’SSH renderizzato dal browser è particolarmente indicato come accesso di emergenza o di supporto predisposto in anticipo. Entrambe le soluzioni presentano requisiti diversi in termini di client e utilizzo; il trasferimento dei file, i flussi di lavoro e i requisiti di audit devono essere compatibili con la procedura scelta. La scelta di modelli più avanzati per le autorizzazioni SSH centralizzate dovrebbe avvenire solo sulla base della relativa documentazione specifica e aggiornata.

Chi necessita di numerosi servizi interni, interi segmenti o un’ampia comunicazione est-ovest dovrebbe valutare un accesso alla rete privata, come una VPN, oppure un modello di connettività appositamente progettato. Un singolo tunnel pubblicato non sostituisce automaticamente tutti i carichi di lavoro VPN. Il tunnel non è adatto a protocolli avviati dal server come VoIP o SIP; anche le sessioni TCP di lunga durata e sensibili alle interruzioni richiedono una verifica del protocollo specifico e delle possibili conseguenze di una riconnessione.

L'apertura classica delle porte può essere giustificabile se un servizio viene offerto consapevolmente in modo diretto al pubblico e se il firewall, la protezione dell'origin e l'autenticazione delle applicazioni vengono gestiti in modo adeguato. Un bastion host raggruppa gli accessi SSH, ma rimane esso stesso un punto di accesso che deve essere protetto con particolare attenzione. Un proxy inverso, dal canto suo, costituisce un livello per la terminazione TLS e la distribuzione delle applicazioni; non risponde da solo alla domanda su come raggiungere l’origine privata.

Lo standard minimo di produttività prevede: ambito di destinazione minimo necessario, regole basate sull’identità, autenticazione a più fattori (MFA) per i ruoli privilegiati, configurazione Ingress e Catch-all testata, processo di aggiornamento pianificato e procedura di ripristino documentata. Piano di ripristino comprende almeno le responsabilità, i percorsi alternativi e la verifica che il servizio di destinazione e il connettore siano nuovamente raggiungibili dopo la manutenzione. I tunnel riducono la superficie di rete esposta, ma non sostituiscono il rafforzamento della sicurezza delle applicazioni, le autorizzazioni locali o il monitoraggio operativo continuo.