Automatizar a Segurança de WiFi Empresarial: O Guia de Implementação de Certificados SCEP

Bem-vindo a este briefing técnico. Estou aqui para o guiar através do nosso guia mais recente: Automatizar a Segurança de WiFi Empresarial, focando-me especificamente na Implementação de Certificados SCEP. Se gere redes para hotéis, cadeias de retalho ou locais públicos, já sabe que depender de chaves pré-partilhadas ou de simples portais cativos para o acesso dos funcionários é uma enorme vulnerabilidade de segurança. Hoje, falamos sobre o padrão de excelência: autenticação 802.1X utilizando EAP-TLS. Vamos mergulhar na arquitetura. O principal desafio com o EAP-TLS não é o protocolo em si; é a logística de colocar certificados de cliente únicos em milhares de dispositivos — sejam portáteis Windows, iPads ou tablets de ponto de venda. É aqui que entram em jogo as plataformas de Mobile Device Management, ou MDM, como o Microsoft Intune ou o Jamf. Mas como é que se entregam esses certificados de forma segura? Geralmente, tem duas opções: PKCS ou SCEP. Deixe-me ser absolutamente claro nisto: para autenticação WiFi, o que pretende é o SCEP. Trata-se do Simple Certificate Enrollment Protocol. Eis porque é importante. Com o SCEP, o MDM instrui o dispositivo final a gerar a sua própria chave privada localmente. Essa chave permanece bloqueada no hardware seguro do dispositivo. Nunca viaja pela rede. O dispositivo apenas envia um Certificate Signing Request para a sua Autoridade de Certificação através de um gateway, normalmente um servidor NDES. Contraste isso com o PKCS, onde a Autoridade de Certificação gera a chave privada centralmente e a envia pela rede para o dispositivo. Embora o PKCS tenha o seu lugar — por exemplo, para encriptação de e-mail onde necessita de custódia de chaves —, transmitir chaves privadas pela rede é um risco que simplesmente não precisa de correr para a autenticação de rede. Mantenha as chaves no dispositivo. Utilize o SCEP. Now, falemos de implementação. Se há algo que deve reter deste briefing, é esta regra prática: Confiança antes da Autenticação. Não pode simplesmente enviar um perfil de WiFi e esperar que funcione. Existe uma sequência de implementação rigorosa de três passos que deve seguir. Passo um: Implementar o Certificado Trusted Root. Antes de um dispositivo poder solicitar um certificado de cliente, ou confiar no seu servidor RADIUS, tem de confiar na Autoridade de Certificação emissora. Envie este perfil primeiro. Passo dois: Configurar e enviar o Perfil de Certificado SCEP. Isto indica ao dispositivo como comunicar com o gateway SCEP, que formato utilizar para o seu subject name e para que serve realmente o certificado — neste caso, Autenticação de Cliente. Deve associar este perfil ao Trusted Root que implementou no passo um. Passo três: Implementar o Perfil de WiFi 802.1X. É aqui que junta tudo. Especifica o SSID, seleciona WPA3-Enterprise, define o tipo de EAP para EAP-TLS e aponta para o certificado SCEP para autenticação de cliente. Eis um grande erro que vemos constantemente. Um cliente liga-nos e diz: "Os certificados estão no dispositivo, mas o perfil de WiFi mostra um erro no Intune." Quase sempre, trata-se de uma incompatibilidade na segmentação de grupos. Se atribuir o perfil SCEP a um grupo de 'Utilizadores', mas atribuir o perfil de WiFi a um grupo de 'Dispositivos', o MDM não conseguirá resolver a dependência. Corresponda os seus alvos exatamente nos três perfis. Vejamos um cenário do mundo real. Imagine um hotel de 200 quartos. Têm 150 dispositivos iOS geridos para o serviço de limpeza. Atualmente, utilizam uma rede padrão com palavra-passe e os funcionários continuam a partilhar a palavra-passe com os hóspedes. É um pesadelo. Ao migrar para WPA2-Enterprise com EAP-TLS via SCEP, o Diretor de TI elimina totalmente a palavra-passe. Os dispositivos iOS autenticam-se silenciosamente em segundo plano utilizando os seus certificados. Mas o que acontece se um funcionário da limpeza perder um dispositivo ou sair da empresa? Desativar a sua conta do Active Directory não é suficiente, porque o certificado nesse dispositivo ainda é criptograficamente válido. Isto leva-nos a um controlo de segurança crítico: verificação rigorosa da CRL. Deve configurar o seu servidor RADIUS para verificar a Lista de Revogação de Certificados. Se um dispositivo desaparecer, revoga o certificado na CA. O servidor RADIUS deteta a revogação na CRL e bloqueia imediatamente o acesso à rede. Sem uma verificação rigorosa da CRL, a sua postura de segurança está incompleta. Para concluir, a transição para a implementação automatizada de certificados SCEP proporciona um ROI massivo. Verá uma redução de 70 a 80 por cento nos pedidos de suporte relacionados com WiFi, porque os utilizadores não ficam bloqueados nem introduzem palavras-passe incorretamente. Mais importante ainda, elimina o risco de recolha de credenciais, garantindo o cumprimento de quadros de conformidade como o PCI DSS e o GDPR. Automatizar a segurança de WiFi empresarial não se trata apenas de bloquear as coisas; trata-se de tornar o caminho seguro no caminho mais fácil para os seus utilizadores. Obrigado por ouvir e não se esqueça de consultar o guia escrito completo para obter todos os detalhes de configuração passo a passo.