Amazon SCS-C02: Container- und Serverless-Sicherheit — Lernleitfaden
Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
ECS Exec und Laufzeitinspektion ohne SSH
ECS Exec bietet eine interaktive Shell in einem laufenden Container – einschließlich Fargate-Tasks – ohne SSH, Bastion-Hosts oder öffentliche IPs preiszugeben. Dies funktioniert über den SSM-Agenten, den AWS in die Sidecar-Ausführungsumgebung des Tasks injiziert. Da es keinen SSH-Daemon, kein Schlüsselmaterial und keinen eingehenden Netzwerkpfad zum Absichern gibt, ist der Betriebsaufwand minimal und jede Sitzung ist über CloudTrail auditierbar und kann (optional) in S3 oder CloudWatch Logs protokolliert werden.
Drei Anforderungen müssen erfüllt sein, damit ECS Exec funktioniert:
Berechtigungen der Task-Rolle: Die Task-Rolle (nicht die Execution-Rolle) benötigt
ssmmessages:CreateControlChannel,ssmmessages:CreateDataChannel,ssmmessages:OpenControlChannelundssmmessages:OpenDataChannel. Die Execution-Rolle holt nur Images und schreibt Protokolle; der SSM-Traffic zur Laufzeit läuft über die Task-Rolle, da dies die Identität ist, die der Container-Prozess annimmt.Service- oder Task-Konfiguration: Der Service muss mit
--enable-execute-commanderstellt oder aktualisiert werden. Dieses Flag setztenableExecuteCommandfür neue Tasks; bestehende Tasks müssen ersetzt werden.Unterstützung durch das Container-Image: Der Container benötigt eine Shell (
/bin/shoder/bin/bash), die im Image vorhanden ist.
Ein typischer Inspektionsablauf sieht wie folgt aus:
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"
Von dieser Shell aus kann ein Techniker Protokolle nach S3 kopieren, einen Heap-Dump auslösen oder /proc für forensische Analysen auslesen. Die Alternative – der Versuch, den Container über SSH zu erreichen oder den Task neu zu starten, um einen Debug-Agenten zu aktivieren – schlägt entweder auf Fargate fehl oder zerstört die Beweise, die Sie zu sammeln versuchten.
Blockieren des IMDS-Zugriffs von Containern auf EC2
Ein weit verbreitetes Missverständnis ist, dass die IMDSv2-Hop-Limit-Einstellungen auf der EC2-Instanz die Container auf dieser Instanz schützen. Das tun sie nicht, zumindest nicht standardmäßig im Bridge- oder Host-Netzwerkmodus: Container teilen sich den Netzwerk-Namespace des Hosts oder eine NAT-Bridge und können 169.254.169.254 erreichen und die Anmeldeinformationen des Instanzprofils abrufen, die typischerweise weitaus mehr Berechtigungen haben als die Task-Rolle. Das hebelt das Prinzip der geringsten Rechte (Least Privilege) vollständig aus.
Die Lösung, wenn eine Migration zu Fargate nicht möglich ist, besteht aus zwei Teilen:
Verwenden Sie den
awsvpc-Netzwerkmodus für Tasks. Jeder Task erhält sein eigenes ENI und seinen eigenen Netzwerk-Namespace. Der IMDS-Traffic erreicht den Link-Local-Endpunkt des Hosts nicht mehr transparent.Setzen Sie
ECS_AWSVPC_BLOCK_IMDS=truein/etc/ecs/ecs.configauf der Container-Instanz. Dies weist den ECS-Agenten an, eine iptables-Regel zu installieren, die Pakete von awsvpc-Tasks mit dem Ziel169.254.169.254verwirft.
echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs
Kombinieren Sie dies mit einem minimalen Instanzprofil (im Wesentlichen nur das, was der ECS-Agent benötigt: AmazonEC2ContainerServiceforEC2Role) und IAM-Rollen pro Task für Anwendungsberechtigungen. Das Setzen des IMDS-Hop-Limits der Instanz auf 1 mit erzwungenem IMDSv2 ist eine nützliche „Defense-in-Depth“-Maßnahme, aber kein Ersatz – Container im Bridge-Modus können IMDS immer noch bei Hop 1 erreichen, da die Anfrage vom Host ausgeht.
GuardDuty Runtime Monitoring, EKS Protection und Control-Plane-Protokolle
GuardDuty bietet eine mehrschichtige Container-Erkennung:
EKS Protection analysiert EKS-Audit-Logs, um verdächtige Kubernetes-API-Aktivitäten zu erkennen – anonymer Zugriff, Erstellung privilegierter Pods, Ausführung von Befehlen (Exec) in System-Pods.
Runtime Monitoring stellt einen eBPF-basierten Sensor bereit (als verwaltetes Add-on für EKS oder als SSM-verwalteter Agent für ECS/Fargate), der Prozess-, Datei- und Netzwerkaktivitäten innerhalb von Containern beobachtet. Es meldet Findings wie Reverse Shells, Cryptomining-Binärdateien und die Exfiltration von Anmeldeinformationen aus einem Pod oder Task heraus.
EKS Protection ist wertlos, wenn das Audit-Log der EKS-Control-Plane nicht tatsächlich an CloudWatch Logs gesendet wird. Aktivieren Sie mindestens die Protokolltypen audit und authenticator auf dem Cluster:
aws eks update-cluster-config --name prod \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
Ohne diese Protokolle hat GuardDuty keine Datenebene, die es auf EKS-Protection-Findings untersuchen kann – eine Falle, die häufig auftritt, weil Betreiber das GuardDuty-Feature aktivieren, aber die Protokollierungskonfiguration des Clusters ausgeschaltet lassen und sich dann wundern, warum keine Kubernetes-Findings erscheinen.
Image-Scanning mit ECR Enhanced Scanning
ECR Enhanced Scanning wird von Amazon Inspector unterstützt und bietet kontinuierliches Scannen von Container-Images auf CVEs in Betriebssystem- und Sprachpaketen (Python, Node, Java, Go, Ruby). Das einfache Scannen (Basic Scanning) erfolgt einmalig zum Zeitpunkt des Pushs und deckt nur Betriebssystempakete ab; das erweiterte Scannen (Enhanced Scanning) ist kontinuierlich und schließt Anwendungsabhängigkeiten ein, wo sich die meisten modernen Schwachstellen befinden.
Findings fließen automatisch in das Security Hub, wenn beide Dienste aktiviert sind. Dies bietet eine zentrale Ansicht (Single Pane of Glass) für die Compliance und ermöglicht es Ihnen, EventBridge-Regeln zu schreiben, die CI/CD-Builds fehlschlagen lassen. Ein typisches Durchsetzungsmuster:
Praktisches Problem: Anwendungsfallszenario
Szenario: Die NovaTech Corp betreibt kundenorientierte Microservices auf einer gemischten Rechenumgebung: mehrere ECS-Cluster auf EC2, ein EKS-Cluster für die Datenverarbeitung und serverlose Lambdas für die Ereignisbehandlung. Images werden in ECR gespeichert, für den Host-Zugriff wird SSM verwendet, und GuardDuty/CloudWatch sind aktiviert, aber die Transparenz über Container und Control-Plane-Komponenten hinweg ist uneinheitlich.
Herausforderung: Ein Produktiv-Container zeigte verdächtige ausgehende Verbindungen, und ein Techniker entdeckte, dass ein Pod den EC2-Instanz-Metadatendienst erreichen konnte, was das Risiko der Exfiltration von Anmeldeinformationen birgt; Schwachstellen in Images und eine unzureichende Protokollierung der Control Plane könnten die eigentliche Ursache verbergen.
Empfohlener Ansatz:
- ECS Exec für Tasks aktivieren und AWS Systems Manager Session Manager für die Überprüfung von Host- und Container-Laufzeitumgebungen vorschreiben (ECS Exec + SSM), wodurch die Notwendigkeit von SSH entfällt und sichergestellt wird, dass Sitzungsaktivitäten in CloudTrail und CloudWatch Logs protokolliert werden.
- IMDSv2 auf EC2-Instanzen erzwingen (Instance Metadata Service HttpTokens=required, hop limit=1) und Netzwerkregeln auf Host-Ebene anwenden, um 169.254.169.254 aus den Netzwerk-Namespaces der Container zu blockieren, sodass Container die Instanz-Metadaten nicht abfragen können.
- Amazon GuardDuty Runtime-Überwachung und Malware-Schutz für Container und Lambda aktivieren, Ergebnisse an Security Hub und EventBridge weiterleiten für automatisierte Eindämmungs-Playbooks.
- EKS härten, indem Control-Plane-Protokolle (audit, authenticator, controllerManager, scheduler) für CloudWatch Logs aktiviert werden, IAM Roles for Service Accounts (IRSA) eingeführt und Admission Controls (Pod Security oder OPA Gatekeeper) durchgesetzt werden, um riskante Berechtigungen (Capabilities) zu begrenzen.
- Erweitertes Image-Scanning von Amazon ECR (Inspector/ECR-Scanning) mit Scan-on-Push aktivieren und die Ergebnisse in die CI integrieren, um Images über EventBridge + Lambda zur Durchsetzung zu blockieren/in Quarantäne zu verschieben.
- Telemetrie zentralisieren: CloudTrail, GuardDuty-Ergebnisse, EKS-Control-Plane-Protokolle und ECR-Scan-Ergebnisse an eine zentralisierte S3/Lambda/Security Hub-Pipeline senden und AWS Config-Regeln für kontinuierliche Compliance speisen.
Begründung: Diese Abfolge beseitigt den SSH-basierten Zugriff, verhindert den Diebstahl von Metadaten-Anmeldeinformationen, bietet Laufzeiterkennung und automatisierte Reaktionen, erzwingt Image-Hygiene und liefert Transparenz auf Control-Plane-Ebene – im Einklang mit den AWS Best Practices für das Prinzip der geringsten Rechte (Least Privilege), tiefengestaffelte Verteidigung (Defense in Depth) und zentralisierte Beobachtbarkeit (Observability).
# 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
Die Integration in die Pipeline macht das Scannen von einer reinen Dashboard-Übung zu einer echten Kontrollmaßnahme.
Lambda: Authorizer, Secrets und Ausführungsrollen
Die Sicherheit auf Ebene einer Lambda-Funktion hat drei Ebenen, die häufig verwechselt werden:
Ressourcenrichtlinie (Function Policy): steuert, welche Prinzipale (API Gateway, EventBridge, andere Konten) die Funktion aufrufen können. Lambda Authorizer am API Gateway sind das Identitäts-Gate für HTTP-Aufrufer – sie geben eine IAM-Richtlinie zurück, die das API Gateway zwischenspeichert und durchsetzt, bevor die Backend-Funktion aufgerufen wird.
Ausführungsrolle: die Identität, die der Funktionscode zur Laufzeit annimmt. Ihre Vertrauensrichtlinie muss
lambda.amazonaws.comenthalten, und sie musslogs:CreateLogGroup,logs:CreateLogStreamundlogs:PutLogEventsgewähren, damit CloudWatch Logs funktioniert. Wenn Protokolle fehlen, liegt die Lösung fast immer in der Ausführungsrolle – nicht in der Lambda-Konsole, die lediglich die von CloudWatch empfangenen Protokolle darstellt. Sich allein auf „Konsolenprotokolle“ zu verlassen, ist eine diagnostische Falle: Keine Berechtigung in der Ausführungsrolle bedeutet keinen Log-Stream, und die Konsole zeigt nichts an.Abruf von Secrets: Anmeldeinformationen niemals im Klartext in Umgebungsvariablen einbetten („bake in“). Speichern Sie sie in Secrets Manager oder SSM Parameter Store SecureString und rufen Sie sie beim Kaltstart (Cold Start) ab:
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
Die Ausführungsrolle benötigt ssm:GetParameter und kms:Decrypt für den CMK. Cachen Sie den Wert im Geltungsbereich des Moduls (Module Scope), damit bei warmen Aufrufen (Warm Invocations) der API-Aufruf vermieden wird; verwenden Sie die Secrets Manager Lambda-Erweiterung für automatisches, rotationsbewusstes Caching in Funktionen mit höherem Durchsatz.
ECR-Verschlüsselung und Repository-Schutz
Amazon ECR verschlüsselt standardmäßig alle Images im Ruhezustand (at rest) mit AES-256 unter Verwendung eines von AWS verwalteten Schlüssels. Regulierte Workloads erfordern jedoch typischerweise einen kundenverwalteten KMS-Schlüssel, damit Schlüsselrotation, Schlüsselrichtlinien und die Überprüfbarkeit durch CloudTrail unter der Kontrolle des Kunden liegen. Die KMS-Verschlüsselung wird nur bei der Erstellung des Repositorys konfiguriert; ein bestehendes ECR-Repository kann nachträglich nicht von AES-256 auf KMS umgestellt werden. Die Migration erfordert daher das Erstellen eines neuen, KMS-verschlüsselten Repositorys, das Replizieren oder erneute Pushen der Images, das Aktualisieren der nachgelagerten Konsumenten (Downstream Consumers) und das Löschen des alten Repositorys. Kontenübergreifende Konsumenten, die von einem KMS-verschlüsselten Repository pullen, müssen zusätzlich zu den ECR-Leseberechtigungen die Berechtigung kms:Decrypt für den CMK erhalten, andernfalls schlägt der Pull-Vorgang mit einem KMS-Zugriffsfehler fehl, selbst wenn die Repository-Richtlinie den Prinzipal zulässt.
{
"encryptionConfiguration": {
"encryptionType": "KMS",
"kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
},
"imageScanningConfiguration": { "scanOnPush": true },
"imageTagMutability": "IMMUTABLE"
}
Unveränderliche Tags (Immutable Tags) verhindern Tag-Hijacking-Angriffe, bei denen ein validiertes v1.2.3-Tag nach dem Scannen unbemerkt durch ein bösartiges Image überschrieben wird.
Image-Scanning: Basic, Enhanced und Inspector
ECR bietet zwei Scan-Modi. Das Basic-Scanning verwendet die Open-Source-CVE-Datenbank Clair, wird nur bei einem Push (oder manueller Auslösung) ausgeführt und gibt die Ergebnisse in der ECR-Konsole zurück. Es ist kostenlos, führt aber keine kontinuierlichen erneuten Scans durch, deckt nicht Betriebssystem- und Programmiersprachenpakete gemeinsam ab und hat keine native Integration mit Security Hub. Das Enhanced-Scanning wird von Amazon Inspector unterstützt und deckt sowohl Betriebssystempakete als auch Pakete für Anwendungssprachen (Python, Java, Node.js, Go, Ruby, .NET) ab. Inspector überwacht gepushte Images kontinuierlich anhand aktualisierter Informationen zu Schwachstellen, sodass eine CVE, die eine Woche nach dem Push des Images offengelegt wird, immer noch zu einem Ergebnis führt, ohne dass ein Rebuild erforderlich ist.
Das Enhanced-Scanning wird auf Registry-Ebene (pro Region) aktiviert, mit repository-spezifischen Einschlussfiltern, die Wildcard-Muster wie prod-* oder team-a/* verwenden. Dies ist die richtige Steuerung für die häufige Anforderung, „die meisten Repositories zu scannen, aber Sandbox-/Experimentier-Repositories auszuschließen“ – Sie definieren positive Filter, die auflisten, was gescannt werden soll, anstatt negative Ausschlüsse für einzelne Repos zu definieren.
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"}]
}]'
Inspector-Integration und Security-Hub-Aggregation
Amazon Inspector muss in jedem Konto und jeder Region aktiviert werden, in der Scans erforderlich sind. In einem AWS-Organizations-Setup wird das Security-Tooling-Konto als delegierter Administrator für Inspector festgelegt, was es ihm ermöglicht, Scans zu aktivieren, die automatische Registrierung für neue Mitgliedskonten festzulegen und aggregierte Ergebnisse einzusehen. Das Vergessen der Delegierung – oder das Vergessen, die automatische Registrierung zu aktivieren – ist ein subtiler Fehlermodus: Neue Konten, die der Organisation beitreten, liefern unbemerkt Container an ECR, die nie gescannt werden, was die Abdeckungsgarantien ohne jegliche Fehlermeldung durchbricht.
Inspector-Ergebnisse fließen automatisch in AWS Security Hub ein, wenn beide Dienste aktiviert sind und die Inspector-Integration von Security Hub eingeschaltet ist. Security Hub normalisiert die Ergebnisse dann in das AWS Security Finding Format (ASFF), korreliert sie mit den Ergebnissen von GuardDuty, Macie und Config und bietet – in Kombination mit einem delegierten Security-Hub-Administrator und regionsübergreifender Aggregation – eine zentrale Übersicht (Single Pane of Glass). EventBridge-Regeln für Security-Hub-Ergebnisse können kritische CVEs an Lambda weiterleiten, um automatisch Tickets zu erstellen, das betreffende Image mit einem quarantine=true-Label zu versehen oder die Bereitstellung über ein Pipeline-Gate zu blockieren.
Zentralisiertes Scannen und kontoübergreifendes CI/CD
Das empfohlene Muster für Container-Workloads über mehrere Konten hinweg stellt ein gehärtetes zentrales Registry-Konto in den Mittelpunkt:
- Zentrales Konto: Hosten von KMS-verschlüsselten ECR-Repositories mit Enhanced-Scanning, unveränderlichen Tags und Image-Signierung (über Notation/Sigstore, integriert mit AWS Signer).
- Build-Konten: Führen CodeBuild/CodePipeline-Jobs aus, die Images erstellen, sie in die zentrale ECR pushen, auf Inspector-Ergebnisse warten und anhand von Schwellenwerten für den Schweregrad blockieren (Gating).
- Workload-Konten (dev/stage/prod): Pullen Images aus der zentralen Registry über kontoübergreifende Berechtigungen.
Kontoübergreifender Lesezugriff erfordert zwei Ebenen: eine IAM-Richtlinie im konsumierenden Konto, die ecr:GetDownloadUrlForLayer, ecr:BatchGetImage und ecr:GetAuthorizationToken gewährt, sowie eine Repository-Richtlinie auf dem ECR-Repo im zentralen Konto, die dem spezifischen Konsumentenkonto oder der Rolle den Zugriff erlaubt.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowProdPull",
"Effect": "Allow",
"Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
"Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
}]
}
Da ECR-Repository-Richtlinien ressourcenbasiert sind, bestimmt die Schnittmenge aus Identitäts- und Ressourcenrichtlinie den Zugriff – das Weglassen einer der beiden Ebenen führt zu einer AccessDeniedException. Wenn KMS involviert ist, muss die KMS-Schlüsselrichtlinie dem kontoübergreifenden Prinzipal ebenfalls kms:Decrypt gewähren.
EKS-Control-Plane-Logging und Observability
Bei EKS ist die verwaltete Control Plane nicht direkt zugänglich, daher werden sicherheitsrelevante Kubernetes-Ereignisse nur dann offengelegt, wenn das Control-Plane-Logging explizit aktiviert ist. Fünf Log-Typen sind verfügbar: api, audit, authenticator, controllerManager und scheduler. Das audit-Log ist das wertvollste Sicherheitsartefakt – es zeichnet jeden API-Aufruf an den Cluster auf, wobei die Identität des Aufrufers über den IAM-Authenticator aufgelöst wird – und authenticator zeichnet die Entscheidungen zur Zuordnung von IAM zu Kubernetes-RBAC auf. Alle Typen werden in eine /aws/eks/<cluster>/cluster-Log-Gruppe in CloudWatch Logs gestreamt, von wo aus sie von Kinesis Data Firehose abonniert, an S3 weitergeleitet oder an ein SIEM gesendet werden können.
aws eks update-cluster-config --name prod-cluster \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator",
"controllerManager","scheduler"],"enabled":true}]}'
Ergänzen Sie die Control-Plane-Logs mit GuardDuty EKS Protection (Laufzeit-Bedrohungserkennung auf den Nodes) und verwenden Sie IRSA (IAM Roles for Service Accounts) anstelle von Node-Instanzprofilen, damit die Audit-Logs die AWS-API-Aktivität bestimmten Pods zuordnen.
Häufige Fallstricke
Sich nur auf Scan-on-Push verlassen: Das einfache Scannen bei Push-Vorgängen (Scan-on-Push) erfasst Schwachstellen, die zum Zeitpunkt des Pushs bekannt sind, unternimmt aber nichts gegen CVEs, die später für bereits in der Registry befindliche Images veröffentlicht werden. Audit-Frameworks wie PCI DSS und FedRAMP erfordern eine fortlaufende Schwachstellenbewertung, was erweiterte Scans mit der Frequenz CONTINUOUS_SCAN sowie die Aggregation in Security Hub zwingend erforderlich macht. Ein einmaliger Snapshot pro Push erfüllt diese Kontrollvorgabe nicht.
KMS bei ECR überspringen, wenn Verschlüsselung im Ruhezustand erforderlich ist: Die standardmäßige AES-256-Verschlüsselung ist eine echte Verschlüsselung. Compliance-Vorschriften, die kundenseitig verwaltete Schlüssel, Aufzeichnungen zur Schlüsselrotation und Audit-Protokolle für kms:Decrypt pro Principal verlangen, können jedoch nicht mit AWS-eigenen Schlüsseln erfüllt werden. Da der Verschlüsselungstyp pro Repository unveränderlich ist, muss dies bei der Erstellung berücksichtigt werden – ein „wir schalten es später ein“ ist ohne eine Neuerstellung des Repos unmöglich.
Vergessen des delegierten Administrators für Inspector oder der automatischen Registrierung: Ohne einen delegierten Administrator für Inspector muss jeder Kontoinhaber das Scannen unabhängig aktivieren und die Ergebnisse weiterleiten, was operativ nicht umsetzbar ist und zu Abdeckungslücken führt. Ohne die automatische Aktivierung für neue Mitgliedskonten startet jedes neue Konto, das über Control Tower oder Organizations erstellt wird, mit deaktiviertem Inspector. Folglich werden dessen ECR-Images nicht gescannt, obwohl Security Hub im zentralen Konto keine Ergebnisse anzeigt – ein stilles Falsch-Negativ anstelle eines offensichtlichen Fehlers.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten, die Produktions-EKS-Cluster, ECS-Services und mehrere ECR-Registries umfasst, welche auf Prod-, Dev- und ein dediziertes Sicherheitskonto verteilt sind. Ihre Engineering-Teams pushen Container-Images über CI/CD-Pipelines in ECR und deployen sie in EKS/ECS, während die Sicherheitsabteilung ein zentrales Konto für Überwachung und Compliance unterhält.
Herausforderung: Ein kürzlich durchgeführtes Deployment lieferte einen Container mit einer Schwachstelle hohen Schweregrads, die vor der Produktion nicht erkannt wurde. Die Ermittler fanden nur begrenzte Protokolle der EKS-Control-Plane und fragmentierte Scan-Ergebnisse über verschiedene Konten hinweg, was die Behebung verlangsamte.
Empfohlener Ansatz:
- Aktivieren von Schutzmaßnahmen auf ECR-Repository-Ebene: Unveränderlichkeit von Image-Tags erzwingen, Repository-Richtlinien anwenden, die Push/Pull auf bestimmte IAM-Rollen beschränken, und Repositories im Ruhezustand mit einem dedizierten, kundenseitig verwalteten AWS KMS-Schlüssel (CMK) verschlüsseln.
- Image-Scans bei Push (Basis) aktivieren und das erweiterte Image-Scannen von Amazon Inspector für ECR aktivieren, um Schwachstellen-Findings zu erzeugen; Inspector in AWS Security Hub integrieren, um Schweregrade kontoübergreifend zentral zu aggregieren.
- Zentralisiertes, kontoübergreifendes Scannen implementieren: ECR-Replikation konfigurieren oder einer CodeBuild/CodePipeline-Rolle im Sicherheitskonto kontoübergreifende Pull-Berechtigungen erteilen, sodass das Sicherheitskonto jedes Image mit Inspector und beliebigen zusätzlichen SCA/DAST-Tools scannt und die Artefakte in einem zentralen S3-Bucket speichert, der mit dem CMK des Sicherheitskontos verschlüsselt ist.
- CI/CD-Gating erzwingen: Eine Scan-Phase in der Pipeline hinzufügen (CodeBuild/CodePipeline oder GitHub Actions mit STS Assume-Role), die die Findings von Inspector/Security Hub abfragt und Images mit hohen/kritischen Findings automatisch blockiert oder eine Genehmigung erfordert.
- Beobachtbarkeit von EKS verbessern: EKS-Control-Plane-Protokolle (API, Audit, Authenticator, ControllerManager, Scheduler) in CloudWatch Logs in einem zentralen Protokollierungskonto aktivieren, CloudTrail für EKS-API-Ereignisse aktivieren und Container Insights und GuardDuty für die Laufzeitüberwachung verwenden.
Begründung: Dieser Ansatz wendet eine tiefgreifende Verteidigungsstrategie (Defense-in-Depth) an: Verschlüsselung und Schutz von Registries, Automatisierung erweiterter Scans mit Inspector, Zentralisierung von Findings in Security Hub für eine konsistente Richtliniendurchsetzung, Gating von Deployments in der CI/CD und Aktivierung von EKS-Control-Plane-Protokollen für eine schnelle Erkennung und Forensik. Dies steht im Einklang mit den AWS Best Practices für das Prinzip der geringsten Rechte (Least Privilege) und zentralisierte Überwachung.
← Schwachstellen · Alle Domänen · Vorfallsreaktion und Forensik →
Diese Fragen üben → · Zeitlich begrenzte Übung auf 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.
Bestehe deine Prüfung →