E-postfiltrering via en VPN: hvor innholdsreglene virkelig kjører

Denne forespørselen lyder som et nettverksproblem: forhindre at en bestemt type vedlegg forlater bygningen, og VPN-en finnes allerede, så bruk den. Det rammeverket faller ved det første spørsmålet filteret må besvare. Innholdsregler trenger å se meldingen, og meldingen blir synlig på et annet nivå enn tunnelen. Jeg følger mailveien utover fra pakken og stopper ved det første stedet der de nødvendige dataene virkelig finnes.

Tre nivåer er uavhengige: VPN-transporten, SMTP TLS-forbindelsen og meldingens egen kryptering. Hvert av dem slutter et annet sted.

Start på nivået som kan se meldingen

VPN-avkapsling gir deg den indre nettverkstrafikken. Hvis mailklienten åpnet en TLS-forbindelse til en innsendingsserver, inneholder den indre trafikken fortsatt den TLS-strømmen, ikke lesbar e-post.

Derfor besvarer et pakkeopptak ved tunnelkanten et annet spørsmål enn «inneholder denne meldingen en forbudt vedlegg».

SMTP TLS-avslutning slutter ved konvolutten

Avslutter man SMTP TLS på mailserveren, ligger meldingen åpen slik den ble sendt inn til det endepunktet. Serveren ser headere, konvolutten og MIME-strukturen. Det holder for mange innholdsregler. Konvolutten forteller deg avsender og mottakere slik serveren oppfattet dem.

Det holder ikke for en S/MIME-beskyttet melding. Serveren mottar en beskyttet enhet, og uten de aktuelle nøklene kan den ikke lese innholdet inni. Samme grense gjelder for en kryptert vedlegg som ankommer hel.

Ikke svekk transportsikkerheten for å gjøre et passivt opptak lesbart. Det endrer arkitekturen i stedet for å plassere regelen der dataene er.

S/MIME slutter der nøklene er

S/MIME beskytter MIME-meldingsdata, så grensen er nøkkelmaterialet og den autoriserte dekrypteringsordningen. Et filter uten disse nøklene kan fortsatt reagere på synlige metadata eller på at et beskyttet objekt finnes, men det er et annet resultat.

Hvis organisasjonen driver en autorisert krypteringsgateway eller en administrert endepunktskontroll, må du dokumentere hvor klartekst finnes, hvilken identitet som kan inspisere den, og hvordan nøkler og logger beskyttes. Det finnes ingen hovednøkkel som oppstår ved å rute trafikk gjennom en VPN.

Skriv det ned før noen lover klartekstklassifisering. Løftet er den delen som er vanskelig å trekke tilbake.

Plasser regelen i mailplattformen

Hvis den godkjente mailserveren mottar den lesbare meldingen, er den støttede innholdsfiltreringsintegrasjonen håndhevingspunktet. Det er noe annet enn å tillate en SMTP-forbindelse gjennom en brannmur. Forskjellen avgjør om regelen kan avvise, sette i karantene eller bare kommentere.

Postfix dokumenterer for eksempel innholdsfiltrering etter køen: e-post legges i kø, overføres til et filter og returneres til leveringsveien. Oppsettet etter køen er forskjellig fra proxyvalgene før køen og Milter som samme veiledning refererer til. Velg den støttede integrasjonen og feiloppførselen for mailtjenesten du faktisk kjører.

Én vedleggsregel er ikke et fullstendig datatapsprogram. Opplastinger i nettleseren, delt lagring og endepunktshandlinger trenger sine egne kontroller.

Skriv akseptansetesten med syntetiske meldinger

Test med godkjente syntetiske eksempler: en tillatt melding, en forbudt innholdshandling og den erklærte håndteringen av kryptering på meldingsnivå. Ta med hva mailtjenesten gjør når filteret ikke er tilgjengelig.

Det nyttige resultatet navngir handlingen, håndhevingspunktet og dataene som er synlige der. «VPN-en dekrypterte den» svarer på ett nivå og kan ikke erstatte innholds- og autorisasjonsmodellen til mailapplikasjonen.