4.1 Caratteristiche del modello di delega dinamico

Con DRA è possibile gestire l'accesso amministrativo all'azienda nell'ambito di un modello di delega. Il modello di delega consente di configurare l'accesso di "minimo privilegio" per gli amministratori aggiunti attraverso un set di controlli dinamico che può essere adattato ai cambiamenti e alle evoluzioni aziendali. Mediante il modello di delega è possibile ottenere il controllo dell'accesso amministrativo che meglio risponde alle modalità operative dell'azienda:

  • Grazie a regole con ambiti flessibili, gli amministratori possono definire autorizzazioni mirate per oggetti gestiti specifici in funzione delle esigenze anziché della struttura aziendale.

  • La delega basata sui ruoli assicura che le autorizzazioni vengano concesse in modo coerente e semplifica il provisioning.

  • È possibile amministrare l'assegnazione dei privilegi su domini, tenant cloud e applicazioni gestite da un'unica ubicazione.

  • I poteri differenziati permettono di adattare l'accesso specifico concesso agli amministratori aggiunti.

4.1.1 Controlli del modello di delega

Per il provisioning dell'accesso mediante il modello di delega, gli amministratori possono utilizzare i controlli seguenti:

  • Delega: il provisioning dell'accesso a utenti e gruppi viene eseguito dagli amministratori assegnando un ruolo, che dispone di autorizzazioni specifiche nel contesto di una vista ActiveView che determina l'ambito.

  • Viste ActiveView: una vista ActiveView rappresenta un ambito specifico di oggetti gestiti che sono definiti da una o più regole. Gli oggetti gestiti identificati da ciascuna regola in una vista ActiveView sono raggruppati in un ambito unificato.

  • Regola ActiveView: le regole sono definite mediante espressioni che corrispondono a un set di oggetti gestiti in base a varie condizioni, quali tipo di oggetto, ubicazione, nome e così via.

  • Ruoli: un ruolo è un set specifico di poteri (autorizzazioni) necessario per eseguire una funzione amministrativa specifica. In DRA sono disponibili alcuni ruoli integrati per le comuni funzioni aziendali ed è possibile definire ruoli personalizzati che soddisfino al meglio le esigenze dell'organizzazione.

  • Poteri: un potere definisce un'autorizzazione specifica per i task supportati dall'oggetto gestito, vale a dire visualizzazione, modifica, creazione, eliminazione e così via. Le autorizzazioni relative alla modifica di un oggetto gestito possono essere ulteriormente suddivise in base alle proprietà specifiche che possono essere modificate. In DRA è disponibile un'ampia gamma di poteri integrati per gli oggetti gestiti supportati ed è possibile definire poteri personalizzati per estendere il provisioning che è possibile fornire mediante il modello di delega.

4.1.2 Elaborazione delle richieste in DRA

Quando il server di amministrazione riceve una richiesta relativa a un'azione, come la modifica di una password utente, utilizza il processo seguente:

  1. Vengono cercate le viste Activeview configurate per gestire l'oggetto di destinazione dell'operazione.

  2. Viene eseguita la convalida dei poteri assegnati all'account che richiede l'azione.

    1. Vengono valutate tutte le assegnazioni alla vista ActiveView che contiene l'amministratore aggiunto che richiede l'operazione.

    2. Una volta stilato l'elenco, viene creato un altro elenco di tutte le viste ActiveView che contengono sia l'oggetto di destinazione sia l'amministratore aggiunto.

    3. Vengono poi confrontati i poteri con quelli necessari per eseguire l'operazione richiesta.

  3. Se l'account dispone del potere appropriato, il server di amministrazione consente l'esecuzione dell'azione.

    Se invece i poteri dell'account non sono appropriati, il server di amministrazione restituisce un errore.

  4. Active Directory viene aggiornato.

4.1.3 Esempi di elaborazione delle assegnazioni di delega in DRA

Gli esempi seguenti descrivono gli scenari più comuni che si verificano nella valutazione del modello di delega quando viene elaborata una richiesta:

Esempio 1: modifica della password di un utente

Quando un amministratore aggiunto tenta di impostare una nuova password per l'account utente MRossi, il server di amministrazione cerca tutte le viste ActiveView che includono MRossi. Più precisamente vengono cercate tutte le eventuali viste ActiveView in cui MRossi è specificato in modo diretto, tramite una regola con caratteri jolly o attraverso l'appartenenza a un gruppo. Se una vista ActiveView include altre viste ActiveView, il server di amministrazione esegue la ricerca anche in tali viste aggiuntive. Il server di amministrazione determina quindi se l'amministratore aggiunto dispone del potere Reset User Account Password (Reimposta password account utente) in una o più di tali viste ActiveView. Se l'amministratore aggiunto dispone del potere Reset User Account Password (Reimposta password account utente), il server di amministrazione reimposta la password di MRossi. Se invece non dispone di tale potere, il server di amministrazione rifiuta la richiesta.

Esempio 2: viste ActiveView sovrapposte

Un potere definisce le proprietà di un oggetto che un amministratore aggiunto può visualizzare, modificare o creare nel dominio o sottoalbero gestito. Lo stesso oggetto può far parte di più viste ActiveView. Questa configurazione è detta viste ActiveView sovrapposte.

Quando le viste ActiveView si sovrappongono, è possibile che sugli stessi oggetti si accumulino poteri diversi. Ad esempio, se una vista ActiveView consente di aggiungere un account utente a un dominio e un'altra vista ActiveView consente di eliminare un account utente dal medesimo dominio, sarà possibile aggiungere o eliminare gli account utente in tale dominio. Di conseguenza, i poteri di cui si dispone su un determinato oggetto sono cumulativi.

È importante comprendere in quale modo le viste ActiveView possono sovrapporsi e come sia possibile disporre di poteri maggiori su oggetti inclusi in nelle ActiveView. Si consideri la configurazione di ActiveView illustrata nella figura seguente.

Le schede bianche identificano le viste ActiveView per ubicazione, cioè New York City e Houston. Le schede nere identificano le viste ActiveView per funzione organizzativa, ovvero Vendite e Marketing. Le celle mostrano i gruppi inclusi in ciascuna vista ActiveView.

NYC_Gruppo vendite e HOU_Gruppo vendite sono entrambi rappresentati nella vista ActiveView Vendite. Se si dispone di un potere nella vista ActiveView Vendite, è possibile gestire qualsiasi membro di NYC_Gruppo vendite e HOU_Gruppo vendite. Se si dispone di poteri anche nella vista ActiveView New York City, tali poteri aggiuntivi si applicano a NYC_Gruppo Marketing. Di conseguenza, i poteri si accumulano dato che le viste ActiveView si sovrappongono.

Le viste ActiveView sovrapposte possono fornire un modello di delega potente e flessibile. Tuttavia, questa funzione può avere anche conseguenze impreviste. È consigliabile pianificare le viste ActiveView per essere certi che ogni AA disponga solo dei poteri che si intende concedere per ciascun account utente, gruppo, unità organizzativa, contatto o risorsa.

Gruppi in più viste ActiveView

In questo esempio, NYC_Gruppo vendite è rappresentato in più viste ActiveView. I membri di NYC_Gruppo vendite sono rappresentati nella vista ActiveView New York City perché il nome del gruppo soddisfa la regola ActiveView NYC_*. Il gruppo fa parte anche della vista ActiveView Vendite perché il nome soddisfa la regola ActiveView *_Vendite. Includendo lo stesso gruppo in più viste ActiveView, è possibile consentire a diversi amministratori aggiunti di gestire gli stessi oggetti in modo diverso.

Utilizzo dei poteri in più viste ActiveView

Si supponga che un amministratore aggiunto, MRossi, disponga del potere Modify General User Properties (Modifica proprietà utente generali) nella vista ActiveView New York City. Il primo potere consente a MRossi di modificare tutte le proprietà nella scheda Generale della finestra delle proprietà di un utente. Mrossi dispone del potere Modify User Profile Properties (Modifica proprietà del profilo utente) nella vista ActiveView Vendite. Il secondo potere consente a MRossi di modificare tutte le proprietà nella scheda Profilo della finestra delle proprietà di un utente.

Nella figura seguente sono illustrati i poteri di cui MRossi dispone per ciascun gruppo.

Mrossi dispone dei poteri seguenti:

  • Proprietà generali nella vista ActiveView NYC_*

  • Proprietà del profilo nella vista ActiveView *_Vendite

La delega dei poteri in queste viste ActiveView sovrapposte consente a MRossi di modificare le proprietà nelle schede Generale e Profilo di NYC_Gruppo vendite. Ciò significa che MRossi dispone di tutti i poteri concessi in tutte le viste ActiveView che rappresentano NYC_Gruppo vendite.