Amazon DOP-C02: Sicherheit, Compliance und Governance — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Teil des AWS DevOps Engineer Professional DOP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Sicherheit, Compliance und Governance auf AWS basieren auf deterministischen Kontrollen, die über Konten und Regionen hinweg skalieren, ohne die Bereitstellung zu verlangsamen. Ein robustes Design schichtet Identitätskontrollen (IAM, Permission Boundaries und Service Control Policies), Multi-Account-Governance (AWS Organizations und Control Tower), kontinuierliche Bewertung und Behebung (AWS Config), Bedrohungserkennung (Security Hub, GuardDuty, Inspector), Hygiene im Umgang mit Secrets, Verschlüsselung mit AWS KMS und Netzwerkisolierung (VPC Security Groups, NACLs, Endpoints und PrivateLink). Das Ziel ist es, den Schadensradius (Blast Radius) zu minimieren, die Compliance kontinuierlich nachzuweisen und Prävention sowie Behebung zu automatisieren, während das Prinzip der geringsten Rechte (Least Privilege) und die Autonomie der Entwickler gewahrt bleiben.

Identität, Richtlinien und Multi-Account-Governance

IAM-Rollen, -Richtlinien, Permission Boundaries und SCPs wirken zusammen, um den effektiven Berechtigungssatz zu bilden. Die identitätsbasierten Richtlinien einer IAM-Rolle definieren erlaubte Aktionen; die Vertrauensrichtlinie der Rolle definiert, wer sie annehmen (assumieren) kann. Permission Boundaries begrenzen, was ein Principal tun kann, unabhängig davon, was die identitätsbasierten Richtlinien aussagen. SCPs in AWS Organizations legen das absolute Maximum für jeden Principal in einem Mitgliedskonto fest (einschließlich des Root-Benutzers). Ressourcenbasierte Richtlinien (für S3, KMS, Secrets Manager usw.) können kontenübergreifenden Zugriff erlauben, aber sie können ebenfalls nicht die durch SCPs oder Permission Boundaries gesetzten Grenzen überschreiten. Die effektive Berechtigung ist die Schnittmenge aus: identitätsbasierten Richtlinien ∩ Permission Boundary ∩ Sitzungsrichtlinien (falls vorhanden) ∩ ressourcenbasierter Richtlinie (falls zutreffend) ∩ SCPs, wobei jede explizite Deny-Anweisung Vorrang hat.

Verwenden Sie Permission Boundaries, um sicheren Self-Service in einem einzelnen Konto zu ermöglichen. Beispielsweise kann eine Pipeline zur Entwickler-Bereitstellung Rollen nur dann erstellen, wenn sie eine Boundary anfügt, die

undefined

außer für bestimmte Muster verweigert,

undefined

für sensible Schlüssel verbietet und die EC2-Instanztypen begrenzt. Boundaries können nur von Principals angefügt werden, die bereits über

undefined

verfügen; schützen Sie dieses Recht sorgfältig.

SCPs sind organisationsweite Leitplanken (Guardrails). Gängige Guardrails umfassen das Verbot, AWS Config oder CloudTrail zu deaktivieren, das Verhindern von Einladungen von außerhalb der Organisation, das Verweigern von Änderungen am delegierten Administrator des IAM Identity Center und die Einschränkung von Regionen. Bevorzugen Sie explizite „Allow-by-Exception“-Muster mit Bedingungen (zum Beispiel die Erlaubnis von Änderungen durch eine zentrale Admin-Rolle), um Reibungsverluste zu minimieren. Erlauben Sie immer die Erstellung und Verwendung notwendiger Service-Linked Roles (z. B. für GuardDuty, Inspector, Config), da Ihre SCPs sonst unbeabsichtigt die Einrichtung von Services blockieren.

