Como revogar o acesso WiFi quando um funcionário sai da empresa

Bem-vindo a esta instrução técnica sobre como revogar o acesso WiFi quando um funcionário sai da empresa. O problema geralmente parece menor do que realmente é. Alguém sai na sexta-feira. Seu gerente desativa o e-mail e recolhe o notebook. No entanto, seu telefone ou dispositivo pessoal ainda consegue se conectar ao WiFi da equipe na segunda-feira. Em um hotel, isso pode colocar um ex-funcionário perto de sistemas operacionais. Em um estabelecimento de varejo, pode dar acesso a uma rede de funcionários em várias lojas. Em um estádio ou centro de convenções, pode tornar um dia de evento movimentado mais difícil de gerenciar. A questão imediata não é se quem saiu sabe uma senha. É se o seu WiFi consegue identificar essa pessoa como uma identidade distinta e negar essa identidade sem interromper todos os outros. Uma única senha compartilhada WPA2 não consegue fazer isso. Cada pessoa tem a mesma credencial. Uma vez que essa senha foi compartilhada com quem saiu, a rede não tem uma maneira limpa de distinguir essa pessoa de todos os funcionários autorizados que também a conhecem. A resposta prática é uma rotação de senha em toda a empresa, seguida de uma atualização em todos os dispositivos aprovados. Isso é operacionalmente caro, gera chamados de suporte e frequentemente é adiado. Não é um controle de desligamento confiável para o mesmo dia em uma propriedade de locais distribuídos. Existem três padrões confiáveis. O primeiro é o 802.1X por pessoa com EAP-TLS. O segundo é o iPSK, às vezes chamado de chave pré-compartilhada individual. O terceiro é o desprovisionamento impulsionado pelo provedor de identidade usando SCIM. Você pode combinar esses padrões. A escolha central de design ainda é a mesma: tornar a credencial de acesso atribuível a uma pessoa ou a um dispositivo gerenciado e, em seguida, tornar a remoção um evento controlado e registrado. Vamos começar com o 802.1X e o EAP-TLS. O IEEE 802.1X é a estrutura de controle de acesso à rede. Ele separa o dispositivo que solicita a conexão, o autenticador na borda da rede e o serviço de autenticação de back-end. O EAP-TLS é um método de Protocolo de Autenticação Extensível que usa certificados para autenticação mútua e derivação de chave. Em termos simples, o dispositivo comprova a posse de um certificado e a rede prova sua própria identidade na mesma troca de autenticação. Este modelo se adequa a dispositivos gerenciados de funcionários e redes de alta garantia. A ação para quem sai não é alterar uma senha compartilhada. É desativar a identidade e revogar, negar ou remover o direito do certificado de se autenticar. O design do seu RADIUS e da validação de certificados deve ser capaz de reconhecer essa alteração quando um dispositivo se autentica. Não confunda a expiração do certificado com a revogação do certificado. A expiração é programada. A revogação é a ação de desligamento que você realiza antes da data de término programada.O momento é fundamental. O acesso WiFi baseado em certificado é verificado na autenticação. Portanto, seu objetivo prático é claro: impedir que o certificado seja bem-sucedido na próxima tentativa de autenticação e testar esse resultado. Se o funcionário já tiver uma sessão ativa, decida separadamente se a sua política exige a desconexão da sessão. Essa é uma escolha de operações de rede, não um substituto para a revogação da identidade. Também leve em conta o comportamento de reconexão rápida e sessões em cache durante o seu processo de design e teste. Um design que parece correto em um laboratório pode criar um ponto cego se o seu caminho de autenticação de produção não validar a alteração conforme pretendido. A lista de verificação operacional para EAP-TLS é simples. Primeiro, confirme o registro de identidade da pessoa e o último horário de trabalho. Segundo, desative a identidade de origem. Terceiro, revogue ou negue o certificado relevante de acordo com a sua autoridade de certificação e processo RADIUS. Quarto, remova ou encerre uma sessão ativa se a sua política exigir. Quinto, tente uma nova conexão com o dispositivo gerenciado do ex-funcionário ou um equivalente controlado. Por fim, registre a solicitação, a alteração, o resultado, o horário e o proprietário responsável. O segundo padrão é o iPSK. Em vez de uma senha compartilhada por toda a força de trabalho, cada pessoa ou dispositivo tem uma chave distinta na mesma rede WiFi de funcionários. Isso torna a remoção direcionada. Exclua a chave associada ao funcionário demitido, confirme que uma nova tentativa de adesão falha e mantenha todas as outras chaves inalteradas. O iPSK pode funcionar bem onde você tem dispositivos que não podem usar certificados, onde um programa de dispositivos gerenciados ainda está em desenvolvimento ou onde você precisa de uma transição prática para deixar de usar uma única senha compartilhada. O iPSK não é o mesmo que uma senha genérica de equipe com um nome diferente. A chave deve estar vinculada a um registro de identidade ou dispositivo. Mantenha um inventário do proprietário da chave, data de emissão, associação de dispositivo ou pessoa, função de rede e status de remoção. Torne a chave suficientemente distinta para que um evento de exclusão possa ser rastreado até o funcionário demitido. Se o mesmo iPSK for reutilizado por uma equipe, grupo de prestadores de serviços ou turno, você recriou o problema do segredo compartilhado em um recipiente menor. O terceiro padrão é o desprovisionamento orientado por SCIM. O SCIM é um protocolo padrão baseado em HTTP para provisionamento e gerenciamento de dados de identidade entre sistemas. Em um bom processo de admissão, movimentação e desligamento, o RH ou a TI desativa a conta no seu provedor de identidade, o estado desativado flui para o serviço de acesso WiFi e uma autenticação de WiFi posterior é negada. A Purple vincula o acesso WiFi ao provedor de identidade por meio de SCIM. Os provedores de identidade relevantes são Microsoft Entra ID, Okta e Google Workspace. O benefício operacional não é mágica. É uma única fonte de verdade: o evento que encerra o emprego também inicia a remoção do WiFi. Trate o SCIM como um caminho de controle, não como um slogan. Você precisa de um identificador exclusivo que mapeie a conta do provedor de identidade ao registro de acesso WiFi. Você precisa de um evento de desativação acordado. Você precisa saber qual erro o serviço receptor produz quando uma solicitação de desativação falha. E você precisa de uma identidade de teste que comprove que seu monitoramento captura essa falha. Agora mude do design para a implementação. Comece com um inventário de acesso. Liste cada rede WiFi corporativa, seu modo de segurança, a fonte de identidade, o caminho RADIUS se houver, a autoridade de certificação se houver, o registro do proprietário do iPSK se houver, a capacidade de desconexão de sessão e o destino do log. Faça isso por grupo de locais, não como uma lista única e unificada da empresa. Um hotel, uma loja de rua e um estádio podem compartilhar a mesma política enquanto utilizam diferentes equipes operacionais e hardwares. Em seguida, escolha o controle que remove a maior parte do trabalho manual do processo de desligamento de funcionários. Para dispositivos corporativos gerenciados, use 802.1X com EAP-TLS onde sua autoridade de certificação, design RADIUS e gerenciamento de dispositivos puderem oferecer suporte. Para ambientes mistos e dispositivos que não podem usar certificados, use iPSK apenas quando cada chave tiver um proprietário exclusivo e puder ser excluída. Para um ambiente que já utiliza Microsoft Entra ID, Okta ou Google Workspace, use o provisionamento impulsionado por SCIM para fazer da desativação da conta o gatilho para a remoção do acesso WiFi. A Purple pode conectar esse evento de identidade ao status de acesso WiFi. Não adicione um segundo ticket manual, a menos que seja um caminho de exceção. Crie um roteiro de desligamento para o mesmo dia. O RH confirma o horário de término. O proprietário da identidade desativa a conta. O proprietário da rede confirma que o certificado correspondente, iPSK ou registro de acesso WiFi não é mais válido. A equipe de operações decide se uma sessão ativa precisa ser desconectada. Um testador designado realiza uma nova tentativa de autenticação. O caso é encerrado apenas quando o resultado é registrado. Isso é deliberadamente simples. É também a parte que um auditor pode reconstruir. Para evidências de ISO 27001 ou SOC 2, retenha uma cadeia pequena, mas completa: a solicitação de desligamento autorizada, a alteração no provedor de identidade, a alteração no WiFi, o resultado da verificação, os registros de data e hora e o responsável por cada etapa. Evite coletar mais dados pessoais do que o controle necessita. Registros de acesso podem ser dados pessoais, portanto, inclua-os em suas decisões de retenção e controle de acesso. Se o WiFi corporativo puder impactar sistemas de pagamento, discuta o escopo e a segmentação com a equipe responsável pelo PCI DSS, em vez de tratar a revogação de WiFi como uma declaração de conformidade isolada. Fique atento a quatro modos de falha. Primeiro, uma senha compartilhada ainda está em uso em um SSID esquecido. Segundo, o registro de WiFi está associado a um endereço de e-mail mutável em vez de uma identidade durável. Terceiro, um evento de desativação chega ao provedor de identidade, mas não ao serviço de acesso WiFi. Quarto, você testa apenas o status do painel de controle e não uma tentativa real de um novo login. Cada modo de falha é evitável se você inventariar, monitorar e testar o controle. Perguntas rápidas. Uma senha WPA2 compartilhada pode ser revogada para apenas uma pessoa que está saindo? Não. Você deve rotacioná-la para todos ou substituí-la por um controle por identidade. Com que rapidez o acesso EAP-TLS pode ser revogado? Na próxima autenticação, desde que o seu design de validação de certificado e RADIUS reconheça a revogação. O SCIM remove uma sessão ativa? Não por si só. Trate o controle de sessão como uma decisão operacional separada. O iPSK é adequado para todos os dispositivos? Não. É um modelo prático de chave vinculado à identidade onde a autenticação por certificado não é apropriada. O próximo passo é uma breve revisão de design. Escolha uma rede WiFi de funcionários. Acompanhe um evento de desligamento desde a notificação do RH até a autenticação negada. Encontre a etapa manual. Depois, remova-a. Uma credencial de WiFi deve expirar quando o funcionário sai, não no próximo projeto de rotação de senhas.