Zaszyfrowany tranzyt nie daje dostępu do operatora

Dwie zatwierdzone bramy przenoszą ruch sieci o niższym zaufaniu przez ograniczoną sieć transportową. Szyfrowanie ładunku utrzymuje go nieczytelnym dla zwykłych obserwatorów tranzytu, i to jest ta część, którą ludzie projektują najpierw, a potem przestają o niej myśleć. Czego szyfrowanie nie robi, to nie określa, do których zasobów strona o niższym zaufaniu może dotrzeć. Projekt wymaga dwóch granic: jednej wokół przenoszonej rozmowy i jednej wokół dostępu do samego operatora.

Wykonaj poniższe kroki po kolei i traktuj niepowodzenie na dowolnym kroku jako zmianę projektu, a nie korektę konfiguracji.

Zdefiniuj obie granice, zanim dotkniesz konfiguracji

Pierwsza granica to rozmowa: które pary bram mogą ustanowić tunel i który ruch wewnętrzny może przez niego przechodzić. Druga to operator: do których adresów i usług hosty o niższym zaufaniu mogą dotrzeć poza tunelem. Zespoły zwykle budują pierwszą, a drugą dziedziczą z dowolnego routingu, który już istniał, i tak ograniczony projekt po cichu staje się szeroki. To dziedziczenie jest zwykle przyczyną źródłową, gdy przegląd znajdzie host o niższym zaufaniu rozmawiający z czymś, czego nikt nie zatwierdził.

Zapisz obie jako listy adresów, portów i kierunków. Jeśli listy nie da się zapisać, granica nie jest jeszcze zdefiniowana.

Krok 1: ogranicz tunel zewnętrzny

Na interfejsie skierowanym do operatora zezwól tylko na to, czego potrzebuje tunel: IKE na UDP 500 i 4500 między dwoma adresami bram oraz ESP tam, gdzie nie stosuje się przechodzenia NAT. Odrzucaj wszystko inne, co dociera do tego interfejsu, w tym protokoły zarządzania. Specyfikacja ESP obejmuje usługi ochrony; nie mówi nic o tym, z których własnych usług operatora bramy mogą korzystać. Wyraź to jako jawną listę zezwoleń, aby nowo opublikowana usługa operatora nie stała się osiągalna domyślnie.

To jest zestaw reguł, który czyni projekt projektem tranzytowym, a nie porozumieniem peeringowym.

Sprawdź to od strony o niższym zaufaniu, a nie z konsoli bramy. Host tam powinien nie móc dotrzeć do serwera DNS operatora jeszcze przed podniesieniem tunelu.

Krok 2: zdecyduj, co dostarcza odległa brama

Na odległym końcu odzyskany ruch musi trafić w określone miejsce. Zdefiniuj, które usługi wewnętrzne są dozwolone, z których zakresów źródłowych i czy odpowiedzi mają być symetryczne. Przejrzyj dostęp administracyjny osobno, ponieważ ta sama brama często udostępnia interfejs administracyjny, który nigdy nie był częścią planu tranzytu.

Schemat, który kończy się na udanym odszyfrowaniu, pominął najważniejszą decyzję.

Krok 3: zachowaj własność na poziomie warstwy

Sprzęt tranzytowy nadal odbiera i przekazuje pakiety zewnętrzne, więc potrzebuje poprawek i planowania pojemności. Punkty końcowe tunelu przetwarzają chroniony protokół i udostępniają ruch wewnętrzny swojej ścieżce przekazywania, więc potrzebują własnych reguł i własnego monitorowania. Aplikacje końcowe przetwarzają ładunek, a nieprzejrzysty ładunek nie jest dowodem, że odszyfrowane pobieranie jest nieszkodliwe.

Przypisz właściciela do każdej warstwy. Warstwy bez właściciela to te, które dryfują.

Krok 4: zweryfikuj, a potem przekaż organowi

Zweryfikuj ścieżkę zewnętrzną przy podniesionym tunelu i regułach operatora na miejscu. Następnie wypróbuj każdy zasób, do którego strona o niższym zaufaniu nie powinna dotrzeć, i potwierdź, że niepowodzenie jest odmową, a nie przekroczeniem czasu, które ukrywa trasę. Sprawdź też dostępność i limity zasobów, ponieważ nawet szyfrowane łącze można wysycić.

W środowiskach regulowanych lub klasyfikowanych zanieś projekt do odpowiedniego organu bezpieczeństwa i użyj jego zatwierdzonej architektury separacji. Konfiguracja VPN i wyjaśnienie koncepcyjne nie ustanawiają akredytacji. Ten krok to nie papierologia; rozstrzyga, czy projekt w ogóle może istnieć.