IAM (Identity and Access Management)

Einfach erklärt

IAM verwaltet, welche Identitäten auf welche Ressourcen unter welchen Bedingungen zugreifen dürfen.

IAM-Komponenten:
├── Identity: Wer bist du? (User, Service Account)
├── Authentication: Beweise es! (Passwort, MFA, SSO)
├── Authorization: Was darfst du? (RBAC, ABAC)
└── Audit: Was hast du getan? (Logging)

Technischer Deep Dive

IAM Policy Beispiel

{
  "Version": "policy-version",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["storage:GetObject"],
      "Resource": "resource-identifier"
    }
  ]
}

Best Practices

Prinzip	Umsetzung
Least Privilege	Rechte auf den notwendigen Umfang begrenzen
MFA	Besonders für privilegierte und riskante Zugriffe nutzen
Rotation	Credentials nach Risiko und Vorgaben erneuern
Audit	Kritische Zugriffe nachvollziehbar protokollieren

Menschliche und maschinelle Identitäten

IAM verwaltet längst nicht mehr nur Benutzerkonten. In modernen Systemen überwiegen maschinelle Identitäten oft deutlich:

Identitätstyp	Beispiele	Besonderheiten
Mensch	Mitarbeitende, Admins, externe Partner	MFA, SSO, Lifecycle bei Ein-/Austritt
Service Account	Microservices, CI/CD-Pipelines, Cronjobs	Keine interaktive Anmeldung, Rotation nötig
Workload Identity	Container, Cloud-Funktionen	Kurzlebige Tokens statt Langzeit-Keys
KI-Agent	LLM-basierte Agenten mit Tool-Zugriff	Eigene, eng begrenzte Berechtigungen

Der Trend geht weg von Langzeit-Credentials hin zu kurzlebigen, automatisch ausgestellten Tokens – etwa über OIDC-Federation, bei der sich eine Pipeline direkt beim Cloud-Anbieter ausweist, ohne dass ein statischer Key gespeichert wird.

IAM für KI- und LLM-Systeme

KI-Anwendungen stellen klassische IAM-Konzepte vor neue Fragen:

• LLM-API-Zugriffe steuern: Wer im Unternehmen darf welche Modelle mit welchem Budget aufrufen? Scoped API-Keys pro Team, Projekt oder Umgebung schaffen Nachvollziehbarkeit und begrenzen Kosten bei Missbrauch.
• Agenten brauchen eigene Identitäten: Ein KI-Agent, der Tools aufruft oder Daten liest, sollte nie mit den Rechten seines Nutzers oder gar eines Admin-Accounts agieren. Stattdessen: eigene Maschinenidentität mit minimalen, klar definierten Rechten.
• Least Privilege gegen Prompt Injection: Wird ein Agent durch manipulierte Eingaben zu unerwünschten Aktionen verleitet, begrenzen enge Berechtigungen den Schaden – die Autorisierungsschicht wird zur letzten Verteidigungslinie.
• RAG und Datenzugriff: Wenn ein Retrieval-System Dokumente in den Modellkontext lädt, müssen die Zugriffsrechte des anfragenden Nutzers durchgesetzt werden – sonst leakt das Modell Inhalte, die der Nutzer nie direkt sehen dürfte.

Typische Stolperfallen

Fehler	Folge	Besser
Geteilte Accounts	Keine Zuordnung von Aktionen zu Personen	Individuelle Identitäten, auch für Maschinen
Rechte wachsen nur	”Permission Creep” über Jahre	Regelmäßige Access Reviews, Rechte entziehen
Offboarding vergessen	Ex-Mitarbeitende behalten Zugriff	Automatisierter Lifecycle über zentrales Verzeichnis
Admin-Rechte im Alltag	Großer Schaden bei Kompromittierung	Just-in-Time-Elevation statt Dauer-Admin
Ein API-Key für alle KI-Dienste	Kein Audit, keine Kostenkontrolle	Keys pro Team/Anwendung mit Limits

Abgrenzung zu verwandten Begriffen

• RBAC/ABAC sind Autorisierungsmodelle innerhalb von IAM – sie beantworten das “Was darfst du?”.
• OAuth und OIDC sind Protokolle für delegierte Autorisierung und Authentifizierung, die IAM-Systeme technisch umsetzen.
• PAM (Privileged Access Management) ist die Spezialdisziplin für hochprivilegierte Konten mit zusätzlichen Kontrollen wie Session-Recording.