Deprovisionamento no offboarding: feche contas órfãs

O desligamento de um funcionário que não desliga as contas dele é uma das falhas de hardening mais fáceis de explorar e das mais baratas de corrigir. Toda organização que autentica pessoas em aplicações SaaS mantém, em algum canto, uma conta órfã: o usuário saiu da empresa, mas o acesso continua de pé, com token de sessão válido e permissões herdadas de grupos antigos. A ação prioritária é auditar o fluxo de deprovisionamento — não o login, o desligamento — e provar, com teste ponta a ponta, que a revogação chega a cada aplicativo crítico.

O problema da conta órfã

Uma conta órfã nasce de uma assimetria simples: quase todo time automatiza a concessão de acesso e quase nenhum automatiza a revogação. O provisionamento just-in-time via SAML cria a conta no primeiro login, mas não desativa nem exclui ninguém quando a pessoa sai — a revogação exige um conector de provisionamento dedicado, mantido ativo e monitorado. O resultado, sem esse conector, é um acervo de contas ativas sem dono, com privilégio acumulado de todos os projetos por onde o usuário passou.

Essas contas têm preço de mercado. Corretores de acesso vendem entradas prontas em redes corporativas, e credenciais de nuvem roubadas já serviram de arma de destruição em campanhas documentadas. Para o invasor, a conta órfã vale mais que uma vulnerabilidade: não exige exploit, não dispara alerta de login anômalo e quase nunca aparece em auditoria. Quem responde a incidentes reconhece o padrão — a pergunta sobre como o invasor entrou termina, com frequência, numa conta que devia ter sido desligada meses antes.

Como o SCIM desliga o acesso

O padrão que fecha essa lacuna é o SCIM (System for Cross-domain Identity Management), publicado pelo IETF como RFC 7644 em setembro de 2015. A especificação do protocolo define uma API REST comum para criar, atualizar e remover usuários entre o diretório-fonte e o aplicativo. O conector de provisionamento sincroniza os dois lados de forma contínua: quando a pessoa sai do escopo, o provedor reage sem intervenção manual.

No Microsoft Entra, o serviço de provisionamento conecta-se ao endpoint SCIM do aplicativo e mantém fonte e destino coerentes, como descreve a documentação de provisionamento do Entra. Quando o usuário sai do escopo — desligado, removido da atribuição ou bloqueado de entrar — o serviço envia um pedido que define a propriedade active como falsa, o que desativa o acesso sem apagar o histórico. A exclusão definitiva chega depois, quando a conta deixa a lixeira do diretório, com janela de trinta dias antes da remoção permanente.

A engenharia está em escolher qual evento dispara a revogação. Desligamento, mudança de função e perda de dispositivo devem produzir estados diferentes no aplicativo. O erro comum é comprimir os três numa única regra de desligamento e deixar a rotação interna sem revogação: o gestor que troca de área carrega o acesso antigo por tempo indeterminado, e o mapa de permissões deixa de refletir a organização real.

Desativar não é excluir

Desativação e exclusão são operações diferentes, com riscos diferentes. A desativação preserva dados, histórico de auditoria e a chance de desfazer um erro; a exclusão remove a conta por completo e, junto dela, a trilha que uma investigação poderia precisar. O padrão de segurança é desativar primeiro e excluir depois de uma janela definida — e saber exatamente o que cada aplicativo faz quando recebe cada pedido.

Desativar a conta, porém, não revoga tokens e sessões já emitidos: um portador de token válido pode continuar autenticado até a expiração. Por isso o runbook de offboarding precisa de duas ações no provedor — desativar no diretório e revogar sessões e tokens de atualização — antes de confiar no conector. Sem a segunda etapa, a conta órfã deixa de existir no aplicativo, mas a sessão órfã continua viva.

Sinais de falha a monitorar

O deprovisionamento falha em silêncio, e a detecção depende de sinais que a maioria do time já tem, mas não consulta:

• logs de provisionamento em quarentena: contas que o conector tentou desativar e recebeu erro, repetindo sem sucesso;
• login bem-sucedido no aplicativo de conta desativada no diretório-fonte — o indicador mais grave da lista;
• divergência entre contas no escopo do conector e contas ativas no destino, medida por reconciliação periódica;
• sincronização delta parada há dias, que congela o estado e transforma saída recente em acesso persistente;
• contas criadas fora do provisionamento, por admissão manual ou aplicativo não gerenciado, invisíveis ao conector.

Cada sinal desses precisa virar um alerta com dono. Sem dono, o log de quarentena acumula meses de contas pendentes e ninguém percebe até o incidente.

Plano de ação priorizado

P1 — nesta semana

1. Inventariar os conectores de provisionamento ativos e listar os aplicativos críticos cobertos só por login federado, sem revogação automática.
2. Revisar o mapeamento de desativação de cada conector e confirmar qual atributo controla o estado da conta no destino.
3. Executar um desligamento de teste ponta a ponta em cada aplicativo crítico e cronometrar o tempo entre a saída no diretório e o bloqueio real.
4. Incluir a revogação de sessões e tokens no runbook de offboarding, como passo separado da desativação.

P2 — neste trimestre

1. Estender o conector SCIM aos aplicativos que hoje dependem de provisionamento manual ou just-in-time.
2. Aplicar privilégio mínimo por requisição nas decisões de acesso, seguindo a definição do NIST para zero trust, que trata a rede como comprometida e exige avaliação por pedido.
3. Automatizar a reconciliação mensal entre diretório-fonte e destinos, com relatório de contas fora do escopo ainda ativas.
4. Levar o offboarding ao exercício de tabletop: simular a saída de um administrador e medir quanto acesso sobrevive ao primeiro dia.

Fontes

• IETF — RFC 7644, SCIM Protocol Specification
• Microsoft — How Application Provisioning works in Microsoft Entra ID
• NIST — SP 800-207, Zero Trust Architecture