AWS-Sicherheit: IAM, VPCs & geteilte Verantwortung

Das Modell der geteilten Verantwortung

AWS-Sicherheit basiert auf einem grundlegenden Prinzip, das viele Organisationen stolpern lässt: AWS ist für die Sicherheit der Cloud verantwortlich; Sie sind für die Sicherheit in der Cloud verantwortlich. AWS sichert die physischen Rechenzentren, den Hypervisor, die verwaltete Dienstinfrastruktur und die zugrunde liegende Netzwerkstruktur. Sie sind für alles verantwortlich, was Sie darauf aufbauen: Ihre Daten, Ihre Anwendungen, Ihre IAM-Konfigurationen, Ihre Security-Group-Regeln, Ihre Verschlüsselungsentscheidungen und Ihre Protokollierung.

Diese Grenze verschiebt sich je nach Diensttyp:

• IaaS (EC2): Sie verwalten das Betriebssystem, die Runtime, die Anwendung und die Daten
• PaaS (RDS, Lambda): AWS verwaltet das Betriebssystem und die Runtime; Sie verwalten die Anwendung und die Daten
• SaaS (Amazon WorkMail): AWS verwaltet fast alles; Sie verwalten den Zugriff und die Daten

Die Fehlkonfiguration Ihrer Seite der Grenze – ein öffentlich gelassener S3-Bucket, eine überprivilegierte IAM-Rolle, eine für 0.0.0.0/0 offene Security Group – liegt in Ihrer Verantwortung, unabhängig davon, wie sicher die Infrastruktur von AWS ist.

IAM: Die kritischste AWS-Sicherheitskontrolle

AWS Identity and Access Management (IAM) steuert, wer was in jedem AWS-Dienst tun kann. IAM richtig zu konfigurieren ist das Wirksamste, was Sie für die AWS-Sicherheit tun können.

Schutz des Root-Kontos

Das AWS-Root-Konto hat uneingeschränkten Zugriff auf alles und kann nicht mit Richtlinien eingeschränkt werden. Schützen Sie es:

• Aktivieren Sie Hardware-MFA auf dem Root-Konto unmittelbar nach der Kontoerstellung
• Erstellen Sie niemals Zugriffsschlüssel für Root – niemals
• Verwenden Sie Root nur für Aufgaben, die es ausdrücklich erfordern (Abrechnung, Kontoeinstellungen, Änderungen des Support-Plans)
• Richten Sie Abrechnungsbenachrichtigungen über CloudWatch ein, damit Sie unerwartete Nutzung bemerken

IAM-Benutzer, -Rollen und -Richtlinien

Für menschliche Benutzer bevorzugen Sie IAM Identity Center (früher SSO) mit föderativen Identitäten aus Ihrem Unternehmensverzeichnis gegenüber einzelnen IAM-Benutzern. Für maschinelle Identitäten (EC2-Instanzen, Lambda-Funktionen, ECS-Tasks) verwenden Sie immer IAM-Rollen anstatt hartkodierten Zugriffsschlüsseln – Rollen bieten temporäre Anmeldedaten, die sich automatisch rotieren.

Schreiben Sie Richtlinien nach dem Prinzip der geringsten Privilegien:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*"
  }]
}

Verwenden Sie IAM Access Analyzer, um überprivilegierte Richtlinien und externen Zugriff auf Ihre Ressourcen zu identifizieren. Führen Sie regelmäßig Anmeldedatenberichte aus (aws iam generate-credential-report), um ungenutzte Zugriffsschlüssel und Benutzer zu überprüfen.

Service Control Policies (SCPs)

In AWS Organizations fungieren SCPs als maximale Berechtigungsgrenzen für ganze Konten oder OUs. Verwenden Sie sie, um organisationsweite Leitplanken durchzusetzen:

• Verbieten Sie das Deaktivieren von CloudTrail
• Schränken Sie ein, welche Regionen verwendet werden können
• Verhindern Sie das Erstellen öffentlicher S3-Buckets
• Fordern Sie MFA für sensible Operationen

