Guia de Configuração SCEP Enterprise: Autenticação WiFi Baseada em Certificado para Ensino Superior e Grandes Redes

Guia de Configuração de SCEP Corporativo: Autenticação WiFi Baseada em Certificado para Ensino Superior e Grandes Redes Um Informativo Técnico da Purple - Roteiro de Podcast (aproximadamente 10 minutos) --- INTRODUÇÃO E CONTEXTO - aproximadamente 1 minuto Boas-vindas à série de Informativos Técnicos da Purple. Estou falando hoje sobre algo que chega a muitas caixas de entrada de TI, mas raramente recebe uma resposta direta: como você realmente implanta a autenticação WiFi baseada em certificado em escala, usando SCEP, em uma grande rede - seja ela um campus universitário, um grupo de hotéis com várias unidades ou uma grande propriedade do setor público? Vamos abordar o cenário completo. O que o SCEP realmente faz, como ele se encaixa em uma arquitetura 802.1X, a sequência de implantação que a maioria das equipes erra, dois cenários reais de implementação e as armadilhas que custarão um fim de semana da sua vida se você não se planejar para elas. Este é um informativo de consultoria, não um tutorial. Estou assumindo que você sabe o que é um servidor RADIUS e que provavelmente já decidiu que precisa deixar de lado as chaves pré-compartilhadas. O que você precisa agora é do mapa de implementação. Vamos começar. --- MERGULHO TÉCNICO PROFUNDO - aproximadamente 5 minutos Então, primeiros princípios. SCEP significa Simple Certificate Enrollment Protocol. Ele foi formalizado pela IETF como RFC 8894 em 2020, embora já estivesse em amplo uso corporativo por mais de uma década antes disso. Sua função é simples: automatizar o processo de obtenção de um certificado digital em um dispositivo gerenciado, sem a necessidade de uma pessoa tocar em cada máquina. No contexto da autenticação WiFi, o SCEP é o mecanismo de entrega. O protocolo de autenticação real que você está buscando é o EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - que faz parte da estrutura 802.1X. O EAP-TLS é amplamente considerado o método de autenticação mais seguro para redes sem fio corporativas porque exige que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados válidos. Nenhum dos lados confia no outro sem uma prova criptográfica. Essa autenticação mútua é o que protege você contra ataques de evil twin - onde um invasor cria um ponto de acesso invasor para coletar credenciais. Aqui está como funciona toda a cadeia. Um dispositivo gerenciado - um laptop de estudante, um telefone de funcionário, um terminal de ponto de venda de hotel - precisa se conectar à rede sem fio corporativa. Sua plataforma MDM, que pode ser o Microsoft Intune ou Jamf, envia um payload SCEP para esse dispositivo. O payload contém duas coisas: a URL do SCEP, que aponta para o seu servidor NDES ou gateway SCEP na nuvem, e uma senha de desafio ou segredo compartilhado. O dispositivo gera seu próprio par de chaves pública e privada localmente. Isso é crítico. A chave privada nunca sai do dispositivo. Ela é gerada no próprio dispositivo, armazenada no secure enclave ou TPM, e nunca é transmitida pela rede. O dispositivo então cria uma Solicitação de Assinatura de Certificado - um CSR - e a envia para o gateway SCEP. O gateway valida o desafio, encaminha o CSR para sua Autoridade Certificadora, e a CA o assina e retorna o certificado público para o dispositivo. A partir desse momento, quando o dispositivo se conecta ao seu SSID de WiFi, ele apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à cadeia de confiança da sua CA, verifica a Lista de Revogação de Certificados para confirmar se o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem de aceitação para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário. Agora, vamos falar sobre onde o SCEP se posiciona em relação à alternativa, que é o PKCS. O PKCS - Public Key Cryptography Standards - é o outro método de entrega de certificados suportado por plataformas como o Intune. Com o PKCS, a CA gera tanto a chave pública quanto a privada de forma centralizada, e o conector de certificado envia o par de chaves para o dispositivo. Isso significa que a chave privada trafega pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de uso como criptografia de e-mail S/MIME, onde o depósito de chaves é realmente desejável. Para autenticação WiFi, o SCEP é a escolha certa. A chave privada permanece no dispositivo, ponto final. Agora, a camada de hardware. O SCEP e o EAP-TLS são padrões independentes de fornecedor, o que significa que funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Sua configuração de RADIUS - seja ela o Windows NPS, FreeRADIUS ou um serviço de RADIUS na nuvem - é onde você define a política de validação de certificado e, fundamentalmente, onde configura a atribuição dinâmica de VLAN. As VLANs dinâmicas são a forma como você segmenta a rede por identidade. Um dispositivo de estudante recebe a VLAN 20 - apenas acesso à internet. Um dispositivo de professor recebe a VLAN 10 - acesso a sistemas internos de pesquisa. Um dispositivo de gerenciamento de instalações recebe a VLAN 30 - acesso a sistemas de gerenciamento predial. Tudo isso é impulsionado pelos atributos do certificado e pela política de RADIUS, sem nenhuma intervenção manual por dispositivo. Para integração com provedores de identidade, os atributos do certificado SCEP - especificamente o Subject Alternative Name - podem carregar o nome principal do usuário a partir do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que quando você desativa uma conta no Entra ID e o MDM desinscreve o dispositivo, o certificado é revogado e o acesso WiFi é cortado automaticamente. Esse é o tipo de histórico de revogação que as chaves pré-compartilhadas simplesmente não conseguem oferecer. - RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - aproximadamente 2 minutos Certo, vamos falar sobre a sequência de implantação, porque é aqui que a maioria das equipes comete erros. A sequência não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP e terceiro o perfil de WiFi. O Intune e o Jamf exigem dependências de perfil. Se o seu perfil de WiFi fizer referência a um certificado SCEP que ainda não foi implantado no dispositivo, o perfil de WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas na verdade é apenas um problema de tempo. A segunda armadilha é o direcionamento de grupo. Todos os três perfis - Trusted Root, SCEP e WiFi - devem ser implantados exatamente no mesmo grupo do Azure AD ou Jamf. Se o perfil SCEP for direcionado a um grupo de usuários e o perfil WiFi for direcionado a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será exibido como Não Aplicável. Isso costuma pegar as equipes de surpresa. Terceiro: acessibilidade do servidor NDES. Seu servidor NDES precisa ser acessível pela internet para que os dispositivos possam se registrar antes de chegarem ao local. A maneira correta de fazer isso é por meio do Azure AD Application Proxy, e não abrindo uma porta no seu firewall. O App Proxy oferece acesso remoto seguro sem portas de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro. Quarto: disponibilidade da CRL. Seu servidor RADIUS verifica a Lista de Revogação de Certificados toda vez que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL estiver indisponível - porque um servidor caiu ou a URL mudou - a autenticação falhará para todos os dispositivos na rede simultaneamente. Isso representa uma interrupção em todo o campus. Torne os endpoints da sua CRL altamente disponíveis e teste a revogação antes de entrar em operação. Para grandes redes - qualquer coisa acima de 500 dispositivos - considere um gateway SCEP em nuvem em vez de um NDES local. Os gateways em nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e geralmente se integram diretamente com serviços RADIUS em nuvem, removendo mais uma dependência de infraestrutura. - PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto O SCEP pode lidar com dispositivos BYOD que não estão inscritos no MDM? Não diretamente. O SCEP requer a inscrição no MDM para enviar a carga do certificado. Para BYOD não gerenciado, você precisa de uma abordagem diferente - seja um portal de autoatendimento para integração ou um SSID separado que utilize um Captive Portal com verificação de identidade. A plataforma da Purple lida com essa camada de convidados e BYOD de forma limpa, operando paralelamente à rede de funcionários autenticada por certificado. E quanto ao iOS e Android? Ambas as plataformas oferecem suporte nativo ao SCEP. O iOS suporta o SCEP desde o iOS 4. O Android Enterprise suporta o SCEP por meio do Intune e de outros MDMs. A configuração é ligeiramente diferente para cada plataforma, mas o protocolo subjacente é idêntico. O EAP-TLS funciona com WPA3? Sim. O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes confidenciais, e o EAP-TLS é totalmente compatível. Na verdade, o WPA3-Enterprise com EAP-TLS é a combinação recomendada pela Wi-Fi Alliance para redes governamentais e financeiras. - RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para resumir. A autenticação WiFi por certificado SCEP é a arquitetura ideal para qualquer rede com mais de 50 dispositivos gerenciados. Ela elimina credenciais compartilhadas, oferece identidade por dispositivo, permite segmentação dinâmica de VLAN e se integra diretamente ao seu provedor de identidade para revogação automatizada. A sequência de implantação - Trusted Root, depois o perfil SCEP e, em seguida, o perfil WiFi - é fixa. O direcionamento de grupo deve ser consistente. A disponibilidade de CRL não é opcional. Especificamente para o ensino superior, a combinação de SCEP para dispositivos de funcionários e professores, juntamente com uma camada separada de WiFi para visitantes para alunos em dispositivos pessoais, oferece segurança e uma excelente experiência de usuário sem concessões. Se você quiser se aprofundar, o guia do Purple sobre autenticação WiFi corporativa sem Active Directory ou servidor local aborda o caminho nativo da nuvem. E se você estiver pensando sobre o que acontece quando um funcionário sai, nosso guia sobre como revogar o acesso ao WiFi orienta você por todo o fluxo de trabalho de revogação. Obrigado por nos acompanhar. Eu sou da equipe técnica do Purple, e nos vemos no próximo briefing. - FIM DO ROTEIRO