Webhost stuurt databank backup door via WeTransfer

[mrsardonian]

Beste Tweakers,

Enkele weken geleden vroeg ik mijn webhost om een backup door te sturen van mijn productiedatabank.
Tot mijn grote verbazing kreeg ik deze onversleuteld aangeleverd via een WeTransfer link (de file was onversleuteld, de wetransfer link werd verstuurd zonder wachtwoord).

Zelf was ik hier uiteraard niet zo blij mee, omdat we als bedrijf net dit soort diensten vermijden en op elk moment onze data versleutelen tot op usb sticks toe.
Mijn webhost blijft beweren dat er niets mis is met deze praktijk omdat WeTransfer een Europees bedrijf is met eveneens privacyregels. Omdat de WeTransfer link via een beveiligde ssl mail is verstuurd naar mij kan er bovendien geen sprake zijn over een datalek.

Ik ben zelf geen specialist in privacywetgeving, maar vind dit toch op zen minst vreemd.
Is dit een datalek volgens jullie? En is het normaal dat medewerkers van een hostingbedrijf toegang hebben tot WeTransfer? Is er iets dat ik verder best kan of moet doen? Of iemand die al iets gelijkaardigs heeft meegemaakt?

Alvast bedankt voor jullie respons.

[HKLM_]

Welke voorwaarden heb je aan je leverancier gesteld bij het opvragen van de data?

Heb je bijvoorbeeld van tevoren opgevraagd hoe ze dergelijke data versturen?

Als ik zo iets zou moeten krijgen van een leverancier zou ik, voordat er verstuurd gaat worden afspraken maken over hoe het verstuurd gaat worden. En niet handjes in de lucht en kijken hoe de leverancier het aanlevert. Wat schijnbaar niet compliance is met jullie security / privacy beleid. Maar wel die van de hoster vandaar de afspraken

[ Voor 54% gewijzigd door HKLM_ op 08-08-2022 21:10 ]

[mrsardonian]

HKLM_ schreef op maandag 8 augustus 2022 @ 21:08:
Welke voorwaarden heb je aan je leverancier gesteld bij het opvragen van de data?

Heb je bijvoorbeeld van tevoren opgevraagd hoe ze dergelijke data versturen?

Ik heb geen specifieke voorwaarden gesteld. Het leek mij nogal evident dat een webhosting bedrijf, eigen data niet elders zou droppen. In hun backend is er een tool om zelf backups te nemen. De file komt dan beschikbaar in de root van het hostingpakket (niet in de public_html), maar dit is jammer genoeg enkel voor MySQL in dit geval ging het om een MSSQL.

[HKLM_]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:11:
[...]

Ik heb geen specifieke voorwaarden gesteld. Het leek mij nogal evident dat een webhosting bedrijf, eigen data niet elders zou droppen. In hun backend is er een tool om zelf backups te nemen. De file komt dan beschikbaar in de root van het hostingpakket (niet in de public_html), maar dit is jammer genoeg enkel voor MySQL in dit geval ging het om een MSSQL.

Aannames

[De_Bastaard]

Lijkt me geen datalek nee. Als je dit allemaal niet wilt moet je, ook als bedrijf, van te voren goed uitzoeken hoe leveranciers met ie data omgaan.

Aannames….

[mrsardonian]

HKLM_ schreef op maandag 8 augustus 2022 @ 21:12:
[...]


Aannames

Gaat mij absoluut niet meer overkomen. Maar er lijkt mij nooit een geldige reden te zijn om een productiedatabank onversleuteld door te sturen, al zeker niet via WeTransfer.

Bedankt voor je respons overigens :-)

[HKLM_]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:17:
[...]


Gaat mij absoluut niet meer overkomen. Maar er lijkt mij nooit een geldige reden te zijn om een productiedatabank onversleuteld door te sturen, al zeker niet via WeTransfer.

Bedankt voor je respons overigens :-)

Ik deel je mening wel hoor, ieder bedrijf die data verstuurd zou dit secure en privacy technisch goed moeten doen. Je kan natuurlijk altijd terugkomen op je vraag en aangeven waarom ze data niet encrypten en of ze dit voortaan wel willen doen.

[mrsardonian]

De_Bastaard schreef op maandag 8 augustus 2022 @ 21:16:
Lijkt me geen datalek nee. Als je dit allemaal niet wilt moet je, ook als bedrijf, van te voren goed uitzoeken hoe leveranciers met ie data omgaan.

Aannames….

Maar blijft toch het feit dat data gedeeld werd met een derde partij? Waar in hun eigen privacy policy bovendien vermeld staat dat ze dit nooit doen zonder toestemming?

[Duskwither]

Beheerders van je webhost die in jouw onversleutelde database kunnen kijken lijkt me op zich al een datalek, laat staan het delen ervan op wetransfer

[HKLM_]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:19:
[...]


Maar blijft toch het feit dat data gedeeld werd met een derde partij? Waar in hun eigen privacy policy bovendien vermeld staat dat ze dit nooit doen zonder toestemming?

Dit heb ik wel bij We Transfer gevonden: During an upload, while it's stored on our servers and during a download, Content is encrypted and only sent over a secure connection (https). The servers we use to store your Content for you are GDPR compliant and secure.

[mrsardonian]

HKLM_ schreef op maandag 8 augustus 2022 @ 21:20:
[...]


Dit heb ik wel bij We Transfer gevonden: During an upload, while it's stored on our servers and during a download, Content is encrypted and only sent over a secure connection (https). The servers we use to store your Content for you are GDPR compliant and secure.

Dit is inderdaad wat de hoster ook aanhaalt. En wil voor de duidelijkheid de veiligheid van WeTransfer niet betwisten. Vind het vooral vreemd dat een medewerker de wetransfer site kan openen en files kan versturen. De deur voor bedrijfsspionage staat op die manier toch wel wijd open.

De hoster zei hiervan dat dit komt omdat medewerkers hun laptops ook privé mogen gebruiken.
Wat ik helemaal gek vind. Op het werk een prod db downloaden en thuis bestuderen, het zou zo maar eens kunnen.

