O modelo de administração em camadas do Active Directory explicado

Um administrador de domínio faz login no laptop de um usuário para resolver um problema de impressora. Malware já presente nesse laptop lê a credencial da memória do Local Security Authority Subsystem Service (LSASS) e a reproduz pelo ambiente, e o plano de controle de identidade de todo o domínio agora está acessível a partir de uma máquina do help desk.

Isso acontece constantemente, e os números comprovam. O Netwrix 2026 Data and Identity Security Report constatou que 75% das exposições de dados sensíveis começam com identidades comprometidas ou permissões mal configuradas. A maioria começa com uma credencial privilegiada na memória de uma máquina não confiável.

A pergunta óbvia é por que os controles que a maioria das organizações já utiliza falharam em impedir isso. A autenticação multifator (MFA), privileged access management (PAM) e o Acesso Condicional atuam na credencial somente quando ela chega ao dispositivo, o que é tarde demais para ajudar. O modelo de administração em camadas funciona antes, governando onde uma credencial privilegiada pode aparecer desde o início.

O que é o modelo de administração em camadas do Active Directory?

O modelo de administração em camadas do Active Directory (AD) é um design de acesso privilegiado que separa contas, sistemas e ferramentas administrativas em Camada 0, Camada 1 e Camada 2, de acordo com seu escopo de controle sobre o ambiente. Sua regra de segurança principal é que as credenciais de camadas superiores se autenticam apenas em sistemas aprovados em sua camada designada, o que reduz o roubo de credenciais e o movimento lateral.

O princípio subjacente é que o teclado, e não o sistema alvo, define o nível de confiança efetivo de uma sessão. Uma credencial de Domain Admin inserida em um laptop de help desk carrega a exposição desse laptop diretamente para o controlador de domínio que ele gerencia. A documentação do modelo de níveis AD da Microsoft trata, portanto, a estação de trabalho administrativa como parte da fronteira de segurança.

Unidades organizacionais (OUs), grupos e Group Policy Objects (GPOs) são geralmente o ponto de partida das equipes e organizam apenas os objetos aos quais o modelo se aplica. A separação de níveis ocorre por meio de contas dedicadas por nível, aplicação de login, estações de trabalho administrativas, delegação deliberada, monitoramento e um processo para revisar exceções.

Por que a hierarquização do Active Directory ainda importa

A estratificação precede a maioria das ferramentas atualmente vendidas para resolver o acesso privilegiado. Organizações que utilizam MFA, Privileged Access Management e Acesso Condicional ainda carregam a exposição que ela foi criada para fechar, e as razões se resumem ao raio de impacto, caminho de ataque e cobertura.

Contém um raio de explosão que abrange todo o ambiente

A estratificação limita até onde uma credencial exposta pode alcançar, o que é mais importante no AD porque o AD é o plano de controle de identidade. Contas privilegiadas e os serviços por trás delas controlam o acesso, autenticação, políticas e recuperação para cada sistema que confia no domínio.

Sem esse limite, uma única credencial de administrador de diretório é suficiente para alcançar tudo. Recuperar um servidor membro leva uma tarde, enquanto recuperar um plano de controle de identidade que um invasor teve direitos administrativos é um projeto de recuperação florestal.

Fecha o caminho que a maioria das violações realmente usa

O tiering bloqueia a única pré-condição da qual a maioria das violações de domínio depende: uma credencial de maior privilégio aparecendo em uma estação de trabalho de menor confiança. Pass-the-hash, despejo de credenciais LSASS e roubo de ticket Kerberos precisam que isso tenha acontecido primeiro.

Remover a pré-condição, em vez de detectar cada técnica, torna o controle duradouro, pois resiste a ferramentas que ninguém criou ainda.

Preenche uma lacuna que Privileged Access Management e MFA não conseguem cobrir sozinhos

A estratificação governa onde uma credencial pode ser usada, que é a única questão que os outros controles deixam em aberto. As estações de trabalho de acesso privilegiado (PAWs) estabelecem confiança no endpoint, PAM e o acesso just-in-time (JIT) governam a duração, e MFA e o Acesso Condicional governam a força da autenticação.

O token theft playbook da Microsoft mostra como a força da autenticação ajuda pouco uma vez que uma credencial já está em um endpoint comprometido, pois um invasor que rouba e reproduz um token emitido obtém acesso mesmo que o usuário tenha satisfeito o MFA.

