Filtragem DNS para MSPs e propriedades multi-site

O filtragem de DNS para MSPs e propriedades com vários locais verifica solicitações de domínio em relação a políticas de segurança na nuvem antes que os dispositivos se conectem. Gerenciado centralmente por meio da Purple junto com SSIDs, portais captivos e análises, ele não requer hardware no local. Operando em integrações como Cisco Meraki e HPE Aruba, a Purple protege propriedades de rede que cobrem mais de 80.000 locais ativos sem a necessidade de agentes.

O que é filtragem de DNS para MSPs e propriedades com vários locais?

Toda conexão que um dispositivo faz começa com uma busca de DNS (Domain Name System). O dispositivo pede a um resolvedor para transformar um nome como exemplo.com em um endereço IP. A filtragem de DNS, também chamada de DNS protetivo, verifica esse nome em relação a uma política antes de responder. Se o domínio for malicioso ou estiver fora da política, o resolvedor retém o endereço real. O dispositivo nunca abre uma conexão, portanto nada é baixado e nenhuma página é carregada.

Para um único local, esse é um controle útil. Para um provedor de serviços gerenciados (MSP) ou uma equipe de TI com vários locais, o requisito muda de forma. Você filtra dezenas ou centenas de redes, pertencentes a clientes diferentes, com regras diferentes, em hardwares diferentes. Isso traz três requisitos que um filtro de local único raramente atende:

• Política por locatário. Um locatário é um cliente ou unidade de negócios com suas próprias regras. Um grupo de hotéis familiares, uma rede de pubs e um consultório médico nunca devem compartilhar a mesma política.
• Gerenciamento central. Você precisa ver e alterar a política de cada locatário a partir de um único local, sem fazer login em cada site.
• Sem hardware por local. Enviar, montar em rack e atualizar um dispositivo em cada local não é escalável em toda uma frota.

Shield é o complemento de DNS protetivo da Purple, ao lado do SecurePass e do Verify. A filtragem roda na nuvem e se vincula aos SSIDs (nomes de rede), Captive Portals e análises que você já gerencia para cada cliente. Um Captive Portal é a página de login que um visitante vê antes de ficar online.

Como a filtragem para MSPs difere de uma implantação em local único

Um filtro de local único tem uma política, um administrador e uma rede. Uma propriedade de MSP tem uma hierarquia. Você define regras para a propriedade, substitui-as por cliente e, em seguida, as varia por rede dentro de um local. A rede de convidados de um hotel precisa de regras diferentes da rede de funcionários atrás da recepção.

Filtros de DNS independentes normalmente lidam com isso por meio de uma suborganização por locatário, configurada separadamente da própria rede WiFi. Você acaba executando duas pilhas para cada cliente: uma para a rede e o portal, e outra para o resolvedor. O Shield elimina a segunda pilha, porque a política de filtragem segue as redes que você já definiu na Purple.

Por que a filtragem de DNS é importante em uma frota de locais de clientes?

Três pressões impulsionam a filtragem na agenda de um MSP: dever de diligência, exposição a ameaças e largura de banda limitada.

Dever de diligência em redes compartilhadas

O WiFi público e para convidados traz obrigações reais. Na Inglaterra, escolas e faculdades seguem os padrões de filtragem e monitoramento do Departamento de Educação, referenciados no Keeping children safe in education. Nos EUA, a Lei de Proteção Infantil na Internet (CIPA) exige que escolas e bibliotecas que recebem financiamento do E-rate realizem a filtragem. Hotéis, cafés e centros de lazer que recebem famílias enfrentam riscos de reputação se uma criança acessar conteúdo adulto. O programa Friendly WiFi do Reino Unido existe exatamente por esse motivo.

Quando você gerencia WiFi para 40 clientes, você carrega uma parcela de cada obrigação. Um site não filtrado é uma conversa com o cliente que você não quer ter.

Ameaças que atingem dispositivos não gerenciados

Você não pode instalar um agente no telefone de um visitante e não pode atualizá-lo. Links de phishing, downloads de malware e retornos de chamada de comando e controle começam com uma busca DNS. Isso torna a busca o único ponto que você controla para cada dispositivo na rede.

O Shield sinaliza ameaças na etapa de busca DNS, bloqueando solicitações maliciosas antes que as conexões sejam concluídas. Em toda uma frota, um bloqueio de ameaça é aplicado em todos os sites de clientes no mesmo instante. Para uma visão mais ampla do mercado, consulte Phishing Protection Software: 10 Options for Shared WiFi.

Largura de banda em locais limitados

Muitos locais executam WiFi para convidados em conexões modestas: um roteador 4G em um posto de combustível, uma linha compartilhada em um pub, um circuito movimentado em uma estação. O tráfego de anúncios e o conteúdo web indesejado competem com todo o resto. Filtrar anúncios e domínios maliciosos na camada DNS reduz o consumo de dados da rede e melhora as velocidades de carregamento. Em um local congestionado, essa folga é devolvida ao tráfego que os convidados realmente vieram buscar.

O que um firewall deixa passar

Um firewall ainda é importante, mas funciona em um ponto diferente. Ele inspeciona conexões depois que o DNS já respondeu. Isso deixa quatro lacunas em uma rede de convidados multisite:

1. A criptografia oculta o destino. O TLS 1.3 (RFC 8446) criptografa o certificado do servidor. O Encrypted Client Hello (ECH), uma extensão IETF para TLS, também pode ocultar o nome do servidor. Sem descriptografia, um firewall vê um endereço IP e pouco mais, e você não pode instalar um certificado de descriptografia no dispositivo de um visitante.
2. Endereços IP compartilhados confundem as regras. As redes de entrega de conteúdo hospedam muitos domínios nos mesmos endereços. Bloqueie o IP e você interromperá sites legítimos; permita-o e o domínio nocivo passará.
3. Os conjuntos de regras por local se desalinham. Uma frota construída ao longo dos anos mistura fornecedores de firewall e versões de firmware. Manter 60 conjuntos de regras alinhados é um trabalho em tempo integral, e um local esquecido é a lacuna.
4. O bloqueio chega tarde. Quando o firewall age, o dispositivo já resolveu o nome e tentou uma conexão. A filtragem DNS interrompe a solicitação antes que qualquer conexão exista.

A filtragem DNS fecha essas lacunas sem descriptografia, agentes ou regras por local. Ela não substitui a função do firewall de segmentar redes e controlar portas.

Como a filtragem DNS funciona em múltiplos locatários?

O que acontece durante cada busca

1. Um convidado se conecta ao WiFi do cliente, geralmente por meio de um Captive Portal.
2. O dispositivo solicita um domínio, por exemplo, a partir de um link em um e-mail de phishing.
3. O Shield verifica o domínio em relação à política atribuída àquela rede.
4. Se o domínio for permitido, o dispositivo recebe o endereço e se conecta normalmente.
5. Se for bloqueado, a busca não retorna o endereço real, portanto, nenhuma conexão é aberta.

Como estruturar a política por locatário (per-tenant)

O filtro de conteúdo por locatário funciona melhor como um pequeno conjunto de políticas padrão, e não como um conjunto de regras sob medida por local. Esse padrão se mantém em setores como hotelaria, varejo e setor público:

• Linha de base de segurança. Malware, phishing e outras categorias de ameaças bloqueadas em todas as redes, para todos os locatários. Ninguém fica de fora.
• Convidado familiar. A linha de base mais conteúdo adulto e impróprio para a idade. Ideal para hotéis familiares, bibliotecas, centros de lazer, escolas e salas de espera de atendimento à saúde.
• Convidado adulto. A linha de base com regras de conteúdo mais flexíveis. Ideal para bares, locais noturnos e hotéis de negócios.
• Equipe. A linha de base mais as regras que refletem a política de uso aceitável de cada cliente.

Atribua uma política por rede e adicione exceções de clientes apenas onde uma empresa precisar delas. A equipe de marketing de um hotel pode precisar de plataformas sociais que uma escola bloquearia. Quatro políticas e uma curta lista de exceções são muito mais fáceis de auditar do que 60 conjuntos de regras criados manualmente.

Como o Shield vincula a política às redes que você executa no Purple, os SSIDs de convidados e de funcionários de um local podem ter políticas diferentes. As redes de funcionários que usam IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta, mantêm seus controles de identidade. O Shield adiciona a camada de DNS por cima.

Gerenciando uma frota a partir de um único painel

O gerenciamento centralizado de políticas de DNS só vale a pena se corresponder à sua forma de trabalho atual. O Shield fica na mesma plataforma Purple que executa os SSIDs, Captive Portals e análises de cada cliente. Você não precisa alternar entre consoles para alterar um filtro nem precisa manter um segundo inventário de locais.

Isso traz consequências práticas para um MSP:

• Integração (Onboarding). Um novo local de cliente no Purple não precisa de uma conta de resolvedor separada.
• Controle de alterações. Altere uma política uma vez e ela se aplicará a todas as redes atribuídas a ela.
• Relatórios. A atividade de filtragem fica ao lado das análises de conexão que você já compartilha, para que uma única revisão trimestral cubra WiFi e segurança.

Por que não há nada para enviar/instalar

O Shield filtra na nuvem, portanto, não há dispositivo físico para comprar, configurar, enviar ou substituir em cada local. O Purple é agnóstico em relação ao hardware e roda como uma sobreposição em nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Uma estrutura de clientes que combina diferentes fornecedores após aquisições ainda executa um único conjunto de políticas. A configuração varia de acordo com o fornecedor, portanto, siga a documentação de suporte do Purple para o seu hardware.

O Purple já opera em mais de 80.000 locais ativos e registrou 440 milhões de logins em 2024 (dados do Purple).

Como é o filtro de DNS em uma propriedade real?

Os três cenários abaixo são composições baseadas em estruturas comuns de instalações. O número de locais e o hardware são típicos; os resultados representam a matemática operacional de cada mudança.

Cenário 1: um MSP com 14 clientes do setor de hospitalidade

Situação. Um MSP gerencia WiFi para convidados e funcionários de 14 clientes de hospitalidade em 60 locais. O mix inclui hotéis independentes, um grupo de 20 pubs e um parque de férias. O WiFi e os Captive Portals já funcionam com a Purple. O filtro rodava em um serviço de DNS separado, com uma conta e uma lista de locais por cliente.

O que foi feito. O MSP migrou a filtragem para o Shield e substituiu 14 conjuntos de regras personalizados pelas quatro políticas padrão. Hotéis familiares e o parque de férias adotaram a política para público familiar; o grupo de pubs adotou a política para público adulto. Dois clientes mantiveram listas curtas de exceções.

Resultado. Zero hardware enviado e zero visitas presenciais em 60 locais. O MSP descontinuou 14 contas de filtragem separadas e agora gerencia todos os clientes a partir do painel da Purple que já utilizava. Uma alteração de regra significa editar uma de quatro políticas, e não até 60 entradas de locais.

Cenário 2: bibliotecas e centros de lazer de um conselho municipal

Situação. Um conselho municipal oferece WiFi público em 22 bibliotecas e cinco centros de lazer. As crianças usam as redes das bibliotecas após o horário escolar. Duas rodadas de aquisição resultaram em HPE Aruba nas bibliotecas e Ubiquiti UniFi nos centros de lazer. A equipe de TI é composta por três pessoas.

O que foi feito. O conselho aplicou a política para público familiar a todos os SSIDs públicos e a política de funcionários às redes corporativas. A autenticação de funcionários permanece em 802.1X com WPA3-Enterprise, o padrão atual de criptografia WiFi empresarial. Os visitantes ainda se conectam por meio do Captive Portal do conselho.

Resultado. Todos os 27 locais executam uma única política pública em dois fornecedores de hardware diferentes, sem nenhum dispositivo físico adicional. Uma única edição é aplicada a todos os 27 locais. O conselho apresenta aos auditores uma política e uma fonte de log, em vez de 27 configurações locais.

Cenário 3: uma rede de varejo com 120 lojas e conexão de backhaul limitada

Situação. Uma rede de varejo oferece WiFi de convidados para clientes em 120 lojas, sendo um terço delas conectadas via backhaul 4G. A navegação dos clientes compete com os sistemas das lojas por largura de banda. O ambiente de dados dos portadores de cartão já está segmentado do tráfego de convidados para mantê-lo fora do escopo do PCI DSS.

O que foi feito. A rede de varejo ativou a proteção contra ameaças e o bloqueio de anúncios do Shield apenas no SSID de convidados. O projeto começou com um piloto de 10 lojas nos locais de 4G mais movimentados. As redes de funcionários e dos sistemas das lojas permaneceram em seus próprios segmentos.

Resultado. O piloto mediu seu próprio uso antes e depois ao longo de quatro semanas, demonstrando uma redução no consumo geral de dados em conexões limitadas. Em seguida, a rede de varejo estendeu a política para todas as 120 lojas em uma única alteração, sem a necessidade de visitas presenciais.

Onde a filtragem de DNS se posiciona junto ao que você já executa?

O DNS de proteção é uma das camadas. Ele funciona melhor quando combinado com os controles que você provavelmente já possui.

• Segmentação. VLANs (LANs virtuais, que dividem uma rede física em redes lógicas isoladas) mantêm o tráfego de visitantes separado dos funcionários e sistemas de pagamento. Veja Como configurar a segmentação de rede para visitantes e funcionários.
• Autenticação. 802.1X com RADIUS, o protocolo que verifica credenciais em um servidor central, decide quem se conecta à rede de funcionários. O mesmo faz o SecurePass com Microsoft Entra ID, Okta ou Google Workspace. O Shield decide para onde os dispositivos podem ir após a conexão.
• Firewalls. Seu firewall ainda controla portas, protocolos e tráfego entre segmentos. O Shield bloqueia destinos maliciosos conhecidos no momento da consulta.
• Legislação de privacidade. Logs de DNS podem conter endereços IP e identificadores de dispositivos, que o GDPR trata como dados pessoais. A Purple está em conformidade com o GDPR e é certificada pela ISO 27001.

Como o Shield se compara ao DNSFilter e ao Cisco Umbrella

O DNSFilter e o WebTitan focam fortemente em MSPs, e o Cisco Umbrella é o padrão em muitas infraestruturas Cisco. Todos eles filtram na camada de DNS na nuvem. As diferenças estão em quem gerencia o quê e onde.

Critério	Purple Shield	DNSFilter	Cisco Umbrella
Onde ocorre a filtragem	Consulta de DNS, na nuvem da Purple	Consulta de DNS, na nuvem do DNSFilter	Consulta de DNS, na nuvem da Cisco
Hardware por local	Nenhum	Nenhum para filtragem de rede	Nenhum para proteção na camada de DNS
Gerenciamento de locatários	Dentro do painel da Purple que executa o WiFi do cliente	Console de MSP separado com suborganizações	Console multi-org ou MSP separado
Vinculado a SSIDs, Captive Portals e analíticos de WiFi	Sim, nativo da plataforma de WiFi	Não, configurado como uma pilha separada	Integra-se ao Cisco Meraki, gerenciado em seu próprio console
Dispositivos em roaming fora do local	Desenvolvido para dispositivos no WiFi que você opera	Agente de cliente em roaming	Módulo de roaming do Cisco Secure Client
Cobertura de hardware	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks, Fortinet	Qualquer rede capaz de encaminhar DNS para seus resolvedores	Qualquer rede capaz de encaminhar DNS para seus resolvedores, mais profundo com Cisco
Mais indicado para	MSPs cujos clientes usam WiFi executado na Purple	MSPs que protegem endpoints gerenciados dentro e fora do local	Infraestruturas padronizadas em segurança Cisco

As alternativas são fortes onde o Shield não compete. O DNSFilter e o Cisco Umbrella oferecem agentes de roaming para notebooks gerenciados fora do local. O Umbrella também faz parte do portfólio de segurança mais amplo da Cisco. O WebTitan, da TitanHQ, também oferece um filtro em nuvem multilocatário para MSPs. Se os seus contratos cobrem endpoints corporativos onde quer que eles estejam, uma dessas opções pode ser adequada.

O argumento do Shield é mais focado e, para MSPs orientados a WiFi, mais sólido. Se você gerencia os SSIDs, Captive Portals e analíticos de cada cliente no Purple, uma pilha de resolvedores separada por cliente gera custos operacionais desnecessários. Para obter mais detalhes, leia Shield vs DNSFilter: uma comparação de DNS de proteção para operadores de WiFi e Shield vs Cisco Umbrella: escolhendo o DNS de proteção para WiFi de visitantes.

Quais são os limites da filtragem de DNS que você deve conhecer?

A filtragem de DNS atua em um ponto específico da conexão, e isso define seus limites.

• O DNS criptografado pode burlá-la. O DNS over HTTPS (DoH, RFC 8484) e o DNS over TLS (DoT, RFC 7858) permitem que um dispositivo escolha seu próprio resolvedor. Controles de rede podem reduzir isso em dispositivos não gerenciados, mas não podem eliminá-lo. Consulte DNS over HTTPS explicado: privacidade vs filtragem de WiFi público.
• VPNs criam túneis que a ultrapassam. Um visitante usando uma VPN pessoal resolve nomes dentro do túnel. Você pode bloquear domínios de VPN conhecidos, mas não todos eles.
• Conexões diretas por IP ignoram o DNS. Softwares maliciosos que acessam um endereço IP rígido no código nunca fazem uma consulta DNS. O seu firewall cobre esse caso.
• Ela visualiza domínios, não conteúdos. A filtragem de DNS permite ou bloqueia um domínio inteiro, não páginas ou arquivos individuais.
• As categorias precisam de revisão. Qualquer lista de categorias pode, em algum momento, bloquear em excesso ou de menos. Forneça a cada cliente um contato designado e um fluxo para solicitar alterações.
• Os registros precisam de governança. Defina a retenção e o acesso por cliente antes da implantação e registre isso no seu contrato de processamento de dados.

O que você deve fazer a seguir?

1. Mapeie seus clientes. Liste cada cliente, local e rede, juntamente com o setor vertical e as obrigações regulatórias, como escolas, bibliotecas, serviços de saúde e estabelecimentos licenciados.
2. Elabore políticas padrão. Comece com as quatro mencionadas acima e mantenha a linha de base de segurança como obrigatória.
3. Realize projetos-piloto em locais representativos. Escolha um local por setor vertical, incluindo um com conexão de backhaul limitada, e meça o uso de dados antes e depois.
4. Implante por política, não por local. Atribua políticas às redes de cada cliente e revise as exceções após 30 dias.
5. Apresente relatórios. Adicione a atividade de filtragem às revisões de WiFi que você já entrega.

Se o WiFi dos seus clientes ainda não roda no Purple, comece com o Guest WiFi e adicione o Shield. Para saber mais sobre como proteger redes em diferentes propriedades, navegue por Todos os guias.

Perguntas frequentes

Preciso instalar hardware no local de cada cliente para usar a filtragem de DNS?

