La copertura PSO degli account di servizio: verifica ogni account

Cosa deve dimostrare la copertura PSO degli account di servizio

La copertura PSO degli account di servizio è la prova che ogni identità di servizio inclusa nell'ambito è stata esaminata rispetto al suo effettivo modello di gestione delle credenziali e alla configurazione di riferimento delle password approvata. Per un utente di dominio tradizionale che esegue un servizio, ciò significa leggere il Password Settings Object (PSO) risultante, oppure registrare il criterio predefinito del dominio quando non si applica alcun PSO. Trovare un criterio collegato a un account di servizio non dimostra la copertura del resto della popolazione.

Il risultato pratico è una matrice: account, servizio, responsabile, PSO risultante, prove del criterio predefinito del dominio e decisione sull'eccezione. Mantenete visibili nella matrice gli errori di raccolta. Un criterio inaccessibile è una lacuna probatoria irrisolta; non deve diventare silenziosamente «protetto» o «nessun criterio».

Questa distinzione conta nell'interpretazione di un rilievo automatizzato. L'implementazione di etc-collector esaminata qui verifica se almeno un account di servizio selezionato possiede un collegamento FGPP che soddisfa i criteri. Non determina se ogni account selezionato riceva un criterio risultante approvato. L'assenza di un rilievo richiede quindi una verifica della copertura prima di poter sostenere una decisione di chiusura.

Differenza tra un collegamento a un criterio e un criterio risultante

La documentazione Microsoft di Get-ADUserResultantPasswordPolicy identifica msDS-ResultantPSO come attributo del criterio risultante. Le assegnazioni dirette hanno la precedenza sui criteri collegati ai gruppi. Nel livello applicabile prevale il valore più basso di msDS-PasswordSettingsPrecedence; a parità di valore viene scelto l'objectGUID più basso, come specificato nell'algoritmo Microsoft del PSO risultante. Un collegamento a un criterio candidato, pertanto, non dimostra quale criterio prevalga.

La verifica della copertura deve conservare l'identità e le impostazioni del criterio restituito invece di dedurre il criterio vincente dal nome di un gruppo. Se un criterio collegato a un gruppo, apparentemente robusto, coesiste con un'assegnazione diretta diversa, esaminate l'oggetto risultante prima di accettare il gruppo come prova di protezione. È un esempio di ragionamento, non il resoconto di una configurazione errata osservata.

Una questione distinta riguarda le identità da includere nella verifica. Le indicazioni Microsoft sugli account di servizio distinguono gli account di servizio basati su utenti di dominio tradizionali dalle identità gestite e virtuali. Descrivono la gestione automatica delle password gMSA e non stabiliscono una lunghezza minima universale per gli account di servizio. La verifica deve preservare queste distinzioni invece di trattare ogni nome che sembri riferito a un servizio come un normale utente con una password mantenuta manualmente.

Rilevamento e verifica: costruire la matrice di copertura

1. Concordare la popolazione con i responsabili dei servizi

Partite dall'inventario dei servizi e riconciliatelo con i candidati presenti nella directory. Registrate l'identificatore stabile dell'account, i servizi associati, il responsabile operativo, lo stato di abilitazione, il tipo di identità e la responsabilità della gestione delle credenziali. Quando un account serve più applicazioni, conservate ogni dipendenza invece di scegliere un unico nome di servizio conveniente.

L'elenco dei candidati del rilevatore è un elemento utile, ma non costituisce l'inventario di riferimento dei servizi. Un'euristica basata sui nomi può includere utenti non pertinenti e non individuare un servizio eseguito con un nome inatteso e senza SPN. Risolvete queste differenze con i responsabili. La nostra verifica dei nomi degli account e dei criteri effettivi spiega perché i nomi selezionano candidati senza dimostrare la debolezza delle password; usate quel tutorial esistente per l'indagine più ampia sui nomi.

Mantenete visibili gli account disabilitati con una decisione separata: conservati per un motivo documentato, in attesa di dismissione o esclusi dalla configurazione di riferimento dei servizi attivi con approvazione. Non considerate il criterio di un account disabilitato come prova che la popolazione dei servizi attivi sia coperta. Il rilevatore non effettua questa distinzione.

Per le identità gestite, la funzionalità di filtro documentata di Get-ADServiceAccount consente questo adattamento dell'inventario in sola lettura:

Get-ADServiceAccount -Filter * -Server dc01.contoso.com

Il comando restituisce oggetti di account di servizio gestiti, non un inventario completo di tutti i servizi o degli account di servizio basati su utenti tradizionali. Usate l'identità e il tipo degli oggetti per riconciliare i risultati con l'inventario dei servizi. Non richiedete materiale relativo alle password gestite per questa verifica. Registrate i gMSA nel loro percorso di verifica delle credenziali gestite invece di considerarli difettosi solo perché un campo PSO per utenti tradizionali è vuoto o non applicabile.

2. Leggere un criterio risultante per ogni account utente tradizionale

Eseguite il seguente adattamento documentato dei parametri di identità e server per ogni account di servizio approvato basato su un utente tradizionale, sostituendo il DN e il controller di dominio illustrativi con la destinazione verificata:

Get-ADUserResultantPasswordPolicy -Identity "CN=svc-sql,OU=Service Accounts,DC=contoso,DC=com" -Server dc01.contoso.com -ErrorAction Stop

La documentazione del cmdlet descrive questi parametri, la gestione comune degli errori e gli errori di autorizzazione della directory. Conservate il comando, l'identità interrogata, il server, la marca temporale, l'oggetto restituito e il record dell'errore. Una risposta riuscita contenente un oggetto criterio fornisce l'identità e le impostazioni del PSO risultante. Un errore fornisce la prova di una lettura non riuscita; non fornisce alcun verdetto sulla copertura dei criteri.

Ripetete la lettura per ogni account della popolazione di utenti tradizionali. Conservate le righe riuscite quando un altro account fallisce e mantenete aperta la riga fallita. Non convertite una chiamata fallita in un valore di criterio nullo in un'esportazione e non omettete le righe fallite dal denominatore. Ogni automazione usata per raccogliere la matrice deve riportare un campo distinto per lo stato della lettura accanto al campo del criterio.

3. Registrare il criterio predefinito del dominio e spiegare i collegamenti concorrenti

Usate l'esempio di identità e il parametro del server documentati da Get-ADDefaultDomainPasswordPolicy, adattandoli al dominio previsto:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com -Server dc01.contoso.com

Conservate il criterio predefinito come prova a livello di dominio. Per una lettura utente riuscita senza PSO restituito, verificate l'identità e il contesto della query, quindi registrate il criterio predefinito applicabile e la sua valutazione rispetto alla configurazione di riferimento. Lasciate la riga irrisolta se la completezza della lettura o le autorizzazioni rimangono incerte. Un campo PSO vuoto, da solo, non è una prova sufficiente per approvare la riga.

Per esaminare i collegamenti ai criteri candidati, usate la funzionalità di filtro documentata di Get-ADFineGrainedPasswordPolicy:

Get-ADFineGrainedPasswordPolicy -Filter * -Server dc01.contoso.com

Esaminate i valori restituiti di AppliesTo, Precedence e le impostazioni insieme al risultato per utente. L'inventario dei criteri spiega le assegnazioni candidate; non sostituisce la lettura risultante. Salvate solo le prove relative a criteri e identità necessarie alla verifica.

Se un percorso di appartenenza annidata è pertinente, documentate la catena dall'account al gruppo, la destinazione del criterio, le prove di appartenenza ottenute con autorizzazione e il criterio risultante restituito. Contrassegnate una catena incompleta come non verificata. Non deducete un PSO effettivo da un diagramma apparentemente ricorsivo o dal confronto dei membri diretti eseguito dal rilevatore. Chiedete al responsabile della directory di riconciliare le prove incoerenti di appartenenza e criterio risultante prima di chiudere quella riga.

4. Usare esiti espliciti per ogni riga

Quello che segue è uno schema probatorio suggerito, non un campione di account reali o risultati di test:

Una riga completata può essere approvata mediante un PSO risultante verificato, un criterio predefinito del dominio approvato o un percorso di controllo dell'identità gestita giustificato separatamente. Sono esiti diversi. «Accesso negato», «errore» e «applicabilità in sospeso» rimangono lacune probatorie aperte. Un'eccezione è una decisione documentata, non un esito positivo automatico.

Riconciliate la matrice con la popolazione concordata prima di sintetizzarla. Riportate esplicitamente le letture irrisolte e le identità escluse. L'assenza di un rilievo automatizzato non deve cancellare quelle righe.

Correzione: risolvere la lacuna di ogni account rispetto alla configurazione di riferimento (Remediation)

1. Approvare le impostazioni in base al contesto del servizio

Usate la matrice per identificare gli account tradizionali che non soddisfano la loro configurazione di riferimento approvata. Fate concordare ai responsabili del servizio e della directory le impostazioni delle password richieste, la compatibilità operativa, la manutenzione delle credenziali e il piano di distribuzione. Esaminate le impostazioni restituite nel loro insieme; il solo confronto della lunghezza minima è insufficiente per una configurazione di riferimento approvata localmente.

Il valore 20 del rilevatore è una soglia di implementazione. Non trasformatelo in un requisito Microsoft per tutti i servizi e non copiate impostazioni di criteri dimostrativi come raccomandazioni per la produzione. Conservate nella riga dell'account la configurazione di riferimento approvata del servizio e la sua motivazione.

2. Correggere consapevolmente le assegnazioni e le lacune probatorie

Quando è prevista una FGPP approvata, pianificate la necessaria correzione dell'assegnazione o della precedenza tramite il processo di modifica della directory. Considerate le assegnazioni dirette concorrenti e gli utilizzatori di criteri condivisi prima della modifica. Evitate di creare un unico collegamento che soddisfi i criteri soltanto per abbassare il contatore del rilevatore.

Una lettura con accesso negato richiede accesso autorizzato o un altro percorso approvato di raccolta delle prove prima di decidere sulla copertura. Acquisite insieme l'errore originale e la successiva lettura riuscita. Correggere la raccolta è un prerequisito per interpretare il criterio; non corregge di per sé le credenziali dell'account.

