Nederlandse overheid mag AWS blijven gebruiken na oplossen van privacyrisico's

De Nederlandse Rijksoverheid mag Amazon Web Services blijven gebruiken voor bepaalde cloudtoepassingen. Amazon heeft een aantal aspecten van de dienst aangepast zodat die voldoen aan de AVG.

Er zitten 'geen bekende hoge risico's' meer aan het gebruik van AWS, stelt onderzoeksbureau Privacy Company na een data protection impact assessment. Privacy Company deed, in opdracht van het Strategisch Leveranciersmanagement Rijk, onderzoek naar het gebruik van Amazon Web Services bij de Nederlandse overheid. Dat onderzoek begon in februari 2021. Daaruit kwamen zeven risico's naar voren waarbij het gebruik van persoonsgegevens in gevaar zou kunnen komen. Die risico's staan niet beschreven in de dpia van SLM Rijk, maar volgens SLM en Privacy Company zijn die risico's inmiddels wel opgelost. Dat gebeurde na overleg tussen Amazon en de Nederlandse overheid.

Wel zijn er nog steeds negen andere risico's voor datagebruik, maar die schat Privacy Company in als laag. Zo kunnen betrokkenen geen inzage krijgen in bepaalde gegevens en is er een risico op het 'verlies van controle over cookies en websitetelemetrie bij AWS-websites met beperkte toegang'. Privacy Company en SLM stellen dat de overheid de dienst alsnog kan gebruiken, ondanks die risico's. Dat kan door ze deels te accepteren of door ze te beperken. Daarvoor noemt SLM verschillende mogelijkheden.

Privacy Company onderzocht specifiek drie diensten binnen AWS waar de Nederlandse overheid gebruik van maakt. Dat zijn Elastic Compute Cloud, S3 en Amazon Relational Database Service of RDS.

Er zijn daarnaast ook risico's voor het gebruik van AWS omdat data daarbij wordt doorgestuurd naar de Verenigde Staten. Daarvoor heeft Privacy Company een data transfer impact assessment gedaan. De risico's van die datadoorgifte kunnen worden vermeden door gevoelige persoonsgegevens te versleutelen en accountgegevens van beheerders te pseudonimiseren.

In theorie zouden de aanpassingen die Amazon heeft gedaan ook van toepassing moeten zijn op de rest van Europa. Omdat de AVG voor alle landen binnen de EU geldt, zouden de dpia en de aanpassingen in heel Europa van toepassing moeten zijn. Dat was ook het geval bij Google Workspace, waar SLM eerder al onderzoek naar liet doen en waarbij Google veel toezeggingen deed door Chrome en ChromeOS aan te passen. Eerder bleek echter dat Vlaanderen het gebruik van Google Workspace niet toestaat: scholen moeten eerst zelf een privacyonderzoek doen, hoewel de regels rondom Workspace voor zowel Nederland als België hetzelfde zouden moeten zijn.

Door Tijs Hofmans

Nieuwscoördinator

26-06-2023 • 10:20

82

Submitter: f4k

Lees meer

Reacties (82)

Sorteer op:

Weergave:

Zoals een Nederlands spreekwoord zegt: papier is geduldig. Lijkt mij veel veiliger om dit in eigen land te doen door een Nederlands bedrijf.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:38]

Vraag is alleen of er in Nederland een partij is die iets van deze schaalgrootte aan kan, en de juiste kwaliteiten heeft.

Ik zou dan eerder insteken op het aansluiten bij het Europese Gaia-X project: nieuws: Europees cloudplatform Gaia-X gaat officieel van start

Ook dat heeft immers een Nederlandse inbreng, via de TNO: nieuws: Europees cloud-initiatief Gaia-X krijgt Nederlandse kennishub

Denk dat dit soort data beter bij een Europese partner kan liggen waar de EU dus zeggenschap, dan bij een Amerikaanse partner als Amazon, Google Cloud etc.
Denk dat dit soort data beter bij een Europese partner kan liggen waar de EU dus zeggenschap, dan bij een Amerikaanse partner als Amazon, Google Cloud etc.
Zelfs in de USA ging deze selectie uiterst moeizaam, en die hadden niet eens last van de GPDR, wat nu "opgelost" is met wat data centers in Europa. Zoals die van Facebook in Zeewolde, die gelukkig niet doorging.

Nee, een Amerikaanse leverancier lijkt me het domste wat een Europese overheid kan doen.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 13:38]

Niet alleen wat datacenters, ook juridische entiteiten (bv's, GMBH's etc.) die eigenaar van die datacenters zijn, waardoor ze ook 100% onder EU wetgeving vallen v.w.b. gehuisveste data.

Het probleem zit meestal in het oerwoud van verschillende wetgeving op de verschillende contintenten, waar de meest vaak genoemde privacywetgeving is. Een Microsoft met EU-datacenters bijv. die niet direct vallen onder Microsoft Corporation, maar onder de gevestige juridische entiteit in het land van operatie. Derhalve mogen ze ook niet zomaar mee te werken aan een bevelschrift uit de US.

Ik ben het wel met @david-v eens, Gaia-x is i.m.h.o. een mooie proof of concept, maar het is aan (commerciele / overheid) marktpartijen in de EU om te laten zien dat dit ook kan werken. Een partij als Gridscale of SURF zou dit zeker op schaal kunnen, als men er goede plannen voor maakt.
Goede comment.

Ik denk dat zowel Europese software als hardware nog een flinke weg te gaan heeft. Die politici moeten gaan doen waar ze altijd van gevlucht zijn. Maar er zijn er teveel.

Ze zullen de data moeten confronteren.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 13:38]

Nee, een Amerikaanse leverancier lijkt me het domste wat een Europese overheid kan doen.
Volgens mij kan het nog dommer, ik denk dan aan China en Rusland, maar de VS is zeker een goede derde. :)
Volgens mij kan het nog dommer, ik denk dan aan China en Rusland, maar de VS is zeker een goede derde. :)
tja, dat klopt dan ook.

Het probleem is echter Europa, die zonder geen van drieën kan. lol, wat dat betreft lijkt net-neutraliteit over land makkelijker dan door water.

tja, uiteindelijk is de veiligheid van natie-staten een risico-paradox, een optelsom van gedeelde belangen tussen buren.

Welcome to the Space Age.
Hoewel ik Gaia-X een goed initiatief vind maak ik me wel ernstig zorgen over de uitvoerbaarheid van het geheel. Daar waar je private ondernemingen hebt met een duidelijke aansturing is dat bij Gaia-X een "overheden" initiatief met inbreng van precies dezelfde bedrijven waar we nu over hebben. Denk aan Alibaba, Google cloud, huawei, AWS, Azure en wat te denken van de samenwerking met Palantir. Deze laatste niet een onbekende in de wereld van privacy schending.

