Como Usar o Microsoft Intune para Enviar Certificados de WiFi para Dispositivos

COMO USAR O MICROSOFT INTUNE PARA ENVIAR CERTIFICADOS WIFI PARA DISPOSITIVOS Um Informativo de Inteligência de WiFi Corporativo da Purple [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Boas-vindas de volta. Falo hoje em nome da Purple, a plataforma de inteligência de WiFi corporativo, e este episódio é um informativo focado em uma das capacidades mais práticas - e, honestamente, mais subestimadas - no 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 cadeia de varejo, um estádio ou instalações do setor público, conhece bem a dor que estou prestes a descrever. Você tem centenas ou milhares de dispositivos gerenciados. Deseja que eles se conectem ao seu WiFi corporativo de forma automática, segura, sem que os usuários precisem digitar senhas e sem que a equipe de TI precise configurar cada dispositivo manualmente. E você quer que essa conexão seja criptograficamente robusta - 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 atrapalhar 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 portas 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 solicitante - o seu ponto de acesso WiFi, que atua como o autenticador, e o seu servidor RADIUS, que é o servidor de autenticação responsável pela decisão final. Atualmente, o 802.1X suporta múltiplos métodos de autenticação. O mais seguro é o EAP-TLS - Protocolo de Autenticação Extensível com Segurança de Camada de Transporte. O EAP-TLS utiliza autenticação mútua por certificado: o dispositivo apresenta um certificado para comprovar sua identidade, e o servidor RADIUS apresenta um certificado para comprovar a dele. Sem senhas envolvidas. Sem credenciais que possam ser alvo de phishing. É isso que buscamos alcançar. O desafio sempre foi instalar esses certificados nos dispositivos em escala. É aí que o Microsoft Intune entra em ação. O Intune suporta dois mecanismos de implantação de certificados: SCEP - Simple Certificate Enrolment Protocol - e PKCS, que significa Public Key Cryptography Standards. Compreender 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, envia para a sua Autoridade de Certificação por meio de um servidor intermediário chamado NDES - Network Device Enrolment 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 PKCS, a Autoridade de Certificação 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 passa 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 mistos de dispositivos, e PKCS onde você tem uma frota homogênea de dispositivos Windows corporativos e deseja minimizar a complexidade da infraestrutura. Agora, vamos falar sobre a sequência de implantação - porque a ordem importa e errar nisso é a causa mais comum de falhas de lançamento. Passo um: configure sua Autoridade de Certificação. Você precisa de um modelo de certificado em sua instância do Active Directory Certificate Services - ou se você for totalmente nativo na nuvem, o Cloud PKI do Microsoft Intune agora está disponível de forma geral e remove totalmente a necessidade de CA local. O modelo precisa das extensões corretas de uso de chave: 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 de 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 de 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á uma tarde inteira olhando para o Event ID 20271 no log de eventos do Windows. Passo três: implante o perfil de certificado do cliente. Esse é o seu perfil SCEP - apontando para a URL do seu servidor NDES - ou o seu perfil PKCS, apontando para a sua Autoridade de Certificação. O Nome Alternativo do Assunto deve incluir o Nome Principal do Usuário para certificados de usuário, ou o ID do Dispositivo AAD para certificados de dispositivo. Essa distinção é importante: 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 do WiFi. No Intune, isso fica em Dispositivos, Perfis de Configuração, Modelos, Wi-Fi. Defina o tipo de WiFi para Enterprise, insira seu SSID, defina o tipo de EAP para 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: a partir do início de 2024, a Microsoft reforçou os requisitos de mapeamento de certificados. Se você estiver usando certificados de dispositivo com dispositivos ingressados no Azure AD que se autenticam em um NPS local, certifique-se de que o atributo altSecurityIdentities no objeto de computador no Active Directory esteja preenchido com a impressão digital do certificado. Isso não acontece de forma automática - você precisa de um script ou de um fluxo de trabalho para gerenciar 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: falhas 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 a raiz e 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 de perfil. Os perfis do Intune não chegam aos dispositivos instantaneamente. Em um parque de dispositivos grande, pode levar de 15 a 30 minutos para que os perfis se propaguem após a atribuição. Não faça testes 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 você estiver usando SCEP com ADCS, configure o ponto de distribuição da Lista de Revogação de Certificados corretamente e garanta que seu servidor RADIUS esteja verificando a CRL ou OCSP em cada autenticação. Este é um requisito de conformidade em estruturas como PCI-DSS, que exige que os mecanismos de controle de acesso sejam revogados imediatamente quando não forem mais necessários. Sobre o tema de conformidade: se você opera em um escopo 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 de ciclo de vida de certificados como parte de suas evidências de conformidade. Para ambientes regulamentados pela GDPR, particularmente na hotelaria e no setor público, a separação entre a sua rede corporate 802.1X e a sua rede guest WiFi é crítica. A sua rede gerenciada pelo Intune corporativa 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 o lado voltado para o visitante - Captive Portal, captura de consentimento, analytics - enquanto a sua rede corporativa gerenciada pelo Intune lida com funcionários e dispositivos operacionais. Essas duas redes nunca devem compartilhar a infraestrutura de autenticação. [PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto] Deixe-me passar por algumas perguntas que surgem regularmente. 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 implantações do zero ou organizações sem infraestrutura ADCS existente, é o caminho recomendado. Isso funciona para dispositivos macOS e iOS? Sim. O Intune suporta 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 é o seu melhor 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 ficar fora de conformidade - sem bloqueio de tela, sistema operacional desatualizado - o certificado pode ser revogado e o acesso à rede removido automaticamente. A Purple pode se integrar com essa arquitetura? Com certeza. A plataforma da Purple fica do lado da rede de convidados, lidando com autenticação de Captive Portal, gerenciamento de consentimento e analytics. A rede corporativa 802.1X e o guest WiFi da Purple operam em paralelo - mesma infraestrutura física, diferentes SSIDs e VLANs - oferecendo 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 por meio do Intune é um processo de cinco etapas - configuração da CA, implantação da raiz confiável, perfil de certificado de cliente, perfil de WiFi e atribuição de grupo. Escolha SCEP para BYOD e ambientes de alta segurança; PKCS para frotas mais simples de propriedade da empresa. Acerte no sequenciamento, lide com 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 registros 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 uma grande propriedade. Se você está planejando uma implantação e quer entender como a plataforma de WiFi de visitantes e analytics da Purple se integra à arquitetura de rede da sua empresa, visite purple.ai. Temos guias detalhados sobre integração com Microsoft Entra ID, arquitetura 802.1X e design de rede de visitantes para os setores hoteleiro, varejo e ambientes do setor público. Obrigado por ouvir. Até a próxima.