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

AWS IAM Best Practices:

Root Account absichern:
  → Root Account: NUR für initiale Account-Einrichtung
  → Danach: MFA aktivieren + Access Keys löschen
  → Root: nie für tägliche Arbeit verwenden!
  → AWS Organizations: Root-Account isolieren

Principle of Least Privilege:
  # FALSCH: zu breite Policy
  {
    "Effect": "Allow",
    "Action": "*",        # Alles erlaubt!
    "Resource": "*"
  }
  
  # RICHTIG: minimale Rechte
  {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::my-specific-bucket/*",
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "eu-central-1"  # Nur Frankfurt!
      }
    }
  }

IAM Access Analyzer:
  # Findet Ressourcen die öffentlich oder cross-account zugänglich sind
  aws accessanalyzer create-analyzer \
    --analyzer-name "company-analyzer" \
    --type ACCOUNT
  
  # Reports: welche S3-Buckets, SQS-Queues, KMS-Keys sind zu offen?
  aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:...

Permission Boundaries:
  # Delegierte Administration: was darf ein Admin maximal vergeben?
  # Admin kann keine Rechte vergeben die er selbst nicht hat!
  aws iam create-policy --policy-name DevTeamBoundary \
    --policy-document file://dev-boundary.json
  
  aws iam put-user-permissions-boundary \
    --user-name developer1 \
    --permissions-boundary arn:aws:iam::ACCOUNT:policy/DevTeamBoundary

Service Control Policies (AWS Organizations):
  # SCP: Guard Rails für gesamte OU/Account
  # Verhindert bestimmte Aktionen ORG-weit
  {
    "Effect": "Deny",
    "Action": [
      "ec2:*",              # Kein EC2 in nicht-genehmigten Regionen
      "s3:CreateBucket"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
      }
    }
  }

AWS: Service Accounts und Rollen

EC2 Instance Roles vs. Access Keys:

FALSCH: Access Keys in EC2-Instanz:
  → Hartgecodiert in Code → Gefahr wenn Code geleakt
  → In .env-Datei → Gefahr wenn Server kompromittiert
  → In S3 gespeichert → Gefahr wenn Bucket offen
  NIEMALS Access Keys in EC2/Lambda/Container!

RICHTIG: IAM Instance Profile:
  # EC2-Instanz: IAM Role zuweisen
  # Instanz greift automatisch auf Credentials zu (IMDS)
  # kein Hardcoding von Keys nötig!
  
  # In Code:
  import boto3
  s3 = boto3.client('s3')   # Automatisch Instance Role-Credentials!
  
  # Lambda: automatisch Execution Role
  # ECS/Fargate: Task Role
  # Kubernetes (EKS): IRSA (IAM Roles for Service Accounts)

IMDS v2 erzwingen (Security!):
  # IMDSv1: ohne Token (anfällig für SSRF!)
  # IMDSv2: Token-basiert (SSRF-resistent)
  
  aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required           # IMDSv2 erzwingen!
    --http-put-response-hop-limit 1  # Hop-Limit: kein Container-Escape!

AWS Secrets Manager:
  # Datenbankpasswörter, API-Keys sicher speichern:
  aws secretsmanager create-secret \
    --name "prod/db/password" \
    --secret-string "$(cat /dev/urandom | tr -dc A-Za-z0-9 | head -c32)"
  
  # Automatische Rotation:
  aws secretsmanager rotate-secret \
    --secret-id "prod/db/password" \
    --rotation-lambda-arn arn:aws:lambda:...
  
  # In Code (kein Hardcoding!):
  import boto3
  client = boto3.client('secretsmanager')
  secret = client.get_secret_value(SecretId='prod/db/password')

Azure RBAC und Entra ID

Azure Identity Best Practices:

Azure RBAC Grundprinzipien:
  → Scope: Management Group > Subscription > Resource Group > Resource
  → Je enger der Scope, desto besser!
  → Custom Roles wenn Built-in zu breit
  
  # FALSCH: Owner auf Subscription-Level
  # RICHTIG: Contributor nur auf spezifische Resource Group
  
  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 (kein Secret-Management nötig!):
  # System-assigned: 1:1 an Ressource gebunden
  # User-assigned: mehrere Ressourcen können teilen
  
  # Beispiel: App Service greift auf Key Vault zu:
  az webapp identity assign --name myapp --resource-group myrg
  
  # Key Vault Policy:
  az keyvault set-policy \
    --name mykeyvault \
    --object-id $(az webapp identity show --name myapp --query principalId -o tsv) \
    --secret-permissions get list
  
  # In Code: kein Passwort/Key nötig!
  from azure.identity import DefaultAzureCredential
  from azure.keyvault.secrets import SecretClient
  
  credential = DefaultAzureCredential()  # Automatisch Managed Identity!
  client = SecretClient(vault_url="https://mykeyvault.vault.azure.net", credential=credential)

Azure AD Conditional Access:
  # Zero-Trust: jeder Zugriff wird kontextbasiert geprüft
  
  Beispiel-Policy: "Admin-Zugriff nur von compliant Geräten":
  → Users: alle Global Admins
  → Apps: alle Cloud-Apps
  → Conditions: Device-Plattformen = alle
  → Grant: Require compliant device
              + Require MFA
              + Require Hybrid Azure AD joined
  → Session: Sign-in Frequency = 1h

GCP IAM und Workload Identity

Google Cloud IAM:

Grundprinzipien:
  → Google-Accounts für Personen
  → Service Accounts für Anwendungen (nie manuell verwendet!)
  → Workload Identity Federation: externe Identitäten ohne Keys

Service Account Best Practices:
  # FALSCH: Service Account JSON Key herunterladen und speichern
  # RICHTIG: Workload Identity (kein Key nötig!)

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

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

Workload Identity Federation (OpenID Connect):
  # Externer Service (GitHub Actions, Kubernetes) ohne Key!
  # GitHub Actions → GCP-Zugriff:
  
  # GitHub OIDC Provider registrieren:
  gcloud iam workload-identity-pools create "github-pool" \
    --location="global"
  
  gcloud iam workload-identity-pools providers create-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --issuer-uri="https://token.actions.githubusercontent.com" \
    --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"
  
  # In GitHub Action:
  # id-token: write permission -> kein GCP-Key nötig!
  - uses: google-github-actions/auth@v2
    with:
      workload_identity_provider: "projects/123/locations/global/workloadIdentityPools/github-pool/providers/github-provider"
      service_account: "webapp-sa@PROJECT.iam.gserviceaccount.com"

Organization Policies:
  # Constraints für gesamte GCP-Organisation
  gcloud org-policies set-policy \
    --project=PROJECT_ID constraints/compute.requireOsLogin \
    --value=ENFORCE  # OS Login Pflicht für alle VMs

  gcloud org-policies set-policy \
    --project=PROJECT_ID constraints/iam.disableServiceAccountKeyCreation \
    --value=ENFORCE  # Keine Service Account Keys!

CSPM: Cloud Security Posture Management

Automatische Fehlkonfigurations-Erkennung:

Was CSPM prüft:
  → S3-Buckets öffentlich zugänglich?
  → MFA-Enforcement für Root Account?
  → Nicht genutzte IAM-Rollen + Access Keys
  → Unverschlüsselte Datenbanken/Speicher
  → Logging (CloudTrail, Activity Log) aktiv?
  → Netzwerk-Konfiguration: Security Groups zu offen?

CSPM-Tools:
  AWS Security Hub:
  → Eingebaut in AWS, kostenlos (Findings: $0,001/Eintrag)
  → Aggregiert: GuardDuty, Inspector, Macie, Config
  → CIS AWS Benchmark automatisch geprüft
  
  Microsoft Defender for Cloud:
  → Eingebaut in Azure
  → Secure Score: 0-100 (Ziel: >80)
  → Recommendations mit konkreten Fixes
  
  Wiz / Orca Security (kommerziell):
  → Multi-Cloud (AWS + Azure + GCP + K8s)
  → Attack Path Analysis: wie weit kommt ein Angreifer?
  → Sehr maechtig, aber teuer

  Checkov + Terraform (praeventiv):
  → IaC-Scanning bevor Deployment
  → Fehlkonfigurationen vor dem Deploy finden
  → S.o.: DevSecOps-Integration