Implementar SCEP para uma Autenticação BYOD e WiFi Segura no Ensino Superior
Este guia técnico fornece aos arquitetos de rede e gestores de TI um plano neutro em termos de fornecedor para implementar a atribuição de certificados baseada em SCEP para proteger o WiFi no ensino superior. Detalha a transição de uma autenticação vulnerável baseada em palavras-passe para EAP-TLS, focando-se na integração escalável de BYOD e MDM.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
Para as equipas de TI do ensino superior, o início do ano letivo traz um teste de esforço imediato. Milhares de estudantes chegam ao campus com múltiplos dispositivos não geridos, esperando uma conectividade instantânea e segura. Quando as universidades dependem de autenticação baseada em palavra-passe como PEAP-MSCHAPv2, esta afluência resulta previsivelmente em filas massivas no suporte técnico, erros de configuração e vulnerabilidades graves ao roubo de credenciais através de pontos de acesso "evil twin".
A solução arquitetural para este desafio de escala e segurança é a autenticação baseada em certificados utilizando EAP-TLS. Para tornar a implementação de certificados viável em dezenas de milhares de endpoints, as universidades devem implementar o Simple Certificate Enrollment Protocol (SCEP). O SCEP automatiza o aprovisionamento de certificados digitais tanto para dispositivos geridos via MDM como para dispositivos não geridos de estudantes através de portais de autoatendimento. Este guia detalha os requisitos técnicos para implementar o SCEP num ambiente de ensino superior, fornecendo passos práticos para eliminar os pedidos de suporte relacionados com palavras-passe e proteger o perímetro do campus.
A Arquitetura do Registo de Certificados SCEP
A transição para o WiFi baseado em certificados requer uma mudança fundamental da validação do conhecimento do utilizador (uma palavra-passe) para a validação da identidade do dispositivo (um certificado). O protocolo SCEP funciona como a ponte entre a sua camada de gestão de dispositivos e a sua Infraestrutura de Chaves Públicas (PKI).
Componentes de Infraestrutura Core
Uma implementação SCEP pronta para produção requer seis componentes integrados a funcionar em sequência:
- Fornecedor de Identidade (IdP): O diretório de autoridade (Microsoft Entra ID, Okta ou Google Workspace) que verifica a identidade do utilizador antes da emissão do certificado.
- Mobile Device Management (MDM): Plataformas como o Microsoft Intune ou Jamf que enviam o payload SCEP para dispositivos propriedade da instituição.
- Autoridade de Certificação (CA): O motor de PKI que assina e emite os certificados. Pode ser uma implementação local do Microsoft ADCS ou uma sobreposição de PKI nativa na nuvem.
- Gateway SCEP: O endpoint HTTP que recebe os Pedidos de Assinatura de Certificados (CSRs) dos dispositivos, valida a palavra-passe de desafio e encaminha o pedido para a CA.
- Servidor RADIUS: O servidor de autenticação que avalia o certificado de cliente apresentado em relação às políticas de acesso à rede durante a troca 802.1X EAP-TLS.
- Rede de Acesso Sem Fios: Os pontos de acesso físicos (Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist) configurados para impor a autenticação 802.1X.
O Fluxo de Registo SCEP
O processo de registo executa-se sem intervenção do utilizador em dispositivos geridos. A plataforma MDM envia um perfil de configuração que contém o URL do gateway SCEP e uma palavra-passe de desafio gerada dinamicamente. O dispositivo gera uma chave privada localmente e constrói um CSR. Em seguida, transmite este CSR para o gateway SCEP através de HTTP.
O gateway intercepta o pedido e valida a palavra-passe de desafio junto da API do MDM para confirmar que o dispositivo está autorizado. Uma vez verificado, o gateway encaminha o CSR para a CA. A CA assina o certificado e devolve-o ao dispositivo através do gateway. A chave privada nunca sai do endpoint, garantindo a integridade criptográfica.
Guia de Implementação: Uma Estratégia de Implementação Faseada
A implementação do SCEP requer uma sequenciação precisa. As dependências de perfil significam que a execução destes passos fora de ordem resultará em falhas de autenticação.
Passo 1: Sincronização de Diretório e Política de Grupo
Antes de mexer nos certificados, certifique-se de que o seu repositório de identidades está limpo. Crie grupos de segurança distintos para estudantes, funcionários e docentes no Entra ID ou Active Directory. O seu servidor RADIUS utilizará estas pertenças a grupos, incorporadas como Subject Alternative Names (SAN) nos certificados, para atribuir dispositivos às VLANs corretas de forma dinâmica.
Passo 2: Configuração de PKI e Gateway SCEP
Estabeleça a sua hierarquia de CA. Se a estrutura for local, implemente uma Root CA offline e uma Issuing CA online. Para ambientes de ensino superior que procurem reduzir a pegada de infraestrutura, as soluções de PKI na nuvem oferecem simplicidade operacional. Configure o gateway SCEP para comunicar com a sua CA e exponha o endpoint de registo ao segmento de rede onde os dispositivos se irão ligar inicialmente.
Passo 3: Integração do Servidor RADIUS
Importe o certificado da Issuing CA para o repositório de certificados fidedignos do seu servidor RADIUS. Configure o protocolo de autenticação estritamente para EAP-TLS. Defina políticas de rede que mapeiem atributos de certificado (como o User Principal Name) para atributos de retorno de VLAN específicos, permitindo a microsegmentação em todo o campus.
Passo 4: Sequenciação de Perfis de MDM
Para dispositivos de propriedade da instituição geridos pelo Intune ou Jamf, a ordem de implementação do perfil é crítica. Deve implementar os perfis exatamente nesta sequência:
- Perfil de Certificado Fidedigno: Distribui o certificado da Root CA para estabelecer confiança.
- Perfil de Certificado SCEP: Direciona o dispositivo para o gateway para obter o seu certificado de cliente.
- Perfil de WiFi: Configura o SSID para utilizar WPA3-Enterprise com EAP-TLS, referenciando explicitamente o certificado obtido no passo anterior.
Passo 5: Ativação de Self-Service para BYOD
Os estudantes não irão instalar manualmente certificados nos seus dispositivos pessoais. Deve fornecer um percurso de integração automatizado. Implemente um SSID aberto que restrinja o tráfego exclusivamente ao Captive Portal e ao gateway SCEP. Quando um estudante se liga, o portal solicita que este se autentique via Single Sign-On utilizando as suas credenciais universitárias. Após uma autenticação bem-sucedida, o portal fornece o payload SCEP ao dispositivo. A Purple integra este fluxo de integração diretamente na experiência do Captive Portal, permitindo que os estudantes concluam o registo em menos de dois minutos sem a intervenção das TI.
Melhores Práticas e Mitigação de Riscos
A transição para EAP-TLS elimina o roubo de credenciais, mas introduz novas considerações operacionais. Os arquitetos de rede devem antecipar eventos de escala e de ciclo de vida.
Planeamento de Capacidade RADIUS
O esforço computacional da validação de certificados EAP-TLS é significativamente superior ao da verificação de palavras-passe PEAP. Durante a primeira semana de aulas, milhares de dispositivos tentarão autenticar-se em simultâneo. Um único nó RADIUS irá provavelmente esgotar os seus recursos e rejeitar pedidos, levando a falhas de ligação generalizadas. Deve implementar o balanceamento de carga em múltiplos nós RADIUS e aumentar o limite de tempo de autenticação nos seus pontos de acesso para, pelo menos, cinco segundos, para acomodar a latência de pico.
Gestão do Ciclo de Vida dos Certificados
Os certificados para os dispositivos dos estudantes devem, normalmente, ter um período de validade de um a dois anos. Esta duração cobre o ciclo académico, ao mesmo tempo que limita a exposição caso um dispositivo seja comprometido. Crucialmente, deve implementar um mecanismo de revogação robusto. Quando um estudante se licencia ou reporta um dispositivo perdido, o certificado deve ser revogado imediatamente. Certifique-se de que a sua CA publica uma Lista de Revogação de Certificados (CRL) ou opera um respondente do Protocolo de Estado de Certificados Online (OCSP), e configure o seu servidor RADIUS para verificar o estado de revogação em cada tentativa de autenticação.
Gestão de Dispositivos IoT sem Interface (Headless)
As Smart TVs, consolas de videojogos e impressoras sem fios nas residências universitárias carecem dos suplicantes 802.1X nativos necessários para o registo SCEP. Para estes dispositivos, implemente o MAC Authentication Bypass (MAB). Disponibilize um portal de registo de dispositivos self-service onde os estudantes possam registar os endereços MAC do seu hardware IoT. O sistema de Controlo de Acesso à Rede (NAC) autentica então estes endereços registados e coloca-os na VLAN de estudantes adequada.
Ouça o Briefing Técnico
Para uma análise mais aprofundada da arquitetura e de cenários de implementação reais, ouça o nosso podcast de briefing técnico de 10 minutos.
ROI e Impacto no Negócio
A justificação comercial para a implementação do SCEP no ensino superior baseia-se em dois pilares: postura de segurança e eficiência operacional.
Sob a perspetiva da segurança, o EAP-TLS fornece autenticação mútua. O dispositivo verifica o certificado do servidor RADIUS antes de transmitir quaisquer dados, mitigando totalmente o risco de pontos de acesso "evil twin" recolherem credenciais. Esta arquitetura alinha-se com os princípios de zero-trust, garantindo que apenas dispositivos criptograficamente verificados acedem à rede do campus.
Operacionalmente, a dissociação da autenticação WiFi das palavras-passe do diretório gera retornos financeiros imediatos. Quando uma universidade força a alteração de palavras-passe a cada 90 dias, os estudantes que utilizam PEAP devem atualizar as suas credenciais em todos os dispositivos. Inevitavelmente, muitos falham, resultando num aumento de pedidos de suporte ao helpdesk. Com o SCEP e o EAP-TLS, o certificado permanece válido independentemente das alterações de palavras-passe. As universidades que implementam a integração automatizada de certificados reportam consistentemente uma redução de até 70% nos pedidos de suporte relacionados com WiFi durante os períodos de pico, permitindo que a equipa de TI se foque em iniciativas estratégicas em vez da resolução de problemas básicos de conectividade.
Definições Principais
SCEP (Simple Certificate Enrollment Protocol)
Um protocolo que automatiza o pedido e a emissão de certificados digitais para dispositivos de rede sem intervenção manual.
Essencial para escalar implementações EAP-TLS, pois permite que os MDMs e portais de onboarding aprovisionem certificados em dezenas de milhares de dispositivos de estudantes de forma contínua.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
O método de autenticação 802.1X mais seguro, que exige um certificado tanto do lado do servidor como do lado do cliente para autenticação mútua.
Substitui protocolos vulneráveis baseados em palavra-passe, como o PEAP, eliminando o risco de roubo de credenciais através de pontos de acesso falsificados (evil twins).
MDM (Mobile Device Management)
Plataformas de software como o Microsoft Intune ou Jamf utilizadas para administrar e proteger dispositivos pertencentes à instituição.
Utilizado para enviar payloads SCEP e perfis de WiFi de forma silenciosa para dispositivos geridos, garantindo que estão configurados para acesso à rede antes da implementação.
CSR (Certificate Signing Request)
Um bloco de texto codificado gerado pelo dispositivo cliente que contém a chave pública e informações de identidade, enviado à CA para solicitar um certificado.
Num fluxo de trabalho SCEP, o dispositivo gera a chave privada localmente e envia apenas o CSR para o gateway, garantindo que a chave privada permanece segura no dispositivo final.
RADIUS (Remote Authentication Dial-In User Service)
O protocolo de rede que fornece gestão centralizada de autenticação, autorização e auditoria.
O servidor que avalia o certificado de cliente apresentado pelo dispositivo durante a troca 802.1X e determina a atribuição de VLAN.
Evil Twin Attack
Uma exploração de segurança na qual um atacante configura um ponto de acesso nocivo com o mesmo SSID que a rede legítima para intercetar credenciais de utilizador.
O EAP-TLS previne isto porque o dispositivo cliente verifica o certificado do servidor RADIUS antes de transmitir quaisquer dados; se o atacante não possuir o certificado de servidor confiável, a ligação cai.
MAB (MAC Authentication Bypass)
Um método de autenticação alternativo que utiliza o endereço MAC de um dispositivo como a sua credencial.
Necessário para a integração de dispositivos IoT autónomos (como consolas de jogos) em residências universitárias que não suportam 802.1X ou SCEP.
CRL (Certificate Revocation List)
Uma lista publicada pela Autoridade de Certificação contendo os números de série dos certificados que foram invalidados antes da sua data de expiração.
Crucial para a segurança da rede; o servidor RADIUS deve verificar a CRL para garantir que o acesso de dispositivos roubados ou de alunos graduados seja imediatamente negado.
Exemplos Práticos
Uma universidade com 20.000 estudantes está a migrar de PEAP-MSCHAPv2 para EAP-TLS. Utilizam o Microsoft Intune para 3.000 portáteis Windows pertencentes à universidade, mas os restantes 45.000 dispositivos são BYOD de estudantes (telemóveis, tablets, portáteis pessoais). Como devem desenhar a arquitetura de implementação de certificados para garantir que todos os dispositivos conseguem autenticar-se no primeiro dia de aulas?
A universidade deve implementar uma estratégia de registo bifurcada. Para os 3.000 portáteis geridos pelo Intune, a equipa de TI configura um perfil de Certificado SCEP no Intune, enviando o URL do gateway e a palavra-passe de desafio de forma silenciosa para os dispositivos. Para os 45.000 dispositivos BYOD, implementam um SSID de "Onboarding" aberto que restringe o tráfego a um Captive Portal self-service e ao gateway SCEP. Os estudantes ligam-se ao SSID de Onboarding, autenticam-se através de SSO SAML no Entra ID e descarregam um payload de configuração que aciona o registo SCEP. Assim que o certificado estiver instalado, o dispositivo associa-se automaticamente ao SSID seguro "eduroam" utilizando EAP-TLS.
Durante a primeira semana de aulas, o suporte técnico de uma universidade recebe relatórios de que os estudantes conseguem ligar-se ao WiFi com os seus portáteis, mas as suas colunas inteligentes e consolas de videojogos nas residências universitárias não conseguem ligar-se à rede 802.1X. Como deve o arquiteto de rede resolver isto?
O arquiteto deve implementar o MAC Authentication Bypass (MAB) para dispositivos sem ecrã/teclado. Como as colunas inteligentes e as consolas carecem de suplicantes 802.1X, não conseguem processar payloads SCEP nem apresentar certificados de cliente. A universidade deve implementar um portal self-service de registo de dispositivos onde os estudantes iniciam sessão com as suas credenciais universitárias e introduzem os endereços MAC dos seus dispositivos IoT. O servidor RADIUS é configurado para aceitar estes endereços MAC registados via MAB e atribuí-los à VLAN específica por quarto do estudante.
Perguntas de Prática
Q1. A sua universidade está a implementar EAP-TLS. Configurou o gateway SCEP e os perfis MDM. No entanto, quando os dispositivos de teste tentam ligar-se ao SSID seguro, a ligação falha silenciosamente. Os registos do RADIUS mostram que o certificado de cliente é válido, mas o dispositivo está a rejeitar o servidor. Qual é o erro de configuração mais provável?
Dica: Considere os requisitos para a autenticação mútua e o que o dispositivo necessita para confiar no servidor.
Ver resposta modelo
O perfil de Certificado Confiável do MDM está provavelmente em falta ou mal configurado. No EAP-TLS, a autenticação mútua exige que o dispositivo verifique o certificado do servidor RADIUS. Se o dispositivo não tiver o certificado da CA Raiz instalado no seu armazenamento confiável, não conseguirá validar o certificado do servidor e irá interromper a ligação para evitar um potencial Evil Twin Attack.
Q2. Um estudante relata que o seu portátil, que foi registado com sucesso através do portal BYOD e possui um certificado de cliente válido, já não consegue aceder à rede após ter alterado a sua palavra-passe no diretório da universidade. Que falha arquitetónica é que isto indica?
Dica: A autenticação EAP-TLS depende inteiramente do certificado, não da palavra-passe.
Ver resposta modelo
Isto indica que a rede não está realmente a utilizar EAP-TLS, mas está provavelmente a recorrer ao PEAP-MSCHAPv2 ou a outro protocolo baseado em palavra-passe. Se o verdadeiro EAP-TLS estiver configurado, o servidor RADIUS valida a assinatura criptográfica do certificado, desacoplando completamente o acesso à rede da palavra-passe do diretório. O arquiteto de rede deve impor políticas rigorosas de EAP-TLS no servidor RADIUS e desativar protocolos alternativos.
Q3. Durante a primeira semana de aulas, os servidores RADIUS estão a registar uma elevada utilização de CPU e erros de timeout intermitentes, causando falhas de autenticação generalizadas. Os servidores estão adequadamente dimensionados para o número total de sessões simultâneas. O que está a causar os timeouts?
Dica: Considere a diferença no processamento computacional entre verificar uma palavra-passe e validar uma cadeia de certificados durante a fase de ligação inicial.
Ver resposta modelo
Os timeouts são causados pelo pesado processamento computacional dos handshakes criptográficos do EAP-TLS durante a sobrecarga inicial de autenticação dos estudantes que regressam. O arquiteto deve aumentar o valor do timeout do RADIUS nos pontos de acesso sem fios (por exemplo, Cisco Meraki ou HPE Aruba) para pelo menos 5 segundos para acomodar a latência, e garantir que o balanceamento de carga está a distribuir uniformemente os pedidos de autenticação total inicial por todos os nós do RADIUS.
Continue a ler esta série
Per-Device PSK por Fabricante: iPSK, DPSK, MPSK e PPSK Comparados (e Suporte a WPA3)
Uma comparação abrangente de implementações de per-device PSK na Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Saiba como o WPA3-SAE afeta as estratégias de chaves por dispositivo e quando implementar modos de transição versus migrar para o 802.1X.
Métodos de Autenticação de Captive Portal Comparados
Este guia de referência técnica de autoridade avalia as compensações arquitetónicas, operacionais e de conformidade de cinco métodos principais de autenticação de captive portal. Fornece aos arquitetos de rede, diretores de TI e gestores de marketing os dados quantitativos e as estruturas de decisão necessários para equilibrar a fricção no registo de convidados com os requisitos de recolha de dados em locais empresariais.
O que é a Autenticação por Endereço MAC? Quando Usar e Quando Evitar
Este guia de referência técnica abrangente aborda a autenticação por endereço MAC em ambientes de WiFi empresarial — como funciona a autenticação MAC baseada em RADIUS na Camada 2, as suas vulnerabilidades de segurança inerentes (incluindo falsificação de MAC e o impacto da randomização de MAC ao nível do SO) e os contextos operacionais precisos onde continua a ser uma ferramenta válida para gerir IoT e dispositivos headless. Fornece orientações de implementação práticas para gestores de TI e arquitetos de rede em setores como hotelaria, retalho, saúde e espaços públicos, com exemplos práticos reais, estruturas de decisão e contexto de integração para a plataforma de guest WiFi e analytics da Purple.