AWS Organizations bietet hierarchische OUs zur Trennung von Umgebungen (z. B. Sandbox, Dev, Prod), Workload-Typen und Ausnahmekorridoren. Übernehmen Sie SCPs von übergeordneten OUs, um Policy-Drift zu vermeiden. Nutzen Sie Account Vending zur Standardisierung der Kontoeinrichtung: die Account Factory von AWS Control Tower (Konsole) oder Account Factory for Terraform (AFT) zur Integration in CI/CD. AFT fügt Workflows im GitOps-Stil, Drift-Erkennung und Feature-Flags hinzu (z. B. die Bereitstellung von Enterprise Support) und skaliert auf Hunderte von Konten mit konsistenten Basis-Guardrails.

AWS Control Tower automatisiert eine Landing Zone mit präskriptiven Guardrails. Präventive Guardrails sind SCPs, die von Control Tower verwaltet werden; detektivische Guardrails sind AWS Config-Regeln, die von ihm bereitgestellt werden. Control Tower integriert das IAM Identity Center für SSO und Permission Sets. Verwenden Sie ABAC-basierte Permission Sets mit Attributen für die Zugriffskontrolle, um Aktionen nach

undefined

oder Identitätsattributen zu steuern. Erweitern Sie die Baseline mit Customizations for AWS Control Tower (CfCT), um CloudFormation, SCPs und Config Packs pro OU/Konto automatisch bereitzustellen. Halten Sie Ausnahme-OUs vor, um Workloads mit maßgeschneiderten Richtlinien zu hosten, ohne die globalen Guardrails zu schwächen.

Kontinuierliche Compliance und automatisierte Behebung

Aktivieren Sie AWS Config organisationsweit von einem delegierten Administratorkonto aus. Aktivieren Sie die Aufzeichnung für alle Ressourcen in allen Regionen und aggregieren Sie die Konfigurationen über die gesamte Organisation mit einem Organisations-Aggregator. Verwenden Sie verwaltete Regeln für gängige Kontrollen (z. B.

undefined

) und erstellen Sie benutzerdefinierte, Lambda-gestützte Regeln für maßgeschneiderte Logik (z. B. die Überprüfung der KMS-Rotationskadenz gegen eine 90-Tage-Richtlinie oder die Erzwingung von Standard-Tags und -Werten). Conformance Packs bündeln Regeln, Parameter und Behebungsmaßnahmen in versionierten, bereitstellbaren Paketen pro OU; pflegen Sie diese in der Versionskontrolle und rollen Sie sie über StackSets oder CfCT aus, um Konsistenz und Überprüfbarkeit zu gewährleisten.

Die automatisierte Behebung schließt den Regelkreis. Ordnen Sie die nicht konforme Auswertung jeder Regel einem SSM Automation Runbook zu, das die Baseline durchsetzt: Fügen Sie ein Standard-Instanzprofil an, wenden Sie ein Tag mit einem Standardwert an, schalten Sie S3 Block Public Access um oder starten Sie eine EC2-Instanz zur Wartung neu. Verwenden Sie parametrisierte Dokumente und dynamische Eingaben (z. B. aus dem Config-Finding), um Runbooks generisch zu halten. Konfigurieren Sie für hochriskante Ressourcen die Behebung zur automatischen Ausführung; für sensible Aktionen fordern Sie eine Änderungsfreigabe oder eine manuelle Auslösung über EventBridge und ChatOps an. Schützen Sie Config selbst mit SCPs, die das Stoppen des Recorders oder das Löschen von Delivery Channels verbieten, außer durch einen zentralen Administrator.

Der Firewall Manager ergänzt diese Schicht für Policy-as-a-Service über Konten hinweg unter Verwendung von Organizations. Delegieren Sie einen zentralen Administrator und erstellen Sie Richtlinien für WAF Web ACL-Assoziationen auf internetzugewandten ALBs/API Gateways, für das Auditing und die Bereinigung von VPC-Sicherheitsgruppen oder für die Verbreitung von DNS-Firewall-Regeln. Dies verlagert die zukünftige Durchsetzung von Erkennung/Behebung hin zur Prävention.

Bedrohungserkennung, Geheimnis-Hygiene und Schwachstellenmanagement

