Gerir 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 dar orientações a um cliente. Ritmo medido, dicção clara, caloroso mas direto. Pausas naturais ocasionais para dar ênfase: Bem-vindo à série de briefings técnicos da Purple. Hoje estamos a falar sobre a gestão de certificados EAP-TLS - especificamente, como executar um programa de autenticação WiFi baseado em certificados em escala sem que este se torne um fardo operacional a tempo inteiro. [pausa média] Se é responsável pelo WiFi corporativo ou de funcionários em vários locais - quer se trate de um grupo hoteleiro, uma rede de retalho, um campus universitário ou instalações do setor público - este briefing é para si. Vamos cobrir o ciclo de vida completo do certificado: 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 vamos falar sobre onde as coisas correm mal, porque elas correm mal, e como evitar as armadilhas mais comuns. [pausa média] Comecemos pelos aspetos fundamentais. 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 palavra-passe para pescar (phishing). Sem credenciais para roubar. É por isso que o PCI-DSS 4.0 e as diretrizes de zero-trust do NCSC apontam para a autenticação baseada em certificados para redes de funcionários. [pausa média] Agora, a arquitetura. Precisa de três coisas para fazer o EAP-TLS funcionar. Primeiro, uma Infraestrutura de Chaves Públicas - a sua hierarquia de CA. Segundo, um mecanismo para colocar os certificados nos dispositivos - ou seja, o SCEP ou a sua plataforma MDM. Terceiro, um servidor RADIUS que confie na sua CA e consiga validar os certificados de cliente em tempo real. [pausa média] A hierarquia de CA é onde a maioria das organizações se depara com problemas logo no início. O modelo correto é um modelo de três níveis. Tem uma CA de Raiz (Root CA) no topo - esta deve estar offline, isolada da rede (air-gapped) e apenas ser colocada online para assinar o seu certificado de CA Intermédia. A CA Intermédia - por vezes chamada de CA Emissora - é a que assina efetivamente 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. [pausa média] Porque é que isto importa? Porque se a sua CA de Raiz for comprometida, terá de reconstruir toda a sua PKI do zero e registar novamente todos os dispositivos. Mantê-la offline elimina esse risco. A CA Intermédia pode ser substituída sem tocar na Raiz. Esse é o argumento de resiliência operacional para o modelo de três níveis. [pausa média] Vamos falar sobre os períodos de validade dos certificados. Tem havido uma mudança significativa na indústria nesta área. A Apple, o Google e a Mozilla passaram 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 é o comum - mas a tendência aponta para tempos de vida mais curtos e renovação automatizada, em vez de certificados de longa duração geridos manualmente. O motivo é 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 5.000 dispositivos em 50 locais, não consegue. Precisa do SCEP - o Simple Certificate Enrolment Protocol - ou do seu sucessor moderno, o EST. O SCEP integra-se diretamente com plataformas de 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 de Active Directory, dispõe de uma alternativa: a inscrição automática baseada em Políticas de Grupo através dos Active Directory Certificate Services. O dispositivo autentica-se no domínio, a autoridade de certificação emite um certificado automaticamente e o certificado é renovado antes de expirar, sem qualquer intervenção manual. Este é o caminho mais simples para parques informáticos predominantemente Windows. [medium pause] Agora, a revogação. Esta é a vertente em que as organizações menos investem e é a que mais importa quando algo corre mal. Se um dispositivo for perdido ou roubado, ou se um funcionário sair da empresa, é necessário revogar o seu certificado imediatamente. Existem dois mecanismos: CRL - Certificate Revocation Lists - e OCSP - Online Certificate Status Protocol. [medium pause] O CRL é o mecanismo mais antigo. A sua autoridade de certificação publica uma lista de números de série de certificados revogados num URL conhecido. O servidor RADIUS descarrega periodicamente esta lista e faz a verificação com base nela. O problema do CRL é a latência - se o seu CRL tiver um período de validade de 24 horas, um certificado revogado ainda pode 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 respondedor OCSP para cada tentativa de autenticação e obtém uma resposta em direto de válido ou revogado. O reverso da medalha é que o seu respondedor OCSP torna-se uma dependência crítica - se estiver indisponível, terá de decidir se permite o acesso ou se bloqueia o acesso por predefinição. Para ambientes de alta segurança, bloquear o acesso é a resposta certa. 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 de 150 propriedades. Estavam a utilizar PEAP com uma palavra-passe partilhada para o WiFi dos funcionários. 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 bloqueados ou a utilizar a palavra-passe antiga. Mudaram para EAP-TLS utilizando o Microsoft Intune para a implementação de certificados. Perfis SCEP 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 tratada automaticamente 30 dias antes da expiração e, quando um funcionário 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 redefiniçõ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 computadores portáteis Windows, dispositivos portáteis Android e dispositivos iOS. Utilizaram 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 Microsoft ADCS Intermediate CA. A infraestrutura de WiFi era Cisco Meraki, com a autenticação RADIUS a ser tratada por um serviço RADIUS alojado na nuvem e integrado com a Purple. A principal decisão de design foi emitir certificados com 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 constantemente. [medium pause] Primeira: não testar a revogação. As organizações configuram a sua PKI, implementam os certificados e nunca testam realmente se a revogação funciona de ponta a ponta. Teste-a. Revoque um certificado de teste, confirme se o servidor RADIUS deteta a revogação dentro da janela de tempo esperada e confirme se o acesso ao dispositivo é negado. [medium pause] Segunda: precipícios de expiração. 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 no tempo, ou pelo menos distribua os seus gatilhos de renovação. Uma taxa de falha de renovação de 10% em 5000 dispositivos em simultâneo é um incidente significativo. [medium pause] Terceira: não distribuir o certificado 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 de surpresa quando têm dispositivos BYOD ou portáteis de subempreiteiros que não estão registados no MDM. [medium pause] Quarta: disponibilidade do respondedor OCSP. Se o seu respondedor OCSP falhar e o seu servidor RADIUS estiver configurado para bloquear o acesso 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 carência com a monitorização adequada. [medium pause] Muito bem, perguntas de resposta rápida. [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 do servidor RADIUS, uma CA pública é adequada e simplifica a distribuição de confiança. [medium pause] E quanto ao BYOD? O BYOD é o caso mais difícil. Não pode enviar certificados para dispositivos não geridos através de MDM. As opções incluem um portal de controlo de acesso à 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 o modo de segurança de 192 bits para ambientes sensíveis, o qual requer pacotes 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] Para resumir. A gestão de certificados EAP-TLS não é simples, mas é gerível se estruturar a arquitetura corretamente desde o início. Hierarquia de CA de três níveis. Inscrição automatizada via SCEP ou MDM. Certificados com tempo de vida curto e 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 de certificados 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ónica - não está bloqueado às ferramentas de PKI de um único fabricante. [medium pause] Próximos passos: audite o seu inventário de certificados atual. Se não sabe quantos certificados possui, quando expiram e quem os emitiu, esse é o primeiro ponto a resolver. A partir daí, o caminho para a automatização total está bem definido. Obrigado por ouvir.