Infrastruttura cloud e integrazione delle applicazioni: architettura, contratti e uscita in Svizzera

Comprendere i modelli architetturali e i confini delle responsabilità

Tecnicamente, il cloud computing implica che applicazioni, software, spazio di archiviazione, strumenti di sviluppo, capacità di rete o potenza di calcolo vengano forniti su richiesta tramite una rete – come Internet – da un provider cloud. Se durante questo processo vengono trasmessi dati personali, si applica la Legge federale sulla protezione dei dati (LPD). L’aspetto decisivo per l’architettura è il confine di responsabilità tra il fornitore e il cliente, che varia notevolmente a seconda del modello.

Con il Software as a Service (SaaS), le aziende ottengono applicazioni pronte all’uso – ad esempio per la contabilità, il CRM o gli uffici – direttamente dal fornitore. Non installano nulla e ricevono aggiornamenti continui nonché supporto. Il software viene solitamente fornito via web; il fornitore è responsabile del funzionamento e della manutenzione.

Il Desktop as a Service (DaaS) è un sottotipo. Il fornitore mette a disposizione desktop virtuali dal cloud; l’utente riceve un desktop completo che gira sul server del fornitore. Anche in questo caso, il fornitore si assume tutta la responsabilità dell’infrastruttura.

Con l’Infrastructure as a Service (IaaS), l’azienda affitta capacità server, spazio di archiviazione o infrastruttura di rete e può gestire il proprio software su di essa. La responsabilità dell’infrastruttura fisica, della tolleranza ai guasti e della sicurezza di base dei dati spetta al fornitore; per il sistema operativo e il livello applicativo rimane responsabile l’azienda. Questa residua responsabilità propria viene spesso sottovalutata nella pratica.

Indipendentemente dal modello, la responsabilità in materia di protezione dei dati rimane presso il cliente. Le aziende continuano a essere responsabili del rispetto della LPD quando esternalizzano i dati nel cloud e affidano compiti tecnici al fornitore. Già il semplice salvataggio di dati personali nel cloud costituisce un trattamento ed è soggetto alla LPD. La legge richiede un trattamento trasparente, finalizzato e proporzionato, nonché adeguate misure tecniche e organizzative.

Ne derivano domande ricorrenti sull’architettura: dove si trovano geograficamente i dati e quanto è isolato l’ambiente del singolo cliente rispetto agli altri? Come è organizzata la tolleranza ai guasti su più sedi e a quale livello avviene la crittografia?

I fornitori di soluzioni Private Cloud pubblicizzano data center georedundanti in Svizzera, ambienti dedicati e completamente isolati per ogni cliente nonché crittografia completa. Tali affermazioni devono essere verificate contrattualmente e tecnicamente e non accettate come semplici dichiarazioni di marketing.

Integrare le applicazioni senza perdere di vista i flussi di dati

Spesso sono le applicazioni cloud quotidiane, apparentemente innocue, a presentare rischi critici per la protezione dei dati. Rientrano in questa categoria gli strumenti Office per la collaborazione online tra dipendenti, gli strumenti di gestione online degli indirizzi e-mail per newsletter o assistenza clienti, sistemi CRM online, il caricamento di video su piattaforme di streaming e il caricamento di file su un server accessibile via Internet. In tutti questi casi vengono trattati dati personali, anche se l’applicazione serve principalmente a uno scopo aziendale.

Prima dell’integrazione, occorre stabilire quali dati fluiscono dove. Devono essere documentati almeno le categorie di dati interessate e la loro origine, le interfacce in entrata e in uscita, i destinatari all’interno e all’esterno dell’organizzazione, i sub-incaricati impiegati nonché i luoghi di archiviazione e di elaborazione, comprese le eventuali copie di backup. Questa registrazione non è un esercizio una tantum. Deve essere verificata per ogni nuova applicazione, ogni aggiornamento con nuove funzionalità e ogni cambio di fornitore.

La chiarezza dei ruoli è un prerequisito. L’azienda che fornisce servizi cloud agisce generalmente come incaricato del trattamento dei dati del cliente ai sensi dell’art. 9 LPD. Il cliente può essere egli stesso responsabile del trattamento dei dati o a sua volta incaricato del trattamento; se è incaricato del trattamento, deve soddisfare i requisiti stabiliti dal responsabile per i suoi trattamenti. Come responsabile, egli ha l’onere di garantire che i trattamenti effettuati per suo conto siano conformi alla protezione dei dati e che i diritti delle persone interessate non siano compromessi dall’esternalizzazione.

In pratica, ciò significa: chi integra una piattaforma per newsletter, un CRM o una piattaforma video deve chiarire, prima del primo importazione dei dati, se sussiste un trattamento per conto terzi, quali sub-incaricati sono coinvolti e se i dati transitano in un altro paese. Se un servizio viene messo in produzione senza questa verifica, ricostruire successivamente il livello dei flussi di dati richiede uno sforzo considerevole.

