Iedereen praat over datasoevereiniteit. Maar waarom begint niemand bij het laaghangend fruit?
Datasoevereiniteit is hot. De nieuwsbladen en LinkedIn staan er vol mee, overheidsbeleid verwijst ernaar, conferenties hebben het als hoofdonderwerp, en CISO’s gebruiken het steeds vaker als strategisch uitgangspunt. Terecht. Organisaties willen en móéten absolute zeggenschap houden over hun vertrouwelijke informatie. Niet alleen vanwege de Cloud Act, maar ook vanwege NIS2, DORA en de snel toenemende dreiging van digitale spionage en sabotage.
Daarom lanceerde Zivver samen met Kiteworks recent het Private Data Network (PDN): een volledig soevereine, veilige én werkbare oplossing voor communicatie en gegevensuitwisseling. Van collaboration (als aanvulling op of alternatief voor bijvoorbeeld SharePoint), tot e-mail, MFT en webformulieren, alles onder controle van de organisatie, ook on-premise of in een private cloud.
Tegelijkertijd zien we een ongemakkelijke paradox: iedereen praat over datasoevereiniteit, maar vrijwel geen enkele organisatie heeft de basis nog op orde.
In deze blog:
-
Leggen we uit waarom emailbeveiliging belangrijk is voor datasoevereiniteit is;
-
Waarom TLS (zoals STARTTLS) onvoldoende bescherming biedt;
-
Wat DANE en MTA-STS wél oplossen – en waarom ze zelden goed worden toegepast;
-
Hoe Microsoft en Google hiermee omgaan;
-
Waarom fallback en afdwinging cruciaal zijn voor werkbare e-mailbeveiliging;
-
En hoe Zivver veilige communicatie met fallback mogelijk maakt.
Echte datasoevereiniteit begint met veilige e-mail – en daar wringt het vaak
Mijn inschatting: minder dan 1% van de organisaties heeft zijn e-mailbeveiliging geregeld volgens de standaarden die het Forum Standaardisatie al jaren aanbeveelt. En dat terwijl e-mail en file transfer juist de belangrijkste kanalen zijn waarmee dagelijks gevoelige informatie wordt gedeeld: juridische documenten, medische gegevens, HR-dossiers, financiële rapportages, klantinformatie, IE, etc.. Dit soort gegevens worden voornamelijk gedeeld via e-mailbijlagen en bestandslinks. Uit recent onderzoek blijkt dat nog steeds voor ruim 90% van de medewerkers e-mail (erg) belangrijk is voor hun dagelijkse werkzaamheden.
Toch is bij het overgrote deel van de organisaties de e-mailbeveiliging niet op orde. De reden? Onwetendheid, onderschatting van de risico’s, of het idee dat het ‘te veel gedoe’ is.
Wat zijn de gevolgen? Gevoelige e-mails kunnen ongemerkt worden onderschept, omgeleid of door buitenlandse partijen meegelezen worden – zónder dat de verzender of ontvanger dit weet. Denk aan strategische overheidsinformatie, patiëntgegevens of bedrijfsgeheimen die via onveilige routes bij de verkeerde partij terechtkomen. Dat is geen toekomstscenario, maar een concreet risico dat dagelijks bestaat zolang veilige e-mailstandaarden niet zijn afgedwongen.
En dát staat haaks op het idee van digitale soevereiniteit. Je kunt niet spreken van controle over je eigen data, als je de infrastructuur die je dagelijks gebruikt om die data te delen – namelijk e-mail – niet eens beschermt tegen de meest basale vormen van interceptie. Soevereiniteit betekent immers: zelf bepalen wie er bij je data kan. Als dat bij e-mail niet gegarandeerd is, is het hele soevereiniteitsverhaal niets meer dan een façade.
Dan vraag ik me af: is de soevereiniteitsbeweging bij veel organisaties niet vooral een kwestie van meedoen en mooi weer spelen, in plaats van écht stappen zetten? Als je het echt meent, begin je bij de basis.
Wat is TLS-versleuteling – en waarom is het onvoldoende voor vertrouwelijke e-mails?
Vrijwel alle organisaties vertrouwen bij e-mail op opportunistische TLS, STARTTLS geheten, om e-mail te versleutelen. TLS (Transport Layer Security) is een protocol dat zorgt voor versleutelde communicatie tussen twee servers, zoals bij het verzenden van e-mail. Daarmee denken ze dat de beveiliging geregeld is. Maar STARTTLS heeft fundamentele gebreken:
-
Geen zekerheid over gebruik: als de ontvangende server geen TLS ondersteunt, valt de verbinding automatisch terug op onversleuteld verzenden. De vraag of TLS beschikbaar is, wordt bovendien onversleuteld verstuurd, waardoor een aanvaller eenvoudig kan doen alsof TLS niet ondersteund wordt (downgrade attack).
-
Geen zekerheid over de ontvangende server: STARTTLS biedt geen authenticatie van de ontvangende server. Je weet dus niet zeker of je met de juiste partij communiceert. Hierdoor zijn man-in-the-middle-aanvallen een reëel en ernstig risico.
Zoals het NCSC al jaren waarschuwt: “Een actieve aanvaller kan het gebruik van STARTTLS eenvoudig ongedaan maken.” Je denkt dus veilig te zijn, maar in werkelijkheid is je gevoelige communicatie makkelijk te onderscheppen. Juist door de actoren waar je je met soevereiniteit tegen probeert te beschermen.
Waarom TLS bij Microsoft en Google tekortschiet
Recent onderzoek toont aan dat Microsoft 365 en Google Workspace geen gegarandeerde veilige e-maillevering bieden—zelfs niet als "force TLS" is ingeschakeld. Google verstuurt e-mails nog steeds via verouderde en kwetsbare TLS 1.0/1.1-protocollen, terwijl Microsoft 365 berichten volledig onbeveiligd (in plain text) verzendt als veilige TLS-verbinding niet mogelijk is. Deze onveilige fallbacks gebeuren stilletjes, waardoor gevoelige gegevens zonder waarschuwing of logging worden blootgesteld—en organisaties onterecht denken dat hun e-mail wel veilig is.
DANE en MTA-STS lossen de kwetsbaarheden van TLS op – maar weinig organisaties passen ze goed toe
Gelukkig zijn er standaarden die dit probleem wél oplossen:
-
DANE (DNS-based Authentication of Named Entities) koppelt certificaten van mailservers aan DNS-records die met DNSSEC zijn ondertekend. Zo weet je zeker dat je met de juiste server communiceert én dat TLS wordt afgedwongen.
-
MTA-STS (Mail Transfer Agent Strict Transport Security) doet iets vergelijkbaars via HTTPS-policies. Het valideert TLS zonder afhankelijk te zijn van DNSSEC.
DANE wordt door zowel het Forum Standaardisatie, alsmede door de Europese Commissie sterk aanbevolen als standaard voor de beveiliging van e-mail op transportniveau.
MTA-STS wordt in de praktijk als minder veilig én lastiger te beheren gezien dan DANE. Het vereist namelijk een aparte HTTPS-infrastructuur en het handmatig onderhouden van policy-bestanden, inclusief geldigheidstermijnen. Dat maakt het beheer foutgevoeliger en minder robuust, zeker voor organisaties zonder goed uitgeruste IT-teams.
Beide standaarden maken mailrouting tussen servers daadwerkelijk veilig. Maar toch worden ze nauwelijks toegepast - of niet op de juiste manier, waardoor ze hun doel missen.
Microsoft ondersteunt sinds 2024 inkomende DANE – maar afdwingen bij verzenden in M365 is nog altijd onmogelijk
Microsoft en Google ondersteunen MTA-STS al een paar jaar. Sinds oktober 2024 ondersteunt Microsoft ook DANE voor inkomende e-mail; een belangrijke stap, met daarin een belangrijke rol weggelegd voor de Nederlandse overheid. Zie dit artikel.
Toch is de adoptie bedroevend laag: minder dan 30% van de domeinen in Nederland ondersteunt DANE, en zelfs minder dan 1% van de domeinen ondersteunt MTA-STS.
Bovendien kun je deze standaarden niet afdwingen in Microsoft 365 of Google Workspace en voor zover bekend, staat dat ook niet op de roadmap van deze techgiganten. Je kunt dus hoogstens controleren of DANE/MTA-STS aanwezig is, maar niet vereisen dat het wordt toegepast. En zelfs stel dat je het wel zou kunnen afdwingen, dan blijft het probleem bestaan: er is geen fallback mechanisme als de juiste protocollen niet worden ondersteund door de ontvangende partij.
Zonder fallback geen veilige communicatie – en geen werkbare e-mailworkflow
Als je DANE of MTA-STS toch weet af te dwingen en de ontvanger ondersteunt het niet, dan wordt je e-mail simpelweg niet bezorgd. De verzender krijgt een bounce (een zogenaamd NDR: Non-Delivery Report). En wat gebeurt er dan?
-
Moet de medewerker zelf een alternatieve verzendmethode zoeken.
-
Weet de medewerker vaak niet wat hij of zij dan moet doen.
-
Wordt de inhoud van die e-mail vaak alsnog verzonden via onveilige of ongecontroleerde routes.
Met andere woorden: de workflow loopt volledig vast. Zeker voor ambtenaren, zorgprofessionals, juristen, of HR-medewerkers die op dat moment gewoon "even iets vertrouwelijks" willen mailen, is het ontbreken van een fallback een showstopper. Het wordt praktisch onmogelijk om nog verantwoord en veilig te communiceren. En dus durven organisaties de standaard niet af te dwingen, zelfs al willen ze dat uit principe wel.
In Microsoft 365 zou dit - indien afdwingbaar - leiden tot zo’n 70% gebouncete berichten, bij Google zelfs tot 99%. Dit is onwerkbaar. En dat is precies waarom zelfs goed geïnformeerde organisaties die de risico’s volledig begrijpen, deze standaarden niet strikt toepassen.
Het toepassen van veilige e-mailstandaarden kán eenvoudig met de juiste infrastructuur
Als je met een goede aanvullende oplossing voor Veilig Mailen werkt, kan het afdwingen van standaarden zoals DANE en MTA-STS snel geregeld zijn. Zo bieden wij als Zivver, dankzij een eigen infrastructuur op basis van Exim en Postfix, volledige ondersteuning voor het afdwingen van dit soort standaarden als aanvulling op M365, Exchange, Google, etc. Onze infrastructuur controleert actief op veilige routes en stelt organisaties in staat om deze standaarden daadwerkelijk af te dwingen, inclusief fallback naar alternatieve veilige aflevermethoden, zoals een beveiligde portal, zodat medewerkers ongestoord kunnen blijven werken zoals ze gewend waren.
Technisch is het vaak in een paar uur geregeld. En toch… ook bij ons kiest slechts een handjevol organisaties ervoor om het daadwerkelijk af te dwingen.
Waarom? Omdat het onderwerp vaak als complex wordt gezien, zowel om intern te begrijpen als extern uit te leggen. Terwijl het in de praktijk juist goed te onderbouwen is: als organisatie hechten we waarde aan datasoevereiniteit, en daarom volgen we de erkende beveiligingsstandaarden. Houdt een ontvanger zich daar niet aan, dan vormt dat een risico voor zowel onze als hun eigen soevereiniteit. In dat geval is het logisch dat de verantwoordelijkheid bij de ontvanger ligt om zich aan te passen, niet bij ons als verzender.
Schijnveiligheid in e-mail: veel organisaties denken veilig te mailen, maar doen dit niet
Sommige organisaties, leveranciers of partners claimen dat zij, of hun klanten, e-mail wel ‘veilig’ verzenden via DANE of MTA-STS. Maar als je doorvraagt, blijkt dat ze:
-
Alleen maar veilige mail gebruiken als een medewerker zelf op de juiste knop drukt, label selecteert, of een triggerwoord invult.
-
En/of opportunistisch DANE of MTA-STS gebruiken, zonder afdwinging.
-
En/of gebruikmaken van aparte 'veilig mailen'-oplossingen die geen eigen mailserver hebben en berichten gewoon versturen via diensten zoals Amazon SES - een platform dat geen DANE of MTA-STS ondersteunt, en waarbij berichten vaak volledig leesbaar via Amerikaanse managed diensten verlopen.
Dat vergroot het risico op interceptie juist, en ondermijnt de hele gedachte achter datasoevereiniteit. Het is schijnveiligheid.
Datasoevereiniteit begint bij e-mailbeveiliging en niet bij dure prestigeprojecten
Wat wringt, is dit: organisaties praten enthousiast over datasoevereiniteit. Over Europese clouds, eigen datacenters, juridische controle en geopolitieke onafhankelijkheid. Allemaal belangrijk en begrijpelijk, maar als het fundament van veilige communicatie ontbreekt, blijft het symboolpolitiek.
Het afdwingen van DANE of MTA-STS is het laaghangend fruit. De investering is laag. De technische drempel is beperkt. En de impact op soevereine communicatie is groot.
Conclusie: datasoeverein werken begint met e-mailbeveiliging volgens standaarden zoals DANE
Iedereen praat over datasoevereiniteit. Maar als je het écht meent en wilt, begin dan niet met prestigeprojecten. Begin met het afdwingen van veilige e-mail. Begin met DANE.
Meen jij dat jouw organisatie dit al goed geregeld heeft? Laat het me weten. Hopelijk om te leren hoe het jou wél gelukt is, zodat anderen daarvan kunnen profiteren. Of om samen te ontdekken hoe de basis toch nog verbeterd kan worden.
Wil je weten hoe jouw organisatie e-mailbeveiliging met DANE en fallback vandaag nog kan realiseren, en tegelijkertijd voldoen aan NIS2 en andere compliance-eisen? Neem dan contact met ons op voor een demo of adviesgesprek.
