Conformidade IWF para Redes WiFi Públicas no Reino Unido

Apresentador: Olá e bem-vindo ao Purple Enterprise IT Briefing. Sou o vosso anfitrião e hoje vamos abordar um tema que todos os Diretores de TI, CTOs e Arquitetos de Rede no Reino Unido precisam de dominar: a Conformidade com a IWF para Redes WiFi Públicas. Se gere infraestruturas para cadeias de retalho, espaços de hotelaria, estádios ou edifícios do setor público, disponibilizar WiFi para convidados já não se resume apenas a largura de banda e cobertura. Trata-se de mitigação de riscos. Disponibilizar uma ligação aberta à Internet sem uma filtragem robusta e certificada expõe a sua organização a graves danos legais e de reputação. Hoje, vamos diretos ao assunto. Sem teorias académicas — apenas orientações práticas e independentes de fornecedores sobre como desenhar a arquitetura de uma rede em conformidade e de alto desempenho. Vamos passar diretamente ao contexto. A Internet Watch Foundation, ou IWF, mantém a lista definitiva do Reino Unido de URLs que contêm Material de Abuso Sexual Infantil, ou CSAM. Para qualquer espaço que ofereça WiFi público, a integração desta lista de bloqueio é a base absoluta de uma operação responsável. Mas aqui está o ponto crítico: não pode simplesmente descarregar uma lista estática uma vez por mês e carregá-la na sua firewall. A lista da IWF é altamente dinâmica. Os URLs são adicionados e removidos constantemente. O seu motor de filtragem web deve consumir este feed em tempo real ou quase em tempo real. Se estiver a utilizar um fornecedor que não seja um membro oficial da IWF a consumir ativamente o seu feed dinâmico, não está em conformidade. Ponto final. Então, como desenhamos realmente esta arquitetura na periferia da rede? Vamos entrar na análise técnica detalhada. A implementação da conformidade com a IWF exige uma abordagem multicamada. Não pode depender de um único ponto de estrangulamento. A primeira camada é a filtragem de DNS. Esta é a sua primeira linha de defesa. Quando um dispositivo de um convidado solicita um domínio CSAM conhecido, o seu DNS seguro intercetá-lo-á e irá redirecioná-lo para uma página de bloqueio. É altamente eficiente e introduz praticamente zero latência. No entanto, a filtragem de DNS por si só é fundamentalmente falível para a conformidade moderna. Porquê? Porque o DNS funciona ao nível do domínio. A lista da IWF especifica frequentemente URLs exatos — páginas específicas no interior de um site. Se utilizar apenas o DNS, enfrentará dois problemas massivos. Ou bloqueia por defeito, permitindo o acesso através de IP direto, ou bloqueia em excesso, bloqueando por completo um domínio legítimo inteiro apenas devido a um URL infrator. O bloqueio em excesso gera utilizadores frustrados e um pico nos pedidos de suporte. Isto leva-nos à Camada dois: Inspeção Profunda de Pacotes HTTP e HTTPS, especificamente a inspeção SNI. Como a grande maioria do tráfego web é encriptada via HTTPS, não consegue ver facilmente o caminho completo do URL sem desencriptar o tráfego. Ora, alguns engenheiros de rede podem sugerir a desencriptação SSL total — Inspeção SSL. Deixe-me ser claro: não faça isto numa rede pública de convidados. Exige a instalação de certificados de raiz personalizados nos dispositivos dos convidados, o que é impossível de impor, quebra a confiança do navegador e constitui uma violação massiva de privacidade. O padrão da indústria é a inspeção SNI — Server Name Indication. O SNI permite que a sua firewall analise o handshake TLS inicial e veja qual o hostname que o cliente está a solicitar antes de o túnel encriptado ser estabelecido. Ao combinar uma filtragem de DNS robusta com uma inspeção SNI avançada e categorização dinâmica de IP, pode aplicar a lista da IWF com precisão sem quebrar a encriptação ponto a ponto. Vamos falar sobre recomendações de implementação e as armadilhas que precisa de evitar. Primeiro, o problema do bypass. A sua filtragem é inútil se os utilizadores puderem simplesmente alterar as suas definições de DNS para 8.8.8.8 e contornar os seus controlos. Deve configurar os seus routers de fronteira ou firewalls para bloquear o tráfego de saída nas portas UDP e TCP 53, bem como na porta 853 para DNS over TLS. Force todos os pedidos de DNS a passar pela sua infraestrutura em conformidade. Além disso, fique atento ao DNS over HTTPS, ou DoH. Os browsers modernos utilizam cada vez mais o DoH, que encapsula as consultas de DNS em tráfego HTTPS padrão. Precisa de garantir que a sua firewall está configurada para bloquear endpoints de resolução DoH conhecidos, de modo a forçar o browser a recorrer ao seu DNS local e seguro. Segundo, o Captive Portal. O captive portal não é apenas um local para colocar o seu logótipo; é uma barreira de controlo legal. A sua Política de Utilização Aceitável, ou AUP, deve indicar explicitamente que a filtragem de conteúdos está ativa e que o acesso a material ilegal é monitorizado e bloqueado. Os utilizadores devem aceitar ativamente esta AUP antes de obterem acesso. Isto garante a sua proteção legal. Terceiro, o registo de logs. Precisa de configurar os seus sistemas para reter logs de tentativas de acesso bloqueadas, associados ao endereço MAC do dispositivo e aos dados da sessão, por um período mínimo de 12 meses. Isto está em conformidade com o GDPR e apoia as investigações das autoridades policiais caso ocorra um incidente. E, finalmente, a segmentação de rede. Nunca misture o tráfego de convidados com o tráfego operacional. A sua VLAN de Convidados deve estar estritamente isolada dos seus sistemas de Ponto de Venda ou da infraestrutura corporativa. Aplique a filtragem web rigorosa à rede de convidados, mas utilize listas de permissão estritas para a sua rede POS para garantir latência zero nas transações. Muito bem, é altura de uma sessão rápida de perguntas e respostas baseada em cenários comuns que vemos no terreno. Pergunta 1: "Podemos utilizar URLs reais da IWF para testar a nossa nova configuração de firewall?" Resposta: Absolutamente não. Aceder a esses URLs é ilegal. A IWF fornece URLs de teste específicos e seguros, concebidos exclusivamente para validar se o seu motor de filtragem está a funcionar corretamente. Utilize esses. Pergunta 2: "A nossa equipa de marketing quer uma rede WiFi aberta 'sem fricção' e sem captive portal. Isto está em conformidade?" Resposta: Não. Sem um captive portal, não pode aplicar a Política de Utilização Aceitável, o que significa que não tem qualquer acordo legal com o utilizador. Isto expõe o espaço a uma responsabilidade civil significativa. Pergunta 3: "O que fazemos em relação aos convidados que utilizam VPNs?" Resposta: Em ambientes como hotéis, os viajantes de negócios precisam de VPNs. Não pode bloqueá-las a todas. No entanto, deve monitorizar a existência de túneis encriptados contínuos e excessivos que contornem as portas padrão, o que pode indicar abuso em vez de um acesso corporativo legítimo. Vamos resumir os próximos passos. A conformidade não é um centro de custos; é proteção de marca. O dano reputacional de o seu espaço ser associado a conteúdos ilegais supera em muito os custos de implementação. Para fazer isto corretamente: 1. Verifique se o seu fornecedor de filtragem web é um membro ativo da IWF. 2. Implemente filtragem de dupla camada utilizando DNS seguro e inspeção SNI. 3. Bloqueie as portas de DNS de saída para evitar desvios. 4. Imponha uma AUP através de um Captive Portal. 5. Conserve os seus registos durante 12 meses. Se seguir estes passos, irá construir uma rede que não é apenas de alto desempenho, mas fundamentalmente segura e em conformidade. Obrigado por se juntar a este Purple Enterprise IT Briefing. Para diagramas de arquitetura mais detalhados e listas de verificação de implementação, consulte o guia técnico completo. Mantenha-se seguro e até à próxima.