Security Hub dient als zentrale Anlaufstelle („Single Pane of Glass“) für Befunde über Konten und Regionen hinweg. Aktivieren Sie ihn mit einem delegierten Administrator, aggregieren Sie Befunde und aktivieren Sie relevante Standards (AWS Foundational Security Best Practices, CIS, PCI DSS, wo zutreffend). Befunde fließen in das AWS Security Finding Format (ASFF) ein, das die Eingaben von GuardDuty, Inspector, IAM Access Analyzer, Config, Macie und Partner-Tools normalisiert. Verknüpfen Sie EventBridge-Muster, um kritische Befunde an Automatisierungen zur Problembehebung (SSM Automation, Lambda) und an Benachrichtigungen (SNS, Chat) weiterzuleiten.

GuardDuty bietet eine verwaltete Bedrohungserkennung, ohne dass Sie Log-Pipelines für die Datenebene verwalten müssen. Der Dienst analysiert CloudTrail-Management- und Datenereignisse, VPC Flow Logs, DNS-Abfrageprotokolle von Route 53 Resolver und EKS-Audit-Logs, um anomales Verhalten, die Exfiltration von Anmeldeinformationen, Krypto-Mining, DNS-Exfiltration und mehr zu erkennen. Aktivieren Sie den Malware-Schutz (Malware Protection) für das Scannen von S3 und EC2/EBS bei verdächtigen Aktivitäten. Nutzen Sie die organisationsweite automatische Aktivierung und archivieren Sie Befunde mit geringer Signifikanz systematisch mit Unterdrückungsregeln (Suppression Rules), um sich auf die umsetzbaren Ergebnisse zu konzentrieren.

Amazon Inspector bewertet kontinuierlich EC2 (über den SSM-Agenten) auf Paket-CVEs, ECR-Container-Images auf Schwachstellen vor der Bereitstellung und Lambda-Funktionen auf CVEs in Code-Paketen. Inspector erfordert, dass auf EC2-Instanzen der SSM Agent installiert ist, das Instanzprofil SSM-Berechtigungen zulässt und ausgehender Datenverkehr (Egress) zu SSM/KMS-Endpunkten möglich ist (über VPC-Endpunkte, wenn der Internetzugang eingeschränkt ist). Konfigurieren Sie Inspector so, dass Befunde an Security Hub gesendet und Patch-Workflows mit dem Systems Manager Patch Manager oder eine durch Runbooks gesteuerte Problembehebung ausgelöst werden. Verwenden Sie Tags, um den Geltungsbereich der zu scannenden Ressourcen festzulegen und um Sandbox- von regulierten Workloads zu trennen.

Secrets Manager zentralisiert die Speicherung, Rotation und den kontoübergreifenden Zugriff auf Geheimnisse mit starker Auditierbarkeit. Bevorzugen Sie Secrets Manager gegenüber Parameter Stores für Anmeldeinformationen, die eine Rotation erfordern, und nutzen Sie die integrierte Rotation für RDS/Aurora oder die Lambda-basierte Rotation für externe Systeme. Staging-Labels (AWSCURRENT, AWSPREVIOUS) ermöglichen eine Rotation ohne Ausfallzeiten. Führen Sie Rotations-Lambdas in VPCs mit den erforderlichen Endpunkten (Secrets Manager, RDS, KMS) aus und schränken Sie den ausgehenden Datenverkehr (Egress) ein. Für die kontoübergreifende Nutzung fügen Sie eine ressourcenbasierte Richtlinie an, die Prinzipalen in anderen Konten GetSecretValue erteilt. Stellen Sie sicher, dass die KMS-Schlüsselrichtlinie für den CMK des Geheimnisses den Prinzipalen des Konsumenten das Entschlüsseln und, falls erforderlich, das Erstellen von Grants erlaubt. Für Disaster Recovery oder zur Steuerung der Lokalität replizieren Sie Geheimnisse über Regionen hinweg und stimmen Sie die Rotationsfenster aufeinander ab.

Datenschutz und Netzwerksicherheit

Entwerfen Sie die Verschlüsselung mit KMS unter Verwendung expliziter Schlüsselrichtlinien. Schlüsselrichtlinien, nicht nur IAM-Richtlinien, autorisieren letztendlich Prinzipale für kryptografische Operationen auf einem CMK. Verfolgen Sie ein rollenbasiertes Schlüsselrichtlinienmodell nach dem Prinzip der geringsten Rechte (Least Privilege): Delegieren Sie die Administration an eine zentrale KMS-Admin-Rolle, gewähren Sie Nutzungsrechte eng an Workload-Rollen und verbieten Sie den Wildcard kms:*, um eine versehentliche Eskalation zu vermeiden. Verwenden Sie Bedingungsschlüssel (kms:EncryptionContext:*), um die Entschlüsselung an erwartete Kontexte zu binden. Multi-Region-Schlüssel ermöglichen eine Aktiv-Aktiv-Verschlüsselung, bei der Daten regionsübergreifend repliziert werden.

Grants sind das richtige Werkzeug, um die temporäre oder eng begrenzte Nutzung von Schlüsseln zu delegieren, ohne die Schlüsselrichtlinie bearbeiten zu müssen. Sie sind für einige Service-Abläufe erforderlich (z. B. EC2 Auto Scaling mit verschlüsselten Launch Templates, kontoübergreifende AMI-Nutzung). Damit ein anderes Konto Grants erstellen kann, muss die Schlüsselrichtlinie kms:CreateGrant für die Prinzipale dieses Kontos erlauben; der Grant-Empfänger (Grantee) muss ein Grant-Token für die sofortige Verwendung im selben Aufrufpfad bereitstellen. Für kontoübergreifend verschlüsselte AMIs kopieren und verschlüsseln Sie das AMI mit einem CMK, geben Sie das AMI frei, erlauben Sie dem Zielkonto, Grants für den CMK zu erstellen, und lassen Sie die serviceverknüpfte Rolle des Ziels einen Grant erhalten.

Die Envelope-Verschlüsselung ist das Standardmuster: Generieren Sie einen Datenschlüssel mit KMS, verschlüsseln Sie die Daten lokal mit dem Klartext-Datenschlüssel und speichern Sie dann nur den Chiffretext und den verschlüsselten Datenschlüssel. Rufen Sie beim Lesen KMS Decrypt auf, um den Klartext-Datenschlüssel wieder in den Speicher zu laden. Dies minimiert KMS-Aufrufe für große Datenmengen und begrenzt die Exposition von Klartext-Schlüsseln. Wo unterstützt, verwenden Sie serviceverwaltetes SSE-KMS (S3, EBS, RDS) zur Vereinfachung des Betriebs, aber stimmen Sie die Schlüsselrichtlinien weiterhin für kontoübergreifende Produzenten/Konsumenten ab.

Die VPC-Sicherheit beginnt mit Sicherheitsgruppen nach dem Prinzip der geringsten Rechte. Sicherheitsgruppen sind zustandsbehaftet (stateful); der Rückverkehr ist implizit erlaubt. Bevorzugen Sie Referenzen auf Sicherheitsgruppen gegenüber CIDR-basierten Regeln, um anfällige IP-Allow-Listen zu vermeiden und die Absicht im Infrastructure-as-Code beizubehalten. Standardmäßige ausgehende Freigaben sind riskant; beschränken Sie den Egress-Verkehr explizit auf erforderliche Ziele und verwenden Sie VPC-Endpunkte für den Zugriff auf AWS-Services. NACLs sind zustandslos (stateless) und werden zuerst ausgewertet; behalten Sie sie als grobe Kontrollen auf Subnetz-Ebene mit expliziten Rückgaberregeln für ephemere Ports nur dann bei, wenn Sie eine zusätzliche Grenze implementieren oder regulatorische Anforderungen erfüllen müssen; bevorzugen Sie andernfalls Sicherheitsgruppen wegen der besseren Verwaltbarkeit.

