Ciberspazio e Diritto · 233 Ciberspazio e diritto 2011, Vol. 12, n. 3, pp. 233-263 Profili civili...

Ciberspazio e DirittoInternet e le Professioni GiuridicheInvestigazioni DigitaliRivista Trimestrale

estrattooffprint

Cyberspace and LawInternet and Legal PracticeDigital InvestigationsQuarterly Journal

Mucchi Editore

issn 1591-9544 - vol. 12 no. 3 november 2011

233

Ciberspazio e diritto 2011, Vol. 12, n. 3, pp. 233-263

Profili civili e penali del cloud computing nell’ordinamento giuridico nazionale: alla ricerca diun equilibrio tra diritti dell’utente e doveri del fornitore

Guglielmo Troiano 1

Sommario: 1. Premesse. – 2. Ambiti contrattualistici, lex contractus e giuris-dizione competente. – 3. Standard proprietari e “vendor lock-in”. – 4. Di-ritti d’autore, “licensing” e libertà dell’utente. – 5. I reati informatici. – 6. L’illecito trattamento di dati. – 7. Le misure di sicurezza. – 8. Il trasferi-mento dei dati extra UE. – 9. Conclusioni.

1. Premesse

Il cloud computing 2 è il risultato di un «percorso circolare nella storia

1 Guglielmo Troiano è membro di Array, gruppo informale di avvocati indipen-denti specializzati in nuove tecnologie. Prima di conseguire la laurea in giurisprudenza presso l’Università degli Studi di Milano ed il Master in Diritto della Rete presso l’Uni-versità degli Studi di Padova, è stato per diversi anni analista di sistemi informativi. Col-labora con le cattedre di Informatica Giuridica e Informatica Giuridica Avanzata dell’U-niversità degli Studi di Milano ed è fellow dell’Istituto Italiano Privacy.

2 Non esite una definizione univoca di cloud computing. Il termine cloud, con ogni probabilità, deriva dalla rappresentazione grafica che in informatica si utilizza per indicare la rete Internet, una nuvola appunto. Il termine computing, invece, attiene alla progettazio-ne e realizzazione di hardware e software per la gestione dei dati. Il NIST (National Institu-te of Standard and Technology) dello U.S. Department of Commerce ha fornito una defini-zione che risulta spesso adottata (http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf). In buona sostanza, il termine cloud computing è utiliz-zato oggi per indicare le risorse informatiche (di un computer) collocate in più luoghi del-la rete Internet e tramite la stessa utilizzabili (per le varie tipologie di cloud computing vedi in seguito). Nel presente Articolo si utilizzeranno i termini “Cloud Computing”, “Cloud” e “CC” per indicare il fenomeno nel suo complesso. L’analisi più completa ed esaustiva sull’argomento risulta essere “The Future of Cloud Computing” coordinata dalla Direzione Generale Società dell’informazione e mezzi di comunicazione (DG Information Society) della Commissione europea. Inoltre, si segnalano “Cloud computing e tutela dei dati per-sonali in Italia: una sfida d’esempio per l’Europa”, in Diritto, Economia e Tecnologie del-la Privacy, Istituto Italiano Privacy, ottobre 2011 e gli atti della conferenza “Cloud Com-puting e Privacy”, E-Privacy 2011 in http://e-privacy.winstonsmith.org/interventi.html.

234

Guglielmo Troiano

dell’informatica» 3. Negli anni ’80, quando i computer domestici non ave-vano risorse sufficienti per poter custodire ed elaborare tante informazio-ni, i dati venivano memorizzati e processati attraverso i più potenti si-stemi informativi dei governi, dei centri di ricerca e delle istituzioni 4. Di questi sistemi si utilizzavano anche il linguaggio di programmazione e in molti casi venivano utilizzati come repository per dati o programmi, attra-verso una «sorta di cloud abusivo» 5. A partire dalla seconda metà degli anni ’90, con il drastico calo dei costi delle memorie e dei processori, l’utiliz-zatore informatico iniziò a custodire i dati sui supporti presso il proprio domicilio privato o luogo di lavoro poiché, in sostanza, aveva «una per-cezione di maggior sicurezza nel tenere tutti i dati presso di sé» 6. Nel nuovo millennio, il dato «abbandona l’utente e ritorna sui grandi sistemi» 7, nella “nuvola”, il più delle volte anche inconsapevolmente 8.

Il Cloud nasce e si sviluppa dall’idea alla base dell’ASP (Application Service Provider) che, circa dieci anni or sono, introduceva nell’informa-tica il concetto del pay-per-use (definito anche del pay-as-you-go) e l’offer-ta di tecnologia come servizio, superando la tradizionale vendita di pro-dotti, ovvero di hardware e software su supporti fisici.

I vantaggi che offre il Cloud sono indubbi. Disponibilità e accessi-bilità ai propri dati in ogni momento, gratuitamente o a costi estrema-mente ridotti, da qualunque dispositivo collegato alla rete. Una Panacea per la società dell’informazione. Ma a quali condizioni si ottiene tutto

3 Cfr. G. Ziccardi, in “Cloud computing tra criminalità, investigazioni e (r)esi-stenza elettronica”, Roma, 25 marzo 2011 e G. Ziccardi, in Hacker - Il richiamo della li-bertà, Marsilio Editore, Venezia, 2011.

4 Tale pratica è riconducibile a quella denominata di “time-sharing”. Negli anni ’80 si pensò di far utilizzare a più utenti i primi computer mainframe, estremamente co-stosi, utilizzando i tempi morti per servire i diversi utenti a rotazione. Allo stesso modo, le piccole porzioni di tempo che i computer trascorrevano nell’attesa dei dispositivi, qua-li dischi, nastro magnetico o rete potevano essere utilizzati per servire i vari utenti. Cfr. “Time-sharing”, in Wikipedia, http://it.wikipedia.org/wiki/Time-sharing.

5 Cfr. G. Ziccardi, op. cit.6 Ibidem.7 Ibidem.8 Il sistema operativo Android per dispositivi mobili, per esempio, prevede una

sincronizzazione pressocché totale dei dati attraverso un account Google. “[…] alla fine il telefono diventa meno importante: lo perdete, ne comprate un altro e quello nuovo diventa identico a quello vecchio […]”. Cfr. G. Ziccardi, op. cit.

235

Profili civili e penali del cloud computing nell’ordinamento giuridico nazionale

ciò? Spesso gli utilizzatori lo ignorano 9 o non ne comprendono realmente le conseguenze 10. I servizi, predeterminati con tipologie 11 standard, sono costituiti essenzialmente da risorse informative e informatiche centraliz-zate che, per loro stessa natura, sono facili da controllare da parte del ge-store. Quest’ultimo possiede tutti i dati dell’utilizzatore ma si concentra generalmente sul deployment e sulla delivery del servizio più che sulla pro-gettazione di un sistema che salvaguardi i dati stessi.

Un recente studio 12 ha ipotizzato che nel 2015 il Cloud sarà utiliz-zato da oltre 2,5 miliardi di persone con oltre 10 miliardi di apparati di-versi che accederanno ad internet, oltre il doppio di quelli attuali. Della sua importanza si è accorta anche la DG Information Society della Com-missione europea che, nell’ambito della Digital Agenda for Europe 13, ha inserito il Cloud tra i temi prioritari da sviluppare entro il 2020 ed ha

9 “Is Google reading my mail? No, but automatic scanning and filtering technology is at the heart of Gmail. Gmail scans and processes all messages using fully automated systems in order to do useful and innovative stuff like filter spam, detect viruses and malware, show rel-evant ads, and develop and deliver new features across your Google experience. Priority In-box, spell checking, forwarding, auto-responding, automatic saving and sorting, and convert-ing URLs to clickable links are just a few of the many features that use this kind of automat-ic processing.” Cfr. “FAQ about Gmail, Security & Privacy” in https://mail.google.com/support/bin/answer.py?hl=en&answer=1304609.

10 Cfr. Jack Schofield, in “When Google owns you…. your data is in the cloud”, The Guardian, articolo disponibile alla pagina http://www.guardian.co.uk/technology/blog/2008/aug/06/whengoogleownsyouyourdata.

11 I servizi del Cloud sono generalmente così classificati: i) Infrastructure as a Ser-vice - IaaS. L’utente può acquistare risorse di memorizzazione (Storage Cloud) o compu-tazionali (Compute Cloud) in quantità proporzionate alle proprie esigenze (es. un tot di Ghz di elaborazione dati con picchi dalle ore x alle ore x, un tot di GB di dati di storage, un tot di banda di traffico dati in ingresso ed in uscita dalle ore x alle ore x e così via); ii) Platform as a Service - PaaS. Sono fornite risorse di calcolo attraverso una piattaforma su cui le applicazioni possono essere sviluppate e ospitate direttamente dall’utente. Il PaaS tipicamente utilizza le API (Application Program Interface) per controllare il comporta-mento del server che esegue e replica l’esecuzione in base alle richieste (istanze, o compute instance) dell’utente (es. tasso di accesso); iii) Software as a Service - SaaS. È il tipo di ser-vizio più diffuso e più semplice, solitamente gratuito, con il quale spesso tutto il Cloud si identifica. Indicato anche come Application Cloud, consiste nell’utilizzo di applicativi con funzionalità standard accessibili, per lo più, via web.

12 Cfr. “Cloud Computing Report 2011”, Nextvalue report.13 I dettagli della Digital Agenda for Europe, sono disponibili alla pagina http://

ec.europa.eu/information_society/digital-agenda/index_en.htm.

236

Guglielmo Troiano

organizzato una consultazione pubblica 14 per tutte le parti interessate. In ambito nazionale, invece, il Cloud è stato recentemente analizzato 15 dall’Autorità garante per la protezione dei dati personali (Garante Priva-cy) che ha focalizzato l’attenzione degli utenti sui pericoli che può com-portare un uso inconsapevole.

L’analisi che qui ci occupa cercherà di fornire un ampio quadro sul-le implicazioni giuridiche del Cloud che, per communis opinio, sono ri-condotte spesso al solo ambito della protezione dei dati personali. Inve-ro, il Cloud conduce a diversi ambiti giuridicamente rilevanti, sia pena-li che civili, che meritano di essere analizzati al pari della protezione dei dati e della sicurezza dei sistemi, che restano in ogni caso i temi maggior-mente trascinanti.

