Como Configurar SCEP para BYOD Seguro e Autenticação de Rede 802.1X

Olá e boas-vindas a este briefing técnico da Purple. Sou o seu anfitrião e hoje vamos nos aprofundar nos detalhes do SCEP - o Simple Certificate Enrollment Protocol - e em como configurá-lo corretamente para autenticação de rede segura em BYOD e 802.1X. Se você é um gerente de TI, arquiteto de rede ou CTO responsável pela infraestrutura de WiFi em um grupo hoteleiro, rede de varejo, arena ou organização do setor público, isso é diretamente relevante para você. Não faremos teoria hoje. Focaremos em arquitetura e decisões. Vamos começar. [SECTION: Introduction and Context - approximately 1 minute] Aqui está o problema que você provavelmente está enfrentando. Você tem dispositivos de funcionários, notebooks de prestadores de serviço e telefones pessoais, todos precisando de acesso à rede. Provavelmente, você tem uma mistura de dispositivos gerenciados e não gerenciados. E em algum lugar da sua infraestrutura, ainda existe uma chave compartilhada WPA2 que doze pessoas conhecem, sendo que três delas deixaram a empresa no ano passado. Isso não é uma postura de segurança. Isso é uma vulnerabilidade. A resposta é o 802.1X - o padrão IEEE para controle de acesso à rede baseado em porta. Ele garante que nenhum dispositivo trafegue dados até que tenha sido explicitamente autenticado. Mas o 802.1X é apenas a estrutura. A verdadeira questão é qual método de autenticação está dentro dele. E para BYOD em escala, a resposta é EAP-TLS com certificados provisionados via SCEP. É isso que vamos detalhar hoje. [SECTION: Technical Deep-Dive - approximately 5 minutes] Vamos começar com o que o SCEP realmente faz. O SCEP - Simple Certificate Enrollment Protocol - foi originalmente publicado como um Internet Draft pela IETF em 1999, criado pela VeriSign. Foi formalizado como RFC 8894. O seu papel é simples: automatizar o processo de emissão de certificados digitais X.509 para dispositivos em escala, sem exigir que um humano gere e instale manualmente cada um deles. Aqui está o fluxo de quatro etapas. Etapa um: o dispositivo se conecta a um endpoint SCEP - uma URL hospedada localmente por meio de uma função do Windows Server chamada NDES (Network Device Enrollment Service) ou por meio de um provedor de PKI em nuvem. Essa URL é a porta de entrada para a sua Autoridade Certificadora. Etapa dois: o dispositivo apresenta um desafio SCEP - um segredo compartilhado que prova que ele está autorizado a solicitar um certificado. Em um ambiente gerenciado por MDM, como o Microsoft Intune, esse desafio é entregue de forma dinâmica e exclusiva por dispositivo, o que é muito mais seguro do que uma senha estática compartilhada entre todos os dispositivos. Etapa três: o dispositivo gera localmente seu próprio par de chaves pública e privada. Ele cria uma Solicitação de Assinatura de Certificado - um CSR - usando a chave pública e a envia para o servidor SCEP. Aqui está o ponto crítico de segurança: a chave privada nunca sai do dispositivo. Ela é gerada localmente, armazenada no enclave seguro do dispositivo - que é o TPM no Windows ou o Secure Enclave no iOS - e nunca é transmitida. É por isso que o SCEP é a escolha certa para autenticação de rede, e não o PKCS, onde a CA gera a chave centralmente e precisa enviá-la para o dispositivo. Passo quatro: a Autoridade Certificadora valida o CSR, assina-o com a chave privada da CA e retorna o certificado X.509 assinado para o dispositivo. O dispositivo agora possui uma identidade criptográfica exclusiva. Agora, como esse certificado é usado para a autenticação 802.1X? Quando o dispositivo se conecta ao seu SSID de WiFi, o ponto de acesso - seja Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist ou Ubiquiti UniFi - atua como o autenticador. Ele não toma a decisão de autenticação por si só. Ele encaminha a troca EAP para o seu servidor RADIUS. Esse pode ser o Microsoft NPS, Cisco ISE ou Aruba ClearPass. O servidor RADIUS inicia um handshake EAP-TLS. O dispositivo apresenta seu certificado de cliente provisionado por SCEP. O servidor RADIUS valida três coisas: a cadeia de certificados de volta à CA raiz confiável, a data de expiração do certificado e se o certificado foi revogado - verificado em uma Lista de Revogação de Certificados, ou CRL, ou via OCSP, o Online Certificate Status Protocol. Se todas as três verificações passarem, o servidor RADIUS envia uma mensagem de EAP-Success e o ponto de acesso abre a porta. O dispositivo está na rede. Isso é autenticação mútua. O dispositivo também valida o certificado do servidor RADIUS. Se alguém configurar um ponto de acesso invasor, o dispositivo o rejeitará porque o certificado do servidor não será validado em relação à CA confiável. Essa é a sua proteção contra ataques de evil twin. Agora vamos falar sobre a sequência de implantação no Microsoft Intune, porque essa é a plataforma de MDM mais comum que vemos em ambientes corporativos. Você implanta três perfis de configuração do Intune, em ordem estrita. Primeiro, o perfil de Certificado Raiz Confiável - isso envia o certificado da sua CA raiz para todos os dispositivos para que eles confiem na sua PKI. Segundo, o perfil de Certificado SCEP - isso informa aos dispositivos a URL do SCEP, o formato do nome do assunto, o uso da chave e o uso estendido da chave para autenticação do cliente. O OID para autenticação de cliente é 1.3.6.1.5.5.7.3.2. Terceiro, o perfil de WiFi - este especifica o SSID, define o tipo de segurança como WPA2-Enterprise ou WPA3-Enterprise, define o tipo de EAP como EAP-TLS e vincula ao perfil de certificado SCEP. A ordem importa. O perfil de WiFi tem uma dependência do perfil SCEP, que por sua vez tem uma dependência do perfil de Raiz Confiável. Implante-os fora de sequência e você obterá erros. Uma decisão de arquitetura que você precisa tomar é onde hospedar o servidor NDES. Ele precisa estar acessível a partir da internet para que os dispositivos possam se registrar antes de chegarem ao local. A maneira segura de fazer isso é publicar a URL do NDES por meio do Proxy de Aplicativo do Microsoft Entra ID. Isso evita a abertura de portas de firewall de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro. Para organizações que desejam eliminar completamente a infraestrutura local, os provedores de PKI em nuvem - a própria Cloud PKI da Microsoft no Intune ou opções de terceiros - removem completamente a dependência do NDES. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Deixe-me apresentar os três modos de falha mais comuns que observamos. Modo de falha um: incompatibilidade de direcionamento de grupo. Esta é a causa mais frequente de falhas na implantação de perfis de WiFi no Intune. Se o seu perfil de Trusted Root for atribuído a um grupo de Usuários, seu perfil SCEP a um grupo de Dispositivos e seu perfil de WiFi a um grupo de Usuários diferente, o Intune não conseguirá resolver a cadeia de dependência. Todos os três perfis devem ter como alvo exatamente o mesmo grupo do Azure AD - ou todos os Usuários ou todos os Dispositivos. Escolha um e seja consistente. Modo de falha dois: disponibilidade da CRL. Seu servidor RADIUS verifica a CRL para confirmar que os certificados não foram revogados. Se o Ponto de Distribuição da CRL - a URL do CDP incorporada no certificado - estiver inacessível, a autenticação falhará para todos os dispositivos. Esta é uma causa comum de interrupções em massa após alterações na rede. Certifique-se de que seus CDPs estejam altamente disponíveis, idealmente publicados tanto em uma URL interna quanto em uma URL externa para dispositivos remotos. Considere o OCSP como uma alternativa mais resiliente à verificação de CRL. Modo de falha três: não impor a validação do certificado do servidor nos clientes. Esta é a configuração incorreta de maior impacto em implantações 802.1X. Se o seu perfil de WiFi implantado por MDM não especificar a CA confiável e o nome esperado do servidor RADIUS, os dispositivos se conectarão a qualquer servidor que apresente qualquer certificado. Isso anula todo o propósito do EAP-TLS. Sempre configure a validação de servidor em seu perfil de WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Vamos para algumas perguntas rápidas. Pergunta: Precisamos de WPA3? Sim. Migre para o WPA3-Enterprise. Ele exige Protected Management Frames, o que bloqueia ataques de desautenticação. Todo o hardware da Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist oferece suporte a isso. Pergunta: E quanto aos dispositivos que não suportam 802.1X - como sensores IoT ou impressoras legadas? Use o MAC Authentication Bypass como alternativa, mas coloque esses dispositivos em uma VLAN altamente restrita, sem acesso aos recursos corporativos. Pergunta: Como a Purple se encaixa nisso? A plataforma de Guest WiFi da Purple gerencia a camada de acesso de visitantes e convidados - o Captive Portal, a captura de dados, os analytics. Sua infraestrutura 802.1X e SCEP gerencia o acesso de funcionários e dispositivos gerenciados. Eles funcionam em SSIDs separados e VLANs separadas. A Purple se integra com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que seu investimento em hardware seja protegido. [SECTION: Summary and Next Steps - approximately 1 minute] Para resumir. O SCEP automatiza a emissão de certificados em escala. A chave privada permanece no dispositivo - essa é a vantagem de segurança em relação ao PKCS. Implante via MDM em sequência estrita: Trusted Root, depois o perfil SCEP e, em seguida, o perfil de WiFi, todos direcionados ao mesmo grupo. Publique o NDES via Application Proxy ou mude para PKI em nuvem. Imponha a verificação de CRL ou OCSP em seu servidor RADIUS. E sempre configure a validação de certificado de servidor nos suplicantes dos clientes. Se você ainda está usando uma chave pré-compartilhada para o WiFi da equipe, essa é a mudança a ser feita neste trimestre. A infraestrutura de certificados exige mais trabalho inicial, mas elimina toda uma classe de ataques baseados em credenciais e normalmente reduz os chamados de suporte relacionados a WiFi de 70 a 80 por cento após a implantação. Para obter o guia técnico completo, diagramas de arquitetura e exemplos práticos, visite purple dot ai. Obrigado por ouvir.