jesper løffler

Stor Schrems II-guide: Status og svar på de 17 vigtigste spørgsmål

Der er blevet sagt og skrevet utroligt meget om Schrems II-sagen, siden den blev afsagt i juli sidste år, herunder af mig selv. Og fordi sagen har betydning for så mange, har nyhedsstrømmen om sagen været så omfattende, at det har været stort set umuligt at følge med i.

Jeg besluttede derfor for nyligt at lave et opslag på LinkedIn, hvor jeg opfordrede folk til at stille spørgsmål til sagen. Det har folk gjort, både på LinkedIn og mail, og nedenfor følger så et bud på de mest relevante spørgsmål med særlig fokus på cloud-løsninger, og et forsøg på kortfattede svar. Nogle svar har jeg selv klaret, men flere steder har jeg hentet hjælp fra andre kloge folk.

Og fordi jeg nu er advokat, er jeg nødt til at komme med et forbehold: Nedenstående udgør ikke juridisk rådgivning og dækker i øvrigt heller ikke tilnærmelsesvist samtlige aspekter og nuancer i denne komplekse sag. Nedenstående er et forsøg på at omsætte tusindvis af siders viden til en nogenlunde overskuelig FAQ, og så er der links til selvstudie for de nørdede.

Her er spørgsmålene, som besvares i det følgende:
• 1: Hvad er "Schrems II"?
• 2: Hvorfor er sagen så kompleks?
• 3: Hvad er status pt.?
• 4: Hvad er det for “6 steps” jeg ifølge EDPB skal gennemgå for at leve op til Schrems II?
• 5: Hvad er “en overførsel ud af EU”?
• 6: Hvilke "overførselsgrundlag" findes der?
• 7: Hvilke “supplerende foranstaltninger” findes der?
• 8: Man hører hele tiden om kryptering som en mulig løsning, men hvordan gør man det i praksis?
• 9: Hvorfor er der så meget fokus på USA? Og er det egentlig i sig selv ulovligt at bruge en US-baseret cloudleverandør, selv hvis denne lover at holde data i EU?
• 10: Er det ikke lidt hyklerisk, at vi her i EU er så kritiske overfor USA?
• 11: Så, hvad er det helt præcist, jeg skal gøre lige nu?
• 12: Hvordan finder jeg ud af, hvorvidt min cloud-leverandører overfører data ud af EU og dermed er ramt af Schrems II?
• 13: Er det ikke noget med, at der i EDPB's endelige anbefalinger er en "juridisk kattelem", så man i visse tilfælde kan slippe udenom Schrems II-udfordringerne?
• 14: Puha, det er godt nok komplekst og træls, og vi sidder jo alle sammen og opfinder den dybe tallerken - er der ikke hjælp at hente fra de store brancheforeninger såsom Dansk Erhverv, Dansk Industri, IT Branchen, Kommunernes Landsforening, mv?
• 15: Æv. Men hvad gør Justitsministeriet og alle de andre offentlige myndigheder? Er der ikke hjælp og inspiration at hente der?
• 16: Æv igen. Men er der så slet ikke mere hjælp på vej?
• 17: Alt det her Schrems-ævl virker som et komplet spild af tid og penge - er der slet ikke noget positivt at sige om sagen?

Spørgsmål 1: Hvad er "Schrems II"?

Schrems II er det uofficielle navn på en afgørelse, som EU-Domstolen afsagde i juli 2020. Sagen er anlagt af privatlivsaktivisten Max Schrems, der helt tilbage i 2013 indgav en klage til det irske datatilsyn over Facebooks behandling af hans personoplysninger. En del af sagen handlede om, hvorvidt Facebooks overførsler af data til USA var i overensstemmelse med EU's regler om databeskyttelse, dengang "persondatadirektivet" fra 1995.

Da det irske datatilsyn samt domstolen i Irland var i tvivl om retsstillingen, sendte de nogle spørgsmål til EU Domstolen, og i oktober 2015 afsagde EU Domstolen så den første dom i sagskomplekset ("Schrems I"). EU Domstolen underkendte i denne første sag den særaftale, som EU og USA havde indgået med henblik på at muliggøre lovlige overførsler til US-virksomheder, kaldet "Safe Harbor". Få måneder efter underkendelsen af Safe Harbor indgik EU Kommissionen dog en ny politisk aftale med USA ("Privacy Shield"). Som Microsofts CLO, Brad Smith skrev i hans bog "Tools and weapons" tilbage i 2019 (før Schrems II-dommen):

“A data disaster had been averted, but the episode revealed how much had changed. For one thing, it showed that there is no such thing as a privacy island... However like the reactions to many near-disasters, the immediate response to the negotiation of the Privacy Shield was mostly a sigh of relief. It was another wake up call but again people hit the snooze-button. Data-flows could continue and companies could continue to do business. Most tech-companies and government officials postponed for another day deeper thinking about the longer term geo-political implications.”

Max Schrems fortsatte sagen med Facebook i Irland, og Facebook lykkedes med at trække sagen i langdrag, så vi skulle helt frem til sommeren 2020, før sagen igen endte hos EU Domstolen. Også denne gang blev den politiske aftale underkendt, men denne gang med en begrundelse, som har gjort det vanskeligt at lave samme nummer med en hurtig politisk aftale ligesom første gang. I samme afgørelse udtalte EU Domstolen også, at Facebooks andet argument for lovlige overførsler til USA, EU Kommissionens standardklausuler/SCC'er, kun er tilstrækkelige, hvis man har sikret, at de rent faktisk giver den nødvendige beskyttelse, også for uretmæssig adgang fra efterretningstjenester. Og det er så her, vi står i dag.

Links til selvstudie:

Spørgsmål 2: Hvorfor er sagen så kompleks?

En del af forklaringen skal findes i, at sagen og dens mange facetter går "på tværs" af traditionelle juridiske specialer: EU-Domstolen fortolker i Schrems II sagen GDPR , så her er eksperter i emner som databeskyttelsesret på hjemmebane. Men Schrems II-sagen handler også om EU's charter om grundlæggende rettigheder, og her er eksperter i EU-ret og menneskerettigheder mere på hjemmebane. Men Schrems II indebærer også, at man er nødt til at forholde sig til andres landes lovgivning, herunder særligt USA's regler for efterretningstjenester og straffeprocessuel bevissikring (fx FISA 702, E.O. 12.333, Cloud Act, PRISM, USPTREAM mv), hvilket ingen danske jurister er på hjemmebane i.

Det bedste bud ville nok være juridiske forskere indenfor offentlig ret og international straffeprocesret.

Men selv hvis man fandt en super-jurist, der er ekspert i alle emnerne (NB! Jeg er ikke en af dem, på trods af et CV, der bl.a. nævner en PhD i IT-ret, certificeret IT-advokat, ekstern DPO og +10 års undervisning i IT-ret og databeskyttelse), så ville denne jurist stadig være på glatis, fordi vedkommende også skal sætte sig ind i tekniske begreber såsom "Public Cloud", "Hyperscaler", "Follow-the-sun support", “Encryption at rest/ in transit", "HTTPS", "TLS 1.2", "AES 256", "BYOK", "Key Management System (KMS)", "Customer Lockbox", "Data segregation", "Hashing osv osv.

Og hertil kan man så lægge flere lag af kompleksitet, fx at emnet er storpolitisk, hvilket har indflydelse på, hvad forskellige aktører og organisationer melder ud, eller snarere, ikke melder ud om emnet.

Spørgsmål 3: Hvad er status pt.?

EU Domstolen afsagde afgørelsen i juli 2020, og siden da har vi ventet på mere vejledning fra officiel hånd til, hvordan vi skal agere. I de seneste måneder har vi fået det sidste på plads, herunder:

Selvom vi nu ikke længere kan slippe af sted med at sige, at vi mangler svar for at kunne gå i gang med at efterleve de nye skærpede krav, så er der formentlig lidt mere hjælp at hente forude, se til sidst i denne FAQ.

Links til selvstudie:

Spørgsmål 4: Hvad er det for “6 steps” jeg ifølge EDPB skal gennemgå for at leve op til Schrems II?

Ifølge EDPB's vejledning er man som dataansvarlig forpligtet til at gennemføre følgende 6 step:
Step 1: Fastlæg dine overførsler ud af EU
Step 2: Fastlæg hvilke overførselsgrundlag du, eller dine cloud-leverandører, anvender
Step 3: Vurdér overførselsgrundlagets effektivitet, herunder om der er problematisk lovgivning og det konkret finder anvendelse
Step 4-6: Implementér supplerende foranstaltninger og følg op på om de vedvarende er effektive.

I praksis er det dog lettere sagt end gjort, idet der i EDPB's vejledning gemmer sig en række vanskelige spørgsmål. De uddybes i de følgende spørgsmål.

Links til selvstudie:

Spørgsmål 5: Hvad er “en overførsel ud af EU”?

Step 1 i EDPB's vejledninger er at få kortlagt, hvornår du overfører personoplysninger ud af EU.

Fra et juridisk og teoretisk perspektiv har der historisk set været en del usikkerhed forbundet med, hvad der nærmere ligger i begrebet "overførsel", ikke mindst i relation til Cloud Computing. Dette blev da også påpeget af EU's egen databeskyttelsesvagthund (EDPS) helt tilbage i 2012, hvor han opfordrede til at indsætte en konkret definition i GDPR, som alene forelå i udkast på det tidspunkt:

"...there is no clear definition in the proposed Regulation of the notion of 'transfer' of personal data. This is problematic with respect to network environments such as cloud computing, where data are not only being actively transferred but are also being made available to a number of recipients located in various countries (often unknown to the cloud customer/end user). The EDPS has called for a clear definition of the notion of 'transfer' in his Opinion on the Data Protection Reform package"

Dette råd blev dog ikke fulgt, så usikkerheden består stadig. Der er links nedenfor til de nysgerrige, men hovedreglen er, at der er tale om en overførsel ud af EU, og dermed en behandling ramt af Schrems II-sagen, hvis en given løsning indebærer, at der rent teknisk er adgang til dine data fra et sted udenfor EU, fx i forbindelse med support - også selvom data ligger på EU-baserede servere. Det kan vi bl.a. læse i note 23 i EDPB's anbefalinger, hvor de kort og godt skriver:

"Please note that remote access by an entity from a third country to data located in the EEA is also considered a transfer. "

Se også Datatilsynets vejledning, hvor de skriver:

"Der vil som udgangspunkt være tale om en overførsel til et tredjeland, når de personoplysninger, du som dataansvarlig eller databehandler behandler, forlader EU/EØS eller gøres tilgængelige uden for EU/EØS. Det gælder, uanset om overførslen af personoplysninger sker til en virksomhed eller en myndighed.”

Links til selvstudie:

Spørgsmål 6: Hvilke "overførselsgrundlag" findes der?

Der findes adskillige overførselsgrundlag, men for cloud-løsninger er det primært EU-Kommissionens standardklausuler / SCC'erne, der er i spil. Kort fortalt er der tale om et standardaftaledokument, som man kan indarbejde i sit kontraktgrundlag, og dermed underlægge en aftalepart udenfor EU nogle forpligtelser lignende dem der ville gælde, hvis ikke-EU aftaleparten var underlagt GDPR.

Som Max Schrems har udtrykt det: Det svarer til, at vi i EU har lovregulering af, hvad kravene til økologi er, så hvis vi vil importere "økologiske" bananer fra fx Peru, så er vi nødt til at binde den peruvianske bananproducent til krav, som lever op til EU's lovkrav ift. økologisk produktion.

Det er dog relevant at nævne, at nogle cloud-kunder potentielt kan lovliggøre deres brug af en cloud-løsning med en af de øvrige regler i GDPR, fx et samtykke efter artikel 49. Det er en snæver regel, men en af EU Domstolens egne dommere har fremhævet, at artikel 49 ifølge hans opfattelse bliver anvendt for lidt.

Links til selvstudie:

Spørgsmål 7: Hvilke “supplerende foranstaltninger” findes der?

I Schrems II-sagen slog EU Domstolen fast, at SCC'erne, som bruges af næsten alle cloud-leverandører, kun er effektive til at opfylde deres formål, hvis deres indhold ikke bliver undergravet i praksis. Det kunne fx være problematisk lovgivning for efterretningstjenesters adgang til data. Og her kan vi så få brug for "supplerende foranstaltninger".

EDPB’s anbefalinger indeholder et stort tagselvbord med forslag til supplerende foranstaltninger i kategorierne ”contractual”, ”technical” og ”organisational” (Se Annex 2 i anbefalingerne)

Men! Hvis der er tale om ”problematisk lovgivning”, som EU Domstolen har udtalt at USA har, så bliver det store tagselvbord indskrænket til en lille, fin tapas-tallerken:

”Contractual and organisational measures alone will generally not overcome access to personal data by public authorities of the third country based on problematic legislation and/or practices” (para. 53)

Links til selvstudie:

Spørgsmål 8: Man hører hele tiden om kryptering som en mulig løsning, men hvordan gør man det i praksis?

Som det fremgår ovenfor, har alle cloud-leverandører et eller flere lag af kryptering, og særligt de helt store kan bryste sig af, at de fra et sikkerhedsmæssigt perspektiv kan levere state of the art-teknologier.

Men cloud leverandørens egen kryptering udgør kun i begrænset omfang en løsning ift. lande, hvor der er problemer med en for vidtgående adgang for efterretningstjenester (fx USA), jf. også EDPB:

“… where unencrypted personal data is technically necessary for the provision of the service by the processor, transport encryption and data-at-rest encryption even taken together, do not constitute a supplementary measure that ensures an essentially equivalent level of protection if the data importer is in possession of the cryptographic keys.” (para. 95)

Altså kan vi, i følge EDPB, kun bruge kryptering som løsning ift. risikoen for udlevering til amerikanske efterretningstjenester, hvis krypteringsnøglen er hos os selv eller en uafhængig tredjepart i EU. Obs! De store cloud-udbydere afviser kategorisk, at de på noget tidspunkt deler krypteringsnøgler med efterretningstjenester, se fx Microsofts Q&A her. Risikoen handler således alene om, hvorvidt cloud-udbyderen kan blive tvunget til at udlevere konkrete datasæt.

Brug af kryptering som løsning på Schrems II er således lettere sagt end gjort, særligt fra et praktisk perspektiv, og jeg har derfor hentet ekspert hjælp fra Michael Albek, direktør i virksomheden SecureDevice, der gav mig følgende svar:

"For at kunne bruge kryptering som løsning på Schrems II skal virksomheden have en krypteringsløsning, som dækker de forskellige use cases alle de tekniske krav i Schrems II. Denne type krypteringsløsning findes i dag, hvor man kan kryptere data at REST, transit, File/Folder og End-to-End og hvor virksomheden bruger deres egene krypteringsnøgler (BYOK – Bring-Your-Own-Key).
De store leverandører af SaaS løsninger tilbyder i dag at virksomheden kan BYOK, men når man snakker mindre SaaS løsninger, er dette ofte ikke tilfældet uden større tekniske ændringer fra leverandørens side. Så derfor er det ofte ikke i praksis muligt at bruge BYOK ved mindre SaaS løsninger.

Det er dog væsentligt at nævne, at der er andre grunde end Schrems II sagen til at arbejde med kryptering af data, idet det kan bidrage til en meget effektiv beskyttelse mod bl.a. hackere, selvfølglig forudsat at man har styr på sine nøgler!"

Links til selvstudie:

  • Der findes flere afgørelser fra andre EU-lande, hvor domstole er nået frem til at brugen af kryptering med nøglen i EU er tilstrækkeligt, fx nogle fanske sager samt en belgisk.

Spørgsmål 9: Hvorfor er der så meget fokus på USA? Og er det egentlig i sig selv ulovligt at bruge en US-baseret cloudleverandør, selv hvis denne lover at holde data i EU?

Der er to primære årsager til, at der generelt er mest fokus på USA, også i dette indlæg:

  • Amerikanerne er klart førende ift. hyperscale-cloudløsninger, og jeg vil gætte på, at 9 ud af 10 danske SaaS-løsninger er hostet hos enten Micrsoft Azure, Google GCP eller Amazon AWS. Dermed har de formentlig adgang til 90 % af verdens data.

  • Schrems II-sagen handlede om US-lovgivning, fordi den handlede om Facebook, og fordi vi rent faktisk ved noget om USA's lovgivning ift. efterretningstjenester som følge af Edward Snowdens afsløringer. I følge EU Domstolen USA's regler på området for vidtgående og med for lidt gennemsigtighed og kontrol. Sidst men ikke mindst har de stort set ingen regulering databeskyttelse på føderalt niveau, indtil videre i hvert fald.

Og nej, det er ikke i sig selv ulovligt at bruge en cloud-løsning, blot fordi der et sted i kæden er en amerikansk virksomhed indblandet: Hvis du kan få en US-cloudleverandør til at skrive i databehandleraftalen, at de aldrig overfører personoplysninger ud af EU (hvilket pt. er svært), så siger eksempel 10 i Datatilsynets vejledning, at kunden som udgangspunkt er på sikker grund.

Det skyldes, at US-cloududbyderen selv agerer dataansvarlig ifm. eventuelle anmodninger fra US-efterretningstjenester, og har dermed selv ansvaret for den juridiske “kattepine” de potentielt kan havne i.

Links til selvstudie:

Spørgsmål 10: Er det ikke lidt hyklerisk, at vi her i EU er så kritiske overfor USA?

Det kan man godt argumentere for, at det er.

En række EU-lande, inklusive Danmark, har i årevis fastholdt omfattende telelogning, selvom EU Domstolen adskillige gange har fremhævet, at dette (også) er i strid med EU's Charter om grundlæggende rettigheder. Og vores egen Højesteret her i Danmark har tidligere afgjort, at den danske anklagemyndighed kan ransage data, selvom de rent teknisk befinder sig på Facebooks servere i USA (U.2012.2614 H).

Igen kommer vi dog tilbage til, at vi her i EU har nogle regler, som giver os en langt bedre beskyttelse end tilfældet er i det amerikanske retssystem - i hvert fald på papiret.

Links til selvstudie:

.

Spørgsmål 11: Så, hvad er det helt præcist, jeg skal gøre lige nu?

Det afhænger af, om man er kunde eller leverandør:

  • Hvis du er kunde, bør du gennemgå de 6 steps i EDPB's vejledning. Når du først har fået kortlagt dine løsninger, vil du formentlig ret hurtigt mangle svar fra dine leverandører, og derfor kan du med fordel spørge dem, hvilke overvejelser de har gjort sig ift. Schrems II. Husk at være forstående og tålmodig - det er ikke let at være cloudleverandør i disse tider...

  • Hvis du er leverandør af cloud-løsninger, fx en dansk SaaS-leverandør, der bruger US-underleverandører såsom Azure, AWS, GCP, Twillio, Auth0 mv., så er du formentlig nødt til at trække i arbejdstøjet og forsøge at svare tilfredsstillende på spørgsmål fra dine kunder. Hvis du er heldig, er der hjælp at hente hos dine underleverandører, men nogle er mere hjælpsomme end andre.

Med henblik på at belyse den praktiske virkelighed for en dansk SaaS-leverandør, har jeg spurgt Dennis Benneballe Grade, complianceansvarlig hos OnlineCity A/S, hvad Schrems II-sagen har betydet for dem:

“For os har sagen fyldt rigtig meget det seneste år, ikke mindst foranlediget af spørgsmål fra en række af vores kunder. Vi har i hele forløbet prioriteret vores kunders krav, bekymringer og ønsker højt, og omvendt har vi også oplevet vores kunder være forstående overfor den komplekse og vanskelige situation, vi er blevet bragt i. Undervejs har vi forsøgt at være åbne og transparente, herunder ved at stille en Transfer Impact Assesment til rådighed for vores kunder. Efter offentliggørelsen af de endelige anbefalinger fra EDPB valgte vi dog i sidste ende at iværksætte en migrering fra Google Cloud til en EU-baseret udbyder. Ikke fordi vi så det som det som eneste udvej, men fordi vi ud fra en samlet vurdering anså det for den bedste langsigtede løsning for os.

Vi er stadigt tidligt i processen, og der er ingen tvivl om, at processen omkring at finde en ny udbyder, inkl. compliance-gennemgang, testing, osv., er meget langt og meget kompliceret. Vi har haft nogle udfordringer med at finde den rigtige udbyder, og er faktisk lidt kommet til den konklusion, at vi ikke kun har behov for én udbyder, men at vi vil gå multi-cloud-vejen, hvor vi kan sikre, at vi ikke kun fokuserer på GDPR som complianceramme, men også evt. anden, ikke-europæisk lovgivning. Vi vil arbejde hen imod et setup, hvor kan tilbyde de samme geolokationsmuligheder som vi arbejder hen imod nu med EU, men for andre regioner end EU. Eksempelvis er der en række privatlivs- og databeskyttelseslovgivninger, som spirer op rundt om i verden. Vi er dog overbeviste om, at det er muligt at finde en udbyder og et setup i EU, som både tilfredsstiller en virksomheds DevOps Engineer og udvikler, samtidig med den Compliance-ansvarlige og økonomichefen. Dog kræver dette både dedikerede kræfter, fuld fokus og forståelse af problemstillingen samt motivationen til at finde den bedste løsning for vores kunder. For os handler det om at vende alt dette til en langsigtet strategisk mulighed. Her er det så, at vi satser på vores dygtige teknikere og giver fuld tillid til deres evner og kompetencer. Dette må siges at være prisen for at vi ikke længere kan læne os tilbage og blive båret på de kæmpes skuldre (Google, Amazon, Microsoft, osv).”

Spørgsmål 12: Hvordan finder jeg ud af, hvorvidt min cloud-leverandører overfører data ud af EU og dermed er ramt af Schrems II?

Dette kan være vanskeligt at gennemskue. Men det mest simple er at kigge i databehandleraftalen, da GDPR kræver, at det skal fremgå, hvorvidt man som dataansvarlig (= cloud-kunde) godkender at data kan overføres ud af EU.

Og som verden ser ud lige nu, kan man ikke bruge nogen af de store US-cloud leverandører uden at denne godkendelse gemmer sig et sted (dybt nede) i deres vilkår.

Jeg har spurgt Ole Kjeldsen, CTO og teknologidirektør for Microsoft i Danmark, hvor det fremgår i Microsofts vilkår, og hvorfor det står der. Her er hans svar:

"Lad mig starte med at anerkende, at jeg fuldt ud forstår, at det for kunder indimellem kan virke uoverskueligt at finde frem til lige det rigtige dokument eller afsnit – det er en relativ kompliceret konstruktion, bl.a. fordi der er så mange forskellige typer af tjenester og så mange scenarier som aftalerne skal kunne omfatte. Derfor har jeg forsøgt i det såkaldte Cloud Governance whitepaper (side 26) at illustrere opbygningen i en model, som forhåbentlig kan guide den enkelte til nemmere at finde frem til det relevante.

