Como Configurar o SCEP para Registro Automatizado de Certificados de WiFi Corporativo

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para o registro automatizado de certificados de WiFi corporativo, cobrindo toda a arquitetura, desde PKI e NDES até a implantação de perfis MDM e validação RADIUS. Destina-se a gerentes de TI, arquitetos de rede e CTOs de hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar a autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem da Purple, independente de hardware, integra-se diretamente a essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que opera em conjunto com a rede de funcionários autenticada por certificado.

📖 10 min de leitura📝 2,720 palavras🔧 2 exemplos práticos❓ 3 questões práticas📚 9 definições principais

Ouça este guia

Ver transcrição do podcast

Bem-vindo à série de Briefings Técnicos da Purple. Hoje vou falar sobre algo que chega a muitas caixas de entrada de TI, mas que raramente recebe uma resposta direta: como realmente implantar a autenticação WiFi baseada em certificados em escala, usando SCEP, em uma grande rede. Seja em um campus universitário, em um grupo hoteleiro com várias unidades ou em um grande patrimônio do setor público, os desafios são idênticos.

Vamos cobrir o cenário completo. O que o SCEP realmente faz, como ele se encaixa em uma arquitetura 802.1X, a sequência de implantação que a maioria das equipes erra, dois cenários de implementação do mundo real e as armadilhas que custarão um fim de semana da sua vida se você não se planejar para elas.

Este é um briefing de consultoria, não um tutorial. Estou assumindo que você sabe o que é um servidor RADIUS e que provavelmente já decidiu que precisa deixar de usar chaves pré-compartilhadas. O que você precisa agora é do mapa de implementação.

Vamos ao que interessa.

Primeiros princípios. SCEP significa Simple Certificate Enrollment Protocol. Foi formalizado pelo IETF como RFC 8894 em 2020, embora já estivesse em amplo uso empresarial por mais de uma década antes disso. O seu trabalho é simples: automatizar o processo de obtenção de um certificado digital em um dispositivo gerenciado sem a necessidade de intervenção humana em cada máquina.

No contexto da autenticação WiFi, o SCEP é o mecanismo de entrega. O protocolo de autenticação real que você está buscando é o EAP-TLS, Extensible Authentication Protocol com Transport Layer Security, que fica dentro do framework 802.1X. O EAP-TLS é amplamente considerado o método de autenticação mais seguro para redes sem fio corporativas porque exige que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados válidos. Nenhum dos lados confia no outro sem prova criptográfica. Essa autenticação mútua é o que protege você contra ataques de "evil twin", onde um invasor cria um ponto de acesso não autorizado para coletar credenciais.

Aqui está como funciona a cadeia completa. Um dispositivo gerenciado, o notebook de um estudante, o telefone de um funcionário, um terminal de ponto de venda de um hotel, precisa se conectar à rede sem fio corporativa. Sua plataforma MDM, que pode ser o Microsoft Intune ou o Jamf, envia um payload SCEP para esse dispositivo. O payload contém duas coisas: a URL do SCEP, que aponta para o seu servidor NDES ou gateway SCEP na nuvem, e uma senha de desafio ou segredo compartilhado.

O dispositivo gera seu próprio par de chaves pública e privada localmente. Isso é fundamental. A chave privada nunca sai do dispositivo. Ela é gerada no dispositivo, armazenada no enclave seguro ou TPM, e nunca é transmitida pela rede. O dispositivo então cria uma Solicitação de Assinatura de Certificado, um CSR, e a envia para o gateway SCEP. O gateway valida o desafio, encaminha o CSR para a sua Autoridade Certificadora, e a CA o assina e retorna o certificado público para o dispositivo.

A partir desse momento, quando o dispositivo se conecta ao seu SSID de WiFi, ele apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem de aceitação para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário.

Agora, vamos falar sobre onde o SCEP se posiciona em relação à alternativa, que é o PKCS. O PKCS, Public Key Cryptography Standards, é o outro método de entrega de certificado suportado por plataformas como o Intune. Com o PKCS, a CA gera tanto a chave pública quanto a privada de forma centralizada, e o conector de certificado envia o par de chaves para o dispositivo. Isso significa que a chave privada trafega pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de uso como criptografia de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para autenticação WiFi, o SCEP é a escolha certa. A chave privada permanece no dispositivo, ponto final.

Agora, a camada de hardware. SCEP e EAP-TLS são padrões neutros de fornecedor, o que significa que funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração do RADIUS, seja ela Windows NPS, FreeRADIUS ou um serviço de RADIUS em nuvem, é onde você define a política de validação de certificado e, fundamentalmente, onde você configura a atribuição dinâmica de VLAN.

As VLANs dinâmicas são a forma como você segmenta a rede por identidade. O dispositivo de um aluno recebe a VLAN 20 apenas para acesso à internet. O dispositivo de um professor recebe a VLAN 10 para acesso aos sistemas de pesquisa internos. Um dispositivo de gestão de instalações recebe a VLAN 30 para acesso aos sistemas de gestão predial. Tudo isso é direcionado pelos atributos do certificado e pela política do RADIUS, sem nenhuma intervenção manual por dispositivo.

Para a integração com provedores de identidade, os atributos do certificado SCEP, especificamente o Subject Alternative Name, podem carregar o nome principal do usuário a partir do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que quando você desativa uma conta no Entra ID e o MDM cancela o registro do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa é a história de revogação que as chaves pré-compartilhadas simplesmente não conseguem contar.

Certo, vamos falar sobre a sequência de implantação, porque é aqui que a maioria das equipes comete erros.

A sequência não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil de WiFi. O Intune e o Jamf impõem dependências de perfil. Se o seu perfil de WiFi fizer referência a um certificado SCEP que ainda não foi implantado no dispositivo, o perfil de WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas na verdade é apenas um problema de tempo.O segundo erro comum é o direcionamento de grupos. Todos os três perfis, Trusted Root, SCEP e WiFi, devem ser implantados exatamente no mesmo grupo do Azure AD ou Jamf. Se o perfil SCEP for direcionado a um grupo de usuários e o perfil WiFi for direcionado a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será exibido como Não Aplicável. Isso costuma pegar as equipes de surpresa constantemente.

Terceiro: acessibilidade do servidor NDES. Seu servidor NDES precisa estar acessível pela internet para que os dispositivos possam se registrar antes de chegarem ao local. A maneira correta de fazer isso é por meio do Azure AD Application Proxy, e não abrindo uma porta no seu firewall. O App Proxy oferece acesso remoto seguro sem portas de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro.

Quarto: disponibilidade de CRL. Seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) toda vez que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL estiver indisponível, seja porque um servidor está fora do ar ou porque a URL mudou, a autenticação falhará para todos os dispositivos na rede simultaneamente. Isso representa uma interrupção em todo o campus. Torne seus endpoints de CRL altamente disponíveis e teste a revogação antes de entrar em operação.

Para redes grandes, com mais de 500 dispositivos, considere um gateway SCEP em nuvem em vez de um NDES local. Os gateways em nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e geralmente se integram diretamente com serviços RADIUS em nuvem, removendo mais uma dependência de infraestrutura.

Vamos responder a algumas perguntas rápidas que costumamos ouvir de CTOs.

O SCEP pode lidar com dispositivos BYOD que não estão registrados no MDM? Não diretamente. O SCEP exige o registro no MDM para enviar a carga do certificado. Para BYOD não gerenciado, você precisa de uma abordagem diferente: um portal de integração de autoatendimento ou um SSID separado usando um Captive Portal com verificação de identidade. A Purple lida com essa camada de convidados e BYOD de forma limpa, operando ao lado da sua rede de funcionários autenticada por certificado.

E quanto ao iOS e Android? Ambas as plataformas oferecem suporte nativo ao SCEP. O iOS suporta o SCEP desde o iOS 4. O Android Enterprise suporta o SCEP por meio do Intune e de outros MDMs. A configuração é um pouco diferente para cada plataforma, mas o protocolo subjacente é idêntico.

O EAP-TLS funciona com WPA3? Sim. O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes confidenciais, e o EAP-TLS é totalmente compatível. Na verdade, o WPA3-Enterprise com EAP-TLS é a combinação recomendada pela Wi-Fi Alliance para redes governamentais e financeiras.

Para resumir tudo. A autenticação WiFi por certificado SCEP é a arquitetura correta para qualquer rede com mais de 50 dispositivos gerenciados. Ela elimina credenciais compartilhadas, oferece identidade por dispositivo, permite segmentação dinâmica de VLAN e se integra diretamente com seu provedor de identidade para revogação automatizada. A sequência de implantação — Trusted Root, depois perfil SCEP e, em seguida, perfil WiFi — é fixa. O direcionamento de grupos deve ser consistente. A disponibilidade de CRL não é opcional.

Para o ensino superior especificamente, a combinação de SCEP para dispositivos de funcionários e professores, juntamente com uma camada separada de WiFi para convidados para estudantes em dispositivos pessoais, oferece segurança e uma excelente experiência de usuário sem concessões.

Se você quiser se aprofundar, o guia da Purple sobre autenticação de WiFi corporativo aborda o caminho nativo em nuvem. E se você está pensando no que acontece quando um funcionário sai, nosso guia sobre revogação de acesso ao WiFi orienta você por todo o fluxo de trabalho de revogação.

Obrigado por ouvir. Eu sou da equipe técnica da Purple, e nos vemos no próximo briefing.

Principais conclusões

✓O SCEP (RFC 8894) automatiza o registro de certificados para dispositivos gerenciados - a chave privada é gerada no próprio dispositivo e nunca é transmitida, tornando-o a escolha correta para autenticação WiFi em relação ao PKCS.
✓A sequência de implantação não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil de WiFi. Violar essa ordem causa falhas de dependência de perfil.
✓Todos os três perfis de MDM (Trusted Root, SCEP, WiFi) devem ter como alvo exatamente o mesmo grupo de diretório. O direcionamento cruzado entre grupos é a causa mais comum de falhas de implantação.
✓O NDES deve ser publicado via Azure AD Application Proxy, não exposto diretamente à internet. Para redes com mais de 500 dispositivos, um gateway SCEP em nuvem elimina o ponto único de falha do NDES.
✓A disponibilidade do Ponto de Distribuição CRL é uma dependência crítica da rede. Se o servidor RADIUS não conseguir alcançar a CRL, ele falha no modo fechado e nega todas as autenticações simultaneamente.
✓O EAP-TLS com certificados provisionados por SCEP atende ao Requisito 8.6 do PCI DSS 4.0 para redes sem fio em ambientes de dados de portadores de cartão e é obrigatório para WPA3-Enterprise de 192 bits (Suite B).
✓O SCEP cobre apenas dispositivos gerenciados. Dispositivos BYOD não gerenciados e de convidados exigem um SSID separado com Captive Portal e verificação de identidade - a plataforma da Purple gerencia essa camada juntamente com a rede de funcionários autenticada por certificado.

📚 Parte da nossa série principal: Enterprise WiFi Security Guide →

Resumo executivo

Para espaços empresariais - quer se trate de um hotel de 200 quartos, de uma cadeia de retalho com 50 localizações ou de um grande centro de conferências - depender de chaves pré-partilhadas para o WiFi dos funcionários é um risco de segurança e um estrangulamento operacional. Uma única palavra-passe divulgada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova a sua identidade de forma criptográfica antes de o ponto de acesso lhe conceder acesso à rede.

