Een lezer vroeg me:
Als je data opvraagt waar je volgens de AVG recht op hebt, dan is de organisatie verantwoordelijk voor het veilig versturen van deze data. Wat nu als een organisatie deze via e-mail stuurt? Ze kunnen dan wel TLS gebruiken, maar dat beschermt de data niet als deze eenmaal in mijn mailbox zit.Inderdaad, een verwerkingsverantwoordelijke (zoals zo’n organisatie) moet zorgen voor een goede beveiliging van die persoonsgegevens. Dat speelt ook bij het afhandelen van een inzageverzoek.
Het gebruik van TLS bij het verzenden van e-mail lijkt me een voor de hand liggende beveiligingsmaatregel tegen meelezen in transit. Ik zou niet weten waarom je anno 2023 als organisatie mail verstuurt zonder TLS naar de ontvangende mailserver.
Natuurlijk beveiligt TLS niet tegen een inbraak in de mailbox bij de ontvanger. Maar op het moment dat de mail bij de (organisatie of isp van de) ontvanger is aangekomen, is de ontvanger zélf verwerkingsverantwoordelijke van die gegevens geworden. Daarmee houdt op dat moment de zorgplicht van de verstrekkende organisatie gewoon op.
Een organisatie zou de gegevens ook anders kunnen verstrekken, zoals een download vanuit een beveiligde site of de bijlage voorzien van een wachtwoord dat via apart kanaal wordt verstrekt. Maar ik zie het wezenlijk verschil niet: zodra ik de download binnen heb of de bijlage ontvang, is de data nog steeds mijn verantwoordelijkheid.
Heel misschien is verdedigbaar dat je mag verwachten dat veel ontvangers niet goed zijn in security, en dat je ze dus een beetje moet helpen. Bijvoorbeeld dus door een wachtwoordbeveiliging met het wachtwoord apart verstuurd. Maar nog los van de vraag of je bij zo’n inzageverzoek wel een tweede communicatiekanaal hébt, ik weet geen artikel in de AVG waaruit zo’n vergaande zorgplicht dwingend zou volgen.
Arnoud
Je lijkt hiermee te stellen dat het bestaansrecht van partijen als Zivver en Zorgmail is weggevallen, tenminste wat betreft communicatie met clienten etc. Begrijp ik dat goed? Zo niet, waar zit het verschil?
Dat begrijp ik niet, hoe volgt dat uit wat ik zeg? Ook bij die diensten vindt een veilige overdracht plaats, plus logging wat sterk bewijs levert van aflevering. Ook daar is het zo dat als je het bericht binnen hebt, het jouw verantwoordelijkheid wordt om de informatie te beveiligen. Maar dat is an sich te weinig om te spreken van geen toegevoegde waarde. De meerwaarde is de duidelijk zichtbare veiligheid en die logging.
Ah OK, ik dacht inderdaad alleen aan de versleuteling-functie van die tools.
Bij mail is het zo dat de versleuteling afhankelijk is van de ontvanger (lees: ontvangende mailserver). Kan de ontvangende mailserver TLS 1.3 praten, dan is dat helemaal top. Wanneer instellingen fout staan of de ontvangende mailserver kan niet overweg met TLS dan wordt op een onveilige wijze verzonden. Als verzender heb je hier dus feitelijk geen invloed op en daarom zijn er oplossingen als Secumailer. Die checken voor verzending of de ontvangende mailserver wel veilig praat.
Is het voor de verzender dan voldoende om te versturen met TLS zonder te weten dat de ontvangende partij ook wel TLS accepteert? Want als de ontvangstserver geen TLS gebruikt, worden de berichten wel bezorgd, maar is de verbinding niet veilig.
Dat komt neer op de vraag op welk punt de verantwoordelijkheid van de verzender eindigt. Ik zou zeggen dat die eindigt bij de laatste mailserver waar de verzender nog voor kiest. Als vanaf die server er geen beveiligde verbinding opgezet kan worden met de ontvanger, dan zou de verzender de verzending moeten weigeren. Het enige alternatief is zeggen “nou ja, de ontvanger kiest zelf voor nul beveiliging, dan moet het maar zo”.
Vergelijk een postpakket sturen dat op verzoek ontvanger onder de struik rechts van de voordeur geplaatst moet worden. Is niet veilig, maar wel op zijn verzoek.
De verzender kan de mailserver zo configureren dat TLS gebruikt moet worden. Ik vermoed dat er maar weinig mailservers op VerzendenMetTLS=moet ingesteld zijn, waarschijnlijk staan de meeste server op VerzendenMetTls=indienMogelijk.
Dit geldt m.m. evenzo voor de ontvangende mailserver.
Je hebt als verzendende partij dus wel degelijk controle over het al dan niet gebruiken van TLS (in een voldoende veilige moderne versie). Rest natuurlijk de praktische vraag wat te doen als de ontvangende mailserver geen TLS of een onveilige versie van TLS wil gebruiken.
Ik heb meegemaakt dat een (auto) verzekeraar mij emails ging versturen met een verwijzing naar een online mailbox waar ik dan weer moest inloggen. Kortom, in plaats van dat ik informatie in mijn eigen mailbox kreeg gingen alle emails nu naar een “beveiligde” website die ik van hen sindsdien moest gebruiken…
Okay, ben direct naar een andere verzekeraar opgestapt omdat ik mij daar niet prettig bij voel. Gevoelige data binnen de AVG die op hun site wordt bewaard en die dus gehackt kan worden zodat iedereen mijn gegevens kan inzien? Nee, bedankt! Mijn eigen mailbox vind ik veiliger, want dan kan ik emails verwijderen en opslaan op mijn systeem…
Maar mag een bedrijf wel een online webmail-account opdringen? Dat ik alleen berichten kan inzien op een specifieke website en niet meer per email?
Daar zijn geen regels voor, ben ik bang. Het idee dat bedrijven eigen communicatiekanalen hebben is vrij recent, de wet komt nog uit de tijd dat je natúúrlijk de post gebruikte, of heel misschien een koerier.
Je komt dan bij de redelijkheid en de gewoonte uit: hoe gaat dit normaal, wat is een beetje wat we willen als land. Veel mensen hebben er een hekel aan maar echt een tegenargument is er nooit gevonden. Enkel ergernis is geen juridisch relevante grond. Een bedrijf zal zeggen dat hun platform ook veilig is, en wijzen op een ISO 27001 certificering. Nu moet jij een deskundige vinden (want jouw mening als eiser in de procedure telt niet) die wil verklaren dat het platform niet veilig genoemd kan worden ondanks die certificering. Ik denk niet dat dat gaat werken.
Er was in dit geval meer aan de hand dan alleen een spontane wijziging waarbij ik opeens via deze “beveiligde website” mijn berichten kon inzien. Voorheen ging dat gewoon per post of email. Zo was mijn login account om mijn gegevens in te zien ook “spontaan” verdwenen en moest ik via deze berichtenbox een nieuw account aanmaken. En, komischer, mijn wachtwoord voor deze berichtenbox was ook nog eens ongeldig toen ik de volgende dag wilde inloggen en “wachtwoord vergeten” stuurde vervolgens een email naar mijn berichtenbox… Waar ik dus niet in kom… :O
Kortom, deze berichtenbox zit vol fouten en problemen dus ik heb mijn verzekering maar direct omgezet naar de ANWB. Die hebben de boel beter op orde… 🙂
Is het feit dat de opvrager een email adres heeft dat bij de verzender bekend is wel voldoende grond om te kunnen concluderen dat de ontvanger deze email dienst ook als veilig medium beschouwt? Heeft de ontvanger geen enkele inspraak hierin?
Verder is in het email protocol directe aflevering van de email op de mail server van de ontvanger niet gegarandeerd. Er kunnen nog diverse andere mail servers zitten tussen verzender en ontvanger. Verzender en ontvanger zouden TLS kunnen afdwingen en daarmee in-transit versleuteling bij de laatste hops verzekeren. Maar ze hebben geen invloed op de tussenliggende server en of deze ook TLS afdwingen. En de betreffende tussenliggende servers kunnen ook meekijken.
Ook zijn de meeste mensen niet in staat een eigen mail server te beheren, en zo zelf volledige controle te houden. Dit in tegenstelling tot het beheren van een brievenbus voor de fysieke post, hetgeen je van mensen denk ik wel mag verwachten.
Niet voor niets zijn er mail content versleuteling methoden zoals PGP/GPG bedacht, hoewel deze jammer genoeg vaak nog veel te ingewikkeld in gebruik zijn voor de meeste mensen.
Het is de eerste keer dat bij mijn weten iemand serieus stelt dat e-mail voldoet aan de AVG beveiliging. Het is volgens mij quasi onmogelijk om generiek e-mail verkeer te beveiligen.
a) De verzender moet kunnen aantonen dat de e-mail beveiligd is tot de isp (of e-mail provider) van de ontvanger. b) De ontvanger zou van zijn isp (of e-mail provider) de verzekering moeten kunnen krijgen dat de ontvangen e-mail adequaat beveiligd is.
Arnoud: Stel de vraag anders eens aan je ISP die voor jou de e-mail verzending afhandeld! Idem voor diegene die je privé e-mail ontvangst verzorgd.
Ik ben benieuwd naar het antwoord.
Voor e-mails binnen een organisatie die zijn eigen mailserver beheert is er een behoorlijke inschatting van de beveiliging te maken. Deze is direct gerelateerd aan het algemene computerbeveiligingsniveau binnen de betreffende organisatie.
Wanneer je gebruik maakt van externe mail providers krijg je te maken met “store and forward” mechanismen en wordt een (tijdelijke) kopie van het bericht gemaakt. Over het algemeen worden deze kopieën niet ingezien door de medewerkers van een ISP of andere derden (politie), maar harde garanties zijn er niet. (Mijn indruk is dat de Nederlandse ISP’s de privacy respecteren.)
Volgens mij betekent dit dat een organisatie de resultaten van een inzageverzoek alleen naar het e-mailadres van de opvrager mag sturen als de opvrager daar expliciet toestemming voor gegeven heeft. Zo niet dan is er sprake van een potentieel datalek.
@Alain “E-mail beveiligen” is volgens mij als zodanig een te generieke frase. Waartegen? Tegen in-transit afluisteren zijn prima oplossingen. Het hacken van mailboxen is ook goed te beveiligen. Voorkomen dat de afzender de verkeerde persoon mailt of de verkeerde bijlage stuurt, dat is veel en veel moeilijker. Dus welk scenario heb jij voor ogen als je zegt dat e-mail niet voldoet aan de AVG?
a) Ik zou zeggen dat als een mail via TLS is overgedragen naar een server van de ontvanger, dat er dan adequaat tegen in-transit afluisteren is beveiligd. Authenticatie tegen een nepserver is lastiger maar niet ondoenlijk (DNSSEC bij de ontvanger helpt).
b) Dat staat in de verwerkersovereenkomst, dat de ontvanger het ook adequaat zal beveiligen. Welk niveau van assurance zou jij willen en hoe regelen we dat?
Arnoud
a) De “in transit” TLS beveiliging is het eenvoudigste. Da’s wiskunde. Als daar een recente veel gebruikte code basis voor gebruikt wordt, kan dat in orde zijn. a2) DNS da’s een moeilijkere en ondoenlijk voor een “algemeen” e-mail verzend programma. Er zullen dan immers een aantal e-mail ontvangers als “verdacht” aangeduid worden of meer tijd nodig hebben voor automatische controles. Je wilt echter niet dat 1% van je e-mails niet vertrekt of slechts na >24u. Het e-mail verzend programma mag ook zelf geen andere “relays” gebruiken of moet daar dezelfde eisen aan hebben. De verzender moet bv. zeker zijn dat mx.transip.com en zijn gevonden ip-adres wel degelijk voor iusmentis.com te gebruiken is. Denk dan maar aan een recente wijziging of onderhoud bij één van de partijen. Het wordt helemaal moeilijk te garanderen als de ontvanger verschillende ontvangstservers gebruikt afhankelijk van locatie en bezetting. –> vraag de schriftelijke garantie aan je mail provider.
b) Ik zou er ook nooit vanuit gaan dat een ontvanger waar je “toevallig” een e-mail adres van hebt, dit beschouwd als voldoende beveiligd. Als iemand dat expliciet bevestigd, is het een ander verhaal. Ook hier twijfel ik of er veel organisaties die keten en technisch en juridisch op orde hebben. Denk ook hier weer aan al dan niet gepland onderhoud aan de standaard ontvangst servers. Daarom ook, vraag het eens aan transip.
De problemen die je schetst zijn toch precies waar DNSSEC voor zijn? Ik snap de behoefte aan snelheid, maar zeker weten dat je naar de goede partij (mailserver) mailt lijkt me minstens zo belangrijk. Ik zie die afweging dus anders.
Wat voor garantie zou je willen dat ik vraag? Ik begrijp het gewoon niet. En wat voegt een door een jurist geformuleerde volzin toe aan de feitelijke situatie?
Arnoud
Het is niet belangrijk welke afweging dat jij maakt, maar welke je serviceprovider maakt. Heb je al ooit een melding terug gehad dat de technische gegevens van de bestemmeling niet te bevestigen was? Het zou me verwonderen.
Mij gaat het niet over een juridisch papiertje, maar of je serviceprovider daar überhaupt een garantie op geeft. Mondeling waarschijnlijk wel “uiteraard”, een deftige schriftelijke garantie ga je volgens mij niet krijgen. Vroeger was ik er wat meer mee bezig, maar ik zie het niet haalbaar.
Sorry, ik begrijp je punt nog steeds niet en ik proef een badinerende ondertoon. Ik laat het dus even hierbij.
Arnoud
Als een partij het aanbied : https://secumailer.nl/zo-werkt-secumailer/ en openlijk stelt dat het hun in 2% van de e-mails niet lukt via normale e-mail, kan je je een idee vormen van de problemen. Let op: Ik ga er vanuit dat ze enkel garanties geven voor de verzendende kant, het zal niet beter zijn aan de kant van de ontvanger.
Het mantra “mail is onveilig” kennen we allemaal en wordt vooral ook graag geroepen door security officers. Ik vraag me echter wel af inderdaad hoe relevant dat nog is in 2023. Veel van de dingen die mail onveilig maakten:
- Mail werd van de ene naar de andere naar de derde server naar de eindbestemming gestuurd
- Er was geen authenticatie op afzenderserver of afzenderadres
- Mails zijn in transit versleuteld
Al grotendeels niet meer relevant. Mail wordt tegenwoordig altijd van verzender naar ontvanger afgeleverd zonder relays, iedereen gebruikt SPF en DKIM omdat anders je mail niet goed binnenkomt bij de grote mailpartijen, en als in-transitversleuteling niet werkt dan is dat met name waarschijnlijk omdat de ontvanger het niet aanbiedt, keuze ontvanger dus, en trouwens wie kan er nou redelijkerwijs internetverkeer aftappen tussen een gegeven verzender en ontvanger?De kans dat zo’n custom “mijn (zorgverzekeraar|telco|sportfondsenbad) omgeving” waarop je moet inloggen om iets te lezen gehackt wordt lijkt mij echt vele malen groter dan dat iemand in transit mails kan afluisteren, mail onbedoelt herrouteert, of gmail compromised heeft.
Natuurlijk kunnen er best nog een paar partijen iets aanscherpen qua dnssec of dmarc ondersteuning, maar volgens mij hebben we het punt wel bereikt waarbij mailen echt niet meer categorisch en onvoorwaardelijk als onveilig beschouwd hoeft te worden.
Thijs, ik ben het redelijk met je eens. Het probleem dat ik nog zie is dat de gemiddelde consument voor email gebruik maakt van de diensten van zijn ISP. De berichten worden op de server van de ISP opgeslagen en systeembeheerders hebben in principe toegang tot deze berichten. Het hangt dan van de contractuele garanties die de ISP aan de consument geeft af of de privacy bij betreffende ISP voldoende gewaarborgd is. (De ISP bepaalt ook of TLS aangeboden wordt.)
Dus ja, ik zou niet in algemene zin kunnen zeggen dat email voldoende veilig is of niet. Het hangt af van de betrouwbaarheid van de door de consument ingeschakelde hulppersoon.
Mee eens. In de praktijk zitten de risico’s meer bij het generieke karakter: een foute bijlage of een verkeerde ontvanger is zo aangeklikt. Binnen een werkprocessysteem is dat veel lastiger, als je in dossier A zit dan kun je geen gegevens doorsturen naar een klant van B, die staat niet in de lijst. Dus in zoverre blijft e-mail wel een onverstandige keuze voor werkprocessen. Maar als je het gebruikt als transportsysteem naar een derde en je hebt eigen controles op wat je verstuurt en naar wie, dan zie ik het probleem niet.
Een andere vraag:
Heb ik als ontvanger van e-mail dan nog het recht om dat als niet AVG-proof te zien of is dat wel mijn verantwoordelijkheid als de verzender dat zonder verwittiging, wel zou veronderstellen. Ik ga er vanuit dat dit nu niet het geval is.
Ik zie een analogie : Onze brievenbus is afgesloten en beveiligd. De drempel aan onze voordeur niet, hij is echter wel gelegen op ons eigendom… De eerste is voor mij AVG-proof, de 2de niet. Is het conform de AVG voldoende voor de verzender om dat op de drempel aan de deur te leggen. Hetzelfde kan je trouwens stellen voor de inrit van een zorginstelling.
Of theoretisch: Mag een verzender veronderstellen dat alles wat onder de bevoegdheid van de ontvanger valt, voldoende is om persoonsgegevens te bezorgen?
–> Dat is uiteraard een fundamentele vraag.