Je krijgt dan een geheel met allerlei private ondernemingen als partners en aangestuurd vanuit een politiek instrument zoals de EU waarbij de belangen van elke natie binnen de EU vertegenwoordigd zijn (ik noem dat een wespennest :D ).

Het doel van Gaia-X is niet om een concurrent van de welbekende Cloud providers te zijn maar om iets te bieden wat zich aan de EU regels houdt en dat met partners die zelf cloud diensten aanbieden in de EU. Volgens mij doen deze partners dit al op individuele basis zoals ook in dit bericht weer naar voren komt.

Ik ben een twijfelaar wat Gaia-X betreft...
Leaseweb zou dit eventueel kunnen denk ik, ze zijn ook al GAIA-X deelnemer.
Alleen is Gaia-X geen alternatief voor AWS, het is een papieren tijger set van richtlijnen en daardoor dus meer te vergelijken met iets als Fedramp, waarbij je dus nog steeds een partij als AWS nodig hebt die producten aanbiedt die Fedramp/Gaia-X certified zijn.
De schaalgrootte en kennis zijn absoluut geen probleem. De zekerheid dat de klant de (hogere) prijs wil betalen is dat wel. Het is onbegrijpelijk dat er naar "goedkope" oplossingen gezocht wordt voor zaken die zo belangrijk zijn. Een speciale oplossing voor de overheid - open source door de overheid - zou waarschijnlijk ook heel goed mogelijk zijn.
Ik snap dat cloud services als deze pas interessant zijn, als er economies in gebruikers te vinden zijn. Anders is het gewoon een data center.

Echter, de regels rond avg zijn niet voor niets europees. Ik begrijp niet dat we het niet van de grond kunnen krijgen een 'lokale' europese cloud van de grond kunnen krijgen.

Op die manier zijn avg zorgen van een heel andere orde dan deze,l. In mijn ogen zijn veel van de dpia risico's vooral textueel afgedekt, ipv concreet. De patriot act bestaat immers gewoon.

Nog los van dat de wereld van vandaag wel aantoont dat je op sommige punten samenwerking niet moet laten verworden tot afhankelijkheid.
Ik snap dat cloud services als deze pas interessant zijn, als er economies in gebruikers te vinden zijn. Anders is het gewoon een data center.
Ik heb het 3x gelezen maar snap niet wat je hier zegt... :?
Je hebt een bepaalde schaalgrootte nodig om daadwerkelijk een cloud te zijn. Waarbij bij voorkeur het cloud meerdere delen van de wereld in verschillende werelddelen beslaat in gebruikers, zodat efficient gebruik gemaakt kan worden van piekbelastig in die verschillende tijd zones.

Kubernetes dat draait in een lokaal datacenter is precies dat, feitelijk niets meer dan Kubernetes dat gebruikt wordt als een soort applicatie server. Geen cloud waarbij je kan op en afschalen wanneer nodig.

Ik denk dat dit het geen is wat david-v bedoelde: economies = economies of scale
Je hebt een bepaalde schaalgrootte nodig om daadwerkelijk een cloud te zijn
Eens, cloud is elastisch en het schalen en per minuut of uur betalen is een zeer groot voordeel. Dat kan je niet zo makkelijk regelen als je een wat kleinere speler bent.
Waarbij bij voorkeur het cloud meerdere delen van de wereld in verschillende werelddelen beslaat in gebruikers, zodat efficient gebruik gemaakt kan worden van piekbelastig in die verschillende tijd zones.
Alle toepassingen waar ik de cloud voor inzet zijn gericht op Nederland. Dat cloudaanbieders wereldwijde datacenters hebben is fijn voor de klanten die dat nodig hebben, maar de enige toegevoegde waarde in de gevallen waar ik mee gwerkt heb is kunnen uitwijken naar Noord Europa (Ierland).
Ik denk dat dit het geen is wat david-v bedoelde: economies = economies of scale
Dat was familyman die dat zei ;)
Alle toepassingen waar ik de cloud voor inzet zijn gericht op Nederland. Dat cloudaanbieders wereldwijde datacenters hebben is fijn voor de klanten die dat nodig hebben, maar de enige toegevoegde waarde in de gevallen waar ik mee gwerkt heb is kunnen uitwijken naar Noord Europa (Ierland).
Het gaat hier niet zozeer om de geolocatie van de datacenters als meer de gebruikers van het systeem. Wanneer in Europa veel resources worden afgenomen, dan zal dat in Azie in Amerika minder zijn.
Maar ja, ik begrijp ook dat je als organisatie liever je data opslaat in Europa of zelfs Nederland. En vooral ook als overheid.

Het grote nadeel van een Nederlands cloud dat door een overheid zou worden gebruikt, is dat je altijd van die piek momenten hebt. Zoals de belastingdienst rond de belastingaangift periode. Bij een Europees cloud zou je dat al wat minder hebben, maar nog steeds zou de belasting overdag veel hoger liggen dan 's nachts.
Dat was familyman die dat zei ;)
8)7
Eens, cloud is elastisch en het schalen en per minuut of uur betalen is een zeer groot voordeel. Dat kan je niet zo makkelijk regelen als je een wat kleinere speler bent.
Lees: in zeer beperkte gevallen is per minuut of per uur betalen een voordeel. Voor een grote webshop zoals bol.com kan dit nuttig zijn bij piekbelasting, of voor een bedrijf zoals Netflix. De Belgische en Nederlandse markt bestaat bijna volledig uit KMO's, met enkele VM's waarbij de patching 's avonds gebeurt, waar 's nachts de backup loopt en waar 's nachts batchverwerkingen op lopen.

Ik heb het zelf al een meerdere keren gezien: on-premise vs cloud, waarbij cloud met 8 uur powered on wordt verkocht en het qua princing een pak goedkoper lijkt. Letterlijk minder dan een week na implementatie merkt men dat 8 uur uiteraard niet mogelijk is en stijgt de kost exponentieel.

Het merendeel van de KMO bedrijfjes blijft jarenlang stabiel qua resources, met hier en daar misschien eens wat extra opslagruimte of extra geheugen.

[Reactie gewijzigd door blinchik op 22 juli 2024 13:38]

