Amazon SCS-C02: Wykrywanie zagrożeń i alertowanie — 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.
Centralizacja GuardDuty w całej organizacji
Amazon GuardDuty to usługa ciągłego wykrywania zagrożeń, która analizuje zdarzenia zarządzania i zdarzenia danych CloudTrail, logi VPC Flow Logs, logi zapytań DNS, logi audytowe EKS, aktywność logowania do RDS oraz telemetrię środowiska uruchomieniowego. Generuje ona wyniki (findings) sklasyfikowane według celu zagrożenia (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) oraz typu zasobu (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).
Zarządzanie GuardDuty na poziomie pojedynczych kont nie jest skalowalne. Prawidłową architekturą w środowisku AWS Organizations jest wyznaczenie delegowanego administratora — zazwyczaj dedykowanego konta bezpieczeństwa lub audytu — przy użyciu konta zarządzającego Organizations. Z poziomu delegowanego administratora włączasz GuardDuty dla całej organizacji i aktywujesz opcję auto-enable, aby nowe konta członkowskie i nowe regiony były chronione automatycznie w momencie ich tworzenia. Bez opcji auto-enable, nowo utworzone konto pozostaje bez ochrony, dopóki operator ręcznie nie włączy wykrywania, co jest dokładnie tą luką, którą atakujący wykorzystują podczas procesu onboardingu.
Problem praktyczny: Scenariusz użycia
Scenariusz: Meridian Financial zarządza środowiskiem AWS obejmującym 28 kont dla usług produkcyjnych, deweloperskich i współdzielonych. Ich konto zarządzające zarządza kontami za pośrednictwem AWS Organizations, ze scentralizowanym logowaniem CloudTrail i S3, ale alerty bezpieczeństwa i dane dochodzeniowe są rozproszone po kontach członkowskich, co sprawia, że segregacja incydentów (triage) jest powolna i niespójna.
Wyzwanie: Niedawne wykrycie ruchu bocznego (lateral movement) na jednym z kont wygenerowało wyniki GuardDuty, które nie były wystarczająco szybko widoczne dla centralnych narzędzi SOC, co opóźniło powstrzymanie ataku i dochodzenie śledcze.
Zalecane podejście:
- Wyznacz delegowanego administratora GuardDuty na koncie zarządzającym i włącz GuardDuty w całej organizacji za pośrednictwem AWS Organizations, aby wszystkie konta członkowskie przekazywały wyniki do centralnego detektora.
- Włącz scentralizowany AWS Security Hub na koncie zarządzającym jako agregator i aktywuj Security Hub dla wszystkich kont i regionów, aby normalizować wyniki GuardDuty wraz z innymi standardami bezpieczeństwa.
- Skonfiguruj reguły Amazon EventBridge na koncie zarządzającym, aby przechwytywać wyniki z GuardDuty i Security Hub i kierować je do scentralizowanych celów, takich jak Amazon SNS do powiadamiania (paging), Amazon Kinesis Data Firehose do S3 w celu archiwizacji lub bezpośrednie dostarczanie do Twojego systemu SIEM.
- Wdróż mechanizmy reagujące (responders) oparte na Lambda, wyzwalane przez EventBridge, do zautomatyzowanych działań powstrzymujących (na przykład izolowanie instancji EC2 za pomocą API EC2 i tworzenie incydentu w AWS Systems Manager) oraz oznaczaj wyniki do dalszego dochodzenia.
- Zintegruj Amazon Detective w celu scentralizowanego dochodzenia i przekazuj zarchiwizowane wyniki z S3 do swojego systemu analitycznego/SIEM w celu długoterminowej korelacji i raportowania.
Uzasadnienie: Użycie delegowanego administratora GuardDuty wraz z Security Hub i EventBridge centralizuje wykrywanie, normalizuje alerty i umożliwia zautomatyzowane, audytowalne reakcje zgodnie z najlepszymi praktykami AWS w zakresie wykrywania zagrożeń w całej organizacji i szybkiego reagowania na incydenty.
# From the Organizations management account
aws organizations enable-aws-service-access \
--service-principal guardduty.amazonaws.com
aws guardduty enable-organization-admin-account \
--admin-account-id 111122223333
# From the delegated admin
aws guardduty update-organization-configuration \
--detector-id abc123 \
--auto-enable-organization-members ALL \
--features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
{"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
{"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'
GuardDuty działa w ujęciu regionalnym, więc relacja delegowanego administratora i ustawienia auto-enable muszą być skonfigurowane w każdym regionie, w którym działasz. Jest to częste źródło martwych punktów — zespół włącza GuardDuty w us-east-1 i zakłada, że ochrona jest globalna.
Ochrona specyficzna dla usług
Podstawowa wersja GuardDuty obejmuje fundamentalne źródła danych, ale kilka planów ochrony musi być jawnie włączonych, ponieważ wiążą się one z dodatkowymi kosztami i pozyskiwaniem dodatkowej telemetrii:
RDS Protection: profiluje aktywność logowania do silników Aurora MySQL/PostgreSQL i RDS, generując wyniki takie jak
CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin, gdy nieznani użytkownicy uwierzytelniają się w punkcie końcowym bazy danych. Jest to właściwe źródło do wykrywania podejrzanych logowań do bazy danych — nie twórz niestandardowych filtrów metryk CloudWatch na logach audytowych bazy danych, gdy RDS Protection natywnie emituje odpowiedni wynik.EKS Protection: przetwarza logi audytowe Kubernetes w celu wykrywania anomalnego dostępu do API, tworzenia uprzywilejowanych podów oraz użycia wystawionych na zewnątrz dashboardów.
Runtime Monitoring: wdraża lekkiego agenta opartego na eBPF na instancjach EC2, kontenerach ECS/Fargate lub w EKS, aby ujawniać zdarzenia dotyczące procesów, plików i sieci — jest to wymagane do wykrywania złośliwego oprogramowania bezplikowego (fileless malware) lub powłok zwrotnych (reverse shells) w czasie rzeczywistym.
Malware Protection: skanuje migawki woluminów EBS podłączonych do instancji oznaczonych przez inne wyniki lub wykonuje skanowanie na żądanie obiektów S3 podczas ich przesyłania.
Lambda Protection i S3 Protection: obejmują odpowiednio wzorce wywołań funkcji oraz dostęp do płaszczyzny danych S3.
Włączenie tylko podstawowej usługi i oczekiwanie, że pojawią się anomalie logowania do bazy danych, jest częstym błędem w konfiguracji — te typy wyników po prostu nie są generowane, dopóki odpowiednia funkcja nie zostanie włączona.
Security Hub jako płaszczyzna agregacji
Security Hub pobiera wyniki (findings) z usług GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health oraz produktów firm trzecich (ISV), normalizując je do formatu AWS Security Finding Format (ASFF). Uruchamia również własne standardy zgodności (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).
Aby scentralizować w całej organizacji:
Włącz Security Hub jako usługę w Organizations i wyznacz delegowanego administratora (zazwyczaj to samo konto bezpieczeństwa co dla GuardDuty).
Włącz automatyczne włączanie dla nowych kont, aby członkowie byli dodawani automatycznie.
Skonfiguruj region agregacji wyników (nazywany również regionem domowym) i połącz z nim wszystkie inne regiony. Bez agregacji międzyregionalnej, każdy region utrzymuje niezależną instancję Security Hub, a analitycy muszą przełączać się między konsolami.
Wzorzec globalnego wdrożenia w organizacji wymaga zatem dwóch skoordynowanych ustawień: połączenia z regionem agregacji oraz przełącznika automatycznego włączania dla całej organizacji. Włączenie jednego bez drugiego pozostawia nowe konta bez ochrony lub nowe regiony w izolacji.
Ważne ograniczenie: Security Hub agreguje i priorytetyzuje, ale nie naprawia (remediate). Traktowanie go jako platformy do naprawy to błąd kategoryczny — naprawa odbywa się za pośrednictwem EventBridge w dalszej części procesu (downstream).
EventBridge jako szkielet automatyzacji
Zarówno GuardDuty, jak i Security Hub publikują wyniki na domyślnej magistrali zdarzeń (event bus). aws.guardduty emituje zdarzenia GuardDuty Finding, a aws.securityhub emituje Security Hub Findings - Imported (utworzone/zaktualizowane przez Hub) oraz Security Hub Findings - Custom Action (wywołane przez operatora).
Zbyt ogólne reguły, takie jak {"source": ["aws.securityhub"]}, wywołują cele (targets) przy każdej aktualizacji wyniku od każdego dostawcy, szybko zalewając tematy SNS i powiadamiając inżynierów dyżurnych szumem informacyjnym. Prawidłowe podejście to filtrowanie po wartościach severity.Label, ProductArn, Types lub konkretnych Title:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{ "numeric": [">=", 7] }],
"type": [{ "prefix": "CredentialAccess:RDS/" }]
}
}
Dla wzorca skoncentrowanego na Security Hub, który uruchamia się tylko dla wyników GuardDuty o wysokiej wadze, ignorując jednocześnie głośne produkty firm trzecich (ISV):
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": { "Label": ["HIGH", "CRITICAL"] },
"ProductArn": [
{ "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
],
"Workflow": { "Status": ["NEW"] }
}
}
}
Typowe cele (targets) to temat SNS do powiadomień e-mail/SMS/Slack, funkcja Lambda izolująca instancję poprzez zamianę jej security group, runbook SSM Automation lub maszyna stanów Step Functions orkiestrująca wieloetapową odpowiedź. Dla przypadku użycia anomalii logowania w Aurora, ścieżka wymagająca minimalnego wysiłku to GuardDuty RDS Protection → reguła EventBridge filtrująca po typie wyniku RDS → temat SNS z subskrypcją e-mail. Nie jest wymagane niestandardowe odpytywanie (polling), żadna Lambda ani zewnętrzny system SIEM.
Niestandardowe akcje Security Hub (Custom Actions)
Akcje niestandardowe to wyzwalacze uruchamiane przez operatora. W konsoli Security Hub analityk wybiera jeden lub więcej wyników i wybiera akcję niestandardową (na przykład „Kwarantanna EC2”). Security Hub emituje zdarzenie Security Hub Findings - Custom Action zawierające ARN-y wybranych wyników; reguła EventBridge dopasowuje ARN akcji niestandardowej i wywołuje funkcję Lambda, która wykonuje odpowiedź. Daje to przycisk wymagający interwencji człowieka (human-in-the-loop) bez konieczności budowania dedykowanego interfejsu użytkownika:
aws securityhub create-action-target \
--name "Quarantine EC2" \
--description "Attach isolation SG and snapshot volumes" \
--id QuarantineEC2
Wynikowy ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) staje się wartością do dopasowania w polu resources reguły EventBridge.
Wyciszanie i zarządzanie sygnałem
Zarządzanie szumem to dyscyplina, a nie jednorazowy filtr. Użyj reguł automatyzacji Security Hub lub reguł wyciszania GuardDuty, aby automatycznie archiwizować wyniki, o których wiadomo, że są nieszkodliwe (na przykład oczekiwany wynik Recon:EC2/Portscan z narzędzia do testów penetracyjnych). Filtruj reguły EventBridge po ProductArn, aby wyciszyć „gadatliwą” integrację zewnętrzną bez jej całkowitego wyłączania. Połącz Severity.Label z Workflow.Status = NEW, aby ponownie otwarte lub już zgłoszone wyniki nie generowały ponownych powiadomień. Celem jest, aby każdy alert docierający do człowieka reprezentował zdarzenie o wysokim stopniu pewności, wymagające podjęcia działań — wszystko inne osłabia gotowość do reagowania.
Punkt wyjścia do dochodzenia (Investigation Pivot)
Gdy pojawi się wynik o wysokiej wadze — na przykład Backdoor:EC2/C&CActivity.B!DNS — najszybszą ścieżką dochodzenia nie jest ręczne pisanie zapytań Athena do logów CloudTrail i Flow Logs. Amazon Detective, gdy jest włączony razem z GuardDuty, wstępnie buduje grafy encji na podstawie logów CloudTrail, VPC Flow Logs i wyników GuardDuty. Przejście (pivoting) od wyniku bezpośrednio do roli IAM lub profilu instancji EC2 w Detective ujawnia aktywność API, komunikujące się zasoby sieciowe (network peers) oraz liczbę udanych i nieudanych połączeń w odpowiednim oknie czasowym, bez konieczności tworzenia niestandardowych zapytań.
← Zarządzanie tożsamością i dostępem · Wszystkie domeny · Logowanie →
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 →