Amazon SCS-C02: Logowanie, audyt i analiza śledcza — 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.

Ustalenia i remediacja w Amazon GuardDuty

GuardDuty to zarządzana usługa wykrywania zagrożeń, która w tle nieustannie przetwarza trzy strumienie telemetrii: zdarzenia zarządcze (i opcjonalnie zdarzenia danych S3) z CloudTrail, dzienniki VPC Flow Logs oraz dzienniki zapytań DNS z Route 53. Nie musisz osobno włączać, dostarczać ani płacić za te źródła logów, aby GuardDuty mógł z nich korzystać — usługa odczytuje bezpośrednio zduplikowany strumień. Dlatego GuardDuty można uruchomić jednym wywołaniem API i zacząć generować ustalenia w ciągu kilku minut, bez konieczności budowania jakiejkolwiek infrastruktury do obsługi logów.

Ustalenia mają przypisaną wagę (severity) od 0.1 do 8.9, co odpowiada poziomom Niski (0.1–3.9), Średni (4.0–6.9) i Wysoki (7.0–8.9). Typowe ustalenia wymagające działania to na przykład UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B oraz Recon:IAMUser/MaliciousIPCaller. Wzorce remediacji różnią się w zależności od ustalenia: kompromitacja instancji EC2 zazwyczaj wymaga odizolowania jej za pomocą grupy bezpieczeństwa przeznaczonej do kwarantanny, wykonania migawki woluminów w celach analityki śledczej i terminacji; ustalenie dotyczące IAM wymaga rotacji kluczy dostępu i przejrzenia ostatniej aktywności podmiotu (principal) w CloudTrail.

W środowiskach wielokontowych należy włączyć GuardDuty poprzez AWS Organizations i wyznaczyć konto delegowanego administratora (zazwyczaj jest to konto Security Tooling). Delegowany administrator może automatycznie włączać GuardDuty na każdym istniejącym i nowym koncie członkowskim we wszystkich regionach, w których usługa jest aktywna. Bez konfiguracji delegowanego administratora, ustalenia GuardDuty z poszczególnych kont pozostają odizolowane na każdym z nich — indywidualne włączanie detektorów nie powoduje ich centralnej agregacji.

AWS Security Hub i agregacja międzykontowa

Security Hub to warstwa normalizacji i agregacji. Przetwarza ustalenia z usług GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config oraz dziesiątek produktów partnerskich, konwertując je do formatu AWS Security Finding Format (ASFF). Uruchamia również własne kontrole w oparciu o standardy takie jak CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS i NIST 800-53.

Agregacja międzykontowa i międzyregionalna działa na tej samej zasadzie co w GuardDuty: należy zarejestrować Security Hub u delegowanego administratora Organizations, a następnie wyznaczyć region agregacji, aby ustalenia z innych regionów były replikowane do tego jednego, spójnego widoku. Częstym błędem jest włączanie Security Hub na każdym koncie z osobna i oczekiwanie skonsolidowanego widoku — bez delegowanego administratora i regionu agregacji, każde konto nadal widzi tylko własne ustalenia.

Security Hub sam w sobie nie wysyła e-maili. Powiadomienia i automatyzacje buduje się poprzez dopasowywanie zdarzeń dotyczących ustaleń Security Hub na domyślnej szynie zdarzeń EventBridge i przekazywanie ich do SNS, Lambda, Step Functions lub dokumentów Systems Manager Automation.

CloudTrail: Zdarzenia zarządcze a zdarzenia danych

CloudTrail rejestruje dwie kategorie aktywności, a ich mylenie jest najczęstszą przyczyną luk w pokryciu detekcji.

Zdarzenia zarządcze (Management events): operacje płaszczyzny sterowania — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Domyślnie włączone dla każdej nowej ścieżki (trail).
Zdarzenia danych (Data events): operacje na poziomie zasobów o dużej częstotliwości — wywołania na poziomie obiektów S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), wywołania Invoke funkcji Lambda, wywołania API na poziomie elementów DynamoDB. Domyślnie wyłączone i rozliczane osobno.

Jeśli wymóg bezpieczeństwa brzmi „wykryj, kiedy ktoś udostępni publicznie obiekt S3 za pomocą PutObjectAcl”, zwykła ścieżka ze zdarzeniami zarządczymi tego nie zarejestruje, ponieważ zmiany ACL na pojedynczych obiektach są zdarzeniami danych. Podobnie, pobieranie danych (GetObject) z wrażliwego bucketa jest niewidoczne bez zdarzeń danych. PutBucketAcl (na poziomie bucketa) jest zdarzeniem zarządczym i zostałoby zarejestrowane; PutObjectAcl (na poziomie obiektu) nim nie jest.

Należy używać ścieżki organizacyjnej (organization trail) utworzonej na koncie zarządzającym lub koncie delegowanego administratora, aby zdarzenia z każdego konta członkowskiego były przechwytywane w jednym buckecie S3 i nie mogły być wyłączone przez podmioty (principals) z kont członkowskich. Chroń ścieżkę za pomocą:

Szyfrowania SSE-KMS na docelowym buckecie, z polityką klucza KMS, która zabrania nieautoryzowanego odszyfrowywania.
Polityki bucketa, która zabrania s3:PutObject bez podmiotu usługi (service principal) CloudTrail i zabrania usuwania.
Włączonej walidacji integralności plików dziennika, która co godzinę tworzy pliki skrótów (digest files) podpisane algorytmem SHA-256, aby można było udowodnić ewentualną manipulację.

Przykład utworzenia:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridge i alerty SNS

EventBridge to szkielet routingu, który łączy ustalenia z ludzkimi i zautomatyzowanymi systemami reagowania. Każde ustalenie GuardDuty, każda aktualizacja ustalenia Security Hub i każde zdarzenie pochodzące z CloudTrail trafia na domyślną szynę zdarzeń. Reguły używają wzorców zdarzeń w formacie JSON do filtrowania, a następnie przekazują je do jednego lub więcej celów (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Kanoniczny wzorzec dla ustaleń GuardDuty o wysokiej wadze, przekazywanych zarówno do tematu SNS w celu wysłania e-maila, jak i do strumienia dostarczania Firehose zasilającego OpenSearch w celach analitycznych:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Dla ustaleń Security Hub o statusie CRITICAL kierowanych na e-mail:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Punkt końcowy dla e-maili to prosta subskrypcja SNS; subskrybent musi ją potwierdzić, klikając link w otrzymanej wiadomości, zanim rozpocznie się dostarczanie. Pojedyncza reguła może mieć do pięciu celów, więc alerty i dalsza analityka nie wymagają tworzenia zduplikowanych reguł.

Podczas tworzenia wzorców należy pamiętać, że zdarzenia zarządcze CloudTrail docierają z polem "detail-type": "AWS API Call via CloudTrail", podczas gdy zdarzenia danych nie pojawiają się na domyślnej szynie, chyba że skonfigurujesz ścieżkę publikującą do CloudWatch Logs i użyjesz filtra metryk lub zasubskrybujesz je poprzez integrację EventBridge ze zdarzeniami danych CloudTrail. Napisanie reguły EventBridge dopasowującej "eventName": "PutObjectAcl" na domyślnej szynie bez włączonych zdarzeń danych nie przyniesie żadnych wyników.

CloudWatch Logs, Insights, filtry metryk i alarmy

Wysyłanie logów CloudTrail (oraz VPC Flow Logs i logów aplikacji) do CloudWatch Logs umożliwia wykrywanie zdarzeń w czasie zbliżonym do rzeczywistego. Filtry metryk skanują każde przychodzące zdarzenie w logu pod kątem wzorca i inkrementują niestandardową metrykę CloudWatch; alarm CloudWatch dla tej metryki uruchamia SNS.

Przykład: alarm w przypadku powtarzających się nieudanych prób logowania do konsoli.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights umożliwia wykonywanie zapytań ad-hoc przy użyciu dedykowanego języka zapytań, co jest przydatne do reagowania na incydenty po uruchomieniu alarmu:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Częste pułapki

Brak aktywności na poziomie obiektów S3: PutObjectAcl, GetObject i DeleteObject to zdarzenia danych (data events). Domyślny trail rejestruje tylko zdarzenia zarządzania (management events); musisz dodać selektory zdarzeń danych, w przeciwnym razie finding, alarm lub reguła EventBridge ukierunkowana na te nazwy API po cichu nigdy się nie uruchomi.
Centralna widoczność bez delegowanego administratora: włączenie GuardDuty lub Security Hub na każdym koncie nie agreguje wyników. Wyniki (findings) są gromadzone centralnie dopiero po zarejestrowaniu delegowanego administratora w AWS Organizations oraz, w przypadku Security Hub, po wybraniu regionu agregacji. Zaproszenia między kontami sprawdzają się w małych środowiskach, ale nie skalują się i wymagają akceptacji na każdym koncie.
Mylenie zdarzeń zarządzania i danych w filtrach: PutBucketAcl (bucket) to zdarzenie zarządzania i działa w każdym standardowym filtrze EventBridge lub filtrze metryk; PutObjectAcl (obiekt) nie zadziała, niezależnie od tego, jak dobrze skonstruowany jest wzorzec, chyba że zdarzenia danych są włączone i dostarczane do tego samego potoku (pipeline).

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial zarządza wielokontową organizacją AWS z dedykowanym kontem bezpieczeństwa i scentralizowanym kontem do logowania. Ich środowisko obejmuje dane osobowe klientów (PII) w S3, transakcyjne API na EC2/Lambda, a CloudTrail już zapisuje zdarzenia zarządzania do centralnego bucketa S3; zespoły chcą szybszego wykrywania i skoordynowanej reakcji na wszystkich kontach.

Wyzwanie: Inżynierowie bezpieczeństwa wykryli nagły wzrost zapytań GET do S3 i powiązane wyniki (findings) z GuardDuty sugerujące potencjalną eksfiltrację danych, ale alerty są szumne (noisy) i brakuje im skorelowanego kontekstu z CloudTrail oraz zautomatyzowanych działań powstrzymujących (containment) na wszystkich kontach.

Zalecane podejście:

Włącz Amazon GuardDuty na każdym koncie członkowskim i wyznacz konto bezpieczeństwa jako delegowanego administratora GuardDuty; włącz ochronę zdarzeń danych S3 (S3 data-event protection), aby wyniki (findings) obejmowały anomalie w dostępie na poziomie obiektów.
Skonfiguruj CloudTrail na każdym koncie, aby dostarczał zdarzenia zarządzania do centralnego S3 w celu retencji oraz aby przekazywał wybrane, wartościowe zdarzenia danych (S3 GetObject/PutObject/DeleteObject i Lambda Invoke) do CloudWatch Logs na koncie bezpieczeństwa w celu inspekcji z niskim opóźnieniem.
Włącz AWS Security Hub na koncie bezpieczeństwa i aktywuj agregację międzykontową z kontami członkowskimi, aby wyniki z GuardDuty, wyniki pochodzące z CloudTrail oraz rezultaty z Config/Inspector były scentralizowane i znormalizowane.
Utwórz reguły EventBridge, które dopasowują wyniki (findings) o wysokiej wadze z GuardDuty i Security Hub i kierują je do SNS w celu powiadomień na pager oraz do funkcji Lambda naprawczej (remediation Lambda), która wykorzystuje kontekst z CloudTrail do podjęcia działań powstrzymujących (np. unieważnienie kluczy API, usunięcie sesji IAM, izolacja ENI instancji EC2).
Dodaj filtry metryk CloudWatch Logs dla nietypowych wskaźników s3:GetObject w zakresie podmiotu IAM (principal) oraz alarm, który uruchamia ten sam potok EventBridge/SNS/Lambda; użyj zapytań CloudWatch Logs Insights na koncie bezpieczeństwa, aby wzbogacić alerty o skorelowane zdarzenia CloudTrail na potrzeby analizy incydentów (incident triage).

Uzasadnienie: Centralizacja wyników (GuardDuty + Security Hub) i wysyłanie ukierunkowanych zdarzeń danych CloudTrail do CloudWatch umożliwia korelację z niskim opóźnieniem, alarmowanie i zautomatyzowane powstrzymywanie za pośrednictwem EventBridge/SNS/Lambda — co jest zgodne z najlepszymi praktykami AWS w zakresie wykrywania, agregacji międzykontowej i zautomatyzowanej reakcji.

Scentralizowany CloudTrail i integralność logów

CloudTrail jest autorytatywnym zapisem aktywności API w AWS, a fundamentem każdej architektury audytu jest pojedynczy trail wieloregionowy (multi-Region trail), który dostarcza logi do jednego, scentralizowanego bucketa S3, najlepiej na dedykowanym koncie archiwum logów w ramach AWS Organizations. Trail wieloregionowy automatycznie przechwytuje zdarzenia zarządzania w każdym bieżącym regionie oraz w każdym regionie, który AWS uruchomi w przyszłości — trail jednoregionowy tworzy martwe punkty w momencie, gdy obciążenie robocze zostanie uruchomione gdzie indziej, co jest klasycznym błędem braku kompletności podczas audytów. Gdy jest zastosowany na poziomie organizacji, trail przechwytuje również zdarzenia z każdego konta członkowskiego, więc nowe konto dołączające do organizacji jest objęte monitoringiem bez żadnej konfiguracji na poziomie konta.

Włącz walidację plików z logami (log file validation) dla danego trailu. CloudTrail będzie wtedy co godzinę dostarczał do tego samego bucketa S3 podpisany plik skrótu (digest file), zawierający hashe SHA-256 dostarczonych plików z logami. Polecenie aws cloudtrail validate-logs przechodzi przez łańcuch skrótów i wykrywa manipulacje, usunięcia lub luki. Bez walidacji, obrońca nie może udowodnić, że logi nie zostały zmienione po incydencie, co unieważnia je jako dowód w informatyce śledczej.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Błędy w dostarczaniu logów to prawie zawsze problemy z uprawnieniami po stronie odbiorcy (downstream), a nie błędy w działaniu CloudTrail. Bucket S3 musi istnieć przed utworzeniem trailu, jego polityka (bucket policy) musi przyznawać uprawnienie s3:PutObject usłudze cloudtrail.amazonaws.com z warunkiem aws:SourceArn pasującym do trailu, a właścicielem obiektu musi być właściciel bucketa (bucket-owner-full-control). Jeśli trail używa SSE-KMS, polityka klucza CMK musi zezwalać na kms:GenerateDataKey* dla principalu usługi CloudTrail, a każdy konsument (Athena, inżynierowie bezpieczeństwa, parsery Lambda) musi mieć uprawnienie kms:Decrypt do tego klucza. Częsty scenariusz awarii: logi są dostarczane poprawnie, ale zapytania Athena zwracają błąd „AccessDenied”, ponieważ rola wykonująca zapytanie nie ma uprawnienia Decrypt do klucza CMK używanego do szyfrowania logów. Napraw to w polityce klucza, a nie przez wyłączenie szyfrowania.

CloudWatch Logs, filtry metryk i alarmowanie w czasie rzeczywistym

CloudTrail dostarcza dane do S3 w partiach co 5-15 minut — jest to wystarczające do audytu retrospektywnego, ale zbyt wolne do wykrywania w czasie rzeczywistym. Aby alarmować o wrażliwych zdarzeniach, strumieniuj ślad (trail) do CloudWatch Logs (jest to opcja konfiguracji śladu) lub przekierowuj określone zdarzenia za pomocą EventBridge. Podejście z CloudWatch Logs wykorzystuje filtry metryk (metric filters), które dopasowują wzorce w zdarzeniach JSON i inkrementują metrykę CloudWatch, co z kolei wyzwala alarm CloudWatch i powiadomienie SNS. Kanonicznym przykładem jest logowanie na konto root do konsoli:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge jest często lepszym rozwiązaniem dla wąsko zdefiniowanych, dobrze znanych zdarzeń (np. wyłączenie klucza KMS, zmiany w politykach IAM), ponieważ jego reguły mogą bezpośrednio wyzwalać funkcje Lambda lub Step Functions bez żadnych kosztów związanych z Logs. Używaj filtrów metryk, gdy potrzebujesz zagregowanych liczników lub wizualizacji na dashboardach.

Domyślna retencja w CloudWatch Logs to Never Expire (Nigdy nie wygasa), co jest kosztowne i rzadko kiedy jest właściwym ustawieniem. Ustaw jawną retencję dla każdej grupy logów (aws logs put-retention-policy) zgodnie z wymogami zgodności — powszechną praktyką jest 90 dni “gorących” danych w CloudWatch z długoterminową archiwizacją w S3 za pomocą filtra subskrypcji lub Kinesis Data Firehose.

W celu zapewnienia higieny danych wrażliwych, zastosuj polityki ochrony danych CloudWatch Logs (data protection policies) na poziomie konta. Wykorzystują one zarządzane identyfikatory danych (numery kart kredytowych, klucze AWS secret keys, numery SSN) do maskowania pasujących ciągów znaków podczas pozyskiwania danych (ingestion). Co kluczowe, odmaskowanie wymaga uprawnienia logs:Unmask; nadawaj je tylko roli typu break-glass (awaryjnej). Użytkownicy, którzy mogą odczytywać grupę logów, ale nie mają uprawnienia Unmask, widzą tylko gwiazdki. Polityka na poziomie całego konta ma zastosowanie do wszystkich obecnych i przyszłych grup logów, co jest właściwym mechanizmem kontrolnym — polityki per grupa mają tendencję do dezaktualizacji w miarę tworzenia nowych grup przez nowe usługi.

Wykonywanie zapytań do logów na dużą skalę: Insights i Athena

Dwa silniki zapytań obsługują różne warstwy danych.

CloudWatch Logs Insights wykonuje zapytania na danych już znajdujących się w CloudWatch Logs, używając dedykowanego języka zapytań. Idealne rozwiązanie dla świeżych danych operacyjnych (logi Lambda, VPC Flow Logs w Logs, logi aplikacji). Szybkie, bez konieczności konfiguracji schematu, ale ograniczone przez retencję CloudWatch i koszt za każdy przeskanowany GB.
Amazon Athena wykonuje zapytania SQL (Presto/Trino) na danych w S3. Idealne rozwiązanie do analiz śledczych (forensic) na dużą skalę na logach CloudTrail, logach dostępowych ALB, VPC Flow Logs przechowywanych w S3 oraz logach CloudFront. Kosztuje 5 USD za przeskanowany TB; użyj projekcji partycji (partition projection) lub partycji Glue opartych na dacie/regionie, aby drastycznie obniżyć koszt skanowania.

Typowy przypadek użycia w analizie śledczej: identyfikacja, kto wyłączył klucz KMS. Ponieważ JSON z CloudTrail jest zagnieżdżony, tabela Athena utworzona dla CloudTrail udostępnia userIdentity jako strukturę (struct):

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Do analizy botów na podstawie logów ALB, włącz logi dostępowe ALB do S3, zdefiniuj tabelę Athena nad prefiksem logów, a następnie wykonaj złączenie (join) z tabelą znanych złośliwych adresów IP i zwizualizuj agregację w QuickSight. QuickSight odczytuje dane z Athena, więc potok danych (pipeline) wygląda następująco: ALB → S3 → Athena → QuickSight. Wysyłanie logów ALB do CloudWatch Logs Insights nie jest natywnie wspieraną ścieżką — logi ALB mogą być wysyłane tylko do S3.

VPC Flow Logs mogą trafiać do obu miejsc docelowych: wybierz Logs do taktycznych dochodzeń typu filter dstPort=3389 and action="REJECT", a S3 (w formacie Parquet, z partycjonowaniem) do zapytań o trendy w skali miesiąca.

Gromadzenie dowodów z użyciem Audit Manager

AWS Audit Manager automatyzuje ciągłe gromadzenie dowodów przypisanych do ram (frameworków) takich jak PCI DSS, HIPAA, SOC 2 i CIS. Pobiera on dowody z reguł Config, ustaleń Security Hub, zdarzeń CloudTrail oraz inwentarza zasobów, a następnie pakuje je w ramach ocen kontroli (control assessments). Gdy jest włączony na koncie zarządzającym Organizations lub na koncie delegowanego administratora, zbiera dane ze wszystkich kont członkowskich, tworząc raport z oceny — spakowany plik zip z dowodami i manifestem — który audytorzy akceptują zamiast ręcznie robionych zrzutów ekranu. Jest to poprawna odpowiedź zawsze, gdy scenariusz pyta o ciągłe, wielokontowe, zgodne z frameworkiem gromadzenie dowodów: sam Config zapewnia zgodność zasobów, ale bez mapowania na framework; Security Hub dostarcza ustaleń, ale bez pakowania ich w ocenę; autorski raport Athena nie jest ciągły.

Podsumowanie pułapek

Obwinianie CloudTrail za brakujące logi jest zazwyczaj błędem: bucket może nie istnieć, polityka bucketa może odrzucać principal CloudTrail lub własność obiektów może być błędnie skonfigurowana. W pierwszej kolejności sprawdź S3.
Trail w jednym regionie wydaje się tańszy, ale tworzy niekompletną historię audytu; opcja multi-Region jest domyślną, poprawną odpowiedzią dla zapewnienia pokrycia w całej organizacji.
Logi zaszyfrowane za pomocą SSE-KMS są niewidoczne dla Athena, parserów Lambda czy inżynierów, chyba że polityka klucza CMK nadaje uprawnienie kms:Decrypt tym principalom — wyłączenie szyfrowania nie jest rozwiązaniem; jest nim poprawienie polityki klucza.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial zarządza wielokontową strukturą AWS Organization z kontami produkcyjnym, stagingowym oraz dedykowanym kontem do logowania. Ich środowisko hostuje API dostępne dla klientów, systemy analityczne oraz sekrety zarządzane przez IAM. Potrzebują scentralizowanego, odpornego na manipulacje logowania oraz szybkich narzędzi dochodzeniowych do wsparcia reakcji na incydenty i obsługi żądań dotyczących zgodności.

Wyzwanie: Niedawna podejrzana sekwencja logowań do konsoli i zmian w politykach IAM pozostała niezauważona przez wiele godzin. Istnieje obawa, że integralność logów i terminowe alertowanie są niewystarczające do rekonstrukcji śledczej i zbierania dowodów przez Audit Manager.

Zalecane podejście:

Włącz AWS Organizations CloudTrail (organization trail) we wszystkich regionach, włącz walidację integralności plików z logami CloudTrail, dostarczaj logi i pliki skrótów (digest files) do scentralizowanego bucketa S3 zaszyfrowanego kluczem KMS CMK, którego polityka klucza ogranicza deszyfrowanie do niewielkiego zespołu ds. bezpieczeństwa, oraz włącz logowanie dostępu i wersjonowanie w S3.
Skonfiguruj CloudTrail do strumieniowania zdarzeń zarządczych (management events) i wybranych zdarzeń danych (data events) do CloudWatch Logs, następnie utwórz filtry metryk CloudWatch Logs dla wzorców wysokiego ryzyka (nieudane logowania do konsoli z nowych adresów IP, CreateUser, PutRolePolicy) i podłącz alarmy CloudWatch do tematów SNS w celu powiadamiania (paging) i uruchamiania zautomatyzowanego scenariusza (playbook) Lambda.
Wdróż dashboardy CloudWatch Logs Insights do interaktywnej analizy ostatnich zdarzeń i ustaw reguły retencji i cyklu życia na koncie do logowania, aby przechowywać dowody zgodnie z polityką.
Sklasyfikuj obiekty CloudTrail w S3 za pomocą AWS Glue i uruchamiaj zapytania Athena (partycjonowane według regionu/daty/usługi) do retrospektywnej analizy na dużą skalę oraz do tworzenia eksportów dowodów w formacie CSV dla analityków śledczych.
Utwórz ocenę (assessment) w AWS Audit Manager, która automatycznie zbiera dowody z CloudTrail, AWS Config i IAM do folderu dowodów (evidence folder) i planuje okresowe eksporty dla audytorów zgodności.

Uzasadnienie: Centralizacja i walidacja CloudTrail, strumieniowanie do CloudWatch w celu tworzenia filtrów metryk i alarmów w czasie rzeczywistym oraz używanie Athena/Logs Insights do skalowalnych zapytań jest zgodne z najlepszymi praktykami AWS w zakresie wykrywania, niezmiennego logowania i gotowości do analizy śledczej, podczas gdy Audit Manager automatyzuje zbieranie dowodów na potrzeby audytów.

← Wykrywanie zagrożeń i alertowanie · Wszystkie domeny · Szyfrowanie →

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 →

Przeglądaj Amazon →

Amazon SCS-C02: Logowanie, audyt i analiza śledcza — Przewodnik do nauki

Ustalenia i remediacja w Amazon GuardDuty

AWS Security Hub i agregacja międzykontowa

CloudTrail: Zdarzenia zarządcze a zdarzenia danych

EventBridge i alerty SNS

CloudWatch Logs, Insights, filtry metryk i alarmy

Częste pułapki

Problem praktyczny: Scenariusz użycia

Scentralizowany CloudTrail i integralność logów

CloudWatch Logs, filtry metryk i alarmowanie w czasie rzeczywistym

Wykonywanie zapytań do logów na dużą skalę: Insights i Athena

Gromadzenie dowodów z użyciem Audit Manager

Podsumowanie pułapek

Problem praktyczny: Scenariusz użycia

Pass the whole exam — not just this question

Related guides

Jedna subskrypcja. Każdy egzamin.