E-mailfiltering over een VPN: waar inhoudsregels echt draaien

Dit verzoek klinkt als een netwerkprobleem: voorkom dat een bepaald soort bijlage het gebouw verlaat, en de VPN is er al, dus gebruik die. Dat kader breekt bij de eerste vraag die het filter moet beantwoorden. Inhoudsregels moeten het bericht kunnen zien, en het bericht wordt zichtbaar op een andere laag dan de tunnel. Ik loop het mailpad naar buiten vanaf het pakket en stop bij de eerste plek waar de vereiste gegevens echt bestaan.

Drie lagen zijn onafhankelijk: het VPN-transport, de SMTP TLS-verbinding en de versleuteling van het bericht zelf. Elk eindigt ergens anders.

Begin bij de laag die het bericht kan zien

VPN-decapsulatie geeft je het interne netwerkverkeer. Als de mailclient een TLS-verbinding naar een inzendserver heeft geopend, bevat het interne verkeer nog steeds die TLS-stroom, geen leesbare mail.

Een pakketopname aan de tunnelrand beantwoordt dus een andere vraag dan „bevat dit bericht een verboden bijlage“.

SMTP TLS-terminatie eindigt bij de envelop

SMTP TLS beëindigen op de mailserver legt het bericht bloot zoals het bij dat eindpunt is ingediend. De server ziet headers, de envelop en de MIME-structuur. Dat is genoeg voor veel inhoudsregels. De envelop vertelt je de afzender en ontvangers zoals de server ze begreep.

Dat is niet genoeg voor een met S/MIME beveiligd bericht. De server ontvangt een beveiligde entiteit en kan zonder de juiste sleutels de inhoud erbinnen niet lezen. Dezelfde grens geldt voor een versleutelde bijlage die intact aankomt.

Verzwak de transportbeveiliging niet om een passieve opname leesbaar te maken. Dat verandert de architectuur in plaats van de regel te plaatsen waar de gegevens zijn.

S/MIME eindigt waar de sleutels zijn

S/MIME beschermt MIME-berichtgegevens, dus de grens is het sleutelmateriaal en de geautoriseerde ontsleuteling. Een filter zonder die sleutels kan nog steeds werken op zichtbare metadata of op de aanwezigheid van een beveiligd object, maar dat is een ander resultaat.

Als de organisatie een geautoriseerde versleutelingsgateway of een beheerde eindpuntcontrole draait, documenteer dan waar platte tekst bestaat, welke identiteit die mag inspecteren en hoe sleutels en registraties worden beschermd. Er is geen hoofdsleutel die ontstaat door verkeer via een VPN te routeren.

Schrijf dat op voordat iemand klare-tekstclassificatie belooft. De belofte is het deel dat moeilijk terug te draaien is.

Zet de regel in het mailplatform

Als de goedgekeurde mailserver het leesbare bericht ontvangt, is de ondersteunde inhoudsfilterintegratie het handhavingspunt. Dat is iets anders dan een SMTP-verbinding door een firewall toestaan. Dat onderscheid bepaalt of de regel kan weigeren, in quarantaine kan plaatsen of alleen kan annoteren.

Postfix documenteert bijvoorbeeld inhoudsfiltering na de wachtrij: mail wordt in de wachtrij geplaatst, aan een filter doorgegeven en teruggezet naar het afleverpad. De ordening na de wachtrij verschilt van de proxy-opties vóór de wachtrij en Milter waarnaar dezelfde gids verwijst. Kies de ondersteunde integratie en het faalgedrag voor de maildienst die je echt draait.

Eén bijlageregel is geen volledig programma tegen gegevensverlies. Browseruploads, gedeelde opslag en eindpunthandelingen hebben hun eigen controles nodig.

Schrijf de acceptatietest met synthetische berichten

Test met goedgekeurde synthetische voorbeelden: een toegestaan bericht, een verboden inhoudshandeling en de verklaarde omgang met versleuteling op berichtniveau. Neem op wat de maildienst doet wanneer het filter niet beschikbaar is.

Het bruikbare resultaat benoemt de handeling, het handhavingspunt en de gegevens die daar zichtbaar zijn. „De VPN heeft het ontsleuteld“ beantwoordt één laag en kan het inhouds- en autorisatiemodel van de mailapplicatie niet vervangen.