Como Configurar SCEP para WiFi Corporativo Seguro e Provisionamento de BYOD

Bem-vindo a este briefing técnico da Purple. Eu sou o seu anfitrião e hoje vamos nos aprofundar na configuração do SCEP para provisionamento seguro de WiFi corporativo e BYOD. Para gerentes de TI, arquitetos de rede e CTOs que atuam nos setores de hotelaria, varejo e público, gerenciar o acesso à rede é um equilíbrio constante entre segurança e eficiência operacional. Vocês lidam com centenas, às vezes milhares de dispositivos se conectando à sua rede todos os dias. Smartphones de funcionários, notebooks de prestadores de serviço, tablets de ponto de venda. E as formas antigas de lidar com isso simplesmente não são mais suficientes. Depender de Chaves Pré-Compartilhadas, ou PSKs, para o WiFi de funcionários e BYOD é uma vulnerabilidade de segurança esperando para ser explorada. Uma senha compartilhada, uma vez comprometida, dá a qualquer pessoa acesso à sua rede. E o MAC Authentication Bypass, ou MAB, não é melhor. Os smartphones modernos usam endereços MAC aleatórios por padrã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 usando EAP-TLS. Isso garante que cada dispositivo seja verificado criptograficamente antes de tocar a rede. Mas aqui está o desafio: como distribuir certificados de cliente exclusivos para milhares de dispositivos não gerenciados sem sobrecarregar o seu helpdesk? A resposta é o Simple Certificate Enrollment Protocol, ou SCEP. Vamos começar com a arquitetura. O SCEP é o padrão da indústria para registro de dispositivos corporativos, definido na RFC 8894. Ele existe desde 1999, criado originalmente pela VeriSign, e resistiu ao teste do tempo porque resolve um problema genuinamente difícil de forma elegante. Em um fluxo de trabalho SCEP, o dispositivo gera seu próprio par de chaves pública e privada localmente. Ele cria uma Solicitação de Assinatura de Certificado, ou CSR, e a envia por meio de um Network Device Enrollment Service, conhecido como NDES, para a sua Autoridade Certificadora, ou CA. A CA valida a solicitação e retorna o certificado público assinado para o dispositivo. A vantagem crítica de segurança aqui é que a chave privada nunca sai do dispositivo. Ela é gerada localmente e armazenada no enclave seguro de hardware do dispositivo. Em um notebook Windows, esse é o Trusted Platform Module, ou TPM. Em um iPhone, é o Secure Enclave. A chave privada nunca é transmitida pela rede. É isso que torna o SCEP amplamente superior a alternativas como o PKCS para autenticação de rede, onde a CA gera o par de chaves de forma centralizada e o transmite para o dispositivo. Agora, vamos falar sobre BYOD. É aqui que as coisas ficam genuinamente interessantes do ponto de vista operacional. Você quer que os funcionários possam usar seus dispositivos pessoais para acessar ferramentas internas, mas não quer forçá-los a se registrar no MDM corporativo. Isso é uma preocupação de privacidade e encontra forte resistência por parte da equipe. A solução é um portal de integração self-service. Veja como funciona. O usuário conecta seu dispositivo pessoal a um SSID de provisionamento dedicado. Essa rede é um walled garden, restringindo o acesso a tudo, exceto ao portal de integração e ao seu provedor de identidade. O usuário se autentica usando suas credenciais corporativas, normalmente por meio 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. Um perfil de configuração é enviado ao dispositivo contendo o certificado, o certificado CA raiz e as configurações de rede. O dispositivo então se conecta automaticamente ao SSID corporativo seguro usando EAP-TLS. É simples para o usuário e seguro para a empresa. Eles não precisam saber nada sobre certificados ou 802.1X. Eles apenas fazem login uma vez e já estão conectados. Agora, vamos detalhar a implementação. A sequência de implantação é crítica, e errar nessa etapa é a causa mais comum de falhas. Passo um: implante o Certificado Raiz Confiável. Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora. Exporte seu certificado CA Raiz como um arquivo .cer e implante-o nos grupos de dispositivos de destino. Este passo é inegociável. Sem ele, toda a cadeia falha. Passo dois: configure o Perfil de Certificado SCEP. Isso instrui os dispositivos sobre como obter seu certificado de cliente. Você precisa configurar o formato do nome do assunto. Para autenticação baseada no usuário, o padrão é CN igual a UserPrincipalName. Para autenticação de dispositivo, use CN igual ao Azure AD Device ID. Defina o uso da chave para assinatura digital e criptografia de chave. Em uso estendido de chave, especifique Autenticação de Cliente com o OID 1.3.6.1.5.5.7.3.2. Vincule este perfil ao perfil de certificado Raiz Confiável do passo um. E forneça a URL externa do seu servidor NDES. Passo três: implante o Perfil WiFi 802.1X. Isso vincula os certificados ao SSID da rede. Insira o nome da rede exatamente como ele é 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 do cliente. E especifique o certificado Raiz Confiável para validação do servidor. Esta sequência é a coisa mais importante a ser lembrada de todo este briefing. Confiança, depois certificado, depois WiFi. Nessa ordem, sempre. Agora, deixe-me apresentar algumas práticas recomendadas que pouparão você de grandes dores de cabeça em produção. Primeiro, publique seu servidor NDES via Azure AD Application Proxy. O servidor NDES deve estar acessível pela internet para permitir que 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 acesso remoto seguro sem abrir portas de firewall de entrada. Em segundo lugar, 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 usuário deverá se autenticar novamente por meio do portal de integração. Isso elimina naturalmente os dispositivos inativos da rede. Um dispositivo que não é usado há 90 dias simplesmente é desconectado. Nenhuma limpeza manual é necessária. Em terceiro lugar, e isso é absolutamente crítico, configure seu servidor RADIUS para impor uma verificação rigorosa da Lista de Revogação de Certificados (CRL). Quando um funcionário deixa a organização, desativar sua conta do Active Directory pode não revogar imediatamente seu acesso ao WiFi se o certificado do cliente continuar válido. Seu servidor RADIUS deve verificar a CRL antes de conceder o acesso. Certifique-se de que seus Pontos de Distribuição de CRL estejam altamente disponíveis. Se o servidor RADIUS não conseguir acessar a CRL, a autenticação falhará para todos. Isso representa uma interrupção generalizada. Agora, vamos analisar 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 é exibido como Erro no console MDM. Em noventa por cento dos casos, trata-se de uma incompatibilidade de direcionamento de grupo. Se o perfil SCEP estiver atribuído a um Grupo de Usuários, mas o perfil de WiFi estiver atribuído a um Grupo de Dispositivos, o MDM não conseguirá resolver a dependência. Audite suas atribuições. Certifique-se de que todos os três perfis tenham como alvo exatamente o mesmo grupo. O segundo problema comum são os erros NDES 403 Forbidden. Os dispositivos não conseguem recuperar o certificado SCEP e os logs do NDES IIS mostram erros HTTP 403. Isso geralmente é causado pelo fato de a conta de serviço do conector não ter as permissões necessárias no modelo de certificado ou por um firewall bloqueando os parâmetros específicos da string de consulta usados pelo SCEP. Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os logs do seu firewall para garantir que as URLs que contêm o parâmetro operation equals GetCACaps não estejam sendo bloqueadas. Deixe-me apresentar dois cenários do mundo real para ilustrar como isso funciona na prática. Cenário um: um hotel de 200 quartos com 50 funcionários de limpeza que usam smartphones pessoais para acessar o aplicativo de escala de trabalho. O gerente de TI deseja evitar o registro completo no MDM para respeitar a privacidade da equipe. A solução é um portal de autoatendimento integrado ao Microsoft Entra ID. A equipe se conecta ao SSID de provisionamento, faz login com suas credenciais do Entra ID e baixa um perfil SCEP. O servidor SCEP emite um certificado de cliente de 30 dias diretamente para o dispositivo. O dispositivo se conecta ao SSID de WiFi da equipe usando EAP-TLS. O servidor RADIUS atribui esses dispositivos a uma VLAN restrita que permite apenas o acesso ao aplicativo de escala. Quando um funcionário se demite, sua conta do Entra ID é desativada e o servidor RADIUS nega instantaneamente o acesso à rede. Cenário dois: uma rede varejista nacional com 500 lojas implantando WiFi seguro para tablets de ponto de venda de propriedade da empresa. O arquiteto de rede precisa garantir que, mesmo se um tablet for roubado, as credenciais não possam ser extraídas. A solução é o Microsoft Intune implantando certificados via SCEP. O Intune envia o certificado Trusted Root, seguido por um perfil SCEP que instrui o tablet a gerar sua própria chave privada em seu enclave seguro de hardware. O tablet envia um CSR para o servidor NDES, recebe o certificado do cliente e se conecta ao SSID do PDV de varejo usando EAP-TLS. Como a chave privada é gerada localmente e nunca transmitida, as credenciais de um tablet roubado não podem ser usadas em outro lugar. Isso atende aos requisitos de conformidade com o PCI DSS. Agora, vamos falar sobre o caso de negócios. A transição para a implantação de certificados SCEP 802.1X oferece retornos mensuráveis em segurança e operações. O WiFi baseado em senha gera um volume significativo de chamados de suporte. Expirações de senha, bloqueios, erros de digitação. A autenticação baseada em certificado é invisível para o usuário. Os dispositivos se conectam automaticamente. Isso normalmente reduz o volume de suporte relacionado ao WiFi em 70%. Essa é uma redução material no custo operacional. O EAP-TLS elimina o risco de coleta de credenciais e ataques Man-in-the-Middle. Isso é fundamental para a conformidade com o PCI DSS em ambientes de varejo e com a GDPR em todos os setores. O custo de uma violação de dados supera em muito o custo de implantar uma infraestrutura PKI adequada. E para organizações que já utilizam a plataforma de análise e Guest WiFi da Purple, estender a integração segura para dispositivos BYOD de funcionários oferece uma estratégia unificada de gerenciamento de rede. A sobreposição de nuvem independente de hardware da Purple se integra com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, para que você não fique preso a um único fornecedor de hardware. A Purple opera em 80.000 locais ativos e processou 440 milhões de logins em 2024, possuindo as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. Deixe-me encerrar com um resumo rápido das principais decisões que você precisa tomar. Você deve usar SCEP ou PKCS? Use SCEP para autenticação WiFi. A chave privada permanece no dispositivo. Use PKCS apenas para criptografia 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 gerenciados pela empresa. Você deve usar o direcionamento por usuário ou por dispositivo no seu MDM? Use o direcionamento por dispositivo para dispositivos corporativos que precisam se conectar antes do login do usuário. Use o direcionamento por usuário para BYOD, onde o certificado deve ser vinculado ao indivíduo. Como você lida com a fragmentação do Android? Use o Passpoint, também conhecido como Hotspot 2.0, sempre que possível. Ele fornece uma experiência de conexão consistente entre os fabricantes de Android. E, finalmente, qual é a coisa mais importante a ser feita corretamente? A verificação de CRL no seu servidor RADIUS. Sem ela, um certificado revogado ainda pode conceder acesso à rede. Esse é o fim do briefing de hoje. Se você quiser se aprofundar em qualquer um desses tópicos, os guias técnicos da Purple sobre segurança de WiFi corporativo e autenticação de certificado EAP-TLS estão disponíveis no site da Purple em purple.ai. Obrigado por ouvir.