GPO Security Filtering vs Delegation in Active Directory: quale differenza?

Contesto

In Active Directory, GPO Security Filtering e Delegation vengono spesso confusi. Il risultato è che molti ambienti sembrano ben organizzati, ma in realtà la policy arriva ai destinatari giusti mentre i permessi di amministrazione sono ancora troppo ampi. Questo è un problema di governance e di sicurezza operativa, non solo di configurazione tecnica.

Questa guida spiega in modo pratico la differenza tra:

• chi dovrebbe ricevere la policy, tramite Security Filtering;
• chi può amministrarla o modificarla, tramite Delegation.

Perché questa distinzione è importante? Perché una GPO può essere ben targettata eppure restare fragile se le deleghe sono sbagliate. E questo diventa particolarmente critico durante audit, hardening e review di least privilege.

Indice

• 1. Come funziona l'applicazione di una GPO
• 2. Security Filtering: cosa controlla davvero
• 3. Delegation: chi può amministrare la GPO
• 4. Perché i due livelli vanno letti separatamente
• 5. Casi tipici di rischio
  • Caso 1: filtering corretto, ma GPO ancora troppo esposta
  • Caso 2: delega amministrativa troppo ampia
  • Caso 3: uso di gruppi troppo generici
• 6. Esempio operativo di differenza
• 7. Checklist rapida per un design least-privilege
  • Esempi concreti di abuso
  • Quick check molto base
• Conclusione

1. Come funziona l'applicazione di una GPO

Prima di parlare di Security Filtering, conviene capire a grandi linee come una GPO viene davvero applicata in Active Directory.

Una GPO non viene "eseguita" ovunque per magia. Si applica a un oggetto di dominio, a un'OU o a un sito solo se è stata collegata lì. Se una policy riguarda gli utenti, il collegamento deve essere fatto dove esistono gli oggetti utente target: ad esempio in un'OU con gli utenti, o in un contesto in cui il targeting consenta che quella policy raggiunga gli utenti giusti. Se invece la GPO impatta i computer, il suo collegamento deve essere fatto dove sono presenti i computer target.

Questa parte è importante perché una GPO collegata ai computer che deve applicare impostazioni utente non la fa diventare automaticamente una policy per gli utenti, e viceversa. In altre parole, il punto di partenza non è il Security Filtering, ma il luogo in cui la GPO è collegata e il tipo di oggetto che la policy riguarda.

Ci sono però eccezioni. Ad esempio, il loopback può modificare il comportamento normale della policy: invece di applicare la configurazione prevista per il computer all'utente reale, la GPO può invertire il contesto e far sì che la policy utente venga valutata come se fosse applicata al computer. È un meccanismo avanzato, ma utile in ambienti specifici.

Questa premessa serve a chiarire un concetto semplice: il Security Filtering non è il primo passaggio dell'applicazione di una GPO. Prima di tutto, la GPO deve essere collegata nel posto giusto e deve essere pensata per il tipo di oggetto che deve riceverla.

2. Security Filtering: cosa controlla davvero

Il Security Filtering decide a quali oggetti la GPO viene applicata. In pratica, stabilisce il gruppo di destinatari effettivi della policy.

Da un punto di vista operativo, questo significa:

• chi riceve la policy;
• su quali computer o utenti viene applicata;
• se il targeting è coerente con il ragionamento di business o di infrastruttura.

Un esempio semplice: una GPO collegata a un'OU con Security Filtering impostato su un gruppo specifico verrà applicata solo agli oggetti che appartengono a quel gruppo e soddisfano i requisiti di scope. Se l'obiettivo è limitare una policy a un sottoinsieme di workstation, il filtering è lo strumento giusto.

Il punto importante è che il Security Filtering non conferisce privilegi amministrativi. Non dice "chi può modificare la GPO". Dice invece "chi è previsto come destinatario della GPO".

3. Delegation: chi può amministrare la GPO

La Delegation, invece, riguarda i permessi di amministrazione. È il piano che stabilisce chi può:

• editare le impostazioni della GPO;
• collegarla a un oggetto di dominio o OU;
• rimuoverla;
• modificare i permessi di sicurezza della GPO;
• gestire il contenuto o la distribuzione della policy.

Questa è la differenza fondamentale: Security Filtering è un meccanismo di applicazione; Delegation è un meccanismo di governance e controllo amministrativo.

Una persona può essere inclusa nel Security Filtering e non avere alcun diritto di modifica sulla GPO. Al contrario, un amministratore può avere il diritto di gestire la GPO senza che quella policy sia applicata a nessun computer specifico.

4. Perché i due livelli vanno letti separatamente

Nelle revisioni di hardening, la confusione nasce spesso perché Security Filtering e Delegation appaiono nello stesso contesto di Group Policy Management e usano entrambi la logica dei permessi di sicurezza. Da un lato si vede un ACL, dall'altro si vede un target di applicazione, e il rischio è quello di leggere tutto come se fosse la stessa cosa.

In realtà, i due livelli servono a finalità differenti:

• il filtering riguarda l'applicazione della policy ai destinatari corretti;
• la delegation riguarda il controllo amministrativo su chi può gestire la GPO.

Questa distinzione è importante perché una GPO può essere molto ben targettata eppure essere amministrata in modo troppo ampio. Al contrario, una GPO può avere una delega stretta ma un target di applicazione troppo generico. In entrambi i casi, la gestione del rischio non è la stessa.

Per decidere quale dei due finding affrontare per primo, consulta il framework per dare priorità ai finding di hardening Active Directory.

5. Casi tipici di rischio

Caso 1: filtering corretto, ma GPO ancora troppo esposta

Immaginiamo di avere una GPO che viene applicata solo a un gruppo molto ristretto di computer. A prima vista sembra tutto sotto controllo. Il problema è che la policy può essere ancora pericolosa se chiunque abbia accesso alla sua distribuzione o al suo contenuto può modificarla. In pratica: il targeting è giusto, ma il controllo sul contenuto della policy non lo è.

Questa è la differenza chiave. Il Security Filtering dice a quali oggetti la policy dovrebbe arrivare. Non dice però chi possa modificarla o chi possa interferire con il suo contenuto. Per questo, anche una GPO ben targettata può restare fragile se la sua protezione amministrativa è debole.

Caso 2: delega amministrativa troppo ampia

Immaginiamo una situazione molto comune: viene assegnata la delega di gestione di una GPO a tutto il reparto IT. Sul carta sembra sensato, perché il reparto IT ha competenze tecniche. Il problema è che quel gruppo include spesso sia gli amministratori di produttività, come quelli che gestiscono Exchange, Teams o altri servizi, sia gli amministratori di Active Directory. In questo caso, la delega finisce per essere troppo ampia per il contesto reale della GPO.

Il design di least privilege (principio del minimo privilegio, o PoLP) dovrebbe invece prevedere che solo gli amministratori di sistema o il team autorizzato a quel dominio specifico abbia accesso alla gestione della policy. Il principio del minimo privilegio significa assegnare solo i permessi strettamente necessari per svolgere un compito specifico, senza concedere accessi più ampi di quelli richiesti. Il risultato è un aumento del rischio sia di errore umano sia di abuso di privilegi.

Caso 3: uso di gruppi troppo generici

L'uso di gruppi come Authenticated Users, Domain Computers o gruppi di supporto condivisi può rendere difficile capire se una policy è davvero destinata a chi dovrebbe riceverla. In alcuni casi, però, l'uso di gruppi generici è inevitabile: ad esempio, se una GPO viene applicata alla root del dominio e il target è l'insieme di tutti gli utenti o di tutti i computer del dominio, allora il targeting di default può essere molto ampio per definizione.

Quello che non va comunque bene, però, è usare gruppi di questo tipo nella Delegation. La Delegation non dovrebbe mai utilizzare Authenticated Users o Domain Computers, perché questi gruppi non rappresentano un perimetro amministrativo reale. Se una delega viene assegnata a quel genere di gruppi, si perde il controllo su chi può effettivamente amministrare la GPO.

6. Esempio operativo di differenza

Immagina una GPO destinata a un gruppo di workstation di produzione.

• Il Security Filtering è impostato in modo che venga applicata solo a quel gruppo.
• Il permesso di Delegation consente a un team di supporto di modificarla.

In questo caso:

• la policy raggiunge solo i computer previsti;
• il team di supporto può ancora alterarne il contenuto.

Questa è la ragione per cui il design della GPO deve essere valutato su entrambi i piani: targeting e governance.

7. Checklist rapida per un design least-privilege

Prima di considerare una GPO "sicura", verificare almeno questi punti:

1. Il Security Filtering riflette davvero il target previsto della policy.
2. La Delegation è limitata a chi deve amministrare la GPO.
3. I gruppi usati per filtering e delega hanno un nome chiaro e un perimetro definito.
4. I permessi non sono assegnati in modo eccessivamente ampio a gruppi generici.
5. Le ACL relative al contenuto della GPO e alla distribuzione sono valutate separatamente.
6. Ogni eccezione è documentata e ha un owner operativo.

Da un punto di vista di governance intesa come sicurezza, la vera domanda non è solo "questa policy arriva dove dovrebbe?", ma anche "chi ha davvero il potere di modificarla, alterarla o usarla per ottenere effetti indesiderati?". Se le deleghe sono sbagliate, una GPO che sembra un semplice elemento di amministrazione può diventare un vettore di abuso. Un attaccante o un insider malintenzionato può sfruttare una delega troppo ampia per ottenere effetti molto più seri di quanto sembri a prima vista.

Per approfondire il tema delle ACL e dei permessi che rendono una GPO davvero fragile, vedi Audit permessi SYSVOL in Active Directory: come verificare chi puo modificare davvero le GPO. Il tema è vicino anche alla logica di hardening degli account amministrativi, ad esempio nella guida su Protected Users in Active Directory: cos'è, limiti, adminCount e rollout senza lockout.

Esempi concreti di abuso

1. GPO di password o sicurezza modificata da un gruppo troppo ampio: un operatore non autorizzato o un attaccante che ha ottenuto accesso a un gruppo di supporto può alterare una GPO che imposta criteri di sicurezza, disabilitare controlli, rimuovere restrizioni o introdurre impostazioni più permissive.
2. GPO di desktop o accesso applicativa modificata in modo malevolo: se una delega è stata concessa a un gruppo troppo ampio, un utente con accesso non appropriato può cambiare policy che controllano l'accesso a applicazioni, la restrizione di rete, il comportamento dei client o le regole di sicurezza locale.
3. GPO di distribuzione e logon usata come leva di persistence: un attaccante che ottiene accesso a una GPO amministrata in modo scorretto può aggiungere script di logon, modificare i profili utente o introdurre configurazioni che si applicano automaticamente ai computer target, creando persistenza e rendendo più difficile la rimozione dell'operazione malevola.

Quick check molto base

Se vuoi fare un primo controllo rapido senza entrare in dettagli troppo complessi, puoi usare una semplice verifica PowerShell per cercare segnali evidenti di deleghe troppo ampie o gruppi generici:

Import-Module GroupPolicy

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $permissions = Get-GPPermission -Name $gpo.DisplayName -All

    [PSCustomObject]@{
        GPO = $gpo.DisplayName
        Delegations = ($permissions | ForEach-Object {
            "$($_.Trustee) [$($_.PermissionLevel)]"
        }) -join "; "
    }
} | Format-Table -AutoSize

In pratica, cerca almeno questi segnali:

• deleghe assegnate a gruppi generici come Authenticated Users o Domain Computers;
• deleghe assegnate a interi reparti o gruppi molto ampi senza un perimetro chiaro;
• GPO che sembrano gestite da più team di quanti ne servano.

Per una revisione più strutturata, strumenti come GPOZaurr possono aiutare a evidenziare anomalie e deleghe fuori standard, ma non sostituiscono una review di governance e least privilege ben fatta.

Conclusione

Security Filtering e Delegation non sono intercambiabili. Il primo descrive chi dovrebbe applicare la policy; il secondo descrive chi può gestirla. Quando si progettano, si auditano o si correggono GPO in produzione, è fondamentale trattarli come due controlli distinti, ciascuno con il proprio rischio e il proprio modello di autorizzazione.

Questa distinzione aiuta a evitare false assunzioni, riduce la probabilità di errori di configurazione e consente di costruire un modello di governance GPO più robusto e più semplice da verificare.