AWS-Sicherheits- und Betriebs-Checkliste

Account-Fundament

• Separater AWS-Account pro Mandant / Umgebung (AWS Organizations)
• Support-Plan geprüft — Produktions-Workloads laufen nicht auf dem Free-Plan
• Genutzte Regionen sind dokumentiert; ungenutzte Regionen per SCP deaktiviert
• Billing-Alerts und ein Monatsbudget mit Alarmschwellen sind konfiguriert
• Alternative Kontakte (Billing, Betrieb, Sicherheit) sind hinterlegt und erreichbar

Identity & Access Management

• Root-Passwort liegt in einem Vault; Root besitzt keine Access Keys
• MFA erzwungen für Root und für jeden IAM- / Identity-Center-Benutzer
• Passwortrichtlinie aktiviert — Komplexitätsanforderungen und Ablauf (≤ 45 Tage, wo die Richtlinie es verlangt)
• Konsolenzugriff nur für Accounts aktiviert, die ihn benötigen
• Access Keys liegen in einem Vault, niemals im Code oder in Konfigurationsdateien
• Kein Access Key ist älter als 90 Tage — ein Rotationsplan existiert
• Berechtigungen werden über Rollen und Gruppen vergeben, nicht über benutzerbezogene Policies
• Least Privilege mit IAM Access Analyzer verifiziert — keine Wildcard-Admin-Policies
• Account-Wiederherstellungspfad dokumentiert (Sicherheitsfragen / Recovery-Kontakte)

Compute (EC2)

• Mehrschichtiges Design — Datenbanken liegen in privaten Subnetzen / einer separaten VPC, niemals neben der Web-Schicht
• Service Quotas (EC2-Limits) gegen die Wachstumsplanung geprüft
• Instance Profiles (EC2-Rollen) definiert — keine statischen Zugangsdaten auf Instanzen
• Eingehende Security-Group-Regeln auf interne VPC / bekannte Quellen beschränkt
• Ausgehende Regeln eingeschränkt — kein standardmäßiges Allow-All-Egress
• Termination Protection auf Produktionsinstanzen aktiviert
• CloudWatch-Alarme definiert (CPU, Status Checks, Disk, Memory via Agent)
• SSH-Schlüssel liegen in einem Vault; ungenutzte Key Pairs gelöscht
• Launch Templates vor der Nutzung gepatcht und gehärtet
• AMIs stammen aus vertrauenswürdigen Quellen — Blocklist / Allowlist geprüft
• AMI-Freigabeberechtigungen geprüft — keine unbeabsichtigt öffentlichen AMIs
• IMDSv2 auf allen Instanzen erzwungen (verhindert Credential-Diebstahl per SSRF)

Storage & Daten

• EBS-Volumes verschlüsselt (Standardverschlüsselung auf Account-Ebene aktiviert)
• Snapshots verschlüsselt
• Keine öffentlichen Snapshots (EBS oder RDS)
• Backups verschlüsselt; Restore-Verfahren getestet, nicht nur angenommen
• S3-Standardverschlüsselung auf jedem Bucket aktiviert
• S3 Block Public Access auf Account-Ebene aktiviert
• S3-Bucket-Policies geprüft — keine Wildcard-Principals
• EFS-Dateisystem-Policies geprüft; Verschlüsselung während der Übertragung erzwungen
• Versioning / Object Lock auf Buckets, die Backups oder Logs enthalten

Load Balancing (ALB / ELB)

• Ziel-Security-Groups akzeptieren Traffic nur vom ALB
• Löschschutz auf dem ALB aktiviert
• TLS-Terminierung mit einer modernen Security Policy (keine Legacy-Cipher)
• HTTP-→-HTTPS-Redirect auf Port 80 konfiguriert
• Zertifikate in ACM; Ablauf wird mit Alarmen überwacht
• ALB-Access-Logs werden in S3 gespeichert

OS-Härtung

• OS-Härtung durchgeführt — ungenutzte Dienste deaktiviert, Standardports geändert, wo sinnvoll
• Patch-Management-Plan definiert (SSM Patch Manager) und Patches aktuell
• Endpoint Protection / Antivirus installiert, wo die Richtlinie es verlangt
• SSM Agent für den Zugriff genutzt — direktes SSH minimiert oder entfernt

Datenbanken (RDS)

• RDS-Security-Groups privat — kein 0.0.0.0/0, kein Public-Accessibility-Flag
• Speicherverschlüsselung aktiviert
• Löschschutz auf Produktionsinstanzen aktiviert
• Automatischer Backup-Zeitplan definiert; Aufbewahrung entspricht der Richtlinie
• Keine öffentlichen RDS-Snapshots
• Entscheidung zum Minor-Version-Auto-Upgrade dokumentiert; Wartungsfenster festgelegt

Netzwerk & Edge

