Autenticação de Certificado WiFi: Como os Certificados Digitais Protegem as Redes Sem Fios

Autenticação WiFi por Certificado: Como os Certificados Digitais Protegem as Redes Sem Fios. Uma Apresentação Técnica da Purple. Introdução e Contexto. Bem-vindo à série de Apresentações Técnicas da Purple. Sou o vosso anfitrião e hoje vamos abordar um dos tópicos mais importantes - e frequentemente incompreendidos - na segurança de redes empresariais: a autenticação 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, esta apresentação é diretamente relevante para o seu estado de segurança atual. Permitam-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 alterá-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 têm feito isto há mais de uma década e, se ainda não fez a transição, esta apresentação dar-lhe-á a clareza necessária para tomar essa decisão. Então - o que é exatamente a autenticação WiFi por certificado, porque é que importa e como é que a implementa na prática? Vamos a isso. Mergulho Técnico Profundo. Comecemos pelos fundamentos. Um certificado digital, no contexto da autenticação WiFi, é uma credencial digital X.509 - essencialmente um documento assinado criptograficamente que comprova a identidade de um dispositivo ou de um utilizador. Pense nele como um passaporte para o ponto final da sua rede. Ao contrário de uma palavra-passe, que é um segredo partilhado que pode ser roubado, adivinhado ou exposto, 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 forçá-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 - a âncora de confiança final. Abaixo desta, tem normalmente uma ou mais Autoridades de Certificação Intermédias, que emitem efetivamente os certificados de entidade final para dispositivos e utilizadores. Esta hierarquia importa porque significa que a sua Autoridade de Certificação de Raiz pode ser mantida completamente offline e isolada, reduzindo drasticamente a sua superfície de ataque. Se uma Autoridade de Certificação Intermédia for comprometida, revoga-a sem tocar na Raiz. Agora, como é que isto funciona realmente numa rede WiFi? A pilha de protocolos é a norma IEEE 802.1X - o padrão de controlo de acesso à rede baseado 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 WiFi empresarial. Aqui está o fluxo de autenticação. Quando um dispositivo cliente tenta ligar-se ao seu SSID corporativo, o ponto de acesso - atuando como o que o 802.1X chama de Autenticador - não concede acesso à rede imediatamente. 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. Em simultâneo - 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 cria 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. Vamos falar 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 da 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. O registo de certificados - a colocação inicial de certificados nos dispositivos - é gerido através de protocolos como o SCEP, o Simple Certificate Enrolment Protocol, ou EST, Enrolment over Secure Transport, que é o substituto mais moderno. Num ambiente Microsoft, normalmente utilizaria os Active Directory Certificate Services com Group Policy para registar automaticamente os 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 contínuo e seguro 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 engagement em cima de 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 são logicamente separados, com políticas de firewall adequadas entre eles. Isto é inegociável para a conformidade com o PCI-DSS se processa pagamentos com cartão em qualquer local próximo da sua infraestrutura sem fios, e é fortemente recomendado para a conformidade com o GDPR, dados os dados que está a processar em ambas as redes. Recomendações de Implementação e Armadilhas. Permita-me dar-lhe as orientações práticas de implementação - e as armadilhas em que vejo as organizações cair 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 o seu failover. Já vi organizações implementarem o 802.1X corretamente e depois descobrirem, durante uma falha, que o seu failover de RADIUS não estava configurado nos pontos de acesso. Terceiro, os períodos de validade dos certificados têm de estar alinhados com os seus ciclos de atualização de 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 no certificado de forma diferente. O iOS exige que o certificado 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 cada classe de dispositivo antes do lançamento. A quinta armadilha é a disponibilidade de OCSP. Se o seu responder OCSP for interno e um cliente não conseguir aceder-lhe durante a autenticação - talvez porque se está a ligar pela primeira vez e ainda não tem acesso à rede - a autenticação pode falhar ou reverter para CRL. Desenhe a sua infraestrutura OCSP para ser acessível a partir do estado pré-autenticação, ou configure o seu servidor RADIUS para colocar em cache as respostas OCSP adequadamente. Perguntas e Respostas Rápidas. Deixe-me abordar as perguntas que me fazem com mais frequência. Pergunta: Podemos usar a autenticação por certificado juntamente com o nosso portal de WiFi de convidados existente? Com certeza. São SSIDs separados com mecanismos de autenticação separados. Os seus utilizadores corporativos autenticam-se através de 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 o dispositivo tentar ligar-se, o servidor RADIUS verifica o estado de revogação e rejeita a ligação. Com OCSP, isto pode ser quase em tempo real. Com 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 o uso 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 conformidade com o PCI-DSS? Positivamente. O Requisito 1 e o Requisito 8 do PCI-DSS beneficiam da 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 uma pista de auditoria clara 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 compreendido: desenhe a sua hierarquia de PKI, implemente uma infraestrutura RADIUS redundante, integre com o seu MDM para distribuição de certificados, configure os seus pontos de acesso para 802.1X e teste 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 WiFi num ativo de negócio e não apenas num serviço público. Se está a avaliar a sua atual postura de autenticação, o ponto de partida correto é uma auditoria à sua configuração de SSID existente e uma revisão da preparaçã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 uma implementação completa. 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.