WiFi Familiar: Boas Práticas para Centros Comerciais

WiFi para Toda a Família: Melhores Práticas para Centros Comerciais Uma Sessão Técnica da Purple - Guião Completo do Podcast (aprox. 10 minutos) --- INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) Bem-vindo à série de Sessões Técnicas da Purple. Sou o vosso anfitrião e hoje vamos abordar algo que se situa mesmo na interseção entre a experiência do cliente e a cibersegurança: WiFi para toda a família em centros comerciais. Se é gestor de TI ou responsável pela CX no retalho, provavelmente já teve de responder à pergunta do seu diretor de operações: "Podemos garantir que as crianças não acedem a conteúdos inadequados na nossa rede de convidados?" Parece simples. Na prática, há várias camadas a afinar - e falhar nelas pode expor a sua organização a riscos reputacionais, escrutínio regulatório e, francamente, a algumas conversas muito desconfortáveis com os pais. Por isso, nos próximos dez minutos, quero dar-vos uma visão clara e prática do que a filtragem de URLs baseada em categorias realmente envolve, como a implementar corretamente num ambiente de retalho e qual é o caso de negócio a apresentar à administração. Vamos a isto. --- MERGULHO TÉCNICO (aprox. 5 minutos) Comecemos pelos aspetos fundamentais. Quando falamos de WiFi para toda a família, o mecanismo principal é a filtragem de DNS - especificamente, a filtragem de DNS baseada em categorias. Sempre que um dispositivo na sua rede de convidados tenta carregar um website, envia uma consulta DNS para traduzir esse nome de domínio num endereço IP. Um motor de filtragem de DNS interpõe-se nesse caminho e verifica o domínio solicitado numa base de dados categorizada. Se o domínio pertencer a uma categoria bloqueada - conteúdo adulto, apostas, distribuição de malware, partilha de ficheiros peer-to-peer - a consulta é bloqueada antes de qualquer dado ser trocado. Em vez disso, o utilizador vê uma página de bloqueio. Isto é fundamentalmente diferente da inspeção profunda de pacotes (DPI) ou da filtragem ao nível do URL na camada de aplicação. A filtragem de DNS opera na camada de rede, o que significa que é rápida, escalável e não exige que quebre a encriptação SSL para inspecionar o tráfego. Para um centro comercial com potencialmente milhares de ligações de convidados em simultâneo, essa característica de desempenho é extremamente importante. Ora, a base de dados de categorias é o componente crítico aqui. Os principais fornecedores de filtragem de DNS - e estou a ser neutro em termos de fornecedor aqui - mantêm bases de dados com dezenas de milhões de domínios, cada um associado a uma ou mais categorias de conteúdo. Estas bases de dados são atualizadas continuamente, muitas vezes em tempo quase real, à medida que novos domínios são registados e os sites existentes alteram o seu conteúdo. A sua política de filtragem é, essencialmente, um conjunto de regras: bloquear estas categorias, permitir estas categorias e sinalizar estas categorias para revisão. Para uma implementação num centro comercial, recomendo que pense na sua política de categorias em três níveis.Nível um: bloquear sempre. Isto é inegociável. Conteúdo para adultos, apostas, malware e phishing, ferramentas de contornar proxy, partilha de ficheiros peer-to-peer e discurso de ódio. Estas categorias devem ser bloqueadas em todos os SSID de convidados, ponto final. Não existe nenhuma razão comercial legítima para que uma rede de convidados de um centro comercial permita o acesso a estas categorias, e permiti-las cria uma exposição tanto reputacional como jurídica. Nível dois: dependente do contexto. Redes sociais, streaming de vídeo, plataformas de jogos, serviços de VPN - estas são categorias em que a sua decisão de política depende do seu local específico e do perfil demográfico dos seus convidados. Um centro comercial focado nas famílias pode optar por bloquear o streaming de vídeo para preservar a largura de banda para outros utilizadores. Um centro com uma zona de restauração e um público mais jovem pode permitir as redes sociais para incentivar o tempo de permanência e a partilha social. Estas são decisões comerciais tanto quanto técnicas. Nível três: permitir sempre. Domínios de retalho e compras, notícias, conteúdo educativo, mapas e navegação - estes devem ser explicitamente permitidos para garantir que os seus convidados possam fazer aquilo a que vieram: comprar, navegar e pesquisar em segurança. Agora, há uma consideração arquitetónica importante que muitas vezes é negligenciada. A sua rede WiFi de convidados deve estar completamente isolada da sua rede corporativa. Isto parece óbvio, mas já vi implementações em que o SSID de convidados e a rede administrativa partilham a mesma VLAN, o que representa um risco de segurança significativo. A sua rede de convidados deve situar-se na sua própria VLAN, com uma gama de DHCP separada, e o tráfego deve ser encaminhado através do seu motor de filtragem de DNS antes de chegar à internet. O tráfego corporativo segue um caminho completamente separado. Do lado da autenticação, para uma rede de convidados de um centro comercial, normalmente procura-se um Captive Portal com início de sessão social, registo por e-mail ou uma simples aceitação dos termos de serviço. É aqui que a sua plataforma de WiFi de convidados - algo como a Purple - adiciona um valor significativo muito além da simples conectividade. O Captive Portal é o seu ponto de recolha de dados. É onde recolhe dados primários baseados em consentimento, que são cada vez mais valiosos num mundo pós-cookies. Ao abrigo do GDPR, necessita de consentimento explícito para comunicações de marketing, e o Captive Portal é o local natural para obter e registar esse consentimento. Para a infraestrutura sem fios subjacente, o WPA3 é agora o padrão que deve visar para qualquer nova implementação ou atualização significativa. O WPA3 fornece uma encriptação mais forte e, crucialmente, protege contra ataques de dicionário offline à chave pré-partilhada. Para uma rede de convidados onde a palavra-passe é frequentemente exibida publicamente, essa proteção é importante. Se estiver a trabalhar com hardware legado que não suporta WPA3, o WPA2 com uma frase de acesso forte e regularmente rodada é a sua alternativa - mas planeie a sua atualização de hardware em conformidade. Mais um ponto técnico importante a assinalar: DNS over HTTPS, ou DoH. Cada vez mais, os browsers e sistemas operativos estão configurados para utilizar DNS encriptado por predefinição, o que significa que contornam totalmente a filtragem de DNS ao nível da rede. Uma implementação de filtragem bem configurada precisa de ter isto em conta. A solução é bloquear o tráfego da porta de saída 443 para fornecedores de DoH conhecidos ao nível da firewall, forçando toda a resolução de DNS através do seu resolvedor controlado. Este é um passo que muitas organizações ignoram, e é o motivo pelo qual a sua política de filtragem tem lacunas. - RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aprox. 2 minutos) Muito bem, vamos falar sobre como implementar isto na prática e onde as coisas costumam correr mal. A sequência de implementação que recomendo é: primeiro, audite a sua arquitetura de rede existente. Confirme que o seu SSID de convidados está devidamente isolado. Segundo, selecione o seu fornecedor de filtragem de DNS e configure a sua política de categorias. Terceiro, implemente em modo de monitorização antes do modo de aplicação - isto dá-lhe de duas a quatro semanas de dados sobre o que os seus convidados estão realmente a tentar aceder, o que muitas vezes revela surpresas e ajuda-o a ajustar a sua política antes de começar a bloquear conteúdos. Quarto, configure a sua página de bloqueio com uma mensagem clara e amigável que explique por que razão o conteúdo foi bloqueado e forneça uma forma de contacto para falsos positivos. Quinto, teste exaustivamente - utilize um dispositivo na rede de convidados e tente aceder a conteúdos em cada uma das suas categorias bloqueadas para verificar se a política está a funcionar como esperado. O erro mais comum que vejo é o bloqueio excessivo. As equipas de TI, compreensivelmente cautelosas, definem uma política inicial agressiva e depois passam semanas a lidar com reclamações sobre sites legítimos que foram bloqueados. Uma base de dados de categorias bem mantida minimiza isto, mas nenhuma base de dados é perfeita. Ter um processo claro de reporte e resolução de falsos positivos é essencial. O segundo erro é a falta de comunicação da política à gestão do espaço e aos lojistas. Se a aplicação de negócio de um lojista for bloqueada pela política da sua rede de convidados, irá receber reclamações. Comunique proactivamente a sua política de filtragem aos lojistas e tenha um processo de exceção documentado. O terceiro erro - e este é o que realmente apanha as organizações de surpresa - é não ter em conta o DNS over HTTPS, como mencionei anteriormente. Teste a sua implementação especificamente para evitar o desvio por DoH antes de entrar em produção. - PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) Vou responder rapidamente a algumas perguntas que me fazem frequentemente sobre este tema. "A filtragem de DNS afeta o desempenho da rede?" À escala, um serviço de filtragem de DNS baseado na cloud adiciona milissegundos de um único dígito de latência à resolução de DNS. Numa rede de convidados, isto é impercetível para os utilizadores. "Os convidados podem contornar o filtro utilizando uma VPN?" Se bloqueou os serviços de VPN e as ferramentas de evasão de proxy na sua política de categorias - o que deveria ter feito - então sim, isto está amplamente mitigado. Nenhum filtro é totalmente à prova de evasão, mas não está a tentar travar um adversário obstinado; está a estabelecer um padrão razoável de diligência para um local público. "Precisamos de registar as consultas de DNS para fins de conformidade?" Isto depende da sua jurisdição e das suas obrigações de conformidade específicas. Ao abrigo do Investigatory Powers Act do Reino Unido, existem requisitos de retenção de dados para operadores de WiFi público. Consulte a sua equipa jurídica, mas a maioria das plataformas de filtragem de DNS oferece capacidades de registo que podem satisfazer estes requisitos. "E quanto à inspeção HTTPS - precisamos dela?" Para uma rede de convidados com filtragem de DNS baseada em categorias, a inspeção SSL total geralmente não é necessária e introduz uma complexidade significativa e potenciais preocupações de privacidade. A filtragem de DNS ao nível do domínio é suficiente para a grande maioria dos casos de utilização. - RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) Para reunir tudo isto: o WiFi familiar num centro comercial não é um problema técnico complexo, mas exige uma arquitetura deliberada e uma estrutura de políticas bem ponderada. Os componentes principais são: uma rede de convidados devidamente isolada, um motor de filtragem de DNS baseado na nuvem com uma política de categorias bem ajustada, um Captive Portal que recolhe dados de convidados baseados em consentimento e um processo para gerir exceções e falsos positivos. O caso de negócio é simples. Está a reduzir o risco de reputação, a demonstrar o dever de diligência para com as famílias e os lojistas e - se estiver a utilizar uma plataforma como a Purple - a transformar o seu WiFi de convidados num ativo de dados primários que gera um ROI de marketing mensurável. Para os seus próximos passos: se atualmente não tem filtragem de DNS na sua rede de convidados, essa é a sua prioridade imediata. Se já tem filtragem mas não revê a sua política de categorias nos últimos doze meses, agende essa revisão agora. E se está a planear uma atualização de rede, aproveite a oportunidade para implementar WPA3 e uma plataforma moderna de WiFi de convidados de ponta a ponta. Obrigado por nos ouvir. Encontrará o guia escrito completo, diagramas de arquitetura e exemplos práticos em purple.ai. Até à próxima. - FIM DO SCRIPT