Filtragem DNS vs secure web gateway: quando precisa da ferramenta mais pesada

Escolha a filtragem de DNS na resolução ao abrigo do RFC 1035 quando precisar de proteger dispositivos WiFi não geridos em mais de 80 000 locais em 90 países sem instalar hardware. Escolha um secure web gateway quando precisar de inspecionar URLs completos, downloads ou uploads em dispositivos geridos utilizando plataformas como o Microsoft Entra ID. A filtragem de DNS bloqueia destinos maliciosos antes de as ligações se abrirem, enquanto os gateways atuam como proxy e descodificam o tráfego.

Filtragem de DNS vs secure web gateway: a resposta curta

A resposta resume-se a uma pergunta: precisa de ver o interior da ligação ou apenas para onde ela vai?

A filtragem de DNS decide ao nível do nome de domínio. Recusa resolver um destino malicioso ou indesejado, de modo a que o dispositivo nunca se ligue. Um secure web gateway (SWG) é um proxy que se situa no caminho do tráfego. Pode ler o URL completo, o ficheiro e a página, mas apenas após descodificar o TLS.

No WiFi de convidados, a questão resolve-se por si mesma. Não é possível instalar um certificado raiz no telemóvel de um convidado. Sem esse certificado, um gateway não consegue descodificar o tráfego sem causar erros de certificado. A filtragem de DNS protege todos os dispositivos na rede sem ter de instalar nada. É por isso que é a opção predefinida para a hotelaria, retalho, pontos de transporte e eventos.

Nos portáteis geridos da equipa que tratam dados regulamentados, o gateway compensa o seu custo. Precisa dele para inspecionar uploads, aplicar regras em caminhos de URL ou aplicar a prevenção contra a perda de dados (DLP). A DLP impede que dados sensíveis saiam da sua rede.

A maioria dos locais precisa de DNS de proteção em todas as redes e de um gateway numa minoria de dispositivos geridos, caso chegue a precisar de algum. O Purple Shield garante a primeira parte. Funciona de forma autónoma em qualquer WiFi ou em conjunto com o Purple Access, com uma política por rede e VLAN. Para conhecer os limites mais amplos da abordagem por DNS, consulte a nossa vista geral sobre os limites da filtragem de DNS.

O que comparámos e por que razão estes critérios determinam a escolha

Avaliámos ambas as abordagens com base em oito critérios. Cada um deles corresponde a uma decisão que um gestor de segurança TI ou um gestor de operações de um local toma ao definir a filtragem. Extraímos as capacidades de cada opção do seu próprio material público e da implementação de ambas.

A localização vem em primeiro lugar porque molda as outras sete. A filtragem de DNS situa-se na resolução de nomes, a pesquisa definida no RFC 1035. Cada dispositivo pede a um resolvedor um endereço antes de se ligar. Um resolvedor de DNS de proteção verifica o domínio face à inteligência sobre ameaças e à política de categorias, e depois responde ou recusa.

Como essa verificação ocorre antes de qualquer ligação, apanha o que um firewall deixa passar. As regras do firewall baseiam-se em endereços IP e portas. Os domínios maliciosos movem-se através de endereços de nuvem partilhados que um firewall não consegue bloquear com segurança.

Um secure web gateway situa-se mais adiante, dentro da ligação. O tráfego chega até ele através de um agente de endpoint, de um ficheiro de autoconfiguração de proxy (PAC) ou de um dispositivo inline. Para ler HTTPS, o gateway termina o TLS, inspeciona o conteúdo e volta a encriptá-lo. Essa profundidade exige um certificado de raiz confiável em cada dispositivo que inspeciona.

Os oito critérios:

• Posicionamento: em que ponto da ligação o filtro toma a sua decisão.
• Visibilidade: o que o filtro consegue ver, desde o nome do domínio até ao conteúdo da página.
• Dispositivos não geridos: se o tráfego de convidados e BYOD (bring your own device) está coberto.
• Pegada de implementação: o hardware, os agentes e os certificados necessários.
• Desempenho: a latência e a largura de banda que o filtro adiciona.
• Comportamento em caso de falha: o que acontece quando o serviço está inacessível.
• Resistência a evasões: a facilidade com que um dispositivo contorna o filtro, por exemplo através de DNS over TLS (DoT) ou DNS over HTTPS (DoH).
• Pegada de privacidade: a quantidade de dados pessoais que o filtro processa.

No mercado, a fronteira nem sempre é clara. O DNSFilter é um serviço de DNS de proteção, na mesma categoria do Shield. A Cisco Umbrella vende segurança na camada de DNS e, nos seus pacotes mais avançados, um secure web gateway completo, pelo que abrange ambos os lados desta comparação. Quando avaliar qualquer fornecedor, verifique qual a camada que cada pacote oferece em vez de confiar apenas no nome do produto.

Como se comparam a filtragem DNS e uma secure web gateway?

Duas linhas merecem uma leitura mais atenta. Na visibilidade, a gateway vence claramente. Um filtro DNS vê exemplo.com, mas nunca o caminho para um ficheiro nesse site. Explicamos o motivo no artigo porque é que a filtragem DNS não consegue ver URLs completos. Nos dispositivos não geridos, a filtragem DNS vence claramente, porque a cobertura de convidados não requer qualquer certificado nem agente.

As restantes linhas são compromissos que pode gerir. Pode fechar o contorno do DNS encriptado com regras de firewall. A latência da gateway é tolerável num serviço de cloud bem dimensionado. O comportamento em caso de falha depende do produto, e é por isso que apresentamos o do Shield de forma clara: falha fechado.

Onde a filtragem DNS vence

WiFi de convidados e dispositivos não geridos

Todos os dispositivos numa rede WiFi utilizam o servidor DNS fornecido pelo DHCP. Ao apontar esse servidor para um resolutor de proteção, todos os telemóveis, portáteis, consolas de jogos e Smart TVs ficam cobertos. Ninguém precisa de instalar nada. O Captive Portal, a página de início de sessão apresentada antes do acesso à rede, permanece inalterado. À escala, esta é a única forma prática de filtrar convidados, residentes, passageiros e adeptos.

Múltiplos locais, sem novo hardware

Mudar para a filtragem DNS é uma alteração de configuração, não um projeto complexo. O Shield funciona na rede WiFi que já utiliza, incluindo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.Define uma política por rede e por VLAN. Por conseguinte, uma rede de convidados adequada para famílias e uma rede de funcionários no mesmo local podem aplicar regras diferentes. A sua rede de funcionários pode atribuir VLANs por função através do IEEE 802.1X, o padrão de autenticação de rede baseado em portas. Se for o caso, a política de DNS específica por função é aplicada sem necessidade de um proxy.

Bloqueio de ameaças mais antecipado

O DNS deteta a intenção antes de qualquer tráfego fluir. Um dispositivo vítima de phishing precisa de consultar um domínio antes de se poder ligar. O mesmo acontece com um dispositivo infetado que estabelece ligação a um servidor de comando e controlo. O Shield assinala as ameaças mais cedo no seu ciclo de vida, antes de a ligação web se estabelecer. Esse tempo de avanço pode decidir se um domínio de phishing é bloqueado antes do primeiro clique ou depois dele.

Redes mais leves

O bloqueio de anúncios ocorre na mesma camada. Quando ativado, o bloqueio de anúncios reduz a utilização de largura de banda e diminui o volume de consultas de DNS. Numa rede de espaço físico movimentada e com backhaul limitado, essa capacidade é recuperada sem novos investimentos.

Falhas que mantêm a segurança

O Shield utiliza o modo "fail closed", pelo que uma interrupção nunca deixa uma rede sem filtragem. Isto é fundamental em redes de convidados, onde assume o risco reputacional de qualquer conteúdo carregado. Explicamos as vantagens e desvantagens em DNS filtering fail open vs fail closed.

Menor impacto na privacidade

Um filtro DNS processa nomes de domínio, não o conteúdo das páginas. Ao abrigo do GDPR, trata-se de um conjunto mais restrito de dados pessoais do que as sessões de navegação descodificadas. Como resultado, os seus registos de atividades de tratamento permanecem mais simples.

Onde uma gateway web segura se destaca

Seja preciso relativamente aos pontos fortes da gateway. Se presumir que a filtragem de DNS os cobre, o seu programa de segurança terá lacunas reais.

Controlo total do URL e do caminho

Algumas políticas operam abaixo do nível do domínio. Pode querer permitir um serviço de armazenamento na nuvem, mas bloquear uma pasta partilhada específica. Pode querer permitir um site de notícias, mas bloquear as suas páginas de comentários. Apenas um proxy que veja o URL completo pode impor regras como estas. As plataformas partilhadas representam o caso mais difícil, porque um filtro DNS tem de permitir ou bloquear o domínio inteiro.

Inspeção de ficheiros e conteúdos

Uma gateway pode verificar descargas em busca de malware, bloquear tipos de ficheiro e isolar executáveis desconhecidos em sandboxes. A filtragem de DNS interrompe as ligações a domínios maliciosos conhecidos. Um ficheiro malicioso alojado num domínio de confiança continua a passar.

Prevenção de perda de dados

A sua equipa pode manusear dados de cartões de pagamento no âmbito da norma PCI DSS ou registos de pacientes. Se for o caso, poderá ter de inspecionar os carregamentos para detetar conteúdos sensíveis. Isso exige tráfego desencriptado e um gateway ou uma ferramenta dedicada de DLP.

Política por pessoa fora da rede

Um agente de gateway aplica políticas por identidade nomeada, sincronizada a partir do Microsoft Entra ID, Okta ou Google Workspace. Essa política acompanha um portátil gerido para a banda larga de casa ou para o WiFi do hotel. A política do Shield é definida por rede e VLAN, o que se adequa a locais de eventos e instalações fixas. Uma força de trabalho remota em dispositivos geridos pode precisar de aplicação de políticas por pessoa onde quer que se ligue.

Controlos de aplicações

Muitos gateways descodificam o tráfego para aplicações nomeadas. Por exemplo, podem permitir que a equipa leia um serviço de partilha de ficheiros, mas bloquear carregamentos para o mesmo. O filtro DNS pode permitir ou bloquear os domínios de uma aplicação, mas não ações individuais dentro da aplicação.

Se está a ponderar estas lacunas em relação ao seu registo de riscos, leia o filtro DNS é suficiente? para conhecer os controlos que acompanham o DNS de proteção.

Quanto custa executar cada um?

As duas abordagens têm preços diferentes, por isso compare as respetivas estruturas de custos em vez de valores genéricos. Não apresentamos cotações de preços de concorrentes. Confirme os termos atuais com cada fornecedor.

O custo oculto de um gateway reside na gestão de certificados e exceções. As aplicações que fixam os seus certificados (certificate pinning) deixam de funcionar sob inspeção TLS, pelo que cada uma necessita de uma exceção. A maioria das implementações isenta sites bancários e de saúde por razões de privacidade. Cada isenção torna-se uma regra que alguém tem de manter. Os agentes também precisam de ser atualizados em toda a frota de dispositivos. Nada disto é uma falha. É o preço a pagar para ver o tráfego por dentro.

O custo de funcionamento da filtragem de DNS assenta na manutenção de políticas e no controlo de desvios. O utilizador analisa as decisões por categoria e gere os pedidos de permissão. Também mantém atualizadas as regras da firewall para DNS encriptado à medida que surgem novos resolvers públicos.

O que envolve a transição entre a filtragem de DNS e um gateway?

De um proxy para a filtragem de DNS em redes de convidados

Esta é a transição mais comum. É frequente as equipas descobrirem que um proxy no WiFi de convidados filtra pouco mais do que nomes de anfitrião (hostnames), porque não consegue desencriptar o tráfego de convidados. Os passos são:

1. Exporte as suas categorias atuais do proxy e as suas listas de permissões e bloqueios.
2. Mapeie-as para categorias de DNS. As regras baseadas no caminho do URL (URL-path) não têm equivalente em DNS, por isso decida, regra a regra, se vai permitir ou bloquear todo o domínio.
3. Aponte o servidor DNS no escopo DHCP de cada rede para o resolver de proteção.
4. Bloqueie o DNS de saída para outros resolvers, DoT na porta 853 e pontos de extremidade (endpoints) DoH conhecidos.
5. Teste a partir de um dispositivo de convidado real e, em seguida, desative o conjunto de regras do proxy para essa rede.

Os passos de configuração do Shield são abordados em como o Shield funciona. Os padrões de DNS encriptado são a RFC 7858 para DoT e a RFC 8484 para DoH.

Adicionar um gateway para dispositivos geridos

Esta mudança é mais complexa e deve ser delimitada aos dispositivos que dela necessitam. Implante o certificado de raiz através da sua plataforma de gestão de dispositivos móveis (MDM). Implemente o agente ou o ficheiro PAC e, em seguida, crie exceções para aplicações com certificados fixos e categorias sensíveis à privacidade. Conclua uma avaliação de impacto sobre a proteção de dados (DPIA) antes de iniciar a inspeção. Mantenha o Shield ativo em segundo plano, pois continua a cobrir todos os dispositivos que o gateway não abrange.

Executar ambos

A sobreposição dos dois é o design mais robusto em instalações mistas. O Shield bloqueia domínios maliciosos conhecidos no momento da resolução, tanto em redes de convidados como de funcionários. O gateway inspeciona depois o tráfego gerido em detalhe. Como o DNS remove os destinos maliciosos primeiro, menos tráfego hostil chega ao proxy. Alinhe as duas políticas de categorias para que um domínio bloqueado numa camada não seja permitido na outra.

Como decidir entre a filtragem de DNS e um secure web gateway

Utilize esta regra de decisão. Se não for proprietário dos dispositivos, utilize a filtragem DNS. Se for proprietário dos dispositivos e tiver de inspecionar o tráfego, adicione um gateway apenas nesses dispositivos. Em todos os outros casos, o DNS de proteção é a ferramenta à medida.

O seu próximo passo consiste em listar as suas redes e VLANs e assinalar quais as que suportam dispositivos não geridos. Essas redes passam a ter DNS de proteção agora. Em seguida, consulte como funciona o Shield para a implementação. Para controlos mais amplos sobre identidade, encriptação e segmentação, leia o nosso guia de segurança WiFi empresarial.

Perguntas frequentes

A filtragem DNS é mais barata de operar do que um secure web gateway?

Normalmente, sim, porque a filtragem DNS não requer hardware, agentes de ponto final nem gestão de certificados. Um gateway adiciona licenças por utilizador ou dispositivo, manutenção de agentes, renovação de certificados de raiz e regras de exceção para aplicações que falhem com a inspeção. O custo de funcionamento da filtragem DNS limita-se à manutenção de políticas e regras de firewall para DNS encriptado. Compare o custo total de funcionamento em vez das linhas de licenciamento e confirme os termos atuais com cada fornecedor.

O Purple Shield funciona com o hardware WiFi que já possuo?

Sim. O Shield funciona na camada de DNS, por isso é executado em qualquer WiFi, incluindo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Basta apontar o DNS de cada rede para o Shield e definir uma política por rede e VLAN. Funciona de forma autónoma ou juntamente com o Purple Access, sem necessidade de hardware novo no local.

A filtragem DNS pode substituir um secure web gateway?

Pode fazê-lo em redes de visitantes e de locais de acesso público, mas não onde for necessário inspecionar o tráfego. A filtragem DNS bloqueia domínios maliciosos e indesejados antes de qualquer ligação ser aberta, o que cobre a maioria das necessidades de ameaças e conteúdos para visitantes. Não permite aplicar regras a caminhos de URL, verificar ficheiros em domínios de confiança nem inspecionar carregamentos para prevenção de perda de dados. Mantenha um gateway para os dispositivos geridos que necessitem desses controlos.

Posso executar a filtragem de DNS e uma gateway web segura em simultâneo?

Sim, e em locais mistos essa é a arquitetura mais sólida. O Shield filtra todos os dispositivos na resolução de DNS, incluindo os dispositivos de visitantes que uma gateway não consegue inspecionar. A gateway inspeciona depois detalhadamente os dispositivos geridos dos colaboradores. Como o DNS bloqueia primeiro os domínios comprovadamente maliciosos, chega menos tráfego malicioso ao proxy. Mantenha as duas políticas de categorias alinhadas para que um domínio bloqueado numa camada não seja permitido na outra.

Uma gateway web segura funciona no WiFi?

Apenas parcialmente. Sem um certificado de raiz fidedigno no dispositivo, uma gateway não consegue desencriptar HTTPS sem causar erros de certificado. Não é possível instalar certificados nos telemóveis dos visitantes. Ainda assim, uma gateway pode filtrar com base no nome de anfitrião enviado no handshake TLS, o que é semelhante ao que a filtragem de DNS já faz com menos infraestrutura. Para o WiFi, o DNS de proteção é a escolha prática.

O que acontece à filtragem se o serviço de DNS falhar?

Com o Shield, a filtragem permanece ativa. O Shield falha em modo fechado (fail-closed), pelo que uma interrupção nunca deixa a rede sem filtragem. Os serviços que falham em modo aberto (fail-open) encaminham os dispositivos para um resolvedor sem filtragem para manter o tráfego a fluir, o que deixa a rede exposta durante todo o período de interrupção. Solicite a todos os fornecedores que declarem por escrito o seu comportamento em caso de falha e teste-o antes da entrada em funcionamento.

A inspeção TLS é compatível com o GDPR?

Pode ser, mas exige mais governança do que a filtragem de DNS. A desencriptação do tráfego dos colaboradores processa o conteúdo das suas comunicações. Por conseguinte, necessita de um fundamento jurídico, de uma avaliação de impacto sobre a proteção de dados e de um aviso claro aos colaboradores. A maioria das implementações também isenta sites bancários e de saúde. A filtragem de DNS processa apenas nomes de domínio, uma pegada mais reduzida que é mais simples de justificar e documentar.

Quanto esforço exige a transição de um proxy para a filtragem de DNS?

Menos do que a maioria das equipas prevê, porque a transição consiste numa alteração de DNS por rede. O trabalho divide-se em três partes. Mapeia as categorias do proxy para as categorias de DNS, decide o que fazer com as regras de caminho URL que não têm equivalente em DNS e bloqueia o DNS encriptado na firewall. Teste cada rede a partir de um dispositivo real antes de desativar o conjunto de regras antigo.