Considerando la finalità specialistica che il presente articolo si pre-figge, non si è ritenuto di dar conto di nozioni di base, soprattutto in ri-ferimento alla normativa in materia di trattamento dei dati personali. È tuttavia utile indicare e definire, quantomeno, le tipologie di soggetti che hanno un ruolo attivo nel Cloud, ovvero, l’utilizzatore dei servizi (che in-dicheremo come “utente”), il fornitore dei servizi (“fornitore”) e i sog-getti che a vario titolo collaborano con quest’ultimo al di fuori della sua struttura (che potremmo definire “partner” o “soggetti terzi”). In partico-lare, l’utente assume nel Cloud il ruolo di titolare del trattamento dei dati che raccoglie e deposita presso il fornitore ma non mancano le eccezioni che possono ricondurre tale ruolo anche a quest’ultimo. Inoltre, l’utente può utilizzare i servizi per fini privati (utente-consumatore) o può essere una società, un’organizzazione (pubblica o privata) o un singolo profes-sionista che utilizza il Cloud per finalità istituzionali o professionali assu-mendo così, a seconda dei casi appena elencati, diverse soggettività giuri-diche nei rapporti contrattuali con il fornitore.

14 La consultazione si è chiusa lo scorso 31 agosto. Le risposte della consultazione andranno ad alimentare la preparazione di una strategia europea di Cloud che la Com-missione europea presenterà nel 2012. Per approfondimenti si consulti la pagina http://ec.europa.eu/yourvoice/ipm/forms/dispatch?form=cloudcomputing&lang=en.

15 Cfr. “Cloud Computing: indicazioni per l’utilizzo consapevole dei servizi”. Scheda di documentazione dell’Autorità garante per la protezione dei dati personali pub-blicata congiuntamente alla Relazione Annuale del 2010.

237


Infine, prima di intraprendere l’analisi giuridica, può tornare utile fornire alcune indicazioni generali sugli aspetti tecnici del Cloud. Abbia-mo già accennato che il Cloud offre diverse tipologie di servizio: SaaS, PaaS e IaaS (cfr. nota n. 11). La parola chiave per tutti i modelli è vir-tualizzazione, ovvero, la creazione di una versione virtuale di una risorsa normalmente fornita fisicamente. Le memorie magnetiche di tipo stabile, ovvero le memorie che custodiscono dati attraverso la memorizzazione di tratti di un determinato supporto (per es. hard disk), con il Cloud sono virtualizzate. Qualunque risorsa hardware o software può essere virtua-lizzata: sistemi operativi, server, memoria, spazio disco, sottosistemi. Il Cloud di tipo SaaS si configura come il sistema più semplice e, anche per questo, più comune e diffuso. Il SaaS corrisponde alla virtualizzazione di applicativi la cui interfaccia grafica è il browser. È utilizzato spesso per fi-nalità consumer anche se non è escluso che sia utilizzato anche da libe-ri professionisti, imprese individuali, società, organizzazioni o pubbliche amministrazioni che elaborano pochi dati e con ridotte esigenze di infor-matizzazione. I modelli PaaS e IaaS sono invece per utenti maggiormen-te esigenti in quanto consentono la gestione di un vero e proprio ambien-te server di sviluppo e/o di produzione. L’architettura informatica sottesa in ogni caso a tutte le species del Cloud è quella che consente l’interazio-ne tra il computer 16 dell’utente e quello del fornitore, ovvero, il sistema client-server. Tutte le applicazioni che comunicano tramite reti o inter-reti seguono questo unico paradigma, senz’altro ciò avviene nel Cloud. I programmi che attendono passivamente di essere contattati sono detti server, mentre quelli che effettivamente contattano un destinatario sono detti client. In particolare, nel Cloud il client si collega al server per acce-dere anche a risorse di computing, che gli consentono di elaborare dati e che, diversamente, dovrebbe richiedere localmente 17. Oltre alla virtualiz-

16 Computer è da intendersi nel senso più ampio del termine, che possa ricom-prendere qualunque dispositivo collegabile alla rete e con capacità, anche minima, di ela-borazione. Per esempio, gli smartphone sono da considerare come tali.

17 Significativo è l’esempio del Chromebook di Google, con il sistema operativo Chrome OS, sempre di Google. In una pagina web che lo pubblicizza si legge: “Applica-zioni, impostazioni e documenti sono tutti memorizzati in modo sicuro nella cloud. Quindi, anche se perdi il tuo computer, è sufficiente eseguire l’accesso su un altro Chromebook per ri-metterti subito al lavoro.”. In altre parole, significa che il pc non memorizza nulla in loca-

238

Guglielmo Troiano

zazione anche la ridondanza 18 è una componente essenziale del Cloud, fi-nalizzata alla ottimizzazione delle risorse informatiche. Infatti, quando, e se, gli algoritmi di gestione delle stesse dovessero verificare la presenza di criticità o eccessivi “carichi di lavoro”, tutte le risorse potrebbero essere spostate automaticamente su un altro server (operazione di c.d. load ba-lancing). Di fatto, quindi, il client non accede sempre allo stesso server ma a quello sul quale risultano essere collocate le risorse richieste. In tal gui-sa, la stabile e certa collocazione fisica dei dati viene meno. Questi pos-sono essere memorizzati contemporaneamente su diversi server, colloca-ti anche in stati al di fuori dell’UE in Paesi che non offrono un’adeguata tutela 19 (cfr. par. n. 8).

2. Ambiti contrattualistici, lex contractus e giurisdizione competente

Gli ordinamenti giuridici, com’è noto, sono generalmente carat-terizzati dal principio di “territorialità” 20 per quanto attiene all’applica-zione delle norme di diritto penale interne 21 ma, in ambito civilistico, si pone sempre il dubbio di quale debba essere considerato l’ordinamento competente a regolare un rapporto tra privati che presenta elementi di “estraneità”. Infatti, con il Cloud, sovente si costituiscono rapporti con-

le. Tutti i dati dell’utente sono online sui server di Google – “nella cloud” – accessibili at-traverso i vari servizi (Google Docs, Google Buzz, Youtube, Picasa ecc.).

18 La ridondanza consiste nella duplicazione dei componenti critici di un sistema con l’intenzione di aumentarne l’affidabilità, in particolare per le funzioni di vitale impor-tanza per garantire la sicurezza delle persone e degli impianti o la continuità della produ-zione. Cfr. Wikipedia, http://it.wikipedia.org/wiki/Ridondanza_(ingegneria).

19 Per esempio, nell’informativa sulla privacy (Privacy Policy, alla pagina http://www.google.co.uk/intl/en/privacy/privacy-policy.html) dei prodotti e servizi di Google (tra i quali Gmail, Calendar, Docs, Groups, Web Search, Picasa ecc.) cui milioni di uten-ti affidano i propri dati personali e sensibili, si legge testualmente “Google processes perso-nal information on our servers in the United States of America and in other countries. In some cases, we process personal information outside your own country.”.

20 Per cui il diritto vigente in ciascun ordinamento si applica a tutti, cittadini e stranieri, che si trovino nel territorio ove quell’ordinamento è in vigore.

21 L’applicazione del principio di territorialità, con internet e le nuove tecnolo-gie di informazione e comunicazione, anche in ambito penale non sempre emerge chia-ramente (cfr. Par. 5).

239


trattuali tra soggetti con residenze o sedi (se persone giuridiche) in stati differenti, cui si aggiunge l’ulteriore complicazione dei casi in cui uno di essi sia un “consumatore”.

L’individuazione quindi della legge che regolerà i termini del con-tratto e del giudice che sarà adìto per le controversie tra utente e forni-tore in un contratto di servizi di Cloud, si basa su una duplice evenien-za: scelta determinata dalle parti e casi in cui la scelta non sia avvenuta o non avvenga nemmeno successivamente alla conclusione del contrat-to. Le regole di diritto internazionale privato 22, infatti, stabiliscono come primo “criterio di collegamento” quello della scelta delle parti, sia prede-terminata nel contratto sia effettuata in ogni momento successivo, anche in deroga ad una scelta precedente 23. Il fornitore di Cloud predetermine-rà quasi sempre una clausola contrattuale nella quale indicherà la legge di uno stato che regolamenterà il contratto e nella scelta, ovviamente, terrà conto solo delle sue esigenze.

Tuttavia, anche se la lex contractus ed il giudice competente sono stati predeterminati, la scelta effettuata incontra dei limiti in materia di contratti conclusi con i consumatori 24. In questo caso, la scelta è ammes-sa ma l’esercizio di essa non può avere per effetto di privare il consuma-tore della tutela garantitagli dalle disposizioni imperative della legge del paese nel quale risiede abitualmente 25.

In tutte le ipotesi in cui, invece, vi è assenza di scelta, il contratto sarà regolato dalla legge del paese nel quale il fornitore del servizio 26 ha

22 Le disposizioni da prendere in esame, ed applicabili al Cloud, sono il Regola-mento CE n. 593/2008 (denominato Roma I) ed il Regolamento CE n. 44/2001. Il pri-mo determina la legge applicabile ai rapporti contrattuali, mentre il secondo si occupa della giurisdizione competente in materia civile e commerciale. I regolamenti hanno ca-rattere universale, ovvero, possono anche comportare l’applicazione della legge, o rendere competente il giudice, di uno stato non facente parte dell’UE.

23 Ex art. 3 del Regolamento CE n. 593/2008.24 Ai sensi dell’art. 6 del Regolamento CE n. 593/2008 e dell’art. 15 del Regola-

mento CE n. 44/2001 il consumatore è da considerarsi la persona fisica che conclude un contratto per scopi estranei all’attività imprenditoriale o professionale.

25 Ex art. 6 c.2 del Regolamento Roma I.26 L’art. 4 c.1 lett. b) e l’art. 6 c.4 lett. a) del Regolamento CE n. 593/2008, espres-

samente richiamano il contratto di prestazione e fornitura di servizi, cui il contratto di Cloud è senz’altro riconducibile (vedi infra nel presente paragrafo).

240

Guglielmo Troiano

la propria residenza abituale o, se si tratta di persona giuridica, la propria sede, ad eccezione sempre dei contratti conclusi con i consumatori, che saranno invece sottoposti alla legge del paese nel quale il consumatore ha la sua residenza abituale ma a condizione che anche il professionista svol-ga le sue attività nello stesso paese, o diriga tali attività, con qualsiasi mez-zo, verso tale paese 27. In assenza di tutte queste condizioni, la legge appli-cabile sarà quella del paese in cui il fornitore ha la residenza abituale, o la sede se persona giuridica.

