Gestão de Certificados Digitais para Autenticação WiFi EAP-TLS

Fale em inglês britânico com um tom confiante, autoritário e conversacional - como um consultor sénior a fazer um briefing a um cliente. Ritmo compassado, dicção clara, caloroso mas direto. Pausas naturais ocasionais para ênfase: Bem-vindo à série de briefings técnicos da Purple. Hoje falamos sobre a gestão de certificados EAP-TLS - especificamente, como executar um programa de autenticação WiFi baseado em certificados em escala sem que isso se torne um fardo operacional a tempo inteiro. [medium pause] Se é responsável pelo WiFi corporativo ou de colaboradores em vários locais - quer se trate de um grupo hoteleiro, de uma rede de retalho, de um campus universitário ou de instalações do setor público - este briefing é para si. Vamos cobrir todo o ciclo de vida dos certificados: desde a configuração da sua hierarquia de CA, passando pela implementação automatizada via SCEP e MDM, até à renovação e revogação. E falaremos sobre onde as coisas correm mal, porque correm mal, e como evitar as armadilhas mais comuns. [medium pause] Comecemos pelos fundamentos. O EAP-TLS - ou seja, Extensible Authentication Protocol com Transport Layer Security - é o padrão de excelência para a autenticação WiFi 802.1X. Ao contrário do PEAP, que depende de um nome de utilizador e palavra-passe, o EAP-TLS utiliza autenticação mútua baseada em certificados. O dispositivo prova a sua identidade com um certificado de cliente. O servidor RADIUS prova a sua identidade com um certificado de servidor. Ambos os lados verificam o outro. Sem palavras-passe para fazer phishing. Sem credenciais para roubar. É por isso que o PCI DSS 4.0 e as orientações de zero-trust do NCSC apontam para a autenticação baseada em certificados para redes de colaboradores. [medium pause] Agora, a arquitetura. Precisa de três coisas para fazer o EAP-TLS funcionar. Primeiro, uma Public Key Infrastructure - a sua hierarquia de CA. Segundo, um mecanismo para colocar certificados nos dispositivos - ou seja, o SCEP ou a sua plataforma MDM. Terceiro, um servidor RADIUS que confie na sua CA e consiga validar certificados de cliente em tempo real. [medium pause] A hierarquia de CA é onde a maioria das organizações se depara com problemas logo de início. O padrão correto é um modelo de três níveis. Tem uma Root CA no topo - esta deve estar offline, isolada da rede (air-gapped) e apenas ser ligada online para assinar o seu certificado de CA Intermédia. A CA Intermédia - por vezes designada por CA Emissora - é a que realmente assina os certificados do dia a dia. Está online, mas a sua chave privada está bem protegida. Abaixo disso, emite dois tipos de certificado: certificados de servidor para a sua infraestrutura RADIUS e certificados de cliente para os seus dispositivos e utilizadores. [medium pause] Porque é que isto importa? Porque se a sua Root CA for comprometida, terá de reconstruir toda a sua PKI do zero e registar novamente cada dispositivo. Mantê-la offline elimina esse risco. A CA Intermédia pode ser substituída sem tocar na Root. Esse é o argumento de resiliência operacional para o modelo de três níveis. [medium pause] Falemos sobre os períodos de validade dos certificados. Tem havido uma mudança significativa no setor neste aspeto. A Apple, a Google e a Mozilla passaram todas a impor tempos de vida máximos mais curtos para os certificados. Para certificados de servidor TLS, o máximo é agora de 398 dias. Para certificados de cliente em WiFi empresarial, existe maior flexibilidade — um a dois anos é comum —, mas a tendência é para tempos de vida mais curtos e renovação automatizada, em vez de certificados de longa duração geridos manualmente. A razão é simples: um tempo de vida mais curto limita a janela de exposição caso um certificado seja comprometido. [medium pause] Isto leva-nos à automatização. A gestão manual de certificados não é escalável. Se tiver 500 dispositivos, consegue gerir as renovações manualmente no limite. Se tiver 5000 dispositivos em 50 locais, não consegue. Necessita do SCEP — o Simple Certificate Enrolment Protocol — ou do seu sucessor moderno, o EST. O SCEP integra-se diretamente com plataformas MDM, incluindo o Microsoft Intune, o Jamf Pro e o VMware Workspace ONE. O MDM envia um perfil de configuração SCEP para o dispositivo. O dispositivo gera um par de chaves, envia um pedido de assinatura de certificado para o seu servidor SCEP e recebe de volta um certificado assinado — tudo sem qualquer interação do utilizador. [medium pause] Para dispositivos Windows num ambiente Active Directory, tem uma alternativa: a inscrição automática orientada por Políticas de Grupo através dos Active Directory Certificate Services. O dispositivo autentica-se no domínio, a CA emite um certificado automaticamente e o certificado é renovado antes de expirar, sem qualquer intervenção manual. Este é o caminho mais simples para infraestruturas maioritariamente compostas por Windows. [medium pause] Agora, a revogação. Esta é a vertente na qual as organizações costumam desinvestir mais, e é a que mais importa quando algo corre mal. Se um dispositivo for perdido ou roubado, ou se um colaborador sair da empresa, é necessário revogar o seu certificado de imediato. Existem dois mecanismos: CRL — Certificate Revocation Lists — e OCSP — Online Certificate Status Protocol. [medium pause] O CRL é o mecanismo mais antigo. A sua CA publica uma lista de números de série de certificados revogados num URL conhecido. O servidor RADIUS descarrega esta lista periodicamente e faz a verificação com base nela. O problema do CRL é a latência — se a sua CRL tiver um período de validade de 24 horas, um certificado revogado ainda poderá autenticar-se até 24 horas após a revogação. [medium pause] O OCSP é a alternativa em tempo real. O servidor RADIUS envia uma consulta ao responder OCSP para cada tentativa de autenticação e obtém uma resposta em tempo real sobre se está válido ou revogado. A desvantagem é que o seu responder OCSP torna-se uma dependência crítica — se estiver indisponível, terá de decidir se permite o acesso em caso de falha (fail open) ou se o bloqueia (fail closed). Para ambientes de alta segurança, bloquear o acesso (fail closed) é a resposta correta. Para ambientes operacionais onde a disponibilidade é fundamental, poderá configurar um curto período de tolerância do OCSP. [medium pause] Permita-me apresentar-lhe dois cenários concretos para tornar isto mais prático. [medium pause] Primeiro: um grupo hoteleiro com 150 propriedades. Estavam a utilizar PEAP com uma palavra-passe partilhada para o WiFi da equipa. A rotação de palavras-passe era trimestral, o que significava uma janela de duas semanas a cada trimestre em que os funcionários ficavam sem acesso ou utilizavam a palavra-passe antiga. Mudaram para EAP-TLS utilizando o Microsoft Intune para a implementação de certificados. Os perfis SCEP foram enviados para todos os dispositivos Windows e iOS. Active Directory Certificate Services como CA. O resultado: zero eventos de rotação de palavras-passe, renovação de certificados processada automaticamente 30 dias antes da expiração e, quando um colaborador saía, o seu certificado era revogado no MDM poucos minutos após a sua conta ser desativada no Microsoft Entra ID. A equipa de TI estimou que poupou aproximadamente 40 horas por trimestre em reposições de palavras-passe e pedidos de suporte. [medium pause] Segundo: uma cadeia de retalho multi-site com 3000 dispositivos de funcionários em 200 lojas. O desafio aqui era a diversidade de dispositivos – uma mistura de portáteis Windows, terminais portáteis Android e dispositivos iOS. Utilizavam o Jamf Pro para dispositivos Apple e o Microsoft Intune para Windows e Android, ambos a apontar para o mesmo servidor SCEP suportado por uma CA Intermédia ADCS da Microsoft. A infraestrutura WiFi era Cisco Meraki, com a autenticação RADIUS a ser processada por um serviço RADIUS alojado na nuvem integrado com a Purple. A principal decisão de design foi emitir certificados com uma validade de 12 meses e configurar a renovação automática para 60 dias antes da expiração. Isto proporcionou uma janela de renovação confortável sem criar sobrecarga operacional. [medium pause] Agora, as armadilhas. Há quatro que vejo consistentemente. [medium pause] Primeiro: não testar a revogação. As organizações configuram a sua PKI, implementam certificados e nunca chegam a testar se a revogação funciona de ponta a ponta. Teste-o. Revoque um certificado de teste, confirme se o servidor RADIUS deteta a revogação dentro do prazo esperado e confirme se o acesso ao dispositivo é negado. [medium pause] Segundo: picos de expiração em simultâneo. Se emitir todos os seus certificados ao mesmo tempo com o mesmo período de validade, todos expiram ao mesmo tempo. Distribua a sua emissão ou, no mínimo, distribua os gatilhos de renovação. Uma taxa de falha de renovação de 10% em 5000 dispositivos em simultâneo é um incidente significativo. [medium pause] Terceiro: não distribuir o certificado da Root CA para todos os dispositivos antes de implementar o EAP-TLS. Se o dispositivo não confiar na sua Root CA, rejeitará o certificado do servidor RADIUS e a autenticação falhará. Isto parece óbvio, mas apanha as organizações desprevenidas quando têm dispositivos BYOD ou computadores portáteis de subcontratados que não estão registados no MDM. [medium pause] Quarto: disponibilidade do respondedor OCSP. Se o seu respondedor OCSP falhar e o seu servidor RADIUS estiver configurado para bloquear em caso de erros de OCSP, toda a sua rede WiFi deixa de funcionar. Crie redundância na sua infraestrutura OCSP ou configure um curto período de tolerância com a monitorização adequada. [medium pause] Muito bem, perguntas rápidas. [medium pause] Posso utilizar uma CA pública para certificados de cliente EAP-TLS? Tecnicamente sim, mas na prática não. As CAs públicas não emitem certificados de cliente para dispositivos arbitrários. Precisa da sua própria CA para certificados de cliente. Para o certificado de servidor RADIUS, uma CA pública serve perfeitamente e simplifica a distribuição de confiança. [medium pause] E quanto ao BYOD? O BYOD é o caso mais complexo. Não é possível enviar certificados para dispositivos não geridos através de MDM. As opções incluem um portal de controlo de acessos à rede que emite certificados de curta duração após a autenticação do utilizador, ou simplesmente manter o BYOD num SSID separado com um método de autenticação diferente. [medium pause] Como é que isto interage com o WPA3? O WPA3-Enterprise exige um modo de segurança de 192 bits para ambientes sensíveis, o que requer conjuntos de cifras específicos. O EAP-TLS é totalmente compatível com o WPA3-Enterprise e é, de facto, o método de autenticação recomendado. [medium pause] Em resumo. A gestão de certificados EAP-TLS não é simples, mas é viável se definir a arquitetura correta desde o início. Hierarquia de CA de três níveis. Atribuição automatizada através de SCEP ou MDM. Certificados de curta duração com renovação automatizada. Revogação em tempo real via OCSP. Teste tudo, especialmente a revogação. E integre o ciclo de vida dos seus certificados com o seu fornecedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - para que a revogação do certificado seja acionada automaticamente quando uma conta é desativada. [medium pause] Se estiver a executar servidores RADIUS associados à Purple, os pontos de integração são o URL do seu servidor SCEP, o certificado do seu servidor RADIUS e o seu endpoint CRL ou OCSP. A arquitetura independente de hardware da Purple significa que isto funciona em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e no resto da lista de hardware canónico — não fica dependente das ferramentas de PKI de um único fornecedor. [medium pause] Próximos passos: audite o seu inventário de certificados atual. Se não sabe quantos certificados tem, quando expiram e quem os emitiu, essa é a primeira coisa a resolver. A partir daí, o caminho para a automatização total está bem definido. Obrigado por ouvir.