Table of Contents



L'originale di questo articolo è consultabile al seguente uri :  http://social.technet.microsoft.com/wiki/contents/articles/design-considerations-for-delegation-of-administration-in-active-directory.aspx

Questo articolo è basato su un documento di Microsoft TechNet Library ed è presentato qui per permettere di migliorarlo alle persone esterne a Microsoft che sono interessate ed informate su questo argomento. Per leggere l'articolo ufficiale di Microsoft su questo argomento, vedere Considerazioni sulla progettazione della delega amministrativa in Active Directory   sulla libreria TechNet Microsoft .
 

Considerazioni sulla progettazione dellla delega amministrativa in Active Directory (it-IT)

Raggiungere autonomia e isolamento con foreste, domini e unità organizzative
Una funzionalità chiave del servizio directory Active Directory ® in Microsoft ® Windows ® 2000 è la delega dell'amministrazione. Attraverso la delega dell'amministrazione, è possibile progettare un'infrastruttura di directory che si estende su più organizzazioni, consentendo di soddisfare i requisiti specifici per l'indipendenza strutturale ed operativa.
In Active Directory, gli amministratori possono delegare sia la gestione del servizio che la gestione dei dati. La gestione può essere delegata per raggiungere l’autonomia tra le organizzazioni o l’isolamento tra le organizzazioni. In questo white paper vengono illustrate considerazioni sulla progettazione di Active Directory e sulle implicazioni di sicurezza quando si utilizzano le foreste, i domini o le unità organizzative per la delega dell'amministrazione.
In questa pagina
Introduzione
Concetti della delega
In questa pagina
Introduzione
Concetti della delega
Delega dell'amministrazione, con foreste, domini e unità organizzative 
Procedure consigliate per gli amministratori del servizio e limitazioni all'accesso fisico sui controller di dominio
Conclusione 
Appendice – informazioni base per i requisiti di fiducia all'amministratore del servizio e requisiti di accesso fisico ai Domain Controller

Introduzione

Una funzionalità chiave del servizio directory di Active Directory in Microsoft ® Windows ® 2000 è la delega dell'amministrazione. Attraverso la delega dell'amministrazione, un'infrastruttura directory può essere progettata per comprendere più organizzazioni che hanno requisiti di gestione specifici. In particolare, la delega dell'amministrazione di Active Directory può aiutare le organizzazioni a soddisfare requisiti specifici per l'indipendenza strutturale ed operativa.
In Active Directory, gli amministratori possono delegare sia la gestione del servizio che la gestione dei dati. La gestione può essere delegata per raggiungere l’autonomia tra organizzazioni o l’isolamento tra le organizzazioni .Questo documento vengono illustrate considerazioni sulla progettazione di Active Directory e sulle implicazioni di sicurezza quando si utilizzano le foreste, i domini o le unità organizzative per la delega dell'amministrazione.
La discussione si presuppone che il lettore conosca concetti e le procedure associate alla progettazione e distribuzione di Active Directory. Per ulteriori informazioni sulla pianificazione e la distribuzione di Active Directory, vedere la serie di documenti : http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].
Inizio della pagina 

Concetti della delega