Lista di controllo per l’integrazione di applicazioni cloud con rischi per la protezione dei dati

Contratti: trattamento per conto terzi, sub-incaricati e diritti di controllo

Nel cloud computing sussiste generalmente un trattamento dei dati per conto terzi: il fornitore elabora i dati trasmessi per conto del cliente. Questo trattamento per conto terzi deve essere regolato contrattualmente. Lo standard minimo prevede un diritto di direttiva e di controllo da parte del committente nonché uno standard base di sicurezza dei dati.

L’utente del cloud, in qualità di responsabile, è obbligato ad accertarsi e a tutelarsi contrattualmente affinché rispetti i requisiti per un trattamento per conto terzi ai sensi dell’art. 9 LPD.

I grandi provider cloud dispongono di modelli contrattuali predefiniti per il trattamento dei dati per conto terzi. Questi modelli devono essere esaminati criticamente e non adottati senza modifiche. Sono spesso formulati a favore del fornitore e non coprono sempre i requisiti svizzeri. In particolare, vanno regolati le condizioni per il coinvolgimento di ulteriori sub-incaricati, l’informazione e, se del caso, il diritto di opposizione del cliente in caso di cambi, gli obblighi di notifica in caso di incidenti di sicurezza nonché la questione di chi sostiene i costi di un audit.

I diritti di controllo non dovrebbero esistere solo sulla carta. Sono utili indicazioni chiare su quali prove fornisca regolarmente il fornitore, in quali condizioni siano possibili audit in loco e come classificare le certificazioni. Anche la cancellazione e la restituzione dei dati devono figurare esplicitamente nel contratto. Quando vengono cancellati i dati, in quale formato vengono restituiti e cosa succede alle copie nei sistemi di backup e presso i sub-incaricati?

Prescrizioni svizzere sulla protezione dei dati nel cloud computing

Trasferimenti verso paesi terzi e sovranità dei dati: USA, UE e regioni svizzere

I dati personali possono原则上 essere trasferiti solo in paesi che offrono un livello adeguato di protezione dei dati. Secondo l’opinione prevalente, per gli USA tale livello non è garantito. Tali trasferimenti devono essere tutelati in altro modo – altrimenti devono essere omessi. Come tutela sostitutiva rientrano in particolare le clausole contrattuali tipo, come previste dal diritto europeo all’art. 46 del GDPR.

La Svizzera, a sua volta, dipende dal riconoscimento da parte dell’UE. La decisione di adeguatezza della Commissione europea per la Svizzera risale al 2000. La legge svizzera sulla protezione dei dati rivista è stata elaborata anche con l’obiettivo di garantire questo riconoscimento.

La LPD rivista, la nuova Ordinanza sulla protezione dei dati e l’Ordinanza sulle certificazioni in materia di protezione dei dati sono entrate in vigore il 1° settembre 2023. L’ambito di applicazione è stato ampliato. Ora si estende anche ai trattamenti che hanno effetti in Svizzera, pur essendo stati causati all’estero. Sono protette solo le persone fisiche.

Con i grandi provider cloud, le sedi dei server possono generalmente essere limitate a livello regionale. Si consiglia di limitare questa regione all’Europa e di prevedere contrattualmente che nessun dato personale lasci questa regione. Una tale limitazione geografica è più efficace di una mera dichiarazione d’intenti, poiché può essere verificata tecnicamente e contrattualmente.

Da distinguere è la questione della sovranità dei dati. I cosiddetti modelli di cloud sovrano mirano a impedire che governi stranieri o multinazionali estere possano accedere all’infrastruttura o monitorarla. Se un tale modello regga dipende dai rapporti di proprietà, dalla sede del fornitore, dagli obblighi di divulgazione vigenti e dalle effettive possibilità di accesso a chiavi e sistema operativo. L’archiviazione regionale da sola non basta se il fornitore può rimanere legalmente obbligato ad accedere ai dati.

Uscita: restituzione dei dati, fallimento e assenza di diritto di separazione

Se il provider cloud finisce in fallimento, può accadere che l’utente del cloud non riesca più ad accedere ai propri dati. Secondo l’attuale situazione giuridica in Svizzera, in caso di fallimento di un’azienda non esiste un diritto di separazione per i dati di terzi. Il diritto svizzero non conosce nemmeno un diritto di proprietà sui dati. I dati non rientrano nel concetto di «cosa» nel Codice civile svizzero, perché manca loro la necessaria corporeità.

Questa situazione di partenza non può essere risolta con una semplice clausola contrattuale. Il caso di fatto generalmente non può essere chiarito solo alla luce del diritto svizzero, poiché la maggior parte dei grandi provider cloud ha sede all’estero. L’uscita deve quindi essere progettata con anticipo – come parte dell’architettura e non come appendice al contratto.

