Implantando SCEP para BYOD Seguro no Ensino Superior e Autenticação WiFi

Bem-vindo ao Purple Technical Briefing. Sou o seu anfitrião e hoje vamos abordar algo que surge constantemente no TI do ensino superior: a implantação do SCEP para autenticação segura de BYOD e WiFi. Se você está executando PEAP-MSCHAPv2 na rede do seu campus, este briefing é diretamente relevante para você. E se você já está planejando a transição para a autenticação baseada em certificados, apresentaremos a arquitetura, as armadilhas e a sequência de implementação para chegar lá. Vamos começar com o problema. As universidades são, por design, ambientes abertos. Os alunos chegam em setembro com dois, três, às vezes cinco dispositivos pessoais. Eles esperam se conectar imediatamente, de forma segura e sem precisar acionar o helpdesk. A realidade para a maioria das instituições é uma fila de helpdesk que atinge dois mil chamados em até quarenta e oito horas após o início do período letivo. Isso não é um problema de equipe. Isso é um problema de arquitetura. A causa raiz é quase sempre a mesma: autenticação WiFi baseada em senha. Ao executar o WPA2-Enterprise com PEAP e MSCHAPv2, você está solicitando que os alunos configurem manualmente as definições de 802.1X em cada dispositivo. Uma única configuração incorreta e eles ficam vulneráveis a um ataque man-in-the-middle. Pior ainda: quando a universidade força uma redefinição de senha a cada noventa dias, todos os dispositivos no campus perdem o acesso WiFi simultaneamente. Esse é um desastre previsível e evitável. A resposta é a autenticação baseada em certificados usando EAP-TLS, e o mecanismo que a torna escalável é o SCEP: o Simple Certificate Enrollment Protocol. O SCEP foi formalizado pelo IETF na RFC 8894 em 2020, embora esteja em uso desde o início dos anos 2000. Ele automatiza o processo de solicitação e instalação de certificados digitais X.509 nos dispositivos, sem exigir qualquer intervenção manual do TI por dispositivo. Veja como funciona em alto nível. Sua plataforma MDM, seja o Microsoft Intune ou o Jamf, envia um payload SCEP para cada dispositivo registrado. Esse payload contém duas coisas: a URL do gateway SCEP e uma senha de desafio compartilhada. O dispositivo gera uma Solicitação de Assinatura de Certificado, envia-a ao gateway SCEP, que valida a senha de desafio e encaminha a solicitação para a sua Autoridade Certificadora (CA). A CA assina o certificado e o devolve ao dispositivo. A partir desse momento, o dispositivo se autentica na sua rede WiFi usando EAP-TLS: o certificado comprova a identidade do dispositivo para o servidor RADIUS, e o certificado do servidor RADIUS comprova a identidade da rede para o dispositivo. Autenticação mútua. Sem troca de senhas pelo ar. Essa etapa de autenticação mútua é essencial. Com o PEAP, um aluno que se conectar a um ponto de acesso invasor que esteja transmitindo o seu SSID entregará alegremente suas credenciais. Com o EAP-TLS, o dispositivo verifica o certificado do servidor RADIUS antes de prosseguir. Se não corresponder à CA confiável, a conexão falha silenciosamente. Com isso, você elimina toda a classe de ataques de evil twin. Agora vamos falar de arquitetura. Uma implantação de SCEP em produção para uma universidade possui seis componentes principais. Primeiro, seu provedor de identidade: Microsoft Entra ID, Okta ou Google Workspace. Segundo, sua plataforma de MDM: Intune para Windows e Android, Jamf para macOS e iOS. Terceiro, sua Autoridade Certificadora (CA): seja o Microsoft Active Directory Certificate Services on-premises ou uma PKI em nuvem. Quarto, seu gateway SCEP: o endpoint HTTP que recebe as solicitações de certificado. Quinto, seu servidor RADIUS para autenticação. Sexto, sua camada de acesso: pontos de acesso Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist configurados para 802.1X. A cadeia de confiança funciona assim. A CA emite um certificado raiz. Essa raiz é distribuída para cada dispositivo via MDM, estabelecendo a confiança. A CA então emite certificados de cliente para os dispositivos via SCEP. Quando a conexão é estabelecida, o dispositivo apresenta seu certificado de cliente ao servidor RADIUS, e o servidor RADIUS apresenta seu certificado de servidor ao dispositivo. Ambos os lados realizam a verificação em relação à raiz confiável. O acesso é concedido ou negado com base na validade do certificado, e não em uma senha. Permita-me guiar você pela sequência de implementação. Esta é a ordem que funciona. Passo um: limpe seu repositório de identidades. Certifique-se de que seu Active Directory ou Entra ID possua grupos bem definidos para alunos, funcionários e convidados. As políticas de certificado e atribuições de VLAN estarão vinculadas a esses grupos. Passo dois: implante sua Autoridade Certificadora. Se estiver usando o Microsoft ADCS, configure uma hierarquia de duas camadas: uma CA raiz offline e uma CA emissora online. A CA raiz deve ser mantida em air-gap após a configuração inicial. Passo três: configure seu gateway SCEP. Este é o endpoint HTTP para o qual seu MDM direcionará os dispositivos. Certifique-se de que ele esteja acessível a partir do segmento de rede onde os dispositivos realizam o registro inicial, normalmente seu SSID de integração. Passo quatro: configure seu servidor RADIUS. Importe o certificado da CA emissora como uma CA confiável. Configure o EAP-TLS como seu método de autenticação. Configure os atributos de retorno de VLAN para que o RADIUS possa atribuir dinamicamente os alunos ao segmento de rede correto. Passo cinco: configure seus perfis de MDM. No Intune, crie primeiro um perfil de Certificado Confiável, depois um perfil de Certificado SCEP e, em seguida, um perfil de WiFi que faça referência ao certificado SCEP. Implante-os exatamente nessa ordem. Cada um depende da existência do anterior. Passo seis: configure seus pontos de acesso. No Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, configure seu SSID seguro para WPA2-Enterprise ou WPA3-Enterprise. Defina o timeout do RADIUS para pelo menos cinco segundos para acomodar a latência de validação de certificados durante os períodos de pico de integração. Agora, as armadilhas. Já vi isso comprometer implantações repetidamente. A primeira delas é implantar os perfis de MDM na ordem errada. Se o perfil de WiFi chegar ao dispositivo antes do perfil de certificado SCEP, o dispositivo não terá nenhum certificado para se autenticar. A conexão falhará e o usuário ligará para o suporte.O segundo erro é esquecer os dispositivos BYOD. O Intune e o Jamf gerenciam sua frota de propriedade da instituição. Mas os dispositivos pessoais dos alunos não estão registrados no seu MDM. Para esses, você precisa de um portal de integração self-service. O aluno se autentica via Single Sign-On usando suas credenciais universitárias, e o portal usa SCEP para provisionar o certificado. A plataforma da Purple integra esse fluxo de onboarding diretamente na experiência do Captive Portal, para que os alunos concluam o registro em menos de dois minutos, sem qualquer envolvimento da TI. O terceiro erro são as falhas de timeout do RADIUS durante o pico de integração. Faça testes de carga na sua infraestrutura RADIUS antes de setembro, não durante. Implemente o balanceamento de carga em pelo menos dois nós RADIUS. O quarto erro é a revogação de certificados. Quando um aluno sai, ou um dispositivo é perdido ou roubado, você precisa revogar o certificado imediatamente. Certifique-se de que sua CA publique uma Lista de Revogação de Certificados e que seu servidor RADIUS a verifique a cada autenticação. Agora, uma rápida sessão de perguntas e respostas sobre as dúvidas que ouvimos com mais frequência. O SCEP pode funcionar sem um MDM? Tecnicamente sim, mas na prática não. Sem um MDM para enviar o payload do SCEP e o perfil de WiFi, você volta para a configuração manual do dispositivo. Qual deve ser o tempo de validade do certificado? Para dispositivos de alunos, de um a dois anos é o padrão. Longo o suficiente para durar o ano letivo sem o atrito de renovação, curto o suficiente para limitar a exposição se um certificado for comprometido. E quanto aos dispositivos IoT que não oferecem suporte a 802.1X? Use o MAC Authentication Bypass com um portal de registro de dispositivos self-service. Os alunos registram o endereço MAC de seu console de videogame ou smart TV, e seu sistema NAC o coloca na VLAN correta. Isso funciona com o eduroam? Sim. O EAP-TLS é totalmente suportado pela federação eduroam. Certificados emitidos pela CA do seu campus podem autenticar alunos no eduroam em qualquer instituição participante em todo o mundo. Para encerrar, aqui estão as três decisões que definem uma implantação SCEP bem-sucedida. Primeiro: escolha sua arquitetura de CA antes de qualquer outra coisa. O ADCS local oferece controle total. A PKI em nuvem oferece simplicidade operacional. A escolha errada aqui custará meses de retrabalho. Segundo: automatize a integração de BYOD desde o primeiro dia. Não presuma que os alunos configurarão seus dispositivos pessoais manualmente. Eles não farão isso. Crie o portal self-service antes do início do período letivo. Terceiro: teste a capacidade do seu RADIUS sob carga antes de setembro. Uma interrupção do RADIUS no primeiro dia de aula é totalmente evitável. A plataforma da Purple oferece suporte a esses três pilares: integração de PKI de sobreposição em nuvem, integração de BYOD self-service por meio de nosso Captive Portal e infraestrutura RADIUS testada em oitenta mil locais ativos com noventa e nove vírgula nove nove nove por cento de uptime. Obrigado por participar do Purple Technical Briefing. Para obter mais orientações, acesse purple.ai.