Maar goed ik word er zelf mogelijks ook wat paranoide van :-).

[ Voor 10% gewijzigd door mrsardonian op 08-08-2022 21:42 ]

[kodak]

Julie kunnen aan de functionaris gegevensbescherming van de hoster vragen waarom ze jullie als verantwoordelijken niet vooraf betrokken hebben hoe jullie de gegevens acceptabel kunnen ontvangen en hoe hun eigen beslissing past bij jullie eisen en wensen.

Dat ze zelf de wet interpreteren wil niet zeggen dat hun eisen en wensen over wat redelijk is de enige zijn waar ze rekening mee hoeven te houden. Want dat de een bijvoorbeeld genoegen neemt dat er beweringen zijn, kan voor de ander net zo goed onvoldoende zijn. Bijvoorbeeld omdat je meer dan beweringen wil, of dat je eisen hebt om alleen via specifieke dienstverleners gegevens te ontvangen. Dat jullie hoster waarschijnlijk van mening is dat er geen datalek is, hoeft niet te betekenen dat hun manier van werken voor jullie of jullie klanten voldoende is.

De vraag of het een datalek is hangt er (ook) vanaf of jullie voor jezelf en anderen vinden dat je nog voldoende controle hebt als een hoster de bedrijfsgegevens en persoonsgegevens van jullie zelf en van anderen verwerkt via bedrijven waar je zelf geen keuze in had. Menen jullie controle te hebben als je hoster vooral zelf beslist wat jullie maar voldoende moeten vinden?

[remco_k]

HKLM_ schreef op maandag 8 augustus 2022 @ 21:20:
[...]
Dit heb ik wel bij We Transfer gevonden: During an upload, while it's stored on our servers and during a download, Content is encrypted and only sent over a secure connection (https). The servers we use to store your Content for you are GDPR compliant and secure.

Ja, leuk en aardig van WeTransfer. Maar als er een 4e partij is die toevallig die WeTransfer link even goed gokt, download ie netjes beveiligd over https die database. Je weet wel, die ene met een niet password beveiligde WeTransfer download.

De verzender kan 0 garantie geven dat de database van TS niet is gelekt. Het verzenden van een "beveiligde mail" telt al helemaal niet. En de verzender kan ook niet weten dat hij wel is gelekt. TS kan het beide zelf ook niet. Ik zou ook not amused zijn. Dit kan een potentieel datalek zijn, of worden, zolang die WeTranser link nog actief is.

[luukvr]

Iets wordt onbeveiligd op het internet geslingerd. Het maakt niet zoveel uit dat de verwijzing 'geheim' is.

Je hoort genoeg verhalen over scrapers die onbeveiligde S3 directories of backup files vinden op servers.

Ik zou snel die backup/wetransfer offline halen.

[MAX3400]

Ik zie toch wel een paar kleine gaten in de casus "tegen" de webhost...

Als je data zo belangrijk is, waarom vraag je dan een MSSQL backup aan die (in de basis) alsnog onversleuteld door het pakket wordt uitgespuugd en/ook door een "onbekende medewerker" geinitieerd moet worden? Kort gezegd; je kan ook zelf je MySQL backup initieren en daarmee zelf aan de gang gaan (meer secure????) om dat in MSSQL te krijgen uiteindelijk on-prem. Of, zoals @HKLM_ aangaf; eisen stellen aan het verzoek en de MSSQL droppen in jouw root; heb je alsnog geen idee hoeveel medewerkers die "plain text file" hebben gezien, bewerkt, neergezet voor je.

Je vindt dat de webhoster/medewerkers geen toegang mogen hebben tot WeTransfer. Wat is dan wel acceptabel als "transfer-dienst"? En hoe groot is dan de limiet dat de hoster of de klant een bestand overgestuurd mag krijgen? Moet je van elke klant eisen dat ze FTPS-server neerzetten met key-pairs per leverancier? MFA-authenticatie naar elkaars Sharepoint om iets uit te wisselen?

Duskwither schreef op maandag 8 augustus 2022 @ 21:19:
Beheerders van je webhost die in jouw onversleutelde database kunnen kijken lijkt me op zich al een datalek, laat staan het delen ervan op wetransfer

En waar leg je die grens?

Een (shared) hosting-omgeving heeft per definitie minstens 1 "administrator" die, hetzij met een 4-ogen-principe, data kan inzien. Is het niet om een klant te helpen (ja, he, die PHP-file van je met functie A waar je over klaagde, ik heb ernaar gekeken en je class is niet goed) of voor een restore (ja, he, ik heb de tapes geladen en je PHP gerestored als restore_functie.php, kan je kijken of dat de goede is) of voor andere zaken.

Dat je een export kan maken van een database en in die export-functie een password meegeven, helemaal top. Maar hoe controleer je dan of die export 100% correct verlopen is? Klant klaagt "ja, die encrpyted backup lijkt maar 99.999% van de records te bevatten en 1 foutmelding". Hoster zegt "geen idee, wij doen export-functie A met password B; zit binnen de dienstverlening". Klant roept "ja maar dat moet je dan toch kunnen controleren". Iets met kip & ei.

Wil je het goed / beter doen? Doe het dan zelf, is in veeeeeel gevallen de standaard-uitspraak En voor een website, database, etc; het is niet lastig om dat zelf te hosten. Of een dedicated server ergens op te hangen en die 100% zelf te beheren. "Ja maar kosten"... Ook hier dus: pay peanuts, get monkeys, blijkbaar...

[Oon]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:05:
Is dit een datalek volgens jullie? En is het normaal dat medewerkers van een hostingbedrijf toegang hebben tot WeTransfer? Is er iets dat ik verder best kan of moet doen? Of iemand die al iets gelijkaardigs heeft meegemaakt?

Dat mederwerkers van een hostingbedrijf toegang hebben tot WeTransfer is absoluut normaal, er is geen enkele reden om die toegang te beperken. Of WeTransfer de juiste manier is om gegevens van klanten te gaan versturen is een tweede. Assets voor een website, oké, maar ik vind het ook wel een beetje vreemd om hier een hele database met mogelijk gevens van jullie klanten zomaar in te gooien.

