SaaS: guida all’implementazione

La sezione 3.1 pone un punto di partenza per lo sviluppo di servizi eterogenei di Cloud Computing, tuttavia non da indicazioni dettagliate agli sviluppatori o ai progettisti sulle tecnologie o standard da utilizzare. Questi ultimi infatti com- prendono che è necessario soddisfare i vincoli imposti dalla definizione perché è il giusto modo di procedere affinché l’efficienza e i vantaggi della filosofia di Cloud Computing vengano rispettati. Tuttavia la progettazione dei servizi e la scelta degli standard da adottare è lasciata a loro stessi. É proprio qui che parte la fase di ricerca da parte dei responsabili (tecnici e non) del servizio SaaS, per cercare di adottare tecnologie e filosofie che siano adeguate sia dal punto di vista tecnologi- co, che dal punto di vista dell’esperienza offerta all’utente finale. L’identificazione delle migliori best practice e la scelta di tecnologie diffuse o largamente usate è una delle situazioni più comuni nei vari ambiti dell’IT. É proprio qui che entra in gioco la filosofia REST trattata nella sezione 2.1. Analizzando le caratteristiche essenziali del Cloud Computing e focalizzandosi (senza perdere di generalità) sul modello di servizio di tipo SaaS è chiaro come i vincoli imposti da REST siano di fatto un sensato ed ottimo stile e filosofia architetturale e di progettazione. Il mo- dello client/server promosso da REST, i vari vincoli di disaccoppiamento, l’uso di un’interfaccia uniforme e di comunicazione leggere tra produttore e consumatore del servizio, rendono in definitiva REST il più popolare stile di progettazione di API per i servizi Cloud, tanto da essere adottato attualmente anche da provi- der come Amazon, Microsoft e Google. Per ulteriori approfondimenti si può far riferimento a [48] [1] [2].

Servizi agili e leggeri

Dal punto di vista implementativo, negli ultimi anni è emersa una forte tendenza nello sviluppo di sistemi distribuiti e servizi basati su tecnologie e architetture che tendono a promuovere una filosofia di progettazione e di sviluppo agile (agile software development) proponendo un approccio meno strutturato e focalizzato

sull’obiettivo di consegnare al cliente software funzionante e di qualità in tempi brevi e frequentemente . La gran parte dei metodi agili tenta di ridurre il rischio di fallimento sviluppando il servizio o il software in finestre di tempo limitate chiamate iterazioni. Ogni iterazione è un piccolo progetto a sé stante e contiene tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del servizio, (pianificazione, analisi dei requisiti, progettazione, implementazione, test e documentazione).

Questo contesto è diventato il terreno fertile per l’adozione e l’evoluzione di una combinazione molto flessibile tra le filosofie e le tecnologie vista nel capi- tolo 2 (REST, HTTP, OAuth2) e tecnologie come HTML5, CSS3, Javascript, JSON per la creazione di servizi SaaS web e mobile oriented leggeri, di rapida implementazione e soprattuto di rapida estensione e distribuzione (in gergo scala- bili). I servizi implementati adottando questo paradigma leggero ed agile hanno di conseguenza le seguenti similitudini (in generale):

REST come architettura e filosofia. O quantomeno un sottoinsieme o una va- riante ispirata alle linee guida analizzate nella sezione 2.1. In particolare questa filosofia viene adottata maggiormente per il disaccoppiamento tra client e server mediante un’interfaccia uniforme e l’uso di un sistema a stra- ti, in modo da soddisfare requisiti di scalabilità. A livello implementativo si traduce nello sviluppo di API lato backend (server-side) che si occupano della business logic specifica del servizio e di un’interfaccia grafica (client- side) che interagisce con le API per la presentazione dei contenuti all’utente finale.

HTTP come protocollo di trasporto. HTTP è infatti economico, facile da im- plementare e gestire e supportato in generale sia dalle linee guida per lo svi- luppo di piattaforme Cloud che maggiormente dalla filosofia REST (come già analizzato in 2.2)

Text-based come contenuto tipico dei messaggi scambiati tra client e server. Di solito si usa il formato JSON come meccanismo per la strutturazione dei contenuti data la sua semplicità, eleganza e leggibilità.

Compattezza dei messaggi scambiati tra client e server. I messaggi sono di piccola e a volte media grandezza per favorire risposte rapide e concise, nonché un’intrinseca velocità di parsing e gestione delle informazioni.

Stateless come filosofia di progettazione non solo perché ispirata da REST ma soprattutto per questioni di reale scalabilità orizzontale. Ovvero vanno infatti tenuti sotto controllo eventuali stati o dati condivisi sia tra client e server che tra veri e propri processi o API lato server. In situazioni di replica orizzontale, tutte le entità condivise devono essere gestite in modo adeguato, con un conseguente impatto sulla scalabilità intrinseca dell’intero servizio o insieme di servizi.

Interoperabilità tra i consumatori del servizio (client). In generale il consu- matore è un’entità generica che vuole interagire con il sistema mediante l’uso delle API che espone. Rientrano in questo contesto le interfacce grafi- che mobile/web based intrinseche del servizio, ma anche reali applicazioni o script e servizi di terze parti che intendono interagire con tali API. I client sono quindi una popolazione variegata di piattaforme e linguaggi che sfrut- tano l’interfaccia uniforme offerta da REST e HTTP per l’interazione con il servizio cloud.

Servizi agili e leggeri: aspetti di sicurezza

Quando si parla di servizi leggeri e agili non significa che aspetti di sicurezza debbano essere messi in secondo piano. Anzi è altamente improbabile che un servizio possa essere talmente leggero da non richiedere alcun aspetto di sicurezza (o tale per cui la sicurezza possa essere trascurata) a meno che non si tratti di un servizio puramente ed esclusivamente informativo. Quando si parla di SaaS e Cloud Computing tuttavia di solito si ha a che fare con una sorta di infrastruttura che dinamicamente cresce/decresce in generale in base al numero di utenti e al numero di usi simultanei. É auspicabile quindi essere provvisti di meccanismi di sicurezza, controllo e monitoraggio (auditing).

In generale quindi gli aspetti di sicurezza necessari sono in linea alle comuni problematiche di ogni prodotto o servizio informatico. In primis (focalizzandosi nell’ambito del Cloud Computing) tra i più importanti c’è sicuramente il controllo dell’identità, dei ruoli e dei permessi per il richiedente di una risorsa in Cloud (in generale applicazioni client e utenti). Un sistema Cloud ben implementato infatti

è in grado di scalare in automatico mano a mano che la domanda cresce o decre- sce, con un conseguente aumento o diminuzione delle risorse hardware/software necessarie al mantenimento del servizio ed un inevitabile aumento o diminuzio- ne dei costi. Proteggere e controllare adeguatamente le risorse da usi anomali o accessi non autorizzati quindi si trasforma anche in un problema economico che partecipa al successo o al fallimento di un servizio implementato con strategie di Cloud Computing.

Dal punto di vista implementativo quindi le domande che uno sviluppatore interessato ad adottare un approccio sicuro ed in linea con la filosofia REST possono essere riassunte nelle seguenti:

• in che modo identità e permessi vengono trasmessi ad un generico servizio (nello specifico, ad un’API offerta dal servizio stesso) ?

• in che modo inoltre queste informazioni di accesso vengono, rappresentate, codificate e interpretate ?

• quali sono le informazioni da prendere in considerazione per concedere o meno l’accesso all’API o al servizio (account utente, ruoli, ACL,ecc.. )? • chi è inoltre l’entità responsabile di questi informazioni di accesso (per

operazioni come memorizzazione, conservazione e recupero)?

• sono inoltre previste entità di terze parti che hanno bisogno di accedere a risorse o API protette per conto di utenti o clienti del servizio ?

Le risposte a queste domande definiscono sia le politiche che gli aspetti imple- mentativi per la messa in sicurezza di risorse e API offerte dal servizio di Cloud Computing. Una scelta non ponderata sarebbe di intralcio al manifesto della filosofia REST e di Cloud Computing portando ad una serie di seri problemi di natura sia economica che architetturale (tra cui la scalabilità). Risulta più chiaro ora perché la definizione di Cloud Computing trattata nella sezione 3.1 privilegia e incoraggia l’uso di standard (anche innovativi). Per la risoluzione di queste problematiche le scelte possibili sono differenti, e una serie di standard e best practice sono state introdotte negli anni. Tuttavia sta prendendo sempre più spazio un altro importantissimo meccanismo che sta influenzando e innovando la moderna filosofia di pensiero in fatto di Cloud Computing, API e REST, ovvero lo standard OAuth2 (introdotto nella sezione 2.3).

Il framework OAuth2 consente di adottare un approccio centralizzato per la gestione delle identità fungendo come un vero e proprio servizio in grado di fornire e gestire tutti i dati e le informazioni di autenticazione in modo sicuro. Questo in- troduce un nuovo livello nell’architettura dell’intero servizio SaaS che in un primo momento potrebbe sembrare una inutile aggiunta di complessità ma i cui benefici saranno evidenti all’aumentare dei dati, dei componenti, e delle API e sotto- servizi offerti dall’intero sistema SaaS. Tutte queste motivazioni hanno spinto sia le grandi realtà dell’IT come Google, Facebook, Microsoft, Amazon, Twitter, Lin- kedin, Dropbox ma anche le emergenti startup ad adottare il framework OAuth2 per l’uso e l’interazione con le loro API e servizi.