Je hebt het hier over VM's en over hoe lang die VM's draaien. Ik maak al jaren geen gebruik van VM's in de cloud. Vrijwel alles is een service (PAAS) waarbij ik zowel horizontaal als verticaal kan schalen en dit ook automatisch ingesteld kan worden. Je kan bij wijze van een SQL database draaien voor €12 per maand en met hetzelfde gemak kan je die database schalen naar een buisness critical SQL database met 128 cores en 625GB geheugen voor €55.000 per maand. Aangezien je per minuut/uur betaald (niet bij alle services is dat het geval) kan je een enorme piek opvangen met een monster van een DB machine gedurende bijvoorbeeld 48 uur om vervolgens de rest van de maand voldoende te hebben aan een DB van €12 per maand. Dit is een extreem voorbeeld maar dat is nou de kracht van cloud.

Het lift en shift model waarbij je VM's in de cloud gaat draaien met je applicaties en daar vervolgens "denkt" goedkoper uit te zijn is niet in alle gevallen realistisch zoals je zelf hebt gezien.
Tja maar:

Op zo'n manier heb je wel een snoeiharde lock-in en hang je volledig af van je cloud provider, want die microservices zijn afhankelijk van je cloud. Qua pricing en technologie. Niet echt leuk voor je volledige organisatie dus, ik zou me toch veiliger voelen met software die ik eenvoudig kan verhuizen naar een andere cloud provider. Ik heb toevallig zicht op de boekhouding van een bevriend softwarehuis die alles in Amazon met PAAS draaien. Hun hosting-kosten op 5 jaar bedragen nu al bijna het dubbele van wat onze volledige hosting infra op 5 jaar rack huren inclusief datacenter huur (met offsite locatie en backup, waarbij zij een minder retentie hebben) en ze zijn nog niet in productie.

Bovendien is zomaar naar PAAS overschakelen een utopie: de KMO's draaien vaak dingen die er niet aan aangepast zijn, alleen nog maar de boekhouding bijvoorbeeld. Medische programma's die we nodig hebben. CAD tekenprogrammatjes. Custom software. etc etc. Dus VM's zal je toch nodig hebben.
Op zo'n manier heb je wel een snoeiharde lock-in en hang je volledig af van je cloud provider, want die microservices zijn afhankelijk van je cloud
We gaan nu wel een hele brede discussie in vrees ik ;) . Je hebt absoluut gelijk dat je een bepaalde mate van lock-in krijgt. Maar ik vraag me af of dat heel anders is dan als je bijvoorbeeld een bepaalde database gebruikt (SQL Server, Oracle, PostgreSQL enz) of een bepaalde ontwikkel framework. Uiteindelijk heb je een "laag" in je applicatie die de communicatie verzorgd met verschillende onderdelen, denk aan filesystem, DB, queues, logging enz. Bij een wijziging in een van deze onderdelen moet je ook niet PAAS oplossingen aanpassen. Zo ook als je gebruik maakt van een PAAS. Maar als ik eerlijk ben, een SQL server PAAS werkt bij mij net zo goed in Azure, AWS of in welke omgeving/cloud dan ook. Vanuit mijn applicatie maakt het eigenlijk niet uit waar de DB draait. Zo ook voor het draaien van een website of een API. Uiteindelijk draait het op een webserver in een linux of windows systeem.

Als je uiteindelijk kijkt naar de mogelijkheden dan zou je zelfs kunnen kiezen om een spreiding te doen van de PAAS waarbij je een storage account in AWS neemt (S3), een database bij Oracle cloud en een app service in Azure om die vervolgens aan elkaar te koppelen in je applicatie. Het is de mate van gelaagdheid in je code die bepalend is voor hoe ingewikkeld het is om over te stappen op een andere oplossing denk ik. Maar zoals ik al in het begin zei, we gaan nu wel een hele brede discussie krijgen :D
Hun hosting-kosten op 5 jaar bedragen nu al bijna het dubbele van wat onze volledige hosting infra op 5 jaar rack huren inclusief datacenter huur (met offsite locatie en backup, waarbij zij een minder retentie hebben) en ze zijn nog niet in productie.
Ik kan er geen echt oordeel over vellen als ik me niet in verdiept heb, maar een PAAS is natuurlijk inclusief al het beheer wat er om heen zit. Dus patches, monitoring, technische ondersteuning enz en niet puur de machines. In jouw geval moet je dus ook de salariskosten erbij nemen van iedereen die betrokken is in het geheel, van de systeembeheerders die de patches uitvoeren remote tot aan de mensen die daadwerkelijk de machines in de racks plaatsen en onderhouden, inclusief de afschrijfkosten op de hardware die je in de in de datacenter hebt staan, kapotte schijven vervangen, nieuwe routes aanleggen bij uitbreiding enz

Als laatste wil je natuurlijk ook schaalbaar zijn, en dat gaat met eigen systemen in een rack in een datacenter niet of zeer beperkt, je moet dan net zoveel power hebben als de grootste piek die je verwacht in een jaar. Dat is eigenlijk niet te doen, tenzij je de piek heel goed kan plannen (bij de belastingdienst kan dat bijvoorbeeld wel)

Ik heb deze transitie bij ons bedrijf ook meegemaakt en zelfs als het je lukte om het goedkoper te doen dan in de cloud (wat dus niet ging als je echt alle kosten meerekent) dan nog heb je te maken met een omgeving die wat certificeringen betreft niet in de buurt komt van wat de grote partijen in de cloud leveren. Het zijn deze certificeringen die door grote klanten/overheid gewenst dan wel geëist worden.
Nu, klopt hoor, cloud kan zeker voordelen hebben bij grotere bedrijven.

Maar het is ook een mythe dat je opeens geen systeembeheer meer hebt. Denk maar aan alle Amazon S3 buckets die open staan omdat mensen denken dat "alles in de cloud beveiligd is en je enkel nog maar cocktails moet drinken". Nadenken over alle permissies en deze instellen, accounts aanmaken. Patches zal je niet meer moeten doen, maar die gebeuren eigenlijk sowieso quasi automatisch. Monitoring moet je sowieso nog ook nog doen, misschien hoef je de infra niet meer te monitorren, maar je wil wel weten of je database up is (kan ook aan jezelf liggen, dat je bv verkeerde accountgegevens hebt gepushed), misschien zijn er tabellen gedropt, etc. Als het productie is dan wil je wel direct weten waar het aan ligt en de vinger op de wonde kunnen leggen. Maar goed, ik ben nogal een monitoring freak en monitor zelf wel heel veel. Technische ondersteuning krijg je sowieso op je apparaten en software als die onder contract zitten, dus dat lijkt me ook niet echt een verschil.

Vreemd dat het niet lukte om het goedkoper te doen, ik denk dat ik nu al een 20 a 30 tal migraties heb gezien waarbij de kosten echt exponentieel omhoog gingen tegenover de schattingen. Waarbij bij een paar paar waar het niet lukte om legacy dingen te migreren die nu nog onsite op een dure installatie draaien en ze nu dubbel moeten betalen. Maar dit gaat natuurlijk allemaal over KMO's, niet over een belastingsdienst die opeens een hele hoge piek krijgt.

Certificeringen kan wel een voordeel zijn als dat benodigd is.

Dus fijn om te horen dat het bij jouw bedrijf wel goed is gelopen, zoals ik al zei: het kan zeker in bepaalde situaties goedkoper zijn, maar het zal wat van de situatie afhangen.
Net vanwege de wetten rond AVG en GDPR kun je geen datacenter van de grond krijgen in Europa.

Het probleem is structureel met de wetten zelf, ze zijn tegenstrijdig en vaak worden bedrijven aangepakt adhv een interpretatie die het Hof van Justitie uit niets opmaakt (wetgeving via de rechtspraak). Dan krijg je oa zaken waar de rechtbank geen informatie kan/wilt delen met belanghebbenden over aanhangende procedures vanwege de privacy regeling.
Wat maakt het dat jij NL verkiest boven Engeland of Frankrijk?
Cultuur + taal + locatie dichtbij
Plus je kunt zelf het personeel screenen.
Detail maar Engeland (GB) is geen EU meer
AWS heeft ook een datacenter in Frankfurt hé... lees ik er over in het bericht dat het in GB zit?
Als er ooit een datalek is dan kun je in Nederland veel makkelijker juridische stappen nemen dan als dat over de grens moet.
Als datalek het belangrijkste is moet je kijken naar wie het beste de boel kan beveiligen.

Het is belangrijker om data in eigen handen te hebben, een land kan zo wetten aanpassen in het nadeel. Dus beter hou je het zelf in je eigen land. Want vrienden voor het leven ben je met niemand.
Het is belangrijker om data in eigen handen te hebben, een land kan zo wetten aanpassen in het nadeel.
In de meeste landen gaat dat niet “zomaar” even, want er is vaak, naast een Tweede Kamer, toch een Eerste Kamer (alsjeblieft geen gedoe over benamingen, het gaat me om het concept, niet om hoe die kamers in andere landen precies heten) waar het hele proces doorheen moet. En dan zit je in het gunstigste geval vele maanden verder, in het ongunstigste nóg verder…
Al staat je data op een Nederlandse server, zo lang je complete software en hardware stack uit de VS komt (zeg Dell met Windows server) vermoed ik dat bepaalde 3-letter agencies in geval van nood prima in staat zijn naar binnen te manoeuvreren.

Daarnaast moet je ook de kennis en software stack nog hebben om data fatsoenlijk te beveiligen. De cloud omgevingen hebben experts in dienst die afdwingen dat iedere omgeving daar een zeker veiligheidsnivo heeft. Nu heb ik er geen twijfel over dat veel beheerders dat ook prima zouden kunnen, maar zou je je data toevertrouwen aan een bedrijf wat 'per ongeluk' een beheerder uit de onderste 10% in dienst heeft en niet over die kunde beschikt?
Elk land denkt aan zijn eigen belang, bovendien kan de EU uit elkaar vallen. Zoals Pep777 al zegt, zie Brexit.
De VS kan ook uit elkaar vallen, waar Google, AWS en Azure zitten met hun cloud. Dat is dus evengoed een risico. Vergelijkbaar qua risico met de kans dat de EU uitvalt, beiden zijn immers zéér klein.

Daarnaast is bijvoorbeeld Gaia-X een Europees initiatief, waar niet één land de scepter zwaait, maar meerdere landen gezamenlijk aan het project werken: Duitsland, Frankrijk, Nederland, België, Finland en Italië hebben allemaal hubs (of zijn ermee bezig), en mogelijk sluiten daar nog meer landen bij aan.

Dat valt dus volledig onder controle van de EU, wat me te prefereren lijkt boven een Amerikaanse oplossing als AWS, Google Cloud etc, waar je toch met Amerikaanse wet- en regelgeving te maken hebt. Die meestal niet in het voordeel van de EU is.

[Reactie gewijzigd door wildhagen op 22 juli 2024 13:38]

De VS kan ook uit elkaar vallen, waar Google, AWS en Azure zitten met hun cloud.
Klopt, Amerikaanse staten hebben al verregaande bevoegdheden, dus het zou voor diverse staten (niet alle) niet zo moeilijk zijn om op eigen houtje verder te gaan. Het zou wat anders zijn als bijvoorbeeld Friesland zich zou willen afscheiden, maar in de VS hoeven staten daar weinig voor te doen, aangezien ze al verregaande bevoegdheden en meer eigen inkomsten hebben.
De VS kan ook uit elkaar vallen, waar Google, AWS en Azure zitten met hun cloud. Dat is dus evengoed een risico. Vergelijkbaar qua risico met de kans dat de EU uitvalt, beiden zijn immers zéér klein.
bij risico inschatting gaat het over de gevolgen; jij beoordeelt enkel de mogelijkheid dat de EU of VS uit elkaar valt.

De EU moet dus de afhankelijkheid met de USA afbouwen. Alleen historisch gezien is die afhankelijkheid ontstaan omdat de EU het niet voor elkaar heeft gekregen om voldoende tegenwicht te bieden aan de USA bigtech. En dat geldt ook voor de NATO.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 13:38]

Lijkt mij veel veiliger om dit in eigen land te doen door een Nederlands bedrijf.
Weet jij een volledig Nederlands bedrijf die de capaciteit en het personeel heeft (in Nederland) om alle overheden te voorzien van de benodigde diensten?

Ik zeg niet dat het niet mogelijk is, maar of het uiteindelijk "veiliger" is durf ik te betwijfelen. Op papier gaat het in ieder geval een klus worden om alle certificeringen die de AWS, Google Cloud, IBM cloud, Azure enz in handen hebben te overtreffen....maar ik laat me graag verrassen ;)
Kansloze zaak inderdaad. Daarom zitten we op Azure: we willen diensten afnemen, niet infrastructuur.

Doe mij een NL aanbieder die in de cloud een aanbieding heeft voor data warehouse een BI die net zo goed en omvangrijk is als Azure, tegen vergelijkbare kosten? Die ga je niet vinden.
Nu niet.

Maar het afnemen van diensten is de lock-in waaraan gewerkt wordt: als je daar je hele BI op hebt opgebouwd, is de volgende stap dat je langzaam maar zeker de prijs omhoog doet. Zoals de internetproviders in NL doen: elk jaar, op de maand en dag nauwkeurig.

Kikkers zijn we. We hebben niet door dat het steeds warmer wordt.
AWS geeft je de tools om je beveiliging relatief eenvoudig tot een zeer hoog niveau op te voeren. Bij een voormalig opdrachtgever hadden wij op heel veel vlakken een zeer hoog veiligheidsniveau. Veel hoger dan ik bij andere niet cloud opdrachtgevers heb meegemaakt. Wij gebruikten daarvoor de tools van AWS. Belangrijkste daarbij was infrastructure-as-code (IAC) d.m.v. CDK. Wij hadden hierin templates gebouwd voor goede oplossingen en dat maakte veiligheidsmaatregelen die elders onwerkbaar complex zouden zijn voor ons eenvoudig toepasbaar. AWS is hierin met afstand het meest mature.

Belangrijk is hierbij dus dat AWS je de middelen geeft om relatief eenvoudig geavanceerde beveiligingsmaatregelen te nemen, waardoor je die dingen ook daadwerkelijk gaat doen.
Punt is met name het beschermen tegen AWS zelf dat, al dan niet in opdracht van, onwelvoegelijke dingen met jouw data zou kunnen doen. Dat gaat van binnen de AWS-bubbel niet lukken zonder tenminste een deel van die bubbel zelf te vertrouwen. En lukt het je wel, dan is dan niet alleen heel bijzonder maar ook breekbaar en niet heel economisch meer.
de overheid zelf heeft al genoeg problemen in de IT, dus denk dat ze beter dit niet kunnen doen.
totdat de IT hier ook op een zekere hoogte is.
Er zijn daarnaast ook risico's voor het gebruik van AWS omdat data daarbij wordt doorgestuurd naar de Verenigde Staten.

Serieus..? Denk de Overheid wel na met hun boerenverstand.. // wat moet mijn BSN relateerde diensten bij AWS servers in Amerika doen terwijl het hier in Europe ook kan Duitsland bijvoorbeeld. //
Ik denk dat deze bewering niet helemaal klopt zoals jij het uitlegt. Data van gebruikers blijft over het algemeen en gezien de privacy regels van de EU in de EU, tenzij je daar als klant een andere keuze in maakt. De data die naar AWS in de VS gaat zou dan voornamelijk telemetrische gegevens kunnen zijn óf de account gegevens van de beheerders van de applicaties die in AWS draaien (ofwel de beheerders van klanten in Nederland). BSN gerelateerde data opslaan elders dan in de EU is eigenlijk not done.
Uit het verslag:
De risico's van die datadoorgifte kunnen worden vermeden door gevoelige persoonsgegevens te versleutelen
Dat klinkt redelijk, maar daarbij lijkt de situatie geaccepteerd te worden dat de gegevens pas op de AWS diensten van encryptie worden voorzien, of al van encryptie worden ontdaan. Het argument is dat AWS de belofte doet geen backdoors te hebben. Maar AWS beheerders die van buiten de EU werken of VS wetgeving in het algemeen voldoet al niet aan de eisen die we in de EU over bescherming stellen. Encryptie is alleen redelijk als de gegevens al/pas buiten de AWS diensten daarvan worden voorzien of ontdaan. Ja maar ze hebben een belofte gedaan is als het mis gaat (als we daar al van weten) te laat.
Wat je aangeeft over encryptie geldt voor alle datacenters. Ook als ze volledig Nederlands zijn. Het is overigens in het voordeel van de cloud providers als bedrijven eigen versleuteling gebruiken omdat ze dan altijd dat excuus kunnen gebruiken om te voorkomen dat ze data beschikbaar moeten stellen. Ja er is een gerechtelijk bevel, maar de data is encrypted met een customer key waar we niet bij kunnen.

Ik ben het volledig met je eens dat dit niet 100% gegarandeerd kan worden, maar dat kan vrijwel nooit tenzij je zelf de encryptie lokaal doet en je werkgever 100% vertrouwen heeft dat jij niet om te kopen bent ;)
Dat het risico met versleutelen en beheer ook voor andere datacenters op gaat is geen redelijk argument. Het laat namelijk het belangrijke kenmerk weg dat werknemers en bedrijven van buiten de EU, dus AWS, zich niet zomaar aan de EU wetgeving kunnen houden boven de eigen wetgeving. En daarin zit het probleem bij het verplicht voldoende voorkomen van overtredingen: als je overeenkomst vooraf al niet voldoet, omdat het tegrnstrijdig is met eigen wetgeving, is het ook niet redelijk daaraan vast te houden alsof het wel voldoet. Dat is waarom handelsovereenkomsten als safe harbour voor verwerken van persoonlijke gegevens steeds onwettig blijken: beloftes maken die minder waard zijn dan geldende wetgeving van een ander land is onvoldoende. En dat is een groot verschil met EU bedrijven die afspraken maken en beloftes doen onder alleen de EU wetgevingen die hier mogelijk uitzonderingen geven. Het doel van het beschermen is dat onbevoegden, zoals andere landen, bedijven en personen uit andere landen, niet onder eigen wetgeving controle nemen of hebben op de persoonslijke gegevens uit of in de EU. En zeker niet op verwerking van een overheid van een EU land.
Jouw BSN en andere privacy gegevens mogen domweg niet buiten Europa opgeslagen worden. Er zijn echter omwegen waarop de overheid en bedrijven dat wel kunnen doen. Als men de privacy gegevens gecodeerd opslaat zijn die gegeven namelijk ineens geen privacy gegevens meer, maar een "willekeurige tekenreeks".
Amazon mag de gegevens niet op die manier versturen, die zou de codering immers zelf weer om kunnen draaien. Voor de overheid is dit echter precies de manier die ze gebruiken.
Leuk dat ze een DPIA gedaan hebben en dat daar iets uitgekomen is.
Nutteloze actie omdat de US iets hebben genaamd de CloudAct.
Daarmee kunnen ze sowieso bij alle clouddata van AWS/Azure/Oracle/...
Dit is wel heel erg kort door de bocht. Ze kunnen met cloud act niet bij alle data van de providers. Dit moet allemaal via de rechter uitgevoerd worden en op individueel niveau. Naast het feit dat de inzet van cloud act nauwelijks voorkomt én dat de bewuste cloud aanbieders daar transparant over zijn.

