Ciberspazio e Diritto Cyberspace and Law

Transcript

issn 1591-9544 - vol. 12 no. 3 november 2011
Ciberspazio e Diritto
Internet e le Professioni Giuridiche
Investigazioni Digitali
Rivista Trimestrale
estratto
offprint
Cyberspace and Law
Internet and Legal Practice
Digital Investigations
Quarterly Journal
Mucchi Editore
Ciberspazio e diritto 2011, Vol. 12, n. 3, pp. 233-263
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 1
Sommario: 1. Premesse. – 2. Ambiti contrattualistici, lex contractus e giurisdizione competente. – 3. Standard proprietari e “vendor lock-in”. – 4. Diritti d’autore, “licensing” e libertà dell’utente. – 5. I reati informatici. – 6.
L’illecito trattamento di dati. – 7. Le misure di sicurezza. – 8. Il trasferimento 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 indipendenti 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’Università degli Studi di Padova, è stato per diversi anni analista di sistemi informativi. Collabora con le cattedre di Informatica Giuridica e Informatica Giuridica Avanzata dell’Università 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 progettazione e realizzazione di hardware e software per la gestione dei dati. Il NIST (National Institute of Standard and Technology) dello U.S. Department of Commerce ha fornito una definizione che risulta spesso adottata (http://csrc.nist.gov/publications/drafts/800-145/DraftSP-800-145_cloud-definition.pdf). In buona sostanza, il termine cloud computing è utilizzato oggi per indicare le risorse informatiche (di un computer) collocate in più luoghi della 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 personali in Italia: una sfida d’esempio per l’Europa”, in Diritto, Economia e Tecnologie della Privacy, Istituto Italiano Privacy, ottobre 2011 e gli atti della conferenza “Cloud Computing e Privacy”, E-Privacy 2011 in http://e-privacy.winstonsmith.org/interventi.html.
233
Guglielmo Troiano
dell’informatica» 3. Negli anni ’80, quando i computer domestici non avevano risorse sufficienti per poter custodire ed elaborare tante informazioni, i dati venivano memorizzati e processati attraverso i più potenti sistemi 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, attraverso 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’utilizzatore informatico iniziò a custodire i dati sui supporti presso il proprio
domicilio privato o luogo di lavoro poiché, in sostanza, aveva «una percezione 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’informatica il concetto del pay-per-use (definito anche del pay-as-you-go) e l’offerta di tecnologia come servizio, superando la tradizionale vendita di prodotti, ovvero di hardware e software su supporti fisici.
I vantaggi che offre il Cloud sono indubbi. Disponibilità e accessibilità ai propri dati in ogni momento, gratuitamente o a costi estremamente 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)esistenza elettronica”, Roma, 25 marzo 2011 e G. Ziccardi, in Hacker - Il richiamo della libertà, 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 costosi, 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, quali 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.
234
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 centralizzate che, per loro stessa natura, sono facili da controllare da parte del gestore. Quest’ultimo possiede tutti i dati dell’utilizzatore ma si concentra
generalmente sul deployment e sulla delivery del servizio più che sulla progettazione di un sistema che salvaguardi i dati stessi.
Un recente studio 12 ha ipotizzato che nel 2015 il Cloud sarà utilizzato da oltre 2,5 miliardi di persone con oltre 10 miliardi di apparati diversi che accederanno ad internet, oltre il doppio di quelli attuali. Della
sua importanza si è accorta anche la DG Information Society della Commissione 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
“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 relevant ads, and develop and deliver new features across your Google experience. Priority Inbox, spell checking, forwarding, auto-responding, automatic saving and sorting, and converting URLs to clickable links are just a few of the many features that use this kind of automatic 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 Service - IaaS. L’utente può acquistare risorse di memorizzazione (Storage Cloud) o computazionali (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 comportamento 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 servizio 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.
9
235
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 Privacy) che ha focalizzato l’attenzione degli utenti sui pericoli che può comportare un uso inconsapevole.
L’analisi che qui ci occupa cercherà di fornire un ampio quadro sulle implicazioni giuridiche del Cloud che, per communis opinio, sono ricondotte spesso al solo ambito della protezione dei dati personali. Invero, il Cloud conduce a diversi ambiti giuridicamente rilevanti, sia penali 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 maggiormente trascinanti.
Considerando la finalità specialistica che il presente articolo si prefigge, non si è ritenuto di dar conto di nozioni di base, soprattutto in riferimento 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 indicheremo come “utente”), il fornitore dei servizi (“fornitore”) e i soggetti che a vario titolo collaborano con quest’ultimo al di fuori della sua
struttura (che potremmo definire “partner” o “soggetti terzi”). In particolare, 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 professionista che utilizza il Cloud per finalità istituzionali o professionali assumendo così, a seconda dei casi appena elencati, diverse soggettività giuridiche nei rapporti contrattuali con il fornitore.
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 Commissione 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 pubblicata congiuntamente alla Relazione Annuale del 2010.
14
236
Infine, prima di intraprendere l’analisi giuridica, può tornare utile
fornire alcune indicazioni generali sugli aspetti tecnici del Cloud. Abbiamo 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 è virtualizzazione, 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 virtualizzata: 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 finalità consumer anche se non è escluso che sia utilizzato anche da liberi professionisti, imprese individuali, società, organizzazioni o pubbliche
amministrazioni che elaborano pochi dati e con ridotte esigenze di informatizzazione. I modelli PaaS e IaaS sono invece per utenti maggiormente esigenti in quanto consentono la gestione di un vero e proprio ambiente server di sviluppo e/o di produzione. L’architettura informatica sottesa
in ogni caso a tutte le species del Cloud è quella che consente l’interazione tra il computer 16 dell’utente e quello del fornitore, ovvero, il sistema
client-server. Tutte le applicazioni che comunicano tramite reti o interreti 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 accedere anche a risorse di computing, che gli consentono di elaborare dati e
che, diversamente, dovrebbe richiedere localmente 17. Oltre alla virtualiz16
Computer è da intendersi nel senso più ampio del termine, che possa ricomprendere qualunque dispositivo collegabile alla rete e con capacità, anche minima, di elaborazione. 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: “Applicazioni, 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 rimetterti subito al lavoro.”. In altre parole, significa che il pc non memorizza nulla in loca-
237
Guglielmo Troiano
zazione anche la ridondanza 18 è una componente essenziale del Cloud, finalizzata 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 balancing). Di fatto, quindi, il client non accede sempre allo stesso server ma
a quello sul quale risultano essere collocate le risorse richieste. In tal guisa, la stabile e certa collocazione fisica dei dati viene meno. Questi possono essere memorizzati contemporaneamente su diversi server, collocati 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 caratterizzati dal principio di “territorialità” 20 per quanto attiene all’applicazione 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 conle. Tutti i dati dell’utente sono online sui server di Google – “nella cloud” – accessibili attraverso 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 importanza per garantire la sicurezza delle persone e degli impianti o la continuità della produzione. 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 utenti affidano i propri dati personali e sensibili, si legge testualmente “Google processes personal 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 tecnologie di informazione e comunicazione, anche in ambito penale non sempre emerge chiaramente (cfr. Par. 5).
238
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 contratto e del giudice che sarà adìto per le controversie tra utente e fornitore in un contratto di servizi di Cloud, si basa su una duplice evenienza: scelta determinata dalle parti e casi in cui la scelta non sia avvenuta
o non avvenga nemmeno successivamente alla conclusione del contratto. Le regole di diritto internazionale privato 22, infatti, stabiliscono come
primo “criterio di collegamento” quello della scelta delle parti, sia predeterminata nel contratto sia effettuata in ogni momento successivo, anche
in deroga ad una scelta precedente 23. Il fornitore di Cloud predeterminerà 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 è ammessa ma l’esercizio di essa non può avere per effetto di privare il consumatore 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
Le disposizioni da prendere in esame, ed applicabili al Cloud, sono il Regolamento CE n. 593/2008 (denominato Roma I) ed il Regolamento CE n. 44/2001. Il primo determina la legge applicabile ai rapporti contrattuali, mentre il secondo si occupa
della giurisdizione competente in materia civile e commerciale. I regolamenti hanno carattere 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 Regolamento 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, espressamente richiamano il contratto di prestazione e fornitura di servizi, cui il contratto di
Cloud è senz’altro riconducibile (vedi infra nel presente paragrafo).
22
239
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 svolga le sue attività nello stesso paese, o diriga tali attività, con qualsiasi mezzo, verso tale paese 27. In assenza di tutte queste condizioni, la legge applicabile 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 internazionale privato si preoccupa solo di fornire le regole per stabilire la legge applicabile ed il giudice competente, prescindendo, generalmente, dal
tipo di contratto. Tuttavia, una breve trattazione che riguarda l’individuazione della tipologia, rectius delle tipologie, di contratto riconducibili
al Cloud, sembra opportuna in questo contesto.
Anzitutto, anche se può apparire superfluo ribadirlo a questo punto del discorso, si può rilevare che il Cloud ha senza dubbio ad oggetto
la fornitura di servizi, piuttosto che la vendita di prodotti, come naturale conseguenza della sua genesi nella storia dell’informatica. Proseguendo quindi sulla base di questo assunto, si possono evidenziare alcuni tratti contrattuali comuni in tutte le tipologie di Cloud. Eloquente risulta
l’impegno dell’utente a consegnare al fornitore i propri dati e l’assunzione 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 identificherebbe 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 Ex art. 6 c.1 del Regolamento CE n. 593/2008.
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”, Altalex, 2011.
27
28
240
ratteri del contratto di appalto 30 sebbene, a parere di chi scrive, occorra
precisare che tale contratto, per essere qualificato tale, necessita di un elemento fondamentale: il progetto. L’oggetto dell’appalto, infatti, dev’essere determinato o determinabile e ciò avviene normalmente con il progetto 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 discendere due problematiche rilevanti: i) l’esportazione dei dati non sarà possibile 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’interconnessione 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 svolgimento di un servizio.
31
“In economics, vendor lock-in, also known as proprietary lock-in or customer lockin, 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 prodotti 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 Formats, http://www.openformats.org/it1.
241
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, costringendolo 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 consenso di differenti attori dell’economia: industrie, imprese medio-piccole, consumatori, lavoratori, organizzazioni non governative, pubbliche
autorità ecc. Per superare quindi gli ostacoli derivanti dall’adozione di
standard diversi nella produzione informatica, è recentemente intervenu33
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 standard 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’importante è che accettino uno standard ISO per il formato della carta (ad esempio l’A4 nello 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 probabilmente 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 processo di analisi tecnica e definizione gestito da apposite organizzazioni, e quando è stato formalizzato e descritto in uno specifico documento chiamato comunemente “norma tecnica”, o anche più semplicemente “norma”. Tuttavia, non sempre un determinato modello 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 realtà non sono mai stati riconosciuti come tali da apposite organizzazioni attraverso un regolare processo di standardizzazione: si parla in questo caso di standard de facto.” Cfr. Simone 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 è trasparente e/o la sua specifica è di pubblico dominio. Si tratta generalmente (ma non esclusivamente) 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 tuttavia casi di formati aperti promossi da aziende, che hanno deciso di rendere pubblica la
specifica dei propri formati. Cfr. Open Formats, ibidem.
242
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 compreso l’importanza dell’utilizzo di standard aperti, molti altri continuano
a definire – indipendentemente l’uno dall’altro – formati ai quali attenersi 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 mancanza di standardizzazione (di uso di standard comuni) nella fase di progettazione del programma. L’uso o meno di interoperabilità nello sviluppo
di prodotti tecnologici ha rilevanti conseguenze economiche. Se prodotti 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 è impegnata a supportare l’interoperabilità dei servizi, ovviamente in forma digitale, offerti ai cittadini ed alle imprese che vivono e svolgono attività commerciali nell’ambito del territorio dell’UE. Da ciò è nato un progetto di
studio da cui è scaturito il documento European Interoperability Fra 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 componenti di un sistema informatico e con gli utenti; che a tale scopo è necessaria un’interconnessione 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 utenti in tutti i modi in cui sono destinati a funzionare; considerando che le parti del programma che assicurano tale interconnessione e interazione fra gli elementi del software e
dell’hardware sono generalmente denominate “interfacce”; considerando che tale interconnessione 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.
36
243
Guglielmo Troiano
mework 39 (EIF). Inoltre, sempre la Commissione Europea, ha adottato
una strategia a lungo termine chiamata “Europe 2020” 40, ovvero la strategia 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 Software 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 Libero e Proprietario, ma alcune precisazioni sono necessarie per compredere meglio l’analisi giuridica che seguirà.
Le opere dell’ingegno che al pari del software sono protette dalla legge sul diritto d’autore (o copyright se si considerano il sistema giuridico sta 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/philosophy/categories.it.html#ProprietarySoftware.
39
244
tunitense e suoi derivati), sono in larga parte dematerializzate e non dipendendo da un supporto fisico determinato. Inoltre, il software è un prodotto (un’opera) per sua natura di rapidissima obsolescenza e l’incoporazione 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 registrato ma nel suo contenuto ideativo ed il pericolo che corre l’autore non
è tanto che gli sia sottratto il supporto, ma che sia plagiato indebitamente 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 fisico 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.
Il diritto d’autore non si è mai granché preoccupato del legame che intercorreva tra il titolare dei diritti e l’utente finale. Quest’ultimo acquistava il diritto di utilizzare 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 musica, i film o le opere letterarie, anche il software non è mai dipeso, di per sè, da un supporto fisico determinato (per esempio i CD o DVD sui quali solitamente si trova incorporato 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 realizzata per mezzo di un’obbligazione di tipo contrattuale. Non sempre è però così. Saltuariamente 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.
44
245
Guglielmo Troiano
Ciò premesso, sappiamo per certo che nel Cloud il software viene
distribuito come servizio e non come prodotto incorporato in un supporto. Tuttavia, l’opera dell’ingegno resta, è solo altrove, installata sui computer del fornitore e visualizzabile dall’utente attraverso un’interfaccia
grafica. Infatti, la possibilità che il titolare dei diritti d’autore possa “licenziare” i propri diritti risulta inattuabile 46 perché il software non è distribuito. Il sistema è strutturato in modo che sia il fornitore a controllarlo (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 distribuzione di programmi aperti e liberi, si sono adeguate a tale pratica,
assorbendo in parte il licenziamento di diritti d’autore nei termini di servizio 47. I diritti tipicamente concessi all’utente con le licenze del FLOSS,
come la possibilità di far funzionare e utilizzare il programma per qualsiasi fine, di studiare come funziona il programma e di adattarlo alle proprie
esigenze (avendo a disposizione il codice sorgente), di migliorare il programma 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 problematiche sottese all’utilizzo di software in Cloud e che possono porta46
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 provided 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, decompile or otherwise attempt to extract the source code of the Software or any part thereof, unless this is expressly permitted or required by law, or unless you have been specifically 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 Software, or otherwise transfer any part of your rights to use the Software.”
246
re lo stesso ad essere considerato “insicuro”, in quanto contenente istruzioni e condizioni non previste dall’essere umano che lo ha programmato ma da qualcun altro. Non solo. Occorre considerare anche i modi con
cui chi ha programmato il software può nascondere al suo interno vulnerabilità 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 interno modalità di funzionamento appositamente nascoste 48. Se una funzionalità non è graficamente visibile all’utente, questi difficilmente la scoprirà, soprattutto se ha a disposizione esclusivamente una forma di rappresentazione 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 partecipanti ad un dato progetto valutano in tempo reale i cambiamenti effettuati al software e spesso effettuano anche un’analisi completa della sicurezza 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 personal 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 pubblicazione Frontpage. Addirittura nel codice della “backdoor” fu ritrovata la frase “Netscape 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-1001239273.html.
247
Guglielmo Troiano
particolarmente agile. La materia è quindi senz’altro pertinente ma, data
la sua complessità, esaminarla anche solo sommariamente in questo contesto è inopportuno 49. Occorre quindi circoscrivere l’analisi ed esaminare
alcuni aspetti che con il Cloud si rendono evidenti più che in altri contesti in cui generalmente sono commessi i “reati informatici” 50.
«Nel cyberspazio i tradizionali confini degli Stati, se vengono azzerati durante l’azione informatica posta in essere dal soggetto agente, riaffiorano
successivamente laddove si tenti di ricostruire il percorso a ritroso alla ricerca 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 verificato 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, oppure, al contrario, il luogo della ricezione degli stessi da parte dei destinatari 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
Trattazioni esaustive e dogmatiche sui reati informatici possono essere rinvenute in molti testi, tra i quali si segnalano: Carlo Sarzana di S. Ippolito (a cura di), in “Informatica, 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’indietro 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.
49
248
dati da parte dell’utente corrisponde alla determinazione del luogo dell’azione, mentre la richiesta degli stessi da parte di un terzo, corrisponde al
luogo dell’evento. Con il Cloud, invece, i server hanno natura “dinamica”. Come precisato in premessa, i dati e, in generale, le risorse informatiche, possono essere duplicate su diversi server e utilizzate a seconda delle esigenze di ottimizzazione delle stesse. In conseguenza, appare impossibile 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 problematiche strettamente legate all’attività d’indagine. I principi 54 ideati e sviluppati dalla Computer Forensics 55 per la gestione del c.d. “reperto informatico”, già di difficile attuazione su computer facilmente reperibili, per esempio, presso il domicilio dell’indagato o in un data center presente sul territorio nazionale, sono sostanzialmente inapplicabili al Cloud. Infatti, quasi mai sarà possibile effettuare accertamenti urgenti sui server per procedere, eventualmente, ad un sequestro proba È da rilevare che la Suprema Corte ha recentemente affermato che, nella diffamazione 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 inutilizzabili, 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 ricorso 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’altro vanno “congelati”, ossia ne va impedita la modifica o alterazione; iii) chain of custody – 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 determinati accadimenti ai fini della costituzione di fonti di prova.
53
249
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 precedenza, il Cloud è geneticamente “dinamico” per cui i dati sono automaticamente spostati, replicati, cancellati e modificati in brevissimo 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 geografica del dato, dovranno cioè riuscire a sapere in quale (o quali) data center
esso è memorizzato e, successivamente, verificare che lo stesso non sia stato alterato. In seguito, sarà possibile verificare se il data center è sottoposto
alla sovranità di uno stato che consente il dispiegamento di attività d’indagine previste dal nostro sistema processuale e che, infine, consenta di procedere secondo le formalità previste dall’art. 727 del c.p.p. (Trasmissione
di rogatoria ad autorità straniere) 60. I poteri di intervento del pubblico ministero procedente, nonostante sia riconosciuta la sua competenza, possono 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 Ex art. 253 bis del c.p.p.
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 ritenere 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 Budapest sono aggiunte le seguenti parole: “[…] anche in relazione a sistemi informatici o telematici, 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 fornita? “Spiacenti, in nostri server stanno in America … quindi chiedete l’intercettazione con
una rogatoria!”. Cfr. F. Cajani, op. cit.
56
57
250
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 criminalità informatica del 23 novembre 2001 (Convenzione di Budapest),
si sarebbero dovute creare le condizioni ideali affinché le cyber-investigazioni di natura internazionale (per lo meno tra i paesi aderenti alla convenzione) 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 ancora in stato di implementazione più che di attuazione 64. Tra questi, in
primis, quello previsto dall’art. 16 “Conservazione rapida di dati informatici immagazzinati” (c.d. “quick freeze” 65) che potrebbe consentire alle
competenti autorità di ordinare o ottenere in altro modo la protezione rapida di specifici dati informatici, inclusi i dati sul traffico, che sono stati
conservati attraverso un sistema informatico, in particolare quando vi è
Contenuta nell’art. 132 del Codice Privacy.
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’accesso ad un sistema informatico nonché ai supporti di memorizzazione dei dati stessi. Condizione 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, diversi 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’assicurazione 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 refers 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.
61
62
251
Guglielmo Troiano
motivo di ritenere che i dati informatici siano particolarmente vulnerabili 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 nazionale e comunitario non prevede, infatti, alcun obbligo di identificazione di
un soggetto che stipula un contratto di fornitura di servizi con un internet provider, tanto più, nello specifico, con un Cloud provider. Il fornitore 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 controllo, 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 Privacy) sono contemplate agli artt. 167-170. Escludendo le più improbabili dell’art. 168 (Falsità nelle dichiarazioni e notificazioni al Garante) e
dell’art. 170 (Inosservanza dei provvedimenti del Garante), ci soffermeremo 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
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, indifferentemente, 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 recare ad altri un danno, procede al trattamento di dati personali in violazione di quanto disposto dagli articoli 18, 19, 23, 123, 126 e 130, ovvero in applicazione dell’articolo 129, è punito, 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.”
66
252
all’art. 169 sarà trattato nel paragrafo seguente congiuntamente alle misure 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 oggettivo.
In relazione al primo elemento occorre considerare che, nonostante il soggetto attivo possa essere considerato “chiunque”, le maggiori responsabilità penali sono generalmente riconducibili a titolare e responsabile 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 servizio. Infatti, il titolare si configura come il soggetto preposto ad ogni potere decisionale con riguardo alle finalità ed alle modalità del trattamento ed il responsabile come il soggetto a cui il primo delega alcune specifiche operazioni. Il fornitore è mero custode delle banche dati degli utenti. Non è individuabile come titolare del trattamento ma non potrebbe
nemmeno essere definito come responsabile, dato che per il tipo di servizio reso si configura un grado di autonomia incompatibile con il ruolo di
semplice esecutore delle istruzioni impartite dal titolare, che è invece l’utente nei confronti dei dati di terzi. In definitiva, all’utente andrebbero
ricondotte entrambe le figure ma, per un’attribuzione formale maggiormente realistica, occorrerebbe intervenire con un atto normativo diretto
a ridistribuire le responsabilià tra i diversi soggetti, per esempio attraverso l’introduzione di una speciale figura di responsabile, che sia contemporaneamente in grado di offrire agli utenti particolari garanzie in termini 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 “danno”, nei confronti di altri. Il concetto di profitto, a differenza di quello di
lucro, appare piuttosto ampio dovendo essere inteso come qualsiasi utilità o vantaggio, ovvero pregiudizio, anche di natura non patrimoniale, essendo 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 citati nell’art. 167 (artt. 18, 19, 23, 123, 126, 129 e 130). Di sicuro rilevo
253
Guglielmo Troiano
nell’ambito del Cloud si può osservare più approfonditamente la violazione dell’art. 23 (Consenso).
L’art. 23 prevede che soggetti privati ed enti pubblici economici possano 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 ricorra una delle ipotesi di esclusione dell’art. 24. Tra queste esclusioni emerge senza dubbio l’eccezione di cui alla lettera b) dell’articolo succitato, per
cui, il trattamento può essere effettuato senza consenso quando “è necessario per eseguire obblighi derivanti da un contratto del quale è parte l’interessato 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’utente 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 nuovo 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/Vividown” in cui quattro dirigenti, di Google, sono stati condannati 68, ai sensi dell’art. 167 ivi richiamato, per violazione dell’art. 23 del Codice Privacy (Consenso), con l’aggravante del fine di lucro. In sostanza, nel caso
in esame è stato evidenziato che rendendo titolari dei dati di terzi solo coloro 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 personali e a cui, pertanto, non si dovrebbero applicare le principali disposizioni
68
Con la Sentenza del Tribunale di Milano (Sez. Quarta Penale) del 24 febbraio 2010 n. 1972.
69
Cfr. L. Bolognini, D. Fulco e P. Paganini (a cura di), op. cit., par. 4.6.
254
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, indubbiamente, 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 immette 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 considerarsi 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 differito trattamento? Chi effettua la prima memorizzazione dei dati dovrebbe 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 raccolti presso terzi. Google indicizza a proprio piacimento 70 i contenuti immessi 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 modalità 71. In casi come questo, il Codice Privacy impone che si chieda il consenso 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 separata 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 quanto la stessa indicizza e organizza le informazioni che gli utenti immettono nei suoi sistemi. 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 giuridici dei servizi della società dell’informazione, in particolare il commercio elettronico,
nel mercato interno).
255
Guglielmo Troiano
7. Le misure di sicurezza
L’utente di servizi di Cloud sarà sempre costantemente afflitto dalle 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 fondamentale e dev’essere analizzata sulla base di una duplice considerazione, ovvero, 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 informatiche 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 indefinito di volte attraverso le reti informatiche, motivo per cui il fornitore
dovrebbe adottare non solo le misure di sicurezza atte a proteggere i sistemi (i data center) da eventuali accessi abusivi esterni ma dovrebbe assicurarsi 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 identificare le previsioni di cui agli artt. 31, 33 e 34 del Codice Privacy, che stabiliscono 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 Cfr. P. Perri, Protezione dei dati e nuove tecnologie, Giuffrè Editore, 2007.
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 “[…] messages 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 Internet 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 comunicazione 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 elettronico o comunque automatizzato con cui si effettua il trattamento”.
72
73
256
te, ai sensi dell’art. 34, alcune specifiche misure minime con le modalità 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 rischi 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 trattamento e delle specifiche caratteristiche del trattamento (ossia se effettuato
con strumenti elettronici o meno). Le misure idonee, infatti, diversamente dalle misure minime, non sono predefinite dalla legge ma legate all’evoluzione tecnologica, obbligando quindi il fornitore ad un’aggiornamento
costante dei sistemi. Inoltre, proseguendo nella disamina dell’art. 31, occorre evidenziare che il fornitore è obbligato ad adottare non solo i sistemi di protezione che possano evitare eventuali accessi abusivi dall’esterno
(come per es. i “firewall”) ma anche i sistemi che gli consentano di monitorare gli accessi ai dati effettuati all’interno della rete, ciò al fine di verificare che soggetti incaricati non effettuino trattamenti non consentiti o
non conformi alle finalità comunicate all’utente (come per es. la memorizzazione 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 provvedimento dell’Autorità garante per la protezione dei dati personali, “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni 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 resterebbero quindi sempre crittografati e solo l’utente potrebbe decifrarli.
257
Guglielmo Troiano
dati attraverso la cifratura degli stessi 77 ed estromettere chiunque dall’accesso abusivo.
L’art. 34 prescrive, invece, le specifiche misure minime da adottare
se il trattamento avviene con strumenti elettronici: a) autenticazione informatica; b) adozione di procedure di gestione delle credenziali di autenticazione; c) utilizzazione di un sistema di autorizzazione; d) aggiornamento periodico dell’individuazione dell’ambito del trattamento consentito 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 determinati 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 effettuati 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 richiamato 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’ambiente informatico di sviluppo e produzione (nell’IaaS di sicuro presenti) 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 notificazione 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.
258
attinenti all’ambito dei servizi offerti, se impiega personale altamente qualificato 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 modelli 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 disposizioni 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 momento in cui inizia un trattamento di dati non accompagnato dalle misure idonee di sicurezza che, in questo senso, devono essere “preventive”. Sul momento 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 Direttiva 95/46/CE, con le legislazioni nazionali ispirate ai medesimi principi.
In via residuale e straordinaria, il Garante Privacy può limitare quei trasferimenti 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, quando il paese di destinazione non assicura un adeguato livello di tutela delle persone.
Gli USA, per esempio, non rientrano nella categoria di quei paesi
che offrono adeguate garanzie, per cui, operano in regime di Safe Harbor 80, ovvero possono offrire garanzie contrattuali adererendo a strumen79
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 attraverso il data base del Dipartimento del Commercio degli USA disponibile alla pagina
https://safeharbor.export.gov/list.aspx.
259
Guglielmo Troiano
ti volontari che assicurano – come richiesto dalla norma – una sufficiente protezione.
In altre parole, il trasferimento dei dati all’esterno dell’UE può avvenire solo con paesi che offrono una garanzia di protezione dei dati equivalente 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, sembrano 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 trasferimenti 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 attraverso una chiara indicazione da parte dello stesso della collocazione geopolitica 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 trasferimento dei dati da paese a paese avvenga nel rispetto delle garanzie minime 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 trasferimento in paesi extra UE se l’interessato ha manifestato il proprio consenso, 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 Autorizzazione Generale n. 35 del 27 maggio 2010.
260
9. Conclusioni
Quello del Cloud è un tema senza dubbio complesso. Di esso si è
parlato e scritto quasi ovunque. Ha dato titoli a conferenze, seminari, riviste, 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 recentemente preso in considerazione, tra l’altro, in un documento di semplice natura informativa.
D’altronde, la stessa rete internet ed i suoi principali player (gli Internet 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 dimostrano. Inoltre, lo stesso accesso alla rete internet, che consente la materiale comunicazione tra l’utente ed il fornitore, è offerta a costi ancora
troppo elevati e le aree geografiche collegate con linee veloci, come la fibra ottica o l’ADSL, corrispondono quasi tutte alle sole grandi città, lasciando al resto del territorio le connessioni mobili UMTS/HSPA a cui,
tra l’altro, fanno capo anche tutti i dispositivi evoluti (smartphone) di telefonia mobile i cui contenuti sono essenzialmente in Cloud.
Nonostante tutto, il Cloud non è da considerare l’ennesimo ambito 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 prima ancora quello comunitario, devono intervenire per affrontare organicamente tutte le complicanze del Cloud. In particolare, risulterà necessario modificare e integrare al più presto alcune disposizioni nell’ambito
della privacy e della data protection 82, interrogandosi, in primis, sulla op 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 norma82
261
Guglielmo Troiano
portunità di individuare garanzie minime che dovrebbero essere offerte
dai fornitori di servizi di Cloud, così come già avviene in altri settori regolamentati 83.
Intanto, la certificazione della affidabilità del fornitore congiuntamente ad un modello contrattuale ben strutturato, costituiscono le necessarie 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ù volte citata nell’articolo al fine di avere un confronto pratico, non è da considerarsi esempio negativo. Come affermato da essa stessa, il Cloud Computing è nel suo DNA 84 e la pletora di servizi che offre è tutti di tal specie. Per questi motivi sarebbe stato innaturale non citarla. Al contrario,
oltre al suo impegno nell’offerta di programmi con codice aperto e ispezionabile 85, sono degne di nota positiva le iniziative intraprese per informare 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 Commissione Europea, cfr. “Action 12” in http://ec.europa.eu/information_society/newsroom/cf/fiche-dae.cfm?action_id=170&pillar_id=43&action=Action%2012%3A%20
Review%20the%20EU%20data%20protection%20rules.
83
Per esempio, nei confronti di tutte le imprese che forniscono servizi di comunicazione 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/.
262
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 treatment of data and the legislative regulation of the European Union.
263
In questo numero - In this issue
Politica dell’innovazione, democrazia elettronica
e 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 Cyberspace and Law

Transcript

Documenti analoghi

Come ridurre i costi aziendali

OASIS Openly Accessible Services and Interacting

Scarica subito

cloud computing

Brochure illustrativa

L`HR è in grado di favorire la crescita?

La Protezione internet Italiana per la Microimpresa e le PMI