Întrebarea europeană despre cloud nu este despre locul serverului
O locație poate fi reală și totuși să lase întrebarea deschisă
Există un moment familiar în orice discuție despre cloud. Cineva întreabă unde vor fi stocate datele. Altcineva răspunde cu numele unui oraș european. Tensiunea din încăpere se mai atenuează. Răspunsul poate fi perfect corect și poate conta enorm. Geografia influențează latența, securitatea fizică, electricitatea, planificarea rezilienței, locurile de muncă, responsabilitatea publică și aranjamentele legale din jurul unui serviciu. O autoritate publică care are nevoie ca anumite înregistrări să rămână într-un teritoriu declarat are un motiv întemeiat să întrebe. Problema începe când numele orașului este chemat să rezolve toate celelalte întrebări din aranjament.
Un server se află undeva. Un serviciu nu. Un serviciu este o relație între entități juridice, persoane cu drepturi de administrator, componente software, furnizori de hardware, contracte, echipe de suport, rețele, aranjamente de criptare, subprocesatori și clientul care depinde de rezultat. Clădirea este o parte materială a acelei relații. Ea nu dezvăluie cine poate emite o instrucțiune privilegiată de altundeva, ce grup corporativ controlează compania care operează, ce jurisdicție poate ajunge la un furnizor, dacă un subprocesator s-a schimbat sau ce poate lua clientul cu el când contractul se încheie.
Acesta nu este un argument împotriva centrelor de date europene sau a furnizorilor europeni. Este un argument împotriva lăsării unui răspuns util să facă o muncă pe care nu o poate face. Întrebarea europeană despre cloud nu este dacă un server poate fi plasat pe pământ european. Este dacă organizația care folosește serviciul poate înțelege și exercita suficient control asupra întregului aranjament pentru munca în cauză. Locația face parte din acel răspuns. Nu poate fi întregul răspuns, mai mult decât ne spune adresa unei companii cine deține cheile conturilor sale.
Distincția contează cel mai mult acolo unde cloud-ul face muncă obișnuită, cu consecințe reale. O administrație locală poate deține corespondență, dosare de caz și informații publice într-un mediu găzduit. Un producător poate deține proiecte și date operaționale. Un grup de cercetare poate deține un set de date care nu poate fi mutat cu ușurință. Un spital poate folosi servicii care ating informații personale. Niciunul dintre aceste exemple nu necesită o pană dramatică sau un scenariu de spionaj pentru a deveni serios. Întrebarea zilnică este mai simplă: cine are autoritate practică asupra unui sistem care a devenit parte din capacitatea organizației de a lucra?
Legislația și orientările europene tratează tot mai mult aceasta ca pe o chestiune de dovezi, roluri și schimbare, nu ca pe o chestiune de vocabular liniștitor. Regulamentul privind datele oferă clienților drepturi și furnizorilor obligații legate de schimbare, date exportabile și interfețe pentru serviciile de procesare a datelor. EDPS a declarat de mult timp că instituțiile europene care folosesc servicii cloud rămân responsabile pentru obligațiile lor de protecție a datelor. Lucrările ENISA privind riscurile cloud numesc blocarea și riscul juridic drept aspecte de evaluat. Acestea nu sunt instrumente identice și nu creează o doctrină unică despre cloud. Împreună, ele indică o direcție utilă: controlul trebuie descris, nu subînțeles.
Marcatorul de pe hartă și planul de control
Limbajul cloud face adesea distincția mai greu de văzut. Cuvântul cloud sugerează un sistem meteorologic: mare, îndepărtat și poate inevitabil. În practică, un serviciu cloud are un plan de control și un plan de lucru. Planul de lucru este locul unde rulează o sarcină de lucru, unde sunt stocate datele, unde sunt procesate cererile și unde sunt returnate rezultatele. Planul de control este setul de mecanisme prin care sunt gestionate identitățile, sunt schimbate politicile, este actualizat software-ul, este alocată capacitatea, este oferit suportul, sunt recuperate înregistrările și sunt oprite sau restaurate sistemele. Ambele planuri pot fi distribuite tehnic. Ambele pot traversa granițe organizaționale.
O declarație de localizare vorbește de obicei mai întâi despre planul de lucru. Poate menționa unde se află un anumit depozit de date, o mașină virtuală sau o regiune. Această informație ar trebui să fie suficient de specifică pentru a fi utilă. Ar trebui să spună ce acoperă, ce categorii de date vizează, cum sunt notificate modificările și dacă backup-urile, jurnalele, informațiile de asistență și datele derivate respectă aceeași regulă. O afirmație care spune doar „Europa”, fără o graniță, este un punct de plecare pentru o întrebare, nu un răspuns. Europa este un loc mare, iar arhitectura serviciilor este cunoscută pentru excepții.
Planul de control pune o serie diferită de întrebări. Cine poate crea sau elimina un administrator? Cine aprobă o intervenție de urgență? Cine operează serviciul de identitate? Cine poate vedea informațiile de diagnosticare? Ce companie întreține software-ul care face platforma să funcționeze? Ce entitate juridică primește o cerere de la o autoritate? Ce subcontractor are voie să se ocupe de asistență? Ce parte poate modifica o descriere a serviciului sau poate întrerupe o funcție? Un client se poate autentifica în fiecare zi și totuși să nu aibă nicio cale independentă de a răspunde la oricare dintre aceste întrebări.
Acest lucru nu înseamnă că clienții ar trebui să se aștepte să opereze fiecare dispozitiv fizic. De obicei, nu pot, iar majoritatea nici nu au nevoie. Ideea este de a face delegarea vizibilă. Operarea delegată poate fi responsabilă și eficientă atunci când puterile delegate sunt definite, monitorizate și reversibile. Devine o problemă de suveranitate atunci când clientul are doar o etichetă contractuală pentru control, în timp ce furnizorul păstrează oamenii, interfețele, înregistrările și cunoștințele tehnice necesare pentru a-l exercita. Un contract care nu poate fi folosit în practică este un obiect decorativ cu o tipografie bună.
Pentru un cumpărător, consecința practică este simplă. Păstrați întrebarea despre localizare. Adăugați întrebarea despre control lângă ea. Întrebați unde se află volumul de lucru, apoi întrebați cine poate schimba condițiile acestuia. Întrebați unde sunt procesate datele, apoi întrebați cine poate ajunge la ruta administrativă. Întrebați unde este ținut backup-ul, apoi întrebați cine îl poate restaura și sub ce autoritate. Răspunsurile pot fi satisfăcătoare. Pot expune o dependență care trebuie acceptată în mod deliberat. Oricare dintre rezultate este mai bun decât să descoperiți că un pin pe o hartă făcea treaba unui model operațional.
Proprietatea nu este un detaliu administrativ
Proprietatea este uneori tratată ca o dezbatere separată despre steaguri, burse de valori și mândrie națională. Este mai concretă decât atât. Proprietatea poate determina cine numește consiliul de administrație, cine aprobă o vânzare, cine direcționează investițiile, cine deține proprietatea intelectuală, ce politici de grup se aplică și ce entitate decide în cele din urmă dacă un serviciu rămâne o linie de afaceri. Un client nu are nevoie de o regulă simplistă conform căreia doar o singură structură de proprietate este acceptabilă. Are nevoie să cunoască structura înainte de a numi aranjamentul independent.
Organizarea corporativă afectează, de asemenea, ce înseamnă o promisiune cloud. Un brand poate fi local, în timp ce serviciul este operat de o entitate diferită. O subsidiară europeană poate contracta cu un client european, în timp ce un grup din altă parte furnizează software esențial, operațiuni de securitate, asistență, facturare, analiză de date sau autoritate executivă. Un partener local poate contribui cu adevărat cu muncă valoroasă de implementare, depinzând în același timp de o platformă pe care nu o poate modifica. Niciunul dintre aceste aranjamente nu este automat nepotrivit. Sunt aranjamente de control diferite și nu ar trebui făcute să pară identice printr-un logo comun și un număr de telefon local.
Întrebarea relevantă nu este dacă un cumpărător poate găsi o legătură străină undeva într-un lanț lung de aprovizionare. Tehnologia modernă este interconectată, iar testele de puritate nu sunt o metodă de achiziție. Întrebarea este unde devine o dependență decisivă. Ce entitate poate modifica contractul? Ce entitate controlează proprietatea intelectuală a serviciului? Ce entitate poate face un angajament de suport? Ce entitate are acreditările sau cunoștințele necesare pentru a restabili funcția? Ce entitate poate fi cumpărată, sancționată, reorganizată sau instruită într-un mod care schimbă poziția clientului? Acestea sunt întrebări despre pârghia reală.
Proprietatea se schimbă și ea. O achiziție, o rundă de finanțare, o restructurare sau un transfer intern pot modifica tabloul controlului fără a muta un singur server. O clauză privind locația, redactată la semnare, poate rămâne corectă din punct de vedere factual, în timp ce faptele organizaționale din jurul ei s-au schimbat. De aceea, un dosar cloud serios are nevoie de un proces de modificare. Clientul ar trebui să știe ce modificare trebuie dezvăluită, cine va evalua efectul acesteia, ce dovezi trebuie actualizate și ce autoritate poate suspenda un nou flux de date în timp ce se face evaluarea. Nu este o muncă plină de strălucire. Nici verificarea uleiului într-o mașină nu este, ceea ce explică poate de ce oamenii își amintesc de ea abia după ce motorul se plânge.
În orientările sale din 2018 privind cloud computing, SEPD a subliniat că instituțiile UE rămân responsabile pentru obligațiile lor de protecție a datelor atunci când utilizează servicii de cloud computing și ar trebui să asigure un nivel de protecție echivalent cu cel al altor modele de infrastructură. Aceasta nu este o cerere ca fiecare instituție să dețină totul. Este o reamintire că externalizarea unei funcții nu externalizează și datoria de a înțelege aranjamentul. Această datorie face ca proprietatea să fie relevantă, deoarece responsabilitatea nu poate fi exercitată printr-o diagramă care omite partea care deține puterea practică.
Raza legală nu este ștearsă de o adresă europeană
Jurisdicția este adesea cel mai inconfortabil strat, deoarece rezistă răspunsului simplu. Un contract poate alege o lege aplicabilă și o instanță. Aceste alegeri contează. Ele nu fac să dispară alte puteri legale. Raza legală poate urma o entitate, o stabilire, un furnizor de servicii, un grup corporativ, o persoană cu acces, un furnizor de hardware sau locația și natura unor date specifice. Analiza exactă depinde de fapte și de lege. O postare pe blog nu poate rezolva acest lucru pentru o organizație reală, iar un șablon de achiziție nu poate înlocui consultanța adecvată acolo unde riscul este material.
Disciplina utilă este să separi o întrebare juridică de o declarație geografică. Un centru de date din Uniunea Europeană ne spune unde este situat echipamentul. Nu ne spune, prin el însuși, ce entități pot fi constrânse, ce autorități ar putea face o cerere, ce notificare este posibilă sau dacă un furnizor are obligații în temeiul unui alt ordin juridic. Tratarea celor două ca fiind echivalente poate produce un fals sentiment de închidere. Cumpărătorul poate fi satisfăcut o cerință de rezidență, lăsând în același timp analiza juridică complet neefectuată.
Orientările finale ale CEPD privind interacțiunea dintre articolul 3 din GDPR și capitolul V privind transferurile internaționale sunt utile tocmai pentru că rezistă scurtăturilor. Ele disting domeniul de aplicare teritorial al GDPR de întrebarea dacă o operațiune de prelucrare este un transfer internațional. Această distincție nu oferă o concluzie universală pentru fiecare aranjament cloud. Ea arată totuși de ce expresii precum bazat în UE sau acoperit de GDPR nu pot suporta orice inferență juridică pe care un cumpărător ar putea dori să o facă. Analiza protecției datelor urmează prelucrarea efectivă și actorii reali.
Regulamentul privind datele aduce o întrebare conexă în dosarul serviciilor cloud. Capitolul VII se referă la accesul guvernamental internațional nelegal și la transferul datelor care nu sunt date cu caracter personal, deținute în Uniune. Regulamentul impune furnizorilor de servicii de procesare a datelor să ia măsuri tehnice, organizatorice și legale adecvate, inclusiv măsuri contractuale, în circumstanțele descrise la articolul 32. Nu promite că un furnizor poate face să dispară orice solicitare externă. Impune un răspuns disciplinat la un conflict care nu poate fi eliminat printr-un termen de marketing.
Pentru clienți, munca imediată este o hartă a dovezilor. Identificați entitatea contractantă, entitățile furnizorului care operează părți materiale ale serviciului, locurile în care au loc stocarea datelor și administrarea, jurisdicțiile declarate, calea de primire și contestare a solicitărilor, condițiile de notificare și consilierea juridică necesară pentru volumul de lucru respectiv. Marcați ce este cunoscut, ce este declarat de furnizor, ce este angajat contractual și ce necesită încă investigație. O hartă cu o dată și un decalaj este mai utilă decât un paragraf de asigurare veșnic verde.
Controlul operațional este locul unde o promisiune devine reală
Controlul operațional este capacitatea de a face un sistem să facă ceva, sau să înceteze să o facă, printr-o autoritate și un mecanism definite. Include lucruri banale: crearea unui cont, schimbarea unei politici de rețea, rotirea unei chei, restaurarea unei copii de rezervă, aprobarea unei versiuni, izolarea unui chiriaș, retragerea unui administrator, inspectarea unui jurnal și exportarea unei înregistrări. Niciuna dintre aceste acțiuni nu este un certificat de suveranitate. Împreună arată dacă clientul și furnizorul au o împărțire inteligibilă a responsabilităților.
Un aranjament cloud este slab acolo unde fiecare acțiune importantă se termină cu un e-mail către o adresă generică de asistență. Asistența contează, iar asistența expertă poate fi unul dintre motivele întemeiate pentru a utiliza un serviciu gestionat. Dar o organizație critică ar trebui să distingă între o cale de asistență și o cale de autoritate. O cale de asistență este modul în care furnizorul ajută. O cale de autoritate este modul în care clientul poate iniția, aproba, observa și înregistra o acțiune pentru care rămâne responsabil. Cele două se pot întâlni într-un tichet. Nu ar trebui confundate.
Luați în considerare un caz clar ipotetic. Un consorțiu european de cercetare utilizează un mediu analitic găzduit pentru un proiect sensibil, dar legal. Are un contract pentru regiunea europeană și o locație documentată a datelor. În timpul unei revizuiri interne, consorțiul dorește să suspende o conductă specifică, să păstreze înregistrările asociate și să prevină conectarea unei noi surse de date până la finalizarea revizuirii. Întrebările utile nu sunt dacă un operator imaginar se comportă eroic. Ele sunt dacă consorțiul are un rol numit capabil să ordone schimbarea, dacă platforma expune un mecanism controlat, dacă acțiunea este înregistrată și dacă fluxurile dependente sunt vizibile înainte de utilizarea comutatorului.
Ipoteza este în mod deliberat liniștită pentru că autoritatea obișnuită este ideea principală. Un serviciu nu trebuie să eșueze pentru ca clientul să aibă nevoie de control. O revizuire a confidențialității, o schimbare a scopului, o decizie de achiziție, un litigiu contractual, o preocupare de securitate sau plecarea unui angajat pot necesita toate o acțiune limitată. Dacă nimeni nu știe cine o poate întreprinde, sau dacă clientul nu poate inspecta ce a făcut acțiunea, problema nu este că norul este misterios. Problema este că modelul operațional nu a fost niciodată finalizat.
Un control operațional bun nu este neapărat centralizat. O instituție mare poate împărți responsabilitățile între un proprietar de serviciu, un rol de securitate, o funcție de protecție a datelor, o echipă de operațiuni și un furnizor. Împărțirea poate reduce riscul ca o singură persoană să ia singură o decizie dăunătoare. Important este ca granița autorității să fie lizibilă. Fiecare rol ar trebui să știe ce poate iniția, ce poate aproba, ce trebuie să înregistreze, când trebuie să escaladeze și cum își revine organizația atunci când persoana obișnuită nu este disponibilă. Cloud-ul nu este scutit de guvernanță doar pentru că panoul său de control este ordonat.
Linia subcontractorilor face parte din serviciu
Majoritatea serviciilor cloud nu sunt livrate de o singură companie care folosește o singură clădire și un singur stivă software. Ele pot implica furnizori de infrastructură, operatori de rețea, servicii de securitate gestionată, parteneri de suport, procesatori de plăți, întreținători de software, servicii de identitate, producători de hardware și subcontractori specializați. Un lanț complex nu este o dovadă de eșec. Este un motiv pentru a descrie lanțul. Clientul trebuie să știe unde încep dependențele materiale, ce au voie să facă și cum va fi comunicată o schimbare.
Vocabularul de protecție a datelor privind operatorul și procesatorul este util aici, dar nu ar trebui să devină un substitut pentru înțelegere. O listă de procesatori poate identifica organizațiile care prelucrează date personale în numele unui furnizor. Este posibil să nu răspundă la fiecare întrebare operațională despre furnizarea de software, suport hardware, administrare de la distanță, telemetrie, răspuns la incidente sau autoritate corporativă. În schimb, un inventar de inginerie poate identifica componente, dar poate omite cine are o obligație contractuală față de client. Cele două viziuni trebuie citite împreună, nu folosite ca documente concurente.
Ghidul EDPS privind cloud-ul recomandă o alocare clară a responsabilităților și atenție la rolurile părților implicate în serviciile cloud. Această preocupare practică rămâne acută, deoarece modelele complexe de livrare pot crea impresia că responsabilitatea s-a evaporat în arhitectură. Nu s-a evaporat. Cineva decide în continuare scopul unei operațiuni de prelucrare. Cineva stabilește în continuare condițiile tehnice. Cineva acceptă în continuare un subcontractor. Cineva trebuie să explice în continuare ce s-a întâmplat atunci când un sistem se schimbă. Complexitatea poate explica de ce răspunsul durează. Nu face întrebarea nerezonabilă.
Există un test util pentru materialitate. Dacă un furnizor ar dispărea din aranjament mâine, serviciul ar pierde o funcție de care clientul are nevoie, ar pierde o proprietate de securitate, ar pierde accesul la o înregistrare sau ar pierde capacitatea de a se muta? Dacă răspunsul este da, acel furnizor aparține hărții de control. Harta nu trebuie să expună fiecare rezistor sau să facă publică fiecare relație comercială. Trebuie să arate dependențele care schimbă capacitatea clientului de a guverna munca. O dependență ascunsă nu este o abstractizare inteligentă. Este o întâlnire viitoare cu un ton ușor diferit.
Controlul subcontractorilor depinde și de timp. Cumpărătorul ar trebui să știe cum sunt introduși noii procesatori și furnizorii operaționali materiali, ce notificare este dată, ce proces de obiecție sau evaluare se aplică și cum este înregistrată o schimbare. O listă statică este mai bună decât nicio listă. O listă actuală și revizuibilă este mai bună, deoarece recunoaște că un serviciu nu este înghețat la semnare. Organizația nu poate guverna dependențele despre care nu i s-a spus că au apărut.
Hardware-ul are o politică și o consecință operațională
Este tentant să oprești analiza la interfața software. Serviciul funcționează, panoul de control este în limba corectă, acordul menționează o regiune europeană, iar infrastructura din spate pare prea îndepărtată ca să fie utilă. Totuși, hardware-ul și lanțul său de suport pot fi decisive atunci când contează disponibilitatea, confidențialitatea, mentenanța, repararea, capacitatea sau continuitatea. Întrebarea nu este dacă un client ar trebui să auditeze fiecare cip. Întrebarea este dacă clientul știe ce dependențe fac posibil serviciul ales și ce se întâmplă atunci când una dintre ele se schimbă.
Aici distincția dintre aspirația suverană și autosuficiență merită atenție. Europa participă la lanțuri globale de aprovizionare. Nicio organizație serioasă nu poate produce fiecare semiconductor, cablu, server, componentă de firmware, sistem de operare și unealtă într-un singur perimetru de achiziție. Nici nu ar fi un prag rezonabil pentru fiecare volum de lucru. Suveranitatea practică este capacitatea de a recunoaște dependența, de a stabili condiții în jurul ei, de a păstra alternative acolo unde sunt necesare și de a evita prefăcătoria că o componentă externă indispensabilă nu este indispensabilă.
Dependențele de hardware pot afecta controlul cloud prin alocarea capacității, accesul la mentenanță, actualizările de software, rutele de înlocuire și componentele de încredere. Ele pot afecta și fezabilitatea unei migrări. Un volum de lucru construit în jurul unei funcții gestionate specifice, al unui mediu de accelerare anume sau al unei integrări nedocumentate poate fi portabil din punct de vedere tehnic doar în același mod în care un pian este portabil atunci când cineva se oferă să îl care șase etaje pe scări. Substantivul este corect. Planul este incomplet.
Evaluarea riscurilor cloud a ENISA este acum o publicație mai veche, dar precauția sa privind blocarea, riscul juridic și pierderea controlului nu a devenit desuetă. Vocabularul tehnic s-a schimbat de mai multe ori de la apariția sa. Întrebarea de bază nu s-a schimbat: ce pierde clientul dacă serviciul se schimbă, relația se încheie sau o dependență nu se comportă conform așteptărilor? O evaluare a riscurilor nu cere cumpărătorului să respingă fiecare serviciu gestionat. Îi cere să atașeze consecințe dependențelor înainte ca dependența să devină o urgență.
Un fișier cloud conștient de hardware poate rămâne proporțional. Înregistrează arhitectura la nivelul care contează pentru volumul de lucru. Identifică dependențele unice și punctele unice de cunoaștere operațională. Menționează termenii contractuali care afectează continuitatea și migrarea. Întreabă ce cale de suport este necesară pentru actualizările de securitate sau recuperare. Verifică dacă un mediu de înlocuire necesită aceleași componente proprietare. Scopul nu este un catalog de muzeu. Este o imagine sobră a lucrurilor care trebuie să rămână disponibile pentru ca organizația să își poată continua activitatea.
Ieșirea este o capacitate, nu un buton de descărcare
Cea mai revelatoare întrebare despre cloud este adesea ce se întâmplă atunci când clientul vrea să plece. Plecarea poate însemna mutarea la alt furnizor, readucerea unei funcții într-un mediu on-premises, schimbarea arhitecturii, reducerea serviciului sau oprirea acestuia. Un client poate uneori să exporte o bază de date și totuși să nu poată relua serviciul. Funcția poate depinde și de configurare, identități, chei, jurnale, permisiuni, automatizare, modele, material de evaluare, proveniența datelor, reguli de integrare și cunoașterea operațională care face ca piesele să funcționeze împreună.
Regulamentul privind datele este neobișnuit de concret în acest punct. Dispozițiile sale privind schimbarea furnizorului cer ca contractele să stabilească drepturi și obligații legate de schimbare și portarea datelor exportabile și a activelor digitale. Acesta stabilește o perioadă normală maximă de tranziție de 30 de zile calendaristice după perioada relevantă de notificare, permițând în același timp o perioadă alternativă în cazuri definite de imposibilitate tehnică, sub rezerva anumitor condiții. De asemenea, abordează interfețele deschise și interoperabilitatea. Regulamentul oferă cumpărătorilor ceva valoros: un motiv legal să ceară ruta înainte de a avea nevoie de ea.
Limitele sunt la fel de importante. Data Act nu face transferabil orice activ digital, nu obligă un furnizor să dezvăluie proprietate intelectuală protejată sau secrete comerciale și nu garantează echivalență funcțională la destinație. Un furnizor poate respecta obligațiile legale, chiar dacă migrarea rămâne dificilă. Un cumpărător poate avea un drept de export, dar să îi lipsească oamenii, bugetul sau destinația necesare pentru a-l folosi. De aceea, ieșirea ar trebui tratată ca o capacitate distribuită între contract, arhitectură și organizație, nu ca o promisiune făcută printr-o singură linie dintr-un formular de comandă.
Un dosar de ieșire credibil consemnează tipul de serviciu țintă, datele și activele exportabile, formatele lor, procedura de obținere, condițiile preconizate de continuitate, perioada de recuperare, ipotezele privind destinația și părțile din funcție care nu pot fi mutate pur și simplu. Identifică cine va valida că materialul exportat este utilizabil. Consemnează ce jurnale și ce dovezi trebuie să supraviețuiască. Numește autoritatea care poate accepta comutarea sau poate decide că nu este încă sigur să fie finalizată. Acest lucru este mai puțin spectaculos decât un anunț de migrare. Dar este mult mai probabil să facă anunțul real.
Testarea contează. Un exercițiu mic și delimitat poate dezvălui dacă un format este doar disponibil sau efectiv utilizabil, dacă o identitate poate fi recreată fără a modifica permisiunile, dacă o cheie poate fi transferată sub autoritatea potrivită, dacă înregistrările își păstrează sensul și dacă un serviciu redus poate continua în timp ce serviciul complet se mută. Nu spunem că fiecare organizație trebuie să repete lunar o ieșire completă din cloud. Amploarea ar trebui să reflecte consecințele unei întreruperi. Spunem că o ieșire netestată este o intenție, nu încă o opțiune.
Ce ar trebui să conțină o evaluare europeană a cloudului
O evaluare utilă începe prin a numi funcția, nu furnizorul. Ce activitate ar trebui să susțină serviciul? Ce date, înregistrări, drepturi, nevoi de continuitate și consecințe publice sunt implicate? Un instrument de colaborare cu consecințe reduse și un sistem care deține înregistrări operaționale sensibile nu au nevoie de aceleași controale. Pornind de la volumul de lucru, organizația evită să aplice o etichetă amplă de suveranitate unei decizii mici și specifice sau să trateze un serviciu critic ca pe încă un abonament de birou.
Apoi, fă o declarație de localizare cu o graniță. Precizează unde se preconizează că va funcționa planul de lucru relevant, ce categorii de date acoperă, ce copii și diagnostice sunt incluse, ce transferuri sunt permise, cum este dovedită poziția și cum sunt notificate modificările. Dacă furnizorul poate face doar o declarație regională generală, consemnează această limitare. Un cumpărător are dreptul să facă distincție între un angajament precis și o descriere comercială generală. Distincția nu este ostilă. Este exact scopul contractelor.
Apoi, realizează o hartă a entităților și a autorităților. Consemnează entitatea contractantă, entitățile din grup cu un rol material, procesatorii sau subprocesatorii numiți, acolo unde este relevant, rolurile care pot administra serviciul, calea de escaladare, aranjamentele privind identitatea și cheile, precum și autoritatea clientului care rămâne după externalizare. Include dovezile legale și tehnice care susțin fiecare intrare. Nu scrie „furnizor” sau „client” acolo unde este cunoscută o anumită entitate, un anumit rol sau un anumit mecanism. Substantivele generale sunt foarte bune la ascunderea absențelor specifice.
Adăugați o hartă a dependențelor. Aceasta ar trebui să includă software-ul, hardware-ul, rețeaua, asistența și dependențele de integrare relevante, calea de modificare pentru fiecare dintre acestea și consecințele pierderii sau alterării lor. Nu este nevoie să prezică viitorul. Trebuie să facă designul actual ușor de contestat. Dacă o dependență este acceptabilă, notați motivul. Dacă nu este acceptabilă, precizați condiția de refuz. Dacă este necunoscută, nu rezolvați disconfortul numind-o risc scăzut. Necunoscut este un statut real și adesea conduce la următoarea sarcină de lucru.
În final, atașați registrul de ieșire și de revizuire. Includeți prevederile contractuale aplicabile, procedurile de export, testele efectuate, lacunele identificate, acțiunile corective, data revizuirii și evenimentele care declanșează reevaluarea. Scopul nu este să produceți un dosar perfect. Este să stabiliți un cont viu al controlului care să supraviețuiască unei schimbări de personal, unei actualizări de serviciu, unei reînnoiri de contract și zilei în care cineva trebuie să ia rapid o decizie dificilă. Un raport care nu poate fi actualizat devine istorie cu o factură atașată.
Ce poate cere achizițiile publice fără să pretindă că rezolvă totul
Cumpărătorii publici au un motiv special să insiste asupra acestor dovezi, deoarece dețin adesea responsabilități care nu se încheie la semnarea contractului. Pot fi răspunzători în fața cetățenilor, supuși regulilor privind documentele publice, responsabili pentru funcții esențiale sau obligați să explice de ce o decizie a fost rezonabilă. Aceasta nu înseamnă că achizițiile publice pot elimina orice dependență externă sau că o preferință națională poate înlocui o evaluare tehnică. Înseamnă că licitația poate pune întrebări care fac aranjamentul vizibil înainte ca acesta să devină încorporat.
O licitație proporțională poate cere entitățile care vor furniza părți esențiale ale serviciului, limitele geografice și juridice declarate, modelul de rol și autoritate, procesul de schimbare a subcontractorilor, ruta de asistență și de incidente, dovezile păstrate pentru client, procedura de export și de comutare și condițiile în care un client poate suspenda, limita sau înceta utilizarea. Poate puncta calitatea răspunsurilor, nu să recompenseze un adjectiv. Un furnizor care își cunoaște propriul model operațional ar trebui să îl poată explica fără fumigene.
Există compromisuri. Mai multe dovezi pot prelungi o achiziție. Unele cerințe pot reduce numărul de oferte. Un furnizor mic poate avea o capacitate mai redusă de a produce documentație elaborată chiar și atunci când modelul său de control este solid. Un furnizor existent poate avea un serviciu tehnic excelent, dar o cale de ieșire care necesită negociere. Acestea nu sunt argumente pentru a sări peste întrebări. Sunt faptele de care un cumpărător are nevoie pentru a decide ce cost este acceptabil: costul dovezilor și al alternativelor acum sau costul dependenței mai târziu.
Lucrările Comisiei Europene privind suveranitatea cloud-ului au făcut această direcție vizibilă în termeni de achiziții, dar cumpărătorii nu trebuie să aștepte un certificat universal. Își pot stabili propria limită de risc și pot cere dovezi care să se potrivească acesteia. O bibliotecă publică, o agenție de cercetare, un departament municipal și un operator de infrastructură critică nu vor folosi același prag. Nu ar trebui să o facă. Testul este dacă cerințele urmează funcția, sunt publicate corect, pot fi evaluate consecvent și păstrează capacitatea clientului de a explica ce a ales.
Aceasta este promisiunea mai liniștită a politicii europene privind cloud-ul. Poate muta conversația de la teatrul naționalității către guvernarea relațiilor. Răspunsul european nu trebuie să fie o insulă tehnologică sigilată. Poate fi o piață mai matură în care afirmațiile despre locație, control, lege și ieșire sunt afirmații separate, susținute de dovezi separate. Interdependența nu dispare atunci când este numită. Devine posibil să se decidă unde este tolerabilă.
Controalele nu își răspund unele altora
Merită să rezistăm unei ultime scurtături. Criptarea puternică nu răspunde la o întrebare de proprietate. Cheile deținute de client pot reduce anumite riscuri de acces și pot fi un control important, dar nu stabilesc prin ele însele cine operează serviciul, cine controlează platforma, ce informații rămân vizibile în metadate sau dacă clientul poate muta funcția. O clauză bună de ieșire nu răspunde la o întrebare de jurisdicție. Un părinte european nu răspunde la o întrebare de suport hardware. Fiecare control are un rol. Fiecare ar trebui evaluat pentru rolul pe care îl îndeplinește efectiv.
Acesta este și motivul pentru care o decizie privind cloudul ar trebui să poată spune „nu este suficient” fără să devină teatrală. Un cumpărător poate considera că angajamentul privind locația este adecvat, dar că notificarea de modificare este prea vagă. Poate accepta un subprocesator, dar cere o rută de autoritate mai clară. Poate accepta o dependență de hardware străin, insistând totodată pe un plan documentat de înlocuire. Poate decide că un anumit serviciu este nepotrivit pentru o anumită categorie de date, rămânând potrivit pentru alta. Nuanța nu este o eșec de a decide. Este condiția pentru a decide pe baza dovezilor, nu pe baza recunoașterii mărcii.
Munca devine mai ușoară când dovezile sunt păstrate aproape de decizie. Nu puneți declarația privind locația datelor într-un sistem, contractul în altul, revizuirea accesului într-o căsuță de e-mail și planul de ieșire în memoria cuiva. Legați-le de fișa serviciului și dați fișei un responsabil. Când o cerință se schimbă, organizația ar trebui să poată găsi dovezile, să identifice granița afectată și să decidă dacă serviciul poate continua. Aceasta este guvernanța la cea mai puțin spectaculoasă și cea mai utilă formă a ei.
O scurtă notă din partea noastră
Raportul nostru The Sovereignty Illusion folosește cinci lentile practice pentru o întrebare similară: proprietate, tehnologie, capital, infrastructură și expunere legală. Acesta este cadrul nostru de cercetare, nu o clasificare juridică și nu o dovadă că un anumit serviciu satisface nevoile unui client. Contribuția sa utilă este un obicei de atenție. Când o afirmație despre cloud sună completă, întrebați care dintre aceste lentile a acoperit-o efectiv și care rămân în afara cadrului.
Acest obicei modelează și modul în care ne descriem propria muncă. O afirmație de suveranitate ar trebui să fie delimitată de implementare, contract și responsabilitate operațională, nu umflată într-o promisiune pe care o pagină de produs nu o poate ține. Clientul, volumul de lucru și modelul de control agreat decid în continuare ce poate fi spus cu onestitate. Într-un domeniu plin de substantive mari, reținerea nu este un inconvenient de marketing. Este parte din dovezi.
Întrebarea după numele orașului
Locația europeană rămâne o întrebare care merită pusă. Poate fi o cerință legală, o cerință operațională, o alegere de reziliență, o alegere de securitate fizică sau o expresie a responsabilității publice. Un cumpărător nu ar trebui să se jeneze să întrebe unde rulează un sistem. Ar trebui pur și simplu să pună întrebarea în companie. Cine deține entitatea care contează? Cine are autoritate operațională? Ce ordine juridice pot ajunge la aranjament? Ce subcontractori și componente sunt materiale? Ce poate inspecta, opri, muta și păstra clientul?
Aceste întrebări nu fac cloud computingul mai puțin util. Ele fac utilizarea cloud computingului mai deliberată. Ele înlocuiesc o atmosferă de asigurare cu un dosar care poate fi revizuit. Ele oferă furnizorilor o oportunitate corectă de a arăta controalele pe care le-au construit, iar cumpărătorilor o modalitate corectă de a distinge o limită utilă de o afirmație goală. Cel mai important, ele păstrează posibilitatea de a schimba direcția înainte ca o dependență să devină o acuzație.
Întrebarea europeană privind cloud-ul nu este, așadar, despre locul unde se află serverul. Este despre locul unde se află controlul atunci când sistemul trebuie să se schimbe. Un centru de date poate fi o parte din răspuns. Un contract european poate fi o parte din răspuns. Un furnizor european poate fi o parte din răspuns. Răspunsul devine credibil doar atunci când organizația poate urma traseul de la locație la proprietate, de la proprietate la sfera juridică, de la sfera juridică la autoritatea operațională și de la autoritate la o cale de ieșire testată. Acest traseu este mai puțin memorabil decât un steag lângă o clădire. Tot aici începe și munca.
Surse
- Cloud Computing, Autoritatea Europeană pentru Protecția Datelor. Folosit pentru poziția EDPS privind orientările referitoare la cloud, conform căreia instituțiile UE rămân responsabile de obligațiile lor de protecție a datelor și ar trebui să asigure o protecție echivalentă.
- EDPB publishes three guidelines following public consultation, Comitetul European pentru Protecția Datelor, 24 februarie 2023. Folosit pentru domeniul de aplicare și scopul orientărilor finale privind articolul 3 din RGPD și transferurile internaționale din capitolul V.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Folosit pentru prevederile privind schimbarea furnizorului, exportul, continuitatea, interoperabilitatea și accesul guvernamental internațional pentru serviciile de prelucrare a datelor.
- Cloud Computing Risk Assessment, Agenția Uniunii Europene pentru Securitate Cibernetică. Folosit pentru cadrul de evaluare a riscurilor privind blocarea în sistem, riscul juridic și pierderea controlului.
- The Sovereignty Illusion, Dweve. Folosit exclusiv pentru cadrul de cercetare Dweve cu cinci lentile, astfel cum a fost dezvăluit.