Implementar SCEP para WiFi 802.1X e BYOD Seguro no Ensino Superior

Implementar SCEP para WiFi Seguro com BYOD e 802.1X no Ensino Superior Um Briefing Técnico da Purple - aproximadamente 10 minutos [INTRODUÇÃO E CONTEXTO - 1 minuto] Bem-vindo ao Briefing Técnico da Purple. Vou orientá-lo sobre um dos pontos problemáticos mais comuns que vemos nas equipas de TI do ensino superior: como colocar milhares de dispositivos de estudantes e funcionários numa rede WiFi segura e autenticada por certificado sem que o seu suporte técnico fique sobrecarregado com chamados. A resposta curta envolve quatro letras: SCEP. Ou seja, o Simple Certificate Enrollment Protocol. E quando o combina com o 802.1X e um serviço cloud RADIUS, obtém algo genuinamente poderoso - uma rede onde cada dispositivo prova a sua identidade antes de obter acesso, os certificados são emitidos e renovados automaticamente e a sua equipa de TI não precisa de intervir manualmente em cada dispositivo. As universidades enfrentam uma pressão real neste aspeto. Todos os anos, em setembro, chegam dezenas de milhares de estudantes com os seus próprios portáteis, telemóveis e tablets. É necessário integrá-los numa rede segura rapidamente. E precisa de garantir que, quando um estudante sai ou um dispositivo se perde, o acesso seja revogado de imediato. O SCEP é o mecanismo que faz tudo isto funcionar à escala. Vamos entrar nos detalhes técnicos. [ANÁLISE TÉCNICA DETALHADA - 5 minutos] Primeiro, vamos esclarecer o que é realmente o SCEP. É um protocolo - originalmente desenvolvido pela Cisco - que automatiza o processo de solicitação e receção de um certificado digital de uma Autoridade de Certificação. Antes do SCEP, colocar um certificado num dispositivo significava um processo manual que envolvia uma pen USB e muitos cliques, ou um registo complexo baseado na web que confundia a maioria dos utilizadores finais. O SCEP automatiza completamente essa troca de dados. Eis como funciona o fluxo num contexto universitário de BYOD. Um estudante chega ao campus. O seu dispositivo - seja um MacBook, um telemóvel Android ou um portátil Windows - é registado na sua plataforma de Gestão de Dispositivos Móveis, ou MDM. O MDM envia um perfil de configuração para o dispositivo. Esse perfil contém o URL do SCEP que aponta para a sua Autoridade de Certificação, uma palavra-passe de desafio para autenticação e o modelo de certificado a utilizar. O dispositivo gera um par de chaves localmente - a chave privada nunca sai do dispositivo - e envia um pedido de assinatura de certificado para a CA através do SCEP. A CA valida o pedido, emite um certificado e devolve-o ao dispositivo. Todo o processo demora segundos e não requer qualquer interação do utilizador para além do registo inicial no MDM. Agora, por que razão isto é importante especificamente para o WiFi? Porque o 802.1X - o padrão IEEE para controlo de acesso à rede baseado em portas - pode utilizar esse certificado como credencial de autenticação. Em vez de um nome de utilizador e palavra-passe, o dispositivo apresenta o seu certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua CA, confirma que o dispositivo é conhecido e fidedigno, e concede o acesso. Trata-se do EAP-TLS - Extensible Authentication Protocol com Transport Layer Security - e é o padrão de excelência para autenticação WiFi. As vantagens de segurança em relação às abordagens baseadas em palavras-passe são significativas. Os certificados não podem ser alvo de phishing. Um estudante não pode, acidentalmente, fornecer o seu certificado a uma rede falsa. A chave privada nunca sai do dispositivo, por isso, mesmo que um certificado seja intercetado de alguma forma, é inútil sem a chave privada correspondente. E como o certificado contém a identidade do dispositivo, obtém uma visibilidade detalhada de qual é exatamente o dispositivo que está na sua rede em qualquer momento. Agora vamos falar sobre os componentes de infraestrutura de que necessita. Precisa de uma Certificate Authority - que pode ser o Microsoft Active Directory Certificate Services, que a maioria das universidades já possui, ou uma CA baseada na nuvem. Precisa de um servidor NDES - Network Device Enrollment Service - que atua como o proxy SCEP entre os seus dispositivos e a sua CA. Precisa de um servidor RADIUS para processar a autenticação 802.1X. E precisa de pontos de acesso que suportem WPA2-Enterprise ou WPA3-Enterprise com 802.1X. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi e Fortinet suportam todos isto nativamente. Para o componente RADIUS, o SecurePass da Purple utiliza um serviço RADIUS nativo da nuvem. O servidor primário é rad1-secure.purple.ai e o secundário é rad2-secure.purple.ai, ambos na porta de autenticação padrão 1812 e na porta de accounting 1813. Isto elimina a necessidade de gerir a sua própria infraestrutura RADIUS local - o que historicamente tem sido um fardo operacional significativo para as equipas de TI das universidades. Para obter os passos completos de configuração, a documentação de suporte da Purple em support.purple.ai abrange o processo exato de configuração. Algo que vale a pena enfatizar: o SecurePass é construído com base no padrão Passpoint - também conhecido como Hotspot 2.0. Isto significa que um estudante que se inscreve na sua universidade não obtém apenas acesso seguro no campus. O seu dispositivo irá ligar-se automaticamente em qualquer um dos mais de 80.000 locais habilitados com OpenRoaming em todo o mundo - aeroportos, hotéis, estações de comboio. A identidade baseada em certificado viaja com eles. Esse é um benefício genuinamente útil para os estudantes que viajam. É importante configurar corretamente o SSID. O SecurePass requer um SSID dedicado com WPA2 ou WPA3-Enterprise e Hotspot 2.0 ativado. Não deve reutilizar o seu SSID de Captive Portal existente. O SSID deve ser transmitido - os SSIDs ocultos impedem o comportamento de ligação automática que faz todo o sistema funcionar. Para a integração com o fornecedor de identidade, o SecurePass sincroniza com o Microsoft Entra ID e o Google Workspace. Isto é crítico para o fluxo de trabalho de entradas, alterações e saídas de utilizadores. Quando um estudante se licencia ou um membro da equipa sai, a sua conta é desativada no Entra ID e o acesso é automaticamente revogado. Não é necessária a revogação manual de certificados. Esse é o tipo de automatização que poupa tempo real à sua equipa de TI. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - 2 minutos] Permita-me apresentar as recomendações práticas que daria a qualquer equipa de TI de uma universidade que esteja a iniciar este projeto. Primeiro, comece pelos funcionários antes dos estudantes. Os dispositivos dos funcionários são normalmente geridos - tem cobertura MDM, conhece o inventário de dispositivos e a população é menor. Acerte o processo com os funcionários, resolva os casos limite e depois expanda para os estudantes. Segundo, planeie cuidadosamente a vida útil dos certificados. Uma validade de certificado de um ano é uma escolha comum, mas pense no seu calendário académico. Se os certificados expirarem em agosto, terá uma vaga de renovações mesmo antes do início do novo ano letivo. Considere alinhar a expiração com o meio do semestre, ou utilize a renovação automática via SCEP para evitar totalmente o problema. Terceiro, teste a sua configuração NDES minuciosamente antes do lançamento. O NDES é o componente que mais frequentemente causa problemas. A palavra-passe de desafio deve ser gerada novamente para cada pedido de registo - tem uma janela de validade curta. Se o seu MDM estiver a gerar o pedido SCEP de forma demasiado lenta após obter a palavra-passe de desafio, o registo falhará. Teste com uma variedade de tipos de dispositivos e versões de sistemas operativos. Quarto, não negligencie a matriz de compatibilidade de dispositivos. O iOS, macOS, Android e Windows lidam com o SCEP de forma ligeiramente diferente. O iOS e o macOS têm suporte nativo para SCEP incorporado e funcionam perfeitamente com perfis enviados por MDM. O comportamento do Android varia de acordo com o fabricante. O Windows requer o conector NDES ou um agente MDM de terceiros. Documente as suas configurações suportadas e comunique-as claramente aos estudantes. O erro mais comum que vejo é o desinvestimento na camada de MDM. O SCEP é tão bom quanto a sua cobertura MDM. Se os estudantes tiverem dispositivos que não estão registados no MDM, não podem receber o perfil SCEP. Precisa de um processo de integração claro - idealmente integrado no seu fluxo de trabalho de inscrição de estudantes - que coloque os dispositivos no MDM antes de chegarem ao campus. [PERGUNTAS E RESPOSTAS RÁPIDAS - 1 minuto] Algumas perguntas rápidas que me fazem regularmente. O SCEP pode funcionar sem um MDM? Tecnicamente sim - pode distribuir perfis SCEP manualmente - mas à escala universitária, precisa de MDM. Sem ele, regressará aos processos manuais. O que acontece aos dispositivos que não suportam 802.1X? Continuam através do seu Captive Portal existente normalmente. O SecurePass é aditivo - os dispositivos não suportados não são bloqueados. Isto funciona para dispositivos IoT no campus? Os dispositivos IoT normalmente não suportam 802.1X. Segmente-os para uma VLAN separada com regras de firewall adequadas. Não tente colocar os sensores de edifícios inteligentes na mesma rede que os portáteis dos estudantes. O EAP-TLS é a única opção? Não. O PEAP com MSCHAPv2 é uma alternativa comum que utiliza nome de utilizador e palavra-passe em vez de certificados. Mas o EAP-TLS com certificados emitidos por SCEP é significativamente mais seguro e elimina a sobrecarga de gestão de palavras-passe. [RESUMO E PRÓXIMOS PASSOS - 1 minuto] Para resumir: o SCEP automatiza a inscrição de certificados à escala. Combinado com o 802.1X e o EAP-TLS, oferece-lhe uma rede onde cada dispositivo é autenticado criptograficamente, os certificados são emitidos e renovados sem a intervenção do departamento de TI e o acesso é revogado automaticamente quando alguém sai. Para uma universidade com milhares de dispositivos BYOD, essa é a diferença entre uma rede gerível e um pesadelo de suporte técnico. Os componentes chave são: uma Autoridade de Certificação, um servidor proxy NDES ou SCEP, um serviço cloud RADIUS e pontos de acesso que suportem WPA2 ou WPA3-Enterprise. O SecurePass da Purple fornece a camada cloud RADIUS e a distribuição de perfis baseada em Passpoint, integrando-se com o seu diretório Microsoft Entra ID ou Google Workspace existente. Os seus próximos passos: analise a cobertura do seu MDM e identifique lacunas, avalie a sua infraestrutura de CA e fale com o seu fornecedor de hardware de rede sobre o suporte para Passpoint. Depois, visite support.purple.ai para consultar o guia de configuração do SecurePass e a lista de compatibilidade de hardware. Obrigado por ouvir. Se tiver dúvidas, a equipa da Purple está disponível em purple.ai.