Offboarding de TI é o processo de retirar ou reatribuir acessos e ativos digitais de uma pessoa que deixa a empresa. Para automatizá-lo, é preciso autorização, inventário por sistema e confirmação dos resultados, preservando os documentos necessários à operação. Bloquear a conta e invalidar sessões são ações diferentes: nenhuma delas, isoladamente, comprova o encerramento de todos os acessos.
O RH informa o desligamento, mas a equipe ainda precisa saber quais contas existem, quem executa cada ação e o que ficou pendente. Para uma empresa com aplicações de departamentos diferentes, esse controle precisa ir além de uma mensagem de “automação concluída”.
O ponto de partida é transformar o desligamento em tarefas verificáveis, com decisões humanas nos pontos que envolvem identidade, preservação de dados e exceções.
O que o offboarding de TI precisa encerrar
O recorte de TI inclui contas do diretório corporativo, logins de aplicações, sessões, senhas compartilhadas, chaves de API e dispositivos. Também envolve definir quem assume arquivos e recursos da pessoa desligada. O checklist de offboarding da Bitwarden reúne essas categorias e separa as responsabilidades de RH, TI e segurança.
Não trate esses elementos como uma coisa só:
- Conta é o cadastro da pessoa em um sistema.
- Sessão é a continuidade de um acesso já autenticado.
- Credencial é um meio de autenticação, como senha ou chave de API.
- Arquivo precisa de uma decisão de preservação e responsabilidade.
- Dispositivo pode conter dados locais, além do acesso aos serviços da empresa.
Uma senha compartilhada pode continuar válida depois que a conta individual foi desabilitada. Um aplicativo com login próprio também exige tratamento no destino, mesmo que a empresa utilize SSO, o login único corporativo.
Por isso, “conta bloqueada” deve ser o resultado de uma tarefa, não o nome do processo inteiro.
Antes de automatizar, autorize e inventarie os acessos
Confirme identidade, autorização e janela
Como desenho de controle, adote uma solicitação autenticada da fonte responsável de RH, vinculada à identidade conferida e à aprovação do desligamento. Uma notificação recebida por e-mail, sozinha, não deve liberar alterações de acesso.
Registre a data, o horário e o fuso da execução. Confirme o identificador da pessoa no diretório e em cada aplicação: selecionar o primeiro cadastro com um nome parecido não é um critério seguro para esse fluxo.
Defina também quem pode cancelar ou corrigir a solicitação antes da execução. Essa regra precisa existir no projeto; não é uma proteção que se deva presumir em qualquer integração.
Defina responsáveis e continuidade
Use a divisão de papéis como referência adaptável: RH confirma o evento e a janela; TI inventaria e executa; segurança ou um validador designado confere os resultados. Quando não houver uma equipe separada de segurança, a empresa precisa nomear quem fará esse aceite.
Título
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Antes de retirar acessos, identifique arquivos, aplicações e contas de serviço que dependem da pessoa. Defina o novo responsável e as decisões de preservação conforme as políticas da empresa. Não exclua documentos apenas para concluir a lista.
Para uma chave usada por uma integração, por exemplo, a tarefa proposta deve registrar a dependência e a ação autorizada. Revogar sem avaliar quem ainda usa a credencial não substitui uma transição planejada.
Checklist por sistema, responsável e evidência
A tabela abaixo é uma proposta operacional, não uma norma nem um procedimento já testado. Adapte as ações ao inventário e às políticas da empresa.
| Sistema ou recurso | Ação a autorizar | Executor sugerido | Evidência para validação | Exceção a registrar |
|---|---|---|---|---|
| Diretório corporativo | Desabilitar a conta conferida | TI | Estado relido no diretório e registro da execução | Identidade ambígua, conta privilegiada ou sincronização híbrida |
| Sessões e aplicações integradas | Invalidar tokens e tratar sessões conforme o destino | TI e dono da aplicação | Resposta da operação e conferência na aplicação | Atraso, sessão própria ou usuário externo |
| Aplicativo com login próprio | Retirar o acesso diretamente no sistema | Administrador da aplicação | Registro de desativação e aceite do responsável | Ausência de API ou conta ainda não localizada |
| Senhas compartilhadas e chaves | Revogar ou rotacionar conforme dependências | TI e responsável pelo recurso | Registro da alteração, sem copiar o segredo | Integração dependente ou conta de serviço sem novo dono |
| Arquivos e colaboração | Preservar e transferir responsabilidade | Dono dos dados e TI | Novo responsável confirmado no destino | Retenção ou destino dos arquivos não decidido |
| Dispositivos e rede | Tratar VPN, certificados e devolução | TI | Registro de retirada de acesso e recolhimento | Equipamento offline ou dados locais pendentes |
Em cada linha, acrescente identidade, horário previsto, resultado técnico, referência da evidência, validador e próximo responsável pela exceção. O registro precisa permitir distinguir ação solicitada, ação executada e resultado confirmado.
Evite uma coluna única de “concluído” para toda a pessoa. Se o diretório foi bloqueado, mas uma aplicação segue sem conferência, preserve essa diferença no chamado.
Bloquear a conta não é revogar todas as sessões
O Microsoft Graph ajuda a visualizar essa separação. Os exemplos abaixo descrevem operações documentadas; não são um roteiro pronto de produção e não representam mudanças executadas em contas reais.
O que muda com accountEnabled
Na operação de atualização do usuário, uma requisição PATCH ao recurso do usuário pode enviar o corpo {"accountEnabled": false}. Isso altera o estado de habilitação da conta.
A documentação de atualização de usuário no Microsoft Graph indica User.EnableDisableAccount.All mais User.Read.All como combinação mínima para atualizar essa propriedade. Funções administrativas e hierarquia de ações sensíveis também dependem do alvo e do cenário de autenticação.
Não presuma que conceder permissões à aplicação basta para alterar qualquer administrador. Em usuários sincronizados, avalie ainda a fonte de autoridade e a sincronização antes de aplicar o mesmo desenho de uma conta mantida apenas na nuvem.
O que revokeSignInSessions invalida
Outra operação é o POST de revokeSignInSessions no recurso do usuário, sem conteúdo no corpo. Ela invalida tokens de atualização e cookies de sessão do usuário no navegador, conforme o escopo descrito pela Microsoft.
O token de atualização é uma credencial usada pela aplicação para tentar obter novos tokens de acesso. Invalidá-lo não significa apagar todos os tokens de acesso já emitidos.
A referência de revokeSignInSessions lista User.RevokeSessions.All como permissão de menor privilégio para aplicação e para acesso delegado corporativo. O recurso /me exige usuário autenticado e permissão delegada; não é a opção para autenticação somente da aplicação.
O que permanece fora dessa confirmação
A documentação informa que pode haver um pequeno atraso de alguns minutos na revogação. Também declara que essa API não revoga sessões de usuários externos, que se autenticam no ambiente organizacional de origem.
Além disso, o guia de revogação de acesso do Microsoft Entra explica que o diretório não consegue revogar diretamente uma sessão emitida pela própria aplicação. O efeito depende dos tokens, das regras do destino e da sincronização.
O mesmo guia alerta que dispositivos offline podem manter dados locais. Revogar acesso na nuvem não apaga automaticamente essas cópias, e uma limpeza irreversível exige decisão específica, não uma tentativa automática de encerrar o chamado.
Como desenhar a automação com conferência humana
O n8n pode coordenar chamadas e encaminhamentos entre sistemas. Para entender o papel do orquestrador, consulte o guia de automação de processos com n8n.
A documentação do nó HTTP Request confirma suporte a métodos como GET, PATCH e POST. Também permite incluir cabeçalhos e código de status na resposta. Guarde a autenticação no gerenciador de credenciais, não em campos de observação do checklist.
A opção Never Error pode fazer o nó retornar sucesso independentemente do código recebido. Não confunda esse comportamento com a confirmação da operação: um fluxo visualmente verde não comprova que o acesso terminou.
Para o projeto, proponha esta sequência:
- Receber a solicitação e conferir identidade, aprovação e janela.
- Carregar o inventário e as ações autorizadas por sistema.
- Executar bloqueio, revogação e demais tarefas separadamente.
- Consultar o destino ou obter o registro disponível para conferir o resultado.
- Encaminhar falhas e situações não verificáveis para uma fila de exceções.
- Obter aceite humano, mantendo explícitas as pendências.
Uma aplicação sem API deve gerar uma tarefa humana rastreável. O responsável registra a ação no próprio sistema e devolve a evidência; a falta de integração não pode desaparecer do relatório.
Teste em laboratório antes de usar contas reais
Esse desenho ainda exige validação. Use identidades fictícias e inclua conta interna, convidado e aplicação com login próprio. Simule falta de permissão, erro da API, atraso, evento duplicado e desligamento cancelado.
Como critério de aceite proposto, verifique se o fluxo impede execução sem aprovação, evita encerrar silenciosamente tarefas pendentes e encaminha casos ambíguos para revisão. Defina quais ações podem ser repetidas e quais exigem nova autorização; não presuma que toda API aceita repetição sem consequências.
Nenhum fluxo ou tenant foi alterado para este artigo. As operações foram consultadas na documentação e precisam ser revalidadas no ambiente de implementação.
Principais conclusões
- Autorize o desligamento com identidade e janela conferidas antes de executar alterações.
- Controle cada sistema com executor, evidência, validador e responsável pelas exceções.
- Separe bloqueio de conta, revogação de tokens e encerramento de sessões das aplicações.
- Resolva a continuidade dos arquivos sem usar exclusão como atalho para concluir o checklist.
- Teste falhas, convidados e eventos duplicados antes de operar com contas reais.
Perguntas frequentes
A revogação de sessões bloqueia o acesso imediatamente?
Não necessariamente. A Microsoft informa possível atraso na operação, e o efeito nas aplicações depende de seus tokens, sessões e sincronização. Não há um prazo universal de encerramento que possa ser aplicado a todos os sistemas.
O que muda para convidados e pessoas de outra organização?
A API revokeSignInSessions não revoga as sessões de usuários externos, pois eles se autenticam no ambiente de origem. Esses acessos precisam de análise específica e conferência nos recursos da empresa, sem sair do inventário de desligamento.
É preciso excluir documentos para concluir o offboarding?
Não trate exclusão como requisito automático. Defina preservação e transferência de responsabilidade conforme as políticas da empresa, separando continuidade dos dados de manutenção do acesso da pessoa desligada.
Próximo passo: avaliar as dependências
Antes de escolher quais tarefas automatizar, identifique onde estão as contas, quais sistemas permitem confirmação e quem assume as exceções. Para avaliar as dependências entre RH, diretório e aplicativos, continue pelo guia de integração de sistemas.
