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

Resumo Executivo

Para locais corporativos — seja um ambiente movimentado de Hospitalidade , uma operação de Varejo com várias unidades ou um campus corporativo moderno — depender de chaves pré-compartilhadas ou Captive Portals básicos para o WiFi da equipe é uma vulnerabilidade de segurança e um gargalo operacional. A arquitetura de rede moderna exige autenticação 802.1X usando EAP-TLS, garantindo que cada dispositivo seja criptograficamente verificado antes de acessar a rede.

No entanto, o desafio reside na distribuição: como implantar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar seu suporte com chamados? O Microsoft Intune resolve isso por meio do gerenciamento automatizado do ciclo de vida de certificados. Ao aproveitar os perfis de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), as equipes de TI podem enviar certificados raiz e de cliente confiáveis silenciosamente para os endpoints gerenciados.

Este guia fornece um projeto arquitetônico definitivo e uma estratégia de implementação passo a passo para a implantação de certificados WiFi do Intune. Exploraremos as diferenças críticas entre SCEP e PKCS, detalharemos a sequência exata de implantação necessária para o sucesso e descreveremos estratégias de mitigação de riscos do mundo real para garantir que seu WiFi para Convidados e redes corporativas permaneçam seguros e eficientes.

Ouça o podcast complementar sobre o tema:

Aprofundamento Técnico: SCEP vs. PKCS

Ao projetar sua estratégia de implantação de certificados WiFi do Intune, a primeira decisão arquitetônica é selecionar o mecanismo de entrega de certificados. O Intune suporta tanto SCEP quanto PKCS, mas eles operam de forma fundamentalmente diferente.

SCEP (Simple Certificate Enrollment Protocol)

O SCEP é o padrão da indústria para registro de dispositivos corporativos. Em um fluxo de trabalho SCEP, o serviço Intune instrui o endpoint a gerar seu próprio par de chaves privada/pública. O dispositivo então cria uma Solicitação de Assinatura de Certificado (CSR) e a envia por meio de um servidor de Serviço de Registro de Dispositivo de Rede (NDES) para sua Autoridade Certificadora (CA). A CA assina a solicitação e retorna o certificado público ao dispositivo.

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

PKCS (Public Key Cryptography Standards)

Por outro lado, com o PKCS, a Autoridade Certificadora gera as chaves pública e privada centralmente. O Microsoft Intune Certificate Connector então exporta esse par de chaves de forma segura e o envia para o dispositivo de destino.

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

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

A configuração bem-sucedida de um perfil WiFi do Intune para 802.1X requer a adesão estrita a uma sequência de implantaçã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: Implantar o Perfil de Certificado Raiz Confiável

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar em seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora.

1. Exporte seu certificado de CA Raiz (e quaisquer certificados de CA Intermediária) como arquivos .cer.
2. No centro de administração do Microsoft Endpoint Manager, navegue até 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 confiável.
4. Faça o upload do arquivo .cer e implante este perfil nos seus grupos de dispositivos de destino.

Regra de Ouro: Sempre direcione os mesmos grupos (sejam Usuários ou Dispositivos) em todos os perfis relacionados para evitar falhas de implantação.

Passo 2: Configurar o Perfil de Certificado SCEP

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

1. Crie um novo perfil de configuração e selecione Certificado SCEP.
2. Configure o Formato do nome do assunto. Para autenticação baseada em usuário, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo, use CN={{AAD_Device_ID}}.
3. Defina o Uso da chave como Assinatura digital e Cifragem de chave.
4. Em Uso estendido de chave, especifique Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2).
5. Vincule este perfil ao perfil de Certificado Raiz Confiável criado no Passo 1.
6. Forneça a URL externa do seu servidor NDES.

Passo 3: Implantar o Perfil WiFi 802.1X

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

1. Crie um perfil de configuração Wi-Fi.
2. Insira o Nome da rede (SSID) exatamente como ele é transmitido pelos seus Pontos de Acesso Sem Fio .
3. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança.
4. Defina o Tipo de EAP como EAP-TLS.
5. Nas configuraçõ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 Raiz Confiável para validação do servidor para garantir que o dispositivo se conecte apenas ao seu servidor RADIUS legítimo.

Melhores Práticas e Padrões da Indústria

Ao implementar a implantação de certificados WiFi do Intune, siga estas melhores práticas neutras de fornecedor para garantir conformidade e confiabilidade.

Posicionamento e Segurança do Servidor NDES

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

Recomendação: Publique a URL do NDES usando o Proxy de Aplicativo do Azure AD. Isso fornece acesso remoto seguro sem abrir portas de firewall de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro.

Verificação de RADIUS e CRL

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

Recomendação: Configure seu Servidor de Políticas de Rede (NPS) ou servidor RADIUS para impor a verificação rigorosa de CRL. Garanta que seus Pontos de Distribuição de CRL (CDPs) estejam altamente disponíveis; se o servidor RADIUS não conseguir alcançar a CRL, a autenticação falhará, causando uma interrupção generalizada.

Para mais informações sobre design de rede segura, considere revisar Os Principais Benefícios do SD WAN para Negócios Modernos .

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

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

Problema: O Perfil WiFi Falha ao ser Aplicado

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

Causa Raiz: Isso quase sempre é causado por uma incompatibilidade no direcionamento de grupo. Se o perfil SCEP for atribuído a um Grupo de Usuários, mas o perfil WiFi for atribuído a um Grupo de Dispositivos, o Intune não conseguirá resolver a dependência.

Mitigação: Audite suas atribuições. Certifique-se de que os perfis Raiz Confiável, SCEP e WiFi estejam todos implantados exatamente no mesmo grupo do Azure AD.

Problema: Erros NDES 403 Forbidden

Sintoma: Os dispositivos falham ao recuperar o certificado SCEP e os logs do IIS do NDES mostram erros HTTP 403.

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

Mitigação: Verifique se a conta do conector tem permissões de 'Leitura' e 'Registro' no modelo da CA. Verifique os logs do firewall para garantir que URLs contendo ?operation=GetCACaps não estejam sendo bloqueadas.

ROI e Impacto nos Negócios

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

1. Redução de Chamados no Suporte: O WiFi baseado em senha gera um volume significativo de chamados (expiração de senhas, bloqueios, erros de digitação). A autenticação baseada em certificado é invisível para o usuário, reduzindo tipicamente o volume de suporte relacionado ao WiFi em 70-80%.
2. Postura de Segurança Aprimorada: O EAP-TLS elimina o risco de coleta de credenciais e ataques Man-in-the-Middle (MitM). Isso é crítico para a conformidade com frameworks como PCI DSS e GDPR, particularmente em ambientes de Saúde e varejo.
3. Integração (Onboarding) Contínua: Para organizações que gerenciam grandes frotas de dispositivos Apple junto com Windows, a integração do Intune com fluxos de trabalho de MDM existentes (veja nosso guia sobre Jamf e RADIUS: Autenticação WiFi Baseada em Certificado para Frotas de Dispositivos Apple ) garante uma experiência de provisionamento zero-touch unificada desde o primeiro dia.