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 entraremos nos detalhes do SCEP - o Simple Certificate Enrollment Protocol - e em como configurá-lo corretamente para BYOD seguro e autenticação de rede 802.1X. Se você é um gerente de TI, um arquiteto de rede ou um CTO responsável pela infraestrutura de WiFi em um grupo hoteleiro, uma rede de varejo, um estádio ou uma organização do setor público, isso é de seu interesse direto. Não faremos teoria hoje. Faremos arquitetura e decisões. Vamos começar. [SECTION: Introduction and Context - approximately 1 minute] Aqui está o problema que você provavelmente enfrenta. Você tem dispositivos de funcionários, notebooks de prestadores de serviço e telefones pessoais, todos precisando de acesso à rede. Você provavelmente tem uma mistura de dispositivos gerenciados e não gerenciados. E em algum lugar da sua infraestrutura, ainda há uma chave compartilhada WPA2 que doze pessoas conhecem, das quais três saíram da empresa no ano passado. Isso não é uma postura de segurança. Isso é um risco. A resposta é o 802.1X - o padrão IEEE para controle de acesso à rede baseado em porta. Ele garante que nenhum dispositivo transmita tráfego até que tenha sido explicitamente autenticado. Mas o 802.1X é apenas o framework. A verdadeira questão é qual método de autenticação está dentro dele. E para BYOD em escala, a resposta é o 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. Ele 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 ser humano gere e instale cada um manualmente. Aqui está o fluxo em quatro etapas. Etapa um: o dispositivo se conecta a um endpoint SCEP - uma URL hospedada localmente via uma função do Windows Server chamada NDES, o 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 comprova 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 única 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 o seu próprio par de chaves pública e privada. Ele cria uma Solicitação de Assinatura de Certificado - uma 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 AC gera a chave centralmente e precisa enviá-la para o dispositivo. Etapa 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 única. 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 servidor 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 até a 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 irá rejeitá-lo 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, pois essa é a plataforma 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 ser 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 via Microsoft Entra ID Application Proxy. 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, provedores de PKI em nuvem - o próprio Cloud PKI da Microsoft no Intune, ou opções de terceiros - removem completamente a dependência do NDES. [SECTION: Recomendações de Implementação e Armadilhas - aproximadamente 2 minutos] 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 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 garantir 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 mudanças de rede. Certifique-se de que seus CDPs estejam altamente disponíveis, idealmente publicados em uma URL interna e 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 mais impactante 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 do servidor em seu perfil de WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Vamos fazer algumas perguntas rápidas. Pergunta: Precisamos de WPA3? Sim. Migre para o WPA3-Enterprise. Ele exige Quadros de Gerenciamento Protegidos, o que bloqueia ataques de desautenticação. Todo o hardware da Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist oferece suporte. Pergunta: E os dispositivos que não oferecem suporte ao 802.1X - como sensores IoT ou impressoras legadas? Use o MAC Authentication Bypass como contingência, mas coloque esses dispositivos em uma VLAN altamente restrita, sem acesso aos recursos corporativos. Pergunta: Como o Purple se encaixa nisso? A plataforma de Guest WiFi do Purple lida com a camada de acesso de visitantes e convidados - o Captive Portal, a captura de dados, a análise de dados. Sua infraestrutura 802.1X e SCEP lida com o acesso de funcionários e dispositivos gerenciados. Eles funcionam em SSIDs separados e VLANs separadas. O Purple se integra com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - assim o investimento no seu hardware está 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, depois 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 no seu servidor RADIUS. E sempre configure a validação do certificado do servidor nos suplicantes dos clientes. Se você ainda está executando uma chave pré-compartilhada compartilhada para o WiFi de funcionários, essa é a mudança a ser feita neste trimestre. A infraestrutura de certificados dá mais trabalho no início, 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 o guia técnico completo, diagramas de arquitetura e exemplos práticos, visite purple dot ai. Obrigado por ouvir.