Não. O Shield filtra na camada de DNS na nuvem, portanto não há dispositivo físico para comprar, configurar ou enviar para qualquer local. O Purple funciona como uma sobreposição em nuvem nos pontos de acesso que seus clientes já possuem, incluindo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A configuração varia de acordo com o fornecedor, portanto siga a documentação de suporte do Purple para cada tipo de hardware em sua estrutura.

Posso definir políticas de filtragem diferentes para cada cliente e cada rede?

Sim. O Shield vincula a política de filtragem às redes que você já executa no Purple, para que cada cliente, e cada SSID dentro de um local, possa ter sua própria política. A rede de convidados de um hotel pode bloquear conteúdo adulto, enquanto a rede de funcionários aplica as regras de uso aceitável do cliente. Um pequeno conjunto de políticas padrão, somado a curtas listas de exceções, é mais fácil de auditar do que regras personalizadas por local.

Posso gerenciar a filtragem de conteúdo para vários locais a partir de um único painel?

Sim. O Shield é gerenciado na mesma plataforma Purple que executa os SSIDs, Captive Portals e analíticos dos seus clientes, para que você altere a filtragem sem trocar de console. Uma alteração de política se aplica a todas as redes atribuídas a essa política, em todos os locais. A atividade de filtragem fica ao lado dos seus relatórios de WiFi existentes, para que uma única revisão de cliente cubra conectividade e segurança juntas.

Como o Shield se compara ao DNSFilter para um MSP?

O Shield é ideal para MSPs cujos clientes já executam WiFi no Purple, enquanto o DNSFilter atende MSPs que protegem notebooks gerenciados dentro e fora da empresa. Ambos filtram na camada de DNS na nuvem sem hardware por local. O DNSFilter funciona como um console multitenant separado com um agente itinerante. O Shield roda dentro da plataforma de WiFi, vinculado aos mesmos SSIDs, Captive Portals e analíticos que você já gerencia.

Os convidados podem burlar a filtragem de DNS com DNS over HTTPS ou uma VPN?

Sim, um convidado determinado pode. O DNS over HTTPS, DNS over TLS e VPNs pessoais enviam consultas fora do seu resolvedor. Controles de rede podem reduzir isso, por exemplo, bloqueando endpoints conhecidos de VPN e DoH público, mas nenhum filtro de DNS controla totalmente um dispositivo não gerenciado. Trate a filtragem de DNS como a proteção padrão para cada dispositivo que usa o DNS da rede, juntamente com a segmentação e seu firewall.

A filtragem de DNS ajuda escolas e bibliotecas a atender aos requisitos de filtragem?

Ela cobre o elemento de filtragem, mas a filtragem por si só não atende a todos os requisitos. Na Inglaterra, os padrões de filtragem e monitoramento do Departamento de Educação exigem tanto a filtragem quanto o monitoramento, com responsabilidades nomeadas e revisões regulares. Nos EUA, a CIPA exige que escolas e bibliotecas financiadas pelo E-rate usem medidas de proteção tecnológica dentro de uma política de segurança na internet. Combine uma filtragem consistente entre locais com seus processos de monitoramento e salvaguarda.

Como os logs de consulta DNS são tratados sob o GDPR?

O Purple está em conformidade com o GDPR e possui certificação ISO 27001. Os logs de DNS podem incluir endereços IP e identificadores de dispositivos, que o GDPR trata como dados pessoais. Acorde retenção, acesso e finalidade com cada cliente antes da implantação e registre esses termos em seu contrato de processamento de dados. Como MSP, você frequentemente atuará como um operador para seus clientes, portanto, documente quem controla os logs de cada propriedade.

Como o Shield é precificado para uma propriedade com vários locais?

O Shield é um complemento de segurança para a plataforma Purple, ao lado do SecurePass e do Verify, para que você o adicione a locais que já usam a Purple. Não há hardware por local, portanto não há custos de equipamento, envio ou substituição para projetar. Solicite os preços à Purple com base no seu número de clientes e locais, e inclua todos os locais que você planeja integrar este ano.