Vlaamse privacywaakhond is kritisch op gebruik van AWS bij onderwijsdatabank

De Vlaamse overheidstoezichthouder voor privacy is erg sceptisch over het gebruik van Amazon Web Services binnen het Belgisch onderwijs. De instantie bracht advies uit over het gebruik van AWS in een aantal onderwijsdatabases, maar dat advies is zeer negatief.

Verschillende Vlaamse onderwijsinstanties vroegen de Vlaamse Toezichtcommissie of VTC om advies over de opslag van studentengegevens. De toezichthouder concludeert nu in een rapport dat de plannen van die onderwijsinstanties mogelijk in strijd zijn met de Europese privacywetgeving. Het departement onderwijs en vorming, het Agentschap voor onderwijsdiensten en het Agentschap HogerOnderwijs, volwassenenonderwijs, kwalificaties en studietoelagen wilde van de toezichthouder een advies over het plan om databases in te zetten waarmee zij beter onderling kunnen samenwerken. In die databanken zouden ook studentengegevens komen te staan. Het plan is om de databanken in Amazon Web Services te zetten.

Met dat laatste heeft de toezichthouder veel moeite. "Het overdragen van veel persoonsgegevens van veel personen aan eenzelfde niet-Europese cloudprovider, terwijl niet bewezen is dat de gegevensbescherming van het land van de ontvanger van de gegevens vergelijkbaar is met de Europese, is niet conform de principes en bepalingen van de AVG", schrijft de instantie. Het zou met name gaan om 'kroonjuwelen'; gevoelige gegevens over studenten, veelal kinderen en jongeren.

In het rapport waarschuwt de VTC voor veel verschillende 'enorme risico's'. Zo is er de mogelijkheid van 'vergaande profilering'. Vendor lock-in zou ook een probleem zijn. Het key management zou bij AWS liggen en dat 'roept vragen op bij de VTC'. Ook zou er in de risico-evaluaties 'onvoldoende rekening zijn gehouden met het risico voor de betrokken burgers'. De risicoanalyse keek volgens de VTC alleen naar de risico's voor de betrokken instanties. "De data protection impact assessment is dus niet bedoeld zoals in de AVG."

De VTC hekelt ook de houding van de onderwijsinstanties over de zogenaamde verplichting om AWS te gebruiken. Het departement Onderwijs en vorming stelde dat AWS de enige aanbieder is waar de data kan worden ondergebracht. De VTC noemt zelf meerdere voorbeelden van cloudproviders waarbij de data wel op Belgisch grondgebied zou worden verzameld, namelijk het Belgische G-Cloud en VPC.

De VTC is sinds mei 2019 de toezichthouder op het gebied van privacy binnen de Vlaamse overheid. De VTC heeft een aantal bevoegdheden zoals het uitbrengen van bindende adviezen en het uitvoeren van onderzoek. Het heeft echter geen boetebevoegdheid. Daarvoor is er de Gegevensbeschermingsautoriteit, de federale toezichthouder voor heel België die ook voor privépersonen en bedrijven optreedt. Voorlopig geldt het VTC-rapport nog als een advies en is het geen bindend verbod op het gebruik van AWS. Wel moeten de onderwijsinstanties nu al beginnen met het weg migreren van gevoelige data van AWS.

Door Tijs Hofmans

Nieuwscoördinator

02-10-2020 • 18:19

93 Linkedin

Reacties (93)

93
90
50
13
2
28
Wijzig sortering
Uit het rapport:
De alternatieven (G-cloud, VPC met datacenters op Belgisch grondgebied en dus beter onder controle te
houden) worden als onaanvaardbaar voorgesteld op basis van minder technische
beschermingsmaatregelen, minder performantie en schaalbaarheid, maar zonder dat dit aangetoond
wordt.
Dus die G-cloud is een interne wannabe-cloud binnen de overheid, via smalls VZW. Dat is niet Google cloud! https://gcloud.belgium.be/ Ze bieden onder andere Vmware, redhat openstack 10 en Openshift 3.11 aan.
Redhat openstack 10 is dus al een tijdje end of life en openshift 4.x bestaat ook al enige tijd. De gemiddelde uptime van de geleverde diensten zal ergens tussen de 90% en 98% liggen. Vraag maar eens aan een apotheker hoe vaak het digitale platform voor digitale voorschriften offline is, leuk als je dringend medicatie nodig hebt (er is een omslachtige noodprocedure).
Komt er nog bij dat beide datacenters op nog geen vijf kilometer van elkaar staan in Brussel Zuid.

Dus ja, ik ga akkoord met het argument van de Vlaamse onderwijsinstanties. En aantonen is heel makkelijk, vrijwel alle geleverde infrastructuur/software is EOL of zelfs volledig out of support. Best triest dit rapport van de VTC, de redeneringen die ze gebruiken slaan op niets en er is blijkbaar amper onderzoek gebeurd. Dit ruikt naar een politiek spelletje.

[Reactie gewijzigd door dovo op 2 oktober 2020 20:40]

Met de VPC (Vlaamse Private Cloud, kwestie van een verwarrende afkorting te kunnen verzinnen) loopt dat anders redelijk goed. De security is dik in orde, en wat de support betreft zal het meevallen intussen. Een tijd geleden was de support nog houterig, maar dat komt omdat het een nieuw platform is. De mensen erachter wisten wel wat ze deden, ze wisten nog niet hoe ze het moesten doen. Het platform op zich is best goed.

