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

Resumo Executivo

Para espaços empresariais - seja um ambiente dinâmico de Hospitality, uma operação de Retail com vários locais ou um campus corporativo moderno - depender de chaves pré-partilhadas ou de portais cativos básicos para o WiFi da equipa é 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 seja verificado criptograficamente antes de aceder à rede.

No entanto, o desafio reside na distribuição: como implementar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar o suporte técnico com pedidos de assistência? 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 Enrolment Protocol) ou PKCS (Public Key Cryptography Standards), as equipas de TI podem enviar silenciosamente certificados raiz e de cliente fidedignos para endpoints 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 do Intune. Iremos explorar as diferenças críticas entre SCEP e PKCS, detalhar a sequência de implementação exata necessária para o sucesso e delinear estratégias de mitigação de riscos do mundo real para garantir que o seu Guest WiFi e as redes corporativas permaneçam seguros e eficientes.

Ouça o podcast complementar informativo:

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

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

SCEP (Simple Certificate Enrolment 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 endpoint 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 Enrolment 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)

Por outro lado, com o PKCS, a Autoridade de Certificação gera as chaves pública e privada de forma centralizada. 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 uso onde a custódia de chaves é necessária, como a encriptação de email 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 do Intune para 802.1X requer a adesão estrita a uma sequência de implementação específica. As dependências do perfil do Intune ditam que a fidedignidade 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 (por exemplo, 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 de Ouro: Direcione sempre os mesmos grupos (sejam Utilizadores ou Dispositivos) em todos os perfis relacionados para evitar falhas de correspondência na implementação.

Passo 2: Configurar o Perfil de Certificado SCEP

Assim que a fidedignidade 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 dispositivos, utilize CN={{AAD_Device_ID}}.
3. Defina a Utilização da chave como Assinatura digital e Encriptação de chaves.
4. Em Utilização avançada da chave, especifique Autenticação do 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 de WiFi que associa os certificados ao SSID da rede.

1. Crie um perfil de configuração WiFi.
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 como 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.
5. Especifique o certificado Trusted Root para a validação do servidor para garantir que o dispositivo apenas se liga ao seu servidor RADIUS legítimo.

Melhores Práticas e Padrões de Mercado

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 aprovisionem certificados antes de chegarem ao local. No entanto, expor um servidor interno diretamente à internet representa um risco de segurança significativo.

Recomendação: Publique o URL do NDES utilizando o 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.

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 demitido, desativar a sua conta do Active Directory pode não revogar imediatamente o seu acesso WiFi se o certificado de cliente continuar 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 de CRL. Garanta que os seus Pontos de Distribuição de CRL (CDPs) estão altamente disponíveis; se o servidor RADIUS não conseguir aceder à CRL, a autenticação irá falhar, causando uma interrupção generalizada.

Para mais informações sobre design de rede seguro, considere rever The Core SD WAN Benefits for Modern Businesses.

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

Mesmo com um planeamento meticuloso, a implementação de certificados pode encontrar problemas. Eis 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 exatamente no mesmo grupo do Azure AD.

Problema: Erros 403 Forbidden no NDES

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

Causa Raiz: A conta de serviço do Int Certificate Connector carece das 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 de AC. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão a ser bloqueados.

Retorno do Investimento e Impacto no Negócio

A transição para a implementação de certificados Microsoft Intune 802.1X 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. Melhoria da Postura de Segurança: O EAP-TLS elimina o risco de recolha de credenciais e de ataques Man-in-the-Middle (MitM). Isto é crítico para a conformidade com normas como o PCI-DSS e o GDPR, particularmente em ambientes de Saúde e retalho.
3. Integração Simplificada: Para organizações que gerem grandes frotas de dispositivos Apple juntamente com o Windows, a integração do Intune com os fluxos de trabalho de MDM existentes (consulte o nosso guia sobre Jamf and RADIUS: Certificate-Based WiFi Authentication for Apple Device Fleets) garante uma experiência de aprovisionamento unificada e sem intervenção manual desde o primeiro dia.