Acesso Seguro de Convidados: Implementar NAC para Dispositivos Não Geridos

Acesso Seguro de Convidados: Implementar NAC para Dispositivos Não Geridos. Um Briefing de Informação Purple WiFi. Introdução e Contexto. Bem-vindo. Se é responsável pela segurança de rede num hotel, cadeia de retalho, estádio ou local do setor público, está a lidar com um problema que se torna cada vez mais difícil: como fornecer aos convidados, visitantes e prestadores de serviços um acesso WiFi rápido e conveniente - sem abrir uma porta para a sua infraestrutura corporativa? É exatamente isso que vamos abordar hoje. Isto não é uma visão teórica. Vamos cobrir a arquitetura, as decisões de implementação, os requisitos de conformidade e os cenários do mundo real onde isto corre bem - e onde corre mal. O principal desafio é este: dispositivos não geridos. Os seus convidados estão a ligar-se com smartphones pessoais, computadores portáteis, tablets e, cada vez mais, dispositivos IoT - nenhum dos quais é controlado por si, nenhum tem o seu agente MDM instalado e todos representam um risco potencial de segurança se não forem devidamente segmentados e autenticados. O Network Access Control, ou NAC, é a estrutura que resolve isto. Vamos começar. Análise Técnica Detalhada. Primeiro, sejamos precisos sobre o que é realmente o NAC. O Network Access Control é uma estrutura de segurança que aplica o acesso baseado em políticas aos recursos de rede. Avalia quem se está a ligar, que dispositivo está a utilizar e se esse dispositivo cumpre os seus requisitos de postura de segurança - antes de conceder o acesso. Para dispositivos de convidados não geridos, a verificação de postura é necessariamente simples, mas os componentes de identidade e segmentação são críticos. A arquitetura divide-se em três camadas funcionais. A primeira é a camada de autenticação. Para dispositivos corporativos geridos, normalmente utilizaria o IEEE 802.1X com EAP-TLS, onde os certificados são enviados via SCEP através do seu MDM. Mas para dispositivos de convidados não geridos, o 802.1X não é prático - os convidados não têm certificados e não os pode enviar. Portanto, a camada de autenticação para convidados depende de um Captive Portal: uma página de autenticação baseada na web que interseta o pedido HTTP ou HTTPS inicial e redireciona o utilizador para um fluxo de login ou registo. É aqui que plataformas como a solução Guest WiFi da Purple operam - capturando a identidade através de login social, e-mail, verificação por SMS ou registo baseado em formulários, e passando essa identidade para o motor de políticas NAC. A segunda camada é o motor de políticas. É aqui que as decisões de acesso são tomadas. O sistema NAC avalia a identidade autenticada em relação às suas políticas de acesso e atribui o dispositivo ao segmento de rede apropriado. Para um convidado, isso significa tipicamente uma VLAN de convidados dedicada com acesso exclusivo à internet e sem rota para as suas sub-redes corporativas. Para um prestador de serviços com um dispositivo conhecido, pode atribuir-lhe uma VLAN restrita com acesso a recursos internos específicos. O motor de políticas também pode aplicar o acesso baseado no tempo - um delegado de uma conferência obtém acesso durante a duração do evento, um hóspede de um hotel obtém acesso durante a duração da sua estadia.A terceira camada é a aplicação. Esta é gerida na periferia da rede - os seus pontos de acesso sem fios, switches e firewall. O sistema NAC comunica com estes dispositivos via RADIUS, que é o protocolo Remote Authentication Dial-In User Service. Quando um convidado se autentica, o servidor RADIUS devolve uma mensagem Access-Accept com atributos de atribuição de VLAN, e o ponto de acesso coloca o dispositivo na VLAN correta. Se a autenticação falhar, o servidor RADIUS devolve Access-Reject, e o dispositivo permanece numa VLAN de quarentena de pré-autenticação com acesso apenas ao Captive Portal. Agora, vamos falar sobre o WPA3. Se está a implementar ou a atualizar a sua infraestrutura sem fios, o WPA3 deve estar no seu roteiro. O WPA3-SAE, que significa Simultaneous Authentication of Equals, substitui o WPA2-PSK e elimina a vulnerabilidade a ataques de dicionário offline. Especificamente para redes de convidados, o WPA3-OWE - Opportunistic Wireless Encryption - é particularmente relevante. O OWE fornece encriptação sem exigir uma palavra-passe, o que significa que os convidados obtêm uma ligação encriptada sem qualquer fricção adicional. Esta é uma melhoria significativa em relação ao tradicional SSID de convidado aberto, que transmite dados em texto simples. A conformidade não é negociável na maioria dos setores de que estamos a falar. Se gere um hotel com um sistema de ponto de venda, o PCI-DSS exige uma segmentação de rede rigorosa entre os ambientes de dados dos titulares de cartões e as redes de convidados. O requisito é explícito: o WiFi de convidados deve estar num segmento de rede separado, sem rota para o âmbito do PCI. O NAC aplica isto na camada de rede, e a política da sua firewall aplica-o no perímetro. O GDPR adiciona outra dimensão - se está a recolher dados de identidade de convidados através do seu Captive Portal, necessita de consentimento explícito, uma base legal para o processamento e uma política de retenção de dados. A plataforma da Purple lida com a recolha de consentimento em conformidade com o GDPR de forma nativa, com períodos de retenção configuráveis e registos de auditoria. Vamos também abordar a randomização de endereços MAC, porque é uma verdadeira dor de cabeça operacional. Desde o iOS 14, Android 10 e Windows 10, os dispositivos randomizam o seu endereço MAC por SSID por predefinição. Isto quebra qualquer política de NAC que dependa do endereço MAC como um identificador persistente. A resposta correta é mover o seu modelo de identidade para o utilizador autenticado, e não para o MAC do dispositivo. Quando um convidado se autentica através do seu Captive Portal, vincula a sua sessão à sua identidade autenticada - e-mail, número de telefone ou perfil social - em vez do seu endereço MAC. A plataforma de analítica da Purple lida com isto corretamente, mantendo a identidade ao nível do utilizador entre sessões, mesmo quando o endereço MAC muda. Para organizações que necessitam de uma avaliação mais rigorosa do estado do dispositivo para dispositivos não geridos, existem abordagens com e sem agente. A avaliação do estado sem agente utiliza técnicas como a identificação do SO (OS fingerprinting), análise de portas abertas e análise do user-agent HTTP para classificar os dispositivos e avaliar a conformidade básica. Isto é adequado para redes de convidados onde se pretende identificar o tipo de dispositivo para fins analíticos ou aplicar políticas diferenciadas - por exemplo, impedir que dispositivos IoT conhecidos acedam a determinados serviços. A avaliação de estado baseada em agente exige que o utilizador instale um agente temporário, o que é adequado para cenários de acesso de subempreiteiros ou parceiros, mas cria fricção para convidados ocasionais. Recomendações de Implementação e Erros Comuns. Permita-me guiar-lhe através da sequência de implementação que funciona na prática. Comece com a segmentação da rede antes de alterar a configuração do NAC. Defina as suas VLANs: uma VLAN de pré-autenticação com acesso apenas ao Captive Portal e ao DNS, uma VLAN de convidados com acesso à internet e sem rotas internas, e opcionalmente uma VLAN de subempreiteiros com acesso interno restrito. Implemente as ACLs do seu firewall. Esta é a base - tudo o resto assenta sobre ela. Em segundo lugar, implemente a sua infraestrutura RADIUS. Para a maioria das implementações de médio mercado, um serviço RADIUS alojado na nuvem e integrado com a sua plataforma de Captive Portal é a escolha certa. Elimina a sobrecarga operacional de gerir servidores RADIUS locais e fornece a redundância necessária para uma rede de convidados em produção. Certifique-se de que os segredos partilhados do RADIUS são fortes e rodados regularmente. Em terceiro lugar, configure o seu Captive Portal. O portal tem de estar acessível a partir da VLAN de pré-autenticação - o que significa que a resolução de DNS para o domínio do portal deve funcionar antes da autenticação. Configure o seu intervalo de DHCP na VLAN de pré-autenticação para apontar para um servidor DNS que resolva o domínio do portal. Teste isto com cuidado - a configuração incorreta do DNS é a causa mais comum de falhas no Captive Portal. Em quarto lugar, teste a sua atribuição de VLAN de ponta a ponta. Ligue um dispositivo de teste, conclua o fluxo de autenticação e verifique se o dispositivo entra na VLAN correta com a política de acesso correta. Utilize uma captura de pacotes para confirmar que os atributos RADIUS estão a ser transmitidos corretamente. Verifique se a VLAN de convidados não tem rota para as suas subredes corporativas - execute um traceroute a partir da VLAN de convidados para um IP corporativo e confirme que falha. Agora, as armadilhas. O modo de falha mais comum é a configuração incorreta de split-tunnel - onde a VLAN de convidados tem uma rota indesejada para recursos internos devido a uma regra de firewall mal configurada ou a uma ACL em falta. Audite as suas regras de firewall antes de entrar em produção. A segunda falha comum é o tratamento de timeout do RADIUS - se o seu servidor RADIUS estiver inacessível, o que acontece? Certifique-se de que os seus pontos de acesso estão configurados para fail-closed, não para fail-open. Fail-open significa que os convidados obtêm acesso à rede mesmo se o RADIUS estiver inativo, o que é um risco de segurança. Fail-closed significa que não há acesso se o RADIUS estiver inacessível, o que é a postura correta para uma implementação segura. A terceira armadilha é a expiração do certificado no seu captive portal. Se o certificado TLS do seu portal expirar, os convidados verão um aviso de segurança do browser e a sua taxa de autenticação cairá para quase zero. Automatize a renovação de certificados com o Let's Encrypt ou com a sua plataforma de gestão de certificados. Perguntas e Respostas Rápidas. Preciso de 802.1X para redes de convidados? Não. O 802.1X é adequado para dispositivos corporativos geridos. Para convidados não geridos, um captive portal com atribuição de VLAN baseada em RADIUS é a arquitetura correta. Posso usar um único SSID para convidados e dispositivos corporativos? Tecnicamente sim, utilizando a atribuição dinâmica de VLAN com base no resultado da autenticação. Mas operacionalmente, SSIDs separados são mais simples de gerir e mais fáceis de auditar. Mantenha-os separados. Como posso gerir dispositivos IoT que não conseguem concluir o fluxo de um captive portal? Utilize o bypass de autenticação baseado em MAC, ou MAB, para dispositivos IoT conhecidos com endereços MAC pré-registados. Para dispositivos IoT desconhecidos, coloque-os numa VLAN de quarentena e analise manualmente. Qual é o timeout de sessão correto para o acesso de convidados? Para o setor da hotelaria, alinhe com a duração da estadia do hóspede. Para o retalho, duas a quatro horas é o habitual. Para eventos, alinhe com o horário do evento. Defina sempre um timeout de inatividade - 30 minutos de inatividade é um valor padrão razoável. Devo registar o tráfego de convidados? Sim, para fins legais e de conformidade. Conserve os registos de ligação - IP de origem, carimbo de data/hora, identidade autenticada - por um período mínimo de 90 dias, ou superior se a sua jurisdição o exigir. A plataforma da Purple fornece este registo de auditoria de forma nativa. Resumo e Próximos Passos. Em resumo: o acesso seguro de convidados para dispositivos não geridos é um problema resolvido, mas exige uma arquitetura deliberada. Os três pilares são a identidade - quem se está a ligar; a segmentação - para onde podem ir; e a aplicação - como garante que a política é cumprida. O NAC une estes pilares, tendo o RADIUS como protocolo de comunicação entre a sua plataforma de autenticação e a sua infraestrutura de rede. Para os seus próximos passos: se ainda não o fez, audite a sua segmentação atual da rede de convidados. Confirme que não existem rotas da sua VLAN de convidados para as suas sub-redes corporativas. Reveja o fluxo de consentimento do GDPR e a configuração de retenção de dados do seu captive portal. E se estiver a utilizar WPA2 com um SSID de convidados aberto, coloque o WPA3-OWE no seu plano de evolução de infraestrutura.A plataforma da Purple integra-se diretamente com esta arquitetura - fornecendo o Captive Portal, a recolha de identidade, a camada de conformidade com o GDPR e as análises que assentam sobre a sua infraestrutura NAC. Se pretender ver como isto se aplica ao ambiente específico do seu espaço, a equipa da Purple pode orientá-lo através de uma arquitetura de referência para o seu caso de utilização. Obrigado por nos ouvir. Este foi um Briefing de Informação Purple WiFi sobre Acesso Seguro de Convidados: Implementar NAC para Dispositivos Não Geridos.