VPC (https://www.hbplus.be/services/cloud-datacenter) is een opzet van HB-plus, wat dan weer een samenwerking tussen DXC en Proximus (vroeger HP en Belgacom, vandaar de naam) is. De hosting zit kort bij Mechelen, dus daar zijn ook geen problemen met buitenlandse hosting of iets dergelijks.
Anoniem: 368883
@Giesber3 oktober 2020 10:42
Werk jij bij DXC of zo? Ik was "verplicht" om er mee samen te werken als consultant bij de Vlaamse Overheid, en het is huilen met de pet op. Vergeet elke vorm van flexibiliteit, wil je een server aanvragen of firewall-rule laten openzetten? Hier is een Excel-sheet die je moet invullen die zo complex is dat OpenOffice er op crasht. Vervolgens moet je 3 weken wachten tot die sheet door elke review board is gegaan en hopelijk wordt goedgekeurd. Ben je ergens een regeltje vergeten in te vullen? Pech!! Want dan begint het weer van voor af aan.

Wil je tools als TerraForm gebruiken om VM's te managen op de "DXC-cloud"? Vergeet het maar! De Excel-sheet van de duivel, die ga je gebruiken. Hoe durf je om tools te willen gebruiken die provisioning makkelijker maken? Daar kan DXC niks op verdienen, dus dat wordt afgeblokt.

Oh wacht, je kan gebruik maken van hun "managed services", was ik bijna vergeten. Dan beheren zij je infrastructuur. Je moet wel zelf draaiboeken aanleveren hoe ze het moeten managen want bij de minste afwijking ben je zelf terug verantwoordelijk. De reden: Ze hebben heel dat boeltje ge-outsourced naar India, waar ze het laten managen door mensen met 0 technische kennis en peanuts worden betaald om stapjes in een draaiboek op te volgen. Ja hoor, dat heet "managed services" in de wereld van DXC: Je betaalt het dubbele om een Indier een een draaiboek te laten aflopen en niks support als het misloopt.

Er zijn genoeg departementen bij de Vlaamse Overheid die willen dat DXC buiten vliegt (en bij sommige departementen is dat ook al voor een deel gebeurd).

En bovenal DXC is nog altijd deel van HP, een Amerikaans bedrijf. Bijgevolg ook nog altijd onderhevig aan de patriot-act dus. Het feit dat ze een datacenter in Mechelen hebben verandert daar niks aan...

[Reactie gewijzigd door Anoniem: 368883 op 3 oktober 2020 10:48]

Voor de duidelijkheid : DXC Technology zoals het volledig heet is een merger van het voormalige HP Enterprise Services (EDS is daarin opgegaan) en CSC. Het is dus een nieuw (amerikaans) IT services bedrijf dat geheel los staat van HP Inc of Hewlett Packard Enterprise... dus ja.. ze komen gedeeltelijk voort uit HP in een ver verleden maar DXC zal HP Inc of Hewlett Packard Enterprise toch echt als een extern bedrijf zien omdat dit in wertkelijkheid ook zo is. Hun datacenter activiteiten in Europa houden zich gewoon aan de europese regels maar het is een Amerikaans bedrijf dus tja.. waarom alle overheden (ook in Nederland) persé met een Microsoft of AWS of DXC in zee willen gaan snap ik ook niet altijd.

Ik ga niet in op je slechte ervaringen met DXC shared services want ik geloof wel dat jij dit zo hebt ervaren; het goedkoopste contract levert niet de service die jij er van verwacht. Moet je dus gaan klagen bij de Vlaamse Overheid omdat ze te knijperig zijn een duurder contract af te sluiten. Het is overigens niet ge-outsourced naar India, de meerderheid van hun mensen zit niet in Europa maar in lage-lonen landen omdat men anders al helemaal niet meer op prijs kan concurreren met de (veelal Indiase) concurrenten ;)
De service desk mensen zijn meestal overigens wel werkzaam bij daarin gespecialiseerde bedrijven die DXC dan inhuurt volgens de wensen van de klant, alleen deep technical support personeel is in dienst van DXC tenzij de klant een dedicated team wil en daarvoor ook betaalt.
Dit is overigens niet anders dan bij andere IT dienstverleners die shared services leveren, kijk maar eens in Cyberjaya (Kuala Lumpur Maleisie) waar alle IT reuzen gezellig naast elkaar zitten met 10 duizenden medewerkers die ze van de Universiteiten een paar straten verderop werven...

[Reactie gewijzigd door rhk22463 op 3 oktober 2020 14:19]

Beste anonieme,

G-Cloud & Smals waren vijf jaar geleden bij de top-3 Early Adopters van containers en meer bepaald van OpenShift in Europa. Onze experts hebben nog samen met Red Hat de multi-tenancy in OpenShift 3.5 op punt gesteld.
https://www.techzine.be/b...van-containers-in-europa/
https://www.computable.be...thes-rond-containers.html

In tegenstelling tot public cloud providers zorgen we ervoor dat grote overheidstoepassingen die je niet elk jaar vanaf nul heropbouwt over langere tijd worden ondersteund. Dat is niet achterlopen op technologisch vlak. Dat is doen wat je gebruikers nodig hebben.

Onze datacenters zijn Tier3+ en zeker bij de top in België. Het eHealth-platform dat we ondersteunen, verwerkt tussen 15-20 miljard transacties per jaar. En ja, als daar iets misloopt, met zo'n aantallen, heeft het halve land dat geweten. In dat ecosysteem zitten meerdere actoren (oa. Mycarenet/ATOS, Recip-e...) waar het ook al eens fout loopt. Onze cijfers mogen gezien worden.

Uw reactie lijkt meer op persoonlijk sentiment dan op feiten gebouwd.

Ik hoop alvast dat de auteur van dit stuk zich niet wil baseren op dit soort lage laster.

Jan-Frans, Smals, 20u29
Doen wat je gebruikers nodig hebben ? Dus als je gebruikers een outdated en onveilig platform willen dan blijf je dit leveren... wel dat is net de reden waarom het vaak fout gaat. Gebruikers moeten beseffen dat het niet stopt bij het bouwen van een applicatie maar dat het dan pas begint.
Sorry, maar je post lijkt een reclame blok zonder echte feiten..
G-Cloud & Smals waren vijf jaar geleden bij de top-3 Early Adopters van containers en meer bepaald van OpenShift in Europa.
Dus 5 jaar geleden (wat een eeuwigheid is in IT) zat je in een top 3 (waarbij je, neem ik aan, nummer 3 bent want anders had je wel eerste of tweede vernoemd) bij een ploeg early adopters (wat gewoon helemaal niets zegt anders dan dat de software toen nog amper af was?)..

Onze experts hebben nog samen met Red Hat de multi-tenancy in OpenShift 3.5 op punt gesteld.
Lees: we hebben een berg geld gegeven aan Red Hat om het in elkaar te draaien. Zie ook je links...
bevestigt Stef Schampaert, Country Manager van Red Hat in België

In tegenstelling tot public cloud providers zorgen we ervoor dat grote overheidstoepassingen die je niet elk jaar vanaf nul heropbouwt over langere tijd worden ondersteund.
Wat een onzin, bij de publieke providers zie je dat ontwikkeling essentieel is anders overleef je het niet. De overheid zit vast aan specifieke aanbieders vanwege Europese aanbestedingswetgeving en die providers hebben echt 0,0 incentive om verder te ontwikkelen. De overheid wil alleen maar lange ondersteuning zodat ze niets hoeven te onderhouden..
Gezien deze datacenters precies dezelfde software draaien als honderden andere datacenters en ondersteuning helemaal niet van het datacenter komt maar van de software, is dit echt allemaal volledige onzin.

Dat is niet achterlopen op technologisch vlak. Dat is doen wat je gebruikers nodig hebben.
Nee, dit is geen innovatie tonen in een vakgebied wat gebaseerd is op innovatie. En klanten gegijzeld houden op oudere versies. Zodat deze ook niet kunnen innoveren.

Onze datacenters zijn Tier3+
Blabla, dat bestaat helemaal niet en is een marketing term. Deze wordt ook gebruikt om aanbestedingen te manipuleren (zorg dat je tier 3+ vereist in de aanbesteding want normale datacenters hebben dat niet... Om dat het niet bestaat als standaard).

Uw reactie lijkt meer op persoonlijk sentiment dan op feiten gebouwd.
Als u reageert met deze bewering dan zou het u sieren om daadwerkelijk wat cijfers te posten.. Want u beweringen zijn enkel ook maar dat, beweringen.

Ik hoop alvast dat de auteur van dit stuk zich niet wil baseren op dit soort lage laster.
Ik hoop niet dat ze in de reacties kijken, dan slapen ze uberhaupt beter ;)

Anyway, om op cijfers terug te komen. Laten we even kijken welke waar AWS allemaal voor gecertificeerd is:
https://aws.amazon.com/compliance/programs/
We doen er ook een paar andere bij, voor de lol:
https://cloud.google.com/security/compliance
https://azure.microsoft.c...trusted-cloud/compliance/

Laten we even kijken waar het Smals DC voor gecertificeerd is (hint: niets te vinden):
https://www.smals.be/nl/content/datacenter-services

Mijn excuses als ik iets bot overkom, ik ben helemaal voor lokale datacenters maar kom niet met een inhoudsloos marketing verhaal.
Komkom zeg...

- Top 3 EU 2015: Dit moet je aan Red Hat gaan vragen (ik denk een buitenlandse telco en bank). In elk geval is oa. KBC bij ons komen kijken hoe we het hadden aangepakt.

- Multitenancy: Draai het nu niet om. Onze mensen hebben Red Hat geadviseerd vanuit onze ervaringen, aangezien we één van de weinigen waren met +1000 containers voor zeer kritieke toepassingen (oa. eHealth) in productie, én multi-tenant.

- We zijn niet tegen public cloud en gebruiken het zelf. Maar voor de levenscyclus van overheidstoepassingen heb je continuiteit nodig, technologisch en qua mensen. We houden hen niet 'gegijzeld' op oude platformen, maar gaan hen ook niet pushen naar het nieuwe met alle kosten en risico's vandien.

- Datacenter en certificaties: Vaak dure boel om iemand anders te laten vaststellen wat je zelf al weet. Komt van pas in B2B marketing. Iets wat wij eigenlijk niet doen, als niet-commerciële organisatie. We kennen onze infra en zijn daarover transparant naar de instellingen, die samen mee Smals besturen.
Aan de andere kant: geen enkel initiatief (national maar ook niet op eu-niveau) biedt de diensten aan die we willen gebruiken en die haalbaar zijn. Zelfs basic bitch spullen als object storage of managed RDBMS kan je niet bij een vendor krijgen. Men heeft al moeite met file-based services en dat is al weer achterhaald.

Feit blijft dat de ontwikkeling intern gewoon afwezig is, en alles op z'n best whitelabel Amerikaanse software op Amerikaanse hardware installeren is.
Misschien domme vraag, maar waarin verschillen de VTC de GBA ( de vroegere "Privacy Commissie" ? )
Is het ene lokaal/Vlaanderen, het andere voor België ? Ik ben er al even tussenuit :)
GBA is België én bevoegd voor alle sectoren.
VTC gaat alleen specifiek over de publieke sector, enkel in Vlaanderen. ;-)
Scherp, kende ik niet! Heb het aangepast, dank!
Ken je eigen taal.
Een instelling en een instantie zijn toch echt wel niet hetzelfde...
Geef mij maar een jus d'orange van appel svp!
Nochtans heeft het VTC een oplossing van Het Facilitair Bedrijf (Vlaamse Overheid) op AWS goedgekeurd waar het key management niet bij AWS zit, maar met customer keys.
Precies. CMKs gebruiken en klaar is het gezeur. Slechte software maken kan altijd maar zolang je data niet leesbaar is door de grote boze provider (of het land van herkomst) maakt het een stuk minder uit.

Ze vergeten voor het gemak ook even dat een cloud meer is dan wat VMs ergens aanzetten. Dat kan iedereen namelijk wel, maar daar zit de meerwaarde niet.
Een zuderans wordt hier ook wel eens een vruchtensapje genoemd.
Maar of het dan van sinaasappel- of appelsiensap gemaakt is zal er ook wel toe doen.

Overigens had ik natuurlijk ook graag geweten wat het verschil is tussen een instantie en een instelling. Een instantie is onnodig, onnuttig gedweep met Frans. Vooral van mensen die eigenlijk geen bal van Frans afweten.
Nochtans heeft het VTC een oplossing van Het Facilitair Bedrijf (Vlaamse Overheid) op AWS goedgekeurd waar het key management niet bij AWS zit, maar met customer keys.
Haha, wat is me dat nu weer voor een samenraapsel en hutsekluts van NederFrAnglees?

Ik mainteneer, want het staat in de TaalVanDalen!
Altijd dat gezeik van privacy etc, terwijl 3/4de van het gepeupel rustig alles op facebook en instragram zet. Ik host alles zelf op Google cloud, waarom ... het was het goedkoopste en voor mijn noden, werkt dit echt perfect. Simpele setup, ik moet mij geen zorgen maken. Ik maak er 6 jaar gebruik van ofzo, denk 1x een uurtje downtime gehad ofzo in al die tijd. Niks om van wakker te liggen. Ken anders best wel wat meer lokale hosters/platform, en daar heb ik bijna altijd wel meer voorvallen van mee gehad. Wat wel zo is, support op een lokaal platform is wel een pak beter (of zou toch moeten zijn). Maar als je rekening groot genoeg is, dan kan er best wel wat support van af en korting.

En wat gaat de Amerikaanse overheid met die gegevens doen ? Zelf een databank aanleggen van alle Belgen in het onderwijs ... Gaan ze veel aan hebben. Soms vind ik dat het "neuten om te neuten" is. Je moet je eens afvragen, want kan je nu echt doen met die data. De Amerikaanse overheid gaat jou geen mailtje sturen van :"hey moet je een visa hebben".

Zal wel -2 worden ofzo, maar dit is mijn mening
Er is nog wel een verschil of iemand zelf informatie over zichzelf op Facebook/Instagram/LinkedIn etc. zet, of dat een organisatie dat doet. Een organisatie heeft verantwoordelijkheid naar klanten/afnemers dat ze voorzichtig omgaan met persoonlijke data, en die data maar klakkeloos bij een buitenlandse partij zetten is volgens de wet dus niet voorzichtig omgaan met die data.

Nu weet ik niet wat jij allemaal in Google Cloud hebt draaien, of dat privé hobbyprojecten zijn of zakelijke omgevingen, maar als het het laatste is, hoop ik dat je wel iets verder hebt nagedacht dan alleen "het was het goedkoopste" en dat je je klanten/afnemers serieus neemt en dus ook over databescherming nadenkt.
Buiten multinationals ligt geen enkele KMO echt wakker van waar die data staat. Altijd dat GDPR geleuter. En ik zeg altijd tegen mijn klanten, de data staat bij Google op een Belgische server. Als ze dit niet willen kan dat ook ergens anders, maar dan gaat de prijs omhoog. Dan is er nooit een probleem om dit bij Google te zetten.

De afkeer die er is om toch maar iets op AWS/Azure/Google cloud te zetten is tegenwoordig zeer groot. En het moet allemaal lokaal etc. In Amerika gaan ze nog iets verder, daar moeten alle persoonsgegevens geëncrypteerd worden opgeslagen. Leuk als je een keer iets moet gaan liggen opzoeken omdat een klant wat verkeerd gedaan heeft. Het moet ook werkbaar blijven. En dat is nou net het probleem. Je moet je tegenwoordig in bochten wringen om nog iets te kunnen doen, of goed te doen voor iedereen. Een klant van mij had van een klant van hem een document van 26 pagina's gekregen over het "verwerken van gegevens", daar stond zelfs letterlijk in dat ze de broncode wouden inkijken van mijn software die hij gebruikte (en dus ook mijn platform), not going to happen.

