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

Fale em inglês britânico com um tom confiante, autoritário e coloquial - como um consultor sênior instruindo 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 estamos falando sobre gerenciamento de certificados EAP-TLS - especificamente, como executar um programa de autenticação WiFi baseado em certificado em escala sem que isso se torne um fardo operacional em tempo integral. [pausa média] Se você é responsável pelo WiFi corporativo ou de funcionários em vários locais - seja um grupo de hotéis, uma rede de varejo, um campus universitário ou propriedades do setor público - este briefing é para você. Vamos cobrir o ciclo de vida completo do certificado: desde a configuração de sua hierarquia de CA, passando pela implantação automatizada via SCEP e MDM, até a renovação e revogação. E falaremos sobre onde as coisas dão errado, porque elas dão errado, e como evitar as armadilhas mais comuns. [pausa média] Vamos começar com o fundamental. EAP-TLS - ou seja, Extensible Authentication Protocol com Transport Layer Security - é o padrão ouro para autenticação WiFi 802.1X. Ao contrário do PEAP, que depende de um nome de usuário e senha, o EAP-TLS usa autenticação mútua baseada em certificado. O dispositivo prova sua identidade com um certificado de cliente. O servidor RADIUS prova sua identidade com um certificado de servidor. Ambos os lados verificam o outro. Nenhuma senha para sofrer phishing. Nenhuma credencial 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 certificado para redes de funcionários. [pausa média] Aqui está a arquitetura. Você precisa de três coisas para fazer o EAP-TLS funcionar. Primeiro, uma Infraestrutura de Chaves Públicas - sua hierarquia de CA. Segundo, um mecanismo para colocar os certificados nos dispositivos - que é o SCEP ou sua plataforma MDM. Terceiro, um servidor RADIUS que confia em sua CA e pode validar os certificados de cliente em tempo real. [pausa média] A hierarquia de CA é onde a maioria das organizações enfrenta problemas logo no início. O padrão correto é um modelo de três níveis. Você tem uma CA Raiz no topo - esta deve estar offline, isolada da rede (air-gapped), e só ser colocada online para assinar o certificado de sua CA Intermediária. A CA Intermediária - às vezes chamada de CA Emissora - é a que realmente assina os certificados do dia a dia. Ela está online, mas sua chave privada está bem protegida. Abaixo disso, você emite dois tipos de certificado: certificados de servidor para sua infraestrutura RADIUS, e certificados de cliente para seus dispositivos e usuários. [pausa média] Por que isso importa? Porque se sua CA Raiz for comprometida, você terá que reconstruir toda a sua PKI do zero e registrar novamente todos os dispositivos. Mantê-la offline elimina esse risco. A CA Intermediária 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. Houve uma mudança significativa no setor aqui. Apple, Google e Mozilla decidiram impor tempos de vida máximos de certificado mais curtos. Para certificados de servidor TLS, o máximo agora é de 398 dias. Para certificados de cliente em redes WiFi corporativas, você tem mais flexibilidade - um a dois anos é o comum - mas a tendência é para tempos de vida mais curtos e renovação automatizada, em vez de certificados de longa duração gerenciados de forma manual. O motivo é simples: um tempo de vida mais curto limita a janela de exposição se um certificado for comprometido. [medium pause] Isso nos leva à automação. O gerenciamento manual de certificados não é escalável. Se você tem 500 dispositivos, até consegue gerenciar as renovações manualmente. Se você tem 5.000 dispositivos em 50 sites, você não consegue. Você precisa do SCEP - o Simple Certificate Enrolment Protocol - ou de seu sucessor moderno, EST. O SCEP se integra 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 uma solicitação de assinatura de certificado para o seu servidor SCEP e recebe de volta um certificado assinado - tudo sem qualquer interação do usuário. [medium pause] Para dispositivos Windows em um ambiente Active Directory, você tem uma alternativa: inscrição automática orientada por Diretiva de Grupo por meio do Active Directory Certificate Services. O dispositivo se autentica no domínio, a CA emite um certificado automaticamente e o certificado é renovado antes do vencimento sem qualquer intervenção manual. Esse é o caminho mais simples para ambientes baseados majoritariamente em Windows. [medium pause] Agora, a revogação. Esta é a parte na qual as organizações costumam investir menos do que deveriam, e é a parte que mais importa quando algo dá errado. Se um dispositivo for perdido, roubado ou se um funcionário se desligar da empresa, você precisa revogar o certificado dele imediatamente. Existem dois mecanismos: CRL - Certificate Revocation Lists - e OCSP - Online Certificate Status Protocol. [medium pause] O CRL é o mecanismo mais antigo. Sua CA publica uma lista de números de série de certificados revogados em uma URL conhecida. O servidor RADIUS baixa essa lista periodicamente e faz a verificação com base nela. 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 poderá se autenticar por 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 ativa de válido ou revogado. A contrapartida é que o seu respondedor OCSP se torna uma dependência crítica - se ele estiver indisponível, você precisa decidir se prefere falhar liberando o acesso ou falhar bloqueando o acesso. Para ambientes de alta segurança, falhar bloqueando o acesso é a resposta certa. Para ambientes operacionais onde a disponibilidade é o mais importante, você pode configurar um curto período de carência do OCSP. [medium pause] Deixe-me dar dois cenários concretos para tornar isso real. [medium pause] Primeiro: um grupo hoteleiro com 150 propriedades. Eles usavam PEAP com uma senha compartilhada para o WiFi da equipe. A rotação de senhas era trimestral, o que significava uma janela de duas semanas a cada trimestre em que os funcionários ficavam bloqueados ou usando a senha antiga. Eles mudaram para EAP-TLS usando o Microsoft Intune para implantação de certificados. Perfis SCEP enviados para todos os dispositivos Windows e iOS. Active Directory Certificate Services como a CA. O resultado: zero eventos de rotação de senhas, renovação de certificado tratada de forma automática 30 dias antes do vencimento e, quando um funcionário saía, seu certificado era revogado no MDM minutos após a desativação de sua conta no Microsoft Entra ID. A equipe de TI estimou uma economia de aproximadamente 40 horas por trimestre em redefinições de senha e chamados de suporte. [medium pause] Segundo: uma rede de varejo multi-site com 3.000 dispositivos de funcionários em 200 lojas. O desafio aqui era a diversidade de dispositivos - uma mistura de laptops Windows, portáteis Android e dispositivos iOS. Eles usavam o Jamf Pro para dispositivos Apple e o Microsoft Intune para Windows e Android, ambos apontando para o mesmo servidor SCEP apoiado por uma CA Intermediária Microsoft ADCS. A infraestrutura de WiFi era Cisco Meraki, com autenticação RADIUS tratada por um serviço RADIUS hospedado na nuvem e integrado com o Purple. A decisão crucial de design foi emitir certificados com validade de 12 meses e configurar a renovação automática para 60 dias antes do vencimento. Isso proporcionou uma janela de renovação confortável sem criar sobrecarga operacional. [medium pause] Agora, os pontos críticos. Existem quatro que vejo constantemente. [medium pause] Primeiro: não testar a revogação. As organizações configuram sua PKI, implantam certificados e nunca testam realmente se a revogação funciona de ponta a ponta. Teste. Revogue um certificado de teste, confirme se o servidor RADIUS detecta a revogação dentro da janela esperada e confirme se o acesso ao dispositivo é negado. [medium pause] Segundo: penhascos de expiração. Se você emitir todos os seus certificados ao mesmo tempo com o mesmo período de validade, todos expirarão ao mesmo tempo. Distribua sua emissão ao longo do tempo ou, no mínimo, distribua seus gatilhos de renovação. Uma taxa de falha de renovação de 10% em 5.000 dispositivos simultaneamente é um incidente significativo. [medium pause] Terceiro: não distribuir o certificado da CA Raiz para todos os dispositivos antes de implantar o EAP-TLS. Se o dispositivo não confiar na sua CA Raiz, ele rejeitará o certificado do servidor RADIUS e a autenticação falhará. Isso parece óbvio, mas pega as organizações de surpresa quando elas possuem dispositivos BYOD ou laptops de prestadores de serviços que não estão registrados no MDM. [medium pause] Quarto: disponibilidade do respondedor OCSP. Se o seu respondedor OCSP ficar inativo e seu servidor RADIUS estiver configurado para falhar fechado em erros de OCSP, toda a sua estrutura de WiFi para de funcionar. Crie redundância na sua infraestrutura OCSP ou configure um curto período de carência com o monitoramento adequado. [medium pause] Certo, perguntas rápidas. [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. Você precisa de 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. Você não pode enviar certificados para dispositivos não gerenciados via MDM. As opções incluem um portal de controle de acesso à rede que emite certificados de curta duração após a autenticação do usuário, ou simplesmente manter o BYOD em um SSID separado com um método de autenticação diferente. [medium pause] Como isso interage com o WPA3? O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes confidenciais, o que requer suítes de criptografia específicas. O EAP-TLS é totalmente compatível com o WPA3-Enterprise e é, na verdade, o método de autenticação recomendado. [medium pause] Para resumir. O gerenciamento de certificados EAP-TLS não é simples, mas é gerenciável se você acertar na arquitetura desde o início. Hierarquia de CA de três níveis. Registro automatizado 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 do seu certificado com o seu provedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - para que a revogação do certificado seja acionada automaticamente quando uma conta for desprovisionada. [medium pause] Se você estiver executando servidores RADIUS vinculados à Purple, os pontos de integração são a 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 isso funciona em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e no restante da lista de hardware canônica - você não fica preso às ferramentas de PKI de um único fornecedor. [medium pause] Próximos passos: audite seu inventário de certificados atual. Se você não sabe quantos certificados possui, quando eles expiram e quem os emitiu, essa é a primeira coisa a corrigir. A partir daí, o caminho para a automação total está bem definido. Obrigado por ouvir.