WiFi Certificate Authentication: How Digital Certificates Secure Wireless Networks

Autenticação de WiFi por Certificado: Como os Certificados Digitais Protegem as Redes Sem Fios. Um Briefing Técnico da Purple. Introdução e Contexto. Bem-vindo à série de Briefings Técnicos da Purple. Sou o vosso anfitrião e hoje vamos abordar um dos temas mais importantes — e frequentemente mal compreendidos — na segurança de redes empresariais: a autenticação de WiFi por certificado. Se gere um grupo hoteleiro, uma cadeia de retalho, um centro de conferências ou qualquer organização onde tanto os funcionários como os convidados se ligam à sua infraestrutura sem fios, este briefing é diretamente relevante para a sua postura de segurança neste exato momento. Deixem-me enquadrar o cenário. A abordagem tradicional para proteger o WiFi corporativo tem sido uma chave pré-partilhada — uma palavra-passe que todos conhecem, que é escrita em quadros brancos, partilhada em canais do Slack e que, francamente, nunca muda porque mudá-la significaria atualizar todos os dispositivos da empresa. Esse modelo está ultrapassado. Sempre esteve. A autenticação baseada em certificados é a forma como as redes empresariais sérias fazem isto há mais de uma década e, se ainda não fez a transição, este briefing dar-lhe-á a clareza necessária para tomar essa decisão. Então — o que é exatamente a autenticação de WiFi por certificado, porque é que importa e como é que a implementa na prática? Vamos a isso. Análise Técnica Detalhada. Comecemos pelos fundamentos. Um certificado digital, no contexto da autenticação WiFi, é uma credencial digital X.509 — essencialmente um documento assinado criptograficamente que prova a identidade de um dispositivo ou de um utilizador. Pense nele como um passaporte para o endpoint da sua rede. Ao contrário de uma palavra-passe, que é um segredo partilhado que pode ser roubado, adivinhado ou divulgado, um certificado está matematicamente associado a uma chave privada específica que nunca sai do dispositivo. Não é possível fazer phishing de um certificado. Não é possível decifrá-lo por força bruta. E, fundamentalmente, pode revogá-lo no momento em que um dispositivo é perdido ou um funcionário sai da empresa. A estrutura subjacente que faz isto funcionar chama-se PKI — Infraestrutura de Chaves Públicas. A PKI é uma hierarquia de confiança. No topo encontra-se uma Autoridade de Certificação de Raiz (Root CA) — a âncora de confiança final. Abaixo desta, existem normalmente uma ou mais Autoridades de Certificação Intermédias, que emitem efetivamente os certificados de entidade final para dispositivos e utilizadores. Esta hierarquia é importante porque significa que a sua Root CA pode ser mantida completamente offline e isolada, reduzindo drasticamente a sua superfície de ataque. Se uma CA Intermédia for comprometida, pode revogá-la sem tocar na Root. Agora, como é que isto funciona realmente numa rede WiFi? A pilha de protocolos é a IEEE 802.1X — a norma de controlo de acesso à rede baseada em portas — combinada com EAP-TLS, que significa Extensible Authentication Protocol com Transport Layer Security. Este é o padrão de excelência para a segurança de WiFi empresarial. Aqui está o fluxo de autenticação. Quando um dispositivo cliente tenta ligar-se ao seu SSID corporativo, o ponto de acesso — agindo como o que o 802.1X chama de Autenticador — não concede acesso imediato à rede. Em vez disso, faz o proxy de uma conversação EAP entre o cliente e o seu servidor RADIUS, que é o Servidor de Autenticação na terminologia 802.1X. O cliente apresenta o seu certificado. O servidor RADIUS valida esse certificado em relação à sua PKI — verificando a cadeia de assinaturas, o período de validade e o estado de revogação. Simultaneamente — e esta é a parte que torna o EAP-TLS genuinamente superior à maioria dos outros métodos EAP — o cliente também valida o certificado do servidor. Esta autenticação mútua previne ataques de pontos de acesso falsos, onde um atacante configura uma rede WiFi falsa para recolher credenciais. Com o EAP-TLS, ambas as partes provam a sua identidade antes que um único byte de dados seja transmitido. Assim que a autenticação mútua é bem-sucedida, o servidor RADIUS envia uma mensagem Access-Accept para o ponto de acesso, e o cliente é colocado no segmento de rede apropriado — quer seja a VLAN corporativa, um segmento de convidados restrito ou um grupo de políticas específico com base nos atributos do certificado. Falemos sobre o ciclo de vida dos certificados, porque é aqui que muitas implementações enfrentam fricção operacional. Os certificados são emitidos, têm um período de validade — normalmente de um a três anos para certificados de dispositivos — e devem ser renovados antes de expirarem. Também podem ser revogados antes de expirarem se um dispositivo for roubado ou desativado. A revogação é gerida através de dois mecanismos: CRL, ou Listas de Revogação de Certificados, que são listas publicadas periodicamente de números de série de certificados revogados; e OCSP, o Online Certificate Status Protocol, que permite a verificação de revogação em tempo real. Para grandes implementações empresariais, o OCSP é fortemente preferido porque os ficheiros CRL podem tornar-se muito grandes e introduzir latência. A inscrição de certificados — colocar os certificados nos dispositivos em primeiro lugar — é gerida através de protocolos como o SCEP, o Simple Certificate Enrolment Protocol, ou o EST, Enrolment over Secure Transport, que é o substituto mais moderno. Num ambiente Microsoft, normalmente utilizaria os Active Directory Certificate Services com Políticas de Grupo para inscrever automaticamente certificados em máquinas associadas ao domínio. Para cenários de gestão de dispositivos móveis, a sua plataforma MDM — quer seja o Intune, o Jamf ou outra solução — gere a distribuição de certificados como parte do perfil de configuração do dispositivo. Agora, onde é que isto se cruza com o WiFi de convidados? Esta é uma distinção importante. A autenticação por certificado é, principalmente, um controlo de rede corporativa. Os seus convidados não vão ter certificados emitidos pela PKI da sua empresa. Para o acesso de convidados, opera-se num modelo de autenticação diferente — tipicamente um Captive Portal com login social, registo por e-mail ou, cada vez mais, Passpoint e OpenRoaming, que utilizam certificados ao nível da infraestrutura para permitir um roaming seguro e contínuo entre locais. A plataforma da Purple situa-se precisamente nesse espaço de WiFi de convidados, fornecendo a captura de identidade, análise e a camada de envolvimento sobre uma infraestrutura sem fios segura. O princípio arquitetónico fundamental é a segmentação de rede: o seu SSID corporativo autenticado por certificado e o seu SSID de WiFi de convidados estão logicamente separados, com políticas de firewall adequadas entre eles. Isto é não negociável para a conformidade com o PCI DSS se estiver a processar pagamentos com cartão em qualquer ponto próximo da sua infraestrutura sem fios, e é fortemente recomendado para a conformidade com o GDPR, dados os dados que está a gerir em ambas as redes. Recomendações de Implementação e Erros Comuns. Permita-me dar-lhe orientações práticas de implementação — e os erros comuns que vejo as organizações cometerem repetidamente. Primeiro, planeie a sua PKI antes de tocar num único ponto de acesso. O erro mais comum é implementar a autenticação por certificado com uma estrutura de CA plana e de nível único. Implemente sempre, pelo menos, uma hierarquia de dois níveis com uma Root CA offline. O esforço operacional é mínimo; o benefício de segurança é substancial. Segundo, acerte na sua infraestrutura RADIUS. Um único servidor RADIUS é um ponto único de falha. Implemente, no mínimo, dois servidores RADIUS numa configuração ativo-passivo ou ativo-ativo, e teste a sua tolerância a falhas. Já vi organizações implementarem o 802.1X corretamente e depois descobrirem, durante uma falha de energia, que a tolerância a falhas do RADIUS não estava configurada nos pontos de acesso. Terceiro, os períodos de validade dos certificados precisam de estar alinhados com os ciclos de atualização do seu MDM. Se o seu MDM força a renovação de certificados num ciclo de 90 dias, mas os seus certificados têm uma validade de 12 meses, terá uma lacuna. Automatize a renovação e crie alertas para 60 dias antes da expiração. Quarto — e isto apanha as pessoas de surpresa — o iOS e o Android gerem a confiança nos certificados de forma diferente. O iOS exige que o certificado da Root CA seja explicitamente confiado pelo utilizador na primeira ligação, a menos que seja enviado via MDM. O comportamento do Android varia consoante a versão e o fabricante. Teste a experiência do cliente em todas as classes de dispositivos antes do lançamento. O quinto erro comum é a disponibilidade do OCSP. Se o seu respondedor OCSP for interno e um cliente não conseguir aceder-lhe durante a autenticação — talvez por se estar a ligar pela primeira vez e ainda não ter acesso à rede — a autenticação pode falhar ou reverter para CRL. Desenhe a sua infraestrutura OCSP para ser acessível a partir do estado de pré-autenticação, ou configure o seu servidor RADIUS para colocar em cache as respostas OCSP de forma adequada. Perguntas e Respostas Rápidas. Deixe-me analisar as perguntas que me fazem com mais frequência. Pergunta: Podemos utilizar a autenticação por certificado juntamente com o nosso portal de WiFi de convidados existente? Absolutamente. São SSIDs separados com mecanismos de autenticação separados. Os seus utilizadores corporativos autenticam-se via EAP-TLS; os seus convidados passam pelo fluxo do Captive Portal. A Purple trata do lado dos convidados; a sua infraestrutura RADIUS trata do lado corporativo. Pergunta: O que acontece quando um dispositivo é perdido ou roubado? Revoga o certificado imediatamente através da sua consola de gestão de CA. Da próxima vez que esse dispositivo tentar ligar-se, o servidor RADIUS verifica o estado de revogação e rejeita a ligação. Com o OCSP, isto pode ser quase em tempo real. Com a CRL, depende do seu intervalo de publicação de CRL — normalmente horas. É por isso que o OCSP é preferido para ambientes de alta segurança. Pergunta: O EAP-TLS é compatível com WPA3? Sim. O WPA3-Enterprise exige a utilização do modo de segurança de 192 bits para as implementações mais sensíveis, e o EAP-TLS é totalmente compatível. Na verdade, o WPA3-Enterprise com EAP-TLS é a configuração de maior segurança disponível para WiFi empresarial atualmente. Pergunta: Como é que isto afeta a nossa postura de conformidade com o PCI DSS? Positivamente. O Requisito 1 e o Requisito 8 do PCI DSS beneficiam de autenticação baseada em certificados. Eliminar chaves pré-partilhadas partilhadas remove uma constatação de auditoria significativa, e a identidade por dispositivo significa que tem um registo de auditoria claro de qual dispositivo acedeu a qual segmento de rede e quando. Resumo e Próximos Passos. Para resumir: a autenticação por certificado WiFi via 802.1X e EAP-TLS é a abordagem correta para qualquer organização que leve a sério a segurança da sua rede. Elimina segredos partilhados, fornece autenticação mútua, permite um controlo de acesso granular e integra-se perfeitamente com a sua infraestrutura de identidade existente. O caminho de implementação é bem conhecido: desenhar a sua hierarquia PKI, implementar infraestrutura RADIUS redundante, integrar com o seu MDM para distribuição de certificados, configurar os seus pontos de acesso para 802.1X e testar exaustivamente em todo o seu parque de dispositivos. Para a sua rede de convidados, essa é uma conversa separada — e é aí que plataformas como a Purple acrescentam valor real, proporcionando-lhe uma integração de convidados segura e em conformidade, com as capacidades de análise e envolvimento que transformam a sua infraestrutura de WiFi num ativo de negócio em vez de apenas um serviço utilitário. Se está a avaliar a sua postura de autenticação atual, o ponto de partida correto é uma auditoria à sua configuração de SSID existente e uma revisão da prontidão da sua infraestrutura de certificados. A partir daí, uma implementação faseada — começando com um grupo piloto de dispositivos geridos — é o caminho de menor risco para a implementação total. Obrigado por ouvir este Purple Technical Briefing. Para mais leituras, consulte os nossos guias sobre segurança de WiFi empresarial e os métodos de autenticação WiFi mais seguros no website da Purple em purple.ai.