Implementação de Certificados WiFi do Microsoft Intune via SCEP e PKCS

Resumo Executivo

Para recintos empresariais—seja um ambiente de Hospitalidade movimentado, uma operação de Retalho com vários locais ou um campus corporativo moderno—depender de chaves pré-partilhadas ou de Captive Portals básicos para o WiFi dos funcionários é uma vulnerabilidade de segurança e um estrangulamento operacional. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS, garantindo que cada dispositivo é verificado criptograficamente antes de aceder à rede.

No entanto, o desafio reside na distribuição: como implementar certificados de cliente únicos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar o seu helpdesk com pedidos de suporte? O Microsoft Intune resolve este problema através da gestão automatizada do ciclo de vida dos certificados. Ao tirar partido de perfis de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), as equipas de TI podem enviar certificados de raiz e de cliente fidedignos de forma silenciosa para os terminais geridos.

Este guia fornece um modelo arquitetural definitivo e uma estratégia de implementação passo a passo para a implementação de certificados WiFi no Intune. Exploraremos as diferenças críticas entre SCEP e PKCS, detalharemos a sequência exata de implementação necessária para o sucesso e delinearemos estratégias de mitigação de riscos no mundo real para garantir que o seu Guest WiFi e as redes corporativas permanecem seguros e performantes.

Ouça o podcast informativo complementar:

Análise Técnica Aprofundada: SCEP vs. PKCS

Ao desenhar a sua estratégia de implementação de certificados WiFi no Intune, a primeira decisão arquitetural é selecionar o mecanismo de entrega de certificados. O Intune suporta tanto SCEP como PKCS, mas estes operam de forma fundamentalmente diferente.

SCEP (Simple Certificate Enrollment Protocol)

O SCEP é o padrão da indústria para o registo de dispositivos empresariais. Num fluxo de trabalho SCEP, o serviço Intune instrui o terminal a gerar o seu próprio par de chaves privada/pública. O dispositivo cria então um Pedido de Assinatura de Certificado (CSR) e envia-o através de um servidor NDES (Network Device Enrollment Service) para a sua Autoridade de Certificação (CA). A CA assina o pedido e devolve o certificado público ao dispositivo.

A vantagem crítica de segurança do SCEP é que a chave privada nunca sai do dispositivo. É gerada localmente, armazenada no enclave seguro do dispositivo (como o TPM no Windows ou o Secure Enclave no iOS), e nunca é transmitida pela rede. Isto torna o SCEP a abordagem fortemente recomendada para a autenticação 802.1X.

PKCS (Public Key Cryptography Standards)

Inversamente, com o PKCS, a Autoridade de Certificação gera tanto a chave pública como a privada centralmente. O Microsoft Intune Certificate Connector exporta então este par de chaves de forma segura e envia-o para o dispositivo de destino.

Embora o PKCS elimine a necessidade de implementar e manter um servidor NDES—simplificando a infraestrutura—introduz um risco de segurança teórico porque a chave privada é transmitida pela rede. O PKCS é geralmente mais adequado para casos de utilização onde a custódia de chaves (key escrow) é necessária, como a cifragem de e-mail S/MIME, em vez de autenticação de rede.

Guia de Implementação: A Sequência de Implementação

A configuração bem-sucedida de um perfil WiFi no Intune para 802.1X requer a adesão estrita a uma sequência de implementação específica. As dependências de perfil do Intune ditam que a confiança deve ser estabelecida antes que a autenticação possa ser configurada.

Passo 1: Implementar o Perfil de Certificado de Raiz Fidedigno

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação emissora.

1. Exporte o seu certificado de CA de Raiz (e quaisquer certificados de CA Intermédia) como ficheiros .cer.
2. No centro de administração do Microsoft Endpoint Manager, navegue para Dispositivos > Perfis de configuração > Criar perfil.
3. Selecione a plataforma de destino (ex: Windows 10 e posterior) e escolha o tipo de perfil Certificado fidedigno.
4. Carregue o ficheiro .cer e implemente este perfil nos seus grupos de dispositivos de destino.

Regra Geral: Direcione sempre os mesmos grupos (Utilizadores ou Dispositivos) em todos os perfis relacionados para evitar falhas na implementação.

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.

1. Crie um novo perfil de configuração e selecione Certificado SCEP.
2. Configure o Formato do nome do requerente. Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo, utilize CN={{AAD_Device_ID}}.
3. Defina a Utilização de chaves para Assinatura digital e Cifragem de chaves.
4. Em Utilização alargada de chaves, especifique Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2).
5. Associe este perfil ao perfil de Certificado de Raiz Fidedigno criado no Passo 1.
6. Forneça o URL externo do seu servidor NDES.

Passo 3: Implementar o Perfil WiFi 802.1X

O passo final é enviar a configuração WiFi que associa os certificados ao SSID da rede.

1. Crie um perfil de configuração Wi-Fi.
2. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus Pontos de Acesso Sem Fios .
3. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança.
4. Defina o Tipo de EAP para EAP-TLS.
5. Nas definições de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente.
6. Especifique o certificado Trusted Root para validação do servidor, de modo a garantir que o dispositivo apenas se liga ao seu servidor RADIUS legítimo.

Melhores Práticas e Padrões do Setor

Ao implementar a implementação de certificados WiFi do Intune, adira às seguintes melhores práticas independentes de fornecedor para garantir a conformidade e a fiabilidade.

Colocação e Segurança do Servidor NDES

O servidor NDES deve estar acessível a partir da internet para permitir que os dispositivos remotos provisionem certificados antes de chegarem ao local. No entanto, expor um servidor interno diretamente à internet constitui um risco de segurança significativo.

Recomendação: Publique o URL do NDES utilizando o Azure AD Application Proxy. Isto proporciona um acesso remoto seguro sem abrir portas de entrada na firewall e permite aplicar políticas de Acesso Condicional ao fluxo de inscrição.

Verificação de RADIUS e CRL

A implementação de certificados é apenas metade da equação de segurança; a revogação é igualmente crítica. Se um funcionário for desligado, desativar a sua conta de Active Directory pode não revogar imediatamente o seu acesso WiFi se o seu certificado de cliente permanecer válido e o servidor RADIUS não estiver a verificar rigorosamente a Lista de Revogação de Certificados (CRL).

Recomendação: Configure o seu Network Policy Server (NPS) ou servidor RADIUS para impor uma verificação rigorosa da CRL. Certifique-se de que os seus Pontos de Distribuição de CRL (CDPs) têm elevada disponibilidade; se o servidor RADIUS não conseguir aceder à CRL, a autenticação falhará, causando uma interrupção generalizada.

Para mais informações sobre o design de redes seguras, considere rever Os Principais Benefícios do SD WAN para Empresas Modernas .

Resolução de Problemas e Mitigação de Riscos

Mesmo com um planeamento meticuloso, a implementação de certificados pode encontrar problemas. Aqui estão os modos de falha comuns e as estratégias de mitigação.

Problema: Falha na Aplicação do Perfil WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil WiFi aparece como 'Erro' ou 'Não Aplicável' no Intune.

Causa Raiz: Isto é quase sempre causado por uma incompatibilidade no direcionamento de grupos. Se o perfil SCEP for atribuído a um Grupo de Utilizadores, mas o perfil WiFi for atribuído a um Grupo de Dispositivos, o Intune não consegue resolver a dependência.

Mitigação: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi estão todos implementados no exato mesmo grupo do Azure AD.

Problema: Erros NDES 403 Forbidden

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

Causa Raiz: A conta de serviço do Intune Certificate Connector não tem as permissões necessárias no modelo de certificado, ou a filtragem de URL na sua firewall está a bloquear os parâmetros específicos da query string utilizados pelo SCEP.

Mitigaçã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 a ser bloqueados.

ROI e Impacto no Negócio

A transição para a implementação de certificados 802.1X do Microsoft Intune proporciona retornos mensuráveis em termos de segurança e operações.

1. Redução de Pedidos de Suporte: O WiFi baseado em palavras-passe gera um volume significativo de pedidos de suporte (expiração de palavras-passe, bloqueios, erros de digitação). A autenticação baseada em certificados é invisível para o utilizador, reduzindo tipicamente o volume de suporte relacionado com WiFi em 70-80%.
2. Postura de Segurança Reforçada: O EAP-TLS elimina o risco de recolha de credenciais e ataques Man-in-the-Middle (MitM). Isto é fundamental para a conformidade com frameworks como PCI DSS e GDPR, particularmente em ambientes de Saúde e retalho.
3. Onboarding Sem Interrupções: Para organizações que gerem grandes frotas de dispositivos Apple a par de Windows, a integração do Intune com fluxos de trabalho de MDM existentes (consulte o nosso guia sobre Jamf e RADIUS: Autenticação WiFi Baseada em Certificados para Frotas de Dispositivos Apple ) garante uma experiência de provisionamento unificada e zero-touch desde o primeiro dia.