L’analisi di diritto internazionale privato sin qui svolta, trascende dalle questioni di diritto privato “interne”. In particolare, per questo tipo di analisi risulta indifferente la qualificazione giuridica del contratto con il quale si regolamenta il rapporto tra utente e fornitore. Il diritto inter-nazionale privato si preoccupa solo di fornire le regole per stabilire la leg-ge applicabile ed il giudice competente, prescindendo, generalmente, dal tipo di contratto. Tuttavia, una breve trattazione che riguarda l’indivi-duazione della tipologia, rectius delle tipologie, di contratto riconducibili al Cloud, sembra opportuna in questo contesto.

Anzitutto, anche se può apparire superfluo ribadirlo a questo pun-to del discorso, si può rilevare che il Cloud ha senza dubbio ad oggetto la fornitura di servizi, piuttosto che la vendita di prodotti, come natura-le conseguenza della sua genesi nella storia dell’informatica. Proseguen-do quindi sulla base di questo assunto, si possono evidenziare alcuni trat-ti contrattuali comuni in tutte le tipologie di Cloud. Eloquente risulta l’impegno dell’utente a consegnare al fornitore i propri dati e l’assunzio-ne dell’obbligo di quest’ultimo di custodirli e restituirli su richiesta del primo, caratteri tipici del contratto di deposito 28 in cui l’utente si iden-tificherebbe come depositante ed il fornitore come depositario. Inoltre, sussistono forti analogie con il contratto di somministrazione, ovvero del contratto con il quale una parte si obbliga ad eseguire a favore dell’altra prestazioni periodiche o continuative, verso corrispettivo di un prezzo. Infine, come parte della Dottrina 29 ha già evidenziato, sono presenti ca-

27 Ex art. 6 c.1 del Regolamento CE n. 593/2008.28 Contratto previsto agli artt. 1766 e ss. del codice civile.29 Cfr. L. Bolognini, D. Fulco e P. Paganini (a cura di), in “Next Privacy”, Etas,

2010 e E. Belisario, in “Diritto sulle nuvole - Profili giuridici del cloud computing”, Al-talex, 2011.

241


ratteri del contratto di appalto 30 sebbene, a parere di chi scrive, occorra precisare che tale contratto, per essere qualificato tale, necessita di un ele-mento fondamentale: il progetto. L’oggetto dell’appalto, infatti, dev’es-sere determinato o determinabile e ciò avviene normalmente con il pro-getto procurato dal committente. Solitamente, invece, i servizi di Cloud sono forniti omologhi per tutti.

3. Standard proprietari e “vendor lock-in”

Una delle più annose questioni dell’informatica è il c.d. “vendor lock-in” 31, concetto sviluppatosi sin da tempi non sospetti nel mondo dell’economia, e a cui il Cloud senz’altro non si è sottratto. In sostanza, sussiste la possibilità che l’utente resti vincolato all’utilizzo di formati di “standard proprietario” 32 scelti dal fornitore e da cui possono discende-re due problematiche rilevanti: i) l’esportazione dei dati non sarà possibi-le se non nel formato di standard scelto dal fornitore, per cui, nel caso di risoluzione o cessazione del contratto non risulterà agevole, quantomeno non a costi contenuti, il trasferimento degli stessi ad un altro fornitore; ii) l’interoperabilità con altri sistemi e programmi, essenzialmente l’in-terconnessione e interazione dei sistemi informativi, non sarà possibile se non con sistemi e programmi che riconoscono lo “standard proprietario” utilizzato. Questi rischi si chiamano anche, in termini economici, rischi

30 L’appalto, ai sensi degli artt. 1655 e ss. del codice civile, è il contratto con il quale un soggetto (committente) affida ad un altro soggetto (appaltatore) lo svolgimen-to di un servizio.

31 “In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.” Cfr. Wikipedia, in http://en.wikipedia.org/wiki/Vendor_lock-in.

32 Un formato è proprietario se il modo di rappresentazione dei suoi dati è opaco e la sua specifica non è pubblica. Si tratta in genere di un formato sviluppato da un’azienda di software per codificare i dati di una specifica applicazione che essa produce: solo i pro-dotti di questa azienda potranno leggere correttamente e completamente i dati contenuti in un file a formato proprietario. I formati proprietari possono inoltre essere protetti da un brevetto e possono imporre il versamento di royalties a chi ne fa uso. Cfr. Open For-mats, http://www.openformats.org/it1.

242

Guglielmo Troiano

di “monopolio” che, come l’economia classica insegna, è una situazione subottimale per il venditore che esercita una forzatura sul compratore per indurlo a continuare ad acquistare a condizioni monopolistiche, costrin-gendolo a portare avanti la scelta iniziale 33.

Data l’esistenza di standard di fatto 34, di dipendenze tecnologiche di vari ordini di grandezza e l’abilità commerciale di alcuni operatori che sottacciono aspetti non irrilevanti delle proprie offerte, il fenomeno del “vendor lock-in” è estremamente più elevato nel Cloud e nemmeno lo “standard aperto” 35 può evitarlo.

La standardizzazione è infatti un processo volontario basato sul con-senso di differenti attori dell’economia: industrie, imprese medio-picco-le, consumatori, lavoratori, organizzazioni non governative, pubbliche autorità ecc. Per superare quindi gli ostacoli derivanti dall’adozione di standard diversi nella produzione informatica, è recentemente intervenu-

33 Ad esempio, se compro una stampante a getto di inchiostro, sono vincolato a comprare cartucce della stessa marca, solo che le cartucce hanno un costo comparabile a quello della stampante. Oppure l’acquisto di certe macchine per il caffé che accettano solo alcune cialde. Storicamente ciò che evita o attenua l’effetto lock-in è l’esistenza di stan-dard aperti, ovvero utilizzabili da chiunque e sotto il controllo di nessuno. Così in uno stesso ufficio possiamo avere stampanti Canon, Xerox, Kyocera, Olivetti, ecc., l’impor-tante è che accettino uno standard ISO per il formato della carta (ad esempio l’A4 nel-lo standard ISO 216). Se ogni fornitore accettasse solo il proprio standard per la carta, e nessuno potesse offrire lo stesso, si sarebbe in una situazione insostenibile, in cui proba-bilmente la carta costerebbe un multiplo di quello che è il costo attuale.

34 “Si parla di standard de jure quando lo standard è frutto di un regolare proces-so di analisi tecnica e definizione gestito da apposite organizzazioni, e quando è stato for-malizzato e descritto in uno specifico documento chiamato comunemente “norma tecni-ca”, o anche più semplicemente “norma”. Tuttavia, non sempre un determinato model-lo può assurgere allo status di standard de jure. Ci sono infatti modelli di riferimento che solo per la loro elevata diffusione vengono comunemente considerati standard, ma in re-altà non sono mai stati riconosciuti come tali da apposite organizzazioni attraverso un re-golare processo di standardizzazione: si parla in questo caso di standard de facto.” Cfr. Si-mone Aliprandi, in “Apriti standard! Interoperabilità e formati aperti per l’innovazione tecnologica”, Ledizioni, 2010.

35 Un formato è aperto se il modo di rappresentazione dei suoi dati è trasparen-te e/o la sua specifica è di pubblico dominio. Si tratta generalmente (ma non esclusiva-mente) di standard fissati da autorità pubbliche e/o istituzioni internazionali il cui scopo è quello di fissare norme che assicurino l’interoperabilità tra software. Non mancano tut-tavia casi di formati aperti promossi da aziende, che hanno deciso di rendere pubblica la specifica dei propri formati. Cfr. Open Formats, ibidem.

243


to il principio dell’interoperabilità che l’Unione Europea ha adottato con proprie definizioni istituzionali 36.

Tuttavia, anche se alcuni fornitori 37 di servizi di Cloud hanno com-preso l’importanza dell’utilizzo di standard aperti, molti altri continuano a definire – indipendentemente l’uno dall’altro – formati ai quali attener-si e che l’utente adotta pedissequamente. I software utilizzati nel Cloud, data la rilevanza che esso ha per il futuro dello sviluppo della società dell’informazione, devono poter invece essere capaci di scambiarsi dati, leggendo e scrivendo sullo stesso file e usando lo stesso protocollo per farlo. L’assenza di interoperabilità non può che essere quindi mancan-za di standardizzazione (di uso di standard comuni) nella fase di proget-tazione del programma. L’uso o meno di interoperabilità nello sviluppo di prodotti tecnologici ha rilevanti conseguenze economiche. Se prodot-ti tra loro concorrenti non sono interoperabili (a causa della presenza di brevetti, segreti industriali o semplicemente mancanza di coordinazione nell’uso di standard comuni), il risultato non può che essere la nascita di un monopolio o il fallimento del mercato 38.

A Siviglia, nel giugno del 2002, durante una riunione dei capi di governo dei Paesi membri dell’Unione Europea, è stato adottato il c.d. “eEurope Action Plan” con cui la Commissione Europea si è impegna-ta a supportare l’interoperabilità dei servizi, ovviamente in forma digita-le, offerti ai cittadini ed alle imprese che vivono e svolgono attività com-merciali nell’ambito del territorio dell’UE. Da ciò è nato un progetto di studio da cui è scaturito il documento European Interoperability Fra-

36 Cfr. Considerando 10, 11 e 12 della Direttiva 91/250/CEE “Considerando che i programmi per elaboratore svolgono la funzione di comunicare e operare con altri com-ponenti di un sistema informatico e con gli utenti; che a tale scopo è necessaria un’inter-connessione e un’interazione logica e, ove opportuno, materiale per consentire a tutti i componenti software e hardware di operare con altri software e hardware e con gli uten-ti in tutti i modi in cui sono destinati a funzionare; considerando che le parti del pro-gramma che assicurano tale interconnessione e interazione fra gli elementi del software e dell’hardware sono generalmente denominate “interfacce”; considerando che tale inter-connessione e interazione funzionale è generalmente denominata “interoperabilità”; che tale interoperabilità può essere definita come la capacità di due o più sistemi di scambiare informazioni e di usare reciprocamente le informazioni scambiate”.

37 Come per esempio “Open Shift” e “Cloud Forms” della Red Hat, Inc. e “Cloud Foundry” di VMware, Inc.

38 Cfr. Adriano Vanzetti, in “Manuale di diritto industriale”, Giuffrè, Milano, 2009.

