Tabele routingu jako mechanizmy kontroli bezpieczeństwa

route table to zestaw reguł określających, gdzie jest kierowany ruch sieciowy z podsieci. Oprócz zapewniania łączności tablice tras są również mechanizmem kontroli bezpieczeństwa: kontrolując miejsca docelowe, do których podsieć może dotrzeć, określasz, co jest możliwe, zanim zostanie sprawdzona jakakolwiek reguła zapory.

Każda trasa mapuje docelowy CIDR na cel, taki jak internet gateway, NAT gateway, połączenie peeringowe lub transit gateway. AWS używa dla każdego pakietu najbardziej szczegółowej pasującej trasy. Trasa lokalna dla CIDR VPC jest zawsze obecna i nie można jej usunąć.

To obecność lub brak trasy do internet gateway decyduje o tym, czy podsieć jest publiczna, czy prywatna. Usunięcie tej trasy natychmiast przekształca podsieć w prywatną. Dlatego prawdziwym wyznacznikiem ekspozycji na Internet są tablice tras, a nie ustawienia podsieci.

Każda podsieć jest powiązana dokładnie z jedną tablicą tras, choć jedna tablica tras może obsługiwać wiele podsieci. Podsieci bez jawnego powiązania korzystają z głównej tablicy tras VPC. Umieszczenie publicznych i prywatnych podsieci w osobnych tablicach tras ułatwia zrozumienie i audytowanie ich reguł dostępu.

Aby odizolować podsieć danych, należy przypisać jej tablicę tras bez jakiejkolwiek trasy do Internetu lub NAT, zawierającą wyłącznie lokalną trasę VPC. Taka podsieć może komunikować się wewnątrz VPC, ale nie ma żadnej ścieżki do Internetu ani z Internetu, co wymusza izolację strukturalnie, a nie wyłącznie za pomocą reguł zapory.

Po utworzeniu gateway VPC endpoint dla S3 lub DynamoDB AWS dodaje trasę do punktu końcowego w odpowiednich tablicach tras. Kieruje to ruch do tej usługi AWS przez prywatny punkt końcowy zamiast przez Internet — jest to zmiana routingu, która jednocześnie umożliwia i zabezpiecza prywatny dostęp.

Tablice tras mogą wymuszać przejście ruchu przez urządzenie inspekcyjne lub AWS Network Firewall przed opuszczeniem VPC. Kierując ruch wychodzący z podsieci do punktu końcowego zapory zamiast bezpośrednio do NAT, gwarantujesz, że każdy pakiet wychodzący zostanie poddany inspekcji. Routing wymusza więc miejsce przeprowadzania kontroli bezpieczeństwa.

Aby dotrzeć do innego VPC, trasa musi wskazywać połączenie peeringowe lub transit gateway. Pominięcie tej trasy utrzymuje oddzielenie sieci. Dodanie zbyt szerokich tras może nieumyślnie otworzyć ścieżki między środowiskami, dlatego wpisy tras powinny być tak szczegółowe, jak wymaga tego rzeczywiście zamierzona łączność.

Nadmiernie zezwalająca trasa, taka jak skierowanie 0.0.0.0/0 do internet gateway w warstwie, która powinna być prywatna, po cichu czyni tę warstwę publiczną. Audytowanie tablic tras pod kątem nieoczekiwanych tras do Internetu lub między VPC jest ważną częścią zabezpieczania VPC.

Połącz routing z NACL i grupami zabezpieczeń: tablice tras określają, jakie ścieżki istnieją, a NACL i grupy zabezpieczeń określają, jaki ruch jest dozwolony na tych ścieżkach. Miejsce docelowe bez trasy jest nieosiągalne niezależnie od reguł zapory, dlatego routing stanowi najbardziej zewnętrzną warstwę kontroli sieci.

Traktuj tablice tras jako świadomie zdefiniowaną granicę bezpieczeństwa. Używaj ich do określania, co jest publiczne, a co prywatne, izolowania wrażliwych podsieci, kierowania ruchu przez inspekcję oraz kontrolowania dostępu między VPC. Sprawdzanie tras pod kątem niezamierzonych ścieżek jest równie ważne jak sprawdzanie reguł zapory.

Zastosuj zasady bezpieczeństwa dotyczące tablic tras.

Tablice tras mapują docelowe CIDR-y na cele i używają najbardziej szczegółowego dopasowania; lokalna trasa VPC jest zawsze obecna. Określają, co jest publiczne, a co prywatne, za pomocą trasy do internet gateway, izolują wrażliwe podsieci (tylko lokalna trasa), kierują ruch do VPC endpoints lub zapor inspekcyjnych oraz kontrolują dostęp między VPC przez trasy peeringowe lub tranzytowe. Należy przeprowadzać audyt pod kątem niezamierzonych ścieżek do Internetu lub między VPC.