• DDoS-Schutz vorhanden (Shield; Advanced, wo das Risiko es rechtfertigt)
• CDN vor öffentlichen Workloads im Einsatz (CloudFront)
• WAF mit Managed Rule Sets und Rate Limiting im Einsatz (AWS WAF)
• Cutover- / Failover-Plan existiert — ASG, Multi-AZ-VPC, ELB, getestetes Runbook
• Origin-Security-Groups akzeptieren Traffic nur aus WAF- / CDN-Bereichen
• VPC Flow Logs auf ENIs aktiviert, mit Alarmen nach S3 / CloudWatch geliefert
• Administrativer Zugriff auf EC2 nur über VPN / SSM — niemals offen zum Internet
• Ausgehender (Egress-)Traffic begrenzt und überwacht
• DNS-Einträge inventarisiert — keine verwaisten Einträge, die auf freigegebene IPs zeigen

SecOps & Monitoring

• CloudTrail in allen Regionen aktiviert, Logs in einem separaten, streng abgesicherten S3-Bucket gespeichert
• GuardDuty aktiviert; Findings werden in den On-Call-Kanal geroutet
• DKIM / SPF / DMARC auf SES-Versanddomains konfiguriert
• SIEM-Integration für alle Log-Quellen abgeschlossen (CloudTrail, ALB, WAF, VPC Flow)
• Regelmäßige Penetrationstests geplant und Findings bis zum Abschluss nachverfolgt
• Regelmäßige Infrastruktur-Schwachstellenscans (Inspector oder gleichwertig)
• SAST- / DAST-Gates in der Release-Pipeline definiert
• Fehlerüberwachung mit APM — Anomalie-Alerts bei steigenden 4xx-/5xx-Raten
• Compliance-Regeln als Code hinterlegt (AWS-Config-Regeln / Conformance Packs)
• Secrets in Secrets Manager / Parameter Store — nichts hartkodiert; Rotation aktiviert

Governance

• Inaktive / ungenutzte IAM-Benutzer deaktiviert (Überprüfung alle 90 Tage)
• Ungenutzte öffentliche SSH-Schlüssel gelöscht
• Zugriffsmodell definiert — Entwickler haben keinen Produktions-Konsolenzugriff
• Tagging-Standard durchgesetzt (Owner, Umgebung, Kostenstelle)
• Infrastruktur wird als Code verwaltet — Konsolenänderungen sind die Ausnahme und werden zurückportiert

Verschlüsselung & Schlüsselverwaltung (KMS)

• Kundenverwaltete KMS-Schlüssel (CMKs) statt AWS-verwalteter Schlüssel, wo die Richtlinie es verlangt
• Eindeutige Key Policy pro CMK — Principals eingeschränkt; kms:ViaService-Bedingungen für Servicezugriff
• Separater CMK pro Anwendung und pro Umgebung (Dev / QA / Staging / Prod)
• Separater CMK für den S3-Bucket mit den Sicherheitslogs
• Automatische Schlüsselrotation auf allen CMKs aktiviert
• S3-Server-Side-Encryption nutzt den anwendungsspezifischen CMK (nicht nur SSE-S3)
• CloudTrail-Logdateien mit einem KMS-CMK verschlüsselt
• Lambda-Umgebungsvariablen at rest mit dem anwendungsspezifischen CMK verschlüsselt
• SQS-Queues nutzen Server-Side-Encryption mit dem anwendungsspezifischen CMK
• Redshift / EMR / jeder andere öffentlich stellbare Datenspeicher mit dem anwendungsspezifischen CMK verschlüsselt

Verschlüsselung bei der Übertragung (TLS)

• Öffentliche Endpoints erzwingen mindestens TLS 1.2 — TLS 1.3 bevorzugt
• Perfect Forward Secrecy — ECDHE-Cipher-Suites mit Server Order Preference auf Load Balancern
• Keine verwundbaren Cipher Suites (NULL, DES / 3DES, RC4, statisches RSA) — aktuellste ELB/ALB Security Policy im Einsatz
• SSLv3 und Legacy-Protokolle auf jedem Load Balancer deaktiviert
• Site-to-Site-IPsec-VPN (oder Direct Connect mit MACsec) zwischen On-Premise-Netzen und AWS
• CloudFront Viewer Protocol Policy verlangt HTTPS (Redirect oder HTTPS-only)
• Keine unsicheren Cipher in CloudFront-Distributionen (moderne Security Policy)
• CloudFront-zu-Origin-Verbindungen verschlüsselt — Origin Protocol Policy HTTPS-only

KI-gestützter Betrieb

• CloudWatch Anomaly Detection auf Schlüsselmetriken aktiviert statt ausschließlich statischer Schwellenwerte
• Alert-Stürme werden automatisch zusammengefasst (LLM-Pipeline), bevor sie den On-Call erreichen
• Runbooks für KI-Assistenten abrufbar — dokumentiert, indexiert, aktuell
• KI-Tooling mit Least Privilege beschränkt — standardmäßig read-only, Schreibzugriffe nur nach Freigabe
• Kosten-Anomalieerkennung aktiviert (AWS Cost Anomaly Detection)