La questione del cloud europeo non è dove si trova il server
Un luogo può essere vero e lasciare comunque aperta la domanda
Nelle discussioni sul cloud c'è un momento ricorrente. Qualcuno chiede dove verranno conservati i dati. Qualcun altro risponde con il nome di una città europea. La tensione nella stanza si allenta un po'. La risposta può essere perfettamente accurata e può contare moltissimo. La geografia incide su latenza, sicurezza fisica, elettricità, pianificazione della resilienza, occupazione, responsabilità pubblica e accordi legali attorno a un servizio. Un'autorità pubblica che deve mantenere determinati documenti all'interno di un territorio dichiarato ha un motivo legittimo per chiederlo. Il problema nasce quando si chiede al nome di una città di risolvere ogni altra questione dell'accordo.
Un server si trova da qualche parte. Un servizio no. Un servizio è una relazione tra entità legali, persone con diritti di amministratore, componenti software, fornitori di hardware, contratti, team di supporto, reti, accordi di crittografia, subappaltatori e il cliente che dipende dal risultato. L'edificio è una parte materiale di questa relazione. Non rivela chi può impartire un'istruzione privilegiata da altrove, quale gruppo societario controlla la società operativa, quale giurisdizione può raggiungere un fornitore, se un subprocessore è cambiato o cosa il cliente può portare via alla scadenza del contratto.
Non è un argomento contro i data centre europei o i fornitori europei. È un argomento contro il lasciare che una risposta utile svolga un lavoro che non può svolgere. La questione del cloud europeo non è se un server possa essere collocato su suolo europeo. È se l'organizzazione che usa il servizio possa comprendere ed esercitare un controllo sufficiente sull'intero accordo per il lavoro in gioco. La localizzazione fa parte di quella risposta. Non può essere l'intera risposta, così come l'indirizzo di un'azienda non ci dice chi detiene le chiavi dei suoi conti.
La distinzione conta di più dove il cloud svolge un lavoro ordinario e consequenziale. Un'amministrazione locale può conservare corrispondenza, fascicoli e informazioni pubbliche in un ambiente ospitato. Un'azienda manifatturiera può conservare progetti e dati operativi. Un gruppo di ricerca può conservare un set di dati che non può essere spostato con leggerezza. Un ospedale può usare servizi che toccano informazioni personali. Nessuno di questi esempi richiede un'interruzione drammatica o un romanzo di spionaggio per diventare serio. La domanda quotidiana è più semplice: chi ha autorità pratica su un sistema che è diventato parte della capacità di lavorare dell'organizzazione?
La legge e le linee guida europee trattano sempre più questa questione come una questione di prove, ruoli e passaggio da un fornitore all'altro, piuttosto che come una questione di vocabolario rassicurante. Il Data Act conferisce ai clienti diritti e ai fornitori obblighi riguardo al passaggio, ai dati esportabili e alle interfacce per i servizi di elaborazione dei dati. L'EDPS ha da tempo affermato che le istituzioni europee che usano servizi cloud restano responsabili dei propri obblighi di protezione dei dati. Il lavoro di ENISA sul rischio cloud indica il lock-in e il rischio legale come aspetti da valutare. Non sono strumenti identici e non creano una dottrina cloud unica. Insieme, indicano una direzione utile: il controllo deve essere descritto, non implicito.
Il segnaposto sulla mappa e il piano di controllo
Il linguaggio del cloud spesso rende più difficile vedere la distinzione. La parola cloud evoca un sistema meteorologico: vasto, distante e forse inevitabile. In pratica, un servizio cloud ha un piano di controllo e un piano operativo. Il piano operativo è dove viene eseguito un carico di lavoro, vengono conservati i dati, vengono elaborate le richieste e vengono restituiti i risultati. Il piano di controllo è l'insieme dei meccanismi attraverso cui vengono gestite le identità, modificate le policy, aggiornato il software, assegnata la capacità, fornito il supporto, recuperati i documenti e arrestati o ripristinati i sistemi. Entrambi i piani possono essere tecnicamente distribuiti. Entrambi possono attraversare i confini organizzativi.
Una dichiarazione sulla localizzazione di solito parla prima di tutto del piano di lavoro. Può indicare dove si trova un particolare archivio di dati, una macchina virtuale o una regione. Queste informazioni dovrebbero essere abbastanza specifiche da essere utili. Dovrebbero indicare cosa coprono, a quali categorie di dati si riferiscono, come vengono comunicate le modifiche e se backup, log, informazioni di supporto e dati derivati seguono la stessa regola. Un'affermazione che dice semplicemente Europa, senza un confine, è un punto di partenza per una domanda, non una risposta. L'Europa è un luogo vasto e l'architettura dei servizi è ricca di eccezioni.
Il piano di controllo pone una serie diversa di domande. Chi può creare o rimuovere un amministratore? Chi approva un intervento di emergenza? Chi gestisce il servizio di identità? Chi può vedere le informazioni diagnostiche? Quale azienda mantiene il software che fa funzionare la piattaforma? Quale entità legale riceve una richiesta da un'autorità? A quale subappaltatore è consentito gestire il supporto? Quale parte può modificare una descrizione del servizio o interrompere una funzionalità? Un cliente può accedere ogni giorno e non avere comunque alcuna via indipendente per rispondere a nessuna di queste domande.
Questo non significa che i clienti debbano aspettarsi di gestire ogni dispositivo fisico. Di solito non possono, e la maggior parte non ne ha bisogno. Il punto è rendere visibile la delega. L'operatività delegata può essere responsabile ed efficiente quando i poteri delegati sono definiti, monitorati e reversibili. Diventa un problema di sovranità quando il cliente ha solo un'etichetta contrattuale per il controllo, mentre il fornitore mantiene le persone, le interfacce, i registri e le conoscenze tecniche necessarie per esercitarlo. Un contratto che non può essere usato nella pratica è un oggetto decorativo con una buona tipografia.
Per un acquirente, la conseguenza pratica è semplice. Mantenete la domanda sulla localizzazione. Aggiungete accanto la domanda sul controllo. Chiedete dove risiede il carico di lavoro, poi chiedete chi può modificarne le condizioni. Chiedete dove vengono elaborati i dati, poi chiedete chi può raggiungere la via amministrativa. Chiedete dove è conservato il backup, poi chiedete chi può ripristinarlo e sotto quale autorità. Le risposte possono essere soddisfacenti. Possono rivelare una dipendenza che deve essere accettata deliberatamente. Entrambi gli esiti sono migliori che scoprire che un segnaposto su una mappa stava facendo il lavoro di un modello operativo.
La proprietà non è un dettaglio amministrativo
La proprietà è talvolta trattata come un dibattito separato su bandiere, borse valori e orgoglio nazionale. È più concreta di così. La proprietà può determinare chi nomina il consiglio di amministrazione, chi approva una vendita, chi dirige gli investimenti, chi possiede la proprietà intellettuale, quali politiche di gruppo si applicano e quale entità decide in ultima istanza se un servizio rimane una linea di business. Un cliente non ha bisogno di una regola semplicistica secondo cui una sola struttura proprietaria è accettabile. Ha bisogno di conoscere la struttura prima di definire l'accordo indipendente.
L'organizzazione societaria influisce anche su ciò che significa una promessa del cloud. Un marchio può essere locale mentre il servizio è gestito da un'entità diversa. Una filiale europea può stipulare un contratto con un cliente europeo mentre un gruppo altrove fornisce software essenziale, operazioni di sicurezza, supporto, fatturazione, analisi dei dati o autorità esecutiva. Un partner locale può contribuire genuinamente con un prezioso lavoro di implementazione mentre dipende da una piattaforma che non può modificare. Nessuno di questi accordi è automaticamente improprio. Sono diversi accordi di controllo e non dovrebbero essere fatti apparire identici da un logo condiviso e un numero di telefono locale.
La domanda pertinente non è se un acquirente possa trovare un collegamento estero da qualche parte in una lunga catena di fornitura. La tecnologia moderna è interconnessa e i test di purezza non sono un metodo di approvvigionamento. La domanda è quando una dipendenza diventa decisiva. Quale entità può modificare il contratto? Quale entità controlla la proprietà intellettuale del servizio? Quale entità può assumere un impegno di supporto? Quale entità possiede le credenziali o le conoscenze necessarie per ripristinare la funzione? Quale entità può essere acquisita, sanzionata, riorganizzata o sottoposta a istruzioni in un modo che cambi la posizione del cliente? Sono queste le domande sul potere reale.
Anche la proprietà cambia. Un'acquisizione, un round di finanziamento, una ristrutturazione o un trasferimento interno possono alterare il quadro del controllo senza spostare un solo server. Una clausola sulla localizzazione scritta alla firma può rimanere fattualmente corretta mentre i fatti organizzativi attorno ad essa sono cambiati. Per questo un file cloud serio ha bisogno di un processo di gestione del cambiamento. Il cliente dovrebbe sapere quale modifica deve essere comunicata, chi valuterà il suo effetto, quali evidenze devono essere aggiornate e quale autorità può sospendere un nuovo flusso di dati mentre la valutazione è in corso. Non è un lavoro affascinante. Non lo è nemmeno controllare l'olio dell'auto, e forse è per questo che la gente se ne ricorda solo quando il motore protesta.
Nelle sue linee guida sul cloud del 2018, l'EDPS ha sottolineato che le istituzioni dell'UE restano responsabili dei propri obblighi di protezione dei dati quando utilizzano servizi di cloud computing e dovrebbero garantire un livello di protezione equivalente a quello di altri modelli infrastrutturali. Non è una richiesta che ogni istituzione possieda tutto. È un promemoria che esternalizzare una funzione non esternalizza il dovere di comprendere l'accordo. Il dovere rende la proprietà rilevante perché la responsabilità non può essere esercitata attraverso un diagramma che omette la parte con il potere pratico.
La portata giuridica non svanisce con un indirizzo europeo
La giurisdizione è spesso il livello più scomodo perché resiste alla risposta semplice. Un contratto può scegliere una legge applicabile e un tribunale. Queste scelte contano. Non fanno sparire altri poteri giuridici. La portata giuridica può seguire un'entità, uno stabilimento, un fornitore di servizi, un gruppo societario, una persona con accesso, un fornitore di hardware o la posizione e la natura di determinati dati. L'analisi esatta dipende dai fatti e dal diritto. Un post di un blog non può risolverla per un'organizzazione reale, e un modello di approvvigionamento non può sostituire una consulenza adeguata quando il rischio è materiale.
La disciplina utile è separare una questione giuridica da una dichiarazione geografica. Un data center nell'Unione Europea ci dice dove si trovano le apparecchiature. Non ci dice da solo quali entità possono essere obbligate, quali autorità potrebbero avanzare una richiesta, quale notifica è possibile, o se un fornitore ha obblighi ai sensi di un altro ordinamento giuridico. Trattare i due aspetti come equivalenti può produrre un falso senso di chiusura. L'acquirente può aver soddisfatto un requisito di residenza lasciando l'analisi giuridica del tutto non svolta.
Le linee guida finali dell'EDPB sull'interazione tra l'Articolo 3 del GDPR e il Capitolo V sui trasferimenti internazionali sono utili proprio perché resistono alle scorciatoie. Distinguono l'ambito territoriale del GDPR dalla questione se un'operazione di trattamento sia un trasferimento internazionale. Questa distinzione non fornisce una conclusione valida per ogni situazione cloud. Mostra però perché espressioni come con sede nell'UE o coperto dal GDPR non possono sostenere ogni inferenza giuridica che un acquirente voglia fare. L'analisi della protezione dei dati segue il trattamento effettivo e gli attori coinvolti.
Il Data Act porta una questione collegata nel fascicolo dei servizi cloud. Il suo capitolo VII riguarda l'accesso governativo internazionale illecito e il trasferimento di dati non personali detenuti nell'Unione. Il regolamento impone ai fornitori di servizi di trattamento dei dati di adottare misure tecniche, organizzative e legali adeguate, incluse misure contrattuali, nelle circostanze descritte dall'articolo 32. Non promette che un fornitore possa far sparire ogni richiesta esterna. Richiede una risposta disciplinata a un conflitto che non può essere dissolto con un termine di marketing.
Per i clienti, il lavoro immediato è una mappa delle evidenze. Identificare l'entità contraente, le entità fornitrici che gestiscono parti sostanziali del servizio, i luoghi in cui avvengono il trattamento dei dati e l'amministrazione, le giurisdizioni dichiarate, il canale per ricevere e contestare le richieste, le condizioni di notifica e la consulenza legale necessaria per il carico di lavoro specifico. Segnare ciò che è noto, ciò che è dichiarato dal fornitore, ciò che è impegnato contrattualmente e ciò che richiede ancora indagine. Una mappa con una data e una lacuna è più utile di una clausola di garanzia senza scadenza.
Il controllo operativo è il punto in cui una promessa diventa realtà
Il controllo operativo è la capacità di far compiere a un sistema un'azione, o di fermarla, attraverso un'autorità e un meccanismo definiti. Comprende cose ordinarie: creare un account, modificare una policy di rete, ruotare una chiave, ripristinare un backup, approvare una release, isolare un tenant, revocare un amministratore, ispezionare un log ed esportare un record. Nessuna di queste azioni è un certificato di sovranità. Insieme mostrano se cliente e fornitore hanno una divisione di responsabilità comprensibile.
Un accordo cloud è debole quando ogni azione rilevante si conclude con un'email a un indirizzo di supporto generico. Il supporto conta, e un supporto esperto può essere uno dei buoni motivi per usare un servizio gestito. Ma un'organizzazione critica dovrebbe distinguere tra un canale di supporto e un canale di autorità. Un canale di supporto è il modo in cui il fornitore aiuta. Un canale di autorità è il modo in cui il cliente può avviare, approvare, osservare e registrare un'azione di cui rimane responsabile. I due possono incontrarsi in un ticket. Non dovrebbero essere confusi.
Consideriamo un caso chiaramente ipotetico. Un consorzio di ricerca europeo utilizza un ambiente analitico ospitato per un progetto sensibile ma legittimo. Ha un contratto per la regione europea e una localizzazione documentata dei dati. Durante una revisione interna, il consorzio vuole sospendere una pipeline specifica, conservare i record associati e impedire che una nuova fonte di dati venga collegata fino alla fine della revisione. Le domande utili non sono se un operatore immaginario si comporti in modo eroico. Sono se il consorzio abbia un ruolo nominato in grado di ordinare la modifica, se la piattaforma esponga un meccanismo controllato, se l'azione sia registrata e se i flussi dipendenti siano visibili prima che l'interruttore venga usato.
L'ipotetico è volutamente tranquillo perché l'autorità ordinaria è il punto. Un servizio non deve guastarsi perché il cliente abbia bisogno di controllo. Una revisione della privacy, un cambio di finalità, una decisione di approvvigionamento, una controversia contrattuale, una preoccupazione di sicurezza o la partenza di un membro del personale possono tutti richiedere un'azione delimitata. Se nessuno sa chi possa intraprenderla, o se il cliente non può ispezionare cosa ha fatto l'azione, il problema non è che il cloud sia misterioso. Il problema è che il modello operativo non è mai stato completato.
Un buon controllo operativo non è necessariamente centralizzato. Una grande istituzione può ripartire le responsabilità tra un responsabile del servizio, un ruolo di sicurezza, una funzione di protezione dei dati, un team operativo e un fornitore. La ripartizione può ridurre il rischio che una sola persona prenda da sola una decisione dannosa. L'importante è che il confine dell'autorità sia leggibile. Ogni ruolo dovrebbe sapere cosa può avviare, cosa può approvare, cosa deve registrare, quando deve inoltrare e come l'organizzazione si riprende quando la persona abituale non è disponibile. Il cloud non è esentato dalla governance solo perché il suo pannello di controllo è ordinato.
La linea del subappaltatore fa parte del servizio
La maggior parte dei servizi cloud non è fornita da un'unica azienda che usa un unico edificio e un unico stack software. Possono essere coinvolti fornitori di infrastrutture, operatori di rete, servizi di sicurezza gestiti, partner di supporto, processori di pagamento, manutentori software, servizi di identità, produttori di hardware e subappaltatori specializzati. Una catena complessa non è prova di un fallimento. È un motivo per descrivere la catena. Il cliente deve sapere dove iniziano le dipendenze materiali, cosa gli è consentito fare e come verrà comunicato un cambiamento.
Il vocabolario di protezione dei dati di titolare e responsabile è utile qui, ma non dovrebbe diventare un sostituto della comprensione. Un elenco dei responsabili può identificare le organizzazioni che trattano dati personali per conto di un fornitore. Potrebbe non rispondere a ogni domanda operativa su fornitura software, supporto hardware, amministrazione remota, telemetria, risposta agli incidenti o autorità aziendale. Al contrario, un inventario tecnico può identificare i componenti ma omettere chi ha un obbligo contrattuale verso il cliente. Le due viste vanno lette insieme, non usate come documenti concorrenti.
La guida EDPS sul cloud raccomanda una chiara allocazione delle responsabilità e attenzione ai ruoli delle parti coinvolte nei servizi cloud. Questa preoccupazione pratica resta viva perché i modelli di consegna complessi possono creare l'impressione che la responsabilità sia evaporata nell'architettura. Non è così. Qualcuno decide ancora lo scopo di un trattamento. Qualcuno fissa ancora le condizioni tecniche. Qualcuno accetta ancora un subappaltatore. Qualcuno deve ancora spiegare cosa è successo quando un sistema cambia. La complessità può spiegare perché la risposta richiede tempo. Non rende la domanda irragionevole.
Esiste un test utile per la materialità. Se un fornitore sparisse dall'accordo domani, il servizio perderebbe una funzione di cui il cliente ha bisogno, perderebbe una proprietà di sicurezza, perderebbe l'accesso a un registro o perderebbe la capacità di migrare? Se la risposta è sì, quel fornitore appartiene alla mappa dei controlli. La mappa non deve esporre ogni resistore né rendere pubblica ogni relazione commerciale. Deve mostrare le dipendenze che cambiano la capacità del cliente di governare il lavoro. Una dipendenza nascosta non è un'astrazione intelligente. È una riunione futura con un tono leggermente diverso.
Il controllo dei subappaltatori dipende anche dal tempo. L'acquirente dovrebbe sapere come vengono introdotti nuovi responsabili e fornitori operativi materiali, quale preavviso viene dato, quale processo di obiezione o valutazione si applica e come viene registrato un cambiamento. Un elenco statico è meglio di nessun elenco. Un elenco aggiornato e verificabile è migliore perché riconosce che un servizio non è congelato alla firma. L'organizzazione non può governare le dipendenze di cui non le è stato detto che sono arrivate.
L'hardware ha una politica e una conseguenza operativa
È forte la tentazione di fermare l'analisi all'interfaccia software. Il servizio funziona, il cruscotto è nella lingua giusta, l'accordo cita una regione europea e l'infrastruttura sottostante sembra troppo remota per essere utile. Eppure l'hardware e la sua catena di supporto possono rivelarsi decisivi quando contano disponibilità, riservatezza, manutenzione, riparazione, capacità o continuità. La domanda non è se il cliente debba verificare ogni chip. La domanda è se il cliente sappia da quali dipendenze dipende il servizio scelto e cosa accade quando una di esse cambia.
È qui che la distinzione tra aspirazione sovrana e autosufficienza merita attenzione. L'Europa partecipa alle catene di approvvigionamento globali. Nessuna organizzazione seria può produrre ogni semiconduttore, cavo, server, componente firmware, sistema operativo e strumento all'interno di un unico perimetro di approvvigionamento. Né sarebbe una soglia sensata per ogni carico di lavoro. La sovranità pratica è la capacità di riconoscere la dipendenza, stabilire condizioni attorno ad essa, mantenere alternative dove servono ed evitare di fingere che un componente esterno indispensabile non sia indispensabile.
Le dipendenze hardware possono influire sul controllo del cloud attraverso l'allocazione della capacità, l'accesso alla manutenzione, gli aggiornamenti software, i percorsi di sostituzione e i componenti fidati. Possono anche influire sulla fattibilità di una migrazione. Un carico di lavoro costruito attorno a una particolare funzionalità gestita, a un ambiente acceleratore specifico o a un'integrazione non documentata può essere tecnicamente portabile solo nello stesso modo in cui un pianoforte è portabile quando qualcuno si offre di trasportarlo su per sei rampe di scale. Il sostantivo è corretto. Il piano è incompleto.
La valutazione del rischio cloud dell'ENISA è ormai una pubblicazione datata, ma la sua cautela su lock-in, rischio legale e perdita di controllo non è diventata fuori moda. Il vocabolario tecnico è cambiato più volte da quando è apparsa. La domanda di fondo non è cambiata: cosa perde il cliente se il servizio cambia, il rapporto termina o una dipendenza non si comporta come previsto? Una valutazione del rischio non richiede all'acquirente di rifiutare ogni servizio gestito. Chiede all'acquirente di associare conseguenze alle dipendenze prima che una dipendenza diventi un'emergenza.
Un file cloud attento all'hardware può restare proporzionato. Registrare l'architettura al livello che conta per il carico di lavoro. Identificare le dipendenze uniche e i punti unici di conoscenza operativa. Dichiarare i termini contrattuali che incidono su continuità e migrazione. Chiedere quale percorso di supporto sia necessario per gli aggiornamenti di sicurezza o il ripristino. Verificare se un ambiente sostitutivo richieda gli stessi componenti proprietari. L'obiettivo non è un catalogo da museo. È un quadro sobrio delle cose che devono restare disponibili perché l'organizzazione possa continuare a fare il suo lavoro.
L'uscita è una capacità, non un pulsante di download
La domanda sul cloud più rivelatrice è spesso cosa accade quando il cliente vuole andarsene. Andarsene può significare passare a un altro fornitore, riportare una funzione in un ambiente on-premises, cambiare l'architettura, ridurre il servizio o interromperlo. Un cliente può talvolta esportare un database e non riuscire comunque a riprendere il servizio. La funzione può anche dipendere da configurazione, identità, chiavi, log, autorizzazioni, automazione, modelli, materiale di valutazione, lineage dei dati, regole di integrazione e dalla conoscenza operativa che fa funzionare i pezzi insieme.
Il Data Act è insolitamente concreto su questo punto. Le sue disposizioni sul passaggio richiedono che i contratti stabiliscano diritti e obblighi relativi al passaggio e al trasferimento dei dati esportabili e degli asset digitali. Stabilisce un periodo transitorio massimo normale di 30 giorni di calendario dopo il periodo di preavviso pertinente, consentendo al contempo un periodo alternativo in casi definiti di non fattibilità tecnica, soggetto a condizioni. Affronta inoltre le interfacce aperte e l'interoperabilità. Il Regolamento offre agli acquirenti qualcosa di prezioso: una ragione legale per chiedere il percorso prima di averne bisogno.
I limiti sono altrettanto importanti. Il Data Act non rende trasferibile ogni risorsa digitale, non impone al fornitore di rivelare proprietà intellettuale protetta o segreti commerciali e non garantisce l'equivalenza funzionale a destinazione. Un fornitore può adempiere agli obblighi di legge mentre una migrazione resta difficile. Un acquirente può avere un diritto di esportazione ma non disporre delle persone, del budget o della destinazione necessari per esercitarlo. Per questo l'uscita va trattata come una capacità condivisa tra contratto, architettura e organizzazione, non come una promessa contenuta in una riga di un modulo d'ordine.
Un fascicolo di uscita credibile registra il tipo di servizio di destinazione, i dati e le risorse esportabili, i loro formati, la procedura per ottenerli, le condizioni di continuità previste, il periodo di recupero, le ipotesi sulla destinazione e le parti della funzione che non possono semplicemente spostarsi. Individua chi validerà l'usabilità del materiale esportato. Registra quali log e prove devono essere conservati. Nomina l'autorità che può accettare il passaggio o decidere che non è ancora sicuro completarlo. Tutto questo è meno entusiasmante di un annuncio di migrazione. Ma è molto più probabile che renda vero quell'annuncio.
I test contano. Un esercizio piccolo e circoscritto può rivelare se un formato è semplicemente disponibile o realmente utilizzabile, se un'identità può essere ricreata senza alterare le autorizzazioni, se una chiave può essere trasferita sotto la giusta autorità, se i registri conservano il loro significato e se un servizio ridotto può continuare mentre il servizio completo si sposta. Non è un'affermazione secondo cui ogni organizzazione deve provare ogni mese un'uscita completa dal cloud. L'ambito deve riflettere le conseguenze di un'interruzione. È un'affermazione secondo cui un'uscita mai testata è un'intenzione, non ancora un'opzione.
Cosa dovrebbe contenere una valutazione cloud europea
Una valutazione utile inizia nominando la funzione, non il fornitore. Quale lavoro ci si aspetta che il servizio supporti? Quali dati, registri, diritti, esigenze di continuità e conseguenze pubbliche sono coinvolti? Uno strumento di collaborazione a basso impatto e un sistema che conserva registri operativi sensibili non richiedono controlli identici. Partire dal carico di lavoro evita che un'organizzazione applichi una grande etichetta di sovranità a una decisione piccola e specifica, o che tratti un servizio critico come se fosse un altro abbonamento da ufficio.
Poi si formula una dichiarazione sulla localizzazione con un confine. Si indica dove si prevede che operi il piano di lavoro pertinente, quali categorie di dati copre, quali copie e diagnostiche sono incluse, quali trasferimenti sono consentiti, come viene comprovata la posizione e come vengono notificate le modifiche. Se il fornitore può fare solo una dichiarazione regionale generica, si registra questa limitazione. Un acquirente ha il diritto di distinguere tra un impegno preciso e una descrizione commerciale generale. La distinzione non è ostile. È ciò a cui servono i contratti.
Poi si crea una mappa di entità e autorità. Si registrano l'entità contraente, le entità del gruppo con un ruolo sostanziale, i responsabili del trattamento o subresponsabili nominati dove pertinente, i ruoli che possono amministrare il servizio, il percorso di escalation, le disposizioni su identità e chiavi e l'autorità del cliente che resta dopo l'esternalizzazione. Si includono le prove giuridiche e tecniche a sostegno di ogni voce. Non si scrive fornitore o cliente quando si conosce una specifica entità, ruolo o meccanismo. I sostantivi generici sono molto bravi a nascondere assenze specifiche.
Add a dependency map. This should include material software, hardware, network, support and integration dependencies, the change path for each, and the consequences of loss or alteration. It does not need to predict the future. It needs to make the current design challengeable. If a dependency is acceptable, record why. If it is not acceptable, state the refusal condition. If it is unknown, do not resolve the discomfort by calling it low risk. Unknown is a real status, and it often earns the next piece of work.
Finally, attach the exit and review record. Capture the applicable contractual provisions, export procedures, tests performed, gaps found, corrective actions, review date and events that trigger reassessment. The point is not to produce a perfect folder. It is to establish a living account of control that survives a staff change, a service update, a contract renewal and the day when somebody has to make an uncomfortable decision quickly. A report that cannot be updated becomes history with an invoice attached.
Che cosa può chiedere una committenza pubblica senza fingere di risolvere tutto
I committenti pubblici hanno un motivo particolare per insistere su queste evidenze, perché spesso detengono responsabilità che non terminano con la firma del contratto. Possono essere responsabili verso i cittadini, soggetti alle regole sulla trasparenza degli atti, responsabili di funzioni essenziali o tenuti a spiegare perché una decisione era ragionevole. Questo non significa che la committenza pubblica possa eliminare ogni dipendenza estera, né che una preferenza nazionale possa sostituire una valutazione tecnica. Significa che il bando può porre domande che rendono visibile l'assetto prima che diventi strutturale.
Un bando proporzionato può chiedere quali soggetti forniranno parti materiali del servizio, quali confini geografici e giuridici vengono dichiarati, il modello di ruolo e autorità, il processo di cambio subappaltatore, il percorso di supporto e gestione degli incidenti, le evidenze conservate per il cliente, la procedura di export e di migrazione, e le condizioni alle quali un cliente può sospendere, limitare o cessare l'uso. Può valutare la qualità delle risposte invece di premiare un aggettivo. Un fornitore che conosce il proprio modello operativo dovrebbe saperlo spiegare senza ricorrere a un linguaggio fumoso.
Ci sono dei compromessi. Più evidenze possono allungare una procedura. Alcuni requisiti possono ridurre il numero di offerte. Un piccolo fornitore può avere meno capacità di produrre documentazione elaborata anche quando il suo modello di controllo è solido. Un operatore storico può offrire un servizio tecnico eccellente ma un percorso di uscita che richiede negoziazione. Non sono argomenti per saltare le domande. Sono i fatti di cui un committente ha bisogno per decidere quale costo è accettabile: il costo delle evidenze e delle alternative oggi, o il costo della dipendenza domani.
Il lavoro della Commissione europea sulla sovranità del cloud ha reso visibile questa direzione in termini di appalti, ma i committenti non devono attendere un marchio universale. Possono definire la propria soglia di rischio e pretendere evidenze che le corrispondano. Una biblioteca pubblica, un'agenzia di ricerca, un dipartimento comunale e un operatore di infrastrutture critiche non useranno la stessa soglia. E non dovrebbero. Il criterio è che i requisiti seguano la funzione, siano pubblicati in modo equo, possano essere valutati in modo coerente e preservino la capacità del cliente di spiegare ciò che ha scelto.
Questa è la promessa più silenziosa della politica europea sul cloud. Può spostare la conversazione dal teatro delle nazionalità verso la gestione delle relazioni. La risposta europea non deve essere un'isola tecnologica sigillata. Può essere un mercato più maturo, in cui le affermazioni su localizzazione, controllo, diritto e uscita sono affermazioni distinte, sostenute da evidenze distinte. L'interdipendenza non scompare quando viene nominata. Diventa possibile decidere dove è tollerabile.
I controlli non si rispondono a vicenda
Vale la pena resistere a un'ultima scorciatoia. Una crittografia forte non risponde a una questione di proprietà. Le chiavi detenute dal cliente possono ridurre alcuni rischi di accesso specifici e rappresentare un controllo importante, ma da sole non stabiliscono chi gestisce il servizio, chi controlla la piattaforma, quali informazioni restano visibili nei metadati o se il cliente può spostare la funzione. Una buona clausola di uscita non risponde a una questione di giurisdizione. Una casa madre europea non risponde a una questione di supporto hardware. Ogni controllo ha un compito. Ciascuno dovrebbe essere valutato per il compito che svolge realmente.
È anche per questo che una decisione sul cloud dovrebbe poter dire "non basta" senza diventare teatrale. Un acquirente può ritenere adeguato l'impegno sulla localizzazione ma troppo vago l'avviso di modifica. Può accettare un subprocessore ma richiedere un percorso di autorità più chiaro. Può accettare una dipendenza da hardware estero insistendo su un piano di sostituzione documentato. Può decidere che un determinato servizio non è adatto a una determinata categoria di dati ma resta adatto a un'altra. La sfumatura non è un fallimento nel decidere. È la condizione per decidere sulla base delle evidenze piuttosto che del riconoscimento del marchio.
Il lavoro diventa più facile quando le evidenze restano vicine alla decisione. Non mettere la dichiarazione sulla localizzazione dei dati in un sistema, il contratto in un altro, la revisione degli accessi in una casella di posta e il piano di uscita nella memoria di qualcuno. Collega tutto alla scheda del servizio e assegna a quella scheda un responsabile. Quando un requisito cambia, l'organizzazione dovrebbe poter trovare le evidenze, identificare il confine interessato e decidere se il servizio può continuare. Questa è la governance nella sua forma meno appariscente e più utile.
Una breve nota da parte nostra
Il nostro rapporto The Sovereignty Illusion usa cinque lenti pratiche per una questione analoga: proprietà, tecnologia, capitale, infrastruttura ed esposizione legale. Questo è il nostro quadro di ricerca, non una classificazione giuridica e non una prova che un determinato servizio soddisfi le esigenze di un cliente. Il suo contributo utile è un'abitudine all'attenzione. Quando un'affermazione sul cloud sembra completa, chiediti quali di quelle lenti ha realmente coperto e quali restano fuori dall'inquadratura.
Questa abitudine plasma anche il modo in cui descriviamo il nostro lavoro. Un'affermazione di sovranità dovrebbe essere delimitata da distribuzione, contratto e responsabilità operativa, non gonfiata in una promessa che una pagina di prodotto non può mantenere. Il cliente, il carico di lavoro e il modello di controllo concordato decidono ancora cosa si può dire onestamente. In un campo pieno di grandi sostantivi, la sobrietà non è un inconveniente di marketing. Fa parte delle evidenze.
La domanda dopo il nome della città
La localizzazione europea resta una domanda che vale la pena porre. Può essere un requisito legale, un requisito operativo, una scelta di resilienza, una scelta di sicurezza fisica o un'espressione di responsabilità pubblica. Un acquirente non dovrebbe sentirsi in imbarazzo a chiedere dove gira un sistema. Dovrebbe semplicemente porre la domanda in compagnia. Chi possiede l'entità che conta? Chi ha l'autorità operativa? Quali ordinamenti giuridici possono raggiungere l'accordo? Quali subappaltatori e componenti sono rilevanti? Cosa può ispezionare, fermare, spostare e conservare il cliente?
Queste domande non rendono il cloud computing meno utile. Rendono l'uso del cloud computing più deliberato. Sostituiscono un'atmosfera di rassicurazione con un fascicolo che può essere esaminato. Danno ai fornitori una giusta opportunità di mostrare i controlli che hanno costruito e agli acquirenti un modo equo di distinguere un limite utile da un'affermazione vuota. Soprattutto, preservano la possibilità di cambiare rotta prima che una dipendenza si trasformi in un'accusa.
La questione del cloud europeo, quindi, non riguarda dove si trova il server. Riguarda dove si trova il controllo quando il sistema deve cambiare. Un data centre può essere parte della risposta. Un contratto europeo può essere parte della risposta. Un fornitore europeo può essere parte della risposta. La risposta diventa credibile solo quando l'organizzazione può seguire il percorso dal luogo alla proprietà, dalla proprietà alla portata giuridica, dalla portata giuridica all'autorità operativa, e dall'autorità a una via d'uscita testata. Quel percorso è meno memorabile di una bandiera accanto a un edificio. È anche il punto in cui inizia il lavoro.
Fonti
- Cloud Computing, Garante europeo della protezione dei dati. Utilizzato per la posizione di orientamento sul cloud dell'EDPS secondo cui le istituzioni dell'UE restano responsabili dei propri obblighi in materia di protezione dei dati e dovrebbero garantire una protezione equivalente.
- EDPB publishes three guidelines following public consultation, Comitato europeo per la protezione dei dati, 24 febbraio 2023. Utilizzato per l'ambito e lo scopo delle linee guida finali sull'articolo 3 del GDPR e sul capitolo V relativo ai trasferimenti internazionali.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Utilizzato per le disposizioni relative a cambio di fornitore, esportazione, continuità, interoperabilità e accesso da parte di governi stranieri per i servizi di trattamento dei dati.
- Cloud Computing Risk Assessment, Agenzia dell'Unione europea per la cibersicurezza. Utilizzato per l'impostazione della valutazione del rischio relativa a lock-in, rischio giuridico e perdita di controllo.
- The Sovereignty Illusion, Dweve. Utilizzato solo per il quadro di ricerca Dweve a cinque lenti dichiarato.