Salvaguarda de OU no AD: verificar antes da limpeza

O que faz a salvaguarda de OU no AD contra eliminações acidentais

A salvaguarda de OU no AD contra eliminações acidentais é uma medida de proteção a rever antes da limpeza do diretório. Uma unidade organizacional pode conter identidades e integrar uma hierarquia administrativa da qual outras equipas dependem. Antes de remover ou reorganizar essa hierarquia, determine quais as OU que devem permanecer, quem é responsável pela decisão e se as permissões reais do diretório oferecem a proteção pretendida.

A referência de Set-ADOrganizationalUnit da Microsoft descreve ProtectedFromAccidentalDeletion como uma propriedade booleana: quando é true, o objeto não pode ser eliminado sem alterar a propriedade. Trata-se de uma salvaguarda baseada em permissões, e não de um bloqueio imutável. Os administradores capazes de remover a proteção continuam a precisar de uma decisão operacional revista.

Este guia foi revisto em 4 de outubro de 2026 com base no Microsoft Learn e no código-fonte do coletor identificado abaixo. Todos os comandos são exemplos documentais para o leitor, não operações executadas num domínio de cliente. Não se afirma aqui que tenha ocorrido qualquer eliminação, recuperação ou verificação bem-sucedida da proteção.

Como funciona: permissões, valores predefinidos na criação e recuperação

A proteção é representada por permissões Deny

A proteção utiliza duas permissões Deny para Everyone, identificado pelo SID S-1-1-0: Delete e Delete Subtree. As orientações da Microsoft para prevenir eliminações acidentais descrevem ACE Deny para DELETE e DELETE TREE no objeto. Descrevem também uma negação complementar de DELETE CHILD no objeto pai. Reveja o objeto e o respetivo pai quando o comportamento das permissões não for claro; não equipare uma única ACE correspondente a uma avaliação completa das permissões efetivas.

No Active Directory Users and Computers, ative as funcionalidades avançadas para apresentar o separador Objeto e a respetiva caixa de proteção. Para rever as permissões, inspecione as entradas avançadas do separador Segurança, o respetivo destinatário, os direitos negados e o âmbito. As orientações de prevenção acima citadas documentam a caixa de seleção e o modelo de permissões subjacente. Mantenha um registo das entradas relevantes em vez de depender apenas de uma captura de ecrã com a caixa selecionada.

Esta distinção é relevante ao comparar ferramentas. Uma propriedade expandida apresenta uma visão administrativa da proteção, enquanto um detetor pode reconhecer apenas um subconjunto das representações de permissões. Uma revisão de ACL deve também considerar o objeto pai e o âmbito de cada entrada. Se estas observações divergirem, conserve a divergência e investigue-a antes de alterar permissões.

A proteção predefinida na criação não audita as OU existentes

O exemplo 1 de New-ADOrganizationalUnit cria uma OU protegida sem definir explicitamente o parâmetro de proteção. O exemplo 2 cria explicitamente uma OU desprotegida com $False. Por isso, o valor predefinido atual na criação não estabelece o estado de OU mais antigas, migradas ou posteriormente modificadas. A proteção pode ser diferente e tem de ser lida.

O nosso guia de contentores predefinidos e redirecionamento utiliza essa proteção implícita ao criar OU de destino para redircmp e redirusr. O seu tema é a localização e o âmbito da Política de Grupo. Rever as salvaguardas de eliminação de uma OU existente é uma tarefa separada; o exemplo de criação não fornece um inventário nem uma aprovação para a limpeza.

A prevenção e a recuperação respondem a perguntas diferentes

A proteção procura evitar uma operação acidental. As cópias de segurança e a recuperação de objetos tratam do que acontece depois da perda de dados. As orientações da Microsoft sobre Recycle Bin explicam que esta funcionalidade apenas permite recuperar objetos eliminados após a sua ativação. Verifique separadamente o estado real da funcionalidade e a preparação para a recuperação.

O nosso guia de recuperação da floresta Active Directory e validação de cópias de segurança explica a seleção de cópias de segurança, as evidências de restauro e os limites de Recycle Bin. Utilize-o para a revisão complementar da recuperação. Nem uma OU protegida nem um Recycle Bin disponível prova que a recuperação de uma floresta tenha sido validada. Da mesma forma, a preparação da recuperação não justifica deixar uma OU de produção desprotegida sem uma exceção aceite.

Deteção: inventariar de forma independente e ler a DACL

1. Estabelecer uma recolha bem-sucedida com âmbito definido

