Como revogar o acesso WiFi quando um colaborador sai

Bem-vindo ao Purple Technical Briefing. Eu sou o seu anfitrião e hoje vamos abordar uma das falhas mais comuns no processo de offboarding das empresas: o que acontece realmente ao acesso WiFi quando um funcionário sai? Parece simples. Alguém entrega o seu crachá, os RH fecham a sua conta e segue-se em frente. Mas se a sua rede ainda funciona com uma palavra-passe WPA2 partilhada, essa pessoa saiu pela porta sabendo a palavra-passe. E a menos que a altere para toda a gente, ela pode voltar a ligar-se a partir do parque de estacionamento. Este é o problema que vamos resolver hoje. Vamos abordar os três modelos credíveis para a revogação de WiFi por utilizador, analisar uma checklist de revogação para o próprio dia e explicar exatamente o que um auditor de ISO 27001 ou SOC 2 espera ver nos seus registos. Vamos a isso. Secção um: porque é que as palavras-passe partilhadas são a ferramenta errada para o trabalho. O WPA2-Personal, a configuração padrão de um router doméstico, utiliza uma única chave pré-partilhada. Todos na rede conhecem a mesma palavra-passe. Quando uma pessoa sai, essa palavra-passe continua a ser válida no seu telemóvel, no seu computador portátil, em qualquer dispositivo que alguma vez tenha ligado. A única forma de revogar o seu acesso é alterar a palavra-passe de toda a rede e redistribuí-la a todos os utilizadores e dispositivos restantes. Num hotel com 200 funcionários, isto significa atualizar todos os terminais de ponto de venda, todos os computadores do back-office, todos os telemóveis dos gerentes. Numa cadeia de retalho com 50 lojas, significa uma implementação coordenada em todos os locais. O custo operacional é elevado, a interrupção é real e a janela entre o último dia de quem sai e a rotação concluída é uma verdadeira lacuna de segurança. O PCI DSS, o padrão da indústria de cartões de pagamento, exige que altere as credenciais partilhadas sempre que o pessoal que as conhece sai. Por isso, se as suas caixas registadoras estiverem na mesma rede que o WiFi dos seus funcionários, a saída de um colaborador gera uma obrigação de conformidade, não apenas uma recomendação de boas práticas. A causa principal é simples: uma palavra-passe partilhada não tem nenhuma identidade associada. A rede não consegue distinguir entre um funcionário atual e um antigo funcionário. Para corrigir isso, precisa de credenciais por utilizador. Secção dois: os três modelos que funcionam realmente. O modelo um é o 802.1X com autenticação baseada em certificados EAP-TLS. Este é o padrão de excelência para a segurança WiFi empresarial. Neste modelo, cada utilizador ou dispositivo possui um certificado digital único emitido pela sua Autoridade de Certificação, ou CA. Quando se ligam ao WiFi, o servidor RADIUS valida esse certificado criptograficamente. O certificado está associado a uma identidade, não a uma palavra-passe. Para revogar o acesso, revoga o certificado ao nível da CA. O servidor RADIUS verifica o estado de revogação em tempo real utilizando o OCSP (Online Certificate Status Protocol). Quando marca um certificado como revogado, na próxima vez que esse dispositivo tentar autenticar-se, o servidor RADIUS consulta o recetor OCSP, recebe uma resposta de revogação e envia um Access-Reject para o ponto de acesso. O dispositivo fica fora da rede segundos após a tentativa de autenticação seguinte. Para sessões ativas, utiliza o RADIUS Change of Authorisation, ou CoA, para terminar a sessão existente imediatamente. Combinados, o OCSP e o CoA significam que pode revogar o acesso WiFi de um colaborador que sai em menos de um minuto, com um registo de auditoria completo nos seus logs de RADIUS. O desafio com o EAP-TLS é a sobrecarga de PKI. Precisa de uma Autoridade de Certificação, de um mecanismo para emitir certificados para os dispositivos, normalmente através de um MDM como o Microsoft Intune, e de um processo para os revogar. Para organizações com uma infraestrutura de identidade e MDM madura, esta é a resposta certa. Para equipas mais pequenas ou ambientes com dispositivos IoT que não suportam autenticação por certificado, necessita de uma abordagem diferente. O modelo dois é o iPSK, Identity Pre-Shared Key. A Cisco chama-lhe iPSK, a Ruckus chama-lhe DPSK, a Aruba chama-lhe MPSK, mas o conceito é o mesmo: cada utilizador ou dispositivo recebe uma palavra-passe única, embora todos se liguem ao mesmo SSID. O servidor RADIUS mapeia cada chave única para uma identidade específica e, opcionalmente, para uma VLAN específica. Quando elimina essa chave da base de dados do RADIUS, o dispositivo deixa de se poder autenticar. O raio de impacto de uma saída é de exatamente uma pessoa. As chaves de todos os outros utilizadores permanecem válidas. O iPSK é particularmente adequado para ambientes com tipos de dispositivos mistos. Dispositivos IoT, terminais de ponto de venda e hardware legado que não suporta certificados 802.1X podem todos utilizar iPSK. É também mais simples de operar do que uma implementação completa de PKI, tornando-o a escolha certa para organizações do mercado médio que necessitam de revogação por utilizador sem a sobrecarga de infraestrutura. O tempo de revogação para o iPSK é normalmente de alguns minutos, não de segundos. A eliminação da chave propaga-se para o servidor RADIUS, mas as sessões ativas podem persistir até que o dispositivo se volte a autenticar ou até que envie um pacote CoA para forçar a desligação. O modelo três é o desaprovisionamento orientado por SCIM. SCIM significa System for Cross-domain Identity Management. É um padrão aberto, definido no RFC 7643 e RFC 7644, que permite ao seu fornecedor de identidade enviar eventos do ciclo de vida do utilizador para sistemas a jusante em tempo real. Eis como funciona na prática. O seu fornecedor de identidade, quer seja o Microsoft Entra ID, Okta ou Google Workspace, é a fonte de verdade autoritária para as contas de utilizador. Quando os Recursos Humanos desativam a conta de um colaborador no fornecedor de identidade, o SCIM envia um pedido a todos os sistemas ligados, incluindo a sua plataforma de gestão de WiFi. A Purple liga-se ao seu fornecedor de identidade através de SCIM. No momento em que desativa um utilizador no Entra ID, Okta ou Google Workspace, a Purple recebe o evento SCIM e revoga as suas credenciais de WiFi na próxima autenticação. O evento é registado com um carimbo de data/hora, a identidade do utilizador e a ação tomada. Essa entrada de registo é exatamente o que um auditor da ISO 27001 necessita de ver. O SCIM não substitui o 802.1X ou o iPSK. Fica posicionado acima deles. O SCIM gere o ciclo de vida da identidade; o protocolo de autenticação trata da aplicação das regras de rede. A combinação de SCIM com 802.1X oferece-lhe uma revogação automática e em tempo real com um registo de auditoria completo e zero passos manuais. Secção três: a lista de verificação para revogação no próprio dia. Quando chega o último dia de um colaborador, esta é a sequência que a sua equipa de TI deve seguir. Passo um: desativar a conta no seu fornecedor de identidade. Este é o gatilho para tudo o resto. No Microsoft Entra ID, defina a conta como desativada. No Okta, desative o utilizador. No Google Workspace, suspenda a conta. Passo dois: se estiver a executar o SCIM, verifique se o evento de desprovisionamento foi acionado. Verifique os seus registos de SCIM ou a sua plataforma de gestão de WiFi para encontrar o evento correspondente. Se o SCIM não estiver implementado, revogue manualmente o certificado na sua CA ou elimine a chave iPSK da sua base de dados RADIUS. Passo três: envie um RADIUS CoA para terminar qualquer sessão WiFi ativa. A maioria dos servidores RADIUS empresariais, e plataformas como a Purple, podem fazer isto automaticamente num evento de desprovisionamento. Se o estiver a fazer manualmente, utilize a interface CoA do seu servidor RADIUS para desligar o dispositivo do utilizador por endereço MAC ou ID de sessão. Passo quatro: confirme que não restam sessões ativas. Verifique o painel do seu controlador WiFi. No Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet, deverá conseguir pesquisar por nome de utilizador ou dispositivo e confirmar que existem zero associações ativas. Passo cinco: arquive a entrada do registo de auditoria. Exporte ou marque o registo de autenticação RADIUS, o registo de eventos SCIM e o registo CoA para o utilizador e data relevantes. Guarde-os na sua plataforma de ITSM ou de gestão de informações e eventos de segurança. O controlo A.9.2.6 do Anexo A da ISO 27001 exige que remova ou ajuste os direitos de acesso de todos os funcionários e prestadores de serviços após a cessação de funções. O seu registo é a prova. Passo seis: se estiver a executar WPA2 PSK partilhado e nada do que foi acima descrito se aplicar, rode a palavra-passe. Coordene a implementação em todos os locais e dispositivos antes do último dia do colaborador, se possível, ou imediatamente a seguir. Secção quatro: o que o auditor espera. A ISO 27001 e o SOC 2 exigem que demonstre que o acesso é removido prontamente quando o emprego termina. Especificamente para o WiFi, os auditores procuram quatro coisas. Primeiro, um procedimento de offboarding documentado que inclua explicitamente o acesso à rede. Segundo, provas de que o procedimento foi seguido para uma amostra de colaboradores que saíram, tipicamente dez a vinte e cinco indivíduos selecionados nos últimos doze meses. Terceiro, um registo que mostre a marca temporal da desativação da conta e a marca temporal da revogação do acesso ao WiFi, com o intervalo entre eles claramente visível. Quarto, a confirmação de que nenhuma conta de ex-colaborador mostra sessões de WiFi ativas. Se estiver a utilizar WPA2 com PSK partilhada, não conseguirá apresentar provas para os pontos três e quatro. Não existe um registo por utilizador. O melhor que pode fazer é mostrar a data de rotação da palavra-passe e argumentar que esta foi concluída antes ou no último dia do colaborador cessante. Os auditores rejeitam cada vez mais esta abordagem. Se estiver a utilizar 802.1X com SCIM, o registo é automático. A Purple regista cada evento de desaprovisionamento de SCIM com um carimbo de data/hora UTC, a origem do fornecedor de identidade, o identificador exclusivo do utilizador e a ação resultante. Trata-se de um registo limpo e auditável. Secção cinco: armadilhas de implementação e como as evitar. O erro mais comum é assumir que desativar uma conta no fornecedor de identidade é suficiente. Não é, a menos que a sua plataforma de WiFi esteja ligada a esse fornecedor de identidade via SCIM ou uma integração em tempo real semelhante. Sem essa ligação, o sistema de WiFi não tem como saber que a conta foi desativada. A segunda armadilha é o cache de certificados. Mesmo com OCSP, os servidores RADIUS guardam em cache as respostas válidas por um período configurável, normalmente de 15 a 60 minutos. Se revogar um certificado e o servidor RADIUS tiver uma resposta válida em cache, o dispositivo poderá continuar a autenticar-se até que o cache expire. Defina o TTL do cache OCSP para 15 minutos ou menos para ambientes de alta segurança. A terceira armadilha é esquecer as sessões ativas. A revogação de credenciais impede novas autenticações, mas não termina uma sessão de WiFi existente. Envie sempre um RADIUS CoA após a revogação de credenciais para desligar o dispositivo imediatamente. A quarta armadilha são os dispositivos IoT e partilhados. Um dispositivo registado na identidade de um colaborador cessante pode ser uma estação de trabalho partilhada ou um equipamento operacional. Antes de revogar, confirme se o dispositivo é pessoal e não partilhado. Se for partilhado, volte a registá-lo numa conta de serviço antes de revogar as credenciais do colaborador. Secção seis: perguntas rápidas. Pergunta: com que rapidez se pode revogar o acesso WiFi baseado em certificados? Com OCSP e RADIUS CoA, em menos de 60 segundos a partir do momento em que revoga o certificado na AC (Autoridade de Certificação). A verificação OCSP ocorre na tentativa de autenticação seguinte. O CoA termina a sessão ativa imediatamente. Pergunta: o SCIM funciona com todo o hardware de WiFi? O SCIM opera na camada de gestão de identidade, não na camada de hardware. A Purple é agnóstica em termos de hardware e funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A integração SCIM é feita com a Purple e não diretamente com os pontos de acesso. Pergunta: e se não tivermos MDM e não conseguirmos implementar certificados? A iPSK é a sua resposta. Oferece-lhe a revogação por utilizador sem exigir uma infraestrutura de certificados. A Purple pode gerir chaves iPSK e ligar-se ao seu fornecedor de identidade para automatizar o ciclo de vida. Resumo e próximos passos. A mensagem principal é esta: se não consegue revogar o acesso WiFi a uma pessoa sem afetar todas as outras, tem um problema de credenciais partilhadas. A solução passa por credenciais por utilizador, sejam certificados via 802.1X EAP-TLS ou chaves únicas via iPSK, combinados com a desprovisionação orientada por SCIM para automatizar a revogação no momento em que os RH atuam. A Purple liga-se ao Microsoft Entra ID, Okta e Google Workspace via SCIM, funciona em 80.000 locais ativos e regista todos os eventos de desprovisionação para auditoria. Se se está a preparar para a ISO 27001 ou SOC 2, ou se quer simplesmente fechar a lacuna de quem sai da empresa antes que se torne um incidente, é por aí que deve começar. Para uma análise técnica detalhada sobre a revogação de certificados e OCSP, consulte o nosso guia sobre OCSP e revogação de certificados para autenticação WiFi. Para uma perspetiva mais ampla sobre a automatização de processos de entrada, mudança e saída de colaboradores (joiner-mover-leaver), consulte o nosso guia de segurança WiFi empresarial. Obrigado por ouvir o Purple Technical Briefing.