Beseitigen Sie Internetabhängigkeiten durch die Verwendung von VPC-Endpunkten. Gateway-Endpunkte (S3, DynamoDB) leiten den Verkehr privat über das AWS-Netzwerk; weisen Sie eine Endpunktrichtlinie zu, um den Zugriff auf Buckets oder Tabellen einzuschränken. Interface-Endpunkte (AWS PrivateLink) stellen AWS-Services (Secrets Manager, KMS, SSM, ECR, CloudWatch) über private IPs bereit; stellen Sie sie in Subnetzen mit den richtigen Sicherheitsgruppen bereit und aktivieren Sie Private DNS, damit Standard-Servicenamen zu privaten Adressen aufgelöst werden. Für Producer-Consumer-Microservices über Konten/VPCs hinweg, veröffentlichen Sie einen NLB-gestützten Endpunktservice und lassen Sie die Konsumenten über PrivateLink Interface-Endpunkte darauf erstellen. Dadurch werden Peering oder Transit Gateways vermieden und der Verkehr vom öffentlichen Internet ferngehalten. Kombinieren Sie diese Kontrollen mit Subnetzen ohne NAT und ohne IGW sowie einer zentralisierten Egress-Inspektion, wo Internetzugang erforderlich ist.

Praktisches Problemszenario

Die Expedia Group expandiert auf Hunderte von AWS-Konten in mehreren Regionen und muss eine strikte Sicherheits-Baseline durchsetzen: kein Internet-Egress für Workloads, automatisierte Behebung von Fehlkonfigurationen, zentralisierte Bedrohungserkennung, Rotation von Secrets und kontrollierte, kontoübergreifende Freigabe von verschlüsselten AMIs für standardisierte Golden Images.

Etablierung einer Multi-Account-Governance mit AWS Organizations und AWS Control Tower

Aktion: Erstellen Sie OUs für Sandbox, Dev, Prod und Security. Stellen Sie Control Tower bereit, um die Landing Zone einzurichten, obligatorische Guardrails zu aktivieren und das IAM Identity Center zu integrieren. Verwenden Sie die Account Factory for Terraform (AFT), um Konten über GitOps bereitzustellen.
Warum: Control Tower bietet schlüsselfertige, kontinuierlich durchgesetzte Guardrails (SCPs und Config-Regeln). AFT standardisiert die Kontobereitstellung im großen Maßstab und kodifiziert Baselines in der Versionskontrolle.

Erstellung von SCPs zur Durchsetzung globaler Guardrails mit Ausnahmen

Aktion: Hängen Sie SCPs an, die das Deaktivieren von CloudTrail und AWS Config verbieten, Regionen einschränken und öffentliche S3-ACLs verhindern. Fügen Sie bedingungsbasierte Ausnahmen für eine Security-Admin-Rolle in der Security-OU hinzu. Erlauben Sie die Erstellung/Verwendung erforderlicher serviceverknüpfter Rollen.
Warum: SCPs begrenzen die Berechtigungen aller Prinzipale, einschließlich des Root-Users, und verhindern so Abweichungen (Drift), während sie kontrollierte Ausnahmen für zentrale Operationen zulassen.

Bereitstellung von Config-Konformitätspaketen mit automatisierter Behebung

Aktion: Aktivieren Sie vom delegierten Administratorkonto für Sicherheit aus AWS Config organisationsweit und erstellen Sie einen Aggregator. Rollen Sie ein Konformitätspaket aus, das standardmäßige EBS-Verschlüsselung, eingeschränktes SSH, obligatorische Tags mit Standardwerten und erforderliches WAF an öffentlichen Einstiegspunkten erzwingt. Ordnen Sie jede Regel SSM-Automatisierungsdokumenten für automatische Korrekturen zu (z. B. Anhängen des Standard-Instanzprofils, Setzen fehlender Tags auf wöchentlich).
Warum: Konformitätspakete liefern konsistente, prüfbare Policy-as-Code mit automatischer Behebung, die Umgebungen in einem konformen Zustand hält, ohne ein hohes Ticket-Aufkommen zu verursachen.

Zentralisierung der Erkennung mit Security Hub, GuardDuty und Inspector

