Hoe ver ben jij al met je migratieplan weg uit de Amerikaanse cloud?

Zoek alternatieven voor Amerikaanse leveranciers, zo knalde Emerce erin begin deze week. Het Nederlandse en hele Europese bedrijfsleven schendt immers op grote schaal de AVG omdat ze nog steeds met Amerikaanse dienstverleners werkt. Sinds het Schrems II arrest is dat, hoe zeg je dat netjes als jurist, hartstikke illegaal. En ik snap best dat je nog even wil wachten om te zien wat toezichthouders precies gaan zeggen, maar je hebt natuurlijk wel een migratieplan klaar liggen voor zodra ze “U mag nu stoppen” gaan zeggen. Toch? Want dat gaan ze.

“Er is geen uitzicht op een nieuw Privacy Shield. Alle partijen die op Amerikaanse servers data opslaan schenden Europese privacyregels.” Zo citeert men JetStream-directeur Stef van der Ziel, die precies de vinger op de zere plek legt. Het probleem met de Amerikaanse cloud is al zo oud als de cloud; Amerikaanse wetgeving over snuffelen in persoonsgegevens botst op fundamentele manier met de Europese grondrechten. We hadden ooit de pretentie dat het Safe Harbor-arrest dat op zou lossen: Amerikaanse bedrijven beloven dat ze zich aan de Europese regels houden – behalve als ze wat anders moeten van Amerikaanse wetgeving.

En dat moesten ze, zo onthulde Edward Snowden enkele jaren terug. Safe Harbor sneuvelde dan ook, en het Privacy Shield werd ingevoerd met extra waarborgen en een ombudsman om het nu écht te regelen. Maar het uiteindelijke probleem blijft: Amerikaanse diensten mogen bij persoonsgegevens die in de VS zijn opgeslagen, ongeacht de Europese regels daarover. Dat weten we uit het Schrems II-arrest, waarin het Hof van Justitie net als in Schrems I (het Safe Harbor agreement) bepaalde dat het gewoon echt niet kan, zoals het werkt. (En nee, ook niet als je met SCC oftewel modelclausules gaat werken.)

De impact van de Amerikaanse cloud is echter te groot, zodat niemand echt de eerste stap durft te nemen. Want je zet jezelf op achterstand, als je concurrent wél met Google Analytics blijft werken en jij Matomo of Piwik moet gaan opzetten en vervolgens overal compatibiliteitsproblemen tegen gaat komen. Dus overstappen per direct is inderdaad nogal veel gevraagd.

Ik zie echter geen reden om dan maar te blijven zitten en niets te doen. Inventariseer op zijn minst welke alternatieven er zijn en wat je nodig hebt om die werkend te krijgen. Doe eens een pilot met Matomo, zoek een Europees nieuwsbriefbedrijf en kijk of je écht die twintig trackers op je website nodig hebt. Dan heb je dat maar gedaan, weet je wat de impact gaat zijn en kun je dán besluiten wanneer je gaat migreren. Misschien wel sneller dan je denkt, want “wij werken volledig Europees” begint langzaam maar zeker een marketingvoordeel te worden.

Arnoud

