Come configurare SCEP per la registrazione automatica dei certificati WiFi aziendali

Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatica dei certificati WiFi aziendali, coprendo l'intera architettura, da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che hanno l'esigenza di superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay di Purple, indipendente dall'hardware, si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.

📖 10 minuti di lettura📝 2,720 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Benvenuti alla serie Purple Technical Briefing. Oggi parlerò di un argomento che arriva spesso nelle caselle di posta dei dipartimenti IT, ma che raramente riceve una risposta chiara: come distribuire concretamente l'autenticazione WiFi basata su certificati su larga scala, utilizzando SCEP, all'interno di una rete estesa. Che si tratti di un campus universitario, di un gruppo alberghiero multi-sito o di un grande patrimonio del settore pubblico, le sfide sono identiche.

Copriremo l'intero scenario. Cosa fa effettivamente SCEP, come si inserisce in un'architettura 802.1X, la sequenza di implementazione che la maggior parte dei team sbaglia, due scenari di implementazione reali e le insidie che vi costeranno un intero fine settimana se non le pianificate in anticipo.

Questo è un briefing di consulenza, non un tutorial. Presumo che sappiate cos'è un server RADIUS e che abbiate probabilmente già deciso di abbandonare le chiavi pre-condivise. Ciò di cui avete bisogno ora è la mappa di implementazione.

Entriamo nel vivo.

Primi principi. SCEP sta per Simple Certificate Enrollment Protocol. È stato formalizzato dall'IETF come RFC 8894 nel 2020, sebbene fosse già ampiamente utilizzato a livello aziendale da oltre un decennio. Il suo compito è semplice: automatizzare il processo di installazione di un certificato digitale su un dispositivo gestito senza richiedere l'intervento umano su ogni singola macchina.

Nel contesto dell'autenticazione WiFi, SCEP è il meccanismo di distribuzione. Il protocollo di autenticazione effettivo che state targettizzando è EAP-TLS (Extensible Authentication Protocol con Transport Layer Security), che si colloca all'interno del framework 802.1X. EAP-TLS è ampiamente considerato come il metodo di autenticazione più sicuro per le reti wireless aziendali perché richiede sia al dispositivo client che al server RADIUS di presentare certificati validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questa autenticazione reciproca è ciò che vi protegge dagli attacchi "evil twin", in cui un utente malintenzionato attiva un access point canaglia per sottrarre credenziali.

Ecco come funziona l'intera catena. Un dispositivo gestito, come il laptop di uno studente, il telefono del personale o un terminale POS di un hotel, deve connettersi alla rete wireless aziendale. La vostra piattaforma MDM, che potrebbe essere Microsoft Intune o Jamf, invia un payload SCEP a quel dispositivo. Il payload contiene due elementi: l'URL SCEP, che punta al vostro server NDES o gateway SCEP cloud, e una password di verifica o segreto condiviso.

Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questo passaggio è fondamentale. La chiave privata non lascia mai il dispositivo. Viene generata sul dispositivo, memorizzata nell'enclave sicura o nel TPM, e non viene mai trasmessa sulla rete. Il dispositivo crea quindi una richiesta di firma del certificato, un CSR, e la invia al gateway SCEP. Il gateway convalida la richiesta, inoltra il CSR alla vostra Autorità di Certificazione (CA), e la CA lo firma restituendo il certificato pubblico al dispositivo.

Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta quel certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla tua catena di attendibilità della CA, controlla la Certificate Revocation List per confermare che il certificato non sia stato revocato e, se tutto è in regola, invia un messaggio di accettazione all'access point. Il dispositivo è in rete. L'intero processo è invisibile all'utente.

