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

COMO UTILIZAR O MICROSOFT INTUNE PARA ENVIAR CERTIFICADOS WIFI PARA DISPOSITIVOS Uma Apresentação de Informação sobre WiFi Empresarial da Purple [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Bem-vindo de volta. Falo hoje em nome da Purple, a plataforma de inteligência de WiFi empresarial, e este episódio é uma apresentação focada numa das capacidades mais práticas - e, honestamente, mais subestimadas - do conjunto de ferramentas do Microsoft Entra ID: a implementação automatizada de certificados para autenticação WiFi 802.1X. Se gere o WiFi num complexo hoteleiro, numa cadeia de retalho, num estádio ou num património do setor público, conhece a dor que estou prestes a descrever. Tem centenas ou milhares de dispositivos geridos. Deseja que se liguem ao seu WiFi corporativo de forma automática, segura, sem que os utilizadores introduzam palavras-passe e sem que a equipa de TI tenha de mexer em cada dispositivo individualmente. E quer que essa ligação seja criptograficamente forte - e não apenas uma palavra-passe partilhada que alguém já enviou por e-mail para metade da organização. É exatamente isso que a implementação de certificados do Intune resolve. E nos próximos nove minutos, vou explicar-lhe como funciona, como implementá-la e as armadilhas que apanham a maioria das equipas na primeira tentativa. [ANÁLISE TÉCNICA DETALHADA — aproximadamente 5 minutos] Comecemos pela arquitetura. A base aqui é o IEEE 802.1X - o padrão de controlo de acesso à rede baseado em portas que tem sido a espinha dorsal da segurança de WiFi empresarial há mais de duas décadas. Quando um dispositivo se liga ao seu WiFi, o 802.1X exige que se autentique antes de obter qualquer acesso à rede. A conversa de autenticação ocorre entre três partes: o dispositivo - chamado de requerente - o seu ponto de acesso WiFi, que funciona como o autenticador, e o seu servidor RADIUS, que é o servidor de autenticação que toma a decisão final. Agora, 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 utiliza autenticação mútua por certificado: o dispositivo apresenta um certificado para provar a sua identidade e o servidor RADIUS apresenta um certificado para provar a sua identidade. Sem palavras-passe envolvidas. Sem credenciais que possam ser alvo de phishing. É isto que pretendemos. O desafio sempre foi colocar esses certificados nos dispositivos à escala. É aí que entra o Microsoft Intune. O Intune suporta dois mecanismos de implementaçã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 um Pedido de Assinatura de Certificado, envia-o para a sua Autoridade de Certificação através de um servidor intermediário chamado NDES - Network Device Enrolment Service - e a AC emite o certificado de volta. A chave privada nunca sai do dispositivo. Esta é a abordagem mais segura e é recomendada para ambientes BYOD e implementaçõ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 implementações empresariais, recomendo SCEP para ambientes BYOD e de dispositivos mistos, e PKCS onde possui uma frota homogénea de dispositivos Windows corporativos e deseja minimizar a complexidade da infraestrutura. Agora, vamos falar sobre a sequência de implementação - porque a ordem importa e errar é a causa mais comum de implementações falhadas. Passo um: configure a sua Autoridade de Certificação. Precisa de um modelo de certificado na sua instância do Active Directory Certificate Services - ou se for totalmente cloud-native, o Intune Cloud PKI da Microsoft já está geralmente disponível e remove completamente o requisito de CA no local. O modelo necessita das extensões corretas de utilização de chaves: 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 o exigir. Passo dois: implemente o certificado raiz confiável. Antes que qualquer dispositivo possa validar o certificado do servidor RADIUS, ele precisa de confiar na CA que o emitiu. Cria um perfil de configuração de Certificado Confiável no Intune, faz o upload do certificado da CA raiz e atribui-o aos seus grupos de dispositivos. Este deve chegar aos dispositivos antes de qualquer perfil de WiFi ou perfil de certificado de cliente. Se errar na sequência, os dispositivos rejeitarão o servidor RADIUS e passará uma tarde a olhar para o Event ID 20271 no registo de eventos do Windows. Passo três: implemente o perfil de certificado de cliente. Este é o seu perfil SCEP - a apontar para o URL do seu servidor NDES - ou o seu perfil PKCS, a apontar para a sua Autoridade de Certificação. O Subject Alternative Name deve incluir o User Principal Name para certificados de utilizador, ou o AAD Device ID para certificados de dispositivo. Esta distinção importa: os certificados de utilizador autenticam o utilizador com sessão iniciada, os certificados de dispositivo autenticam a própria máquina, o que significa que o dispositivo pode ligar-se ao WiFi antes de um utilizador iniciar sessão - útil para cenários de adesão ao domínio e implementações de quiosques. Passo quatro: crie o perfil de configuração de WiFi. No Intune, isto está em Dispositivos, Perfis de Configuração, Modelos, Wi-Fi. Defina o tipo de WiFi para Enterprise, introduza o seu SSID, defina o tipo de EAP para EAP-TLS, configure as definições de confiança do servidor - é aqui que referencia o nome do certificado do servidor RADIUS - e para a autenticação de cliente, referencie o perfil de certificado que criou no passo três. Passo cinco: atribua tudo aos grupos corretos e valide. Atribua o seu certificado raiz, certificado de cliente e perfis de WiFi aos mesmos grupos de dispositivos ou utilizadores. Utilize os relatórios integrados do Intune para monitorizar o estado de implementação do perfil. Uma implementação bem-sucedida mostra os três perfis como 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 estiver a utilizar certificados de dispositivos com dispositivos associados ao Azure AD que se autenticam num NPS local, deve garantir que o atributo altSecurityIdentities no objeto do computador no Active Directory está preenchido com a assinatura (thumbprint) do certificado. Isto não acontece de forma automática - precisa de um script ou de um fluxo de trabalho para processar isto, geralmente acionado quando a AC emite um novo certificado. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos] Deixe-me apresentar os três erros comuns que vejo com mais frequência em implementações empresariais. Erro um: falhas na cadeia de certificados. O dispositivo precisa de confiar em todos os certificados da cadeia, desde a AC raiz até ao certificado do servidor RADIUS. Se o certificado do seu servidor RADIUS foi emitido por uma AC intermédia, precisa de implementar tanto a raiz como a intermédia nos dispositivos. Já vi implementações falharem durante semanas porque alguém implementou a raiz, mas não a intermédia. Erro dois: tempo de atribuição de perfis. Os perfis do Intune não chegam aos dispositivos instantaneamente. Numa infraestrutura de grandes dimensões, pode demorar de 15 a 30 minutos para os perfis se propagarem após a atribuição. Não teste imediatamente após criar os perfis. Utilize o botão Sincronizar no portal do Intune para forçar uma verificação e, em seguida, aguarde. Além disso, os perfis de certificado de cliente devem ser implementados e confirmados antes de o perfil de WiFi ser aplicado - se o perfil de WiFi referenciar um certificado que ainda não existe, o perfil irá falhar silenciosamente nalgumas plataformas. Erro três: revogação de certificados BYOD. Quando um dispositivo deixa de estar registado no Intune - porque um funcionário sai ou um dispositivo é perdido - precisa de um processo para revogar o certificado. Se estiver a utilizar SCEP com ADCS, configure o ponto de distribuição da Lista de Revogação de Certificados de forma correta e garanta que o seu servidor RADIUS está a verificar a CRL ou OCSP em cada autenticação. Este é um requisito de conformidade sob estruturas como a PCI-DSS, que exige que os mecanismos de controlo de acesso sejam revogados imediatamente quando deixam de ser necessários. Sobre o tema da conformidade: se estiver a operar num âmbito PCI-DSS - ambientes de pagamento de retalho, por exemplo - a autenticação 802.1X baseada em certificados é o seu controlo mais forte para o acesso à rede sem fios. Satisfaz o Requisito 1.3 da PCI-DSS sobre controlos de acesso à rede e o Requisito 8.6 sobre fatores de autenticação. Documente o seu processo de gestão do ciclo de vida dos certificados como parte das suas provas de conformidade. Para ambientes regulados pelo GDPR, particularmente na hotelaria e no setor público, a separação entre a sua rede corporativa 802.1X e a sua rede WiFi de convidados é crítica. A sua rede gerida pelo Intune corporativa deve estar numa VLAN e num SSID completamente separados de qualquer rede de convidados ou visitantes. A plataforma de WiFi de convidados da Purple lida com a parte voltada para o visitante - captive portal, recolha de consentimento, analítica - enquanto a sua rede corporativa gerida pelo Intune lida com funcionários e dispositivos operacionais. Estas duas redes nunca devem partilhar 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 gerida no Azure. Remove o requisito de servidor NDES para SCEP e simplifica significativamente a configuração do conector. Para novas implementações ou organizações sem infraestrutura ADCS existente, é o caminho recomendado. Isto 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 ligeiramente por plataforma, mas a arquitetura central - raiz fidedigna, certificado de cliente, perfil WiFi - é consistente. E quanto a dispositivos pessoais num programa BYOD? O SCEP é o seu melhor aliado aqui. Com as políticas de conformidade de dispositivos do Intune, pode exigir que um dispositivo cumpra os padrões mínimos de segurança antes que um certificado seja emitido. Se o dispositivo deixar de estar em conformidade - sem bloqueio de ecrã, OS desatualizado - o certificado pode ser revogado e o acesso à rede removido automaticamente. A Purple pode integrar-se com esta arquitetura? Absolutamente. A plataforma da Purple posiciona-se do lado da rede de convidados, gerindo a autenticação do captive portal, a gestão de consentimento e a analítica. A rede corporativa 802.1X e o WiFi de convidados da Purple funcionam em paralelo - mesma infraestrutura física, diferentes SSIDs e VLANs - proporcionando-lhe uma separação completa entre a conectividade dos funcionários e o envolvimento dos visitantes. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Para concluir: a implementação de certificados WiFi via Intune é um processo de cinco etapas - configuração de CA, implementação de raiz fidedigna, perfil de certificado de cliente, perfil WiFi e atribuição de grupo. Escolha SCEP para BYOD e ambientes de alta segurança; PKCS para frotas mais simples de propriedade corporativa. Acerte na sequência, lide com o requisito de mapeamento de certificados NPS e crie um fluxo de trabalho de revogação de certificados desde o primeiro dia. O caso de negócio é simples: elimina palavras-passe de WiFi partilhadas, obtém registos de autenticação por dispositivo e por utilizador, satisfaz os requisitos de segurança sem fios PCI-DSS e ISO 27001 e reduz os custos operacionais de TI na gestão de credenciais de WiFi numa grande infraestrutura.Se está a planear uma implementação e deseja compreender como a plataforma de WiFi de convidados e analítica da Purple se enquadra na arquitetura da sua rede corporativa, visite purple.ai. Temos guias detalhados sobre integração com o Microsoft Entra ID, arquitetura 802.1X e design de redes de convidados para hotelaria, retalho e ambientes do setor público. Obrigado por nos ouvir. Até à próxima.