Os três níveis de administração do Active Directory

Cada nível agrupa ativos e identidades administrativas conforme o controle que possuem, e os requisitos para estação de trabalho e login se tornam mais rigorosos à medida que esse controle aumenta. O nível de um sistema é determinado pelo que ele pode alcançar.

Nível 0: O plano de controle de identidade

O Nível 0 contém todos os ativos que controlam o serviço de diretório, direta ou indiretamente. O inventário da Microsoft cobre controladores de domínio e Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS) e a infraestrutura de chave pública (PKI) por trás disso, além do Active Directory Federation Services (AD FS). Microsoft Entra Connect e as próprias contas e grupos do Nível 0 também pertencem aqui.

Sistemas de backup capazes de restaurar um controlador de domínio também pertencem aqui. Qualquer coisa que possa restaurar um controlador de domínio também pode reconstruí-lo nos termos de um invasor.

Os administradores Tier 0 trabalham apenas a partir de Tier 0 PAWs, usando contas dedicadas de Tier 0. Proteger controladores de domínio começa controlando quais credenciais podem alcançá-los.

Nível 1: Servidores, cargas de trabalho e aplicações empresariais

O Nível 1 cobre servidores membros, aplicações, bases de dados e as contas que os administram, correspondendo aos planos de gestão e dados/carga de trabalho no Enterprise Access Model da Microsoft.

Na prática, isso significa servidores de arquivos, SQL Server, Exchange Server, aplicativos de linha de negócios e plataformas de virtualização limitadas a cargas de trabalho Tier 1. A restrição funciona em ambas as direções. Um administrador Tier 1 faz login apenas em sistemas Tier 1, e sistemas Tier 1 iniciam apenas administração Tier 1.

Nível 2: Estações de trabalho e suporte ao usuário

O Nível 2 tem a maior exposição dos três, devido ao que acontece nesses endpoints todos os dias. Os usuários navegam na web, abrem anexos, instalam software e absorvem as tentativas de phishing que iniciam a maioria das intrusões.

Abrange estações de trabalho de usuários finais, laptops, contas de usuário e as identidades que as suportam. O trabalho do help desk ocorre aqui, cobrindo redefinições de senha, suporte a estações de trabalho e solução de problemas de endpoint, e os direitos de conta do Nível 2 permanecem limitados aos recursos do Nível 2.

Como implementar o modelo de níveis no Active Directory

A implementação começa com um inventário preciso e termina com a aplicação que resiste a um administrador local. A Microsoft trata sua sequência recomendada como um caminho, não como uma cadeia rígida de dependências, permitindo que as fases posteriores ocorram em paralelo.

1. Inventariar cada conta e ativo privilegiado

Catalogue todos os sistemas AD, contas e ferramentas com alcance administrativo. Os indiretos são os mais importantes, pois nada indica que podem alcançar Tier 0. Essa lista inclui service accounts, plataformas de backup que podem restaurar controladores de domínio, a infraestrutura de chave pública e Entra Connect, que a Microsoft classifica como um componente Tier 0.

Apenas 36% das organizações realizaram uma avaliação completa de segurança de AD nos últimos 12 meses, segundo o Netwrix 2026 Data and Identity Security Report, portanto a maioria dos inventários começa do zero, e não a partir de um registro existente.

2. Classifique cada ativo pelo que ele pode controlar

Qualquer conta ou sistema que possa gerenciar um nível superior pertence a esse nível, independentemente de onde foi destinado a estar.

Plataformas de backup, hosts de virtualização executando máquinas virtuais Tier 0, agentes de endpoint detection and response em controladores de domínio e direitos de gerenciamento de Group Policy pertencem todos ao Tier 0 quando podem acessar ativos Tier 0. A Microsoft Incident Response documentou o custo de errar: um misconfigured PAM server situado no Tier 1 detinha as chaves do Tier 0 e deu aos atacantes uma rota através da fronteira.

3. Crie contas separadas para cada nível

Forneça aos administradores contas distintas por nível, sem sobreposição. Isso significa uma conta identity-admin do Tier 0, uma conta server-admin do Tier 1 e credenciais padrão para uso diário para todo o resto.

O plano de modernização rápida da Microsoft tem como alvo 100% dos usuários privilegiados locais que possuem contas dedicadas separadas. A separação de contas também permite a aplicação do login, pois uma única conta usada em vários níveis não oferece nada a restringir.