Per le eccezioni mantenute, registrate la dipendenza del servizio, il responsabile, le misure compensative, l'approvatore e la prossima data di revisione. Mantenete visibile l'eccezione della riga nei futuri rapporti di copertura. Un'eccezione senza responsabile o scaduta deve tornare in revisione.

3. Separare le decisioni sugli account gestiti e sulla dismissione

Per un servizio idoneo a gMSA, valutate una migrazione a un'identità gestita con il suo responsabile e convalidate la compatibilità e il recupero autorizzato delle credenziali. Si tratta di una modifica distinta dall'assegnazione di una FGPP a un account tradizionale. Conservate nella matrice la decisione di classificazione e le prove della migrazione.

Per le identità disabilitate, risolvete le dipendenze e il motivo della conservazione prima della dismissione. Non rimuovete account in massa perché compaiono in una verifica della copertura. Viceversa, non lasciate che un'identità inutilizzata ma conforme ai criteri nasconda lacune nei servizi attivi.

Per l'esposizione agli attacchi, la nostra guida a Kerberoasting sui ticket di servizio e sui segreti degli account di servizio tratta l'indagine separata su ticket, segreti e privilegi. Questa matrice stabilisce la copertura della verifica dei criteri; non dimostra la resistenza al cracking offline o l'assenza di attività malevole.

4. Ripetere le letture dopo le modifiche approvate

Rieseguite il comando del criterio risultante per utente e le letture dell'inventario pertinenti dopo la modifica approvata. Allegate le prove prima e dopo a ogni riga interessata, quindi fate convalidare ai responsabili il funzionamento del servizio e il piano di manutenzione delle credenziali. Un risultato PSO cambiato dimostra un esito del criterio, non la qualità di un segreto esistente.

Come EtcSec rileva questo problema

Il controllo di etc-collector SERVICE_ACCOUNT_WEAK_PASSWORD_POLICY appartiene alla categoria Password e ha gravità Medium. Questa descrizione proviene da public/internal/audit/detectors/ad/password/service-account-password-policy.go:39 al commit del collector 0423094759d50002457031317098417993e19510.

Seleziona gli utenti raccolti con un SPN o un probabile nome di servizio: prefissi svc_, svc-, sa_, sa-, sql, iis o app, oppure la sottostringa service, dopo aver convertito sAMAccountName in minuscolo. Gli account selezionati devono avere un DN non vuoto. L'insieme di DN risultante viene deduplicato senza escludere gli account disabilitati né separare i gMSA.

Il controllo cerca poi le FGPP raccolte con lunghezza minima almeno pari a 20. Una corrispondenza diretta di AppliesTo con un qualsiasi account selezionato, oppure una corrispondenza con l'elenco dei Members diretti di un gruppo contenente tale account, attiva il suo indicatore di copertura. La ricerca si interrompe dopo la prima relazione che soddisfa i criteri.

Di conseguenza, Count=1 significa che esistono account selezionati e non è stata trovata alcuna relazione che soddisfi i criteri nei dati raccolti. Count=0 significa che non è stato selezionato alcun account oppure che è stata trovata almeno una relazione che soddisfa i criteri. Count è binario, non il numero di account non coperti. I dettagli includono serviceAccountCount, che è la dimensione dell'insieme dei DN selezionati, non un totale di copertura.

Il controllo non legge msDS-ResultantPSO, non calcola la precedenza effettiva, non espande i gruppi annidati, non confronta ogni account con una configurazione di riferimento, non ispeziona una password esistente e non verifica MFA. Il suo testo descrittivo non deve essere considerato una prova che tali controlli siano stati testati.

Anche la raccolta limita la conclusione. In public/internal/providers/ldap/client.go:1835, GetFGPPs restituisce nil, nil quando la ricerca nel contenitore dei criteri fallisce. Il motore accetta un errore nil in public/internal/audit/engine.go:557; per questo rilevatore, tale percorso non distingue un contenitore inaccessibile da un elenco di criteri vuoto. In presenza di account selezionati, quell'input vuoto può portare a Count=1. Esaminate la raccolta prima di affermare che non esistono criteri.

Decisioni da registrare prima della chiusura

Risolvete tre domande con i responsabili che ne rispondono:

1. Quali identità eseguono realmente servizi, inclusi gli account disabilitati e gestiti, e quale percorso di controllo si applica a ciascuna?
2. Come sono state registrate e riconciliate le letture con accesso negato, le query fallite e le appartenenze annidate pertinenti?
3. Quale configurazione di riferimento è approvata per ogni servizio e quali eccezioni mantenute hanno un approvatore e una data di revisione?

Conservate insieme la definizione della popolazione, le letture dei criteri, le spiegazioni delle appartenenze, le prove delle modifiche e le decisioni, senza esportare segreti. La dichiarazione finale sulla copertura deve descrivere gli account effettivamente esaminati e le lacune ancora aperte. Non deve mai dedurre una protezione universale da una sola relazione FGPP che soddisfi i criteri.