Attributi riservati AD: verificare l'accesso in lettura

Che cosa sono gli attributi riservati AD?

Gli attributi riservati AD sono attributi della directory soggetti a un controllo aggiuntivo dell'accesso in lettura. Iniziate identificando quali attributi personalizzati contengono effettivamente dati aziendali sensibili, poi verificate chi può leggerli. Un semplice promemoria sulla classificazione non dimostra che i dati siano esposti, che un attributo sia privo di protezione o che l'organizzazione non rispetti un requisito di conformità.

Questa guida usa un esempio circoscritto: un attributo personalizzato approvato per uno specifico scopo aziendale, con un responsabile designato e un elenco documentato di lettori. Descrive una procedura di verifica in laboratorio con valori fittizi. Per questo articolo non è stato eseguito alcun test di Active Directory e nessuno degli esiti attesi riportati di seguito viene presentato come un risultato osservato.

Il documento utile da produrre è un registro delle decisioni sull'accesso in lettura: classificazione dell'attributo, idoneità a livello di schema, lettori effettivi, comportamento previsto delle applicazioni ed eventuali differenze misurate rispetto a tale aspettativa. Completate questo registro prima di proporre una modifica allo schema.

Come funziona il controllo della lettura riservata

La definizione di searchFlags in MS-ADTS identifica fCONFIDENTIAL come il bit 0x80 (128). Richiede un controllo di accesso esteso. Gli altri flag hanno significati distinti, quindi è importante registrare l'intero valore esistente.

Per un attributo con quel flag, MS-ADTS Extended Access Checks richiede sia READ_PROPERTY sia CONTROL_ACCESS. Senza i diritti richiesti, il valore viene trattato come assente negli attributi restituiti e nel filtro LDAP. Un valore assente, quindi, non basta a distinguere una restrizione di accesso da un attributo vuoto.

Le indicazioni Microsoft sugli attributi riservati escludono gli attributi dello schema di base, identificati da FLAG_SCHEMA_BASE_OBJECT (0x10) in systemFlags. L'esempio distingue employeeID, un attributo di base, da un attributo idoneo. Un significato aziendale sensibile non prevale su questa restrizione dello schema.

Le stesse indicazioni spiegano che Full Control include CONTROL_ACCESS e che le concessioni generiche possono essere più ampie delle ACE specifiche dell'attributo. Contano sia le concessioni esplicite sia quelle ereditate. Considerate la schermata di una singola voce di autorizzazione come un elemento della revisione, anziché come una risposta completa sull'accesso effettivo.

Rilevamento: creare un inventario approvato degli attributi

Passo 1 — Concordare la classificazione e il responsabile

Chiedete al responsabile dei dati quali attributi personalizzati contengono informazioni che richiedono una lettura limitata. Registrate la classificazione e lo scopo approvati senza copiare valori di produzione nella revisione. Un nome di campo come «private» o «confidential» non costituisce una classificazione approvata.

Per ogni candidato, registrate il nome visualizzato LDAP, il DN dell'oggetto dello schema, le classi di oggetti in cui viene usato, il responsabile aziendale, i lettori legittimi e le applicazioni che lo utilizzano. Identificate anche chi può autorizzare una modifica. Quando la responsabilità o la classificazione resta irrisolta, lasciate irrisolta l'aspettativa di accesso e indirizzate la domanda al team responsabile.

Una piccola scheda di revisione è più utile di un elenco indiscriminato di tutti gli attributi:

Limitate l'inventario agli attributi personalizzati effettivamente sensibili. Se l'indagine scopre credenziali in normali note, seguite il processo separato di rimozione dell'esposizione delle password e rotazione. Modificare un flag di riservatezza non sostituisce la gestione di tale esposizione.

Passo 2 — Leggere lo schema prima di considerare una modifica

Usate un controller di dominio di laboratorio designato e un candidato noto dell'inventario approvato. Questi esempi richiedono il modulo PowerShell ActiveDirectory. Sostituite il server e l'attributo di esempio con gli equivalenti di laboratorio; non eseguiteli in produzione nell'ambito di questa procedura.

La documentazione di Get-ADRootDSE espone schemaNamingContext. Get-ADObject supporta filtri LDAP, una base di ricerca, un server esplicito e proprietà aggiuntive. Quella seguente è una combinazione illustrativa di sola lettura di questi parametri documentati:

$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

Registrate il DN dell'oggetto restituito e i valori completi dei flag. Se la query fallisce o non identifica l'attributo previsto, interrompete la valutazione di quel candidato. Non trasformate una ricerca non riuscita in «non riservato» o «idoneo».

Verificate se il bit di riservatezza è già presente e se il bit dello schema di base esclude l'uso proposto. Conservate i valori esistenti dei flag nelle evidenze, compresi i bit non pertinenti. In questa fase, il risultato è una valutazione di idoneità, non una richiesta di impostare a 128 ogni campo che sembra sensibile.

Passo 3 — Spiegare l'accesso effettivo in lettura

Per ogni lettore approvato e ogni identità rappresentativa esterna all'insieme dei lettori approvati, esaminate il descrittore di sicurezza dell'oggetto di destinazione e l'ereditarietà pertinente dei contenitori padre. Includete il contesto dei gruppi, le negazioni applicabili, l'ambito dell'attributo o dell'insieme di proprietà, le ACE generiche e qualsiasi ereditarietà disabilitata. Registrate il motivo dell'aspettativa di accesso.

Verificate separatamente READ_PROPERTY e, quando si applica la riservatezza, CONTROL_ACCESS. La possibilità per un lettore di esplorare l'oggetto non determina la sua capacità di ottenere il valore del candidato. Analogamente, un ruolo applicativo descritto come limitato può comunque ricevere un accesso ampio tramite un altro gruppo o una voce ereditata.

Prestate particolare attenzione a Full Control e alle concessioni generiche di controllo di accesso. La domanda pratica è se tali concessioni assegnino già a un'identità il diritto aggiuntivo, non se un'ACE contenga il nome dell'attributo. Documentate l'origine della concessione affinché un futuro revisore possa riprodurre il ragionamento.

Questa revisione riguarda il contratto di lettura di un attributo personalizzato. Per l'indagine separata sulle autorizzazioni di scrittura dello schema e su defaultSecurityDescriptor, usate l'audit delle autorizzazioni dello schema e del descrittore di sicurezza predefinito.

Verifica in laboratorio: confrontare due identità di lettori

Passo 4 — Predisporre un valore fittizio noto

Preparate un oggetto di test isolato con un valore chiaramente artificiale nell'attributo candidato approvato. Chiedete all'operatore del laboratorio di confermare che il valore esista, registrate il suo marcatore nel registro del test e documentate la preparazione. Non usate dati reali del personale, segreti operativi o un'esportazione di una directory di produzione.

Selezionate un'identità che il responsabile abbia approvato per leggere il valore e un'identità rappresentativa che non debba leggerlo. Documentate il loro contesto di gruppo. Nessuna delle due identità deve essere sostituita silenziosamente con l'account amministratore usato per esaminare lo schema.

Usate lo stesso endpoint, oggetto e attributo richiesto per entrambe le letture. Il parametro delle credenziali documentato di Get-ADObject accetta un nome account e ne richiede la password. Questi sono comandi proposti per il laboratorio, non esecuzioni registrate:

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'

Esaminate la proprietà richiesta in ciascun oggetto restituito. Registrate se contiene il marcatore fittizio noto, se è assente o vuota oppure se il comando genera un errore. Distinguete autenticazioni fallite, errori di connettività e dati di test mancanti da una restrizione di accesso.

Passo 5 — Registrare la differenza senza inventare un esito positivo

La tabella seguente specifica le aspettative da valutare; non contiene alcun risultato misurato:

Se entrambe le identità leggono il marcatore, esaminate le concessioni effettive e lo stato attuale dei flag. Se nessuna lo legge, verificate prima la predisposizione del test, l'endpoint, le credenziali e la proprietà richiesta. Se il lettore approvato riesce e quello esterno no, conservate le evidenze e il relativo ambito: il confronto copre quelle identità e quella configurazione.

Non generalizzate un singolo confronto come prova che tutti gli utenti o tutte le applicazioni siano correttamente limitati. Aggiungete gruppi di lettori rappresentativi e confini di ereditarietà secondo l'inventario approvato. Registrate data, operatore, endpoint, valori dello schema, query, contesto dell'identità, esito e domande irrisolte per ogni caso.

Per le applicazioni che usano un percorso di query diverso, riproducete quel percorso separatamente con dati fittizi. La specifica di searchFlags segnala differenze di comportamento relative ai controlli DirSync. Registrate i controlli e il comportamento del client quando pertinenti; una lettura PowerShell da sola non convalida il contratto di sincronizzazione di un'applicazione.

Correzione: decidere prima di modificare lo schema (Remediation)

Passo 6 — Scegliere l'azione in base alle evidenze

Se manca la classificazione o l'assegnazione di un responsabile, ottenete prima quella decisione. Se l'accesso attuale corrisponde già al contratto approvato, conservate le evidenze e il calendario delle revisioni. Se viene misurata una discrepanza nell'accesso in lettura, proponete una correzione specifica indicando le identità e le applicazioni interessate.

Una modifica proposta allo schema richiede una decisione documentata separata. Includete l'idoneità dell'attributo, i valori originali dei flag, i lettori necessari, l'ambito delle concessioni, il responsabile dell'implementazione, il piano di compatibilità per gli utilizzatori, i criteri di verifica e la strategia di ripristino. Preservate i bit di searchFlags non pertinenti nella configurazione proposta. Evitate di trattare 128 come un valore sostitutivo universale.

Microsoft raccomanda di testare le modifiche agli attributi in un laboratorio che riproduca la foresta di produzione. Usate quei test per convalidare l'esatta combinazione proposta di configurazione dello schema e autorizzazioni. Le indicazioni storiche contengono istruzioni sugli strumenti specifiche per determinate versioni; valutatene l'adeguatezza per l'ambiente di destinazione prima dell'implementazione.

Passo 7 — Convalidare la compatibilità e il ripristino

Chiedete al responsabile di ogni applicazione utilizzatrice quale operazione dipenda dall'attributo e con quale identità. Convalidate la funzione approvata con valori fittizi, compreso il modo in cui l'applicazione gestisce una proprietà illeggibile o mancante. Una lettura autorizzata della directory e un processo aziendale funzionante sono verifiche di accettazione separate.

Definite il ripristino prima dell'approvazione della distribuzione: registrate il valore originale del flag dello schema, le esatte voci di autorizzazione coinvolte, chi può ripristinarle e come verificare il ripristino. Ripristinare una configurazione precedente può consentire nuovamente la lettura, quindi includete questa conseguenza nella decisione. Non descrivete il ripristino come una cancellazione dei dati già letti o copiati.

La revisione si conclude solo quando tre domande hanno risposte esplicite: quali dati hanno una classificazione e un responsabile approvati; se l'attributo è idoneo e quali diritti effettivi danno accesso; e quali utilizzatori legittimi devono restare compatibili dopo un'eventuale modifica. Assegnate qualsiasi risposta irrisolta a un responsabile anziché contrassegnare la valutazione come completata.

Come EtcSec rileva questo aspetto

DATA_CLASSIFICATION_MISSING è un promemoria informativo di revisione in etc-collector. Al commit del collector 0423094759d50002457031317098417993e19510, public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 definisce un Detect() che ignora sia data sia ctx e non utilizza alcun provider.

Restituisce sempre un solo rilievo con gravità Info e un Count: 1 fisso. Titolo, descrizione, esempi di dati sensibili e raccomandazioni sono statici. Il conteggio non rappresenta un numero di attributi esposti, classificazioni mancanti o test di lettura falliti.

Questo rilevatore non misura né la classificazione dei dati né la configurazione degli attributi riservati, i diritti effettivi o la compatibilità degli utilizzatori. Il rilievo non fornisce alcuna prova di esposizione o non conformità. Usatelo per avviare l'inventario e il registro delle decisioni di laboratorio descritti sopra, mantenendo queste osservazioni manuali separate dall'output del rilevatore.

Fonti tecniche e implementazione del collector esaminate il 4 ottobre 2026. Il confronto in laboratorio resta una procedura che il lettore deve eseguire con dati fittizi approvati.