O desafio reside na distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve este problema. Automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos geridos através da sua plataforma MDM - sem qualquer interação do utilizador.

Este guia abrange toda a arquitetura: o que o SCEP faz, como se integra com o Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implementação que a maioria das equipas erra e as armadilhas operacionais que causam interrupções de serviço. Também abordamos dois cenários reais de implementação em hotelaria e retalho, e explicamos onde a plataforma de Guest WiFi da Purple se enquadra ao lado da sua rede de funcionários autenticada por certificado.

Ouça o podcast informativo complementar:

Análise técnica detalhada: SCEP, PKI e 802.1X

O que o SCEP realmente faz

O SCEP não substitui a sua Public Key Infrastructure (PKI). É a camada de registo automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.

No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.

Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access .

O fluxo de registo SCEP, passo a passo

A cadeia de registo completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.

O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.

A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.

SCEP vs. PKCS: qual utilizar para WiFi

As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.

Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade	SCEP	PKCS
Geração de chave privada	No dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmissão de chave privada	Nunca	Através da rede
Servidor NDES necessário	Sim (ou gateway na nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.

Guia de implementação: a sequência de implementação

A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.

A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.

Passo 1: implementar o perfil de Certificado de Raiz de Confiança (Trusted Root)

Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermédia - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.

Se tiver uma hierarquia PKI de dois níveis (recomendado), precisa de implementar tanto o certificado da CA raiz como o da CA emissora como perfis de Certificado de Confiança separados, ou como uma cadeia num único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o seu certificado de cliente.

Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Nome do Requerente (Subject name). Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos partilhados, IoT, terminais POS), utilize CN={{AAD_Device_ID}}. Defina a Utilização da chave (Key usage) para Assinatura digital e Cifragem de chave. Defina a Utilização de Chave Alargada (Extended Key Usage) para Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado de Raiz de Confiança criado no Passo 1. Forneça o URL externo do seu servidor NDES.Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado através do Azure AD Application Proxy para permitir que os dispositivos remotos se registem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implementar o perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP para EAP-TLS. Nas definições de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado Trusted Root para validação do servidor - isto garante que o dispositivo apenas se liga ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.

Integração do fornecedor de identidade

Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM remove o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-partilhadas não conseguem igualar.

Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access , incluindo caminhos de migração PEAP-MSCHAPv2, consulte o nosso guia dedicado.

Boas práticas e padrões da indústria

Posicionamento do servidor NDES

O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de firewall de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Nunca exponha o NDES diretamente à internet.

Para redes com mais de 500 dispositivos geridos, considere um gateway SCEP na nuvem em vez de um NDES local. Os gateways na nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na nuvem.

Disponibilidade da CRL

O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está em baixo ou o URL mudou - a autenticação falha para todos os dispositivos na rede em simultâneo. Configure o seu servidor NPS ou RADIUS para impor uma verificação rigorosa da CRL e torne os seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.

O Requisito 8.6 do PCI DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retail e Hospitality .

Compatibilidade com WPA3

O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suite de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se está a implementar em ambientes de Saúde ou Transportes com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura-alvo correta.

BYOD e WiFi de convidados

O SCEP requer a inscrição no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não geridos ou convidados. Para esses casos de utilização, necessita de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.

Resolução de problemas e mitigação de riscos

Falha na aplicação do perfil de WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro ou Não Aplicável no MDM.

Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP se destinar a um grupo de Utilizadores e o perfil de WiFi se destinar a um grupo de Dispositivos, o MDM não consegue resolver a dependência.

Solução: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi se destinam todos exatamente ao mesmo grupo de diretório.

Erros NDES 403 Forbidden

Sintoma: Os dispositivos não conseguem obter o certificado SCEP. Os registos do IIS do NDES mostram erros HTTP 403.

Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, ou a filtragem de URLs da firewall está a bloquear os parâmetros de query string do SCEP.

Solução: Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão bloqueados.

Falha de autenticação em massa após expiração da CRL

Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo.

Causa raiz: A CRL expirou ou o URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha por omissão (fails closed).

Solução: Configure a monitorização e alertas de CRL. Publique as CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento.

Expiração de certificado a causar falhas silenciosas

Sintoma: Dispositivos individuais falham a ligação de forma intermitente, sem um padrão claro.

Causa raiz: Os certificados de cliente expiraram e o MDM não os renovou com sucesso.

Solução: Configure a renovação do certificado para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de estado de inscrição do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos.

ROI e impacto empresarial

A transição para a autenticação por certificado 802.1X baseada em SCEP proporciona retornos mensuráveis em termos de segurança, operações e conformidade.

Redução de pedidos de suporte: O WiFi baseado em palavra-passe gera um volume significativo de pedidos de suporte - expiração de palavras-passe, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o utilizador. As organizações registam tipicamente uma redução de 70-80% no volume de suporte relacionado com WiFi após a migração.

Postura de segurança: O EAP-TLS elimina a recolha de credenciais e os ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI DSS 4.0 para redes de retalho e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.

Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipa de rede.

Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.

Para saber mais sobre como a análise comportamental ( Behavioral Analytics: Insights for WiFi Networks ) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.

Referências

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definições principais

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo formalizado na RFC 8894 que permite que dispositivos gerenciados solicitem e recebam automaticamente certificados digitais X.509 de uma Autoridade Certificadora via HTTP, usando uma senha de desafio compartilhada para a autenticação inicial. A chave privada é gerada no dispositivo e nunca é transmitida.

O mecanismo padrão usado por plataformas de MDM como Microsoft Intune e Jamf para implantar certificados de autenticação WiFi em endpoints gerenciados em escala.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

O método de autenticação 802.1X mais seguro, exigindo que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados X.509 válidos. A autenticação mútua significa que nenhuma das partes confia na outra sem prova criptográfica.

O protocolo de autenticação de destino para WiFi corporativo. Exigido ou fortemente recomendado pelo PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) e HIPAA para redes sem fio que lidam com dados confidenciais.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma Autoridade de Registro (RA) entre dispositivos habilitados para SCEP e uma Autoridade Certificadora. Ele valida senhas de desafio e encaminha CSRs para a CA em nome de dispositivos que não possuem credenciais de domínio.

Infraestrutura necessária para a implantação do SCEP com o Microsoft Intune. Deve ser publicado via Azure AD Application Proxy em vez de ser exposto diretamente à internet.

PKI (Public Key Infrastructure)

A hierarquia de Autoridades Certificadoras, políticas e procedimentos usados para emitir, gerenciar e revogar certificados digitais. Uma PKI de duas camadas consiste em uma CA raiz offline (a âncora de confiança mestre) e uma CA emissora online (que lida com a emissão diária de certificados).

O pré-requisito inegociável para a implantação de EAP-TLS e SCEP. A CA raiz deve ser mantida isolada (air-gapped); sua chave privada é a base de toda a sua cadeia de confiança de certificados.

CSR (Certificate Signing Request)

Uma mensagem gerada por um dispositivo contendo sua chave pública e informações de identidade, enviada a uma Autoridade Certificadora para solicitar um certificado digital assinado. No SCEP, o CSR é gerado no dispositivo e encapsulado em um envelope PKCS antes da transmissão.

Gerado automaticamente pelo dispositivo durante o fluxo de registro do SCEP. A chave privada usada para assinar o CSR nunca sai do dispositivo.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade Certificadora contendo os números de série dos certificados que foram revogados antes da data de expiração. Os servidores RADIUS verificam a CRL a cada tentativa de autenticação para garantir que certificados revogados não acessem a rede.

A disponibilidade do Ponto de Distribuição CRL (CDP) é crítica. Se o servidor RADIUS não conseguir acessar a CRL, ele falha no modo fechado e nega todas as autenticações - causando uma interrupção em toda a rede.

