Confini di fiducia di Configuration Manager: mappa dell'autorità

Perché il posizionamento in una OU non stabilisce i confini di fiducia di Configuration Manager

I confini di fiducia di Configuration Manager seguono l'autorità amministrativa: chi può modificare un componente di gestione, quali risorse può controllare un operatore e dove un'identità di installazione dispone di diritti locali. Il nome distinto di un computer AD è una prova di inventario utile, ma spostarlo in una OU chiamata Management non risponde a queste domande.

Partite dal computer candidato, poi seguite la sua autorità verso gli altri sistemi. È un server di sito, un host SMS Provider, un altro sistema di sito oppure semplicemente un client gestito con un nome di prodotto nella descrizione? Quali persone e identità di servizio lo amministrano? Quali sistemi possono raggiungere queste identità? La revisione di un confine è incompleta finché lo stesso documento non collega l'infrastruttura di gestione ai suoi effettivi sistemi di destinazione.

Il modello di amministrazione a tier di Active Directory e le sessioni amministrative fornisce i principi generali di separazione. Questa revisione aggiunge una mappa dell'autorità specifica del prodotto. Mantenete i due aspetti collegati: una convenzione per le OU può agevolare la distribuzione dei criteri, ma non può sostituire le prove su chi controlla Configuration Manager o i sistemi che gestisce.

Come funziona: accesso al provider, autorità sul database e portata sulle destinazioni

Microsoft descrive livelli di sicurezza distinti. Il SMS Provider espone l'accesso al database del sito tramite WMI e il servizio di amministrazione. L'accesso al provider e le autorizzazioni sugli oggetti gestiti sono questioni diverse. Local System e l'utente di installazione di Configuration Manager hanno autorità predefinita su tutti gli oggetti del database del sito; gli altri utenti amministrativi sono governati dall'amministrazione basata sui ruoli della console. Ruoli, ambiti di sicurezza e raccolte definiscono insieme ciò che un utente può visualizzare e gestire. Queste distinzioni provengono dai fondamenti di sicurezza di Configuration Manager.

Per la revisione, registrate tre percorsi separatamente:

• Controllo dell'infrastruttura: identità in grado di amministrare l'host del provider, il server di sito o l'infrastruttura del database.
• Amministrazione del prodotto: entità di sicurezza le cui autorizzazioni assegnate consentono operazioni su specifici oggetti Configuration Manager e raccolte di destinazione.
• Autorità di installazione: account con diritti sui sistemi dove il prodotto installa un client o un componente di sistema di sito.

Questo è un modello di valutazione, non un'affermazione secondo cui ogni operatore Configuration Manager dispone di amministrazione Windows senza restrizioni. Per ciascun percorso, stabilite l'operazione concessa e la risorsa interessata. Non trasformate la capacità di interrogare il provider nella conclusione che l'identità possa distribuire su ogni dispositivo.

La documentazione degli account Configuration Manager di Microsoft fornisce distinzioni concrete. SMS Admins è un gruppo locale sui computer del provider; le sue autorizzazioni WMI possono essere esaminate con lo snap-in MMC WMI Control. Il RBAC continua a determinare l'accesso agli oggetti della console. Il client push installation account richiede l'appartenenza al gruppo Administrators locale sui client di destinazione, non a Domain Admin; in assenza di un account configurato, il sito tenta di usare il proprio account computer. Il site system installation account, distinto, richiede autorizzazioni amministrative locali e il diritto utente di accesso alla rete sui sistemi di sito di destinazione. Il network access account serve per accedere alle risorse, non come contesto di esecuzione per software, aggiornamenti o sequenze di attività.

Questi account meritano righe separate anche quando la stessa identità AD svolge più funzioni. Un'etichetta come «account di servizio» nasconde la distinzione tra scaricare contenuti e amministrare una destinazione. Al contrario, nomi di account diversi non stabiliscono una separazione se ricevono diritti equivalenti sulle stesse macchine.

Rilevamento: costruire la matrice dell'autorità dalle prove del prodotto

Passaggio 1: confermare la funzione effettiva del candidato

Conservate il risultato LDAP, il DN del computer, il campo di inventario che ha prodotto la corrispondenza e la data della revisione. Chiedete al responsabile del prodotto di identificare la funzione effettiva del candidato e il sito associato. Confrontate quella risposta con la configurazione distribuita del prodotto e l'inventario degli host. Se è soltanto un client, registrate perché l'euristica lo ha selezionato; non inventate un ruolo di gestione per giustificare il risultato.

Per un componente di gestione confermato, elencate gli host del provider e del database da cui dipende, le identità di installazione e i responsabili amministrativi. Contrassegnate come sconosciute le relazioni irrisolte. Un inventario che omette un provider o un sistema di sito remoto può far apparire un ambito di gestione ritenuto ristretto più sicuro di quanto sia.

