Cloud IAM (Identity and Access Management in der Cloud)

Cloud IAM ist die Verwaltung von Identitäten, Zugriffsrechten und Berechtigungen in Cloud-Umgebungen. Aufgrund der Komplexität moderner Cloud-Setups und des “Infrastructure as Code”-Paradigmas entstehen hier häufig überprivilegierte Rollen und Access Keys - die häufigste Ursache schwerer Cloud-Sicherheitsvorfälle.

AWS IAM - Best Practices und häufige Fehler

AWS IAM - Grundprinzipien:

1. Root-Account sofort absichern:
   □ MFA aktivieren (sofort!)
   □ Keine Access Keys für Root (Delete all root access keys!)
   □ Root nur für initiales Setup und Notfall
   □ Alert bei Root-Login (CloudWatch Event Rule)

2. Least Privilege für alle IAM-Entitäten:
   Falsch (überprivilegiert):
   {
     "Effect": "Allow",
     "Action": "*",
     "Resource": "*"
   }
   → "Administrator Access" für Service = sofortiger Kompromittierungssyuper-Blast-Radius!

   Richtig (minimal berechtigt):
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject"
         ],
         "Resource": "arn:aws:s3:::my-specific-bucket/*"
       }
     ]
   }

3. IAM Access Analyzer nutzen:
   → Findet: externe Zugriffe auf Ressourcen (andere AWS-Accounts, öffentlich)
   → Unused Access: welche Berechtigungen werden nie genutzt?
   → Policy Validation: JSON-Policy auf Fehler prüfen

   aws accessanalyzer create-analyzer \
     --analyzer-name my-analyzer \
     --type ACCOUNT_UNUSED_ACCESS

4. Keine langlebigen Access Keys für EC2/Lambda:
   Falsch: Access Key + Secret Key in Code oder Environment Variable
   → Keys kompromittiert → Vollzugriff bis manuell gelöscht!

   Richtig: IAM Roles für EC2/Lambda/ECS
   → Temporäre Credentials via Instance Metadata Service
   → Automatische Rotation, kein statischer Key!

   # IAM-Rolle für EC2 erstellen (Terraform):
   resource "aws_iam_role" "ec2_role" {
     name = "ec2-app-role"
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Action    = "sts:AssumeRole"
         Effect    = "Allow"
         Principal = { Service = "ec2.amazonaws.com" }
       }]
     })
   }

   resource "aws_iam_role_policy" "ec2_policy" {
     role = aws_iam_role.ec2_role.id
     policy = jsonencode({
       Statement = [{
         Action   = ["s3:GetObject"]
         Effect   = "Allow"
         Resource = "arn:aws:s3:::my-bucket/*"
       }]
     })
   }

5. SCPs (Service Control Policies) für Organizations:
   → Guardrails für alle Accounts in AWS Organization
   → Beispiel: kein Root-Account-Nutzung, kein Deaktivieren von CloudTrail

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "DenyDisablingCloudTrail",
         "Effect": "Deny",
         "Action": [
           "cloudtrail:StopLogging",
           "cloudtrail:DeleteTrail"
         ],
         "Resource": "*"
       }
     ]
   }

Azure RBAC und Managed Identities

Azure RBAC (Role-Based Access Control):

Eingebaute Rollen:
  Owner:       Vollzugriff + Rollenverwaltung
  Contributor: Ressourcen verwalten, keine Rollen-Delegation
  Reader:      Nur lesen
  + 100+ spezifische Rollen (Storage Blob Data Contributor, etc.)

Least Privilege in Azure:
  Falsch: Contributor auf Subscription-Ebene für Service Principal
  Richtig: Spezifische Rolle auf spezifische Resource Group

  # Azure CLI: minimale Berechtigung
  az role assignment create \
    --assignee "service-principal-id" \
    --role "Storage Blob Data Reader" \
    --scope "/subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Storage/storageAccounts/STORAGE_NAME"

Azure Managed Identities (analog zu AWS IAM Roles für EC2):
  System-assigned MI:
  → Automatisch mit Azure-Ressource (VM, App Service, etc.) verknüpft
  → Lifecycle = Ressource-Lifecycle (gelöscht wenn VM gelöscht)
  → Keine Credentials, kein Passwort

  User-assigned MI:
  → Eigenständige Ressource, mehreren Diensten zuweisbar
  → Zentralere Verwaltung

  # VM mit Managed Identity in Azure CLI:
  az vm identity assign \
    --name myVM \
    --resource-group myRG

  # Berechtigung für MI:
  az role assignment create \
    --assignee $(az vm show -g myRG -n myVM --query identity.principalId -o tsv) \
    --role "Key Vault Secrets User" \
    --scope /subscriptions/SUB_ID/.../vaults/VAULT_NAME

Azure Privileged Identity Management (PIM):
  → Just-in-Time Admin-Rechte (wie AWS STS assume-role)
  → Anforderung + Genehmigung für privilegierte Rollen
  → Maximale Aktivierungsdauer (z.B. 8 Stunden)
  → Alert + Audit bei Aktivierung

GCP IAM:
  → Service Accounts = AWS IAM Roles + Azure Managed Identities
  → Workload Identity Federation: externe Identitäten (GitHub Actions, K8s) ohne Keys
  → IAM Recommender: "Diese Berechtigung wird seit 90 Tagen nicht genutzt"
  → Access Transparency: was tut Google-Personal in eurem Account?

CIEM - Cloud Infrastructure Entitlement Management

CIEM (Cloud Infrastructure Entitlement Management):

Was ist CIEM?
  → Spezialisiertes Tool für Cloud-IAM-Analyse
  → Analysiert: wer darf was in der Cloud (effektive Berechtigungen)
  → Findet: überprivilegierte Rollen, unused permissions
  → Empfiehlt: minimale Policies auf Basis tatsächlicher Nutzung

Warum IAM Access Analyzer allein nicht reicht:
  → Access Analyzer: findet externe Zugriffe, unused access
  → CIEM: Tiefere Analyse, cross-account, laterale Bewegungspfade
  → "Wenn diese IAM-Rolle kompromittiert ist, was kann der Angreifer tun?"

CIEM-Tools:
  AWS IAM Access Analyzer (kostenlos in AWS):
    aws accessanalyzer list-findings \
      --analyzer-name my-analyzer

  Ermetic / Sonrai Security (kommerziell):
    → Graph-basierte Analyse von IAM-Beziehungen
    → "Weg von dieser kompromittierten EC2 zur Datenbank?"

  Wiz CIEM (Teil von Wiz Cloud Security):
    → Integriert mit gesamtem Cloud Security Posture
    → Angriffspfad: "Kompromittierte Instanz → IAM-Rolle →
      S3 Buckets mit PII-Daten"

IAM-Härtungs-Checkliste (AWS):
  □ Root-Account: MFA aktiv, keine Access Keys
  □ Alle IAM-User: MFA aktiviert (besonders Admins!)
  □ IAM Access Analyzer aktiv in jeder Region
  □ AWS Config: iam-user-no-policies-check aktiv
    (Policies NUR über Gruppen/Rollen, nicht direkt an User!)
  □ AWS Config: access-keys-rotated
    (Alert wenn Access Key > 90 Tage alt)
  □ Keine Wildcard-Permissions (*:* ) außer für absoluten Notfall
  □ IAM Password Policy: min. 14 Zeichen, MFA
  □ Quartalsmäßige Access Reviews via IAM Access Advisor