atributos confidenciais do ad: verificar acesso de leitura

O que são atributos confidenciais do AD?

Os atributos confidenciais do ad são atributos do diretório sujeitos a uma verificação adicional de acesso de leitura. Comece por identificar quais atributos personalizados contêm realmente dados empresariais sensíveis e, em seguida, verifique quem os pode ler. Um simples lembrete de classificação não demonstra que os dados estão expostos, que um atributo não tem proteção ou que a organização incumpre um requisito de conformidade.

Este guia utiliza um exemplo restrito: um atributo personalizado aprovado para uma finalidade empresarial específica, com um responsável identificado e uma lista documentada de leitores. Descreve um procedimento de verificação em laboratório com valores fictícios. Não foi executado qualquer teste de Active Directory para este artigo, e nenhum dos resultados esperados abaixo é apresentado como um resultado observado.

O resultado útil é um registo de decisão sobre o acesso de leitura: a classificação do atributo, a sua elegibilidade no esquema, os leitores efetivos, o comportamento esperado das aplicações e qualquer diferença medida face a essa expectativa. Complete esse registo antes de propor uma alteração do esquema.

Como funciona a verificação de leitura confidencial

A definição de searchFlags em MS-ADTS identifica fCONFIDENTIAL como o bit 0x80 (128). Exige uma verificação de acesso alargada. Os outros flags têm significados distintos, pelo que importa registar o valor existente completo.

Para um atributo com esse flag, MS-ADTS Extended Access Checks exige tanto READ_PROPERTY como CONTROL_ACCESS. Sem os direitos necessários, o valor é tratado como ausente nos atributos devolvidos e no filtro LDAP. Por conseguinte, um valor ausente não basta para distinguir uma restrição de acesso de um atributo vazio.

As orientações da Microsoft sobre atributos confidenciais excluem os atributos do esquema base, identificados por FLAG_SCHEMA_BASE_OBJECT (0x10) em systemFlags. O exemplo distingue employeeID, um atributo base, de um atributo elegível. Um significado empresarial sensível não se sobrepõe a essa restrição do esquema.

As mesmas orientações explicam que Full Control inclui CONTROL_ACCESS e que concessões genéricas podem ser mais abrangentes do que ACEs específicas de um atributo. Tanto as concessões explícitas como as herdadas são relevantes. Trate uma captura de ecrã de uma entrada de permissão como um elemento da análise, em vez de uma resposta completa sobre o acesso efetivo.

Deteção: Criar um inventário de atributos aprovado

Passo 1 — Acordar a classificação e o responsável

Pergunte ao responsável pelos dados quais atributos personalizados contêm informações que exigem leitura restrita. Registe a classificação e a finalidade aprovadas sem copiar valores de produção para a análise. Um nome de campo como «private» ou «confidential» não é uma classificação aprovada.

Para cada candidato, registe o nome de apresentação LDAP, o DN do objeto do esquema, as classes de objetos em que é utilizado, o responsável empresarial, os leitores legítimos e as aplicações consumidoras. Identifique também quem pode autorizar uma alteração. Quando a responsabilidade ou a classificação não estiver resolvida, deixe a expectativa de acesso em aberto e encaminhe a questão para a equipa responsável.

Uma pequena folha de análise é mais útil do que uma lista indiscriminada de todos os atributos:

Limite o inventário aos atributos personalizados realmente sensíveis. Se a investigação descobrir credenciais em notas comuns, siga o procedimento separado de remoção da exposição de palavras-passe e de rotação. Alterar um flag de confidencialidade não substitui a resolução dessa exposição.

Passo 2 — Ler o esquema antes de considerar uma alteração

Utilize um controlador de domínio de laboratório designado e um candidato conhecido do inventário aprovado. Estes exemplos exigem o módulo PowerShell ActiveDirectory. Substitua o servidor e o atributo de exemplo pelos equivalentes do laboratório; não os execute em produção como parte deste procedimento.

A documentação de Get-ADRootDSE disponibiliza schemaNamingContext. Get-ADObject suporta filtros LDAP, uma base de pesquisa, um servidor explícito e propriedades adicionais. O exemplo seguinte combina esses parâmetros documentados apenas para leitura:

$dc = 'dc01.lab.example'
$schema = (Get-ADRootDSE -Server $dc).schemaNamingContext
Get-ADObject -Server $dc -SearchBase $schema -LDAPFilter '(lDAPDisplayName=labSensitiveReference)' -Properties lDAPDisplayName,searchFlags,systemFlags,schemaIDGUID,attributeSecurityGUID

Registe o DN do objeto devolvido e os valores completos dos flags. Se a consulta falhar ou não identificar o atributo pretendido, interrompa a avaliação desse candidato. Não transforme uma pesquisa malsucedida em «não confidencial» ou «elegível».

Verifique se o bit de confidencialidade já está presente e se o bit do esquema base exclui a utilização proposta. Conserve os valores existentes dos flags na evidência, incluindo os bits não relacionados. Nesta fase, o resultado é uma avaliação de elegibilidade, não um pedido para definir como 128 todos os campos que parecem sensíveis.

Passo 3 — Explicar o acesso de leitura efetivo

Para cada leitor aprovado e cada identidade representativa fora do conjunto de leitores aprovados, inspecione o descritor de segurança do objeto de destino e a herança relevante dos contentores ascendentes. Inclua o contexto de grupos, as negações aplicáveis, o âmbito do atributo ou conjunto de propriedades, as ACEs genéricas e qualquer herança desativada. Registe a razão da expectativa de acesso.

Verifique separadamente READ_PROPERTY e, quando a confidencialidade se aplica, CONTROL_ACCESS. A capacidade de um leitor navegar no objeto não determina a sua capacidade de obter o valor candidato. Da mesma forma, uma função de aplicação descrita de modo restrito pode receber acesso amplo através de outro grupo ou de uma entrada herdada.

Preste especial atenção a Full Control e às concessões genéricas de control-access. A questão prática é saber se essas concessões já atribuem à identidade o direito adicional, não se uma ACE contém por acaso o nome do atributo. Documente a origem da concessão para que um futuro revisor possa reproduzir o raciocínio.

Esta análise diz respeito ao contrato de leitura de um atributo personalizado. Para a investigação separada das permissões de escrita no esquema e de defaultSecurityDescriptor, utilize a auditoria das permissões do esquema e do descritor de segurança predefinido.

Verificação em laboratório: Comparar duas identidades de leitura

Passo 4 — Estabelecer um valor fictício conhecido

Prepare um objeto de teste isolado com um valor claramente artificial no atributo candidato aprovado. Peça ao operador do laboratório que confirme a existência do valor, registe o seu marcador no registo de teste e documente a preparação. Não utilize dados reais de pessoal, segredos operacionais ou uma exportação do diretório de produção.

Selecione uma identidade que o responsável tenha aprovado para ler o valor e uma identidade representativa que não o deva ler. Documente o contexto de grupos de ambas. Nenhuma identidade deve ser substituída silenciosamente pela conta de administrador utilizada para inspecionar o esquema.

Utilize o mesmo endpoint, objeto e atributo solicitado para ambas as leituras. O parâmetro credential documentado de Get-ADObject aceita um nome de conta e pede a respetiva palavra-passe. Estes são comandos propostos para laboratório, não execuções registadas:

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\ApprovedReader'

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\OutsideReader'

Inspecione a propriedade solicitada em cada objeto devolvido. Registe se contém o marcador fictício conhecido, se está ausente ou vazia, ou se o comando apresenta um erro. Mantenha as falhas de autenticação, os erros de conectividade e os dados de teste em falta separados de uma restrição de acesso.

Passo 5 — Registar a diferença sem inventar uma aprovação

A tabela seguinte especifica expectativas a avaliar; não contém qualquer resultado medido:

Se ambas as identidades lerem o marcador, investigue as concessões efetivas e o estado atual dos flags. Se nenhuma o ler, verifique primeiro a preparação do teste, o endpoint, as credenciais e a propriedade solicitada. Se o leitor aprovado tiver sucesso e o leitor externo não, conserve a evidência e o seu âmbito: a comparação abrange essas identidades e essa configuração.

Não generalize uma única comparação como prova de que todos os utilizadores ou aplicações têm restrições corretas. Acrescente grupos de leitores representativos e limites de herança de acordo com o inventário aprovado. Registe a data, o operador, o endpoint, os valores do esquema, a consulta, o contexto da identidade, o resultado e as questões por resolver para cada caso.

Para aplicações que utilizem um caminho de consulta diferente, reproduza esse caminho separadamente com dados fictícios. A especificação de searchFlags assinala diferenças de comportamento relacionadas com controlos DirSync. Registe os controlos e o comportamento do cliente quando aplicável; uma leitura PowerShell, por si só, não valida o contrato de sincronização de uma aplicação.

Correção: Decidir antes de alterar o esquema (Remediation)

Passo 6 — Selecionar a ação a partir da evidência

Se a classificação ou a responsabilidade estiver em falta, obtenha primeiro essa decisão. Se o acesso atual já corresponder ao contrato aprovado, conserve a evidência e o calendário de revisão. Se for medida uma lacuna no acesso de leitura, proponha uma correção específica com as identidades e aplicações afetadas.

Uma alteração proposta do esquema exige uma decisão documentada separada. Inclua a elegibilidade do atributo, os valores originais dos flags, os leitores necessários, o âmbito das concessões, o responsável pela implementação, o plano de compatibilidade dos consumidores, os critérios de verificação e a abordagem de reversão. Preserve os bits não relacionados de searchFlags na configuração proposta. Evite tratar 128 como um valor de substituição universal.

A Microsoft recomenda testar as alterações de atributos num laboratório que reproduza a floresta de produção. Utilize esses testes para validar a combinação exata proposta de configuração do esquema e permissões. As orientações históricas contêm instruções de ferramentas específicas de determinadas versões; avalie a sua adequação ao ambiente de destino antes da implementação.

Passo 7 — Validar a compatibilidade e a reversão

Pergunte ao responsável de cada aplicação consumidora qual operação depende do atributo e sob que identidade é executada. Valide a função aprovada com valores fictícios, incluindo a forma como a aplicação trata uma propriedade ilegível ou ausente. Uma leitura autorizada do diretório e um fluxo empresarial funcional são verificações de aceitação separadas.

Defina a reversão antes da aprovação da implementação: registe o valor original do flag do esquema, as entradas exatas de permissão envolvidas, quem as pode restaurar e como seria verificada a restauração. Restaurar uma configuração anterior pode reabrir a leitura, pelo que deve incluir essa consequência na decisão. Não descreva uma reversão como eliminando dados anteriormente lidos ou copiados.

A análise só termina quando três questões têm respostas explícitas: quais dados têm classificação e responsável aprovados; se o atributo é elegível e quais direitos efetivos dão acesso; e quais consumidores legítimos devem manter a compatibilidade após uma eventual alteração. Atribua qualquer resposta pendente a um responsável, em vez de marcar a avaliação como concluída.

Como a EtcSec deteta esta situação

DATA_CLASSIFICATION_MISSING é um lembrete informativo de análise em etc-collector. No commit do collector 0423094759d50002457031317098417993e19510, public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 define um Detect() que ignora tanto data como ctx e não utiliza qualquer provider.

Devolve sempre um único resultado com severidade Info e um Count: 1 fixo. O título, a descrição, os exemplos de dados sensíveis e as recomendações são estáticos. A contagem não representa o número de atributos expostos, classificações em falta ou testes de leitura falhados.

Este detetor não mede a classificação dos dados, a configuração de atributos confidenciais, os direitos efetivos nem a compatibilidade dos consumidores. O seu resultado não fornece evidência de exposição ou de incumprimento. Utilize-o para iniciar o inventário e o registo de decisão em laboratório descritos acima, mantendo essas observações manuais separadas da saída do detetor.

As fontes técnicas e a implementação do collector foram analisadas em 4 de outubro de 2026. A comparação em laboratório continua a ser um procedimento que o leitor deve executar com dados fictícios aprovados.