Amazon SCS-C02: Bezpieczeństwo sieci i VPC — Przewodnik do nauki

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Część AWS Security Specialty SCS-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Punkty końcowe VPC i polityki punktów końcowych

Punkty końcowe VPC (VPC endpoints) utrzymują ruch do usług AWS w sieci AWS, omijając publiczny internet, bramy NAT i bramy internetowe. Istnieją dwa strukturalnie różne rodzaje, a ich mylenie jest jednym z najczęstszych błędów projektowych.

Bramkowe punkty końcowe (gateway endpoints) istnieją tylko dla Amazon S3 i DynamoDB. Są to wpisy w tablicach routingu — kojarzysz punkt końcowy z tablicami routingu, a ruch przeznaczony dla listy prefiksów usługi (np. pl-63a5400a dla S3 w us-east-1) jest po cichu przekierowywany przez punkt końcowy. Nic nie kosztują i nie można się do nich dostać spoza VPC, do którego są podłączone.

Interfejsowe punkty końcowe (interface endpoints), oparte na AWS PrivateLink, to interfejsy sieciowe (ENI) z prywatnymi adresami IP umieszczonymi w Twoich podsieciach. Są one wymagane dla każdej usługi, która nie jest S3 ani DynamoDB — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR i setek innych. Jeśli instancja EC2 w prywatnej podsieci bez bramy NAT musi wykonać GetSecretValue na usłudze Secrets Manager, bramkowy punkt końcowy nie pomoże; musisz utworzyć interfejsowy punkt końcowy com.amazonaws.<region>.secretsmanager i włączyć prywatny DNS (Private DNS), aby standardowa nazwa hosta usługi była rozwiązywana na prywatny adres IP punktu końcowego.

Polityki punktów końcowych (endpoint policies) ograniczają, co można zrobić za pośrednictwem punktu końcowego, niezależnie od polityk IAM przypisanych do wywołującego. Dwa najważniejsze klucze warunkowe (condition keys) zapobiegające eksfiltracji danych to aws:PrincipalOrgID (tożsamość wykonująca wywołanie musi należeć do Twojej Organizacji) oraz aws:ResourceOrgID (zasób, którego dotyczy operacja, np. bucket S3, klucz KMS, musi należeć do Twojej Organizacji). Zastosowanie obu zamyka klasyczną ścieżkę eksfiltracji, w której przejęta instancja z prawidłowymi uprawnieniami do S3 zapisuje dane do bucketa kontrolowanego przez atakującego spoza Twojej organizacji — poświadczenia nadal działają w stosunku do S3, ale punkt końcowy odmawia przekazania żądania.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

Domyślna polityka punktu końcowego jest w pełni zezwalająca ("Action":"*" na "Resource":"*"), dlatego podsieć z samym bramkowym punktem końcowym i minimalnymi uprawnieniami IAM (least-privilege) może być nadal wykorzystana do eksfiltracji, chyba że zaostrzysz samą politykę punktu końcowego.

Łączność hybrydowa: VPN i Direct Connect

Site-to-Site VPN ustanawia dwa tunele IPsec między wirtualną bramą prywatną (virtual private gateway) lub Transit Gateway a urządzeniem bramy klienta (customer gateway). Jest szybki w provisioningu, domyślnie szyfrowany i przechodzi przez publiczny internet — więc przepustowość i opóźnienia zależą od ścieżki Twojego dostawcy usług internetowych (ISP).

AWS Direct Connect provisionuje dedykowane, fizyczne łącze za pośrednictwem lokalizacji Direct Connect. Zapewnia przewidywalne, niskie opóźnienia i wysoką, stałą przepustowość (1/10/100 Gbps), co ma znaczenie dla „gadatliwego” ruchu z lokalnych baz danych. Direct Connect sam w sobie nie jest szyfrowany w warstwie 3; ramki przesyłane są po prywatnym światłowodzie. Dla obciążeń, które wymagają zarówno niskich opóźnień, jak i szyfrowania IPsec, kanonicznym rozwiązaniem jest Direct Connect plus Site-to-Site VPN działający na publicznym VIF (lub Transit Gateway z MACsec na nowszych portach DX). Sam VPN jest również zalecanym szyfrowanym łączem zapasowym dla głównego połączenia Direct Connect, zapewniając odporność na awarie w przypadku uszkodzenia łącza.

• Tylko Direct Connect: niskie opóźnienia, prywatne, ale nieszyfrowane w warstwie IP.
• Tylko VPN: szyfrowane, szybkie do wdrożenia, ale z opóźnieniami i jitterem zależnymi od ścieżki internetowej.
• Direct Connect + VPN: niskie opóźnienia i szyfrowanie IPsec; jest to również standardowy wzorzec HA.

Grupy zabezpieczeń, NACL, DHCP i sprawdzanie źródła/przeznaczenia

Grupy zabezpieczeń (Security groups) są stanowe: jeśli zezwolisz na żądanie przychodzące, odpowiedź jest automatycznie przepuszczana na zewnątrz. Obsługują tylko reguły zezwalające (allow) i są ewaluowane na poziomie każdego ENI.

Sieciowe listy kontroli dostępu (NACL) są bezstanowe i działają na granicy podsieci. Każdy przepływ wymaga dwóch reguł — jednej dla kierunku początkowego i drugiej dla ruchu powrotnego w zakresie portów efemerycznych (Linux zazwyczaj 32768–60999, Windows 49152–65535, a NLB/ELB używają 1024–65535). NACL, który zezwala na przychodzący ruch TCP 443, ale zapomina o wychodzącym TCP 1024–65535, po cichu zepsuje działanie TLS. ICMP to nie TCP/UDP: pakiety zwrotne „echo reply” muszą być jawnie dozwolone, a mechanizm Path MTU Discovery opiera się na ICMP typ 3 kod 4, który łatwo jest nieumyślnie odrzucić. Reguły NACL są również ewaluowane w kolejności numerycznej, pierwsza pasująca reguła wygrywa, a na końcu znajduje się niejawna reguła odrzucająca (deny).

Zestawy opcji DHCP (DHCP option sets) kontrolują, co VPC przekazuje instancjom podczas uruchamiania: domain-name-servers, domain-name, serwery NTP, NetBIOS. Zastąpienie domyślnego AmazonProvidedDNS niestandardowym resolverem on-premises może być uzasadnione, ale ma realne konsekwencje dla bezpieczeństwa. Usługi takie jak GuardDuty generują swoje ustalenia oparte na DNS (np. wykrycia „kryptowalut” i „domen C&C”) na podstawie zapytań przechodzących przez Route 53 Resolver. Gdy tylko skierujesz instancje na serwer DNS innej firmy, GuardDuty przestaje widzieć zapytania, a te typy ustaleń znikają — to łatwy sposób na przypadkowe „oślepienie” systemów detekcji.

Sprawdzanie źródła/przeznaczenia (Source/destination checking) to atrybut ENI, który odrzuca każdy pakiet, którego źródłowy lub docelowy adres IP nie pasuje do ENI. To domyślne ustawienie jest poprawne dla zwykłych instancji, ale psuje działanie każdego urządzenia, którego zadaniem jest przekazywanie ruchu — instancji NAT, wirtualnych firewalli (Palo Alto, Fortinet, Check Point), routerów tranzytowych, koncentratorów VPN. Dla takich ENI należy wyłączyć to sprawdzanie:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC Peering, współdzielone VPC przez RAM i projektowanie NAT

VPC peering to połączenie jeden-do-jednego, nietranzytywne, na warstwie 3. Jeśli VPC A jest połączony z B, a B z C, to A nie może komunikować się z C — musisz bezpośrednio połączyć A z C lub użyć Transit Gateway. Tablice routingu po obu stronach muszą zawierać trasy do CIDR peera, a grupy bezpieczeństwa mogą odwoływać się do ID grup bezpieczeństwa peera tylko w obrębie jednego Regionu.

