Confronto tra gruppi definiti dal sistema operativo e autorizzazione ACL

Invece di assegnare utenti a più gruppi definiti dal sistema operativo, gli ACL consentono di assegnare elementi a più gruppi, cosa che semplifica l'amministrazione delle autorizzazioni.

gruppi definiti dal sistema operativo

Nella versione 8.0 e in precedenti release di ClearCase, ogni elemento VOB possiede tre categorie di protezione: owner, group e other. Per ogni categoria, l'amministratore può impostare o cancellare i bit di lettura e esecuzione. Ad esempio, se si possiede un file origine che deve essere leggibile per il proprietario e i membri del gruppo di elementi, ma non per tutti gli utenti della rete, si deve impostare owner=read, group=read, other=none. Se si dispone di un file eseguibile per alcuni strumenti di programmazione, è possibile impostare tutti e tre su lettura e esecuzione.

In pratica, questo modello richiede l'utilizzo di un gruppo separato per ogni classe di elementi che condivide la stessa protezione. Se non si autorizzano tutti gli utenti a leggere gli elementi in VOB, si imposta other=none e si deve controllare l'accesso mediante le categorie owner e group.

Per il proprietario dell'elemento la protezione degli elementi ha un'utilità limitata, lasciando solo il gruppo come controllo effettivo. Il proprietario di un elemento è per impostazione predefinita impostato sull'account utente che ha creato l'elemento. Se vi sono più sviluppatori, i proprietari degli elementi varieranno, cosa non vantaggiosa per il controllo accessi. Alcuni amministratori configurano un trigger per modificare la proprietà nell'account del proprietario VOB dopo la creazione degli elementi, ma anche questo è un inconveniente per il controllo accessi dal momento che la maggior parte degli utenti raramente assume l'identità del proprietario VOB.

In tal modo il gruppo dell'elemento viene lasciato come meccanismo di controllo dell'accesso a ogni elemento. L'amministratore deve definire un gruppo separato per ogni classe di elemento che ha bisogno di protezione. Ad esempio, la classe di elementi 1 è per gli sviluppatori del componente A. La classe di elementi 2 è per gli sviluppatori del componente B. La classe di elementi 3 è per tutti gli sviluppatori (codice condiviso). Se si hanno 25 componenti (A-Y) e un componente condiviso (Z), sono necessari 26 gruppi per il controllo accessi. Verranno protetti tutti gli elementi del componente A impostando le loro autorizzazioni in modo tale che possano essere leggibili per i membri del gruppo A, ma non letti da chiunque. Allo stesso modo per i componenti B-Y. Ogni sviluppatore del componente A-Y sarà membro di quel gruppo, oltre che anche membro del gruppo Z. L'account utilizzato per creare e integrare tutto il codice deve essere membro di tutti i gruppi A-Z.

I gruppi utilizzati da ClearCase vengono definiti dal sistema operativo (dominio Windows, NIS UNIX o LDAP) e aggiunti alle credenziali di un utente quando accede a un host su cui è in esecuzione ClearCase. Purtroppo, a causa delle limitazioni nei protocolli di rete utilizzati nel sistema operativo e in ClearCase, un singolo utente può solo utilizzare 16 gruppi (UNIX e Linux) o 32 gruppi (Windows) per volta con ClearCase. Nell'esempio riportato in precedenza, l'account di build/integrazione deve utilizzare 26 gruppi per completare il build; ciò richiede una sequenza complessa di fasi di build e di modifiche di credenziali che definiscono i gruppi attivati per ClearCase o l'utilizzo di meno gruppi che potrebbero compromettere l'implementazione della sicurezza degli elementi. Nessuna di queste opzioni è auspicabile.

ACL su elementi

Se si abilitano gli ACL per la protezione di elementi in un VOB con livello funzione 8 in ClearCase 8.0.1, è possibile modificare la strategia di controllo accessi per eliminare molti casi in cui si toccano i limiti di appartenenza gruppo per utente. Può essere utile pensare agli ACL come a qualcosa che consente di inserire gli elementi in più gruppi invece di dover inserire gli utenti in più gruppi. Poiché il numero di gruppi consentiti in un ACL effettivo di elementi non è vincolato agli stessi limiti bassi del numero di gruppi per un account utente, questo meccanismo di sicurezza consente alcuni nuovi casi di utilizzo di protezione e semplifica altri.