Een datalek zal het niet zijn, want er is geen onbedoelde toegang tot de informatie geweest; jullie hebben een verwerkersovereenkomst getekend waarin waarschijnlijk gewoon staat dat ze gegevens op jullie verzoek mogen versturen. Meestal staat hier een heel vrij te interpreteren 'op een veilige manier' in, en aangezien WeTransfer ook een redelijk straight-forward verwerkersovereenkomst heeft ('wij doen niks met je data, onze inkomsten komen uit betaalde abonnementen en advertenties') en gewoon over HTTPS werkt kun je stellen dat aan die voorwaarde voldaan is.

Gebruikelijk is dat er echter een end-to-end encrypted dienst met expliciete overeenkomst en verificatie voor ontvangst gebruikt wordt. Een voorbeeld hiervan is Zivver, daar kun je bij versturen o.a. een telefoonnummer en/of e-mailadres van de ontvanger invullen, waarbij ze dus moeten bevestigen dat ze zijn wie ze zijn voor ze het bericht (met bijlagen) kunnen openen.

Een andere optie is WeTransfer met een versleuteld bestand, waarbij de sleutel uiteraard niet per e-mail wordt verstuurd. E-mail is per definitie onveilig, tenzij je twee partijen met een (vooral face-to-face overgedragen) sleutel hebt die dus de e-mail ook versleutelen. Maar een linkje via het WeTransfer formulier is dat dus niet.

Ik ben benieuwd wat jullie security officer of die van de webhost hier over zegt. Ik verwacht dat het sowieso geen datalek is, maar ik zou dit toch wel even checken met de SO van beide partijen, aangezien het zeker merkwaardig is. Uiteindelijk houdt het daar ook wel op tenzij er dus toegang door een derde partij is geweest via een gehackte mailserver, maar het is goed om aan beide kanten controle te laten plaatsvinden op de processen die hiervoor zijn vastgelegd.

Een 'beveiligde ssl mail' bestaat overigens niet. Jij kan beveiligd met de server zijn verbonden, WeTransfer zal intern ook niet vatbaar zijn voor een MITM aanval, maar er is de theoretische kans dat er ergens een relay tussen zit of iemand toegang heeft tot het mailaccount zonder SSL, en de mail zelf dus gewoon volledig uit te lezen is. Persoonsgegevens horen gewoon nooit in e-mail thuis.

[BytePhantomX]

Was de WeTransfer link op de één of andere manier beveiligd met een code, of ging men er vanuit dat een verborgen link voldoende was?

Als er geen extra beveiliging op zat dan is dat m.i. een datalek. De database staat zonder beveiligingsmaatregelen op een open webdienst op het internet. Voor zover mij bekend houdt de WeTransfer geen access log bij, dus je kan niet weten wie er allemaal toegang heeft gehad.

En er wordt, bijvoorbeeld in de zorg, niet voor niets niet gewerkt met gewone e-mail. Simpelweg omdat het nooit als veilig kan worden beschouwd. Ook niet als het SSL is. Hoe kan jouw webhoster weten dat de keten in tact is gebleven en de SSL keten niet ergens is afgebroken? Wil je dit veilig per e-mail doen, dan moet je de e-mail encrypten en signen, bijvoorbeeld met PGP.

Ps, het feit dat ze dit gedrag verdedigen, zou voor mij reden zijn om snel te gaan zoeken naar een andere hoster. Meestal is dit typerend hoe ze tegen beveiliging aankijken en slaan ze daar vaak de plank bij mis.

En volgende keer eisen dat het bestand wordt versleuteld voor het via een filesharing dienst gaat en de key via een apart kanaal wordt verstuurd (signal ofzo).

[DataGhost]

MAX3400 schreef op dinsdag 9 augustus 2022 @ 09:14:

Je vindt dat de webhoster/medewerkers geen toegang mogen hebben tot WeTransfer. Wat is dan wel acceptabel als "transfer-dienst"?

Vraag je dit nou serieus over een webhoster? Ik mag toch hopelijk verwachten dat zij op een vrijwel triviale manier de middelen intern zouden moeten hebben om dat voor elkaar te krijgen, en op een veilige manier. Zeker aangezien er dus gewoon mappen zijn ("de root") die niet zonder authenticatie te bereiken zijn en andere backups wel op die manier toegankelijk gemaakt worden. Het klinkt vooral als een ongelofelijke partij onkunde, van de medewerker in kwestie of zelfs van de hoster. En ja, met deze voor de hand liggende en triviale manier mogen diensten als WeTransfer wat mij betreft gewoon geblokkeerd zijn voor medewerkers of zou het beleid minimaal moeten zijn dat er sancties staan op het gebruik van dergelijke diensten.

En hoe groot is dan de limiet dat de hoster of de klant een bestand overgestuurd mag krijgen? Moet je van elke klant eisen dat ze FTPS-server neerzetten met key-pairs per leverancier? MFA-authenticatie naar elkaars Sharepoint om iets uit te wisselen?

De klant kan al met SFTP/FTPS (even gok dat de S erin zit maar anno 2022 zal dat wel toch?) bij zijn root en data dus alle hoepels die jij noemt zijn niet van toepassing.

[laurens0619]

remco_k schreef op maandag 8 augustus 2022 @ 23:47:
[...]

Ja, leuk en aardig van WeTransfer. Maar als er een 4e partij is die toevallig die WeTransfer link even goed gokt, download ie netjes beveiligd over https die database. Je weet wel, die ene met een niet password beveiligde WeTransfer download.

De verzender kan 0 garantie geven dat de database van TS niet is gelekt. Het verzenden van een "beveiligde mail" telt al helemaal niet. En de verzender kan ook niet weten dat hij wel is gelekt. TS kan het beide zelf ook niet. Ik zou ook not amused zijn. Dit kan een potentieel datalek zijn, of worden, zolang die WeTranser link nog actief is.

“Even goed gokt”
Ik heb even het formaat van die link bekeken

https://wetransfer.com/downloads/<tekenreeks van 46chars>/<tekenreeks van 46 chars>/<tekenreeks 6 chars>