Ora, parliamo di dove si colloca SCEP rispetto all'alternativa, ovvero PKCS. PKCS, Public Key Cryptography Standards, è l'altro metodo di distribuzione dei certificati supportato da piattaforme come Intune. Con PKCS, la CA genera sia la chiave pubblica che quella privata a livello centrale, e il connettore del certificato invia la coppia di chiavi al dispositivo. Ciò significa che la chiave privata viaggia sulla rete, il che introduce una superficie di attacco teorica. PKCS va bene per casi d'uso come la crittografia delle e-mail S/MIME, dove il deposito delle chiavi è effettivamente auspicabile. Per l'autenticazione WiFi, SCEP è la scelta giusta. La chiave privata rimane sul dispositivo, senza eccezioni.

Ora, il livello hardware. SCEP ed EAP-TLS sono standard indipendenti dal fornitore, il che significa che funzionano su access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La configurazione RADIUS, che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS cloud, è il luogo in cui si definisce la policy di convalida dei certificati e, soprattutto, in cui si configura l'assegnazione dinamica delle VLAN.

Le VLAN dinamiche consentono di segmentare la rete in base all'identità. Un dispositivo per studenti ottiene la VLAN 20 solo per l'accesso a Internet. Un dispositivo per docenti ottiene la VLAN 10 per l'accesso ai sistemi di ricerca interni. Un dispositivo per la gestione delle strutture ottiene la VLAN 30 per l'accesso ai sistemi di gestione dell'edificio. Tutto questo è guidato dagli attributi del certificato e dalla policy RADIUS, senza alcun intervento manuale per singolo dispositivo.

Per l'integrazione con l'identity provider, gli attributi del certificato SCEP, in particolare il Subject Alternative Name, possono contenere il nome principale dell'utente da Microsoft Entra ID, Okta o Google Workspace. Questo lega il certificato a un'identità specifica, il che significa che quando si disabilita un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questa è la gestione della revoca che le chiavi pre-condivise semplicemente non possono offrire.

Bene, parliamo della sequenza di distribuzione, perché è qui che la maggior parte dei team commette errori.

La sequenza non è negoziabile: prima il certificato Trusted Root, poi il profilo del certificato SCEP, infine il profilo WiFi. Sia Intune che Jamf impongono dipendenze tra i profili. Se il tuo profilo WiFi fa riferimento a un certificato SCEP che non è ancora stato distribuito sul dispositivo, il profilo WiFi fallirà con un errore criptico che sembra una configurazione errata ma che in realtà è solo un problema di tempistica.

Il secondo errore comune è il targeting dei gruppi. Tutti e tre i profili, Trusted Root, SCEP e WiFi, devono essere distribuiti esattamente allo stesso gruppo Azure AD o Jamf. Se il profilo SCEP è destinato a un gruppo di utenti e il profilo WiFi a un gruppo di dispositivi, Intune non sarà in grado di risolvere la dipendenza e il profilo WiFi risulterà come Non applicabile. Questo è un errore in cui i team incorrono costantemente.

Terzo: l'accessibilità del server NDES. Il server NDES deve essere raggiungibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Il modo corretto per farlo è tramite Azure AD Application Proxy, non aprendo una porta nel firewall. App Proxy offre un accesso remoto sicuro senza porte in entrata e consente di applicare criteri di accesso condizionale al flusso di registrazione.

Quarto: la disponibilità della CRL. Il server RADIUS controlla la Certificate Revocation List ogni volta che un dispositivo si autentica. Se il CRL Distribution Point non è disponibile, a causa di un server offline o di un URL modificato, l'autenticazione fallisce contemporaneamente per tutti i dispositivi della rete. Questo si traduce in un disservizio per l'intera sede. Assicuratevi che gli endpoint CRL siano altamente disponibili e testate la revoca prima di andare online.

Per le reti di grandi dimensioni, con più di 500 dispositivi, prendete in considerazione un gateway SCEP cloud anziché un NDES on-premises. I gateway cloud eliminano il single point of failure di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud, rimuovendo un'ulteriore dipendenza infrastrutturale.

Rispondiamo ora ad alcune domande rapide che riceviamo spesso dai CTO.

SCEP può gestire i dispositivi BYOD non registrati in un MDM? Non direttamente. SCEP richiede la registrazione MDM per inviare il payload del certificato. Per i dispositivi BYOD non gestiti, è necessario un approccio diverso, come un portale di onboarding self-service o un SSID separato che utilizzi un Captive Portal con verifica dell'identità. Purple gestisce questo livello di ospiti e BYOD in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato.

E per quanto riguarda iOS e Android? Entrambe le piattaforme supportano SCEP nativamente. iOS supporta SCEP fin da iOS 4. Android Enterprise supporta SCEP tramite Intune e altri MDM. La configurazione varia leggermente a seconda della piattaforma, ma il protocollo sottostante è identico.

EAP-TLS funziona con WPA3? Sì. WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti sensibili ed EAP-TLS è pienamente compatibile. Di fatto, WPA3-Enterprise con EAP-TLS è la combinazione raccomandata dalla Wi-Fi Alliance per le reti governative e finanziarie.

Per riassumere. L'autenticazione WiFi con certificato SCEP è l'architettura corretta per qualsiasi rete con più di 50 dispositivi gestiti. Elimina le credenziali condivise, fornisce un'identità per singolo dispositivo, consente la segmentazione dinamica delle VLAN e si integra direttamente con l'identity provider per la revoca automatizzata. La sequenza di distribuzione (Trusted Root, poi profilo SCEP, infine profilo WiFi) è fissa. Il targeting dei gruppi deve essere coerente. La disponibilità della CRL non è opzionale.

Specificamente per l'istruzione superiore, la combinazione di SCEP per i dispositivi del personale e dei docenti, insieme a un livello di guest WiFi separato per gli studenti sui dispositivi personali, offre sia sicurezza che un'ottima esperienza utente senza compromessi.

Se desideri approfondire, la guida di Purple sull'autenticazione WiFi aziendale copre il percorso cloud-native. E se stai pensando a cosa succede quando un dipendente lascia l'azienda, la nostra guida sulla revoca dell'accesso WiFi illustra l'intero flusso di lavoro di revoca.

Grazie per l'attenzione. Faccio parte del team tecnico di Purple e ci vediamo al prossimo briefing.

Punti chiave

✓SCEP (RFC 8894) automatizza la registrazione dei certificati per i dispositivi gestiti: la chiave privata viene generata sul dispositivo e non viene mai trasmessa, rendendolo la scelta corretta per l'autenticazione WiFi rispetto a PKCS.
✓La sequenza di distribuzione non è negoziabile: prima il certificato Trusted Root, secondo il profilo del certificato SCEP, terzo il profilo WiFi. La violazione di questo ordine causa errori di dipendenza del profilo.
✓Tutti e tre i profili MDM (Trusted Root, SCEP, WiFi) devono avere come target lo stesso identico gruppo di directory. Il targeting tra gruppi diversi è la causa più comune di errori di distribuzione.
✓NDES dovrebbe essere pubblicato tramite Azure AD Application Proxy, non esposto direttamente a Internet. Per le reti con più di 500 dispositivi, un gateway SCEP cloud elimina il singolo punto di errore di NDES.
✓La disponibilità del CRL Distribution Point è una dipendenza critica per la rete. Se il server RADIUS non riesce a raggiungere la CRL, si blocca in modalità protetta e nega contemporaneamente tutte le autenticazioni.
✓EAP-TLS con certificati forniti tramite SCEP soddisfa il requisito 8.6 di PCI DSS 4.0 per le reti wireless negli ambienti di dati dei titolari di carta ed è richiesto per WPA3-Enterprise a 192 bit (Suite B).
✓SCEP copre solo i dispositivi gestiti. I dispositivi BYOD non gestiti e gli ospiti richiedono un SSID separato con Captive Portal e verifica dell'identità: la piattaforma di Purple gestisce questo livello insieme alla rete del personale autenticata tramite certificato.

