AWS Security — Referenz.

IAM — Modell und Fallen

• Policy-Evaluation-Logik. Explicit Deny > Org-SCP > Resource-Policy > Identity-Policy > Permissions-Boundary. Ein einziges Explicit Deny irgendwo tötet die Action. Default = Implicit Deny.
• Die fünf zu-breiten Muster. "Action":"*", "Resource":"*", "Principal":"*", "Condition":{} leer, "Effect":"Allow" auf Root. Jede Kombination aus zweien = High-Impact-Befund.
• iam:PassRole-Missbrauch. Principal kann eine Role an einen Service übergeben, den er selbst nicht assumieren kann. iam:PassRole auf * = Pfad zu jeder Service-Role.
• Confused Deputy. Trusted-Third-Party (Lambda, GitHub OIDC) kann getrickst werden, deine Role im Angreifer-Auftrag zu nutzen. Verteidigung: aws:SourceArn + aws:SourceAccount-Conditions in Trust-Policies.
• Wildcard in Resource-ARN. arn:aws:s3:::data-* matcht künftige Buckets namens data-attacker — Bucket-Namen registrieren, impliziten Zugriff erhalten.

Cross-Account-Boundaries

• Trust-Relationship-Discovery. Jeder Role AssumeRolePolicyDocument nach Principal: {"AWS": "arn:aws:iam::OTHER_ACCOUNT:root"}-Einträgen durchgehen. Jeder solche Eintrag ist External-Account-Access-Vector.
• AssumeRole-Chain. AWS unterstützt Role-Chaining (assume A, dann mit A B assumieren). Jeder Hop verkürzt Max-Session-Duration um eine Stunde. aws sts decode-authorization-message für Chain-Failure-Debug.
• SCP an OU-Grenze. SCPs gelten für alle Accounts in der OU, beschränken aber nur Identity- und Resource-basierte Policies — sie gewähren nicht. Ein Child-Account verliert Zugriff wenn Parent-SCP denyed.
• Org-weiter Blast-Radius. Einzige zu vertrauensvolle Role in einem Management-Account = gesamte Org-Kompromittierung via Organizations-API.

Höchster-Hebel-Misconfigs — Triage-Sequenz

1. Öffentliche S3-Buckets. aws s3api list-buckets, dann aws s3api get-bucket-acl + get-bucket-policy pro Bucket. Block-Public-Access auf Account-Ebene sollte AN sein.
2. Veraltete IAM-User mit Access-Keys. aws iam list-users + list-access-keys + get-access-key-last-used. Keys ungenutzt >90 Tage = sofort revoken.
3. EC2-IMDSv1 noch erlaubt. aws ec2 describe-instances + HttpTokens prüfen. optional = SSRF kann Role-Creds greifen. required erzwingen.
4. RDS-Snapshots öffentlich. aws rds describe-db-snapshots --include-public. Öffentliches Snapshot = gesamte DB an jeden in AWS geleakt.
5. Lambda-Function-URLs mit Auth NONE. aws lambda list-function-url-configs. AuthType: NONE = unauthenticated Invoke.
6. SigV4-unsignierte Services. Jedes API-Gateway oder Lambda-URL ohne Auth exponiert.
7. KMS-Key-Policy zu permissiv. "Principal":"*" auf KMS-Key = jeder in deiner Org (oder bei Cross-Account-Allow, überall) kann damit entschlüsseln.
8. CloudTrail nicht Multi-Region oder nicht aktiv. aws cloudtrail describe-trails. Single-Region-Trail = blind auf andere Regionen.

Post-Compromise-Pivots auf AWS

• EC2-Instance-Profile-Cred-Diebstahl. SSRF → IMDS → /latest/meta-data/iam/security-credentials/<role> → temporäre Creds.
• Lambda-Env-Var-Leak. Viele Lambdas speichern Secrets in Env-Vars. aws lambda get-function-configuration --function-name X.
• Secrets-Manager-Scan. aws secretsmanager list-secrets --max-results 100, dann get-secret-value pro Secret, das deine Role lesen kann.
• SSM-Parameter-Store. Gleiches Muster. aws ssm describe-parameters + get-parameters --names X.