Devono essere ancorati contrattualmente almeno: un diritto alla restituzione completa dei dati in un formato comune leggibile dalla macchina; termini per la restituzione e la successiva cancellazione; l’obbligo di assistenza durante una fase di migrazione definita; nonché la messa in sicurezza di copie al di fuori dell’ambiente del fornitore. Chi non replica i propri dati in un sistema proprio e controllato, in caso di emergenza dipende esclusivamente dalla disponibilità a collaborare della massa fallimentare.

Il piano di uscita dovrebbe anche indicare il dispendio di personale e le dipendenze tecniche: quali applicazioni dipendono dalla stessa piattaforma, quali interfacce devono essere sostituite e quali formati di dati possono essere adottati senza perdite? Un’uscita che viene ponderata solo in caso di fallimento è praticamente impossibile da attuare.

Piano di azione per un’uscita sicura dal cloud

I backup sono prede: ripensare la salvaguardia e il ripristino dei dati

Molte PMI partono dal presupposto che un backup esistente significhi già protezione. Proprio questa assunzione oggi è un rischio. Le copie di backup possono trovarsi nello stesso account cloud dei dati produttivi ed essere accessibili con le stesse credenziali. In caso di account compromesso, possono essere crittografate o cancellate insieme; un backup nello stesso luogo e con gli stessi diritti dell’originale non protegge contro i danni più probabili.

I backup appartengono quindi all’architettura cloud e al piano di uscita, non alla sola competenza del reparto IT. Sono sensate copie di backup crittografate e ridondanti, conservate in un luogo separato dal sistema produttivo e ripristinabili in qualsiasi momento per la propria organizzazione. Dove i dati devono rimanere in Svizzera, questo deve valere anche per le copie di backup e per i sistemi di backup di eventuali sub-incaricati.

Altrettanto importante quanto il backup è il ripristino. Un ripristino mai testato è, in caso di emergenza, solo un’ipotesi. Da chiarire sono: quanto dura un ripristino completo, chi può attivarlo, quali diritti sono necessari e come si verifica che i dati ripristinati siano completi e invariati? Questi test dovrebbero essere documentati e ripetuti a intervalli regolari.

Infine, la salvaguardia dei dati deve essere coordinata con il trattamento per conto terzi: chi salva quali dati, per quanto tempo vengono conservati i backup e come vengono cancellati alla scadenza del contratto? Senza questo coordinamento, resta aperto se dopo un cambio di fornitore rimangano residui di dati nei sistemi di backup.

Verifica del fornitore con sguardo a esercizio, compliance ed exit

La verifica di un provider cloud non dovrebbe terminare con gamma funzionale e prezzo. Si è rivelata utile un’interrogazione strutturata lungo otto punti.

Rientrano tra questi la sede dei dati e i luoghi di archiviazione dei backup; i sub-incaricati impiegati con sede e modalità di cambio; le misure di sicurezza tecniche e organizzative, inclusa la crittografia e la gestione delle chiavi. Da verificare sono anche i diritti contrattuali di direttiva e controllo nonché le possibilità di audit; eventuali trasferimenti verso paesi terzi e la loro tutela; rischio di fallimento e posizione giuridica del fornitore; modalità di restituzione dei dati inclusi formato e completezza; nonché termini di uscita e assistenza nella transizione.

Come orientamento servono le indicazioni del PFPDT sul cloud computing. Secondo queste, tre aspetti meritano particolare attenzione: l’impiego di incaricati del trattamento e sub-incaricati, la sicurezza del trattamento dei dati e la trasmissione di dati personali in paesi terzi. Il PFPDT cita sotto «Ulteriori informazioni» la scheda informativa privatim rivista «Rischi specifici del cloud e misure» (2022). Vi cita anche le brochure dell’Ufficio federale tedesco per la sicurezza nelle tecnologie dell’informazione sull’uso sicuro dei servizi cloud (2016) e sulla scelta di un servizio cloud (2022).

Nella valutazione va considerato che i servizi cloud vengono forniti come soluzioni standardizzate. La standardizzazione abbassa i costi e aumenta la scalabilità, ma rende più difficili accordi individuali. Dove il fornitore non ammette deroghe alle sue condizioni standard, l’organizzazione deve decidere se i rischi residui per i dati concreti sono giustificabili – e se eventualmente sia più sensata un’altra soluzione con una limitazione regionale più forte o un ambiente proprio.

La verifica deve essere documentata e ripetuta. Le occasioni为此 sono la prima acquisizione di un servizio, modifiche contrattuali o funzionali sostanziali, nuovi sub-incaricati, cambiamenti nella situazione giuridica nonché l’uscita di figure chiave presso il fornitore. Chi fissa per iscritto i risultati, può in seguito dimostrare che la selezione è avvenuta con cura. Al prossimo cambio di fornitore, le domande decisive sono già pronte.

Lista di controllo a 8 punti per la verifica del provider cloud