Melhor filtragem DNS: um guia completo para empresas
Este guia de referência técnica explica como a filtragem DNS empresarial protege as redes públicas bloqueando domínios maliciosos na camada de resolução - antes de uma ligação ser estabelecida. Oferece aos diretores de TI, arquitetos de rede e equipas de operações de locais a arquitetura de implementação, configuração de firewall e contexto de conformidade necessários para proteger o Guest WiFi em ambientes de hotelaria, retalho e setor público. O Purple Shield bloqueia malware, botnets e conteúdos inadequados ao nível do DNS em mais de 80.000 locais ativos.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Para líderes de TI que gerem redes públicas de grande escala, proteger o ambiente de navegação é um mandato operacional e não um extra opcional. O Guest WiFi na hotelaria, retalho e locais públicos é, por natureza, um ambiente não fidedigno. Sem controlos robustos, torna-se um vetor para a distribuição de malware, atividade de botnets e acesso a conteúdos inadequados que prejudicam a reputação da marca e criam riscos de conformidade.
O filtro DNS é o mecanismo mais eficiente para aplicar políticas de conteúdo e bloquear ameaças na periferia da rede. Ao contrário da Inspeção Profunda de Pacotes (DPI), que consome muitos recursos, o filtro DNS intercepta o pedido de resolução do domínio antes de qualquer payload ser trocado. Avalia um pacote UDP leve em relação a informações sobre ameaças em tempo real e devolve um endereço IP válido ou um sinkhole, adicionando menos de dois milissegundos de latência. Isto torna-o o único método prático de controlo de conteúdos para ambientes de alta densidade que servem milhares de dispositivos não geridos em simultâneo.
Este guia aborda a arquitetura técnica necessária para implementar filtros DNS em locais empresariais distribuídos, incluindo segmentação de VLAN, imposição da porta 53, integração de Captive Portal e prevenção de evasão de DNS over HTTPS (DoH). Também aborda a conformidade com PCI-DSS e GDPR, e explica como o Purple Shield se integra em infraestruturas de hardware existentes da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet sem necessidade de substituição de hardware.
Análise técnica detalhada: como funciona o filtro DNS
O Domain Name System (DNS) traduz domínios legíveis por humanos em endereços IP legíveis por máquinas. Todas as ligações à internet começam com um pedido de resolução DNS. Numa rede padrão, os dispositivos consultam um resolvedor predefinido atribuído pelo ISP. Numa arquitetura segura, o servidor DHCP atribui um resolvedor DNS com aplicação de políticas aos dispositivos na VLAN de convidados.
Quando um dispositivo consulta este resolvedor seguro, o motor de filtragem avalia o domínio em relação a múltiplas fontes de dados em simultâneo: feeds de inteligência sobre ameaças em tempo real, listas de bloqueio por categoria (conteúdo adulto, jogo, pirataria) e registos de domínios de comando e controlo de botnets. A decisão ocorre em milissegundos.
Se o domínio for seguro, o motor devolve o endereço IP correto e a ligação prossegue normalmente. Se o domínio for sinalizado como malicioso ou violar a sua política de utilização aceitável, o motor devolve um endereço IP não encaminhável (sinkholing) ou redireciona o utilizador para uma página de bloqueio personalizada. O ponto-chave: esta intervenção ocorre antes de qualquer payload de dados ser trocado entre o dispositivo e o servidor de destino.
Vantagens de desempenho e escala
O filtragem DNS é arquitetonicamente superior ao DPI para ambientes públicos de alta densidade. O DPI exige que o hardware de rede inspecione o payload de cada pacote. Num local com 50.000 utilizadores simultâneos - um estádio, centro de conferências ou um grande espaço comercial - o DPI introduz uma latência significativa e exige hardware dispendioso e concebido especificamente para o efeito em cada ponto de inspeção.
O filtragem DNS funciona no início do ciclo de vida da ligação. Avalia um único pacote UDP leve. Assim que a resolução é concluída, os dados são transferidos diretamente entre o cliente e o servidor de destino. O motor de filtragem nunca processa o payload de dados. O impacto na latência é consistentemente inferior a dois milissegundos, independentemente do número de utilizadores simultâneos.
Como o filtragem DNS funciona antes do estabelecimento da ligação, é agnóstico em relação ao protocolo. Bloqueia ligações quer a aplicação utilize HTTP, HTTPS, FTP ou uma porta personalizada. Esta é uma vantagem significativa sobre a filtragem baseada em URL, que apenas inspeciona o tráfego HTTP/HTTPS.
A vantagem de 10 dias na deteção de ameaças
A segurança DNS legada baseia-se em listas de bloqueio reativas: um domínio é identificado como malicioso, comunicado a uma autoridade central, adicionado a uma base de dados e, eventualmente, distribuído ao seu filtro - um processo que pode demorar dias. As campanhas de malware modernas exploram este atraso. Os atacantes registam novos domínios, executam uma campanha num período de 24 horas e abandonam o domínio antes que este chegue a qualquer lista de bloqueio padrão.
O Purple Shield utiliza a deteção de ameaças baseada em IA para analisar padrões de registo de domínios, reputação de IP e assinaturas criptográficas em tempo real. Esta abordagem identifica e bloqueia ameaças emergentes de dia zero até 10 dias mais rápido do que os fornecedores reativos tradicionais (dados internos da Purple, 2026). Num ambiente onde um único link malicioso num dispositivo convidado pode levar a ransomware, essa janela de deteção é operacionalmente significativa.
Guia de implementação: arquitetura e implementação
A implementação correta do filtragem DNS exige uma configuração de rede precisa em três camadas: DHCP, firewall e Captive Portal.
Passo 1: Segmentação de VLAN
Segmente a sua rede para que o tráfego de convidados fique isolado dos sistemas operacionais. Coloque os dispositivos dos convidados numa VLAN dedicada (por exemplo, VLAN 20) e mantenha os terminais POS, os sistemas de gestão de propriedades e os dispositivos da equipa em VLANs separadas com resolutores DNS internos. Isto garante que a sua política de filtragem DNS se aplica exclusivamente ao tráfego de convidados não confiável e não interrompe os sistemas operacionais.
Esta segmentação também cumpre o Requisito 1.3 do PCI-DSS, que exige que os ambientes de dados dos titulares de cartões sejam isolados de redes não confiáveis. O WiFi de convidados nunca deve partilhar uma VLAN com a infraestrutura de pagamento.
Passo 2: Configuração do escopo DHCP
Configure o escopo DHCP para a VLAN de convidados para atribuir os endereços IP do seu serviço de filtragem de DNS na cloud como servidores DNS primário e secundário. Isto garante que cada dispositivo que se junta à rede de convidados recebe o resolver correto automaticamente.
Passo 3: Imposição da Porta 53 na firewall
A atribuição de DHCP por si só é insuficiente. Um utilizador pode anular as configurações de DNS fornecidas pelo DHCP configurando manualmente o seu dispositivo para utilizar um resolver público como o Google (8.8.8.8) ou o Cloudflare (1.1.1.1). O malware frequentemente codifica rigidamente as configurações de DNS para contornar totalmente os controlos de rede.
Deve implementar uma regra de firewall que descarte todo o tráfego de saída na porta 53 (tanto UDP como TCP) da VLAN de convidados para qualquer endereço IP que não sejam os seus servidores de filtragem designados. Isto converte o filtro DNS de um controlo consultivo num controlo imposto.
Passo 4: Mitigação de DNS over HTTPS (DoH)
Os browsers e aplicações modernos utilizam cada vez mais DoH, que encripta as consultas DNS dentro do tráfego HTTPS padrão na porta 443. Isto contorna totalmente a interceção na porta 53. Para manter a cobertura, configure a sua firewall para bloquear as gamas de endereços IP conhecidas dos principais fornecedores de DoH. Isto força os dispositivos clientes a recorrerem ao DNS não encriptado padrão, que o seu motor de filtragem pode inspecionar. O NIST SP 800-81r3 (publicado em março de 2026) aborda especificamente o DoH como uma consideração de segurança de DNS empresarial.
Passo 5: Configuração do Walled Garden do Captive Portal
Se opera um Captive Portal para autenticação de convidados, deve configurar um Walled Garden antes de aplicar qualquer política de bloqueio. O Walled Garden é uma lista de domínios que os dispositivos podem aceder antes de se autenticarem. Deve incluir todos os domínios necessários para o funcionamento do Captive Portal: o próprio domínio do seu portal, quaisquer fornecedores de identidade (Microsoft Entra ID, Okta, Google Workspace) e quaisquer endpoints OAuth de login social.
Se estes domínios forem bloqueados antes da autenticação, os utilizadores não conseguem concluir o fluxo de início de sessão. O resultado é uma experiência de adesão corrompida e convidados frustrados. Configure primeiro o Walled Garden e, em seguida, aplique a sua política de filtragem de conteúdo apenas a sessões autenticadas.
Para saber mais sobre a arquitetura de SSID e como o Guest WiFi, Staff WiFi e redes IoT devem ser estruturados, consulte Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi .
Melhores práticas: design de políticas e gestão contínua
Bloqueio baseado em categorias
Organize a sua política de filtragem de DNS em torno de categorias de conteúdo em vez de listas de bloqueio de domínios individuais. As categorias normalmente incluem: malware e phishing, comando e controlo de botnets, conteúdo adulto, jogos de azar, streaming ilegal e partilha de ficheiros peer-to-peer. As políticas baseadas em categorias são mais fáceis de manter e capturam automaticamente novos domínios à medida que as informações sobre ameaças são atualizadas.
Frequência de atualização de informações sobre ameaças
Selecione um fornecedor de filtragem DNS que atualize a inteligência de ameaças em tempo real ou quase em tempo real. As listas de bloqueio estáticas atualizadas diariamente são insuficientes contra as campanhas modernas de malware fast-flux. O Purple Shield atualiza a sua inteligência de ameaças continuamente, refletindo a mesma deteção baseada em IA que proporciona a vantagem de 10 dias sobre os fornecedores reativos.
Implantação independente de hardware
O Purple Shield funciona como uma sobreposição na nuvem, o que significa que se integra com a sua infraestrutura de pontos de acesso existente sem necessidade de substituição de hardware. É compatível com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, e Fortinet. A política de filtragem é aplicada na camada de DNS, pelo que o hardware do ponto de acesso apenas necessita de encaminhar as consultas DNS para o resolvedor correto.
Análise e relatórios
A filtragem DNS gera registos de consultas detalhados que proporcionam visibilidade sobre o comportamento da rede. Utilize estes registos para identificar tendências: um pico de tentativas de phishing bloqueadas a partir de um ponto de acesso específico pode indicar um ataque direcionado. A revisão regular dos relatórios de categorias bloqueadas também apoia as auditorias de conformidade, demonstrando aos avaliadores PCI-DSS e auditores GDPR que possui controlos ativos implementados.
A plataforma de WiFi Analytics da Purple integra-se com o Shield para fornecer uma visibilidade unificada de eventos de segurança e desempenho de rede.
Resolução de problemas e mitigação de riscos
Contorno de filtro via DNS personalizado
Sintoma: Os utilizadores reportam o acesso a conteúdos que deveriam estar bloqueados. Os registos da firewall mostram consultas DNS para 8.8.8.8 ou 1.1.1.1 a partir da VLAN de convidados.
Causa: A porta 53 não está bloqueada na firewall. Os utilizadores estão a substituir as definições de DNS atribuídas por DHCP.
Correção: Implemente uma regra de firewall que rejeite todo o tráfego de saída da porta UDP/TCP 53 da VLAN de convidados para qualquer IP que não seja o seu motor de filtragem.
Falha na autenticação do Captive Portal
Sintoma: Os convidados não conseguem concluir o fluxo de início de sessão. A página do Captive Portal não carrega ou os botões de início de sessão social não respondem.
Causa: O filtro DNS está a bloquear os domínios do fornecedor de identidade antes da autenticação. O Microsoft Entra ID, o Google Workspace ou o próprio domínio do seu portal estão numa lista de categorias bloqueadas.
Correção: Audite a configuração do seu Walled Garden. Adicione todos os domínios de autenticação necessários à lista de permissões pré-autenticação. Teste todo o fluxo de início de sessão num ambiente de testes antes de implementar alterações de política.
Contorno de DoH
Sintoma: Os registos do filtro DNS mostram um volume de consultas baixo, apesar da elevada utilização da rede. Alguns dispositivos parecem contornar totalmente a filtragem.
Causa: Os browsers ou aplicações estão a utilizar DoH, encaminhando consultas DNS encriptadas através da porta 443 para resolvedores externos.
Correção: Bloqueie as gamas de IP conhecidas dos principais fornecedores de DoH na firewall. Verifique a cobertura monitorizando as ligações HTTPS para IPs de resolvedores DoH conhecidos.
Interrupção da VLAN operacional
Sintoma: Os terminais POS ou os sistemas de gestão de propriedades perdem a conectividade após a implementação do filtro DNS. Causa: A política de filtragem de DNS foi aplicada à VLAN errada, ou o DHCP está a atribuir o resolvedor de DNS na nuvem a dispositivos operacionais.
Resolução: Verifique a marcação de VLAN em todas as portas de switch e pontos de acesso. Confirme se as VLANs dos dispositivos operacionais estão configuradas para utilizar apenas resolvedores de DNS internos.
ROI e impacto empresarial
A filtragem de DNS oferece retornos mensuráveis em três dimensões.
Recuperação de largura de banda: Bloquear streaming ilegal, partilha peer-to-peer e tráfego automatizado de botnets recupera uma largura de banda significativa. Num ambiente hoteleiro, isto pode reduzir a utilização da VLAN de convidados em 20-40%, melhorando o desempenho para utilizadores legítimos sem necessitar de atualizações de circuitos.
Redução de custos de conformidade: Demonstrar controlos ativos ao nível do DNS reduz o âmbito e o custo das avaliações PCI DSS. Também fornece evidências documentadas para o Artigo 32.º do GDPR (medidas técnicas para garantir a segurança dos dados) e apoia os requisitos de certificação do Cyber Essentials para proteção contra malware.
Proteção de marca e de responsabilidade civil: A aplicação de políticas de navegação adequadas para famílias em ambientes de retalho e hotelaria evita a exibição pública de conteúdos inadequados. Em locais que servem crianças - centros comerciais, hotéis familiares, estádios - isto é tanto um requisito de marca como uma consideração legal em muitas jurisdições.
Para orientações de implementação específicas do setor, consulte as nossas páginas de setores para Hotelaria , Retalho , Saúde e Transportes .
Definições Principais
Filtragem DNS
Uma técnica de segurança que interpeta pedidos de resolução de domínio e os avalia face a fontes de inteligência de ameaças e políticas de conteúdo antes de permitir ou bloquear uma ligação.
O método principal de controlo de conteúdos para dispositivos de convidados não geridos em redes públicas. Não requer agente no endpoint.
Sinkholing
Retorno de um endereço IP não encaminhável (como 0.0.0.0) em resposta a uma consulta DNS para um domínio malicioso, impedindo o dispositivo de estabelecer uma ligação.
Utilizado para bloquear silenciosamente o tráfego de comando e controlo de botnets sem alertar o malware de que foi detetado.
Walled Garden
Um ambiente de rede restrito de pré-autenticação que permite o acesso a um conjunto específico de domínios aprovados antes de o utilizador concluir o fluxo de início de sessão no captive portal.
Deve incluir todos os domínios do fornecedor de identidade (Microsoft Entra ID, Google Workspace, Okta) e recursos do captive portal para evitar falhas de autenticação.
DNS over HTTPS (DoH)
Um protocolo que encripta consultas DNS dentro do tráfego HTTPS padrão na porta 443, ocultando o domínio de destino da inspeção ao nível da rede.
Cada vez mais utilizado por predefinição nos navegadores modernos. Requer o bloqueio ao nível do firewall das gamas de IP do fornecedor de DoH para manter a cobertura de filtragem DNS.
Segmentação de VLAN
Divisão de uma única rede física em várias redes lógicas isoladas utilizando a marcação 802.1Q.
Crítico para isolar o tráfego de convidados dos sistemas operacionais. O Requisito 1.3 do PCI-DSS exige que os ambientes de dados de titulares de cartões sejam separados de redes não fidedignas, incluindo o WiFi de convidados.
Captive portal
Uma página web com a qual os dispositivos devem interagir antes de obterem acesso total à rede, utilizada para autenticação, aceitação dos termos de serviço e captura de dados primários.
Requer uma configuração cuidadosa do Walled Garden para funcionar corretamente em conjunto com a filtragem DNS.
Deep Packet Inspection (DPI)
Um método de filtragem de rede que examina a carga total dos pacotes num ponto de inspeção, permitindo uma filtragem sensível ao conteúdo, mas introduzindo uma sobrecarga de processamento significativa.
Inviável para redes de convidados de alta densidade devido à latência e ao custo do hardware. A filtragem DNS é a alternativa preferida para ambientes de dispositivos não geridos.
Fonte de inteligência de ameaças
Uma base de dados continuamente atualizada de endereços IP, domínios e padrões de URL maliciosos conhecidos, utilizada para alimentar decisões de filtragem DNS em tempo real.
A qualidade e a frequência de atualização da fonte de inteligência de ameaças determinam a rapidez com que um filtro DNS responde a novas ameaças de dia zero.
Domínio de dia zero
Um domínio recém-registado utilizado numa campanha de malware ou phishing antes de aparecer em qualquer lista de bloqueio padrão.
As campanhas de ataque modernas utilizam domínios descartáveis que estão ativos por menos de 24 horas. A deteção de ameaças orientada por IA identifica estes domínios analisando padrões de registo em vez de esperar por relatórios.
Exemplos Práticos
Uma cadeia de hotéis de 400 quartos está a implementar Guest WiFi em 12 propriedades. Utilizam o Microsoft Entra ID para a autenticação no Captive Portal e o seu sistema de gestão de propriedades (PMS) corre na mesma infraestrutura física de switches. Após ativarem a filtragem DNS, os hóspedes em três propriedades relatam que não conseguem concluir o fluxo de início de sessão. Qual é a causa principal e como deve a equipa resolver o problema?
A causa principal é uma configuração incompleta de Walled Garden. O filtro DNS está a bloquear os domínios de autenticação do Microsoft Entra ID antes de os hóspedes se autenticarem, criando um impasse onde os hóspedes não conseguem carregar a página de início de sessão. Passos para a resolução: 1. No painel de filtragem DNS, crie uma política de pré-autenticação que inclua explicitamente na lista de permissões todos os domínios do Microsoft Entra ID, incluindo login.microsoftonline.com, login.live.com e quaisquer domínios específicos do inquilino. 2. Verifique se o próprio domínio do Captive Portal e quaisquer recursos de CDN que este carregue também estão na lista de permissões. 3. Confirme se a VLAN do PMS (VLAN 10) está configurada para utilizar resolutores DNS internos, e não o motor de filtragem na nuvem. 4. Aplique a política restritiva de bloqueio de conteúdo apenas às sessões pós-autenticação na VLAN de convidados (VLAN 20). 5. Teste o fluxo de início de sessão completo em cada propriedade afetada antes de fechar o incidente.
Uma grande cadeia de retalho opera 200 lojas, cada uma com uma rede WiFi de convidados. A sua equipa de segurança de TI implementa um filtro DNS na nuvem e atualiza o âmbito de DHCP em todas as VLANs de convidados. Duas semanas depois, um teste de penetração revela que 18% dos dispositivos de convidados estão a resolver com sucesso domínios maliciosos conhecidos. Os registos do filtro DNS não mostram consultas bloqueadas provenientes destes dispositivos. Qual é a falha arquitetónica e qual é a correção?
A falha é que a porta 53 não está bloqueada na firewall. Os 18% de dispositivos estão a contornar os servidores DNS atribuídos por DHCP utilizando resolutores codificados (8.8.8.8, 1.1.1.1) ou utilizando DNS over HTTPS. Como as suas consultas DNS nunca chegam ao motor de filtragem, não aparecem consultas bloqueadas nos registos. Correção: 1. Implemente uma regra de firewall no gateway da VLAN de convidados que descarte todo o tráfego de saída UDP e TCP na porta 53 para qualquer IP que não sejam os IPs aprovados do motor de filtragem. 2. Identifique e bloqueie as gamas de IP dos principais fornecedores de DoH (Cloudflare, Google, NextDNS) na firewall para evitar o desvio encriptado. 3. Execute novamente o teste de penetração para confirmar a cobertura. 4. Monitorize os registos de descartes da firewall para tráfego na porta 53 para verificar se a regra está ativa.
Perguntas de Prática
Q1. Uma cadeia de retalho implementa um filtro DNS na nuvem em 150 lojas. Atualizam o âmbito DHCP em todas as VLAN de convidados para atribuir os IPs do motor de filtragem. Uma semana depois, os gerentes das lojas reportam que os clientes ainda conseguem aceder a categorias de conteúdo bloqueadas. O painel do filtro DNS mostra um volume de consultas muito baixo a partir dessas lojas. Qual é a causa mais provável e qual é a solução?
Dica: Considere como um dispositivo pode resolver DNS sem utilizar o servidor atribuído pelo DHCP.
Ver resposta modelo
A causa mais provável é que a porta de saída 53 não está bloqueada no firewall. Os dispositivos estão a sobrepor os servidores DNS atribuídos pelo DHCP com resolvedores públicos codificados no hardware. O baixo volume de consultas no painel confirma que as consultas não estão a chegar ao motor de filtragem. A solução é implementar uma regra de firewall que elimine todo o tráfego UDP e TCP de saída na porta 53 da VLAN de convidados para qualquer IP que não seja os IPs do motor de filtragem aprovados. Adicionalmente, bloqueie as gamas de IP conhecidas dos fornecedores de DoH para evitar o desvio de DNS encriptado.
Q2. Um centro de conferências está a implementar a filtragem de DNS pela primeira vez. Utilizam o Google Workspace para autenticação de participantes no seu Captive Portal. Durante os testes, os participantes não conseguem concluir o fluxo de início de sessão - a página de login da Google não carrega. Que passo de configuração foi esquecido e como deve ser corrigido?
Dica: A autenticação ocorre antes de o dispositivo ter acesso total à Internet. Que domínios devem estar acessíveis antes de a autenticação ser concluída?
Ver resposta modelo
O Walled Garden não foi configurado antes de a política de filtragem de DNS ser aplicada. O filtro de DNS está a bloquear os domínios de autenticação do Google Workspace (accounts.google.com, oauth2.googleapis.com) antes que os participantes se possam autenticar. A correção consiste em adicionar todos os domínios de OAuth e autenticação do Google Workspace necessários à lista de permissões de pré-autenticação na política de filtragem de DNS. O próprio domínio do Captive Portal e quaisquer recursos de CDN também devem ser incluídos na lista de permissões. Aplique a política de conteúdo restritivo apenas a sessões pós-autenticação.
Q3. A equipa de TI de um estádio está a avaliar a filtragem de DNS versus a Inspeção Profunda de Pacotes (DPI) para o seu recinto com capacidade para 60.000 pessoas. A equipa de rede está preocupada com a latência durante eventos de pico. Qual é a abordagem mais adequada e porquê?
Dica: Considere a sobrecarga de processamento de cada método à escala de 60.000 utilizadores em simultâneo.
Ver resposta modelo
A filtragem de DNS é a escolha adequada. Funciona na camada de resolução, avaliando um único pacote UDP leve antes de qualquer ligação ser estabelecida, adicionando menos de dois milissegundos de latência, independentemente do número de utilizadores em simultâneo. A DPI requer a inspeção de todo o payload de cada pacote, o que, com 60.000 utilizadores em simultâneo, introduziria uma latência significativa e exigiria hardware proibitivamente caro em todos os pontos de inspeção. A filtragem de DNS é também agnóstica em termos de protocolo, bloqueando ligações em qualquer porta, enquanto a DPI é normalmente limitada a tráfego HTTP e HTTPS.
Q4. Um diretor de TI de um grupo hoteleiro pretende confirmar se a sua implementação de filtragem de DNS cumpre os requisitos do PCI DSS. Os seus terminais de pagamento estão na VLAN 10 e o WiFi de convidados está na VLAN 20. O filtro de DNS é aplicado apenas à VLAN 20. Que evidências adicionais devem documentar para o seu auditor do PCI DSS?
Dica: O Requisito 1.3 do PCI DSS abrange controlos de acesso à rede entre redes fidedignas e não fidedignas.
Ver resposta modelo
O diretor de TI deve documentar: 1. Regras de firewall que confirmem que a VLAN 10 (ambiente de dados de titulares de cartões) não pode ser acedida a partir da VLAN 20 (rede de convidados), satisfazendo o Requisito 1.3 do PCI DSS. 2. Configuração de DHCP que mostre que os dispositivos da VLAN 10 utilizam resolvedores de DNS internos, e não o motor de filtragem na nuvem. 3. Regras de firewall que bloqueiem a porta de saída 53 da VLAN 20 para IPs não aprovados, demonstrando a aplicação obrigatória da filtragem de DNS. 4. Documentação da política do filtro de DNS que mostre categorias ativas de bloqueio de malware e botnets na VLAN 20. 5. Registos do filtro de DNS que mostrem eventos de consultas bloqueadas, demonstrando que o controlo está ativo e a ser monitorizado.
Continue a ler esta série
Como Segregar com Segurança Redes WiFi de Funcionários e Convidados
Este guia técnico de referência fornece aos líderes de TI estratégias práticas para segregar com segurança redes WiFi de funcionários, convidados e IoT utilizando VLANs e 802.1X. Detalha como proteger a infraestrutura empresarial, manter a conformidade com o PCI-DSS e potenciar Captive Portals para recolher dados primários (first-party data).
How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment
Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a atribuição automatizada de certificados WiFi empresariais, cobrindo toda a arquitetura desde PKI e NDES até à implementação de perfis MDM e validação RADIUS. Destina-se a gestores de TI, arquitetos de rede e CTOs em hotéis, cadeias de retalho, estádios, centros de conferências e organizações do setor público que necessitam de ir além das chaves pré-partilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição na nuvem da Purple, independente de hardware, integra-se diretamente com esta arquitetura, fornecendo a camada de WiFi para convidados e BYOD que coexiste com a sua rede de colaboradores autenticada por certificado.
O Guia Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus
Este guia de referência técnica fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais utilizando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.