Identity and Access Management (IAM): Definition und Beispiele

Was ist Identity and Access Management (IAM)?

Identity and Access Management (IAM) umfasst die Richtlinien, Prozesse und Werkzeuge, die festlegen, wer sich an einem System anmelden darf und was jede Identität danach tun darf. Eine Identität kann eine Person, ein Dienst oder ein Gerät sein. IAM beantwortet drei Fragen: Wer bist du, was darfst du, und was hast du getan?

So funktioniert IAM

Jedes IAM-Setup kombiniert drei Säulen. Sie greifen nacheinander: Eine Anfrage wird authentifiziert, dann autorisiert, und das Ergebnis wird protokolliert.

Single Sign-On setzt darauf auf: Eine Login-Sitzung schaltet mehrere Anwendungen frei, meist über ein Protokoll wie SAML oder OpenID Connect. So lässt sich der Zugang an einer Stelle entziehen, wenn jemand das Unternehmen verlässt.

Zugriffskontrollmodelle

• RBAC (rollenbasiert): Berechtigungen hängen an Rollen wie "Viewer" oder "Billing-Manager", Personen erhalten Rollen. Das gängigste Modell und am leichtesten zu prüfen.
• ABAC (attributbasiert): Eine Regel vergleicht Attribute von Nutzer, Ressource und Kontext, etwa "erlauben, wenn user.department gleich resource.department". Feiner steuerbar, aber schwerer zu auditieren.
• ACL (Access Control List): Jede Ressource trägt ihre eigene Liste, wer was darf. Passt für Dateien und kleine Systeme, wird im großen Maßstab unhandlich.

Beispiel: Ein CI-Job, der ein Container-Image pusht

Eine Pipeline soll ein Image in ein einziges Registry-Repository pushen. Ein schwaches Setup gibt ihr einen gemeinsamen Admin-Schlüssel, der dauerhaft in einer Build-Variable liegt. Ein sauberes IAM-Setup gibt dem Job eine eigene Dienst-Identität mit einer Rolle, die nur "in dieses Repository pushen" erlaubt, stellt Zugangsdaten aus, die nach dem Job ablaufen, und protokolliert jeden Aufruf. Wird die Pipeline abgeschaltet, wird die Identität gelöscht und sonst ändert sich nichts.

Häufige IAM-Fehler

• Überprivilegierte Konten. Admin-Rechte "nur kurz" vergeben und nie wieder entzogen.
• Geteilte Zugangsdaten. Mehrere Personen oder Dienste nutzen ein Login, sodass sich kein Logeintrag jemandem zuordnen lässt.
• Langlebige Secrets im Code. Access Keys im Git-Repository oder in Tickets. Besser sind kurzlebige Tokens.
• Verwaiste Konten. Ehemalige Mitarbeitende, alte Dienstleister und abgeschaltete Dienste haben weiter Zugriff.
• Keine Mehrfaktor-Authentifizierung für Admin-Konten. Ein gestohlenes Passwort wird zum vollständigen Einbruch.
• Keine Zugriffsprüfungen. Berechtigungen sammeln sich über Jahre an, weil niemand sie kontrolliert.

IAM, API-Sicherheit und Performance-Tests

IAM wird an der API durchgesetzt: Jeder Aufruf trägt ein Token oder einen Schlüssel, den Ihr Gateway gegen Rollen und Richtlinien prüft. Das ist das Thema API-Sicherheit, und deshalb muss ein gutes IAM-Setup auch echten Traffic aushalten. Token-Aussteller begrenzen Anfragen, Tokens laufen mitten in einem langen Test ab, und eine Erneuerung kostet eigene Latenz. Der Leitfaden Performance-Tests für APIs mit OAuth2 (englisch) geht auf diese Effekte ein.

LoadFocus ist kein Identity Provider, Ihr IAM bleibt also bei Ihnen. LoadFocus liefert die Traffic-Seite: Lasttests, um zu sehen, wie sich Login- und Token-Endpunkte unter Last verhalten, und API-Monitoring, um geschützte Endpunkte laufend zu beobachten.

Häufige Fragen: IAM

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Authentifizierung beweist, wer Sie sind, zum Beispiel mit Passwort und zweitem Faktor. Autorisierung entscheidet danach, was Sie tun dürfen, anhand von Rollen oder Richtlinien. Ein System authentifiziert zuerst und autorisiert dann jede Aktion.

Reicht RBAC aus?

Für die meisten Teams ja. Starten Sie mit wenigen Rollen und prüfen Sie sie regelmäßig. Auf attributbasierte Regeln wechseln Sie erst, wenn Rollen sich vervielfachen oder der Zugriff von Daten abhängt, etwa wenn ein Mandant die Datensätze eines anderen nie sehen darf.

Was bedeutet Least Privilege?

Eine Identität erhält nur die Berechtigungen, die sie für ihre Aufgabe braucht, und nicht mehr. Standardmäßig verweigern, konkrete Aktionen auf konkreten Ressourcen freigeben, und der Schaden durch ein geleaktes Credential bleibt klein.

Wie unterscheidet sich IAM von PAM?

IAM deckt jede Identität und jede Zugriffsentscheidung ab. Privileged Access Management (PAM) ist die Teilmenge, die mächtige Konten wie Root, Datenbank-Admins und Notfallzugänge schützt, meist mit Tresor für Zugangsdaten, Sitzungsaufzeichnung und zeitlich begrenztem Zugriff.

Soll ich IAM selbst bauen oder einen Anbieter nutzen?

Nutzen Sie einen etablierten Anbieter oder das IAM Ihrer Cloud. Passwortspeicherung, Sitzungsverwaltung, Wiederherstellungsabläufe und Audit-Trails lassen sich leicht unbemerkt falsch umsetzen, und ein Fehler dort betrifft alles hinter dem Login.