Active Directory Tiered Admin Model: Como Criar Camadas que Realmente Funcionam (de ESAE a RAMP)

O Que É o Active Directory Tiered Admin Model

O Active Directory Tiered Admin Model é a arquitetura de segurança que impede que um invasor que comprometeu um laptop do helpdesk chegue diretamente a Domain Admin. Ele divide cada identidade, estação de trabalho e servidor em níveis de confiança (tiers) — Tier 0 (o próprio plano de controle de identidade), Tier 1 (servidores e aplicações de negócio) e Tier 2 (estações de trabalho de usuários finais e contas padrão) — e aplica uma regra nas duas direções: credenciais de um tier superior nunca devem ser expostas a um tier inferior, e credenciais de um tier inferior nunca devem conseguir controlar um tier superior (Microsoft Learn, AD DS Tier Model).

A maioria dos ambientes que afirmam operar um modelo em camadas não o aplica de fato na prática. Domain Admins fazem RDP em servidores membros para "só checar uma coisa rápida". Uma GPO do service desk de Tier 1 é vinculada uma OU acima do necessário e acaba na OU dos domain controllers. Uma conta break-glass fica fora do grupo Protected Users porque ninguém se lembrou de adicioná-la. Cada um desses casos é pequeno isoladamente; juntos, eles derrubam o limite entre tiers que o modelo existe para proteger — e é exatamente esse tipo de desvio de acesso privilegiado que volta a se infiltrar depois de um esforço de hardening, a menos que algo continue revalidando.

Errar esse limite é caro porque o comprometimento de Tier 0 não é um incidente localizado — é total. Um invasor que obtém uma credencial de Tier 0 (via logon cross-tier, uma GPO com escopo incorreto, ou uma conta deixada fora do Protected Users) normalmente consegue fazer DCSync no diretório inteiro e forjar tickets Kerberos para qualquer identidade do domínio. O modelo em camadas existe exatamente para conter esse resultado a uma violação de Tier 0, em vez de permitir que uma única estação de trabalho de helpdesk comprometida escale para isso.

De OUs à Aplicação Prática: Como o Tiering Funciona de Verdade

Tiering não é um diagrama — é uma estrutura de OUs, um conjunto de GPOs com escopo bem definido e um limite rígido sobre onde contas privilegiadas podem fazer logon interativo.

Estrutura de OUs

Os ativos de Tier 0 (domain controllers, AD FS, servidores PKI/ADCS, infraestrutura de backup capaz de restaurar um DC, e as contas/grupos que administram qualquer um deles) ficam em uma árvore de OU de Tier 0 dedicada, separada dos servidores de Tier 1 e das estações de trabalho de Tier 2. Delegação e vínculos de GPO seguem o mesmo limite — uma GPO de hardening de estações de Tier 2 nunca deve ser vinculada perto da OU de Tier 0, e vice-versa (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).

Privileged Access Workstations (PAWs)

Contas de admin de Tier 0 só deveriam conseguir fazer logon interativo em um conjunto pequeno e dedicado de dispositivos de Tier 0 — PAWs vinculadas à sua própria OU, com GPOs de hardening (sem navegação na internet, sem e-mail, allow-listing de aplicações) restritas exclusivamente a essa OU (Microsoft Learn, PAW legacy guidance). Essa é a aplicação prática da Regra nº 1: se uma credencial de Tier 0 consegue se autenticar em um dispositivo de Tier 1 ou Tier 2, o limite já foi quebrado, independentemente do que o organograma ou o diagrama da wiki dizem.

Disciplina de Escopo de GPO

Vincule GPOs de hardening de segurança apenas na OU do tier correspondente — nunca na raiz do domínio, nunca na Default Domain Policy. Vincular uma GPO cruzando OUs de tiers diferentes é uma das formas mais comuns pelas quais os limites entre tiers se corroem silenciosamente ao longo de meses, porque ninguém percebe a adição de um vínculo da mesma forma que perceberia uma nova conta admin.

Detecção: Identificando Violações de Tier Antes de Serem Exploradas

Uma violação de tier não é um evento único — é um padrão em que uma identidade privilegiada ou um vínculo de GPO aparece onde não deveria estar. Construa detecções em torno destes sinais:

Por Que o Event ID 4672 É o Sinal de Alta Fidelidade

O Event ID 4672 ("privilégios especiais atribuídos a um novo logon") dispara imediatamente após um 4624 bem-sucedido para qualquer conta com direitos equivalentes a admin, e seu Logon ID é a chave de junção em todo o ciclo de vida da sessão — 4624 → 4672 → atividade → 4634/4647 (Microsoft Learn, Event 4672). Em uma estação de trabalho onde um Domain Admin nunca deveria fazer logon interativo, um único 4672 para essa conta é um alerta de alta fidelidade e baixo esforço — não é preciso ferramentas de UEBA para pegar o caso óbvio, apenas a regra de correlação certa no escopo de OU certo.

Remediação: Construindo Tiers que Realmente Funcionam

1. Mova contas privilegiadas para uma OU de admin de Tier 0 dedicada. Esse é o check específico que a ANSSI destaca diretamente — contas com adminCount=1 que vivem fora de uma OU dedicada e estritamente delegada quebram a segmentação da qual o resto do modelo depende (ANSSI-PA-099, "Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory", out. 2023).

2. Adicione todas as contas de Tier 0 ao Protected Users. Isso bloqueia autenticação NTLM, criptografia Kerberos DES/RC4, delegação unconstrained/constrained e TGTs de longa duração para essas contas — fechando várias das rotas de roubo de credenciais que lacunas de delegação abrem.

3. Aplique uma Fine-Grained Password Policy nos grupos de Tier 0. Domain e Enterprise Admins não deveriam herdar a política de senha padrão do domínio; uma PSO dedicada, com requisitos mais rígidos de tamanho e rotação, limita o raio de impacto caso uma credencial de Tier 0 seja exposta mesmo assim.

4. Restrinja cada GPO estritamente à sua OU de tier. Audite os vínculos de GPO existentes em busca de qualquer coisa que toque tanto uma OU de Tier 0 quanto uma OU de Tier 1/2, e separe-as. Nunca adicione configurações de aplicação de tiering à Default Domain Policy — crie GPOs dedicadas e vincule-as apenas à OU de tier relevante.

5. Implemente PAWs para logon interativo de Tier 0 e depois aplique isso tecnicamente. Use GPOs de direitos de logon (Deny log on locally / Deny log on through Remote Desktop Services) em ativos de Tier 1/2 para contas de Tier 0 — não apenas como documentação de política, porque uma regra escrita que ninguém consegue violar tecnicamente não sobrevive a um incidente.

6. Refaça a baseline trimestralmente, não apenas uma vez. Os limites entre tiers se desviam com o trabalho administrativo de rotina — um novo admin de servidor adicionado ao grupo errado, uma GPO revinculada durante uma migração, ou contas privilegiadas obsoletas que ninguém removeu do Tier 0. Um projeto de tiering feito uma única vez, sem auditoria recorrente, degrada de volta para administração plana em menos de um ano; veja o guia mais amplo de prioridades de hardening para entender como isso se encaixa em uma sequência mais ampla de hardening de AD, e as recomendações da ANSSI na prática para o checklist completo orientado a compliance do qual esse modelo faz parte.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec verifica violações do modelo de tiers diretamente contra seu diretório ao vivo: ANSSI_R15_TIER_MODEL_VIOLATION sinaliza contas privilegiadas fora de uma OU de admin dedicada, ANSSI_R40_NO_PSO_TIER0 sinaliza grupos de Tier 0 sem uma Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION verifica a segregação de trust da floresta de administração, quando uma é usada, NOT_IN_PROTECTED_USERS sinaliza contas privilegiadas ausentes do grupo Protected Users, e EXCESSIVE_PRIVILEGED_ACCOUNTS sinaliza limites de tier que cresceram demais para serem auditados manualmente.