We hebben een grote afkeer voor AWS/Azure/Google cloud, maar we gaan wel Windows en office365 gebruiken ... En we gaan gezellig bij Amazon shoppen en gebruiken Google (of misschien zelfs Bing) om iets op te zoeken ... Daar stopt het voor mij. En wie maakt geen gebruik van deze diensten op zakelijk vlak ? Het kan natuurlijk anders, maar het is een beetje hypocriet
Maar dan ga je voorbij aan de vraag of het terecht is dat die KMO's niet wakker liggen van waar de data staat, want ze hebben wel de wettelijke plichten vanuit de AVG waaraan ze moeten voldoen. Die afweging moeten ze wel maken en daar zal jij ook zeker een verantwoordelijkheid in hebben als leverancier, dus ik hoop dat je het dan iets professioneler brengt dan het is allemaal "geleuter", "prijs omhoog" als ze het ergens anders willen en "in bochten wringen om nog iets te kunnen doen". Want het zijn gewoon wettelijke eisen, daar kan je het mee eens zijn of niet, maar de boetes die er staan als je het niet goed doet, die zijn niet mis.

En ik hoop dat je ook wel doorhebt dat data die je in Office365 zet of die je bij Google in typt, in principe geen persoonlijke informatie zou mogen zijn, en daardoor waarschijnlijk van heel andere aard is dan de data die door jouw systemen gaat. Dat als ik zelf iets op Facebook zet, het heel anders is dan als diezelfde data toevallig in jouw systeem staat en zo bij een derde partij komt waar ik niet voor gekozen heb.
Er is geen enkele wet die zegt waar mijn data moet staan, alleen dat het veilig moet gebeuren en dat de data in de EU moet staan. En op Google cloud staat dat de data nergens de EU verlaat als je bepaalde data centers kiest, zoals hetgene in St Gishlain in België. https://support.google.com/googlecloud/answer/6056694?hl=en

Voor Azure was dit vroeger alleen het datacenter in Frankfurt, hoe dat nu zit weet ik niet. Aws heb ik nooit bekeken.

Er bestaat er ook nog zoiets als contracen en verwerkingsovereenkomsten. Al mijn klanten weten van welke diensten mijn bedrijf gebruikt maakt, staat zo in hun contract. Aan hun de keuze. En als ze willen kunnen ze het zelf lokaal draaien en hosten of zet ik het ergens anders. Maar dan gaat de rekening wel naar omhoog en van het moment dat er een besparing kan zijn , dan maakt het voor velen niet meer uit. Weet je hoeveel keer ik de vraag al gehad hebt, waar staan de gegevens... het ronde getal van 0 keer. Wel eenmaal ooit eentje die een privé server wou. Tot de prijs naar boven kwam ... Dan was het niet meer nodig.

En jij weet van alles wat je gebruikt waar die data staat ? En jij shopt ook nooit bij Amazon ?. Ik,gebruik zelf geen Office365 maar het bedrijfsleven wel. En dat kan wel allemaal. En velen weten nog niet eens wat gdpr is, zeker niet van die kleine bedrijven zoals bijvoorbeeld in de bouw, transportsector etc. En dan is er nog het volgende feit .. volgens de Belgische wetgeving als ik van iets een factuur maak, moeten die gegevens 10 jaar bewaart blijven, een architect moet 25 jaar na datum nog het plan kunnen voorleggen van je huis of verbouwing, een elektricien moet 20 jaar schema’s bijhouden... dus zelfs schrappen is niet mogelijk moest je dit vragen. Want het mag niet van de wetgeving. En het standaard zinnetje als iemand iets niet weet of snapt ... is dit wel ok voor de gdpr ben ik ondertussen wel beu. Omdat het voor vanalles en nog wat gebruikt wordt. Je moet je data niet te grabbel gooien, als iemand vraagt om zijn gegevens te wissen dan doe je dat, en je gebruikt de data niet voor commerciële doeleinden (tenzij dat je business is en dan moet dit volledig anoniem). Vele kleinere bedrijven hebben geen idee als ze gehacked zijn, zelfs grotere weten het meestal zelfs nog niet. Niet elk bedrijf heeft een it dienst van 20 man die niks anders te doen heeft dan zich met gdpr bezig te houden. Voor kleinere bedrijven deze maken misschien gebruik van een it provider, maar dit is het minimum, omdat dat geld kost. En de heel kleine bedrijven die kopen een laptop bij Coolblue of bol. Die doen geen beroep op een it provider.

Binnen it bedrijven is dit helemaal anders, maar het merendeel van de bedrijven heeft NIKS met it te maken en deze zijn nog dikwijls niet op de hoogte van wetgevingen omtrent dat. Vraag aan 5 bakkers, 5 eigenaars van een broodjeszaak, 5 klusjesmannen, 5 schilders wat gdpr is. Als je bij elke groep er 2 zult hebben die kunnen antwoorden of er al van gehoord hebben, zal het veel zijn. Dit zijn ook bedrijven, en als die gebruik maken van een dienst dan is het enige waar ze naar kijken, doet dit wat ik wil en wat is de prijs. Zo werkt het echte leven en bedrijven die non it gerelateerd zijn

[Reactie gewijzigd door cricque op 4 oktober 2020 13:57]

Anoniem: 715452
@cricque3 oktober 2020 12:06
Azure west europe is het datacentrum in noord-holland.
Wat jij wil. Maar als ik een leverancier in de hand wil nemen is 1 van de vragen waar de data staan.

Als ze dan met een Amerikaanse oplossing komen ben ik snel klaar.
Dus jij gebruikt geen Office365, Google om te zoeken of Windows ? Want dat is voor mij net hetzelfde. Beetje hypocriet om te zeggen dat data in EU moet staan en mag geen Amerikaanse partij zijn, maar je gaat dan wel software gebruiken die ook uit de US komt.

Het kan best zijn dat je deze niet gebruikt uiteraard, maar zakelijk gezien is de kans zeer, zeer klein
Ok dan ben jij een van de weinigen. Ik gebruik ook geen office 365 voor eigen zaak (windows alleen om te testen/gamen, rest linux), maar waar ik regelmatig consultancy lever is dit allemaal wel het geval (meerdere bedrijven). En dit is zo in het merendeel van de bedrijven. Als er veel "geneut" word over gdpr dan breng ik dit altijd te sprake. En dan is het direct stil. Als je kijkt naar hoeveel mensen hier in de EU gewoon Google gebruiken om iets te zoeken (meer dan 93%) tsja zegt genoeg zeker. Ik ken gerust Bing, Duckduckgo, Yandex. Bing hebben sommige al van gehoord, maar de andere 2 is Chinees. En dan is er nog android, daar zijn bitterweinig alternatieven voor (buiten Apple uiteraard). Dus hoe je het draait of keer, je zal altijd met 3de partijen zitten. En dikwijls uit de US. Ik zou ook best wel een librephone willen, maar dan kan ik een deel van de apps niet gebruiken (zeker bank gerelateerd). Dus dan moet ik alsnog een 2de toestel (en meerdere) om te testen. Sommige mensen kunnen daar allemaal tijd in steken, ik heb daar het geduld niet voor. Als je 2 kleine kinderen hebt, meer dan 60u/week werkt (eigen keuze uiteraard), dan ga je de dingen niet moeilijker maken dan ze zijn. Je moet niet heiliger zijn da de paus zelf. Het merendeel is ook tegen het gebruik van jquery, maar zelfs sites van Google, Microsoft gebruiken nog altijd jquery.
Bijna helemaal met je eens.

