Como Configurar SCEP para Inscrição Automatizada de Certificados WiFi Enterprise

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a inscrição automatizada de certificados WiFi enterprise, cobrindo toda a arquitetura desde a 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 precisam de ir além das chaves pré-partilhadas 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 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,719 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 9 definições principais

Video overview

Ouça este guia

Ver transcrição do podcast

Bem-vindo à série de Briefing Técnico da Purple. Hoje vou falar sobre algo que chega a muitas caixas de entrada de TI, mas que raramente obtém uma resposta direta: como implementar efetivamente 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 multi-site ou de uma grande propriedade do setor público, os desafios são idênticos.

Vamos cobrir todo o cenário. 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 vão custar 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 isto.

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 necessitar que um ser 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 está a visar é o EAP-TLS, Extensible Authentication Protocol com Transport Layer Security, que se insere 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 nocivo para recolher credenciais.

Eis como funciona toda a cadeia. Um dispositivo gerido - um portátil de um estudante, um 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 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 (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 fidedignidade da AC, 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 situa 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 AC gera a chave pública e a chave 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 utilização como a encriptação de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para a autenticação de 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 de RADIUS, quer seja o Windows NPS, o FreeRADIUS ou um serviço de 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 de segmentar a rede por identidade. O dispositivo de um estudante obtém a VLAN 20 apenas para acesso à Internet. O dispositivo de um docente obtém a VLAN 10 para acesso aos sistemas internos de investigação. O dispositivo de gestão de instalações obtém a VLAN 30 para acesso aos sistemas de gestão do edifício. Tudo isto é gerido pelos atributos do certificado e pela política de 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 associa o certificado a uma identidade específica, o que significa que 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 é 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 falha.

A sequência não é negociável: primeiro o certificado Trusted Root, em segundo o perfil de certificado SCEP e em 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 implementado no dispositivo, o perfil de WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas que na verdade é apenas um problema de temporização.

A segunda armadilha é a segmentação de 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 for direcionado 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-lhe um acesso remoto seguro sem portas de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo.

Quarto: disponibilidade de CRL. O seu servidor RADIUS verifica a Lista de Revogação de Certificados de cada vez que um dispositivo se autentica. Se o seu Ponto de Distribuição 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. Trata-se de uma interrupção em todo o campus. Torne os seus endpoints 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 mais uma dependência de infraestrutura.

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

O SCEP consegue gerir dispositivos BYOD que não estão registados num MDM? Não diretamente. O SCEP requer o registo num MDM para enviar o payload do certificado. Para BYOD não geridos, precisa de uma abordagem diferente: ou um portal de integração self-service, ou um SSID separado utilizando um Captive Portal com verificação de identidade. O Purple trata dessa camada de convidados e BYOD de forma simples, funcionando a par da sua rede de colaboradores autenticada por certificado.

E quanto ao iOS e Android? Ambas as plataformas suportam o SCEP de forma nativa. O iOS suporta o SCEP desde o iOS 4. O Android Enterprise suporta o 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.

Para resumir. A autenticação WiFi por certificado SCEP é a arquitetura certa para qualquer rede com mais de 50 dispositivos geridos. Elimina credenciais partilhadas, fornece identidade por dispositivo, permite a segmentação dinâmica de VLAN e integra-se diretamente com o seu fornecedor de identidade para revogação automatizada. A sequência de implementação - Trusted Root, depois perfil SCEP, depois perfil WiFi - é fixa. A segmentação 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 docentes, juntamente com uma camada de WiFi para convidados separada 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 WiFi empresarial aborda o caminho nativo na nuvem. E se estiver a pensar no que acontece quando um colaborador sai, o nosso guia sobre como revogar o acesso WiFi detalha todo o fluxo de trabalho de revogação.

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

Principais Conclusões

✓O SCEP (RFC 8894) automatiza a inscrição 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 detrimento 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 de WiFi. Violar esta 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. A segmentação entre grupos diferentes é a causa mais comum de falhas de implementação.
✓O NDES deve ser publicado através do Azure AD Application Proxy e 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 Ponto de Distribuição de CRL é uma dependência crítica da rede. Se o servidor RADIUS não conseguir aceder à CRL, falha de forma segura (fail-closed) e nega todas as autenticações em simultâneo.
✓O EAP-TLS com certificados fornecidos por SCEP satisfaz o Requisito 8.6 do PCI DSS 4.0 para redes sem fios em ambientes de dados de titulares de cartões e é necessá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 gere esta camada em conjunto com a sua rede de funcionários autenticada por certificado.

📚 Parte da nossa série principal: Guia de Segurança WiFi Enterprise →

Como Configurar SCEP para Inscrição Automatizada de Certificados WiFi Enterprise

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 .

Como Configurar SCEP para Inscrição Automatizada de Certificados WiFi Enterprise - scep architecture overview

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-as-a-Service - é 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.

Como Configurar SCEP para Inscrição Automatizada de Certificados WiFi Enterprise - deployment checklist infographic

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 WiFi. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2 ou WPA3 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, 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 aos dispositivos geridos solicitar e receber automaticamente certificados digitais X.509 de uma Autoridade de Certificação através de 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 de MDM como o Microsoft Intune e o Jamf para implementar certificados de autenticação WiFi em terminais geridos em grande 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 provas criptográficas.

O protocolo de autenticação de destino para WiFi empresarial. Obrigatório ou fortemente recomendado pela PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) e HIPAA para redes sem fios que processam dados confidenciais.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma Autoridade de Registo (RA) entre dispositivos habilitados para SCEP e uma Autoridade de Certificação. Valida palavras-passe 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 implementação do SCEP com o Microsoft Intune. Deve ser publicada através do Proxy de Aplicações do Azure AD em vez de 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 principal) 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 do 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 conseguem aceder à rede.

A disponibilidade do CRL Distribution Point (CDP) é crítica. Se o servidor RADIUS não conseguir alcançar a CRL, este falha de forma segura e nega todas as autenticações - causando uma falha geral em toda a rede.

RADIUS (Remote Authentication Dial-In User Service)

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

O servidor de autenticação no modelo de 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 em atributos de certificado ou na pertença a grupos de diretório, em vez de depender da seleção de SSID ou de filtragem por endereço MAC. Impõe a segmentação de rede através da 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 de MDM, como o Microsoft Intune e o Jamf, utilizam perfis SCEP para enviar instruções de registo de certificados para os dispositivos geridos sem a interaçã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 de WiFi. Os dispositivos BYOD não geridos requerem uma abordagem de integração diferente.

Exemplos Práticos

Uma propriedade de 200 quartos da Premier Inn precisa de proteger o seu WiFi para colaboradores 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. A propriedade utiliza pontos de acesso HPE Aruba.

Implementar uma PKI interna de duas camadas 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 Confiável contendo os certificados Root CA e Issuing CA. Implementar num grupo Azure AD de 'Dispositivos de Colaboradores da Propriedade'.
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 o Key Usage para Digital Signature e Key Encipherment, e o Extended Key Usage para Client Authentication. Implementar em 'Dispositivos de Colaboradores da Propriedade'.
Criar um perfil de Wi-Fi para o SSID de colaboradores, configurando WPA2-Enterprise e EAP-TLS. Selecionar o perfil SCEP para autenticação de clientes e a Root CA para validação do servidor. Implementar em 'Dispositivos de Colaboradores da Propriedade'.
Configurar as definições do RADIUS do HPE Aruba para apontar para o Windows NPS. No NPS, configurar uma Política de Rede que exija EAP-TLS e atribua a VLAN 10 para dispositivos de colaboradores.
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 autenticação baseada no dispositivo (CN={{AAD_Device_ID}}) em vez de autenticação baseada no utilizador, uma vez que vários colaboradores utilizam o mesmo dispositivo. Segue a sequência de implementação de perfis obrigatória e garante que todos os três perfis visam o mesmo grupo Azure AD. Publicar o NDES através do App Proxy em vez de exposição direta à internet é a postura de segurança correta para um ambiente de hotelaria.

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

Implemente 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 os certificados; o gateway SCEP na nuvem lida com a validação do CSR.
Configure o serviço RADIUS na nuvem (fornecido pelo fornecedor de PKI) no painel do Cisco Meraki em Wireless > Access Control para o SSID corporativo. Defina a segurança para WPA2-Enterprise e aponte o RADIUS para o serviço na nuvem.
No Intune, crie um perfil de Trusted Root Certificate contendo o certificado raiz da CA na nuvem. Aloque ao grupo de dispositivos 'Corporate Laptops'.
Crie um perfil de SCEP Certificate apontando para o URL do gateway SCEP na nuvem. Defina o Subject Name como CN={{UserPrincipalName}} para autenticação baseada no utilizador. Aloque ao grupo 'Corporate Laptops'.
Crie um perfil de Wi-Fi para o SSID corporativo com EAP-TLS, referenciando o perfil SCEP e a raiz da CA na nuvem. Aloque ao grupo 'Corporate Laptops'.
Quando os computadores portáteis se registarem no Intune, solicitam automaticamente os certificados à CA na nuvem através do gateway SCEP na nuvem. Não é necessária 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 de implementação. O gateway SCEP na nuvem dimensiona-se horizontalmente e é intrinsecamente altamente disponível, 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 para o seu grupo 'Corporate Users' do Azure AD no Intune. Implementa o perfil de WiFi para 'All Corporate Devices'. Os utilizadores relatam que não conseguem ligar-se e o perfil de WiFi é apresentado como Não Aplicável.

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

Ver resposta modelo

O problema deve-se a uma incompatibilidade na segmentação de grupos. 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 perfis - 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 essa decisão 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 da equipa até uma semana após a rescisão de contrato.

Dica: Considere de que forma o servidor RADIUS determina se um certificado ainda é válido após a conta ser desativada. Qual é o mecanismo utilizado 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 colaborador é demitido, o MDM deve anular a inscrição do dispositivo e a CA deve revogar o certificado. No entanto, se o servidor RADIUS não verificar a CRL em cada tentativa de autenticação - ou se a CRL apenas for publicada semanalmente - o certificado revogado continua a ser aceite. A correção envolve três passos: configurar o servidor RADIUS para impor a 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 a inscrição de um dispositivo é anulada.

Q3. Necessita de fornecer acesso WiFi seguro para dispositivos IoT "headless" (termóstatos inteligentes, ecrãs 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 a inscrição SCEP e quais as alternativas existentes para dispositivos que não podem ser inscritos num MDM ou interagir com um navegador.

Ver resposta modelo

O SCEP não pode ser utilizado para estes dispositivos. O SCEP requer um agente MDM para receber o URL de inscrição 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 inscrição 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 for compatível, o EST (Enrolment over Secure Transport, RFC 7030) pode fornecer certificados a dispositivos que suportem HTTPS mas não MDM; (3) para dispositivos com uma interface de gestão, alguns fabricantes suportam a inscrição SCEP diretamente através do firmware do dispositivo, sem necessidade 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

Compreender o Cisco SUDI: Identidade Ancorada em Hardware no Controlo de Acesso Seguro à Rede

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

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.