Ambito del punteggio di conformità AD: confrontare cinque deduzioni

Ambito del punteggio di conformità AD: cosa può dimostrare il numero

L'ambito del punteggio di conformità AD determina cosa può sostenere un numero in un audit. Nell'implementazione di etc-collector esaminata il 4 ottobre 2026, il punteggio parte da 100 e sottrae punti per quattro valori dei criteri password del dominio e un conteggio degli utenti abilitati con adminCount=1. Non aggrega tutti i rilievi e non valuta un quadro di conformità completo.

Un punteggio di 100 significa che nessuna di queste cinque condizioni di deduzione si è attivata sugli input forniti. Non certifica Active Directory, non dimostra che siano stati raccolti tutti gli oggetti pertinenti e non stabilisce che i controlli indipendenti siano stati superati. Prima di usare il numero in un rapporto, ricostruite i suoi input e le prove della loro raccolta.

Questa analisi è fissata alla revisione del collector 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, in particolare a public/internal/audit/detectors/ad/compliance/score.go, a partire da Detect() alla riga 23. Gli esempi seguenti sono calcoli ricavati da quel codice, non misurazioni di un dominio reale. Per questo articolo non sono stati eseguiti comandi Windows su un ambiente.

Come funzionano le cinque deduzioni

Con un DomainInfo non nullo, ogni condizione viene valutata indipendentemente. Il quinto input deriva dalla raccolta Users fornita. Queste sono soglie del prodotto; usarle per riprodurre un risultato non stabilisce che siano la baseline approvata dall'organizzazione.

L'uguaglianza conta: lunghezza 14, cronologia 24, soglia di blocco 10, età massima 90 giorni e conteggio 20 non attivano le rispettive deduzioni. Il contatore conta una volta gli oggetti che soddisfano i criteri; non calcola un rapporto tra amministratori e utenti.

Se DomainInfo è nullo, il rilevatore salta tutte e quattro le condizioni dei criteri e sottrae 15 sotto no_domain_info. Poi valuta la stessa condizione di conteggio degli utenti. Un oggetto nullo è quindi un ramo di calcolo diverso, non quattro controlli dei criteri falliti e confermati.

Dimostrare l'intervallo raggiungibile

Con DomainInfo presente, la massima deduzione possibile è 10 + 5 + 5 + 5 + 10 = 35. La minima è zero. I punteggi vanno quindi da 65 a 100, a incrementi di cinque punti. Queste condizioni non raggiungono mai il limite difensivo a zero.

Senza DomainInfo, il punteggio è 85 quando il conteggio degli utenti che soddisfano i criteri è al massimo 20, oppure 75 quando supera 20. In quel ramo non può assumere altri valori.

Per esempio, tutte e quattro le condizioni dei criteri attivate con conteggio 20 producono 75; il conteggio 21 produce 65. Un oggetto del dominio nullo con conteggio 20 produce 85. Questi casi ipotetici spiegano perché un numero apparentemente migliore può accompagnarsi a prove dei criteri più deboli.

Il rilievo include fasce di interpretazione come 50-69 e 0-49. Solo 65 è raggiungibile nella prima; la seconda è interamente irraggiungibile. Valori inferiori a 65 non possono derivare da questo calcolo da solo. Queste etichette di visualizzazione non ampliano la copertura del rilevatore né trasformano la sua fascia superiore in un verdetto di conformità.

Rilevamento: confrontare gli input con letture indipendenti

Partite dal dominio, dal controller di dominio scelto, dall'ora di raccolta e dall'ambito dell'inventario. Una lettura indipendente recente da un altro DC o da una base di ricerca più ristretta può descrivere prove diverse. Registrate queste differenze prima di trattare una discrepanza come un errore del rilevatore.

Microsoft documenta Get-ADDefaultDomainPasswordPolicy come comando che recupera i criteri predefiniti per un dominio. Questo esempio di sola lettura usa i parametri documentati -Identity e -Server. Sostituite il dominio e il DC illustrativi con i destinatari esaminati:

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' -Server 'dc01.example.com'

Conservate l'intero oggetto restituito e confrontate lunghezza minima, cronologia password, soglia di blocco ed età massima con gli input del collector. Preservate le unità di durata: il provider converte l'intervallo di età massima della directory in giorni interi. Non confrontate direttamente un intervallo grezzo della directory o una stringa di durata formattata con l'intero 90.

Il collector legge questi attributi dei criteri dall'oggetto del dominio. Non usa l'oggetto delle impostazioni password risultanti (PSO) di ogni utente per questo punteggio. Microsoft documenta Get-ADUserResultantPasswordPolicy per questa domanda distinta a livello di account. Tenete tali prove fuori dal punteggio riprodotto, anziché sostituire agli input del dominio i criteri di un utente selezionato.

Leggere adminCount senza rinominare la popolazione

La definizione Microsoft dell'attributo adminCount descrive un oggetto le cui ACL sono state rafforzate dal sistema a causa dell'appartenenza diretta o transitiva a un gruppo amministrativo. Questo descrive una storia di protezione; non è una query sull'appartenenza attuale a Domain Admins.

Il provider converte la stringa LDAP esatta "1" nel booleano utente AdminCount=true. Il rilevatore esclude poi gli utenti disabilitati. Sebbene la descrizione e il testo dell'ambito del rilievo dicano «Domain Admins count», il predicato effettivo non risolve mai quel gruppo. Preservate la distinzione quando spiegate il risultato.

Usate i parametri documentati di ricerca e proprietà di Get-ADUser per conservare i record utente sottostanti:

Get-ADUser -Filter * -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties adminCount,Enabled

Questo è un esempio adattato dalla documentazione, non un inventario eseguito. Dai record restituiti, confrontate gli utenti abilitati il cui adminCount grezzo è uguale a 1 con la popolazione che soddisfa i criteri del collector. Conservate identità degli oggetti ed eccezioni, non soltanto il totale finale. Un attributo mancante, una base ristretta o un limite di raccolta richiede una precisazione prima di interpretare un conteggio basso.

Costruire una scheda di calcolo e provenienza

Per un audit reale, compilate il seguente registro con i valori osservati. «Raccolta confermata» significa che la risposta e gli attributi richiesti sono stati letti correttamente per l'ambito indicato; una struttura non nulla da sola non lo dimostra.

Aggiungete a ogni riga il valore effettivo, l'esito della raccolta, il valore indipendente e la deduzione risultante. Quando le prove non sono disponibili, scrivete «sconosciuto» nella colonna delle prove preservando l'input numerico utilizzato dal codice. Non sostituite silenziosamente l'input con un valore ipotizzato.

Correzione: risolvere le lacune nelle prove prima di cambiare i criteri (Remediation)

Prima confrontate il calcolo. Conservate il punteggio del rilievo, la mappa delle deduzioni, le statistiche utente e la revisione del collector. Ricalcolate il risultato con gli input forniti e identificate se l'oggetto del dominio era presente, parziale o nullo. Questo distingue una discrepanza aritmetica da un'osservazione incompleta.

Poi precisate la raccolta. Uno zero può rappresentare un valore configurato o un valore assente/non analizzato in questo provider. Ottenete la risposta pertinente del dominio e una lettura indipendente sul DC registrato. Per gli utenti, confrontate ambito e limiti di ricerca con la popolazione prevista. Una chiamata GetUsers riuscita è una prova necessaria, ma non dimostra da sola che un inventario intenzionalmente limitato copra l'intero dominio.

Se la raccolta è incompleta, risolvete il problema specifico di raccolta ed eseguite un nuovo audit. Conservate il risultato precedente come osservazione incompleta. Non descrivete il passaggio da 85 a 100 dopo il recupero delle informazioni del dominio come quattro controlli dei criteri corretti senza prove dei criteri prima e dopo.

Quindi identificate la baseline dell'organizzazione, la sua edizione, il responsabile e le eccezioni. Il nostro confronto dei predicati ANSSI e CIS dei criteri password spiega perché controlli diversi possono divergere su attributi comuni. Le cinque deduzioni di questo punteggio sono un calcolo distinto del prodotto; non sono una terza baseline di un quadro di conformità.

Per una lacuna di configurazione confermata, applicate la modifica approvata dei criteri tramite il processo di amministrazione stabilito, conservate il registro della modifica, ripetete la lettura indipendente e rieseguite l'audit sullo stesso ambito. Per una discrepanza adminCount, indagate separatamente gli oggetti effettivi e le appartenenze privilegiate attuali. Cancellare il marcatore solo per ridurre il contatore non dimostra che i privilegi o la protezione delle ACL siano corretti.

Infine allegate le prove dei controlli indipendenti. La nostra mappatura dei requisiti di conformità AD e Azure a controlli di identità identificati fornisce il contesto per questo lavoro. Registrazione degli eventi, protezioni dei protocolli, governance degli accessi e controlli Entra richiedono risultati propri. Questo punteggio non esamina quei controlli e non può colmare le loro lacune nelle prove.

Come EtcSec rileva questo caso

COMPLIANCE_SCORE è l'unico rilevatore trattato qui. Il suo Detect() legge DomainInfo e Users, applica le cinque condizioni sopra e restituisce sempre un rilievo Info con Count=1, anche con punteggio 100. Count 1 indica il rilievo del punteggio restituito, non un utente interessato o un controllo fallito.

I dettagli includono score, maxScore=100, deductions, totalUsers, enabledUsers e adminCount. I totali utente descrivono la raccolta fornita. Non dimostrano la copertura completa della directory.

I percorsi del provider spiegano i limiti:

• public/internal/providers/ldap/client.go:569 crea un oggetto di informazioni sul dominio prima di interrogare RootDSE e il dominio. Risposte fallite o vuote possono lasciare un oggetto parziale con valori zero. I quattro valori dei criteri provengono dall'oggetto del dominio, non da un PSO risultante per utente.
• public/internal/providers/ldap/parser.go:155 definisce l'AdminCount utente tramite il confronto esatto di stringhe adminCount == "1". La sua funzione ausiliaria per gli interi restituisce zero per valori assenti e ignora gli errori di parsing degli interi.
• public/internal/audit/engine.go:512 tratta un errore restituito da GetDomainInfo come non fatale e fornisce informazioni sul dominio nulle. Quel ramo produce 85 prima della deduzione opzionale di 10 punti per adminCount. Al contrario, il precedente percorso di errore di GetUsers interrompe la raccolta.
• I valori raggiungibili del calcolo sono 65–100 con un oggetto del dominio, oppure 75/85 senza. Un oggetto non nullo non dimostra che la raccolta degli attributi sia riuscita, e le fasce di interpretazione inferiori a 65 sono irraggiungibili per questo rilevatore.

Tutti i riferimenti al codice sopra sono fissati alla revisione esaminata. Riportate l'output come un indicatore parziale del prodotto sostenuto da input debitamente qualificati. Un punteggio di 100 stabilisce solo che queste cinque condizioni di deduzione non si sono attivate; la conformità complessiva e la certificazione richiedono controlli e prove definiti indipendentemente.