Cloud, i modelli di controllo degli accessi: quali sono e come funzionano

L’integrazione tra sistemi on-premise e sistemi cloud mette fortemente in discussione l’efficacia dei tradizionali processi di sicurezza in ambito enterprise. La distribuzione delle applicazioni e dei dati su diversi cloud provider (multi-cloud), situati in varie aree geografiche, che devono soddisfare diversi vincoli normativi e che adottano diversi modelli di autorizzazione e controllo degli accessi (o differenti implementazioni dello stesso modello), evidenzia come ci sia una forte necessità di fornire alle aziende degli strumenti di sicurezza adeguati al contesto.

Diventa pertanto fondamentale, ad esempio, analizzare accuratamente i modelli di controllo degli accessi attualmente disponibili e proporre nuovi approcci che soddisfino le necessità aziendali.

Cloud Computing, le sfide per le aziende

Alcune delle caratteristiche che hanno permesso un rapido e veloce sviluppo delle soluzioni cloud sono, come ormai ben noto, la possibilità di effettuare il provisioning delle risorse su richiesta del cliente in maniera rapida e commisurata alle specifiche esigenze di business (On-demand self-service); di accedere ai servizi in qualsiasi momento, tramite qualsiasi dispositivo (Broad network access); di monitorare le attività al fine di garantire l’ottimizzazione delle risorse (Measured service). Secondo uno studio dell’Osservatorio Cloud Transformation condotto dal Politecnico di Milano, il mercato del cloud nel 2020 in Italia vale circa 3,34 miliardi di euro, con una crescita del 21% rispetto al 2019 mentre, l’adozione di soluzioni cloud da parte delle PMI italiane, ha registrato un incremento del 42%.

Sicurezza IT, aziende ancora impreparate: una strategia per organizzare il futuro

Numeri alla mano, l’attenzione verso il mercato del cloud è evidentemente altissima ma sebbene la graduale dismissione dalle soluzioni on-premise abbia portato con sé numerosi vantaggi, è altresì vero che le aziende devono ora confrontarsi con nuove problematiche come ad esempio:

• Continuare a garantire la compliance alle normative vigenti: le aziende devono rispettare normative legali, non sempre chiare ed esplicite, specifiche per la propria Industry ed in particolare legate alla tipologia dei dati trattati. Tali norme non sono spesso di facile attuazione e sono talvolta in diretto contrasto con le caratteristiche tipiche degli ambienti cloud;
• Garantire l’interoperabilità tra sistemi: non esistono ancora standard definiti che possano aiutare le aziende ad integrare e gestire risorse che risiedono su public cloud, private cloud ed altre tipologie di sistemi; di garantirne la comunicazione tramite API condivise; di adottare politiche di controllo degli accessi e di autenticazione condivise.
• Evitare il vendor Lock-in: le aziende si trovano sempre più spesso ad essere strettamente vincolate ai servizi di un unico cloud service provider (CSP), in quanto, l’assenza di standard ed il conseguente problema dell’interoperabilità, rende difficile sia a livello tecnico, sia a livello economico, la possibilità di migrare i propri sistemi su un cloud service provider diverso.
• Gestire le prestazioni: fattori come la velocità di connessione, la virtualizzazione delle risorse su network separati, la gestione di grossi volumi di dati, possono inevitabilmente causare ritardi nell’evasione delle richieste da parte del CSP.

La nuova frontiera del multi–cloud

Un ambiente multi-cloud è costituito da più servizi cloud — pubblici o privati — offerti da diversi fornitori tra loro indipendenti, cioè che non sono legati da nessuna forma di accordo legale o di federazione. La presenza di deployment multi-cloud è molto frequente, nelle aziende il cui obiettivo è quello di:

• Ottimizzare i costi: la possibilità di scegliere tra più fornitori che offrono servizi diversi con costi diversi, aumenta la competitività tra i CSP, aiuta a superare il problema del vendor lock-in ed a portare un vantaggio economico importante alle aziende.
• Aumentare la resilienza: avere a disposizione risorse fisiche di più fornitori, dislocati in luoghi diversi, garantisce alle aziende una maggiore tolleranza a possibili guasti o eventi catastrofici (fault tolerance).
• Rispettare vincoli legali: l’azienda può scegliere il CSP che meglio si adatta alle proprie esigenze di governance ed affidarsi ad uno di essi solo per specifici servizi. Un esempio potrebbe essere affidare i propri dati sensibili ad un fornitore localizzato nei confini europei o nei confini della propria nazione al fine di ottemperare alle richieste delle normative vigenti.