Aktion: Aktivieren Sie GuardDuty und Inspector organisationsweit mit einem delegierten Administrator. Aktivieren Sie Security Hub-Standards (AWS FSBP und CIS) und aggregieren Sie die Findings. Erstellen Sie EventBridge-Regeln, um Findings mit hohem Schweregrad an SSM-Automatisierungs-Runbooks und ein SNS-Thema für die Rufbereitschaft weiterzuleiten.
Warum: Verwaltete Erkennung und Schwachstellenanalyse bieten kontinuierliche Abdeckung bei minimalem Betriebsaufwand, und Security Hub konsolidiert Signale für eine schnellere Triage und Reaktion.

Durchsetzung des Least-Privilege-Prinzips in IAM mit Berechtigungsgrenzen und ABAC

Aktion: In durch AFT bereitgestellten Konten muss für von Entwicklern erstellte Rollen eine Berechtigungsgrenze (Permission Boundary) angehängt werden, die iam:PassRole außer für kuratierte Rollen verweigert und APIs mit großer Auswirkung einschränkt. Verwenden Sie Berechtigungssätze (Permission Sets) des IAM Identity Center mit ABAC, um Aktionen nach Team-Tags zu steuern.
Warum: Berechtigungsgrenzen ermöglichen einen sicheren Self-Service und verhindern gleichzeitig eine Privilegienerweiterung; ABAC reduziert den Wildwuchs von Richtlinien und bleibt an den Identitätsattributen ausgerichtet.

Absicherung der Netzwerkpfade mit VPC-Endpunkten und PrivateLink

Aktion: Entfernen Sie IGWs/NATs aus den Anwendungs-Subnetzen. Erstellen Sie Interface-Endpunkte für KMS, Secrets Manager, SSM, ECR, CloudWatch und Gateway-Endpunkte für S3/DynamoDB mit restriktiven Endpunktrichtlinien. Veröffentlichen Sie interne Plattform-Services über PrivateLink-gestützte NLBs für die kontoübergreifende Nutzung.
Warum: Private Konnektivität eliminiert die Exposition gegenüber dem Internet und stellt sicher, dass Services auch in abgeschotteten Umgebungen erreichbar bleiben.

Implementierung einer KMS-Schlüsselstrategie mit Grants für kontoübergreifende AMIs

Aktion: Erstellen Sie CMKs pro Umgebung mit rollenspezifischen Schlüsselrichtlinien. Verschlüsseln Sie im Konto für die Image-Erstellung die Golden AMIs und geben Sie sie frei. Aktualisieren Sie die CMK-Richtlinie, um den Zielkonten das Erstellen von Grants zu ermöglichen, und erstellen Sie dann Grants für die serviceverknüpften Rollen in diesen Zielkonten.
Warum: Grants ermöglichen eine bereichsbezogene, prüfbare Delegierung, ohne die Schlüsselrichtlinien für jeden Konsumenten bearbeiten zu müssen. Dies ermöglicht es Auto Scaling, Instanzen von verschlüsselten AMIs kontoübergreifend zu starten.

Standardisierung der Secret-Rotation und des kontoübergreifenden Zugriffs

Aktion: Speichern Sie Datenbank- und API-Anmeldeinformationen im Secrets Manager. Implementieren Sie die Lambda-Rotation für Nicht-RDS-Ziele und aktivieren Sie die integrierte Rotation für RDS. Hängen Sie für gemeinsam genutzte Plattform-Secrets ressourcenbasierte Richtlinien an, die GetSecretValue für Konsumentenrollen in anderen Konten gewähren, und stellen Sie sicher, dass die CMK-Richtlinien die Entschlüsselung erlauben. Platzieren Sie die Rotations-Lambdas in VPCs mit den notwendigen Endpunkten.
Warum: Die automatisierte Rotation reduziert das Risiko von Anmeldeinformationen; ressourcenbasierte Richtlinien mit Abstimmung auf KMS ermöglichen eine sichere kontoübergreifende Nutzung unter Beibehaltung des Prinzips der geringsten Rechte und der Audit-Protokolle.

Diese Architektur bietet der Expedia Group durchsetzbare Guardrails, nachweisbare

← Monitoring · Alle Domänen · Container und Serverless-Betrieb →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →