Amazon SCS-C02: Schwachstellen, Patches und Host-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.
Amazon Inspector: Erweitertes Scannen für EC2, Lambda und ECR
Amazon Inspector ist ein kontinuierlicher, agentengestützter Schwachstellenmanagement-Dienst, der CVEs in EC2-Instanzen, in ECR gespeicherten Container-Images und Lambda-Funktionen (sowohl Anwendungscode als auch Abhängigkeits-Layer) aufdeckt. Die Aktivierung von Inspector auf Kontoebene registriert automatisch alle geeigneten Ressourcen – es gibt keinen Opt-in-Workflow pro Ressource. Die Ergebnisse werden automatisch im standardisierten ASFF-Format an AWS Security Hub übertragen, was das korrekte Integrationsmuster ist, wenn ein zentrales Dashboard für die Sicherheitslage erforderlich ist.
Für EC2 verwendet Inspector ein hybrides Scan-Modell. Der SSM Agent (mit der von AWS bereitgestellten Association) sammelt ein Software-Inventar, das für eine agentenlose Prüfung der Netzwerk-Erreichbarkeit und eine Paket-Bewertung verwendet wird, während für eine tiefgehende Host-Bewertung der Agent laufen und die Instanz über SSM erreichbar sein muss. Deshalb ist der „rein agentenlose“ Ansatz eine Falle: Ohne den Pfad über den SSM Agent (oder die agentenbasierte Tiefenprüfung von Inspector, wo erforderlich) erhalten Sie nur oberflächliche Ergebnisse – Netzwerk-Exposition und aus Manifesten abgeleitete CVEs – aber verpassen Inventare von Laufzeitbibliotheken, nicht verwaltete Pakete und Konfigurationen. Der Hybrid-Modus ist das, was die meisten Produktionsumgebungen benötigen.
Für Lambda führt Inspector zwei Arten von Scans durch: Standard (Paket-Schwachstellen in Layern und Funktionsabhängigkeiten) und Code-Scanning (statische Analyse des Funktionscodes auf Injection-Fehler, hartcodierte Geheimnisse und unsichere APIs). Eine kritische Voraussetzung für die Eignung: Eine Lambda-Funktion muss innerhalb der letzten 90 Tage mindestens einmal aufgerufen worden sein, um gescannt zu werden. Inaktive oder archivierte Funktionen fallen stillschweigend aus dem Geltungsbereich von Inspector heraus. Teams, die davon ausgehen, „Inspector ist aktiviert, also ist jede Funktion abgedeckt“, bekommen Probleme, wenn Auditoren Nachweise für selten ausgeführte Funktionen verlangen. Die Abhilfe besteht darin, die Funktionen entweder nach einem Zeitplan (EventBridge) aufzurufen oder den Ausschluss zu akzeptieren und zu dokumentieren.
Für ECR ersetzt das erweiterte Scannen (powered by Inspector) die älteren Basis-Scans, die auf Clair basierten. Das erweiterte Scannen unterstützt sowohl den Scan bei Push als auch das kontinuierliche Scannen von bereits in der Registry befindlicher Images. Dadurch erzeugen neu bekannt gegebene CVEs für bereits gepushte Images neue Ergebnisse ohne einen erneuten Push. Aktivieren Sie das erweiterte Scannen auf Registry-Ebene und konfigurieren Sie Filter pro Repository (zum Beispiel prod/* kontinuierlich, sandbox/* nur Scan-bei-Push), um die Kosten zu steuern.
Delegierte Administration und Unterdrückungsregeln
In einem AWS Organizations-Setup mit mehreren Konten benennen Sie vom Verwaltungskonto aus ein delegierter Administrator-Konto für Inspector. Der delegierte Administrator sieht aggregierte Ergebnisse über alle Mitgliedskonten hinweg und steuert die organisationsweite Scan-Konfiguration. Dies vermeidet die Vergabe von kontoübergreifenden IAM-Rollen zum Abrufen von Ergebnissen und verhindert das Anti-Pattern, Inspector stückweise pro Konto zu aktivieren.
Unterdrückungsregeln ermöglichen es einem Sicherheitsteam, Rauschen zu filtern, ohne Ergebnisse zu löschen. Eine Regel passt auf Attribute wie Ressourcen-Tag, Schweregrad, CVE-ID oder ECR-Repository. Um Ergebnisse von Dev/Test-Lambda-Funktionen vom Produktions-Dashboard fernzuhalten, wenden Sie eine Unterdrückungsregel an, die auf dem Tag Environment=dev basiert – die Ergebnisse existieren weiterhin im zugrunde liegenden Datenspeicher für Audits, werden aber von den Standardansichten und, falls konfiguriert, von Security Hub ausgeschlossen. Erreichen Sie dies nicht, indem Sie Inspector für Dev-Konten deaktivieren; Sie verlieren die Fähigkeit, die Hochstufung eines anfälligen Artefakts von Dev nach Prod zu erkennen.
CI/CD-Gating für die Image-Promotion
Das erweiterte ECR-Scannen erzeugt Ergebnisse, die an einen Image-Digest (nicht nur an den Tag) gebunden sind, den eine Pipeline abfragen muss. Das kanonische Muster ist: Image bauen → nach ECR pushen (löst Scan-bei-Push aus) → den Abschluss des Scans abfragen oder darauf warten → den Build fehlschlagen lassen, wenn Ergebnisse mit dem Schweregrad „High“ oder „Critical“ vorhanden sind → andernfalls die ECS/EKS-Task/das Deployment aktualisieren.
Ein minimaler CodeBuild-Schritt in 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
An dieser Stelle kein Gating zu implementieren – im Vertrauen darauf, dass „Inspector uns schon benachrichtigen wird“ – ist der klassische Fehler: Benachrichtigungen kommen asynchron und erst dann an, wenn das anfällige Image bereits ausgeführt wird. Das Gate muss synchron mit der Promotion erfolgen. Ebenso ist ein Gating nur auf Basis des Tags anstelle des Digests unsicher, da Tags veränderlich sind; zwei Pushes mit demselben Tag würden die Scan-Ergebnisse vermischen.
Patch Manager, Baselines und Patch-Gruppen
SSM Patch Manager arbeitet mit drei Grundelementen:
Patch-Baseline: Definiert Regeln für die automatische Genehmigung, genehmigte Patches, abgelehnte Patches und den Compliance-Level pro Schweregrad/Klassifizierung.
Patch-Gruppe: Ein Tag mit dem exakten Schlüssel
Patch Group, dessen Wert Instanzen bei einer bestimmten Baseline registriert.Wartungsfenster: Der Zeitplan, während dem
AWS-RunPatchBaselineScan- oder Installationsaufgaben ausführt.
Für eine Umgebung, in der Dev alle Sicherheitspatches sofort automatisch genehmigen soll und Prod nur kritische/wichtige Patches nach einer 7-tägigen Wartezeit (Soak Time), während Kernel-Pakete abgelehnt werden, erstellen Sie zwei Baselines. Die Dev-Baseline verwendet eine Genehmigungsregel mit ApproveAfterDays: 0, die alle Sicherheitsklassifikationen abdeckt. Die Prod-Baseline verwendet ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtert nach Classification=Security und Severity in [Critical, Important] und fügt kernel* zur Liste der abgelehnten Patches mit BlockAllPatchesFromRejectedList hinzu. Instanzen werden mit Patch Group=Dev oder Patch Group=Prod getaggt, und jede Patch-Gruppe wird bei der entsprechenden Baseline registriert. Die Compliance wird über Patch-Compliance-Berichte zusammengefasst und kann für eine zentrale Prüfung nach S3 exportiert werden.
Eine einzelne Baseline „mit Logik“ kann die Unterschiede zwischen Dev und Prod nicht abbilden – Baselines sind pro registrierter Gruppe statisch. Versuchen Sie nicht, dieses Verhalten durch unterschiedliche Wartungsfenster zu fälschen; das Fenster steuert, wann das Patchen ausgeführt wird, nicht, welche Patches genehmigt werden.
Echtzeit-Benachrichtigungs-Pipeline
Für Benachrichtigungen über neue Findings in Slack oder Microsoft Teams ist die betrieblich effiziente Kette wie folgt:
Inspector gibt Findings an EventBridge über die
aws.inspector2-Ereignisquelle aus.EventBridge-Regel filtert nach Schweregrad (z. B.
HIGH,CRITICAL) und hat ein SNS-Topic als Ziel.SNS-Topic hat eine AWS Chatbot-Subscription, die dem Slack-Kanal oder dem Teams-Workspace zugeordnet ist.
Chatbot abonniert SNS direkt – fügen Sie keine Lambda-Funktion dazwischen ein, um Nachrichten neu zu formatieren, da Chatbot Inspector-Findings nativ darstellt. Ein Beispiel für ein EventBridge-Pattern:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Zwei Fallen, die hier zu vermeiden sind: Das Routing über Security Hub fügt Latenz hinzu und kann bei falsch konfigurierten Custom Insights die Granularität des Schweregrads verringern; und die Verwendung von SES oder einer benutzerdefinierten Webhook-Lambda-Funktion erhöht den Betriebsaufwand, ohne Funktionen hinzuzufügen, die Chatbot bereits nativ bereitstellt.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine AWS-Organisation mit mehreren Konten, die kundenorientierte Webdienste, Batch-Analyse-Workloads und serverlose Ereignisprozessoren unterstützt. Ihre CI/CD-Pipelines pushen Container-Images zu Amazon ECR, sie hosten EC2-Flotten für Legacy-Workloads und verwenden Lambda für neuere Dienste; ein zentrales Sicherheitsteam in einem Sicherheitskonto muss die Transparenz und das Patchen von Schwachstellen über alle Konten hinweg verwalten.
Herausforderung: Ein kürzlich erstelltes Image, das eine Bibliothek mit hohem Schweregrad enthielt, wurde in die Produktion überführt, da Scans in der CI/CD-Pipeline nicht erzwungen wurden. Zudem ist das Patchen von EC2-Instanzen in den verschiedenen Umgebungen inkonsistent, was zu Sicherheitslücken und einer Flut von Findings führt, die das Team überfordern.
Empfohlener Ansatz:
- Aktivieren Sie Amazon Inspector Enhanced Scanning für EC2, Lambda und ECR vom Sicherheitskonto aus, indem Sie die delegierte Administration in AWS Organizations konfigurieren. So können Scans, Findings und Unterdrückungsregeln zentral verwaltet werden.
- Konfigurieren Sie das Scannen von ECR-Images bei einem Push und integrieren Sie Scan-Gates in CodePipeline/CodeBuild: Blockieren Sie die Beförderung von Images, bis die Scan-Ergebnisse von Inspector/ECR die Schwellenwerte für den Schweregrad erfüllen, und machen Sie Findings im Build-Schritt sichtbar.
- Implementieren Sie den AWS Systems Manager Patch Manager mit definierten Patch-Baselines und Patch-Gruppen pro Umgebung, planen Sie Wartungsfenster (Maintenance Windows) für ein Rollout, das zuerst in Nicht-Produktionsumgebungen stattfindet, und automatisieren Sie die Genehmigung für kritische CVE-Fixes mithilfe von SSM-Automatisierungsdokumenten.
- Erstellen Sie eine Echtzeit-Benachrichtigungs-Pipeline mit Amazon EventBridge, um Inspector-Findings und SSM-Compliance-Ereignisse zu erfassen, leiten Sie diese an Amazon SNS und eine schlanke AWS-Lambda-Funktion weiter, die die Alarme anreichert, dedupliziert und priorisierte Benachrichtigungen an Slack sendet sowie Tracking-Tickets erstellt.
- Automatisieren Sie die Eindämmung und Behebung: Verwenden Sie durch EventBridge ausgelöste SSM-Automatisierungen oder Lambda-Runbooks, um betroffene EC2-/Lambda-Versionen zu isolieren oder Image-Rebuilds auszulösen, und wenden Sie Inspector-Unterdrückungsregeln nur für nachverfolgte False Positives über das delegierte Administratorkonto an, um das Rauschen zu reduzieren.
Begründung: Zentralisiertes Inspector-Management, Gating in der CI/CD-Pipeline, Patch-Manager-Baselines und eine EventBridge-gesteuerte Pipeline folgen den AWS Best Practices, indem sie automatisierte Prävention, konsistentes Patching und eine priorisierte, auditierbare Reaktion durchsetzen und gleichzeitig die „Alert Fatigue“ (Benachrichtigungsmüdigkeit) reduzieren.
Schwachstellenerkennung mit Amazon Inspector
Amazon Inspector ist der wichtigste verwaltete Dienst zur Schwachstellenbewertung auf AWS und arbeitet auf drei für die Host-Sicherheit relevanten Ebenen: EC2-Instanzen, Container-Images in Amazon ECR und Lambda-Funktionen. Wenn er auf Konto- oder Organisationsebene (über einen delegierten Administrator in der Inspector-Konsole) aktiviert wird, führt er ein kontinuierliches, agentenloses oder SSM-basiertes Scannen durch, anstatt geplanter, zeitpunktbezogener Scans. Diese kontinuierliche Überwachung ist wichtig, da sich CVE-Feeds täglich ändern; ein Snapshot von letzter Woche kann bereits veraltet sein.
Für EC2 stützt sich Inspector auf den SSM Agent, um installierte Pakete und Kernel-Versionen aufzuzählen und diese dann mit Herstellerhinweisen und der National Vulnerability Database abzugleichen. Die Findings umfassen die CVE-Kennung, den CVSS-Score, das betroffene Paket, die korrigierte Version und den Kontext zur Netzwerk-Erreichbarkeit (die Regeln zur Netzwerk-Erreichbarkeit identifizieren Ports, die über ENIs, Sicherheitsgruppen, NACLs und Routing-Tabellen dem Internet ausgesetzt sind). Da das Scannen von SSM abhängt, wird eine EC2-Instanz, deren Instanzprofil nicht über die verwaltete Richtlinie AmazonSSMManagedInstanceCore verfügt, einfach nicht in den Inspector-Ergebnissen erscheinen – ein stiller Fehler, den man im Hinterkopf behalten sollte.
Für ECR unterstützt Inspector zwei Scan-Modi:
Basis-Scanning: kostenlos, verwendet die Open-Source-Engine Clair, läuft nur bei einem Push oder bei Bedarf.
Erweitertes Scannen: basiert auf Inspector, scannt Images kontinuierlich erneut (sowohl Betriebssystempakete als auch Anwendungssprachenpakete wie Python, Node, Java), sobald neue CVEs veröffentlicht werden, auch lange nach dem Push-Ereignis.
Eine häufige Falle ist die Annahme, dass das Scannen von ECR-Images bei einem Push als Host-Sicherheit ausreicht. Das ist nicht der Fall. Das Scannen bei einem Push validiert das Image zum Zeitpunkt des Builds, aber der laufende Container erbt das Image plus jegliche Abweichungen (Drift), und der zugrunde liegende EC2- oder Fargate-Host hat seinen eigenen Kernel und eigene Betriebssystempakete, die unabhängig gepatcht werden müssen. Das erweiterte Scannen in Kombination mit dem Scannen des EC2-Hosts schließt diese Lücke. Alle Inspector-Findings sollten an AWS Security Hub weitergeleitet werden, der sie in das ASFF-Format normalisiert und eine kontoübergreifende Aggregation, Deduplizierung und nachgelagerte Automatisierung über EventBridge ermöglicht.
Patch Manager und flottenweite Korrekturmaßnahmen
AWS Systems Manager Patch Manager ergänzt Inspector, indem er die von Inspector entdeckten Schwachstellen tatsächlich behebt. Während Inspector die Frage beantwortet: „Welche CVEs betreffen mich?“, beantwortet Patch Manager die Fragen: „Welche Patches fehlen und wie installiere ich sie sicher?“
Patch Manager arbeitet mit Patch-Baselines – deklarativen Regeln, die definieren, welche Patches genehmigt sind, basierend auf Klassifizierung (Security, Critical, Bugfix), Schweregrad und einer Verzögerung für die automatische Genehmigung (z. B. Genehmigung von Security-Patches sieben Tage nach ihrer Veröffentlichung, um die Stabilität des Herstellers zu gewährleisten). AWS stellt Standard-Baselines pro Betriebssystem bereit (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline usw.), aber Produktionsflotten verwenden in der Regel benutzerdefinierte Baselines, die über das Patch Group-Tag auf Instanzen mit Patch-Gruppen verknüpft sind.
Ein typischer Workflow zum Scannen und Patchen verwendet zwei Operationen:
Scan: Meldet die Konformität, ohne etwas zu installieren; die Ergebnisse erscheinen im Patch-Manager-Compliance-Dashboard und in Config.
Install: Wendet genehmigte Patches an und führt bei vielen Betriebssystemen einen Neustart durch.
Diese Operationen werden typischerweise über Wartungsfenster (maintenance windows) mit einem AWS-RunPatchBaseline-Dokument als Ziel geplant. Für dringende Zero-Day-Szenarien bietet Patch Manager Patch Now an, eine On-Demand-Aktion, die den Zeitplan des Wartungsfensters umgeht. Das empfohlene Muster besteht darin, eine eng gefasste Patch-Baseline zu erstellen, die nur das spezifische KB oder Paket genehmigt, das die Schwachstelle behebt, die betroffene Patch-Gruppe als Ziel auszuwählen, Patch Now auszuführen und die Ausgabeprotokolle in einen zentralen S3-Bucket und eine CloudWatch-Logs-Gruppe zu streamen. Dieses zentralisierte Protokoll wird zu Ihrem Audit-Artefakt – dem Nachweis der Behebung für Auditoren oder die Incident Response.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten mit mehreren hundert EC2-Instanzen (Windows und Amazon Linux) und einem kleinen EKS-Cluster, der kundenorientierte Dienste unterstützt. Sie verwenden AWS Organizations, AWS Systems Manager für operative Werkzeuge und pflegen AMIs in einem gemeinsam genutzten Image-Konto, verfügen jedoch nicht über konsistente, automatisierte Schwachstellenscans oder koordinierte Patch-Rollouts über alle Konten hinweg.
Herausforderung: Eine öffentliche CVE, die OpenSSL betrifft, wird veröffentlicht, und Amazon Inspector meldet erhöhte Befunde auf mehreren Instanzen. Das Patchen war jedoch uneinheitlich, und ein Produktionsdienst war aufgrund einer verzögerten Behebung einem kurzen Ausnutzungsversuch ausgesetzt.
Empfohlener Ansatz:
- Aktivieren Sie Amazon Inspector in allen Konten und Regionen, um Schwachstellenscans sowohl für Images als auch für laufende Instanzen durchzuführen, und leiten Sie Ergebnisse mit hohem Schweregrad an AWS Security Hub und einen benutzerdefinierten EventBridge-Event-Bus weiter.
- Verwenden Sie AWS Systems Manager Inventory, um betroffene Instanzen zu identifizieren und sie nach Kritikalität zu taggen; erstellen Sie eine Patch-Manager-Baseline, die die erforderlichen OpenSSL-Fixes enthält, und zielen Sie auf Windows/Linux-Regeln ab.
- Erstellen Sie eine EventBridge-Regel, die ein SSM-Automatisierungsdokument auslöst, wenn Inspector-Befunde einen definierten Schweregrad erreichen. Dabei wird die Liste der Instanz-IDs an ein Automatisierungs-Runbook übergeben, das Patch Manager oder Run Command aufruft, um Patches anzuwenden und bei Bedarf neu zu starten.
- Für zustandsbehaftete oder risikoreiche Dienste orchestrieren Sie Rolling Updates mit EC2 Image Builder, um gepatchte AMIs zu erstellen, aktualisieren Sie Auto-Scaling-Gruppen oder EKS-Knotengruppen mit einem kontrollierten Blue/Green- oder Rolling-Deployment und überprüfen Sie den Dienstzustand mit Route 53/ALB-Health-Checks.
- Führen Sie nach der Behebung Amazon Inspector erneut aus, um zu überprüfen, ob die Befunde behoben sind, aktualisieren Sie das SSM-Compliance-Reporting und senden Sie eine Zusammenfassung über SNS an das Sicherheitsteam; bewahren Sie das Automatisierungs-Runbook in einer Systems-Manager-Automatisierungsbibliothek für eine wiederholbare, flottenweite Reaktion auf.
Begründung: Dieser Ansatz nutzt Amazon Inspector für die kontinuierliche Erkennung, Systems Manager Patch Manager und Automation für die kontrollierte, automatisierte Behebung und Image-basierte Neuerstellungen für eine unveränderliche Infrastruktur. Dies steht im Einklang mit den AWS Best Practices für Erkennung, automatisierte Reaktion und minimalen „Blast Radius“ (Explosionsradius).
# 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
Zentralisierte Compliance wird durch die Konfiguration des delegierten Administratorkontos im Systems Manager Explorer und die Aktivierung der Ressourcendaten-Synchronisierung (resource data sync) ermöglicht. Dadurch wird der Patch-Compliance-Status aus jedem Konto in einem einzigen S3-Bucket aggregiert, der dann mit Athena abgefragt oder in QuickSight visualisiert werden kann.
Session Manager für auditierbare Administration
Der traditionelle SSH-basierte Zugriff hat drei strukturelle Schwächen: langlebiges Schlüsselmaterial befindet sich auf den Laptops der Bediener, Port 22 muss erreichbar sein (selbst wenn nur über eine Bastion-Host), und die Shell-Aktivität wird ohne zusätzliche Tools nicht zentral aufgezeichnet. Session Manager beseitigt alle drei.
Session Manager tunnelt eine interaktive Shell durch die ausgehende HTTPS-Verbindung des SSM Agent zu den SSM-Endpunkten. Es gibt keinen eingehenden Port, kein SSH-Schlüsselpaar und keinen Bastion-Host. Der Zugriff wird durch IAM-Richtlinien autorisiert (ssm:StartSession, eingeschränkt durch Instanz-Tag oder ARN), und jede Sitzung kann in CloudWatch Logs oder S3 protokolliert werden, optional mit KMS-Verschlüsselung. Unter Linux laufen Sitzungen standardmäßig als ssm-user; das sudo-Verhalten wird durch die sudoers-Konfiguration der Instanz gesteuert, nicht durch IAM.
Das korrekte Härtungsmuster für neue Flotten ist: Starten Sie Instanzen ohne ein EC2-Schlüsselpaar, fügen Sie ein Instanzprofil mit AmazonSSMManagedInstanceCore an, platzieren Sie die Instanzen in privaten Subnetzen mit VPC-Endpunkten für ssm, ssmmessages und ec2messages und erzwingen Sie die Sitzungsprotokollierung auf der Einstellungsebene des Session Managers. Die weitere Verteilung von SSH-Schlüsseln neben dem Session Manager ist die Falle: Sie erhält genau die Angriffsfläche aufrecht, zu deren Beseitigung der Session Manager eingeführt wurde, und hinterlässt einen nicht protokollierten Zugriffskanal. Entfernen Sie die Bereitstellung von authorized_keys aus Ihrem AMI-Erstellungsprozess.
Host-Telemetrie mit dem CloudWatch Agent
Der vereinheitlichte CloudWatch Agent sammelt Metriken auf Betriebssystemebene (Speicher, Festplatte, CPU pro Prozess) und Protokolldateien, die der EC2-Hypervisor nicht einsehen kann. Er wird über eine JSON-Datei konfiguriert, die typischerweise im Parameter Store gespeichert und dann mit amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux angewendet wird.
Der häufigste Betriebsfehler beim Agenten sind fehlende IAM-Berechtigungen im Instanzprofil. Der Agent benötigt mindestens:
logs:CreateLogGroup (es sei denn, die Gruppe wurde vorab erstellt)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (für benutzerdefinierte Metriken)
ssm:GetParameter (um die Konfiguration aus dem Parameter Store abzurufen)
Die verwaltete Richtlinie CloudWatchAgentServerPolicy bündelt diese. Wenn Berechtigungen fehlen, startet der Agent erfolgreich und erscheint in systemctl status als fehlerfrei, aber die Protokolle kommen nie in CloudWatch an – die Fehler sind nur in /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log sichtbar. Jedes Host-Sicherheitskonzept, das von zentralisierten Protokollen ausgeht, muss die Zustellung validieren, nicht nur den Status des Agenten.
Das Gesamtbild
Der defensive Kreislauf sieht wie folgt aus: Inspector entdeckt CVEs auf Hosts und in Container-Images, die Ergebnisse fließen zur Aggregation in Security Hub, Patch Manager führt die Behebung über geplante Wartungsfenster oder bei Notfällen über „Patch Now“ durch, Session Manager stellt den einzigen administrativen Zugriffspfad bereit, und der CloudWatch Agent streamt sowohl Patch-Nachweise als auch Laufzeitprotokolle an ein zentrales Konto. Jedes Steuerelement setzt die anderen voraus: Inspector ohne Patch Manager erzeugt Berichte, auf die niemand reagiert; Patch Manager ohne zentralisierte Protokollierung erzeugt keinen Audit-Trail; Session Manager ohne korrektes IAM hinterlässt entweder zu viel oder zu wenig Zugriff; und der CloudWatch Agent ohne korrekte Protokollberechtigungen erzeugt die Illusion von Sichtbarkeit.
← Governance · Alle Domänen · Container- und Serverless-Sicherheit →
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 →