How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a atribuição automatizada de certificados WiFi empresariais, cobrindo toda a arquitetura desde PKI e NDES até à implementação de perfis MDM e validação RADIUS. Destina-se a gestores de TI, arquitetos de rede e CTOs em hotéis, cadeias de retalho, estádios, centros de conferências e organizações do setor público que necessitam de ir além das chaves pré-partilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição na nuvem da Purple, independente de hardware, integra-se diretamente com esta arquitetura, fornecendo a camada de WiFi para convidados e BYOD que coexiste com a sua rede de colaboradores autenticada por certificado.

📖 10 min de leitura📝 2,282 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 9 definições principais

Ouça este guia

Ver transcrição do podcast

Bem-vindo à série Purple Technical Briefing. Hoje vou falar sobre algo que chega a muitas caixas de entrada de TI, mas que raramente obtém uma resposta direta: como implementar, de facto, a autenticação WiFi baseada em certificados à escala, utilizando SCEP, numa grande rede. Quer se trate de um campus universitário, de um grupo hoteleiro com vários locais ou de uma grande propriedade do setor público, os desafios são idênticos.

Vamos cobrir o cenário completo. O que o SCEP realmente faz, como se enquadra numa arquitetura 802.1X, a sequência de implementação que a maioria das equipas erra, dois cenários de implementação no mundo real e as armadilhas que lhe custarão um fim de semana da sua vida se não planear para elas.

Este é um briefing de consultor, não um tutorial. Estou a assumir que sabe o que é um servidor RADIUS e que provavelmente já decidiu que precisa de se afastar das chaves pré-partilhadas. O que precisa agora é do mapa de implementação.

Vamos a isso.

Primeiros princípios. SCEP significa Simple Certificate Enrollment Protocol. Foi formalizado pelo IETF como RFC 8894 em 2020, embora já estivesse em utilização empresarial generalizada há mais de uma década antes disso. O seu trabalho é simples: automatizar o processo de obtenção de um certificado digital num dispositivo gerido sem exigir que um humano toque em cada máquina.

No contexto da autenticação WiFi, o SCEP é o mecanismo de entrega. O protocolo de autenticação real que tem como alvo é o EAP-TLS, Extensible Authentication Protocol com Transport Layer Security, que se enquadra na estrutura 802.1X. O EAP-TLS é amplamente considerado como o método de autenticação mais seguro para redes sem fios empresariais porque exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados válidos. Nenhum dos lados confia no outro sem prova criptográfica. Essa autenticação mútua é o que o protege contra ataques de "evil twin", onde um atacante cria um ponto de acesso não autorizado para recolher credenciais.

Aqui está como funciona toda a cadeia. Um dispositivo gerido, o portátil de um estudante, o telemóvel de um funcionário, um terminal de ponto de venda de um hotel, precisa de se ligar à rede sem fios corporativa. A 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: o URL do SCEP, que aponta para o seu servidor NDES 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. Isto é crítico. A chave privada nunca sai do dispositivo. É gerada no dispositivo, armazenada no enclave seguro ou TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request, um CSR, e envia-o para o gateway SCEP. O gateway valida o desafio, encaminha o CSR para a sua Autoridade de Certificação, 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 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 utilizador.

Agora, falemos 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 certificados suportado por plataformas como o Intune. Com o PKCS, a CA gera tanto a chave pública como a privada de forma centralizada, e o conector de certificados envia o par de chaves para o dispositivo. Isso significa que a chave privada viaja pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de uso como a encriptação de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para a autenticação WiFi, o SCEP é a escolha certa. A chave privada permanece no dispositivo, ponto final.

Agora, a camada de hardware. O SCEP e o EAP-TLS são normas neutras em termos 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 RADIUS, quer seja o Windows NPS, o FreeRADIUS ou um serviço RADIUS na nuvem, é onde define a política de validação de certificados e, fundamentalmente, onde configura a atribuição dinâmica de VLAN.

As VLANs dinâmicas são a forma como segmenta a rede por identidade. O dispositivo de um estudante recebe a VLAN 20 apenas para acesso à Internet. O dispositivo de um docente recebe a VLAN 10 para acesso a sistemas de investigação internos. O dispositivo de gestão de instalações recebe a VLAN 30 para acesso a sistemas de gestão de edifícios. Tudo isto é impulsionado pelos atributos do certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para a integração com fornecedores de identidade, os atributos do certificado SCEP, especificamente o Subject Alternative Name, podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que quando desativa uma conta no Entra ID e o MDM anula o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa é a história de revogação que as chaves pré-partilhadas simplesmente não conseguem contar.