244

Guglielmo Troiano

mework 39 (EIF). Inoltre, sempre la Commissione Europea, ha adottato una strategia a lungo termine chiamata “Europe 2020” 40, ovvero la stra-tegia per far riavviare l’economia Europea in questo periodo di crisi con prospettiva per i prossimi dieci anni. Nell’ambito dello “Europe 2020” si inserisce la Digital Agenda for Europe (accennata in premessa) che ha tra le sue finalità 41 essenziali l’Interoperabilità e il Cloud, appunto. Secondo questi principi, la società dell’informazione può progredire e svilupparsi solo se si basa su piattaforme e standard aperti e interoperabili.

4. Diritti d’autore, “licensing” e libertà dell’utente

Il Cloud evidenzia anche un’altra trascinante questione del mondo dell’informatica, strettamente connessa al “vendor lock-in” analizzato nel paragrafo precedente, ovvero, la distribuzione del software che, sin dagli anni 80, si identifica sostanzialmente nella contrapposizione tra il Sof-tware Libero 42 (in tempi recenti definito anche FLOSS, Free Libre Open Source Software) ed il Software Proprietario 43.

Per questioni di opportunità, non sarà ripercorsa in questa sede la sconfinata storia della genesi dei programmi per elaboratore nel mondo del diritto, che ha anche portato al “forking” ideologico tra Software Li-bero e Proprietario, ma alcune precisazioni sono necessarie per compre-dere meglio l’analisi giuridica che seguirà.

Le opere dell’ingegno che al pari del software sono protette dalla leg-ge sul diritto d’autore (o copyright se si considerano il sistema giuridico sta-

39 Il documento completo e nella versione finale è disponibile alla pagina http://ec.europa.eu/idabc/servlets/Doc?id=19529.

40 Per gli ultimi aggiornamenti sul tema si consulti il sito http://europa.eu/rapid/pressReleasesAction.do?reference=IP/10/225&format=HTML&aged=0&language=EN&guiLanguage=en.

41 http://ec.europa.eu/information_society/newsroom/cf/pillar.cfm?pillar_id=43&pillar=Digital%20Single%20Market.

42 Il Software Libero o FLOSS è il software che viene rilasciato sotto licenze che rispettano – a seconda delle scuole di pensiero – le quattro libertà della Free Software Foundation oppure i principi dell’Open Source Initiative.

43 Il Software Proprietario è quello che non è libero o semilibero. Il suo utilizzo, la ridistribuzione o modifica sono proibiti o richiedono un permesso o sono sottoposti a tali vincoli che in pratica non si possono fare liberamente. Cfr. http://www.gnu.org/philoso-phy/categories.it.html#ProprietarySoftware.

245


tunitense e suoi derivati), sono in larga parte dematerializzate e non dipen-dendo da un supporto fisico determinato. Inoltre, il software è un prodot-to (un’opera) per sua natura di rapidissima obsolescenza e l’incoporazio-ne sul c.d. corpus mechanicum risulta inutile per diversi motivi tra cui, per esempio, l’aggiornamento necessario alla stabilità e sicurezza del sistema informativo su cui è, o andrà, installato il software. L’unico supporto sul quale può essere utilmente fissato il software è rappresentato dall’hardware dello stesso elaboratore elettronico e non da supporti (memorie) esterni ad esso. Il valore del software non sta, difatti, nel supporto su cui viene regi-strato ma nel suo contenuto ideativo ed il pericolo che corre l’autore non è tanto che gli sia sottratto il supporto, ma che sia plagiato indebitamen-te da altri il contenuto dell’opera. Questo concetto è di assoluta rilevanza in relazione alla distribuzione al pubblico del programma per elaboratore.

Ciononostante, il “business model” adottato per la distribuzione del software è stato storicamente legato alla vendita di un supporto fisi-co cui si è aggiunta anche la pratica di regolare i rapporti 44 tra titolare dei diritti e utente finale con una specifica regolamentazione negoziale, con un vero e proprio contratto, ovvero con la licenza per l’utente finale (o EULA, End User License Agreement), il contratto tipico 45 che riserva al produttore tutti i diritti sul software o, nel caso del FLOSS, ne concede diversi ritenuti importanti per la libertà dell’utente finale ma soprattutto per gli sviluppatori.

44 Il diritto d’autore non si è mai granché preoccupato del legame che intercorre-va tra il titolare dei diritti e l’utente finale. Quest’ultimo acquistava il diritto di utilizza-re una copia dell’opera semplicemente perché acquistava il supporto su cui l’opera veniva incorporata (il disco, il libro, la videocassetta ecc.). Al pari delle altre opere come la mu-sica, i film o le opere letterarie, anche il software non è mai dipeso, di per sè, da un sup-porto fisico determinato (per esempio i CD o DVD sui quali solitamente si trova incor-porato nella vendita).

45 In realtà i diritti d’autore sul software possono essere trasferiti anche attraverso strumenti diversi dal contratto. “Nella nostra tradizione giuridica, la possibilità di imporre obblighi o condizioni a un altro soggetto in occasione del trasferimento di un diritto, viene re-alizzata per mezzo di un’obbligazione di tipo contrattuale. Non sempre è però così. Saltuaria-mente si ricorre invece a fattispecie minori, quale il modo, che non è un’obbligazione, ma può consentire la revoca della donazione.”. Cfr. Carlo Piana, in “Licenze pubbliche di software e contratto”, I Contratti, n. 7/2006, Ipsoa. Articolo disponibile alla pagina http://www.piana.eu/repository/720_727.pdf.

246

Guglielmo Troiano

Ciò premesso, sappiamo per certo che nel Cloud il software viene distribuito come servizio e non come prodotto incorporato in un suppor-to. Tuttavia, l’opera dell’ingegno resta, è solo altrove, installata sui com-puter del fornitore e visualizzabile dall’utente attraverso un’interfaccia grafica. Infatti, la possibilità che il titolare dei diritti d’autore possa “li-cenziare” i propri diritti risulta inattuabile 46 perché il software non è di-stribuito. Il sistema è strutturato in modo che sia il fornitore a control-larlo (escluso forse il caso del Cloud IaaS). Modifiche e aggiornamento del programma, per esempio, sono predefinite ed operate dal fornitore centralmente. Qualunque operazione sul software è riservata al fornitore.

Anche le software house generalmente inclini allo sviluppo ed alla di-stribuzione di programmi aperti e liberi, si sono adeguate a tale pratica, assorbendo in parte il licenziamento di diritti d’autore nei termini di ser-vizio 47. I diritti tipicamente concessi all’utente con le licenze del FLOSS, come la possibilità di far funzionare e utilizzare il programma per qualsia-si fine, di studiare come funziona il programma e di adattarlo alle proprie esigenze (avendo a disposizione il codice sorgente), di migliorare il pro-gramma e di rilasciare i propri miglioramenti al pubblico, non sono presi in considerazione dai fornitori di Cloud.

Tra l’altro, sarebbe sufficiente spiegare il legame che il software ha in generale con la sicurezza per comprendere facilmente quali sono le pro-blematiche sottese all’utilizzo di software in Cloud e che possono porta-

46 Ad eccezione del modello di Cloud IaaS in cui i fornitori licenziano le c.d. “istanze virtuali”.

