Europas sky-spørgsmål handler ikke om, hvor serveren står
En lokation kan være korrekt og stadig lade spørgsmålet stå åbent
Der er et velkendt øjeblik i en cloud-diskussion. Nogen spørger, hvor dataene vil blive opbevaret. En anden svarer med navnet på en europæisk by. Stemningen i rummet letter lidt. Svaret kan være fuldstændig præcist, og det kan betyde meget. Geografi påvirker latenstid, fysisk sikkerhed, elektricitet, robusthedsplanlægning, beskæftigelse, offentlig ansvarlighed og de juridiske ordninger omkring en tjeneste. En offentlig myndighed, der har behov for, at bestemte registre forbliver inden for et angivet territorium, har en legitim grund til at spørge. Problemet begynder, når bynavnet forventes at besvare alle andre spørgsmål i arrangementet.
En server står et sted. En tjeneste gør ikke. En tjeneste er et forhold mellem juridiske enheder, personer med administratorrettigheder, softwarekomponenter, hardwareleverandører, kontrakter, supportteams, netværk, krypteringsordninger, underleverandører og den kunde, der er afhængig af resultatet. Bygningen er en materiel del af det forhold. Den afslører ikke, hvem der kan udstede en privilegeret instruktion fra et andet sted, hvilken koncern der kontrollerer driftsselskabet, hvilken jurisdiktion der kan nå en udbyder, om en underdatabehandler er ændret, eller hvad kunden kan tage med sig, når kontrakten udløber.
Dette er ikke et argument imod europæiske datacentre eller europæiske udbydere. Det er et argument imod at lade et nyttigt svar udføre et arbejde, som det ikke kan udføre. Det europæiske cloud-spørgsmål er ikke, om en server kan placeres på europæisk jord. Det er, om organisationen, der bruger tjenesten, kan forstå og udøve tilstrækkelig kontrol over hele arrangementet til det arbejde, der er på spil. Lokation hører med i det svar. Den kan ikke være hele svaret, ligesom en virksomhedsadresse ikke fortæller os, hvem der har nøglerne til dens konti.
Forskellen betyder mest, hvor cloud'en udfører almindeligt, betydningsfuldt arbejde. En lokal kommune kan opbevare korrespondance, sagsakter og offentlige oplysninger i et hosted miljø. En producent kan opbevare design og driftsdata. En forskningsgruppe kan opbevare et datasæt, der ikke uden videre kan flyttes. Et hospital kan bruge tjenester, der berører personoplysninger. Ingen af disse eksempler kræver en dramatisk nedetid eller en spionroman for at blive alvorlige. Det daglige spørgsmål er enklere: hvem har praktisk myndighed over et system, der er blevet en del af organisationens evne til at arbejde?
Europæisk lovgivning og vejledning behandler i stigende grad dette som et spørgsmål om dokumentation, roller og skift frem for et spørgsmål om betryggende ordforråd. Dataforordningen giver kunder rettigheder og udbydere forpligtelser omkring skift, eksporterbare data og grænseflader for databehandlingstjenester. EDPS har længe sagt, at europæiske institutioner, der bruger cloud-tjenester, forbliver ansvarlige for deres databeskyttelsesforpligtelser. ENISA's cloud-risikoarbejde nævner lock-in og juridisk risiko som forhold, der skal vurderes. Disse er ikke identiske instrumenter, og de skaber ikke en enkelt cloud-doktrin. Sammen peger de i en nyttig retning: kontrol skal beskrives, ikke underforstås.
Kortnålen og kontrolplanet
Cloud-sprog gør ofte forskellen sværere at se. Ordet cloud antyder et vejrsystem: stort, fjernt og måske uundgåeligt. I praksis har en cloud-tjeneste et kontrolplan og et arbejdsplan. Arbejdsplanet er, hvor en arbejdsbyrde kører, data opbevares, anmodninger behandles, og resultater returneres. Kontrolplanet er det sæt af mekanismer, hvorigennem identiteter administreres, politikker ændres, software opdateres, kapacitet tildeles, support ydes, registre hentes, og systemer stoppes eller gendannes. Begge planer kan være teknisk distribuerede. Begge kan krydse organisatoriske grænser.
En lokaliseringserklæring handler som regel først om arbejdsplanet. Den kan sige, hvor en bestemt datalagring, virtuel maskine eller region befinder sig. Disse oplysninger bør være specifikke nok til at være nyttige. Den bør sige, hvad den dækker, hvilke datakategorier den vedrører, hvordan ændringer meddeles, og om sikkerhedskopier, logfiler, supportoplysninger og afledte data følger samme regel. En påstand, der blot siger Europa uden en afgrænsning, er et udgangspunkt for et spørgsmål snarere end et svar. Europa er et stort sted, og servicearkitekturer er glade for undtagelser.
Kontrolplanet stiller en anden række spørgsmål. Hvem kan oprette eller fjerne en administrator? Hvem godkender en nødindgriben? Hvem driver identitetstjenesten? Hvem kan se diagnostiske oplysninger? Hvilket firma vedligeholder den software, der får platformen til at fungere? Hvilken juridisk enhed modtager en henvendelse fra en myndighed? Hvilken underleverandør har lov til at håndtere support? Hvilken part kan ændre en servicebeskrivelse eller nedlægge en funktion? En kunde kan måske logge ind hver dag og stadig ikke have nogen uafhængig vej til at besvare nogen af dem.
Det betyder ikke, at kunderne skal forvente at betjene hver eneste fysiske enhed. Det kan de som regel ikke, og de fleste har ikke brug for det. Pointen er at gøre delegation synlig. Delegeret drift kan være ansvarlig og effektiv, når de delegerede beføjelser er definerede, overvågede og reversible. Det bliver et suverænitetsproblem, når kunden kun har en kontraktuel etiket for kontrol, mens udbyderen beholder de mennesker, grænseflader, registre og den tekniske viden, der er nødvendige for at udøve den. En kontrakt, der ikke kan bruges i praksis, er en dekorativ genstand med god typografi.
For en køber er den praktiske konsekvens ligetil. Behold lokaliseringsspørgsmålet. Tilføj kontrolspørgsmålet ved siden af. Spørg, hvor arbejdsbyrden ligger, og spørg derefter, hvem der kan ændre dens betingelser. Spørg, hvor dataene behandles, og spørg derefter, hvem der kan nå den administrative vej. Spørg, hvor sikkerhedskopien opbevares, og spørg derefter, hvem der kan gendanne den, og under hvilken myndighed. Svarene kan være tilfredsstillende. De kan afsløre en afhængighed, der bevidst skal accepteres. Begge udfald er bedre end at opdage, at en nål på et kort gjorde arbejdet for en driftsmodel.
Ejerskab er ikke en administrativ detalje
Ejerskab behandles nogle gange som en separat debat om flag, børser og national stolthed. Det er mere konkret end det. Ejerskab kan afgøre, hvem der udpeger bestyrelsen, hvem der godkender et salg, hvem der styrer investeringer, hvem der ejer intellektuel ejendom, hvilke koncernpolitikker der gælder, og hvilken enhed der i sidste ende beslutter, om en service forbliver en forretningsgren. En kunde har ikke brug for en forenklet regel om, at kun én ejerskabsstruktur er acceptabel. Den har brug for at kende strukturen, før den kalder arrangementet uafhængigt.
Virksomhedsorganisation påvirker også, hvad et cloud-løfte betyder. Et brand kan være lokalt, mens servicen drives af en anden enhed. Et europæisk datterselskab kan indgå kontrakt med en europæisk kunde, mens en koncern andre steder leverer essentiel software, sikkerhedsdrift, support, fakturering, dataanalyse eller ledelsesmyndighed. En lokal partner kan reelt bidrage med værdifuldt implementeringsarbejde, mens den afhænger af en platform, den ikke kan ændre. Ingen af disse arrangementer er automatisk upassende. De er forskellige kontrolarrangementer, og de bør ikke gøres til at se identiske ud af et fælles logo og et lokalt telefonnummer.
Det relevante spørgsmål er ikke, om en køber kan finde en udenlandsk forbindelse et eller andet sted i en lang forsyningskæde. Moderne teknologi er indbyrdes forbundet, og renhedstests er ikke en indkøbsmetode. Spørgsmålet er, hvor en afhængighed bliver afgørende. Hvilken enhed kan ændre kontrakten? Hvilken enhed kontrollerer tjenestens intellektuelle ejendom? Hvilken enhed kan afgive en supportforpligtelse? Hvilken enhed har de legitimationsoplysninger eller den viden, der er nødvendig for at genskabe funktionen? Hvilken enhed kan blive opkøbt, sanktioneret, omstruktureret eller instrueret på en måde, der ændrer kundens position? Det er spørgsmål om faktisk indflydelse.
Ejerskab ændrer sig også. Et opkøb, en finansieringsrunde, en omstrukturering eller en intern overdragelse kan ændre kontrolbilledet uden at flytte en eneste server. En lokaliseringsklausul skrevet ved underskriften kan forblive faktuel korrekt, mens de organisatoriske forhold omkring den har ændret sig. Derfor har en seriøs cloud-fil brug for en ændringsproces. Kunden bør vide, hvilken ændring der skal oplyses, hvem der skal vurdere dens virkning, hvilke beviser der skal opdateres, og hvilken myndighed der kan sætte en ny dataoverførsel i bero, mens vurderingen foretages. Det er ikke glamourøst arbejde. Det er det heller ikke at tjekke olien i en bil, hvilket måske er grunden til, at folk husker det, efter motoren har klaget.
I sine cloud-retningslinjer fra 2018 understregede EDPS, at EU-institutionerne forbliver ansvarlige for deres databeskyttelsesforpligtelser, når de bruger cloud-computing-tjenester, og at de bør sikre et beskyttelsesniveau svarende til andre infrastrukturmodeller. Det er ikke et krav om, at alle institutioner skal eje alt. Det er en påmindelse om, at outsourcing af en funktion ikke outsourcer pligten til at forstå arrangementet. Pligten gør ejerskab relevant, fordi ansvar ikke kan udøves gennem et diagram, der udelader den part med den praktiske magt.
Juridisk rækkevidde slettes ikke af en europæisk adresse
Jurisdiktion er ofte det mest ubehagelige lag, fordi det modstår det simple svar. En kontrakt kan vælge en lovgivning og en domstol. Disse valg betyder noget. De får ikke andre juridiske beføjelser til at forsvinde. Juridisk rækkevidde kan følge en enhed, en etablering, en tjenesteudbyder, en koncern, en person med adgang, en hardwareleverandør eller placeringen og arten af bestemte data. Den præcise analyse afhænger af fakta og jura. Et blogindlæg kan ikke afgøre det for en reel organisation, og en indkøbsskabelon kan ikke erstatte ordentlig rådgivning, hvor risikoen er væsentlig.
Den nyttige disciplin er at adskille et juridisk spørgsmål fra en geografisk erklæring. Et datacenter i Den Europæiske Union fortæller os, hvor udstyr er placeret. Det fortæller os ikke i sig selv, hvilke enheder der kan pålægges krav, hvilke myndigheder der kan fremsætte en anmodning, hvilken notifikation der er mulig, eller om en udbyder har forpligtelser under en anden retsorden. At behandle de to som ækvivalente kan skabe en falsk følelse af afslutning. Køberen kan have opfyldt et bopælskrav, mens den juridiske analyse er helt udeladt.
EDPB's endelige retningslinjer om samspillet mellem artikel 3 i GDPR og kapitel V om internationale overførsler er nyttige netop, fordi de modstår genveje. De adskiller GDPR's territoriale anvendelsesområde fra spørgsmålet om, hvorvidt en behandlingsaktivitet er en international overførsel. Denne sondring giver ikke en altomfattende konklusion om ethvert cloud-arrangement. Den viser dog, hvorfor vendinger som EU-baseret eller GDPR-dækket ikke kan bære enhver juridisk slutning, en køber måtte ønske at drage. Databeskyttelsesanalysen følger den faktiske behandling og de faktiske aktører.
Forordningen om data rejser et beslægtet spørgsmål i forbindelse med cloud-tjenester. Kapitel VII handler om ulovlig international statslig adgang til og overførsel af ikke-personoplysninger, der opbevares i Unionen. Forordningen kræver, at udbydere af databehandlingstjenester træffer passende tekniske, organisatoriske og retlige foranstaltninger, herunder kontraktuelle foranstaltninger, under de omstændigheder, der er beskrevet i artikel 32. Den lover ikke, at en udbyder kan få enhver ekstern anmodning til at forsvinde. Den kræver et disciplineret svar på en konflikt, som ikke kan ønskes væk med et marketingudtryk.
For kunder er det umiddelbare arbejde et evidenskort. Identificér den kontraherende enhed, de udbyderenheder, der driver væsentlige dele af tjenesten, de steder, hvor data og administration finder sted, de angivne jurisdiktioner, ruten for at modtage og udfordre anmodninger, underretningsbetingelserne og den juridiske rådgivning, der er nødvendig for den pågældende arbejdsbyrde. Markér, hvad der er kendt, hvad der er oplyst af leverandøren, hvad der er kontraktligt forpligtet, og hvad der stadig kræver undersøgelse. Et kort med en dato og et hul er mere nyttigt end et evigtgyldigt forsikringsafsnit.
Operationel kontrol er, hvor et løfte bliver virkeligt
Operationel kontrol er evnen til at få et system til at gøre noget eller stoppe med at gøre det gennem en defineret autoritet og mekanisme. Det omfatter dagligdags ting: oprette en konto, ændre en netværkspolitik, rotere en nøgle, gendanne en sikkerhedskopi, godkende en udgivelse, isolere en lejer, tilbagetrække en administrator, inspicere en log og eksportere en post. Ingen af disse handlinger er et suverænitetscertifikat. Tilsammen viser de, om kunden og udbyderen har en forståelig ansvarsfordeling.
En cloud-aftale er svag, hvor enhver væsentlig handling ender med en e-mail til en generisk supportadresse. Support betyder noget, og ekspertsupport kan være en af de gode grunde til at bruge en administreret tjeneste. Men en kritisk organisation bør skelne mellem en supportrute og en autoritetsrute. En supportrute er, hvordan udbyderen hjælper. En autoritetsrute er, hvordan kunden kan igangsætte, godkende, observere og registrere en handling, som kunden fortsat er ansvarlig for. De to kan mødes i en billet. De bør ikke forveksles.
Overvej et klart hypotetisk tilfælde. Et europæisk forskningskonsortium bruger et hostet analyse-miljø til et følsomt, men lovligt projekt. Det har en kontrakt for den europæiske region og en dokumenteret dataplacering. Under en intern gennemgang ønsker konsortiet at suspendere en bestemt pipeline, bevare de tilknyttede poster og forhindre, at en ny datakilde tilsluttes, indtil gennemgangen er afsluttet. De nyttige spørgsmål er ikke, om en imaginær operatør opfører sig heroisk. De er, om konsortiet har en navngiven rolle, der kan beordre ændringen, om platformen udstiller en kontrolleret mekanisme, om handlingen registreres, og om afhængige flows er synlige, før kontakten bruges.
Det hypotetiske tilfælde er bevidst stille, fordi almindelig autoritet er pointen. En tjeneste behøver ikke at fejle, for at kunden har brug for kontrol. En privatlivsgennemgang, ændring af formål, indkøbsbeslutning, kontraktstrid, sikkerhedsbekymring eller personalefratræden kan alle kræve en afgrænset handling. Hvis ingen ved, hvem der må foretage den, eller hvis kunden ikke kan inspicere, hvad handlingen gjorde, er problemet ikke, at cloud'en er mystisk. Problemet er, at driftsmodellen aldrig blev færdiggjort.
God operationel kontrol er ikke nødvendigvis centraliseret. En stor institution kan fordele ansvar mellem en serviceejer, en sikkerhedsrolle, en databeskyttelsesfunktion, et driftsteam og en leverandør. En opdeling kan reducere risikoen for, at én person alene træffer en skadelig beslutning. Det vigtige er, at autoritetsgrænsen er tydelig. Hver rolle skal vide, hvad den kan igangsætte, hvad den kan godkende, hvad den skal registrere, hvornår den skal eskalere, og hvordan organisationen kommer sig, når den sædvanlige person ikke er tilgængelig. Cloud er ikke fritaget for styring, fordi dens dashboard er pænt.
Underleverandørlinjen er en del af servicen
De fleste cloudtjenester leveres ikke af én virksomhed, der bruger én bygning og én softwarestack. De kan involvere infrastrukturudbydere, netværksoperatører, administrerede sikkerhedstjenester, supportpartnere, betalingsformidlere, softwarevedligeholdere, identitetstjenester, hardwareproducenter og specialiserede underleverandører. En kompleks kæde er ikke et tegn på fejl. Det er en grund til at beskrive kæden. Kunden skal vide, hvor væsentlige afhængigheder begynder, hvad de har lov til at gøre, og hvordan en ændring vil blive kommunikeret.
Databeskyttelsesvokabularet om dataansvarlig og databehandler er nyttigt her, men det bør ikke blive en erstatning for forståelse. En databehandlerliste kan identificere organisationer, der behandler personoplysninger på vegne af en leverandør. Den besvarer måske ikke alle operationelle spørgsmål om softwareforsyning, hardwaresupport, fjernadministration, telemetri, håndtering af sikkerhedshændelser eller virksomhedsautoritet. Omvendt kan en teknisk oversigt identificere komponenter, men udelade, hvem der har en kontraktlig forpligtelse over for kunden. De to perspektiver skal læses sammen i stedet for at blive brugt som konkurrerende dokumenter.
EDPS's cloudvejledning anbefaler en klar fordeling af ansvar og opmærksomhed på de involverede parters roller i cloudtjenester. Den praktiske bekymring er stadig skarp, fordi komplekse leveringsmodeller kan skabe indtryk af, at ansvaret er fordampet ind i arkitekturen. Det er det ikke. Nogen beslutter stadig formålet med en behandlingsaktivitet. Nogen fastsætter stadig de tekniske betingelser. Nogen accepterer stadig en underleverandør. Nogen skal stadig forklare, hvad der skete, når et system ændres. Kompleksitet kan forklare, hvorfor svaret tager tid. Det gør ikke spørgsmålet urimeligt.
Der er en nyttig test for væsentlighed. Hvis en leverandør forsvandt fra arrangementet i morgen, ville tjenesten så miste en funktion, som kunden har brug for, miste en sikkerhedsegenskab, miste adgang til en registrering eller miste evnen til at flytte? Hvis svaret er ja, hører den leverandør til i kontrolkortet. Kortet behøver ikke at afsløre hver eneste modstand eller gøre ethvert kommercielt forhold offentligt. Det skal vise afhængigheder, der ændrer kundens evne til at styre arbejdet. En skjult afhængighed er ikke en smart abstraktion. Det er et fremtidigt møde med en lidt anden tone.
Kontrol med underleverandører afhænger også af tid. Køberen skal vide, hvordan nye databehandlere og væsentlige operationelle leverandører introduceres, hvilket varsel der gives, hvilken indsigelses- eller vurderingsproces der gælder, og hvordan en ændring registreres. En statisk liste er bedre end ingen liste. En aktuel, gennemgåelig liste er bedre, fordi den anerkender, at en tjeneste ikke er frosset ved underskrift. Organisationen kan ikke styre de afhængigheder, den ikke er blevet informeret om er ankommet.
Hardware har en politik og en operationel konsekvens
Det er fristende at stoppe analysen ved softwaregrænsefladen. Tjenesten virker, dashboardet er på det rigtige sprog, aftalen nævner en europæisk region, og infrastrukturen under den virker for fjern til at være nyttig. Alligevel kan hardware og dens forsyningskæde være afgørende, når tilgængelighed, fortrolighed, vedligeholdelse, reparation, kapacitet eller kontinuitet betyder noget. Spørgsmålet er ikke, om en kunde bør revidere hver eneste chip. Spørgsmålet er, om kunden ved, hvilke afhængigheder der gør den valgte tjeneste mulig, og hvad der sker, når en af dem ændrer sig.
Det er her, skelnen mellem suveræn aspiration og selvforsyning fortjener omhu. Europa deltager i globale forsyningskæder. Ingen seriøs organisation kan fremstille hver halvleder, kabel, server, firmwarekomponent, operativsystem og værktøj inden for én indkøbsgrænse. Det ville heller ikke være en fornuftig tærskel for enhver arbejdsbyrde. Praktisk suverænitet er evnen til at genkende afhængighed, sætte betingelser omkring den, bevare alternativer, hvor de er nødvendige, og undgå at lade som om, at en uundværlig ekstern komponent ikke er uundværlig.
Hardwareafhængigheder kan påvirke cloudstyring gennem kapacitetsallokering, vedligeholdelsesadgang, softwareopdateringer, udskiftningsveje og betroede komponenter. De kan også påvirke gennemførligheden af en migrering. En arbejdsbyrde, der er bygget omkring en bestemt administreret funktion, et specifikt accelerator-miljø eller en udokumenteret integration, kan være teknisk bærbar kun på samme måde, som et klaver er bærbart, når nogen tilbyder at bære det op ad seks etager trapper. Navneordet er korrekt. Planen er ufuldstændig.
ENISA's cloudrisikovurdering er nu en ældre publikation, men dens advarsel om lock-in, juridisk risiko og tab af kontrol er ikke blevet gammeldags. Det tekniske ordforråd er ændret flere gange, siden den udkom. Det underliggende spørgsmål er ikke: hvad mister kunden, hvis tjenesten ændrer sig, forholdet ophører, eller en afhængighed ikke opfører sig som forventet? En risikovurdering kræver ikke, at en køber afviser enhver administreret tjeneste. Den beder køberen om at knytte konsekvenser til afhængigheder, før afhængigheden bliver en nødsituation.
En hardwarebevidst cloud-fil kan forblive proportionel. Registrer arkitekturen på det niveau, der betyder noget for arbejdsbyrden. Identificer eneafhængigheder og enkeltpunkter for operationel viden. Angiv de kontraktvilkår, der påvirker kontinuitet og migrering. Spørg, hvilken supportvej der er nødvendig for sikkerhedsopdateringer eller genoprettelse. Kontrollér, om et erstatningsmiljø kræver de samme proprietære komponenter. Målet er ikke et museumskatalog. Det er et nøgternt billede af de ting, der skal forblive tilgængelige, for at organisationen kan fortsætte sit arbejde.
Exit er en kapacitet, ikke en downloadknap
Det mest afslørende cloud-spørgsmål er ofte, hvad der sker, når kunden ønsker at forlade. At forlade kan betyde at flytte til en anden udbyder, bringe en funktion tilbage til et on-premises-miljø, ændre arkitekturen, reducere tjenesten eller stoppe den. En kunde kan nogle gange eksportere en database og stadig ikke være i stand til at genoptage tjenesten. Funktionen kan også afhænge af konfiguration, identiteter, nøgler, logfiler, tilladelser, automatisering, modeller, evalueringsmateriale, datalinjering, integrationsregler og den operationelle viden, der får delene til at fungere sammen.
Dataforordningen er usædvanligt konkret på dette punkt. Dens bestemmelser om skift kræver, at kontrakter fastsætter rettigheder og forpligtelser omkring skift og porting af eksporterbare data og digitale aktiver. Den fastsætter en normal maksimal overgangsperiode på 30 kalenderdage efter den relevante opsigelsesperiode, samtidig med at den tillader en alternativ periode i definerede tilfælde af teknisk uigennemførlighed, underlagt betingelser. Den adresserer også åbne grænseflader og interoperabilitet. Forordningen giver købere noget værdifuldt: en juridisk grund til at bede om ruten, før de har brug for den.
Grænserne er lige så vigtige. Dataforordningen gør ikke alle digitale aktiver overførbare, kræver ikke, at en udbyder videregiver beskyttet intellektuel ejendom eller forretningshemmeligheder, og garanterer ikke funktionel ækvivalens på en destinationsplatform. En udbyder kan opfylde sine juridiske forpligtelser, mens en migrering stadig er vanskelig. En køber kan have en eksportret, men mangle de medarbejdere, det budget eller den destination, der skal til for at bruge den. Derfor bør exit behandles som en kapacitet, der deles mellem kontrakt, arkitektur og organisation, snarere end et løfte fra en enkelt linje i en bestillingsformular.
En troværdig exit-fil registrerer den forventede servicetype, de data og aktiver, der kan eksporteres, deres formater, proceduren for at få adgang til dem, de forventede kontinuitetsbetingelser, hentningsperioden, destinationsforudsætningerne og de dele af funktionen, der ikke bare kan flyttes. Den identificerer, hvem der skal validere, at det eksporterede materiale kan bruges. Den registrerer, hvilke logfiler og beviser der skal bevares. Den navngiver den myndighed, der kan godkende skiftet eller beslutte, at det endnu ikke er sikkert at gennemføre. Dette er mindre spændende end en migrationsmeddelelse. Det gør langt mere sandsynligt, at meddelelsen bliver til virkelighed.
Test betyder noget. En lille, afgrænset øvelse kan afsløre, om et format blot er tilgængeligt eller faktisk brugbart, om en identitet kan genskabes uden at ændre tilladelser, om en nøgle kan overføres under den rette autoritet, om registreringer bevarer deres betydning, og om en reduceret service kan fortsætte, mens den fulde service flyttes. Dette er ikke en påstand om, at enhver organisation skal øve en komplet cloud-exit hver måned. Omfanget bør afspejle konsekvensen af en afbrydelse. Det er en påstand om, at en utestet exit er en intention, endnu ikke en mulighed.
Hvad en europæisk cloud-vurdering bør indeholde
En brugbar vurdering begynder med at navngive funktionen, ikke leverandøren. Hvilket arbejde forventes servicen at understøtte? Hvilke data, registreringer, rettigheder, kontinuitetsbehov og offentlige konsekvenser er involveret? Et samarbejdsværktøj med lav konsekvens og et system, der indeholder følsomme operationelle registreringer, behøver ikke identiske kontroller. At starte med arbejdsbyrden forhindrer en organisation i at anvende en stor suverænitetsetiket på en lille og specifik beslutning eller i at behandle en kritisk service, som om den var endnu et kontorabonnement.
Derefter skal du lave en lokationserklæring med en grænse. Angiv, hvor det relevante arbejdsplan forventes at operere, hvilke datakategorier det dækker, hvilke kopier og diagnostik der er inkluderet, hvilke overførsler der er tilladt, hvordan positionen dokumenteres, og hvordan ændringer meddeles. Hvis leverandøren kun kan komme med en bred regional erklæring, skal du registrere den begrænsning. En køber har lov til at skelne mellem en præcis forpligtelse og en generel kommerciel beskrivelse. Forskellen er ikke fjendtlig. Det er det, kontrakter er til for.
Dernæst skal du laver et kort over enheder og autoritet. Registrer den kontraherende enhed, gruppeenheder med en væsentlig rolle, navngivne behandlere eller underbehandlere, hvor det er relevant, de roller, der kan administrere servicen, eskaleringsvejen, identitets- og nøgleordningerne samt den kundemyndighed, der forbliver efter outsourcing. Inkluder de juridiske og tekniske beviser, der understøtter hver post. Skriv ikke udbyder eller kunde, hvor en bestemt enhed, rolle eller mekanisme er kendt. Generelle navneord er meget gode til at skjule specifikke fravær.
Tilføj et afhængighedskort. Det skal omfatte materiel software, hardware, netværk, support og integrationsafhængigheder, ændringsstien for hver enkelt, og konsekvenserne ved tab eller ændring. Det behøver ikke at forudsige fremtiden. Det skal gøre det nuværende design udfordrerbart. Hvis en afhængighed er acceptabel, skal du registrere hvorfor. Hvis den ikke er acceptabel, skal du angive afvisningsbetingelsen. Hvis den er ukendt, skal du ikke løse ubehaget ved at kalde den lav risiko. Ukendt er en reel status, og den fører ofte til det næste stykke arbejde.
Til sidst skal du vedhæfte udtrædelses- og gennemgangsregistret. Registrer de gældende kontraktbestemmelser, eksportprocedurer, udførte test, fundne huller, korrigerende handlinger, gennemgangsdato og begivenheder, der udløser en revurdering. Pointen er ikke at producere en perfekt mappe. Det er at etablere en levende kontrolkonto, der overlever en personaleforandring, en serviceopdatering, en kontraktfornyelse og den dag, hvor nogen skal træffe en ubehagelig beslutning hurtigt. En rapport, der ikke kan opdateres, bliver historie med en faktura vedhæftet.
Hvad offentlige indkøb kan spørge om uden at lade som om de løser alt
Offentlige købere har en særlig grund til at insistere på denne dokumentation, fordi de ofte har ansvar, der ikke ophører, når en kontrakt er underskrevet. De kan være ansvarlige over for borgerne, underlagt regler om offentlig adgang, ansvarlige for væsentlige funktioner eller forpligtet til at forklare, hvorfor en beslutning var rimelig. Det betyder ikke, at offentlige indkøb kan fjerne enhver udenlandsk afhængighed, eller at en national præference er en erstatning for en teknisk vurdering. Det betyder, at udbuddet kan stille spørgsmål, der gør arrangementet synligt, før det bliver indlejret.
Et forholdsmæssigt udbud kan spørge om de enheder, der vil levere væsentlige dele af tjenesten, de hævdede geografiske og juridiske grænser, rolle- og autoritetsmodellen, underleverandørændringsprocessen, support- og hændelsesvejen, den dokumentation, der opbevares for kunden, eksport- og skifteproceduren og de betingelser, hvorunder en kunde kan suspendere, begrænse eller afslutte brugen. Det kan bedømme kvaliteten af svarene i stedet for at belønne et adjektiv. En leverandør, der kender sin egen driftsmodel, bør kunne forklare den uden en tågemaskine.
Der er afvejninger. Mere dokumentation kan forlænge et udbud. Nogle krav kan reducere antallet af bud. En lille udbyder kan have mindre kapacitet til at producere omfattende dokumentation, selv når dens kontrolmodel er stærk. En etableret leverandør kan have en fremragende teknisk tjeneste, men en udtrædelsesvej, der skal forhandles. Det er ikke argumenter for at springe spørgsmålene over. Det er de fakta, en køber har brug for for at beslutte, hvilken omkostning der er acceptabel: omkostningen ved dokumentation og alternativer nu, eller omkostningen ved afhængighed senere.
Europa-Kommissionens arbejde med cloud-suverænitet har gjort denne retning synlig i udbudsmæssig forstand, men købere behøver ikke at vente på et universelt mærke. De kan specificere deres egen risikogrænse og kræve dokumentation, der passer til den. Et offentligt bibliotek, et forskningsagentur, en byafdeling og en operatør af kritisk infrastruktur vil ikke bruge samme tærskel. Det bør de ikke. Testen er, om kravene følger funktionen, offentliggøres retfærdigt, kan evalueres konsekvent og bevarer kundens evne til at forklare, hvad den har valgt.
Det er det mere stille løfte i europæisk cloud-politik. Den kan flytte samtalen væk fra nationalitetsteater og hen imod styring af relationer. Det europæiske svar behøver ikke at være en forseglet teknologisk ø. Det kan være et mere modent marked, hvor påstande om placering, kontrol, lov og udtrædelse er separate påstande, understøttet af separat dokumentation. Indbyrdes afhængighed forsvinder ikke, når den navngives. Det bliver muligt at beslutte, hvor den er tålelig.
Kontrollerne svarer ikke på hinanden
Det er værd at modstå én sidste genvej. Stærk kryptering besvarer ikke et ejerskabsspørgsmål. Kundeadministrerede nøgler kan reducere bestemte adgangsrisici og kan være en vigtig kontrol, men de fastlægger ikke i sig selv, hvem der driver tjenesten, hvem der kontrollerer platformen, hvilke oplysninger der forbliver synlige i metadata, eller om kunden kan flytte funktionen. En god udtrædelsesklausul besvarer ikke et jurisdiktionsspørgsmål. En europæisk modervirksomhed besvarer ikke et spørgsmål om hardwaresupport. Hver kontrol har en opgave. Hver enkelt bør vurderes ud fra den opgave, den faktisk udfører.
Det er også derfor, at en cloud-beslutning skal kunne sige "ikke nok" uden at blive teatralsk. En køber kan finde, at lokalitetsforpligtelsen er tilstrækkelig, men at ændringsmeddelelsen er for vag. Den kan acceptere en underdatabehandler, men kræve en klarere autoritetsvej. Den kan acceptere en udenlandsk hardwareafhængighed, mens den insisterer på en dokumenteret udskiftningsplan. Den kan beslutte, at en bestemt tjeneste er uegnet til en bestemt kategori af data, mens den forbliver egnet til en anden. Nuancering er ikke en manglende evne til at beslutte. Det er betingelsen for at beslutte på baggrund af dokumentation frem for genkendelse af varemærker.
Arbejdet bliver lettere, når dokumentationen holdes tæt på beslutningen. Læg ikke erklæringen om dataplacering i ét system, kontrakten i et andet, adgangsgennemgangen i en indbakke og udtrædelsesplanen i nogens hukommelse. Forbind dem med tjenesteposten og giv posten en ejer. Når et krav ændres, skal organisationen kunne finde dokumentationen, identificere den berørte grænse og beslutte, om tjenesten kan fortsætte. Det er governance på sit mindst glamourøse og mest nyttige niveau.
En kort note fra os
Vores rapport The Sovereignty Illusion bruger fem praktiske linser til et lignende spørgsmål: ejerskab, teknologi, kapital, infrastruktur og juridisk eksponering. Det er vores forskningsramme, ikke en juridisk klassifikation og ikke et bevis på, at en bestemt tjeneste opfylder en kundes behov. Dens nyttige bidrag er en vane med opmærksomhed. Når et cloud-løfte lyder komplet, så spørg, hvilke af disse linser det faktisk har dækket, og hvilke der forbliver uden for rammen.
Den vane former også, hvordan vi beskriver vores eget arbejde. Et suverænitetsløfte bør være afgrænset af implementering, kontrakt og driftsansvar, ikke pustet op til et løfte, som en produktside ikke kan holde. Kunden, arbejdsbyrden og den aftalte kontrolmodel afgør stadig, hvad der ærligt kan siges. I et felt fuld af store navneord er tilbageholdenhed ikke en markedsføringsmæssig gene. Det er en del af dokumentationen.
Spørgsmålet efter bynavnet
Europæisk placering er stadig værd at spørge om. Det kan være et juridisk krav, et operationelt krav, et valg om modstandsdygtighed, et valg om fysisk sikkerhed eller et udtryk for offentligt ansvar. En køber bør ikke være flov over at spørge, hvor et system kører. Det skal blot stille spørgsmålet i selskab. Hvem ejer den enhed, der betyder noget? Hvem har driftsautoritet? Hvilke retsordener kan nå arrangementet? Hvilke underleverandører og komponenter er væsentlige? Hvad kan kunden inspicere, stoppe, flytte og bevare?
Disse spørgsmål gør ikke cloud computing mindre nyttigt. De gør brugen af cloud computing mere bevidst. De erstatter en atmosfære af beroligelse med en fil, der kan gennemgås. De giver leverandører en fair mulighed for at vise de kontroller, de har bygget, og købere en fair måde at skelne en nyttig begrænsning fra et tomt løfte. Vigtigst af alt bevarer de muligheden for at ændre kurs, før en afhængighed bliver til en beskyldning.
Det europæiske cloud-spørgsmål handler derfor ikke om, hvor serveren står. Det handler om, hvor kontrollen ligger, når systemet skal ændres. Et datacenter kan være en del af svaret. En europæisk kontrakt kan være en del af svaret. En europæisk udbyder kan være en del af svaret. Svaret bliver først troværdigt, når organisationen kan følge ruten fra placering til ejerskab, fra ejerskab til juridisk rækkevidde, fra juridisk rækkevidde til driftsmyndighed, og fra myndighed til en afprøvet vej ud. Den rute er mindre mindeværdig end et flag ved siden af en bygning. Det er også her, arbejdet begynder.
Kilder
- Cloud Computing, Den Europæiske Tilsynsførende for Databeskyttelse. Anvendt for EDPS' cloud-vejledningsposition om, at EU-institutioner forbliver ansvarlige for deres databeskyttelsesforpligtelser og bør sikre tilsvarende beskyttelse.
- EDPB publishes three guidelines following public consultation, Det Europæiske Databeskyttelsesråd, 24. februar 2023. Anvendt for omfanget og formålet med de endelige retningslinjer om artikel 3 i GDPR og kapitel V om internationale overførsler.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Anvendt for bestemmelserne om skift, eksport, kontinuitet, interoperabilitet og international statslig adgang for databehandlingstjenester.
- Cloud Computing Risk Assessment, Den Europæiske Unions Agentur for Cybersikkerhed. Anvendt for risikovurderingsrammen for leverandørbinding, juridisk risiko og tab af kontrol.
- The Sovereignty Illusion, Dweve. Anvendt udelukkende for den offentliggjorte fem-linse Dweve-forskningsramme.