Passaggio 2: leggere insieme ruoli, ambiti e raccolte assegnate

Seguite la procedura di configurazione dell'amministrazione basata sui ruoli di Microsoft. Nella console, aprite Administration > Security > Administrative Users, selezionate l'entità di sicurezza e aprite Properties. Esaminate Security Roles e Security Scopes, inclusa l'associazione configurata tra ruoli, ambiti e raccolte. Per esaminare le autorizzazioni di un ruolo sugli oggetti, andate in Administration > Security > Security Roles, selezionate il ruolo, aprite Properties e scegliete la scheda Permissions.

Per l'autorità sulle raccolte, esaminate le autorizzazioni del ruolo sull'oggetto Collection e le raccolte assegnate all'utente amministrativo. Includete le raccolte limitate da quelle assegnate. Microsoft indica anche il Role-based administration and auditing tool per verificare utenti, raccolte e ambiti.

Usate queste viste come prove, non soltanto come schermate di nomi descrittivi. Registrate gli identificatori, le azioni consentite pertinenti, le assegnazioni tramite gruppi e i dispositivi membri utilizzati per la revisione. Quando l'appartenenza cambia, la mappa dell'autorità richiede un'altra revisione. Una raccolta chiamata «Servers» non stabilisce che ogni membro appartenga al livello di fiducia previsto.

Passaggio 3: esaminare la configurazione di installazione e i diritti locali sulle destinazioni

La procedura di distribuzione dei client Windows di Microsoft indica il percorso nella console: Administration > Site Configuration > Sites, selezionate il sito, poi Client Installation Settings > Client Push Installation. Esaminate la scheda Accounts e le impostazioni di installazione automatica, i tipi di sistema selezionati e la selezione dei controller di dominio nella scheda General. La procedura documenta anche l'installazione push avviata per un singolo dispositivo o una raccolta.

Leggete questa configurazione prima di avviare qualsiasi installazione. Una selezione configurata delle destinazioni costituisce una prova sul flusso di installazione; esaminate separatamente dove ogni identità dispone effettivamente di diritti amministrativi locali. Distinguete il client push installation account configurato, il ricorso all'account computer e il site system installation account.

Registrate separatamente le verifiche riuscite e non riuscite. Se l'appartenenza ai gruppi locali non può essere verificata su una destinazione, contrassegnatela come sconosciuta. Non deducete l'assenza di diritti da un host non disponibile, né diritti su tutte le macchine da una verifica riuscita su un solo dispositivo rappresentativo.

Passaggio 4: collegare le entità di sicurezza ai sistemi gestiti

Costruite una riga per ogni percorso di autorità. Il seguente è un modello di revisione, non un ambiente rilevato o un insieme di autorizzazioni predefinite:

Leggete la tabella da sinistra a destra: entità di sicurezza → ruolo/account → sito/raccolta → sistemi gestiti. Poi chiedete quale riga unisce livelli di fiducia precedentemente separati. Esaminate le assegnazioni combinate invece di considerare ciascun ruolo isolatamente. Conservate una voce separata per un insieme di destinazioni sconosciuto; una cella vuota non deve mai significare implicitamente «nessun accesso».

Correzione: allineare l'autorità prima di cambiare il posizionamento in OU (Remediation)

Passaggio 1: decidere il confine previsto e conservare lo stato di riferimento

Con i responsabili dell'infrastruttura e delle identità, definite quali sistemi gestiti devono essere raggruppati e quali percorsi amministrativi devono rimanere separati. Confrontate quel confine previsto con ogni riga della matrice. Registrate il motivo di ogni discrepanza, il suo responsabile e le prove necessarie per chiuderla.

Conservate le assegnazioni dei ruoli esistenti, la configurazione di installazione, i membri degli insiemi di destinazione e le dipendenze operative prima delle modifiche. Scegliete un progetto pilota contenente sia una destinazione prevista sia un sistema che deve rimanere fuori dall'autorità dell'operatore. Pianificate un test funzionale approvato e un ripristino per ogni modifica.

Passaggio 2: restringere le autorizzazioni del prodotto tramite la console supportata

Usate le proprietà dell'utente amministrativo già esaminate per modificare le associazioni pertinenti di ruoli, ambiti e raccolte. Dove i ruoli esistenti concedono autorità eccessiva, usate la procedura per i ruoli personalizzati documentata da Microsoft: copiate un ruolo in Administration > Security > Security Roles, esaminate le sue autorizzazioni sugli oggetti e assegnate soltanto quelle necessarie. Le autorizzazioni dei ruoli predefiniti non possono essere modificate. Queste operazioni sono descritte nella procedura di configurazione dell'amministrazione basata sui ruoli.

La modifica deve rimuovere una specifica operazione indesiderata o una relazione con una destinazione. Verificate che l'amministrazione prevista continui a funzionare e che il sistema escluso sia fuori dall'autorità concessa. Mantenete l'amministrazione dell'infrastruttura nella revisione; restringere soltanto un'assegnazione nella console non risolve un percorso separato di amministrazione dell'host o del database.

Passaggio 3: separare l'autorità di installazione quando la sua portata attraversa il confine

Per ciascuna identità di installazione, confrontate i suoi diritti locali verificati con l'insieme di destinazioni previsto. Proponete identità separate con ambiti adeguati quando un account attraversa più livelli di fiducia. Controllate l'account configurato nel prodotto e le autorizzazioni concesse in ogni destinazione; cambiare soltanto un lato lascia la revisione incompleta.

La documentazione degli account di Microsoft raccomanda di negare esplicitamente l'accesso interattivo locale al client push installation account. Documenta anche una sequenza di sostituzione: creare un account con un nome diverso, aggiungerlo all'elenco configurato, consentire la replica AD, poi ritirare il vecchio account. Trattatela come una migrazione coordinata con verifica dei diritti sulle destinazioni, non come un'istruzione di eliminare account o gruppi. L'identità di installazione dei sistemi di sito richiede una propria revisione delle destinazioni. Seguite i requisiti documentati degli account per la funzione effettivamente utilizzata.

Passaggio 4: conciliare posizionamento in OU, sessioni amministrative e flussi

Solo dopo che la mappa dell'autorità è coerente, confrontate posizionamento in OU, delega, criteri e punti di ingresso amministrativi con il progetto previsto. Considerate insieme gli host di gestione e le persone e gli account che li controllano. Spostare un oggetto computer non può correggere un account che mantiene diritti su un insieme di destinazioni non previsto.

Esaminate il trasporto come controllo separato. I controlli GPO per il trasporto dei metadati WSUS riguardano la protezione di quella connessione; non stabiliscono chi può amministrare il SMS Provider o cosa possa controllare un'identità di installazione. Conservate entrambe le revisioni, con prove e conclusioni separate.

Passaggio 5: chiudere i rilievi con prove e conservare le eccezioni

Ricostruite la matrice dopo il progetto pilota e la successiva distribuzione. Per ogni riga modificata, allegate la nuova assegnazione, i membri attuali dell'insieme di destinazioni, le prove pertinenti dei diritti locali e il risultato funzionale. Un'eccezione deve identificare l'operazione richiesta, i sistemi interessati, il responsabile, le misure compensative e una condizione che attivi la revisione. Un'autorizzazione irrisolta o una destinazione irraggiungibile rimane sconosciuta.

Definite le condizioni per un'altra revisione: un nuovo host del provider, sistema di sito, assegnazione di raccolta, identità di installazione o livello di fiducia gestito. Una decisione sul confine rimane difendibile soltanto finché la mappa dell'autorità che la sostiene corrisponde all'ambiente distribuito.

Come EtcSec rileva questo caso

Il controllo etc-collector esaminato è ANSSI_R49_R50_MGMT_CATEGORIZATION, al commit del collector 15fc6399c215eabc415c370b762303cfcd7a353a. È un'euristica di inventario e denominazione, non un audit delle autorizzazioni di Configuration Manager.

Un computer diventa candidato quando il suo DN corrisponde a una voce dell'elenco facoltativo mgmt_systems, oppure quando la combinazione in minuscolo di SAMAccountName, DNSHostName, Description e OperatingSystem contiene uno di questi marcatori: sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack o sentinelone.

Produce un rilievo per i candidati il cui DN in minuscolo non contiene nessuno di ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt o ou=management. Sono test di sottostringhe, non una convalida dei controlli effettivi di una OU. Se nessun candidato fallisce quel test, Detect() restituisce nil.

L'elenco facoltativo mgmt_systems proviene da tier0_groups.yaml. Se quel file è assente, non viene caricata alcuna personalizzazione, l'elenco è vuoto e si applicano soltanto le euristiche sui nomi, senza avviso. Se il file non è leggibile o il suo YAML non è valido, il motore scrive un avviso su stderr e continua con i valori predefiniti. Una voce DN esplicita aggiunge un candidato; non stabilisce l'autorità del prodotto e non sostituisce il test delle sottostringhe della OU.

Il provider LDAP fornisce i campi di inventario dei computer. Questo controllo non raccoglie autorizzazioni SMS Provider, autorità sul database del sito, assegnazioni RBAC, raccolte di destinazione o diritti degli account di installazione. Il nome di un client può corrispondere; un sistema di gestione effettivamente potente può non essere rilevato; un nome di OU può soddisfare il test delle sottostringhe senza imporre isolamento.

Usate il rilievo per avviare la revisione dell'autorità. Risolvete la questione architetturale con le prove del prodotto e delle destinazioni nella matrice, conservando elementi sconosciuti ed eccezioni anche quando l'euristica di denominazione non segnala più un rilievo.