Utilize um computador de administração autorizado com o módulo Active Directory PowerShell. Registe o domínio, o servidor consultado, a hora da recolha, o contexto das credenciais e o âmbito da pesquisa. Uma leitura falhada ou parcial deve constar das evidências como um problema de recolha por resolver. Não classifique um objeto ilegível como desprotegido nem interprete um resultado vazio como um inventário concluído.

O exemplo seguinte para o leitor adapta os parâmetros documentados Filter e Properties de Get-ADOrganizationalUnit. Solicita explicitamente a propriedade expandida:

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Escolha o domínio e o servidor pretendidos em vez de aceitar silenciosamente os valores predefinidos do computador de administração. O Learn documenta também Server, SearchBase e SearchScope para definir esse contexto. O comando acima é um ponto de partida para o inventário, não uma garantia de cobertura completa de toda a floresta nem uma instrução para modificar todos os resultados.

Para cada OU lida com êxito, conserve o distinguished name e o GUID do objeto juntamente com o valor da propriedade. Acrescente a equipa de negócio ou de infraestrutura responsável, a finalidade pretendida e qualquer proposta de decisão de limpeza. A equipa responsável é um dado para a revisão; não presuma que um atributo ou um nome de OU prova quem pode aprovar a eliminação.

2. Ler as permissões independentemente do coletor

Para um objeto específico, o exemplo seguinte solicita tanto a propriedade de proteção como o descritor de segurança através do mesmo mecanismo documentado Properties. O DN de Fabrikam é um exemplo fictício a substituir pelo destino revisto:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Inspecione a DACL do descritor de segurança devolvido com uma ferramenta autorizada de administração do diretório ou utilize a vista avançada de Segurança no Active Directory Users and Computers. Confirme Everyone através do SID, em vez de depender de um nome de apresentação localizado. Examine as negações de Delete e Delete Subtree, se se aplicam ao objeto e as permissões relevantes do objeto pai. Conserve as evidências de permissões em bruto ou exportadas, quando disponíveis.

Esta leitura independente deve preservar as entradas Deny. Reutilizar a lista de ACL filtrada pelo coletor reproduz precisamente a limitação em investigação. Se o acesso ao descritor falhar, registe a falha e obtenha o acesso de leitura adequado através do processo normal de administração. Um valor de propriedade e uma leitura falhada da DACL devem continuar a ser distinguíveis.

3. Conciliar os findings com as evidências do diretório

Compare o inventário do coletor com o inventário administrativo lido com êxito. Utilize identificadores de objetos e os DN reais para investigar discrepâncias. Uma diferença de grafia ou de maiúsculas e minúsculas deve motivar uma conciliação, e não a decisão de que dois registos descrevem necessariamente objetos diferentes. Preserve os valores originais para poder explicar a pesquisa do coletor sensível a maiúsculas e minúsculas.

Um finding não fornece uma cronologia de ataque nem um histórico de eliminações. Não deduza comprometimento, intenção maliciosa ou um incidente concluído a partir deste sinal de configuração. Se ocorreu uma eliminação real, a respetiva investigação e recuperação precisam de evidências separadas.

Correção: proteger OU selecionadas e limitar as exceções de limpeza (Remediation)

1. Decidir o estado pretendido com o responsável

Comece pelo inventário conciliado. Identifique as OU de produção a manter, as hierarquias de preparação, as exceções de migração e os objetos propostos para remoção. Peça à equipa responsável que confirme as dependências e os objetos exatos abrangidos pela alteração. Uma OU aparentemente vazia não constitui, por si só, um pedido de limpeza aprovado.

Registe as evidências atuais da propriedade e da DACL, o responsável pela decisão, o identificador do destino, o estado pretendido e o método de verificação. Reveja quem pode alterar as permissões relevantes. A proteção não substitui essa revisão administrativa, uma cópia de segurança utilizável ou um plano de recuperação de objetos. Se a recolha ou a responsabilidade continuar incerta, mantenha o item aberto em vez de transformar a incerteza numa alteração em massa.

2. Ativar a proteção numa OU aprovada que será mantida

Este exemplo para o leitor utiliza os parâmetros documentados Identity e ProtectedFromAccidentalDeletion de Set-ADOrganizationalUnit, definindo o booleano como true para um destino fictício. É um exemplo de modificação direcionada, não uma recomendação para encaminhar todo o inventário para uma alteração:

Set-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -ProtectedFromAccidentalDeletion $True

Aplique a alteração apenas ao objeto revisto através do fluxo autorizado de administração. Guarde qualquer erro e o resultado real da operação. Um pedido para definir um valor é uma evidência diferente de uma atualização bem-sucedida do diretório. Se a alteração falhar, investigue o acesso e o contexto do destino antes de repetir ou alargar permissões.

3. Voltar a ler o objeto e as permissões relevantes

Após uma alteração bem-sucedida, consulte novamente o destino de forma independente:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Confirme a propriedade e inspecione a DACL utilizando o contexto de recolha registado. Preserve as evidências anteriores e posteriores e qualquer discrepância restante. Se outro servidor fizer parte do plano de verificação, registe essa leitura separada em vez de presumir que todas as vistas do diretório já são idênticas. Encerre a alteração apenas com base nas evidências de aceitação pretendidas.

Não tente eliminar um objeto de produção para demonstrar que a proteção funciona. Este guia exige uma nova leitura bem-sucedida e uma revisão das permissões; não prescreve um teste destrutivo. Uma contagem do coletor que permaneça inalterada também é insuficiente para declarar esta modificação malsucedida, devido ao defeito do provider descrito abaixo.

4. Limitar a remoção da proteção à operação aprovada

A referência Set da Microsoft inclui um exemplo com $false para remover a proteção. Essa alteração só deve integrar uma decisão de limpeza ou migração aprovada separadamente. Registe o destino exato, o motivo, o operador e o período da exceção. Evite remover as salvaguardas de uma hierarquia inteira apenas para simplificar uma operação.

Depois do trabalho aprovado, volte a aplicar a proteção aos objetos mantidos que foram temporariamente isentados e repita a revisão da propriedade e da DACL. Se o objeto foi eliminado intencionalmente, conserve a aprovação e as evidências da operação; não existe um objeto sobrevivente a proteger novamente. Uma limpeza abandonada ou falhada não deve deixar silenciosamente as OU mantidas sem a salvaguarda pretendida.

Como o EtcSec deteta esta situação

A verificação revista de etc-collector é OU_UNPROTECTED, em public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. O detetor e o provider LDAP foram lidos no commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; o mesmo comportamento relevante foi também inspecionado no HEAD do coletor 42bfefbace3189588e76ff291c39e100c6a603a0.

O detetor constrói um conjunto de DN de objetos protegidos a partir das entradas ACL fornecidas. Uma entrada só se qualifica quando o seu tipo corresponde ao nome de tipo exato ACCESS_DENIED, o seu destinatário é igual a S-1-1-0 e a sua máscara de acesso contém DELETE (0x10000). A comparação do nome de tipo utiliza strings.EqualFold, pelo que ignora maiúsculas e minúsculas nessa comparação; ACCESS_DENIED_OBJECT é um tipo diferente e não se qualifica.

Em seguida, procura cada ou.DN inventariado nesse conjunto utilizando a chave de cadeia de caracteres ObjectDN. Esta correspondência de DN é sensível a maiúsculas e minúsculas. As OU sem correspondência contribuem para o Count de um único finding de gravidade Low. O finding é devolvido mesmo com contagem zero; as entidades OU afetadas só são acrescentadas quando são pedidos detalhes e a contagem é positiva.

Apesar do comentário mais abrangente sobre Delete e Delete Subtree, o predicado não testa DELETE_TREE (0x40). Também não testa DELETE CHILD no pai, flags de âmbito das ACE ou direitos efetivos de eliminação. Uma negação de Delete que se qualifique basta para integrar o conjunto protegido, pelo que o predicado do detetor, por si só, não pode validar a salvaguarda completa.

O provider impede uma deteção fiável de ponta a ponta neste percurso revisto. Em public/internal/providers/ldap/acl_parser.go:276, parseACE conserva apenas ACE Allow. As linhas 297–300 devolvem nil para tipos diferentes de ACCESS_ALLOWED e ACCESS_ALLOWED_OBJECT, eliminando as ACE Deny que este detetor espera. Com essa entrada filtrada, o conjunto protegido pode permanecer vazio e a contagem pode abranger todas as OU inventariadas, incluindo OU que estão efetivamente protegidas.

Esta é uma limitação da recolha que exige uma verificação independente da propriedade e da DACL, não uma medição fiável da ausência de proteção. Corrigir o provider compete à equipa do coletor e está fora do âmbito deste artigo. Não se afirma qualquer sucesso de deteção de ponta a ponta nem qualquer contagem de cliente.