Men ’kort’ fortalt – Når man anvender Microsoft Core Online Services som fx de der tilbydes i Microsoft Azure eller Microsoft 365, gælder det såkaldte ’Tillæg om databeskyttelse’ (på engelsk ”Microsoft Products and Services Data Protection Addendum”) forkortet “DPA”, som databehandleraftalen. Den er inkorporeret i Produktvilkårene og andre Microsoft-aftaler ved henvisning og angiver alle forpligtelser, for så vidt angår behandlingen og sikkerheden af både de data kunde skaber, opbevarer og behandler i Online Services og i øvrigt generelt personoplysninger ifm brugen. DPA’en er altså en del af det samlede aftalegrundlag mellem kunden og Microsoft, som bl.a. også omfatter Licensaftaler og Service Level Agreements. I selve DPA’en sker der yderligere henvisninger til detaljeret dokumentation i form af fx Revisionsrapporter, Servicebeskrivelser, Sikkerhedspolitikker etc. og alt det skal således ses i en sammenhæng for at få det fulde overblik. Så jo, der er skam i DPA’en et afsnit med overskriften ”Dataoverførsler og -placering” som beskriver de overordnede retningslinjer, men det skal læses i sammenhæng med den øvrige dokumentation. Det gør at nogle helt forståeligt kan miste overblikket over hvad der i praksis sker eller misforstå fx hvad Microsoft foretager sig ift overførsler – vi gør det desværre ikke i alle tilfælde helt nemt.

Men for at slå det helt fast: Kundens data opbevares altid i den geografi kunden har valgt – der kan blot i ifm driftsopgaver eller support ske fjernadgang fra usikre tredjelande og dermed ske en overførsel i juridisk forstand. Dette sker i øvrigt i ekstremt sjældne tilfælde, og formålet er altid at udføre en essentiel opgave så MS kan sikre at tjenesten er tilgængelig som kunden forventer og leve op til vore forpligtelser i DPA’en, at en MS medarbejder har brug for adgang som potentielt kunne give adgang til at se kundens data. Hvis det sker, og Microsofts egen såkaldte ’Lockbox’ procedure anser det for nødvendigt med den adgang, vil kunden modtage en såkaldt ’Customer Lockbox Request’ og først når den er accepteret kan opgaven udføres. Kunden har altså den fulde kontrol over disse scenarier, som i øvrigt naturligvis er underlagt beskrevne sikkerhedspolitikker, revision, EU SCCs etc.

Udover kundens indholdsdata, registrerer vi også en række personhenførbare data med hjemmel i det GDPR kalder ’Legitim forretningsinteresse’, når en kundes medarbejdere anvender en Online Service. Her pseudonymiseres og i vid udstrækning aggregeres disse data (efter ISO19944 standarden), inden de behandles af særligt personale i Microsofts driftssystemer i bl.a. USA. Disse data og behandlingen af dem er nødvendige for at kunne levere servicen til kunden, og det er (os) Microsoft, der er dataansvarlig for denne behandling, modsat når vi behandler kundens indholdsdata.”

Links til selvstudie:

Spørgsmål 13: Er det ikke noget med, at der i EDPB's endelige anbefalinger er en "juridisk kattelem", så man i visse tilfælde kan slippe udenom Schrems II-udfordringerne?

Jo, det er rigtigt. Vejledningens afsnit 43 giver mulighed for, at man kan se bort fra problematisk lovgivning (fx USA's), “…if you have no reason to believe that relevant and problematic legislation will be applied, in practice, to your transferred data and/or importer."

Det er dog ikke en blankocheck: "You will need to have demonstrated and documented through your assessment, where appropriate in collaboration with the importer, that the law is not interpreted and/or applied in practice so as to cover your transferred data and importer, also taking into account the experience of other actors operating within the same sector and/or related to similar transferred personal data and the additional sources of information described further below.”

Og det er så her, at det hele bliver lidt fjollet: Man kan, måske, lovligt bruge en US-baseret cloudløsning, hvis man bruger en hel masse tid på at sætte sig ind i nogle svært gennemskuelige amerikanske regler for efterretningstjenester, eller alternativt købe bistand hos advokater eller nogle af de legaltech-løsninger, som tilbyder "automatiserede Transfer Impact Assesments". Går man den vej, vil man eksempelvis kunne finde argumenter såsom at FISA 702 ikke finder anvendelse på en given SaaS-løsning, da dettte ifølge officielle dokumenter (se links nedenfor) forudsætter, at man kan søge på en "selector" såsom en emailadresse eller et telefonnummer.

Links til selvstudie:

Spørgsmål 14: Puha, det er godt nok komplekst og træls, og vi sidder jo alle sammen og opfinder den dybe tallerken - er der ikke hjælp at hente fra de store brancheforeninger såsom Dansk Erhverv, Dansk Industri, IT Branchen, Kommunernes Landsforening mv.?

Øjensynligt ikke ret meget, indtil videre. De synes også, at det er komplekst.

.

Spørgsmål 15: Æv. Men hvad gør Justitsministeriet og alle de andre offentlige myndigheder i Danmark og i EU? Er der ikke hjælp og inspiration at hente der?

Med undtagelse af enkelte myndigheder, der har haft modet til at være åbne, har langt de fleste indtil nu holdt kortene meget tæt ind til kroppen ift. hvordan de lovligt kan anvende løsninger såsom Office 365, Google Analytics mv.

Fsva. EU's instanser, er der dog formentlig inden længe noget inspiration at hente, da EU's egen GDPR-vagthund, EDPS, har iværksat en undersøgelse med fokus på EU-institutionernes brug af Amazon AWS samt Microsoft Azure og Office 365. For ganske få dage siden blev der "lækket" et slideshow fra EDPS, hvor der bl.a. stod, at "More guidance to EUIs - coming shortly: TIA Guidance - based on EDPB recommendations...".

Links til selvstudie:

Spørgsmål 16: Æv igen. Men er der så slet ikke mere hjælp på vej?

Jo, det er der, heldigvis. Selvom der ikke er nogen undskyldning for at vente med at gå i gang, så er der flere ting på vej, som kan gøre det lettere at bruge cloud-løsninger lovligt. Jeg har i forbindelse med oplæg om Schrems II lavet dette skema:

Illustration: Jesper Løffler

Af særlig relevans kan fremhæves punktet om at opnå international konsensus ift. spillereglerne for efterretningstjenesters adgang til persondata. Kernen i hele Schrems II-cirkusset er som bekendt, at USA’s regler for efterretningstjenester (ifølge EU Domstolen) er for vidtgående, og at registreredes rettigheder ikke er beskyttet i tilstrækkeligt omfang, og lige præcis dét emne er der ved at opnå konsensus om i flere internationale fora, fx GPA og OECD.

Links til selvstudie:

Spørgsmål 17: Alt det her Schrems-ævl virker som et komplet spild af tid og penge - er der slet ikke noget positivt at sige om sagen?

Jo, det er der faktisk.

Det kan godt være, at der for tiden bruges meget tid på jura og compliance, når der skal anskaffes nye cloud-løsninger, men det har også været tiltrængt. Det ligger således udenfor enhver tvivl, at der før sommeren 2020 var alt for få, som rent faktisk læste cloud-leverandørernes dokumentation - eller manglen på samme.

Og så har Schrems II-sagen været med til at skubbe på den politiske dagsorden, både i USA og i resten af verden. På et internationalt plan har sagen som sagt bl.a. ført til et arbejde mod fælles principper for efterretningstjenesters adgang til data (se spm. 16 ovenfor). Og i USA har sagen bl.a. været med til at skabe en ny bølge af politisk fokus på at USA skal indføre føderale regler om databeskyttelse. Så sent som i sidste uge, d. 15. november 2021, har et medlem af USA’s kongres endnu engang presset på at få sine kolleger til at vedtage regler med udtrykkelig henvisning til Schrems II:

”In July 2020 the ECJ struck down this agreement too, again due to the breadth of U.S. surveillance laws. Plainly put, the ECJ ruling highlights that EU citizens--and Americans--cannot easily challenge the uses of their data by our Intelligence Community using our judicial system. The decision harms U.S. companies by creating uncertainty in the market and restricting access to data that many small businesses, startups, and other companies rely on to remain competitive.
I have joined efforts by Representatives Lofgren and Massie to reform Section 702 of FISA to prohibit the warrantless search of online communications and prohibit the federal government from pressuring companies to build encryption “backdoors,'' and I intend to keep fighting for these needed reforms.
I urge my colleagues to pass legislative reforms to surveillance laws that respect privacy and enable American economic competitiveness, while also respecting our national security needs. We must devote our energies to achieving these objectives.”

Links til selvstudie:

Relateret indhold

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Debbie Winter

Dette er intet mindre end genialt, Jesper. Tusind tak🙏

Jeg vil mene, der er en tredje indirekte gruppe: Medarbejderne

Jeg var på mit arbejde inviteret til et møde i Zoom, som jeg ellers har holdt mig helt væk fra. Da jeg spurgte ind til datasikkerhed, fordi min arbejdsmail jo er mit fulde navn, fik jeg fornemmelsen af at de syntes jeg var meget besværlig ("ingen andre har spurgt ind til dette"). Det blev ikke ændret til Teams (som selvfølgelig ikke er meget bedre), og jeg meldte afbud til mødet Min chef foreslog dog, at jeg bare oprettede en anonym mail og brugte den til dette Zoom møde...

Da jeg kontaktede vores it support, fik jeg et link til Zooms privacy info på Zooms egen hjemmeside...

Jeg rykkede min support for at høre hvilken privacy MIN virksomhed havde mht Zoom, og så viste det sig at selv om Zoom var godkendt software i vores virksomhed, så kunne virksomheden ikke garantere privacy blev overholdt og dermed fik mit team besked på, at de fremover skulle holde sig fra Zoom

Som medarbejder kan man godt føle sig presset til at skulle bruge virksomhedens software, uden mulighed for at sige fra.

Hvordan bør situationer som denne håndteres og er der andre, der har lignende historier?

  • 15
  • 2
#2 Martin Dahl

Som Max Schrems har udtrykt det: Det svarer til, at vi i EU har lovregulering af, hvad kravene til økologi er, så hvis vi vil importere "økologiske" bananer fra fx Peru, så er vi nødt til at binde den peruvianske bananproducent til krav, som lever op til EU's lovkrav ift. økologisk produktion.

Og som tilstanden er lige nu, så kan økologiske "bananer" fra USA være sprøjtet med polonium-210, såfremt at en institution i en amerikansk stat eller føderationen vikårligt ønsker at sprøjte.

"Bananerne" bliver stadig mærket økologiske, og den amerikanske producent bliver straffet hvis de nævner at "bananerne" ikke længere er økologiske.

Såfremt at al data signeres asymmetrisk fra tryg grund, er der i teorien en garanti for at data i transit eller lager er originalt.

Men der er, som bekendt, ingen mulighed for at vide om data er kopieret, gennemset eller viderebragt til trediepart. Som f.eks. til en national konkurrerende virksomhed, en kløgtig forsikringsbranche eller et tredielands efterretningstjeneste.

Derfor er de europæiske økologiske varer sundere.

  • 2
  • 0
#3 Yoel Caspersen Blogger

Hvordan bør situationer som denne håndteres

Det er et rigtig godt spørgsmål, og svaret er desværre ret simpelt: Det afhænger af, hvor meget du holder af dit arbejde.

Husk på, at din holdning, set fra chefens synspunkt, oftest blot er en blandt mange - alle medarbejdere har holdninger til, hvordan tingene skal gøres, nogle mere højlydte end andre. Som chef er man nødt til at balancere en lang række modstridende hensyn, og det er umuligt at gøre alle glade på samme tid.

En konstruktiv medarbejder vil argumentere for, hvorfor der er et problem, og samtidig komme med løsningsforslag. En obstruktiv medarbejder vil blot brokke sig uden at bidrage med nogen løsningsforslag.

I sidste ende må chefen træffe en afgørelse, og så må man finde ud af, om man vil rette ind, eller om man hellere vil finde et andet sted at arbejde, som i højere grad matcher ens egne værdier. At udeblive fra et møde i trods lyder desværre som et skridt ud af en sti, der før eller siden vil ende med, at man forlader arbejdspladsen - så før man tager det skridt, bør man overveje, om det er en kamp, der er værd at tage.

  • 3
  • 0
#4 Peter Valdemar Mørch

Tusind tak for en meget fin arkikel.

I håbet om at gøre dette mere håndgribeligt, kunne vi så ikke gøre det helt konkret?

Vi forestiller os at jeg vil lave en virksomhed der sælger en SaaS løsning, hvor mine kunder kan gemme information om deres kontakter (det bliver nok ikke en stor success).

Jeg opretter en Postgresql database i en virtuel maskine i Azure og en Java app der viser en GUI med login og CRUD (Create, Retrieve, Update, Delete) operationer for kontaktoplysninger for min kundes 117 kontakter. Al kontakt info (navn, email, addresse, fødselsdato og evt. CPR nummer) gemmes i postgresql databasen i ukrypteret form til disk. Jeg bruger et helt standard Ubuntu Server 20.04 LTS image og en standard D2 instans i Azure og vælger "Region: North Europe". Alt med default værdier. Hvis der er noget kryptering er det kun HTTPS mod brugerens browser og hvad Azure ellers giver mig med sine defaultværdier.

Der må gerne være en Terms-of-service side som kunden skal godkende med en hvilken som helst tekst som gør at det kan godkendes.

Må man det? Kan man få et entydigt binært ja/nej når jeg nu har gjort det 100% konkret?

Hvorfor skal vi alle læse 79 PDF filer på 27 sider hver, som jeg som ikke-jurist har præcis 0% chance for at hive et binært ja/nej svar ud af.

Hvis jeg ikke kan få et binært ja/nej svar selvom det er 100% konkret, er det så fordi der er "nogen" der ikke tør sige højt og utvetydigt:

Man må ikke gemme eller tilgå personhenførbare data i en USA-nsk sky

fordi de økonmiske konsekvenser for samfundet er uoverskuelige? Er det her problemet ligger?

Og ellers har vi tekniske folk da ikke en chance med bruger- og forretningskrav på den ene side og jura på den anden.

Tilsvarende, kunne man også have omformuleret eksemplet til:

  • I en EC2 instance i AWS?
  • I en Google Cloud instans?
  • I en kubernetes pod i de tre miljøer?
  • I hostede databaser i de tre miljøer?

Eller:

  • Gemme backups i Amazon S3 buckets, så længe de er forsvarligt krypteret først her i DK og krypteringsnøglen kun kan findes på min egen laptop her i DK? (Det er vist entydigt ok)

Kunne man lave et par konkrete eksempler (evt. nogle andre) på noget man entydigt må og noget man entydigt ikke må, som ikke er til at fortolke eller misforstå? Det ville i hvert fald hjælpe mig...

  • 2
  • 0
#5 Martin Dahl

Jeg opretter en Postgresql database i en virtuel maskine i Azure

Data i Azure behandles og lagres af Microsoft.

Microsoft er underlagt amerikansk lov.

Ønsker en amerikansk efterretningstjeneste adgang til data, så skal Microsoft give adgang til data, og de bliver straffet for at fortælle at de har givet adgang.

Derfor er Schrems indvending noget af det vigtigste inden for sikkerhed og persondata.

Hvad nytter de hundredetusindvis af timer de danske virksomheder bruger på GDPR, Cookie samtykke, it-revision, sikkerhedsopdateringer osv. hvis andre bare kan tage data bag vores ryg?

Må man det? Kan man få et entydigt binært ja/nej

Og det er sagens kerne.

Alle der benytter Azure giver USA direkte adgang til al data og programmel on-demand. Det er allerede 100% sikkert og afklaret.

Men om man , i forhold til EUs GDPR, det er der hvor praktik, hykleri og idealisme klasher i Europa.

Du kan i princippet reducere dit eksempel til følgende:

Som virksomhed lagrer du een samtykkende persons skostørrelse på en storage instans i Azure. Må man det?

GDPR skelner ikke CPR fra skostørrelser, det er persondata. Og den skostørrelse er persondata, sålænge der er en applikation, som fortolkter den byte, som den persons skostørrelse. Og personsdata er persondata.

Må man lagre een enkelt byte persondata i Azure, AWS etc. jf. GDPR?

Svaret er det samme, som til dit eksempel.

  • 4
  • 0
#6 Peter Valdemar Mørch

Som virksomhed lagrer du een samtykkende persons skostørrelse på en storage instans i Azure. Må man det?

...

Svaret er det samme, som til dit eksempel.

Og svaret er?

Hvis vi ikke kan få et entydigt svar på det, hvad er så chancen for at finde en afgørelse man kan bruge til noget når det bliver lange mere kompliceret?

@Jesper eller andre: Må man det?

  • 0
  • 0
#7 Jesper Løffler Nielsen Blogger

Hej Peter. Jeg tror jeg vil nøjes med at svare:

Ja, formelt set skal gud og hver mand læse “79 PDF filer på 27 sider hver, som jeg som ikke-jurist har præcis 0% chance for at hive et binært ja/nej svar ud af.” Hvilket er fjollet. Men den her sag er også meget usædvanlig, og jeg er ret overbevist om, at det danske Datatilsyn i deres håndhævelse har forståelse for, at forskellige organisationer har forskellige forudsætninger. Så, hvis dit fiktive eksempel fx handler om en virksomhed med 20 ansatte, så tror jeg at tilsynet vil være meget large ift hvad de forventer af den kunde, som bruger CRM-systemet. Forestiller man sig i stedet at der var tale om Folketingets mødebooking-system, som er sat op med præcis samme Azure/ Ubuntu setup, så bliver baren nok sat lidt højere.

Og ja, det kan i visse tilfælde godt lade sig gøre at bruge US-baserede løsninger lovligt. Se fx svar på spm. 7, 8, 9 og 13.

  • 0
  • 1
#8 Peter Valdemar Mørch

Hej Jesper,

Tak for dit svar.

Så vi og f.eks. Datatilsynet er enige om at det ikke er til at finde ud af. Og at derfor vil Datatilsynet se igennem fingre med min lille virksomhed laver noget der er non-kompliant. Great.

Om spørgsmålene og "i visse tilfælde"

Spørgsmål 7 har netop 3 kategorier ”contractual”, ”technical” og ”organisational”. Mit og Martins eksempler er netop konstrueret så det ikke er muligt at bruge ”technical” supplerende foranstaltninger da der ikke er noget kryptering involeret.

Spørgsmål 8 snakker netop om kryptering, som der med vilje ikke er noget af i vore eksempler.

For hvis man skal anvende kryptering så spørgsmål 8 kan finde andvendelse kan man kun bruge cloud løsninger til storage og så forsvinder 99% af use cases. (Og nej, homomorphic encryption er ikke klar til brug i praksis)

Spørgsmål 9 siger:

Hvis du kan få en US-cloudleverandør til at skrive i databehandleraftalen, at de aldrig overfører personoplysninger ud af EU (hvilket pt. er svært), så siger eksempel 10 i Datatilsynets vejledning, at kunden som udgangspunkt er på sikker grund.

Min lille virksomhed med én ansat kan helt sikkert ikke få Microsoft til noget som helst. Kan jeg i praksis i deres self-service univers finde et dokument hvor der står at: "de aldrig overfører personoplysninger ud af EU"? Nej, vel?

Spørgsmål 13 siger at jeg kan benytte en "juridisk kattelem" hvis jeg kan demonstrere at f.eks. FISA 702 i praksis ikke bliver brugt på min virtuelle maskine eller Martins storage instans i Azure.

Går man den vej, vil man eksempelvis kunne finde argumenter såsom at FISA 702 ikke finder anvendelse på en given SaaS-løsning

Konkret for en viruel maskine eller en storage instans i Azure: Kan NSA anvende FISA 702 på netop dem?

Hvis det kun afhænger af SaaS løsningen må man kunne lave en konkret tabel ala:

SaaS LøsningFISA 702 kan anvendes
Azure D2 Virtuel MaskineJa
Azure Storage InstansNej
AWS System XYZJa
GCP System ABCNej
......

Men jeg har aldrig set sådan en tabel. For jeg tror ikke den kan laves. Fordi ingen har interesse i at gøre det konkret så man kan træffe konkrete afgørelser.

Hvis det også afhænger af om man kan søge på en specifik person, må det også gøre at FISA 702 kan anvendes, for både min database og Martins storage data vil indholde specifikke personer som søgenøgler for at være anvendelige (og det vil næsten alle andre use cases også.)

Sammenfatning

Mit og Martins konkrete eksempler er netop konstrueret for at dække de andvendelser af Azure, AWS og GCP der er de allermest almindelige.

Spørgsmål 7, 8 og 9 er klart ude så vidt jeg kan se. Jeg har meget svært ved at se at Spørgsmål 13 kan finde andvendelse. Særligt med de begrænsede ressourcer som min (hypotetiske) enmandsvirksomhed har. Men jeg kan ikke få nogen til at sige: Dit og Martins eksempler er klokkeklart non-compliant (eller det modsatte).

Jeg får personligt mistanken om at Datatilsynet egentlig mener at jeg ikke må anvende mit og Martins eksempelsystemer til at gemme GDPR data, men at de manger modet til at bekende kulør og sige det utvetydigt, for så er 99% af alle anvendelser af skytjenester på den forkerte side af loven, og det vil få uoverskuelige økonmiske konsekvenser for alt for mange virksomheder.

Eller må jeg bare acceptere at jura er mere gråt end jeg håber? Og mit ønske om et stort/hvidt svar er urimeligt eller naivt?

  • 2
  • 0
#9 Jesper Løffler Nielsen Blogger

Hej Peter. Du har helt ret: Det er svært at få jurister som mig og dem der i Datatilsynet til at svære klokkeklart ja eller nej til dit eksempel. Noget af det skyldes formentlig manglende mod, bl.a. fordi vi kæmper en kamp for at forstå alle de tekniske begreber og forudsætninger det kræver for at kunne svare klart (se spm 2 ovenfor). Og så er en del af forklaringen utvivlsomt også, at juraen ikke er sort/hvid. Det er den generelt ikke, og det er den særligt ikke i denne sag. Særligt den “juridiske kattelem” (spm 13) er smækfyldt med gråzoner og konkrete vurderinger. Og de vurderinger kan ikke foretages på PaaS-niveau (som din tabel prøver at gøre), men handler om den konkrete usecase for den enkelte dataansvarlige kunde. Fx Sundhedsplatformen eller Aula.

  • 0
  • 0
#11 Baldur Norddahl

For hvis man skal anvende kryptering så spørgsmål 8 kan finde andvendelse kan man kun bruge cloud løsninger til storage

Det er så spørgsmålet om det reelt er rigtigt. Ja teoretisk kan de hive nøglen ud af hukommelsen på en virtuel maskine, men mon ikke man kan slippe afsted med at konstatere, at der ikke er nogen kendte eksempler på at det er sket med baggrund i de problematiske love i USA? Der er endvidere technologier (trusted computing etc) der kan gøre det svært at aflæse en nøgle også selvom man har fuld adgang til host operativsystemet.

Man kan altid argumentere at NSA nok har en metode. Man kan dog konstatere at NSA i så fald ikke hjælper de amerikanske myndigheder i almindelige sager og igen nå konklusionen at det ikke sker i praksis.

Afhængig af hvor følsomme data man arbejder med, så vil man måske i mange tilfælde kunne nå frem til en risikovurdering der siger, at det er muligt at benytte en amerikansk kontrolleret cloud udbyder til virtuelle maskiner, såfremt man eksempelvis sikrer at maskinen fysisk kører i EU, at disk er krypteret, at der anvendes teknologier til at sikre nøglen i hukommelsen og at nøglen opbevares udenfor miljøet i øvrigt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere