Amazon SCS-C02: Podatności, poprawki i bezpieczeństwo hostów — 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.
Amazon Inspector: Rozszerzone skanowanie dla EC2, Lambda i ECR
Amazon Inspector to ciągła, wspierana przez agenta usługa zarządzania podatnościami, która wykrywa podatności CVE w instancjach EC2, obrazach kontenerów przechowywanych w ECR oraz funkcjach Lambda (zarówno w kodzie aplikacji, jak i w warstwach zależności). Włączenie Inspectora na poziomie konta automatycznie obejmuje skanowaniem kwalifikujące się zasoby — nie ma procesu aktywacji dla każdego zasobu z osobna — a wyniki są automatycznie przesyłane do AWS Security Hub w standardowym formacie ASFF, co jest poprawnym wzorcem integracji, gdy wymagany jest centralny panel stanu bezpieczeństwa.
Dla EC2, Inspector używa hybrydowego modelu skanowania. Agent SSM (z dostarczoną przez AWS asocjacją) zbiera inwentarz oprogramowania używany do oceny osiągalności sieciowej i pakietów w stylu bezagentowym, podczas gdy głęboka ocena hosta wymaga, aby agent był uruchomiony, a instancja osiągalna przez SSM. Dlatego podejście “tylko bezagentowe” to pułapka: bez ścieżki przez Agenta SSM (lub głębokiej inspekcji opartej na agencie Inspectora, gdy jest to wymagane), otrzymujesz płytkie wyniki — ekspozycję sieciową i podatności CVE pochodzące z manifestu — ale pomijasz inwentarze bibliotek wykonawczych, niezarządzane pakiety i konfiguracje. Tryb hybrydowy jest tym, czego potrzebuje większość środowisk produkcyjnych.
Dla Lambda, Inspector wykonuje dwa typy skanowania: standardowe (podatności w pakietach w warstwach i zależnościach funkcji) oraz skanowanie kodu (statyczna analiza kodu funkcji pod kątem luk typu injection, zaszytych na stałe sekretów i niezabezpieczonych API). Kluczowa zasada kwalifikowalności: funkcja Lambda musi być wywołana co najmniej raz w ciągu ostatnich 90 dni, aby została przeskanowana. Nieaktywne lub zarchiwizowane funkcje po cichu wypadają z zakresu działania Inspectora. Zespoły, które zakładają, że “Inspector jest włączony, więc każda funkcja jest objęta ochroną”, napotykają problemy, gdy audytorzy proszą o dowody dotyczące rzadko wykonywanych funkcji. Rozwiązaniem jest albo cykliczne wywoływanie funkcji (EventBridge), albo akceptacja i udokumentowanie tego wykluczenia.
Dla ECR, skanowanie rozszerzone (obsługiwane przez Inspector) zastępuje starsze skanowanie podstawowe oparte na Clair. Skanowanie rozszerzone wspiera zarówno skanowanie przy wypchnięciu (scan on push), jak i skanowanie ciągłe obrazów już znajdujących się w rejestrze, dzięki czemu nowo ujawnione podatności CVE w odniesieniu do wcześniej wypchniętych obrazów generują nowe wyniki bez konieczności ponownego pusha. Włącz skanowanie rozszerzone na poziomie rejestru i skonfiguruj filtry dla poszczególnych repozytoriów (na przykład prod/* skanowanie ciągłe, sandbox/* tylko skanowanie przy wypchnięciu), aby kontrolować koszty.
Delegowane administrowanie i wyciszanie
W konfiguracji wielokontowej AWS Organizations, wyznacz konto delegowanego administratora dla Inspectora z poziomu konta zarządzającego. Delegowany administrator widzi zagregowane wyniki ze wszystkich kont członkowskich i zarządza konfiguracją skanowania dla całej organizacji. Pozwala to uniknąć nadawania międzykontowych ról IAM w celu pobierania wyników i zapobiega antywzorcowi polegającemu na włączaniu Inspectora fragmentarycznie na każdym koncie.
Reguły wyciszania (suppression rules) pozwalają zespołowi bezpieczeństwa filtrować szum bez usuwania wyników. Reguła dopasowuje wyniki na podstawie atrybutów takich jak tag zasobu, poziom ważności, ID podatności CVE czy repozytorium ECR. Aby wyniki z funkcji Lambda w środowisku dev/test nie pojawiały się na produkcyjnym panelu, zastosuj regułę wyciszania opartą o tag Environment=dev — wyniki nadal istnieją w bazowym magazynie danych na potrzeby audytu, ale są wykluczone z domyślnych widoków oraz z Security Hub, jeśli tak skonfigurowano. Nie należy osiągać tego celu poprzez wyłączanie Inspectora dla kont deweloperskich; tracisz zdolność do wychwycenia promocji podatnego artefaktu z środowiska deweloperskiego na produkcyjne.
Bramkowanie w CI/CD przy promocji obrazów
Rozszerzone skanowanie ECR generuje wyniki powiązane ze skrótem obrazu (digest) (a nie tylko z tagiem), który potok CI/CD musi sprawdzać. Kanoniczny wzorzec jest następujący: zbuduj obraz → wypchnij do ECR (uruchamia skanowanie przy wypchnięciu) → odpytuj lub czekaj na zakończenie skanowania → przerwij budowanie, jeśli istnieją wyniki o statusie High lub Critical → w przeciwnym razie zaktualizuj zadanie/deployment ECS/EKS.
Minimalny krok w CodeBuild w pliku buildspec.yml:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
Brak bramkowania na tym etapie – ufając, że “Inspector nas zaalarmuje” – to klasyczny błąd: alerty przychodzą asynchronicznie i już po tym, jak podatny obraz jest uruchomiony. Bramka musi działać synchronicznie z procesem promocji. Podobnie, bramkowanie tylko na podstawie tagu zamiast digestu jest niebezpieczne, ponieważ tagi są mutowalne (zmienne); dwa wypchnięcia z tym samym tagiem spowodują pomieszanie wyników skanowania.
Patch Manager, linie bazowe i grupy poprawek
SSM Patch Manager operuje na trzech podstawowych elementach:
Linia bazowa poprawek (patch baseline): definiuje reguły automatycznego zatwierdzania, zatwierdzone poprawki, odrzucone poprawki oraz poziom zgodności (compliance) dla danego poziomu ważności/klasyfikacji.
Grupa poprawek (patch group): tag o kluczu dokładnie
Patch Group, którego wartość rejestruje instancje do określonej linii bazowej.Okno konserwacyjne (maintenance window): harmonogram, podczas którego zadanie
AWS-RunPatchBaselinewykonuje operacje Scan lub Install.
Dla środowiska, które wymaga, aby Dev automatycznie zatwierdzał wszystkie poprawki bezpieczeństwa natychmiast, a Prod zatwierdzał tylko poprawki Critical/Important po 7-dniowym okresie testowym, odrzucając jednocześnie pakiety jądra, tworzysz dwie linie bazowe. Linia bazowa Dev używa reguły zatwierdzania z ApproveAfterDays: 0 obejmującej wszystkie klasyfikacje bezpieczeństwa. Linia bazowa Prod używa ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtruje Classification=Security i Severity in [Critical, Important] oraz dodaje kernel* do listy odrzuconych poprawek z BlockAllPatchesFromRejectedList. Instancje są tagowane Patch Group=Dev lub Patch Group=Prod, a każda grupa poprawek jest zarejestrowana do odpowiedniej linii bazowej. Informacje o zgodności są agregowane w raportach Patch Compliance i mogą być eksportowane do S3 w celu centralnego audytu.
Pojedyncza linia bazowa “z logiką” nie jest w stanie wyrazić różnic między Dev a Prod — linie bazowe są statyczne dla każdej zarejestrowanej grupy. Nie próbuj używać różnych okien konserwacyjnych, aby symulować to zachowanie; okno kontroluje, kiedy odbywa się patchowanie, a nie które poprawki są zatwierdzane.
Potok powiadomień w czasie rzeczywistym
W przypadku alertów o nowych znaleziskach wysyłanych do Slacka lub Microsoft Teams, operacyjnie wydajny łańcuch wygląda następująco:
Inspector emituje znaleziska do EventBridge w źródle zdarzeń
aws.inspector2.Reguła EventBridge filtruje według wagi (np.
HIGH,CRITICAL) i kieruje ruch do tematu SNS.Temat SNS ma subskrypcję AWS Chatbot zmapowaną na kanał Slack lub obszar roboczy Teams.
Chatbot subskrybuje bezpośrednio SNS — nie umieszczaj pomiędzy nimi funkcji Lambda do reformatowania wiadomości, ponieważ Chatbot natywnie renderuje znaleziska z Inspectora. Przykładowy wzorzec EventBridge:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Dwie pułapki, których należy tu unikać: routing przez Security Hub dodaje opóźnienia i może obniżyć granulację wagi, jeśli niestandardowe analizy (insights) są błędnie skonfigurowane; a używanie SES lub niestandardowej funkcji Lambda z webhookiem zwiększa narzut operacyjny bez dodawania funkcjonalności, którą Chatbot już zapewnia natywnie.
Problem praktyczny: Scenariusz użycia
Scenariusz: Meridian Financial zarządza wielokontową organizacją AWS, która obsługuje usługi internetowe dla klientów, analitykę wsadową i bezserwerowe procesory zdarzeń. Ich potoki CI/CD wypychają obrazy kontenerów do Amazon ECR, utrzymują floty EC2 dla starszych obciążeń i używają Lambda dla nowszych usług; centralny zespół ds. bezpieczeństwa na koncie bezpieczeństwa musi zarządzać widocznością podatności i procesem patchowania na wszystkich kontach.
Wyzwanie: Niedawno obraz zawierający bibliotekę o wysokiej wadze podatności został wdrożony na produkcję, ponieważ skanowanie nie było wymuszane w CI/CD, a patchowanie instancji EC2 jest niespójne w różnych środowiskach, co pozostawia okna ekspozycji na zagrożenia i generuje szum informacyjny w postaci znalezisk, które przytłaczają zespół.
Zalecane podejście:
- Włącz Amazon Inspector Enhanced Scanning dla EC2, Lambda i ECR z poziomu konta bezpieczeństwa, konfigurując delegowaną administrację w AWS Organizations, aby skany, znaleziska i reguły wyciszania (suppression rules) mogły być zarządzane centralnie.
- Skonfiguruj skanowanie obrazów ECR przy wypychaniu (on push) i zintegruj bramki skanowania w CodePipeline/CodeBuild: blokuj promowanie obrazu, dopóki wyniki skanowania Inspector/ECR nie spełnią progów wagi, i prezentuj znaleziska w kroku budowania.
- Wdróż AWS Systems Manager Patch Manager z zdefiniowanymi bazami łatek (patch baselines) i grupami łatek (patch groups) dla każdego środowiska, zaplanuj okna konserwacyjne (Maintenance Windows) dla wdrożeń zaczynających się od środowisk nieprodukcyjnych i zautomatyzuj zatwierdzanie krytycznych poprawek CVE za pomocą dokumentów SSM Automation.
- Stwórz potok powiadomień w czasie rzeczywistym używając Amazon EventBridge do przechwytywania znalezisk z Inspectora i zdarzeń zgodności SSM, kieruj je do Amazon SNS i lekkiej funkcji AWS Lambda, która wzbogaca, deduplikuje i publikuje priorytetowe alerty na Slacku oraz tworzy zgłoszenia do śledzenia.
- Zautomatyzuj powstrzymywanie i usuwanie skutków (remediation): użyj wyzwalanych przez EventBridge dokumentów SSM Automation lub runbooków Lambda do izolowania dotkniętych wersji EC2/Lambda lub wyzwalania przebudowy obrazów, i stosuj wyciszanie w Inspectorze tylko dla śledzonych fałszywych alarmów (false positives) za pośrednictwem konta delegowanego administratora, aby zredukować szum.
Uzasadnienie: Scentralizowane zarządzanie Inspectorem, bramki w CI/CD, bazy łatek w Patch Managerze oraz potok oparty na EventBridge są zgodne z najlepszymi praktykami AWS, wymuszając zautomatyzowaną prewencję, spójne patchowanie oraz priorytetyzowaną, audytowalną reakcję, jednocześnie redukując zmęczenie alertami.
Odkrywanie podatności za pomocą Amazon Inspector
Amazon Inspector to główna zarządzana usługa oceny podatności w AWS, działająca na trzech płaszczyznach istotnych dla bezpieczeństwa hostów: instancje EC2, obrazy kontenerów w Amazon ECR oraz funkcje Lambda. Po włączeniu na poziomie konta lub organizacji (poprzez delegowanego administratora w konsoli Inspector), wykonuje ciągłe skanowanie bezagentowe lub oparte na SSM, zamiast zaplanowanych skanów w określonym punkcie czasowym. Ta ciągła postawa jest ważna, ponieważ bazy danych CVE zmieniają się codziennie; zrzut z zeszłego tygodnia może być już nieaktualny.
W przypadku EC2, Inspector polega na agencie SSM do wyliczania zainstalowanych pakietów i wersji jądra, a następnie koreluje je z biuletynami dostawców i National Vulnerability Database. Znaleziska zawierają identyfikator CVE, wynik CVSS, pakiet, którego dotyczy problem, wersję z poprawką oraz kontekst dostępności sieciowej (reguły dostępności sieciowej identyfikują porty wystawione na internet poprzez ENI, grupy bezpieczeństwa, NACL i tablice routingu). Ponieważ skanowanie zależy od SSM, instancja EC2, która nie ma przypisanej zarządzanej polityki AmazonSSMManagedInstanceCore do swojego profilu instancji, po prostu nie pojawi się w wynikach Inspectora — to cicha awaria, o której warto pamiętać.
Dla ECR, Inspector obsługuje dwa tryby skanowania:
Skanowanie podstawowe (Basic scanning): darmowe, używa silnika open-source Clair, uruchamiane tylko przy wypychaniu (on push) lub na żądanie.
Skanowanie rozszerzone (Enhanced scanning): oparte na Inspectorze, ciągle ponownie skanuje obrazy (zarówno pakiety systemowe, jak i pakiety języków aplikacji, takie jak Python, Node, Java), gdy publikowane są nowe CVE, nawet długo po zdarzeniu wypchnięcia.
Częstą pułapką jest traktowanie skanowania ECR przy wypychaniu (scan-on-push) jako wystarczającego zabezpieczenia hosta. Tak nie jest. Skanowanie przy wypychaniu weryfikuje obraz w czasie budowania, ale działający kontener dziedziczy obraz oraz wszelkie zmiany (drift), a podstawowy host EC2 lub Fargate ma własne jądro i pakiety systemowe, które muszą być patchowane niezależnie. Skanowanie rozszerzone w połączeniu ze skanowaniem hostów EC2 wypełnia tę lukę. Wszystkie znaleziska z Inspectora powinny być kierowane do AWS Security Hub, który normalizuje je do formatu ASFF i umożliwia agregację międzykontową, deduplikację oraz dalszą automatyzację za pośrednictwem EventBridge.
Patch Manager i Naprawa w Całej Flocie
AWS Systems Manager Patch Manager uzupełnia usługę Inspector, faktycznie naprawiając to, co Inspector wykryje. Podczas gdy Inspector odpowiada na pytanie „które CVE mnie dotyczą?”, Patch Manager odpowiada na pytania „których poprawek brakuje i jak je bezpiecznie zainstalować?”.
Patch Manager działa w oparciu o linie bazowe poprawek (patch baselines) — deklaratywne reguły, które określają, które poprawki są zatwierdzone, na podstawie klasyfikacji (Security, Critical, Bugfix), wagi (severity) i opóźnienia automatycznego zatwierdzania (na przykład zatwierdzanie poprawek bezpieczeństwa siedem dni po ich wydaniu, aby zapewnić stabilność dostawcy). AWS dostarcza domyślne linie bazowe dla każdego systemu operacyjnego (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline itp.), ale floty produkcyjne zazwyczaj używają niestandardowych linii bazowych powiązanych z grupami poprawek (patch groups) za pomocą tagu Patch Group na instancjach.
Typowy przepływ pracy skanowania i instalowania poprawek wykorzystuje dwie operacje:
Scan: raportuje zgodność bez instalowania czegokolwiek; wyniki pojawiają się na pulpicie zgodności Patch Managera oraz w usłudze Config.
Install: instaluje zatwierdzone poprawki i, w przypadku wielu systemów operacyjnych, ponownie uruchamia system.
Operacje te są zazwyczaj zaplanowane w ramach okien konserwacyjnych (maintenance windows) z celem w postaci dokumentu AWS-RunPatchBaseline. W przypadku pilnych scenariuszy typu zero-day, Patch Manager oferuje opcję Patch Now, czyli działanie na żądanie, które omija harmonogram okien konserwacyjnych. Zalecanym wzorcem jest utworzenie wąskiej linii bazowej poprawek, która zatwierdza tylko konkretny artykuł KB lub pakiet naprawiający podatność, wskazanie docelowej grupy poprawek, uruchomienie Patch Now i przesyłanie strumieniowe wyników wykonania do centralnego bucketu S3 i grupy CloudWatch Logs. Ten scentralizowany log staje się Twoim artefaktem audytowym — dowodem naprawy dla audytorów lub na potrzeby reagowania na incydenty.
Problem Praktyczny: Scenariusz Użycia
Scenariusz: Meridian Financial zarządza środowiskiem AWS obejmującym wiele kont z kilkuset instancjami EC2 (Windows i Amazon Linux) oraz małym klastrem EKS obsługującym usługi dla klientów. Używają AWS Organizations, AWS Systems Manager do narzędzi operacyjnych i utrzymują obrazy AMI na współdzielonym koncie, ale nie mają spójnego, zautomatyzowanego skanowania podatności ani skoordynowanego wdrażania poprawek na wszystkich kontach.
Wyzwanie: Opublikowano publiczne CVE dotyczące OpenSSL, a Amazon Inspector zgłasza wyniki o podwyższonej wadze na wielu instancjach, ale proces instalacji poprawek był nierównomierny, a jedna z usług produkcyjnych doświadczyła krótkiej próby wykorzystania luki z powodu opóźnionej naprawy.
Zalecane Podejście:
- Włącz Amazon Inspector na wszystkich kontach i we wszystkich regionach, aby przeprowadzać skanowanie podatności zarówno obrazów, jak i działających instancji, a wyniki o wysokiej wadze przesyłaj do AWS Security Hub i niestandardowej magistrali zdarzeń EventBridge.
- Użyj AWS Systems Manager Inventory do zidentyfikowania dotkniętych instancji i oznacz je tagami według krytyczności; utwórz linię bazową Patch Managera, która zawiera wymagane poprawki OpenSSL i docelowe reguły dla systemów Windows/Linux.
- Utwórz regułę EventBridge, która uruchamia dokument SSM Automation, gdy wyniki z Inspectora osiągną zdefiniowaną wagę, przekazując listę identyfikatorów instancji do runbooka Automation, który wywołuje Patch Manager lub Run Command w celu zastosowania poprawek i ponownego uruchomienia systemu w razie potrzeby.
- W przypadku usług stanowych lub o wysokim ryzyku, zorganizuj aktualizacje kroczące za pomocą EC2 Image Builder, aby tworzyć obrazy AMI z wgranymi poprawkami, aktualizuj grupy Auto Scaling lub grupy węzłów EKS za pomocą kontrolowanego wdrożenia typu blue/green lub kroczącego i weryfikuj stan usługi za pomocą kontroli kondycji Route 53/ALB.
- Po zakończeniu naprawy, ponownie uruchom Amazon Inspector, aby zweryfikować, że problemy zostały rozwiązane, zaktualizuj raportowanie zgodności w SSM Compliance i wyślij podsumowanie do zespołu bezpieczeństwa za pośrednictwem SNS; przechowuj runbook Automation w bibliotece Systems Manager Automation, aby umożliwić powtarzalne reagowanie w całej flocie.
Uzasadnienie: To podejście wykorzystuje Amazon Inspector do ciągłego wykrywania, Systems Manager Patch Manager i Automation do kontrolowanej, zautomatyzowanej naprawy oraz przebudowy opartej na obrazach dla niezmiennej infrastruktury (immutable infrastructure), co jest zgodne z najlepszymi praktykami AWS w zakresie wykrywania, automatycznej odpowiedzi i minimalizowania promienia rażenia.
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
Scentralizowana zgodność jest możliwa dzięki skonfigurowaniu konta delegowanego administratora w Systems Manager Explorer i włączeniu synchronizacji danych zasobów (resource data sync) w celu agregacji stanu zgodności poprawek z każdego konta w jednym buckecie S3, który można następnie przeszukiwać za pomocą Athena lub wizualizować w QuickSight.
Session Manager do Audytowalnej Administracji
Tradycyjny dostęp oparty na SSH ma trzy słabości strukturalne: długożyjący materiał klucza znajduje się na laptopach operatorów, port 22 musi być osiągalny (nawet jeśli tylko przez host bastionu), a aktywność powłoki nie jest centralnie rejestrowana bez dodatkowych narzędzi. Session Manager eliminuje wszystkie trzy.
Session Manager tuneluje interaktywną powłokę poprzez wychodzące połączenie HTTPS agenta SSM do punktów końcowych SSM. Nie ma portu przychodzącego, pary kluczy SSH ani hosta bastionu. Dostęp jest autoryzowany przez polityki IAM (zakres ssm:StartSession ograniczony przez tag instancji lub ARN), a każda sesja może być logowana do CloudWatch Logs lub S3, opcjonalnie z szyfrowaniem KMS. W systemie Linux sesje domyślnie działają jako użytkownik ssm-user; zachowanie sudo jest kontrolowane przez konfigurację sudoers instancji, a nie przez IAM.
Prawidłowy wzorzec wzmacniania bezpieczeństwa (hardening) dla nowych flot to: uruchamianie instancji bez pary kluczy EC2, dołączanie profilu instancji z AmazonSSMManagedInstanceCore, umieszczanie instancji w podsieciach prywatnych z punktami końcowymi VPC dla ssm, ssmmessages i ec2messages oraz wymuszanie logowania sesji na poziomie preferencji Session Managera. Kontynuowanie dystrybucji kluczy SSH obok Session Managera to pułapka: zachowuje ona tę samą powierzchnię ataku, którą Session Manager miał wyeliminować, i pozostawia nielogowany kanał dostępu. Usuń dostarczanie authorized_keys z procesu tworzenia obrazów AMI.
Telemetria hosta za pomocą agenta CloudWatch
Ujednolicony agent CloudWatch zbiera metryki na poziomie systemu operacyjnego (pamięć, dysk, CPU per proces) oraz pliki logów, których hypervisor EC2 nie widzi. Jest on konfigurowany za pomocą pliku JSON, zazwyczaj przechowywanego w Parameter Store, a następnie stosowany za pomocą amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.
Najczęstszą awarią operacyjną agenta jest brak uprawnień IAM w profilu instancji. Agent wymaga co najmniej:
logs:CreateLogGroup (chyba że grupa jest już utworzona)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (dla metryk niestandardowych)
ssm:GetParameter (do pobrania konfiguracji z Parameter Store)
Zarządzana polityka CloudWatchAgentServerPolicy grupuje te uprawnienia. Gdy brakuje uprawnień, agent uruchamia się pomyślnie i wygląda na sprawny w systemctl status, ale logi nigdy nie docierają do CloudWatch — błędy są widoczne tylko w /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Każdy projekt zabezpieczeń hosta, który zakłada centralizację logów, musi weryfikować ich dostarczenie, a nie tylko status agenta.
Podsumowanie
Pętla obronna wygląda następująco: Inspector wykrywa CVE na hostach i w obrazach kontenerów, wyniki przepływają do Security Hub w celu agregacji, Patch Manager naprawia systemy poprzez zaplanowane okna serwisowe lub opcję Patch Now w sytuacjach awaryjnych, Session Manager zapewnia jedyną ścieżkę dostępu administracyjnego, a agent CloudWatch przesyła strumieniowo zarówno dowody łatania, jak i logi czasu wykonania na scentralizowane konto. Każdy mechanizm kontrolny zakłada istnienie pozostałych: Inspector bez Patch Manager generuje raporty, na które nikt nie reaguje; Patch Manager bez scentralizowanego logowania nie tworzy ścieżki audytowej; Session Manager bez odpowiednich uprawnień IAM pozostawia albo zbyt szeroki, albo zbyt wąski dostęp; a agent CloudWatch bez prawidłowych uprawnień do logów stwarza jedynie iluzję widoczności.
← Nadzór · Wszystkie domeny · Bezpieczeństwo kontenerów i Serverless →
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 →