Read Access Control: idea base

Read Access Control è la struttura dati crittografica usata da Izzie per la gestione degli accessi (da clienti e gruppi) per le operazioni di lettura (verso collezioni e risorse). L’analisi di tale struttura viene affrontata in modo diverso da quello delle sezioni precedenti. Risulta infatti molto più naturale e comprensibile presentare un esempio reale, per poi analizzarne in dettaglio ogni suo aspetto in modo da riuscire anche a non perdere l’impronta astratta usata in questa dissertazione. Per tale motivo si supponga che la struttura crittografica Read Access Control sia stata utilizzata per l’implementazione del file system di una grande azienda. Il file system sarà caratterizzato da una grande mole di dati (file) suddivisi tra i vari dipartimenti e tra i vari gradi di privilegi dei dipendenti e manager dell’azienda. Uno snapshot di tale struttura viene proposto nella figura 4.17.

Figura 4.17: Read Access Control

Intuitivamente l’immagine è già sufficiente per permettere di capire quali sono le entità in gioco ed i loro ruoli. Brevemente, il CEO ha privilegi di lettura su tutti i dipartimenti della sua azienda, il CTO invece è in grado di operare

solo sul dipartimento informatico IT. A loro volta gli sviluppatori web hanno privilegi di lettura sull’area Web del dipartimento IT, mentre lo sviluppatore di terze parti (esterno all’azienda) si occupa solo di un sottoinsieme di contenuti web (in figura ha l’accesso al semplice file home.html). Resta da capire come tutto ciò sia effettivamente realizzabile e quali sono i principi (link) crittografici necessari affinché non ci siano situazioni critiche dal punto di vista delle sicurezza e situazioni altrettanto critiche sia dal punto di vista funzionale che della scalabilità.

Cienti e Gruppi

Clienti e Gruppi (utenti secondo l’esempio in figura 4.17) hanno le stesse proprie- tà astratte (e semantico crittografiche) già analizzate nella sezione 4.3.2. Ogni cliente ed ogni gruppo è quindi dotato di una coppia di chiavi crittografiche asimmetriche necessarie all’accesso verso risorse e collezioni a lui abilitate. Rias- sumendo, la parte pubblica di tale coppia viene utilizzata per la creazione (fisica) del link crittografico asimmetrico. La parte privata invece è ovviamente usata per percorrere il link asimmetrico (decifrandone di fatto il contenuto).

In aggiunta, ogni cliente può appartenere ad uno o più gruppi. Questo è reso possibile sfruttando un link asimmetrico tra la coppia di chiavi asimmetriche del cliente e quella del gruppo. Più nello specifico, occorre cifrare la chiave privata della coppia di chiavi del gruppo con la chiave pubblica del cliente. Nell’esempio in figura 4.17, questo caso viene espresso dall’utente WebDeveloper1 (WD1) che fa parte del gruppo di utenti WebDevelopers (attraverso il link asimmetrico dalla coppia di chiavi dell’utente WD1_KEYPAIR alla coppia di chiavi del gruppo WDG_KEYPAIR). Ovviamente un tale link asimmetrico è presente anche per gli sviluppatori WebDeveloper2 e WebDeveloper3, tuttavia ciò non è stato riportato in figura per ovvie ragioni grafiche.

Risorse e Collezioni

Con la strategia appena descritta, intere parti della struttura dati crittografica (collezioni e risorse) possono essere rivelate direttamente ad insiemi di utenti (per mezzo dei gruppi) o ad utenti singoli utilizzando un’unica operazione asimmetrica. Resta da capire come ciò sia possibile, ovvero quali sono le chiavi che entrano in gioco per le entità risorse e collezioni. La figura 4.17 introduce diverse nuove

chiavi crittografiche simmetriche e link simmetrici particolari che necessitano di particolare attenzione.

Partendo dalle collezioni (che nell’esempio in figura 4.17 corrispondono a directory del file system) sono previste 3 nuove chiavi crittografiche simmetriche: (SK) SubCollection Key consente di ottenere tutte le collezioni e le risorse contenute nella collezione a cui la chiave SK fa riferimento. Un cliente o gruppo che ha accesso alla SK di una collezione avrà quindi l’accesso anche a tutte le collezioni e risorse in essa contenute (e così via fino alla raggiunta delle foglie dell’albero crittografico). Nella figura 4.17 il CEO dell’azienda ha l’accesso ad ogni directory e file contenuti nella directory departments. Il punto di partenza del CTO è invece la directory IT.

(CK) Collection Key è la chiave con cui vengono cifrate le informazioni di una collezione. Nell’esempio in figura 4.17 le informazioni di una generica directory possono essere: il nome, le date di creazione e modifica ed altre in- formazioni tipiche di una directory. Secondo la struttura dati crittografica, chiunque abbia accesso alla chiave SK di una collezione ha anche l’accesso alla chiave CK.

(BK) BackLink Key è una chiave particolare (ed opzionale) che consente di percorrere a ritroso la catena crittografica solo per i dati informativi di una collezione. Qualora presente infatti, la chiave BK viene usata per cifrare la chiave CK necessaria alla decodifica delle informazioni della collezione. Ispirandosi all’esempio in figura 4.17, questa struttura consente di fatto all’utente CTO di sapere che la directory IT si trova al di sotto della direc- tory departments. Il gruppo di sviluppatori web è invece ignaro dell’effettiva posizione della directory Web all’interno della struttura dati crittografica. Le risorse invece non hanno particolari differenze da quanto già detto nella se- zione 4.3.2. L’unica aggiunta riguarda la chiave simmetrica necessaria per andare a ritroso nella catena crittografica delle informazioni delle collezioni (BK).

Il lettore è ora in grado di comprendere appieno la semantica della struttura dati crittografica usata nella figura 4.17, il tutto si basa in definitiva su due tipologie di link crittografici:

Resource/Collection Symmetric Links link crittografici simmetrici necessa- ri a percorrere la catena crittografica simmetrica per arrivare alle informa- zioni di collezioni e ai dati effettivi delle risorse (directory e file nell’esempio) User/Group Asymmetric Links link crittografici asimmetrici necessari a for- nire a clienti e gruppi un punto di accesso alla catena crittografica simme- trica in base al loro livello di privilegio. Clienti e gruppi più privilegiati avranno un punto di accesso vicino alla radice dell’albero crittografico (CEO e CTO nell’esempio in figura 4.17), mentre clienti e gruppi meno privile- giati avranno un punto di accesso vicino alle foglie dell’albero crittografico (sviluppatore di terze parti nell’esempio in figura 4.17).

Problemi

É evidente che la struttura dati crittografica per i permessi di lettura (Read Access Control) appena presentata è stata costruita in modo da privilegiare le operazioni simmetriche piuttosto che quelle asimmetriche. In generale infatti un cliente o un gruppo non avrà un alto numero di punti di accesso asimmetrici alla struttura dati crittografica (spesso ne avrà solo uno). Le operazioni di lettura sono quindi molto veloci e i tempi di accesso diventano trascurabili anche per un’elevata mole di collezioni e risorse.

Tuttavia esistono delle particolari operazioni che possono mettere in difficol- tà la struttura dati crittografica appena proposta con un inevitabile impatto sui tempi di gestione. Cosa succede infatti quando si intende revocare il permesso di accesso ad un cliente o a un gruppo ? Ovviamente come primo punto, il link crittografico asimmetrico (punto di accesso) deve essere rimosso o invalidato. Ma questo non basta, ai fini di mantenere la sicurezza e la privacy dei dati protetti dalla struttura dati crittografica, ogni link crittografico simmetrico in cui il grup- po o il cliente in questione era coinvolto deve essere necessariamente aggiornato, con una conseguente creazione di nuove chiavi e nuovi link simmetrici. Quest’o- perazione non è così semplice come si potrebbe pensare. Le nuove chiavi infatti devono essere nuovamente rivelate (mediante link asimmetrici) alle entità (clienti e gruppi) che ancora hanno i privilegi di lettura (sfruttando la parte pubblica

della coppia di chiave asimmetriche). Quest’operazione potrebbe essere compu- tazionalmente molto onerosa, specie se l’entità a cui è stato revocato l’accesso è dotata di alti privilegi nella struttura dati crittografica e quindi ha un punto di accesso ad essa molto vicino alla radice. Ovviamente questi tipi di proble- mi sono molto rari se la struttura dati crittografica è implementata ed usata a dovere; è raro infatti che ad un’entità con un alto grado di privilegi venga di colpo revocato l’accesso ad una collezione importante e molto ricca. Tuttavia il problema non deve essere trascurato ed è bene studiare soluzioni che siano in grado di mantenere i requisiti di funzionalità e scalabilità richiesti e incoraggiati dalla filosofia del Cloud computing. Per tale motivo nelle sezioni 4.4.4 e 4.4.8 si introdurranno strumenti avanzati e possibili ottimizzazione alla struttura di Read Access Control.