Tərəfdaş VPN girişini tərəfdaşları birləşdirmədən mərkəzləşdirin

Təklif məqul görünür: on iki noutbuka yayılmış beş tərəfdaş tuneli, beş dəst müştəri versiyası, beş yardım masası skripti və bunların necə bir-birinə uyduğunu bilən bir mühəndis. Onları idarə olunan giriş səviyyəsinə köçürmək son nöqtə artımını həll edir. Bu həm də arxitekturanızda yeni bir obyekt yaradır, indi öz avtorizasiya modelinə ehtiyacı olan ortaq giriş xidməti, və hamının kiçik saydığı uğursuzluq bütün tunelləri işə salınmış mərkəzi cihazın qonşu olmağa heç vaxt razılaşmamış təşkilatlar arasında səssizcə tranzit şəbəkəsinə çevrilməsidir. Bu risk dizayn seçimidir, avadanlığın öz-özünə etdiyi bir şey deyil. Aşağıdakı iş rahatlığı təsadüfi yan təsiri qəbul etmədən necə saxladığımdır.

Hər tərəfdaşın artıq imzaladığı müqavilədən başlayın

Hər hansı konfiqurasiyadan əvvəl tərəfdaşın ümumiyyətlə ortaq şlüzə və ya sayt bağlantısına icazə verdiyini təsdiqləyin. Şəxsi uzaqdan giriş hesabı, cihaz duruşu tələbi və ya interaktiv MFA axını nəzarətsiz ortaq tunelə köçürülə bilməz, və işçiləri bir kopyalanmış müştəri kimliyi arxasında toplamaq tərəfdaş loglarını yoxlayana qədər yaşayan qısa yollardan biridir. Hər icazə verilən bağlantı üçün təyinat diapazonlarını, xüsusi DNS domenlərini, icazəli daxili mənbələri, autentifikasiya sahibini və tunel sıradan çıxanda nə olmasını qeyd edin. Tərəfdaşdan ortaq bağlantını yazılı şəkildə təsdiqləməsini, qəbul edəcəkləri mənbə diapazonları ilə birlikdə istəyin. Şifahi razılıq adətən təhlükəsizlik komandaları dəyişdiyi həftə mənasını dəyişir.

Bu qeyd əsas nəticədir. Bir tərəfdaş üçün onu yaza bilmirsinizsə, o tərəfdaş mərkəzləşdirməyə hazır deyil.

Yalnız təyinatla deyil, kontekstə görə marşrutlayın

İki tərəfdaş sonda eyni xüsusi diapazondan istifadə edəcək, çünki hər təşkilat eyni RFC 1918 məkanından seçir. Tək adi marşrut cədvəli yalnız təyinat ünvanından düzgün tərəfdaşı seçə bilməz, ona görə üst-üstə düşən diapazonlar ayrı marşrut kontekstləri və ya razılaşdırılmış başqa dizayn tələb edir. RFC 4364 sənədindəki yönləndirmə domeni modeli bu ayrılığın niyə vacib olduğunu izah edir və bir quraşdırma öz şlüz platformasından eyni xassəni tələb etmək üçün MPLS işlətməli deyil.

Platformaya birbaşa sual verin: iki tərəfdaş eyni təyinat prefiksini paylaşa və yenə də sessiyanın hansı işçi kontekstindən gəldiyinə görə fərqləndirilə bilərmi? Cavab xeyr isə, bu məhdudiyyət dizaynı hər hansı satıcı funksiya siyahısından çox formalaşdırır.

Cavab bəli olduqda, marşrut konteksti sənədləşdirdiyiniz və sınaqdan keçirdiyiniz şey olur, çünki traceroute-da görünmür.

İşçinin nə yazdığını və tərəfdaşın nə qeyd etdiyini müəyyənləşdirin

Bəzi tərəfdaş işləri tətbiq proksisinə və ya həmin tərəfdaşın konteksti daxilində açılan uzaq iş sahəsinə uyğun gəlir. Digər işlər təsdiqlənmiş işçi seqmentindən marşrutlanmış şəbəkə girişi tələb edir və ikisi uzaq tərəfdə fərqli mənbə ünvanları və fərqli audit izləri yaradır. Ortaq tərcümə olunmuş mənbə ünvanı icazə siyahısını təmin edə bilər, amma hansı cihazın nə etdiyini gizlədir, ona görə etibarlı işçi-sessiya qeydini saxlayın və şlüz ünvanını kimlik kimi qəbul etmək əvəzinə tətbiq autentifikasiyasını yerində saxlayın; bu, tərəfdaş kim etdiyini soruşana qədər rahatdır.

Sonra işçinin tərəfindən bir real tapşırığı gəzin: nəyə klikləyirlər, nə tələb olunur və tərəfdaş log qeydi istəsə nə görərdi. Bu gəzinti təkrarlana bilmirsə, dizayn bitməyib.

Tərəfdaşdan tərəfdaşa tranziti açıq şəkildə rədd edin

Ortaq avadanlıq heç vaxt ortaq etimad demək olmamalıdır. Rəddi adı çəkilmiş sahibi olan qəsdən bir qayda kimi əlavə edin, itkin konfiqurasiyanın təsadüfü kimi deyil, və onu hər iki istiqamətdən, əks halda keçəcək bir sorğu ilə sınayın. Sınaq vacibdir, çünki yalnız olmayan bir icazə əlaqəsiz bir şikayəti həll etmək üçün marşrut əlavə edən növbəti mühəndis tərəfindən bərpa edilə bilər.

Rəddi icazələrin yanında tərəfdaş qeydinə yazın ki, niyyət kadr dəyişikliklərindən sonra da qalsın.

Onu daha böyük noutbuk kimi deyil, ortaq xidmət kimi işlədin

Tunel yenilənməsi, etimadnamə rotasiyası, tutum və şlüz dəyişdirilməsi indi hamısı ortaq xidmət dəyişikliklərinə çevrilir, yəni fərdi noutbukların heç vaxt tələb etmədiyi bir cədvəl və rabitə yolu lazımdır. Şənbə günü bitən tərəfdaş sertifikatı artıq bir istifadəçinin kəsintisi deyil; həmin tərəfdaşın bütün sessiyaları birdən olur.

Səviyyəni yalnız rədd edilmiş tərəfdaşlararası sorğu tam nəzərdə tutulduğu kimi uğursuz olduqda və icazəli işçi sorğusu düzgün mənbə ilə düzgün təyinata çatdıqda qəbul edin. Noutbuk toqquşmasını aradan qaldırmaqla hər tərəfdaşın sərhədini toxunulmaz saxlamaq bütün məsələdir; hər masadan hər uzaq prefiksə çatılan dizayn yalnız problemin yerini dəyişib.

Tərəfdaş, kontekst, icazəli diapazonlar və sahib üçün kiçik bir cədvəl saxlayın. Hadisə zamanı hər kəsin ilk soruşacağı şey bu olacaq.