Kan een handtekeningtool je e-mails lezen? Het technische antwoord

Het is de eerste vraag in een securityreview, en een terechte: heeft een tool die ingrijpt op je e-mails toegang tot de inhoud ervan? Het antwoord hangt volledig af van de gekozen architectuur, en de drie architecturen op de markt hebben niet dezelfde reikwijdte.

Architectuur 1 — De invoegtoepassing aan de clientzijde

De invoegtoepassing (add-in) draait in de e-mailclient, op het moment dat de gebruiker zijn bericht schrijft. Ze voegt een HTML-blok in de tekst van het bericht in.

De reikwijdte van de toegang komt overeen met de machtigingen in het manifest van de invoegtoepassing: schrijven in het item dat wordt opgesteld, en lezen van de directorykenmerken die nodig zijn om de velden in te vullen.

Daaruit volgen twee eigenschappen, en die tellen in een securityreview:

Het bericht loopt niet via de leverancier. De invoeging gebeurt op de computer, in het opstelvenster. Daarna gaat het bericht vanuit je Microsoft- of Google-tenant naar de ontvanger, via je gebruikelijke routering, zonder omweg.

De mailbox wordt niet gelezen. De invoegtoepassing werkt op een bericht dat wordt opgesteld, niet op het Postvak IN, de geschiedenis of de archieven.

Dat is de architectuur van Signally, beschreven op de pagina Microsoft 365-invoegtoepassing.

Architectuur 2 — De transportregel

De handtekening wordt tijdens de aflevering toegevoegd door je eigen mailserver — Exchange Online, of de compliancedienst van Google Workspace.

Hier komt de leverancier helemaal niet aan de verwerking van het bericht: hij levert de inhoud van de voettekst, je server past die toe. Geen toegang, geen doorvoer.

Daar staat tegenover dat deze architectuur belangrijke functionele beperkingen heeft — de afzender ziet zijn handtekening nooit, conversaties stapelen de blokken op, versleutelde berichten ontsnappen eraan — die we uitwerken in invoegtoepassing of transportregel.

Architectuur 3 — De SMTP-relay

Deze vraagt om een zorgvuldig onderzoek. Het bericht verlaat je server, loopt via de infrastructuur van de leverancier die de handtekening toevoegt, en gaat dan door naar de ontvanger.

Deze architectuur betekent per definitie dat de volledige inhoud van je berichten via een derde loopt — tekst, bijlagen, ontvangers. Ze vraagt ook een aanpassing van je uitgaande routering, met de bijbehorende gevolgen voor de afleverbaarheid en voor je SPF- en DKIM-configuratie.

Ze is op zich niet onrechtmatig, en sommige leveranciers implementeren haar serieus. Maar ze verandert de aard van de vraag aan je securityofficer: het gaat er niet meer om een component toe te staan, maar om een derde partij in je afleverketen op te nemen.

Controleren in plaats van geloven

Drie concrete controles die niet op het woord van de leverancier steunen.

Het toestemmingsscherm. Bij het koppelen van de tenant toont je identiteitsprovider — Microsoft Entra ID of Google — de exacte lijst met gevraagde machtigingen. Die lijst komt van Microsoft of Google, niet van de leverancier. Het is het meest directe bewijs van de reikwijdte.

De API-documentatie. De gevraagde machtigingen komen overeen met scopes die Microsoft en Google publiek documenteren. Je kunt nagaan wat elk ervan omvat.

De routeringsconfiguratie. Vraagt de installatie om je connectors, je MX-records of je SPF aan te passen, dan zit je in een relay-architectuur. Raakt ze niets van de routering aan, dan niet.

Goed om te weten: laat het toestemmingsscherm tijdens de installatie vastleggen in een screenshot en voeg dat toe aan het securitydossier. Het is een gedateerd bewijsstuk dat meer waard is dan een commerciële toezegging.

De reikwijdte van het restrisico

Geen enkele tool heeft een risico van nul, en het is eerlijker het risico af te bakenen dan het te ontkennen.

Bij een invoegtoepassing krijgt een aanvaller bij een compromittering van de leverancier de opgeslagen gegevens: de gesynchroniseerde directory — namen, functies, zakelijke telefoonnummers — en de sjablonen. Niet de inhoud van berichten, die nooit toegankelijk was.

Dat is een verschil in aard, niet in gradatie. Een uitgelekte zakelijke directory is een ernstig incident; de e-mailgeschiedenis van een organisatie is iets heel anders.

De locatie en de jurisdictie die voor die opgeslagen gegevens gelden, vormen het andere deel van het dossier, behandeld in datasoevereiniteit.

De samenvatting voor je securityofficer

Vier regels volstaan voor de invoegtoepassingsarchitectuur:

• De handtekening wordt tijdens het schrijven ingevoegd, aan de clientzijde, in het bericht dat wordt opgesteld.
• Geen enkele e-mailinhoud wordt gelezen, geanalyseerd of opgeslagen, of loopt via de leverancier.
• De enige gesynchroniseerde gegevens zijn de directorykenmerken die in de handtekening staan.
• Geen aanpassing van de uitgaande routering: geen connector, geen relay, geen SPF-wijziging.

Deze punten en de details van wat Signally niet doet, staan op onze pagina beveiliging en AVG, gemaakt om zo aan een IT-afdeling te worden doorgestuurd.