Amazon SAA-C03: Sicherheit, IAM, KMS & Governance — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Grundlagen der Identität: Benutzer, Root, Gruppen und Rollen

Identity and Access Management ist die Steuerungsebene (Control Plane), die jede Workload durchläuft, und ihr Leitprinzip ist das der geringsten Rechte (Least Privilege): Gewähren Sie nur das, was benötigt wird, nur so lange, wie es benötigt wird, und bevorzugen Sie Identitäten, die kurzlebige Anmeldeinformationen erzeugen, gegenüber solchen, die statische Geheimnisse speichern.

Der Root-Benutzer ist der Eigentümer des Kontos, besitzt uneingeschränkte Berechtigungen und kann nicht durch IAM-Richtlinien oder SCPs eingeschränkt werden. Das macht ihn zur sensibelsten Anmeldeinformation in der gesamten Umgebung, und er sollte als Notfallzugriff (Break-Glass) behandelt werden. Bei einem neuen Konto: Aktivieren Sie ein Hardware- oder virtuelles MFA-Gerät für den Root-Benutzer, legen Sie ein langes, einzigartiges Passwort fest, entfernen Sie alle historischen Root-Zugriffsschlüssel und registrieren Sie alternative Kontakte für Abrechnung, Betrieb und Sicherheit, damit eine Wiederherstellung möglich ist. Nach der Ersteinrichtung – dem Erstellen einer IAM-Admin-Identität, der Konfiguration der Abrechnung und dem Festlegen des Konto-Alias – wird der Root-Benutzer nicht mehr verwendet, außer für den engen Satz von Aufgaben, für die AWS ihn explizit vorschreibt (Schließen des Kontos, Ändern des Kontonamens, Wiederherstellen gelöschter IAM-Berechtigungen, Aktivieren von MFA Delete und eine Handvoll S3/CloudFront-Operationen, die mit Root signiert werden müssen). Die tägliche Verwendung des Root-Benutzers ist falsch, da sein Geltungsbereich nicht durch Richtlinien eingeschränkt werden kann, er bei gemeinsamer Nutzung in CloudTrail schwer zuzuordnen ist und eine einzige Kompromittierung unwiderrufliche Kontrolle gewährt.

Der tägliche Zugriff durch Menschen erfolgt über IAM-Identitäten, deren Geltungsbereich durch Richtlinien mit den geringsten Rechten (Least-Privilege) eingeschränkt ist. Weisen Sie verwaltete Richtlinien Gruppen zu, nicht einzelnen Benutzern: Eine Administrators-Gruppe mit angehängter AdministratorAccess-Richtlinie und darin platzierten benannten Benutzern führt zu einem einzigen Punkt für Änderungen und vermeidet das Anti-Pattern, identische Richtlinien auf jeden Benutzer zu kopieren. Beschränken Sie den Geltungsbereich von Ressourcen mit expliziten ARNs anstelle von *.

Rollen dienen einem völlig anderen Zweck. Sie werden von Prinzipalen – Diensten, EC2-Instanzen, Lambda-Funktionen, föderierten Benutzern, kontoübergreifenden Aufrufern – übernommen und erzeugen temporäre STS-Anmeldeinformationen, die automatisch rotieren. Da diese Anmeldeinformationen nicht in einem Git-Commit offengelegt werden können und innerhalb von Minuten bis Stunden ablaufen, anstatt bis zur manuellen Rotation bestehen zu bleiben, sind Rollen die Standardidentität für alles, was nicht menschlich ist.

Zwei Richtlinien pro Rolle: Berechtigungen und Vertrauen

Jede Rolle wird von zwei unabhängigen Dokumenten gesteuert, und das Vergessen eines der beiden ist ein klassischer Fehlerfall.

Die Berechtigungsrichtlinie (identitätsbasiert) deklariert, was die Rolle tun kann, sobald sie übernommen wurde. Die Vertrauensrichtlinie (ressourcenbasiert, an die Rolle selbst angehängt) deklariert, wer sie übernehmen kann. Das Anhängen von AmazonS3ReadOnlyAccess an eine Rolle bewirkt nichts, wenn kein Prinzipal berechtigt ist, sts:AssumeRole dafür aufzurufen. Umgekehrt erzeugt eine freizügige Vertrauensrichtlinie ohne Berechtigungsrichtlinie eine Rolle, die zwar übernommen werden kann, aber nichts Nützliches tut.

Eine Lambda-Ausführungsrolle (Execution Role) zeigt das Service-Prinzipal-Muster – der Dienst selbst, nicht der Kontoinhaber, ist der Aufrufer:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Workload-Identität: Instance Profiles, Task Roles, IRSA, Roles Anywhere

Jede Anmeldeinformation, die in einem Template, einer Umgebungsvariable oder auf einem Laptop gespeichert ist, stellt eine zukünftige Sicherheitslücke dar. Das kanonische AWS-Muster ersetzt statische Zugriffsschlüssel durch kurzlebige, automatisch rotierte Anmeldeinformationen, die über Rollen bereitgestellt werden.

Für EC2 ist der Bereitstellungsmechanismus das Instance Profile – ein schlanker Container, der eine IAM-Rolle an eine Instanz bindet, damit der Instance Metadata Service (IMDSv2) temporäre Anmeldeinformationen an das SDK ausgeben kann. Die standardmäßige Credential Provider Chain findet diese ohne Konfiguration, sodass boto3.client('s3') einfach funktioniert und der Anwendungscode niemals eine Anmeldeinformation zu Gesicht bekommt. IMDSv2 (HttpTokens: required) sollte erzwungen werden, um die Exfiltration von Anmeldeinformationen durch SSRF zu verhindern. Die Anmeldeinformationen rotieren etwa alle sechs Stunden, und der Widerruf erfolgt durch eine einfache Bearbeitung der Rolle.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Für ECS ist das Analogon die Task Role, für Lambda die Execution Role und für EKS-Pods IRSA (IAM Roles for Service Accounts) oder EKS Pod Identity. In jedem Fall vermittelt AWS selbst die Anmeldeinformationen gegen eine Rolle, und die Workload sieht niemals ein langlebiges Geheimnis.

Das Einbacken von Zugriffsschlüsseln in ein AMI, ein User-Data-Skript oder eine .env-Datei ist aus drei konkreten Gründen falsch: Schlüssel rotieren niemals automatisch, ihr Geltungsbereich kann nicht auf den Sitzungskontext, wie z. B. einen Quell-VPC-Endpunkt, beschränkt werden, und wenn die Instanz kompromittiert oder ein AMI versehentlich geteilt wird, gehen die Anmeldeinformationen dauerhaft verloren.

Für Workloads außerhalb von AWS – On-Premises-Server, andere Clouds, CI-Runner – die temporäre AWS-Anmeldeinformationen ohne eingebettete Schlüssel benötigen, verwendet IAM Roles Anywhere X.509-Zertifikate von einer privaten CA (AWS Private CA oder Ihre eigene) als Vertrauensanker (Trust Anchor). Die Workload präsentiert ihr Client-Zertifikat und erhält kurzlebige STS-Anmeldeinformationen:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Dies schließt dasselbe Anti-Pattern, das Instance Roles und Secrets Manager innerhalb von AWS unterbinden.

Menschlicher Zugriff im großen Stil: Identity Center, SAML, Directory Service

Die Bereitstellung von IAM-Benutzern pro Konto ist in größerem Umfang nicht verwaltbar. AWS IAM Identity Center (Nachfolger von AWS SSO) ist der empfohlene zentrale Einstiegspunkt für den Zugriff von Mitarbeitern: ein einziges Verzeichnis, das sich mit jedem Konto in einer Organization föderiert und temporäre, rollenbasierte Sitzungen über Permission Sets ausstellt – vorlagenbasierte IAM-Rollen, die IdP-Gruppen zugeordnet sind. Benutzer authentifizieren sich einmal im Identity Center-Portal und übernehmen dann Permission Sets in jedem zugewiesenen Konto.

Identity Center lässt sich mit externen IdPs (Okta, Entra ID/Azure AD, Google Workspace, ADFS) über SAML 2.0 und SCIM für automatisierte Joiner/Mover/Leaver-Prozesse integrieren, sowie mit On-Premises Active Directory über den AWS Directory Service AD Connector (ein Proxy) oder AWS Managed Microsoft AD (eine vollständige Replik in AWS). Für mobile oder Web-Anwendungen, die AWS-Aufrufe von nicht authentifizierten oder von Drittanbietern authentifizierten Benutzern ausführen müssen, tauscht Amazon Cognito die externe Identität gegen temporäre STS-Anmeldeinformationen aus und vermeidet so ebenfalls eingebettete, langlebige Schlüssel.

Kontoübergreifender Zugriff

Kontoübergreifender Zugriff wird durch Rollen realisiert, nicht durch gemeinsam genutzte Benutzer, und beide Seiten müssen zustimmen. Das Zielkonto (B) erstellt eine Rolle, deren Vertrauensrichtlinie das Konto A (oder einen bestimmten Prinzipal darin) benennt, und der Aufrufer in A muss ebenfalls die Berechtigung sts:AssumeRole für den ARN dieser Rolle haben. Keine der beiden Seiten allein ist ausreichend. Dies erzeugt kurzlebige Anmeldeinformationen und einen klaren CloudTrail-Audit-Trail in beiden Konten.

Wenn ein Dritter (ein SaaS-Anbieter) der annehmende Prinzipal ist, fügen Sie eine ExternalId-Bedingung hinzu, um das Confused-Deputy-Problem zu verhindern, und ziehen Sie in Betracht, MFA zu verlangen:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Für kontoübergreifende Aufrufe von Service zu Service werden Ressourcenrichtlinien verwendet. Um einem SNS-Thema in Konto A zu erlauben, eine Lambda-Funktion in Konto B aufzurufen:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

Der --principal sns.amazonaws.com ist der Service-Prinzipal (SNS selbst ruft Lambda auf), und --source-arn schränkt das Vertrauen auf ein bestimmtes Topic ein, um das Confused-Deputy-Problem zu verhindern.

Für die S3-Freigabe über eine ganze Organisation hinweg skaliert der naive Ansatz – das Auflisten jedes Konto-ARNs in der Bucket-Richtlinie – nicht und geht kaputt, sobald ein neues Konto hinzugefügt wird. Das korrekte Muster ist aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Jeder Prinzipal in jedem Konto dieser Organisation ist erlaubt; alle anderen werden abgewiesen. Beachten Sie, dass Principal: "*" ohne die Bedingung den Bucket öffentlich machen würde – der Condition-Schlüssel ist das, was den Geltungsbereich einschränkt. Die Identitätsseite ist ebenfalls wichtig: Benutzer in Mitgliedskonten benötigen zusätzlich die Berechtigung s3:GetObject, die durch ihre eigene IAM-Richtlinie gewährt wird (es sei denn, sie sind der Konto-Root-Benutzer), da für kontoübergreifenden Zugriff beide Seiten den Aufruf erlauben müssen.

Speziell für S3 deaktiviert seit 2023 die Standardeinstellung für den Objektbesitz Bucket-Eigentümer erzwungen die ACLs vollständig, wodurch Bucket-Richtlinien zum einzigen Autorisierungsmechanismus für den Bucket werden. Wenn Objekte zuvor von anderen Konten hochgeladen wurden, können historische Objekt-ACLs oder die vordefinierte ACL bucket-owner-full-control weiterhin eine Rolle spielen.

Organizations und Service Control Policies

AWS Organizations fasst Konten in einer Baumstruktur von OUs zusammen, mit einem Verwaltungskonto an der Wurzel. Service Control Policies sind Leitplanken, die an die Root, eine OU oder ein einzelnes Konto angehängt werden. Sie gelten für jeden IAM-Benutzer und jede Rolle im Konto – einschließlich des Konto-Root-Benutzers – jedoch nicht für das Verwaltungskonto selbst, weshalb dort niemals Workloads ausgeführt werden sollten.

Das entscheidende Denkmodell: SCPs erteilen niemals Berechtigungen. Sie definieren die maximale Menge an Aktionen, die in einem Konto erlaubt sind. Eine Aktion ist nur dann erlaubt, wenn sie durch eine Identitäts- oder Ressourcenrichtlinie gewährt wird und nicht durch eine SCP im Pfad des Kontos blockiert wird. Wenn ein Entwickler AdministratorAccess hat, aber eine SCP ec2:RunInstances außerhalb von ap-southeast-2 verweigert, schlägt der Start in us-east-1 fehl. Umgekehrt bewirkt eine SCP, die s3:* erlaubt, für sich allein nichts – der Benutzer benötigt immer noch eine IAM-Richtlinie, die s3:* gewährt. SCPs filtern, was IAM bereits erlaubt hat; sie sind Obergrenzen, keine Untergrenzen.

Typische Anwendungsfälle für SCPs sind die Sperrung von Regionen, das Verbot der Deaktivierung von CloudTrail oder GuardDuty, das Verbot der Löschung von KMS-Schlüsseln außerhalb einer Break-Glass-Rolle und die Erzwingung der Verschlüsselung. Um die Verschlüsselung von EBS beim Start zu erzwingen, kombiniert man zwei Mechanismen: Aktivieren Sie die EBS-Standardverschlüsselung in der Region (eine regionsspezifische Kontoeinstellung, damit Benutzer keine Skripte ändern müssen), plus eine SCP als auditierbare Leitplanke:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Da SCPs für das gesamte Konto gelten, können sie von einem kompromittierten Administrator in einem Mitgliedskonto nicht umgangen werden. Tag-Richtlinien erzwingen standardisierte Tag-Schlüssel und deren Groß-/Kleinschreibung (CostCenter, nicht costcenter), damit Kostenzuordnung und ABAC zuverlässig funktionieren. Organizations unterstützt auch die delegierte Administration: Anstatt Sicherheitsdienste vom Verwaltungskonto aus zu betreiben, delegiert man ein Mitgliedskonto („Security“ oder „Audit“) als Administrator für GuardDuty, Security Hub, IAM Access Analyzer oder Config – wodurch die Funktionstrennung gewahrt bleibt.

KMS: Schlüssel, Schlüsselrichtlinien und Eigentümermodelle

KMS unterscheidet Schlüsselmaterial nach Eigentümerschaft und Kontrolle:

Ein CMK wird durch eine Schlüsselrichtlinie (Key Policy) geregelt – eine ressourcenbasierte Richtlinie, die an den Schlüssel angehängt ist. Im Gegensatz zu fast allen anderen AWS-Ressourcen können IAM-Richtlinien allein keinen Zugriff auf einen KMS-Schlüssel gewähren, es sei denn, die Schlüsselrichtlinie delegiert diesen zuerst an IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Ohne diese Anweisung (Statement) macht keine IAM-Richtlinie den Schlüssel nutzbar. Sowohl die Schlüsselrichtlinie als auch die IAM-Richtlinie des Aufrufers müssen die Operation erlauben – dies ist der häufigste einzelne Fehler bei der Verschlüsselung. Die Gewährung von kms:Decrypt in einer IAM-Richtlinie ist notwendig, aber nicht ausreichend; wenn die Schlüsselrichtlinie nicht an IAM delegiert oder den Principal nicht benennt, schlägt die Entschlüsselung selbst für einen Administrator mit AccessDenied fehl.

Für Dienste, die KMS in Ihrem Namen verwenden (EBS, S3, RDS, Lambda), benötigt die aufrufende Rolle typischerweise kms:GenerateDataKey, kms:Decrypt und oft kms:CreateGrant. Bei einer von EKS verwalteten Knotengruppe, die EBS-Volumes mit einem CMK verschlüsselt, muss die Service-verknüpfte Rolle von Auto Scaling in der Schlüsselrichtlinie mit kms:CreateGrant aufgeführt sein, andernfalls schlagen Instanzstarts stillschweigend fehl.

Die Rotation von kundenverwalteten CMKs muss explizit aktiviert werden – viele Praktiker gehen fälschlicherweise davon aus, dass alle KMS-Schlüssel automatisch rotieren:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

Die Rotation behält dieselbe Schlüssel-ID und denselben Alias bei; das zugrunde liegende Schlüsselmaterial ändert sich, aber frühere Chiffretexte bleiben entschlüsselbar, da KMS altes Material zur Entschlüsselung bestehender Chiffretexte aufbewahrt, während neue Schreibvorgänge frisches Material verwenden. Importiertes Material rotiert niemals automatisch. KMS erzwingt ein obligatorisches Fenster von 7–30 Tagen für die ausstehende Löschung; kombinieren Sie dies mit einer EventBridge-Regel, die auf ScheduleKeyDeletion oder DisableKey in CloudTrail reagiert und auf ein SNS-Thema abzielt, um ein serverloses, abfragefreies Benachrichtigungsmuster zu erstellen:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

External Key Stores erweitern das Modell, wenn Regulierungsbehörden verlangen, dass das Schlüsselmaterial physisch in einem vom Kunden kontrollierten HSM verbleibt. KMS leitet kryptografische Operationen an einen XKS-Proxy weiter, der mit dem lokalen HSM kommuniziert; wenn das HSM offline ist, schlägt die Entschlüsselung fehl – die Verfügbarkeit liegt dann in der Verantwortung des Kunden.

Multi-Region Keys (MRKs) teilen dieselbe Schlüssel-ID und dasselbe Material über Regionen hinweg, sodass ein in us-east-1 erzeugter Chiffretext direkt in eu-west-1 entschlüsselt werden kann. Dies ist das korrekte Muster für DynamoDB Global Tables, S3 Cross-Region Replication mit SSE-KMS und Disaster Recovery (DR), bei dem eine Standby-Region verschlüsselte Backups lesen muss. Standardmäßige Single-Region-Schlüssel würden zum Zeitpunkt der Replikation eine Entschlüsselung mit anschließender Neuverschlüsselung erfordern.

Kontoübergreifende Freigabe verschlüsselter Ressourcen

Die Freigabe von verschlüsselten AMIs und EBS-Snapshots ist einer der häufigsten kontoübergreifenden Fehlermodi, da sie vier koordinierte Aktionen erfordert: (1) Verwendung eines kundenverwalteten CMK – AWS-verwaltete Schlüssel können nicht freigegeben werden; (2) Hinzufügen des Zielkontos als Principal in der Schlüsselrichtlinie mit den Berechtigungen kms:Decrypt, kms:DescribeKey, kms:CreateGrant und kms:ReEncrypt*; (3) Ändern der Start-/Freigabeberechtigungen des AMIs oder Snapshots, um dieses Konto einzuschließen; und (4) Sicherstellen, dass der IAM-Principal im Zielkonto ebenfalls über diese KMS-Aktionen verfügt. Der Freigabevorgang scheint erfolgreich zu sein, wenn Sie Schritt 2 überspringen, aber das empfangende Konto kann nicht entschlüsseln. Anzunehmen, dass die alleinige Freigabe des AMIs ausreicht, ist die klassische Falle.

S3: Serverseitige Verschlüsselungsmodi

Wenn eine Anforderung automatische jährliche Rotation, Auditierbarkeit in CloudTrail und Minimierung der Schlüsselkosten vorschreibt, lautet die Antwort SSE-KMS mit dem AWS-verwalteten aws/s3-Schlüssel – er rotiert jährlich kostenlos und jeder Aufruf von GenerateDataKey/Decrypt wird protokolliert. SSE-S3 ist günstiger, hinterlässt aber keine Spur der Schlüsselnutzung. Ein kundenverwalteter CMK kostet zusätzlich 1 $/Monat und rotiert nur, wenn Sie die Rotation aktivieren.

Die Verwechslung von SSE-S3 und SSE-KMS ist die klassische PHI-Falle. SSE-S3 verschlüsselt Daten, bietet aber keine Schlüsselrichtlinie, keine Sichtbarkeit in CloudTrail und keine Möglichkeit für ein Compliance-Team, den Schlüssel zu verwalten – daher erfüllt es keine Anforderung, die die “Verwaltung”, “Kontrolle”, “Auditierung” oder den “Entzug des Zugriffs auf” den Schlüssel erwähnt. Umgekehrt ist die Wahl von SSE-KMS, wenn die Anforderung nur “Verschlüsselung im Ruhezustand mit minimalem Verwaltungsaufwand” lautet, Over-Engineering.

Die Aktivierung von SSE-KMS verhindert nicht von sich aus unbefugte Lesezugriffe. Wenn die Bucket-Richtlinie s3:GetObject erlaubt und die Schlüsselrichtlinie demselben Principal kms:Decrypt gewährt, ist das Objekt lesbar. Verschlüsselung im Ruhezustand schützt vor der Kompromittierung physischer Medien und fügt eine zweite Autorisierungsprüfung über die Schlüsselrichtlinie hinzu – sie ersetzt jedoch nicht korrekt definierte Bucket-Richtlinien, IAM-Richtlinien, VPC-Endpunkt-Richtlinien und aws:PrincipalOrgID-Bedingungen.

Erzwingen von Verschlüsselung und TLS bei S3

Einen Bucket als „standardmäßig verschlüsselt“ zu konfigurieren, reicht nicht aus – Clients können den Verschlüsselungs-Header weglassen oder überschreiben. Zwei Schutzmaßnahmen müssen ineinandergreifen: standardmäßige Bucket-Verschlüsselung (füllt den Header aus, wenn der Client ihn weglässt) und eine ablehnungsbasierte Bucket-Richtlinie, die PutObject ohne den erforderlichen Header zurückweist, sowie eine Anweisung, die den Zugriff ohne TLS verweigert:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Die Bedingung aws:SecureTransport erzwingt HTTPS und erfüllt damit die Anforderung „Verschlüsselung während der Übertragung“ (encrypted in transit). In Kombination mit SSE-KMS unter Verwendung eines CMK, der dem Compliance-Team gehört, ist dies das kanonische Speichermuster für PHI.

Verschlüsselung bei der Übertragung (in Transit) vs. im Ruhezustand (at Rest)

Verschlüsselung im Ruhezustand (KMS-verschlüsselte EBS-Volumes, RDS-Speicher, S3-Objekte) und Verschlüsselung bei der Übertragung (TLS auf der Leitung) sind unabhängige Kontrollen, die unterschiedliche Bedrohungen adressieren – Diebstahl von Festplatten gegenüber dem Abfangen von Netzwerkverkehr. Die Aktivierung von KMS auf einer RDS-Instanz schützt den zugrunde liegenden Speicher; sie bewirkt nichts für eine Sitzung zwischen Client und Datenbank, die standardmäßig unverschlüsselt sein kann. Für RDS MySQL erfordert der Schutz bei der Übertragung das Herunterladen des RDS CA-Bundles, das Setzen von require_secure_transport=ON in der Parametergruppe und die Verbindung von Clients mit --ssl-ca=rds-combined-ca-bundle.pem. Die Annahme, dass „Verschlüsselung im Ruhezustand ist aktiviert“ ausreicht, ist ein häufiger Fehler bei Audits.

Secrets Manager und Parameter Store

Statische Datenbankpasswörter in Konfigurationsdateien, Umgebungsvariablen oder CloudFormation-Parametern sind der häufigste Angriffsvektor für den Diebstahl von Anmeldeinformationen. AWS Secrets Manager speichert Secrets KMS-verschlüsselt, stellt sie über den IAM-gesteuerten Befehl GetSecretValue bereit und – was entscheidend ist – rotiert sie automatisch über eine Lambda-Rotationsfunktion. Für RDS, Aurora, Redshift und DocumentDB stellt AWS eine verwaltete Rotations-Lambda-Funktion bereit, die sich mit der Datenbank verbindet, ein neues Passwort generiert, sowohl das Secret als auch den DB-Benutzer atomar aktualisiert und Single-User- oder Multi-User-Strategien unterstützt. Für andere Systeme erstellen Sie eine Lambda-Funktion, die den vierstufigen Lebenszyklus implementiert: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Anwendungen cachen den Wert für kurze Zeit (mithilfe der Caching-Bibliothek des AWS SDK) und verbinden sich bei einem Authentifizierungsfehler neu. Die Rotation ist unsichtbar und es ist kein Deployment erforderlich, um ein Passwort zu ändern.

SSM Parameter Store SecureString ist die Alternative, wenn keine Rotation erforderlich ist und die Kosten im Vordergrund stehen:

Ein Abrufer eines SecureString-Parameters benötigt sowohl ssm:GetParameter als auch kms:Decrypt für den Schlüssel. Das Vergessen der KMS-Berechtigung ist eine der häufigsten Fehlkonfigurationen – die IAM-Richtlinie sieht korrekt aus, aber der API-Aufruf schlägt bei der Entschlüsselung fehl.

Auf EC2, ECS, EKS und Lambda sollte der Code eine IAM-Rolle annehmen und GetSecretValue oder GetParameter aufrufen; keine langlebigen Anmeldeinformationen auf der Festplatte. Das direkte Einbetten von IAM-Benutzer-Zugriffsschlüsseln in den Anwendungscode – selbst verschlüsselt – verletzt das Prinzip der geringsten Rechte (Least Privilege) und erschwert die Rotation.

Audit- und Forensik-Werkzeuge

CloudTrail zeichnet jeden AWS-API-Aufruf auf: wer, was, wann und von wo. Ein Organization Trail, der vom Verwaltungskonto aus aktiviert wird, erfasst Ereignisse aus allen Konten in einem einzigen S3-Bucket, idealerweise in einem abgesicherten Sicherheitskonto mit S3 Object Lock und MFA Delete. Dies liefert eine unveränderliche forensische Zeitachse – welcher Principal ein Volume gelöscht hat, welche Rolle eine Sicherheitsgruppe geändert hat, welcher Zugriffsschlüssel ec2:RunInstances um 03:17 UTC aufgerufen hat. Ergänzen Sie dies mit CloudWatch Logs und Alarmen (Root-Login, Änderungen an IAM-Richtlinien) sowie AWS Config für den Ressourcenstatus zu einem bestimmten Zeitpunkt und für Conformance Packs. Verhindern Sie Manipulationen mit einer SCP, die cloudtrail:StopLogging und cloudtrail:DeleteTrail verweigert.

MFA Delete für einen S3-Bucket zwingt den Root-Benutzer, ein MFA-Token vorzulegen, um eine Objektversion endgültig zu löschen oder die Versionierung zu deaktivieren. Es kann nur vom Root-Benutzer über die CLI aktiviert werden und bietet einen starken Schutz gegen Ransomware und das Löschen durch Insider.

Amazon Macie verwendet verwaltetes ML, um PII, PHI, Anmeldeinformationen und Finanzdaten in S3 zu entdecken und erstellt nach Schweregrad geordnete Ergebnisse (Findings). Es ist ein Werkzeug zur Erkennung, kein Verschlüsselungswerkzeug.

Bedrohungserkennung: GuardDuty, Security Hub, Detective

Amazon GuardDuty analysiert kontinuierlich VPC Flow Logs, DNS-Protokolle sowie CloudTrail-Management- und Datenereignisse, mit dedizierten Schutzplänen für EKS-Audit-Protokolle, S3-Datenereignisse, EBS-Malware-Scans, Lambda-Netzwerkaktivitäten und RDS-Anmeldeereignisse. GuardDuty RDS Protection deckt anomale oder Brute-Force-Authentifizierungsversuche gegen Aurora und RDS auf – ein Verhalten, das eine Sicherheitsgruppe nicht erkennen kann, da die Verbindung auf L4 legitim ist. Die Ergebnisse (Findings) fließen in die Dashboards von EventBridge, Security Hub und Detective.

Sicherheitsgruppen arbeiten nur auf L3–L4. Eine Gruppe, die 0.0.0.0/0 auf Port 443 zulässt, erfüllt ihre Aufgabe, wenn sie eine SQL-Injection-Payload weiterleitet – genau das soll eine WAF verhindern. Defense in Depth bedeutet Sicherheitsgruppen plus WAF plus Shield plus GuardDuty, wobei jede Komponente eine Schicht abdeckt, die die anderen nicht sehen können.

DDoS: Shield Standard und Advanced

AWS Shield Standard ist automatisch und kostenlos und verteidigt jedes Konto gegen gängige L3/L4-Angriffe (SYN-Floods, Reflection-Angriffe). Es läuft unbemerkt im Hintergrund ohne Einblick, ohne benutzerdefinierte Abwehrmaßnahmen und ohne die Möglichkeit menschlicher Eingriffe.

AWS Shield Advanced (3.000 $/Monat pro Organisation zuzüglich Datenübertragungskosten) ist erforderlich, wenn im Szenario von proaktivem Eingreifen, dedizierter Reaktion, Kostenschutz vor DDoS-induzierter Skalierung oder Angriffssichtbarkeit in nahezu Echtzeit die Rede ist. Es schützt CloudFront, Global Accelerator, ALB, CLB, Route 53 und Elastic IPs und bietet rund um die Uhr Zugang zum Shield Response Team (SRT) – vorab autorisiert über eine IAM-Rolle –, um während eines aktiven Angriffs in Ihrem Namen WAF-Regeln zu schreiben. Wenn ein Design hinter einem ALB und Route 53 eine verwaltete Erkennung und eine menschliche Reaktion erfordert, ist Shield Standard allein unzureichend; das ist die wiederkehrende Falle. Advanced gewährt außerdem Kostenschutz für Skalierungen, die durch Angriffe ausgelöst werden. Wenn von „GERINGSTEM Implementierungsaufwand“ die Rede ist und die Architektur bereits einen Global Accelerator oder einen ALB enthält, lautet die Antwort typischerweise Shield Advanced aktivieren und die von AWS verwalteten WAF-Regelgruppen anhängen, nicht das Erstellen benutzerdefinierter Lambda@Edge-Funktionen oder die Migration des CDN.

Schutz auf Anwendungsebene: AWS WAF

AWS WAF wird an CloudFront, Application Load Balancer, API Gateway, AppSync, App Runner und Cognito-Benutzerpools angehängt. Es schützt Network Load Balancer nicht direkt (schalten Sie CloudFront davor). Es inspiziert den L7-Verkehr und wendet Regeln für SQL-Injection, XSS, Größenbeschränkungen, Geo-Blocking, IP-Reputation und Ratenbegrenzung an. AWS Managed Rules bieten kuratierte Gruppen wie AWSManagedRulesCommonRuleSet und AWSManagedRulesSQLiRuleSet, ohne dass man Regex schreiben muss.

Ratenbasierte Regeln sind die primäre Verteidigung gegen HTTP-Floods und Credential Stuffing – sie zählen Anfragen pro Fünf-Minuten-Fenster pro Quell-IP (oder pro weitergeleitetem Header) und blockieren Angreifer automatisch:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF ist kein DDoS-Dienst – das ist die Aufgabe von Shield. WAF ergänzt Ressourcenrichtlinien (S3-Bucket-Richtlinien, die Nicht-TLS-Verbindungen verweigern, VPC-Endpunkt-Richtlinien, die erreichbare Buckets einschränken) und Netzwerkkontrollen (Security Groups, NACLs) – eine Fehlkonfiguration auf einer einzigen Ebene darf keine Daten preisgeben.

Netzwerkisolierung: Security Groups, NACLs, Network Firewall

Innerhalb einer VPC ist die Verteidigung mehrschichtig aufgebaut:

• Security Groups sind zustandsbehaftet (stateful), gelten für ENIs, erlauben nur Zulassungsregeln (allow-only) und werten alle Regeln gemeinsam aus. Rückverkehr wird automatisch zugelassen, sodass ephemere Ports nicht explizit geöffnet werden müssen.
• Network ACLs sind zustandslos (stateless), gelten für Subnetze, unterstützen sowohl Zulassen (allow) als auch Verweigern (deny) und werden in numerischer Reihenfolge ausgewertet. Da sie zustandslos sind, müssen Sie, wenn Sie eingehenden Port 443 zulassen, auch ausgehende ephemere Ports 1024–65535 für Antworten zulassen. Wenn man dies vergisst, werden alle Antworten auf subtile Weise verworfen. Security Groups haben dieses Problem nicht.
• AWS Network Firewall bietet Deep Packet Inspection, Suricata-kompatible IPS-Regeln und domänenbasiertes Filtern des ausgehenden Verkehrs und befindet sich zur zentralen Überprüfung zwischen Subnetzen und IGWs/TGWs.

Die Annahme, dass Security Groups allein ausreichen, ignoriert Bedrohungen auf Subnetz-Ebene und Kontrollen des Explosionsradius (Blast Radius); die Annahme, dass NACLs allein ausreichen, ignoriert ihre Zustandslosigkeit und Grobheit.

Fallstricke-Katalog

Vertrauensrichtlinie vergessen. Die Berechtigungsrichtlinie einer Rolle gewährt Fähigkeiten; nur die Vertrauensrichtlinie (Trust Policy) gewährt die Übernehmbarkeit (Assumability). Beide müssen für den kontoübergreifenden oder Service-zu-Service-Zugriff geöffnet sein, damit es funktioniert – der Aufrufer erhält AccessDenied bei sts:AssumeRole, unabhängig davon, wie freizügig die Identitätsrichtlinie ist.

IAM-Richtlinie ohne passende Schlüsselrichtlinie. kms:Decrypt in IAM ist notwendig, aber nicht ausreichend. Die Schlüsselrichtlinie muss entweder den Prinzipal benennen oder an IAM mit Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"} delegieren. Die Freigabe verschlüsselter AMIs/Snapshots schlägt fehl, wenn nur die AMI-Freigabe erfolgt und die Schlüsselrichtlinie nicht aktualisiert wird.

SCPs als Berechtigungen behandelt. SCPs begrenzen, sie gewähren niemals Berechtigungen. Ein Allow s3:* SCP bewirkt nichts ohne eine passende Identitätsrichtlinie. Umgekehrt wird eine freizügige Identitätsrichtlinie durch jegliches Deny in einem SCP im Pfad des Kontos eingeschränkt.

Annahme der automatischen KMS-Rotation. Vom Kunden verwaltete CMKs rotieren nicht, bis dies aktiviert wird; importiertes Schlüsselmaterial rotiert niemals automatisch.

SSE-S3 für compliance-gesteuerte Daten gewählt. SSE-S3 hat keine Schlüsselrichtlinie, keine Sichtbarkeit in CloudTrail und keinen Widerrufspfad – es erfüllt keine Anforderung, die das „Verwalten“, „Kontrollieren“, „Auditieren“ oder „Widerrufen“ des Schlüssels erwähnt.

Verschlüsselung im Ruhezustand (at rest) als ausreichend behandelt. Verschlüsselung im Ruhezustand und während der Übertragung (in transit) sind unabhängig voneinander. RDS mit KMS benötigt trotzdem require_secure_transport=ON und eine Client-CA-Validierung.

Bucket-Richtlinie, die Konten einzeln benennt. Skaliert nicht und geht bei Änderungen in der Organisation kaputt. Verwenden Sie aws:PrincipalOrgID.

Hardcodierte Zugriffsschlüssel an beliebiger Stelle. In User Data, .env-Dateien, CloudFormation-Parametern, Git – immer falsch. Verwenden Sie Instance Profiles, Task Roles, Execution Roles, IRSA/Pod Identity oder Roles Anywhere.

Root-Benutzer für die tägliche Arbeit oder angehängte Richtlinien. Der Root-Benutzer kann nicht durch IAM oder SCPs eingeschränkt werden; das Hinzufügen einer Richtlinie zum Root-Benutzer ist sinnlos. Jede Antwort, die dies tut, ist auf den ersten Blick falsch.

IAM-Benutzer für kontoübergreifenden Zugriff. IAM-Benutzer können nicht kontoübergreifend übernommen werden; erstellen Sie eine Rolle im Zielkonto und lassen Sie den Prinzipal des Quellkontos diese übernehmen.

NLB hinter WAF. WAF kann nicht an NLBs angehängt werden. Schalten Sie dem NLB CloudFront vor, wenn L7-Filterung erforderlich ist.

Fehlende ephemere ausgehende Regel in NACL. Zustandslose NACLs benötigen explizite Regeln für den Rückweg. Fehlende ausgehende Regeln für 1024–65535 führen unbemerkt zum Scheitern aller eingehenden Antworten auf Port 443.

Shield Standard für verwaltetes Eingreifen. Standard ist passiv und ohne SRT-Zugriff; nur Advanced erfüllt die Anforderungen an „proaktives verwaltetes Eingreifen“ oder „Kostenschutz“.

← Anwendungsintegration · Alle Domänen · Management →

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

Amazon durchsuchen →