Projektowanie publicznych i prywatnych podsieci

Virtual Private Cloud (VPC) to logicznie odizolowana sieć w AWS. W jej obrębie wydziela się subnets, czyli zakresy adresów IP przypisane do jednej strefy Availability Zone. Sposób podziału VPC na podsieci jest pierwszą i najważniejszą decyzją dotyczącą bezpieczeństwa, ponieważ określa, co może komunikować się z czym.

Public subnet ma trasę do bramy internetowej, dlatego zasoby w tej podsieci mogą być osiągane z internetu i łączyć się z internetem. Private subnet nie ma bezpośredniej trasy do internetu. Rozróżnienie to wynika wyłącznie z route table, a nie z żadnej właściwości samej podsieci.

W publicznych podsieciach powinny znajdować się tylko zasoby, które muszą być dostępne z internetu: load balancers, NAT gateways, and bastion alternatives. Ograniczenie tej warstwy zmniejsza powierzchnię ataku. Serwery aplikacji i bazy danych nigdy nie powinny znajdować się w publicznej podsieci, gdzie internet mógłby uzyskać do nich bezpośredni dostęp.

Application servers, databases, and internal services należy umieszczać w prywatnych podsieciach. Nadal mogą one obsługiwać ruch za pośrednictwem load balancera w publicznej podsieci i łączyć się z internetem w celu pobierania aktualizacji przez NAT, ale nigdy nie są bezpośrednio adresowalne z zewnątrz, co znacznie ogranicza ich ekspozycję.

Typowy bezpieczny układ obejmuje trzy warstwy: public subnet dla load balancerów, private app subnet dla obliczeń oraz private data subnet dla baz danych. Ruch przepływa do wewnątrz warstwa po warstwie, a każda warstwa akceptuje połączenia tylko z warstwy znajdującej się przed nią.

Aby zapewnić odporność, należy replikować podsieci w wielu strefach Availability Zones (AZs). Para publicznej i prywatnej podsieci w każdej strefie pozwala load balancerom i obciążeniom działać mimo utraty jednej strefy. Jest to praktyka zapewniająca wysoką dostępność, która wspiera również bezpieczne i nadmiarowe projekty.

Należy zaplanować CIDR blocks tak, aby podsieci się nie nakładały i aby pozostało miejsce na rozwój. Przemyślane, niepokrywające się zakresy upraszczają routing, peering i odwołania w regułach bezpieczeństwa. Nakładające się CIDR-y w różnych VPC później uniemożliwiają peering i komplikują łączność, dlatego przestrzeń adresową należy zaplanować starannie z wyprzedzeniem.

Projekt podsieci jest mechanizmem kontroli bezpieczeństwa, ponieważ pozwala izolować wrażliwe obciążenia. Podsieć danych bez trasy do internetu i bez ścieżki przychodzącej innej niż z warstwy aplikacji jest chroniona strukturalnie jeszcze przed dodaniem security groups. To architektura, a nie tylko reguły, egzekwuje tę granicę.

Podsieci określają, gdzie stosowane są network ACLs, ponieważ NACL-e są przypisywane na granicy podsieci. Połączenie dobrze zaprojektowanych podsieci z NACL-ami na poziomie podsieci i security groups na poziomie zasobów zapewnia wielowarstwowy model sieciowy oparty na defense in depth, którego oczekuje egzamin SCS-C02.

Klasycznym błędem jest umieszczenie bazy danych w publicznej podsieci lub przydzielenie prywatnym instancjom publicznych adresów IP dla wygody. Oba rozwiązania narażają zasoby, które powinny pozostać wewnętrzne. Domyślnie należy wybierać private placement i wyraźnie uzasadniać każdy zasób w publicznej podsieci.

Przemyślany projekt podsieci jest podstawą bezpiecznej VPC. Oddzielając zasoby dostępne z internetu od wewnętrznych i rozkładając je na strefy AZ, wbudowuje się izolację i odporność w samą sieć — fundament, na którym następnie opierają się bramy, tablice routingu i zapory sieciowe.

Zastosuj zasady projektowania podsieci.

VPC dzieli się na subnets przypisane do stref Availability Zone. Podsieć jest public tylko wtedy, gdy jej tablica routingu prowadzi do bramy internetowej; w przeciwnym razie jest private. W publicznych podsieciach należy umieszczać tylko load balancery i NAT, a warstwy aplikacji i danych umieszczać prywatnie. Należy stosować wzorzec wielowarstwowy w wielu strefach AZ oraz zaplanowane, niepokrywające się CIDR-y, aby izolacja była częścią samej architektury.