Ik vind het niet heel aannemelijk dat je even 98 random chars “even goed gokt”

En een password gebruiken? Los van t feit dat veel mensen slechte wachtwoorden gebruiken, vaak zijn deze secrets via de mail te resetten..

Zolang een password te resetten is via een mailbox vind ik een authenticatielink veiliger (mits veilig ingericht) want dan heb je geen last van hergebruikte/makkelijk te raden wachtwoorden. Plus als je mailbox achter mfa zit, is de dienst die je gebruikt daardoor ook een soort van achter mfa. De wereld gaat niet voor niets naar password less.

Tuurlijk de hoster had t bestand gewoon moeten encrypten voor de upload en het wachtwoord delen via separaat kanaal.
Of het encrypted op hun eigen sftp uploaden maar daar kun je je sterk afvragen of dat nou veiliger is. Die dingen hebben vaak geen mfa, gebrekkige monitoring etc etc. Het is niet hun core business om data online te delen, van wetransfer wel.

[DataGhost]

laurens0619 schreef op dinsdag 9 augustus 2022 @ 13:26:
[...]

“Even goed gokt”
Ik heb even het formaat van die link bekeken

https://wetransfer.com/downloads/<tekenreeks van 46chars>/<tekenreeks van 46 chars>/<tekenreeks 6 chars>

Ik vind het niet heel aannemelijk dat je even 98 random chars “even goed gokt”

En een password gebruiken? Los van t feit dat veel mensen slechte wachtwoorden gebruiken, vaak zijn deze secrets via de mail te resetten..

Zolang een password te resetten is via een mailbox vind ik een authenticatielink veiliger (mits veilig ingericht) want dan heb je geen last van hergebruikte/makkelijk te raden wachtwoorden. Plus als je mailbox achter mfa zit, is de dienst die je gebruikt daardoor ook een soort van achter mfa. De wereld gaat niet voor niets naar password less.

Tuurlijk de hoster had t bestand gewoon moeten encrypten voor de upload en het wachtwoord delen via separaat kanaal.
Of het encrypted op hun eigen sftp uploaden maar daar kun je je sterk afvragen of dat nou veiliger is. Die dingen hebben vaak geen mfa, gebrekkige monitoring etc etc. Het is niet hun core business om data online te delen, van wetransfer wel.

Maar als het geheel gewoon via e-mail verstuurd is heb je dikke kans dat dat een onversleutelde mail is die ook via niet-beveiligde verbindingen het internet over gegaan is. Dus dan hoef je niet veel te raden.

[laurens0619]

DataGhost schreef op dinsdag 9 augustus 2022 @ 13:42:
[...]

Maar als het geheel gewoon via e-mail verstuurd is heb je dikke kans dat dat een onversleutelde mail is die ook via niet-beveiligde verbindingen het internet over gegaan is. Dus dan hoef je niet veel te raden.

Als email communicatie zo makkelijk af te luisteren zou zijn dan zou een significant aantal van alle online accounts te hacken zijn (dmv password reset)

Stel het mailtje van wetransfer naar bv de gmail
Smtp server zou unecrypted over de lijn gaan (denk het niet maar stel), dan moet je ook op die lijn zitten om het af te luisteren

Theoretisch is alles hackbaar maar dan word je gek in security, risk based is de kans dat je die mail kan onderscheppen gewoon laag

[Jazzy]

Punt rondom gevoelige email is vooral dat je zeker moet weten dat je de gegevens deelt met alleen degene voor wie het bedoeld is. Een eenvoudig foutje in het invoeren van het mailadres, per ongeluk selecteren van een entry uit je adresboek, etc. kan tot resultaat hebben dat het bericht bij een verkeerde persoon uitkomt.

Je kunt je afvragen of een organisatie dan voldoende zorgvuldig met de gegevens om gaat. Betere oplossing zou zijn om de data beschikbaar te maken via gebruikersnaam/wachtwoord op de omgeving waar de TS al toegang toe heeft. Of aanvullend te beveiligen met een wachtwoord dat via een andere mechanisme wordt gedeeld, bijvoorbeeld SMS.

[DukeBox]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:24:
Dit is inderdaad wat de hoster ook aanhaalt.

Je zou de hoster dan nog kunnen vragen om een verwerkers overeenkomst met wertansfer. Die krijg je namelijk alleen bij de betaalde versie (die ook wachtwoorden ondersteund).

Verder sluit ik mij aan bij de rest dat de hoster zelf een dergelijke dienst zou moeten hebben.

[Sissors]

Dat een hoster dit niet zelf met hun eigen servers kan is natuurlijk wat apart. Maar als dit niet een hoster was geweest, maar bijvoorbeeld je accountant die de bedrijfscijfers doorstuurt die bij Microsoft gehost blijken te zijn. Zou je dan ook het probleemmatig vinden dat een derde partij de data heeft in principe?

[DJMaze]

Ik snap de hoster wel.
Hier ben ik PCI-DSS en NEN compliant, en als een klant vraagt om backups: login op de server met je TOTP, maak een SSH sleutel aan, en via SFTP kan je er dan bij.

Nou, dan kan ik 9 van de 10 keer alles tot in detail gaan uitleggen (keer op keer).

Als de klant niet betaalt voor beveiliging, dan zou ik het ook op WeTransfer knikkeren.

[kodak]

DJMaze schreef op woensdag 10 augustus 2022 @ 20:01:
Als de klant niet betaalt voor beveiliging, dan zou ik het ook op WeTransfer knikkeren.

Dat je compliant bent wil niet zomaar zeggen dat het compliant is met de eisen waar klanten aan menen te moeten voldoen.Dat zal eerst ergens uit moeten blijken, zeker als het gaat om gegevens die niet van jou zijn en mogelijk zelfs van anderen ipv je klant. Er staat niet voor niets niet in de wet dat compliant zijn met een standaard maar voldoende is.

Maar de klant heeft niet extra betaald? Dan heb je waarschijnlijk ook geen overeenkomst om meer te doen dan waar wel voor betaald is, kun je alsnog niet zomaar zelf gaan verzinnen wat je met andermans gegevens doet. Niet extra betalen is eerder een reden om juist niet meer te doen dan is afgesproken en eerst afspraken te maken.

En als een bedrijf als klant je te veel tijd kost in verhouding tot de overeenkomst? Dat is bedrijfsrisico bij klanten, je hebt niet alleen voordelen. Wat dat betreft heb je met een bedrijf als klant veel mogelijkheden om het zakelijk gezamenlijk op te lossen. Dan ga je eerst met elkaar in onderhandeling over de overeenkomst, of is het redelijk om de overeenkomst beindigen door alsnog op een eerst met elkaar afgesproken manier de laatste verwerking doen.

[mrsardonian]

@kodak Daar volg ik je volledig in. Er is ook geen soort van add-on beschikbaar voor extra security, er is ook geen bericht naar ons gekomen dat we extra zouden moeten betalen in de toekomst. Het bedrijf gaat er prat op dat alle data bij hen veilig is, en heeft hier ook enkele certificaten of onderscheidingen voor.

Ik vermoed dat dit voorval te wijten is aan een menselijke fout en het ontbreken of niet naleven van een data policy voor medewerkers. Op zich heb ik hier wel begrip voor, fouten maken is heel menselijk. Maar de reactie dat we kregen van het bedrijf is - ik kan jammer genoeg niet in detail treden - zeer bedroevend en frustrerend.

@MAX3400 Bedankt voor je reactie! Ik beschouw het eigenlijk niet als een case tegen de webhost maar eerder een voor het beschermen van de privacy van ons bedrijf en vooral van onze klanten. Ik kan niet uitwijden over de inhoud van de databank maar uit de benaming van de db kan iedereen afleiden dat er omzichtig moet mee omgesprongen worden. Zelf een backup nemen van de databank wordt door de hoster niet ondersteund, wij kunnen dit enkel vragen via een mail aan support.

Wij hebben van onze kant verder ook nooit de indruk gehad dat onze support vragen "bij om het even wie" terecht kwamen. Het bedrijf in kwestie is geen kleine speler en beweert zelf privacy en specifiek AVG héél serieus te nemen. Op basis van oa deze elementen hebben we bewust gekozen voor hen als leader op vlak van privacy ipv een volger. Want op het einde van de rit zijn wij verantwoordelijk voor de data die wij toevertrouwen aan de webhost.

@BytePhantomX De link was niet beveiligd met een passwoord. Het bestand dat werd doorgestuurd was een .bak file en was onversleuteld. Had je de link kon je de data gewoon uitlezen.

@Sissors Afhankelijk wat de inhoud is van dergelijke documenten, vind ik dat problematisch ja. Daarom vragen we standaard bij elke nieuwe partner naar een verwerkersovereenkomst. Dat geeft nog absoluut geen garanties maar dan hebben we toch iets. Facturen van bv leveranciers ontvangen en versturen we gewoon via mail.

@DJMaze Thanks voor je antwoord. Ik geef toch nog graag mee dat de hoster geen kleine partij is. We betalen dan ook een premiumprijs. En die prijs werd in het verleden ook al geïndexeerd (waar ik overigens geen problemen mee heb), maar ik verwacht dan wel dat bepaalde basisregels en de eigen privacy policy van de hoster worden gerespecteerd dat is in dit geval niet gebeurd.

[DJMaze]

@mrsardonian als je een premium prijs betaalt en de juiste beveiligingsafspraken, dan is het inderdaad een foutief handelen van de hoster.
Zeker wanneer ze zelf ook roeptoeteren over de nodige standaarden en certificaten.

[BernardV]

Jazzy schreef op dinsdag 9 augustus 2022 @ 14:29:
Punt rondom gevoelige email is vooral dat je zeker moet weten dat je de gegevens deelt met alleen degene voor wie het bedoeld is. Een eenvoudig foutje in het invoeren van het mailadres... *knip*

Precies dit; Ik heb een domein die 1 letter minder heeft dan een gemeente in NL. Het komt regelmatig voor dat ik mail ontvang die niet voor mij bedoeld is, facturen van 3den, aanvragen (soms zelfs met BSN e.d.). Ik heb de gemeente al een paar keer gesproken, maar het beleid is niet echt veranderd m.b.t. gevoelige gegevens.
Ik stuur de mails meestal door door de letter toe te voegen en CC ook naar de verzender met melding dat ze de mail niet naar de goede partij hebben gestuurd.

[Tozz]

mrsardonian schreef op maandag 8 augustus 2022 @ 21:17:
[...]
Gaat mij absoluut niet meer overkomen. Maar er lijkt mij nooit een geldige reden te zijn om een productiedatabank onversleuteld door te sturen, al zeker niet via WeTransfer.

De data is niet onversleuteld verzonden. Het is verzonden over een HTTPS link. Zowel bij de up- als de download. Je kunt alleen nog aanvoeren dat de data onversleuteld bij WeTransfer is opgeslagen.

Echter.. Het is helemaal niet raar dat bedrijven derden inschakelen voor bepaalde diensten. Jouw e-mail bij Office365 is waarschijnlijk ook onversleuteld opgeslagen. Dat is dan toch ook geen datalek? Veel salarisadministraties worden ook door grote derde partijen gedaan. Die weten ook allemaal hoe hoog jouw loon is.

Wanneer de betreffende hostingpartij WeTransfer als vertrouwde derde heeft bestempeld dan is het in principe in orde.

Was een wachtwoordje op de ZIP beter? Wellicht. Is dit een datalek? Nee.

[Tozz]

mrsardonian schreef op donderdag 11 augustus 2022 @ 10:15:Want op het einde van de rit zijn wij verantwoordelijk voor de data die wij toevertrouwen aan de webhost.

Dit is toch precies de crux? Waarom mag jij wel vertrouwen op een derde (de webhost) voor je data maar mag volgens jouw die webhost niet vertrouwen op WeTransfer?

Als de webhost dezelfde due diligence heeft gedaan op WeTransfer als jij bij de webhost gedaan zegt te hebben (hoewel ik 'we betalen veel' nou niet echt due diligence vind) dan is het toch in orde?

Je meet naar mijn mening met 2 maten. Jij mag wel maar zij mogen niet.

Ik denk dat er ook best veel automatiseerders zijn die bijvoorbeeld de backups uitbesteden aan cloud partijen. Of die zelfs hun hele hebben en houden (lees: de hele infra) bij Amazon in de cloud hebben draaien. Die data is niet meer versleuteld dan die .BAK bij WeTransfer.

[mrsardonian]

@Tozz Bedankt voor je reactie.
Zoals eerder aangegeven hadden wij voor dit project specifieke voorwaarden. De hoster werd gekozen omdat hun privacy policy/algemene voorwaarden volledig voldeden aan onze voorwaarden. Over data delen met derden werd niets vermeld, al zeker niet zonder onze toestemming. Hierdoor wordt het - volgens onze bronnen - een datalek (althans zo heb ik het begrepen :-)). Overigens was prijs zeker niet het enige criteria om de kwaliteit van de host te beoordelen.

Wij mogen er vanuit gaan dat een hoster zijn eigen policy volgt. Anders zou een privacy policy zinloos zijn :-). Op basis van algemene voorwaarden/privacy policy en andere factoren zoals referenties oa hebben we vertrouwen met een partner. Had de hoster vermeld dat de kans bestond dat ze ooit gebruik zouden maken van WeTransfer om onze bestanden door te sturen dan hadden we dit onmiddellijk geweigerd.

Wat betreft Amazon, voor een ander project maken we gebruik van AWS S3. Hier hebben we eveneens een overeenkomst, waarin expliciet vermeld wordt dat alle data versleuteld is én dat employees geen toegang hebben tot de data. De data komt enkel vrij mits gebruik van een specifieke toegangscode die enkel wij hebben.

Als laatst, oprechte dank om dieper in te gaan op deze kwestie.

[Tozz]

Ik denk dat de privacy policy niet het juiste document is. Ik denk dat je de verwerkersovereenkomst had moeten hebben. Die kan soms geintegreerd zijn in de Algemene Voorwaarden. Een privacy policy gaat vooral over de verwerking van persoonsgegevens van jou als klant en niet zozeer om eventuele data die de hoster verwerkt.

Een zinnetje als "Verwerkingsverantwoordelijke verleent Verwerker toestemming om bij de verwerking derden (subverwerkers) te mogen inschakelen" is standaard in vrijwel elke verwerkersovereenkomst, al dan niet met nog wat vereisten aan die subverwerkers.

[Jazzy]

Tozz schreef op vrijdag 12 augustus 2022 @ 13:39:
Ik denk dat er ook best veel automatiseerders zijn die bijvoorbeeld de backups uitbesteden aan cloud partijen. Of die zelfs hun hele hebben en houden (lees: de hele infra) bij Amazon in de cloud hebben draaien. Die data is niet meer versleuteld dan die .BAK bij WeTransfer.

Je doet in deze twee berichten allerlei aannames en lijkt vervolgens de TS de les te willen lezen. Denk dat je zowel op technisch als privacy-gebied gerust wat terughoudender mag zijn met je uitspraken. Om er even één puntje uit te pikken, je data in Office 365 is zowel tijdens transport (client connecties, routeren van email, datasynchronisatie tussen locatie) als tijdens opslag (disken van opslagsystemen en servers) altijd versleuteld.

Verder gaat het bezwaar van de TS vooral over een combinatie van zaken die in samenhang niet de indruk geven dat de hoster op de juiste, zorgvuldige manier met de data van TS om gaat. Bijvoorbeeld door het gebruik van email waarbij je niet kunt garanderen dat het alleen bij de juiste persoon terecht komt, het feit dat geen authenticatie bij WeTransfer nodig is en dat de backup niet versleuteld is. Zouden ze op slechts één van die drie gebieden anders gehandeld hebben dan zou het gevaar voor een datalek al enorm verminderd zijn.

Ik zou werkelijk niet weten waarom het eisen van redelijk standaard beveiligingsmaatregelen dan "het meten met twee maten" is. Volgens mij heeft de TS alle reden om dit aan de kaak te stellen. Bovendien vraag je je af hoe goed dit bedrijf het op andere gebieden voor elkaar heeft, als securitybewustzijn bij de medewerkers niet top of mind is.

[Tozz]

je data in Office 365 is zowel tijdens transport (client connecties, routeren van email, datasynchronisatie tussen locatie) als tijdens opslag (disken van opslagsystemen en servers) altijd versleuteld.

Dit is onzin. SMTP communicatie, dus e-mail afleveringen tussen servers onderling, is oppertunistisch versleuteld op z'n best. Dat wil zeggen zonder encryptie of zonder validatie van certificaten. Dat kan dus ook een self-signed certificaat zijn.. Een certificaat dat vervallen is of een certificaat waarvan de common name niet matched met de server. Of helemaal geen certificaat (dus plain text). In andere woorden.. het mag dan versleuteld zijn met een beetje geluk, er is geen validatie of je wel echt met de juiste persoon hebt gesproken. De mail kan dus onderschept of gewijzigd zijn door een MitM aanval.

Je kunt in O365 aangeven dat TLS encryptie afgedowngen wordt (met verificatie), maar dan zul je het overgrote deel van je e-mail gaan missen, want een belachelijk groot deel van de SMTP machines op Internet gebruiken ongeldige certificaten.

Het zal ongetwijfeld zijn dat binnen het ecosysteem van Microsoft het versleuteld is. Maar e-mail communicatie tussen verschillende partijen onderling zijn nou eenmaal simpelweg niet of niet goed versleuteld.

Los daarvan verwerkt Microsoft je e-mail ook tot in ieder geval de laatste verwerkingsstappen onversleuteld. Denk daarbij aan spamfiltering, DKIM validatie, het toevoegen van 'Received' headers, etc. In dat proces kunnen beheerders van Microsoft die mail dus lezen. At best is de mail versleuteld op het moment dat het in een mailbox zit, maar ook daar heb ik zo mijn twijfels bij. Lijkt mij een uitdaging qua indexes en optimalisatie van search queries.

Bijvoorbeeld door het gebruik van email waarbij je niet kunt garanderen dat het alleen bij de juiste persoon terecht komt, het feit dat geen authenticatie bij WeTransfer nodig is en dat de backup niet versleuteld is.

Hier heb je enigzins een punt.. Maar als de WeTransfer link verzonden is als reply op een verzoek tot het overhandigen van een backup dan vind ik het niet een bijzonder sterk argument. Als de hoster uit eigen initiatief is gaan e-mailen dan is die kans er inderdaad wel.

Ik maak uit de OP echter op dat de discussie vooral gaat om het gebruik van een derde partij zoals WT en niet zozeer uit de gekozen distributiewijze van de link. Ik ben het wel eens dat op z'n minst een wachtwoordje op de BAK file beter was geweest.. Maar *dat* is vooral een fout van de hoster zelf en staat verder los van het gebruik van WT als third-party verwerker.

Ik blijf er bij dat de hoster een valide argument heeft.. Namelijk dat WT zich moet houden aan de AVG/GDPR omdat ze een Europees bedrijf zijn.. En zeker als de hoster ook WT heeft beoordeeld (denk aan controle ISO27001, PCI-DSS) en goedbevonden heeft en er in de verwerkersovereenkomst is genoemd dat er derde partijen ingeschakeld kunnen worden dan is met deze praktijk juridisch helemaal niets mis. Dan is er dus geen datalek en is dit naar mijn mening ook niet "opmerkelijk".

Verder denk ik dat gegevens veel vaker door derden worden verwerkt dan de meeste mensen, inclusief TS, denken. Zeker met het gebruik van clouddiensten (AWS, Azure, O365) en allerlei SaaS producten (administratie, backup diensten) slingert je data werkelijk overal en nergens rond.

[F_J_K]

HKLM_ schreef op maandag 8 augustus 2022 @ 21:08:
Welke voorwaarden heb je aan je leverancier gesteld bij het opvragen van de data?

Heb je bijvoorbeeld van tevoren opgevraagd hoe ze dergelijke data versturen?

Als ik zo iets zou moeten krijgen van een leverancier zou ik, voordat er verstuurd gaat worden afspraken maken over hoe het verstuurd gaat worden. En niet handjes in de lucht en kijken hoe de leverancier het aanlevert. Wat schijnbaar niet compliance is met jullie security / privacy beleid. Maar wel die van de hoster vandaar de afspraken

Eens, maar zonder afspraken mag / moet je er nog steeds op vertrouwen dat de hoster zich gedraagt. En dat is heel erg niet het geval met onversleutelde backups delen, danwel een backup zonder enige autorisatie/authenticatie (of logging?) op de toegang ertoe.

-

Ja het is een datalek, immers gebeurt er iets met de data dat de verantwoordelijke, de TS, niet verwachte en niet wilde. Dus een datalek. Een datalek hoeft niet te zijn dat iemand misschien / zeker heeft meegekeken. Dat zou het ook zijn als bijv. per ongeluk de backup wordt gedeletet.

Of het is te melden bij de AP is een ander verhaal, zijn er indicaties dat er misbruik is? Is het bestand meer dan 1x gedownload? Waarschijnlijk niet nodig.

Wel nodig: afspraak maken dat in het vervolg wordt versleuteld - en die sleutel niet ook in de mail staat

MAX3400 schreef op dinsdag 9 augustus 2022 @ 09:14:
Je vindt dat de webhoster/medewerkers geen toegang mogen hebben tot WeTransfer. Wat is dan wel acceptabel als "transfer-dienst"? En hoe groot is dan de limiet dat de hoster of de klant een bestand overgestuurd mag krijgen? Moet je van elke klant eisen dat ze FTPS-server neerzetten met key-pairs per leverancier? MFA-authenticatie naar elkaars Sharepoint om iets uit te wisselen?

(S)FTP(S), cloud filesharing, whatever. Maar versleutel vlak voor je het stalt. Na controles.

Ook hier dus: pay peanuts, get monkeys, blijkbaar...

Dat sowieso.

Moraal van het verhaal: maak nu goede afspraken. (En controleer dat die worden nageleefd).

[worldfastest]

Enige wat ik zo zie is dat er een datalek is en dat TS de schuldige is van het lek. Hij is degene die het verzoek heeft gedaan zonder enige randvoorwaarden. TS zou zelf voor een backup moeten zorgen en deze op een veilige manier verschepen.

[F_J_K]

worldfastest schreef op maandag 15 augustus 2022 @ 13:25:
Enige wat ik zo zie is dat er een datalek is en dat TS de schukdige is van het lek. Hij is degene die het verzoek heeft gedaan zonder enige randvoorwaarden. TS zou zelf voor een backup moeten zorgen en deze op een veilige manier verschepen.

De TS is sowieso verantwoordelijk. Al kan het wel zo zijn dat de verwerker aansprakelijk is. (Al zal dat hier meevallen - er is geen schade?)

Voorbeeld van waar de hoster prutst, er geen afspraak is, maar toch aansprakelijk omdat ze niet doen wat van een “redelijk bekwaam en redelijk handelend ICT-dienstverlener” mag worden verwacht:
https://blog.iusmentis.co...on-backups-maken-klanten/

Maar goed, aanleiding om andere afspraken te maken en controleren. Waarbij ik voor zoiets basaals zelf niet snel bereid zou zijn meerkosten te betalen (en anders dat geld liever zou steken in verhuizen), maar dat is aan de TS.

[Jazzy]

Tozz schreef op maandag 15 augustus 2022 @ 12:57:
[...]


Dit is onzin. SMTP communicatie, dus e-mail afleveringen tussen servers onderling, is oppertunistisch versleuteld op z'n best. Dat wil zeggen zonder encryptie of zonder validatie van certificaten. Dat kan dus ook een self-signed certificaat zijn.. Een certificaat dat vervallen is of een certificaat waarvan de common name niet matched met de server. Of helemaal geen certificaat (dus plain text). In andere woorden.. het mag dan versleuteld zijn met een beetje geluk, er is geen validatie of je wel echt met de juiste persoon hebt gesproken. De mail kan dus onderschept of gewijzigd zijn door een MitM aanval.

Je kunt in O365 aangeven dat TLS encryptie afgedowngen wordt (met verificatie), maar dan zul je het overgrote deel van je e-mail gaan missen, want een belachelijk groot deel van de SMTP machines op Internet gebruiken ongeldige certificaten.

Het zal ongetwijfeld zijn dat binnen het ecosysteem van Microsoft het versleuteld is. Maar e-mail communicatie tussen verschillende partijen onderling zijn nou eenmaal simpelweg niet of niet goed versleuteld.

Ik schreef dan ook IN Office 365, staat in de quote die je aanhaalt. We hebben het hier over service providers en of die je data versleutelen.

At best is de mail versleuteld op het moment dat het in een mailbox zit, maar ook daar heb ik zo mijn twijfels bij. Lijkt mij een uitdaging qua indexes en optimalisatie van search queries.

Je schreef:

Tozz schreef op vrijdag 12 augustus 2022 @ 13:35:
Jouw e-mail bij Office365 is waarschijnlijk ook onversleuteld opgeslagen.

Dat is dus niet zo, data in rest is wel versleuteld opgeslagen. Zie https://docs.microsoft.co...rview?view=o365-worldwide voor meer uitleg en de gebruikte technieken.

[Tozz]

Zie https://docs.microsoft.co...rview?view=o365-worldwide voor meer uitleg en de gebruikte technieken.

Ik heb 'm even snel doorgelezen.. Daar staat dat ze BitLocker gebruiken voor data 'at rest', dus mailbox content. Misschien heb ik het mis, maar volgens mij betekent dit dat zodra zo'n filesystem gemount is (wat in praktijk altijd het geval zal zijn), dat deze data onversleuteld beschikbaar is voor de machine en dus ook voor beheerders van Microsoft ..

Ik gebruik zelf BitLocker.. En dat is inderdaad versleuteld zodra ik mijn PC opstart.. Dan moet ik een wachtwoord ingeven en dan is de data bereikbaar voor mij. Maar dus ook voor bijvoorbeeld malware dat mijn data wil stelen.

Filesystem encryptie is eigenlijk alleen zinvol tegen diefstal van je harddisks/SSDs. Voor een systeem dat productie draait (en dus de originele unencrypted data kan benaderen) voegt 't niets toe.

[Sniels]

Tozz schreef op maandag 15 augustus 2022 @ 15:41:
Misschien heb ik het mis [...]

Ja en nee.

Standaard wordt data-at-rest inderdaad met Bitlocker versleuteld. Het is echter niet zo dat bij het mounten van het FS alle data ineens decrypted is. Encryption/decryption wordt door Bitlocker on-the-fly uitgevoerd.

Op je PC overigens ook maar gezien je account over de nodige keys beschikt, merk je daar weinig van. Pas wanneer je Bitlocker zou uitschakelen zul je zien dat dat best even duurt, omdat dan alles decrypted moet worden.

Daarbij wordt dan ook nog eens Distributed Key Management (DKM) toegepast. DKM zorgt ervoor dat alleen geautoriseerde service accounts (in dit geval de accounts waaronder de eigen Exchange tenant werkt) toegang tot de keys kunnen krijgen. Zonder die keys is decrypten natuurlijk onmogelijk.

Voor de volledigheid: ja, die keys zijn (standaard) in beheer van Microsoft en ja, een beheerder kan (na een streng proces) toegang krijgen tot deze data. Als je dat niet wil kun je met Customer Key de keys in eigen beheer nemen (en kun je ook je veto uitspreken over een toegangsverzoek).

Edit: toevoeging "Op je PC [...]".

[ Voor 13% gewijzigd door Sniels op 15-08-2022 16:34 ]

[jurroen]

DataGhost schreef op dinsdag 9 augustus 2022 @ 13:42:
[...]

Maar als het geheel gewoon via e-mail verstuurd is heb je dikke kans dat dat een onversleutelde mail is die ook via niet-beveiligde verbindingen het internet over gegaan is. Dus dan hoef je niet veel te raden.

Die dikke kans valt tegenwoordig wel mee. Het overgrote deel van mail is met TLS. Zie bijvoorbeeld deze statistieken bij Google of dit rapport van F5.

[laurens0619]

Data at rest encrypten is vooral tegen fysieke diefstal zoals @Tozz ook aanhaalt.
Voor laptops daarom super nuttig, voor servers een stuk minder. De server kan tenslotte gewoon bij de data, inclusief beheerder

Een ander verhaal Zou zijn als de data echt end to end encrypted is zoals bv “fileshare” dienst als mega (even los van het feit dat er vraagtekens bij de implementatie zijn en uberhaupt het bedrijf mega). Als ik wetransfer zou zijn dan zou ik dit ook aanbieden want dan kun je nooit bij de data. Probleem is alleen dat het minder gebruiksvriendelijk is omdat de sleutel los gedeeld moet worden.

Maar terug naar de fileshare: veel bedrijven zijn overgestapt naar SaaS diensten omdat andere partijen het vaker beter, veiliger en goedkoper kunnen aanbieden.
Als een hoster geen expertise heeft in veilig bestanden delen dan heb ik liever dat ze een SaaS dienst gebruiken die hier wel expert in is. Beter dan dat $sysadminHoster denkt “ik installeer wel ff filezilla ftp server ergens”.
Schoenmaker blijf bij je leest

Dataset zou ik wel altijd encrypten (zip) bij zoiets voor de upload.

[Tozz]

jurroen schreef op maandag 15 augustus 2022 @ 21:10:
[...]


Die dikke kans valt tegenwoordig wel mee. Het overgrote deel van mail is met TLS. Zie bijvoorbeeld deze statistieken bij Google of dit rapport van F5.

Ja, maar ze melden hier niet hoeveel daarvan daadwerkelijk slaagt.

Dit is net zoiets als 'Kijk, vrijwel elke website doet SSL'.. Zonder daarbij te melden hoeveel daarvan een verlopen of ongeldig certificaat hebben.

Maar goed, dit is OT.