Reguły AWS Client VPN należą do zasobu, a nie do podsieci

Pracownicy muszą dotrzeć do jednej aplikacji w VPC i nie mogą dotrzeć do nasłuchu bazy danych na tej samej instancji, więc ktoś dodaje drugą publiczną podsieć dla endpointu VPN i uznaje wymaganie za spełnione. Umiejscowienie podsieci zmienia routing i dostępność. Nie przyznaje ani nie odmawia ani jednego portu. Uprawnienie wyrażające wymaganie znajduje się w miejscu docelowym, w grupie zabezpieczeń zasobu, a granica VPN dostarcza uchwyt, do którego odwołuje się ta reguła.

Umiejscowienie podsieci to routing, nie autoryzacja

To, gdzie znajduje się skojarzenie sieciowe endpointu, decyduje o tym, która tablica routingu przenosi ruch klientów i które strefy dostępności przetrwają awarię. Nie mówi nic o tym, do którego portu na której instancji ten ruch może dotrzeć. Dwóch klientów skojarzonych z tą samą podsiecią nadal przychodzi z tą samą tożsamością źródła, a zasób nie potrafi ich rozróżnić po nazwie podsieci.

Zacznij raczej od wymagania: kto wywołuje, który zasób, który port usługi i w którym kierunku. Następnie wybierz model reguły, który potrafi wyrazić te cztery rzeczy w miejscu docelowym. Takie ujęcie zwykle całkowicie usuwa dodatkową podsieć z projektu.

Grupa skojarzeń Client VPN jest tym uchwytem

Dla endpointu AWS Client VPN skojarzonego z podsiecią udokumentowany układ jest konkretny. Zastosuj zamierzoną grupę zabezpieczeń do skojarzeń sieci docelowej endpointu, a następnie zezwól na wymagany ruch w grupie zabezpieczeń zasobu, używając tej grupy Client VPN jako źródła.

Konkretnie, grupa instancji aplikacji zezwala na port aplikacji z grupy skojarzeń i nic więcej. Procedura dostępu do zasobu AWS opisuje tę zależność, i warto utrzymywać tę samą politykę grupy w każdej podsieci, z którą endpoint się kojarzy, ponieważ nieaktualne skojarzenie z inną grupą po cichu poszerza granicę.

Ta reguła nikogo nie uwierzytelnia. Logowanie jest osobną kontrolą, a droga do zasobu jest trzecia. Wszystkie trzy muszą zachodzić, zanim dotrze żądanie. To, które zawiedzie, decyduje o tym, która poprawka jest właściwa, a zmiana reguły jest właściwą odpowiedzią tylko dla pierwszego.

Czego jedna grupa skojarzeń nie rozróżni

Każdy klient za tą samą grupą skojarzeń dociera do zasobu jako to samo źródło grupy zabezpieczeń. Dwóch użytkowników o różnych rolach jest nierozróżnialnych na tej warstwie, niezależnie od nazwy czy tagów grupy. Autoryzacja grup zewnętrznych w Client VPN ogranicza dostęp według prefiksu docelowego dla grupy katalogowej lub SAML, co jest grubsze niż rola zasobu i powinno być traktowane jako granica sieci, a nie system tożsamości.

Drobniejsze rozróżnienia należą do aplikacji. Nasłuch bazy danych, który musi pozostać zamknięty dla większości pracowników, jest lepiej chroniony przez to, że w ogóle nie jest osiągalny w dozwolonym prefiksie, niż przez nadzieję, że członkostwo w grupie pozostanie uporządkowane.

Zmiana nazwy grupy nie tworzy tożsamości, a duplikowanie jej dla każdego zespołu tylko mnoży skojarzenia do audytu.

Nie kopiuj tej reguły do każdego projektu VPN

Samodzielnie zarządzana brama EC2 VPN, rutowane urządzenie inspekcyjne i zarządzany Client VPN to trzy różne ścieżki pakietów. Ustal, który adres źródłowy faktycznie dociera do zasobu, czy po drodze następuje translacja i jakie mechanizmy referencyjne usługa obsługuje na tej ścieżce.

Przekazywanie ruchu przez urządzenie pośrednie nie zachowuje referencji źródłowej grupy zabezpieczeń tak, jak robi to bezpośredni ruch między instancjami. AWS dokumentuje, że takie projekty mogą wymagać odpowiednich prywatnych adresów źródłowych lub CIDR-ów zamiast referencji grupy. Procedura zarządzanego Client VPN nie jest dowodem, że dołączona grupa każdej bramy działa jako uniwersalny token tożsamości dla przekazywanych pakietów.

Jeden skok NAT na ścieżce wystarczy, by złamać założenie, a awaria wygląda jak reguła, która istnieje, ale nigdy nie pasuje.

Przejrzyj efektywną granicę

Przeczytaj każdą grupę zabezpieczeń dołączoną do zasobu, ponieważ reguły zezwalające się sumują i wąska reguła nie anuluje szerszej w innej grupie. Następnie sprawdź ACL sieci, zaporę hosta i własną autoryzację aplikacji, które są osobnymi warstwami z osobnymi błędami.

Zakończ jednym żądaniem dozwolonym i jednym celowo wykluczonym wobec tego samego zasobu. Ta para dowodzi granicy, podczas gdy jedno udane połączenie dowodzi tylko, że coś jest otwarte. Potwierdź trasę, efektywne źródło i zamierzony port usługi, a nie podsieć zawierającą endpoint.

Kolejność pracy: napisz wymaganie z czterech części, dołącz grupę do skojarzeń, ogranicz regułę zasobu do portu, zweryfikuj jedno zezwolenie i jedną odmowę, a dopiero potem rozważ dzielenie podsieci ze względów routingu.