Per capire come delegare l'amministrazione di Active Directory, dobbiamo prima capire perché le organizzazioni potrebbero delegare l'amministrazione e i diversi tipi di responsabilità amministrativa che può essere delegata.
Motivi per delegare l’amministrazione
Le organizzazioni in genere delegano l'amministrazione per tre tipi di motivazione :
·    Struttura organizzativa — parti di un'organizzazione potrebbero partecipare a un'infrastruttura condivisa per ridurre i costi, ma richiedere la capacità di operare in modo indipendente dal resto dell'organizzazione.
·    Requisiti operativi — una parte di un'organizzazione o una applicazione che sfrutta l'Active Directory potrebbero porre vincoli  specifici sulla configurazione del servizio di directory, sulla continuità o sulla sicurezza. Esempi si trovano in:
o  Organizzazioni militari
o  Scenari di hosting
o  Scenari extranet oppure di directory esposte al mondo esterno
o  Istituzioni finanziarie
o  Appaltatori della difesa
o  Organizzazioni governative
Per tali ragioni, un'organizzazione potrebbe dover delegare il controllo sulla gestione dei servizi, sulla gestione dei dati o entrambi. In base alle esigenze specifiche dell'organizzazione, scopo di tale delega potrebbe essere raggiungere l'isolamento, l'autonomia o entrambi. Un primo passo importante nella progettazione di Active Directory è definire con precisione le esigenze di un&tori della difesa
o  Organizzazioni governative
Per tali ragioni, un'organizzazione potrebbe dover delegare il controllo sulla gestione dei servizi, sulla gestione dei dati o entrambi. In base alle esigenze specifiche dell'organizzazione basandosi sui concetti di gestione dei servizi, gestione dei dati, autonomia e isolamento. Questi concetti sono definiti qui di seguito.
Gestione del servizio e gestione dei dati
Le responsabilità amministrative che vengono delegate in Active Directory possono essere separate in due tipi: responsabilità per la fornitura del servizio di directory (gestione del servizio) e la responsabilità per i contenuti memorizzati o protetti dal servizio directory (gestione dei dati). Gli amministratori con queste responsabilità sono gli amministratori del servizio o gli amministratori dei dati.
·    Gli amministratori dei servizi — gli amministratori del servizio Active Directory sono responsabili per la configurazione e la distribuzione del servizio directory. Ad esempio, gli amministratori dei servizi mantengono i controller di dominio, controllano le impostazioni di configurazione a livello di directory e sono responsabili di garantire la disponibilità del servizio.
·    Gli amministratori di dati — gli amministratori dati di Active Directory sono responsabili per la gestione dei dati archiviati in Active Directory o nei computer appartenenti ad Active Directory e non hanno alcun controllo sulla configurazione o la distribuzione del servizio directory. Gli amministratori di dati includono:
o  Amministratori che controllano un sottoinsieme di oggetti nella directory. Attraverso il controllo di accesso ereditabile a livello di attributo, agli amministratori di dati può essere concesso il controllo di sezioni molto specifiche della directory, senza avere alcun controllo sulla configurazione del servizio stesso.
o  Amministratori che gestiscono computer membri appartenenti alla directory e i dati archiviati su tali computer.
o  In molti casi, la configurazione del servizio della directory è determinata dai valori degli attributi su oggetti memorizzati nella directory. Di conseguenza, gli amministratori dei servizi di Active Directory sono anche gli amministratori di dati.
Autonomia e isolamento
I requisiti di delegazione di un'organizzazione generalmente rientrano in due categorie: autonomia e isolamento.
·    Autonomia — autonomia è la capacità degli amministratori di un'organizzazione di gestire in modo indipendente:
o  Tutta la gestione del servizio o parte di esso (autonomia dei servizi).
o  Tutti (o parte) dei dati memorizzati nella directory o su computer membri che partecipano alla directory (l'autonomia dei dati).
·    Isolamento — l'isolamento è la capacità degli amministratori di un'organizzazione di impedire ad altri amministratori di:
o  Controllare o interferire con la gestione del servizio (isolamento dei servizi).
o  Controllare o la visualizzare un sottoinsieme di dati nella directory o su computer che partecipano alla directory (isolamento dei dati).
L’autonomia è meno vincolante rispetto all’isolamento. Gli amministratori che richiedono solo autonomia accettano che nel sistema esistano altri amministratori con privilegi uguali o superiori che hanno un controllo equivalente o superiore (al loro). Gli amministratori che richiedono specificamente l’isolamento cercano di bloccare ad altri amministratori la visione o il controllo della loro parte di servizi o di gestione dei dati. Poiché l'autonomia è meno vincolante dell’isolamento, è in genere meno costosa e più efficiente delegare l’autonomia in Active Directory.
La combinazione di gestione dei servizi, gestione dei dati, autonomia e requisiti di isolamento determina quale struttura Active Directory utilizzerà per delegare il controllo di un'organizzazione.
Nota: In molte organizzazioni di piccole o medie dimensioni, non è insolito per tutto i servizi e per tutta la gestione dei dati in Active Directory essere sotto il controllo di un singolo e gruppo IT. Tali organizzazioni che non hanno alcun requisito specifico di autonomia o di isolamento possono utilizzare un foresta unica, un singolo dominio Active Directory e trattare le procedure in questo documento come semplice riferimento.
Inizio della pagina

Delega dell'amministrazione, con foreste, domini e unità organizzative

Tre differenti strutture possono essere utilizzati per delegare l'amministrazione di Active Directory: foreste, domini e unità organizzative (ou). La sezione seguente descrive brevemente le caratteristiche di ogni struttura, e quando è appropriato scegliere una struttura basata su specifici requisiti di delega.
Per ulteriori informazioni sulla progettazione di Active Directory, vedere la serie di documenti : http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].
Foreste, domini e unità organizzative
Per capire la discussione della delega che segue, è utile esaminare brevemente le definizioni e le caratteristiche di gestione delle foreste di Active Directory, domini e unità organizzative.
Una foresta è un insieme di domini con una configurazione e uno schema condivisi, rappresentati da un unico catalogo globale e collegati da una rete completa di trust transitive. Una foresta è rappresentata da un dominio radice della foresta. Il proprietario amministrativo predefinito di una foresta è il gruppo Domain Admins del dominio radice della foresta. Il gruppo Domain Admins del dominio principale controlla l'appartenenza ai gruppi Enterprise Admins e Schema Admins, che, per impostazione predefinita, controllano le configurazioni a livello di foresta. Dato che il proprietario della foresta gestice i controller di dominio, il proprietario della foresta è un amministratore del servizio.
Un dominio è una partizione in una foresta di Active Directory. Il proprietario amministrativo di un dominio è per default il gruppo Domain Admins del dominio. Datosi che  il proprietario del dominio controlla i controller di dominio, il proprietario del dominio è un amministratore del servizio. Tutti i proprietari del dominio non radice in una foresta sono di pari livello, indipendentemente dalla posizione del loro dominio nella gerarchia dei nomi; il proprietario di un dominio padre non radice della foresta non dispone di alcun controllo amministrativo predefinito su un dominio figlio.
Un' unità organizzativa (OU) è un contenitore all'interno di un dominio. Il controllo su una unità organizzativa e gli oggetti in una unità organizzativa cono determinati interamente dalla Access Control List (ACL) sull'unità organizzativa e sugli oggetti nell'unità organizzativa. Utenti e gruppi che hanno il controllo su oggetti in unità organizzative sono amministratori di dati.
Maggiore sarà il numero delle organizzazioni che possono partecipare in una foresta, maggiori sono i possibili benefici dalla collaborazione e i risparmi sui costi. Per questo motivo, è consigliabile ridurre al minimo il numero di foreste in una distribuzione di Active Directory. Tuttavia, ci sono situazioni in cui i requisiti di delega rendono la creazione di più foreste del tutto appropriata.
Ad esempio, nelle organizzazioni dove il controllo amministrativo è estremamente distribuito, può essere impraticabile aspettarsi che tutte le organizzazioni partecipino alla stessa infrastruttura. In queste situazioni, il costo di gestione di un insieme di strutture aggiuntive barattato con la soddisfazione di questa esigenza pratica.
Informazioni su strutture di Directory e proprietari di struttura di Directory
I seguenti fatti riguardo le strutture di Active Directory e gli amministratori sono importanti quando si sceglie una struttura di directory per una delegazione. Per l’utilizzo di queste informazioni in sede di semplice selezione di una struttura, fare riferimento a "Selezionare una struttura basata su requisiti di delega", più avanti in questo documento.
1. I proprietari del dominio non possono impedire che i proprietari di foreste controllino i loro servizi e abbiano accesso ai loro dati.Sebbene sia possibile rimuovere l'accesso a un dominio per gli Enterprise Admins, generalmente non è possibile impedire l'accesso agli oggetti in domini non root al proprietario della foresta. Ad esempio, i membri del gruppo Schema Admins (che è controllato dal gruppo Domain Admins del dominio radice della foresta) possono modificare il descrittore di protezione predefinito su una classe di oggetti per concedere il controllo completo al gruppo Enterprise Admins su una classi di oggetti appena creata. Di conseguenza, le organizzazioni che partecipano a una foresta devono concedere fiducia al proprietario della foresta.
2. I proprietari di un dominio mantengono il diritto di accedere ai dati memorizzati in un dominio o ospitato su computer appartenenti a un dominio. Gli amministratori del servizio di un dominio non possono essere esclusi dalla visione o dalla manipolazione dei dati memorizzati in un dominio o sui computer appartenente a un dominio. Questa è una conseguenza delle seguenti caratteristiche di Active Directory:
o  Il gruppo Builtin\Administrators in un controller di dominio può assumere la proprietà di qualsiasi oggetto del dominio e quindi leggere, modificare o cancellare, indipendentemente dalla ACL esistente per l'oggetto. Questa caratteristica dà gli amministratori dei servizi un modo per correggere gli errori nelle ACL applicate agli oggetti. Di conseguenza, le organizzazioni che archiviano i dati in unità organizzative di un dominio devono concedere fiducia al proprietario del dominio.
o  Un amministratore del servizio può modificare intenzionalmente il software di sistema su un controller di dominio per ignorare i controlli di sicurezza normali. Un amministratore del servizio può utilizzare questa procedura per visualizzare o modificare qualsiasi oggetto del dominio, indipendentemente dalla ACL per l'oggetto. Di conseguenza, le organizzazioni che archiviano i dati in unità organizzative di un dominio devono concedere fiducia  al proprietario del dominio.
o  Un amministratore del servizio può utilizzare i criteri di sicurezza dei gruppi con restrizioni per concedere qualsiasi utente o gruppo l'accesso amministrativo a qualsiasi computer del dominio. Questa caratteristica garantisce che un amministratore può sempre ottenere il controllo su un computer del dominio, indipendentemente dalle intenzioni del proprietario del computer. Di conseguenza, le organizzazioni che inseriscono computer in un dominio devono concedere fiducia al proprietario del dominio.
o  Se a un utente o a un gruppo in un dominio viene concesso l'accesso ai dati memorizzati su un computer che fa parte della foresta, il proprietario del dominio dell'utente o del gruppo può reimpostare la password dell'utente o manipolare l'appartenenza al gruppo e così facendo guadagnare l’accesso ai dati. Di conseguenza, le organizzazioni che aggiungere computer a una foresta devono concedere fiducia a ogni proprietario di dominio della foresta.
3. i proprietari del dominio non possono impedire che altri proprietari di dominio malintenzionati controllino i loro servizi e accedano ai loro dati. A causa della natura strettamente legata di una foresta di Active Directory, è possibile che i proprietari del dominio utilizzino metodi malevoli per ottenere l'accesso ad altri domini della foresta. Ad esempio, è possibile che un proprietario di dominio malintenzionato modifichi il software di sistema su un controller di dominio e così facendo interferisca con il funzionamento di un qualsiasi dominio della foresta, veda o manipoli i dati di configurazione della foresta, visualizzi o manipoli i dati memorizzati in un qualsiasi dominio, oppure visualizzi o manipoli i dati memorizzati su qualsiasi computer inserito nella foresta. Pertanto, il proprietario della foresta deve concedere fiducia a tutti i proprietari di dominio in una foresta e tutti i proprietari di dominio in una foresta devono considerarsi attendibili l’un l'altro.
  1. Controller di dominio all'interno di una foresta non possono essere isolati tra di loro. A causa della natura distribuita di Active Directory, la violazione della sicurezza di un singolo controller di dominio può avere effetti in tutta una foresta. Ad esempio, è possibile che un utente malintenzionato che ha accesso fisico a un controller di dominio apporti modifiche non in linea al database di directory e così facendo interferisca con il funzionamento di qualsiasi dominio della foresta, visualizzi o manipoli i dati memorizzati in un punto qualsiasi della foresta oppure visualizzi o manipoli i dati memorizzati su qualsiasi computer che della foresta. Di conseguenza, l'accesso fisico ai controller di dominio deve essere limitato a personale di fiducia.
Considerare attendibili gli amministratori dei servizi
Per riassumere le conseguenze delle informazioni (fin qui elencate) sulle strutture di directory e sui proprietari della struttura di directory, un'organizzazione per partecipare a una infrastruttura di dominio o di foresta, deve scegliere di concedere fiducia a tutti gli amministratori dei servizi nella foresta e in tutti i domini. In questo contesto, dare fiducia agli amministratori dei servizi significa:
·    Avere fondati motivi per credere che gli amministratori dei servizi operano nell’interesse dell'organizzazione. Le organizzazioni non dovrebbero entrare in una foresta o in un dominio se i proprietari del dominio o della foresta possono avere motivi legittimi per agire intenzionalmente contro l'organizzazione.
·    Comprendere e accettare i rischi per l'organizzazione associati agli amministratori con intenti criminali e agli amministratori sottoposti a coercizione.
o  Amministratori con intenti criminali  - è sempre possibile che amministratori normalmente affidabili si rivelino malintenzionati e abusino del potere che essi hanno nel sistema.
Alcune organizzazioni potrebbero accettare il rischio di violazioni della sicurezza da amministratori con intenti criminali o dagli amministratori sottoposti a coercizione (che operano) su altre parti dell'organizzazione. Tali organizzazioni potrebbero valutare che il beneficio derivato dalla collaborazione e il risparmio derivati dal partecipare ad un'infrastruttura condivisa prevalgono sul rischio. Tuttavia, altre organizzazioni potrebbero non accettare questo rischio perché le conseguenze di una violazione della sicurezza sarebbero troppo gravi.
Nota: documentazione  precedentemente pubblicata su Active Directory afferma che un dominio è un limite di sicurezza, ma non fornisce dettagli specifici circa il livello di autonomia e isolamento possibile tra domini in una foresta. Anche se un dominio è in realtà un limite di protezione quando si considera gli aspetti della gestione di Active Directory, non fornisce completo isolamento di fronte a possibili attacchi dagli amministratori di servizio che modificano con intenzioni malevole il comportamento del sistema. Per ulteriori informazioni, vedere l'appendice a questo documento.
Selezionare una struttura basandosi sui requisiti di delega
La Figura 1 illustra il processo decisionale per determinare se i requisiti specifici di delega di un'organizzazione giustificano la delega del controllo di una foresta separata, di un dominio o di una unità organizzativa a quell'organizzazione. Per utilizzare il processo, eseguire il seguente esercizio concettuale :
1. Iniziare inserendo tutte le organizzazioni in una foresta con dominio singolo.
2. Per ogni organizzazione con specifici requisiti amministrativi, utilizzare il processo di decisione per determinare il modo appropriato di agire.
3. Quando si prende nota della motivazione per ogni decisione, assicuratevi di osservare :
o  Se il requisito della delegazione è imposto da uno o più requisiti organizzativi, operativi, legali o altro.
o  Se il requisito è per la delega di gestione di un servizio, gestione dei dati o entrambi.
o  Se il requisito è per autonomia, isolamento o entrambi.
Il processo di decisione per la delega dell'amministrazione è illustrato nella figura 1 e discusso in dettaglio in una serie di scenari che seguono l’illustrazione.
Figura 1: Processo per la determinazione dei requisiti di delega per l'organizzazione
Scenario 1: Creazione di foreste per l'isolamento di servizio
Un'organizzazione che ha bisogno di isolamento dei servizi richiede che nessun amministratore al di fuori dell'organizzazione possa interferire con il funzionamento della directory. L'isolamento è in genere imposto da requisiti operativi o giuridici. Per fornire l'isolamento dei servizi, occorre creare una nuova foresta per l'organizzazione.
I requisiti operativi che guidano l'isolamento dei servizi potrebbero includere quanto segue:
·    Una società di produzione potrebbe avere un'applicazione critica abilitata alle Active Directory che controlla un’apparecchiatura utilizzata da diversi operai. Se questa azienda considera il funzionamento delle attrezzature di fabbrica come massima priorità, potrebbe scegliere di creare una singola foresta di tutta la società per le normali funzioni amministrative e una foresta separata per ogni stabilimento critico. In questo modo fabbriche critiche potrebbero continuare ad operare indipendentemente dallo stato della foresta della società e dallo stato di altre fabbriche.
·    Una Marina militare potrebbe richiedere che la cattura di una singola nave non abbia il potenziale di compromettere l’erogazione di servizi per un intero gruppo di battaglia o per l'intera Marina. Per contenere l'impatto della cattura di una singola nave alla nave stessa, la Marina potrebbe creare una foresta separata per ogni nave.
·    Una società di hosting potrebbe desiderare di collocare i controller di dominio di un cliente nei locali dedicati al cliente stesso. Poiché la violazione di un controller di dominio da sola può influire sulla fornitura di servizi nel resto di una foresta,  si potrebbe creare una foresta separata per ogni cliente che richiede controller di dominio nei locali. In caso contrario, un client manomesso con accesso fisico a un controller di dominio nei loro locali potrebbe essere in grado di interferire con il funzionamento della directory per gli altri clienti nella stessa foresta.
Considerazioni particolari per le foreste di isolamento del servizio sono i seguenti:
·    Foreste create per l'isolamento dei servizi possono avere trust con domini di altre foreste, ma non devono includere gli utenti dalle altre foreste nei gruppi amministrativi. Se gli utenti dalle altre foreste sono inclusi nei gruppi amministrativi della foresta isolata, una violazione dell’altra foresta potrebbe portare a una violazione della foresta isolata.
·    Sebbene la creazione di una foresta separata possa fornire isolamento del servizio, è importante notare che fino a che i controller di dominio sono accessibili su una rete, essi sono soggetti ad attacchi (ad esempio attacchi denial of service) dai computer in rete. Le organizzazioni che decidono che il rischio di attacco è troppo alto, o che la conseguenza di un attacco o violazione sono troppo grandi, possono effettuare le seguenti operazioni:
o  Valutare attentamente l'affidabilità delle reti che contengono i controller di dominio.
o  Limitare l'accesso alle reti che contengono i controller di dominio.
L’accesso può essere limitato utilizzando tecnologie come firewall e IPSEC. Per ulteriori informazioni sul limitare l'accesso tramite firewall e IPSEC, vedere Windows 2000 Server Resource Kit al link http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx [http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx].
Scenario 2: Creazione di foreste per l'autonomia dei servizi a livello di foresta
Una foresta è costituito da un insieme di domini con contenitore dello schema e un contenitore di configurazione condivisi. Questi contenitori sono controllati dal proprietario della foresta.
·    Schema:Lo schema della foresta determina quali classi di oggetti possono essere creati nella directory e quali attributi sono associati a tali oggetti. Le applicazioni che si avvalgono di Active Directory possono estendere lo schema per includere dati specifici dell'applicazione.
·    Configurazione:Dati memorizzati nel contenitore di configurazione includono:
o  Dati che definiscono la topologia dei siti e della replica della foresta.
o  Varie impostazioni a livello delle policy di foresta, ad esempio una policy LDAP basata su sito e una a livello di foresta (per i controller di dominio).
o  Informazioni che identificano l’insieme dei domini nella foresta e la gerarchia di trust. Ogni dominio della foresta ha una trust con tutti gli altri domini della foresta. Attraverso il controllo di questi dati di configurazione, il proprietario della foresta controlla la creazione di nuovi domini della foresta.
o  Applicazioni abilitate per Active Directory possono memorizzare i dati di configurazione a livello di foresta nel contenitore configurazione. Un esempio di tali applicazioni è Microsoft ® Exchange 2000.
Se un'organizzazione richiede la capacità di manipolare in modo indipendente il contenitore di configurazione o dello schema, essa richiede una propria foresta. Questo requisito è tipicamente guidato dalla struttura organizzativa o da requisiti operativi.
Un requisito di struttura organizzativa che spinge all'autonomia dei servizi a livello di foresta potrebbe essere il seguente:
·    Una divisione di un'azienda potrebbe voler installare applicazioni abilitate all'uso di directory che estendono lo schema, senza consultare altre divisioni dell'azienda. La creazione di una foresta separata scambia i costi supplementari di gestione di una foresta separata con l'autonomia a livello di foresta.
Un'esigenza operativa che spinge all'autonomia dei servizi a livello di foresta potrebbe essere la seguente:
Una considerazione speciale per la creazione di foreste per l'autonomia dei servizi a livello di foresta è il seguente:
·      Le organizzazioni che giustificano la creazione di una foresta separata con requisiti relativi alla struttura organizzativa devono essere consapevoli che nella realizzazione di più foreste è necessario bilanciare costi e benefici. Anche se un'organizzazione potrebbe preferire le operazioni del servizio in autonomia, potrebbe essere più conveniente a concedere la responsabilità per la fornitura di servizi ad un gruppo IT affidabile centralizzato. In questo modo, l'organizzazione IT del gruppo può partecipare alla gestione dei dati nella foresta, ma elimina il costo di ottenere personale specializzato nella gestione dei servizi directory. Per ulteriori informazioni sul bilanciare costi e benefici in questo scenario, consultare la serie Best Practice nella distribuzione di Active Directory http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].
Scenario 3: Delega di domini per l'autonomia dei servizi a livello di dominio
Un'organizzazione potrebbe concordare nel consentire che la configurazione a livello di foresta sia gestita da un proprietario della foresta, ma potrebbe ancora desiderare di avere autonomia dei servizi a livello di dominio. I seguenti elementi del servizio sono controllati in modo indipendente a livello di dominio:
·    Disponibilità del servizio —Il proprietario del dominio ha la capacità di creare, eliminare, salvare e ripristinare i controller di dominio al fine di soddisfare un livello stabilito di disponibilità del servizio.
·    Trust esterno —Il proprietario del dominio può determinare quali domini in altre foreste avranno una trust.
·    Criteri di account utente di dominio —Certe politiche che governano gli account utente di dominio possono essere controllate solo a livello di dominio. Questi criteri sono:
o  Criterio password
o  Criterio di blocco account
o  Politica di vita del ticket Kerberos
Per delegare la capacità di controllare autonomamente questi aspetti del servizio, un proprietario della foresta può delegare un dominio nell'organizzazione. Considerazioni particolari per la delega di un dominio sono i seguenti :
·         In conseguenza delle informazioni su Active Directory discusse in precedenza in questo documento (vedere " Informazioni su strutture di Directory e proprietari di struttura di Directory"), il proprietario di una foresta deve delegare un dominio ad una organizzazione  solo se il proprietario della foresta e tutti i proprietari di dominio considerano attendibile il proprietario del dominio dell’organizzazione delegata. In base a questo requisito, è una pratica consigliata centralizzare le proprietà della foresta e dei servizi di dominio in una singola organizzazione responsabile della foresta e utilizzare domini solo per il partizionamento geografica della replica. Poiché tutti gli amministratori del servizio sono attendibili, delegazione può essere tranquillamente fatto interamente a livello dell'unità organizzativa.
·    I domini forniscono autonomia dei servizi a livello di dominio, ma non forniscono isolamento dei dati dal proprietario della foresta o altri proprietari di dominio. Se un'organizzazione richiede l'isolamento dei dati rispetto ai proprietari di servizio, è necessario creare foreste separate. Per ulteriori informazioni, vedere "Scenario 4: creazione di foreste per dati isolate dai proprietari del servizio", più avanti in questo documento.
·    In un'organizzazione di grandi dimensioni è possibile che l'organizzazione IT che possiede la foresta sia diversa dall'organizzazione IT che gestisce tutte le altre operazioni di directory. In questa situazione è consigliabile creare un dominio radice della foresta dedicato. Il proprietario del dominio radice della foresta controlla il dominio radice dedicato della foresta e l'organizzazione IT operativa ha la proprietà di uno o più domini figlio. In questo modo l'organizzazione IT operativa può gestire autonomamente la disponibilità del servizio, ma non controlla l'appartenenza dei gruppi Enterprise Admins e Schema Admins nel dominio radice della foresta. Si noti che un dominio root  della foresta dedicato garantisce protezione solo contro l'abuso non intenzionale o accidentale dei privilegi; i proprietari di domini non root possono ancora utilizzare metodi dannosi per tentare di manipolare i gruppi nel dominio radice.
Per ulteriori informazioni sulle best practice nella progettazione del partizionamento di dominio geografico e sul dominio root dedicato per la foresta consultare i documenti Best Practice seguenti http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].
Scenario 4: creazione di foreste per dati isolate dai proprietari del servizio
Datosi che i dati archiviati in Active Directory e sui computer fanno parte di Active Directory non possono essere isolati dagli amministratori del servizio di directory, l'unico modo per un'organizzazione di ottenere l'isolamento completo dei dati è di creare una foresta separata. Questa situazione può verificarsi in un'organizzazione in cui gli amministratori dei servizi sono normalmente affidabili, ma le conseguenze di un attacco da un amministratore malintenzionato o costretto con coercizione possono avere un impatto grave sull'organizzazione. Questo tipo di requisito per l'isolamento dei dati in genere è imposto da requisiti legali.
Requisiti legali che impongono la necessità di isolamento dei dati da parte dei proprietari del servizio sono i seguenti :
·    Una istituzione finanziaria è obbligata per legge a limitare l'accesso ai dati dei clienti in una particolare giurisdizione agli utenti, computer e agli amministratori che si trova in tale giurisdizione. Anche se l'ente darebbe normalmente fiducia gli amministratori dei servizi che lavorano di fuori della giurisdizione protetta, violando la limitazione di accesso potrebbe far perdere all'istituzione la sua capacità di fare affari in tale giurisdizione.
·    Un appaltatore dell’esercito è obbligato per legge a limitare l'accesso ai dati del progetto di difesa a un insieme di utenti specificato. Anche se il contraente darebbe normalmente fiducia gli amministratori dei servizi che controllano i sistemi di computer connessi ad altri progetti, la conseguenza di una violazione da parte di questi amministratori dei servizi potrebbe essere la perdita della capacità di avere contratti con il governo.
Considerazioni particolari per la creazione di foreste per l'isolamento dei dati da parte dei proprietari del servizio sono i seguenti:
·    Foreste create per l'isolamento dei dati possono avere trust con domini da altre foreste, ma gli utenti dalle altre foreste non dovrebbero essere inclusi in uno qualsiasi dei seguenti gruppi:
o  Gruppi responsabili della gestione del servizio o gruppi che possono gestire l'appartenenza a gruppi di amministratori di servizio
o  Gruppi con controllo amministrativo di computer che archiviano i dati protetti
o  Gruppi che hanno accesso ai dati protetti, o gruppi, responsabili per la gestione di oggetti utente o gruppo che hanno accesso ai dati protetti
Se gli utenti da un'altra foresta sono inclusi in uno qualsiasi di questi gruppi, una violazione di altra foresta potrebbe portare a una violazione della foresta isolata e alla divulgazione di dati protetti.
·    Sebbene la creazione di una foresta separata consente l'isolamento dei dati, è importante notare che, finché i controller di dominio delo accesso ai dati protetti, o gruppi, responsabili per la gestione di oggetti utente o gruppo che hanno accesso ai dati protetti
Se gli utenti da un'altra foresta sono inclusi in uno qualsiasi di questi gruppi, una violazione di altra foresta potrebbe portare a una violazione della foresta isolata e alla divulgazione di dati protetti.
· o  Considerare con attenzione l'affidabilità delle reti che ospitano i controller di dominio o computer contenente dati protetti
o  Limitare l'accesso per le reti che ospitano i controller di dominio e i computer che ospitano dati protetti utilizzando tecnologie come firewall e IPSEC
Scenario 5: Delega di unità organizzative per autonomia e isolamento dei dati da non proprietari di servizi
Un'organizzazione può affidare la proprietà del servizio a livello di foresta e di dominio ad una organizzazione separata, attendibile, conservando controllo autonomo sui suoi dati mettendoli in un'unità organizzativa. Possono essere collocate autorizzazioni sui dati in modo che siano visibili solo a utenti specifici. Questo permette a un'organizzazione di isolare i suoi dati da altre organizzazioni  che non sono proprietarie di servizi che controllano OU nello stesso dominio o nella stessa foresta
Un requisito di struttura organizzativa che giustifica l'utilizzo di unità organizzative per la delega è il seguente:
·    Una business unit in un'azienda potrebbe richiedere la capacità di creare, modificare e cancellare gli account utente per i propri dipendenti in modo indipendente. Se la business unit non ha nessun requisito di isolare questi account utente dai proprietari di servizio, è sicuro per questa business unit di accettare una delega a livello di OU.
Un'esigenza operativa che giustifica l'utilizzo di unità organizzative per la delega è la seguente:
·    Una società di hosting che mantiene tutte le proprietà del servizio in una foresta e limita l'accesso fisico al personale della società di hosting può delegare le unità organizzative ai clienti. Questi clienti possono gestire autonomamente i loro dati di directory e potrebbero anche scegliere di avere i loro dati nascosti da altri clienti che condividono la stessa infrastruttura.
Segue una considerazione speciale per la delega dell'unità organizzative:
·    Un'unità organizzativa delegata è appropriata solo se l'organizzazione è convinta che tutti i proprietari di servizio nella foresta sono affidabili, e tutti i controller di dominio della foresta sono fisicamente protetti.
Inizio della pagina

·    Un'unità organizzativa delegata è approp>Procedure consigliate per gli amministratori del servizio e che limitano l'accesso fisico ai controller di dominio

Poiché gli amministratori dei servizi devono essere altamente attendibili, è importante capire quali gruppi amministrativi di Active Directory sono amministratori dei servizi, e quali sono le Procedure consigliate da seguire per questi gruppi.
Gli amministratori dei servizi in Active Directory includono:
·    Qualsiasi gruppo che legittimamente può modificare le impostazioni di configurazione di directory
·    Qualsiasi gruppo che può installare un controller di dominio
·    Qualsiasi gruppo che può installare o modificare il software sui controller di dominio
·    Qualsiasi gruppo che può modificare l'appartenenza a un altro gruppo di amministratore del servizio
Per la versione di Windows 2000 di Active Directory, questi gruppi comprendono:
·    Gruppi controllati dal proprietario di una foresta
o  Enterprise Admins
o  Schema Admins
·    Gruppi controllati dal  proprietario di un dominio
o  Gruppo Domain Admins
o  Builtin\Administrators
o  Builtin\Server Operators
o  Builtin\Backup Operators
 Per ridurre la possibilità di attacco da amministratori di servizio o tramite l'accesso fisico ai controller di dominio, sono consigliate le seguenti procedure :
·    Ridurre al minimo il numero dei membri nei
·    Consentire solo altri gruppi di amministratori del servizio la modifica dell'appartenenza a gruppi di amministratori di servizio
·    Non includere utenti o gruppi da foreste trusted esterne in gruppi di amministratore di servizio nella foresta a meno che gli amministratori del servizio dalla foresta esterna siano attendibili come gli amministratori della foresta (interna)
·    Effettuare audit delle modifiche all’appartenenze al gruppo di amministratori del servizio
·    Accedere utilizzando le credenziali dell'amministratore del servizio solo se strettamente necessario; fornire account utente alternativi agli amministratori per lavoro quotidiano
·    Consentire solo ai gruppi amministratori di servizio di gestire le postazioni utilizzate dagli amministratori di servizio
·    Limitare l'accesso fisico ai controller di dominio per gli amministratori dei servizi; non posizionare controller di dominio in luoghi che non possono essere protetti
·    Ridurre al minimo il software utilizzato  sui controller di dominio
·    Formare gli amministratori dei servizi sull'importanza di osservare le procedure consigliate
Inizio della pagina 

Conclusione

Active Directory fornisce un'infrastruttura che consente la collaborazione tra le persone e le organizzazioni. Durante la progettazione per la delega dell'amministrazione, i progettisti devono definire le loro esigenze di delega, comprendere le implicazioni di sicurezza della delega ed essere consapevoli dei compromessi tra collaborazione, autonomia e isolamento in un'infrastruttura di directory.
Per consentire la massima collaborazione con il minor costo, un'organizzazione può implementare un design di foresta singola con una singola organizzazione IT che possiede tutta la gestione del servizio di foresta e dominio e delegare l'autonomia o isolamento dei dati ad altre organizzazioni utilizzando unità organizzative. Ciascuna organizzazione partecipante deve dare fiducia al proprietario del servizio, prima di entrare nella foresta.
Alcune organizzazioni hanno requisiti specifici di autonomia o di isolamento rendono la fiducia a un proprietario di servizio centrale impraticabile o imprudente. Queste organizzazioni possono realizzare più disegni di foresta e abilitare la collaborazione tra foreste attraverso sistemi di gestione aggiuntivi quali Microsoft Metadirectory Services (MMS).
Per ulteriori informazioni su MMS, vedere http://www.microsoft.com/windows2000/technologies/directory/MMS/default.asp [http://www.microsoft.com/windows2000/technologies/directory/mms/default.asp].
Inizio della pagina 

Appendice – informazioni base per i requisiti di fiducia all'amministratore del servizio e requisiti di accesso fisico ai Domain Controller

Le procedure di progettazione in questo documento presuppongono  che qualsiasi organizzazione che partecipa a una foresta dia fiducia a tutti gli amministratori del servizio foresta (iderazioni-sulla-progettazione-della-delega-dell-amministrazione-in-active-directory-it-it/edit.aspx#Inizio%20Pagina">Inizio della pagina 

Implicazioni di sicurezza dell’accesso come amministratore di servizio e accesso fisico