Tutto su AGDLP Group Scope per Active Directory – Account, globale, locale di dominio, permessi

Ultimamente ho ricevuto alcune domande da potenziali clienti sull’ambito del gruppo di sicurezza AD. Volevo prendermi un minuto per dare una panoramica di cosa sono gli ambiti di gruppo e perché sono significativi. Parlerò anche un po’ dei modelli di best practice di Microsoft per l’utilizzo dell’ambito di gruppo e discuterò alcuni dei vantaggi e degli svantaggi di ognuno di essi.

L’ambito di gruppo è importante da capire se si vuole controllare efficacemente i rischi nel modo in cui si utilizzano i gruppi AD. L’ambito di un gruppo determina dove il gruppo può essere applicato nella foresta o nel dominio. L’ambito determina anche chi può essere membro di un gruppo. Poiché Microsoft non ha costruito molte limitazioni in Active Directory riguardo a quali gruppi possono essere annidati all’interno di quali, l’annidamento dei gruppi può presentare enormi rischi operativi e di sicurezza per un’organizzazione. L’unico aiuto reale che AD offre per combattere i potenziali rischi di annidamento dei gruppi di sicurezza è l’ambito del gruppo.

Ci sono tre ambiti di gruppo: universale, globale e locale del dominio. Ogni ambito di gruppo definisce i possibili membri che un gruppo può avere e dove i permessi del gruppo possono essere applicati all’interno del dominio. La tabella qui sotto è stata presa direttamente da Microsoft Technet e fornisce l’intera storia delle regole per l’ambito del gruppo. Ma le regole sono solo metà della storia. L’altra metà, più importante, sta nel capire come usare e applicare correttamente questi ambiti.

Scopo del gruppo Il gruppo può includere come membri… Al gruppo possono essere assegnati permessi in… Lo scopo del gruppo può essere convertito in…
Universal
  • Accounts from any domain within the forest in which this Universal Group resides
  • Global groups from any domain within the forest in which this Universal Group resides
  • Universal groups from any domain within the forest in which this Universal Group resides
Any domain or forest
  • Domain local
  • Global (as long as no other universal group exist as members)
Global
  • Accounts from the same domain as the parent global group
  • Global groups from the same domain as the parent global group
Member permissions can be assigned in any domain Universal (as long as no other domain local groups exist as members)
Domain Local
  • Accounts from any domain
  • Global groups from any domain
  • Universal groups from any domain
  • Domain local groups but only from stesso dominio del gruppo locale del dominio padre
I permessi dei membri possono essere assegnati solo all’interno dello stesso dominio del gruppo locale del dominio padre Universale (finché non esistono altri gruppi locali del dominio come membri)

L’obiettivo di una buonaarchitettato bene è quello di fornire agli utenti appropriati non più o meno dei livelli necessari di accesso alle informazioni e alle risorse necessarie per svolgere il loro lavoro. I modelli di sicurezza basati sui ruoli, sugli attributi e sulle risorse sono tutti modi diversi che le organizzazioni utilizzano per raggiungere questo obiettivo in tutta l’infrastruttura IT, compreso AD. Per realizzare questi modelli nell’ambiente è necessaria un’adeguata comprensione dell’ambito del gruppo e di come applicarlo. AGDLP e AGUDLP sono i modelli strutturali di best practice di Microsoft per l’architettura AD e possono aiutare le organizzazioni a seguire questi modelli di sicurezza.

Il modello AGDLP fornisce una guida su come annidare i gruppi gli uni negli altri senza compromettere la sicurezza o sacrificare l’efficienza operativa. Il modello stabilisce quanto segue: Gli account degli utenti e dei computer dovrebbero essere membri dei gruppi globali, che sono a loro volta membri dei gruppi locali di dominio che descrivono i permessi delle risorse.

La logica dietro questo può essere un po’ complicata, ma farò del mio meglio per spiegarla qui. I gruppi globali sono usati per contenere gli account degli utenti e dei computer e possono includere altri gruppi globali all’interno dello stesso dominio. Pensate ai gruppi globali come “gruppi di account”. Questi gruppi includeranno utenti che sono simili nel senso che fanno tutti parte dello stesso dominio, poiché i gruppi globali non possono contenere membri di altri domini. Gli utenti avranno probabilmente anche altri punti in comune, come essere nello stesso dipartimento, avere lo stesso manager, o qualche altra somiglianza di questo tipo. Per esempio, tutti gli utenti che sono nel dipartimento di Marketing della sede centrale di New York di una società sarebbero messi nello stesso gruppo globale chiamato “Marketing”.

A causa della flessibilità delle loro restrizioni di appartenenza, i gruppi locali di dominio sono ideali per concedere permessi sulle risorse. In particolare, questi gruppi sono usati perché i gruppi del dominio padre, così come altri domini e foreste di fiducia, possono essere aggiunti ad essi. Questo permette agli amministratori di concedere l’accesso a una risorsa a chiunque nell’ambiente, se ne ha bisogno. Se i gruppi globali sono i “gruppi di account”, i gruppi locali del dominio sono i “gruppi di risorse”. Un esempio di un gruppo di risorse in azione può essere un gruppo locale di dominio che garantisce l’accesso a una condivisione di file chiamata “Marketing Documents”. Annidando il gruppo globale “New York Marketing” dentro il gruppo locale di dominio “Marketing Documents”, abbiamo appena dato a tutti gli utenti del dipartimento Marketing di New York accesso al contenuto della condivisione Marketing Documents. Ecco una rappresentazione grafica di questo scenario AGDLP:

AD Workflow

L’uso dei gruppi locali di dominio diventa particolarmente importante quando si ha a che fare con situazioni che coinvolgono foreste fidate. In un caso come questo, ci sono buone probabilità che gli account in una foresta abbiano bisogno di accedere a risorse nell’altra foresta. Se un gruppo globale venisse usato per garantire l’accesso a una risorsa, non ci sarebbe modo per gli account della seconda foresta di avere accesso a quella risorsa, poiché gli account e i gruppi non possono essere annidati in gruppi globali di un dominio o di una foresta diversi.

Per continuare con il nostro esempio, forse la nostra azienda fittizia acquisisce un’altra azienda a Miami e i gruppi IT decidono di fidarsi delle foreste delle due aziende insieme. Se seguiamo il modello AGDLP, il reparto Marketing dell’azienda di Miami dovrebbe avere il proprio gruppo globale nella loro foresta. Per dare al reparto Marketing della nuova società l’accesso alla condivisione di Marketing Documents, tutto quello che l’amministratore deve fare è di annidare il gruppo globale Miami Marketing nel gruppo locale del dominio Marketing Documents. Vedere la rappresentazione grafica qui sotto per un’occhiata semplificata:

AD Workflow Multiple

Il modello AGUDLP è molto simile a AGDLP (come suggerisce il nome) ma introduce la “U” per Universal groups nell’equazione. Le appartenenze di questi gruppi sono memorizzate nel catalogo globale, che è più di una necessità negli ambienti multi-dominio. L’uso di questo modello dipende davvero da quanto si fa affidamento sul catalogo globale nell’organizzazione. Se c’è un interesse acquisito nell’avere il catalogo globale il più completo possibile (forse hai una grande forza lavoro mobile e fai molto affidamento sul fatto che i dipendenti siano in grado di trovare facilmente gli altri in Outlook), allora il modello AGUDLP aiuterà in questo sforzo. Tuttavia, per gli ambienti più piccoli che hanno solo un singolo dominio questo modello può aggiungere un inutile strato di complessità.

La ragione per cui questi modelli sono la migliore pratica di Microsoft è duplice. Dal punto di vista della sicurezza, se uno dovesse usare i gruppi globali per dare agli utenti i permessi per le risorse, dovrebbe aggiungere utenti da altri domini e foreste nel dominio dove risiedono le risorse. In generale, i domini e le foreste separate esistono per una ragione e le delimitazioni tra i domini e le foreste non devono essere confuse. Usando i gruppi locali del dominio per concedere i permessi a risorse specifiche, un amministratore può dare ai membri di altri domini e foreste l’accesso alla risorsa senza bisogno di dare loro l’accesso diretto al resto del dominio dove risiede quella risorsa. Troppo spesso vediamo le organizzazioni utilizzare gruppi globali per definire i permessi sulle risorse e finire per sovra-provisionare l’accesso e i diritti come risultato quando gli utenti si spostano dentro e fuori dal gruppo.

Da un punto di vista operativo, i modelli AGDLP e AGUDLP rendono anche la gestione dei membri del gruppo più facile nel senso che i permessi e l’organizzazione degli utenti sono gestiti in luoghi distinti. I permessi delle risorse sono impostati per i gruppi locali del dominio e non hanno bisogno di cambiare una volta che sono stati determinati, limitando la frequenza con cui è necessario andare alla risorsa per regolare questi permessi. Oltre a contenere restrizioni incorporate per l’appartenenza, i gruppi globali sono anche facilmente modificabili e quindi, forniscono un posto perfetto per gli utenti in cui risiedere dal momento che gli utenti si spostano costantemente all’interno dell’organizzazione richiedendo diversi livelli di accesso.

Si dovrebbe notare che solo perché questi modelli sono le migliori pratiche di Microsoft, non sono perfetti per tutti. In ambienti più grandi, l’uso di gruppi locali di dominio per gestire i permessi delle risorse può portare alla generazione di un numero molto grande di gruppi. Questo potrebbe portare un utente ad essere membro di migliaia di gruppi nel momento in cui gli viene concesso l’accesso a tutte le risorse di cui ha bisogno e potrebbe, a sua volta, portare a problemi come il token bloat.

Alla fine della giornata, seguire i modelli AGDLP e AGUDLP offre alcuni vantaggi molto reali per un’organizzazione. Il problema spesso risiede nell’implementazione dell’infrastruttura per seguire il modello, dato che si basa su qualcosa di più di un semplice amministratore esperto per mischiare i gruppi in AD. Questi modelli richiedono una costante vigilanza e supervisione da parte dell’IT per essere applicati. Molti passi devono essere fatti per implementarli e mantenerli, come l’assegnazione di proprietari ai gruppi che capiscano le esigenze degli utenti in quei gruppi, assicurandosi che gli utenti giusti siano nei gruppi giusti e che i gruppi contengano le autorizzazioni corrette sulle risorse.

La buona notizia è che ci sono strumenti che possono aiutare con questi passi. StealthAUDIT fornisce un punto di partenza per mettere in pista le organizzazioni, aiutandole a capire a quali gruppi sono attualmente concessi gli accessi, quali utenti sono in quei gruppi e quali diritti hanno quegli utenti. Inoltre, StealthAUDIT può assistere nella trasformazione del modello di accesso di un’organizzazione e nell’identificazione dei proprietari dei gruppi, mettendo il potere nelle mani dell’azienda per gestire i propri gruppi, poiché sanno chi ha bisogno di accedere a cosa meglio di chiunque altro. Mentre può essere uno sforzo monumentale adottare AGDLP o AGUDLP, i benefici residui possono andare molto lontano per garantire un ambiente sicuro e sostenibile.

Scopri StealthAUDIT qui.

Non perdere un post! Iscriviti al blog sulla sicurezza di Insider Threat qui:

.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *