Amazon ANS-C01: Bezpieczeństwo sieci i zgodność — Przewodnik do nauki

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

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

Koncepcja podstawowa

Bezpieczeństwo sieciowe w AWS jest warstwowe: kontrole na brzegu sieci (perimeter), kontrole na poziomie VPC, kontrole na poziomie hosta i aplikacji oraz monitorowanie/inspekcja. Na granicy VPC używasz grup bezpieczeństwa (stateful, wirtualne zapory sieciowe zorientowane na hosta, stosowane do ENI) oraz sieciowych list ACL (stateless, filtrowanie na poziomie podsieci, oceniane według numeru reguły), aby egzekwować ogólne kontrole dostępu. Grupy bezpieczeństwa śledzą stan połączenia, dzięki czemu ustanowiony przepływ odpowiedzi jest automatycznie dozwolony, co czyni je idealnymi do zezwalania na połączenia inicjowane przez klienta do podów lub instancji. NACL wymagają jawnych wpisów zezwalających w obu kierunkach lub komplementarnych reguł dla ruchu powrotnego; są one oceniane w porządku rosnącym numerów reguł i dlatego są odpowiednie do ogólnego wzmacniania bezpieczeństwa na poziomie podsieci, takiego jak eliminowanie całych zakresów CIDR lub stosowania tymczasowych „furtek” dla list blokujących w sytuacjach awaryjnych.

Inspekcja i scentralizowane egzekwowanie polityk są zapewniane przez usługi zarządzane i samoobsługowe. AWS Network Firewall może implementować stanowe zabezpieczenia w stylu Suricata, filtrowanie list domen oraz sygnatury w stylu prewencji przed włamaniami (intrusion-prevention) na brzegu VPC za pomocą jawnych polityk zapory i grup reguł. Web Application Firewall (AWS WAF) koncentruje się na aplikacji w celu ochrony warstwy HTTP(S) i integruje się z Application Load Balancer, Amazon CloudFront i API Gateway, aby egzekwować zabezpieczenia OWASP, reguły oparte na częstotliwości zapytań (rate-based) i niestandardowe sprawdzanie nagłówków. Ochrona przed atakami DDoS jest zapewniana przez AWS Shield (wersja Standard jest automatyczna i bezpłatna; Shield Advanced zapewnia inżynierię ruchu, ochronę kosztów i integrację z WAF w celu mitygacji na warstwie aplikacji). Usługi detekcji, takie jak Amazon GuardDuty, analizują VPC Flow Logs, logi DNS i CloudTrail, aby ujawnić rekonesans, skanowanie portów i zachowanie naruszonych instancji.

Widoczność i przechwytywanie pakietów uzupełniają ten model. VPC Flow Logs rejestrują metadane przepływu dla każdego ENI i mogą być dostarczane do CloudWatch Logs, Amazon S3 lub Kinesis Data Firehose w celu analizy za pomocą Athena. W celu pełnego przechwytywania pakietów lub głębszej inspekcji, Traffic Mirroring umożliwia kopiowanie ruchu z ENI do urządzenia IDS/przechwytującego pakiety (sensor EC2 z lustrzanym ENI lub cel Network Load Balancer), gdzie działają narzędzia takie jak Suricata czy Zeek. Razem, te mechanizmy kontroli umożliwiają stworzenie postawy obrony w głąb (defense-in-depth), w której obecne są prewencja, detekcja i analiza śledcza (forensics).

Kluczowe usługi i konfiguracja

Kilka usług AWS ma kluczowe znaczenie dla bezpieczeństwa sieci, a każda z nich ma specyficzne wzorce konfiguracji i API, które należy znać:

• Security Groups
• Network ACLs (NACLs)
• AWS Network Firewall
• AWS WAF
• AWS Shield (Standard i Advanced)
• Amazon GuardDuty
• VPC Flow Logs
• Traffic Mirroring

Grupy bezpieczeństwa są konfigurowane dla każdego ENI za pośrednictwem EC2 API lub konsoli; aby dodać regułę przychodzącą (ingress), użyj

undefined

. Pamiętaj, aby używać zakresów CIDR o najmniejszych uprawnieniach i dołączać oddzielne grupy bezpieczeństwa dla load balancerów i podów backendowych, aby unikać zbyt szerokich reguł. Twórz NACL za pomocą

undefined

i dodawaj ponumerowane wpisy za pomocą

undefined

, określając numer reguły, akcję reguły, protokół, zakres portów i flagę ruchu wychodzącego (egress).

AWS Network Firewall używa grup reguł i polityk zapory sieciowej powiązanych z zasobem zapory utworzonym w podsieci VPC. Użyj polecenia

undefined

do definiowania reguł stateless lub stateful,

undefined

do ich komponowania, a

undefined

do wdrożenia. Wybierz stanowe grupy reguł dla inspekcji świadomej protokołu i reguł sygnatur kompatybilnych z Suricata; użyj reguł bezstanowych (stateless) do filtrowania o bardzo wysokiej przepustowości i wstępnej selekcji.

AWS WAF dołącza Web ACL do ALB i może egzekwować dopasowania zestawów IP, dopasowania ciągów znaków w nagłówkach lub reguły oparte na częstotliwości zapytań (rate-based). Użyj

undefined

i określ reguły sprawdzające nagłówki (na przykład blokujące żądania, które nie zawierają niestandardowego nagłówka wstawianego na zaufanym wejściu do systemu). AWS Shield Advanced jest włączany na poziomie konta i zapewnia dostęp do zespołu reagowania na ataki DDoS oraz dodatkową ochronę dla zasobów zarejestrowanych w Shield Advanced.

Włącz GuardDuty za pomocą

undefined

i integruj ustalenia z CloudWatch Events lub EventBridge w celu automatyzacji. W celu telemetrii, utwórz VPC Flow Logs za pomocą

undefined

. Do przechwytywania pakietów użyj poleceń

undefined

,

undefined

i

undefined

, aby skierować kopiowany ruch do ENI urządzenia lub NLB.

Wzorce projektowe i kompromisy

Szyfrowanie end-to-end z wzajemnym uwierzytelnianiem TLS (mutual TLS), w którym system równoważenia obciążenia nie może kończyć sesji TLS, wymaga wzorca przekazywania na warstwie 4 (Layer 4 pass-through). Użyj Network Load Balancer (NLB) przed podami backendowymi, aby sesja TLS była negocjowana bezpośrednio z punktami końcowymi usługi. W Kubernetes na EKS, wdróż Service typu LoadBalancer oparty na NLB i zarejestruj pody jako cele (targets) po adresie IP; AWS Load Balancer Controller lub starsze adnotacje Service zapewniają, że typem celu jest IP, a protokołem grupy docelowej jest TCP. W przypadku dużej współbieżności, charakterystycznej dla gRPC i wielu długotrwałych połączeń HTTP/2, NLB zachowuje źródłowe adresy IP i narzuca mniejszy narzut na połączenie niż proxy L7. Jeśli wymagane jest zakończenie sesji TLS na ALB (np. do routingu opartego na URL), musisz zakończyć sesję TLS na ALB przy użyciu certyfikatu ACM, a następnie przekierować ruch do backendów; zachowaj IP klienta, opierając się na nagłówku X-Forwarded-For (ALB) lub używając NLB obsługującego Proxy Protocol v2 dla backendów, które potrzebują oryginalnego źródłowego adresu IP na warstwie L4.

Dla skalowalnych architektur wielokontowych i wielo-VPC, gdzie wymagane są centralne usługi, PrivateLink (AWS VPC Endpoint Services) jest najbezpieczniejszym i najbardziej skalowalnym wyborem. Udostępnij centralne usługi z VPC usług współdzielonych (shared-services VPC) jako usługę punktu końcowego AWS PrivateLink. Każde konto konsumenckie tworzy interfejsowy punkt końcowy VPC (interface VPC endpoint) do tej usługi; właściciel usługi może wymagać akceptacji punktu końcowego i stosować kontrole oparte na grupach bezpieczeństwa (security groups) na interfejsach ENI punktu końcowego. Ten model utrzymuje ruch w sieci AWS, unika limitów skalowalności peeringu i zapewnia granularne bezpieczeństwo dla każdego konsumenta. Transit Gateway z segmentacją i Network Firewall mogą być używane do tranzytu na poziomie sieci i centralnej inspekcji, ale jest to bardziej odpowiednie, gdy wymagana jest pełna routowalna łączność ze złożonymi politykami routingu, a nie izolacja per usługa.

Podczas diagnozowania zużycia przepustowości na wielu interfejsach VIF w Direct Connect, w pierwszej kolejności skup się na metadanych: włącz i odpytuj VPC Flow Logs agregowane do S3 lub CloudWatch i analizuj za pomocą Athena, aby zmapować przepływy IP o dużej objętości do konkretnych VPC i podsieci. Uzupełnij flow logs metrykami CloudWatch dla wirtualnych interfejsów Direct Connect, a jeśli potrzebujesz inspekcji na poziomie zawartości (payload) lub obsługi heterogenicznych protokołów, wdróż Traffic Mirroring, aby przechwytywać pakiety do systemu IDS opartego na EC2. Traffic Mirroring jest zasobożerny i generuje koszty; używaj go tylko w sesjach/oknach czasowych, w których flow logs i wyniki z GuardDuty są niewystarczające.

Typowe pułapki i kryteria decyzyjne

Częstym błędem jest poleganie wyłącznie na grupach bezpieczeństwa (security groups) w celu ogólnego zabezpieczenia obwodu sieci i niestosowanie NACL lub Network Firewall tam, gdzie wymagana jest kontrola na poziomie podsieci lub inspekcja stanowa. Grupy bezpieczeństwa działają na poziomie ENI i są łatwe w zarządzaniu, ale nie skalują się dobrze jako scentralizowana płaszczyzna kontroli dla wielu VPC na różnych kontach; użyj AWS Firewall Manager, aby scentralizować reguły WAF i Network Firewall na wszystkich kontach. Kolejną pułapką jest kończenie sesji TLS na load balancerze bez uwzględnienia zachowania adresu IP klienta; ALB wstawia nagłówki X-Forwarded-For, ale logowanie aplikacji musi jawnie odczytywać ten nagłówek i należy ustanowić zaufanie (np. tylko ALB powinien go wysyłać). Aby uzyskać pewność, że tylko Global Accelerator może komunikować się z ALB, unikaj polegania wyłącznie na DNS; zamiast tego ogranicz listenery ALB za pomocą grup bezpieczeństwa do opublikowanych zakresów IP akceleratora (automatyzuj aktualizacje za pomocą pliku ip-ranges.json lub zarządzanych list prefiksów) lub, jeśli to możliwe, użyj wewnętrznego ALB i umieść go za punktem końcowym akceleratora.

Decydując między PrivateLink a Transit Gateway, należy rozważyć granularność usług w porównaniu z pełnym routingiem w topologii siatki (full-mesh). PrivateLink zapewnia kontrolę dostępu na poziomie pojedynczej usługi z filtrowaniem na poziomie grup bezpieczeństwa i skaluje się bez gwałtownego rozrostu tablic routingu; Transit Gateway jest niezbędny, gdy potrzebujesz łączności opartej na routingu między wieloma VPC i sieciami on-premises oraz gdy wymagasz scentralizowanej inspekcji pakietów za pomocą AWS Network Firewall. Aby uzyskać wysoką przepustowość, preferuj bezstanowe (stateless) reguły Network Firewall na obwodzie sieci, połączone z ukierunkowanymi grupami reguł stanowych (stateful) dla krytycznych przepływów; przetwarzanie bezstanowe skaluje się, ale traci świadomość protokołu.

Praktyczny problem: Scenariusz użycia

Nazwa firmy: Meridian Payments — wyzwanie: uruchomienie API płatności opartego na gRPC w usłudze EKS, wymagającego wzajemnego uwierzytelniania TLS end-to-end (bez kończenia sesji TLS po drodze), obsługa tysięcy jednoczesnych, długotrwałych połączeń, autoskalowanie podów oraz identyfikacja źródłowych adresów IP klientów na potrzeby logowania i wykrywania oszustw.

1. Podejście: Wdróż Amazon Network Load Balancer przed usługą EKS skonfigurowaną z typem celu (target type) IP, aby ENI podów były rejestrowane bezpośrednio w grupach docelowych (target groups) NLB. Użyj AWS Load Balancer Controller do stworzenia usługi (Service) wspieranej przez NLB z adnotacjami, aby upewnić się, że protokołem grupy docelowej jest TCP na porcie 443, a sprawdzanie kondycji (health checks) również używa TCP. Zakończ sesję mTLS na podach backendowych; skonfiguruj Istio lub bibliotekę TLS w kontenerze sidecar, jeśli potrzebujesz standardowej rotacji certyfikatów, używając Kubernetes Secrets zasilanych z AWS Certificate Manager Private Certificate Authority lub AWS Secrets Manager. Zachowaj adresy IP klientów, ponieważ NLB zachowuje źródłowy adres IP; upewnij się, że reguły networkPolicy i grup bezpieczeństwa podów backendowych zezwalają na ruch z zakresów źródłowych NLB/klientów. Użyj HPA i Cluster Autoscaler do skalowania podów; upewnij się, że opóźnienie wyrejestrowania celu (target group deregistration delay) jest dostosowane, aby umożliwić płynne opróżnianie połączeń (graceful connection draining).

2. Podejście do obserwowalności i analizy śledczej: Włącz VPC Flow Logs dla VPC klastra EKS do CloudWatch Logs i agreguj dane w S3 za pomocą Kinesis Firehose w celu przechowywania i wykonywania zapytań w Athena mapujących przepływy o dużej przepustowości. Włącz GuardDuty do wykrywania anomalii w przepływach VPC i zapytaniach DNS. Jeśli podczas okresów podejrzenia oszustwa wymagana jest głębsza inspekcja pakietów, utwórz sesje Traffic Mirror na problematycznych ENI, kierując ruch do sensora na instancji EC2 z uruchomionym oprogramowaniem Suricata; zarządzaj filtrami mirror, aby przechwytywać tylko istotny ruch w celu ograniczenia kosztów.

Uzasadnienie z perspektywy AWS: NLB zapewnia przekazywanie ruchu na warstwie 4 (L4 pass-through), dzięki czemu negocjacje TLS i mTLS odbywają się end-to-end, a backend widzi prawdziwy adres IP klienta. Spełnia to wymóg, aby ruch nie był deszyfrowany przez pośredniczące proxy oraz aby logowanie i analiza oszustw widziały oryginalne źródło. Rejestrowanie podów po adresie IP i użycie AWS Load Balancer Controller integruje się z autoskalowaniem EKS. Usługi VPC Flow Logs, GuardDuty i Traffic Mirroring zapewniają stopniowaną widoczność, od metadanych po pełne przechwytywanie pakietów, co umożliwia skalowalne, efektywne kosztowo zapewnienie zgodności i reagowanie na incydenty.

← Równoważenie obciążenia i zarządzanie ruchem · Wszystkie domeny · Dostarczanie treści i sieci brzegowe →

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

Przeglądaj Amazon →