4. Aplicar restrições de logon no controlador de domínio e no endpoint

Implemente ambos os mecanismos disponíveis em vez de escolher entre eles. Group Policy oferece ampla cobertura nos endpoints, e as políticas de autenticação Kerberos adicionam uma barreira que o controlador de domínio aplica por si mesmo, que é a parte que ainda se mantém após uma máquina de nível inferior ser totalmente comprometida.

Restrições de logon baseadas em GPO negam direitos de logon interativos, Remote Desktop Protocol (RDP), de rede, em lote e de serviço para contas de nível superior em endpoints de nível inferior por meio da Atribuição de Direitos de Usuário. A Autoridade de Segurança Local do endpoint as aplica, razão pela qual a Microsoft reconhece que um administrador local pode contornar a Política de Grupo e que a restrição se aplica apenas a máquinas Windows ingressadas no AD.

As políticas de autenticação Kerberos e os silos de políticas de autenticação restringem de onde uma credencial privilegiada pode se originar, e o Centro de Distribuição de Chaves (KDC) do controlador de domínio aplica a verificação ao emitir um ticket. O AD recusa emitir um Ticket Granting Ticket de um computador não autorizado, mesmo que as credenciais estejam corretas.

Ambos os mecanismos possuem pré-requisitos fáceis de serem ignorados. As verificações do dispositivo de origem precisam que o Kerberos armoring, também chamado de Flexible Authentication Secure Tunneling, esteja habilitado nos controladores de domínio e clientes. As políticas de autenticação também isentam a conta integrada de Administrador de domínio, que deve ser controlada separadamente.

5. Dê a cada nível sua própria estação de trabalho reforçada

Implemente um PAW por nível para que o ambiente imponha a separação em vez de depender que um administrador lembre uma regra sob pressão de tempo. A orientação da Microsoft é que o modelo de níveis depende da administração iniciando a partir de uma estação de trabalho confiável que corresponda ao nível administrado.

Um PAW de Nível 0 segue restrições rigorosas de aplicação que removem email, navegação e software de produtividade, que são as rotas de entrega para malware que coleta credenciais. Combinar o PAW com Windows Defender Credential Guard mantém as credenciais derivadas fora do alcance na própria máquina.

6. Implementar em fases, começando pelo Tier 0

Proteja primeiro o Tier 0, abrangendo contas, PAWs e aplicação, antes de estender o mesmo processo para o Tier 1 e depois para o Tier 2. As fases posteriores dependem de um plano de controle de identidade limpo.

Teste as GPOs de aplicação fora da produção antes que elas cheguem a um domínio ativo, pois a Microsoft alerta que a ordem incorreta dos links pode bloquear os administradores de domínio em todos os sistemas Windows do domínio, incluindo os controladores de domínio.

Erros comuns a evitar ao implementar o modelo de níveis no Active Directory

A maioria dos programas de classificação são bem projetados e depois prejudicados pela lacuna entre o design e o que realmente é aplicado. Cada erro amplia essa lacuna de forma previsível, e cada um surge meses após o fechamento do projeto.

Tratar o tiering como um projeto de redesign de OU

Criar apenas as OUs Tier 0, Tier 1 e Tier 2 deixa as contas privilegiadas livres para autenticar em qualquer lugar. As políticas de autenticação e os direitos de negação do GPO aplicam o limite, enquanto a estrutura do contêiner apenas organiza a que esses controles se aplicam.

Configure as restrições de logon antes de mover os objetos AD para a nova estrutura de OU, pois as regras de negação têm precedência sobre as regras de permissão e uma estrutura parcialmente migrada pode causar surpresas em qualquer direção.

Permitir contas e endpoints de uso duplo

Mantenha as credenciais Tier 0 em endpoints administrativos dedicados. A Microsoft Incident Response encontra repetidamente que administradores que usam dispositivos administrativos comuns para o trabalho diário deixam credenciais privilegiadas que ferramentas de extração de credenciais podem capturar.

Contas separadas e PAWs são controles, não conveniências, e abandoná-los sob pressão de tempo é a forma mais comum de o tiering parar de funcionar silenciosamente.

Supervisão de contas de serviço e automação

Tarefas agendadas, ferramentas de implantação, scripts e contas de serviço precisam da mesma disciplina de nível que os administradores humanos, ou seja, um proprietário nomeado, least privilege e um caminho de autenticação alinhado ao nível.

Negue direitos de logon interativo para contas de serviço e mantenha o caminho de autenticação de cada serviço dentro de seu nível atribuído. Group Managed Service Accounts ajudam removendo a senha estática compartilhada que torna uma conta de serviço portátil entre níveis.

Lacunas no monitoramento de logon entre níveis

Fique atento a uma credencial Tier 0 autenticando em um sistema Tier 1 ou Tier 2. A Microsoft classifica o Evento 4964 como de alta criticidade e aconselha que um login de Domain Admin em uma estação de trabalho de usuário final deve disparar tanto um alerta quanto uma investigação.

Falhas de logon e uso explícito de credenciais, IDs de evento 4625 e 4648, são sinais úteis de investigação junto com alterações na associação ao privileged-group, edições de GPO e exceções concedidas uma vez e nunca revisadas. Configure a política de auditoria explicitamente, pois muitas configurações de GPO relacionadas à auditoria vêm como Não Configurado.

Como a Netwrix suporta a visibilidade em níveis e evidências de auditoria

A estratificação é uma decisão de design e aplicação que a organização possui. As ferramentas cobrem o que o design não pode fazer sozinho: provar que os limites ainda se mantêm meses depois e remover as credenciais permanentes que tornam a travessia válida.

Netwrix Auditor rastreia alterações privilegiadas em todos os níveis

Netwrix Auditor é um produto de auditoria de TI local que rastreia alterações privilegiadas no AD, mudanças na associação de grupos, modificações de GPO e mudanças de permissões com valores antes e depois. Seus relatórios respondem quem mudou o quê, quando e onde, até a estação de trabalho de origem.

Várias dessas capacidades se relacionam diretamente com a aplicação de níveis. A análise de tentativas de login falhadas revela as tentativas de autenticação que uma restrição entre níveis acabou de bloquear, mostrando que a aplicação está funcionando, não apenas configurada.

Alertas de detecção de escalonamento de privilégios ocorrem quando uma conta obtém acesso elevado que não possuía anteriormente, e a detecção de anomalias sinaliza comportamentos administrativos que se desviam da linha de base da conta. A cobertura se estende ao Entra ID junto com o AD local, para que um mapa de níveis híbrido permaneça visível em um só lugar.

Flagler Bank obteve uma visão contínua do seu perfil de risco de TI com um departamento de TI de uma pessoa, reduzindo investigações de horas para 10 minutos e alcançando o primeiro valor 30 minutos após a configuração.

Netwrix Privilege Secure suporta separação de contas e acesso just-in-time

Netwrix Privilege Secure fornece acesso privilegiado limitado à tarefa e cria uma trilha de auditoria para cada sessão. Cria uma conta efêmera para a sessão e a destrói depois, de modo que a credencial privilegiada exista apenas enquanto o trabalho aprovado estiver sendo realizado.

Isso é importante porque 76% das organizações não conseguem revogar imediatamente o acesso permanente quando ele não é mais necessário, segundo o Netwrix 2026 Data and Identity Security Report.

Eastern Carver County Schools substituiu privilégios permanentes por acesso just-in-time em sistemas que armazenam dados de 9.300 alunos, concluindo a implantação em dias e eliminando a confusão na auditoria causada pelos direitos administrativos permanentes.

Nenhum dos produtos implementa o modelo de níveis em si; ambos existem para provar que ele ainda funciona após o término do trabalho de design.

Comece com Tier 0, depois torne o modelo operacional

Um programa de níveis torna-se operacional quando a equipe pode mostrar que as credenciais de nível superior permaneceram dentro dos caminhos de autenticação aprovados, que um responsável revisou cada exceção e que a trilha de auditoria prova que a aplicação foi mantida. Logons bloqueados entre níveis, mudanças em grupos privilegiados, idade das exceções e propriedade do controle são as medidas que valem a pena acompanhar.

Para a maioria das organizações, o ponto de partida eficaz não é um redesenho. Faça o inventário e proteja o plano de controle de identidade Tier 0, emita contas Tier 0 separadas, implemente PAWs reforçados e aplique restrições de login tanto no endpoint quanto no KDC.

Solicite uma demonstração para ver como a Netwrix rastreia alterações privilegiadas entre níveis, sinaliza logons entre níveis e mantém as evidências de auditoria que comprovam que os limites estão sendo respeitados.