Amazon SCS-C02: Bezpieczeństwo kontenerów i Serverless — 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.
ECS Exec i inspekcja środowiska uruchomieniowego bez SSH
ECS Exec zapewnia interaktywną powłokę do działającego kontenera — w tym zadań Fargate — bez udostępniania SSH, serwerów bastionowych czy publicznych adresów IP. Działa w oparciu o agenta SSM, którego AWS wstrzykuje do środowiska wykonawczego sidecar zadania. Ponieważ nie ma demona SSH, żadnych kluczy ani przychodzącej ścieżki sieciowej do zabezpieczenia, narzut operacyjny jest minimalny, a każda sesja jest audytowalna przez CloudTrail i (opcjonalnie) logowana do S3 lub CloudWatch Logs.
Aby ECS Exec działał, muszą być spełnione wszystkie trzy poniższe wymagania:
Uprawnienia roli zadania: rola zadania (nie rola wykonawcza) potrzebuje uprawnień
ssmmessages:CreateControlChannel,ssmmessages:CreateDataChannel,ssmmessages:OpenControlChannelissmmessages:OpenDataChannel. Rola wykonawcza jedynie pobiera obrazy i zapisuje logi; ruch SSM w czasie działania przepływa przez rolę zadania, ponieważ jest to tożsamość przyjmowana przez proces kontenera.Konfiguracja usługi lub zadania: usługa musi być utworzona lub zaktualizowana z flagą
--enable-execute-command. Ta flaga włączaenableExecuteCommanddla nowych zadań; istniejące zadania muszą zostać zastąpione.Wsparcie w obrazie kontenera: kontener musi mieć w obrazie powłokę (
/bin/shlub/bin/bash).
Typowy przepływ inspekcji wygląda następująco:
aws ecs update-service --cluster prod --service api \
--enable-execute-command --force-new-deployment
aws ecs execute-command --cluster prod \
--task 5f8c...c2 --container api \
--interactive --command "/bin/sh"
Z tej powłoki inżynier może kopiować logi do S3, wyzwolić zrzut sterty (heap dump) lub odczytać /proc w celach analityki śledczej (forensics). Alternatywa — próba dostania się do kontenera przez SSH lub restart zadania w celu włączenia agenta debugującego — albo kończy się niepowodzeniem na Fargate, albo niszczy dowody, które próbowałeś zebrać.
Blokowanie dostępu do IMDS z kontenerów na EC2
Częstym błędem jest przekonanie, że ustawienia hop-limit IMDSv2 na instancji EC2 chronią kontenery na tej instancji. Tak nie jest, przynajmniej nie domyślnie w trybie sieciowym bridge lub host: kontenery współdzielą przestrzeń sieciową hosta lub mostek NAT i mogą dotrzeć do 169.254.169.254, aby pobrać poświadczenia profilu instancji, które są zazwyczaj znacznie bardziej uprzywilejowane niż rola zadania. To całkowicie zaprzecza zasadzie najmniejszych uprawnień (least privilege).
Rozwiązanie, gdy migracja na Fargate nie jest możliwa, składa się z dwóch części:
Użyj trybu sieciowego
awsvpcdla zadań. Każde zadanie otrzymuje własny ENI i przestrzeń sieciową. Ruch IMDS nie dociera już w sposób przezroczysty do punktu końcowego link-local hosta.Ustaw
ECS_AWSVPC_BLOCK_IMDS=truew pliku/etc/ecs/ecs.configna instancji kontenerowej. Informuje to agenta ECS o konieczności zainstalowania reguły iptables, która odrzuca pakiety z zadań awsvpc skierowane do169.254.169.254.
echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs
Połącz to z minimalnym profilem instancji (zasadniczo tylko to, czego potrzebuje agent ECS: AmazonEC2ContainerServiceforEC2Role) i rolami IAM per zadanie dla uprawnień aplikacji. Ustawienie limitu hop IMDS instancji na 1 z wymaganym IMDSv2 jest użytecznym środkiem obrony w głąb (defense-in-depth), ale nie jest substytutem — kontenery w trybie bridge nadal mogą dotrzeć do IMDS przy hop 1, ponieważ żądanie pochodzi od hosta.
GuardDuty Runtime Monitoring, EKS Protection i logi Control Plane
GuardDuty oferuje warstwową detekcję dla kontenerów:
EKS Protection analizuje logi audytowe EKS w celu wykrycia podejrzanej aktywności w API Kubernetes — anonimowego dostępu, tworzenia uprzywilejowanych podów, wywoływania exec na podach systemowych.
Runtime Monitoring wdraża sensor oparty na eBPF (jako zarządzany dodatek dla EKS lub zarządzany przez SSM agent dla ECS/Fargate), który obserwuje aktywność procesów, plików i sieci wewnątrz kontenerów. Ujawnia znaleziska takie jak reverse shells, binaria do kopania kryptowalut i eksfiltrację poświadczeń z wnętrza Poda lub zadania.
EKS Protection jest bezwartościowe, jeśli logi audytowe control plane EKS nie są faktycznie przesyłane do CloudWatch Logs. Włącz na klastrze co najmniej typy logów audit i authenticator:
aws eks update-cluster-config --name prod \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
Bez tego GuardDuty nie ma płaszczyzny danych do inspekcji w poszukiwaniu znalezisk EKS Protection — to pułapka, która często się pojawia, ponieważ operatorzy włączają funkcję GuardDuty, ale pozostawiają wyłączoną konfigurację logowania klastra, a następnie dziwią się, dlaczego nie pojawiają się żadne znaleziska związane z Kubernetes.
Skanowanie obrazów za pomocą ECR Enhanced Scanning
ECR Enhanced Scanning jest napędzane przez Amazon Inspector i zapewnia ciągłe skanowanie obrazów kontenerów pod kątem CVE w systemie operacyjnym i pakietach językowych (Python, Node, Java, Go, Ruby). Skanowanie podstawowe (Basic) jest jednorazowe w momencie wypychania obrazu (push) i obejmuje tylko pakiety systemowe; skanowanie rozszerzone (Enhanced) jest ciągłe i obejmuje zależności aplikacji, w których znajduje się większość współczesnych podatności.
Znaleziska automatycznie przepływają do Security Hub, gdy obie usługi są włączone, zapewniając jeden panel (single pane of glass) do zarządzania zgodnością i umożliwiając pisanie reguł EventBridge, które powodują niepowodzenie buildów CI/CD. Typowy wzorzec egzekwowania polityki:
Problem praktyczny: Scenariusz użycia
Scenariusz: Firma NovaTech Corp uruchamia mikroserwisy dla klientów w mieszanym środowisku obliczeniowym: kilka klastrów ECS na EC2, klaster EKS do przetwarzania danych oraz bezserwerowe funkcje Lambda do obsługi zdarzeń. Obrazy są przechowywane w ECR, operacje wykorzystują SSM do dostępu do hostów, a usługi GuardDuty i CloudWatch są włączone, ale widoczność jest nierównomierna w obrębie kontenerów i komponentów płaszczyzny sterowania.
Wyzwanie: Produkcyjny kontener wykazywał podejrzane połączenia wychodzące, a inżynier odkrył, że jeden z podów mógł uzyskać dostęp do serwisu metadanych instancji EC2, co groziło eksfiltracją poświadczeń; podatności w obrazach i niewystarczające logowanie płaszczyzny sterowania mogą ukrywać pierwotną przyczynę.
Zalecane podejście:
- Włącz ECS Exec dla zadań i wymagaj użycia AWS Systems Manager Session Manager do inspekcji hosta i środowiska uruchomieniowego kontenera (ECS Exec + SSM), eliminując potrzebę SSH i zapewniając, że aktywność sesji jest logowana w CloudTrail i CloudWatch Logs.
- Wymuś stosowanie IMDSv2 na instancjach EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) i zastosuj reguły sieciowe na poziomie hosta, aby blokować dostęp do 169.254.169.254 z przestrzeni sieciowych kontenerów, uniemożliwiając im odpytywanie metadanych instancji.
- Włącz monitorowanie środowiska uruchomieniowego i ochronę przed złośliwym oprogramowaniem w Amazon GuardDuty dla kontenerów i funkcji Lambda, a następnie przesyłaj wyniki do Security Hub i EventBridge w celu uruchamiania zautomatyzowanych playbooków ograniczających zagrożenia.
- Wzmocnij zabezpieczenia EKS poprzez włączenie logów płaszczyzny sterowania (audit, authenticator, controllerManager, scheduler) do CloudWatch Logs, wdróż IAM Roles for Service Accounts (IRSA) i wymuś stosowanie kontroli dopuszczenia (Pod Security lub OPA Gatekeeper), aby ograniczyć ryzykowne uprawnienia.
- Aktywuj rozszerzone skanowanie obrazów w Amazon ECR (Inspector/ECR scanning) z opcją skanowania przy wgrywaniu (scan-on-push) i zintegruj wyniki z potokiem CI, aby blokować lub poddawać kwarantannie obrazy za pomocą EventBridge i Lambda w celu egzekwowania polityk.
- Scentralizuj telemetrię: wysyłaj logi CloudTrail, wyniki z GuardDuty, logi płaszczyzny sterowania EKS i wyniki skanowania ECR do scentralizowanego potoku opartego na S3/Lambda/Security Hub i zasilaj reguły AWS Config w celu zapewnienia ciągłej zgodności.
Uzasadnienie: Ta sekwencja działań eliminuje dostęp oparty na SSH, zapobiega kradzieży poświadczeń z metadanych, zapewnia wykrywanie w czasie rzeczywistym i automatyczną reakcję, wymusza higienę obrazów i dostarcza wgląd w płaszczyznę sterowania — co jest zgodne z najlepszymi praktykami AWS: zasadą najmniejszych uprawnień, obroną w głąb i scentralizowaną obserwowalnością.
# CodeBuild buildspec fragment
post_build:
commands:
- aws ecr describe-image-scan-findings \
--repository-name api --image-id imageTag=$TAG \
--query 'imageScanFindings.findingSeverityCounts' > findings.json
CRIT=$(jq '.CRITICAL // 0' findings.json)
if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi
Integracja z potokiem CI/CD jest tym, co przekształca skanowanie z przeglądania panelu w rzeczywisty mechanizm kontroli.
Lambda: Authorizery, sekrety i role wykonawcze
Bezpieczeństwo na poziomie funkcji Lambda ma trzy płaszczyzny, które są często mylone:
Polityka zasobu (polityka funkcji): kontroluje, które jednostki (principals), takie jak API Gateway, EventBridge czy inne konta, mogą wywoływać funkcję. Authorizery Lambda w API Gateway działają jak bramka tożsamości dla wywołań HTTP — zwracają politykę IAM, którą API Gateway buforuje i egzekwuje przed wywołaniem funkcji backendowej.
Rola wykonawcza: tożsamość, którą kod funkcji przyjmuje w czasie wykonania. Jej polityka zaufania musi zawierać
lambda.amazonaws.com, a sama rola musi mieć uprawnienialogs:CreateLogGroup,logs:CreateLogStreamilogs:PutLogEvents, aby logowanie do CloudWatch Logs działało. Jeśli brakuje logów, problem prawie zawsze leży w roli wykonawczej — a nie w konsoli Lambda, która jedynie renderuje logi otrzymane przez CloudWatch. Poleganie wyłącznie na „logach z konsoli” to pułapka diagnostyczna: brak uprawnień w roli wykonawczej oznacza brak strumienia logów, a konsola nic nie pokaże.Pobieranie sekretów: nigdy nie umieszczaj poświadczeń w postaci zwykłego tekstu w zmiennych środowiskowych. Przechowuj je w Secrets Manager lub jako SecureString w SSM Parameter Store i pobieraj podczas zimnego startu (cold start):
import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None
def get_db_password():
global _cached
if _cached is None:
r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
_cached = r["Parameter"]["Value"]
return _cached
Rola wykonawcza potrzebuje uprawnień ssm:GetParameter i kms:Decrypt do klucza CMK. Przechowuj wartość w pamięci podręcznej w zakresie modułu, aby ciepłe wywołania (warm invocations) unikały ponownego wywołania API; użyj rozszerzenia Secrets Manager dla Lambda, aby uzyskać automatyczne buforowanie uwzględniające rotację kluczy w funkcjach o wyższej przepustowości.
Szyfrowanie i ochrona repozytorium ECR
Amazon ECR domyślnie szyfruje wszystkie obrazy w spoczynku (at rest) za pomocą AES-256 z kluczem zarządzanym przez AWS, ale obciążenia podlegające regulacjom zazwyczaj wymagają klucza KMS zarządzanego przez klienta (customer-managed key), aby rotacja kluczy, polityki kluczy i możliwość audytu przez CloudTrail były pod kontrolą klienta. Szyfrowanie KMS jest konfigurowane tylko w momencie tworzenia repozytorium; istniejącego repozytorium ECR nie można przełączyć z AES-256 na KMS po jego utworzeniu. Migracja wymaga zatem utworzenia nowego repozytorium zaszyfrowanego kluczem KMS, replikacji lub ponownego wgrania obrazów, aktualizacji systemów docelowych i usunięcia starego repozytorium. Konsumenci z innych kont pobierający obrazy z repozytorium szyfrowanego KMS muszą mieć nadane uprawnienie kms:Decrypt do klucza CMK, oprócz uprawnień do odczytu z ECR. W przeciwnym razie operacja pobrania (pull) zakończy się niepowodzeniem z błędem dostępu KMS, nawet jeśli polityka repozytorium zezwala na dostęp danej jednostce (principal).
{
"encryptionConfiguration": {
"encryptionType": "KMS",
"kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
},
"imageScanningConfiguration": { "scanOnPush": true },
"imageTagMutability": "IMMUTABLE"
}
Niezmienne tagi (immutable tags) zapobiegają atakom typu „tag-hijack”, w których zweryfikowany tag v1.2.3 jest po cichu nadpisywany przez złośliwy obraz po zakończeniu skanowania.
Skanowanie obrazów: Basic, Enhanced i Inspector
ECR oferuje dwa tryby skanowania. Skanowanie podstawowe (Basic) wykorzystuje bazę danych CVE open-source Clair, jest uruchamiane tylko przy operacji push (lub ręcznie) i zwraca wyniki w konsoli ECR. Jest bezpłatne, ale nie wykonuje ciągłego ponownego skanowania, nie obejmuje jednocześnie pakietów systemu operacyjnego i języków programowania oraz nie ma natywnej integracji z Security Hub. Skanowanie rozszerzone (Enhanced) jest obsługiwane przez Amazon Inspector i obejmuje zarówno pakiety systemu operacyjnego, jak i pakiety języków aplikacji (Python, Java, Node.js, Go, Ruby, .NET). Inspector stale monitoruje wypchnięte obrazy w oparciu o zaktualizowane dane o podatnościach, więc CVE ujawnione tydzień po wypchnięciu obrazu nadal generuje wynik bez potrzeby ponownego budowania.
Skanowanie rozszerzone jest włączane na poziomie rejestru (dla danego regionu), z filtrami włączającymi dla poszczególnych repozytoriów, które używają wzorców wieloznacznych, takich jak prod-* lub team-a/*. Jest to właściwa metoda kontroli dla częstego wymogu „skanuj większość repozytoriów, ale wyklucz te typu sandbox/eksperymentalne” — definiuje się filtry pozytywne, określające, co ma być skanowane, zamiast negatywnych wykluczeń dla pojedynczych repozytoriów.
aws ecr put-registry-scanning-configuration \
--scan-type ENHANCED \
--rules '[{
"scanFrequency": "CONTINUOUS_SCAN",
"repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
},{
"scanFrequency": "SCAN_ON_PUSH",
"repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
}]'
Integracja z Inspector i agregacja w Security Hub
Usługa Amazon Inspector musi być włączona na każdym koncie i w każdym regionie, gdzie wymagane jest skanowanie. W konfiguracji z AWS Organizations, konto narzędzi bezpieczeństwa jest wyznaczane jako delegowany administrator dla usługi Inspector, co pozwala mu na włączanie skanowania, ustawianie automatycznej rejestracji dla nowych kont członkowskich i przeglądanie zagregowanych wyników. Zapomnienie o delegacji — lub o włączeniu automatycznej rejestracji — jest subtelnym trybem awarii: nowe konta dołączające do organizacji po cichu wysyłają kontenery do ECR, które nigdy nie są skanowane, naruszając gwarancje pokrycia bez generowania jakichkolwiek błędów.
Wyniki z Inspectora automatycznie trafiają do AWS Security Hub, gdy obie usługi są włączone, a integracja Security Hub z Inspectorem jest aktywna. Security Hub następnie normalizuje wyniki do formatu AWS Security Finding Format (ASFF), koreluje je z wynikami z usług GuardDuty, Macie i Config, a — w połączeniu z delegowanym administratorem Security Hub i agregacją międzyregionalną — prezentuje je w jednym, scentralizowanym widoku. Reguły EventBridge oparte na wynikach z Security Hub mogą kierować krytyczne CVE do Lambda w celu automatycznego tworzenia zgłoszeń, oznaczać problematyczny obraz etykietą quarantine=true lub blokować wdrożenie za pomocą bramki w potoku CI/CD.
Scentralizowane skanowanie i CI/CD między kontami
Zalecany wzorzec dla wielokontowych obciążeń kontenerowych umieszcza w centrum wzmocnione centralne konto rejestru:
- Konto centralne: przechowuje repozytoria ECR szyfrowane za pomocą KMS, z włączonym skanowaniem rozszerzonym, niezmiennymi tagami i podpisywaniem obrazów (przez Notation/Sigstore zintegrowane z AWS Signer).
- Konta budujące: uruchamiają zadania CodeBuild/CodePipeline, które budują obrazy, wypychają je do centralnego ECR, czekają na wyniki z Inspectora i stosują bramki oparte na progach ważności.
- Konta z obciążeniami (dev/stage/prod): pobierają obrazy z centralnego rejestru za pomocą uprawnień międzykontowych.
Dostęp do odczytu między kontami wymaga dwóch warstw: polityki IAM na koncie konsumującym, przyznającej uprawnienia ecr:GetDownloadUrlForLayer, ecr:BatchGetImage i ecr:GetAuthorizationToken, oraz polityki repozytorium w ECR na koncie centralnym, zezwalającej na dostęp konkretnemu kontu lub roli konsumenta.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowProdPull",
"Effect": "Allow",
"Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
"Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
}]
}
Ponieważ polityki repozytoriów ECR są oparte na zasobach, o dostępie decyduje część wspólna polityki tożsamości i polityki zasobu — pominięcie którejkolwiek z warstw skutkuje błędem AccessDeniedException. Gdy używany jest KMS, polityka klucza KMS musi również przyznawać uprawnienie kms:Decrypt podmiotowi z innego konta.
Logowanie i obserwowalność płaszczyzny sterowania EKS
W przypadku EKS, zarządzana płaszczyzna sterowania nie jest bezpośrednio dostępna, więc istotne dla bezpieczeństwa zdarzenia Kubernetes są udostępniane tylko wtedy, gdy logowanie płaszczyzny sterowania jest jawnie włączone. Dostępnych jest pięć typów logów: api, audit, authenticator, controllerManager i scheduler. Log audit jest najcenniejszym artefaktem bezpieczeństwa — rejestruje każde wywołanie API klastra wraz z tożsamością wywołującego, rozwiązaną przez uwierzytelniacz IAM — a log authenticator zapisuje decyzje dotyczące mapowania uprawnień IAM na RBAC w Kubernetes. Wszystkie typy są przesyłane strumieniowo do CloudWatch Logs do grupy logów /aws/eks/<cluster>/cluster, skąd mogą być subskrybowane przez Kinesis Data Firehose, przekazywane do S3 lub wysyłane do systemu SIEM.
aws eks update-cluster-config --name prod-cluster \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator",
"controllerManager","scheduler"],"enabled":true}]}'
Uzupełnij logi płaszczyzny sterowania o GuardDuty EKS Protection (wykrywanie zagrożeń w czasie rzeczywistym na węzłach) i używaj IRSA (IAM Roles for Service Accounts) zamiast profili instancji węzłów, aby logi audytowe przypisywały aktywność API AWS do konkretnych podów.
Częste pułapki
Poleganie wyłącznie na skanowaniu „on-push”: Podstawowe skanowanie „on-push” wykrywa podatności znane w momencie wypchnięcia obrazu, ale nie robi nic w kwestii CVE ujawnionych później dla obrazów już znajdujących się w rejestrze. Frameworki audytowe, takie jak PCI DSS i FedRAMP, wymagają ciągłej oceny podatności, co wymusza stosowanie rozszerzonego skanowania z częstotliwością CONTINUOUS_SCAN oraz agregacji w Security Hub. Jednorazowe skanowanie przy wypchnięciu nie spełnia tego wymogu kontrolnego.
Pominięcie KMS w ECR, gdy wymagane jest szyfrowanie w spoczynku (encryption-at-rest): Domyślne szyfrowanie AES-256 to prawdziwe szyfrowanie, ale reżimy zgodności, które wymagają kluczy zarządzanych przez klienta (customer-managed keys), zapisów rotacji kluczy i ścieżek audytowych kms:Decrypt dla poszczególnych podmiotów (principal), nie mogą być spełnione przez klucze należące do AWS. Ponieważ typ szyfrowania jest niezmienny dla danego repozytorium, należy to uwzględnić podczas jego tworzenia — opcja „włączymy to później” jest niemożliwa bez ponownego utworzenia repozytorium.
Zapominanie o delegowanym administratorze Inspector lub automatycznej rejestracji: Bez delegowanego administratora dla usługi Inspector, właściciel każdego konta musi samodzielnie włączać skanowanie i przekazywać wyniki, co jest operacyjnie niewykonalne i prowadzi do luk w pokryciu. Bez automatycznego włączania dla nowych kont członkowskich, każde nowe konto utworzone za pomocą Control Tower lub Organizations rozpoczyna z wyłączoną usługą Inspector, więc jego obrazy ECR nie są skanowane, mimo że Security Hub na koncie centralnym nie wykazuje żadnych znalezisk — jest to cichy fałszywy negatyw (false-negative), a nie oczywisty błąd.
Problem praktyczny: Scenariusz użycia
Scenariusz: Meridian Financial zarządza wielokontowym środowiskiem AWS z produkcyjnymi klastrami EKS, usługami ECS i wieloma rejestrami ECR rozmieszczonymi na kontach produkcyjnych, deweloperskich oraz na dedykowanym koncie bezpieczeństwa. Ich zespoły inżynierskie wypychają obrazy kontenerów poprzez potoki CI/CD do ECR i wdrażają je na EKS/ECS, podczas gdy zespół bezpieczeństwa utrzymuje scentralizowane konto do monitorowania i zapewniania zgodności.
Wyzwanie: Niedawne wdrożenie dostarczyło kontener z podatnością o wysokiej wadze (high-severity), która nie została wykryta przed wdrożeniem na produkcję, a analitycy odkryli ograniczone logi płaszczyzny sterowania EKS i rozproszone wyniki skanowania na różnych kontach, co spowolniło proces naprawczy.
Zalecane podejście:
- Włącz zabezpieczenia na poziomie repozytorium ECR: wymuś niezmienność tagów obrazów (image tag immutability), zastosuj polityki repozytorium ograniczające operacje push/pull do określonych ról IAM i zaszyfruj repozytoria w spoczynku za pomocą dedykowanego klucza zarządzanego przez klienta (CMK) w AWS KMS.
- Włącz skanowanie obrazów przy wypchnięciu (podstawowe) oraz aktywuj rozszerzone skanowanie obrazów Amazon Inspector dla ECR w celu generowania wyników podatności; zintegruj Inspector z AWS Security Hub w celu scentralizowanej agregacji wag podatności (severities) na wszystkich kontach.
- Zaimplementuj scentralizowane skanowanie międzykontowe: skonfiguruj replikację ECR lub nadaj roli CodeBuild/CodePipeline z konta bezpieczeństwa uprawnienia do pobierania obrazów z innych kont (cross-account pull), aby konto bezpieczeństwa skanowało każdy obraz za pomocą Inspector oraz dodatkowych narzędzi SCA/DAST, przechowując artefakty w scentralizowanym buckecie S3 zaszyfrowanym kluczem CMK z konta bezpieczeństwa.
- Wymuś bramki jakości (gating) w CI/CD: dodaj etap skanowania w potoku (CodeBuild/CodePipeline lub GitHub Actions z STS assume-role), który odpytuje wyniki z Inspector/Security Hub i automatycznie blokuje lub wymaga zatwierdzenia dla obrazów z wynikami o wadze wysokiej (high) lub krytycznej (critical).
- Popraw obserwowalność EKS: włącz logi płaszczyzny sterowania EKS (API, Audit, Authenticator, ControllerManager, Scheduler) do CloudWatch Logs na scentralizowanym koncie do logowania, włącz CloudTrail dla zdarzeń API EKS i użyj Container Insights oraz GuardDuty do monitorowania w czasie rzeczywistym (runtime monitoring).
Uzasadnienie: To podejście stosuje obronę w głąb (defense-in-depth): szyfrowanie i ochrona rejestrów, automatyzacja rozszerzonego skanowania za pomocą Inspector, centralizacja wyników w Security Hub w celu spójnego egzekwowania polityk, bramkowanie wdrożeń w CI/CD oraz włączenie logów płaszczyzny sterowania EKS w celu szybkiego wykrywania i analizy śledczej, co jest zgodne z najlepszymi praktykami AWS dotyczącymi zasady najmniejszych uprawnień (least-privilege) i scentralizowanego monitorowania.
← Podatności · Wszystkie domeny · Reagowanie na incydenty i analiza śledcza →
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 →