📚 Parte della nostra serie principale: 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

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo formalizzato nella RFC 8894 che consente ai dispositivi gestiti di richiedere e ricevere automaticamente certificati digitali X.509 da una Certificate Authority tramite HTTP, utilizzando una password di verifica condivisa per l'autenticazione iniziale. La chiave privata viene generata sul dispositivo e non viene mai trasmessa.

Il meccanismo standard utilizzato dalle piattaforme MDM come Microsoft Intune e Jamf per distribuire certificati di autenticazione WiFi agli endpoint gestiti su larga scala.

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

Il metodo di autenticazione 802.1X più sicuro, che richiede sia al dispositivo client sia al server RADIUS di presentare certificati X.509 validi. L'autenticazione reciproca implica che nessuna delle due parti si fidi dell'altra senza una prova crittografica.

Il protocollo di autenticazione di riferimento per il WiFi aziendale. Richiesto o fortemente raccomandato da PCI DSS 4.0, WPA3-Enterprise a 192 bit (Suite B) e HIPAA per le reti wireless che gestiscono dati sensibili.

NDES (Network Device Enrollment Service)

Un ruolo di Microsoft Windows Server che funge da Registration Authority (RA) tra i dispositivi abilitati a SCEP e una Certificate Authority. Convalida le password di verifica e inoltra le CSR alla CA per conto dei dispositivi che non dispongono di credenziali di dominio.

Infrastruttura richiesta per la distribuzione di SCEP con Microsoft Intune. Dovrebbe essere pubblicata tramite Azure AD Application Proxy anziché essere esposta direttamente a Internet.

PKI (Public Key Infrastructure)

La gerarchia di Certificate Authority, policy e procedure utilizzate per emettere, gestire e revocare certificati digitali. Una PKI a due livelli è composta da una root CA offline (l'ancora di attendibilità principale) e da una CA di emissione online (che gestisce l'emissione quotidiana dei certificati).

Il prerequisito non negoziabile per la distribuzione di EAP-TLS e SCEP. La CA radice (root CA) deve essere mantenuta isolata (air-gapped); la sua chiave privata è la base dell'intera catena di attendibilità dei certificati.

CSR (Certificate Signing Request)

Un messaggio generato da un dispositivo contenente la sua chiave pubblica e le informazioni di identità, inviato a una Certificate Authority per richiedere un certificato digitale firmato. In SCEP, la CSR viene generata sul dispositivo e racchiusa in una busta PKCS prima della trasmissione.

Generata automaticamente dal dispositivo durante il flusso di registrazione SCEP. La chiave privata utilizzata per firmare la CSR non lascia mai il dispositivo.

CRL (Certificate Revocation List)

Un elenco pubblicato dalla Certificate Authority contenente i numeri di serie dei certificati che sono stati revocati prima della loro data di scadenza. I server RADIUS controllano la CRL a ogni tentativo di autenticazione per garantire che i certificati revocati non possano accedere alla rete.

La disponibilità del CRL Distribution Point (CDP) è fondamentale. Se il server RADIUS non riesce a raggiungere la CRL, si blocca in modalità protetta e nega qualsiasi autenticazione, causando un'interruzione dell'intera rete.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce servizi centralizzati di autenticazione, autorizzazione e contabilità (AAA) per l'accesso alla rete. Nel WiFi 802.1X, il server RADIUS convalida i certificati client, controlla la CRL e restituisce un messaggio di Access-Accept o Access-Reject all'access point.

Il server di autenticazione nel modello supplicant-authenticator-server di 802.1X. Le implementazioni comuni includono Windows NPS, FreeRADIUS e servizi RADIUS in cloud.

Assegnazione dinamica della VLAN

Una funzionalità RADIUS che inserisce un dispositivo autenticato in una specifica VLAN in base agli attributi del certificato o all'appartenenza a un gruppo di directory, anziché affidarsi alla selezione dell'SSID o al filtraggio degli indirizzi MAC. Applica la segmentazione della rete in base all'identità del dispositivo.

Consente a un singolo SSID di servire più tipi di dispositivi con diversi livelli di accesso alla rete. Un dispositivo del personale ottiene la VLAN 10 (accesso interno); un dispositivo di un collaboratore esterno ottiene la VLAN 20 (solo internet); un terminale POS ottiene la VLAN 30 (solo sistemi di pagamento).

MDM (Mobile Device Management)

Software utilizzato dai team IT per registrare, configurare, proteggere e gestire smartphone, tablet e laptop. Le piattaforme MDM come Microsoft Intune e Jamf utilizzano i profili SCEP per inviare le istruzioni di registrazione dei certificati ai dispositivi gestiti senza alcuna interazione da parte dell'utente.

Il prerequisito per la distribuzione dei certificati basata su SCEP. I dispositivi devono essere registrati nell'MDM prima di poter ricevere i profili SCEP e WiFi. I dispositivi BYOD non gestiti richiedono un approccio di onboarding separato.

Esempi pratici

Una struttura Premier Inn da 200 camere deve proteggere la propria rete WiFi del personale per i tablet dei punti vendita e gli smartphone del servizio di pulizia. Attualmente utilizzano una chiave precondivisa che è stata trapelata a collaboratori esterni. Gestiscono i dispositivi tramite Microsoft Intune e hanno un mix di dispositivi iOS e Android. La struttura utilizza access point HPE Aruba.

Distribuire una PKI interna Microsoft AD CS a due livelli. Configurare NDES su un Windows Server dedicato e pubblicarlo tramite Azure AD Application Proxy.
In Intune, creare un profilo di Certificato radice attendibile contenente i certificati della CA radice e della CA emittente. Distribuire a un gruppo Azure AD "Property Staff Devices".
Creare un profilo di Certificato SCEP in Intune che punti all'URL esterno di NDES. Impostare il formato del Nome soggetto su CN={{AAD_Device_ID}} poiché si tratta di dispositivi condivisi. Impostare l'Utilizzo chiave su Firma digitale e Crittografia chiave, e l'Utilizzo chiave avanzato su Autenticazione client. Distribuire a "Property Staff Devices".
Creare un profilo Wi-Fi per l'SSID del personale, configurando WPA2-Enterprise ed EAP-TLS. Selezionare il profilo SCEP per l'autenticazione client e la CA radice per la convalida del server. Distribuire a "Property Staff Devices".
Configurare le impostazioni RADIUS di HPE Aruba in modo che puntino a Windows NPS. Su NPS, configurare un Criterio di rete che richieda EAP-TLS e assegni la VLAN 10 per i dispositivi del personale.
Una volta che i dispositivi ricevono i profili e si connettono correttamente, ruotare la PSK sul vecchio SSID e pianificarne la dismissione.

Commento dell'esaminatore: Questo approccio identifica correttamente che i dispositivi condivisi (POS, servizio di pulizia) richiedono un'autenticazione basata sul dispositivo (CN={{AAD_Device_ID}}) anziché un'autenticazione basata sull'utente, poiché più membri del personale utilizzano lo stesso dispositivo. Segue la sequenza obbligatoria di distribuzione dei profili e garantisce che tutti e tre i profili abbiano come target lo stesso gruppo Azure AD. La pubblicazione di NDES tramite App Proxy anziché l'esposizione diretta a Internet rappresenta la corretta postura di sicurezza per un ambiente ricettivo.

Una catena di vendita al dettaglio con 50 sedi desidera distribuire lo standard 802.1X per i laptop aziendali in tutti i siti. Utilizzano access point Cisco Meraki e Microsoft Intune. Non desiderano distribuire e mantenere server NDES locali o infrastrutture AD CS in ciascuna sede o nel proprio data center.

Implementare una PKI basata su cloud e un servizio gateway SCEP che si integri con Intune tramite il protocollo SCEP. La CA cloud emette i certificati; il gateway SCEP cloud gestisce la convalida CSR.
Configurare il servizio RADIUS cloud (fornito dal fornitore PKI) all'interno della dashboard Cisco Meraki in Wireless > Controllo accessi per l'SSID aziendale. Impostare la sicurezza su WPA2-Enterprise e indirizzare il RADIUS al servizio cloud.
In Intune, creare un profilo di Certificato radice attendibile contenente il certificato radice della CA cloud. Distribuire al gruppo di dispositivi "Corporate Laptops".
Creare un profilo di Certificato SCEP che punti all'URL del gateway SCEP cloud. Impostare il Nome soggetto su CN={{UserPrincipalName}} per l'autenticazione basata sull'utente. Distribuire a "Corporate Laptops".
Creare un profilo Wi-Fi per l'SSID aziendale con EAP-TLS, facendo riferimento al profilo SCEP e alla radice della CA cloud. Distribuire a "Corporate Laptops".
Quando i laptop si registrano in Intune, richiedono automaticamente i certificati alla CA cloud tramite il gateway SCEP cloud. Non è richiesta alcuna infrastruttura locale in nessuna delle 50 sedi.

Commento dell'esaminatore: Questa è l'architettura moderna ottimale per ambienti di vendita al dettaglio distribuiti. Sfruttando la PKI cloud e il RADIUS cloud, l'organizzazione elimina la necessità di mantenere una complessa infrastruttura locale (NDES, AD CS, NPS) in ciascun sito. Il gateway SCEP cloud scala orizzontalmente ed è intrinsecamente ad alta disponibilità, eliminando il singolo punto di guasto introdotto dal NDES locale. L'architettura gestita via cloud di Cisco Meraki si allinea perfettamente con questo approccio.

Domande di esercitazione

Q1. La tua organizzazione sta migrando da PEAP-MSCHAPv2 a EAP-TLS. Hai distribuito con successo i profili Trusted Root e SCEP al tuo gruppo Azure AD "Corporate Users" in Intune. Distribuisci il profilo WiFi a "All Corporate Devices". Gli utenti segnalano che non riescono a connettersi e il profilo WiFi risulta come Non applicabile.

Suggerimento: Verifica le dipendenze del profilo e le regole di targeting del gruppo. Intune risolve le dipendenze del profilo in base al gruppo assegnato.

Visualizza risposta modello

Il problema è una mancata corrispondenza nel targeting dei gruppi. Il profilo WiFi dipende dal profilo SCEP, che è stato indirizzato a un gruppo di utenti ("Corporate Users"). Il profilo WiFi è stato invece indirizzato a un gruppo di dispositivi ("All Corporate Devices"). Intune non può risolvere la dipendenza tra tipi di gruppi diversi. La soluzione consiste nel modificare tutte e tre le assegnazioni dei profili - Trusted Root, SCEP e WiFi - per indirizzarle allo stesso gruppo. Decidi se utilizzare un gruppo di utenti o un gruppo di dispositivi in base al tuo modello di autenticazione (basato su utente o basato su dispositivo) e applicalo in modo coerente a tutti e tre i profili.

Q2. Un audit di sicurezza rivela che quando un dipendente viene licenziato e il suo account Microsoft Entra ID viene disabilitato, il suo smartphone aziendale può ancora connettersi alla rete WiFi del personale fino a una settimana dopo il licenziamento.

Suggerimento: Considera come il server RADIUS determina se un certificato è ancora valido dopo che l'account è stato disabilitato. Qual è il meccanismo per comunicare lo stato di revoca?

Visualizza risposta modello

Il server RADIUS non sta eseguendo un controllo rigoroso della Certificate Revocation List (CRL), oppure la CRL viene pubblicata raramente. Quando un dipendente viene licenziato, l'MDM dovrebbe annullare la registrazione del dispositivo e la CA dovrebbe revocare il certificato. Tuttavia, se il server RADIUS non controlla la CRL a ogni tentativo di autenticazione - o se la CRL viene pubblicata solo settimanalmente - il certificato revocato continua a essere accettato. La soluzione prevede tre passaggi: configurare il server RADIUS per imporre un controllo rigoroso della CRL a ogni autenticazione; configurare la CA per pubblicare la CRL a un intervallo più breve (giornaliero o più frequente); e assicurarsi che l'MDM sia configurato per attivare la revoca del certificato quando un dispositivo viene rimosso dalla registrazione.

Q3. È necessario fornire un accesso WiFi sicuro per dispositivi IoT headless (termostati intelligenti, lettori di segnaletica digitale) che non possono eseguire un agente MDM e non possono visualizzare un Captive Portal. È possibile utilizzare SCEP per questi dispositivi e, in caso contrario, qual è l'alternativa consigliata?

Suggerimento: Considera i prerequisiti per la registrazione SCEP e quali alternative esistono per i dispositivi che non possono essere registrati tramite MDM o che non possono interagire con un browser.

Visualizza risposta modello

Non è possibile utilizzare SCEP per questi dispositivi. SCEP richiede un agente MDM per ricevere l'URL di registrazione e la password di verifica, generare la coppia di chiavi e installare il certificato risultante. I dispositivi IoT headless che non possono eseguire un agente MDM non possono partecipare al flusso di registrazione SCEP. Le alternative consigliate sono: (1) MAC Authentication Bypass (MAB) combinato con una rigorosa segmentazione della VLAN - il server RADIUS consente l'accesso al dispositivo in base al suo indirizzo MAC e lo inserisce in una VLAN IoT isolata senza accesso ai sistemi aziendali; (2) se il dispositivo lo supporta, EST (Enrollment over Secure Transport, RFC 7030) può fornire certificati a dispositivi che supportano HTTPS ma non MDM; (3) per i dispositivi dotati di un'interfaccia di gestione, alcuni fornitori supportano la registrazione SCEP direttamente tramite il firmware del dispositivo senza richiedere un agente MDM. In tutti i casi, i dispositivi IoT dovrebbero essere isolati su una VLAN dedicata, indipendentemente dal metodo di autenticazione utilizzato.

Continua a leggere questa serie

Comprensione di Cisco SUDI: Identità ancorata all'hardware nel controllo degli accessi di rete sicuro

Questa guida spiega come Cisco SUDI fornisca un'identità crittograficamente sicura e ancorata all'hardware per l'infrastruttura di rete aziendale. Scopri come sostituire gli indirizzi MAC facilmente falsificabili con certificati 802.1AR immutabili per proteggere il controllo degli accessi alla rete della tua struttura.

Come implementare SCEP per l'assegnazione automatizzata dei certificati WiFi

Questa guida spiega come implementare SCEP (Simple Certificate Enrollment Protocol) per l'assegnazione automatizzata dei certificati WiFi nelle sedi aziendali. Copre l'intero schema architetturale - dalla progettazione PKI e integrazione MDM alla sequenza obbligatoria di implementazione in tre passaggi - e mostra ai manager IT e agli architetti di rete come eliminare le credenziali condivise, automatizzare la gestione del ciclo di vita dei certificati e soddisfare i requisiti PCI DSS e GDPR su scala globale.

Comprendere Cisco SUDI: Identità del Dispositivo Basata su Hardware nel Controllo dell'Accesso alla Rete

Questa guida descrive in dettaglio l'architettura tecnica di Cisco SUDI, spiegando come l'identità ancorata all'hardware protegga il controllo dell'accesso alla rete. Fornisce passaggi di implementazione pratici per i leader IT per distribuire l'autenticazione 802.1X EAP-TLS e automatizzare il Zero Touch Provisioning in tutte le sedi aziendali.