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

Bem-vindo ao Purple Technical Briefing. Eu sou o vosso anfitrião e hoje vamos analisar em detalhe um tema que surge constantemente no setor de TI do ensino superior: como implementar o SCEP - o Simple Certificate Enrolment Protocol - para disponibilizar BYOD e WiFi 802.1X seguros no campus. Se está a gerir uma rede universitária ou de ensino superior neste momento, provavelmente depara-se com uma tensão familiar. Por um lado, tem estudantes, docentes e funcionários a trazerem centenas ou milhares de dispositivos pessoais. Por outro, tem uma postura de segurança que precisa de cumprir requisitos institucionais, regulamentares e, cada vez mais, de seguros de cibersegurança. O WiFi baseado em palavras-passe e os portais cativos abertos simplesmente já não são suficientes. Por isso, vamos falar sobre o que realmente funciona. Primeiro, vamos enquadrar o cenário. O 802.1X é a norma IEEE para controlo de acesso à rede baseado em portas. Existe desde 2001, mas é mais relevante hoje do que nunca. A ideia central é que, antes de qualquer dispositivo entrar na sua rede, tem de provar quem é - não apresentando apenas uma palavra-passe que qualquer pessoa poderia partilhar, mas sim uma credencial verificável. Num contexto com fios, essa verificação de credenciais ocorre na porta do comutador. No WiFi, ocorre no ponto de acesso, intermediado por um servidor RADIUS. Ora, a credencial em si pode assumir várias formas. Pode utilizar um nome de utilizador e palavra-passe através de PEAP - o Protected Extensible Authentication Protocol. Ou pode utilizar um certificado digital através de EAP-TLS - Extensible Authentication Protocol com Transport Layer Security. O EAP-TLS é o padrão de excelência. É mútuo - a rede autentica-se perante o dispositivo e o dispositivo autentica-se perante a rede. Essa autenticação mútua é o que bloqueia pontos de acesso falsos. O portátil de um estudante simplesmente não se ligará a uma rede falsificada que não possua o certificado correto. Então, onde entra o SCEP? O SCEP - Simple Certificate Enrolment Protocol - é o mecanismo através do qual os dispositivos solicitam e recebem esses certificados digitais de forma automática. Sem o SCEP, teria de gerar e distribuir manualmente certificados para cada dispositivo. Numa universidade com dez mil estudantes e três mil funcionários, essa não é uma operação viável. O SCEP automatiza todo o processo. Eis como funciona o fluxo. Um dispositivo liga-se a uma rede de aprovisionamento - por vezes chamada SSID de integração. Contacta o seu servidor SCEP, que normalmente está integrado na sua Autoridade de Certificação - a sua CA. O dispositivo envia um Pedido de Assinatura de Certificado. O servidor SCEP valida o pedido, frequentemente verificando as credenciais do utilizador no seu diretório - Microsoft Entra ID ou Google Workspace. Uma vez validada, a CA emite um certificado assinado e o dispositivo instala-o. A partir desse momento, o dispositivo utiliza esse certificado para se autenticar automaticamente no seu SSID protegido por 802.1X. Sem portal, sem solicitação de palavra-passe, sem pedidos de suporte de TI. Vamos falar sobre a arquitetura com um pouco mais de detalhe. Numa implementação típica de ensino superior, terá de pensar em três segmentos de rede. Primeiro, a sua rede de integração - é aqui que os dispositivos não registados aterram. Tem acesso à internet, mas está isolada dos seus recursos internos. Segundo, o seu SSID protegido por 802.1X - é aqui que os dispositivos registados se ligam, com acesso total aos recursos adequados à sua função. Terceiro, a sua infraestrutura de gestão - o seu servidor RADIUS, a sua CA, o seu servidor SCEP e a sua integração de diretório. O servidor RADIUS é o polícia de trânsito. Quando um dispositivo tenta ligar-se ao seu SSID 802.1X, o ponto de acesso envia um pedido de autenticação ao RADIUS. O RADIUS valida o certificado em relação à lista de revogação de certificados da CA, verifica o estado do utilizador no seu diretório e concede ou nega o acesso. Também pode atribuir o dispositivo a uma VLAN com base na função - os estudantes vão para um segmento, os docentes para outro, o pessoal administrativo para um terceiro. Isto é o Identity-Based Networking na prática. Agora, uma das perguntas mais comuns que recebo é: com que hardware funciona isto? A boa notícia é que o 802.1X é um padrão, pelo que funciona com qualquer ponto de acesso que suporte WPA2 ou WPA3 Enterprise. Na prática, vai querer verificar a implementação específica do seu fornecedor. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi - todos estes suportam o padrão. Os passos de configuração variam de acordo com o fornecedor, mas o protocolo subjacente é o mesmo. Deixe-me orientá-lo sobre como é uma implementação real. Vou usar um exemplo composto com base numa universidade britânica de dimensão média - cerca de quinze mil estudantes, três campi, uma mistura de infraestrutura Aruba e Meraki. O projeto começou com uma auditoria de rede. A configuração existente era uma mistura de SSIDs abertos e um Captive Portal para acesso de estudantes. A equipa de TI estava sobrecarregada com pedidos de reposição de palavra-passe - cerca de quarenta por semana. A aleatorização de endereços MAC em iOS e Android tinha corrompido completamente as suas análises, pelo que não tinham dados fiáveis sobre os padrões de utilização da rede. A primeira fase foi a implementação da infraestrutura PKI. Instalaram uma CA de dois níveis - uma CA raiz offline e uma CA emissora online. O servidor SCEP foi integrado com a CA emissora e ligado ao Microsoft Entra ID para validação de identidade. O tempo de vida do certificado foi definido para um ano, com a renovação automática a ser acionada aos trinta dias. A segunda fase foi a configuração do SSID 802.1X. Criaram um SSID dedicado com WPA3-Enterprise, apontaram-no para os seus servidores RADIUS e configuraram regras de atribuição de VLAN. Os estudantes receberam uma VLAN, os funcionários outra e os dispositivos IoT uma terceira. A terceira fase foi a experiência de integração. Utilizaram uma solução de Network Access Control para redirecionar os dispositivos não registados para um portal de self-service. Os estudantes autenticavam-se com as suas credenciais universitárias, o fluxo SCEP corria em segundo plano e o certificado era instalado. Em iOS, isto exigia um perfil de configuração. Em Android, o processo era ligeiramente diferente, mas igualmente automatizado. O resultado? Os pedidos de reposição de palavra-passe diminuíram em mais de noventa por cento no primeiro mês. A visibilidade da rede melhorou drasticamente porque as identidades baseadas em certificados não mudam como os endereços MAC. E a equipa de segurança passou finalmente a ter um registo de auditoria fiável para cada dispositivo na rede. Agora vamos falar sobre como a Purple se enquadra neste cenário. O produto SecurePass da Purple baseia-se exatamente nesta arquitetura. O SecurePass emite perfis de WiFi assinados digitalmente utilizando WPA2 e WPA3-Enterprise com autenticação mútua 802.1X. O processo de registo demora menos de trinta segundos. Assim que um dispositivo tem um perfil, liga-se automaticamente - sem portal, sem palavra-passe, sem atrito. O que torna o SecurePass particularmente relevante para o ensino superior é a combinação de segurança e analítica. Como a credencial de autenticação é um certificado estável e não um endereço MAC rotativo, obtém dados precisos de visitas repetidas, tempos de permanência e frequência de visitas. Esses dados alimentam diretamente a plataforma de analítica da Purple, proporcionando-lhe uma visibilidade real de como a rede do seu campus está a ser utilizada. O SecurePass também se integra com o Microsoft Entra ID e o Google Workspace para implementações de funcionários. Isso significa que quando um membro do pessoal deixa a universidade, o seu acesso é revogado automaticamente. Sem processos manuais, sem contas esquecidas, sem lacunas de segurança. Trata-se do fluxo de trabalho de admissões, transferências e saídas automatizado de ponta a ponta. Para a infraestrutura RADIUS, a Purple opera servidores RADIUS na nuvem - primário e secundário - para que não precise de gerir essa infraestrutura por si próprio. A lista de hardware suportado abrange Cisco Meraki, Cisco Catalyst, HPE Aruba, Ubiquiti UniFi, Ruckus, Juniper Mist e Fortinet, entre outros. Os detalhes completos estão nas FAQ do SecurePass no site de suporte da Purple. Deixe-me indicar-lhe os erros comuns de implementação a evitar. Estes são os aspetos que costumam surpreender as equipas em implementações reais. Primeiro: revogação de certificados. Precisa de uma CRL - Certificate Revocation List - funcional ou de um respondedor OCSP. Se o seu servidor RADIUS não conseguir verificar o estado de revogação, ou bloqueia todas as ligações ou aceita todas as ligações. Nenhuma das opções é aceitável. Teste a sua infraestrutura de revogação antes de entrar em produção. Segundo: compatibilidade de dispositivos. A maioria dos dispositivos modernos iOS, Android, macOS e Windows suporta nativamente EAP-TLS. Mas os dispositivos mais antigos, terminais IoT e alguns sistemas legados não o fazem. Precisa de um plano para esses dispositivos - seja um SSID separado com uma autenticação diferente ou um processo de exceção gerido. Terceiro: tempo de vida e renovação dos certificados. Se os certificados expirarem e o processo de renovação falhar, os utilizadores perdem o acesso. Defina a sua janela de renovação de forma generosa - trinta dias antes da expiração é um mínimo razoável. Monitorize a expiração dos certificados de forma centralizada e emita alertas antes que se torne um problema. Quarto: a experiência de adesão. O fluxo técnico pode ser perfeito, mas se os estudantes acharem o processo de inscrição confuso, não o irão concluir. Invista numa sinalização clara, num portal de self-service simples e num guia de ajuda curto. A inscrição em trinta segundos que o SecurePass publicita é alcançável, mas apenas se a UX for adequada. Quinto: resiliência do servidor RADIUS. A sua infraestrutura 802.1X é agora um caminho crítico para o acesso à rede. Se o seu servidor RADIUS for abaixo, ninguém se liga. Precisa de servidores RADIUS primários e secundários, idealmente em diferentes zonas de disponibilidade, com failover automático. Agora, passemos às nossas perguntas e respostas rápidas. Estas são as perguntas que recebo com mais frequência. O SCEP pode funcionar com uma CA baseada na nuvem? Sim. O NDES - Network Device Enrolment Service - da Microsoft e vários fornecedores de CA na nuvem de terceiros suportam SCEP através de HTTPS. Não necessita de infraestrutura local. O 802.1X funciona com Passpoint e OpenRoaming? Sim. O Passpoint - também conhecido como Hotspot 2.0 - utiliza o 802.1X como a sua camada de autenticação. O OpenRoaming estende isso a uma federação global de redes fidedignas. Um estudante inscrito através do SecurePass irá ligar-se automaticamente em qualquer um dos mais de oitenta mil locais com OpenRoaming em todo o mundo. Isso inclui aeroportos, hotéis, interfaces de transporte - tudo sem qualquer ação adicional. E quanto ao acesso de convidados? O 802.1X e o SCEP destinam-se a dispositivos geridos e identidades conhecidas. Para convidados genuínos, continua a precisar de um mecanismo de acesso de convidados separado. Os dois sistemas funcionam em paralelo; não entram em conflito. O WPA3-Enterprise é obrigatório? Não, o WPA2-Enterprise com 802.1X ainda é amplamente implementado e perfeitamente seguro para a maioria dos casos de utilização. O WPA3-Enterprise adiciona uma encriptação mais forte. Se o seu hardware o suportar, ative-o. Caso contrário, o WPA2-Enterprise é uma base sólida. Para resumir, aqui estão as cinco ideias que gostaria que retivesse desta sessão informativa. Um: o 802.1X com autenticação baseada em certificados é a arquitetura de segurança correta para BYOD no ensino superior. As palavras-passe e os portais não são adequados para o ambiente de ameaças em que opera atualmente. Dois: o SCEP é o que torna a autenticação baseada em certificados escalável. Sem a inscrição automatizada, não conseguirá implementar certificados na escala que uma universidade exige. Três: a autenticação mútua é a propriedade de segurança fundamental. Protege os seus estudantes de pontos de acesso falsos tanto quanto protege a sua rede de dispositivos não autorizados. Quatro: a integração de diretórios - com o Microsoft Entra ID ou Google Workspace - é o que torna automático o fluxo de trabalho de entradas, transferências e saídas. Não implemente o 802.1X sem isso. Cinco: a experiência de integração determina a adoção. A tecnologia pode ser perfeita, mas se o processo de registo for complexo, passará mais tempo a resolver pedidos de suporte do que a poupar tempo. Se quiser aprofundar o assunto, o site de suporte da Purple tem documentação detalhada sobre o SecurePass, abrangendo a configuração RADIUS, a compatibilidade de hardware e o fluxo de registo. Os links estão nas notas do programa. Obrigado por ouvir. Vemo-nos no próximo briefing.