E-postfiltrering over en VPN: hvor innholdsreglene faktisk kjører

Denne forespørselen høres ut som et nettverksproblem: hindre en bestemt type vedlegg i å forlate bygget, og VPN-en er allerede der, så bruk den. Den rammen bryter sammen ved det første spørsmålet filteret må svare på. Innholdsregler trenger å se meldingen, og meldingen blir synlig på et annet lag enn tunnelen. Jeg går e-postveien utover fra pakken og stopper på det første stedet der de nødvendige dataene faktisk finnes.

Tre lag er uavhengige: VPN-transporten, SMTP TLS-forbindelsen og meldingens egen kryptering. Hver av dem ender et annet sted.

Begynn på laget som kan se meldingen

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

Så et pakkeopptak ved tunnelkanten svarer på et annet spørsmål enn «inneholder denne meldingen et forbudt vedlegg».

SMTP TLS-avslutning ender ved konvolutten

Avslutning av SMTP TLS på e-postserveren avdekker meldingen slik den ble levert til det endepunktet. Serveren ser headere, konvolutten og MIME-strukturen. Det er nok for mange innholdsregler. Konvolutten forteller deg avsender og mottakere slik serveren forsto dem.

Det er ikke nok for en S/MIME-beskyttet melding. Serveren mottar en beskyttet enhet, og uten de relevante nøklene kan den ikke lese innholdet inni. Den samme grensen gjelder for et kryptert vedlegg som ankommer intakt.

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

S/MIME ender 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 handle på synlige metadata eller på tilstedeværelsen av et beskyttet objekt, men det er et annet resultat.

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

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

Sett regelen i e-postplattformen

Hvis den godkjente e-postserveren mottar den lesbare meldingen, er dens støttede innholdsfiltreringsintegrasjon håndhevelsespunktet. Det er noe annet enn å tillate en SMTP-forbindelse gjennom en brannmur. Den forskjellen avgjør om regelen kan avvise, sette i karantene eller bare annotere.

Postfix dokumenterer for eksempel innholdsfiltrering etter køen: e-post legges i kø, sendes til et filter og returneres til leveringsveien. Ordningen etter køen er forskjellig fra proxyvalgene før køen og Milter, som samme veiledning viser til. Velg den støttede integrasjonen og feilatferden for e-posttjenesten du faktisk kjører.

Én vedleggsregel er ikke et fullstendig datatapsprogram. Nettleseropplastinger, 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 e-posttjenesten gjør når filteret ikke er tilgjengelig.

Det nyttige resultatet navngir handlingen, håndhevelsespunktet og dataene som er synlige der. «VPN-en dekrypterte den» svarer på ett lag og kan ikke erstatte e-postapplikasjonens innholds- og autorisasjonsmodell.