Amazon SCS-C02: Reagowanie na incydenty 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.

Izolacja przejętych instancji EC2

Pierwszym celem operacyjnym w przypadku podejrzenia przejęcia instancji EC2 jest jej odizolowanie bez niszczenia dowodów. Izolacja w AWS to działanie wielowarstwowe, które dotyczy ekspozycji sieciowej instancji, jej powiązań z cyklem życia oraz dostępności dla analityków.

Standardowa sekwencja izolacji rozpoczyna się od zacieśnienia grupy bezpieczeństwa (security group) instancji. Ponieważ idealnie każda instancja ma swoją własną, dedykowaną grupę bezpieczeństwa, można zastąpić reguły przychodzące (ingress) i wychodzące (egress) minimalnym zestawem, który zezwala na dostęp tylko zespołowi dochodzeniowemu (lub dedykowanej grupie bezpieczeństwa do celów diagnostycznych). Jeśli instancja znajduje się za Application Load Balancer lub w grupie docelowej (target group), należy ją najpierw wyrejestrować; jeśli jest członkiem grupy Auto Scaling, należy ją odłączyć za pomocą flagi --should-decrement-desired-capacity, aby ASG nie uruchomiła natychmiast nowej instancji w jej miejsce lub, co gorsza, nie zakończyła „niezdrowej” instancji w trakcie dochodzenia.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Włączenie ochrony przed zakończeniem (termination protection) jest kluczowe, ponieważ dobrze poinformowany operator, skrypt automatyzujący lub zdarzenie skalowania w dół (scale-in) w ASG mogłoby w przeciwnym razie zniszczyć woluminy, które próbujesz zachować. Ochrona przed zakończeniem nie zastępuje odłączenia od ASG — ASG wciąż może zakończyć chronione instancje podczas skalowania w dół, chyba że usuniesz instancję z zakresu działania grupy.

W celu izolacji na poziomie podsieci, gdy potrzebne jest natychmiastowe odcięcie ruchu wychodzącego (np. gdy instancja komunikuje się ze znanymi złośliwymi adresami IP), można dodać do sieciowej listy ACL podsieci jawną regułę blokującą cały ruch wychodzący jako pierwszą regułę w kolejności. Jest to działanie bezstanowe (stateless) i wchodzi w życie natychmiast dla wszystkich przepływów, w przeciwieństwie do zmian w grupach bezpieczeństwa, które wpływają tylko na nowe przepływy. Gdy ścieżka dostępu dla analityków jest już gotowa poprzez diagnostyczną SG, blokada w NACL może zostać usunięta, aby podsieć analityków mogła dotrzeć do celu poprzez listę dozwolonych w SG.

Zabezpieczanie dowodów ulotnych i trwałych

Dowody ulotne — lista procesów, otwarte gniazda sieciowe, załadowane moduły jądra, zawartość pamięci, zawartość tmpfs — są niszczone w momencie zatrzymania instancji. Dowody trwałe znajdują się na woluminach EBS i przetrwają zatrzymanie/uruchomienie, ale wciąż mogą zostać utracone, jeśli woluminy zostaną odłączone lub instancja zostanie zakończona bez wykonania snapshotów. Zasada kolejności: najpierw zbierz artefakty ulotne, gdy instancja wciąż działa, a następnie wykonaj snapshoty EBS.

Zbieranie danych ulotnych powinno być oskryptowane i wykonane za pomocą SSM Run Command, a nie przez człowieka wpisującego polecenia w interaktywnej powłoce. Run Command rejestruje wywołanie, parametry, tożsamość wykonującą (principal) oraz wynik w CloudWatch Logs lub S3, co samo w sobie staje się częścią zapisu łańcucha dowodowego (chain-of-custody).

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial uruchamia swoje aplikacje internetowe dla klientów na jednym koncie AWS w wielu VPC, używając grup Auto Scaling za Application Load Balancer, instancji EC2 z woluminami EBS, scentralizowanego logowania CloudTrail i CloudWatch, usługi GuardDuty oraz archiwum logów w S3 szyfrowanego za pomocą KMS. Zespół operacji bezpieczeństwa używa AWS Systems Manager do zdalnego zarządzania i przechowuje kopie zapasowe oraz snapshoty na dedykowanym koncie odzyskiwania.

Wyzwanie: Jedna z produkcyjnych instancji EC2 wykazuje oznaki przejęcia, w tym podejrzany ruch wychodzący i nieoczekiwaną aktywność procesów; zespół musi odizolować instancję i zabezpieczyć zarówno ulotne dowody z pamięci, jak i trwałe dowody z dysku do analizy śledczej, nie niszcząc przy tym śladów audytowych.

Zalecane podejście:

1. Użyj API Auto Scaling i ELB, aby odłączyć instancję od grup docelowych i zawiesić procesy Auto Scaling, a następnie zastosuj restrykcyjną grupę bezpieczeństwa (blokada całego ruchu przychodzącego/wychodzącego) i zaktualizuj reguły sieciowej listy ACL instancji, aby odizolować dostęp sieciowy, zachowując jednocześnie zarządzanie przez AWS Systems Manager Session Manager.
2. Użyj AWS Systems Manager Run Command, aby wykonać wewnątrz systemu operacyjnego zrzut pamięci (np. za pomocą LiME), który zapisze zrzut RAM na podłączonym, zaszyfrowanym woluminie EBS lub bezpośrednio do bucketu S3 zaszyfrowanego za pomocą SSE-KMS z włączoną funkcją S3 Object Lock w celu retencji.
3. Użyj EC2 CreateSnapshot (lub CreateImage), aby przechwycić snapshoty EBS wszystkich podłączonych woluminów w danym punkcie czasowym, a następnie skopiuj te snapshoty na osobne konto AWS lub do innego regionu, aby zachować łańcuch dowodowy i zapobiec manipulacji.
4. Włącz lub pobierz dane z VPC Traffic Mirroring dla ENI instancji, aby zbierać pakiety sieciowe na dedykowanej instancji monitorującej EC2, i równocześnie eksportuj logi VPC Flow Logs, logi dostępowe ELB, dane z CloudTrail, CloudWatch Logs oraz ustalenia GuardDuty do bezpiecznego archiwum S3.
5. Otaguj i zinwentaryzuj wszystkie zebrane artefakty w AWS Security Hub lub systemie ticketowym, upewnij się, że obiekty S3 są zaszyfrowane i mają ustawiony Object Lock, oraz ogranicz dostęp IAM do małego zespołu dochodzeniowego, logując jednocześnie cały dostęp przez CloudTrail.

Uzasadnienie: Izolacja dostępu sieciowego przed wykonaniem obrazów zapobiega dalszemu zanieczyszczeniu, a użycie SSM pozwala uniknąć otwierania nowych wektorów sieciowych; przechwycenie najpierw pamięci ulotnej oraz utworzenie niezmiennych snapshotów EBS i bezpiecznych archiwów S3 zapewnia integralność dowodów i łańcuch dowodowy zgodnie z najlepszymi praktykami reagowania na incydenty w AWS.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Natychmiast po przechwyceniu danych ulotnych wykonaj snapshot każdego podłączonego woluminu EBS. Otaguj snapshoty identyfikatorem incydentu, aby były jednoznacznie powiązane ze sprawą.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Otaguj samą instancję tym samym numerem ticketu incydentu, nazwiskiem analityka oraz etykietą statusu, taką jak Quarantine. Spójne tagowanie metadanych jest natywnym mechanizmem AWS do zarządzania łańcuchem dowodowym — można je przeszukiwać, uczynić niezmiennymi za pomocą kluczy warunkowych IAM (condition keys) i pojawia się w każdym zdarzeniu CloudTrail dotyczącym zasobu.

Reakcja na żywo z użyciem Session Manager i Run Command

Subtelna, ale kluczowa z perspektywy egzaminu kwestia: istniejące sesje SSH przetrwają usunięcie reguł grupy bezpieczeństwa. Grupy bezpieczeństwa są stanowe i oceniają reguły w momencie nawiązywania połączenia; już nawiązana sesja TCP będzie kontynuowana, nawet po usunięciu reguły ruchu przychodzącego, która na nią zezwoliła. Jeśli osoba reagująca na incydent izoluje instancję, usuwając reguły SG, polegając jednocześnie na własnej sesji SSH w celu uzyskania dostępu, ta sesja będzie działać — dopóki nie zostanie przerwana. W tym momencie osoba ta zostanie odcięta od dostępu, a ponowne wejście za pomocą bastionu lub klucza będzie już niemożliwe.

Prawidłowym wzorcem jest przyznanie zespołowi analityki śledczej dostępu poprzez SSM Session Manager, który nie wymaga otwierania żadnego portu przychodzącego. Session Manager działa poprzez wychodzące połączenie Agenta SSM z punktami końcowymi SSM, EC2 Messages i SSM Messages (najlepiej za pośrednictwem interfejsowych punktów końcowych VPC, dzięki czemu izolowana instancja nie potrzebuje trasy do internetu). Dołącz profil instancji zezwalający na ssm:UpdateInstanceInformation i API do obsługi wiadomości, a osobom reagującym przyznaj uprawnienie ssm:StartSession z zakresem ograniczonym przez tag do instancji poddanej kwarantannie.

Ponieważ sesje Session Manager są pośredniczone przez płaszczyznę sterowania SSM, zacieśnienie lub całkowite opróżnienie reguł przychodzących grupy bezpieczeństwa nie zakłóca ich działania, a każde naciśnięcie klawisza może być logowane do S3 lub CloudWatch Logs — co daje audytowalną sesję interaktywną, a nie czarną skrzynkę.

Odzyskiwanie zaszyfrowanych migawek między kontami

Dojrzałe środowiska przekierowują migawki na potrzeby analityki śledczej na dedykowane konto analityczne, odizolowane od konta z naruszonym obciążeniem roboczym. Udostępnianie migawek między kontami wymaga dwóch rzeczy: migawka musi być udostępniona docelowemu kontu (modify-snapshot-attribute --create-volume-permission), a jeśli migawka jest zaszyfrowana kluczem KMS zarządzanym przez klienta (CMK), polityka klucza KMS musi przyznawać podmiotom z konta analitycznego uprawnienia kms:Decrypt, kms:CreateGrant i kms:DescribeKey. Migawki zaszyfrowane zarządzanym przez AWS kluczem aws/ebs nie mogą być udostępniane między kontami — najpierw należy je ponownie zaszyfrować za pomocą klucza CMK poprzez operację kopiowania. Na koncie analityki śledczej skopiuj udostępnioną migawkę i ponownie zaszyfruj ją lokalnym kluczem CMK, aby późniejsze tworzenie woluminów nie zależało od konta źródłowego.

Projektowanie scenariuszy (playbooków) i minimalizacja narzutu

Skodyfikuj kroki powstrzymywania jako dokument SSM Automation lub przepływ pracy Step Functions, wyzwalany przez znaleziska GuardDuty lub Security Hub za pośrednictwem EventBridge. Pojedyncza automatyzacja powinna: (1) przechwycić dane ulotne za pomocą Run Command, (2) utworzyć migawki woluminów z tagami incydentu, (3) włączyć ochronę przed terminacją, (4) odłączyć od ASG i wyrejestrować z celów ELB, (5) zastąpić SG kwarantannową grupą bezpieczeństwa oraz (6) otagować instancję identyfikatorem zgłoszenia (ticket ID). Utrzymanie działającej instancji zachowuje dowody ulotne i umożliwia interaktywną analizę za pomocą Session Manager — wyłączenie zasilania powinno być świadomym, późniejszym krokiem, a nie częścią automatycznego powstrzymywania, ponieważ zamknięcie systemu zeruje dowody ulotne i może wyzwolić logikę czyszczącą zaimplementowaną w złośliwym oprogramowaniu.

Pułapki, które należy sobie przyswoić: usuwanie reguł SG przy jednoczesnym zaufaniu do istniejącej sesji SSH pozostawia reagującego bez wglądu i daje fałszywe poczucie izolacji; przeprowadzanie naprawy w miejscu przed wykonaniem migawki niszczy artefakty, które odpowiadają na pytanie, jak doszło do włamania; a pozostawienie instancji w jej grupie ASG lub grupie docelowej prowokuje automatyczną terminację lub, co gorsza, cichą wymianę, która ukrywa zakres incydentu.

Natychmiastowe powstrzymanie

Gdy istnieje podejrzenie naruszenia bezpieczeństwa obciążenia roboczego, pierwszą decyzją jest, czy odizolować je w miejscu, czy wycofać z użycia. Wycofanie — zatrzymanie lub terminacja — niszczy dowody ulotne, takie jak zawartość pamięci RAM, uruchomione procesy, otwarte gniazda (sockets) oraz wszelkie złośliwe oprogramowanie, które istnieje tylko w pamięci. Izolacja w miejscu jest prawie zawsze właściwym pierwszym krokiem i musi nastąpić na tyle szybko, aby atakujący nie mógł dokonać dalszej eksfiltracji danych ani ruchu bocznego, zanim zabezpieczenia zaczną działać.

Dwa natywne mechanizmy kontroli AWS działają na różnych warstwach, a rozróżnienie to ma znaczenie. Grupy bezpieczeństwa (Security groups) są stanowe i dołączone do elastycznych interfejsów sieciowych (ENI); sieciowe listy kontroli dostępu (NACL) są bezstanowe i dołączone do podsieci. Zastąpienie grup bezpieczeństwa instancji zablokowaną, “kwarantannową” SG jest podejściem chirurgicznym — izoluje jeden interfejs ENI bez zakłócania innych obciążeń w tej samej podsieci i zachowuje stan wykonawczy instancji. Jednak zmiany w grupach bezpieczeństwa wpływają tylko na nowe przepływy docierające do ENI, a jeśli naruszona instancja utrzymuje już długotrwałe połączenia wychodzące, istniejący stan może przetrwać. Reguły deny w NACL wchodzą w życie na granicy podsieci natychmiast i mogą zablokować ruch jeszcze szybciej, gdy prędkość jest ważniejsza niż chirurgiczna precyzja — na przykład, gdy zagrożonych jest kilka instancji w tej samej podsieci lub gdy aktywna sesja atakującego musi zostać natychmiast przerwana. NACL są również przydatne, gdy polityka bezpieczeństwa uniemożliwia bezpośrednią modyfikację instancji.

Kanoniczna kwarantannowa grupa bezpieczeństwa (SG) zezwala na brak ruchu przychodzącego i ruch wychodzący tylko do interfejsowych punktów końcowych VPC dla com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages i com.amazonaws.<region>.ec2messages. Pozwala to zachować dostęp przez Systems Manager Session Manager, jednocześnie blokując kanały C2, eksfiltrację danych i ruch boczny.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Kolejność zabezpieczania dowodów

Wartość dowodowa maleje od danych najbardziej ulotnych do najmniej ulotnych, dlatego kolejność operacji jest stała i nie podlega negocjacjom:

• Najpierw włącz ochronę przed terminacją. Ustawienie DisableApiTermination=true zapobiega zniszczeniu instancji w trakcie dochodzenia przez zdarzenie Auto Scaling, błąd operatora lub zaplanowane działanie. Odłącz również instancję od jej grupy Auto Scaling, aby mechanizmy sprawdzania kondycji ASG nie mogły jej zastąpić.

• Odłącz lub chroń przed Auto Scaling. Użyj EnterStandby lub odłącz instancję, aby ASG nie zakończyła jej działania z powodu braku sprawności.

• Utwórz snapshot każdego podłączonego woluminu EBS. Polecenie CreateSnapshot (lub CreateSnapshots do atomowego przechwytywania wielu woluminów) tworzy niezmienny, zaszyfrowany artefakt dowodowy. Oznacz snapshoty identyfikatorem incydentu, ID instancji źródłowej, znacznikiem czasu i analitykiem. Skopiuj snapshoty na dedykowane konto analityki śledczej należące do zespołu bezpieczeństwa, aby przetrwały one ewentualne przejęcie konta.

• Zabezpiecz pamięć. Użyj dokumentu SSM RunCommand, aby wywołać narzędzie do akwizycji pamięci (LiME, AVML w systemie Linux; WinPMEM w systemie Windows) i strumieniuj obraz do bucketu S3 przeznaczonego na dane śledcze, z włączonym Object Lock w trybie zgodności (compliance mode). Pamięć musi zostać przechwycona, gdy instancja jest wciąż uruchomiona — zatrzymana instancja nie ma pamięci RAM do pozyskania.

• Zbierz metadane. Zapisz ID instancji, AMI, profil instancji IAM, VPC/podsieć, ID interfejsów ENI, tagi, listę uruchomionych procesów, wynik polecenia netstat oraz zawartość IMDS. Oznacz instancję tagami Status=Quarantined i IncidentId=<id>, aby późniejsze automatyzacje i operatorzy rozpoznali jej stan.

• Dopiero wtedy zatrzymaj instancję, jeśli dochodzenie wymaga analizy dysku w trybie offline. Zatrzymanie instancji czyści pamięć, więc jest to zawsze ostatni krok.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Zautomatyzowane przepływy pracy IR

Ustalenia GuardDuty powinny uruchamiać izolację w ciągu sekund, a nie godzin. Kanoniczny potok przetwarzania to EventBridge → Lambda → SSM Automation, z wykorzystaniem SNS do powiadomień.

Reguła EventBridge dopasowuje zdarzenia z source: aws.guardduty o typie szczegółów GuardDuty Finding i wzorcu filtrującym typy ustaleń istotne dla EC2, takie jak UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* i CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Docelowa funkcja Lambda wyodrębnia ID instancji z detail.resource.instanceDetails.instanceId, a następnie wywołuje dokument SSM Automation (lub bezpośrednio wywołuje SDK), aby: włączyć ochronę przed terminacją, zastąpić grupy bezpieczeństwa ENI grupą kwarantanny za pomocą ModifyNetworkInterfaceAttribute, utworzyć snapshoty wszystkich podłączonych woluminów, otagować instancję i opublikować wiadomość SNS na kanale SOC. Użycie SSM Automation zamiast surowych wywołań SDK zapewnia szczegółowe ścieżki audytu w historii wykonań Automation.

Logowanie na potrzeby analizy eksfiltracji i C2

Izolacja bez telemetrii to działanie po omacku. VPC Flow Logs muszą być włączone na poziomie VPC lub podsieci z typem ruchu ustawionym na ALL (zarówno ACCEPT, jak i REJECT). Rekordy REJECT ujawniają skanowanie, zablokowane próby eksfiltracji i sygnały C2 próbujące dotrzeć do znanych złośliwych adresów IP; rekordy ACCEPT pokazują, które przepływy zakończyły się powodzeniem. Przekieruj logi przepływu do CloudWatch Logs w celu wykonywania zapytań w czasie rzeczywistym oraz do S3 w celu długoterminowego przechowywania z użyciem Object Lock. CloudTrail z włączonymi zdarzeniami danych (data events) dla bucketu S3 z danymi śledczymi i KMS zapewnia łańcuch dowodowy (audit chain) dla obsługi materiału dowodowego. Połącz to z logowaniem zapytań DNS (Route 53 Resolver), aby wychwycić DGA i tunelowanie DNS, których same logi przepływu by nie wykryły.

Kontrolowany dostęp do analizy śledczej przez Session Manager

Session Manager eliminuje potrzebę używania kluczy SSH, bastionów czy otwierania portów 22/3389, co jest dokładnie powodem, dla którego grupa bezpieczeństwa kwarantanny może blokować wszelki tradycyjny dostęp. Włącz logowanie sesji do bucketu S3 z SSE-KMS oraz do CloudWatch Logs; wymuś ustawienie EnforceEncryption=true w preferencjach sesji, aby żadna sesja nie działała bez TLS i szyfrowania logów. Polityki IAM dla akcji ssm:StartSession powinny być ograniczone do instancji z tagiem tag:Status=Quarantined i przyznawane wyłącznie roli przeznaczonej do reagowania na incydenty.

Typowe pułapki i dlaczego są nieskuteczne

• Zatrzymywanie lub terminowanie w pierwszej kolejności. Zatrzymanie zwalnia pamięć, zrywa aktywne połączenia i uniemożliwia przechwycenie artefaktów ulotnych. Terminowanie dodatkowo zwalnia wolumin główny, chyba że ustawiono DeleteOnTermination=false, a nawet wtedy tracisz stan czasu wykonania. Zawsze izoluj instancję w jej bieżącym stanie przed jakąkolwiek zmianą stanu zasilania.

• Poleganie wyłącznie na grupach bezpieczeństwa, gdy NACL są szybsze. Zmiany w SG są precyzyjne, ale wpływają tylko na ENI, do którego są dołączone, i zarządzają tylko nowymi przepływami. Gdy problem dotyczy wielu instancji w podsieci lub gdy istniejąca sesja wychodząca atakującego musi zostać natychmiast przerwana, reguła deny na poziomie NACL w podsieci zamyka drzwi szybciej, ponieważ NACL są bezstanowe i blokują każdy pakiet niezależnie od poprzedniego stanu.

• Naprawianie przed wykonaniem snapshotu. Ponowne obrazowanie, łatanie lub wymiana instancji przed utworzeniem snapshotów EBS niszczy dowody rezydujące na dysku — pliki binarne złośliwego oprogramowania, mechanizmy utrzymania dostępu, logi, znaczniki czasu. Snapshoty są tanie i niezmienne; wykonaj je przed jakąkolwiek akcją naprawczą i skopiuj na dedykowane konto analityki śledczej, aby przejęte konto produkcyjne nie mogło ich usunąć.

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial zarządza środowiskiem AWS z wieloma kontami, z obciążeniami produkcyjnymi na dedykowanym koncie: usługi EC2 i EKS hostujące dane klientów, buckety S3 na archiwa, scentralizowane logowanie na koncie bezpieczeństwa z włączonymi CloudTrail, GuardDuty, Security Hub i Config oraz potok CI/CD do wdrożeń. Ich zespół operacyjny używa Systems Manager do łatania i utrzymania oraz Route 53/ALB dla publicznych punktów końcowych.

Wyzwanie: Wykrycie przez GuardDuty i nieoczekiwane skoki ruchu wychodzącego wskazują na prawdopodobne przejęcie instancji EC2, która dokonuje eksfiltracji danych i wykonuje podejrzane wywołania API IAM. Wymaga to natychmiastowej izolacji przy jednoczesnym zachowaniu dowodów do analizy śledczej i utrzymaniu audytowalnego dostępu dla analityków.

Zalecane podejście:

1. Uruchom natychmiastową izolację za pomocą EventBridge w odpowiedzi na wykrycie GuardDuty, aby wywołać przepływ pracy Step Functions, który używa Lambda/SSM Automation do dołączenia grupy bezpieczeństwa kwarantanny, usunięcia publicznych adresów IP lub odłączenia ENI oraz unieważnienia/rotacji powiązanych poświadczeń IAM za pomocą IAM.
2. Zabezpiecz dowody ulotne i trwałe, wykonując dokument SSM Automation w celu utworzenia snapshotu EBS i obrazu AMI instancji, skopiowania snapshotów na dedykowane konto AWS do analizy śledczej oraz przechowywania wyeksportowanych artefaktów w buckecie S3 z S3 Object Lock (w trybie zgodności) i szyfrowaniem KMS.
3. Przechwytuj logi do analizy eksfiltracji i C2, upewniając się, że zdarzenia zarządcze i zdarzenia danych CloudTrail (S3, Lambda) są włączone, przekierowując VPC Flow Logs, logi dostępowe ALB/NGINX i logi zapytań Route 53 na centralne konto bezpieczeństwa, oraz eskalując wykrycie do Amazon Detective w celu korelacji na osi czasu.
4. Zautomatyzuj orkiestrację i powiadomienia za pomocą EventBridge -> Step Functions -> Lambda, aby koordynować izolację, kopiowanie dowodów, powiadomienia SNS do właścicieli incydentu i tworzenie zgłoszeń w istniejącym systemie ITSM.
5. Zapewnij kontrolowany dostęp do analizy śledczej, wymagając użycia AWS Systems Manager Session Manager do sesji dochodzeniowych na żywo, z logowaniem sesji do CloudWatch Logs i bucketu S3 do analizy śledczej, dostępnego tylko dla wyznaczonej roli IAM analityka śledczego z MFA i tymczasowymi poświadczeniami.

Uzasadnienie: To podejście szybko izoluje zagrożenie, zabezpiecza niezmienne artefakty i scentralizowane logi do analizy, automatyzuje powtarzalne kroki reakcji w celu skrócenia czasu do izolacji oraz wymusza audytowalny dostęp do analizy śledczej z najmniejszymi uprawnieniami za pomocą Session Manager, zgodnie z najlepszymi praktykami AWS.

← Bezpieczeństwo kontenerów i Serverless · Wszystkie domeny

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

Przeglądaj Amazon →