O desligamento foi comunicado, o notebook voltou para a empresa e o time respira. É justamente aí que muita operação de TI deixa uma porta aberta: o usuário continua em um grupo, um token ainda funciona, uma caixa de e-mail recebe redefinição de senha ou uma conta de fornecedor ficou fora da lista.
Isso não é burocracia de fim de contrato. É controle de acesso. O NIST coloca na mesma rotina de desligamento a desativação de acesso, a revogação de credenciais, a recuperação de propriedade relacionada a sistemas e a retenção das informações que estavam sob controle da pessoa. Na prática, o risco não mora só no login corporativo: mora em tudo que a pessoa conseguiu acumular para trabalhar.
Um offboarding bom não é uma corrida para “desligar o usuário”. É um processo curto, com dono, ordem e prova de que cada corte aconteceu.
Comece pelo relógio, não pela planilha
Para um desligamento programado, RH, gestor e TI precisam combinar data e hora antes de a conversa acontecer. Para um desligamento sensível, esse alinhamento precisa ser ainda mais próximo: a sequência entre notificação, bloqueio de acesso e recolhimento de ativos pode fazer diferença.
O erro clássico é receber um e-mail genérico dizendo “fulano saiu” e começar a procurar sistemas depois. Até localizar a lista certa, o ex-colaborador pode continuar com VPN, e-mail, repositório, console cloud ou uma sessão já aberta.
Defina um responsável operacional, uma janela de execução e um canal de escalonamento. Isso transforma um conjunto de lembretes em procedimento.
O que precisa cair primeiro
Não existe lista universal, porque cada empresa entrega ferramentas diferentes. Mas há uma ordem que reduz bastante a chance de esquecer o básico:
- Identidade principal. Bloqueie SSO, diretório corporativo e e-mail. Se o provedor sincroniza identidades, confirme a propagação em vez de presumir que ela ocorreu.
- Acesso remoto e dispositivos. Revogue VPN, MDM, certificados, chaves SSH, MFA, tokens físicos e sessões de dispositivos gerenciados.
- Privilégios e grupos. Retire a pessoa de grupos administrativos, listas de distribuição, projetos, cofres de senha, consoles cloud e ferramentas de atendimento.
- Segredos de trabalho. Invalide tokens pessoais de automação, PATs, chaves de API, chaves de deploy e credenciais compartilhadas que possam ter sido vistas ou exportadas.
- Terceiros que fogem do SSO. Não esqueça registradores de domínio, SaaS financeiro, plataformas de recrutamento, contas de suporte, ferramentas de analytics e portais de fornecedores.
O ponto não é tirar tudo de uma vez sem pensar. É impedir que a conta pessoal continue sendo a ponte para recursos corporativos enquanto o restante da transição é resolvido.
Conta bloqueada não significa operação preservada
Desativar alguém não pode apagar o contexto que ficou com essa pessoa. Antes de remover ou arquivar, confirme quem passa a cuidar de caixas compartilhadas, calendários de plantão, repositórios, pipelines, documentos, dashboards e domínios.
Trocar o dono de um recurso é diferente de manter um acesso antigo “só por garantia”. O ideal é nomear o novo responsável e testar se ele realmente consegue administrar o recurso. Se há uma senha compartilhada, rotacione-a; se há uma automação rodando em um token individual, migre-a para uma identidade de serviço com escopo mínimo.
Também vale revisar regras de encaminhamento no e-mail e integrações com aplicativos pessoais. São detalhes pequenos, mas costumam aparecer tarde — quando uma aprovação, um alerta ou uma fatura chega ao lugar errado.
Ativos físicos também são acesso
Notebook, celular, chave de segurança, crachá e token de VPN entram na mesma conversa. O NIST cita explicitamente a recuperação de propriedade relacionada a sistemas: não é só inventário patrimonial, é reduzir caminhos de acesso e proteger dados que podem estar no equipamento.
Registre número de série, estado do aparelho e destino. Se o equipamento não voltou, trate o caso com uma avaliação de risco: ele tinha dados locais? Estava criptografado? Havia sessão ativa? O MDM permite bloqueio ou limpeza remota? A resposta precisa ficar documentada, não guardada em memória de alguém.
Quando uma conta esquecida pode virar incidente
Uma vulnerabilidade sozinha não é automaticamente um incidente. Mas, segundo a ANPD, acesso não autorizado a dados pessoais pode ser um incidente de segurança, e a análise considera contexto, tipo e quantidade de dados, pessoas afetadas e as medidas de mitigação adotadas.
Se houver confirmação de acesso indevido a dados pessoais e possibilidade de risco ou dano relevante, o controlador tem obrigações de comunicação. A ANPD informa que, em regra, a comunicação à Autoridade e aos titulares deve ocorrer em até três dias úteis, ressalvadas regras específicas. Não é motivo para transformar todo offboarding em pânico; é motivo para não tratar uma conta esquecida como mero detalhe administrativo.
Feche com evidência, não com “deve estar tudo certo”
O melhor checklist é o que deixa uma trilha: hora do bloqueio de identidade, grupos removidos, tokens revogados, ativos recebidos, recursos transferidos e exceções abertas. Uma planilha ou ticket simples já resolve — desde que tenha responsável, status e prazo.
Depois, faça uma revisão curta: qual sistema apareceu fora da lista? Qual acesso demorou para cair? O que ainda depende de processo manual? Essas respostas alimentam a próxima saída e evitam que a empresa descubra seus buracos pelo pior caminho possível.