RADIUS (Remote Authentication Dial-In User Service)

Um protocolo de rede que fornece Autenticação, Autorização e Contabilização (AAA) centralizada para acesso à rede. No WiFi 802.1X, o servidor RADIUS valida os certificados dos clientes, verifica a CRL e retorna uma mensagem de Access-Accept ou Access-Reject para o ponto de acesso.

O servidor de autenticação no modelo suplicante-autenticador-servidor 802.1X. Implementações comuns incluem Windows NPS, FreeRADIUS e serviços de RADIUS na nuvem.

Dynamic VLAN assignment

Um recurso do RADIUS que coloca um dispositivo autenticado em uma VLAN específica com base nos atributos do certificado ou na associação a grupos de diretório, em vez de depender da seleção de SSID ou filtragem de endereço MAC. Aplica a segmentação de rede por identidade de dispositivo.

Permite que um único SSID atenda a múltiplos tipos de dispositivos com diferentes níveis de acesso à rede. Um dispositivo de funcionário recebe a VLAN 10 (acesso interno); o dispositivo de um prestador de serviços recebe a VLAN 20 (apenas internet); um terminal de PDV recebe a VLAN 30 (apenas sistemas de pagamento).

MDM (Mobile Device Management)

Software usado por equipes de TI para registrar, configurar, proteger e gerenciar smartphones, tablets e laptops. Plataformas de MDM como Microsoft Intune e Jamf usam perfis SCEP para enviar instruções de registro de certificados para dispositivos gerenciados sem a necessidade de interação do usuário.

O pré-requisito para a implantação de certificados baseada em SCEP. Os dispositivos devem estar registrados no MDM antes de poderem receber perfis de SCEP e WiFi. Dispositivos BYOD não gerenciados exigem uma abordagem de integração separada.

Exemplos práticos

Uma propriedade Premier Inn de 200 quartos precisa proteger o WiFi de sua equipe para tablets de ponto de venda e smartphones do serviço de quarto. Atualmente, eles usam uma chave pré-compartilhada que foi vazada para prestadores de serviços. Eles gerenciam os dispositivos via Microsoft Intune e possuem uma mistura de dispositivos iOS e Android. A propriedade utiliza pontos de acesso HPE Aruba.

Implante uma PKI interna de duas camadas do Microsoft AD CS. Configure o NDES em um Windows Server dedicado e publique-o via Azure AD Application Proxy.
No Intune, crie um perfil de Certificado Raiz Confiável contendo os certificados da CA Raiz e da CA Emissora. Implante para um grupo do Azure AD 'Property Staff Devices'.
Crie um perfil de Certificado SCEP no Intune apontando para a URL externa do NDES. Defina o formato do Nome do Assunto como CN={{AAD_Device_ID}}, pois estes são dispositivos compartilhados. Defina o Uso da Chave como Assinatura Digital e Criptografia de Chave, e o Uso Estendido da Chave como Autenticação de Cliente. Implante para 'Property Staff Devices'.
Crie um perfil de Wi-Fi para o SSID da equipe, configurando WPA2-Enterprise e EAP-TLS. Selecione o perfil SCEP para autenticação de cliente e a CA Raiz para validação de servidor. Implante para 'Property Staff Devices'.
Configure as definições de RADIUS do HPE Aruba para apontar para o Windows NPS. No NPS, configure uma Política de Rede que exija EAP-TLS e atribua a VLAN 10 para os dispositivos da equipe.
Assim que os dispositivos receberem os perfis e se conectarem com sucesso, rotacione a PSK no SSID antigo e agende sua desativação.

