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

Olá, e bem-vindo a este briefing técnico da Purple. Sou o vosso anfitrião e hoje vamos detalhar o SCEP - Simple Certificate Enrollment Protocol - e como configurá-lo corretamente para uma autenticação de rede BYOD e 802.1X segura. Se é gestor de TI, arquiteto de rede ou CTO responsável pela infraestrutura de WiFi num grupo hoteleiro, numa rede de retalho, num estádio ou numa organização do setor público, isto é diretamente relevante para si. Hoje não vamos fazer teoria. Vamos fazer arquitetura e tomar decisões. Vamos a isso. [SECTION: Introduction and Context - approximately 1 minute] Este é o problema que provavelmente enfrenta. Tem dispositivos de funcionários, portáteis de prestadores de serviços e telemóveis pessoais, todos a precisar de acesso à rede. Provavelmente tem uma mistura de dispositivos geridos e não geridos. E algures na sua infraestrutura, ainda existe uma chave WPA2 partilhada que doze pessoas conhecem, três das quais saíram da 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 controlo de acesso à rede baseado em portas. Garante que nenhum dispositivo transmite tráfego até ser explicitamente autenticado. Mas o 802.1X é apenas a estrutura. A verdadeira questão é que método de autenticação está lá dentro. E para BYOD à escala, a resposta é EAP-TLS com certificados provisionados via SCEP. É isso que vamos analisar hoje. [SECTION: Technical Deep-Dive - approximately 5 minutes] Comecemos pelo 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. A sua função é simples: automatizar o processo de emissão de certificados digitais X.509 para dispositivos à escala, sem exigir que um humano gere e instale manualmente cada um deles. Aqui está o fluxo em quatro etapas. Etapa um: o dispositivo liga-se a um endpoint SCEP - um URL alojado localmente através de uma função do Windows Server chamada NDES, o Network Device Enrollment Service, ou através de um fornecedor de PKI na nuvem. Este URL é a porta de entrada para a sua Autoridade de Certificação. Etapa dois: o dispositivo apresenta um desafio SCEP - um segredo partilhado que prova que está autorizado a solicitar um certificado. Num ambiente gerido por MDM como o Microsoft Intune, este desafio é entregue de forma dinâmica e única por dispositivo, o que é muito mais seguro do que uma palavra-passe estática partilhada por todos os dispositivos. Etapa três: o dispositivo gera o seu próprio par de chaves privada e pública localmente. Cria um Pedido de Assinatura de Certificado - um CSR - utilizando a chave pública e envia-o para o servidor SCEP. Aqui está o ponto crítico de segurança: a chave privada nunca sai do dispositivo. É gerada localmente, armazenada no enclave seguro do dispositivo - que é o TPM em Windows ou o Secure Enclave em 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 tem de a enviar para o dispositivo. Passo quatro: a Autoridade de Certificação valida o CSR, assina-o com a chave privada da CA e devolve o certificado X.509 assinado ao dispositivo. O dispositivo tem agora uma identidade criptográfica única. Agora, como é que esse certificado é utilizado para a autenticação 802.1X? Quando o dispositivo se liga ao seu SSID de WiFi, o ponto de acesso - quer seja Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist ou Ubiquiti UniFi - atua como o autenticador. Não toma a decisão de autenticação por si próprio. 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 o seu certificado de cliente provisionado por SCEP. O servidor RADIUS valida três coisas: a cadeia de certificados até à CA raiz fidedigna, a data de expiração do certificado e se o certificado foi revogado - verificado através de uma Lista de Revogação de Certificados, ou CRL, ou via OCSP, o Online Certificate Status Protocol. Se 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. Isto é autenticação mútua. O dispositivo também valida o certificado do servidor RADIUS. Se alguém configurar um ponto de acesso desonesto, o dispositivo irá rejeitá-lo porque o certificado do servidor não será validado em relação à CA fidedigna. Essa é a sua proteção contra ataques de "evil twin". Agora vamos falar sobre a sequência de implementação no Microsoft Intune, porque essa é a plataforma MDM mais comum que vemos em ambientes empresariais. Implementa três perfis de configuração do Intune, numa ordem estrita. Primeiro, o perfil de Certificado de Raiz Fidedigna - este envia o seu certificado de CA raiz para todos os dispositivos para que estes confiem na sua PKI. Segundo, o perfil de Certificado SCEP - este indica aos dispositivos o URL do SCEP, o formato do nome do requerente, a utilização da chave e a utilização de chave expandida para autenticação de 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 para WPA2-Enterprise ou WPA3-Enterprise, define o tipo de EAP para EAP-TLS e liga 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 Fidedigna. Implemente-os fora de sequência e obterá erros. Uma decisão arquitetónica que precisa de tomar é onde alojar o servidor NDES. Este precisa de estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. A forma segura de o fazer é publicar o URL do NDES através do Microsoft Entra ID Application Proxy. Isto evita abrir portas de entrada na firewall e permite aplicar políticas de Acesso Condicional ao fluxo de registo. Para organizações que pretendem eliminar completamente a infraestrutura local, os fornecedores de PKI na nuvem - a própria 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 segmentação de grupo. Esta é a causa mais frequente de falhas na implementação de perfis WiFi no Intune. Se o seu perfil de Raiz Confiável for atribuído a um grupo de Utilizadores, o seu perfil SCEP a um grupo de Dispositivos e o seu perfil WiFi a um grupo de Utilizadores diferente, o Intune não conseguirá resolver a cadeia de dependências. Todos os três perfis devem segmentar exatamente o mesmo grupo Azure AD - ou todos os Utilizadores ou todos os Dispositivos. Escolha um e seja consistente. Modo de falha dois: disponibilidade da CRL. O seu servidor RADIUS verifica a CRL para confirmar que os certificados não foram revogados. Se o Ponto de Distribuição da CRL - o URL do CDP incorporado no certificado - estiver inacessível, a autenticação falha em todos os dispositivos. Esta é uma causa comum de interrupções em massa após alterações na rede. Garanta que os seus CDPs estão altamente disponíveis, idealmente publicados tanto para um URL interno como para um URL externo para dispositivos remotos. Considere o OCSP como uma alternativa mais resiliente à verificação da CRL. Modo de falha três: não impor a validação do certificado do servidor nos clientes. Esta é a configuração incorreta com maior impacto em implementações 802.1X. Se o seu perfil WiFi implementado por MDM não especificar a CA confiável e o nome do servidor RADIUS esperado, os dispositivos ligar-se-ão a qualquer servidor que apresente qualquer certificado. Isso anula todo o propósito do EAP-TLS. Configure sempre a validação do servidor no seu perfil WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Vamos fazer algumas perguntas rápidas. Pergunta: Precisamos de WPA3? Sim. Migre para WPA3-Enterprise. Este exige Protected Management Frames, o que bloqueia ataques de desautenticação. Todo o hardware da Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist suporta esta tecnologia. Pergunta: E quanto aos dispositivos que não suportam 802.1X - como sensores IoT ou impressoras antigas? Utilize o MAC Authentication Bypass como recurso alternativo, mas coloque esses dispositivos numa VLAN fortemente restrita, sem acesso aos recursos corporativos. Pergunta: Como é que a Purple se enquadra nisto? A plataforma Guest WiFi da Purple gere a camada de acesso de visitantes e convidados - o Captive Portal, a captura de dados e a análise. A sua infraestrutura 802.1X e SCEP gere o acesso do pessoal e dos dispositivos geridos. Funcionam em SSIDs separados e VLANs separadas. A Purple integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que o seu investimento em hardware esteja protegido. [SECTION: Summary and Next Steps - approximately 1 minute] Para concluir. O SCEP automatiza a emissão de certificados em grande escala. A chave privada permanece no dispositivo - essa é a vantagem de segurança em relação ao PKCS. Implemente através de MDM numa sequência estrita: Raiz Confiável, depois perfil SCEP, depois perfil WiFi, todos segmentando o mesmo grupo. Publique o NDES através de Application Proxy ou mude para PKI na nuvem. Imponha a verificação de CRL ou OCSP no seu servidor RADIUS. E configure sempre a validação do certificado do servidor nos suplicantes do cliente. Se ainda está a utilizar uma chave pré-partilhada partilhada para o WiFi dos colaboradores, essa é a alteração a fazer este trimestre. A infraestrutura de certificados dá mais trabalho inicial, mas elimina uma classe inteira de ataques baseados em credenciais e normalmente reduz os pedidos de suporte técnico relacionados com WiFi em 70 a 80 por cento após a implementação. Para obter o guia técnico completo, diagramas de arquitetura e exemplos práticos, visite purple dot ai. Obrigado por ouvir.