Como revogar o acesso WiFi quando um funcionário sai

Bem-vindo ao Purple Technical Briefing. Eu sou o seu anfitrião e hoje estamos abordando uma das lacunas mais comuns no desligamento corporativo: o que realmente acontece com o acesso WiFi quando um funcionário sai? Parece simples. Alguém entrega o crachá, o RH fecha a conta e você segue em frente. Mas se a sua rede ainda funciona com uma senha WPA2 compartilhada, essa pessoa saiu pela porta ainda sabendo a senha. E, a menos que você a altere para todos, ela poderá se reconectar a partir do estacionamento. Esse é o problema que estamos resolvendo hoje. Abordaremos os três modelos viáveis para revogação de WiFi por usuário, passaremos por um checklist de revogação no mesmo dia e explicaremos exatamente o que um auditor da ISO 27001 ou SOC 2 espera ver em seus logs. Vamos começar. Seção um: por que senhas compartilhadas são a ferramenta errada para o trabalho. O WPA2-Personal, a configuração padrão de roteadores domésticos, usa uma única chave pré-compartilhada. Todos na rede sabem a mesma senha. Quando uma pessoa sai, essa senha ainda é válida em seu telefone, em seu laptop, em qualquer dispositivo que ela já tenha conectado. A única maneira de revogar seu acesso é alterar a senha de toda a rede e redistribuí-la para todos os usuários e dispositivos restantes. Em um hotel com 200 funcionários, isso significa atualizar cada terminal de ponto de venda, cada PC de back-office, cada telefone de gerente. Em uma rede de varejo com 50 lojas, significa uma implementação coordenada em cada local. O custo operacional é alto, a interrupção é real e a janela entre o último dia do funcionário que sai e a conclusão da rotação é uma lacuna de segurança real. O PCI DSS, o padrão da indústria de cartões de pagamento, exige que você altere as credenciais compartilhadas sempre que funcionários com conhecimento delas saírem. Portanto, se os seus caixas estiverem na mesma rede que o WiFi da sua equipe, a saída de um funcionário gera uma obrigação de conformidade, não apenas uma recomendação de melhores práticas. A causa raiz é simples: uma senha compartilhada não tem identidade associada a ela. A rede não consegue distinguir entre um funcionário atual e um ex-funcionário. Para corrigir isso, você precisa de credenciais por usuário. Seção dois: os três modelos que realmente funcionam. O modelo um é o 802.1X com autenticação baseada em certificado EAP-TLS. Este é o padrão ouro para a segurança de WiFi corporativo. Neste modelo, cada usuário ou dispositivo possui um certificado digital exclusivo emitido pela sua Autoridade Certificadora, ou CA. Quando eles se conectam ao WiFi, o servidor RADIUS valida esse certificado criptograficamente. O certificado está vinculado a uma identidade, não a uma senha. Para revogar o acesso, você revoga o certificado no nível da CA. O servidor RADIUS verifica o status de revogação em tempo real usando o OCSP, o Online Certificate Status Protocol. Quando você marca um certificado como revogado, na próxima vez que esse dispositivo tentar se autenticar, o servidor RADIUS consulta o respondedor OCSP, recebe uma resposta de revogado e envia um Access-Reject para o ponto de acesso. O dispositivo fica fora da rede segundos após a próxima tentativa de autenticação. Para sessões ativas, você usa a Alteração de Autorização do RADIUS, ou CoA, para encerrar a sessão existente imediatamente. Combinados, o OCSP e o CoA significam que você pode revogar o acesso WiFi de um funcionário que está saindo em menos de um minuto, com uma trilha de auditoria completa em seus logs do RADIUS. O desafio com o EAP-TLS é a sobrecarga de PKI. Você precisa de uma Autoridade Certificadora, um mecanismo para emitir certificados para dispositivos, normalmente por meio de um MDM como o Microsoft Intune, e um processo para revogá-los. Para organizações com um MDM e infraestrutura de identidade maduros, esta é a resposta certa. Para equipes menores ou ambientes com dispositivos IoT que não suportam autenticação por certificado, você precisa de uma abordagem diferente. O modelo dois é o iPSK, Identity Pre-Shared Key. A Cisco o chama de iPSK, a Ruckus o chama de DPSK, a Aruba o chama de MPSK, mas o conceito é o mesmo: cada usuário ou dispositivo recebe uma senha exclusiva, embora todos se conectem ao mesmo SSID. O servidor RADIUS mapeia cada chave exclusiva para uma identidade específica e, opcionalmente, para uma VLAN específica. Quando você exclui essa chave do banco de dados do RADIUS, o dispositivo não pode mais se autenticar. O raio de impacto de um funcionário que sai é de exatamente uma pessoa. As chaves de todos os outros 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 suportam certificados 802.1X podem usar o iPSK. Também é mais simples de operar do que uma implantação completa de PKI, tornando-o a escolha certa para organizações de médio porte que precisam de revogação por usuário sem a sobrecarga de infraestrutura. O tempo de revogação para o iPSK é normalmente de alguns minutos, não segundos. A exclusão da chave se propaga para o servidor RADIUS, mas as sessões ativas podem persistir até que o dispositivo se autentique novamente ou até que você envie um pacote CoA para forçar a desconexão. O modelo três é o desprovisionamento orientado por SCIM. SCIM significa System for Cross-domain Identity Management. É um padrão aberto, definido nas RFC 7643 e RFC 7644, que permite ao seu provedor de identidade enviar eventos de ciclo de vida do usuário para sistemas downstream em tempo real. Veja como funciona na prática. Seu provedor de identidade, seja o Microsoft Entra ID, o Okta ou o Google Workspace, é a fonte autoritativa de verdade para as contas de usuário. Quando o RH desativa a conta de um funcionário que está saindo no provedor de identidade, o SCIM envia uma solicitação para cada sistema conectado, incluindo sua plataforma de gerenciamento de WiFi. A Purple se conecta ao seu provedor de identidade via SCIM. No momento em que você desativa um usuário no Entra ID, Okta ou Google Workspace, a Purple recebe o evento SCIM e revoga suas credenciais de WiFi na próxima autenticação. O evento é registrado com um carimbo de data/hora, a identidade do usuário e a ação realizada. Essa entrada de log é exatamente o que um auditor da ISO 27001 precisa ver. O SCIM não substitui o 802.1X ou o iPSK. Ele fica acima deles. O SCIM lida com o ciclo de vida da identidade; o protocolo de autenticação lida com a aplicação na rede. A combinação de SCIM mais 802.1X oferece revogação automática em tempo real com uma trilha de auditoria completa e zero etapas manuais. Seção três: o checklist de revogação no mesmo dia. Quando chega o último dia de um funcionário que está saindo, aqui está a sequência que sua equipe de TI deve seguir. Etapa um: desative a conta em seu provedor de identidade. Este é o gatilho para todo o resto. No Microsoft Entra ID, defina a conta como desativada. No Okta, desative o usuário. No Google Workspace, suspenda a conta. Etapa dois: se você estiver executando o SCIM, verifique se o evento de desprovisionamento foi acionado. Verifique seus logs do SCIM ou sua plataforma de gerenciamento de WiFi para o evento correspondente. Se o SCIM não estiver implementado, revogue manualmente o certificado em sua CA ou exclua a chave iPSK do seu banco de dados RADIUS. Etapa três: envie um CoA do RADIUS para encerrar qualquer sessão WiFi ativa. A maioria dos servidores RADIUS corporativos, e plataformas como a Purple, podem fazer isso automaticamente em um evento de desprovisionamento. Se estiver fazendo isso manualmente, use a interface CoA do seu servidor RADIUS para desconectar o dispositivo do usuário por endereço MAC ou ID de sessão. Etapa 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, você deve ser capaz de pesquisar por nome de usuário ou dispositivo e confirmar zero associações ativas. Etapa cinco: arquive a entrada do log de auditoria. Exporte ou marque o log de autenticação do RADIUS, o log de eventos do SCIM e o log do CoA para o usuário e data relevantes. Armazene-os em seu ITSM ou plataforma de gerenciamento de informações e eventos de segurança (SIEM). O controle A.9.2.6 do Anexo A da ISO 27001 exige que você remova ou ajuste os direitos de acesso de todos os funcionários e prestadores de serviços após o desligamento. Seu log é a evidência. Etapa seis: se você estiver executando o PSK compartilhado WPA2 e nada do que foi mencionado acima se aplicar, rotacione a senha. Coordene a implementação em todos os locais e dispositivos antes do último dia do funcionário que está saindo, se possível, ou imediatamente após. Seção quatro: o que o auditor espera. A ISO 27001 e o SOC 2 exigem que você demonstre que o acesso é removido imediatamente quando o vínculo empregatício termina. Para o WiFi especificamente, os auditores procuram por quatro coisas. Primeiro, um procedimento de desligamento documentado que inclua explicitamente o acesso à rede. Segundo, evidências de que o procedimento foi seguido para uma amostra de funcionários desligados, normalmente de dez a vinte e cinco indivíduos selecionados nos últimos doze meses. Terceiro, um log mostrando o carimbo de data/hora da desativação da conta e o carimbo de data/hora da revogação do acesso WiFi, com o intervalo entre eles claramente visível. Quarto, confirmação de que nenhuma conta de ex-funcionário mostra sessões WiFi ativas. Se você estiver executando o PSK compartilhado WPA2, não poderá produzir evidências para os itens três e quatro. Não há log por usuário. O melhor que você pode fazer é mostrar a data de rotação da senha e argumentar que ela foi concluída antes ou no último dia do funcionário que está saindo. Os auditores rejeitam cada vez mais essa justificativa. Se você estiver executando o 802.1X com SCIM, o log é automatic. A Purple registra cada evento de desprovisionamento do SCIM com um carimbo de data/hora UTC, a origem do provedor de identidade, o identificador exclusivo do usuário e a ação resultante. Esse é um registro limpo e auditável. Seção cinco: armadilhas de implementação e como evitá-las. O erro mais comum é presumir que desativar uma conta no provedor de identidade é suficiente. Não é, a menos que sua plataforma de WiFi esteja conectada a esse provedor de identidade via SCIM ou uma integração semelhante em tempo real. Sem essa conexão, o sistema WiFi não tem como saber que a conta foi desativada. A segunda armadilha é o cache de certificados. Mesmo com o OCSP, os servidores RADIUS armazenam em cache respostas boas por um período configurável, normalmente de 15 a 60 minutos. Se você revogar um certificado e o servidor RADIUS tiver uma resposta boa em cache, o dispositivo poderá continuar a se autenticar 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. Revogar credenciais impede novas autenticações, mas não encerra uma sessão WiFi existente. Sempre envie um CoA do RADIUS após revogar as credenciais para desconectar o dispositivo imediatamente. A quarta armadilha são os dispositivos IoT e compartilhados. Um dispositivo registrado na identidade de um funcionário que está saindo pode ser uma estação de trabalho compartilhada ou um hardware operacional. Antes de revogar, confirme se o dispositivo é pessoal, não compartilhado. Se for compartilhado, registre-o novamente sob uma conta de serviço antes de revogar as credenciais do funcionário que está saindo. Seção seis: perguntas rápidas. Pergunta: com que rapidez o acesso WiFi baseado em certificado pode ser revogado? Com OCSP e CoA do RADIUS, em menos de 60 segundos a partir do momento em que você revoga o certificado na CA. A verificação do OCSP ocorre na próxima tentativa de autenticação. O CoA encerra a sessão ativa imediatamente. Pergunta: o SCIM funciona com todo hardware de WiFi? O SCIM opera na camada de gerenciamento de identidade, não na camada de hardware. A Purple é agnóstica em relação ao hardware e funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A integração do SCIM é com a Purple, não diretamente com os pontos de acesso. Pergunta: e se não tivermos MDM e não pudermos implantar certificados? O iPSK é a sua resposta. Ele oferece revogação por usuário sem exigir infraestrutura de certificados. A Purple pode gerenciar chaves iPSK e se conectar ao seu provedor de identidade para automatizar o ciclo de vida. Resumo e próximas etapas. A mensagem principal é esta: se você não pode revogar o acesso WiFi de uma pessoa sem afetar todas as outras, você tem um problema de credencial compartilhada. A solução são credenciais por usuário, sejam certificados via 802.1X EAP-TLS ou chaves exclusivas via iPSK, combinadas com o desprovisionamento orientado por SCIM para automatizar a revogação no momento em que o RH agir. A Purple se conecta ao Microsoft Entra ID, Okta e Google Workspace via SCIM, opera em 80.000 locais ativos e registra cada evento de desprovisionamento para auditoria. Se você está se preparando para a ISO 27001 ou SOC 2, ou simplesmente deseja fechar a lacuna de desligamento antes que ela se torne um incidente, é por aí que deve começar. Para a análise técnica completa da revogação de certificados e OCSP, consulte nosso guia sobre OCSP e revogação de certificados para autenticação WiFi. Para uma visão mais ampla da automação de admissão, movimentação e desligamento (joiner-mover-leaver), consulte nosso guia de segurança de WiFi corporativo. Obrigado por ouvir o Purple Technical Briefing.