Comentário do examinador: Esta abordagem identifica corretamente que dispositivos compartilhados (PDV, serviço de quarto) exigem autenticação baseada em dispositivo (CN={{AAD_Device_ID}}) em vez de autenticação baseada em usuário, já que vários membros da equipe usam o mesmo dispositivo. Ela segue a sequência obrigatória de implantação de perfil e garante que todos os três perfis tenham como alvo o mesmo grupo do Azure AD. Publicar o NDES via App Proxy em vez de exposição direta à internet é a postura de segurança correta para um ambiente de hotelaria.

Uma rede de varejo com 50 lojas deseja implantar o 802.1X para laptops corporativos em todas as unidades. Eles usam pontos de acesso Cisco Meraki e o Microsoft Intune. Eles não querem implantar e manter servidores NDES locais ou infraestrutura AD CS em cada localidade ou em seu data center.

Implemente um serviço de gateway SCEP e PKI baseado em nuvem que se integre ao Intune via protocolo SCEP. A CA em nuvem emite os certificados; o gateway SCEP em nuvem lida com a validação de CSR.
Configure o serviço RADIUS em nuvem (fornecido pelo fornecedor de PKI) no painel do Cisco Meraki em Wireless > Access Control para o SSID corporativo. Defina a segurança como WPA2-Enterprise e aponte o RADIUS para o serviço em nuvem.
No Intune, crie um perfil de Certificado Raiz Confiável contendo o certificado raiz da CA em nuvem. Implante para o grupo de dispositivos 'Corporate Laptops'.
Crie um perfil de Certificado SCEP apontando para a URL do gateway SCEP em nuvem. Defina o Nome do Assunto como CN={{UserPrincipalName}} para autenticação baseada em usuário. Implante para 'Corporate Laptops'.
Crie um perfil de Wi-Fi para o SSID corporativo com EAP-TLS, referenciando o perfil SCEP e a raiz da CA em nuvem. Implante para 'Corporate Laptops'.
Quando os laptops se registrarem no Intune, eles solicitarão automaticamente certificados da CA em nuvem por meio do gateway SCEP em nuvem. Nenhuma infraestrutura local é necessária em nenhuma das 50 localidades.

Comentário do examinador: Esta é a arquitetura moderna ideal para ambientes de varejo distribuídos. Ao aproveitar a PKI em nuvem e o RADIUS em nuvem, a organização elimina a necessidade de manter uma infraestrutura local complexa (NDES, AD CS, NPS) em cada site. O gateway SCEP em nuvem escala horizontalmente e é inerentemente altamente disponível, removendo o ponto único de falha que o NDES local introduz. A arquitetura gerenciada em nuvem da Cisco Meraki se alinha perfeitamente com essa abordagem.

Questões práticas

Q1. Sua organização está migrando de PEAP-MSCHAPv2 para EAP-TLS. Você implantou com sucesso os perfis Trusted Root e SCEP para o seu grupo do Azure AD 'Corporate Users' no Intune. Você implanta o perfil de WiFi para 'All Corporate Devices'. Os usuários relatam que não conseguem se conectar e o perfil de WiFi é exibido como Não Aplicável.

Dica: Verifique as dependências do perfil e as regras de direcionamento de grupo. O Intune resolve as dependências do perfil com base no grupo atribuído.

Ver resposta modelo

O problema é uma incompatibilidade de direcionamento de grupo. O perfil de WiFi depende do perfil SCEP, que foi direcionado a um grupo de Usuários ('Corporate Users'). O perfil de WiFi foi direcionado a um grupo de Dispositivos ('All Corporate Devices'). O Intune não pode resolver a dependência entre tipos de grupos diferentes. A solução é alterar as atribuições de todos os três perfis - Trusted Root, SCEP e WiFi - para direcionar ao mesmo grupo. Decida se usará um grupo de Usuários ou um grupo de Dispositivos com base no seu modelo de autenticação (baseado em usuário vs. baseado em dispositivo) e aplique isso de forma consistente em todos os três perfis.

Q2. Uma auditoria de segurança revela que, quando um funcionário é desligado e sua conta do Microsoft Entra ID é desativada, seu smartphone corporativo ainda consegue se conectar à rede WiFi da equipe por até uma semana após o desligamento.

Dica: Considere como o servidor RADIUS determina se um certificado ainda é válido após a conta ser desativada. Qual é o mecanismo para comunicar o status de revogação?

Ver resposta modelo

O servidor RADIUS não está realizando uma verificação estrita da Lista de Revogação de Certificados (CRL) ou a CRL é publicada com pouca frequência. Quando um funcionário é desligado, o MDM deve desinscrever o dispositivo e a CA deve revogar o certificado. No entanto, se o servidor RADIUS não estiver verificando a CRL a cada tentativa de autenticação - ou se a CRL for publicada apenas semanalmente - o certificado revogado continuará sendo aceito. A solução envolve três etapas: configurar o servidor RADIUS para impor a verificação estrita da CRL em cada autenticação; configurar a CA para publicar a CRL em um intervalo menor (diariamente ou com maior frequência); e garantir que o MDM esteja configurado para acionar a revogação do certificado quando um dispositivo for desinscrito.

Q3. Você precisa fornecer acesso WiFi seguro para dispositivos IoT headless (termostatos inteligentes, players de sinalização digital) que não podem executar um agente MDM e não podem exibir um Captive Portal. Você pode usar SCEP para esses dispositivos e, se não, qual é a alternativa recomendada?

Dica: Considere os pré-requisitos para a inscrição SCEP e quais alternativas existem para dispositivos que não podem ser inscritos no MDM ou interagir com um navegador.

Ver resposta modelo

O SCEP não pode ser usado para esses dispositivos. O SCEP requer um agente MDM para receber a URL de inscrição e a senha de desafio, gerar o par de chaves e instalar o certificado resultante. Dispositivos IoT headless que não podem executar um agente MDM não podem participar do fluxo de inscrição SCEP. As alternativas recomendadas são: (1) MAC Authentication Bypass (MAB) combinado com segmentação estrita de VLAN - o servidor RADIUS permite o dispositivo com base em seu endereço MAC e o coloca em uma VLAN de IoT isolada, sem acesso aos sistemas corporativos; (2) se o dispositivo for compatível, o EST (Enrollment over Secure Transport, RFC 7030) pode provisionar certificados para dispositivos que suportam HTTPS, mas não MDM; (3) para dispositivos com uma interface de gerenciamento, alguns fornecedores oferecem suporte à inscrição SCEP diretamente por meio do firmware do dispositivo, sem a necessidade de um agente MDM. Em todos os casos, os dispositivos IoT devem ser isolados em uma VLAN dedicada, independentemente do método de autenticação utilizado.

Continue a ler esta série

Entendendo o Cisco SUDI: Identidade Ancorada em Hardware no Controle de Acesso a Redes Seguras

Este guia explica como o Cisco SUDI fornece uma identidade criptograficamente segura e ancorada em hardware para a infraestrutura de rede corporativa. Saiba como substituir endereços MAC clonáveis por certificados 802.1AR imutáveis para proteger o controle de acesso à rede do seu local.

Como implementar SCEP para registro automatizado de certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para registro automatizado de certificados WiFi em locais corporativos. Ele abrange o projeto arquitetônico completo - desde o design de PKI e integração com MDM até a sequência obrigatória de implantação em três etapas - e mostra aos gerentes de TI e arquitetos de rede como eliminar credenciais compartilhadas, automatizar o gerenciamento do ciclo de vida dos certificados e atender aos requisitos do PCI DSS e GDPR em escala.

Entendendo o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controle de Acesso à Rede

Este guia detalha a arquitetura técnica do Cisco SUDI, explicando como a identidade ancorada em hardware protege o controle de acesso à rede. Ele fornece etapas práticas de implementação para líderes de TI implantarem a autenticação 802.1X EAP-TLS e automatizarem o Zero Touch Provisioning em locais corporativos.