Como configurar SCEP para WiFi corporativo seguro e provisionamento de BYOD

Boas-vindas a este informativo técnico da Purple. Sou o seu anfitrião e hoje vamos nos aprofundar na configuração do SCEP para WiFi corporativo seguro e provisionamento de 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ços, tablets de ponto de venda. E as formas antigas de lidar com isso simplesmente não são mais suficientes. Depender de Pre-Shared Keys, 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 completamente, além de endereços MAC poderem ser clonados 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 na rede. Mas aqui está o desafio: como distribuir certificados de cliente exclusivos para milhares de dispositivos não gerenciados sem sobrecarregar seu suporte técnico? A resposta é o Simple Certificate Enrolment 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 privada e pública localmente. Ele cria uma Certificate Signing Request, ou CSR, e a envia por meio de um Network Device Enrolment 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 de hardware seguro 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 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 dos funcionários. 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. Esta rede é um jardim murado (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 se conecta automaticamente ao SSID corporativo seguro usando EAP-TLS. É integrado para o usuário e seguro para a empresa. Eles não precisam saber nada sobre certificados ou 802.1X. Eles apenas fazem o login uma vez e estão conectados. Agora, vamos detalhar a implementação. A sequência de implantação é crítica, e errar nesta 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 em seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora. Exporte o certificado Root CA como um arquivo .cer e implante-o em seus 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 orientada pelo 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 como assinatura digital e criptografia de chave. Em uso estendido da 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 de 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 é o ponto mais importante a ser lembrado de toda esta apresentação. Confiança, depois certificado, depois WiFi. Nessa ordem, sempre. Agora, permita-me apresentar algumas práticas recomendadas que pouparão dores de cabeça significativas 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 físico. No entanto, expor um servidor interno diretamente à internet é um risco de segurança significativo. O Application Proxy oferece acesso remoto seguro sem a necessidade de abrir portas de entrada no 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 usuário deverá autenticar-se 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 perde o acesso. Nenhuma limpeza manual é necessária. Terceiro, e isso é absolutamente crítico, configure seu servidor RADIUS para impor uma verificação rigorosa da Lista de Revogação de Certificados. Quando um funcionário sai da organização, desativar sua conta no Active Directory pode não revogar imediatamente seu acesso 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 é o perfil de WiFi que não se aplica. O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é exibido como Erro no console do MDM. Nove em cada dez vezes, trata-se de uma incompatibilidade de direcionamento de grupo. Se o perfil SCEP for atribuído a um Grupo de Usuários, mas o perfil de WiFi for 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 destino 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 IIS do NDES exibem erros HTTP 403. Isso geralmente é causado pela conta de serviço do conector que não possui as permissões necessárias no modelo de certificado, ou por um firewall que bloqueia os parâmetros específicos de 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 usando smartphones pessoais para acessar o aplicativo de escala de trabalho. O gerente de TI quer evitar o registro completo no MDM para respeitar a privacidade dos funcionários. A solução é um portal de autoatendimento integrado ao Microsoft Entra ID. Os funcionários se conectam ao SSID de provisionamento, fazem login com suas credenciais do Microsoft Entra ID e baixam um perfil SCEP. O servidor SCEP emite um certificado de cliente de 30 dias diretamente para o dispositivo. O dispositivo se conecta ao SSID do WiFi dos funcionários usando EAP-TLS. O servidor RADIUS atribui esses dispositivos a uma VLAN restrita que permite apenas o acesso ao aplicativo de escala de trabalho. Quando um funcionário se demite, sua conta do Microsoft Entra ID é desativada e o servidor RADIUS nega instantaneamente o acesso à rede. Cenário dois: uma cadeia de varejo nacional com 500 lojas implantando WiFi seguro para tablets de ponto de venda de propriedade corporativa. 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 de Raiz Confiável, 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 de 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 proporciona retornos mensuráveis em termos de segurança e operações. O WiFi baseado em senha gera um volume significativo de chamados no 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 a WiFi em 70%. Essa é uma redução material no custo operacional. O EAP-TLS elimina o risco de colheita de credenciais e ataques de Man-in-the-Middle. Isso é fundamental para a conformidade com o PCI-DSS em ambientes de varejo e com o GDPR em todos os setores. O custo de uma violação de dados supera em muito o custo de implantar uma infraestrutura de PKI adequada. E para organizações que já utilizam a plataforma de análise e WiFi de Visitantes da Purple, estender o onboarding seguro para os dispositivos BYOD da equipe fornece uma estratégia unificada de gerenciamento de rede. O overlay 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 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 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 o depósito de chaves é necessário. Qual deve ser a validade dos certificados? 90 dias para BYOD. Um a dois anos para dispositivos gerenciados corporativos. 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 estar vinculado ao indivíduo. Como lidar com a fragmentação do Android? Use 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 dispositivos 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. Chegamos ao fim do briefing de hoje. Se você quiser se aprofundar em algum 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.