Ik heb er voor gekozen om zo min mogelijk te doen met Amerikaans omdat ik ze niet vertrouw. In mijn geval met reden, ze hebben bij de douane daar gepoogd data te kopiëren.

Ik heb ook geen mobieltje meer. De laatste die ik had draaide op Lineage, maar ook daar ben ik mee klaar.

Ik zou ook voorstander zijn van een betaalde zoekmachine, net als dat ik Protonmail heb. Maar iedereen wil gratis, dus ik ben bang dat een betaalde optie niet uit de verf zal komen.
Heb je +1 gegeven. De vraag die ik met vaak stel bij privacy-activisme, is of het in de eerste plaats om de privacy, dan wel om het activisme gaat. Men richt zich bijna uitsluitend op de infrastructuuraanbieders die voor de eindgebruiker niet als zodanig herkenbaar zijn, en waar die niet van afhankelijk is voor de dagelijkse routines, omdat men weet dat als men zich succesvol tegen Facebook, Google et tutti quanti zou richten en die diensten er in de EEA effectief mee zouden moeten ophouden, of minder frictieloos zouden kunnen werken, men de impliciete steun/tolerantie van de medeburger kwijt is. En dan is het gedaan met het activististische geLARP. Als je denkt dat de Facebook-boomers boos zijn om "5G", de "plandemie" en "satanistische pedofielen in Hollywood", dan heb je ze nog niet gezien als ze geen foto's van hun kleinkinderen kunnen zien op Facebook of knullig-racistische memes kunnen posten en liken.
Yups, maar we gaan rustig office 365 gebruiken, MS Windows en zoeken doen we altijd via Google. Maar owee als er wat data komt te staan in een data center in België bijvoorbeeld dat van Google is of Azure in Frankfurt ... Dat kan dan niet. Uiteraard hoeft niemand deze diensten te gebruiken, maar zakelijk is dat nu net wat bijna iedereen gebruikt. Dus vraag ik mij toch altijd af, waar zijn we eigenlijk mee bezig.
Dan is er ook nog het feit dat de meeste grote, niet zomaar toegang geven tot gegevens. Het maakt niet uit wie het vraagt. En velen zetten wel alles op smoelboek, instagram, twitter, tiktok, youtube, maar owee als een applicatie die je gebruikt gehost is op 1 van de grote 3 ... Dat is dan heiligschennis.

En ik hanteer het principe, wil je niet dat het bij Google staat, zoek dan iemand anders, of ik zet het voor jou wel ergens anders tegen een meerprijsje. Dan kan het allemaal wel vlug bij Google, want als KMO kunnen we wat sparen. En Ik wil best wat lokaler zetten, maar ik moet hetzelfde gemak hebben als ik nu heb. En tot op heden is er niks dat in aanmerking (en dan heb ik het nog niet over prijs) die mij dit alles kan aanbieden op 1 platform. Dusja dan is er zelfs geen keuze.
Europa zou beter eigen AWS initiatieven ondersteunen. Ik vertrouw Amazon voor geen meter...
Ik denk dat je de winkel, de logistiek en de webservices door elkaar haalt. Ja, ze delen en naam, maar dat is dan ook wel waar de samenhang eindigt.

Je zou kunnen stellen dat 'Amerika' niet te vertrouwen is (zij het qua politiek of normen en waarden), maar de technologie van de grote spelers is ordegroottes verder dan wat we hier neer kunnen zetten.

Er is gewoon geen Europese versie en daar is ook geen markt voor. Voor 'de rest' van de wereld zijn wij 'net zo erg' als Amerika, en voor de interne markt kunnen we op prijs en functionaliteit niet concurreren.
En het stomme is dus dat juist dankzij GDPR en aanverwanten er hier juist een enorme markt is voor een stevige cloud provider.

Als je kijkt naar de worldmap van Bijvoorbeeld azure locations dan is de presence in EU enorm. Veel meer locaties dan de VS en Azië.

Heel Afrika heeft er volgens mij twee.

Eu is een enorm afzet gebied en tevens ook de lastigste qua regelgeving en startklimaat.

Het is overigens wel zo dat heel veel bedrijven stiekem hun eigen private cloud hebben gebouwd die vrijwel identiek weekt als een G cloud. Zo heeft de overheid er meerdere in gebruik via belastingdienst en kadaster, maar kiezen zij nu weer voor de public cloud in de vorm van Azure. Als Nederland zou willen is er kennis genoeg om hier een eigen public cloud neer te zetten.
Nouja, ze werken vooral in de vorm van basic networking en virtuele machines vergelijkbaar, maar daar houdt het wel op. Qua FaaS is er meestal niks of weinig en de 100+ andere turnkey services zijn compleet afwezig.

Dat er een grote markt is klopt idd wel, ik ben er het ook wel mee eens dat het gewoon belabberd is dat er nu niet iemand opstaat en zegt: wij bouwen het.

Alles wat er tot zo ver is (ook de half-werk private clouds), is gewoon commerciële verkrijgbare software, soms op FOSS gebaseerd maar dan re-packaged in bijv. een RedHat (IBM) of Canonical supported versie.

Tenzij er als groot EU-bedrijf met goede internationale ondersteuning (binnen de EU desnoods) iemand zelf investeert en zelf bouwt maakt het niet uit wat we allemaal willen doen. Dan komt er gewoon geen EU-oplossing.

Ironisch genoeg zijn de grote spelers van nu vooral ontstaan door dat ze interne diensten zijn gaan ontsluiten aan het publiek. Ze hebben dus niet eens gedacht: hoe starten we een commercieel haalbare cloud. Maar ze hebben iets ontwikkeld wat intern praktisch was (object storage, VM-self serve, database-as-a-service bijv.) en dat uiteindelijk kunnen slijten aan de rest van de wereld. Dat is ook waarom andere systemen die public-first gebouwd zijn gewoon niet net zo goed en net zo groot geworden zijn.

De enige projecten die het geprobeerd hebben (maar eigenlijk dood zijn voor het arriveren) zijn van die verzamelbedrijfjes geworden die onder een merknaam van hardware die ze al hadden liggen meer diensten proberen te slijten. Dat is dus verkeerd om en dat merk je gewoon als je dat spul gebruikt. Het is niet praktisch, kwalitatief teleurstellend en aan de voorkant niet van dezelfde kwaliteit als aan de achterkant (en dat werkt twee kanten op: soms krijg je een brakke externe API om mee te werken ( -- de hele dag knopjes klikken in een UI is net zo nutteloos als zelf nog fysieke servers in een rack schroeven) en blijken ze op de achtergrond een goede API te hebben maar alleen voor intern gebruik en geen tenant-scheiding. Of ze hebben een goede API aan de voorkant, maar blijken aan de achterkant gewoon overal bij te kunnen om maar wat te noemen. Of iets wat aan de API kant geautomatiseerd moet lijken te zijn, maar op de achtergrond blijkt dat er iemand een service ticket krijgt en met de hand wat loopt te doen.

Het is gewoon om moedeloos van te worden. We weten wat we willen, wat we nodig hebben, en het zou ook moeten kunnen (commercieel gezien). Maar het enige wat we krijgen is de zoveelste repackaged whitelabel frontend voor een ding dat alleen VMs kan 'beheren'.

[Reactie gewijzigd door johnkeates op 2 oktober 2020 22:50]

Anoniem: 30722
2 oktober 2020 18:44
Jarenlange Microsoft overvloed op school, Chromebooks en Android tablets zijn er standaard. Maar AWS, owee!
Ik vind vooral dit stukje grappig:

"Er moeten minstens twee providers worden ingeschakeld. AWS kan failliet gaan."

Twee verschillende platformen onderhouden voegt veel complexiteit toe, dat risico alleen al lijkt me groter.

Daarnaast denk ik dat een cloud provider Databases veel beter kunnen beveiliging dan een onderwijsinstelling. Dus de data veiligheid zal hoogstwaarschijnlijk alleen maar toenemen.

Raar verhaal dit :-)

[Reactie gewijzigd door Jay-v op 2 oktober 2020 19:06]

De argumentatie is inderdaad vreemd, al was het maar omdat Amazon de nodige positieve cijfers kan voorleggen, maar de noodzakelijkheid van 2 providers (of hybride) hoor je wel vaker om vendor lock-in te voorkomen.

Dat is ook de reden waarom je o.a. in Azure kan verbinden met andere cloud providers zoals AWS.
Ze hebben het ook over het ontbreken van een exit strategie. Als je dat goed voor elkaar hebt dan is de eis om 2 platformen te gebruiken wellicht overkill.
Echter moet je ook niet vergeten dat alle grote cloud aanbieders wel eens een outage hadden met zeer grote gevolgen. Als je dan volledig afhankelijk ben van die cloud zit je hele toko per direct duimen te draaien.
Ik ben misschien wat ouderwets, maar zou toch minimaal voor een hybride oplossing kiezen waar je data ook op eigen ijzer hebt draaien.
Te vaak, en zeker in het onderwijs, is de ict kennis wegbezuinigd. Er loopt een docent wiskunde die de pet ict coordinator er maar even bij heeft gekregen en het maar moet uitvechten met externe dienstverleners.
Probleem is dan alleen dat aansluitende partijen dan ook twee providers moeten gebruiken anders kan bij uitval van de ene helft alsno een hoop dienstverlening uit vallen.

Hybrids met twee providers kosten enorm veel geld. Het is echt alleen interessant als je SLA technisch gewoon moet. Daar zit dan ook een prijskaartje aan richting de klant. Het is niet alleen alles dubbel uitvoeren bijvoorbeeld, maar ook extra kosten doordat je het op het ene platform zo moet doen en op het andere platform zus.
Ik voel toch ook meer voor het standpunt van michielRB. En als we dan naar een iets vroeger tijdperk keken bij on premise hosting dan was een hybride oplossing met 2 providers over 2 locaties en een full redundante oplossing gewoon heel normaal. Mirroren over 2 datacenters met eigen infrastructuur, altijd een duidelijke en makkelijke exit strategie.

Het feit dat hybride nu belachelijk veel duurder is, maakt het nog eens duidelijk dat de cloud gewoon veel meer kost, tenzij je bespaart op dingen zoals exit strategie en cloud onafhankelijkheid...
Het feit dat hybride nu belachelijk veel duurder is, maakt het nog eens duidelijk dat de cloud gewoon veel meer kost,
Nee hoo. Nu maak je de berekening verkeerd om. De reden dat het vroeger met on premise spul kon was dat je werkelijkwaar niks vendor specifiek had.

Met cloud native zijn een hoop dingen specifiek geoptimaliseerd om zo veel mogelijk performance uit zo weinig mogelijk hardware te krijgen en daardoor soms ook veel goedkoper dan wat je on premise kwijt zou zijn. In hybride opstellingen moet je dat dus ook doen voor de andere provider (die het weer iets anders heeft), of je moet het zelf draaien in K8s en dat is dan weer duurder en vereist meer onderhoud (omdat zelf doen). Dat is de reden dat je dan ineens met meer dan 2X de kosten zit.
Mirroren over 2 datacenters met eigen infrastructuur,
Ja dat heet availability en wordt in vrijwel iedere cloud omgeving ondersteund over meerdere datacenters op verschillende niveaus. Lokaal, regionaal, zonaal en vaak globaal.

Ideaal icm autoloadbalancing op DB’s bijvoorbeeld. Een Postgres instance op AWS RDS heeft bijvoorbeeld autofailover en read loadbalancing. Heb je twee of meerdere instances die je altijd kunt gebruiken voor reads (en dus in principe 2+x performance) en auto failover binnen je regio. Valt er een datacenter weg heb je dus redundante data op een andere locatie waarmee je gewoon verder kunt. Je zult een kleine performance hit kunnen verwachten maar that’s it.
Ik ben waarschijnlijk al wat ouder dan jij, want deze evolutie heb ik vroeger al gezien. We hadden mainframes, die waren mega duur en de vendor bepaalde wat je er mee kon. Daarvan hebben we ons stilaan losgewrikt en zeker met Linux kwamen er open standaarden. De vendors konden niet meer bepalen wat je betaalde, je kon makkelijk overschakelen en je was redelijk vrij.

De huidige evolutie gaat terug richting mainframe : de vendor bepaalt en als die zegt, nu betaal je opeens 20% meer dan kan je alleen "ja meneer" zeggen. Wijzigingen die niet in jouw kraam passen, zijn ook geen vrije keuze meer.

Vendor lock-in is iets wat je allen tijde moet vermijden. Zoals een monopolie. Het feit dat je vendor specifiek geweldig vindt, doet me denken dat je nog vrij jong bent, verontschuldig mij als ik verkeerd ben.

Daarom wil je ook absoluut dat je cloud provider onafhankelijk bent : 2 cloud providers, zodat als de ene je financieel onder druk zet, of iets doet wat je niet leuk vindt, makkelijk kan overschakelen naar de andere (zoals 2 *eigen* datacenters). Autofailover en loadbalancing hadden we vroeger al. Met enkel AWS ben je afhankelijk van 1 cloud provider en dat is echt iets niet wat je wil. Ik heb daarom niets tegen de cloud, maar ik wil geen afbreuk maken van wat ik vroeger had : onafhankelijkheid. Dat doet bijna niemand (iedereen blijft in dezelfde cloud), en dan is het al duurder, maar met 2 aparte cloud providers kost het inderdaad *nog* een pak meer.

Qua kosten dacht ik inderdaad dat we naar 2x de prijs zouden gaan, maar ik heb al omgevingen gezien waar ze naar 5x de prijs gaan. Sommige moesten overschakelen omdat de baas zich heeft laten overtuigen door een of andere verkoper in maatpak, nadat de kosten zo hard opliepen werd de baas buitengegooid en vervangen en moest er een migratie terug naar on-premise (wel, naar hosted datacenters met eigen infrastructuur) gebeuren.

Vorig jaar was ik op Fosdem, misschien moet je deze talk eens zien : https://archive.fosdem.org/2019/schedule/event/cloud_is_another_sun/
Ik ben met je eens dat vendor lock-in eigenlijk weer een stap terug is. Echter ben ik niet met je eens dat we weer terug gaan naar mainframe achtig tijdperk. Cloud native heeft nog steeds een mate van onafhankelijkheid en daar zijn prima strategieën voor te bedenken. Cloud is daarnaast vrijwel altijd goedkoper dan on-premise. Ik heb factor 10 prijzen gezien. Het voordeel bij cloud is met name heel groot als je services hebt die nationaal georiënteerd zijn en dus ook niet 24/7 eenzelfde load kennen. Dankzij “pay as you go” kun je daarmee al gauw je kosten halveren, maar wel de 2x de performance bieden op piekmomenten. Want dynamic scaling. En ja auto failover en loadbalancing is niet nieuw, maar het feit dat het met 1 klik op de knop geconfigureerd is, is ook wat waard.
De huidige evolutie gaat terug richting mainframe : de vendor bepaalt en als die zegt, nu betaal je opeens 20% meer dan kan je alleen "ja meneer"
Nee ben ik niet met je eens. Dit kun je misschien een paar weken of maanden volhouden, maar dan migreert iedereen weg. Als jij je cloud infra goed op orde hebt (infra as code) kun je de hele zwik met wat kleine aanpassingen binnen no time migreren naar een andere provider. Dat vereist wel kleine services en dergelijke, maar als je dat hebt maakt het echt geen drol uit hoe je dat hebt draaien. Iets als AWS lambda klinkt eng, maar kun je natuurlijk zo omzetten naar een docker container.

Ik denk dat als je die vendor lockin goed aanpakt dat een migratie helemaal niet zo veel zou moeten kosten, complex moeten zijn. Ik ben nu zelf bezig met een migratie van GKE naar AWS en een IaaS naar AWS. De rotzooi die je on-premise krijgt (die vaak niet aan standaarden voldoet) is echt de extra kosten niet waard. Zelfs als je ieder jaar een migratie zou doen durf ik te wedden dat je in veel gevallen nog steeds goedkoper uit bent dan on premise. Daarbij betaal je namelijk ook altijd voor de hardware die je niet gebruikt, maar wel mogelijk op korte tot middellange termijn nodig hebt.

Het ligt dan ook echt aan het gebruik van de services en hoe de operational costs in verhouding staan met je development costs en het gebruik van de services. Als dat binnen nederland is (en dus niet 24/7 dezelfde load) dan is het heel handig om pay as you go te hebben. ‘S nachts niks doen kost je dan ook daadwerkelijk niks.

Een goede exit strategie is daarom ontzettend belangrijk in dit soort scenario’s.
Als je cloud omgeving goedkoper is dan on premise, dan zijn het waarschijnlijk zeer kleine bedrijfjes die niet het budget hebben om een eigen infrastructuur te kopen. Als tante Maria email nodig heeft, is het inderdaad onzinnig om een exchange server aan te kopen of een eigen virtuele infrastructuur en dan is het natuurlijk een no-brainer om een dienst aan te kopen.

Maar als je een groter bedrijf bent, dan kan je hier heel goed in optimaliseren zodat je servers ideaal belast worden. En dan is het echt *belachelijk* veel goedkoper. Ik host zelf op eigen infra voor enkele klanten, en dan zit ik ongeveer een 5x goedkoper dan AWS/Azure, met een echt hele mooie marge. En we spreken over full ssd / fully redundant. Het is niet voor niets dat Amazon of Microsoft iedereen de cloud door hun strot rammen en bijna geen keus meer geven. Dat is niet omdat het beter of makkelijker is, maar omdat ze een lock-in kunnen creeeren en hun winst enorm kunnen optrekken. Dat zie je ook aan de cijfers van de bedrijven sinds ze met cloud computing zijn begonnen.

's nachts servers afzetten ? Een leuk verkooppraatje waar velen intrappen, maar kijk eens in de praktijk? 's nachts draait onze webserver niet. Synchronisaties, nee, die doen we niet meer. Backups, unloads of manipulaties daar op niet meer nodig. Nee, in de praktijk werken servers 's nachts vaak meer dan overdag als je de load bekijkt. Eventueel kan je wat development afzetten, maar dat is vaak ook niet het geval omdat developers vaak 's nachts grote of zware testverwerkingen laten lopen. In de cloud projecten die ik heb gezien, wordt er nauwelijks iets afgezet omdat het niet kan. Er wordt wel over gediscussieerd, want dat was de bedoeling, en zo was het kosten-matig besproken, maar in de praktijk kan het niet.

Het kan wel interessanter zijn als je bv je zegt echt, zoals bol.com piekmomenten hebt zoals met nieuwjaar of kerst. Met zo'n bedrijven ben ik zelf echter nog niet in contact gekomen, dit lijken me eerder uitzonderingen als ik rond mij kijk, maar ik vraag me af met de marges die je hebt bij een eigen infra t.o.v cloud, of je dat er zelfs niet uithaalt.
Echter moet je ook niet vergeten dat alle grote cloud aanbieders wel eens een outage hadden met zeer grote gevolgen. Als je dan volledig afhankelijk ben van die cloud zit je hele toko per direct duimen te draaien.
Het probleem bij dat soort argumenten is dat je met je resilience tot het oneindige kan gaan en vaak onterecht. Je hebt bij cloud providers vaak meerdere vormen van redundantie ter beschikking die vaak verder gaan dan on-premise oplossingen, uiteraard tegen de nodige meerkost, maar dat is ook het geval voor een on-premise oplossing.

Daarnaast zou het niet de eerste keer zijn dat een on-premise resilience strategie zich beperkt tot het restoren van een backup en is redundantie beperkt tot switches en n+1 hypervisor hosts.

Ik bedoel maar, je kan een server volledig op redundante HW laten draaien (hosts, netwerk, storage) in een geclusterde omgeving met asynchrone replicatie naar een ander standby locatie met dezelfde HW. Vervolgens neem je van die omgeving elke 10 minuten een incrementele backup die word weggeschreven naar een een gescheiden redundante storage die enkel bereikbaar is met een API en waar HW aan gekoppeld is om geautomatiseerde DR test te doen. Die backups worden ook nog eens 2 dagelijks naar tape geschreven om vervolgens door een externe firma off-site te worden gebracht. ... we kunnen een tijdje doorgaan.

[Reactie gewijzigd door IStealYourGun op 3 oktober 2020 01:18]

Ik vind wel dat je backups niet bij dezelfde provider kunnen staan. Ofwel intern, ofwel extern, maar als Amazon of Microsoft plat gaat (wat al eens gebeurd is), dan moet je toch wel een restore kunnen runnen.
Dat hoeft niet een issue te zijn, je kan perfect backupen naar een andere provider of zelfs lokaal. Nadeel in het geval van Azure is dat al je uitgaand verkeer buiten de regio, niet gratis is. Anderzijds, offsite backup is nooit gratis.

[Reactie gewijzigd door IStealYourGun op 3 oktober 2020 11:43]

Dan moet je zorgen dat je vms hebt draaien en je programmatie niet bv met Amazon lamdas werkt (waarvoor je initieel naar de cloud wilde). Die dingen heb je dan misschien wel gebackupped maar je krijgt ze niet online in een andere cloud.
Wat zou dat voor zin hebben?
Maar gaat een cloud provider zich bezig houden met databasebeveiliging van databases van klanten? Want hoe weet de cloud provider welke tabellen ik nodig heb in mijn database? Wat als er iets fout gaat met de data, hoe weten ze dan hoe het te corrigeren? Nee, dat is gewoon de verantwoordelijkheid van de klant.

