Gerir Certificados Digitais para Autenticação WiFi EAP-TLS

Fale em inglês britânico com um tom confiante, autoritário e de conversação - como um consultor sénior a fazer um briefing a um cliente. Ritmo pausado, 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 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. [pausa média] Se é responsável pelo WiFi corporativo ou do pessoal em várias localizações - seja um grupo hoteleiro, uma rede de retalho, um campus universitário ou um património 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 vamos falar sobre onde as coisas correm mal, porque correm mal, e como evitar as armadilhas mais comuns. [pausa média] Vamos começar com os fundamentos. 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 diretrizes de zero trust do NCSC apontam para a autenticação baseada em certificados para redes de colaboradores. [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 certificados nos dispositivos - ou seja, o SCEP ou a sua plataforma MDM. Terceiro, um servidor RADIUS que confie na sua CA e possa validar certificados de clientes em tempo real. [pausa média] A hierarquia de CA é onde a maioria das organizações se mete em sarilhos logo no início. O padrão correto é um modelo de três níveis. Tem uma Root CA no topo - esta deve estar offline, isolada e apenas online para assinar o certificado da sua Intermediate CA. A Intermediate CA - por vezes chamada de Issuing CA - é 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 certificados: 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 Root CA for comprometida, terá de reconstruir toda a sua PKI do zero e voltar a registar todos os dispositivos. Mantê-la offline elimina esse risco. A Intermediate CA pode ser substituída sem tocar na Root. Esse é o argumento de resiliência operacional para o modelo de três níveis. [pausa média] Falemos sobre os períodos de validade dos certificados. Tem havido uma mudança significativa no setor aqui. A Apple, a Google e a Mozilla moveram-se todas no sentido de impor tempos de vida máximos de certificados mais curtos. Para certificados de servidor TLS, o máximo é agora de 398 dias. Para certificados de cliente em WiFi empresarial, tem mais 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. O motivo é simples: um tempo de vida mais curto limita a janela de exposição se um certificado for 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 quase à mão. Se tiver 5000 dispositivos em 50 locais, não consegue. Precisa de SCEP - o Simple Certificate Enrolment Protocol - ou do seu sucessor moderno, EST. O SCEP integra-se diretamente com plataformas MDM, incluindo Microsoft Intune, Jamf Pro e 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: inscrição automática orientada por Políticas de Grupo através do 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 contínuo para parques informáticos predominantemente Windows. [medium pause] Agora, a revogação. Esta é a peça na qual as organizações mais frequentemente investem menos do que o necessário, e é a peça que mais importa quando algo corre mal. Se um dispositivo for perdido, roubado ou se um colaborador sair, precisa de 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 CA publica uma lista de números de série de certificados revogados num URL conhecido. O servidor RADIUS transfere esta lista periodicamente e faz a verificação em relação a ela. O problema com o CRL é a latência - se o seu CRL tiver um período de validade de 24 horas, um certificado revogado ainda se pode autenticar 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 se torna uma dependência crítica - se estiver indisponível, precisa de decidir se vai falhar em modo aberto ou falhar em modo fechado. Para ambientes de alta segurança, falhar em modo fechado é a resposta certa. Para ambientes operacionais onde a disponibilidade importa, pode configurar um curto período de carência OCSP. [medium pause] Deixe-me dar-lhe dois cenários concretos para tornar isto real. [medium pause] Primeiro: um grupo hoteleiro com 150 propriedades. Utilizavam 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 sem acesso ou utilizavam a palavra-passe antiga. Passaram a utilizar EAP-TLS com 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 processada 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 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 computadores 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 do Microsoft ADCS. A infraestrutura WiFi era Cisco Meraki, com autenticação RADIUS processada por um serviço RADIUS alojado na nuvem e integrado com o Purple. A principal decisão de conceção 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. Existem quatro que vejo consistentemente. [medium pause] Primeiro: 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-o. Revoque um certificado de teste, confirme se o servidor RADIUS deteta a revogação dentro do prazo previsto e confirme se o acesso do dispositivo é recusado. [medium pause] Segundo: penhascos 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, no mínimo, distribua os acionadores 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 de 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] Quarto: 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 monitorização adequada. [medium pause] Muito bem, perguntas de resposta rápida. [medium pause] Posso usar 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 fidedignidade. [medium pause] E em relação ao BYOD? O BYOD é o caso mais difícil. Não pode enviar certificados para dispositivos não geridos via 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 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 é 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 tempos de vida curtos 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ónico - não está dependente das 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 tem, quando expiram e quem os emitiu, essa é a primeira coisa a corrigir. A partir daí, o caminho para a automatização total está bem definido. Obrigado por ouvir.