Muito bem, falemos sobre a sequência de implementação, porque é aqui que a maioria das equipas se depara com problemas.

A sequência não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil de WiFi. Tanto o Intune como o Jamf impõem dependências de perfil. Se o seu perfil de WiFi referenciar um certificado SCEP que ainda não foi implementado no dispositivo, o perfil de WiFi falhará com um erro críptico que parece uma configuração incorreta, mas que na verdade é apenas um problema de temporização.

O segundo erro comum é a segmentação por grupos. Todos os três perfis, Trusted Root, SCEP e WiFi, devem ser implementados exatamente no mesmo grupo do Azure AD ou Jamf. Se o perfil SCEP for direcionado a um grupo de utilizadores e o perfil WiFi a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será apresentado como Não Aplicável. Isto apanha as equipas de surpresa constantemente.

Terceiro: acessibilidade do servidor NDES. O seu servidor NDES precisa de estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. A forma correta de o fazer é através do Azure AD Application Proxy, e não abrindo uma porta no seu firewall. O App Proxy oferece um acesso remoto seguro sem portas de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registo.

Quarto: 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 da CRL 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. Isso representa uma interrupção em todo o campus. Torne os seus endpoints de CRL altamente disponíveis e teste a revogação antes de entrar em produção.

Para redes de grande dimensão, com mais de 500 dispositivos, 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, removendo outra dependência de infraestrutura.

Vamos abordar algumas perguntas rápidas que ouvimos frequentemente dos CTOs.

O SCEP pode gerir dispositivos BYOD que não estão registados num MDM? Não diretamente. O SCEP requer o registo no MDM para enviar o payload do certificado. Para BYOD não geridos, precisa de uma abordagem diferente, seja um portal de integração self-service ou um SSID separado que utilize um Captive Portal com verificação de identidade. A Purple lida com essa camada de convidados e BYOD de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado.

E quanto ao iOS e Android? Ambas as plataformas suportam o SCEP nativamente. O iOS suporta SCEP desde o iOS 4. O Android Enterprise suporta SCEP através do Intune e de outros MDMs. A configuração é ligeiramente diferente por 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 sensíveis, 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.

Em resumo: a autenticação WiFi por certificado SCEP é a arquitetura correta para qualquer rede com mais de 50 dispositivos geridos. Elimina credenciais partilhadas, oferece identidade por dispositivo, permite a segmentação dinâmica de VLANs e integra-se diretamente com o seu fornecedor de identidade para revogação automatizada. A sequência de implementação — primeiro o Trusted Root, depois o perfil SCEP e, por fim, o perfil WiFi — é fixa. A segmentação por grupos deve ser consistente. A disponibilidade da CRL não é opcional.

Especificamente para o ensino superior, a combinação de SCEP para dispositivos de funcionários e docentes, juntamente com uma camada separada de WiFi para convidados para estudantes em dispositivos pessoais, oferece segurança e uma excelente experiência de utilizador sem cedências.

Se quiser aprofundar, o guia da Purple sobre autenticação de WiFi empresarial aborda o caminho nativo na nuvem. E se estiver a pensar no que acontece quando um funcionário sai, o nosso guia sobre revogação de acesso a WiFi explica todo o fluxo de trabalho de revogação.

Obrigado por ouvir. Sou da equipa técnica da Purple, e encontramo-nos no próximo briefing.

Principais Conclusões

✓O SCEP (RFC 8894) automatiza o registo de certificados para dispositivos geridos - a chave privada é gerada no próprio dispositivo e nunca é transmitida, tornando-o a escolha correta para autenticação WiFi em vez do PKCS.
✓A sequência de implementação não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP, terceiro o perfil WiFi. A violação desta ordem causa falhas de dependência de perfil.
✓Todos os três perfis de MDM (Trusted Root, SCEP, WiFi) devem visar exatamente o mesmo grupo de diretório. A segmentação de grupos cruzados é a causa mais comum de falhas de implementação.
✓O NDES deve ser publicado através do Azure AD Application Proxy, não exposto diretamente à internet. Para redes com mais de 500 dispositivos, um gateway SCEP na nuvem elimina o ponto único de falha do NDES.
✓A disponibilidade do CRL Distribution Point é uma dependência crítica da rede. Se o servidor RADIUS não conseguir aceder à CRL, falha de forma segura (fails closed) e nega todas as autenticações em simultâneo.
✓O EAP-TLS com certificados provisionados por SCEP cumpre o Requisito 8.6 do PCI DSS 4.0 para redes sem fios em ambientes de dados de titulares de cartões e é obrigatório para WPA3-Enterprise de 192 bits (Suite B).
✓O SCEP abrange apenas dispositivos geridos. Dispositivos BYOD não geridos e de convidados requerem um SSID separado com Captive Portal e verificação de identidade - a plataforma da Purple lida com esta camada em conjunto com a sua rede de colaboradores autenticada por certificado.

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 no RFC 8894 que permite a dispositivos geridos solicitar e receber automaticamente certificados digitais X.509 de uma Autoridade de Certificação via HTTP, utilizando uma palavra-passe de desafio partilhada para a autenticação inicial. A chave privada é gerada no dispositivo e nunca é transmitida.