51 reacties

  1. Wat mij nu niet duidelijk wordt is of het wel Ok is om dat in Europa op te slaan bij Amerikaanse cloud providers. Kun je gebruik blijven maken van Office 365 als je data in Europa staat en van AWS als je servers in Duitsland staan.

    1. Dat hangt (a) van de data die je opslaat/verwerkt en (b) van de exacte inrichting van de gebruikte cloud af. Er is geen privacy-bezwaar tegen het verwerken van “niet tot een persoon te herleiden” gegevens, dus veel technisch en financieel modelleerwerk kan zonder problemen. Voor persoonsgegevens (denk ook aan email) zul je moeten kijken hoe jij en je cloud-leverancier toegang door Amerikaanse overheidsorganisaties tegenhouden. Het gaat daarbij om een analyse van het totaal aan feiten en dat is niet iets wat ik even in vijf minuten doe. Bij een “gegarandeerd EUropese” cloud-aanbieder is zo’n analyse simpeler.

    2. Als ik deze regel uit het artikel goed begrijp:

      Maar het uiteindelijke probleem blijft: Amerikaanse diensten mogen bij persoonsgegevens die in de VS zijn opgeslagen, ongeacht de Europese regels daarover.
      Zou dat dus geen probleem mogen zijn. Zolang de data in Europa staat en niet in de USA. Belangrijkste vraag die je je hier wel bij moet stellen is, of de cloud provider vanwege “beschikbaarheid en naleving van een SLA” de data niet ook heeft gerepliceerd naar een datacenter in de USA, want dan kan een Amerikaanse rechter er wel weer bij.

      1. Dat is inderdaad wat het artikel zegt. Desalniettemin heeft een amerikaanse dienst nog altijd toegang tot de gegevens die in europa zijn opgeslagen. Een rechter kan hier dus ook een bedrijf dwingen de data alsnog te overhandigen.

        1. Hoe kan dat bedrijf dan precies dat gerechtelijk bevel uitvoeren? Als het datacenter eigendom is van (of gehuurd door) een Europese zuster, met een apart bestuur dus, welke stappen gebeuren er dan concreet tussen “de Amerikaanse BV krijgt een bevel” en “de Amerikaanse BV heeft nu een zipfile met alle data”?

          1. Die concrete stap is volgens mij “Amerikaanse BV vraagt een van de eigen medewerkers om in te loggen en de gegevens op te halen en in een ZIPje te pakken”.

            Zoals de clouds nu ingericht zijn, logt iedereen in via een globale portal (portal.azure.com, console.aws.amazon.com). Deze portal wordt waarschijnlijk beheerd door de Amerikaanse BV, en niet de Europese dochter. Er moeten dus integraties zitten tussen de systemen van het Amerikaanse en het Europese bedrijf, en ik heb geen garanties gezien hoe die integraties voorkomen dat er Amerikaanse admins inloggen in Europa, of Europese data plotseling gedupliceerd wordt naar Amerika.

            Microsoft had eerder een Duitse versie van hun cloud, waar die garantie er wel was – die had ook een eigen portal URL, waardoor het echt een afgescheiden systeem kan zijn. Maar die versie is inmiddels niet meer te bestellen, volgens het artikel omdat klanten meer flexibiliteit en consistentie willen (??)

            Als we echt denken dat Amerikaanse cloud wel veilig is als de servers maar in Europa staan, dan heeft Max Schrems (die Oostenrijkse activist die geprocedeerd heeft tegen Safe Harbor en Privacy Shield) nog een boel werk te doen.

            1. Dat voelt als een zorgelijk punt, hoewel ik zou verwachten dat de Europese dochters logging hebben en zouden zien dat een Amerikaanse medewerker inlogt zonder daartoe strekkend verzoek van een klant, én natuurlijk een volledige datadump maakt. Dat laatste lijkt me een relevant alarmsignaal, het zal een kwaadwillende werknemer zijn die ermee naar de concurrent gaat of losgeld gaat eisen.

              Ik ben wel verbaasd dat een Amerikaanse werknemer dus kennelijk zomaar in kan loggen en toegang nemen tot customer data in Europa. Daar is geen supportverzoek voor nodig?

              1. Als je er van uit gaat dat het is gebouwd en ingericht op het moment dat er geen noodzaak was voor zo’n scheiding (d.w.z toen die verdragen nog geldig waren) dan is het prima verklaarbaar, en zelfs logisch, dat zo’n geografisch onderscheid er niet is. Waarom zou je dat immers willen, als dat niet doen alles eenvoudiger en klantvriendelijker maakt. Je kan klanten met meerdere kantoren wereldwijd beter bedienen, je kan diensten waar 24h-support op zit bedienen vanuit het service-centrum in een regio waar het op dat moment normale kantoortijden zijn, je kan eenvoudiger data via meerdere locaties beschikbaar maken om latency te verminderen en meer redundantie in te bouwen, etc etc. Er zijn legio voordelen te behalen als je het idee laat vallen dat je cloud-dienst op het Internet gebonden moet zijn aan een of andere regio uit de fysieke wereld. Kortom, ik vind het vanuit een technisch en klantvriendelijkheids-perspectief gezien volkomen logisch dat Amerikaans personeel toegang heeft tot de data van de klant, ook al staan die bitjes dan toevallig (of juist bewust) op een stuk opslag ergens in Europa, en vice versa. Het is wetgeving, Internationale verdragen e.d. die het “moeilijk” maken. Overigens ben ik net als jij van mening dat die privacy-wetgeving terecht is, en gehandhaaft moet worden, ik heb het puur over het technisch aspect van dat geografisch verschil.

                  1. Vergeet niet de hele geschiedenis met National Security Letters, waar systeembeheerders verplicht werden apparatuur te plaatsen om data af te tappen en de werkgever er niet van wist.

                    Een federale rechtbank heeft Apple al eens verplicht om een backdoor in te bouwen. Wat met een sisser afliep , omdat het hoger beroiep niet doorging omdat men op een andere wijze al toegang had gekregen.

                    Die cloud software, ook al draait die in de EU wordt grootdeels in de VS gemaakt. Denk jij echt dat de Amerikaanse veiligheidsdiensten niet opdracht zullen geven om de login portal van die mogelijkheid te voorzien en dat uit te rtollen als het er nog niet is?

                    En vergeet niet, daar hoor je helemaal niets van, want het gaat niet om een ‘gewone’ zaak. Als de could provider al in beroep gaat is dat bij de FISA court en horen we er nooit wat van, of ze nu winnen of verliezen.

                    En met die mogelijkheden is het dus totaal irrelevant of het nu mogelijk is, de benodigde bescherming dat het niet ongemerkt mogelijk wordt ontbreekt en dus voldoet men niet aan de Europese privacy wetgeving.

              2. Over Amerikaanse werknemers die data van in Europa kunnen benaderen. Audit trails staan in alle grote clouds aan, er wordt gewoon continue bijgehouden welk account welke data probeert te benaderen. Nu weet ik alleen van Microsoft hoe zij om gaan met data verzoeken, data logging en toegang tot data van hun klanten. De meeste informatie daarover is hier te lezen. Het komt er in het kort op neer dat medewerkers van Microsoft alleen toegang tot data krijgen naar aanleiding van een support verzoek. Als er een verzoek tot dataoplevering vanuit een overheid komt, zal Microsoft dit verzoek eerst zelf analyseren, daar zitten dus ook gewoon een aantal juristen bij. De Q&A waar ik naar heb gelinkt legt veel (maar helaas niet alles) uit.

          2. Het verzoek moet blijkbaar worden gesteld aan de Amerikaanse rechtspersoon maar er is nog een andere test, namelijk dat die rechtspersoon ook een vorm van “controle” moet kunnen uitoefenen over de informatie die wordt opgevraagd. Zoals ik ‘m lees: als de informatie in een datacentrum in Amsterdam staat en bijvoorbeeld Microsoft Nederland BV eigenaar is van die servers dan heeft Microsoft Corp in de VS daar niet veel direct over te zeggen lijkt me.

            Maar je zou ook kunnen lezen dat “controle” betekent: is het ook maar technisch mogelijk om toegang te krijgen tot die gegevens? Dan heb je controle en moet je die informatie opleveren, onafhankelijk van waar het staat.

            Dat “onafhankelijk van waar het staat” kom ik heel veel terug in papers over de Cloud Act. Blijkbaar formaliseert de Cloud Act wat veel Amerikaanse rechtbanken toch al deden: het maakt niet uit waar die data staat maar het maakt uit wie controle heeft.

            Ik heb eerst meer koffie nodig voordat ik er in duik wat de Amerikaanse wet nou precies bedoelt met “controle”.

        2. Maar dan moet de Amerikaanse (hoofd-)vestiging van het bedrijf controle hebben over data die in de Europese datacenters is opgeslagen. De gemiddelde cloud biedt nu al beveiliging waardoor klanten niet bij elkaars data kunnen komen; het moet niet zo moeilijk zijn om een het beheer van klantengroepen ook te partitioneren. Dan kan de cloud-leverancier in voorkomende gevallen tegen de Amerikaanse overheid zeggen: “Doet U maar een rechtshulpverzoek aan onze Europese collega’s”.

    3. Ik zie heel veel reacties die aangeven of Microsoft vanuit Amerika bij jouw data mag. Bij Microsoft kun je dat enigzins zelf regelen door een customer lockbox feature te gebruiken. Als je je druk maakt of de cloud provider bij jouw data kan, dat is m.i. nog altijd een eigen risico afweging die je zelf kan maken. Het is wat anders als de conclusie van deze zaak is dat het volgens de wetgever niet meer mag. En dat laatste is mij nu nog niet helemaal duidelijk. Als het van de wetgever niet mag, dan wens ik veel bedrijven success om weer uit de cloud te gaan en te stoppen met Office 365, Gmail, AWS, Azure en Google cloud. Ik denk dit in veel gevallen niet eens kan (tenzij je niets met persoonsgegevens doet).

      1. De AVG (de Europese wetgever dus) zegt, het mag niet als Amerikaanse partijen naar eigen inzicht in je data kunnen graaien zonder jouw medewerking. Het opslaan van een encrypted blob in Amerika is geen probleem want dan kunnen ze niet bij de data. Je klantenbestand in een CRM-systeem van een Amerikaanse dienstverlener met database in Florida is wel een probleem want dan kán die dienstverlener erbij.

        Hoe werkt die lockbox bij Microsoft, ik ken dat niet. Kan ik dan mijn Onedrive bestanden afschermen voor iedereen buiten mijn organisatie, ook supportmedewerkers van MS die op afstand problemen komen verhelpen?

        1. Dus het gaat met name om de geheime diensten in de VS die mogelijk bij je data kunnen komen als ik het zo lees. De lockbox feature: https://www.microsoft.com/en-us/microsoft-365/blog/2015/04/21/announcing-customer-lockbox-for-office-365/ Een andere die in dat perspectief ook intressant kan zijn is Hold Your Own Key: https://docs.microsoft.com/nl-nl/azure/information-protection/configure-adrms-restrictions Overigens zijn beide nu onderdeel van de duurste licentie variant.

  2. ik weet dat voor veel bedrijven dit een veel grotere impact heeft dan het vervangen van een enkele applicatie. Heel veel applicaties zijn van Amerikaanse leveranciers of worden gehost op Amerikaanse cloud providers (AWS of Azure). Voor veel applicaties zijn ook geen volwaardige alternatieven beschikbaar, daarnaast kost het overstappen naar een ander leverancier behoorlijk wat tijd en geld. Als overheidsorganisatie moet je dit vervolgens ook nog via een Europese aanbesteding doen. Dus ja daarom wacht iedereen af tot er meer duidelijk is. Natuurlijk wordt er wel een lijstje gemaakt om welke applicaties het gaat.

    1. Mijn zorg en twijfel is dus dat mensen niet eens een lijstje gaan maken, maar helemáál achterover zitten en wachten tot er wat komt. En dan is er paniek want dan moet het op stel en sprong en krijg je inderdaad argumenten als “ja maar we moeten Europees aanbesteden” of “we wisten niet dat het zó erg was” (wat je bij de AVG in 2018 hoorde, die dus in 2016 aangenomen was).

      1. maar helemáál achterover zitten en wachten tot er wat komt.

        Aaah, dus je hebt gelukkig ook al met mijn vorige werkgever gesproken 😛

        Je zegt het inderdaad netjes. De wetgeving uit 2016, welke actief werd in 2018, en waar eind 2020 nog steeds niet aan wordt voldaan… De organisaties en bestuursleden die hiervoor verantwoordelijk zijn hebben helemaal geen motivatie om actie te ondernemen. Ze blijven lekker zitten en hopen dat de juridische inertie hun termijn en gouden handdruk redt.

    2. Dat lijkt me allesbehalve natuurlijk. Het lijkt me eerder dat er helemaal niks gedaan wordt, en zodra er een daadwerkelijke uitspraak is zal men gaan klagen dat ze veel te weinig tijd hebben om hun zaakjes op orde te krijgen. Dat is tot nog toe altijd zo gegaan met ver vantevoren aangekondigde wetswijzigingen.

  3. Bij ons bedrijf zijn er hierover twee ideeen:

    1 – Als we de data encrypten is er niks aan de hand 2 – Als we alleen VMs laten draaien in de cloud en de data lokaal houden is er helemaal niks aan de hand

    Beide voelen voor mij een beetje fragiel maar ik kan dat gevoel niet hard maken. Hoe zit het juridisch met data verwerken in de US maar niet daar opslaan, en met data encrypted opslaan in de US?

    De enige tegenreactie die tot nog toe een beetje aan kwam was ‘zou je dit bij alibaba cloud willen hosten?’ maar men vond microsoft en amazon best te vertrouwen…

    1. In de praktijk gaat het om “wie heeft de toegangs-controle tot de data”. Bij een privé-computer in een datacenter zou de eigenaar van het datacenter de harddisk uit de PC moeten verwijderen om toegang te krijgen… Zal er vast ook wel een slotje opengebroken moeten worden en dan komt al heel snel het strafrecht om de hoek kijken.

      Punt twee is dan: hoe goed is de private cloud software en zit daar een toegangsmogelijkheid voor de leverancier van de cloud-software in?

  4. We houden kijken binnen eDiscovery ook naar wie de eigenaar is van de instance, zelfs al draait ‘ie op een server in Amsterdam. Als deze eigendom van de Amerikaanse platform leverancier zou zijn, zou de US overheid er via de Cloud Act bij kunnen. Dus een NoGo . Er kunnen allerlei bezwaren zijn waarom dit juridisch (volgens NL of Europees recht) niet zou kunnen of mogen, maar als een US Company moet kiezen welke wet / subpoena ze opvolgen en welke niet, zet ik mijn geld niet op de NL of Europese wet/regelgeving.

  5. Over kunnen uitoefenen van feitelijke controle: indien aangenomen moet worden dat Amerikaanse leveranciers (ontwikkelaars) van cloud-systemen geheime opdracht tot inbouw van achterdeuren kunnen krijgen – sinds Snowden is reden om dat aan te nemen – dan moet daaruit volgen dat die systemen alleen acceptabel zijn als deze als open source zelf te compileren etc. zijn of anders van een betrouwbare auditverklaring zijn voorzien. Voor systemen afkomstig uit andere jurisdicties dan de VS zal hetzelfde ook wel opgaan.

    (open source, ongeacht de licentie zolang het product maar zelf te compileren is voor bitwise verificatie, is vermoedelijk de enig betrouwbare wijze waarmee de integriteit zonder al te hoge kosten kan worden aangetoond, want gedeelde kosten)

    1. Al je data dus ge-encrypt opslaan zodat al zouden ze een copietje trekken er toch nog niks mee kunnen…

      Het gaat veelal niet uitsluitend om opslag. Als dat ook anderszins wordt verwerkt – denk bijvoorbeeld aan die vele duizenden bedrijven die hun toepassingen in de Oracle cloud draaien – dan gaat die vlieger niet op.

      En als het al alleen opslag in een cloud betreft en de decryptie van de data binnen een vertrouwde omgeving gebeurt, dan zal om dit praktisch en (technisch) transparant te doen een lokale “overlay” dat op het niveau van het bestandssysteem (OS functie) moeten bieden. Werkwijzen waarbij eerst een complete versleutelde blob moet worden gekopieerd, dan de hele bups ontsleutelen, data verwerken en ten slotte weer versleutelen en weer kopiëren naar de opslag in de cloud zijn al snel onwerkbaar en lastig beheerbaar.

      1. https://docs.microsoft.com/en-us/azure/storage/common/storage-client-side-encryption

        En je kan prima de database entries versleutelen op azure en alleen de records die wijzigen schrijven ipv de hele database. Op database niveau versleutelen is wel de slechtste optie. Net als dat je prima opnfile niveu encryption cn doen ipv een encrypted container in je cloud opslaan.

        Ik zie echt jouw probleem niet, dat is al lang opgelost.

          1. Wij hebben een SaaS product in ontwikkeling waarbij wij de data op deze wijze opslaan in de VS, de client side is een web app die draait op een webserver in een Nederlands datacentrum. Dus database met encrypted data at rest en in transit met en-/decryptie op de server in de EU.

            Overigens is niet gezegd dat dit zo blijft, sommige minder technische klanten begrijpen niet dat de VS zo niet bij de data kan en worden al allergies als ze VS ergens zien staan. Dus vanuit PR oogpunt kan het best dat we de data nog verplaatsen van de cloud naar een ouderwetse zelf gehoste databaseserver.

            De SaaS versie van Office is overigens niet perse webapps, je kan ook lokaal office installeren en lokaal opslaan. Het is wat dat betreft een betere optie als Google Apps.

            1. Ik heb zelf flink wat Sybase en MSSQL server ervaring (eind jaren 90 en is misschien achterhaald), maar ik begrijp niet goed hoe een (relationeel) DBMS op encrypted data kan opereren, d.w.z. anders dan een wat wonderlijke opslag. Indices e.d. mogen dan beslist geen data bevatten die versleuteld dient te blijven; geheid een manier om de mist in te gaan, zeker als indices automatisch door de query optimizer kunnen worden aangelegd. @elroy: mooi dat jullie proberen oplossingen te vinden.

              1. De meeste applicaties gebruiken tegenwoordig geen relationele databases meer (of als ze ze wel gebruiken dan gebruiken ze het relationele gedeelte niet). Die slaan gewoon blobs met data op, en het kleine beetje relaties tussen verschillende tabellen/databronnen wat wordt in de applicatie zelf geregeld.

                1. De meeste applicaties gebruiken tegenwoordig geen relationele databases meer (of als ze ze wel gebruiken dan gebruiken ze het relationele gedeelte niet).

                  Don’t believe the hype… “De meeste applicaties” gebruiken gewoon een relationele database.

                  Overigens lost het gebruik van een NoSQL database niet het probleem met keys en encryptie op.

                    1. Wat een verspilling. Want ook extra licentiekosten aftikken – o jee, pas op voor BSA, zorg dat alle benodigde licenties er zijn (met een licentie op een licence-inventory-management-system) – en ook, volg de “provisioning guide” dus minimaal 2xCPU+xGB enz. Grapje, maar ook niet helemaal.

                      Hoe dan ook: toepassen van cryptografie is listig, je ziet al snel iets over het hoofd. Je zult zien dat menig ontwikkelaar, goed bedoeld, ad-hoc versleuteling op of in zijn toepassingen gaat stoppen, en net als met al de net zo goed bedoelde zelf-gebakken implementaties voor logins op basis van wachtwoorden de ene na de andere fout maakt (opslag van wachtwoorden i.p.v. een secure hash t.b.v. verificatie, geen “salt” bij initialisatievectors, enz). Een ander voorbeeld waar ontwikkelaars goed bedoeld massaal de mist ingingen was toen begin jaren ’90 allerlei programma’s opeens multi-user moesten worden. Dat vereist voor gelijktijdige toegang tot de data heel precies gebruik van locking om dead-locks en datacorruptie te vermijden. En ging fout, heel vaak fout.

                      Kortom, de leveranciers van cloud software moeten oplossingen bieden om te kunnen voldoen aan de AVG en de gebruikers van die diensten moeten de juiste leveranciers kiezen en niet zelf crea-bea aan de gang gaan.

              2. Je hebt natuurlijk wel wat beperkingen, maar als de client mijn naam ‘Elroy’ versleutelt en opslaat in de database als ‘D4G7%$’ dan is het daarna een kwestie van bij de queries ipv ‘Elroy’ te gebruiken client side de encryptie op naam eerste te doen en dan pas ‘ SELECT * FROM table WHERE name=”D4G7%$”.

                Je hoeeft niet alles te encrypten, maar alleen de data waarmee een gebruiker geidentificeerd kan worden.

                Wat voor een beperkingen heb je dan? De geboortedatums zijn encrypted dus een select statement voor alle deelnemers geboren voor een bepaalde datum kan niet meer. De encryptie garandeert niet dat de alfabetische volgorde van de geëncrypte data gelijk is aan de oorspronkelijke data. Je kan wel eerst een lijst van alle deelnemers en geboortedatums opvragen dan clientside een lijst maken met alle deelnemers die geboren zijn voor de gewenste datum en dan een query te doen op die lijst met deelnemers. Je hoeft de lijst met namen hoervoor niet eens te decrypten. Alle data die aan een deelnemer is gekoppeld is daarom dus niet encrypted, alleen de data waarmee je zou kunnen achterhalen bij wie die gegevens horen. En ja daar moet je heel goed over nadenken, dat je niet iets over het hoofd ziet en alsnog een datalek mag melden…

                1. En ja daar moet je heel goed over nadenken, dat je niet iets over het hoofd ziet en alsnog een datalek mag melden…

                  Precies, en dat is op grote schaal een no-go. Wanneer het aan moet komen op goed nadenken, dan gaat dat, zeker onder druk van deadlines, zeker mis, ook met goede hersens en goede intenties.

                  En daarbij, nogmaals, het toepassen van cryptografie is tricky, echt tricky. Key handling: kritisch; versleutelingsmodus: kritisch; protocollen: kritisch; goed gebruik van (pseudo) random data: kritisch; en ineenstortende performance ligt slechts een comma weg; enz. Ampele gelegenheid om de boot in te gaan.

        1. Voor een Azure SQL database (West Europe – Amsterdam) gebruiken we “Transparent data encryption” https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-tde-overview

          “Transparent data encryption (TDE) helps protect Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics against the threat of malicious offline activity by encrypting data at rest. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.”

          Wat vinden jullie van deze oplossing?

          1. Dat beschermt niet tegen het probleem waar deze blogpost over gaat. Zo doet het bedrijf tegen wie je je data wil beschermen de encryptie voor je…

            “We vertrouwen Azure niet dus we encrypten de data.” “Waar slaan we de sleutel veilig op?” “Simpel, in Azure Keyvault!”

          2. … against the threat of malicious offline activity by encrypting data at rest.

            Twee begrippen die hier van belang zijn: “offline” en “at rest”. Deze verdediging biedt dus geen bescherming voor on-line data, maar beschermt uitsluitend de gegevens in het geval de schijven in het bezit van een onbevoegde komen die deze op zijn eigen systeem uit wil lezen; een schijf uit een datacenter jatten of (straf)rechtelijk vorderen is niet het grootste risico, maar inderdaad die weg dek je af (zolang de encryptie-sleutel niet kan worden gevorderd). De mogelijkheid om toegang tot de data te krijgen zolang die on-line wordt hierdoor niet verminderd.

            1. Dank voor de reacties.

              Azure biedt nog de mogelijkheid om de standaard meegeleverde encryption key te vervangen door een Bring You Own key, dus je eigen encryption key, die inderdaad in Azure Key Vault wordt opgeslagen.

              https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview “Greater trust from your end customers, since AKV is designed such that Microsoft cannot see nor extract encryption keys;”

              In theorie is dit wat je nodig hebt: een kluis bij Azure, waar alleen jij de sleutel voor hebt. Maar inderdaad, hoe weten we dat Microsoft er daadwerkelijk niet bij kan? Ze kunnen immers eventjes in de portal inloggen as superadmin, is mijn gedachte dan.

  6. Ik blijft het vreemd vinden dat bedrijven er mee blijven wegkomen als ze stellen van niets te weten. De problematiek is reeds gekend van vor Snowden zijn onthullingen en vanaf dan super duidelijk voor iedereen die een beetje de situatie volgt.

    Zeker voor websites is het hatelijk. Bovendien lijkt het me twijfelachtig dat meer dan 1/20 van de bedrijven meer gebruikt dan wat Matomo of zelfs eenvoudige logfile analyse kan aanleveren.

    Zelfs de Belgische Gegevensbeschermingsautoriteit gebruikt gstatic.com (van Google), hoe zot kan het worden.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.