Como Configurar SCEP para WiFi Corporativa Segura e Aprovisionamento de BYOD

Bem-vindo a este briefing técnico da Purple. Sou o seu anfitrião e hoje vamos aprofundar a configuração de SCEP para WiFi corporativo seguro e aprovisionamento de BYOD. Para gestores de TI, arquitetos de rede e CTOs que operam nos setores de hotelaria, retalho e setor público, a gestão do acesso à rede é um equilíbrio constante entre segurança e eficiência operacional. Lida diariamente com centenas, por vezes milhares de dispositivos que se ligam à sua rede. Smartphones de funcionários, portáteis de subempreiteiros, tablets de pontos de venda. E as formas antigas de lidar com isto simplesmente já não são suficientes. Confiar em chaves pré-partilhadas, ou PSKs, para o WiFi de funcionários e BYOD é uma vulnerabilidade de segurança à espera de ser explorada. Uma palavra-passe partilhada, uma vez comprometida, dá a qualquer pessoa acesso à sua rede. E o MAC Authentication Bypass, ou MAB, não é melhor. Os smartphones modernos utilizam endereços MAC aleatórios por predefinição, o que quebra totalmente o MAB, e os endereços MAC podem ser falsificados em segundos. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS. Isto garante que cada dispositivo é verificado criptograficamente antes de tocar na rede. Mas eis o desafio: como distribuir certificados de cliente únicos para milhares de dispositivos não geridos sem sobrecarregar a sua equipa de suporte? A resposta é o Simple Certificate Enrolment Protocol, ou SCEP. Comecemos pela arquitetura. O SCEP é o padrão da indústria para o registo de dispositivos corporativos, definido no RFC 8894. Existe desde 1999, originalmente criado pela VeriSign, e resistiu ao teste do tempo porque resolve um problema genuinamente difícil de forma elegante. Num fluxo de trabalho SCEP, o dispositivo gera o seu próprio par de chaves privada e pública localmente. Cria um Pedido de Assinatura de Certificado, ou CSR, e envia-o através de um Network Device Enrolment Service, conhecido como NDES, para a sua Autoridade de Certificação, ou CA. A CA valida o pedido e devolve o certificado público assinado ao dispositivo. A vantagem crítica de segurança aqui é que a chave privada nunca sai do dispositivo. É gerada localmente e armazenada no enclave seguro de hardware do dispositivo. Num portátil Windows, esse é o Trusted Platform Module, ou TPM. Num iPhone, é o Secure Enclave. A chave privada nunca é transmitida através da rede. Isto é o que torna o SCEP vastamente superior a alternativas como o PKCS para autenticação de rede, onde a CA gera o par de chaves centralmente e o transmite para o dispositivo. Agora, falemos sobre BYOD. É aqui que as coisas se tornam genuinamente interessantes do ponto de vista operacional. Deseja que os funcionários possam utilizar os seus dispositivos pessoais para aceder a ferramentas internas, mas não quer forçá-los a registarem-se no MDM corporativo. Essa é uma preocupação de privacidade e encontra forte resistência por parte da equipa. A solução é um portal de integração self-service. Eis como funciona. O utilizador liga o seu dispositivo pessoal a um SSID de provisionamento dedicado. Esta rede é um jardim fechado (walled garden), que restringe o acesso a tudo, exceto ao portal de integração e ao seu fornecedor de identidade. O utilizador autentica-se utilizando as suas credenciais corporativas, normalmente através de integração SAML com Microsoft Entra ID, Okta ou Google Workspace. Após a autenticação bem-sucedida, o sistema gera um certificado de cliente exclusivo e específico do dispositivo via SCEP. É enviado para o dispositivo um perfil de configuração que contém o certificado, o certificado de CA raiz e as definições de rede. O dispositivo liga-se então automaticamente ao SSID corporativo seguro utilizando EAP-TLS. É simples para o utilizador e seguro para a empresa. Não precisam de saber nada sobre certificados ou 802.1X. Só têm de iniciar sessão uma vez e ficam ligados. Agora, vamos analisar a implementação em detalhe. A sequência de implementação é fundamental, e errar nesta fase é a causa mais comum de falha. Passo um: implementar o Certificado de Raiz Confiável. Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação emissora. Exporte o seu certificado de CA Raiz como um ficheiro .cer e implemente-o nos grupos de dispositivos de destino. Este passo é inegociável. Sem ele, toda a cadeia falha. Passo dois: configurar o Perfil de Certificado SCEP. Isto instrui os dispositivos sobre como obter o seu certificado de cliente. Precisa de configurar o formato do nome do requerente. Para autenticação baseada no utilizador, o padrão é CN igual a UserPrincipalName. Para autenticação de dispositivos, utilize CN igual ao ID do Dispositivo Azure AD. Defina a utilização da chave como assinatura digital e cifragem de chave. Na utilização de chave estendida, especifique Autenticação de Cliente com o OID 1.3.6.1.5.5.7.3.2. Associe este perfil ao perfil de certificado de Raiz Confiável do passo um. E forneça o URL externo do seu servidor NDES. Passo três: implementar o Perfil WiFi 802.1X. Isto associa os certificados ao SSID da rede. Introduza o nome da rede exatamente como é transmitido pelos seus pontos de acesso. Defina o tipo de segurança como WPA2-Enterprise ou WPA3-Enterprise. Defina o tipo de EAP como EAP-TLS. Selecione o perfil de certificado SCEP como o certificado de autenticação de cliente. E especifique o certificado de Raiz Confiável para validação do servidor. Esta sequência é a coisa mais importante a reter de toda esta sessão informativa. Confiança, depois certificado, depois WiFi. Por esta ordem, sempre. Agora, permita-me partilhar algumas boas práticas que lhe pouparão dores de cabeça significativas em ambiente de produção. Primeiro, publique o seu servidor NDES através do Azure AD Application Proxy. O servidor NDES deve estar acessível a partir da internet para permitir que os dispositivos remotos provisionem certificados antes de chegarem ao local. Mas expor um servidor interno diretamente à internet é um risco de segurança significativo. O Application Proxy oferece-lhe um acesso remoto seguro sem abrir portas de entrada na firewall. Segundo, implemente certificados de curta duração para dispositivos BYOD. Em vez de um certificado válido por três anos, emita certificados válidos por 90 dias. Quando o certificado expira, o utilizador deve re-autenticar-se através do portal de integração. Isto elimina naturalmente os dispositivos inativos da rede. Um dispositivo que não tenha sido utilizado em 90 dias simplesmente perde o acesso. Não é necessária qualquer limpeza manual. Terceiro, e isto é absolutamente crítico, configure o seu servidor RADIUS para impor uma verificação rigorosa da Lista de Revogação de Certificados. Quando um colaborador deixa a organização, desativar a sua conta de Active Directory pode não revogar imediatamente o seu acesso WiFi se o certificado de cliente continuar válido. O seu servidor RADIUS deve verificar a CRL antes de conceder o acesso. Garanta que os seus Pontos de Distribuição de CRL estão altamente disponíveis. Se o servidor RADIUS não conseguir aceder à CRL, a autenticação falha para todos. Trata-se de uma interrupção generalizada. Vejamos agora alguns modos de falha comuns e como evitá-los. O problema mais frequente é a falha na aplicação do perfil de WiFi. O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro na consola de MDM. Nove em cada dez vezes, trata-se de um desalinhamento na atribuição de grupos. Se o perfil SCEP for atribuído a um Grupo de Utilizadores, mas o perfil de WiFi for atribuído a um Grupo de Dispositivos, o MDM não consegue resolver a dependência. Audite as suas atribuições. Garanta que os três perfis visam exatamente o mesmo grupo. O segundo problema comum são os erros NDES 403 Forbidden. Os dispositivos falham ao obter o certificado SCEP e os registos do NDES IIS apresentam erros HTTP 403. Isto é normalmente causado pelo facto de a conta de serviço do conector não ter as permissões necessárias no modelo de certificado, ou por uma firewall que está a bloquear os parâmetros específicos da query string utilizados pelo SCEP. Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os registos da sua firewall para garantir que os URLs que contêm o parâmetro operation equals GetCACaps não estão a ser bloqueados. Permita-me apresentar dois cenários do mundo real para ilustrar como isto se processa na prática. Cenário um: um hotel de 200 quartos com 50 funcionários de limpeza que utilizam os seus smartphones pessoais para aceder à aplicação de horários. O gestor de TI pretende evitar a inscrição total no MDM para respeitar a privacidade dos funcionários. A solução é um portal de self-service integrado com o Microsoft Entra ID. Os funcionários ligam-se ao SSID de provisionamento, iniciam sessão com as suas credenciais do Entra ID e descarregam um perfil SCEP. O servidor SCEP emite um certificado de cliente de 30 dias diretamente para o dispositivo. O dispositivo liga-se ao SSID de WiFi dos funcionários utilizando EAP-TLS. O servidor RADIUS atribui estes dispositivos a uma VLAN restrita que apenas permite o acesso à aplicação de horários. Quando um funcionário se demite, a sua conta do Entra ID é desativada e o servidor RADIUS recusa instantaneamente o acesso à rede. Cenário dois: uma cadeia de retalho nacional com 500 lojas a implementar WiFi seguro para tablets de ponto de venda propriedade da empresa. O arquiteto de rede precisa de garantir que, mesmo que um tablet seja roubado, as credenciais não possam ser extraídas. A solução é o Microsoft Intune a implementar certificados via SCEP. O Intune envia o certificado Trusted Root, seguido de um perfil SCEP que instrui o tablet a gerar a sua própria chave privada no seu enclave de hardware seguro. O tablet submete um CSR ao servidor NDES, recebe o certificado de cliente e liga-se ao SSID Retail POS usando EAP-TLS. Como a chave privada é gerada localmente e nunca é transmitida, as credenciais de um tablet roubado não podem ser usadas noutro local. Isto satisfaz os requisitos de conformidade PCI-DSS. Agora, falemos sobre o caso de negócio. A transição para a implementação de certificados SCEP 802.1X proporciona retornos mensuráveis em termos de segurança e operações. O WiFi baseado em palavras-passe gera um volume significativo de pedidos de suporte ao helpdesk. Expiração de palavras-passe, bloqueios, erros de digitação. A autenticação baseada em certificados é invisível para o utilizador. Os dispositivos ligam-se automaticamente. Isto reduz tipicamente o volume de helpdesk relacionado com WiFi em 70%. Trata-se de uma redução material nos custos operacionais. O EAP-TLS elimina o risco de recolha de credenciais e de ataques Man-in-the-Middle. Isto é fundamental para a conformidade com o PCI-DSS em ambientes de retalho e com o GDPR em todos os setores. O custo de uma violação de dados excede de longe o custo de implementar uma infraestrutura PKI adequada. E para as organizações que já utilizam a plataforma de WiFi de convidados e analítica da Purple, a extensão do onboarding seguro aos dispositivos BYOD dos colaboradores proporciona uma estratégia unificada de gestão de rede. A sobreposição de nuvem independente de hardware da Purple integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, para que não fique fidelizado a um único fornecedor de hardware. A Purple opera em 80 000 locais ativos e processou 440 milhões de inícios de sessão em 2024, detendo as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. Permita-me encerrar com um resumo rápido das principais decisões que precisa de tomar. Deve utilizar SCEP ou PKCS? Utilize SCEP para autenticação WiFi. A chave privada permanece no dispositivo. Utilize PKCS apenas para encriptação de e-mail onde a custódia de chaves é necessária. Qual deve ser o período de validade dos certificados? 90 dias para BYOD. Um a dois anos para dispositivos geridos pela empresa. Deve utilizar a segmentação por utilizador ou por dispositivo no seu MDM? Utilize a segmentação por dispositivo para dispositivos corporativos que precisam de se ligar antes do início de sessão do utilizador. Utilize a segmentação por utilizador para BYOD onde o certificado deve estar associado ao indivíduo. Como lidar com a fragmentação do Android? Utilize o Passpoint, também conhecido como Hotspot 2.0, sempre que possível. Este proporciona uma experiência de ligação consistente entre os vários fabricantes Android. E, finalmente, qual é o aspeto mais importante a acertar? A verificação de CRL no seu servidor RADIUS. Sem ela, um certificado revogado ainda pode conceder acesso à rede. Chegamos ao fim do briefing de hoje. Se quiser aprofundar qualquer um destes tópicos, os guias técnicos da Purple sobre segurança de WiFi empresarial e autenticação de certificados EAP-TLS estão disponíveis no website da Purple em purple.ai. Obrigado por ouvir.