Cloud IAM Security: AWS, Azure und GCP richtig absichern

Cloud IAM ist anders als On-Premises-IAM: alles läuft über APIs, Berechtigungen sind granularer, und ein einziger falsch konfigurierter Service-Account kann zur vollständigen Cloud-Kompromittierung führen.

AWS IAM: Least Privilege umsetzen

Der Root Account darf nur für die initiale Account-Einrichtung verwendet werden. Danach: MFA aktivieren, alle Access Keys löschen, und den Root Account niemals für tägliche Arbeit nutzen. In AWS Organizations sollte der Root Account zusätzlich isoliert werden.

Das Prinzip des Least Privilege bedeutet in AWS: keine Wildcard-Actions, kein "Resource": "*", und Conditions wo immer möglich. Eine zu breite Policy erlaubt alle Actions auf alle Ressourcen - eine sichere Policy beschränkt sowohl Actions als auch Ressourcen auf das Notwendige:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-specific-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "eu-central-1"
    }
  }
}

IAM Access Analyzer findet automatisch Ressourcen die öffentlich oder cross-account zugänglich sind - S3-Buckets, SQS-Queues, KMS-Keys. Die Einrichtung und das Abfragen von Findings erfolgt über die AWS CLI:

# Analyzer erstellen
aws accessanalyzer create-analyzer \
  --analyzer-name "company-analyzer" \
  --type ACCOUNT

# Findings abfragen
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:...

Permission Boundaries ermöglichen delegierte Administration: ein Admin kann keine Rechte vergeben, die er selbst nicht hat. Mit put-user-permissions-boundary wird das Maximum festgelegt, das ein Developer an Berechtigungen erhalten kann.

Service Control Policies (SCPs) in AWS Organizations sind Guard Rails für gesamte OUs oder Accounts. Eine typische SCP verhindert EC2-Instanzen und S3-Bucket-Erstellung außerhalb genehmigter Regionen (z. B. eu-central-1 und eu-west-1) mit einer Deny-Condition auf StringNotEquals für aws:RequestedRegion.

AWS: Service Accounts und Rollen

Access Keys gehören nie in EC2-Instanzen, Lambdas oder Container - weder hartgecodiert im Code, noch in .env-Dateien, noch in S3. Der richtige Ansatz ist ein IAM Instance Profile: die Instanz bekommt eine IAM Role zugewiesen und greift automatisch über den Instance Metadata Service (IMDS) auf temporäre Credentials zu. In boto3 werden die Credentials ohne jegliche Konfiguration automatisch verwendet:

import boto3
s3 = boto3.client('s3')  # Automatisch Instance Role-Credentials

# AWS Secrets Manager für Datenbankpasswörter und API-Keys:
client = boto3.client('secretsmanager')
secret = client.get_secret_value(SecretId='prod/db/password')

Für Lambda gilt die Execution Role, für ECS/Fargate die Task Role, für EKS IRSA (IAM Roles for Service Accounts).

IMDSv2 erzwingen: IMDSv1 ist ohne Token und anfällig für SSRF-Angriffe. IMDSv2 ist token-basiert und SSRF-resistent. Das Erzwingen erfolgt per CLI:

aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

Das Hop-Limit auf 1 zu setzen verhindert außerdem Container-Escape-Angriffe, bei denen ein kompromittierter Container die Instance-Credentials stiehlt.

AWS Secrets Manager speichert Datenbankpasswörter und API-Keys verschlüsselt und unterstützt automatische Rotation via Lambda. Secrets werden per secretsmanager create-secret angelegt und per rotate-secret automatisch rotiert - kein Hardcoding im Code nötig.

Azure RBAC und Entra ID

Azure RBAC funktioniert über vier Scope-Ebenen: Management Group, Subscription, Resource Group und einzelne Ressource. Je enger der Scope, desto besser. Owner-Rechte auf Subscription-Level sind fast immer zu breit - korrekt ist z. B. Storage Blob Data Contributor nur auf ein einzelnes Storage Account:

az role assignment create \
  --assignee user@company.com \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/SUB-ID/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/myaccount"

Managed Identities eliminieren Secret Management vollständig: kein Passwort, kein API-Key, kein Zertifikat im Code. System-assigned Identities sind 1:1 an eine Ressource gebunden, User-assigned Identities können von mehreren Ressourcen geteilt werden. Ein App Service bekommt per az webapp identity assign eine Identität, die Key Vault Policy wird auf die principalId gesetzt, und im Python-Code reicht DefaultAzureCredential() - die Managed Identity wird automatisch verwendet.

Azure AD Conditional Access setzt Zero Trust um: jeder Zugriff wird kontextbasiert geprüft. Eine typische Policy für Admin-Zugriff erfordert ein compliant Device, MFA und Hybrid Azure AD Join gleichzeitig - und setzt die Sign-in Frequency auf 1 Stunde, damit gestohlene Sessions zeitlich begrenzt sind.

GCP IAM und Workload Identity

In GCP gilt: Google Accounts für Personen, Service Accounts für Anwendungen. Service Accounts sollen nie manuell verwendet werden (kein Einloggen, kein JSON Key Download). Der sichere Ansatz ist Workload Identity Federation für externe Workloads und die direkte Zuweisung von Rollen mit Conditions für interne Services:

# Service Account erstellen
gcloud iam service-accounts create webapp-sa \
  --description "Web App Service Account" \
  --display-name "webapp-sa"

# Minimal-Permissions mit Resource-Condition
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:webapp-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/storage.objectViewer" \
  --condition "title=bucket-condition,expression=resource.name.startsWith('projects/_/buckets/my-bucket')"

# Service Account Key-Erstellung org-weit deaktivieren
gcloud org-policies set-policy \
  --project=PROJECT_ID constraints/iam.disableServiceAccountKeyCreation \
  --value=ENFORCE

Workload Identity Federation ermöglicht GitHub Actions, Kubernetes und andere externe Services den Zugriff auf GCP ohne JSON Keys. Das Prinzip: ein OpenID Connect Provider (z. B. GitHub) wird bei GCP registriert, GitHub Actions bekommt id-token: write-Permission, und der google-github-actions/auth-Action tauscht den OIDC-Token gegen kurzlebige GCP-Credentials.

Organization Policies sind die GCP-Entsprechung der AWS SCPs: Constraints für die gesamte Organisation, z. B. OS Login-Pflicht für alle VMs (constraints/compute.requireOsLogin) oder die Deaktivierung von Service Account Keys org-weit.

CSPM: Cloud Security Posture Management

CSPM-Tools erkennen automatisch Fehlkonfigurationen in Cloud-Umgebungen. Typische Prüfpunkte sind öffentlich zugängliche S3-Buckets, fehlende MFA-Enforcement für Root Accounts, ungenutzte IAM-Rollen und Access Keys, unverschlüsselte Datenbanken und Speicher, deaktiviertes Logging (CloudTrail, Activity Log) sowie zu offene Security Groups.

AWS Security Hub ist in AWS eingebaut und aggregiert Findings aus GuardDuty, Inspector, Macie und Config. Der CIS AWS Benchmark wird automatisch geprüft. Kosten: 0,001 USD pro Finding.

Microsoft Defender for Cloud ist das Azure-Äquivalent mit einem Secure Score von 0-100 (Ziel: über 80) und konkreten Handlungsempfehlungen mit Fix-Anleitungen.

Wiz und Orca Security sind kommerzielle Multi-Cloud-Lösungen (AWS, Azure, GCP, Kubernetes) mit Attack Path Analysis - sie zeigen, wie weit ein Angreifer ausgehend von einer Fehlkonfiguration in die Infrastruktur eindringen könnte.

Checkov mit Terraform scannt Infrastructure-as-Code präventiv vor dem Deployment und findet Fehlkonfigurationen bevor sie in die Produktion gelangen - die DevSecOps-Integration im CI/CD ist die effektivste Stelle, um CSPM-Findings zu verhindern statt zu beheben.