Como usar o Microsoft Intune para enviar certificados de WiFi para dispositivos

COMO USAR O MICROSOFT INTUNE PARA ENVIAR CERTIFICADOS DE WIFI PARA DISPOSITIVOS Um Informativo de Inteligência de WiFi Corporativo da Purple [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Boas-vindas de volta. Estou falando hoje em nome da Purple, a plataforma de inteligência de WiFi corporativo, e este episódio é um informativo focado em um dos recursos mais práticos — e, honestamente, mais subestimados — do kit de ferramentas do Microsoft Intune: a implantação automatizada de certificados para autenticação WiFi 802.1X. Se você gerencia WiFi em uma rede de hotéis, uma rede de varejo, um estádio ou um complexo do setor público, conhece bem o problema que vou descrever. Você tem centenas ou milhares de dispositivos gerenciados. Você quer que eles se conectem ao seu WiFi corporativo de forma automática e segura, sem que os usuários digitem senhas e sem que a equipe de TI precise tocar em cada dispositivo. E você quer que essa conexão seja criptograficamente forte — não apenas uma senha compartilhada que alguém já enviou por e-mail para metade da organização. É exatamente isso que a implantação de certificados do Intune resolve. E nos próximos nove minutos, vou orientar você sobre como isso funciona, como implantar e as armadilhas que costumam pegar a maioria das equipes na primeira tentativa. [APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos] Vamos começar com a arquitetura. A base aqui é o IEEE 802.1X — o padrão de controle de acesso à rede baseado em porta que tem sido a espinha dorsal da segurança de WiFi corporativo por mais de duas décadas. Quando um dispositivo se conecta ao seu WiFi, o 802.1X exige que ele se autentique antes de obter qualquer acesso à rede. A conversa de autenticação ocorre entre três partes: o dispositivo — chamado de suplicante —, o seu ponto de acesso WiFi, que atua como o autenticador, e o seu servidor RADIUS, que é o servidor de autenticação que toma a decisão final. O 802.1X suporta múltiplos métodos de autenticação. O mais seguro é o EAP-TLS — Extensible Authentication Protocol com Transport Layer Security. O EAP-TLS usa autenticação mútua por certificado: o dispositivo apresenta um certificado para provar sua identidade, e o servidor RADIUS apresenta um certificado para provar a dele. Sem senhas envolvidas. Sem credenciais que possam ser alvo de phishing. É isso que estamos buscando. O desafio sempre foi instalar esses certificados nos dispositivos em escala. É aí que entra o Microsoft Intune. O Intune suporta dois mecanismos de implantação de certificados: SCEP — Simple Certificate Enrollment Protocol — e PKCS, que significa Public Key Cryptography Standards. Entender a diferença é fundamental. Com o SCEP, a chave privada é gerada no próprio dispositivo. O dispositivo cria uma Solicitação de Assinatura de Certificado (CSR), envia-a para a sua Autoridade Certificadora (CA) por meio de um servidor intermediário chamado NDES — Network Device Enrollment Service — e a CA emite o certificado de volta. A chave privada nunca sai do dispositivo. Essa é a abordagem mais segura e é recomendada para ambientes BYOD e implantações de alta segurança. Com o PKCS, a Autoridade Certificadora gera o par de chaves, e o Intune Certificate Connector entrega a chave privada e o certificado ao dispositivo. É mais simples de configurar — sem necessidade de servidor NDES — mas a chave privada transita pelo conector, o que é uma consideração para a sua postura de segurança. Para a maioria das implantações corporativas, eu recomendaria SCEP para BYOD e ambientes de dispositivos mistos, e PKCS onde você tem uma frota homogênea de dispositivos Windows de propriedade da empresa e deseja minimizar a complexidade da infraestrutura. Agora, vamos falar sobre a sequência de implantação — porque a ordem importa e errar aqui é a causa mais comum de falhas de implementação. Passo um: configure sua Autoridade Certificadora. Você precisa de um modelo de certificado em sua instância do Active Directory Certificate Services — ou, se você for totalmente nativo em nuvem, o Cloud PKI do Microsoft Intune agora está disponível de forma geral e elimina completamente a necessidade de uma CA local. O modelo precisa das extensões corretas de uso de chave: a Autenticação de Cliente é obrigatória. Defina o tamanho mínimo da chave para 2048 bits, ou 4096 se a política de segurança da sua organização exigir. Passo dois: implante o certificado raiz confiável. Antes que qualquer dispositivo possa validar o certificado do servidor RADIUS, ele precisa confiar na CA que o emitiu. Você cria um perfil de configuração de Certificado Confiável no Intune, faz o upload do certificado da CA raiz e o atribui aos seus grupos de dispositivos. Isso deve chegar aos dispositivos antes de qualquer perfil de WiFi ou perfil de certificado de cliente. Se você errar a sequência, os dispositivos rejeitarão o servidor RADIUS e você passará a tarde olhando para o Event ID 20271 no log de eventos do Windows. Passo três: implante o perfil de certificado de cliente. Este é o seu perfil SCEP — apontando para a URL do seu servidor NDES — ou o seu perfil PKCS, apontando para a sua Autoridade Certificadora. O Subject Alternative Name deve incluir o User Principal Name para certificados de usuário, ou o AAD Device ID para certificados de dispositivo. Essa distinção importa: certificados de usuário autenticam o usuário conectado, certificados de dispositivo autenticam a própria máquina, o que significa que o dispositivo pode se conectar ao WiFi antes de um usuário fazer login — útil para cenários de ingresso no domínio e implantações de quiosques. Passo quatro: crie o perfil de configuração de WiFi. No Intune, isso fica em Dispositivos, Perfis de Configuração, Modelos, Wi-Fi. Defina o tipo de WiFi como Enterprise, insira seu SSID, defina o tipo de EAP como EAP-TLS, configure as definições de confiança do servidor — é aqui que você faz referência ao nome do certificado do servidor RADIUS — e, para a autenticação do cliente, faça referência ao perfil de certificado que você criou no passo três. Passo cinco: atribua tudo aos grupos corretos e valide. Atribua seu certificado raiz, certificado de cliente e perfis de WiFi aos mesmos grupos de dispositivos ou usuários. Use os relatórios integrados do Intune para monitorar o status de implantação do perfil. Uma implantação bem-sucedida mostra todos os três perfis como Bem-sucedido na lista de perfis de configuração do dispositivo. Um ponto crítico na configuração do NPS para ambientes Windows Server: desde o início de 2024, a Microsoft endureceu os requisitos de mapeamento de certificados. Se você estiver usando certificados de dispositivo com dispositivos ingressados no Azure AD autenticando contra o NPS local, precisa garantir que o atributo altSecurityIdentities no objeto do computador no Active Directory esteja preenchido com a impressão digital (thumbprint) do certificado. Isso não acontece automaticamente — você precisa de um script ou de um fluxo de trabalho para lidar com isso, normalmente acionado quando a CA emite um novo certificado. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aproximadamente 2 minutos] Deixe-me apresentar as três armadilhas que vejo com mais frequência em implantações corporativas. Armadilha um: lacunas na cadeia de certificados. O dispositivo precisa confiar em todos os certificados da cadeia, desde a CA raiz até o certificado do servidor RADIUS. Se o certificado do seu servidor RADIUS foi emitido por uma CA intermediária, você precisa implantar tanto a raiz quanto a intermediária nos dispositivos. Já vi implantações falharem por semanas porque alguém implantou a raiz, mas não a intermediária. Armadilha dois: tempo de atribuição do perfil. Os perfis do Intune não chegam aos dispositivos instantaneamente. Em um parque de grande porte, pode levar de 15 a 30 minutos para que os perfis se propaguem após a atribuição. Não teste imediatamente após criar os perfis. Use o botão Sincronizar no portal do Intune para forçar uma verificação e depois aguarde. Além disso, os perfis de certificado de cliente devem ser implantados e confirmados antes que o perfil de WiFi seja aplicado — se o perfil de WiFi fizer referência a um certificado que ainda não existe, o perfil falhará silenciosamente em algumas plataformas. Armadilha três: revogação de certificado BYOD. Quando um dispositivo é desvinculado do Intune — porque um funcionário sai ou um dispositivo é perdido —, você precisa de um processo para revogar o certificado. Se estiver usando SCEP com ADCS, configure o ponto de distribuição da Lista de Revogação de Certificados (CRL) corretamente e garanta que seu servidor RADIUS esteja verificando a CRL ou OCSP a cada autenticação. Este é um requisito de conformidade sob frameworks como o PCI DSS, que exige que os mecanismos de controle de acesso sejam revogados prontamente quando não forem mais necessários. Sobre o tema da conformidade: se você estiver operando dentro do escopo do PCI DSS — ambientes de pagamento de varejo, por exemplo —, a autenticação 802.1X baseada em certificado é o seu controle mais forte para acesso à rede sem fio. Ela atende ao Requisito 1.3 do PCI DSS sobre controles de acesso à rede e ao Requisito 8.6 sobre fatores de autenticação. Documente seu processo de gerenciamento do ciclo de vida dos certificados como parte de suas evidências de conformidade. Para ambientes regulamentados pelo GDPR, especialmente no setor de hospitalidade e no setor público, a separação entre a sua rede corporativa 802.1X e a sua rede guest WiFi é crítica. Sua rede corporativa gerenciada pelo Intune deve estar em uma VLAN e SSID completamente separados de qualquer rede de convidados ou visitantes. A plataforma de guest WiFi da Purple lida com a parte voltada para o visitante — Captive Portal, captura de consentimento, analytics — enquanto sua rede corporativa gerenciada pelo Intune lida com a equipe e os dispositivos operacionais. Essas duas redes nunca devem compartilhar a infraestrutura de autenticação. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Vou passar rapidamente por algumas perguntas que surgem com frequência. Posso usar o Intune Cloud PKI em vez do ADCS local? Sim. O Intune Cloud PKI da Microsoft, lançado em 2024, fornece uma CA totalmente gerenciada no Azure. Ele elimina a necessidade do servidor NDES para SCEP e simplifica significativamente a configuração do conector. Para novas implantações ou organizações sem infraestrutura ADCS existente, este é o caminho recomendado. Isso funciona para dispositivos macOS e iOS? Sim. O Intune oferece suporte a perfis de certificado para Windows, iOS, iPadOS, Android e macOS. Os tipos de perfil e as opções de configuração variam um pouco de acordo com a plataforma, mas a arquitetura principal — raiz confiável, certificado de cliente, perfil de WiFi — é consistente. E quanto aos dispositivos pessoais em um programa BYOD? O SCEP é seu aliado aqui. Com as políticas de conformidade de dispositivos do Intune, você pode exigir que um dispositivo atenda aos padrões mínimos de segurança antes que um certificado seja emitido. Se o dispositivo perder a conformidade — sem bloqueio de tela, sistema operacional desatualizado —, o certificado pode ser revogado e o acesso à rede removido automaticamente. A Purple pode se integrar a essa arquitetura? Com certeza. A plataforma da Purple fica do lado da rede de convidados, gerenciando a autenticação do Captive Portal, o gerenciamento de consentimento e o analytics. A rede corporativa 802.1X e o guest WiFi da Purple operam em paralelo — mesma infraestrutura física, diferentes SSIDs e VLANs —, proporcionando total separação entre a conectividade da equipe e o engajamento dos visitantes. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para resumir: a implantação de certificados de WiFi via Intune é um processo de cinco etapas — configuração da CA, implantação da raiz confiável, perfil de certificado do cliente, perfil de WiFi e atribuição de grupo. Escolha SCEP para BYOD e ambientes de alta segurança; PKCS para frotas corporativas mais simples. Acerte na sequência, trate o requisito de mapeamento de certificado NPS e crie um fluxo de trabalho de revogação de certificado desde o primeiro dia. O caso de negócios é simples: você elimina senhas de WiFi compartilhadas, obtém logs de autenticação por dispositivo e por usuário, atende aos requisitos de segurança sem fio PCI DSS e ISO 27001 e reduz a sobrecarga de TI no gerenciamento de credenciais de WiFi em um grande parque de dispositivos. Se você está planejando uma implantação e quer entender como a plataforma de WiFi para convidados e analytics da Purple se integra à arquitetura de rede corporativa, visite purple.ai. Temos guias detalhados sobre integração com Azure Entra ID, arquitetura 802.1X e design de rede de convidados para os setores de hotelaria, varejo e setor público. Obrigado por ouvir. Até a próxima.