Kiçik ofis VPN-i: onu domen nəzarətçisindən uzaq saxlayın

Ofisin yeganə Windows serverinin VPN-i də bağlamalı olub-olmadığını üç şərt həll edir: kataloqda nə qədər internetə baxan proqram işlətməyə hazırsınız, uzaq istifadəçiləri həmin rol olmadan doğrulaya bilirsinizmi və host yenidən başladıqda idarəetmə girişinizə nə olur. Üçündən hər hansı birinin pis cavabı varsa, rolları ayırın. Ofisin kiçik olması büdcəni dəyişir, riski yox.

Domen nəzarətçisinə domendəki hər maşın etibar edir; VPN şlüzünə isə internetdəki hər kəs çata bilir. Bütün arqument bu asimmetriyadır.

Fərqli məruz qalma profilləri olan iki vəzifə

Şlüz xaricdən gələn bağlantıları qəbul edir, buna görə onun dinləyicisi, TLS yığını və autentifikasiya səthi etibarsız şəbəkələrdən hamısı əlçatandır. Kataloq digər maşınların etibar etdiyi səlahiyyəti saxlayır, buna görə Microsoft-un sərtləşdirmə təlimatı domen nəzarətçisi rolunu və onun host mühitini xüsusilə həssas hesab edir. Həmin hosta əlavə edilən hər xidmət kataloqun etibar mövqeyini mənimsəyir və eyni zamanda öz hücum səthini artırır. Quraşdırma rahatlığı etibar sərhədi deyil.

Rolların ayrılması asılılıqları aradan qaldırmır. Uzaq istifadəçilər hələ də autentifikasiya, marşrutlar, DNS və giriş qaydalarına ehtiyac duyur və bunları atlayan şlüz daha təhlükəsiz deyil, sadəcə daha az faydalıdır.

Kataloq rolu olmadan autentifikasiya

Şlüz dəstəklənən xarici inteqrasiya vasitəsilə kataloqu özü host etmədən etimadnamələri doğrulaya bilər. Bu inteqrasiya nə olursa olsun, ona məqsədə uyğun hüquqları olan hesab verin: autentifikasiya üçün lazım olan atributları oxumaq, başqa heç nə. VPN istifadəçilərini qəbul etmək heç vaxt onların adi hesablarını domen administratoru etməyi tələb etmir və heç vaxt şlüzün kataloqun kopyasını saxlamasını tələb etmir.

Sonra uzaq müştərinin həqiqətən ehtiyac duyduğu şəbəkə yollarını əhatə edin. Bir daxili fayl xidmətinə giriş, üstəgəl həmin iş axınının asılı olduğu ad həlli və şəxsiyyət xidmətləri, müəyyən edilmiş yollar toplusudur. Bu, VPN hovuzundan hər domen nəzarətçisi portuna və ya hər inzibati interfeysə icazə vermək üçün səbəb deyil.

Bir host yenə də bir uğursuzluq sahəsidir

Bir hipervizorda iki qonaq əməliyyat sistemi konfiqurasiyasını ayırır, taleyini ayırmır. Hipervizorun administratorları, virtual kommutasiya, saxlama və ehtiyat nüsxələr dizaynın hissəsi olaraq qalır və hostun yenidən başlaması iki xidməti birdən aradan qaldırır. Diaqram iki VM göstərdiyi üçün buna yüksək əlçatanlıq demək geniş yayılmış və bahalı bir səhvdir. Əgər geri qayıtmağın yeganə yolu həmin hostdakı VPN-dən keçirsə, nasazlıq onu təmir etmək üçün lazım olan bağlantını aparır.

Beləliklə, tuneldən asılı olmayan müstəqil idarəetmə yolu planlaşdırın və texniki xidmət zamanı nəyin əlçatan qaldığını yazın. Şlüz yeniləmələrini və kataloq xidmətini ayrıca cədvəlləşdirin, hər fasilənin hansı istifadəçilərə və ya tətbiqlərə toxunduğunu qeyd edin.

VPN-i düzəltmək üçün VPN-in işlək olmasını tələb edən texniki xidmət pəncərəsi texniki xidmət pəncərəsi deyil.

Özünüzü kilidləmədən köçürün

Rollar artıq bir quraşdırmanı paylaşırsa, tələsik uzaq miqrasiyadan çəkinin. Şlüzün bu gün sahib olduğunu inventarlaşdırın: ünvanlar, yönləndirmə qaydaları, NAT, DNS parametrləri, autentifikasiya konfiqurasiyası və hər hansı yayımlanmış xidmət. Dinləyicini yeritməzdən və ya standart marşrutu dəyişməzdən əvvəl həm əvəzləyicini, həm də geri qayıtma yolunu hazırlayın. Sonra adi uzaq istifadəçinin real işini yeni sərhəddən sınaqdan keçirin və lazımsız inzibati girişin hələ də uğursuz olduğunu təsdiqləyin.

Məqsəd daha gözəl diaqram deyil. Bütün ofis üçün kataloq etibarını ankraj edən qutuya toxunmadan VPN-i təmir etmək və ya yenidən qurmaq bacarığıdır. Bunlar fərqli məqsədlərdir və yalnız biri ikinci server tələb edir.

Qərarı hər halda qeyd edin, onu yenidən aça biləcək şərtlər də daxil olmaqla. Kiçik ofis böyüyür və bir serverə uyğun gələn cavab növbətiyə uyğun gəlməyə bilər.