Filtragem DNS para MSPs e propriedades multi-site

O filtragem de DNS para MSPs e propriedades com vários locais verifica os pedidos de domínio em relação às políticas de segurança na nuvem antes de os dispositivos se ligarem. Gerido centralmente através da Purple juntamente com SSIDs, portais cativos e analítica, não requer qualquer hardware no local. A funcionar em integrações como a Cisco Meraki e a HPE Aruba, a Purple protege propriedades de rede que cobrem mais de 80 000+ locais ativos sem necessidade de agentes.

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

Todas as ligações efetuadas por um dispositivo começam com uma pesquisa de DNS (Domain Name System). O dispositivo pede a um resolvedor para converter um nome como exemplo.com num endereço IP. A filtragem de DNS, também chamada de DNS de proteção, verifica esse nome em relação a uma política antes de responder. Se o domínio for malicioso ou violar a política, o resolvedor retém o endereço real. O dispositivo nunca abre uma ligação, pelo que nada é descarregado e nenhuma página é carregada.

Para um único local, este é um controlo útil. Para um fornecedor de serviços geridos (MSP) ou para uma equipa de TI com vários locais, o requisito muda de forma. Filtra dezenas ou centenas de redes, pertencentes a diferentes clientes, com regras diferentes e em hardware diferente. Isto traz três requisitos que um filtro de local único raramente satisfaz:

• Política por cliente (tenant). Um cliente ou unidade de negócio tem as suas próprias regras. Um grupo hoteleiro familiar, uma cadeia de pubs e um consultório médico nunca devem partilhar a mesma política.
• Gestão centralizada. Precisa de ver e alterar a política de cada cliente a partir de um único local, sem ter de iniciar sessão em cada site.
• Sem hardware por local. Enviar, instalar e atualizar um equipamento em cada localização não é escalável numa frota.

O Shield é o suplemento de DNS de proteção da Purple, a par do SecurePass e do Verify. A filtragem é executada na nuvem e liga-se aos SSIDs (nomes de rede), portais cativos e analítica que já gere para cada cliente. Um Captive Portal é a página de início de sessão que um visitante vê antes de aceder à Internet.

Como a filtragem de MSP difere de uma implementação num único local

Um filtro num único local tem uma política, um administrador e uma rede. Uma propriedade de MSP tem uma hierarquia. Define regras para a propriedade, substitui-as por cliente e, em seguida, varia-as 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 receção.

Os filtros de DNS autónomos lidam normalmente com isto através de uma suborganização por cliente, configurada separadamente do próprio WiFi. Acaba por gerir duas pilhas de software para cada cliente: uma para a rede e para o portal, e outra para o resolvedor. O Shield elimina a segunda pilha, porque a política de filtragem segue as redes que já definiu na Purple.

Por que motivo a filtragem de DNS é importante numa frota de locais de clientes?

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

Dever de diligência em redes partilhadas

O WiFi público e de convidados acarreta obrigações reais. Em Inglaterra, as escolas e faculdades seguem as normas de filtragem e monitorização do Department for Education, referenciadas em Keeping children safe in education. Nos EUA, a Children's Internet Protection Act (CIPA) exige que as escolas e bibliotecas que recebem financiamento E-rate apliquem filtros. Hotéis, cafés e centros de lazer que acolhem famílias enfrentam riscos reputacionais se uma criança aceder a conteúdos para adultos. O programa Friendly WiFi do Reino Unido existe exatamente por essa razão.

Quando gere WiFi para 40 clientes, partilha uma quota de cada obrigação. Um único site não filtrado resulta numa conversa com o cliente que vai querer evitar.

Ameaças que atingem dispositivos não geridos

Não é possível instalar um agente no telemóvel de um visitante, nem é possível atualizá-lo. Links de phishing, downloads de malware e chamadas de retorno de comando e controlo começam todos com uma consulta DNS. Isso faz da consulta o único ponto que controla para cada dispositivo na rede.

O Shield assinala ameaças na fase de consulta DNS, interrompendo pedidos maliciosos antes de as ligações se concretizarem. Em toda uma frota, o bloqueio de uma ameaça é aplicado em todos os locais 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 com limitações

Muitas propriedades operam WiFi de convidados em ligações modestas: um router 4G numa área de serviço, uma linha partilhada num pub, um circuito congestionado numa estação. O tráfego de anúncios e os conteúdos web indesejados competem com tudo o resto. A filtragem de anúncios e domínios maliciosos na camada de DNS reduz o consumo de dados da rede e melhora a velocidade de carregamento. Num local congestionado, essa margem libertada volta para o tráfego que os convidados realmente procuram.

O que um firewall não deteta

Um firewall continua a ser importante, mas atua num ponto diferente. Inspeciona as ligações após o DNS já ter respondido. Isso deixa quatro lacunas numa rede de convidados multilocal:

1. A encriptação oculta o destino. O TLS 1.3 (RFC 8446) encripta o certificado do servidor. O Encrypted Client Hello (ECH), uma extensão IETF ao TLS, também pode ocultar o nome do servidor. Sem descodificação, um firewall vê um endereço IP e pouco mais, e não é possível instalar um certificado de descodificação no dispositivo de um visitante.
2. Endereços IP partilhados desfocam as regras. As redes de distribuição de conteúdo alojam muitos domínios nos mesmos endereços. Bloqueie o IP e quebrará sites legítimos; permita-o e o domínio malicioso passa.
3. Os conjuntos de regras por local divergem. Uma frota construída ao longo de anos mistura fornecedores de firewall e versões de firmware. Manter 60 conjuntos de regras alinhados é um trabalho a tempo inteiro, e um único local esquecido é a lacuna.
4. O bloqueio chega tarde. Quando um firewall atua, o dispositivo já resolveu o nome e tentou uma ligação. A filtragem DNS interrompe o pedido antes que exista qualquer ligação.

A filtragem DNS fecha estas lacunas sem descodificação, agentes ou regras por local. Não substitui a função do firewall de segmentar redes e controlar portas.

Como funciona a filtragem DNS em vários clientes?

O que acontece durante cada consulta

1. Um convidado liga-se ao WiFi do cliente, frequentemente através de um Captive Portal.
2. O dispositivo solicita um domínio, por exemplo a partir de uma hiperligação num e-mail de phishing.
3. O Shield verifica o domínio em relação à política atribuída a essa rede.
4. Se o domínio for permitido, o dispositivo recebe o endereço e liga-se normalmente.
5. Se for bloqueado, a consulta não devolve o endereço real, pelo que nenhuma ligação é aberta.

Como estruturar políticas por cliente (tenant)

O fornecimento de filtragem de conteúdos por cliente funciona melhor como um pequeno conjunto de políticas padrão, e não como um conjunto de regras à medida por local. Este padrão aplica-se com sucesso nos setores da hotelaria, retalho 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 clientes. Ninguém fica de fora.
• Convidado familiar. A linha de base mais conteúdos adultos e desadequados para a idade. Ideal para hotéis familiares, bibliotecas, centros de lazer, escolas e salas de espera de cuidados de saúde.
• Convidado adulto. A linha de base com regras de conteúdo mais flexíveis. Ideal para bares, espaços noturnos e hotéis de negócios.
• Funcionários. A linha de base mais regras que refletem a política de utilização aceitável de cada cliente.

Atribua uma política por rede e adicione exceções de clientes apenas onde o negócio realmente necessitar. A equipa de marketing de um hotel pode precisar de redes sociais que uma escola iria bloquear. Quatro políticas e uma lista curta de exceções são muito mais fáceis de auditar do que 60 conjuntos de regras criados manualmente.

Como o Shield associa políticas às redes que gere no Purple, os SSIDs de convidados e funcionários de um local podem ter políticas diferentes. As redes de funcionários que utilizam 802.1X, o padrão para controlo de acesso à rede baseado em portas, mantêm os seus controlos de identidade. O Shield adiciona a camada de DNS por cima.

Gerir uma frota a partir de um único painel

A gestão centralizada de políticas de DNS só compensa se corresponder à sua forma habitual de trabalhar. O Shield está integrado na mesma plataforma Purple que gere os SSIDs, Captive Portals e análises de cada cliente. Não precisa de mudar de consola para alterar um filtro nem de manter um segundo inventário de locais.

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

• Integração (Onboarding). Um novo local de cliente no Purple não necessita de uma conta de resolvedor separada.
• Controlo de alterações. Altere uma política uma vez e esta será aplicada a todas as redes que lhe estiverem atribuídas.
• Relatórios. A atividade de filtragem fica ao lado das análises de ligação que já partilha, permitindo que uma única revisão trimestral cubra o WiFi e a segurança.

