Filtrarea e-mailurilor printr-un VPN: unde rulează de fapt regulile de conținut

Această cerere sună ca o problemă de rețea: opriți un anumit tip de atașament să părăsească clădirea, iar VPN-ul este deja acolo, așa că folosiți-l. Acest cadru se rupe la prima întrebare la care filtrul trebuie să răspundă. Regulile de conținut trebuie să vadă mesajul, iar mesajul devine vizibil într-un alt strat decât tunelul. Parcurg calea poștei spre exterior de la pachet și mă opresc în primul loc unde datele necesare există cu adevărat.

Trei straturi sunt independente: transportul VPN, conexiunea SMTP TLS și criptarea proprie a mesajului. Fiecare se termină în alt loc.

Începeți cu stratul care poate vedea mesajul

Decapsularea VPN vă oferă traficul de rețea intern. Dacă clientul de poștă a deschis o conexiune TLS către un server de trimitere, traficul intern conține în continuare acel flux TLS, nu poștă lizibilă.

Prin urmare, o captură de pachete făcută la marginea tunelului răspunde la o altă întrebare decât „conține acest mesaj un atașament interzis“.

Terminarea SMTP TLS se termină la plic

Terminarea SMTP TLS pe serverul de poștă expune mesajul așa cum a fost trimis către acel punct. Serverul vede antetele, plicul și structura MIME. Asta este suficient pentru multe reguli de conținut. Plicul vă spune expeditorul și destinatarii așa cum i-a înțeles serverul.

Nu este suficient pentru un mesaj protejat cu S/MIME. Serverul primește o entitate protejată și, fără cheile relevante, nu poate citi conținutul din interior. Aceeași limită se aplică unui atașament criptat care sosește intact.

Nu slăbiți securitatea transportului pentru a face o captură pasivă lizibilă. Asta schimbă arhitectura în loc să plaseze regula acolo unde sunt datele.

S/MIME se termină acolo unde sunt cheile

S/MIME protejează datele mesajului MIME, deci granița sa este materialul de chei și aranjamentul autorizat de decriptare. Un filtru fără acele chei poate acționa în continuare asupra metadatelor vizibile sau asupra prezenței unui obiect protejat, dar acesta este un rezultat diferit.

Dacă organizația operează o poartă de criptare autorizată sau un control gestionat al punctelor finale, documentați unde există text clar, ce identitate îl poate inspecta și cum sunt protejate cheile și înregistrările. Nu există nicio cheie principală creată prin direcționarea traficului printr-un VPN.

Scrieți asta înainte ca cineva să promită clasificarea textului clar. Promisiunea este partea greu de retras.

Puneți regula în platforma de poștă

Dacă serverul de poștă aprobat primește mesajul lizibil, integrarea sa de filtrare a conținutului acceptată este punctul de aplicare. Asta este diferit de a permite o conexiune SMTP printr-un firewall. Această distincție decide dacă regula poate respinge, pune în carantină sau doar adnota.

Postfix, de exemplu, documentează filtrarea conținutului după coadă: poșta este pusă în coadă, transmisă unui filtru și returnată pe calea de livrare. Aranjamentul său după coadă diferă de opțiunile proxy dinaintea cozii și Milter la care face referire același ghid. Alegeți integrarea acceptată și comportamentul la eșec pentru serviciul de poștă pe care îl operați efectiv.

O singură regulă de atașamente nu este un program complet împotriva pierderii de date. Încărcările din browser, stocarea partajată și acțiunile la punctele finale au nevoie de propriile controale.

Scrieți testul de acceptare cu mesaje sintetice

Testați cu exemple sintetice aprobate: un mesaj permis, o acțiune de conținut interzisă și tratarea declarată a criptării la nivel de mesaj. Includeți ce face serviciul de poștă când filtrul său nu este disponibil.

Rezultatul util numește acțiunea, punctul de aplicare și datele vizibile acolo. „VPN-ul l-a decriptat“ răspunde la un singur strat și nu poate înlocui modelul de conținut și autorizare al aplicației de poștă.