Se da un lato è vero che sempre più aziende adottano soluzioni multi-cloud per lo sviluppo del proprio business, la maggioranza di esse evidenzia ancora una certa difficoltà a governare efficacemente ambienti complessi composti da cloud privati on-premise, cloud privati gestiti (managed private cloud) e più cloud pubblici. Secondo una indagine mondiale condotta da IDC che ha coinvolto più di 2000 imprese utenti di servizi cloud, il 36% del campione ritiene che non riuscirà a raggiungere un livello di interoperabilità soddisfacente tra i vari cloud in uso.

Oltre al problema dell’interoperabilità tra sistemi, il multi-cloud ha maggiormente evidenziato la crescente necessità delle aziende di coordinare i livelli di autenticazione tra sistemi e di armonizzare i modelli di access control adottabili.

Access Control Model: principi generali

Le aziende che decidono di affidare i propri dati e le proprie applicazioni a servizi cloud pubblici devono necessariamente prestare molta attenzione al monitoraggio ed al controllo dei permessi al fine di prevenire accessi a dati o risorse da parte di soggetti non autorizzati.

Con il termine access control intendiamo tutti quei meccanismi messi in atto al fine di controllare le operazioni che un utente può effettuare o meno su un determinato sistema e di proteggere l’accesso ai dati da utenti non autorizzati. Un efficiente sistema di Access Control consente di preservare le caratteristiche fondanti la sicurezza dei dati gestiti da un sistema: confidenzialità, integirtà e disponibilità.

Generalmente un modello di controllo degli accessi è definito considerando le seguenti entità:

• Utenti: soggetti che si interfacciano con il sistema informativo.
• Oggetti: risorse gestite dal sistema (entità passive).
• Operazioni: singole azioni effettuate dagli utenti sulle risorse.
• Permessi: autorizzazione ad effettuare specifiche azioni sugli oggetti.

Ad esempio: un dipendente dell’azienda (Utente) necessita di accedere (Permesso) al Data Base (Oggetto) per inserire (Operazione) i dati sulle fatture.

Inoltre, si definisce:

• Policy: una regola che stabilisce quali utenti possono accedere a quali oggetti.
• Modello: uno schema per specificare ed imporre una policy.

Le policy vengono definite per cogliere i requisiti di sicurezza del sistema, e spesso seguono best practice note quali la sepration of duties o il principio del privilegio minimo. Una volta definite, le policy vengono codificate attraverso il Modello che ne rende i contenuti accessibili ed utilizzabili dal sistema.

I tradizionali Access Control Model sono generalmente classificati in tre categorie:

• DAC (Discretionary Access Control) model: ad ogni risorsa (Object) viene assegnato un proprietario (Owner) a cui viene affidato il compito di gestire gli accessi. Un utente può accedere alla risorsa solo se è stato precedentemente autorizzato (dall’owner) o se fa parte di un gruppo autorizzato. Il termine “discretionary” (discrezionale) implica che gli utenti, se autorizzati, possono a loro discrezione, modificare le policy su una determinata risorsa (es. il proprietario U1 di un file può dare, a sua discrezione, il diritto all’utente U2 di accedere a tale file).
• MAC (Mandatory Access Control) model: una autorità centrale, di solito l’amministratore di sistema, ha il compito di definire le policy da assegnare ad ogni utente. Il mandatory access control segue un approccio gerarchico in cui a ogni oggetto viene assegnato un livello di sicurezza basato sulla sensibilità dei dati. I livelli di sicurezza tipici sono “confidenziale” o “strettamente confidenziale”. La stessa classificazione è applicata sia agli utenti che ai dispositivi. Ogniqualvolta un utente tenta di accedere a una qualsiasi risorsa si avvia in automatico una verifica atta a convalidare o a negare l’accesso.
• RBAC (Role Based Access Control) model: sposta l’attenzione sul ruolo assunto dall’utente più che dalla sua identità, secondo il principio che “a subject’s responsibility is more important than whom the subject is”. Ogni utente può essere associato a più ruoli, ognuno dei quali sarà dotato dei permessi necessari a svolgere le operazioni richieste.
• ABAC (Attribute Based Access Control) model: l’autorizzazione ad accedere ad una determinata risorsa si basa sull’analisi di un serie di attributi relativi al sistema a cui si tenta di accedere, all’utente che richiede l’accesso ed al contesto in cui la richiesta di accesso viene valutata. Un attributo può essere la data di accesso, la localizzazione, il ruolo dell’utente ecc. o una combinazione di essi. Ad esempio, si può consentire l’accesso al Database solo per operazioni di lettura (attributo1), solo da un dispositivo localizzato in Italia (attributo2) in orario lavorativo 9-18 (attributo3).

Access Control in Cloud Computing: vantaggi e svantaggi

I tradizionali modelli di controllo degli accessi, visti nel precedente paragrafo, risultano essere poco flessibili e poco scalabili e non riescono a far fronte a tutti i possibili scenari di sicurezza tipici delle soluzioni cloud, risultando maggiormente inappropriati se applicati in contesti multi-cloud. Di seguito analizzeremo vantaggi e svantaggi dell’utilizzo dei tradizionali Access Control Model in ambienti cloud.

Discretionary Access Control (DAC)

La discrezionalità affidata all’owner di un object, di concedere o rimuovere permessi ad altri utenti, rende il DAC un modello flessibile ed efficiente se utilizzato in ambienti in cui tutti i dati trattati possano essere condivisi. È un modello che può essere adottato in ambienti che non richiedono alti livelli di protezione. Il DAC, presenta diversi problemi se utilizzato in contesti cloud:

• non prevede meccanismi o metodi per prevenire eventuali errori di gestione dei permessi e non può impedire episodi di negligenza da parte dell’owner della risorsa. In ambienti cloud dove una stessa risorsa è condivisa tra diversi utenti con diversi profili autorizzativi diventa estremamente oneroso per l’owner garantire una corretta gestione dei privilegi;
• non consente di prevenire o individuare operazioni di ereditarietà di privilegi dovuti ad esempio ad attacchi malware, o ad azioni illecite esercitate dagli utenti, andando incontro alla violazione dei principi di integrità e confidenzialità del dato;
• non è abbastanza scalabile per poter gestire efficacemente ambienti multi-utente con una varietà piuttosto ampia di dispositivi interconnessi.

Mandatory Access Control (MAC)

Un modello di tipo non discrezionale, in quanto la gestione dei permessi è affidata interamente ad una unità centrale (solitamente l’amministratore di sistema) ed impedisce agli altri utenti di modificare o sovrascrivere le policy stabilite per un determinato object. A differenza del DAC, pertanto il MAC, garantisce il controllo totale del flusso di informazioni in quanto le policy non possono essere ereditate da altri utenti senza l’autorizzazione dell’autorità centrale. La semplicità di questo modello risulta però essere il suo punto di debolezza, in quanto immaginare di lasciar gestire l’intera organizzazione degli accessi ad una sola autorità, in un ambiente come il cloud, costituisce un onore estremamente gravoso e di difficile implementazione. E’ un modello inoltre poco flessibile (se due utenti hanno necessità ad esempio, anche solo di scambiarsi un file, devono contattare l’amministratore di sistema), non supporta vincoli legati al tempo di accesso o alla localizzazione dell’utente e non supporta alcuna attivazione dinamica dei permessi in base ad esempio al tipo di operazione che deve essere eseguita.

Role Based Access Control (RBAC)

Il modello che più di tutti si adatta alle esigenze di molte organizzazioni, è molto flessibile e permette l’accesso alle risorse in base al ruolo a cui l’utente è associato o in base al gruppo a cui appartiene. Sebbene sia stato sviluppato per superare i problemi dei modelli MAC e DAC, classificare gli utenti in maniera corretta o creare gruppi di lavoro con permessi omogenei in ambienti complessi, come può esserlo il cloud o il multi-cloud, diventa di difficile attuazione:

• Non è possibile differenziare per un utente l’accesso a determinati tipi di dati (ad esempio quelli sensibili). I permessi sono regolati solo dal ruolo di appartenenza non consentendo la possibilità di associare al ruolo anche altre tipologie di attributi (time, location, risk,…) utili a restringere ancora di più le policy di accesso.
• Non è possibile trasferire i propri privilegi ad un altro utente (come avviene nel DAC), caratteristica utile ad esempio per sopperire all’assenza del personale durante la gestione di casi di emergenza.
• Non è un modello sufficientemente scalabile. In ambienti distribuiti quando il numero di utenti e di permessi da gestire cresce considerevolmente, il numero di ruoli creati potrebbe superare il numero di utenti. Questa limitazione è chiamata “role explosion problem”.
• Per verificare che non ci siano conflitti tra ruoli e permessi, la fase di test diventa cruciale ma soprattutto complessa da eseguire.

Attribute Based Access Control (ABAC)

Anche questo modello, come RBAC, nasce con l’auspicio di superare i limiti dei precedenti modelli. Propone un approccio in cui l’accesso ad un oggetto è consentito solo dopo la valutazione di una serie di attributi aumentando così il livello di dettaglio dei controlli. Fondamentale in questo modello definire accuratamente le policy di sicurezza che dovranno stabilire con precisione quali attributi (o quale combinazione di essi) devono essere verificati. A questo punto, si può facilmente intuire come, capire quali tipi di attributi dovranno essere utilizzati, quanti attributi bisogna tenere in considerazione ed impostare di conseguenza correttamente le policy diventa, così come già discusso per RBAC, una operazione molto complessa, onerosa da implementare e difficile da sostenere.

I consigli per le aziende

In letteratura, per superare i limiti dei tradizionali Access Control Model, sono stati proposti diversi modelli basati sugli attributi, sui rischi, sul tempo di lavoro, sui processi ma la ricerca in questo campo è ancora aperta. Attualmente i principali Service Providers (Amazon AWS, Google Cloud Platform, Microsoft Azure, …) utilizzano un modello impostato prevalentemente su RBAC, ma lo estendono con elementi mutuati da altri modelli (es. ABAC), consentendo in tal modo di ottenere una maggiore flessibilità ed un controllo fine-grained dei privilegi (es. combinando il concetto dei ruoli con altri elementi quali il tempo, la localizzazione, il tipo di risorsa, l’ambito progettuale, ecc.).Il modello risultante non è dunque un modello di access control specifico ma una combinazione dei diversi modelli esistenti in letteratura.

Riuscire a garantire la protezione dei dati, la difesa da potenziali minacce, il rispetto delle normative vigenti, diventa per le aziende una sfida importante che prevede necessariamente una stretta collaborazione con i diversi CSPs. In questo scenario è fondamentale che le aziende acquisiscano una profonda e dettagliata conoscenza dei loro ambienti di lavoro al fine di evitare quello che oggi viene chiamato il fenomeno del cloud sprawl (la dispersione nel cloud). Il cloud sprawl avviene quando una azienda perde il controllo dei suoi ambienti cloud, non riesce più a gestirli ed a monitorarli efficacemente con un conseguente aumento delle spese sostenute, una flessione della produttività ed un aumento del rischio per la sicurezza. Pertanto, prima ancora di implementare una nuova strategia multi-cloud è importante che ogni azienda:

• sviluppi internamente le competenze richieste per la gestione delle nuove soluzioni o reperisca sul mercato figure con competenze specifiche;
• dimensioni in maniera opportuna il gruppo di lavoro: ogni CSP sviluppa i propri servizi utilizzando proprie APIs, tools e processi specifici. L’assenza di standard definiti comporta un maggiore carico di lavoro per le aziende ed in particolare per la struttura IT che deve essere per questo motivo, composta da un numero adeguato di risorse.
• implementi una efficiente security governance con tutti i fornitori coinvolti accordandosi sulle strategie di sicurezza da adottare, definire chiaramente i processi e garantirne un continuo monitoraggio.

Le aziende, hanno bisogno di un punto di controllo unico, e non di soluzioni frastagliate, che consentano loro di poter controllare interamente tutta la supply chain coinvolta, e di standard definiti per migliorare e garantire l’interoperabilità tra gli ambienti al fine di evitare sovraccarichi di lavoro alla struttura, di evitare errori di configurazioni, di prevenire minacce che possano compromettere il rispetto della compliance normativa e della security aziendale.