Planejar e criar o Sophos ZTNA Gateway
Um Sophos ZTNA Gateway conecta usuários a aplicativos internos sem a necessidade do clássico acesso VPN de túnel completo. No entanto, o benefício real só surge quando o modo gateway, DNS, certificado, regras de firewall e acessibilidade interna são devidamente planejados.
Este guia descreve como planejar e criar um gateway ZTNA no Sophos Central. O foco está na parte do gateway. Para a decisão básica entre VPN, ZTNA e outras variantes de acesso remoto, Sophos Connect ou SSL VPN: Qualificação de acesso remoto e um certificado? também se aplica.
Para a base neutra sobre Zero Trust, ZTNA e a diferença para VPN, começar por Zero Trust explicado: ZTNA em vez de VPN clássico.
Entenda os modos de gateway
O Sophos ZTNA pode ser operado com um Gateway local ou um Sophos Cloud Gateway. Ambas as variantes fornecem acesso a recursos internos, mas diferem significativamente na exposição à Internet, DNS, operações e solução de problemas.
- Gateway local: Gateway VM está localizado em seu próprio data center ou rede de site própria VM, próprio DNS público, DNAT na porta 443, controle mais direto.
- Gateway de Nuvem Sophos: Os usuários se conectam via Sophos Cloud Points of Presence. menos exposição direta à Internet, diferentes CNAMEs de DNS, seleção de ponto de presença.
- Sophos Firewall como gateway de nuvem: Sophos Firewall assume a função de gateway para ZTNA Cloud Gateway. nenhuma VM de gateway separada, mas dependência de SFOS, operação central e firewall.
O modo não é apenas uma caixa de seleção técnica. Determina onde o tráfego entra, quem opera o caminho de dados, quais entradas DNS são necessárias e se uma regra DNAT é necessária no firewall.
Gateway local
Com um gateway local, uma VM de gateway é implantada no VMware ESXi ou no Microsoft Hyper-V. O gateway pode ser acessado pela Internet e aceita acesso ZTNA. Na prática, um nome DNS público aponta para o firewall e uma regra DNAT encaminha HTTPS para o gateway.
Vantagens:
- caminho de dados direto para sua própria localização,
- controle total sobre regras de gateway, segmento, DNS e firewall,
- nenhuma dependência do Sophos Cloud Data Plane para o ponto de entrada real.
Desvantagens:
- Gateway VM deve ser operado e atualizado,
- A porta 443 deve ser acessível do exterior,
- Certificado, DNS, DNAT e roteamento interno devem estar corretos,
- A disponibilidade depende da sua localização, conexão com a internet e hipervisor.
Ao publicar um gateway local via DNAT, a regra deve ser planejada com tanto cuidado quanto outras publicações. O básico pode ser encontrado em Servidores Públicos com DNAT no Sophos Firewall.
Sophos Cloud Gateway
Com o Sophos Cloud Gateway, o acesso é gerenciado através dos Sophos Cloud Points of Presence. O componente de gateway interno conecta o Sophos Cloud aos recursos internos. Isso elimina a necessidade de os usuários acessarem diretamente seu próprio IP de gateway público.
Isso reduz a exposição direta à Internet, mas move partes do caminho dos dados para a nuvem Sophos. Portanto, são importantes:
- ponto de presença adequado próximo ao data center,
- corrigir registros CNAME públicos,
- trabalhar na resolução DNS interna,
- expectativas claras em relação à latência, disponibilidade e perfis de tráfego,
- Verificação de licença, produto e limites de tráfego para o ambiente específico.
Para aplicações com uso intensivo de dados, como armazenamento de arquivos grandes, arquivos CAD ou downloads em massa, você não deve apenas testar o ZTNA Cloud Gateway com base no registro. O que importa é como o uso real, a latência e o volume de dados se comportam no dia a dia.
Sophos Firewall como ZTNA Cloud Gateway
Um Sophos Cloud Gateway também pode ser configurado em dispositivos de firewall Sophos gerenciados centralmente. Isto é interessante se já existir um firewall Sophos no local e nenhuma VM de gateway separada for operada.
No entanto, esta variante não deve ser ativada como função secundária. O seguinte deve ser verificado:
- Versão SFOS suportada e status de gerenciamento central.
- Licenciamento ZTNA e mapeamento de usuários.
- Acessibilidade dos recursos internos na perspectiva do firewall.
- Impacto nas janelas de manutenção, atualizações de firmware e funcionamento do firewall.
- Registro e responsabilidade por interrupções. Se o firewall for o nó central de acesso remoto, essa variante pode ser elegante. Por outro lado, se você deseja que o ZTNA seja executado independentemente da manutenção do firewall, uma VM de gateway dedicada ou outro design às vezes é mais limpo.
Requisitos
Antes da implantação, estes pontos devem ser esclarecidos:
- Locatário Sophos Central com licença ZTNA.
- Usuários e grupos sincronizados.
- Provedor de identidade, por exemplo Microsoft Entra ID.
- Escolha entre On-premise Gateway ou Sophos Cloud Gateway.
- Hypervisor ou Sophos Firewall compatível, dependendo do modo.
- DNS público para gateway e recursos.
- Certificado curinga ou conceito de certificado adequado.
- Resolução DNS interna de aplicativos alvo.
- Segmento de rede para o gateway.
- Regras de firewall desde o gateway até as aplicações.
- Proprietário de operações, logs, certificados e alterações posteriores.
Para certificados, um certificado curinga costuma ser a opção mais prática. A obtenção de um certificado curinga está descrita em Vamos criptografar criar certificado curinga. Se os certificados forem gerenciados diretamente no Sophos Firewall, Gerenciar certificados Let’s Encrypt no Sophos Firewall também serve.
Plataforma e dimensionamento
Para VMs de gateway, VMware ESXi e Microsoft Hyper-V são as plataformas típicas. Dependendo do modo e do status do Sophos, outras opções podem ser relevantes. É crucial que a plataforma seja oficialmente suportada, atualizada e devidamente monitorizada.
Para configurações pequenas e médias, uma VM gateway com 2 vCPU e 4 GB de RAM é um ponto de partida realista. Mas isto não substitui o planeamento operacional. Os factores decisivos são o número de utilizadores, recursos, perfil de tráfego, TLS, latência e disponibilidade.
Para ambientes produtivos você também deve planejar:
- Existe um cluster de gateway?
- O gateway funciona em sua própria VLAN?
- Como é feito backup ou restauração da VM?
- Existe monitoramento de hipervisor?
- Quem atualiza o gateway?
- Existe uma janela de manutenção para reinicializações?
Rede e sub-rede
O Gateway ZTNA deve ser operado em sua própria sub-rede ou VLAN. Não deve ser simplesmente colocado em uma rede cliente ou servidor. Um segmento separado facilita regras de firewall, registro, captura de pacotes e solução de problemas posteriores.
Estas redes não devem ser usadas para o gateway:
10.42.0.0/1610.43.0.0/1610.108.0.0/16
Para um gateway local, um nome DNS público, por exemplo ztna.example.com, aponta para o IP público do firewall. O firewall encaminha a porta 443 para o gateway via DNAT. O gateway requer então acesso à Internet e acesso às VLANs ou redes de servidores nas quais os aplicativos publicados estão localizados.
As entradas DNS são diferentes para um Sophos Cloud Gateway. Aí, os CNAMEs tornam-se relevantes para validação de domínios, aliases de gateway e, dependendo do tipo de acesso, aliases de recursos. As entradas DNS públicas devem, portanto, ser verificadas como uma etapa separada antes da implementação.
Decida antes da implantação
Antes de clicar em Add gateway, estas perguntas devem ser respondidas:
- Quais aplicativos são publicados?: O aplicativo Web, o aplicativo TCP e o armazenamento de arquivos têm requisitos diferentes.
- Acesso sem agente ou baseado em agente?: DNS, CNAMEs e experiência do usuário são diferentes.
- Gateway local ou na nuvem?: Decide sobre DNAT, caminho de dados e responsabilidade operacional.
- Quais grupos de usuários têm acesso permitido?: A ZTNA prospera com associações estreitas, não com grupos amplos.
- Como o DNS é resolvido interna e externamente?: Destinos DNS incorretos são uma das fontes mais comuns de erros.
- Qual certificado é usado?: Erros de certificado agem como uma falha de ZTNA para os usuários.
- Quem revisa os registros e as alterações?: Sem um proprietário, a ZTNA rapidamente se torna difícil de sustentar.
Baixe o gateway ZTNA
No Sophos Central, os arquivos da máquina virtual podem ser baixados em Protect Devices no menu principal.
Implante VM no Hyper-V ou ESXi
Para um gateway local ou VM de gateway, a máquina virtual é criada primeiro.
Configurações típicas:
- Geração 1 para Hyper-V.
- 2 processadores virtuais como valor inicial.
- 4 GB de RAM como valor inicial.
- Rede em sua própria VLAN ou segmento de gateway.
- Hyper-V: use arquivos
.vhdxbaixados. - ESXi: Use arquivo OVA.
A VM não deve ser iniciada até que a imagem ISO seja criada com as configurações do gateway. Posteriormente, esse ISO conecta a VM ao locatário do Sophos Central e às configurações do gateway.
Configurações de gateway no Sophos Central
O gateway é então adicionado e configurado no Sophos Central.
Campos importantes:
- Moda: Escolha o gateway local ou o gateway na nuvem Sophos de forma consciente.
- Nome: Use localização, finalidade ou nome de host.
- Localização: Opcional, mas útil com vários gateways.
- FQDN: Para o gateway local, o nome DNS público apontando para o firewall ou IP do gateway.
- Domínio: Domínio correspondente ao certificado e aos recursos.
- Tipo de plataforma: VMware ESXi, Hyper-V, AWS ou variante de firewall Sophos compatível, dependendo do modo.
- Provedor de identidade: Selecione o provedor de identidade configurado anteriormente.
- Modo de implantação da instância de gateway: Um braço para cenários DNAT simples, dois braços para design WAN/LAN separado.
- Endereço IP: Prefira endereços IP estáticos ou reservados para gateways produtivos.
- Certificado: Use curinga ou certificado de gateway apropriado.
O braço único costuma ser mais simples porque uma interface é usada para tráfego de entrada e saída. Dois braços separam os lados WAN e LAN, mas requerem duas interfaces e um design de rede mais claro.
Após salvar, o Sophos Central cria uma imagem ISO com as informações do gateway. Este ISO é atribuído à VM como ISO de inicialização.
Dependendo do desempenho e do ambiente do host, a inicialização e o registro no Sophos Central podem levar algum tempo. Assim que o gateway responder, ele poderá ser aceito na Central.
Verifique após a inicialização
Após o registro, o gateway não estará automaticamente pronto para produção. Somente estes testes mostram se o design funciona:
- Estado da porta de entrada: O Gateway está online no Sophos Central e mostra uma versão plausível.
- DNS público: Gateway FQDN ou CNAMEs apontam para o destino esperado.
- Certificado: O navegador e o cliente ZTNA confiam no certificado.
- Resolução DNS interna: O gateway pode resolver corretamente os recursos internos.
- Regras de firewall: O Gateway alcança apenas os aplicativos e portas de que necessita.
- DNAT no local: A porta 443 atinge a regra esperada de NAT e firewall.
- Usuário de teste: Um grupo piloto pode atingir exatamente os recursos planejados.
- Registros: Os logs de gateway, central e firewall mostram eventos rastreáveis.
Se o ZTNA for introduzido como uma alternativa à VPN, um piloto não deverá ser testado apenas com um site de amostra. Aplicativos de destino real são melhores: portal interno da web, salto RDP/SSH, aplicativo especializado ou acesso a arquivos, dependendo do uso planejado.
Erros típicos
- DNS público mostra falso: Os usuários não conseguem acessar o gateway. A/CNAME, TTL, verifique resolução externa.
- Falta resolução de DNS interno: Login funciona, recurso não abre. Verifique DNS privado, FQDN de recurso ou IP de destino.
- Certificado não cabe: Aviso do navegador ou cliente. Verifique Wildcard, SAN, Cadeia e Domínio.
- DNAT está faltando no gateway local: Gateway permanece inacessível do exterior. Verifique regra NAT, porta 443, IP WAN e visualizador de log.
- O gateway não tem permissão para acessar o aplicativo: O recurso permanece off-line ou expira. Verifique as regras de firewall do segmento de gateway até o destino.
- Alterações de endereço DHCP: ZTNA falha após reinicialização. Use endereço IP reservado ou estático.
- Grupo de usuários muito amplo: Muitos recursos visíveis. Alocar grupos, políticas e recursos de forma mais próxima.
- Cloud Gateway com PoP incorreto: latência perceptível. Escolha um ponto de presença próximo ao data center.
Para análise de regras e NAT no Sophos Firewall Teste regras de firewall com Log Viewer, Policy Test e Packet Capture e Compreendendo o NAT no Sophos Firewall help.
Lista de verificação operacional
- Modo gateway documentado.
- DNS público e DNS privado testados.
- Certificado válido e renovável.
- Gateway operava em segmento próprio.
- DNAT configurado apenas para o gateway local.
- As regras de gateway para recursos internos são estritamente limitadas.
- Usuários piloto e recursos piloto definidos.
- Logs, proprietário e processo de suporte esclarecidos.
- Janelas de atualização e manutenção do gateway agendadas.
- Plano de desmontagem em vigor caso o Piloto não funcione.