47 I “Google Terms of Service” (disponibili all’indirizzo http://www.google.com/accounts/TOS?hl=en) applicabili al servizio Google Docs, in relazione ai diritti d’autore stabiliscono: “10.1 Google gives you a personal, worldwide, royalty-free, non-assignable and non-exclusive license to use the software provided to you by Google as part of the Services as provided to you by Google (referred to as the “Software” below). This license is for the sole purpose of enabling you to use and enjoy the benefit of the Services as provid-ed by Google, in the manner permitted by the Terms. 10.2 You may not (and you may not permit anyone else to) copy, modify, create a derivative work of, reverse engineer, de-compile or otherwise attempt to extract the source code of the Software or any part there-of, unless this is expressly permitted or required by law, or unless you have been specifi-cally told that you may do so by Google, in writing. 10.3 Unless Google has given you specific written permission to do so, you may not assign (or grant a sub-license of) your rights to use the Software, grant a security interest in or over your rights to use the Soft-ware, or otherwise transfer any part of your rights to use the Software.”

247


re lo stesso ad essere considerato “insicuro”, in quanto contenente istru-zioni e condizioni non previste dall’essere umano che lo ha programma-to ma da qualcun altro. Non solo. Occorre considerare anche i modi con cui chi ha programmato il software può nascondere al suo interno vulne-rabilità per finalità eticamente molto discutibili.

La sicurezza ed il FLOSS hanno invece un legame inscindibile e tale software può essere non solo più sicuro dell’alternativa “proprietaria” ma l’unico modello utile per risolvere diversi problemi di sicurezza informatica.

Le backdoor sono per esempio uno dei rischi legati all’utilizzo di Software Proprietario e riguarda la possibilità che esso abbia al suo inter-no modalità di funzionamento appositamente nascoste 48. Se una funzio-nalità non è graficamente visibile all’utente, questi difficilmente la scopri-rà, soprattutto se ha a disposizione esclusivamente una forma di rappre-sentazione del software come quella fornita nel Cloud.

Nel FLOSS, invece, la disponibilità pubblica del codice sorgente fornisce una elevata garanzia di assenza di backdoor. Il codice è infatti soggetto alla “peer review” di sviluppatori di tutto il mondo. Tutti i par-tecipanti ad un dato progetto valutano in tempo reale i cambiamenti ef-fettuati al software e spesso effettuano anche un’analisi completa della si-curezza dell’intera base di codice. Potrebbe mai passare inosservato un problema grave in un progetto di FLOSS, con numerosi sviluppatori che condividono e rivedono il codice e tutti i suoi cambiamenti?

5. I reati informatici

I “reati informatici”, ovvero i reati che hanno quale bene giuridico di attacco la sicurezza dei sistemi informativi e della rete (compresi i per-sonal computer), trovano negli ambienti del Cloud un campo d’azione

48 È ormai celebre la “backdoor” che ha accompagnato per oltre quattro anni la componente server di Frontpage 98, un prodotto di Microsoft; la “backdoor” rendeva possibile a chiunque l’accesso a un web server che utilizzasse le estensioni di pubblica-zione Frontpage. Addirittura nel codice della “backdoor” fu ritrovata la frase “Netsca-pe engineers are weenies!” chiaramente introdotta da un programmatore Microsoft per schernire i concorrenti di Netscape. Cfr. Joe Wilcox, in “Microsoft secret file could allow access to Web sites”, articolo disponibile alla pagina http://news.cnet.com/2100-1001-239273.html.

248

Guglielmo Troiano

particolarmente agile. La materia è quindi senz’altro pertinente ma, data la sua complessità, esaminarla anche solo sommariamente in questo con-testo è inopportuno 49. Occorre quindi circoscrivere l’analisi ed esaminare alcuni aspetti che con il Cloud si rendono evidenti più che in altri conte-sti in cui generalmente sono commessi i “reati informatici” 50.

«Nel cyberspazio i tradizionali confini degli Stati, se vengono azzera-ti durante l’azione informatica posta in essere dal soggetto agente, riaffiorano successivamente laddove si tenti di ricostruire il percorso a ritroso alla ricer-ca di tracce digitali eventualmente lasciate dall’autore» 51. Con il Cloud, la determinazione del locus commissi delicti e, in conseguenza, l’attribuzione della relativa competenza giurisdizionale, risulta più difficoltosa che mai.

Il principio che nel nostro ordinamento interviene per risolvere le problematiche ora accennate è contenuto nell’art. 6 del c.p., principio di territorialità (accennato nel par. 2). Questo stabilisce che la legge italiana si applica a chiunque commetta un reato la cui azione (o l’omissione) è avvenuta in tutto o in parte nel territorio dello Stato, ovvero, si è ivi veri-ficato l’evento che è la conseguenza dell’azione (od omissione).

Applicando questi criteri 52, normalmente, il luogo di immissione dei dati sul server del fornitore determinerebbe il luogo dell’azione, oppu-re, al contrario, il luogo della ricezione degli stessi da parte dei destinata-ri determinerebbe il luogo dell’evento. Il server è normalmente “statico”, oltre che “passivo”. In sostanza, il dato resta latente (memorizzato) sino a quando un terzo non lo richiede. Quindi, l’azione di immissione dei

49 Trattazioni esaustive e dogmatiche sui reati informatici possono essere rinvenu-te in molti testi, tra i quali si segnalano: Carlo Sarzana di S. Ippolito (a cura di), in “Infor-matica, internet e diritto penale”, Giuffrè, terza edizione, 2010; G. Ziccardi e L. Luparia, in “Investigazione penale e tecnologia informatica”, Giuffrè, 2007; M. Cuniberti, G. B. Gallus e F. P. Micozzi, in “I nuovi reati informatici”, Giappichelli, 2010.

50 I reati previsti espressamente dal D.Lgs. 196/2003 (Codice Privacy) saranno esplorati nei paragrafi seguenti.

51 Cfr. F. Cajani, in “La convenzione di Budapest nell’insostenibile salto all’indie-tro del Legislatore italiano, ovvero: quello che le norme non dicono …”, Ciberspazio e Diritto, vol. 11, n. 1, marzo 2010.

52 A livello internazionale ricalcano questi criteri le teorie del “no server, no law” e “no server, but law” per cui, si applica la legge del luogo in cui il server, che contiene i dati, è situato o, invece, si prescinde dal luogo in cui è situtato il server, applicando la legge del luogo in cui il servizio viene offerto.

249


dati da parte dell’utente corrisponde alla determinazione del luogo dell’a-zione, mentre la richiesta degli stessi da parte di un terzo, corrisponde al luogo dell’evento. Con il Cloud, invece, i server hanno natura “dinami-ca”. Come precisato in premessa, i dati e, in generale, le risorse informa-tiche, possono essere duplicate su diversi server e utilizzate a seconda del-le esigenze di ottimizzazione delle stesse. In conseguenza, appare impos-sibile stabilire in concreto l’immissione e la memorizzazione dei dati, per cui, troverebbe applicazione concreta solo il criterio che determina il locus commissi delicti in relazione al luogo dell’evento, quindi al luogo in cui il terzo soggetto richiede i dati 53.

A quanto detto sinora si sovrappongono poi tutte le problemati-che strettamente legate all’attività d’indagine. I principi 54 ideati e svi-luppati dalla Computer Forensics 55 per la gestione del c.d. “reperto in-formatico”, già di difficile attuazione su computer facilmente repe-ribili, per esempio, presso il domicilio dell’indagato o in un data cen-ter presente sul territorio nazionale, sono sostanzialmente inapplicabi-li al Cloud. Infatti, quasi mai sarà possibile effettuare accertamenti ur-genti sui server per procedere, eventualmente, ad un sequestro proba-

53 È da rilevare che la Suprema Corte ha recentemente affermato che, nella dif-famazione online, la competenza è ricavabile dal domicilio dell’imputato. Cfr. Corte di Cassazione, Sentenza del 15 marzo 2011, n. 16307: “Rispetto all’offesa della reputazione altrui realizzata via internet, ai fini dell’individuazione della competenza, sono inutilizzabi-li, in quanto di difficilissima, se non impossibile individuazione, criteri oggettivi unici, quali, ad esempio, quelli di prima pubblicazione, di immissione della notizia nella rete, di accesso del primo visitatore. Per entrambe le ragioni esposte non è neppure utilizzabile quello del luogo in cui a situato il server (che può trovarsi in qualsiasi parte del mondo), in cui il provider alloca la notizia. Ne consegue che non possono trovare applicazione né la regola stabilita dall’art. 8 cod. proc. pen. né quella fissata dall’art. 9, comma 1, cod. proc. pen., ma è necessario fare ri-corso ai criteri suppletivi fissati dal secondo comma del predetto art. 9 cod. proc. pen., ossia al luogo di domicilio dell’imputato”.

54 I principi di cui si tratta sono: i) rapidità – i reperti vanno acquisiti nel minor lasso di tempo possibile dall’evento che si vuol ricostruire; ii) congelamento/time stamp – gli hard disk, i device contenenti informazioni che potrebbero essere rilevanti e quant’al-tro vanno “congelati”, ossia ne va impedita la modifica o alterazione; iii) chain of custo-dy – deve essere garantita e documentata la corretta gestione del reperto dal momento dell’acquisizione sino alla presentazione in giudizio; iv) controllabilità e ripetibilità – ogni attività compiuta sul reperto deve essere ripetibile da parte dei periti o consulenti tecnici.

55 La scienza che, in ambito informatico, studia il valore processuale di determina-ti accadimenti ai fini della costituzione di fonti di prova.

250

Guglielmo Troiano

torio 56 dei dati in essi contenuti e “congelarli” come fonti di prova sino ad un eventuale giudizio o istanza di restituzione. Come detto in pre-cedenza, il Cloud è geneticamente “dinamico” per cui i dati sono au-tomaticamente spostati, replicati, cancellati e modificati in brevissi-mo tempo e senza preavviso. Anche i più “snelli” ed efficaci mezzi di ricerca della “prova informatica” come le perquisizioni 57, le ispezioni 58 e le intercettazioni 59 sopperiscono alla estrema volatilità dei dati nel Cloud.

Gli inquirenti dovranno confrontarsi con la individuazione geogra-fica del dato, dovranno cioè riuscire a sapere in quale (o quali) data center esso è memorizzato e, successivamente, verificare che lo stesso non sia sta-to alterato. In seguito, sarà possibile verificare se il data center è sottoposto alla sovranità di uno stato che consente il dispiegamento di attività d’inda-gine previste dal nostro sistema processuale e che, infine, consenta di pro-cedere secondo le formalità previste dall’art. 727 del c.p.p. (Trasmissione di rogatoria ad autorità straniere) 60. I poteri di intervento del pubblico mi-nistero procedente, nonostante sia riconosciuta la sua competenza, posso-no essere quindi vanificati in concreto o essere, comunque, molto limitati.

Strumento senz’altro utile alle “investigazioni digitali” è costituito dai dati del traffico telematico a disposizione dei fornitori di servizi di co-

56 Ex art. 253 bis del c.p.p.57 Ai sensi dell’art. 247, c. 1 bis, del c.p.p., come modificato dall’art. 8 della Legge

48/2008 in attuazione della Convenzione di Budapest: “Quando vi è fondato motivo di ri-tenere che dati, informazioni, programmi informatici o tracce comunque pertinenti al reato si trovino in un sistema informatico o telematico, ancorché protetto da misure di sicurezza, ne è disposta la perquisizione, adottando misure tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione”.

58 Ai sensi dell’art. 244, c. 2, secondo periodo, del codice di procedura penale, come modificato dall’art. 8 della Legge 48/2008 in attuazione della Convenzione di Bu-dapest sono aggiunte le seguenti parole: “[…] anche in relazione a sistemi informatici o te-lematici, adottando misure tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione”.

59 Ex art. 266 bis del c.p.p.60 “[…] infatti quando la Polizia Giudiziaria italiana va a notificare a Google o a

Microsoft (entrambe aventi, quali filiali, una società di diritto italiano con sede in Milano) il decreto del Giudice che autorizza l’intercettazione, qual è la risposta tipica che viene loro for-nita? “Spiacenti, in nostri server stanno in America … quindi chiedete l’intercettazione con una rogatoria!”. Cfr. F. Cajani, op. cit.

251


municazione elettronica (c.d. “file di log”) ma la relativa disciplina 61 non sembra applicabile, prima facie, ai fornitori di servizi di Cloud quanto, piuttosto, ai gestori del servizio di connettività tra il client dell’utente ed i server del fornitore di Cloud.

Con la Convenzione del Consiglio d’Europa di Budapest sulla cri-minalità informatica del 23 novembre 2001 (Convenzione di Budapest), si sarebbero dovute creare le condizioni ideali affinché le cyber-investiga-zioni di natura internazionale (per lo meno tra i paesi aderenti alla con-venzione) avrebbero potuto portare a risultati concreti e in breve tempo ma, il ritardo di sette anni 62 dalla ratifica, ha vanificato qualsiasi portata realmente innovativa e, in realtà, i principi 63 della Convenzione sono an-cora in stato di implementazione più che di attuazione 64. Tra questi, in primis, quello previsto dall’art. 16 “Conservazione rapida di dati infor-matici immagazzinati” (c.d. “quick freeze” 65) che potrebbe consentire alle competenti autorità di ordinare o ottenere in altro modo la protezione ra-pida di specifici dati informatici, inclusi i dati sul traffico, che sono stati conservati attraverso un sistema informatico, in particolare quando vi è

61 Contenuta nell’art. 132 del Codice Privacy.62 Avvenuta solo nel 2008 con la Legge 18 marzo 2008 n. 48.63 L’art. 19 della Convenzione di Budapest si occupa della perquisizione dei dati

informatici immagazzinati in sistemi informatici o in supporti per la conservazione di dati informatici. In particolare è previsto che i Paesi aderenti debbano adottare tutte le misure che si dovessero rendere necessarie per consentire la perquisizione o, comunque, l’acces-so ad un sistema informatico nonché ai supporti di memorizzazione dei dati stessi. Con-dizione necessaria perché venga posta in essere quest’attività di perquisizione o di accesso è che la “fonte di prova” si trovi nel territorio dello stato che procede. In tal guisa, diver-si articoli del c.p.p. (artt. 244, 247, 248, 254, 256, 259, 260, 352, 353 e 354), così come l’art. 132 del Codice Privacy, sono stato modificati in virtù dell’obbligo del fornitore, o dell’operatore di servizi informatici o telematici, ad ottemperare senza ritardo agli ordini dell’autorità giudiziaria fornendo immediatamente all’autorità richiedente l’assicurazio-ne dell’adempimento.

64 Per approndimenti, cfr. F. Cajani, op. cit.65 “Data preservation (“quick freeze”) is the preservation of specific traffic data of an

identifiable internet user for a specific criminal investigation for a limited period of time. It re-fers to data that already exists in a stored form and that must be protected from anything that would cause its current quality or the condition to change or deteriorate. It requires that must be kept safe from modification, deterioration or deletion.”. Cfr. Hamid Jahankhani et alt., in “Handbook of Electronic Security and Digital Forensics”, World Scientific.

252

Guglielmo Troiano

motivo di ritenere che i dati informatici siano particolarmente vulnerabi-li e soggetti a cancellazione o modificazione.

Si aggiunga, infine, un’altra delle maggiori peculiarità dei “crimini informatici” che con il Cloud si amplifica: l’anonimato dell’autore di un reato, quindi dell’utente del Cloud. L’attuale assetto normativo naziona-le e comunitario non prevede, infatti, alcun obbligo di identificazione di un soggetto che stipula un contratto di fornitura di servizi con un inter-net provider, tanto più, nello specifico, con un Cloud provider. Il fornito-re potrebbe accertarsi della identità dell’utente prima della sottoscrizione del contratto anche con semplici sistemi, come per esempio lo scambio di comunicazioni tra indirizzi di posta elettronica certificata (anche se, in effetti, ciò avrebbe valore solo in Italia), ma questa o altre attività di con-trollo, anche se efficaci, difficilmente saranno adottate dal Cloud provider in quanto non obbligatorie ex lege.

6. L’illecito trattamento di dati

Le ipotesi di reato contenute nel D.Lgs. 196/2003 (Codice Priva-cy) sono contemplate agli artt. 167-170. Escludendo le più improbabi-li dell’art. 168 (Falsità nelle dichiarazioni e notificazioni al Garante) e dell’art. 170 (Inosservanza dei provvedimenti del Garante), ci soffermere-mo sull’art. 169 (Misure di sicurezza), ovvero l’illecito penale in cui può incorrere “chiunque, essendovi tenuto” 66 nel caso in cui non abbia adottato le misure minime di sicurezza e sull’art. 167 (Illecito trattamento di dati), reato che può essere invece commesso da “chiunque” 67. L’illecito di cui

66 L’art. 169 del Codice Privacy con “chiunque, essendovi tenuto” lascia intendere che l’illecito sia da considerarsi “reato proprio” in quanto ne potranno rispondere tutti, e solo, i soggetti tenuti all’adozione delle misure minime di sicurezza, quindi, indifferente-mente, titolare, responsabile e incaricato al trattamento dei dati.

67 L’illecito di cui all’art. 167 del Codice Privacy è definito come “reato comune” in quanto il soggetto attivo può essere “chiunque”. L’articolo infatti così recita: “Salvo che il fatto costituisca più grave reato, chiunque, al fine di trarne per sè o per altri profitto o di re-care ad altri un danno, procede al trattamento di dati personali in violazione di quanto dispo-sto dagli articoli 18, 19, 23, 123, 126 e 130, ovvero in applicazione dell’articolo 129, è pu-nito, se dal fatto deriva nocumento, con la reclusione da sei a diciotto mesi o, se il fatto consiste nella comunicazione o diffusione, con la reclusione da sei a ventiquattro mesi.”

253


all’art. 169 sarà trattato nel paragrafo seguente congiuntamente alle mi-sure di sicurezza previste dagli artt. 31 e 33 del Codice Privacy.

L’illecito trattamento di dati può essere scomposto e analizzato in tre elementi: il soggetto attivo, l’elemento soggettivo e l’elemento ogget-tivo.

In relazione al primo elemento occorre considerare che, nonostan-te il soggetto attivo possa essere considerato “chiunque”, le maggiori re-sponsabilità penali sono generalmente riconducibili a titolare e responsa-bile del trattamento in funzione del loro potere di controllo sui dati. Nel Cloud non è però agevole ricondurre queste due categorie tradizionali, di titolare e responsabile, rispettivamente all’utente ed al fornitore del servi-zio. Infatti, il titolare si configura come il soggetto preposto ad ogni po-tere decisionale con riguardo alle finalità ed alle modalità del trattamen-to ed il responsabile come il soggetto a cui il primo delega alcune specifi-che operazioni. Il fornitore è mero custode delle banche dati degli uten-ti. Non è individuabile come titolare del trattamento ma non potrebbe nemmeno essere definito come responsabile, dato che per il tipo di servi-zio reso si configura un grado di autonomia incompatibile con il ruolo di semplice esecutore delle istruzioni impartite dal titolare, che è invece l’u-tente nei confronti dei dati di terzi. In definitiva, all’utente andrebbero ricondotte entrambe le figure ma, per un’attribuzione formale maggior-mente realistica, occorrerebbe intervenire con un atto normativo diretto a ridistribuire le responsabilià tra i diversi soggetti, per esempio attraver-so l’introduzione di una speciale figura di responsabile, che sia contem-poraneamente in grado di offrire agli utenti particolari garanzie in termi-ni di affidabilità e di assumersi in prima persona specifiche responsabilità.

L’elemento soggettivo s’identifica nel dolo specifico, ovvero in una specifica finalità che può essere il “profitto”, per sè o per altri, o il “dan-no”, nei confronti di altri. Il concetto di profitto, a differenza di quello di lucro, appare piuttosto ampio dovendo essere inteso come qualsiasi utili-tà o vantaggio, ovvero pregiudizio, anche di natura non patrimoniale, es-sendo sufficiente che l’agente abbia operato per il soddisfacimento di un qualsiasi interesse, perfino di natura psichica.

Infine, elemento senz’altro più importante di tutti, l’elemento oggettivo, ovvero la violazione, che può essere solo degli articoli cita-ti nell’art. 167 (artt. 18, 19, 23, 123, 126, 129 e 130). Di sicuro rilevo

254

Guglielmo Troiano

nell’ambito del Cloud si può osservare più approfonditamente la viola-zione dell’art. 23 (Consenso).

L’art. 23 prevede che soggetti privati ed enti pubblici economici pos-sano trattare dati personali solo con il consenso espresso dell’interessato (se si tratta di dati sensibili il consenso dev’essere dato per iscritto), salvo che ri-corra una delle ipotesi di esclusione dell’art. 24. Tra queste esclusioni emer-ge senza dubbio l’eccezione di cui alla lettera b) dell’articolo succitato, per cui, il trattamento può essere effettuato senza consenso quando “è necessa-rio per eseguire obblighi derivanti da un contratto del quale è parte l’interessa-to o per adempiere, prima della conclusione del contratto, a specifiche richieste dell’interessato”. Questa esimente è molto spesso trascurata ma è in realtà tra le più importanti in quanto quasi tutti i rapporti giuridici, senz’altro quello tra fornitore di Cloud e utente, si costituiscono sulla base di un contratto. Motivo per cui, il fornitore non ha necessità di recepire il consenso dell’u-tente ma avrà l’obbligo di portare a conoscenza di quest’ultimo le finalità e modalità del trattamento e tutte le informazioni che l’art. 13 del Codice Privacy indica (attraverso l’Informativa o “Privacy Policy”).

Ciò premesso, ci si può porre il seguente quesito: se il fornitore di Cloud non si limitasse solo alla memorizzazione dei dati dell’utente ma, con sistemi più o meno automatizzati, dovesse anche effettuare un nuo-vo trattamento dei dati di cui, appunto, decide diverse finalità e modalità non previste nell’informativa fornita inizialmente all’utente?

Questo dubbio è stato sollevato nel celebre caso “Google/Vivi-down” in cui quattro dirigenti, di Google, sono stati condannati 68, ai sen-si dell’art. 167 ivi richiamato, per violazione dell’art. 23 del Codice Pri-vacy (Consenso), con l’aggravante del fine di lucro. In sostanza, nel caso in esame è stato evidenziato che rendendo titolari dei dati di terzi solo co-loro che effettuano l’immissione dei dati sul server (un video nel caso di specie), significa mantenere una situazione di evidente incertezza in caso di violazione della privacy di terzi i cui dati sono trattati 69. Escludendo gli utenti dei servizi di Cloud che agiscono per lo più per fini persona-li e a cui, pertanto, non si dovrebbero applicare le principali disposizioni

68 Con la Sentenza del Tribunale di Milano (Sez. Quarta Penale) del 24 febbra-io 2010 n. 1972.

69 Cfr. L. Bolognini, D. Fulco e P. Paganini (a cura di), op. cit., par. 4.6.

255


previste dal Codice Privacy (per effetto della c.d. “esenzione domestica” prevista dall’art. 5 c. 3 del Codice Privacy), il problema sussiste senz’altro per gli utenti che utilizzano i servizi di Cloud – come appunto tutti quelli di Google: Gmail, Docs ecc. – per fini professionali trattando, indubbia-mente, dati di terzi sia personali che sensibili.

In questi casi, chi dev’essere considerato titolare del trattamento? Il fornitore del servizio è titolare del trattamento rispetto all’utente che im-mette i contenuti e quest’ultimo è titolare del trattamento rispetto ai dati di terzi soggetti?

