Łączenie dwóch VPN-ów w łańcuch sprzedaje się zwykle jako dodatkowe szyfrowanie, co jest najmniej interesującą rzeczą, jaką to robi. Prawdziwym produktem jest druga decyzja autoryzacyjna, podejmowana przez innego właściciela wobec innego zestawu zasobów. Jeśli oba etapy akceptują te same dane uwierzytelniające i docierają do tych samych celów, wewnętrzna brama jest dekoracją z dodatkowym opóźnieniem. Rozstrzygnięcie, czy ta druga decyzja jest warta swoich kosztów operacyjnych, zaczyna się od nazwania tego, co każda brama faktycznie weryfikuje.

Jeden tunel, potem druga decyzja

Zewnętrzna brama odpowiada na szerokie pytanie: czy to zatwierdzone urządzenie pracownika i czy może dotrzeć do ogólnej sieci wewnętrznej. Wewnętrzna brama odpowiada na węższe: czy ta tożsamość ma uprawnienie do utrzymania i czy może dotrzeć do tych konkretnych punktów końcowych zarządzania. To różne pytania z różnymi właścicielami i żadne nie implikuje drugiego. Istnienie ścieżki przez oba etapy nie jest upoważnieniem do korzystania z tego, co jest za drugim. Dotarcie do odległego wejścia dowodzi, że trasa działa, i niczego więcej.

Zasada jest stara i wciąż ignorowana: położenie w sieci samo w sobie o niczym nie świadczy. Streszczenie architektury zero zaufania NIST mówi to wprost, odrzucając domniemane zaufanie wynikające z tego, skąd przyszło połączenie lub kto jest właścicielem sieci. Zastosowane tutaj: dotarcie do wewnętrznego wejścia jest warunkiem wstępnym dostępu do jego zasobów, nigdy pozwoleniem na ich użycie.

Zapisz, co weryfikuje każda brama

Dla każdego etapu zanotuj tożsamość, którą sprawdza, cele, które dopuszcza, oraz warunki, w których można go pominąć. Zewnętrzna brama może legalnie dopuszczać zwykłe usługi wewnętrzne plus odbiornik wewnętrznej bramy i nic więcej. Wewnętrzna brama może wymagać oświadczenia o roli i dopuszczać tylko adresy zarządzania nazwane w zapisie zmiany. Aplikacja na dalekim końcu zachowuje ostatnie słowo co do operacji, które ta rola może wykonywać, więc łańcuch dodaje bramę bez zastępowania autoryzacji aplikacji.

GateIdentity it checksDestinations it permitsHow it could be skippedWhen it is removed
Outer gatewayEmployee account plus a managed device postureGeneral internal services and the inner gateway's listenerAny alternate path to the same destinations, including a public listenerOrdinary work stops and the inner stage becomes unreachable
Inner gatewayA maintenance entitlement or role claim on that identityThe named management addresses in the change recordDirect routes from the outer domain to those addressesMaintenance access ends while general access stays as it was

Dwa pominięcia po cichu psują projekt. Jeśli domena zewnętrzna już dociera bezpośrednio do każdego wrażliwego celu, wewnętrzna brama jest opcjonalna, a nie obowiązkowa. Jeśli publiczny odbiornik lub druga prywatna trasa oferuje ten sam dostęp, zamierzona ścieżka jest jedną z kilku opcji. Przydziel właściciela także każdemu zestawowi reguł i pozwól, by ich umowa nazywała usługi docelowe, dozwolone tożsamości źródłowe, prywatny DNS, tłumaczenie adresów i to, kto odpowiada, gdy przekazanie zawiedzie. Adres, któremu ufa się w sieci zewnętrznej, nigdy nie powinien zastępować autoryzacji domeny wewnętrznej.

Testuj przypadki odmowy, nie szczęśliwą ścieżkę

Udane połączenie przez obie bramy dowodzi bardzo niewiele, bo to właśnie ten przypadek wszyscy testowali podczas wdrożenia. Ciekawe są przypadki, w których jeden etap przechodzi, a drugi odmawia. Trzy z nich pokrywają większość ryzyka i każdy ma oczekiwany wynik, który można sprawdzić, a nie dyskutować.

Gdy ogólny dostęp jest zatwierdzony, a rola wrażliwa nieobecna, zwykła praca musi trwać, podczas gdy wrażliwy cel jest odrzucany. Zatwierdź oba etapy, a osiągalny zbiór powinien być punktami końcowymi utrzymania nazwanymi w zapisie zmiany, nic szerszym. Gdy uprawnienie zostanie odebrane w środku sesji, uzgodniona polityka sesji musi wejść w życie bez zrywania niepowiązanego ogólnego dostępu. To, czy to odebranie kończy istniejącą sesję natychmiast, czy przy następnym ponownym uwierzytelnieniu, jest decyzją polityczną, którą umowa powinna już zawierać. Ten, kto napisał przypadki akceptacyjne, nie jest osobą, która powinna je interpretować podczas incydentu.

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

Policz dodane zależności

Każdy dodatkowy etap dodaje komponent, który może zawieść, oraz trasę, która musi się poprawnie zagnieździć w zewnętrznym tunelu. Podczas częściowej awarii zewnętrzna ścieżka pozostaje w górze, a wewnętrzna jest nieosiągalna, więc użytkownik widzi zdrową ikonę VPN obok usługi, która nigdy nie odpowiada.

Sprawdź trasy i reguły blokowania podczas awarii, a nie tylko w normalnym przypadku. Trasa domyślna wypychana przez zewnętrzny tunel może przechwycić własny adres wewnętrznej bramy, co zamienia drugi etap w połączenie, które się nawiązuje, a potem spada. Zanotuj, co ma pozostać zablokowane, gdy nie ma wewnętrznego tunelu, bo przypadkowy powrót wokół niego jest gorszy niż czyste przerwanie. Użyj tego samego kształtu sondy na obu przeskokach, aby każdy był zmierzony, a nie założony. Dwa wskaźniki połączenia nie dowodzą ani zagnieżdżenia, ani izolacji.

Czego druga brama nie może ci kupić

Zapytaj, czy dwie bramy dzielą dane uwierzytelniające, urząd certyfikacji lub płaszczyznę zarządzania. Tam, gdzie dzielą, dzielą też swoje najważniejsze tryby awarii, a drugi etap kosztuje więcej niż niezależność, którą pozornie dodaje. Osobne sesje kryptograficzne nie tworzą osobnych kontroli administracyjnych.

Zatrzymaj wewnętrzną bramę, dopóki egzekwuje wymóg, który możesz nazwać i przetestować, na przykład rolę, której domena zewnętrzna nigdy nie sprawdza. Usuń ją, gdy jej jedynym zadaniem jest ponowne uwierzytelnienie tej samej tożsamości wobec tych samych celów. W każdym razie zanotuj wymóg, właściciela i zachowanie przy awarii razem, aby następny przegląd spierał się o wymóg, a nie o diagram.

Powiązane artykuły