Współdzielone VPC za pomocą AWS Resource Access Manager (RAM) pozwalają kontu sieciowemu na posiadanie VPC i udostępnianie poszczególnych podsieci kontom uczestniczącym. Uczestnicy uruchamiają zasoby we współdzielonych podsieciach, ale nie mogą modyfikować VPC, tablic routingu ani punktów końcowych — właściciel zachowuje kontrolę nad polityką łączności. Jest to często tańsze i prostsze niż łączenie wielu VPC za pomocą peeringu.

Dla ruchu wychodzącego do internetu z prywatnych podsieci, wdróż bramkę NAT w każdej Strefie Dostępności i kieruj ruch z każdej prywatnej podsieci do bramki NAT w jej własnej AZ. Pojedyncza bramka NAT stanowi zależność między Strefami Dostępności oraz wąskie gardło pod względem skalowalności i dostępności. Gdy Twoje obciążenie robocze komunikuje się z usługą zewnętrzną, która wymaga dodania Twojego adresu IP do listy dozwolonych (np. procesor płatności), rejestrujesz adres Elastic IP bramki NAT. Ponieważ instancje w grupie Auto Scaling generują ruch wychodzący przez ten stały adres EIP, źródłowy adres IP nie zmienia się w miarę skalowania grupy. Umieszczenie instancji EC2 i bazy danych RDS w prywatnych podsieciach oraz kończenie połączeń HTTP/HTTPS tylko na ALB dopełnia ten wzorzec.

Route 53 Resolver: Przekierowywanie i logowanie zapytań

Route 53 Resolver (adres .2 w każdym VPC) jest centralnym punktem dla hybrydowego DNS. Wychodzące punkty końcowe resolvera przekazują zapytania o określone nazwy domen z AWS do lokalnych serwerów DNS za pomocą reguł warunkowego przekierowywania — używane na przykład, aby corp.example.internal było rozwiązywane przez Twoje Active Directory. Przychodzące punkty końcowe resolvera działają odwrotnie, udostępniając hostom lokalnym prywatny adres IP w Twoim VPC, pod który mogą wysyłać zapytania w celu rozwiązywania nazw *.eu-west-1.compute.internal oraz z Prywatnych Stref Hostowanych.

Logowanie zapytań resolvera zapisuje każde zapytanie DNS wykonane z VPC do CloudWatch Logs, S3 lub Kinesis Firehose. Jest to autorytatywny zapis do badania podejrzeń o eksfiltrację danych lub nadużycia i uzupełnia — ale nie zastępuje — GuardDuty. Pamiętaj, że jeśli zestaw opcji DHCP przekierowuje instancje do resolvera innego niż amazoński, zarówno logowanie zapytań, jak i ustalenia DNS z GuardDuty przestają działać, ponieważ zapytania nigdy nie trafiają do Route 53 Resolver.

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial zarządza wielokontowym środowiskiem AWS z siecią w topologii hub-and-spoke: współdzielone przez RAM VPC dla usług wspólnych hostuje centralne bramki NAT, punkty końcowe Route 53 Resolver oraz podłączenia Transit Gateway, podczas gdy wiele VPC aplikacyjnych jest połączonych za pomocą peeringu lub podłączonych do Transit Gateway. Lokalne centra danych łączą się przez Direct Connect z przełączaniem awaryjnym na VPN, a zespoły polegają na scentralizowanych zestawach opcji DHCP i współdzielonych punktach końcowych resolvera do hybrydowego rozwiązywania nazw DNS.

Wyzwanie: Niedawny incydent wykazał, że wrażliwe obiekty S3 były dostępne przez publiczny internet, ponieważ VPC typu spoke kierowały ruch do współdzielonej bramki NAT zamiast do punktów końcowych VPC. Zapytania DNS o strefy wewnętrzne wyciekały do publicznych resolverów, a instancja EC2 używana jako doraźny router (z wyłączoną weryfikacją źródła/celu) umożliwiła ruch boczny.

Zalecane podejście:

1. Wdróż Bramkowe punkty końcowe VPC dla S3 i DynamoDB oraz Interfejsowe punkty końcowe (AWS PrivateLink) dla Secrets Manager i KMS w VPC usług współdzielonych, dołączając jawne polityki punktów końcowych ograniczające dostęp do określonych bucketów i jednostek głównych usług.
2. Przeprojektuj architekturę NAT tak, aby podsieci aplikacyjne używały punktów końcowych VPC do komunikacji z API AWS i S3; zachowaj bramki NAT tylko dla rzeczywistego ruchu wychodzącego do internetu, z restrykcyjnymi grupami bezpieczeństwa dla ruchu wychodzącego i logami Flow Logs do CloudWatch/S3.
3. Włącz ponownie weryfikację źródła/celu na wszystkich instancjach EC2 z wyjątkiem udokumentowanych urządzeń routingowych; przenieś routing do podłączeń Transit Gateway lub zarządzanych instancji NAT i egzekwuj zasadę najmniejszych uprawnień w tablicach routingu.
4. Zaostrz konfigurację Grup Bezpieczeństwa i sieciowych list ACL podsieci do postawy domyślnego blokowania i zastosuj scentralizowane standardy bazowe dla IAM i grup bezpieczeństwa za pomocą SCPs w AWS Organizations oraz reguł AWS Config.
5. Wzmocnij hybrydowy DNS, wdrażając przychodzące/wychodzące punkty końcowe Route 53 Resolver, skonfiguruj warunkowe przekierowywanie i reguły DNS Firewall, włącz logowanie zapytań resolvera do CloudWatch Logs i użyj zestawów opcji DHCP, aby wymusić użycie wewnętrznych resolverów dla wszystkich VPC współdzielonych przez RAM.

Uzasadnienie: Takie podejście eliminuje niepotrzebny ruch wychodzący do internetu dzięki użyciu punktów końcowych VPC z politykami punktów końcowych, centralizuje i kontroluje routing za pomocą Transit Gateway/Direct Connect, przywraca ochronę na poziomie instancji oraz zapobiega wyciekom DNS za pomocą punktów końcowych resolvera i logowania — co jest zgodne z najlepszymi praktykami AWS w zakresie sieci i obrony w głąb.

Punkty końcowe VPC i polityki punktów końcowych

Punkty końcowe VPC pozwalają obciążeniom roboczym wewnątrz VPC na komunikację z API usług AWS bez przechodzenia przez publiczny internet lub bramę NAT. Istnieją dwa warianty architektoniczne, a wybór niewłaściwego jest częstym źródłem błędów w routingu.

• Bramkowe punkty końcowe: Używane tylko dla Amazon S3 i DynamoDB. Są implementowane jako cel w tabeli routingu (lista prefiksów pl-xxxxxxxx wskazująca na vpce-xxxxxxxx). Nie jest tworzony żaden interfejs ENI, nie są wymagane zmiany w DNS i nie ma kosztu godzinowego.

• Interfejsowe punkty końcowe (PrivateLink): Używane dla KMS, SQS, SNS, Secrets Manager, STS, EC2 API i większości innych usług. Udostępniają interfejsy ENI z prywatnymi adresami IP w wybranych podsieciach i są rozliczane za godzinę oraz za każdy GB transferu.

Dla międzykontowego zadania wsadowego, w którym instancje EC2 na Koncie B odczytują dane z bucketu S3 na Koncie A, zaszyfrowane kluczem KMS z Konta A, prawidłowym projektem jest bramkowy punkt końcowy dla S3 oraz interfejsowy punkt końcowy dla KMS. Bramkowy punkt końcowy utrzymuje ruch s3:GetObject, s3:PutObject, s3:PutObjectAcl i s3:ListBucket z dala od publicznego internetu; interfejsowy punkt końcowy robi to samo dla kms:Decrypt, kms:Encrypt i kms:GenerateDataKey. Ponieważ ARN klucza KMS używa standardowej nazwy hosta kms.<region>.amazonaws.com, interfejsowy punkt końcowy musi mieć włączoną opcję Prywatny DNS (Private DNS enabled), aby niezmieniona nazwa hosta z SDK była rozwiązywana na adres ENI punktu końcowego, a nie na publiczną usługę KMS. Bez Prywatnego DNS (lub bez włączonych na poziomie VPC opcji DNS hostnames i DNS resolution), klient wciąż trafiałby do publicznego punktu końcowego — stąd wymóg „braku zmian w kodzie” niejawnie wymusza użycie Prywatnego DNS.

Polityki punktów końcowych to druga, niezależna warstwa autoryzacji. Domyślnie istnieje liberalna polityka, ale jej wzmocnienie (hardening) dla konkretnego bucketu i klucza wygląda następująco:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Samo utworzenie punktu końcowego nie wystarczy. Powtarzają się dwa typowe błędy: (1) punkt końcowy istnieje, ale w tabeli routingu prywatnej podsieci brakuje wpisu dla listy prefiksów S3, więc ruch nadal wychodzi przez bramę NAT; (2) polityka punktu końcowego pomija akcję taką jak s3:PutObjectAcl lub wskazuje na zły ARN bucketu, po cichu blokując wywołania, na które w innym przypadku pozwoliłby IAM. Zarówno polityka bucketu, jak i polityka punktu końcowego muszą zezwalać na żądanie — ich uprawnienia są częścią wspólną (iloczynem logicznym), a nie sumą.

Grupy bezpieczeństwa, sieciowe listy ACL i szybkie ograniczanie zagrożeń

Grupy bezpieczeństwa i sieciowe listy ACL (NACL) rozwiązują podobne problemy na różnych warstwach, a egzamin często wymusza wybór między nimi w scenariuszach reagowania na incydenty.

• Grupy bezpieczeństwa: Stanowe, ewaluowane na poziomie ENI. Ruch powrotny jest automatycznie dozwolony. Istnieją tylko reguły zezwalające (allow). Idealne do polityk na poziomie hosta („warstwa webowa może komunikować się z warstwą aplikacyjną na porcie 8080”).

• Sieciowe listy ACL (NACL): Bezstanowe, ewaluowane na granicy podsieci. Istnieją zarówno reguły zezwalające (allow), jak i odmawiające (deny), przetwarzane w kolejności numerów. Idealne do zgrubnych blokad na poziomie całej podsieci — zwłaszcza do blokowania zakresu IP lub zamykania określonego portu dla wszystkich instancji w podsieci.

Gdy wybuch złośliwego oprogramowania zmusza do zablokowania wychodzącego ruchu TCP na porcie 2905 do zestawu adresów IP serwerów C2 (command-and-control) na wielu instancjach, reguła deny w NACL jest właściwym narzędziem. Grupy bezpieczeństwa nie potrafią wyrazić reguły deny i wymagałyby wyszukania i modyfikacji każdej grupy bezpieczeństwa używanej przez każdy dotknięty problemem interfejs ENI. Pojedyncza reguła deny w NACL na poziomie podsieci, z niskim numerem (np. 90), natychmiast obejmuje wszystkie instancje w tej podsieci, jednocześnie nie wpływając na niepowiązany ruch, który jest oceniany przez późniejsze reguły allow.

Ponieważ NACL są bezstanowe, należy pamiętać, że oba kierunki ruchu wymagają osobnych reguł. Zablokowanie ruchu wychodzącego na porcie 2905 nie wymaga reguły dla ruchu przychodzącego, ale jeśli chcesz również odrzucać odpowiedzi przychodzące, musisz dodać wpis dla ruchu przychodzącego — a także muszą istnieć reguły allow dla ruchu przychodzącego na portach efemerycznych (1024–65535), aby przepuścić legalny ruch powrotny.

Bramy NAT, routing i niezależność od Stref Dostępności

Brama NAT jest zasobem strefowym. Kanoniczny wzorzec to jedna brama NAT na każdą Strefę Dostępności (AZ), gdzie tabela routingu każdej prywatnej podsieci kieruje ruch 0.0.0.0/0 do bramy NAT w tej samej strefie AZ:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Jedna brama NAT współdzielona między strefami AZ wydaje się tańsza, ale wprowadza dwa problemy: opłaty za transfer danych między strefami AZ naliczane dla każdego pakietu oraz twardą zależność od dostępności — jeśli ta strefa AZ ulegnie awarii, każda prywatna podsieć traci wyjście do internetu. Wzorzec ze strefowymi bramami NAT pozwala również uniknąć anomalii związanych z asymetrycznym routingiem powrotnym w połączeniu z inspekcją ruchu przez Transit Gateway (patrz niżej).

Dzienniki przepływu VPC (VPC Flow Logs) do celów dochodzeniowych

Dzienniki przepływu (Flow Logs) przechwytują metadane 5-krotki (źródłowy/docelowy adres IP, port, protokół, akcja ACCEPT/REJECT, bajty, pakiety) na poziomie VPC, podsieci lub ENI. Aby wytropić instancje komunikujące się z serwerami C2 na porcie TCP/2905, włącz Flow Logs na poziomie VPC z typem ruchu ustawionym na REJECT (ponieważ NACL odrzuca teraz ten ruch) i wykonaj zapytanie w CloudWatch Logs Insights lub Athena:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

Kolumna srcaddr ujawnia adresy IP zainfekowanych instancji przy minimalnym wysiłku — bez przechwytywania pakietów i bez agentów na hostach. Wybór typu ruchu „ALL” zadziała, ale wygeneruje więcej danych i kosztów; wybór tylko „ACCEPT” spowodowałby całkowite pominięcie odrzuconych prób, czyli dokładnie tego, co chcesz zobaczyć.

PrivateLink, Transit Gateway i Network Firewall

PrivateLink rozszerza model interfejsowego punktu końcowego na Twoje własne usługi: VPC dostawcy (provider VPC) udostępnia NLB za pośrednictwem usługi punktu końcowego VPC, a konsumenci tworzą interfejsowe punkty końcowe, aby się z nim połączyć bez konieczności peeringu VPC czy udostępniania tras. Jest to połączenie jednokierunkowe i całkowicie ukrywa CIDR dostawcy.

Transit Gateway (TGW) to hub zapewniający łączność typu wiele-do-wielu dla VPC i środowisk on-premises. Powszechnym wzorcem jest scentralizowany inspekcyjny VPC, w którym działa AWS Network Firewall lub urządzenia firm trzecich, a tablice routingu TGW kierują ruch między szprychami (spoke-to-spoke) przez ten inspekcyjny VPC. Ten projekt zawodzi przy domyślnym zachowaniu TGW, ponieważ TGW hashuje przepływy pomiędzy dołączonymi interfejsami ENI w różnych Strefach Dostępności (AZ), a ścieżka powrotna może wejść do innej strefy AZ niż ścieżka wychodząca. Zapory sieciowe ze stanem (stateful) odrzucają pakiety w środku przepływu, dla których nigdy nie widziały pakietu SYN.

Wymagane są dwie jednoczesne poprawki. Po pierwsze, włącz tryb urządzenia (Appliance Mode) na załączniku TGW dla inspekcyjnego VPC; przypina to każdy dwukierunkowy przepływ do tego samego ENI w danej strefie AZ, dzięki czemu ruch wychodzący i powrotny przechodzi przez ten sam punkt końcowy zapory sieciowej. Po drugie, skonfiguruj tablice routingu TGW tak, aby załączniki typu spoke wysyłały ruch do załącznika inspekcyjnego VPC, a osobna tablica routingu po inspekcji w inspekcyjnym VPC kierowała ruch z powrotem do właściwego spoke’a. Pominięcie któregokolwiek z tych kroków — samego trybu urządzenia bez tablic routingu lub samych tablic routingu bez trybu urządzenia — pozostawia problem asymetrycznego odrzucania pakietów.

Sam Network Firewall używa reguł kompatybilnych z Suricata i jest zależny od routingu symetrycznego, aby utrzymać stan przepływu; połączenie go z Flow Logs zarówno w inspekcyjnym VPC, jak i w VPC typu spoke, dostarcza śladu forensycznego potrzebnego do udowodnienia, który spoke zainicjował sesję i czy zapora sieciowa na nią zezwoliła, czy ją odrzuciła.

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial zarządza wielokontowym środowiskiem AWS z produkcyjnymi VPC w trzech Strefach Dostępności w regionie us-east-1, połączonymi za pomocą AWS Transit Gateway z centralnym VPC ds. bezpieczeństwa. Używają bram NAT (NAT Gateways) w każdej strefie AZ do ruchu wychodzącego, bramowych punktów końcowych S3 (S3 Gateway Endpoints) i interfejsowych punktów końcowych (PrivateLink) dla usług SaaS partnerów, a także scentralizowanego AWS Network Firewall obok grup bezpieczeństwa (Security Groups) i list NACL; logi VPC Flow Logs są przesyłane do CloudWatch w celu monitorowania.

Wyzwanie: Istnieje podejrzenie, że produkcyjna instancja EC2 podejmowała próby ruchu bocznego (lateral movement) i eksfiltracji danych na zewnętrzny adres IP oraz do S3. Meridian potrzebuje szybkiego powstrzymania zagrożenia we wszystkich strefach AZ bez zakłócania działania innych krytycznych dla biznesu VPC.

Zalecane podejście:

1. Natychmiast poddaj skompromitowaną instancję kwarantannie, zastępując jej grupy bezpieczeństwa restrykcyjną grupą „kwarantannową”, która blokuje cały ruch wychodzący i przychodzący, oraz oznacz instancję tagiem w celu automatycznej naprawy za pomocą Systems Manager; jednocześnie zastosuj reguły na poziomie podsieci w listach ACL (Network ACL), aby zablokować ruch wychodzący do podejrzanych zewnętrznych zakresów IP.
2. Izoluj VPC w Transit Gateway, usuwając lub zmieniając załącznik tablicy routingu TGW dla dotkniętego VPC na kwarantannową tablicę routingu TGW (typu blackhole lub bez tras do innych załączników), zatrzymując ruch boczny do innych VPC.
3. Przekieruj pozostały ruch wychodzący z VPC przez scentralizowany AWS Network Firewall, aktualizując wpisy w TGW i tablicach routingu, aby wymusić inspekcję i zablokować znane złośliwe miejsca docelowe, zachowując niezależność stref AZ poprzez utrzymanie bram NAT w każdej strefie dla odpornego, poddanego inspekcji ruchu wychodzącego.
4. Wzmocnij kontrole na płaszczyźnie danych, stosując restrykcyjne polityki punktów końcowych VPC (VPC Endpoint policies) na bramowych punktach końcowych S3/DynamoDB, aby odmawiać operacji Put/Get od niezatwierdzonych podmiotów (principals) i upewnić się, że wewnętrzne API używają interfejsowych punktów końcowych (PrivateLink), aby unikać ścieżek internetowych.
5. Użyj VPC Flow Logs z CloudWatch Logs Insights i AWS CloudTrail do przeprowadzenia analizy forensycznej, a następnie napraw (ponowne wgranie obrazu, rotacja kluczy) i przywróć instancję do działania dopiero po walidacji; egzekwuj reguły za pomocą AWS Firewall Manager/AWS Config.

Uzasadnienie: Ta sekwencja zapewnia szybkie powstrzymanie zagrożenia na zasadzie minimalnych uprawnień, zarówno na warstwie hosta, jak i sieci, centralizuje inspekcję za pomocą Network Firewall i routingu Transit Gateway w celu minimalizacji promienia rażenia, zachowuje odporność na poziomie stref AZ dzięki bramom NAT w każdej strefie i wykorzystuje VPC Flow Logs do odpowiedzialnego dochodzenia — co jest zgodne z najlepszymi praktykami AWS w zakresie obrony w głąb (defense-in-depth).

← Ochrona danych i S3 · Wszystkie domeny · Bezpieczeństwo Edge i aplikacji →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →