Como Configurar o SCEP para WiFi Corporativo Seguro e Provisionamento de BYOD

Bem-vindo a este briefing técnico da Purple. Eu sou o vosso anfitrião e hoje vamos aprofundar a configuração do SCEP para WiFi empresarial seguro e aprovisionamento de BYOD. Para gestores de TI, arquitetos de rede e CTOs que operam nos setores da hotelaria, retalho e público, a gestão do acesso à rede é um equilíbrio constante entre segurança e eficiência operacional. Lidam diariamente com centenas, por vezes milhares de dispositivos a ligarem-se à vossa rede. Smartphones de funcionários, portáteis de prestadores de serviços, tablets de pontos de venda. E os métodos antigos de lidar com isto já não são suficientes. Depender de Pre-Shared Keys, 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 à vossa 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 o MAB por completo, 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 aceder à rede. Mas aqui está o desafio: como distribuir certificados de cliente únicos para milhares de dispositivos não geridos sem sobrecarregar o vosso suporte técnico? A resposta é o Simple Certificate Enrollment Protocol, ou SCEP. Comecemos pela arquitetura. O SCEP é o padrão da indústria para o registo de dispositivos empresariais, definido no RFC 8894. Existe desde 1999, criado originalmente 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 Certificate Signing Request, ou CSR, e envia-o através de um Network Device Enrollment Service, conhecido como NDES, para a vossa Certificate Authority, 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 pela rede. Isto é o que torna o SCEP amplamente 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. Querem que os funcionários possam utilizar os seus dispositivos pessoais para aceder a ferramentas internas, mas não querem forçá-los a registarem-se no vosso MDM corporativo. Isso é uma preocupação de privacidade e enfrenta uma forte resistência por parte dos funcionários. 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 "walled garden", restringindo 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 o Microsoft Entra ID, Okta ou Google Workspace. Após a autenticação bem-sucedida, o sistema gera um certificado de cliente único e específico do dispositivo via SCEP. Um perfil de configuração é enviado para o dispositivo contendo o certificado, o certificado 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. Apenas iniciam sessão uma vez e ficam ligados. Agora, vamos analisar a implementação em detalhe. A sequência de implementação é crítica, e errar nesta fase é a causa mais comum de falha. Passo um: implementar o Certificado de Raiz Confiável. Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação emissora. Exporte o seu certificado Root CA como um ficheiro .cer e implemente-o nos seus grupos de dispositivos de destino. Este passo não é negociá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 Azure AD Device ID. Defina a utilização da chave para assinatura digital e cifragem de chave. Em 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 para WPA2-Enterprise ou WPA3-Enterprise. Defina o tipo de EAP para 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. A sequência é o aspeto mais importante a reter de toda esta apresentação. Confiança, depois certificado, depois WiFi. Por esta ordem, sempre. Agora, permita-me apresentar algumas das melhores práticas que lhe pouparão dores de cabeça significativas em 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 expirar, o utilizador deve autenticar-se novamente 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 deixa de ter 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 (CRL). Quando um colaborador deixa a organização, desativar a sua conta do 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. Certifique-se de 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. Isso representa uma interrupção generalizada. Agora, vejamos 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 uma incompatibilidade de segmentação de grupos. Se o perfil SCEP estiver atribuído a um Grupo de Utilizadores, mas o perfil de WiFi estiver atribuído a um Grupo de Dispositivos, o MDM não consegue resolver a dependência. Audite as suas atribuições. Certifique-se de que os três perfis visam exatamente o mesmo grupo. O segundo problema comum são os erros NDES 403 Forbidden. Os dispositivos não conseguem obter o certificado SCEP e os registos do NDES IIS mostram 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 estar 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 AC. 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. Deixe-me apresentar-lhe dois cenários do mundo real para ilustrar como isto funciona na prática. Cenário um: um hotel de 200 quartos com 50 funcionários de limpeza que utilizam smartphones pessoais para aceder à aplicação de escalas. O gestor de TI quer 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 aprovisionamento, 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 escalas. Quando um funcionário se demite, a sua conta do Entra ID é desativada e o servidor RADIUS nega instantaneamente o acesso à rede. Cenário dois: uma cadeia nacional de retalho com 500 lojas a implementar WiFi seguro para tablets de ponto de venda de propriedade corporativa. 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 seguro de hardware. O tablet envia um CSR para o servidor NDES, recebe o certificado de cliente e liga-se ao SSID de POS de Retalho utilizando EAP-TLS. Como a chave privada é gerada localmente e nunca é transmitida, as credenciais de um tablet roubado não podem ser utilizadas noutro local. Isto cumpre os requisitos de conformidade com o 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 palavra-passe gera um volume significativo de pedidos de suporte ao helpdesk. Expirações 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 normalmente 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 em muito o custo de implementar uma infraestrutura PKI adequada. E para as organizações que já utilizam a plataforma de Guest WiFi e analítica da Purple, alargar o onboarding seguro aos dispositivos BYOD dos colaboradores proporciona uma estratégia de gestão de rede unificada. O overlay de nuvem agnóstico de hardware da Purple integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, para que não fique dependente de 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. Deixe-me terminar 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 a 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 lida 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 fabricantes de Android. E, finalmente, qual é a coisa mais importante a acertar? A verificação de CRL no seu servidor RADIUS. Sem ela, um certificado revogado ainda pode conceder acesso à rede. Chegámos ao fim do briefing de hoje. Se pretender 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 nos ouvir.