È chiaro e fuori di dubbio che il titolare del trattamento debba con-siderarsi sempre e solo il soggetto che “tratta” i dati, volta per volta, ma risulta corretto ipotizzare che in questi casi si configura un duplice e diffe-rito trattamento? Chi effettua la prima memorizzazione dei dati dovreb-be essere titolare degli stessi e, successivamente, chi fornisce lo spazio nel Cloud potrebbe esserlo per i dati memorizzati e sui quali viene effettuato un nuovo trattamento. Ma è proprio così?

A rigor di logica, consentire ad un soggetto la pubblicazione di dati di terzi significa, anzitutto, eseguire un trattamento di dati personali raccol-ti presso terzi. Google indicizza a proprio piacimento 70 i contenuti immes-si dagli utenti e li rielabora per fini pubblicitari e di marketing effettuando, di fatto, un nuovo trattamento di cui si decidono le (nuove) finalità e mo-dalità 71. In casi come questo, il Codice Privacy impone che si chieda il con-senso all’interessato. Per i dati comuni è sufficiente che, appena possibile, si dia l’informativa all’interessato o ai suoi rappresentanti, per i dati sensibili è anche richiesto il consenso scritto da parte dello stesso interessato.

La questione è controversa e merita di essere approfondita in sepa-rata sede.

70 Attraverso algoritmi programmati secondo logiche e direttive commerciali. Vedi anche nota n. 9.

71 In tal senso, nelle indagini del caso “Google/Vividown”, i PM hanno ipotizzato nei confronti di Google un quarto genus di prestatore, ovvero di “hoster attivo”, in quan-to la stessa indicizza e organizza le informazioni che gli utenti immettono nei suoi siste-mi. Tipologia di prestatore, tuttavia, non prevista espressamente dal Decreto legislativo 9 aprile 2003, n. 70 (Attuazione della direttiva 2000/31/CE relativa a taluni aspetti giu-ridici dei servizi della società dell’informazione, in particolare il commercio elettronico, nel mercato interno).

256

Guglielmo Troiano

7. Le misure di sicurezza

L’utente di servizi di Cloud sarà sempre costantemente afflitto dal-le domande “chi può accedere ai miei dati?” e “cosa viene fatto con i miei dati?”, piuttosto che dalla domanda “dove sono i miei dati?”.

La sicurezza dei dati assume nel Cloud una importanza fondamen-tale e dev’essere analizzata sulla base di una duplice considerazione, ovve-ro, in relazione alla sua visione “statica”, che comprende essenzialmente la protezione e la archiviazione/conservazione del dato sulle memorie dei computer, e “dinamica”, che riguarda il dato in transito su reti informa-tiche più o meno sicure 72.

È superfluo ma giova ribadirlo anche a questo punto del discorso. Nel Cloud i dati possono essere trasferiti e ritrasferiti un numero inde-finito di volte attraverso le reti informatiche, motivo per cui il fornitore dovrebbe adottare non solo le misure di sicurezza atte a proteggere i si-stemi (i data center) da eventuali accessi abusivi esterni ma dovrebbe assi-curarsi anche che i dati vengano trasmessi attraverso canali sicuri, sia nel flusso di comunicazione tra il client dell’utente ed i server del fornitore che tra i suoi data center in Cloud 73.

In relazione invece alla visione statica dei dati si possono identifi-care le previsioni di cui agli artt. 31, 33 e 34 del Codice Privacy, che sta-biliscono le misure minime (art. 33) ed idonee (art. 31) di sicurezza che devono essere adottate nel trattamento. Se poi quest’ultimo avviene con strumenti elettronici 74, come nel caso del Cloud, devono essere adotta-

72 Cfr. P. Perri, Protezione dei dati e nuove tecnologie, Giuffrè Editore, 2007.73 In Gmail viene contrattualmente assicurata una comunicazione protetta solo tra

il browser (o il client di posta elettronica) dell’utente ed i server di Google “[…] messag-es are encrypted during their transmission from your web browser to Google’s servers, which helps protect your data from being snooped by third parties if you’re using an unsecured Inter-net connection.”. Cfr. "FAQ about Gmail, Security & Privacy" in http://mail.google.com/support/bin/answer.py?hl=en&answer=1304609. In questo senso l’interprete potrebbe intervenire estendendo anche al Cloud provider l’applicazione delle disposizioni di cui all’art. 32 del Codice Privacy che fa espressamente riferimento ai fornitori di servizi di co-municazione elettronica e, in conseguenza, come già precedentemente accennato nel par. 5, estendere l’applicazione anche dell’art. 132 del Codice Privacy (sulla data retention).

74 Ai sensi dell’art. 2 c. 3 lett. b) del Codice Privacy gli strumenti elettronici sono da considerare “gli elaboratori, i programmi per elaboratori e qualunque dispositivo elettro-nico o comunque automatizzato con cui si effettua il trattamento”.

257


te, ai sensi dell’art. 34, alcune specifiche misure minime con le modali-tà tecniche di attuazione di cui all’Allegato B dello stesso Codice Privacy.

La disposizione di cui all’art. 31 si riferisce alle c.d. misure “idonee e preventive” che devono essere adottate al fine di ridurre al minimo i ri-schi di distruzione o perdita, anche accidentale, dei dati, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta. Anzitutto, occorre precisare che, diversamente dalle misure minime di cui all’art. 33, le misure “idonee e preventive”, si configurano come misure da adottare tenendo conto delle conoscenze acquisite in base al progresso tecnologico, oltre che della natura dei dati oggetto di tratta-mento e delle specifiche caratteristiche del trattamento (ossia se effettuato con strumenti elettronici o meno). Le misure idonee, infatti, diversamen-te dalle misure minime, non sono predefinite dalla legge ma legate all’evo-luzione tecnologica, obbligando quindi il fornitore ad un’aggiornamento costante dei sistemi. Inoltre, proseguendo nella disamina dell’art. 31, oc-corre evidenziare che il fornitore è obbligato ad adottare non solo i siste-mi di protezione che possano evitare eventuali accessi abusivi dall’esterno (come per es. i “firewall”) ma anche i sistemi che gli consentano di moni-torare gli accessi ai dati effettuati all’interno della rete, ciò al fine di veri-ficare che soggetti incaricati non effettuino trattamenti non consentiti o non conformi alle finalità comunicate all’utente (come per es. la memoriz-zazione e l’analisi sistematica dei “file di log” della rete interna).

Infatti, l’utente può essere diffidente del fornitore ma lo sarà ancor di più dei soggetti da lui preposti 75. Avrà quindi il timore che l’accesso abusivo possa provenire proprio dall’interno del sistema informativo che custodisce i suoi dati per motivi estranei agli adempimenti contrattuali, quindi previsti nell’informativa. L’utente comunque timoroso, avendone la possibilità 76, potrebbe eliminare ogni perplessità rendendo illeggibili i

75 Come per esempio gli amministratori di sistema, oggetto di uno specifico prov-vedimento dell’Autorità garante per la protezione dei dati personali, “Misure e accorgimen-ti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle at-tribuzioni delle funzioni di amministratore di sistema - 27 novembre 2008”, G.U. n. 300 del 24 dicembre 2008, in http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499.

76 Con le recenti evoluzioni della “crittografia omomorfica” i sistemi saranno in grado di eseguire operazioni sui database di dati senza mai doverli decifrare. I dati reste-rebbero quindi sempre crittografati e solo l’utente potrebbe decifrarli.

258

Guglielmo Troiano

dati attraverso la cifratura degli stessi 77 ed estromettere chiunque dall’ac-cesso abusivo.

L’art. 34 prescrive, invece, le specifiche misure minime da adottare se il trattamento avviene con strumenti elettronici: a) autenticazione in-formatica; b) adozione di procedure di gestione delle credenziali di au-tenticazione; c) utilizzazione di un sistema di autorizzazione; d) aggiorna-mento periodico dell’individuazione dell’ambito del trattamento consen-tito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici; e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a deter-minati programmi informatici; f) adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi; g) tenuta di un aggiornato documento programmatico sulla sicurezza; h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale ef-fettuati da organismi sanitari.

Nel Cloud sono rilevanti più di tutte le previsioni delle lettere e) ed f). La prima ricalca sostanzialmente i contenuti dell’art. 31 ivi richiama-to con riguardo all’adozione di sistemi di protezione dei dati. La lettera f) prevede invece l’adozione di procedure che per il fornitore di Cloud si traducono in garanzia di ripristino immediato, oltre che dei dati, dell’am-biente informatico di sviluppo e produzione (nell’IaaS di sicuro presen-ti) che sia stato irreversibilmente compromesso attraverso, per esempio, tecniche di “disk image”.

In conclusione, il fornitore di Cloud si potrà valutare agevolmente attraverso la sua solidità finanziaria ed il grado di trasparenza e di sicurezza garantito dalle policy aziendali che assicurino, di conseguenza, l’adozione di adeguate misure di sicurezza dei sistemi informativi, oltre a strumenti negoziali con capienti garanzie patrimoniali nonché obblighi di notifica-zione per il caso di perdita o di accesso non autorizzato ai dati affidati in custodia. Si potrà così verificare se è anche in possesso di certificazioni 78

77 Operazione che, tra l’altro, risulterebbe obbligatoria per gli organi sanitari se si tratta di dati idonei a rivelare lo stato di salute o la vita sessuale dell’interessato ex art. 34 lett. h) del Codice Privacy.

78 Come ad esempio del diffusissimo Standard ISO/IEC 27001:2005 che fornisce i requisiti di un Sistema di Gestione della Sicurezza delle Informazioni, in particolare per gli aspetti della sicurezza fisica, logica ed organizzativa.

259


attinenti all’ambito dei servizi offerti, se impiega personale altamente qua-lificato e certificato, se le infrastrutture informatiche e di comunicazione sono adeguate per dimensione e quantità e se è disponibile ad assumersi eventuali responsabilità derivanti da falle nella security. Inoltre, nei model-li contrattuali che utilizza, dovrebbe sempre indicare precisi parametri che permettano all’utente di misurare in ogni momento le sue prestazioni e le misure di sicurezza garantite (c.d. Service Level Agreements).

Come accennato nel paragrafo precedente, la violazione delle disposi-zioni ora analizzate sulle misure di sicurezza, sono sanzionate ai sensi dell’art. 169 del Codice Privacy 79. L’illecito di cui si tratta si consuma nel momen-to in cui inizia un trattamento di dati non accompagnato dalle misure ido-nee di sicurezza che, in questo senso, devono essere “preventive”. Sul mo-mento consumativo del reato, non ci sono dubbi, diversamente, risulta problematica l’individuazione delle condotte attraverso le quali l’illecito si può realizzare. Queste ultime, infatti, sono riconducibili a tutte le misure di sicurezza specificamente contenute nell’Allegato B del Codice Privacy.