Con gli ACL sugli elementi, è possibile concedere l'accesso a più singoli utenti, più gruppi e a meno categorie di "tutti". In questa sezione sono illustrati gli ACL sugli elementi in termini di relativi ACL effettivi. In questa sezione e negli argomenti correlati vi sono esempi sul modo in cui le mappe ruoli e le politiche si combinano per creare ACL effettivi.

Nell'esempio riportato in precedenza, in cui c'erano 25 componenti A-Y, ognuno a cui deve accedere un team differente e un account di build ("builders"), ma a cui nessun altro può avere accesso. Con gli ACL, si proteggerà ogni elemento in un dato componente con un ACL effettivo condiviso che concede autorizzazioni di modifica al groupA e ai builder.

Ogni componente B-Y avrà un ACL effettivo simile. Anche il componente Z (quello condiviso) possiede un ACL effettivo simile. In questa configurazione, ogni account del membro del team si trova nel gruppo corrispondente per il relativo componente, più il gruppo per Z (come in precedenza). Tuttavia l'account builder deve essere solo nel gruppo "builders". Non ci sono limiti all'appartenenza simultanea a gruppi per l'account builder.

Inoltre, non si devono utilizzare strategie complesse durante un build di sistema e nemmeno compromettere la sicurezza per i componenti A-Y. Si può anche ottenere la flessibilità di aggiungere ulteriori gruppi e accesso di sola lettura agli elementi. Si presupponga che il componente Z sia gestito dal proprio team, ma vi devono fare riferimento solo i team A-Y e gli sviluppatori non appartenenti a Z sono stati inseriti nel gruppo "alldevelopers" invece che nel gruppo "groupZ". È possibile configurare l'ACL dell'elemento del componente Z in modo tale che il gruppo groupZ abbia autorizzazioni di modifica, alldevelopers abbia le autorizzazioni in lettura e builders abbia le autorizzazioni di modifica.

Uno sviluppatore nel team A sarà in grado di leggere gli elementi nel componente Z ma non di modificarli. Senza gli ACL tale operazione avrebbe richiesto un checkout precedente all'operazione e un trigger mkbranch per verificare l'autorizzazione a modificare l'elemento e a rifiutare un'operazione se non autorizzata.

È possibile anche inserire account singoli negli ACL dell'elemento. Ciò può avere senso se vi sono pochi singoli che hanno bisogno di un accesso specifico a un componente, in un caso in cui non è utile creare un nuovo gruppo del sistema operativo solo per questo scopo. Pertanto, se il componente B deve essere modificabile da parte del proprio team, più un altro utente ("extrauser"), l'ACL concederà autorizzazioni di modifica a groupB, extrauser e builders.

Se vi sono alcuni componenti che sono gestiti da più team, è possibile persino poter eliminare alcuni gruppi utilizzati in precedenza. Si presupponga che il componente E era gestito da tutti i membri del gruppo per i componenti C e D. Nell'esempio 8.0, è necessario che il gruppo E contenga tutti i membri di entrambi i gruppi C e D. Con gli ACL, è possibile impostare l'ACL per il componente E per ridenominare entrambi i gruppi, quindi abbandonare l'utilizzo del gruppo E (rimuoverlo dall'elenco del gruppo per gli account sui team C e D).

Una politica e mappe ruoli associate

La precedente descrizione illustra gli ACL effettivi. In un VOB, l'ACL effettivo viene generato applicando una mappa ruoli a una politica. Il database calcola e memorizza l'ACL effettivo per ogni mappa ruoli. Ogni elemento viene associato a una mappa ruoli. Per implementare gli esempi illustrati in precedenza, è necessaria una mappa ruoli distinta per ogni classe di elementi (componenti A - Z). È possibile collegare tutte queste mappe ruoli a una singola politica che descrive il proprio modello di protezione generale. Di seguito viene riportata una politica di esempio e una serie di mappe ruoli che forniscono gli ACL effettivi mostrati sopra. In pratica è possibile aggiungere un utente o un gruppo amministrativo perché abbia controllo completo su tutti gli elementi.


Feedback