VPN istifadəçilərinə subnetə deyil, bir xidmətə giriş verin

Bir podratçıya bir daxili veb tətbiqi lazımdır, başqa heç nə, və asan cavab onlara server subnetinə tunel verməkdir. Bu, onlar onu skan edən günə qədər işləyir. Daha dar dizayn daha çox düşünmə tələb edir, çünki əlçatanlıq, marşrutlaşdırma və tətbiq icazəsi razılaşmalı olan üç ayrı nəzarətdir.

Tələbi subnet kimi deyil, xidmət kimi yazın

Təyinat hostu, protokol və portdan başlayın, sonra ona çatmalı olan istifadəçi və ya cihaz qrupunu əlavə edin. Şəxsi DNS zonasını yalnız tətbiq adı həll edirsə daxil edin, kimlik provayderini yalnız giriş axını ona ehtiyac duyursa daxil edin. Qalan hər şey hələ əsaslandırmadığınız asılılıqdır.

Subnet şəbəkə komandasının tətbiq detallıdır, xidmət isə biznesin istədiyi şey və nəzərdən keçirilib ləğv edilə bilən vahiddir.

Asılılıq siyahısı üç elementdən çox olarsa, tətbiqin çox güman ki öz dizayn söhbətinə ehtiyacı var.

Dar marşrutlaşdırın, amma icranı başqa yerdə edin

Dar marşrut və ya selektor tunelə hansı paketləri daşıyacağını deyir; bu avtorizasiya siyasəti deyil. Giriş qərarı şlüz filtrində, təyinat hostunun firewallunda və tətbiqin öz icazə modelində verilir. Bir ünvanı əhatə edən marşrut yaxşı başlanğıcdır və qərarlı istifadəçini dayandıran nəzarət deyil. Bu ayrılıq filtri tuneli yenidən dizayn etmədən dəyişməyə imkan verir.

Əksinə, ciddi filtrlə geniş marşrut qanuni ola bilər, ancaq iştirak edən hər kəs icranı hansının etdiyini bilirsə.

İcra nöqtəsini açıq şəkildə sənədləşdirin, əks halda növbəti dəyişiklik onu təsadüfən yerindən oynadar.

Xidmətin həqiqətən gördüyü mənbəyi yoxlayın

Hədəf ya müştərinin hovuz ünvanını, ya da şlüzün ünvanını görür; bu, tərcümə edib-etməməyinizdən asılıdır. Host firewall qaydaları və jurnallar real mənbəyə uyğun olmalıdır. Bir neçə istifadəçi tərcümə olunmuş mənbəyi paylaşırsa, o hostda heç bir istifadəçi-üzrə qayda onları ayıra bilməz və bu, səhv deyil, dizayn məhdudiyyətidir.

Tərcüməni qəsdən seçin: marşrutlaşdırmanı sadələşdirir və mənbə kimliyini məhv edir, bu da audit və istifadəçi-üzrə qaydalar üçün vacibdir.

İkisindən hansını seçdiyinizi ona bağlı olan qaydanın yanında yazın.

Tətbiq avtorizasiyası məcburidir

Porta çatmaq rol vermir. Tətbiq yenə də öz girişini və öz icazələrini tələb edir, çünki şəbəkə qatı istifadəçinin hansı qeydləri redaktə edə biləcəyini ifadə edə bilmir. Daxili subnetdən gələn hər sorğuya güvənən xidmət dar tuneli bir kompromis edilmiş etimad məlumatı üçün tam girişə çevirir. Tunel soketi kimin aça biləcəyini, tətbiq isə onunla nə edə biləcəyini qərarlaşdırır.

Dar dizayn burada iki dəfə ödəyir, çünki daha az əlçatan host daha az yerdə tətbiq səviyyəli səhvin istismar olunması deməkdir.

Şəbəkə qaydasını və tətbiq rolunu ayrı sistemlərdə saxlayın və onları ayrıca ləğv edin.

İcazə verilən və rədd edilən yolu birlikdə sübut edin

Səlahiyyətli istifadəçi kimi qoşulun və bir zərərsiz nümunəvi əməliyyat icra edin, sonra əlçatmaz olmalı olan təyinatı yoxlayın. Yalnız birinci yarısını sınaqdan keçirən dizayn sınaqdan keçməmişdir və dizaynı sübut edən rədd sınağıdır. Hər qayda dəyişikliyindən sonra təzə sessiya sınayın və sorğular gəlib cavablar gəlmirsə, qayıdış yoluna baxın.

Qəbul sınağını keçirmək üçün yönləndirmə filtrlərini söndürməyin, çünki bu, sınaqdan keçirilən şeyi dəyişir.

İstifadəçi artıq xidmətə ehtiyac duymadıqda, uzaq kimliyi və tətbiq rolunu öz sistemlərində ləğv edin və hər ikisini qeyd edin. strongSwan yönləndirmə bələdçisi yolun şlüz tərəfini əhatə edir.