E-mail szűrés VPN-en át: hol futnak valójában a tartalomszabályok

Ez a kérés hálózati problémának hangzik: akadályozza meg, hogy egy bizonyos típusú melléklet elhagyja az épületet, és a VPN már ott van, tehát használja. Ez a keret az első kérdésnél szétesik, amelyre a szűrőnek válaszolnia kell. A tartalomszabályoknak látniuk kell az üzenetet, az üzenet pedig más rétegben válik láthatóvá, mint az alagút. Végigjárom a levél útját kifelé a csomagtól, és megállok az első helyen, ahol a szükséges adatok valóban léteznek.

Három réteg független: a VPN-szállítás, az SMTP TLS kapcsolat és az üzenet saját titkosítása. Mindegyik máshol ér véget.

Kezdje azzal a réteggel, amely látja az üzenetet

A VPN-dekapszuláció a belső hálózati forgalmat adja. Ha a levelezőprogram TLS-kapcsolatot nyitott egy beküldő kiszolgálóhoz, a belső forgalom még mindig azt a TLS-folyamot tartalmazza, nem olvasható levelet.

Így az alagút szélén vett csomagrögzítés más kérdésre válaszol, mint hogy „tartalmaz-e ez az üzenet tiltott mellékletet“.

Az SMTP TLS lezárása a borítéknál ér véget

Az SMTP TLS lezárása a levélkiszolgálón feltárja az üzenetet úgy, ahogy ahhoz a végponthoz beküldték. A kiszolgáló látja a fejléceket, a borítékot és a MIME szerkezetet. Ez sok tartalomszabályhoz elég. A boríték megmondja a feladót és a címzetteket úgy, ahogy a kiszolgáló értelmezte őket.

Ez nem elég egy S/MIME-mal védett üzenethez. A kiszolgáló védett entitást kap, és a megfelelő kulcsok nélkül nem tudja elolvasni a benne lévő tartalmat. Ugyanez a korlát érvényes a sértetlenül megérkező titkosított mellékletre is.

Ne gyengítse a szállítási biztonságot azért, hogy egy passzív rögzítés olvasható legyen. Ez megváltoztatja az architektúrát ahelyett, hogy a szabályt oda tenné, ahol az adatok vannak.

Az S/MIME ott ér véget, ahol a kulcsok vannak

Az S/MIME az MIME-üzenet adatait védi, így a határa a kulcsanyag és az engedélyezett visszafejtési elrendezés. A kulcsok nélküli szűrő még mindig cselekedhet látható metaadatokon vagy egy védett objektum jelenlétén, de az más eredmény.

Ha a szervezet engedélyezett titkosítási átjárót vagy felügyelt végpontvezérlést üzemeltet, dokumentálja, hol van nyílt szöveg, melyik identitás vizsgálhatja, és hogyan védik a kulcsokat és a nyilvántartásokat. Nincs olyan főkulcs, amely a forgalom VPN-en át történő átirányításával keletkezne.

Írja le ezt, mielőtt bárki nyílt szöveg osztályozását ígéri. Az ígéret az a rész, amelyet nehéz visszavonni.

Tegye a szabályt a levelezőplatformba

Ha a jóváhagyott levélkiszolgáló megkapja az olvasható üzenetet, a támogatott tartalomszűrő integrációja a kényszerítési pont. Ez más, mint SMTP-kapcsolatot engedélyezni egy tűzfalon át. Ez a különbség dönti el, hogy a szabály elutasíthat, karanténba tehet vagy csak megjegyzést fűzhet.

A Postfix például dokumentálja a sor utáni tartalomszűrést: a levél sorba kerül, szűrőhöz kerül, majd visszakerül a kézbesítési útvonalra. A sor utáni elrendezése eltér a sor előtti proxy- és Milter-lehetőségektől, amelyekre ugyanaz az útmutató hivatkozik. Válassza a támogatott integrációt és a hiba viselkedését ahhoz a levelezőszolgáltatáshoz, amelyet valóban üzemeltet.

Egy mellékletszabály nem teljes adatvesztés-elleni program. A böngészőfeltöltésekhez, a megosztott tárolóhoz és a végpontműveletekhez saját ellenőrzések kellenek.

Írja meg az átvételi tesztet szintetikus üzenetekkel

Teszteljen jóváhagyott szintetikus példákkal: engedélyezett üzenet, tiltott tartalmi művelet és az üzenetszintű titkosítás deklarált kezelése. Vegye bele, mit tesz a levelezőszolgáltatás, amikor a szűrője nem elérhető.

A hasznos eredmény megnevezi a műveletet, a kényszerítési pontot és az ott látható adatokat. „A VPN fejtette vissza“ egy rétegre válaszol, és nem helyettesítheti a levelezőalkalmazás tartalmi és engedélyezési modelljét.