RBAC em AD: delegação que funciona
Depois de auditar o grupo Domain Admins, a pergunta inevitável aparece.
"Ok, tenho 40 contas aqui. O que faço com elas?"
A resposta é delegação. Mas delegação sem estrutura resolve um problema e cria três novos.
Por que a maioria das delegações em AD não funciona
Delegação em AD é tecnicamente simples. Você abre o wizard, seleciona um usuário, marca algumas permissões e pronto. Em 10 minutos está feito.
O problema não é a execução. É a ausência de um modelo por trás dela.
Sem modelo, cada delegação é uma decisão isolada. Com o tempo, o ambiente vira um mapa impossível de ler. Permissões sobrepostas, escopos inconsistentes, ninguém sabe ao certo quem pode fazer o quê.
Já encontrei ambientes onde a delegação havia sido feita com boas intenções, e havia criado um caminho de escalonamento de privilégios que ninguém percebeu por anos. Não por má fé. Por falta de design.
As três perguntas antes de qualquer delegação
Antes de abrir qualquer ferramenta, responda:
1. Quem precisa fazer o quê? Não "quem precisa de acesso". Isso é genérico demais. A pergunta certa é: qual tarefa específica essa pessoa precisa executar? Resetar senha de usuários em determinada OU? Criar contas em um departamento? Modificar atributos de um grupo específico?
2. Em qual escopo? Domínio inteiro, uma OU específica, um grupo de objetos? Escopo mínimo é o princípio. Se a tarefa é gerenciar contas do departamento financeiro, o escopo é a OU do financeiro, não o domínio.
3. Com qual frequência? Uma tarefa diária justifica uma delegação permanente. Uma tarefa que acontece uma vez por trimestre talvez não, pode ser resolvida com um processo controlado e acesso temporário.
Essas três perguntas, respondidas antes de qualquer configuração, eliminam 80% dos problemas que vejo em ambientes com delegação mal feita.
Delegação por OU ou por grupo — quando usar cada uma
No AD, você pode delegar permissões de duas formas principais:
Por OU: você dá permissão sobre todos os objetos dentro de uma unidade organizacional. Simples de entender, fácil de gerenciar, mas rígido, se a estrutura de OUs mudar, as delegações podem quebrar.
Por grupo: você cria um grupo de segurança e delega permissões sobre os membros desse grupo, independente de onde estão no AD. Mais flexível, mas exige disciplina na gestão dos grupos.
Na prática, a maioria dos ambientes usa uma combinação dos dois. A regra que uso: se o escopo é geográfico ou departamental e a estrutura de OUs reflete isso, use OU. Se o escopo é funcional, todos os servidores de produção, todos os usuários de um sistema específico, use grupo.
O erro mais comum
Dar mais permissão do que o necessário "para não precisar voltar".
É compreensível. Voltar para ajustar uma delegação dá trabalho. Mas cada permissão extra é superfície de risco. Se a conta for comprometida, o atacante herda exatamente o que você delegou, não mais, não menos.
Least privilege não é paranoia. É o que limita o raio de ação quando algo dá errado.
Como documentar para o próximo administrador entender
Delegação sem documentação é conhecimento tácito. Quando você sair, vai junto.
O mínimo que todo ambiente deveria ter:
- Quem tem o quê delegado
- Em qual escopo
- Por qual razão
- Quando foi criado
- Quem aprovou
Não precisa ser um sistema sofisticado. Uma planilha com esses cinco campos já é infinitamente melhor do que nada — e salva horas de análise quando algo quebra ou quando um auditor bate à porta.
O que vem depois
Delegação resolve o acesso administrativo. Mas existe outra categoria de conta que acumula privilégio de forma silenciosa e raramente é auditada: as contas de serviço. E é mais simples de identificar do que parece.