TLS bərkitməsi və VPN qəbulu fərqli suallara cavab verir

Şəxsi mobil tətbiqi VPN-in arxasına qoyun və ağlabatan bir insan onun hələ də sertifikat bərkitməsinə ehtiyacı olub-olmadığını soruşacaq. Sual iki bərabər nəzarət arasında seçim kimi səslənir, əslində isə iki fərqli qapı haqqında sualdır. VPN bu cihazın yoldan ümumiyyətlə istifadə edə biləcəyini həll edir; tətbiq isə çatdığı serverin gözlədiyi server olub-olmadığını həll edir. Hər ikisinə ayrıca cavab verin və dizayn sadələşəcək.

İki qapı, iki sual

Şəbəkəyə buraxılış müştəri ilə bağlıdır: bu cihaz qeydiyyatdan keçibmi, onun etimadnaməsi etibarlıdırmı və siyasət ona bu yolda icazə verirmi? Tətbiq etimadı serverlə bağlıdır: bağlantı tətbiqin qəbul etdiyi kimliyə malik xidmətə çatıbmı? Bu cavablar müxtəlif sistemlərdən gəlir, müxtəlif səbəblərdən uğursuz olur və müxtəlif komandalar tərəfindən düzəldilir. VPN əl sıxışması uğurlu ola bilər, halbuki tətbiq həmyaşının arxasındakı vaxtı keçmiş sertifikatla danışır. Mükəmməl bərkidilmiş tətbiqə yenə də heç kim çata bilməz, çünki cihaz heç vaxt şəbəkəyə daxil olmayıb.

İkisi bir-birini tamamlayır. Birini atmaq bir nəzarəti aradan qaldırır; digərini əlavə etmək onu əvəz etmir.

Bərkitmə əslində nəyi məhdudlaşdırır

Bərkitmə tətbiqin qəbul edəcəyi server kimliklərinin çoxluğunu daraldır, adətən hansısa anbarın zəmanət verdiyi hər zəncirə güvənmək əvəzinə açıq açarı və ya sertifikat heşini adlandırmaqla. Bu, adi yoxlamanın üzərinə qoyulan məhdudiyyətdir, onun əvəzi deyil. Adi yoxlama zəncirin ümumiyyətlə etibarlı olub-olmadığını cavablandırır; bərkitmə isə bunun bu tətbiqin gözlədiyi zəncir olub-olmadığını. Birinci addımı atlayan tətbiq təhlükəsizlik deyil, yalnız yenilik qazanır.

Bərkidilən obyekt platformalar arasında fərqlənir, ona görə sözün özü sizə çox az şey deyir. Bir məhsulun etimad anbarından heşi köçürüb mobil tətbiqdə eyni şey kimi qəbul etmək geniş yayılmış və səssiz bir səhvdir.

Platformada bərkitmə siyasət deyil, konfiqurasiyadır

Android bərkitməni şəbəkə təhlükəsizliyi konfiqurasiyası vasitəsilə təqdim edir, burada bərkitmə dəsti açıq açarın həzmlərini saxlayır və zəncir onlardan ən azı birini ehtiva etməlidir. Bu fayl hər tətbiq üçün ayrıdır və qəsdən edilən qurma dəyişikliyi tələb edir. iOS-un bərabər manifest mexanizmi yoxdur, ona görə orada bərkitmə tətbiqin öz etimad qiymətləndirmə kodunda yaşayır.

Mexanizm fərqli olduğu üçün tələb hər platforma üçün yazılmalıdır. Platformanı adlandırmadan sertifikatı bərkit deyən siyasət tətbiq oluna bilən deyil.

Rotasiya bərkitmənin yaşayıb-yaşamayacağını həll edir

Çətin hissə ilk buraxılış deyil, ondan sonrakı sertifikat yenilənməsidir. Məhdudlaşdırıcı etimad siyasəti qanuni yeni açarı hücumçunun açarı qədər qətiyyətlə rədd edir.

Rotasiyanı yaşadıla bilən edən iki mexanizm var: ehtiyac duyulmazdan əvvəl artıq etibar edilən ehtiyat bərkitmə və bərkitmə dəstində son istifadə tarixi ki, icra tətbiqi bloklamaq əvəzinə bitsin. Hər ikisi siyasət qərarıdır və son tarix xüsusilə zərərsiz taymer deyil, təhlükəsizliyin qəsdən azaldılmasıdır. Tətbiq qurmasına, TLS son nöqtəsinə və sertifikat yenilənməsinə kimin nəzarət etdiyini adlandırın və onları bir dəyişiklik prosesinə yığın. Əgər bunlar üç fərqli komandadırsa, bərkitmə gec-tez heç kimin planlamadığı bir kəsintiyə səbəb olacaq.

İtirilmiş cihaz üçüncü problemdir

VPN etimadnaməsini ləğv etmək mütləq tətbiq sessiyasını bitirmir və server bərkitməsi başqasının əlindəki telefonla bağlı heç nə etmir. Cihaz kilidi, etimadnamə saxlancı, sessiya ömrü və uzaqdan ləğvetmə ayrı qərarlar və ayrı sahiblərdir. Onları bərkitmə müzakirəsinə qatlamaq heç birinin dizayn olunmayacağını təmin edir.

Gördüyünüz bir əlaqə yerinə dörd əlaqəni sınayın: nəzərdə tutulan server və əməliyyat, rədd edilməli hesab, rədd edilməli server kimliyi və planlaşdırılmış rotasiya. İşləyən VPN yalnız birincisini təcrübədən keçirir. Hər testin nəyi sübut etdiyini yazın, çünki növbəti şəxs yaşıl tunelin dördünün də keçdiyini bildirdiyini güman edəcək.