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 entrar em detalhe sobre o SCEP - o Simple Certificate Enrollment Protocol - e como configurá-lo corretamente para BYOD seguro e autenticação de rede 802.1X. Se é um gestor de TI, um arquiteto de rede ou um 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 falar de teoria. Vamos falar de arquitetura e decisões. Vamos a isso. [SECÇÃO: Introdução e Contexto - aproximadamente 1 minuto] Eis 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 pré-partilhada WPA2 que doze pessoas conhecem, três das quais saíram da empresa no ano passado. Isso não é uma postura de segurança. É uma vulnerabilidade. A resposta é o 802.1X - a norma 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 é qual o método de autenticação que reside no seu interior. E para BYOD em escala, a resposta é EAP-TLS com certificados aprovisionados via SCEP. É isso que vamos analisar hoje. [SECÇÃO: Análise Técnica Detalhada - aproximadamente 5 minutos] Comecemos pelo que o SCEP realmente faz. O SCEP - Simple Certificate Enrollment Protocol - foi originalmente publicado como um Internet Draft pelo 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 em escala, sem exigir que um humano gere e instale manualmente cada um deles. Eis o fluxo de quatro passos. Passo 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. Passo 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. Passo três: o dispositivo gera localmente o seu próprio par de chaves privada e pública. Cria um Pedido de Assinatura de Certificado - um CSR - utilizando a chave pública e envia-o para o servidor SCEP. Eis 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 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 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 - 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 só. Encaminha a troca EAP para o seu servidor RADIUS. Este pode ser o Microsoft NPS, o Cisco ISE ou o Aruba ClearPass. O servidor RADIUS inicia um handshake EAP-TLS. O dispositivo apresenta o seu certificado de cliente aprovisionado 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 em relação a 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 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 falso (rogue), o dispositivo irá rejeitá-lo porque o certificado do servidor não será validado em relação à CA fidedigna. Esta é a sua proteção contra ataques 'evil twin'. Agora vamos falar sobre a sequência de implementação no Microsoft Intune, porque essa é a plataforma de MDM mais comum que vemos em ambientes empresariais. Implementa três perfis de configuração do Intune, numa ordem rigorosa. Primeiro, o perfil de Certificado de Raiz Fidedigna - este envia o certificado da sua 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 assunto, a utilização de chaves e a utilização de chaves 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 como WPA2-Enterprise ou WPA3-Enterprise, define o tipo de EAP como EAP-TLS e associa-o 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. Se os implementar fora de sequência, obterá erros. Uma decisão arquitetural 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 a abertura de portas de firewall de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registo. Para organizações que pretendem eliminar totalmente 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. [SECÇÃO: Recomendações de Implementação e Erros Comuns - aproximadamente 2 minutos] Deixe-me apresentar-lhe os três modos de falha mais comuns que vemos. Modo de falha um: incompatibilidade no direcionamento de grupos. Esta é a causa mais frequente de falhas na implementação de perfis de WiFi no Intune. Se o seu perfil de Raiz Fidedigna for atribuído a um grupo de Utilizadores, o seu perfil SCEP a um grupo de Dispositivos e o seu perfil de WiFi a um grupo de Utilizadores diferente, o Intune não conseguirá resolver a cadeia de dependências. Todos os três perfis devem visar exatamente o mesmo grupo do 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 de CRL - o URL do CDP incorporado no certificado - estiver inacessível, a autenticação falha para todos os dispositivos. Esta é uma causa comum de interrupções em massa após alterações na rede. Garanta que os seus CDPs são de alta disponibilidade, idealmente publicados tanto num URL interno como num URL externo 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 com maior impacto em implementações 802.1X. Se o seu perfil de WiFi implementado pelo MDM não especificar a CA fidedigna 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 de WiFi. [SECÇÃO: Perguntas e Respostas Rápidas - aproximadamente 1 minuto] Vamos a 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 alternativa, mas coloque esses dispositivos numa VLAN fortemente restrita, sem acesso aos recursos corporativos. Pergunta: Como é que a Purple se enquadra nisto? A plataforma de Guest WiFi da Purple lida com a camada de acesso de visitantes e convidados - o Captive Portal, a captura de dados, a análise. A sua infraestrutura 802.1X e SCEP lida com o acesso de funcionários e 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. [SECÇÃO: Resumo e Próximos Passos - aproximadamente 1 minuto] Para concluir. 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. Implemente via MDM numa sequência rigorosa: Raiz Fidedigna, depois perfil SCEP, depois perfil WiFi, todos direcionados para o mesmo grupo. Publique o NDES via 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 utiliza uma chave pré-partilhada para o WiFi dos funcionários, essa é a mudança a fazer este trimestre. A infraestrutura de certificados dá mais trabalho inicialmente, mas elimina toda uma classe de ataques baseados em credenciais e normalmente reduz os pedidos de suporte 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.ai. Obrigado por nos ouvir.