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

Guia de Configuração SCEP para Empresas: Autenticação WiFi Baseada em Certificados para Ensino Superior e Grandes Redes Uma Sessão Técnica da Purple - Guião de Podcast (aproximadamente 10 minutos) --- INTRODUÇÃO E CONTEXTO - aproximadamente 1 minuto Bem-vindo à série de Sessões Técnicas da Purple. Hoje vou falar sobre algo que chega a muitas caixas de entrada de TI, mas que raramente tem uma resposta direta: como é que se implementa realmente a autenticação WiFi baseada em certificados à escala, utilizando SCEP, numa grande rede - seja um campus universitário, um grupo hoteleiro com vários locais ou uma grande propriedade do setor público? Vamos cobrir o cenário completo. O que o SCEP realmente faz, como se enquadra numa arquitetura 802.1X, a sequência de implementação que a maioria das equipas erra, dois cenários de implementação do mundo real e as armadilhas que lhe vão custar um fim de semana da sua vida se não se planear para elas. Esta é uma sessão de consultoria, não um tutorial. Assumo que sabe o que é um servidor RADIUS e que provavelmente já decidiu que precisa de se afastar de chaves pré-partilhadas. O que precisa agora é do mapa de implementação. Vamos a isso. --- MERGULHO TÉCNICO PROFUNDO - aproximadamente 5 minutos Então, primeiros princípios. SCEP significa Simple Certificate Enrollment Protocol. Foi formalizado pelo IETF como RFC 8894 em 2020, embora já estivesse em uso empresarial generalizado há mais de uma década antes disso. A sua função é simples: automatizar o processo de obtenção de um certificado digital num dispositivo gerido, sem exigir que um humano toque em cada máquina. No contexto da autenticação WiFi, o SCEP é o mecanismo de entrega. O protocolo de autenticação real que visa é o EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - que se insere na estrutura 802.1X. O EAP-TLS é amplamente considerado como o método de autenticação mais seguro para redes sem fios empresariais porque exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados válidos. Nenhum dos lados confia no outro sem prova criptográfica. Essa autenticação mútua é o que o protege contra ataques "evil twin" - onde um atacante cria um ponto de acesso falso para recolher credenciais. Eis como funciona toda a cadeia. Um dispositivo gerido - um computador portátil de um estudante, um telemóvel de um funcionário, um terminal de ponto de venda de um hotel - precisa de se associar à rede sem fios corporativa. A sua plataforma MDM, que pode ser o Microsoft Intune ou o Jamf, envia um payload SCEP para esse dispositivo. O payload contém duas coisas: o URL SCEP, que aponta para o seu servidor NDES ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado. O dispositivo gera localmente o seu próprio par de chaves pública e privada. Isto é fundamental. A chave privada nunca sai do dispositivo. É gerada no dispositivo, armazenada no enclave seguro ou TPM, e nunca é transmitida através da rede. O dispositivo cria então um Pedido de Assinatura de Certificado - um CSR - e envia-o para o gateway SCEP. O gateway valida o desafio, encaminha o CSR para a sua Autoridade de Certificação, e a CA assina-o e devolve o certificado público ao dispositivo. A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, 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 que 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 utilizador. Agora, vamos falar sobre a posição do SCEP em relação à alternativa, que é o PKCS. O PKCS - Public Key Cryptography Standards - é o outro método de distribuição de certificados suportado por plataformas como o Intune. Com o PKCS, a CA gera a chave pública e a privada de forma centralizada, e o conector de certificados envia o par de chaves para o dispositivo. Isso significa que a chave privada viaja pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de utilização como a encriptação de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para a 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 normas neutras em termos de fornecedor, o que significa que funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. A sua configuração RADIUS - quer seja o Windows NPS, o FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e, fundamentalmente, onde configura a atribuição dinâmica de VLAN. As VLANs dinâmicas são a forma como segmenta a rede por identidade. Um dispositivo de um estudante obtém a VLAN 20 - apenas acesso à internet. Um dispositivo de um docente obtém a VLAN 10 - acesso a sistemas de investigação internos. Um dispositivo de gestão de instalações obtém a VLAN 30 - acesso a sistemas de gestão de edifícios. Tudo isto é impulsionado pelos atributos do certificado e pela política de RADIUS, sem qualquer intervenção manual por dispositivo. Para a integração com fornecedores de identidade, os atributos do certificado SCEP - especificamente o Subject Alternative Name - podem carregar o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que, quando desativa uma conta no Entra ID e o MDM remove o registo do dispositivo, o certificado é revogado e o acesso WiFi é cortado automaticamente. Esse é o cenário de revogação que as chaves pré-partilhadas simplesmente não conseguem oferecer. - RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos Muito bem, vamos falar sobre a sequência de implementação, porque é aqui que a maioria das equipas se desequilibra. A sequência não é negociável: primeiro o certificado Trusted Root, depois o perfil de certificado SCEP e, em terceiro, o perfil WiFi. O Intune e o Jamf impõem dependências de perfil. Se o seu perfil WiFi referenciar um certificado SCEP que ainda não foi implementado no dispositivo, o perfil WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas que, na verdade, é apenas um problema de temporização. O segundo erro comum é a definição de grupos-alvo. Todos os três perfis - Trusted Root, SCEP e WiFi - devem ser implementados exatamente no mesmo grupo Azure AD ou Jamf. Se o perfil SCEP tiver como alvo um grupo de utilizadores e o perfil WiFi tiver como alvo um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será apresentado como Não Aplicável. Isto surpreende as equipas constantemente. Terceiro: acessibilidade do servidor NDES. O seu servidor NDES precisa de estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. A forma correta de o fazer é através do Azure AD Application Proxy, e não abrindo uma porta na sua firewall. O App Proxy oferece-lhe um acesso remoto seguro sem portas de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Quarto: disponibilidade da CRL. O seu servidor RADIUS verifica a Lista de Revogação de Certificados sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL estiver indisponível - porque um servidor está offline ou o URL foi alterado - a autenticação falha para todos os dispositivos na rede em simultâneo. Isso representa uma falha geral no campus. Torne os seus endpoints de CRL altamente disponíveis e teste a revogação antes de avançar para o ambiente de produção. Para redes de grande dimensão - qualquer uma acima de 500 dispositivos - considere um gateway SCEP na cloud em vez de um NDES local. Os gateways na cloud eliminam o ponto único de falha do NDES, escalam horizontalmente e integram-se normalmente de forma direta com serviços RADIUS na cloud, removendo outra dependência de infraestrutura. - PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto O SCEP pode gerir dispositivos BYOD que não estão registados no MDM? Não diretamente. O SCEP requer o registo no MDM para enviar o payload do certificado. Para BYOD não geridos, precisa de uma abordagem diferente - ou um portal de integração self-service ou um SSID separado utilizando um Captive Portal com verificação de identidade. A plataforma da Purple trata dessa camada de convidados e BYOD de forma limpa, coexistindo com a sua rede de colaboradores autenticada por certificado. E em relação ao iOS e ao Android? Ambas as plataformas suportam SCEP nativamente. O iOS suporta SCEP desde o iOS 4. O Android Enterprise suporta SCEP através do Intune e de outros MDMs. A configuração é ligeiramente diferente por 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 sensíveis, 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 certa para qualquer rede com mais de 50 dispositivos geridos. Elimina credenciais partilhadas, fornece uma identidade por dispositivo, permite a segmentação dinâmica de VLAN e integra-se diretamente com o seu fornecedor de identidade para revogação automatizada. A sequência de implementação - Raiz de Confiança, depois perfil SCEP, depois perfil WiFi - é fixa. A segmentação de grupos 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 docentes, juntamente com uma camada de WiFi para convidados separada para estudantes nos seus dispositivos pessoais, oferece segurança e uma excelente experiência de utilizador sem compromissos. Se quiser aprofundar o assunto, o guia da Purple sobre autenticação WiFi empresarial sem Active Directory ou servidor local aborda o caminho nativo na nuvem. E se estiver a pensar no que acontece quando um funcionário sai, o nosso guia sobre como revogar o acesso WiFi explica todo o fluxo de trabalho de revogação. Obrigado por ouvir. Sou da equipa técnica da Purple, e encontramo-nos na próxima sessão informativa. - FIM DO GUIÃO