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

COMO UTILIZAR O MICROSOFT INTUNE PARA ENVIAR CERTIFICADOS DE WIFI PARA DISPOSITIVOS Uma Apresentação de Informação sobre WiFi Intelligence da Purple Enterprise [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Bem-vindo de volta. Falo hoje em nome da Purple, a plataforma de WiFi intelligence 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 Intune: a implementação automatizada de certificados para autenticação WiFi 802.1X. Se gere o WiFi numa rede de hotéis, numa cadeia de retalho, num estádio ou numa infraestrutura do setor público, conhece bem o problema que vou descrever. Tem centenas ou milhares de dispositivos geridos. Quer que eles se liguem ao seu WiFi corporativo de forma automática e segura, sem que os utilizadores tenham de introduzir palavras-passe e sem que a equipa de TI tenha de intervir 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. [APROFUNDAMENTO TÉCNICO — 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 este se autentique antes de obter qualquer acesso à rede. A comunicação de autenticação ocorre entre três partes: o dispositivo — designado por suplicante —, o seu ponto de acesso WiFi, que funciona como autenticador, e o seu servidor RADIUS, que é o servidor de autenticação que toma a decisão final. Ora, 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. Sem palavras-passe envolvidas. Sem credenciais que possam ser alvo de phishing. É este o nosso objetivo. 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 Enrollment 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 (CSR), envia-o para a sua Autoridade de Certificação (CA) através 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. Esta é a abordagem mais segura e é recomendada para ambientes BYOD e implementações de alta segurança. Com o 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 — não requer 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 implementações empresariais, recomendo o SCEP para ambientes BYOD e de dispositivos mistos, e o PKCS onde tem uma frota homogénea de dispositivos Windows propriedade da empresa e deseja minimizar a complexidade da infraestrutura. Agora, vamos falar sobre a sequência de implementação — porque a ordem importa e errar aqui é a causa mais comum de falhas nas implementações. 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 nativo na nuvem, o Intune Cloud PKI da Microsoft está agora geralmente disponível e elimina totalmente o requisito de CA local. O modelo precisa das extensões de utilização de chave corretas: 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 fidedigno. Antes de qualquer dispositivo poder validar o certificado do servidor RADIUS, precisa de confiar na CA que o emitiu. Cria um perfil de configuração de Certificado Fidedigno no Intune, carrega o certificado da CA raiz e atribui-o aos seus grupos de dispositivos. Isto 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 será 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 se pode ligar 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 encontra-se 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 fidedignidade do servidor — é aqui que 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 criou no passo três. Passo cinco: atribua tudo aos grupos certos 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 dos perfis. Uma implementação bem-sucedida mostra 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 reforçou os requisitos de mapeamento de certificados. Se estiver a utilizar certificados de dispositivo 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 o thumbprint do certificado. Isto não acontece automaticamente — 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 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: lacunas na cadeia de certificados. O dispositivo precisa de confiar em todos os certificados da cadeia, desde a CA raiz até ao certificado do servidor RADIUS. Se o certificado do seu servidor RADIUS foi emitido por uma CA 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 do perfil. Os perfis do Intune não chegam aos dispositivos instantaneamente. Numa infraestrutura de grande dimensão, pode demorar 15 a 30 minutos para que os perfis se propaguem após a atribuição. Não teste imediatamente após a criação dos 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 falhará silenciosamente em algumas plataformas. Erro três: revogação de certificados BYOD. Quando um dispositivo é desassociado do 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 corretamente e garanta que o seu servidor RADIUS está a verificar a CRL ou o OCSP em cada autenticação. Este é um requisito de conformidade sob estruturas como o PCI DSS, que exige que os mecanismos de controlo de acesso sejam revogados prontamente quando já não forem 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 do PCI DSS relativo a controlos de acesso à rede e o Requisito 8.6 relativo a 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 corporativo deve estar numa VLAN e SSID completamente separadas 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, captura de consentimento, analítica — enquanto a sua rede corporativa gerida pelo Intune lida com os 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 do 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 principal — raiz fidedigna, certificado de cliente, perfil de WiFi — é consistente. E quanto aos dispositivos pessoais num programa BYOD? O SCEP é o seu 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 reside no 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 operam 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 de WiFi através do Intune é um processo de cinco etapas — configuração da CA, implementação da raiz fidedigna, 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 corporativas mais simples. Acerte na sequência, trate do 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 as palavras-passe de WiFi partilhadas, obtém registos de autenticação por dispositivo e por utilizador, cumpre os requisitos de segurança sem fios PCI DSS e ISO 27001 e reduz a sobrecarga de TI na gestão de credenciais de WiFi em todo o parque de dispositivos. Se está a planear uma implementação e deseja compreender como a plataforma de WiFi para convidados e analítica da Purple se enquadra na arquitetura de rede da sua empresa, visite purple.ai. Temos guias detalhados sobre a integração com o Azure Entra ID, arquitetura 802.1X e design de redes de convidados para os setores da hotelaria, retalho e setor público. Obrigado por nos ouvir. Até à próxima.