Gerenciando 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 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 falaremos 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 uma sobrecarga 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ê. Abordaremos 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 - que é o 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. 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 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 instalar certificados nos dispositivos - ou seja, o SCEP ou sua plataforma MDM. Terceiro, um servidor RADIUS que confie na sua CA e possa validar os certificados dos clientes em tempo real. [pausa média] A hierarquia de CA é onde a maioria das organizações enfrenta problemas logo de início. O padrão correto é um modelo de três camadas. Você tem uma CA Raiz no topo - esta deve estar offline, isolada (air-gapped) e só deve ser colocada online para assinar o certificado da 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 a 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 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 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 corporativo, você tem mais flexibilidade — de um a dois anos é o comum —, mas a tendência é de 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 caso um certificado seja comprometido. [medium pause] Isso nos leva à automação. O gerenciamento manual de certificados não é escalonável. Se você tem 500 dispositivos, consegue gerenciar as renovações manualmente no limite. Se tiver 5.000 dispositivos em 50 locais, não conseguirá. Você precisa do SCEP — o Simple Certificate Enrolment Protocol — ou de seu sucessor moderno, o 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: o autoregistro orientado por Diretiva de Grupo (Group Policy) 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 prático para ambientes predominantemente Windows. [medium pause] Agora, a revogação. Esta é a parte na qual as organizações costumam investir menos, e é a que mais importa quando algo dá errado. Se um dispositivo for perdido, roubado ou se um funcionário sair, você precisará 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 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 poderá ser autenticado 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 imediata de válido ou revogado. O contraponto é que seu respondedor OCSP se torna uma dependência crítica — se ele estiver indisponível, você precisa decidir se deve liberar o acesso (fail open) ou bloquear o acesso (fail closed). Para ambientes de alta segurança, bloquear o acesso é a resposta certa. Para ambientes operacionais onde a disponibilidade é fundamental, 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 de 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 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 foram enviados para todos os dispositivos Windows e iOS. O Active Directory Certificate Services atuava 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 membro da equipe 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 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, dispositivos 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 respaldado por uma CA intermediária do Microsoft ADCS. A infraestrutura de WiFi era Cisco Meraki, com autenticação RADIUS tratada por um serviço RADIUS hospedado na nuvem integrado ao 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 consistentemente. [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-a. 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 foi 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. Escalone sua emissão ou, no mínimo, escalone os gatilhos de renovação. Uma taxa de falha de renovação de 10% em 5.000 dispositivos simultaneamente é 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 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 têm dispositivos BYOD ou notebooks de prestadores de serviços que não estão registrados no MDM. [medium pause] Quarta: disponibilidade do respondente OCSP. Se o seu respondente OCSP ficar fora do ar e o seu servidor RADIUS estiver configurado para falhar e fechar em erros de OCSP, toda a sua rede de WiFi para de funcionar. Crie redundância em sua infraestrutura de OCSP ou configure um curto período de carência com o 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. CAs públicas não emitem certificados de cliente para dispositivos arbitrários. Você precisa da sua própria CA para certificados de cliente. Para o certificado do servidor RADIUS, uma CA pública funciona bem e simplifica a distribuição de confiança. [medium pause] E quanto ao BYOD? BYOD é o caso mais complexo. 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 conjuntos de cifras específicos. 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 é 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 ciclo 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 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 integrados à Purple, os pontos de integração são o URL do seu servidor SCEP, o certificado do seu servidor RADIUS e 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: faça uma auditoria no seu inventário atual de certificados. Se você não sabe quantos certificados possui, quando expiram e quem os emitiu, esse é o primeiro ponto a ser corrigido. A partir daí, o caminho para a automação total é bem definido. Obrigado por ouvir.