Gerenciamento 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 orientando um cliente. Ritmo cadenciado, dicção clara, caloroso mas direto. Pausas naturais ocasionais para ênfase: Bem-vindo à série de briefings técnicos da Purple. Hoje vamos falar sobre o gerenciamento 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 em tempo integral. [pausa média] Se você é responsável pelo WiFi corporativo ou de funcionários em vários locais - seja um grupo hoteleiro, uma rede de varejo, um campus universitário ou órgãos do setor público - este briefing é para você. Vamos cobrir todo o ciclo de vida 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 os fundamentos. O 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 certificados. O dispositivo comprova sua identidade com um certificado de cliente. O servidor RADIUS comprova sua identidade com um certificado de servidor. Ambos os lados verificam o outro. Sem senha para phish. Sem credencial 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 funcionários. [pausa média] Agora, 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 certificados nos dispositivos - ou seja, SCEP ou sua plataforma de 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 enfrenta problemas logo no início. O padrão correto é um modelo de três camadas. Você tem uma Root CA no topo - ela deve estar offline, isolada e somente ser colocada online para assinar o certificado de sua Intermediate CA. A Intermediate CA - às vezes chamada de Issuing CA - é aquela 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 Root CA 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 Intermediate CA pode ser substituída sem tocar na Root. Esse é o argumento de resiliência operacional para o modelo de três camadas. [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 máximos de vida de certificados mais curtos. Para certificados de servidor TLS, o máximo agora é de 398 dias. Para certificados de cliente em WiFi corporativo, você 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 gerenciados manualmente. O motivo é simples: um tempo de vida mais curto limita a janela de exposição se um certificado for comprometido. [medium pause] Isso nos traz à automação. O gerenciamento manual de certificados não é escalável. Se você tem 500 dispositivos, consegue gerenciar as renovações manualmente. Se você tem 5.000 dispositivos em 50 locais, você não consegue. Você precisa de SCEP - o Simple Certificate Enrolment Protocol - ou 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 um certificado assinado de volta - tudo sem qualquer interação do usuário. [medium pause] Para dispositivos Windows em um ambiente Active Directory, você tem uma alternativa: auto-registro direcionado por Diretiva de Grupo via Active Directory Certificate Services. O dispositivo se autentica no domínio, a autoridade certificadora emite um certificado automaticamente e o certificado é renovado antes do vencimento sem qualquer intervenção manual. Este é o caminho mais simples para ambientes com forte presença de Windows. [medium pause] Agora, a revogação. Esta é a parte em que 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 sair, você precisa revogar o certificado dele imediatamente. Existem dois mecanismos: CRL - Certificate Revocation Lists - e OCSP - Online Certificate Status Protocol. [medium pause] CRL é o mecanismo mais antigo. Sua autoridade certificadora 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 comparativa. O problema com a CRL é a latência - se a sua CRL tiver um período de validade de 24 horas, um certificado revogado ainda poderá 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. O contraponto é que o seu respondedor OCSP se torna uma dependência crítica - se ele estiver indisponível, você precisa decidir se permite o acesso livre ou se bloqueia o acesso por padrão. Para ambientes de alta segurança, bloquear por padrão é a resposta correta. Para ambientes operacionais onde a disponibilidade é importante, você pode configurar um curto período de tolerância do OCSP. [medium pause] Deixe-me apresentar dois cenários concretos para tornar isso real. [medium pause] Primeiro: um grupo hoteleiro de 150 propriedades. Eles operavam PEAP com uma senha compartilhada para o WiFi da equipe. A rotação de senha era trimestral, o que significava uma janela de duas semanas a cada trimestre em que a equipe ficava bloqueada 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 senha, renovação de certificado tratada automaticamente 30 dias antes do vencimento e, quando um funcionário saía, seu certificado era revogado no MDM poucos minutos após sua conta ser desativada no Microsoft Entra ID. A equipe de TI estimou que economizou 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 notebooks Windows, coletores de dados 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 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 do vencimento. Isso proporcionou uma janela de renovação confortável sem criar sobrecarga operacional. [medium pause] Agora, as armadilhas. Existem quatro que vejo de forma consistente. [medium pause] Primeira: 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 isso. Revoque um certificado de teste, confirme se o servidor RADIUS detecta a revogação dentro da janela esperada e confirme se o acesso do dispositivo é negado. [medium pause] Segunda: penhascos de vencimento. Se você emitir todos os seus certificados ao mesmo tempo com o mesmo período de validade, todos eles vencerão ao mesmo tempo. Distribua sua emissão ao longo do tempo ou, no mínimo, distribua os gatilhos de renovação. Uma taxa de falha de renovação de 10% em 5.000 dispositivos simultâneos é um incidente significativo. [medium pause] Terceira: não distribuir o certificado da CA Raiz para todos os dispositivos antes de implantar o EAP-TLS. Se o dispositivo não confiar em 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 têm dispositivos BYOD ou notebooks de prestadores de serviços que não estão registrados no MDM. [medium pause] Quarta: disponibilidade do responder OCSP. Se o seu responder OCSP ficar inativo e o seu servidor RADIUS estiver configurado para falhar fechado em erros de OCSP, toda a sua rede de WiFi para de funcionar. Crie redundância na sua infraestrutura OCSP ou configure um curto período de carência com monitoramento apropriado. [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 implantar certificados em 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 é, de fato, o método de autenticação recomendado. [medium pause] Para resumir. O gerenciamento de certificados EAP-TLS não é simples, mas é viável se você acertar a arquitetura desde o início. Hierarquia de CA de três níveis. Registro automatizado via 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 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 canônica de hardware - você não fica preso às ferramentas de PKI de um único fornecedor. [medium pause] Próximos passos: realize uma auditoria no seu inventário atual de certificados. Se você não sabe quantos certificados possui, quando eles expiram e quem os emitiu, esse é o primeiro ponto a ser corrigido. A partir daí, o caminho para a automação completa é bem definido. Obrigado por ouvir.