Amazon SCS-C02: Bezpieczeństwo Edge i aplikacji — Przewodnik do nauki
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.
Ograniczenia geograficzne (Geo Restriction) i blokowanie na poziomie kraju w CloudFront
CloudFront oferuje dwa mechanizmy blokowania ruchu według kraju, a wybór między nimi ma znaczenie dla kosztów i funkcjonalności. Wbudowana funkcja ograniczeń geograficznych (nazywana również geoblokowaniem) jest konfigurowana bezpośrednio w dystrybucji i ocenia żądania na brzegu sieci (edge) na podstawie listy dozwolonych lub zablokowanych krajów, określonych na podstawie adresu IP użytkownika. Jest to bezpłatne, nie wymaga ewaluacji reguł i zwraca kod HTTP 403 przed jakimkolwiek zapytaniem do źródła (origin). W przypadku prostych scenariuszy zgodności — „zablokuj odwiedzających z kraju X” — jest to najtańsza i najprostsza opcja.
Alternatywą jest instrukcja WAF geo match, która jest bardziej elastyczna: można łączyć dopasowania krajów ze ścieżkami URI, nagłówkami, limitami zapytań (rate limits) lub je negować („zezwalaj na kraj A tylko dla /admin”). WAF jest wymagany, gdy logika jest warunkowa; samo ograniczenie geograficzne nie jest w stanie wyrazić warunku „zablokuj kraj X tylko dla określonej ścieżki”. Wybierz natywne ograniczenie geograficzne, gdy wymogiem jest bezwarunkowe blokowanie kraju i chcesz uniknąć kosztów za każde zapytanie w WAF.
Podpisane adresy URL a podpisane pliki cookie dla prywatnej zawartości
CloudFront wspiera dwa sposoby dostarczania autoryzowanej, prywatnej zawartości, jednocześnie ukrywając źródło (bucket S3, ALB lub źródło Media) za pomocą origin access control lub niestandardowego nagłówka:
Podpisane adresy URL: każdy adres URL zawiera podpis i politykę. Idealne do pobierania pojedynczego pliku lub gdy potrzebujesz kontroli dostępu na poziomie pliku (np. jednorazowy link do instalatora oprogramowania).
Podpisane pliki cookie: klient otrzymuje zestaw plików cookie
CloudFront-Policy,CloudFront-SignatureiCloudFront-Key-Pair-Idjednorazowo od Twojej usługi uwierzytelniającej. Wszystkie kolejne żądania do pasujących wzorców ścieżek są automatycznie autoryzowane bez konieczności przepisywania adresów URL.
W przypadku strumieniowania wideo HLS, gdzie jedna sesja odtwarzania pobiera tysiące segmentów .ts odwołujących się do manifestu, podpisane pliki cookie są znacznie prostsze. Przepisywanie każdego adresu URL segmentu w manifeście z odrębnym, podpisanym adresem URL jest możliwe, ale dodaje opóźnień i złożoności. Ustaw plik cookie po uwierzytelnieniu subskrybenta w Twojej wewnętrznej bazie użytkowników, ograniczając jego zakres do wzorca ścieżki strumieniowania.
Kanoniczna polityka dla podpisanego pliku cookie z użyciem wildcards wygląda następująco:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Połącz to z origin access control (OAC) lub sekretnym, niestandardowym nagłówkiem walidowanym przez WAF na serwerze źródłowym (origin), aby użytkownicy nie mogli ominąć CloudFront i odwoływać się bezpośrednio do źródła.
AWS WAF: Zarządzane reguły, ATP i reguły oparte na częstotliwości (Rate-Based Rules)
Dołącz Web ACL do dystrybucji CloudFront, a nie do regionalnego ALB, gdy obciążenie robocze znajduje się za CloudFront. Dołączenie na brzegu sieci (edge) zatrzymuje złośliwe żądania w jednym z setek punktów obecności (POP) — bliżej atakującego — co zmniejsza obciążenie źródła podczas ataków DDoS i obniża ruch wychodzący (egress) ze źródła, ponieważ zablokowany ruch nigdy nie przechodzi przez Twoją sieć VPC. Dołączenie WAF tylko do ALB oznacza, że atak wolumetryczny wciąż dociera do regionalnego load balancera i zużywa jednostki LCU, a ataki międzyregionalne są obsługiwane przez jeden region, a nie przez globalną sieć brzegową.
Kluczowe grupy reguł do połączenia:
Zarządzane zestawy reguł AWS:
AWSManagedRulesCommonRuleSet(w stylu OWASP Top 10),AWSManagedRulesKnownBadInputsRuleSetiAWSManagedRulesAmazonIpReputationListzapewniają szeroką ochronę przy prawie zerowym nakładzie pracy na dostrajanie.Account Takeover Prevention (ATP):
AWSManagedRulesATPRuleSetinspekcjonuje wskazany przez Ciebie punkt końcowy logowania, śledzi wzorce ataków typu credential stuffing, sprawdza przesłane poświadczenia w bazie danych naruszonych poświadczeń i blokuje boty ponownie wykorzystujące ujawnione hasła. Skonfiguruj go, podając dokładną ścieżkę logowania oraz nazwy pól w ciele JSON dla nazwy użytkownika i hasła.Reguły oparte na częstotliwości (rate-based): ograniczają liczbę żądań z jednego adresu IP w 5-minutowym oknie (na przykład 2000 żądań). Ogranicz ich zakres do URI lub metody, aby scraping ścieżki
/searchnie wpływał na anonimowe przeglądanie/. Reguły oparte na częstotliwości łagodzą ataki wolumetryczne na warstwę 7 i enumerację metodą brute-force.
Skrócony blok reguł WAF:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
Certyfikaty ACM, walidacja DNS i CloudFront
Dla CloudFront certyfikat musi być utworzony w ACM w regionie us-east-1 (N. Virginia), niezależnie od tego, gdzie znajduje się Twoje źródło — jest to ścisły wymóg, ponieważ CloudFront jest usługą globalną, która odczytuje certyfikaty z tego właśnie regionu. Usługi regionalne, takie jak ALB, odczytują certyfikaty z własnego regionu ALB.
Zawsze używaj walidacji DNS z rekordem CNAME w Route 53 dla każdego publicznego certyfikatu, który chcesz automatycznie odnawiać. ACM automatycznie odnawia certyfikaty walidowane przez DNS, o ile rekord CNAME walidacji pozostaje opublikowany; Route 53 sprawia, że jest to trywialne (konsola oferuje opcję „Utwórz rekordy w Route 53” podczas składania wniosku). Walidacja przez e-mail, w przeciwieństwie do tego, wysyła potwierdzenie na pięć adresów w domenie (admin@, administrator@, hostmaster@, postmaster@, webmaster@) oraz do kontaktu WHOIS. Te skrzynki pocztowe często nie istnieją lub są poddawane kwarantannie przez korporacyjne filtry poczty, więc odnowienia kończą się niepowodzeniem 60 dni przed wygaśnięciem i powodują awarie, którym można było zapobiec. Nie ma sposobu na zautomatyzowanie kliknięć w linki walidacyjne w e-mailach.
Prawidłowy wzorzec odnawiania dla wieloregionalnych ALB to: zażądaj certyfikatu ACM walidowanego przez DNS w każdym regionie, opublikuj rekord CNAME walidacji w Route 53 raz, dołącz certyfikat do listenera ALB i pozwól ACM zająć się odnowieniem i wdrożeniem. Udział człowieka kończy się na etapie wydania certyfikatu.
DNSSEC i Route 53
Włącz podpisywanie DNSSEC w strefie hostowanej (hosted zone) w Route 53, aby zapobiegać fałszowaniu DNS (DNS spoofing) i zatruwaniu pamięci podręcznej (cache poisoning) w Twojej domenie. Route 53 zarządza kluczem KSK w KMS (asymetryczny klucz ECC w us-east-1); musisz opublikować rekord DS u rejestratora domeny. Zauważ, że podpisywanie DNSSEC chroni proces rozwiązywania nazw w Twojej strefie — nie szyfruje ruchu DNS (do tego służą DoH/DoT) i nie wpływa na TLS w CloudFront.
Nagłówki odpowiedzi: Polityki kontra Lambda@Edge
CloudFront nie wstrzykuje automatycznie nagłówków bezpieczeństwa, takich jak Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options czy Content-Security-Policy. Jeśli Twoje źródło (origin) nie może być modyfikowane (starsza strona S3, źródło zewnętrzne), masz dwie opcje:
Polityka nagłówków odpowiedzi (response headers policy): natywna, deklaratywna funkcja CloudFront. Dołącz zarządzaną lub niestandardową politykę do zachowania pamięci podręcznej (cache behavior), aby dodać nagłówki HSTS, CORS, nagłówki bezpieczeństwa i niestandardowe. To powinno być domyślne rozwiązanie — bez kodu, bez zimnych startów, bez kosztów za wywołanie.
Lambda@Edge (viewer response lub origin response): użyj, gdy potrzebujesz dynamicznej logiki, takiej jak zmienne wartości nonce CSP dla każdego żądania lub przepisywanie nagłówków na podstawie atrybutów żądania. Wymienia prostotę na elastyczność i dodaje koszt za każde żądanie.
Zarządzana polityka nagłówków odpowiedzi SecurityHeadersPolicy obejmuje powszechne podstawowe zabezpieczenia w jednym załączniku.
Wyjaśnienie typowych pułapek
Żądanie publicznych certyfikatów ACM z walidacją przez e-mail jest kruche, ponieważ odnowienie zależy od ludzi odczytujących wiadomości wysyłane na ogólne adresy, których większość organizacji nie monitoruje lub które są kierowane do spamu. Walidacja DNS za pomocą Route 53 całkowicie eliminuje czynnik ludzki.
Dołączanie WAF tylko do ALB na papierze wygląda równoważnie, ale zmusza ruch związany z atakiem do wejścia do Twojego regionu i zużywa zasoby ALB. WAF dołączony na brzegu sieci (edge) do CloudFront blokuje ruch w setkach punktów obecności (POP), dzięki czemu rozproszony atak jest absorbowany globalnie, a ruch wychodzący ze źródła (origin egress) pozostaje niski — co jest kluczowe podczas ataku DDoS.
Zakładanie, że CloudFront automatycznie dodaje nagłówki bezpieczeństwa, prowadzi do nieudanych testów penetracyjnych. Dystrybucja przekazuje (proxy) te nagłówki, które wysyła źródło; musisz jawnie dołączyć politykę nagłówków odpowiedzi lub funkcję Lambda@Edge, aby wstrzyknąć X-Frame-Options: DENY, HSTS i CSP.
Problem praktyczny: Scenariusz użycia
Scenariusz: Meridian Financial prowadzi globalnie rozproszony portal klienta oraz wewnętrzny portal z raportami na AWS. Ruch publiczny jest kierowany przez Amazon CloudFront do Application Load Balancers dla dynamicznych API oraz do źródeł S3 dla prywatnych raportów; DNS znajduje się w Route 53, a certyfikaty TLS są wydawane przez AWS Certificate Manager (ACM).
Wyzwanie: Atakujący przeprowadzają scraping i credential stuffing na kontach z kilku krajów, omijając CloudFront przez bezpośrednie odpytywanie punktów końcowych źródeł (origin endpoints) w celu pobrania prywatnych raportów, co powoduje przeciążenie źródeł i wyciek danych.
Zalecane podejście:
- Skonfiguruj CloudFront jako jedyny publiczny punkt wejścia i zastosuj CloudFront Geo Restriction, aby zablokować kraje-źródła ataków; włącz Origin Access Control (OAC) i zablokuj polityki źródeł S3/ALB, aby tylko CloudFront mógł pobierać zawartość ze źródeł.
- Serwuj prywatne raporty dla poszczególnych użytkowników za pomocą podpisanych adresów URL CloudFront (z krótkim TTL) zamiast podpisanych plików cookie, aby każde pobranie było indywidualnie autoryzowane i możliwe do audytu.
- Dołącz AWS WAF do dystrybucji CloudFront, używając AWS Managed Rules, włącz AWS WAF Bot Control (zaawansowana ochrona przed zagrożeniami) i utwórz reguły oparte na częstotliwości (rate-based rules) oraz wyzwania CAPTCHA, aby ograniczyć scraping i credential stuffing.
- Dostarcz certyfikaty TLS w ACM (w regionie us-east-1 dla dystrybucji CloudFront) używając walidacji DNS przez Route 53 i opublikuj rekordy Route 53 Alias wskazujące na dystrybucję CloudFront.
- Włącz DNSSEC w strefie hostowanej (hosted zone) Route 53, włącz logi dostępowe CloudFront i WAF do S3 oraz utwórz alarmy CloudWatch i opcjonalnie AWS Shield Advanced w celu zapewnienia widoczności i alertów dotyczących ataków DDoS.
Uzasadnienie: Wymuszenie całego ruchu przez CloudFront z OAC i WAF egzekwuje zasadę najmniejszych uprawnień (least-privilege) dla dostępu do źródeł, Geo Restriction i zabezpieczenia oparte na częstotliwości/WAF zatrzymują szkodliwy ruch, podpisane adresy URL zapewniają autoryzację na poziomie obiektu, a ACM+walidacja DNS z DNSSEC gwarantuje zaufaną integralność TLS i DNS zgodnie z najlepszymi praktykami AWS.
Reguły AWS WAF oraz integracja z ALB i CloudFront
AWS WAF to zapora sieciowa warstwy 7, która ocenia żądania HTTP(S) w oparciu o listę Web ACL składającą się z uporządkowanych reguł. Każda reguła sprawdza atrybuty żądania (URI, nagłówki, treść, ciąg zapytania, źródłowy adres IP) i zwraca akcję kończącą (Allow, Block, Challenge, CAPTCHA) lub akcję niekończącą (Count). Listy Web ACL można dołączać do dystrybucji CloudFront, Application Load Balancers, API Gateway, AppSync, pul użytkowników Cognito oraz usług App Runner. Gdy jest dołączona do CloudFront, lista ACL działa na brzegu sieci (edge) i musi być utworzona w zakresie us-east-1 (Global); w przypadku ALB musi znajdować się w tym samym regionie co load balancer.
Reguły oparte na częstotliwości (rate-based rules) śledzą liczbę żądań przychodzących z jednego adresu IP (lub z nagłówka z przekazanym adresem IP, lub klucza zagregowanego, takiego jak kombinacja URI + IP) w ruchomym oknie pięciominutowym. Gdy liczba przekroczy skonfigurowany próg, akcja reguły jest uruchamiana, dopóki częstotliwość nie spadnie poniżej limitu. Ponieważ AWS WAF stale aktualizuje listę atakujących w ciągu sekund, reguły oparte na częstotliwości są kanoniczną odpowiedzią na nadużycia o dużej skali pochodzące z małego, rotującego zestawu adresów IP — nie musisz ręcznie zarządzać zestawem IP, a narzut operacyjny jest praktycznie zerowy po wdrożeniu początkowej reguły.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
Zestawy IP (IP sets) to reużywalne listy zakresów CIDR, do których odwołują się reguły za pomocą IPSetReferenceStatement. Są one właściwym elementem podstawowym, gdy masz deterministyczną listę blokowania/zezwalania — na przykład dla geograficznie ograniczonych punktów końcowych administracyjnych lub znanych złośliwych zakresów pochodzących z kanałów analityki zagrożeń (threat intelligence feeds). Reguły niestandardowe łączą wiele instrukcji za pomocą operatorów logicznych AndStatement, OrStatement i NotStatement, co pozwala wyrażać warunki takie jak „blokuj żądania do /login z krajów innych niż USA, które jednocześnie nie mają określonego nagłówka”.
CloudFront jako warstwa mitygacji DDoS i ochrona origin
CloudFront absorbuje ataki wolumetryczne i wyczerpujące stan (state-exhaustion) na brzegu sieci AWS, na długo zanim ruch dotrze do Twojego ALB lub floty EC2. Każda lokalizacja brzegowa (edge location) automatycznie uruchamia AWS Shield Standard, zapewniając bezpłatną mitygację ataków typu SYN flood i reflection. Umieszczenie CloudFront przed ALB zmniejsza powierzchnię ataku do sieci brzegowej i umożliwia stosowanie WAF na brzegu sieci, geoblokadę oraz terminację TLS.
Mitygacja jest skuteczna tylko wtedy, gdy atakujący nie mogą ominąć CloudFront, uderzając bezpośrednio w nazwę DNS load balancera ALB. Dwa mechanizmy wzmacniają tę ścieżkę. Po pierwsze, skonfiguruj CloudFront tak, aby wstrzykiwał tajny, niestandardowy nagłówek origin (np. X-Origin-Verify: <random-value>) i skonfiguruj regułę w listenerze ALB, która zwraca 403 dla każdego żądania, w którym brakuje tej dokładnej wartości nagłówka. Okresowo rotuj ten sekret za pomocą AWS Secrets Manager. Po drugie, ogranicz grupę bezpieczeństwa (security group) ALB do zarządzanej przez AWS listy prefiksów com.amazonaws.global.cloudfront.origin-facing, która zawiera zakresy adresów IP brzegowych lokalizacji CloudFront.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
Samo dołączenie WAF ACL do ALB bez wymuszania ruchu przez CloudFront pozostawia punkt końcowy ALB publicznie osiągalnym. Atakujący, którzy odkryją nazwę DNS (poprzez logi certificate transparency, historyczne wpisy DNS lub enumerację subdomen), mogą go zaatakować bezpośrednio, omijając wszystkie zabezpieczenia brzegowe. Jest to najczęstszy błąd architektoniczny w projektach typu „CloudFront + ALB”.
Metryki, alarmy i powiadomienia w Shield Advanced
Shield Advanced dodaje ulepszone wykrywanie, dostęp 24/7 do zespołu Shield Response Team, ochronę kosztów związaną ze skalowaniem podczas ataków oraz wgląd w ataki na warstwę aplikacji. Nie wysyła jednak automatycznie wiadomości e-mail ani SMS w przypadku wystąpienia ataku. Powiadomienia muszą być jawnie skonfigurowane za pomocą CloudWatch.
Shield Advanced publikuje metrykę DDoSDetected (wartość 1 w trakcie trwania ataku) oraz DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond i DDoSAttackRequestsPerSecond dla każdego chronionego zasobu w przestrzeni nazw AWS/DDoSProtection. Utwórz alarm CloudWatch dla metryki DDoSDetected >= 1, z tematem SNS jako akcją alarmu; SNS następnie rozsyła powiadomienia na e-mail, SMS, czat lub do funkcji Lambda.
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Założenie, że Shield Advanced „po prostu wyśle Ci e-mail”, jest częstym nieporozumieniem — bez alarmu CloudWatch i subskrypcji SNS jedynym sygnałem jest konsola Shield i zdarzenie w AWS Health Dashboard.
AWS Network Firewall z automatycznym blokowaniem przez Lambda
Network Firewall to stanowa zapora sieciowa warstw 3–7, dołączana do VPC, która inspekcjonuje ruch przechodzący przez tablice routingu podsieci. Jego polityka składa się z bezstanowych i stanowych grup reguł; stanowe grupy reguł używają składni kompatybilnej z Suricata. Ponieważ grupy reguł są zarządzane przez API, są idealnym celem dla automatyzacji sterowanej zdarzeniami.
Częstym wzorcem jest reagowanie na znaleziska GuardDuty (np. UnauthorizedAccess:EC2/RDPBruteForce lub Backdoor:EC2/C&CActivity). Security Hub agreguje znalezisko, EventBridge dopasowuje wzorzec zdarzenia i wywołuje funkcję Lambda, a Lambda wywołuje UpdateRuleGroup, aby wstawić regułę odrzucającą (drop rule) ruch z atakującego adresu IP lub ENI przejętej instancji.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
Network Firewall jest właściwym wyborem, gdy musisz zablokować dwukierunkowy ruch do/z instancji EC2 lub bloku CIDR na brzegu VPC — WAF inspekcjonuje tylko żądania HTTP skierowane do obsługiwanych punktów końcowych warstwy 7, więc nie może zatrzymać wychodzącego ruchu C2 ani protokołów innych niż HTTP.
Logowanie, monitorowanie i bezpieczne wdrażanie z użyciem akcji Count
Włącz logowanie WAF dla każdej listy Web ACL i przesyłaj strumieniowo do CloudWatch Logs, S3 lub Kinesis Data Firehose. Logi zawierają dopasowaną regułę, akcję, nagłówki żądania oraz (z zastosowaniem reguł redakcyjnych) oczyszczone treści żądań (body). Próbkowane żądania w konsoli dają szybki wgląd, ale przechowują tylko ostatnie 3 godziny i 100 próbek na regułę; pełne logi są niezbędne do audytu i analizy śledczej (forensics).
Akcja Count jest kluczowa dla bezpiecznego wdrażania reguł. Wdrażaj nowe zarządzane grupy reguł (na przykład AWSManagedRulesCommonRuleSet lub grupę Bot Control) z akcjami reguł początkowo nadpisanymi na Count. Obserwuj metrykę CountedRequests w CloudWatch oraz wpisy w logach pod kątem fałszywych alarmów (false positives) — prawidłowego ruchu, który zostałby zablokowany. Dopiero po dostrojeniu wykluczeń zmień akcje na Block. Wdrażanie zarządzanych reguł od razu z akcją Block regularnie powoduje awarie, gdy reguła taka jak SizeRestrictions_BODY blokuje prawidłowy punkt końcowy do przesyłania dużych plików, lub gdy CrossSiteScripting_BODY jest wyzwalana przez zawartość edytora tekstu sformatowanego. Rozwiązaniem nie jest wyłączenie całej grupy, ale dodanie instrukcji zawężającej zakres (scope-down statement) lub nadpisanie akcji dla konkretnej reguły, która działa nieprawidłowo.
Połącz metryki WAF (BlockedRequests, AllowedRequests, CountedRequests) z alarmami CloudWatch, aby nagły skok liczby zablokowanych żądań — lub nagły spadek dozwolonego ruchu — powiadamiał inżyniera dyżurnego, domykając pętlę między ochroną na brzegu sieci a świadomością operacyjną.
Praktyczny problem: Scenariusz użycia
Scenariusz: Firma Meridian Financial prowadzi aplikację internetową dla klientów w wielostrefowym VPC (multi-AZ VPC), używając Application Load Balancers (ALB) przed usługami ECS, oraz dystrybuuje treści statyczne i dynamiczne za pomocą CloudFront. Zespół korzysta z AWS WAF, ale ma ograniczoną automatyzację w zakresie zagrożeń na warstwie sieciowej i niespójne logowanie między usługami.
Wyzwanie: Niedawny gwałtowny wzrost ruchu wolumetrycznego i na warstwie aplikacji, wymierzony w punkty końcowe logowania, spowodował wyczerpanie zasobów CPU na ALB podczas prób ataków typu credential stuffing; zespół ds. bezpieczeństwa potrzebuje szybkiej mitygacji DDoS, spójnej ochrony origin, zautomatyzowanego blokowania złośliwych adresów IP oraz bezpiecznego wdrażania bardziej rygorystycznych reguł.
Zalecane podejście:
- Użyj CloudFront przed ALB w celu globalnej mitygacji na brzegu sieci, skonfiguruj ALB tak, aby akceptował ruch tylko z CloudFront poprzez walidację niestandardowego nagłówka origin oraz ograniczenie dostępu przychodzącego za pomocą listy prefiksów zarządzanej przez CloudFront lub znanych zakresów IP.
- Wdróż AWS WAFv2 z zarządzanymi zestawami reguł AWS oraz niestandardowymi regułami opartymi na częstotliwości zapytań i wykrywaniu botów; podłącz WAF zarówno do dystrybucji CloudFront, jak i do ALB. Początkowo ustaw nowe niestandardowe reguły w tryb COUNT, aby zbierać dane telemetryczne.
- Zarejestruj konto w usłudze AWS Shield Advanced i powiąż z nią dystrybucję CloudFront oraz ALB; utwórz alarmy metryk CloudWatch, korzystając z metryk Shield/DDoS, i przesyłaj alarmy do tematu SNS w celu powiadamiania inżyniera dyżurnego i wyzwalania procedur runbook.
- Scentralizuj logi: przesyłaj strumieniowo logi z CloudFront, ALB, WAF i AWS Network Firewall do Kinesis Data Firehose → S3 i włącz metryki/pulpity nawigacyjne CloudWatch do monitorowania liczby dopasowań reguł z trybu COUNT.
- Wdróż AWS Network Firewall w VPC ze stanowymi grupami reguł i włącz jego logowanie; utwórz filtry metryk CloudWatch dla podejrzanych wzorców oraz funkcję Lambda, która będzie wyzwalana przez alarmy, aby automatycznie aktualizować grupę reguł Network Firewall, dodając szkodliwe adresy IP do listy blokowanych.
- Po obserwacji ruchu w trybie COUNT i na pulpitach nawigacyjnych przez uzgodnione okno obserwacyjne, przełącz reguły WAF o wysokim stopniu pewności w tryb BLOCK i utrzymuj zautomatyzowane aktualizacje Network Firewall z bezpiecznym wycofywaniem zmian i wersjonowaniem grup reguł.
Uzasadnienie: Użycie CloudFront jako warstwy brzegowej z WAF i Shield Advanced zapewnia warstwową ochronę przed atakami DDoS, podczas gdy scentralizowane logowanie, walidacja reguł w trybie COUNT oraz zautomatyzowane aktualizacje Network Firewall sterowane przez funkcje Lambda oferują bezpieczną, obserwowalną i zautomatyzowaną obronę sieci, zgodną z najlepszymi praktykami AWS.
← Bezpieczeństwo sieci i VPC · Wszystkie domeny · Nadzór →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →