AWS Cloud Practitioner 08: Security und Compliance

Security and Compliance ist mit 30 Prozent die zweitgrößte Domäne des Exam Guide CLF-C02. Den Rahmen kennen wir schon aus der Shared Responsibility in Teil 01: AWS sichert die Cloud, wir sichern, was wir hineinstellen. In diesem Teil geht es um die Dienste, mit denen wir unseren Anteil erledigen. Die meisten Prüfungsfragen beschreiben ein Problem und wollen den passenden Dienst hören, deshalb sortieren wir nach Aufgabe und nicht nach Alphabet.

Schutz am Rand mit Shield, WAF und Firewall Manager

Angriffe auf Webanwendungen kommen auf zwei Ebenen an. DDoS-Angriffe auf Netz- und Transportebene (Layer 3 und 4) überfluten eine Anwendung mit Paketen, etwa SYN- oder UDP-Floods. Angriffe auf Anwendungsebene (Layer 7) sehen dagegen aus wie normale HTTP-Requests und verstecken ihre Wirkung im Inhalt, etwa bei SQL Injection oder Cross-Site Scripting.

AWS Shield Standard schützt gegen die erste Sorte. Er ist für alle Kunden aktiv und kostet nichts. Shield Advanced ist die bezahlte Stufe für Unternehmen, die bei einem Angriff Unterstützung brauchen. Der Preis liegt laut Shield-FAQ bei 3.000 USD pro Monat und Organization (Stand Oktober 2026, Momentaufnahme), über die konsolidierte Abrechnung einmal für alle Accounts, zuzüglich Data-Transfer-Gebühren. Dafür gibt es Zugang zum Shield Response Team rund um die Uhr, sofern zusätzlich ein Business- oder Enterprise-Support-Plan besteht (Shield Doku). Shield Advanced schützt außerdem vor Kostenspitzen, die ein Angriff durch Skalierung verursacht. Die Standardkosten von WAF für die geschützten Ressourcen sind inklusive.

AWS WAF arbeitet auf Layer 7. Wir hängen eine Web ACL vor einen Application Load Balancer, ein API Gateway oder eine CloudFront-Distribution und legen darin Regeln fest: SQL Injection und XSS blocken, Länder sperren (Geo-Block) oder IP-Adressen drosseln, die zu viele Requests schicken (rate-based rules). Für CloudFront ist WAF global und läuft in allen Edge Locations, für ALB und API Gateway regional (WAF FAQ).

Die typische Verwechslung ist Shield gegen WAF. Prüfungsfragen mit „DDoS“ zielen auf Shield, Fragen mit „SQL Injection“, „Cross-Site Scripting“ oder „bestimmte Länder blockieren“ auf WAF.

AWS Firewall Manager verwaltet Regeln für Security Groups, WAF, Shield Advanced und Network Firewall zentral über alle Accounts einer AWS Organization. Er ersetzt keinen dieser Dienste, er verteilt deren Regeln. AWS Network Firewall filtert den Verkehr einer ganzen VPC, ist laut Exam Guide aber nicht prüfungsrelevant.

Zertifikate und Secrets gehören nicht in den Code

AWS Certificate Manager (ACM) stellt TLS-Zertifikate aus und erneuert sie automatisch. Öffentliche Zertifikate für integrierte Dienste sind kostenlos, nur exportierbare Zertifikate für den Einsatz außerhalb von AWS kosten Gebühren (ACM Pricing). Wir binden sie an Elastic Load Balancing, CloudFront oder API Gateway, und das abgelaufene Zertifikat am Montagmorgen ist kein Thema mehr.

AWS Secrets Manager speichert Zugangsdaten wie Datenbankpasswörter oder API-Keys und rotiert sie auf Wunsch automatisch über eine Lambda-Funktion. Für RDS ist die Rotation fertig integriert. Daneben nennt der Exam Guide (Task 2.3) AWS Systems Manager als zweiten Ort für Credentials, dort übernimmt der Parameter Store diese Aufgabe. Ist von Rotation die Rede, ist Secrets Manager gemeint.

Wer nachsehen will, ob eine Ressource versehentlich mit einem fremden Account oder öffentlich geteilt ist, nutzt den IAM Access Analyzer, den wir in Teil 02 kennengelernt haben. Er ist Teil von IAM und fällt unter die „access reports“, die der Exam Guide in Task 2.2 nennt.

KMS für den Alltag, CloudHSM für volle Schlüsselhoheit

Task 2.2 des Exam Guide trennt Encryption at rest und Encryption in transit. Die erste schützt gespeicherte Daten, etwa auf EBS-Volumes, in S3, RDS, EFS oder Redshift. Hier greifen KMS und bei S3 die serverseitige Verschlüsselung (SSE-S3 oder SSE-KMS). Die zweite schützt Daten auf dem Weg durchs Netz, in der Regel per TLS mit einem Zertifikat aus ACM.

Manche Dienste verschlüsseln ohne unser Zutun, etwa S3 jedes neue Objekt mit SSE-S3 (S3 Doku) oder CloudTrail die Logdateien, die ein Trail in einen Bucket schreibt (CloudTrail Doku). Bei anderen schalten wir die Verschlüsselung selbst ein oder wählen eine Variante mit mehr Kontrolle über den Schlüssel, etwa SSE-KMS statt SSE-S3.

Fast jede Verschlüsselung in AWS läuft über den AWS Key Management Service (KMS). Die Hardware dahinter betreibt AWS, die Schlüssel liegen als eigene Ressourcen im Account. Customer managed keys legen wir selbst an und steuern sie mit einer eigenen Key Policy. AWS managed keys erzeugt ein Dienst für uns, erkennbar am Alias aws/<dienst>, etwa aws/s3. AWS rotiert sie jährlich automatisch, ändern können wir an ihnen nichts (KMS Doku). AWS owned keys gehören AWS und tauchen in unserem Account gar nicht auf.

AWS CloudHSM ist die Alternative, wenn Vorgaben ein dediziertes Hardware Security Module verlangen. AWS stellt das Gerät bereit, die Schlüssel verwaltet allein der Kunde. Die aktuellen HSMs vom Typ hsm2m.medium sind nach FIPS 140-3 Level 3 validiert (Zertifikat #4703, CloudHSM Doku). Das 140-2-Zertifikat der älteren hsm1.medium steht seit dem 4. Januar 2026 auf der historischen Liste.

Bei S3 begegnet uns KMS am häufigsten. Wie in Teil 04 gesehen, verschlüsselt jeder neue Bucket standardmäßig mit SSE-S3, bei dem S3 die Schlüssel komplett selbst verwaltet. SSE-KMS ist ein Opt-in. Dann verschlüsselt S3 mit einem KMS-Key, den wir als Ressource sehen und bei einem Customer managed key auch selbst steuern. Wie beides konkret aussieht, schauen wir uns unten im Hands-on an.

Jeder Detektor hat seine eigene Datenquelle

Die meisten Verwechslungen in der Prüfung passieren bei den Diensten, die Probleme finden. Sie klingen ähnlich, schauen aber auf unterschiedliche Daten.

Amazon GuardDuty erkennt Bedrohungen per Machine Learning in Logdaten. Grundlage sind CloudTrail-Management-Events, VPC Flow Logs und DNS-Logs. Dazu kommen optionale Protection Plans, unter anderem für S3, EKS, Laufzeitüberwachung von ECS und EC2, Malware, RDS, Lambda und inzwischen AI Protection für Bedrock und SageMaker. Ein bekanntes Beispiel für einen Fund sind EC2-Instanzen, die nach einer Kompromittierung Kryptowährung schürfen (AWS Security Blog). GuardDuty fragt also, ob sich etwas im Account verdächtig verhält.

Amazon Macie sucht sensible Daten wie personenbezogene Informationen (PII), und zwar ausschließlich in S3. Amazon Inspector prüft EC2-Instanzen, Container-Images in ECR, Lambda-Funktionen und inzwischen auch Code-Repositories auf Schwachstellen. Bei EC2-Instanzen meldet Inspector außerdem offene Netzwerkpfade, über die sie von außerhalb der VPC erreichbar sind, etwa aus dem Internet über ein Internet Gateway (Inspector Doku). Das passt zu Task 3.5, wo der Exam Guide Inspector als Baustein für die Sicherheit einer VPC nennt.

AWS Security Hub sammelt die Ergebnisse (Findings) an einer Stelle. Hier gibt es seit Dezember 2025 zwei Produkte (Ankündigung). Das bisherige Security Hub heißt jetzt Security Hub CSPM (Cloud Security Posture Management), prüft die Konfiguration gegen Sicherheitsstandards und setzt dafür ein aktiviertes AWS Config voraus. Das neue Security Hub ist allgemein verfügbar, korreliert Findings aus GuardDuty, Inspector und CSPM, zeigt Exposure Findings und Angriffspfade und braucht Config nicht. Die klassische Prüfungsantwort „Security Hub braucht Config“ stimmt also nur noch für den CSPM-Teil.

Amazon Detective kommt danach. Liegt ein Finding vor, hilft Detective bei der Untersuchung, also bei der Frage, was genau passiert ist und welche Ressourcen beteiligt waren. Soll auf ein Finding automatisch etwas passieren, etwa eine Benachrichtigung, übernimmt das EventBridge aus Teil 07. Dort haben wir auch Config und CloudTrail kennengelernt, die für Konfigurationshistorie und API-Protokoll zuständig sind.

Compliance-Nachweise und die Regeln für Pentests

Viele Unternehmen müssen Prüfern belegen, dass ihr Cloud-Anbieter bestimmte Standards erfüllt. AWS Artifact ist das Portal dafür. Es stellt Compliance-Reports wie ISO, PCI oder SOC bereit und enthält Agreements, etwa das Business Associate Addendum (BAA) für HIPAA. Artifact prüft nichts selbst, es liefert die Dokumente zu dem Teil, den AWS verantwortet. Der Exam Guide (Task 2.2) betont außerdem, dass sich Compliance-Anforderungen nach Region, Branche und einzelnem Service unterscheiden.

Nutzt jemand AWS-Ressourcen für Spam, Portscans, DDoS oder Malware, melden wir das dem AWS Trust and Safety team. So heißt die Anlaufstelle im Exam Guide.

Eigene Penetrationstests sind für eine Reihe von Diensten ohne vorherige Genehmigung erlaubt. Die aktuelle Policy-Seite führt 16 Einträge: EC2-Instanzen samt WAF, NAT Gateways und Elastic Load Balancing (ein Eintrag), RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda und Lambda@Edge (ein Eintrag), Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx, Transit Gateway, Bedrock AgentCore und Global Accelerator.

Verboten bleiben DoS- und DDoS-Angriffe, Port-, Protocol- und Request-Flooding, DNS Zone Walking, DNS Hijacking, DNS Pharming über Route 53 sowie S3 Bucket Takeover und Subdomain Takeover. Wer einen DDoS-Angriff simulieren will, braucht dafür eine eigene DDoS-Simulation-Policy.

Sicherheitsprodukte von Drittanbietern finden wir laut Exam Guide (Task 2.4) im AWS Marketplace. Als Informationsquellen nennt der Guide das AWS Knowledge Center, das AWS Security Center und den AWS Security Blog.

Hands-on

Legen wir einen Bucket an und schreiben zwei Objekte hinein, eines ohne Angabe zur Verschlüsselung, eines mit SSE-KMS. Den Bucket-Namen ergänzen wir um ein eigenes Suffix, weil S3-Namen global eindeutig sein müssen. Unser Lauf fand am 25. Oktober 2026 in eu-central-1 statt. Requests an S3 und KMS können außerhalb des Free Tier Kosten verursachen, deshalb räumen wir am Ende auf.

aws s3api create-bucket --bucket ccp-demo-kms-<suffix> \
  --create-bucket-configuration LocationConstraint=eu-central-1 \
  --region eu-central-1

echo "Lernkarte Teil 08" > karte.txt

aws s3api put-object --bucket ccp-demo-kms-<suffix> \
  --key ohne-angabe.txt --body karte.txt \
  --region eu-central-1

{
    "ServerSideEncryption": "AES256"
}

Die Ausgabe ist gekürzt, das ETag fehlt. AES256 steht für SSE-S3, die Standardverschlüsselung jedes neuen Buckets. Jetzt dasselbe mit SSE-KMS, ohne einen Key anzugeben.

aws s3api put-object --bucket ccp-demo-kms-<suffix> \
  --key mit-kms.txt --body karte.txt \
  --server-side-encryption aws:kms \
  --region eu-central-1

{
    "ServerSideEncryption": "aws:kms",
    "SSEKMSKeyId": "arn:aws:kms:eu-central-1:123456789012:key/…"
}

In der Konsole: S3 → Bucket → Upload → Properties → Server-side encryption beim Hochladen; bei einem vorhandenen Objekt S3 → Bucket → Objekt anklicken → Properties → Server-side encryption settings.

Der Screenshot stammt aus einem zweiten Lauf am 26. Oktober 2026.

Auch diese Ausgabe ist gekürzt. Ohne eigene Key-ID nimmt S3 den AWS managed key alias/aws/s3. Schauen wir ihn uns an.

aws kms describe-key --key-id alias/aws/s3 --region eu-central-1 \
  --query "KeyMetadata.{Manager:KeyManager,Spec:KeySpec,Usage:KeyUsage,Origin:Origin}"

{
    "Manager": "AWS",
    "Spec": "SYMMETRIC_DEFAULT",
    "Usage": "ENCRYPT_DECRYPT",
    "Origin": "AWS_KMS"
}

KeyManager: AWS kennzeichnet einen AWS managed key, bei einem selbst angelegten Key stünde dort CUSTOMER. Aufschlussreich war das Erstellungsdatum des Keys (CreationDate, in der Ausgabe oben weggelassen). Es entsprach dem Zeitpunkt unseres put-object. AWS hat den Key also erst beim ersten Gebrauch erzeugt. Die Alias-Liste nennt die vordefinierten Namen der AWS managed keys.

aws kms list-aliases --region eu-central-1 \
  --query "Aliases[?starts_with(AliasName, 'alias/aws/')].AliasName"

[
    "alias/aws/dynamodb",
    "alias/aws/ebs",
    "alias/aws/elasticfilesystem",
    "alias/aws/es",
    "alias/aws/glue",
    "alias/aws/kinesisvideo",
    "alias/aws/rds",
    "alias/aws/redshift",
    "alias/aws/s3",
    "alias/aws/ssm",
    "alias/aws/xray"
]

Die Liste enthält auch Aliase, hinter denen noch kein Key steht. AWS gibt diese Namen vor, ihnen fehlt die TargetKeyId. Einen Key dahinter gibt es erst, wenn der Dienst ihn zum ersten Mal für die Verschlüsselung mit KMS nutzt. Jeder Dienst bekommt so seinen eigenen AWS managed key.

In der Konsole: Key Management Service (KMS) → AWS managed keys; daneben stehen Customer managed keys und Custom key stores.

Im zweiten Lauf stand dort nur aws/s3, obwohl die Alias-Liste elf Namen nennt. Die übrigen Aliase verweisen noch auf keinen Key.

AWS Artifact lässt sich am einfachsten in der Konsole ansehen, dort stehen Reports und Agreements zum Herunterladen bereit.

In der Konsole: AWS Artifact → Reports bzw. Agreements.

Zum Aufräumen löschen wir die Objekte und den Bucket. Versioning ist in diesem Bucket nicht aktiv, ein rekursives Löschen genügt.

aws s3 rm s3://ccp-demo-kms-<suffix> --recursive --region eu-central-1
aws s3api delete-bucket --bucket ccp-demo-kms-<suffix> --region eu-central-1
rm karte.txt

Für die Prüfung

Typische Fallen:

• Shield oder WAF. DDoS heißt Shield, Angriffe im HTTP-Inhalt heißen WAF.
• DDoS-Abwehr mit Mehrfachauswahl. Verlangt eine DDoS-Frage zwei oder mehr Antworten, gehören neben Shield auch CloudFront und Route 53 dazu. Beide laufen an den Edge Locations und nehmen Angriffe dort auf, bevor sie die Anwendung in der Region erreichen. Zielt der Angriff auf Layer 7, kommt WAF hinzu (DDoS-Whitepaper).
• Macie oder GuardDuty. Macie findet sensible Daten in S3, GuardDuty findet verdächtiges Verhalten im Account.
• Inspector oder GuardDuty. Inspector sucht Schwachstellen in Software, GuardDuty erkennt laufende Bedrohungen.
• Security Hub und Config. Die Abhängigkeit gilt nur für Security Hub CSPM, das neue Security Hub braucht kein Config.
• CloudHSM und FIPS. Die aktuellen HSMs sind nach FIPS 140-3 Level 3 validiert.

Quellen

• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide, insbesondere Domain 2 und Domain 4
• In-Scope-Services und Out-of-Scope-Services
• AWS Shield FAQs und Shield Response Team, Voraussetzungen
• AWS WAF FAQs
• AWS Certificate Manager Pricing
• AWS KMS keys
• AWS KMS API Reference, ListAliases
• CloudTrail, Verschlüsselung der Logdateien
• AWS Best Practices for DDoS Resiliency
• Amazon GuardDuty FAQs und Krypto-Mining erkennen und verhindern
• Amazon Macie: Automated sensitive data discovery
• Amazon Inspector Features und Inspector, Scans von EC2-Instanzen und Finding-Typen
• AWS Security Hub FAQs und Ankündigung Security Hub, Dezember 2025
• AWS CloudHSM: FIPS validation
• AWS Penetration Testing Policy

Im nächsten Teil geht es um Machine Learning und generative KI, von Rekognition bis Amazon Q.