Configurando o Sophos ZTNA: visão geral e pedido
O Sophos Zero Trust Network Access, ZTNA abreviadamente, não substitui simplesmente uma VPN por um novo botão. ZTNA consiste em identidade, gateway, recursos, políticas, DNS, certificados e um caminho de acesso de cliente ou sem agente. Se esses blocos de construção forem configurados na ordem errada, o login poderá funcionar, mas o aplicativo ainda permanecerá inacessível.
Este artigo classifica a configuração e mostra a ordem sensata. Planejar e criar o Sophos ZTNA Gateway também é adequado para a parte específica do gateway.
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.
Requisitos
Antes de um teste ZTNA, estes pontos devem ser esclarecidos:
- Conta Sophos Central com licença ZTNA apropriada ou ambiente de teste.
- Microsoft Entra ID, anteriormente conhecido como Azure AD, ou um provedor de identidade compatível com usuários e grupos mantidos.
- Decisão entre acesso sem agente, cliente ZTNA ou operação mista.
- Modelo de gateway: On-premise Gateway, Sophos Cloud Gateway ou Sophos Firewall como variante de gateway.
- Nomes DNS para gateway e recursos publicados.
- Certificado curinga ou conceito de certificado correspondente.
- Acessibilidade interna das aplicações na perspectiva do gateway.
- Proprietário de políticas, certificados, logs e alterações subsequentes.
Habilitar Sophos Central ZTNA
Se o ZTNA ainda não estiver ativo, o teste poderá ser preparado usando uma conta Sophos Central existente ou nova. É importante que o inquilino, a origem do utilizador e os recursos subsequentes correspondam ao teste planeado. Um teste ZTNA sem um aplicativo de destino real diz pouco sobre latência, DNS, experiência do navegador ou design de políticas.
Começar pela página de testes do Sophos pode ser útil para ambientes de laboratório iniciais: Crie uma conta de teste do Sophos Central.

Certificado do plano e DNS
ZTNA requer um certificado que corresponda ao gateway planejado e aos domínios de recursos. Em muitos ambientes, um certificado curinga é a opção mais simples porque vários recursos podem ser publicados no mesmo domínio.
Para ambientes produtivos, deverá esclarecer o prazo de validade, renovação, responsabilidade e acompanhamento do certificado. Let’s Encrypt pode ser útil para testar se ainda não existe um certificado curinga adequado. O processo está em Criar certificado curinga Let’s Encrypt.
Ordem de configuração
Para uma implementação limpa do ZTNA, a ordem não deve ser escolhida arbitrariamente:
- Adicionar serviço de diretório: Sincronize o Microsoft Entra ID ou outro serviço de diretório compatível com o Sophos Central.
- Adicionar provedores de identidade: configure os provedores de identidade necessários para autenticação.
- Adicionar gateway: planeje e implante o modelo de gateway apropriado para cada local ou caminho de dados.
- Crie recursos: Defina aplicações com FQDN, porta, tipo de acesso e acessibilidade.
- Adicione políticas: atribua conscientemente grupos de usuários, condições e recursos permitidos.
- Teste o acesso do cliente ou sem agente: verifique com os usuários piloto se o login e o aplicativo funcionam.

1. Sincronize usuários
Para ZTNA, o Sophos Central precisa de usuários e grupos que serão usados posteriormente em políticas. Em ambientes Microsoft, o Microsoft Entra ID é o ponto de entrada típico. É crucial que apenas os grupos necessários sejam usados e que nomes, UPN, endereços de e-mail e membros de grupos possam ser rastreados posteriormente.
A base está em Adicionar Sophos Central Azure AD.
2. Adicione provedor de identidade
Após o serviço de diretório, o provedor de identidade é configurado. Para o Microsoft Entra ID, normalmente incluem ID do cliente, ID do locatário e Segredo do cliente. Esses valores são dados de configuração relevantes para a segurança e devem ser tratados como dados de acesso.

3. Adicionar gateway
O ZTNA Gateway conecta o acesso do usuário a aplicativos internos. Dependendo do design, ele funciona como um gateway local em sua própria rede, é operado através do Sophos Cloud Gateway ou usa uma variante de firewall Sophos compatível.
O planejamento do gateway é uma etapa de trabalho separada porque DNS, certificado, segmento de rede, DNAT, acessibilidade interna e logs precisam se encaixar. O processo está em Planejar e criar o Sophos ZTNA Gateway.
4. Crie recursos
Recursos são os aplicativos que devem estar acessíveis via ZTNA. Para fazer isso, você deve documentar o seguinte para cada aplicativo:
- FQDN interno ou IP de destino interno,
- protocolo e porta,
- Tipo de acesso, por exemplo, aplicativo web ou aplicativo TCP,
- grupo de usuários necessário,
- nome externo desejado,
- Teste os critérios de usuário e aceitação.
Um recurso não deve ser publicado mais amplamente do que o necessário. Especialmente com ferramentas administrativas, RDP, SSH ou aplicativos especializados internos, você precisa de grupos claros, registro e um proprietário.
5. Adicione políticas
As políticas conectam grupos de usuários a recursos. Na prática, você deve começar com um pequeno grupo piloto e não ativar imediatamente departamentos inteiros ou todos os funcionários.
Boas questões políticas:
- Qual grupo realmente precisa deste aplicativo?
- O acesso sem agente é suficiente ou o cliente ZTNA é necessário?
- O acesso precisa ser restrito por dispositivo, condição ou localização?
- Como é feito o registro e quem verifica as tentativas malsucedidas?
- Existe um caminho alternativo se o ZTNA ou o provedor de identidade for interrompido?
6. Teste o acesso
Após a configuração, não é apenas o login que deve ser testado. O que é crucial é saber se a aplicação real pode ser alcançada e se a política funciona exactamente como planeado.
Pontos de verificação:
- O usuário de teste está no grupo correto.
- O DNS aponta para o gateway esperado ou CNAME.
- O certificado é aceito sem aviso do navegador.
- O registro no provedor de identidade funciona.
- O recurso é aberto com o tipo de acesso planejado.
- Usuários não autorizados são claramente rejeitados.
- Os logs no Sophos Central, Gateway e Firewall podem ser avaliados.
Erros comuns
- Gateway, DNS e certificado só são verificados após as políticas.
- Os recursos são publicados de forma muito ampla.
- Os usuários de teste têm mais associações a grupos do que usuários regulares.
- A resolução interna de DNS funciona apenas na LAN, mas não da perspectiva do gateway.
- O ZTNA está planejado para substituir qualquer conexão VPN ou administrativa, embora alguns casos especiais ainda possam exigir VPN, Jump Host ou outro modelo de acesso.