VPN üzərindən e-poçt filtrləmə: məzmun qaydaları əslində harada işləyir

Bu sorğu şəbəkə problemi kimi səslənir: müəyyən növ əlavənin binanı tərk etməsini dayandırın, VPN artıq var, deməli ondan istifadə edin. Bu çərçivə filtrin cavab verməli olduğu ilk sualda dağılır. Məzmun qaydaları mesajı görməlidir, mesaj isə tuneldən fərqli qatda görünür. Mən poçt yolunu paketdən bayıra doğru izləyir və tələb olunan məlumatın həqiqətən mövcud olduğu ilk yerdə dayanıram.

Üç qat bir-birindən asılı deyil: VPN nəqli, SMTP TLS bağlantısı və mesajın öz şifrələməsi. Hər biri fərqli yerdə bitir.

Mesajı görə bilən qatdan başlayın

VPN dekapsulyasiyası sizə daxili şəbəkə trafikini verir. Əgər poçt müştərisi göndərmə serverinə TLS bağlantısı açıbsa, daxili trafik hələ də həmin TLS axınını ehtiva edir, oxuna bilən poçtu yox.

Beləliklə, tunel kənarında götürülmüş paket tutması “bu mesajda qadağan olunmuş əlavə varmı” sualından fərqli bir suala cavab verir.

SMTP TLS-in sonlanması zərfin yanında bitir

SMTP TLS-i poçt serverində sonlandırmaq mesajı həmin son nöqtəyə göndərildiyi kimi açır. Server başlıqları, zərfi və MIME strukturunu görür. Bu, bir çox məzmun qaydası üçün kifayətdir. Zərf sizə göndərən və alıcıları serverin onları anladığı kimi bildirir.

S/MIME ilə qorunan mesaj üçün bu kifayət etmir. Server qorunan bir varlıq alır və müvafiq açarlar olmadan içindəki məzmunu oxuya bilmir. Eyni məhdudiyyət bötöv gələn şifrələnmiş əlavəyə də aiddir.

Passiv tutmanı oxunaqlı etmək üçün nəqliyyat təhlükəsizliyini zəiflətməyin. Bu, qaydanı məlumatın olduğu yerə qoymaq əvəzinə arxitekturanı dəyişir.

S/MIME açarların olduğu yerdə bitir

S/MIME MIME mesaj məlumatlarını qoruyur, buna görə onun sərhədi açar materialı və icazəli şifrə açma quruluşudur. Bu açarlar olmayan filtr görünən metadatanın və ya qorunan obyektin mövcudluğunun üzərində hərəkət edə bilər, lakin bu fərqli nəticədir.

Təşkilat icazəli şifrələmə şlüzü və ya idarə olunan son nöqtə nəzarəti işlədirsə, açıq mətnin harada olduğunu, hansı şəxsiyyətin onu yoxlaya biləcəyini və açarlarla qeydlərin necə qorunduğunu sənədləşdirin. Trafiki VPN-dən keçirməklə yaranan heç bir master açar yoxdur.

Kimsə açıq mətn təsnifatı vəd etməzdən əvvəl bunu yazın. Vəd geri götürülməsi çətin olan hissədir.

Qaydayı poçt platformasına qoyun

Əgər təsdiqlənmiş poçt serveri oxuna bilən mesajı alırsa, onun dəstəklənən məzmun filtri inteqrasiyası tətbiq nöqtəsidir. Bu, firewall-dan SMTP bağlantısına icazə verməkdən fərqlidir. Bu fərq qaydanın rədd edə, karantinə ala və ya yalnız qeyd edə biləcəyini müəyyən edir.

Məsələn, Postfix növbədən sonrakı məzmun filtrləməsini sənədləşdirir: poçt növbəyə qoyulur, filtrə ötürülür və çatdırılma yoluna qaytarılır. Onun növbədən sonrakı quruluşu həmin təlimatın istinad etdiyi növbədən əvvəlki proxy və Milter seçimlərindən fərqlidir. Həqiqətən işlətdiyiniz poçt xidməti üçün dəstəklənən inteqrasiyanı və uğursuzluq davranışını seçin.

Bir əlavə qaydası tam məlumat itkisi proqramı deyil. Brauzer yükləmələri, paylaşılan yaddaş və son nöqtə əməliyyatları öz nəzarətlərinə ehtiyac duyur.

Qəbul testini sintetik mesajlarla yazın

Təsdiqlənmiş sintetik nümunələrlə sınaqdan keçirin: icazə verilmiş mesaj, qadağan edilmiş məzmun əməliyyatı və mesaj səviyyəli şifrələmənin bəyan edilmiş idarəsi. Filtr mövcud olmadıqda poçt xidmətinin nə etdiyini də daxil edin.

Faydalı nəticə əməliyyatı, tətbiq nöqtəsini və orada görünən məlumatı adlandırır. “VPN onu şifrədən çıxardı” bir qata cavab verir və poçt tətbiqinin məzmun və avtorizasiya modelini əvəz edə bilməz.