Como revogar o acesso WiFi quando um funcionário sai

Bem-vindo a esta sessão técnica sobre a revogação do acesso WiFi quando um funcionário sai da empresa. O problema parece frequentemente menor do que realmente é. Alguém sai na sexta-feira. O seu gestor desativa o e-mail e recolhe o portátil. No entanto, o seu telemóvel ou dispositivo pessoal ainda consegue ligar-se à Staff WiFi na segunda-feira. Num hotel, isso pode colocar um antigo funcionário perto de sistemas operacionais. Numa rede de retalho, pode dar acesso a uma rede de funcionários em várias lojas. Num estádio ou centro de conferências, pode tornar um dia de evento movimentado mais difícil de gerir. A questão imediata não é se quem saiu sabe uma palavra-passe. É se o seu WiFi consegue identificar essa pessoa como uma identidade distinta e negar essa identidade sem perturbar todos os outros. Uma única frase de acesso WPA2 partilhada não consegue fazer isso. Cada pessoa tem a mesma credencial. Uma vez que essa frase de acesso tenha sido partilhada com alguém que saiu, a rede não tem uma forma limpa de distinguir essa pessoa de todos os funcionários autorizados que também a conhecem. A resposta prática é uma rotação de frases de acesso a nível de toda a empresa, seguida de uma atualização em todos os dispositivos aprovados. Isso é operacionalmente dispendioso, cria pedidos de suporte e é frequentemente adiado. Não é um controlo de desativação credível para o próprio dia num património de locais distribuídos. Existem três padrões credíveis. O primeiro é o 802.1X por pessoa com EAP-TLS. O segundo é o iPSK, por vezes designado por chave individual pré-partilhada. O terceiro é a desativação orientada por fornecedor de identidade utilizando SCIM. Pode combinar estes padrões. A escolha central de design continua a ser a mesma: tornar a credencial de acesso atribuível a uma pessoa ou a um dispositivo gerido, e depois fazer da remoção um evento controlado e registado. Comecemos com o 802.1X e o EAP-TLS. O IEEE 802.1X é a estrutura de controlo de acesso à rede. Separa o dispositivo que solicita a ligação, o autenticador na periferia da rede e o serviço de autenticação de back-end. O EAP-TLS é um método de Extensible Authentication Protocol que utiliza certificados para autenticação mútua e derivação de chaves. Em linguagem simples, o dispositivo prova a posse de um certificado e a rede prova a sua própria identidade na mesma troca de autenticação. Este modelo adequa-se a dispositivos de funcionários geridos e a redes de elevada fiabilidade. A ação para quem sai não é alterar uma palavra-passe partilhada. É desativar a identidade e revogar, negar ou de outra forma remover o direito do certificado de se autenticar. O seu design de validação de certificados e RADIUS 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 é agendada. A revogação é a ação de desativação que toma antes da data de fim agendada. O momento certo é fundamental. O acesso WiFi baseado em certificados é verificado no momento da autenticação. Portanto, o 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 colaborador já tiver uma sessão ativa, decida separadamente se a sua política exige a desconexão da sessão. Esta é uma escolha de operações de rede e não um substituto para a revogação da identidade. Considere também o comportamento de ligação rápida e as sessões em cache durante o seu processo de conceção e teste. Um design que parece correto num 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 registo de identidade da pessoa e a última hora de trabalho. Segundo, desative a identidade de origem. Terceiro, revogue ou recuse o certificado relevante de acordo com a sua autoridade de certificação e o processo RADIUS. Quarto, remova ou termine uma sessão ativa se a sua política o exigir. Quinto, tente uma nova ligação com o dispositivo gerido do antigo colaborador ou um equivalente controlado. Finalmente, retenha o pedido, a alteração, o resultado, a hora e o proprietário responsável. O segundo padrão é o iPSK. Em vez de uma frase de acesso partilhada por toda a força de trabalho, cada pessoa ou dispositivo tem uma chave distinta na mesma rede WiFi Staff. Isso torna a remoção direcionada. Elimine a chave associada a quem está a sair, confirme que uma nova tentativa de adesão falha e mantenha todas as outras chaves inalteradas. O iPSK pode funcionar bem onde tem dispositivos que não podem utilizar certificados, onde um programa de dispositivos geridos ainda está em desenvolvimento ou onde precisa de uma transição prática para deixar de usar uma frase de acesso partilhada. O iPSK não é o mesmo que uma palavra-passe genérica de equipa com um nome diferente. A chave deve estar associada a um registo de identidade ou de 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 estado de remoção. Torne a chave suficientemente distinta para que um evento de eliminação possa ser rastreado até à pessoa que está a sair. Se o mesmo iPSK for reutilizado por uma equipa, grupo de prestadores de serviços ou turno, recriou o problema do segredo partilhado num contentor mais pequeno. O terceiro padrão é o desprovisionamento orientado por SCIM. O SCIM é um protocolo padrão baseado em HTTP para provisionamento e gestão de dados de identidade em vários sistemas. Num bom processo de admissão, mobilidade e saída, os RH ou a TI desativam a conta no seu fornecedor de identidade, o estado desativado flui para o serviço de acesso WiFi e uma autenticação WiFi posterior é recusada. A Purple associa o acesso WiFi ao fornecedor de identidade através de SCIM. Os fornecedores de identidade relevantes são o Microsoft Entra ID, Okta e Google Workspace. O benefício operacional não é magia. É uma única fonte de verdade: o evento que encerra o vínculo laboral também inicia a remoção do WiFi. Trate o SCIM como um caminho de controlo, não como um slogan. Precisa de um identificador exclusivo que associe a conta do fornecedor de identidade ao registo de acesso WiFi. Precisa de um evento de desativação acordado. Precisa de saber que erro o serviço recetor produz quando um pedido de desativação falha. E precisa de uma identidade de teste que prove que a sua monitorização deteta essa falha. Agora passe do design para a implementação. Comece com um inventário de acessos. Liste cada rede WiFi para colaboradores, o seu modo de segurança, a fonte de identidade, o caminho RADIUS se presente, a autoridade de certificação se presente, o registo de proprietário de iPSK se presente, a capacidade de desligar a sessão e o destino dos registos. Faça isto por grupo de locais, e não como uma lista única de toda a empresa. Um hotel, uma loja de rua e um estádio podem partilhar políticas enquanto utilizam equipas operacionais e hardware diferentes. Em seguida, escolha o controlo que remove a maior parte do trabalho manual do processo de saída de colaboradores. Para dispositivos corporativos geridos, utilize 802.1X com EAP-TLS onde a sua autoridade de certificação, o design de RADIUS e a gestão de dispositivos possam suportá-lo. Para parques de dispositivos mistos que não podem utilizar certificados, utilize iPSK apenas quando cada chave for de propriedade exclusiva e puder ser eliminada. Para um parque que já utilize Microsoft Entra ID, Okta ou Google Workspace, utilize o desaprovisionamento orientado por SCIM para tornar a desativação da conta o gatilho para a remoção do acesso WiFi. A Purple pode ligar esse evento de identidade ao estado de acesso WiFi. Não adicione um segundo pedido manual, a menos que seja um caminho de exceção. Crie um guião de saída para o próprio dia. Os recursos humanos confirmam a hora de término. O proprietário da identidade desativa a conta. O proprietário da rede confirma que o respetivo certificado, iPSK ou registo de acesso WiFi já não é válido. As operações decidem se uma sessão ativa precisa de ser desligada. Um testador designado realiza uma nova tentativa de autenticação. O caso só é fechado quando o resultado for registado. Isto é deliberadamente pouco glamoroso. É também a parte que um avaliador pode reconstruir. Para evidências de conformidade com a ISO 27001 ou SOC 2, retenha uma cadeia pequena mas completa: o pedido de saída autorizado, a alteração no fornecedor de identidade, a alteração no WiFi, o resultado da verificação, as marcações temporais e o proprietário de cada etapa. Evite recolher mais dados pessoais do que o controlo necessita. Os registos de acesso podem constituir dados pessoais, pelo que deve incluí-los nas suas decisões de retenção e controlo de acessos. Se o WiFi para colaboradores puder afetar os sistemas de pagamento, discuta o âmbito e a segmentação com a equipa responsável pelo PCI-DSS, em vez de tratar a revogação de WiFi como uma alegação de conformidade isolada. Fique atento a quatro modos de falha. Primeiro, uma palavra-passe partilhada ainda está em utilização num SSID esquecido. Segundo, o registo de WiFi é associado a um endereço de e-mail mutável em vez de uma identidade duradoura. Terceiro, um evento de desativação chega ao fornecedor de identidade, mas não ao serviço de acesso WiFi. Quarto, testa apenas o estado no painel de controlo e não uma tentativa real de nova adesão. Cada modo de falha é evitável se inventariar, monitorizar e testar o controlo. Perguntas de resposta rápida. Um passe WPA2 partilhado pode ser revogado para um único colaborador que sai? Não. Roteie o passe para todos ou substitua-o por um controlo por identidade. Com que rapidez pode o acesso EAP-TLS ser revogado? Na próxima autenticação, desde que o design de validação do certificado e RADIUS reconheça a revogação. O SCIM remove uma sessão ativa? Não por si só. Trate o controlo de sessão como uma decisão operacional separada. O iPSK é adequado para todos os dispositivos? Não. É um modelo prático de chave vinculada à 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 colaboradores. Siga um evento de saída desde a notificação dos RH até à negação de autenticação. Identifique o passo manual. Depois, elimine-o. Uma credencial de WiFi deve expirar quando o colaborador sai, e não no próximo projeto de rotação de passes.