8. Il trasferimento dei dati extra UE

I trasferimenti di dati tra soggetti all’interno dell’UE non incontrano restrizioni di sorta dal momento che il settore è regolamentato dalla Diret-tiva 95/46/CE, con le legislazioni nazionali ispirate ai medesimi principi. In via residuale e straordinaria, il Garante Privacy può limitare quei trasfe-rimenti effettuati al solo fine di eludere le disposizioni in materia.

I trasferimenti di dati verso paesi non facenti parte dell’UE, invece, sono generalmente vietati, ai sensi dell’art. 45 del Codice Privacy, quan-do il paese di destinazione non assicura un adeguato livello di tutela del-le persone.

Gli USA, per esempio, non rientrano nella categoria di quei paesi che offrono adeguate garanzie, per cui, operano in regime di Safe Har-bor 80, ovvero possono offrire garanzie contrattuali adererendo a strumen-

79 Per un approfondimento sull’illecito di cui all’art. 169 del Codice Privacy, cfr. P. Perri, op. cit., parr. 4.5 e ss.

80 È possibile verificare l’adesione di una impresa ai principi del Safe Harbor at-traverso il data base del Dipartimento del Commercio degli USA disponibile alla pagina https://safeharbor.export.gov/list.aspx.

260

Guglielmo Troiano

ti volontari che assicurano – come richiesto dalla norma – una sufficien-te protezione.

In altre parole, il trasferimento dei dati all’esterno dell’UE può av-venire solo con paesi che offrono una garanzia di protezione dei dati equi-valente a quella europea. Il trasferimento è dunque vietato se, prima di procedere allo stesso, non vengano adottate adeguate salvaguardie, anche di natura contrattuale, per la protezione dei dati personali.

Infatti, le clausole contrattuali tipo 81 per il trasferimento di dati da un Titolare nell’UE ad un Responsabile extra UE, al momento, sem-brano essere il solo espediente che si adatta alle specifiche esigenze del Cloud. Altri strumenti alternativi appaiono difficilmente adattabili: le Binding Corporate Rules, ovvero le regole che disciplinano i trasferimen-ti di dati tra società appartenenti allo stesso gruppo, per esempio, non sono applicabili se non all’interno di un medesimo gruppo societario ed i principi del Safe Harbor‚ che regola i trasferimenti di dati verso gli Stati Uniti, non sono estensibili ad altri paesi extra UE.

Al di fuori delle tutele di natura contrattuale, quindi, attualmente solo Svizzera, Canada, Argentina, Isola di Guernsey, Isola di Man, Isola di Jersey, Isole Far Oer, Andorra, e USA (ma limitatamente alle imprese che aderiscono al Safe Harbor) rientrano tra i paesi che secondo la nostra normativa offrono tutele adeguate.

Appare quindi necessaria un’accurata selezione del fornitore attra-verso una chiara indicazione da parte dello stesso della collocazione geo-politica della rete di data center ove i dati potrebbero essere ospitati, dato che, prima di inviare i dati personali del cliente in un luogo indefinito della “nuvola”, occorrerà sempre assicurarsi che, oggettivamente, il trasfe-rimento dei dati da paese a paese avvenga nel rispetto delle garanzie mini-me di sicurezza previste dalla legge europea, quindi italiana.

Se quanto detto sinora costituisce la regola generale, numerose sono le eccezioni previste dagli articoli 43 e 44 del Codice Privacy. Tra queste, è senz’altro rilevante la lettera a) dell’art. 43 che consente sempre il trasferi-mento in paesi extra UE se l’interessato ha manifestato il proprio consen-so, ovvero, se si tratta di dati sensibili, lo ha manifestato in forma scritta.

81 Previste dalla Decisione della Commissione Europea del 5 febbraio 2010 n. 2010/87/UE, recepita dal Garante per la Protezione dei Dati Personali con Autorizzazio-ne Generale n. 35 del 27 maggio 2010.

261


9. Conclusioni

Quello del Cloud è un tema senza dubbio complesso. Di esso si è parlato e scritto quasi ovunque. Ha dato titoli a conferenze, seminari, ri-viste, articoli, guide ma i legislatori e le istituzioni sono ancora confusi su ciò che realmente può significare per la società dell’informazione. Come accennato in premessa, in Italia solo il Garante Privacy lo ha recentemen-te preso in considerazione, tra l’altro, in un documento di semplice na-tura informativa.

D’altronde, la stessa rete internet ed i suoi principali player (gli In-ternet Service Provider), che rappresentano le condicio sine qua non del Cloud, non godono di buona visibilità nel nostro Paese e alcuni recenti provvedimenti regolamentari (come quello dell’AGCOM, n. 398/2011, sull’enforcement della tutela del diritto d’autore), disegni di legge (come il DDL n. 1415 sulle intercettazioni telefoniche e telematiche) e sentenze (come la Sentenza del Tribunale di Milano del 24 febbraio 2010 n. 1972, meglio conosciuta come “Google-Vividown”, trattata nel par. 6) lo di-mostrano. Inoltre, lo stesso accesso alla rete internet, che consente la ma-teriale comunicazione tra l’utente ed il fornitore, è offerta a costi ancora troppo elevati e le aree geografiche collegate con linee veloci, come la fi-bra ottica o l’ADSL, corrispondono quasi tutte alle sole grandi città, la-sciando al resto del territorio le connessioni mobili UMTS/HSPA a cui, tra l’altro, fanno capo anche tutti i dispositivi evoluti (smartphone) di te-lefonia mobile i cui contenuti sono essenzialmente in Cloud.

Nonostante tutto, il Cloud non è da considerare l’ennesimo ambi-to tecnologico privo di regole e di cui si deve aver timore. Come visto, diversi istituti in materia civile e penale sono applicabili al Cloud, anche se non proprio de plano. De iure condendo, il Legislatore nazionale e pri-ma ancora quello comunitario, devono intervenire per affrontare organi-camente tutte le complicanze del Cloud. In particolare, risulterà neces-sario modificare e integrare al più presto alcune disposizioni nell’ambito della privacy e della data protection 82, interrogandosi, in primis, sulla op-

82 La Commissione Europea, a novembre 2010, ha manifestato l’intenzione di proporre un atto legislativo per la revisione dell’intero quadro giuridico in materia di protezione dei dati (Cfr. comunicato disponibile all’indirizzo http://ec.europa.eu/justice/news/consulting_public/0006/com_2010_609_it.pdf). Inoltre, la revisione della norma-

262

Guglielmo Troiano

portunità di individuare garanzie minime che dovrebbero essere offerte dai fornitori di servizi di Cloud, così come già avviene in altri settori re-golamentati 83.

Intanto, la certificazione della affidabilità del fornitore congiunta-mente ad un modello contrattuale ben strutturato, costituiscono le ne-cessarie attività da attuare al fine di creare affidamento negli utenti e far crollare il muro di resistenza dei soggetti più diffidenti nell’affidarsi alla “nuvola”.

In chiusura, si ritiene doveroso chiarire che Google, società più vol-te citata nell’articolo al fine di avere un confronto pratico, non è da con-siderarsi esempio negativo. Come affermato da essa stessa, il Cloud Com-puting è nel suo DNA 84 e la pletora di servizi che offre è tutti di tal spe-cie. Per questi motivi sarebbe stato innaturale non citarla. Al contrario, oltre al suo impegno nell’offerta di programmi con codice aperto e ispe-zionabile 85, sono degne di nota positiva le iniziative intraprese per infor-mare efficacemente gli utenti sui loro diritti e sulla possibilità di liberare 86 i propri dati quando si decide di abbandonare i suoi servizi di/in Cloud.

tiva sulla data protection è inserita anche nella Digital Agenda for Europe della stessa Com-missione Europea, cfr. “Action 12” in http://ec.europa.eu/information_society/news-room/cf/fiche-dae.cfm?action_id=170&pillar_id=43&action=Action%2012%3A%20Review%20the%20EU%20data%20protection%20rules.

83 Per esempio, nei confronti di tutte le imprese che forniscono servizi di comuni-cazione elettronica accessibili al pubblico regolamentati dalla Direttiva 2002/21/CE del Parlamento europeo e del Consiglio, del 7 marzo 2002.

84 Cfr. http://www.google.com/apps/intl/en/business/cloud.html#toc-cloud.85 Cfr. http://code.google.com/.86 Cfr. http://www.dataliberation.org/.

263


Abstract

The article deals with legal and technological issues related to cloud computing. The first part presents the main technical issues, placing the phenomenon of cloud computing in the daily technological framework. The central part of the study, on the other hand, deals with legal issues both from the point of view of the user of the service and from the point of view of the operator/provider. A part also investigates the issues of copyright and the discipline of contents, computer crimes, illegal tre-atment of data and the legislative regulation of the European Union.

In questo numero - In this issuePolitica dell’innovazione, democrazia elettronicae informatica giuridica

233 Profili civili e penali del cloud computing nell’ordinamento giuridico nazionale: alla ricerca di un equilibrio tra diritti dell’utente e doveri del fornitore Guglielmo Troiano

Privacy, sicurezza, data retention e sorveglianza globale

267 Analisi dello stato di protezione delle infrastrutture critiche attraverso il modello CHELPT e futuri sviluppi David Ward - Alessandro Lazari

Criminalità informatica e investigazioni digitali

289 Whistleblowing 2.0. Le “soffiate” tra opportunità di community etiche e problematiche giuridiche Alessandro Rodolfi

Diritti di libertà e dissidenza digitale

307 Tecniche di censura dei contenuti e diritti di libertà in Australia e Nuova Zelanda Diego Dimalta

321 Internet e diritti umani in Russia: il quadro politico e tecnologico Stefano Rossetti

331 Internet e diritti umani in Cina, Birmania e Iran: firewall di Stato, repressioni e resistenza digitale Silvia Scalzaretto

Ciberspazio e Diritto · 233 Ciberspazio e diritto 2011, Vol. 12, n. 3, pp. 233-263 Profili civili...

Documents

Transcript of Ciberspazio e Diritto · 233 Ciberspazio e diritto 2011, Vol. 12, n. 3, pp. 233-263 Profili civili...