VPN dla małego biura: trzymaj go z dala od kontrolera domeny

Trzy warunki decydują, czy jedyny serwer Windows w biurze ma także kończyć VPN: ile oprogramowania wystawionego na internet chcesz uruchamiać na katalogu, czy możesz uwierzytelniać zdalnych użytkowników bez tej roli i co dzieje się z twoim dostępem administracyjnym, gdy host się restartuje. Jeśli którykolwiek z trzech ma złą odpowiedź, rozdziel role. To, że biuro jest małe, zmienia budżet, a nie ryzyko.

Każda maszyna w domenie ufa kontrolerowi domeny; brama VPN jest osiągalna dla każdego w internecie. Ta asymetria to cały argument.

Dwa zadania o dwóch różnych profilach ekspozycji

Brama przyjmuje połączenia z zewnątrz, więc jej nasłuchiwacz, stos TLS i powierzchnia uwierzytelniania są osiągalne z niezaufanych sieci. Katalog przechowuje autorytet, któremu ufają inne maszyny, dlatego wytyczne Microsoftu dotyczące utwardzania traktują rolę kontrolera domeny i jego środowisko hostingu jako szczególnie wrażliwe. Każda usługa dodana do tego hosta dziedziczy pozycję zaufania katalogu i dokłada własną powierzchnię ataku. Wygoda instalacji nie jest granicą zaufania.

Rozdzielenie ról nie usuwa zależności. Zdalni użytkownicy nadal potrzebują uwierzytelniania, tras, DNS i reguł dostępu, a brama, która je pomija, nie jest bezpieczniejsza, tylko mniej użyteczna.

Uwierzytelnianie bez roli katalogu

Brama może weryfikować poświadczenia przez obsługiwaną integrację zewnętrzną bez hostowania samego katalogu. Czymkolwiek jest ta integracja, daj jej konto, którego uprawnienia pasują do celu: odczyt atrybutów potrzebnych do uwierzytelniania, nic więcej. Dopuszczanie użytkowników VPN nigdy nie wymaga uczynienia ich zwykłych kont administratorami domeny ani utrzymywania przez bramę kopii katalogu.

Następnie ogranicz ścieżki sieciowe, których zdalny klient naprawdę potrzebuje. Dostęp do jednej wewnętrznej usługi plików oraz usługi rozwiązywania nazw i tożsamości, od których zależy ten przepływ pracy, to zdefiniowany zbiór ścieżek. To nie powód, by zezwalać na każdy port kontrolera domeny ani każdy interfejs administracyjny z puli VPN.

Jeden host to nadal jedna domena awarii

Dwaj goście na jednym hiperwizorze rozdzielają konfigurację systemów operacyjnych, a nie rozdzielają swojego losu. Administratorzy hiperwizora, przełączanie wirtualne, pamięć masowa i kopie zapasowe pozostają częścią projektu, a restart hosta usuwa obie usługi naraz. Nazywanie tego wysoką dostępnością, bo diagram pokazuje dwa VM, to częsty i kosztowny błąd. Jeśli jedyna droga powrotna prowadzi przez VPN na tym hoście, awaria zabiera połączenie potrzebne do jego naprawy.

Zaplanuj więc niezależną ścieżkę zarządzania, która nie zależy od tunelu, i zapisz, co pozostaje dostępne podczas konserwacji. Zaplanuj aktualizacje bramy i konserwację katalogu oddzielnie, odnotowując, których użytkowników lub aplikacji dotyczy każda przerwa.

Okno konserwacji, które wymaga działającego VPN, aby naprawić VPN, nie jest oknem konserwacji.

Przenieś to, nie zamykając się na zewnątrz

Jeśli role już dzielą jedną instalację, unikaj pośpiesznej migracji zdalnej. Zinwentaryzuj, co brama posiada dziś: adresy, reguły przekazywania, NAT, ustawienia DNS, konfigurację uwierzytelniania i wszelkie opublikowane usługi. Przygotuj zarówno zamiennik, jak i drogę powrotną, zanim przeniesiesz nasłuchiwacz lub zmienisz trasę domyślną. Następnie przetestuj rzeczywistą pracę zwykłego zdalnego użytkownika przez nową granicę i potwierdź, że niepotrzebny dostęp administracyjny nadal zawodzi.

Celem nie jest ładniejszy diagram. To zdolność naprawy lub odbudowy VPN bez dotykania pudełka, które zakotwicza zaufanie katalogu dla całego biura. To różne cele i tylko jeden z nich potrzebuje drugiego serwera.

Zapisz decyzję tak czy inaczej, wraz z warunkami, które by ją ponownie otworzyły. Małe biuro rośnie, a odpowiedź pasująca do jednego serwera może nie pasować do następnego.