Als je het mij vraagt denk ik dat er eerder communicatie plaatsvindt tussen de veiligheidsdiensten tussen de VS en Nederland om alsnog aan die data te komen dan dat ze de data opvragen aan de cloud provider zelf, wat een gegarandeerde juridische strijd oplevert.
Ik bedacht net waarom heeft Nederlandse overheid geen eigen server park?
Dat is verdomd een goede vraag...
Dan hoeft Nederland gaan Azure of Amazon Web Services niet meer gebruiken.
Een deel van de Nederlandse overheidsinstanties heeft wel degelijk een eigen serverpark. Bijvoorbeeld de Belastingdienst.

Ook wordt een deel van de servers gewoon in Nederlandse datacenters gehost. Er zijn vier datacenters van de overheid. O.a. https://www.odc-noord.nl/ is er één van bijvoorbeeld (ODC = Overheids Data Center). O.a. DUO, RDW en CJIB zitten daar gehost, net als 8 ministeries.

Een andere wordt gehost door SSC-ICT: https://www.ssc-ict.nl/pr...nsten/overheidsdatacenter

En zo zijn er dus nog enkelen.

[Reactie gewijzigd door wildhagen op 22 juli 2024 13:38]

Wij (ProRail) hebben een paar eigen server parken 1 centrale om gewoon mee te werken en 2 stuks (1 backup) voor alle trein besturingsgerelateerde zaken.
Maar we hebben volgens mij ook wat zaken via Azure lopen.
Ik bedacht net waarom heeft Nederlandse overheid geen eigen server park?
Dat is verdomd een goede vraag...
Dan hoeft Nederland gaan Azure of Amazon Web Services niet meer gebruiken.
ja, historisch gezien hadden bijna alle uitvoerende diensten hun eigen infrastructuur. Partijen als de ANWB noemden zoiets vaak een rekencluster. Daarna kwamen er allerlei externe partijen met SLA's.
.

[Reactie gewijzigd door MarkHart op 22 juli 2024 13:38]

Sjeezus, wat een boter op het hoofd.
Wij werken met medische (en dus privacygevoelige) data en er is/was een beweging om dat naar MS Azure te verplaatsen. Onze DPIA zegt dat we dat dus niet mogen wegens het klappen van PrivacyShield en omdat Microsoft een Amerikaans bedrijf is.

Nog steeds hoor ik hier teleurstelling dat we geen Azure mogen gebruiken, en mensen beginnen zich in allerlei bochten te wurmen met VPN tunnels en rare encryptieschema's (e.g. een API op Azure, met een VPN tunnel naar een on-premise database... wtf... je bottleneck is nog steeds je database. Je lost niks op, je hebt het alleen maar moeilijker gemaakt) om toch maar Azure te kunnen gebruiken in hun project. Ik begin me een beetje kwaad te maken van de reflex om overal maar cloud (Azure/AWS) te WILLEN gebruiken. Telkens hoor ik het argument "schaalbaarheid" en "gemakkelijk", maar wanneer je niet wil investeren in kennis van security dan moet je niet met privacygevoelige data willen werken.
Cloud services geven je handvatten om dingen snel en gemakkelijk te kunnen doen, maar dan moet je NOG STEEDS weten waar je mee bezig bent. Dus dat er een "gemakkelijk vinkje" is voor security parameters wil niet zeggen dat je niet hoeft te weten wat er ACHTER dat vinkje gebeurt.

Dus neem "gewoon" die beheerder aan, bouw je kennis op, en mik een paar servers in een rack in een datacenter. Pas je architectuur aan dat de zaken die ECHT schaalbaar moeten zijn wel op een cloud service kunnen draaien, maar dat er geen privacygevoelige data in zit.

[Reactie gewijzigd door boxlessness op 22 juli 2024 13:38]

Ik begin me een beetje kwaad te maken van de reflex om overal maar cloud (Azure/AWS) te WILLEN gebruiken. Telkens hoor ik het argument "schaalbaarheid" en "gemakkelijk", maar wanneer je niet wil investeren in kennis van security dan moet je niet met privacygevoelige data willen werken.
Ik hou zelf in het achterhoofd dat men nog steeds gelooft dat de cloud goedkoper is dan wat ze eerst hadden. (Dat klopt vaak wel maar grote denkfout is dat de meesten nooit de echte prijs van IT hebben gezien omdat ze dusver alleen naar de licentieprijs keken, niet naar het personeel en andere bijkomende kosten voor bijvoorbeeld backups (die misschien wel helemaal niet gemaakt werden)).

De meesten zijn inmiddels wel zo verstandig om de cloud niet te benaderen als een bezuiniging maar dat je eigenlijk fors meer geld gaat uitgeven wil er meestal nog niet in.

De tweede factor is dat de managers hem beginnen te knijpen. Ze hebben zelf weinig idee waar ze mee bezig zijn en geloven hun eigen personeel haast niet omdat het allemaal zo negatief klinkt. Als ze al genoeg geschikt personeel kunnen krijgen. Daarom wordt er steeds vaker vertrouwd op de gratis consultants van de leverancier. Die uiteraard adviseren meer producten van hun werkgever in te zetten.

Ze hebben het gevoel helemaal klem te zitten en kiezen dus voor de partij de verlossing belooft. De grootste partijen op de markt hebben de mooiste verhalen. Ook voor Azure was er bij velen al een soort blind vastklampen aan MS omdat het "gebruikersvriendelijk" is of "iedereen kent het".

Ten slotte is het lastig om op te boxen tegen het enorme schaalvoordeel dat de megatechbedrijven hebben.
Dat is wel een behoorlijke valkuil want de markt wordt daarmee volledig ontoegankelijk. Vrijwel niemand in de wereld heeft genoeg geld om vanuit het niets een bedrijf op te zetten dat op een dergelijke schaal kan profiteren. Misschien dat een bedrijf als Shell genoeg geld heeft om te proberen maar dan nog blijft onwaarschijnlijk.

[/quote]
Cloud services geven je handvatten om dingen snel en gemakkelijk te kunnen doen, maar dan moet je NOG STEEDS weten waar je mee bezig bent. Dus dat er een "gemakkelijk vinkje" is voor security parameters wil niet zeggen dat je niet hoeft te weten wat er ACHTER dat vinkje gebeurt.
[quote]

Het is heel makkelijk om op papier een hoop zaken goed voor elkaar te hebben en toch geen idee te hebben waar je mee bezig bent. Als beheerder wordt het ook allemaal steeds ondoorgrondelijker want bedrijven als Amazon en MS willen helemaal geen informatie met je delen over hoe hun systemen intern werken. Je moet er maar op vertrouwen dat ze alles goed doen en in jouw belang. Met wat aandringen mag je misschien nog een audit rapport zien dat eigenlijk maar uit één zin bestaat: "Er zijn geen significante afwijkingen van de gestelde normen geconstateerd" en dan weet je nog niks maar daar moet je het mee doen.
Misschien dat een bedrijf als Shell genoeg geld heeft om te proberen maar dan nog blijft onwaarschijnlijk.
Als iemand dat voor Shell (indirect) gewerkt heeft, kan ik je verzekeren dat ze daar niet veel gaan doen. Veel penny pinching op bestaande projecten en dan geld smijten als het iemand zijn carrier maakt. En dat is het probleem, niet enkel geld maar ook politiek.

Een bepaald project had problemen (je kent het verhaal van outsourcing naar oost Europe en dan ... ironisch genoeg was dat een resultaat van Shells penny pinching).

Uiteindelijk liep de boel totaal in het honderd en wanneer er een verlies van personeel was... Ik nam de boel over, en herprogrammeerde het ganse project in nog geen 6 maand tijd (hou rekening dat was een systeem van jaren ontwikkeling). En het doel was om het project verder te zetten onder mijn firma. Alles was afgesproken, project was daar, firma ontwikkeld...

En dan kregen we de koude douche in de vergadering dat 1 van de junior directie leden een "alternatief" gevonden had in een systeem dat eigenlijk niets anders was dan een open source oplossing via een 3de bedrijf en met niets ontwikkeld.

Maar die junior directeur had een "win" nodig om terug te gaan naar Shell (is een vreemd systeem van dochterbedrijven in Shell waar ze mensen laten ervaring opdoen als directieleden en dan terugkomen als managers in shell zelf). En ja, ons project was de deur buiten (met de nodige kosten voor ons).

Grappig genoeg, heeft het hun nog een jaar+ gekost om een deel van de functionality te krijgen dat we al geschreven hadden. Maar dat was niet belangrijk want de junior directeur was intussen terug in het moederbedrijf met een mooie palmares van "zie, ik heb die gedaan". Feit dat dit hun VEEL meer geld gekost heeft, voor minder functionaliteit. Nu ja, bedrijven en politiek ;)

Ik zie Shell NO WAY een project opzetten zoals AWS met mijn ervaring van hun interne politiek.
Ik zie Shell NO WAY een project opzetten zoals AWS met mijn ervaring van hun interne politiek.
Ik bedoelde dat niet als suggestie maar als voorbeeld van een van de weinige bedrijven dat rijk genoeg is om het te kunnen proberen. Buiten de techbedrijven hebben alleen banken en oliebedrijven zo veel geld.

Het het voorbeeld is ook weer niet helemaal willekeurig want ik heb Shell/oliebedrijven wel eens eerder genoemd als potentiele kandidaat voor een eigen cloud omdat die sector op zoek moet naar een nieuwe manier om geld te verdienen nu we van de olie af willen (ongeacht op welke termijn). Voor een cloud heb je naast veel geld en personeel ook een hoop energie nodig. Daar is een bedrijf als Shell wel in thuis. Daarnaast gebruikt deze sector ook enorm veel rekenkracht bij het zoeken naar olie dus er is wel enige expertise.

Maar deze zijstraat is wel erg offtopic. Mijn punt is vooral dat er maar een handvol bedrijven in de wereld is met genoeg geld om het op te nemen tegen een MS of Amazon (los van de vraag of ze dat willen).
Mijn verwachtingen waren al laag toen ik het screenshot uit Word op de webpagina vol rode en blauwe spellingcontrolewaarschuwingen zag maar dit is wel heel gek.

De helft van de oplossingen lijkt "vraag Amaxon vriendelijk om onze wetten te respecteren" te zijn. Als dat een optie was, hadden we heel Privacy Shield niet nodig gehad. "Gebruik geen EC2 voor privacy

Ik verwacht dat bij het eerste de beste datalek waaruit blijkt dat de overheid gegevens niet versleuteld heeft of hun pseudoniemisering ontoereikend blijkt dit hele onderzoek op zijn gat valt. Maar hee, tot die tijd geeft de overheid hun zaken nu rechtgeluld dus alles is weer okee.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 13:38]

Wat ik wel interessant vind, is dat Meta nog geen maand geleden een recordboete heeft gehad, waarbij Meta als argument voor data doorgifte zei "dat zij data alleen sterk versleuteld overbrengen vanuit Europa naar haar datacenters in de VS. Dus dan kan FISA of die executive order wel toelaten dat de NSA de onderzeekabel aftapt (het gaat immers om personen buiten de VS), maar ze kunnen er niets mee."[1]

Dit werd echter juridisch niet gezien als argument.

Nu wilt de Nederlandse Overheid graag AWS gebruiken, en ze gebruiken in hun DTIA het argument "De risico's van die datadoorgifte kunnen worden vermeden door gevoelige persoonsgegevens te versleutelen en accountgegevens van beheerders te pseudonimiseren."

Zoals al vaker is geconcludeerd zijn persoonsgegevens die encrypted zijn gepseudonimiseerde persoonsgegevens, en vallen daarmee nog steeds onder de AVG.[2]

Het voelt voor mij alsof de DTIA dus is gedaan met de insteek "hoe kunnen we problemen recht brijen zodat we AWS kunnen gebruiken" ipv dat er een objectieve "DTIA" is gedaan.

[1] https://blog.iusmentis.co...erbod-ermee-door-te-gaan/
[2] https://blog.iusmentis.co...g-als-ik-ze-elders-opsla/
Wat ik wel interessant vind, is dat Meta nog geen maand geleden een recordboete heeft gehad, waarbij Meta als argument voor data doorgifte zei "dat zij data alleen sterk versleuteld overbrengen vanuit Europa naar haar datacenters in de VS. Dus dan kan FISA of die executive order wel toelaten dat de NSA de onderzeekabel aftapt (het gaat immers om personen buiten de VS), maar ze kunnen er niets mee."[1]

Dit werd echter juridisch niet gezien als argument.

Nu wilt de Nederlandse Overheid graag AWS gebruiken, en ze gebruiken in hun DTIA het argument "De risico's van die datadoorgifte kunnen worden vermeden door gevoelige persoonsgegevens te versleutelen en accountgegevens van beheerders te pseudonimiseren."

Zoals al vaker is geconcludeerd zijn persoonsgegevens die encrypted zijn gepseudonimiseerde persoonsgegevens, en vallen daarmee nog steeds onder de AVG.[2]

Het voelt voor mij alsof de DTIA dus is gedaan met de insteek "hoe kunnen we problemen recht brijen zodat we AWS kunnen gebruiken" ipv dat er een objectieve "DTIA" is gedaan.

[1] https://blog.iusmentis.co...erbod-ermee-door-te-gaan/
[2] https://blog.iusmentis.co...g-als-ik-ze-elders-opsla/
Bovendien, hoe lang loopt dit proces (of de leveranciersselectie) al? De wereld is niet meer hetzelfde als 3 jaar geleden, en data heeft nu een factor meer AI-powers..

En de laatste jaren is het ook wel duidelijk geworden hoe weinig mensen als Kaag en Rutte verstand hebben van data.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 13:38]

Wat ik in de DTIA interessant vind is het volgende:
Depending on the risks of unauthorised access to the data, government organisations may want to use AWS Nitro, a collection of security measures that allows hardware based VM encryption and key management for customer virtual machines. See: https://aws.amazon.com/ec2/nitro/
SLM Rijk and AWS have signed the new Controller to Processor SCC.
Ik ben zelf niet bekend met AWS Nitro, maar als je het dan combineert met een VM zou het mogelijk zijn om de eigen sleutels te beheren? In welk geval je wel een sterk argument hebt in het kader van de DTIA.
Zijn er überhaupt Europese hosters die meer bieden dan (virtuele) machines waar je zelf alsnog aan het roer komt te staan, tenzij je vele uurtje-factuurtje bedragen gaat spenderen aan managed hosting die niets meer is dan een extern persoon het handmatige beheer in handen geven?

Zo zou deze website alternatieven voor AWS horen te geven, maar als ik dan het lijstje en de bijbehorende diensten zo bekijk is het eveneens alleen basale zaken, zoals VPS, load balancers, wat netwerk zaken en eventueel nog een opslagdienst. Zaken als RDS, NoSQL varianten, FaaS etc. ontbreken dan volledig.
Ik vind dit maar lastige rapporten. Technisch gezien klopt het wel maar het beeld dat onstaat is dat alles wel goed zit terwijl ik toch een paar flinke struikelblokken zie.

Het komt allemaal samen in het volgende statement:
Privacy Company en SLM stellen dat de overheid de dienst alsnog kan gebruiken, ondanks die risico's. Dat kan door ze deels te accepteren of door ze te beperken. Daarvoor noemt SLM verschillende mogelijkheden.
Ik vind het een beetje een dooddoener. Alles in deze wereld is mogelijk als je het risico accepteert. Zonder parachute uit een vliegtuig springen is mogelijk als je het risico accepteert. De gebruikelijke manier om het risico van uit vliegtuigen springen te beperken is om wél een parachute te gebruiken.


Wat voorbeelden:

"if (the customers) conclude that AWS's recording of IP addresses of visitors to Dutch government
applications or websites causes a high data protection risk, they can either host their website somewhere else, or use a proxy before redirecting visitors to AWS."

Technisch gezien klopt het hoor maar wie gaat daar in praktijk echt iets mee doen? De niet-technische manager van de afdeling leest alleen "AWS is toegestaan".

Ander voorbeeld: "Because the level of data protection in the USA is not considered adequate (yet),
there are inherent risks related to the transfer of personal data to the USA. (...) Government organisations can mitigate these risks by pseudonymising the admin account data, and instructing admins never to upload personal data as part of support tickets."

Klinkt goed, maar in praktijk lijkt me dat behoorlijk lastig en iets dat iedereen verkeerd zal doen als ze niet strak bij de hand worden gehouden. Je zal toch op z'n minst een apart e-mail-adres en een aparte 2fa-oplossing moeten hebben wat in praktijk vaak een aparte telefoon + abonnement is. Als je verwacht dat admins hun eigen telefoon gebruiken voor 2fa dan zal die pseudonimsering niet lang in stand blijven.
Mij lijkt het haast niet te doen en een gevalletje "leuk bedacht maar in praktijk onuitvoerbaar voor de beheerders waar het om gaat".

Nog een: "In view of AWS's processor role, and the limited purposes for which AWS is contractually allowed to process these personal data, SLM Rijk can largely mitigate the risks from the lack of transparency by organising audits to verify AWS's compliance with the guarantees in the enrolment framework."
Wat moet je daar nu weer mee? In dit onderzoek hebben ze niet de info gekregen die ze nodig hebben. De oplossing is zelf een onderzoek doen. De kans lijkt me groot dat je de benodigde informatie als nog niet krijgt.


Voor de duidelijkheid, het rapport en de technische adviezen kloppen wel maar ik ben bang dat er toch een verkeerd beeld ontstaat. Het gevoel dat ik krijg bij de introductie is namelijk "alles ok behalve een paar kleine puntjes die je eenvoudig kan zelf kan oplossen, gewoon doen!". Maar als ik verder lees trek ik een heel andere conclusie, zeker als je een 'alles of niets' antwoord wil en er op veel plekken de wens bestaat om alle hosting (en/of andere dienstverlening) op één plek onder te brengen.

CAPSLOCK2000 hoeft nooit meer een paraplu te gebruiken na het oplossen van het regenprobleem.
CAPSLOCK2000 kan veilig in de zon zitten na het oplossen van het UV-stralingsprobleem.
Ik vind dit maar lastige rapporten. Technisch gezien klopt het wel maar het beeld dat onstaat is dat alles wel goed zit terwijl ik toch een paar flinke struikelblokken zie.

Het komt allemaal samen in het volgende statement:

[...]


Ik vind het een beetje een dooddoener. Alles in deze wereld is mogelijk als je het risico accepteert. Zonder parachute uit een vliegtuig springen is mogelijk als je het risico accepteert. De gebruikelijke manier om het risico van uit vliegtuigen springen te beperken is om wél een parachute te gebruiken.
Uit een vliegtuig springen is ook geen laag risico. Zet jij je woonkamer af met veiligheidshekken en trek je een klim gordel aan als je een lamp gaat vervangen?

Nee? Precies, klein risico, dat accepteer je. En als het mis gaat is er niemand dood, hooguit een gebroken pols, waar ook een business continuity plan voor is.
Met andere woorden: laten we nu niet moeilijk doen, het is allemaal prima veilig!

Niemand zal zich hierin verdiepen in de basis. Het is dus "business as usual".
Maar weten ze dan ook

Op dit item kan niet meer gereageerd worden.