O mecanismo padrão utilizado por plataformas MDM como o Microsoft Intune e Jamf para implementar certificados de autenticação WiFi em endpoints geridos em escala.

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

O método de autenticação 802.1X mais seguro, que exige que tanto o dispositivo cliente como 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 empresarial. Obrigatório ou fortemente recomendado pelo PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) e HIPAA para redes sem fios que processam dados sensíveis.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma Autoridade de Registo (RA) entre dispositivos compatíveis com SCEP e uma Autoridade de Certificação. Valida as palavras-passe de desafio e encaminha os CSRs para a CA em nome de dispositivos que não possuem credenciais de domínio.

Infraestrutura necessária para a implementação de SCEP com o Microsoft Intune. Deve ser publicada através do Azure AD Application Proxy em vez de ser exposta diretamente à internet.

PKI (Public Key Infrastructure)

A hierarquia de Autoridades de Certificação, políticas e procedimentos utilizados para emitir, gerir e revogar certificados digitais. Uma PKI de dois níveis consiste numa CA raiz offline (a âncora de confiança mestre) e numa CA emissora online (que lida com a emissão diária de certificados).

O pré-requisito não negociável para a implementação de EAP-TLS e SCEP. A CA raiz deve ser mantida isolada (air-gapped); a 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 que contém a sua chave pública e informações de identidade, enviada a uma Autoridade de Certificação para solicitar um certificado digital assinado. No SCEP, o CSR é gerado no dispositivo e envolvido num envelope PKCS antes da transmissão.

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

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade de Certificação que contém os números de série dos certificados que foram revogados antes da sua data de expiração. Os servidores RADIUS verificam a CRL em cada tentativa de autenticação para garantir que os certificados revogados não acedem à rede.

A disponibilidade do Ponto de Distribuição de CRL (CDP) é crítica. Se o servidor RADIUS não conseguir aceder à CRL, falha de forma segura (fails closed) e recusa 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) centralizadas para acesso à rede. No WiFi 802.1X, o servidor RADIUS valida os certificados dos clientes, verifica a CRL e envia uma mensagem Access-Accept ou Access-Reject para o ponto de acesso.

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

Atribuição dinâmica de VLAN

Uma funcionalidade RADIUS que coloca um dispositivo autenticado numa VLAN específica com base nos atributos do certificado ou na pertença a um grupo de diretório, em vez de depender da seleção de SSID ou da filtragem de endereços MAC. Aplica a segmentação de rede por identidade do dispositivo.

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

MDM (Mobile Device Management)

Software utilizado pelas equipas de TI para registar, configurar, proteger e gerir smartphones, tablets e computadores portáteis. As plataformas MDM como o Microsoft Intune e Jamf utilizam perfis SCEP para enviar instruções de registo de certificados para dispositivos geridos sem intervenção do utilizador.

O pré-requisito para a implementação de certificados baseada em SCEP. Os dispositivos devem estar registados no MDM antes de poderem receber perfis SCEP e WiFi. Os dispositivos BYOD não geridos requerem uma abordagem de integração separada.

Exemplos Práticos

Um hotel Premier Inn com 200 quartos precisa de proteger o seu WiFi de funcionários para tablets de ponto de venda e smartphones do serviço de quartos. Atualmente, utilizam uma chave pré-partilhada que foi divulgada a prestadores de serviços. Gerem os dispositivos através do Microsoft Intune e têm uma mistura de dispositivos iOS e Android. O hotel utiliza pontos de acesso HPE Aruba.

Implementar uma PKI interna de dois níveis do Microsoft AD CS. Configurar o NDES num Windows Server dedicado e publicá-lo através do Azure AD Application Proxy.
No Intune, criar um perfil de Certificado de Raiz Fidedigna que contenha os certificados da CA de Raiz e da CA Emissora. Implementar num grupo do Azure AD 'Property Staff Devices'.
Criar um perfil de Certificado SCEP no Intune a apontar para o URL externo do NDES. Definir o formato do Nome do Requerente como CN={{AAD_Device_ID}}, uma vez que se trata de dispositivos partilhados. Definir a Utilização de Chaves como Assinatura Digital e Cifragem de Chaves, e a Utilização de Chaves Alargada como Autenticação de Cliente. Implementar em 'Property Staff Devices'.
Criar um perfil de Wi-Fi para o SSID de funcionários, configurando WPA2-Enterprise e EAP-TLS. Selecionar o perfil SCEP para a autenticação de cliente e a CA de Raiz para a validação do servidor. Implementar em 'Property Staff Devices'.
Configurar as definições de RADIUS do HPE Aruba para apontarem para o Windows NPS. No NPS, configurar uma Política de Rede que exija EAP-TLS e atribua a VLAN 10 para dispositivos de funcionários.
Assim que os dispositivos receberem os perfis e se ligarem com sucesso, rodar a PSK no SSID antigo e agendar a sua desativação.

Comentário do Examinador: Esta abordagem identifica corretamente que os dispositivos partilhados (POS, serviço de quartos) requerem uma autenticação baseada no dispositivo (CN={{AAD_Device_ID}}) em vez de uma autenticação baseada no utilizador, uma vez que vários funcionários utilizam o mesmo dispositivo. Segue a sequência obrigatória de implementação de perfis e garante que os três perfis visam o mesmo grupo do Azure AD. A publicação do NDES através do App Proxy, em vez da exposição direta à Internet, é a postura de segurança correta para um ambiente hoteleiro.

Uma cadeia de retalho com 50 localizações pretende implementar o 802.1X para portáteis corporativos em todos os locais. Utilizam pontos de acesso Cisco Meraki e o Microsoft Intune. Não pretendem implementar e manter servidores NDES locais ou infraestrutura AD CS em cada localização ou no seu centro de dados.

Implementar um serviço de gateway SCEP e PKI baseado na nuvem que se integre com o Intune através do protocolo SCEP. A CA na nuvem emite certificados; o gateway SCEP na nuvem lida com a validação de CSR.
Configurar o serviço RADIUS na nuvem (fornecido pelo fornecedor de PKI) no painel do Cisco Meraki em Wireless > Access Control para o SSID corporativo. Definir a segurança para WPA2-Enterprise e apontar o RADIUS para o serviço na nuvem.
No Intune, criar um perfil de Certificado de Raiz Fidedigna que contenha o certificado de raiz da CA na nuvem. Implementar no grupo de dispositivos 'Corporate Laptops'.
Criar um perfil de Certificado SCEP a apontar para o URL do gateway SCEP na nuvem. Definir o Nome do Requerente como CN={{UserPrincipalName}} para autenticação baseada no utilizador. Implementar em 'Corporate Laptops'.
Criar um perfil de Wi-Fi para o SSID corporativo com EAP-TLS, referenciando o perfil SCEP e a raiz da CA na nuvem. Implementar em 'Corporate Laptops'.
Quando os portáteis se registam no Intune, solicitam automaticamente certificados à CA na nuvem através do gateway SCEP na nuvem. Não é necessária qualquer infraestrutura local em nenhuma das 50 localizações.

Comentário do Examinador: Esta é a arquitetura moderna ideal para ambientes de retalho distribuídos. Ao tirar partido de PKI na nuvem e RADIUS na nuvem, a organização elimina a necessidade de manter uma infraestrutura local complexa (NDES, AD CS, NPS) em cada local. O gateway SCEP na nuvem escala horizontalmente e é inerentemente de alta disponibilidade, removendo o ponto único de falha que o NDES local introduz. A arquitetura gerida na nuvem da Cisco Meraki alinha-se perfeitamente com esta abordagem.

Perguntas de Prática

Q1. A sua organização está a migrar de PEAP-MSCHAPv2 para EAP-TLS. Implementou com sucesso os perfis Trusted Root e SCEP no seu grupo do Azure AD 'Corporate Users' no Intune. Implementa o perfil de WiFi para 'All Corporate Devices'. Os utilizadores reportam que não conseguem ligar-se e o perfil de WiFi é apresentado como Não Aplicável.

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

Ver resposta modelo

O problema é uma incompatibilidade de segmentação de grupo. O perfil de WiFi depende do perfil SCEP, que foi direcionado a um grupo de Utilizadores ('Corporate Users'). O perfil de WiFi foi direcionado a um grupo de Dispositivos ('All Corporate Devices'). O Intune não consegue resolver a dependência entre diferentes tipos de grupos. A solução consiste em alterar as três atribuições de perfil - Trusted Root, SCEP e WiFi - para direcionar para o mesmo grupo. Decida se deve utilizar um grupo de Utilizadores ou um grupo de Dispositivos com base no seu modelo de autenticação (baseado em utilizador vs baseado em dispositivo) e aplique isso de forma consistente nos três perfis.

Q2. Uma auditoria de segurança revela que, quando um funcionário é despedido e a sua conta do Microsoft Entra ID é desativada, o seu smartphone corporativo ainda se consegue ligar à rede WiFi dos funcionários até uma semana após a rescisão.

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 estado de revogação?

Ver resposta modelo

O servidor RADIUS não está a realizar uma verificação rigorosa da Lista de Revogação de Certificados (CRL), ou a CRL é publicada com pouca frequência. Quando um funcionário é despedido, o MDM deve anular o registo do dispositivo e a CA deve revogar o certificado. No entanto, se o servidor RADIUS não estiver a verificar a CRL em cada tentativa de autenticação - ou se a CRL for publicada apenas semanalmente - o certificado revogado continua a ser aceito. A solução envolve três passos: configurar o servidor RADIUS para impor uma verificação rigorosa da CRL em cada autenticação; configurar a CA para publicar a CRL num intervalo mais curto (diariamente ou com maior frequência); e garantir que o MDM está configurado para acionar a revogação do certificado quando o registo de um dispositivo é anulado.

Q3. Necessita de fornecer acesso WiFi seguro para dispositivos IoT headless (termóstatos inteligentes, leitores de sinalização digital) que não podem executar um agente MDM e não conseguem apresentar um Captive Portal. Pode utilizar o SCEP para estes dispositivos e, se não, qual é a alternativa recomendada?

Dica: Considere os pré-requisitos para o registo SCEP e quais as alternativas existentes para dispositivos que não podem ser registados no MDM ou interagir com um browser.

Ver resposta modelo

O SCEP não pode ser utilizado para estes dispositivos. O SCEP requer um agente MDM para receber o URL de registo e a palavra-passe de desafio, gerar o par de chaves e instalar o certificado resultante. Os dispositivos IoT headless que não conseguem executar um agente MDM não podem participar no fluxo de registo SCEP. As alternativas recomendadas são: (1) MAC Authentication Bypass (MAB) combinado com uma segmentação rigorosa de VLAN - o servidor RADIUS permite o dispositivo com base no seu endereço MAC e coloca-o numa VLAN de IoT isolada, sem acesso aos sistemas corporativos; (2) se o dispositivo o suportar, o EST (Enrollment over Secure Transport, RFC 7030) pode fornecer certificados a dispositivos que suportam HTTPS mas não MDM; (3) para dispositivos com uma interface de gestão, alguns fornecedores suportam o registo SCEP diretamente através do firmware do dispositivo, sem necessitar de um agente MDM. Em todos os casos, os dispositivos IoT devem ser isolados numa VLAN dedicada, independentemente do método de autenticação utilizado.

Continue a ler esta série

O Guia Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais utilizando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Como Implementar SCEP para a Inscrição Automatizada de Certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para a inscrição automatizada de certificados WiFi em espaços empresariais. Abrange todo o plano de arquitetura - desde o design de PKI e integração de MDM até à sequência de implementação obrigatória de três passos - e mostra aos gestores de TI e arquitetos de rede como eliminar credenciais partilhadas, automatizar a gestão do ciclo de vida dos certificados e cumprir os requisitos de PCI DSS e GDPR à escala.

Compreender o Cisco SUDI: Identidade de Dispositivo Baseada em Hardware no Controlo de Acesso à Rede

Este guia detalha a arquitetura técnica do Cisco SUDI, explicando como a identidade ancorada em hardware protege o controlo de acesso à rede. Fornece passos de implementação práticos para líderes de TI implementarem a autenticação 802.1X EAP-TLS e automatizarem o Zero Touch Provisioning em espaços empresariais.