Non cadiamo dalle nubi con il cloud

di a cura di Carlo Piana - 18 novembre 2014

Il cloud (o “la cloud”) è il paradigma informatico che sta rivoluzionando il mondo dell'IT, consentendo notevoli economie e semplificazioni. Ma gestirlo in modo da non cadere dalla padella nella brace richiede scelte sagge, per non diventare ancora più dipendenti da un fornitore  (in “lock-in”) di quanto lo si è con certo software proprietario. Una serie di documenti di Ecis –  organizzazione di imprese, tra cui Ibm, Oracle, Red Hat, che promuove l'interoperabilità dei sistemi – presentato il 13 novembre ci dà il “la” per introdurre alcuni concetti base.

In realtà con il termine “cloud” si intendono molte e svariate tipologie di soluzioni, tutte caratterizzate da una separazione tra il livello fisico e il livello applicativo del software, dove parte dello stack viene servito via Internet, dunque con un alto livello di astrazione (da cui il termine “cloud”, il simbolo convenzionale per Internet nei diagrammi). Dal punto di vista legale, la maggiore distinzione, è quella tra il cloud privato e il cloud pubblico. Il (o “la”) cloud privato è quello in cui fornitore e utilizzatore sono lo stesso soggetto, oppure sono collegati da relazioni che vanno al di là del contratto di servizio. In questo assetto, da un punto di vista legale e del lock-in, cloud o non cloud non c'è grande differenza, si tratta di fare le scelte giuste, ma il “dominio” sull'infrastruttura è dell'utilizzatore, non ci si affida a terzi, se non magari per l'infrastruttura di base (“IaaS”). Su tale infrastruttura si ha quanto meno il controllo e i privilegi cui siamo abituati, per cui la differenza è minima.

I problemi e le cautele crescono soprattutto con le cloud pubbliche. Nelle cloud pubbliche il cliente riceve non software, ma i servizi gestiti dal software. Di solito il cliente ha interfacce, consolle di amministrazione, ma l'amministrazione vera e propria è affidata al fornitore, il quale gestisce gli aggiornamenti, la sicurezza, il bilanciamento tra risorse geograficamente distribuite. Il che tra l'altro porta conseguenze anche dal punto di vista della tutela dei dati personali, su cui il Garante ha avuto modo di esprimersi più volte. Tra le cloud pubbliche vi sono soluzioni di ogni tipo, da quelle che si limitano a fornire software generico, come per esempio un database o un sistema centrale di autenticazione (Platform as a Service, o “PaaS”), a quelle che forniscono un prodotto fatto e finito a cui semmai il cliente può appoggiarsi attraverso limitate Api, e attraverso un'interfaccia web, pensiamo a Gmail o a un Crm via web (Software as a Service, o “SaaS”). Più tali applicazioni sono nel cuore dell'azienda (o dell'ente pubblico), più occorrono cautele. Esse non possono limitarsi solo a livelli di servizio garantiti, ma debbono includere una strategia di uscita se le cose vanno male. Il tema dei costi e delle inefficienze di uscita deve comunque sempre essere considerato, soprattutto lo deve essere per gli enti pubblici (vedi art. 68 comma 1 ter Cad).

In una situazione “tradizionale” quasi sempre il software è acquistato ed è “nostro”. Anche scaduto il contratto di assistenza possiamo ancora utilizzarlo (sempre che non si disattivi) e alla mala parata possiamo accedere al database e recuperare i dati, o affidare a un terzo questa operazione. Quando sia il software che i dati sono altrove, tutto ciò non è più una valida rete di sicurezza. E qui entrano a fagiolo le “policy reccomendations” e il documento illustrativo “Ensuring a Thriving Cloud market: Why interoperability matters for business and government” di Ecis.

Riassumendone i contenuti:

  • forte attenzione all'interoperabilità, perché solo così si possono utilizzare servizi di operatori diversi, incluse soluzioni-ponte;
  • l'interoperabilità deve essere garantita sia per i dati, sia per i servizi, per i dati di autenticazione e autorizzazione per gli utenti, sia addirittura per la portabilità delle singole applicazioni;
  • optare per soluzioni che utilizzano piattaforme aperte e riproducibili altrove (OpenStack, per esempio) consente di massimizzare la possibilità di migrare il fornitore e la maggior parte dello stack, sapendo di poter replicare la stessa situazione con minime disfunzioni;
  • dati, servizi, protocolli siano il più standard possibile (soprattutto standard aperti).

Privilegiare soluzioni ibride potrebbe essere anche una soluzione, ovvero non affidare tutto a un operatore esterno, ma utilizzare la parte cloud per singole funzioni, magari quelle più “commodity” (ancora, l'esempio del database) e con maggiore interoperabilità.

Per gli utenti più piccoli questi suggerimenti potrebbero essere al di fuori della propria portata. Ma in ogni caso la domanda che va fatta è sempre la stessa: ho una valida strategia di uscita se le cose vanno male? Il contratto e le licenze mi consentono una business continuity in caso di grane con il fornitore? Posso trovarmi da un momento all'altro nella situazione di dover migrare? In quali tempi? E se sì, come posso portare dati, servizi, applicazioni su un altro provider in tempo sufficiente?

E non abbiamo ancora toccato, se non marginalmente, la tematica della protezione dei dati personali nelle applicazioni in cloud, che molti fornitori dicono di rispettare, ma alcuni mancano clamorosamente. Ne parleremo magari più in là.

I documenti sono reperibili online:

http://www.ecis.eu/2014/11/ecis-report-careless-choice-of-cloud-provider-adds-big-costs-later/

http://www.ecis.eu/wp-content/uploads/2014/11/ECIS-cloud-computing-paper_Policy-Recommendations.pdf

http://www.ecis.eu/wp-content/uploads/2014/11/Cloud-Computing-Standards-Compatibility-and-Interoperability1.pdf

 

Carlo Piana

@carlopiana

 

- - - - - - -

Articolo sotto licenza Creative Commons Attribuzione – Condividi allo stesso modo 4.0


prev
next

0 Commenti :

Commento

Captcha

A CURA DI CARLO PIANA

/media/5648275/piana.png
DIRITTO NUOVE TECNOLOGIE
Account twitter Account LinkedIn Feed RSS

Rubrica in collaborazione con Simone Aliprandi e Alberto Pianon di Array Avvocato esperto di diritto delle nuove tecnologie, si occupa di tutela del software, informatica nei servizi pubblici, antitrust, marchi e nomi a dominio e molto altro.

Noto per l'impegno per il software libero e le libertà digitali, è editor della International Free and Open Source Software Law Review. Nel 2008 ha fondato Array, network di legali specializzati in ICT law - http://arraylaw.eu

Impresa
Se le leggi offrono poca ospitalità alla sharing economy: i problemi sollevati da AirBnB
30 novembre 2016

Grane legali per Facebook. Quando i social media diventano veicolo di contenuti illeciti
17 novembre 2016

"Secondary ticketing” o bagarinaggio 2.0?
3 novembre 2016

ARCHIVIO