Por que razão não há nada para enviar

O Shield filtra na nuvem, pelo que não há equipamentos físicos para comprar, configurar, enviar ou substituir em cada localização. O Purple é independente de hardware e funciona como uma sobreposição em nuvem para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O parque de um cliente que misture diferentes fabricantes após aquisições continua a executar um único conjunto de políticas. A configuração varia consoante o fabricante, pelo que deve seguir a documentação de suporte do Purple para o seu hardware.

O Purple já opera em mais de 80 000 locais ativos e registou 440 milhões de inícios de sessão em 2024 (dados do Purple).

Como é que a filtragem de DNS se comporta num parque imobiliário real?

Os três cenários abaixo são modelos compostos construídos a partir de estruturas comuns de instalações. A contagem de locais e o hardware são típicos; os resultados são a aritmética operacional de cada mudança.

Cenário 1: um MSP com 14 clientes no setor da hoteleira e restauração

Situação. Um MSP gere WiFi para convidados e funcionários em 14 clientes de hoteleira e restauração distribuídos por 60 locais. O conjunto inclui hotéis independentes, um grupo de 20 pubs e um parque de campismo. O WiFi e os portais captivos já funcionam no Purple. A filtragem funcionava num serviço 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. Os hotéis familiares e o parque de campismo adotaram a política de convidados familiares; o grupo de pubs adotou a de convidados adultos. Dois clientes mantiveram listas curtas de exceções.

Resultado. Zero hardware enviado e zero visitas aos locais em 60 estabelecimentos. O MSP desativou 14 contas de filtragem separadas e agora gere todos os clientes a partir do painel do 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 desportivos de um município

Situação. Um município oferece WiFi público em 22 bibliotecas e cinco centros desportivos. As crianças utilizam as redes da biblioteca depois das aulas. Duas etapas de aquisição resultaram em HPE Aruba nas bibliotecas e Ubiquiti UniFi nos centros desportivos. A equipa de TI é composta por três pessoas.

O que foi feito. O município aplicou a política de convidados familiares a todos os SSID públicos e a política de funcionários às redes de colaboradores. A autenticação de funcionários permanece em 802.1X com WPA3-Enterprise, o padrão atual de encriptação para WiFi empresarial. Os visitantes continuam a ligar-se através do Captive Portal do município.

Resultado. Todos os 27 locais executam uma única política pública em dois fornecedores de hardware diferentes, sem qualquer equipamento físico adicional. Uma única edição chega a todos os 27 locais. O município apresenta aos auditores uma única política e uma única fonte de registos, em vez de 27 configurações locais.

Cenário 3: uma cadeia de retalho com 120 lojas e largura de banda limitada

Situação. Um retalhista disponibiliza WiFi de convidados para clientes em 120 lojas, um terço das quais a utilizar ligações 4G. A navegação dos clientes compete com os sistemas das lojas pela largura de banda. O ambiente de dados de titulares de cartões já está segmentado do tráfego de convidados para se manter fora do âmbito do PCI DSS.

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

Resultado. O piloto mediu a sua própria utilização antes e depois ao longo de quatro semanas, demonstrando uma redução no consumo geral de dados em ligações limitadas. O retalhista alargou depois a política a todas as 120 lojas numa única alteração, sem necessidade de realizar uma única visita presencial.

Onde se posiciona a filtragem DNS em relação ao que já executa?

O DNS de proteção é uma camada adicional. Funciona melhor juntamente com os controlos que provavelmente já possui.

• Segmentação. As VLANs (LANs virtuais, que dividem uma rede física em redes lógicas isoladas) mantêm o tráfego de convidados separado do pessoal e dos sistemas de pagamento. Consulte Como Configurar a Segmentação de Rede para Convidados e Colaboradores.
• Autenticação. O 802.1X com RADIUS, o protocolo que verifica credenciais em relação a um servidor central, decide quem se junta a uma rede de colaboradores. O mesmo faz o SecurePass com Microsoft Entra ID, Okta ou Google Workspace. O Shield decide para onde os dispositivos podem ir após estarem ligados.
• Firewalls. A sua firewall continua a controlar portas, protocolos e tráfego entre segmentos. O Shield bloqueia destinos maliciosos conhecidos no momento da consulta.
• Legislação de privacidade. Os registos de DNS podem conter endereços IP e identificadores de dispositivos, que o GDPR considera dados pessoais. A Purple cumpre o GDPR e possui a certificação ISO 27001.

Como o Shield se compara com o DNSFilter e o Cisco Umbrella

O DNSFilter e o WebTitan focam-se fortemente em MSPs, e o Cisco Umbrella é o padrão em muitos ambientes Cisco. Todos filtram na camada de DNS na nuvem. As diferenças residem em quem gere 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
Gestão de instâncias	Dentro do painel da Purple que gere o WiFi de clientes	Consola de MSP separada com suborganizações	Consola multi-organização ou de MSP separada
Associado a SSIDs, portais cativos e analítica de WiFi	Sim, nativo para a plataforma de WiFi	Não, configurado como uma solução separada	Integra-se com Cisco Meraki, gerido na sua própria consola
Dispositivos em itinerância fora do local	Criado para dispositivos no WiFi que gere	Agente cliente de itinerância	Módulo de itinerância Cisco Secure Client
Cobertura de hardware	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks, Fortinet	Qualquer rede que possa reencaminhar DNS para os seus resolutores	Qualquer rede que possa reencaminhar DNS para os seus resolutores, mais avançado com Cisco
Mais adequado para	MSPs cujos clientes utilizam WiFi gerido na Purple	MSPs que protegem pontos de extremidade geridos dentro e fora do local	Ambientes padronizados com a segurança Cisco

As alternativas são fortes onde o Shield não compete. O DNSFilter e o Cisco Umbrella oferecem ambos agentes de itinerância para portáteis geridos fora do local. O Umbrella também se integra no portfólio de segurança mais amplo da Cisco. O WebTitan, da TitanHQ, também oferece um filtro na nuvem multi-instância para MSPs. Se os seus contratos cobrirem pontos de extremidade corporativos independentemente de onde viajem, uma dessas soluções poderá ser adequada.

O caso do Shield é mais focado e, para MSPs centrados em WiFi, mais forte. Se gere os SSIDs, Captive Portals e analítica de cada cliente no Purple, ter uma pilha de resolutores separada por cliente é uma sobrecarga. Para mais detalhes, leia Shield vs DNSFilter: uma comparação de DNS de proteção para operadores de WiFi e Shield vs Cisco Umbrella: escolher DNS de proteção para guest WiFi.

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

A filtragem DNS atua num ponto específico da ligação, o que define os seus limites.

• O DNS encriptado pode contorná-la. O DNS over HTTPS (DoH, RFC 8484) e o DNS over TLS (DoT, RFC 7858) permitem que um dispositivo escolha o seu próprio resolutor. Os controlos de rede podem reduzir isto em dispositivos não geridos, mas não o conseguem eliminar. Consulte DNS over HTTPS explicado: privacidade vs filtragem em WiFi público.
• As VPNs criam túneis que a ultrapassam. Um convidado numa VPN pessoal resolve nomes dentro do túnel. Pode bloquear domínios de VPN conhecidos, mas não todos.
• As ligações diretas por IP ignoram o DNS. Malware que chame um endereço IP fixo no código nunca faz uma consulta. O seu firewall cobre esse caso.
• Vê domínios, não conteúdos. A filtragem DNS permite ou bloqueia um domínio inteiro, não páginas ou ficheiros individuais.
• As categorias precisam de revisão. Qualquer lista de categorias irá, por vezes, bloquear em excesso ou em defeito. Forneça a cada cliente um contacto dedicado e um meio para solicitar alterações.
• Os registos precisam de governação. Acorde a retenção e o acesso por cliente antes da implementação e registe-o no seu acordo de processamento de dados.

O que deve fazer a seguir?

1. Mapeie os seus clientes. Liste todos os clientes, locais e redes, com os respetivos setores verticais e deveres regulatórios, tais como escolas, bibliotecas, cuidados de saúde e espaços licenciados.
2. Elabore políticas padrão. Comece com as quatro indicadas acima e mantenha a linha de base de segurança como obrigatória.
3. Faça um piloto em locais representativos. Escolha um local por setor vertical, incluindo um com ligação de tráfego limitada, e meça a utilização de dados antes e depois.
4. Implemente por política, não por local. Atribua políticas às redes de cada cliente e, em seguida, reveja as exceções após 30 dias.
5. Apresente relatórios. Adicione a atividade de filtragem às revisões de WiFi que já disponibiliza.

Se o WiFi dos seus clientes ainda não funciona no Purple, comece com o Guest WiFi e, em seguida, adicione o Shield. Para saber mais sobre como proteger redes em vários edifícios, explore Todos os guias.

Perguntas frequentes

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

Não. O Shield filtra na camada de DNS na cloud, pelo que não há qualquer dispositivo físico para comprar, configurar ou enviar para qualquer localização. O Purple funciona como uma sobreposição na cloud nos pontos de acesso que os seus clientes já possuem, incluindo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. A configuração varia consoante o fornecedor, por isso siga a documentação de suporte do Purple para cada tipo de hardware no seu parque.

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

Sim. O Shield associa a política de filtragem às redes que já executa no Purple, para que cada cliente, e cada SSID num local, possa ter a 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 utilização aceitável do cliente. Um pequeno conjunto de políticas padrão, juntamente com listas curtas de exceções, é mais fácil de auditar do que regras personalizadas por local.

Posso gerir a filtragem de conteúdos de vários locais a partir de um único painel de controlo?

Sim. O Shield é gerido na mesma plataforma Purple que executa os SSIDs, os Captive Portals e as analíticas dos seus clientes, para que possa alterar a filtragem sem mudar de consola. Uma alteração de política aplica-se 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 a conetividade e a segurança em conjunto.

Como é que o Shield se compara com o DNSFilter para um MSP?

O Shield é adequado para MSPs cujos clientes já utilizam WiFi no Purple, enquanto o DNSFilter é adequado para MSPs que protegem portáteis geridos dentro e fora do local. Ambos filtram na camada de DNS na nuvem, sem necessidade de hardware por local. O DNSFilter é executado como uma consola multi-tenant separada com um agente itinerante. O Shield é executado dentro da plataforma WiFi, associado aos mesmos SSIDs, Captive Portals e analíticas que já gere.

Os convidados podem contornar a filtragem de DNS com DNS sobre HTTPS ou uma VPN?

Sim, um convidado determinado pode fazê-lo. O DNS sobre HTTPS, o DNS sobre TLS e as VPNs pessoais enviam consultas para fora do seu resolvente. Os controlos de rede podem reduzir isto, por exemplo, bloqueando VPNs conhecidas e pontos de extremidade DoH públicos, mas nenhum filtro de DNS controla totalmente um dispositivo não gerido. Trate a filtragem de DNS como a proteção predefinida para todos os dispositivos que utilizam o DNS da rede, a par da segmentação e da sua firewall.

A filtragem de DNS ajuda escolas e bibliotecas a cumprir os requisitos de filtragem?

Cobre o elemento de filtragem, mas a filtragem por si só não cumpre a totalidade do requisito. Em Inglaterra, os padrões de filtragem e monitorização do Department for Education exigem tanto filtragem como monitorização, com responsabilidades nomeadas e revisões regulares. Nos EUA, a CIPA exige que as escolas e bibliotecas financiadas pelo E-rate utilizem medidas de proteção tecnológica no âmbito de uma política de segurança na internet. Combine uma filtragem consistente em todos os locais com os seus processos de monitorização e salvaguarda.

Como são tratados os registos de consultas DNS ao abrigo do GDPR?

O Purple está em conformidade com o GDPR e possui a certificação ISO 27001. Os registos de DNS podem incluir endereços IP e identificadores de dispositivos, que o GDPR trata como dados pessoais. Acorde a retenção, o acesso e a finalidade com cada cliente antes da implementação, e registe esses termos no seu acordo de processamento de dados. Como MSP, atuará frequentemente como subcontratante para os seus clientes, pelo que deve documentar quem controla os registos de cada propriedade.

Como é definido o preço do Shield para uma propriedade com múltiplos locais?

O Shield é um suplemento de segurança para a plataforma Purple, juntamente com o SecurePass e o Verify, pelo que o adiciona a locais que já utilizam a Purple. Não existe hardware por local, pelo que não há custos de equipamento, envio ou substituição a integrar no modelo. Solicite à Purple uma proposta de preços com base no seu número de clientes e locais, e inclua quaisquer locais que planeie integrar este ano.