Conformidade com a 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: Conformidade com a IWF para Redes WiFi Públicas. Se gere infraestruturas para cadeias de retalho, locais de hotelaria, estádios ou edifícios do setor público, disponibilizar WiFi para convidados já não é apenas uma questão de largura de banda e cobertura. É uma questão de mitigação de riscos. Fornecer uma ligação aberta à Internet sem uma filtragem robusta e certificada expõe a sua organização a graves danos jurídicos e reputacionais. Hoje, vamos diretos ao assunto. Sem teorias académicas - apenas orientações práticas e neutras em termos de fornecedor sobre como arquitetar uma rede em conformidade e de alto desempenho. Vamos passar diretamente para o 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 local 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 no seu 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 está a utilizar um fornecedor que não é um membro oficial da IWF a consumir ativamente o seu feed dinâmico, não está em conformidade. Ponto final. Então, como é que estruturamos isto na prática no limite da rede? Vamos avançar para a análise técnica detalhada. A implementação da conformidade com a IWF requer uma abordagem multicamada. Não pode depender de um único ponto de estrangulamento. A camada um é a filtragem de DNS. Esta é a sua primeira linha de defesa. Quando o dispositivo de um convidado solicita um domínio CSAM conhecido, o seu DNS seguro intercepa-o e redireciona-o para uma página de bloqueio. É altamente eficiente e introduz uma latência praticamente nula. No entanto, a filtragem de DNS por si só é fundamentalmente inadequada 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 por excesso, anulando um domínio legítimo inteiro apenas por causa de um URL infrator. O bloqueio por excesso leva a utilizadores frustrados e a um aumento 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 total de SSL - Inspeção SSL. Deixe-me ser claro: não faça isto numa rede pública de convidados. Requer a instalação de certificados raiz personalizados nos dispositivos dos convidados, o que é impossível de impor, quebra a confiança do navegador e é uma violação massiva de privacidade. O padrão do setor é a inspeção SNI - Server Name Indication. O SNI permite que a sua firewall analise o handshake TLS inicial e veja qual é o hostname solicitado pelo cliente antes de o túnel encriptado ser estabelecido. Ao combinar uma filtragem de DNS robusta com a inspeção SNI avançada e a 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 os erros que deve evitar. Primeiro, o problema do desvio. A sua filtragem é inútil se os utilizadores puderem simplesmente alterar as suas configurações de DNS para 8.8.8.8 e contornar os seus controlos. Deve configurar os seus routers de periferia ou firewalls para bloquear o tráfego de saída nas portas UDP e TCP 53, bem como na porta 853 para DNS sobre TLS. Force todos os pedidos de DNS através da sua infraestrutura em conformidade. Além disso, fique atento ao DNS sobre HTTPS, ou DoH. Os browsers modernos estão a utilizar cada vez mais o DoH, que encapsula consultas DNS em tráfego HTTPS padrão. Precisa de garantir que a sua firewall está configurada para bloquear endpoints de resolução DoH conhecidos para 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 fornece-lhe uma cobertura legal. Terceiro, o registo de dados (logging). Precisa de configurar os seus sistemas para reter registos 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 ser estritamente isolada dos seus sistemas de Ponto de Venda ou da infraestrutura corporativa. Aplique a filtragem web rigorosa na rede de convidados, mas utilize listas de permissões estritas para a sua rede POS para garantir latência zero nas transações. Muito bem, hora de uma sessão rápida de Perguntas e Respostas com base em cenários comuns que vemos no terreno. Pergunta 1: "Podemos usar 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 nenhum acordo legal com o utilizador. Isso expõe o local 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 em negócios precisam de VPNs. Não pode bloqueá-las a todas. No entanto, deve monitorizar a existência de túneis encriptados excessivos e contínuos 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. Os danos de reputação associados ao seu espaço estar ligado a conteúdos ilegais superam 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 tanto DNS seguro como inspeção SNI. 3. Bloqueie as portas 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 Briefing de TI da Purple Enterprise. Para diagramas de arquitetura mais detalhados e listas de verificação de implementação, consulte o guia técnico completo. Mantenha-se seguro e encontramo-nos na próxima.