Role-Based Access Control (RBAC): Il nuovo modo per gestire Exchange (Parte 1 e 2)

L’RBAC (Role-Based Access Control) è una delle novità introdotte da Exchange 2010. Il suo scopo è quello di rendere più semplice e intuitiva la gestione degli accessi e dei permessi di Exchange. In questa serie di post descriverò il funzionamento e i componenti di RBAC per poi arrivare ad alcuni esempi pratici.

 

Parte 1: Un po’ di Storia

 

Fin dalla notte dei tempi gli amministratori Exchange hanno avuto il problema del controllo degli accessi. Dovevano permettere alle persone di fare il proprio lavoro senza dargli la possibilità di accedere a dati sensibili o fare cose che non erano di loro competenza. Da questo punto di vista le varie versioni di Exchange hanno introdotto sempre nuove funzionalità che poi sono culminate con RBAC. Prima di partire però vorrei ricordare come funzionavano le cose prima che il Role-Based Access Control vedesse la luce.

 

Exchange 2003

 

Exchange 2003 introduceva un sistema di ruoli abbastanza semplice. Si può scegliere tra 3 livelli di accesso differenti a cui sono associati una serie di permessi standard.

Exchange Full Administrator: Gli Exchange Full Administrators avevano accesso completo ai server Exchange e potevano impostare permessi all’interno della parte di organizzazione da loro controllata. C’è da notare che però non erano automaticamente membri degli amministratori locali dei server su cui avevano il controllo.

Exchange Administrator: Gli Exchange Administrator erano i fratelli minori dei Full Admin. Potevano fare tutto ma non potevano impostare permessi.

Exchange View-Only Administrator: I membri di questo gruppo potevano solo vedere le configurazioni ma non potevano fare altro.

 

Exchange 2007

 

Exchange 2007, pur rimanendo abbastanza semplice, dava la possibilità di scegliere tra 5 ruoli.

Exchange Organization Administrators: Questo gruppo aveva il controllo completo dell’organizzazione e degli oggetti al suo interno. Tutti i comandi che agivano a livello di organizzazione (ad es.: Aggiungere una Transport Rule o ggiungere un Send Connector) potevano essere eseguiti solo se si era membri di questo gruppo.

Exchange Server Administrators: I Server Administrators avevano controllo completo su un server e potevano amministrare liberamente quel server specifico ma non potevano effettuare operazioni che influivano sull’intera organizzazione come nel ruolo precedente.

Exchange View-Only Administrators: Come per Exchange 2003 questo gruppo aveva accesso read-only all’Organizzazione Exchange.

Exchange Recipient Administrators: Questo gruppo aveva il permesso di modificare solo gli attributi relativi ad Exchange di utenti, contatti, gruppi, distribution list dinamiche e cartelle pubbliche dell’Organizzazione.

Exchange Public Folder Administrators: Questo gruppo è stato introdotto con l’SP1 di Exchange 2007 e aveva il controllo completo sulle cartelle pubbliche (incluso l’abilitarli alla posta) ma non potevano modificare le proprietà delle cartelle relative alla posta (ad es. l’indirizzo mail)

 

Parte 2: I Componenti

Il Modello di RBAC risponde essenzialmente a 3 domande: Chi ?, Dove ? e Cosa ?

Chi può fare determinate Operazioni (la domanda Cosa ?) e Dove le può fare.

Per arrivare a questo scopo ci sono 5 componenti principali: I Management Role, I Management Role Assignment, I Role Group, Le Role Assignment Policy e i Management Scope.

I Management Role

Il Management Role definisce la lista dei comandi disponibili a un particolare utente a cui è assegnato quel ruolo. La configurazione di un Management Role include la lista dei Cmdlet e dei parametri disponibili a questo ruolo (chiamate Management Role Entries).

Ci sono 3 categorie di Management Role:

· I Ruoli Built-In: Questi ruoli sono creati automaticamente durante l’installazione di Exchange e coprono gli scenari più comuni di controllo degli accessi (ad es. la gestione dei DAG, delle Cartelle Pubbliche, etc…)

· I Ruoli Custom: Questi ruoli sono una copia dei ruoli Built-In che può essere personalizzata per rispondere alle necessità specifiche di un’organizzazione

· I Ruoli Unscoped Top-Level: Questi ruoli sono un gruppo speciale utilizzato per garantire l’accesso ai Cmdlet non-Exchange a particolari utenti o script

I Management Role Assignment

Un Management Role Assignment consiste nell’associazione di un Management Role a un utente, a un gruppo Universale direttamente o tramite una Role Assignment Policy. L’assegnazione di un ruolo permette all’assegnatario di usare i Cmdlet e i parametri inclusi nelle Management Role Entries di un Management Role.

I Role Group

Un Role Group è un Gruppo Universale usato da RBAC che serve a semplificare l’assegnazione di un ruolo a un gruppo di utenti. Tutti i membri di un Role Group avranno gli stessi ruoli.

Le Role Assignment Policy

Le Role Assignment Policy permettono di assegnare dei ruoli agli utenti in maniera strutturata. Un Role Assignment è associato a una policy a cui, a sua volta, è associato un utente. Questa associazione si può fare al momento della creazione dell’utente o successivamente.

I Management Scope

Il Management Scope definisce l’insieme di oggetti che un ruolo può gestire. Gli scope possono essere gruppi di server, di recipient o insiemi di oggetti definiti da un filtro creato dall’amministratore.

Riassumendo:

Nella prossima parte parlerò meglio dei Management Role.