Hooguit dat op hoger niveau er betere beveiliging is, maar zeker voor grotere organisaties voegt dat weinig toe omdat die vaak zelf ook de expertise in huis hebben.
Maar gaat een cloud provider zich bezig houden met databasebeveiliging van databases van klanten?
In zekere zin wel ja. Ze zorgen sowieso voor de beveilinging van het datacenter, de infra, dat het OS gepatched is, dat de DB engine gepatched is. Dat is al een groot stuk van de beveiliging. Daarnaast kan je met een druk op de knop (of een veld op true zetten) je DB encrypten etc.

Tuurlijk je moet de DB User / Password en de firewall rules nog steeds zelf regelen, maar het overgrote deel is dus al goed beveiligd.
Dikke kans dat jij wel fysiek in een straal van een paar meter van de fysieke locatie van een database kan komen, tenzij die bij Google, AWS of Microsoft staat. Het is echt een wereld van verschil qua beveiliging en kwaliteit. Het zijn niet voor niets grote spelers.
Dit is echt stelletje regelgeving van mensen die denken dat ze er iets va snappen. Wow :/
Het gaat om ALLE niet Europese oplossingen. Ze zijn allemaal link om te gebruiken door Amerikaanse wetgeving
Dat zijn 'Europese' net zo goed, want de software komt gewoon uit Amerika. Ja, in theorie is er een wettelijk verschil, maar theorie en praktijk lopen nogal uit elkaar.

Stel dat de fysieke locatie belangrijk is, dan kan je ook fysiek de systemen op lokatie hebben. Bijv een AWS Outpost. Of dat ding van Microsoft (naam vergeten). Dan heb je storage, compute, netwerk enz. gewoon on-site, maar wel met alle functionaliteit waar je praktisch gebruik van wil maken.

[Reactie gewijzigd door johnkeates op 2 oktober 2020 21:38]

Ik ben ook niet kapot van Microsoft als het gaat om privacy (zoals het verzamelen van telemetrische gegevens in Windows), maar ik denk minder in Amazon.
Amazon heeft een naam ten opzichte van het behandelen van zijn personeel. Als het al de arbeidsomstandigheden niet respecteert, denk ik ook dat ze veel proberen om geld te verdienen met gegevens, net zoals Facebook.

[Reactie gewijzigd door Nas T op 2 oktober 2020 18:57]

Ook Amazon verzamelt telemetrie hoor, dat kan ik in mijn netwerk mooi zien aan het verkeer dat de fire tv stick genereert :+
Yup, al die tech reuzen vormen een groot gevaar. We moeten toch ergens beginnen met handhaven :).
Zijn er niet terms waar Amazon zich aan moet houden tov afnemers qua data? Ik zie geen directe reden tot zorg als leek.
Ja... de CLOUD Act bijvoorbeeld:
https://en.wikipedia.org/wiki/CLOUD_Act

Lang verhaal kort: Als de VS Overheid eist dat een Amerikaans bedrijf gegevens overhandigd van een Europees data centrum, dan moet het bedrijf vanuit de VS akkoord gaan.
Kan de EU ook doen hoor, en daarmee dat ze de informatie van Europeanen in de EU willen houden, omdat ze dan de gegevens via bevel of wet kunnen verkrijgen.

De vraag is waarom de overheid zoveel informatie wilt centraal bijhouden. Vroeger deed elke school dit ook apart, als er een brand of een inbraak was, was dat de verantwoordelijkheid van de school maar dat was gelimiteerd tot een enkele school, niet het hele land.
Dat gaat ook op voor software die je als bedrijf levert en als die software dan telemetrie en automatische updates heeft kan je als Amerikaans bedrijf nog steeds verplicht worden data te exfiltreren, ook zonder de klant te berichten. En dat gaat zelfs zonder FISA court.
Amerikaans bedrijf... Iets met wetten van de overheid daar die allerlei data zal kunnen nog willen opeisen. Buiten de vraag wat Amazon zelf mogelijk kan doen met deze data.
Weet ik niet, ik weet ook niet of de kwestie is "gebeurt het over de grens"? Wat ik daarmee bedoel is dat als een onderwijs de keuze maakt data bij Amazon te stallen, op een buitenlandse server, welk recht van toepassing is. Is het Europese/Belgische recht alleen van toepassing op de onderwijsinstelling of ook Amazon? Als het alleen op de onderwijsinstelling is, dan kun je misschien weer in een discussie terechtkomen dat de onderwijsinstellingen andere plichten t.o.v. data kent dan bedrijven en zodoende bepaalde plichten ontlopen kunnen worden. Maar ik ben geen jurist en misschien denk ik daar te moeilijk over.
Nochtans heeft Google Cloud een data center in België, waarom wordt die dan niet genoemd? Heeft het iets met het feit dat de grootste cloud providers Amerikaanse bedrijven zijn?

[Reactie gewijzigd door SlasZ op 2 oktober 2020 21:17]

Wat een apart verhaal.... er is namelijk prima aan te tonen dat dit onderzoek uitgevoerd is door iemand die niet verder gekeken heeft dan zijn neus lang is.

1- De data van AWS kan prima binnen de EU gewaardborgd worden zodat het volledig conform GDRP is. Wanneer er data buiten de EU gestuurd wordt komt met in aanraking met het onlangs belachelijke wet welke voortkomt uit Schrems 2. Ook dit is geborgd door AWS. https://aws.amazon.com/compliance/eu-us-privacy-shield-faq/

2- Encryptie is in beheer van AWS. Sorry toen ik dit las moest ik lachen en verwerpen ze direct het complete onderzoek. De encryptie is namelijk een keuze van de gebruiker. Je kiest of, de encryptie van AWS of je kan er voor kiezen om je eigen encryptie keys te gebruiken zoder er helemaal niks bij AWS bekend is of gedecrypt kan worden. Daarbij zijn de encryptie keys van AWS account specifiek en ook nog region bound dus niet te gebruiken buiten de EU. Nu zijn er wel manieren om die data te exporteren dus de veiligste methodiek is eigen keys te gebruiken.

[Reactie gewijzigd door cork87 op 3 oktober 2020 09:16]

Uit de product portfolio van die g-cloud van jullie (onze zuiderburen), blijkt eigenlijk alleen maar dat wij het goed hebben hier in Nederland.

“SharePoint as a service” tussen 7:30 en 17:30 maar 99,9 uptime en 99% van de requests sneller dan 4 seconden.
4 seconden is echt heel langzaam voor een website. Wie wil überhaupt zelf nog SharePoint hosten? Dat gebruikt iedereen toch in de cloud?

Ook best gek dat er een vergelijking tussen een echte cloud provider met cloud diensten en een vps-boer wordt gemaakt. Dat lijkt een vergelijking tussen aardbeien en aardappels, het is niet eens beide een fruit.
Ik heb niet superveel ervaring met AWS (ben Azure persoon), maar in Azure kun je op alle SQL varianten TDE (transparant data encryption) aanzetten. Ik zie dat dit ook beschikbaar is voor AWS RDS: https://docs.aws.amazon.c...QLServer.Options.TDE.html

Kortom wat is precies het probleem? Daarnaast waar komt altijd het idee vandaan dat privacy alleen gegarandeerd is op eigen grondgebied? Het merendeel van de privacy lekken vind echt niet plaats omdat er een cloud partij in data gaat zitten te snuffelen.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee