Vai al contenuto
Avanet

Pianificare e creare Sophos ZTNA Gateway

Un Sophos ZTNA Gateway connette gli utenti alle applicazioni interne senza la necessità del classico accesso VPN a tunnel completo. Tuttavia, il vantaggio reale si ottiene solo quando la modalità gateway, il DNS, il certificato, le regole del firewall e l’accessibilità interna sono pianificate correttamente.

Questa guida descrive come pianificare e creare un gateway ZTNA in Sophos Central. L’attenzione è rivolta alla parte gateway. Per la decisione di base tra VPN, ZTNA e altre varianti di accesso remoto è adatto anche Sophos Connect o SSL VPN: quale soluzione ha l’accesso remoto?.

Per le basi neutrali su Zero Trust, ZTNA e la differenza rispetto a VPN, partire da Zero Trust spiegato semplice: ZTNA invece del VPN classico.

Comprendere le modalità del gateway

Sophos ZTNA può essere gestito con un On-premise Gateway o un Sophos Cloud Gateway. Entrambe le varianti forniscono l’accesso alle risorse interne, ma differiscono in modo significativo nell’esposizione a Internet, nel DNS, nelle operazioni e nella risoluzione dei problemi.

  • Gateway locale: La VM gateway si trova nel tuo data center o nella rete del tuo sito VM propria, DNS pubblico proprio, DNAT sulla porta 443, controllo più diretto.
  • Sophos Cloud Gateway: Gli utenti si connettono tramite Sophos Cloud Points of Presence. esposizione Internet meno diretta, CNAME DNS diversi, selezione del punto di presenza.
  • Sophos Firewall come gateway cloud: Sophos Firewall assume il ruolo di gateway per ZTNA Cloud Gateway. nessuna VM gateway separata, ma dipendenza da SFOS, funzionamento centrale e firewall.

La modalità non è solo una casella di controllo tecnica. Determina da dove entra il traffico, chi gestisce il percorso dati, quali voci DNS sono necessarie e se è necessaria una regola DNAT sul firewall.

Gateway locale

Con un gateway on-premise, una VM gateway viene distribuita su VMware ESXi o Microsoft Hyper-V. Il gateway è raggiungibile da Internet e accetta l’accesso ZTNA. In pratica, un nome DNS pubblico punta al firewall e una regola DNAT inoltra HTTPS al gateway.

Vantaggi:

  • percorso dati diretto alla tua posizione,
  • pieno controllo su gateway, segmenti, regole DNS e firewall,
  • nessuna dipendenza dal Sophos Cloud Data Plane per il punto di ingresso effettivo.

Svantaggi:

  • La VM del gateway deve essere utilizzata e aggiornata,
  • La porta 443 deve essere accessibile dall’esterno,
  • Certificato, DNS, DNAT e routing interno devono essere corretti,
  • La disponibilità dipende dalla posizione, dalla connessione Internet e dall’hypervisor.

Quando si pubblica un gateway locale tramite DNAT, la regola deve essere pianificata con la stessa attenzione delle altre pubblicazioni. Le nozioni di base possono essere trovate in Server Public con DNAT su Sophos Firewall.

Sophos Cloud Gateway

Con Sophos Cloud Gateway, l’accesso viene gestito tramite Sophos Cloud Points of Presence. Il componente gateway interno collega Sophos Cloud alle risorse interne. Ciò elimina la necessità per gli utenti di accedere direttamente al proprio IP gateway pubblico.

Ciò riduce l’esposizione diretta a Internet ma sposta parti del percorso dei dati nel cloud di Sophos. Sono quindi importanti:

  • punto di presenza adeguato vicino al data center,
  • correggere i record CNAME pubblici,
  • risoluzione DNS interna funzionante,
  • aspettative chiare in merito a latenza, disponibilità e profili di traffico,
  • Verifica dei limiti di licenza, prodotto e traffico per l’ambiente specifico.

Per applicazioni ad alta intensità di dati come archiviazione di file di grandi dimensioni, file CAD o download di massa, non dovresti testare ZTNA Cloud Gateway solo in base alla registrazione. Ciò che conta è come si comportano l’utilizzo reale, la latenza e il volume dei dati nella vita di tutti i giorni.

Sophos Firewall come ZTNA Cloud Gateway

È inoltre possibile configurare un Sophos Cloud Gateway sui dispositivi firewall Sophos gestiti centralmente. Ciò è interessante se sul posto è già presente un firewall Sophos e non si deve utilizzare una VM gateway separata.

Tuttavia, questa variante non dovrebbe essere attivata come funzione secondaria. È necessario verificare quanto segue:

  • Versione SFOS supportata e stato di gestione centrale.
  • Licenza ZTNA e mappatura degli utenti.
  • Accessibilità delle risorse interne dal punto di vista del firewall.
  • Impatto sulle finestre di manutenzione, sugli aggiornamenti del firmware e sul funzionamento del firewall.
  • Registrazione e responsabilità per i disservizi. Se il firewall è comunque il nodo centrale di accesso remoto, questa variante può essere elegante. D’altra parte, se si desidera che ZTNA funzioni indipendentemente dalla manutenzione del firewall, una VM gateway dedicata o un altro progetto a volte è più pulito.

Requisiti

Prima della distribuzione, è necessario chiarire questi punti:

  • Tenant Sophos Central con licenza ZTNA.
  • Utenti e gruppi sincronizzati.
  • Provider di identità, ad esempio ID Microsoft Entra.
  • Scegli tra il gateway on-premise o il Sophos Cloud Gateway.
  • Hypervisor o Sophos Firewall supportato, a seconda della modalità.
  • DNS pubblico per gateway e risorse.
  • Certificato jolly o concetto di certificato adeguato.
  • Risoluzione DNS interna delle applicazioni di destinazione.
  • Segmento di rete per il gateway.
  • Regole firewall dal gateway alle applicazioni.
  • Titolare delle operazioni, dei log, dei certificati e delle successive modifiche.

Per i certificati, un certificato con caratteri jolly è spesso l’opzione più pratica. L’ottenimento di un certificato con caratteri jolly è descritto in Crittografiamo creando un certificato con caratteri jolly. Se i certificati vengono gestiti direttamente su Sophos Firewall, è adatto anche Gestisci i certificati Let’s Encrypt su Sophos Firewall.

Piattaforma e dimensionamento

Per le macchine virtuali gateway, VMware ESXi e Microsoft Hyper-V sono le piattaforme tipiche. A seconda della modalità e dello stato di Sophos, potrebbero essere rilevanti altre opzioni. È fondamentale che la piattaforma sia ufficialmente supportata, aggiornata e adeguatamente monitorata.

Per le configurazioni di piccole e medie dimensioni, una VM gateway con 2 vCPU e 4 GB di RAM è un punto di partenza realistico. Ma ciò non sostituisce la pianificazione operativa. I fattori decisivi sono il numero di utenti, risorse, profilo di traffico, TLS, latenza e disponibilità.

Per gli ambienti produttivi dovresti pianificare anche:

  • Esiste un cluster gateway?
  • Il gateway funziona nella propria VLAN?
  • Come viene eseguito il backup o il ripristino della VM?
  • Esiste il monitoraggio dell’hypervisor?
  • Chi aggiorna il gateway?
  • Esiste una finestra di manutenzione per i riavvii?

Rete e sottorete

Il gateway ZTNA deve essere utilizzato nella propria sottorete o VLAN. Non dovrebbe essere semplicemente posizionato su una rete client o server. Un segmento separato semplifica le regole del firewall, la registrazione, l’acquisizione dei pacchetti e la successiva risoluzione dei problemi.

Queste reti non devono essere utilizzate per il gateway:

  • 10.42.0.0/16
  • 10.43.0.0/16
  • 10.108.0.0/16

Per un gateway locale, un nome DNS pubblico, ad esempio ztna.example.com, punta all’IP pubblico del firewall. Il firewall inoltra la porta 443 al gateway tramite DNAT. Il gateway richiede quindi l’accesso a Internet e l’accesso alle VLAN o alle reti di server in cui si trovano le applicazioni pubblicate.

Le voci DNS sono diverse per Sophos Cloud Gateway. Qui i CNAME diventano rilevanti per la convalida del dominio, gli alias del gateway e, a seconda del tipo di accesso, gli alias delle risorse. Le voci DNS pubbliche dovrebbero quindi essere controllate come una fase separata prima del rollout.

Decidi prima della distribuzione

Prima di fare clic su Add gateway, è necessario rispondere a queste domande:

  • Quali applicazioni vengono pubblicate?: L’app Web, l’app TCP e l’archiviazione di file hanno requisiti diversi.
  • Accesso senza agente o basato su agente?: DNS, CNAME ed esperienza utente differiscono.
  • Gateway on-premise o cloud?: Decide su DNAT, percorso dei dati e responsabilità operativa.
  • A quali gruppi di utenti è consentito l’accesso?: ZTNA prospera grazie a strette associazioni, non a grandi gruppi.
  • Come viene risolto il DNS internamente ed esternamente?: Le destinazioni DNS errate sono una delle fonti di errore più comuni.
  • Quale certificato viene utilizzato?: Gli errori del certificato agiscono come un errore ZTNA per gli utenti.
  • Chi esamina i registri e le modifiche?: Senza un proprietario, ZTNA diventa rapidamente difficile da sostenere.

Scarica ZTNA Gateway

In Sophos Central, i file per la macchina virtuale possono essere scaricati in Proteggi dispositivi nel menu principale.

Scarica Sophos ZTNA Gateway
Scarica Sophos Central - ZTNA Gateway VM

Distribuisci la VM su Hyper-V o ESXi

Per un gateway locale o una VM gateway, la macchina virtuale viene creata per prima.

Impostazioni tipiche:

  • Generazione 1 per Hyper-V.
  • 2 processori virtuali come valore iniziale.
  • 4 GB di RAM come valore iniziale.
  • Rete nella propria VLAN o segmento gateway.
  • Hyper-V: utilizza i file .vhdx scaricati.
  • ESXi: utilizza il file OVA.

La VM non deve essere avviata finché non viene creata l’immagine ISO con le impostazioni del gateway. Questa ISO connette successivamente la VM al tenant di Sophos Central e alle impostazioni del gateway.

Impostazioni del gateway in Sophos Central

Il gateway viene quindi aggiunto e configurato in Sophos Central.

Campi importanti:

  • Moda: Scegli consapevolmente il gateway on-premise o il gateway cloud Sophos.
  • Nome: Utilizza posizione, scopo o nome host.
  • Posizione: Facoltativo, ma utile con più gateway.
  • Nome di dominio completo: Per il gateway locale, il nome DNS pubblico che punta al firewall o all’IP del gateway.
  • Dominio: Dominio corrispondente al certificato e alle risorse.
  • Tipo di piattaforma: VMware ESXi, Hyper-V, AWS o variante del firewall Sophos supportata a seconda della modalità.
  • Fornitore di identità: Seleziona il provider di identità configurato in precedenza.
  • Modalità di distribuzione dell’istanza gateway: A un braccio per scenari DNAT semplici, a due bracci per progettazione WAN/LAN separata.
  • Indirizzo IP: Preferire un indirizzo IP statico o riservato per i gateway produttivi.
  • Certificato: Utilizzare caratteri jolly o certificato gateway appropriato.

One-arm è spesso più semplice perché viene utilizzata un’unica interfaccia per il traffico in entrata e in uscita. Due bracci separano i lati WAN e LAN, ma richiedono due interfacce e una progettazione di rete più chiara.

Dopo il salvataggio, Sophos Central crea un’immagine ISO con le informazioni sul gateway. Questa ISO viene assegnata alla VM come ISO di avvio.

A seconda delle prestazioni e dell’ambiente dell’host, l’avvio iniziale e la registrazione con Sophos Central potrebbero richiedere del tempo. Non appena il gateway risponde, può essere accettato in Central.

Configurazione di Sophos ZTNA Gateway
Aggiungere Sophos Central - Gateway ZTNA
Impostazioni di Sophos ZTNA Gateway
Sophos Central - Immettere i dati di base del gateway
Impostazioni di distribuzione di Sophos ZTNA Gateway
Selezionare Sophos Central - Modalità di distribuzione gateway
Impostazioni ISO di Sophos ZTNA Gateway
Scarica Sophos Central - Gateway ISO con le impostazioni

Controllare dopo l’avvio

Dopo la registrazione il gateway non è automaticamente pronto per la produzione. Solo questi test mostrano se il progetto funziona:

  • Stato del gateway: Gateway è online in Sophos Central e mostra una versione plausibile.
  • DNS pubblico: Gli FQDN o i CNAME del gateway puntano alla destinazione prevista.
  • Certificato: Il browser e il client ZTNA considerano attendibile il certificato.
  • Risoluzione DNS interna: Il gateway può risolvere correttamente le risorse interne.
  • Regole del firewall: Il gateway raggiunge solo le applicazioni e le porte di cui ha bisogno.
  • DNAT in sede: La porta 443 soddisfa la regola NAT e firewall prevista.
  • Prova utente: Un gruppo pilota può ottenere esattamente le risorse pianificate.
  • Registri: I registri del gateway, centrale e del firewall mostrano eventi tracciabili.

Se ZTNA venisse introdotto come alternativa alla VPN, un progetto pilota non dovrebbe essere testato solo con un sito Web di esempio. Le applicazioni target reali sono migliori: portale web interno, salto RDP/SSH, applicazione specializzata o accesso ai file, a seconda dell’uso previsto.

Errori tipici

  • Il DNS pubblico mostra falso: Gli utenti non possono raggiungere il gateway. A/CNAME, TTL, controlla la risoluzione esterna.
  • Manca la risoluzione DNS interna: Il login funziona, la risorsa non si apre. Seleziona DNS privato, FQDN della risorsa o IP di destinazione.
  • Il certificato non è adatto: Avviso browser o client. Controlla jolly, SAN, catena e dominio.
  • DNAT manca dal gateway locale: Il gateway rimane inaccessibile dall’esterno. Controlla la regola NAT, la porta 443, l’IP WAN e il visualizzatore registro.
  • Al gateway non è consentito raggiungere l’applicazione: La risorsa rimane offline o va in timeout. Controlla le regole del firewall dal segmento gateway alla destinazione.
  • Modifiche all’indirizzo DHCP: ZTNA fallisce dopo il riavvio. Utilizza indirizzo IP riservato o statico.
  • Gruppo utenti troppo ampio: Troppe risorse visibili. Assegnare più attentamente gruppi, politiche e risorse.
  • Cloud Gateway con PoP errato: latenza evidente. Scegli un punto di presenza vicino al data center.

Per l’analisi delle regole e del NAT su Sophos Firewall Testa le regole del firewall con Log Viewer, Policy Test e Packet Capture e Comprendere il NAT su Sophos Firewall saranno utili.

Lista di controllo operativa

  • Modalità gateway documentata.
  • DNS pubblico e DNS privato testati.
  • Certificato valido e rinnovabile.
  • Gateway operava nel proprio segmento.
  • DNAT configurato solo per il gateway locale.
  • Le regole del gateway per le risorse interne sono strettamente limitate.
  • Definiti utenti pilota e risorse pilota.
  • Registri, proprietario e processo di supporto chiariti.
  • Finestre di aggiornamento e manutenzione del gateway pianificate.
  • Piano di smantellamento in atto se il pilota non funziona.

Domande frequenti

Hai sempre bisogno di una VM gateway per Sophos ZTNA?

Non sempre. I gateway on-premise e i Sophos Cloud Gateway possono essere eseguiti come VM su ESXi o Hyper-V. Sophos Cloud Gateway può essere implementato anche su dispositivi firewall Sophos gestiti centralmente.

La porta 443 deve sempre essere pubblicata tramite DNAT?

No. Ciò è particolarmente rilevante per i gateway locali quando gli utenti accedono direttamente al proprio gateway. Con Sophos Cloud Gateway, la voce pubblica è strutturata in modo diverso e funziona con Sophos Cloud e CNAME.

Sophos ZTNA può sostituire qualsiasi VPN?

Non automaticamente. ZTNA è particolarmente adatto per applicazioni definite e accesso basato sulle risorse. L’accesso VPN classico può ancora avere senso per determinati protocolli amministrativi, di rete o speciali. La decisione dipende dal caso d’uso.

Perché il DNS è così importante per ZTNA?

ZTNA controlla l’accesso tramite gateway, risorse e talvolta nomi alias. Quando i record DNS pubblici o privati ​​puntano in modo errato, il problema spesso sembra un errore del gateway, del certificato o della policy.