O desligamento de uma pessoa da empresa costuma parecer um assunto de RH. Para TI, ele deveria acender outra luz: que acesso ainda ficou vivo depois que a pessoa saiu?
Esse é o tipo de risco que não faz barulho no primeiro dia. O e-mail corporativo pode ter sido bloqueado, mas ainda existe conta em SaaS, token de API, chave SSH, usuário em ferramenta de suporte, VPN antiga, repositório privado, grupo de admin ou acesso de convidado que ninguém revisou. Quando dá ruim, a pergunta chega tarde: quem ainda conseguia entrar?
O erro quase nunca está em um único botão
Offboarding ruim raramente nasce de uma pessoa mal-intencionada sentada na frente do painel. Normalmente ele nasce de processo quebrado: RH avisa por e-mail, gestor esquece uma ferramenta, TI desativa o básico, mas ninguém tem inventário real de tudo que foi provisionado durante meses ou anos de trabalho.
A documentação da Microsoft sobre operações de segurança em contas de usuário bate bastante nessa tecla: criação, exclusão e uso de contas precisam ter baseline, logs e alerta. Não basta saber que a conta principal foi encerrada. É preciso enxergar contas criadas fora do processo, contas com atributo estranho, permissões privilegiadas e eventos de criação ou deleção fora do padrão.
Traduzindo para a vida real: se a empresa não sabe qual é o caminho normal de uma identidade, também não sabe quando uma identidade saiu da curva.
O offboarding de verdade começa antes da demissão
A melhor hora de remover acesso não é no improviso, às 18h12, depois de alguém mandar uma mensagem no grupo dizendo “fulano saiu hoje”. O offboarding bom começa no desenho do ciclo de identidade.
Em ambientes mais maduros, a identidade nasce de uma fonte confiável, como o sistema de RH, ganha permissões por grupo, função e política, muda quando a pessoa troca de cargo e perde acesso quando a relação com a empresa acaba. A própria visão de governança de identidade da Microsoft resume bem o objetivo: garantir que as pessoas certas tenham o acesso certo aos recursos certos, e que esse acesso seja revisável e removível.
Isso parece burocracia até o dia em que alguém descobre uma conta externa ativa há oito meses, com acesso a uma ferramenta que guarda cliente, pipeline, financeiro ou código.
O risco mora nos acessos pequenos
Conta de administrador chama atenção. O problema é que incidente também nasce de permissão aparentemente pequena.
Um acesso antigo ao CRM pode expor lista de clientes. Um convite esquecido no workspace pode manter documentos sensíveis abertos. Uma chave SSH sem dono claro pode sobreviver a várias trocas de equipe. Um token de CI/CD pode continuar publicando artefato sem ninguém lembrar quem criou.
É aqui que o princípio de menor privilégio, reforçado pela OWASP, deixa de ser frase bonita de auditoria. Cada permissão deveria existir porque alguém precisa dela agora, para uma função clara. Quando a pessoa muda de papel ou sai, aquela justificativa precisa expirar junto.
Um checklist curto para TI não virar bombeiro
Se o processo da empresa ainda é manual, o mínimo saudável é transformar o desligamento em checklist executável, com dono e evidência. Não precisa começar perfeito. Precisa começar rastreável.
- Conta principal: desativar usuário corporativo e encerrar sessões ativas.
- Grupos e papéis: remover de grupos, roles, listas, times e permissões herdadas.
- SaaS fora do diretório: conferir ferramentas que não seguem SSO ou provisionamento automático.
- Repositórios e deploy: revogar acesso a Git, CI/CD, nuvem, secrets, chaves SSH e tokens pessoais.
- Dispositivos: inventariar notebook, celular, MDM, VPN, certificados e perfis locais.
- Terceiros e convidados: revisar contas B2B, freelancers, fornecedores e e-mails externos.
- Logs: verificar login depois do desligamento, tentativa negada e atividade anormal em contas relacionadas.
O ponto não é transformar TI em polícia interna. É impedir que a empresa dependa de memória, planilha solta e boa vontade quando o assunto é acesso a ambiente crítico.
O sinal de maturidade é conseguir provar
Uma pergunta simples separa o processo maduro do improvisado: se alguém saiu ontem, você consegue provar hoje que os acessos críticos foram removidos?
Provar não é responder “acho que sim”. É ter log, ticket, fluxo, automação, revisão e lista de sistemas cobertos. Também é saber o que ficou fora do fluxo e precisa de correção manual.
Para times pequenos, isso pode começar com uma tabela simples de sistemas, responsáveis e passos de revogação. Para empresas maiores, o caminho natural é integrar RH, diretório, SSO, gestão de acesso, revisões recorrentes e monitoramento. O importante é parar de tratar offboarding como evento administrativo e começar a tratar como controle de segurança.
O recado para quem trabalha em TI
Offboarding ruim é ingrato porque, quando funciona, ninguém percebe. Quando falha, todo mundo lembra da TI.
Por isso a pauta é menos sobre paranoia e mais sobre higiene operacional. A pessoa saiu? O acesso precisa sair junto. Se não sai, a empresa não tem um ex-colaborador. Tem uma porta esquecida aberta, esperando alguém notar.