VPCs: Netzwerkisolation in AWS

Eine Virtual Private Cloud (VPC) ist Ihr privates Netzwerk innerhalb von AWS. Gestalten Sie es von Anfang an mit Sicherheit im Hinterkopf:

Subnetz-Design

Trennen Sie Ressourcen in öffentliche, private und Daten-Subnetzebenen:

• Öffentliche Subnetze: nur Load Balancer und NAT-Gateways – sonst nichts
• Private Subnetze: Anwendungsserver, Lambda-Funktionen, ECS-Tasks – kein direkter Internetzugang
• Daten-Subnetze: RDS-Datenbanken, ElastiCache und andere Datenspeicher – kein Internetpfad whatsoever

Ressourcen in privaten Subnetzen erreichen das Internet über NAT-Gateway (nur ausgehend). Eingehender Internetverkehr sollte nur über einen Load Balancer im öffentlichen Subnetz eingehen.

Security Groups vs. NACLs

Security Groups sind zustandsbehaftete Firewalls, die an einzelne Ressourcen angehängt werden – wenn Sie eingehenden Port 443 erlauben, wird der Rückkehrverkehr automatisch erlaubt. Wenden Sie das Prinzip der geringsten Privilegien an: sourced aus spezifischen Security-Group-IDs anstatt IP-Bereichen, wo möglich.

Network ACLs sind zustandslos und gelten auf Subnetz-Ebene – sowohl eingehende als auch ausgehende Regeln müssen definiert werden. Verwenden Sie NACLs für breite Subnetz-Ebene-Kontrollen und Security Groups für ressourcenspezifische Granularität.

VPC Flow Logs

Aktivieren Sie VPC Flow Logs für alle Subnetze und senden Sie diese an CloudWatch Logs oder S3. Flow Logs erfassen Quell-/Ziel-IPs, Ports, Protokoll und Accept/Reject-Entscheidungen – unerlässlich für Forensik und Anomalieerkennung.

Protokollierung und Überwachung: Der Sicherheitssichtbarkeits-Stack

• CloudTrail: zeichnet jeden AWS-API-Aufruf auf – wer was wann und von wo getan hat. Aktivieren Sie es in allen Regionen, aktivieren Sie die Protokolldateivalidierung und senden Sie an einen S3-Bucket mit einem SCP, das das Löschen verhindert. Dies ist nicht verhandelbar.
• AWS Config: zeichnet Konfigurationsänderungen an AWS-Ressourcen auf und bewertet sie anhand von Compliance-Regeln
• Amazon GuardDuty: ML-gestützte Bedrohungserkennung, die CloudTrail, VPC Flow Logs und DNS-Protokolle analysiert, um Anmeldedaten-Kompromittierung, Instanz-Kompromittierung und Aufklärung zu erkennen
• AWS Security Hub: aggregiert Befunde von GuardDuty, Config, Inspector und Drittanbieter-Tools in einer einzigen Konsole mit CIS-Benchmark-Bewertung

S3-Sicherheit

Öffentlich zugängliche S3-Buckets bleiben eine der häufigsten Ursachen für Cloud-Datenpannen. Erzwingen Sie auf Kontoebene:

• Aktivieren Sie S3 Block Public Access auf Kontoebene – dies überschreibt alle Bucket-Ebene-Einstellungen
• Aktivieren Sie Standard-Verschlüsselung (SSE-S3 oder SSE-KMS) für alle Buckets
• Aktivieren Sie S3 Object Lock für Buckets, die Audit-Protokolle enthalten, um das Löschen zu verhindern
• Verwenden Sie Bucket-Richtlinien, um nur HTTPS durchzusetzen: aws:SecureTransport: false → Deny
• Prüfen Sie Bucket-Berechtigungen regelmäßig mit Macie zur Entdeckung sensibler Daten