Acessos órfãos e privilégio excessivo: o provisório que virou permanente

Toda empresa tem um acesso que ninguém sabe explicar. Um usuário ativo no Active Directory sem correspondência na base de RH. Um perfil de administrador criado numa madrugada de incidente. Uma conta de serviço que sustenta uma integração desconhecida.

Esses são os acessos órfãos: permissões vivas sem titular, sem owner e sem prazo. Não aparecem em relatório porque ninguém pediu nada de novo. Seguem válidas por omissão.

A origem raramente é técnica. É de processo. A concessão tem gatilho claro, que é o pedido. A revogação depende de alguém lembrar.

O que são acessos órfãos e contas órfãs

Acesso órfão é a permissão que continua ativa depois que a razão de existir terminou. Conta órfã é a identidade que perdeu o titular ou o owner responsável: a pessoa saiu, o contrato encerrou, o projeto acabou, mas o registro segue habilitado no diretório e nos sistemas conectados.

São três falhas distintas. Titularidade: não há mais pessoa física por trás. Responsabilidade: a conta existe, ninguém responde por ela. Pertinência: a pessoa existe, o acesso não serve mais à função.

Privilégio excessivo é o efeito acumulado das três. O usuário não carrega uma permissão indevida, carrega dezenas somadas em anos.

Por que a conta órfã é o alvo preferido na movimentação lateral

A conta órfã entrega ao atacante a melhor combinação: credencial legítima, privilégio real e nenhum dono para estranhar o comportamento.

O acesso não é forçado, ele autentica. Não gera alerta de tentativa inválida nem aciona o help desk. Sem titular ativo, ninguém percebe login em horário atípico.

Contas privilegiadas órfãs pesam mais. Têm senha estática, sem rotação, e muitas ficam fora do MFA porque nasceram para automação.

Na auditoria o problema é gêmeo. Ação não atribuível não sustenta trilha de auditoria. Os critérios de acesso lógico dos Trust Services Criteria e os controles do Anexo A da ISO/IEC 27001 pedem o mesmo: acesso com dono, motivo e revisão.

De onde vêm os acessos órfãos

Desligamento sem gatilho de revogação

O desligamento chega ao RH e ao gestor. A TI descobre depois, por e-mail ou planilha. A conta principal cai rápido porque é visível. O resto fica: o SaaS contratado pela área, o acesso ao ERP concedido anos atrás, o grupo do diretório que abre três sistemas. Deprovisionamento parcial é a regra quando não há fonte única ligando pessoa, vínculo e permissão.

Terceiro e consultor com prazo indefinido

O terceiro entra por demanda urgente e recebe acesso até o fim do projeto. O fim do projeto não é uma data no sistema, é uma expectativa. O contrato encerra, a nota fiscal para de chegar, o acesso continua.

Projeto encerrado, férias e incidente de madrugada

Mesmo padrão nos três casos: acesso concedido para uma janela que nunca foi registrada.

A cobertura de férias é a mais silenciosa. O substituto acumula o poder do titular por quinze dias e mantém por anos. Quando o titular volta, dois perfis exercem a mesma função crítica e a segregação de funções deixa de existir.

O acesso emergencial é o pior. Administrador concedido às três da manhã para restabelecer um serviço, com aprovação verbal e registro em grupo de mensagens. O privilégio nunca volta ao normal.

Migração de sistema e conta de serviço sem dono

Em migração, os acessos são replicados no ambiente novo antes de serem baixados no antigo. O legado fica no ar por garantia e a superfície dobra.

A conta de serviço herdada é o caso clássico: criada por um analista que já saiu, privilégio alto, credencial em algum script, nenhum owner nomeado. Ninguém desativa porque ninguém sabe o que quebra.

Tipos de acesso órfão, origem, risco e controle

Role creep: o acúmulo de permissões por mudança de cargo

Promoção deveria trocar o conjunto de permissões. Na prática, soma. O pedido que chega à TI diz o que a pessoa passa a precisar, nunca o que ela deixa de precisar.

Ninguém tem incentivo para pedir remoção. O gestor não quer travar o time, o usuário não devolve acesso, a TI executa o pedido. O resultado é o analista que virou coordenador e depois gerente com as permissões dos três cargos, podendo criar fornecedor, aprovar pagamento e conciliar conta.

Esse é o vetor de privilégio excessivo mais comum e o mais difícil de ver sem modelagem de papéis. Um modelo de RBAC com papéis por cargo e herança controlada transforma movimentação interna em substituição de papel.

Vigência compulsória: o least privilege morre sem data de término

Least privilege é tratado como decisão de concessão. É, na verdade, uma condição a manter no tempo. Permissão mínima hoje é excessiva em seis meses se a função mudou.

Sem data de fim, toda concessão é permanente por padrão e a revogação depende de esforço voluntário. Inverta isso:

1. 1Defina classes de vigência por criticidade: prazo curto para privilégio administrativo, prazo maior para leitura.
2. 2Torne a data de término campo obrigatório. Sem data, o pedido não avança.
3. 3Amarre a vigência à origem: prazo do contrato, fim do projeto, período da cobertura de férias.
4. 4Trate renovação como nova concessão, com justificativa atual, nunca prorrogação automática.
5. 5Registre exceção com dono nomeado e prazo. Exceção sem dono é acesso órfão em formação.
6. 6Notifique gestor e owner da aplicação antes do vencimento.
7. 7Revogue por padrão na ausência de renovação. O ônus passa a ser manter, não remover.

Esse desenho encaixa no ciclo descrito em governança de acessos e sustenta as campanhas de recertificação. Sem vigência, recertificar vira reaprovar em massa o que já existe.

Conta de serviço e conta privilegiada precisam de owner humano

Conta de serviço não tem gestor, não tira férias e não passa por desligamento. Por isso escapa de todo controle desenhado para pessoas.

A regra é direta: nenhuma conta técnica existe sem responsável humano nomeado, com registro da integração que ela sustenta, do privilégio concedido e da próxima revisão. Quando o responsável sai, a transferência de ownership entra na checklist de desligamento.

O mesmo vale para contas privilegiadas de administração: justificativa por uso, prazo e ciclo de revisão mais curto que o das contas comuns.

Inventário inicial de faxina: achar o que já está solto

Antes de automatizar, é preciso limpar. O inventário inicial é exercício de reconciliação, não de adivinhação.

1. 1Congele o estado atual. Extraia o dump do diretório e dos sistemas críticos na mesma data.
2. 2Reconcilie o diretório com a base de RH. Conta ativa sem vínculo ativo é candidata imediata.
3. 3Cruze com a base de contratos. Terceiro sem contrato vigente entra na mesma fila.
4. 4Classifique por último uso. Conta sem autenticação em período longo é forte indício de acesso órfão.
5. 5Identifique o owner de cada aplicação e conta técnica. Sem owner, é declarado órfão.
6. 6Trate em lote por grupo de risco, a começar por privilégio administrativo e dados pessoais sob LGPD.
7. 7Desabilite antes de excluir, com janela de reversão definida e registro do que foi feito.
8. 8Registre as exceções com dono e prazo e jogue todas na primeira campanha de recertificação.

O resultado não é uma base perfeita. É uma base explicável: cada acesso com dono, motivo e data.

Como o AuditAcesso trata vigência, reconciliação e desligamento

O AuditAcesso é a camada de governança acima do IAM. Não substitui o provisionamento técnico, governa a decisão e produz a evidência.

• Automação de vigência. Data de término compulsória. O acesso temporário expira sozinho e a renovação exige nova justificativa.
• Reconciliação com Active Directory. A entrada vem do catálogo do AD, o que permite comparar diretório e aprovações e expor conta ativa sem solicitação válida.
• Carga massiva com tratamento de exceções. Faxina inicial e onboarding em lote entram por carga aprovada, com cada exceção registrada com dono e prazo.
• Desligamento com evidência. A revisão registra o que foi revogado, quando e por ordem de quem, o que sustenta a resposta ao auditor de SOC 2 e ISO 27001.

O pedido só avança com o proprietário da aplicação e o conflito de SoD é barrado antes da execução. A execução sai via ITSM (Jira, GLPI) ou API, com integrações nativas homologadas. A lista está na página de integrações e as cinco etapas no ciclo de governança.

Checklist prático

• Toda concessão nasce com data de término no sistema.
• Toda aplicação e toda conta de serviço têm owner nomeado e ativo.
• Transferência de ownership entra na checklist de desligamento.
• Acesso emergencial tem prazo curto e revisão obrigatória.
• Mudança de cargo dispara revisão de remoção, não só de adição.
• Diretório é reconciliado com a base de RH em ciclo definido.
• Terceiro tem vigência amarrada ao prazo do contrato.
• Exceção só existe com dono, motivo e prazo.
• Desligamento gera evidência de revogação por sistema.
• Pedido de acesso não entra por e-mail, chat ou planilha.

Perguntas frequentes

Qual a diferença entre acesso órfão e conta órfã?

Conta órfã é a identidade que perdeu o titular ou o responsável, como o usuário de um ex-funcionário que segue habilitado. Acesso órfão é mais amplo: qualquer permissão ainda ativa depois de a justificativa ter expirado, inclusive em contas de pessoas que continuam na empresa.

Como identificar acessos órfãos sem ferramenta de IGA?

Comece por reconciliação manual. Extraia a lista de usuários do Active Directory na mesma data do relatório de vínculos ativos do RH e compare. Depois cruze com contratos de terceiros e com o último logon de cada conta. Trabalhoso, insustentável como rotina, mas revela o tamanho do passivo.

Desabilitar a conta é suficiente ou é preciso excluir?

Desabilitar primeiro é a prática segura, porque permite reverter se alguma integração depender daquela conta. A exclusão vem depois, com janela de reversão definida. O que não pode faltar é o registro de quem desabilitou, quando e com base em qual decisão.

Por que o least privilege falha mesmo com política aprovada?

Porque a política trata da concessão e não da manutenção. Sem data de término, o acesso mínimo de hoje se torna privilégio excessivo amanhã, quando a função muda. O least privilege só sobrevive com vigência compulsória, revisão periódica e remoção automática na ausência de renovação.

Como provar ao auditor que os acessos órfãos foram tratados?

O auditor pede evidência de processo, não declaração. Precisa ver a concessão com justificativa e prazo, o registro da revisão no período, a decisão de manter ou revogar e a execução com data. Uma trilha de auditoria do ciclo responde a isso sem coleta manual.

Próximo passo

Acessos órfãos não desaparecem com mutirão. Voltam no trimestre seguinte se a concessão continuar nascendo sem prazo e sem dono.

Para cortar privilégio excessivo e sustentar a evidência disso, fale com um especialista do AuditAcesso e marque uma reunião técnica para ver a automação de vigência e a reconciliação com Active Directory aplicadas ao seu ambiente.

==============================================================