Daj użytkownikom VPN dostęp do jednej usługi, nie do podsieci

Wykonawca potrzebuje jednej wewnętrznej aplikacji webowej i niczego więcej, a łatwa odpowiedź to dać mu tunel do podsieci serwera. To działa do dnia, w którym ją przeskanuje. Węższy projekt wymaga więcej myślenia, bo osiągalność, routing i uprawnienie aplikacji to trzy odrębne mechanizmy kontroli, które muszą się zgadzać.

Zapisz wymaganie jako usługę, nie jako podsieć

Zacznij od hosta docelowego, protokołu i portu, a potem dodaj grupę użytkowników lub urządzeń, która ma do niego dotrzeć. Uwzględnij prywatną strefę DNS tylko wtedy, gdy aplikacja rozwiązuje nazwę, a dostawcę tożsamości tylko wtedy, gdy przepływ logowania go potrzebuje. Wszystko inne to zależność, której jeszcze nie uzasadniłeś.

Podsieć to szczegół implementacji zespołu sieciowego, a usługa to to, o co poprosił biznes, i jednostka, którą można przejrzeć i wycofać.

Jeśli lista zależności przekroczy trzy pozycje, aplikacja prawdopodobnie potrzebuje własnej rozmowy o projekcie.

Trasuj wąsko, ale egzekwuj gdzie indziej

Wąska trasa lub selektor mówi tunelowi, które pakiety ma przenosić; to nie jest polityka autoryzacji. Filtr bramy, firewall hosta docelowego i własny model uprawnień aplikacji to miejsca, w których decyduje się dostęp. Trasa obejmująca jeden adres to dobry początek i nie jest kontrolą, która zatrzyma zdeterminowanego użytkownika. Właśnie to rozdzielenie pozwala zmienić filtr bez przeprojektowywania tunelu.

Odwrotnie, szeroka trasa ze ścisłym filtrem może być uzasadniona, ale tylko jeśli wszyscy zaangażowani wiedzą, który z nich wykonuje egzekwowanie.

Udokumentuj punkt egzekwowania wprost, inaczej następna zmiana przesunie go przypadkiem.

Sprawdź źródło, które usługa faktycznie widzi

Cel widzi albo adres puli klienta, albo adres bramy, w zależności od tego, czy tłumaczysz. Reguły firewalla hosta i logi muszą odpowiadać rzeczywistemu źródłu. Jeśli kilku użytkowników dzieli przetłumaczone źródło, żadna reguła na użytkownika na tym hoście nie może ich rozróżnić, i to jest ograniczenie projektu, nie błąd.

Wybieraj tłumaczenie świadomie: upraszcza routing i niszczy tożsamość źródła, co ma znaczenie dla audytu i reguł na użytkownika.

Zapisz, które z dwóch wybrałeś, obok reguły, która od tego zależy.

Autoryzacja aplikacji nie jest opcjonalna

Dotarcie do portu nie przyznaje roli. Aplikacja nadal potrzebuje własnego logowania i własnych uprawnień, bo warstwa sieci nie potrafi wyrazić, które rekordy użytkownik może edytować. Usługa, która ufa każdemu żądaniu z wewnętrznej podsieci, zamienia wąski tunel w pełny dostęp dla jednego skompromitowanego poświadczenia. Tunel decyduje, kto może otworzyć gniazdo, a aplikacja decyduje, co można z nim zrobić.

Tu wąski projekt zwraca się podwójnie, bo mniej osiągalnych hostów oznacza mniej miejsc, w których błąd na poziomie aplikacji można wykorzystać.

Trzymaj regułę sieciową i rolę aplikacji w osobnych systemach i wycofuj je osobno.

Udowodnij zarówno ścieżkę dozwoloną, jak i odrzuconą

Połącz się jako uprawniony użytkownik i wykonaj jedną nieszkodliwą reprezentatywną operację, a potem spróbuj celu, który powinien być nieosiągalny. Projekt, który testuje tylko pierwszą połowę, nie jest przetestowany, i to test odrzucenia dowodzi projektu. Testuj nową sesję po każdej zmianie reguły i patrz na ścieżkę powrotną, jeśli żądania docierają, ale odpowiedzi nie.

Nie wyłączaj filtrów przekazywania, żeby test akceptacyjny przeszedł, bo to zmienia rzecz, która jest testowana.

Gdy użytkownik nie potrzebuje już usługi, wycofaj tożsamość zdalną i rolę aplikacji w ich odpowiednich systemach i zapisz oba. Przewodnik strongSwan po przekazywaniu obejmuje stronę bramy tej ścieżki.