IAM Groups vs. direkte Policy-Zuweisung: Warum Gruppen die bessere Wahl sind
Wer zum ersten Mal mehrere IAM-Benutzer anlegt, greift oft zur schnellsten Lösung: Policy direkt an den User hängen, fertig. Das funktioniert — bis das Team auf zehn Personen wächst, jemand die Abteilung wechselt, oder ein Audit zeigt, dass drei Entwickler versehentlich Admin-Rechte haben. IAM Groups lösen genau dieses operationale Problem, und dieser Beitrag erklärt warum.
TL;DR: IAM Groups vs. direkte Policy-Zuweisung
| Kriterium | Direkte Policy-Zuweisung | IAM Groups |
|---|---|---|
| Skalierbarkeit | Jeder neue User braucht manuelle Policy-Zuweisung | User zur Gruppe hinzufügen — Policies gelten sofort |
| Konsistenz | Fehleranfällig bei vielen Usern | Einheitliche Berechtigungen für alle Gruppenmitglieder |
| Auditierbarkeit | Berechtigungen verteilt über viele User-Objekte | Zentrale Policy-Definition an der Gruppe |
| Offboarding | Manuelles Entfernen aller Policies pro User | User aus Gruppe entfernen — Zugriff entzogen |
| Least Privilege | Schwer durchzusetzen ohne Automatisierung | Rollenbasierte Gruppen erzwingen klare Grenzen |
Wie IAM-Berechtigungen funktionieren: Das Fundament
Bevor die Entscheidung zwischen direkter Zuweisung und Gruppen Sinn ergibt, muss das Auswertungsmodell klar sein. AWS wertet Berechtigungen nicht einfach additiv aus — es gibt eine definierte Reihenfolge.
Ein IAM-User kann Berechtigungen aus drei Quellen erhalten: direkt zugewiesene Inline- oder Managed Policies, Policies der Gruppen, in denen er Mitglied ist, und — wenn er eine Rolle übernimmt — die Policies dieser Rolle. Alle diese Berechtigungen werden zur Laufzeit zusammengeführt. Ein explizites Deny überschreibt dabei immer jeden Allow, unabhängig davon, woher er stammt.
IAM Groups sind keine Principals im AWS-Sinne — sie können keine Ressourcen-basierte Policy als Principal referenzieren, und sie können keine Rollen übernehmen. Sie sind ausschließlich ein Verwaltungsmechanismus, um Policies gebündelt an mehrere User zu vergeben.
S3 Read + CloudWatch"] User --> DirectPolicy["Direkte Policy
(falls vorhanden)"] Policy --> Eval["Berechtigungs-Auswertung"] DirectPolicy --> Eval SCP["SCP: Account-Ebene"] --> Eval BucketPolicy["S3 Bucket Policy"] --> Eval Eval --> Result{"Zugriff erlaubt?"} Result -->|"Kein explizites Deny"| Allow["Allow"] Result -->|"Explizites Deny"| Deny["Deny"]
- IAM User ist Mitglied in der Gruppe 'Developers'.
- Die Gruppe trägt eine Managed Policy (z.B. S3-Lesezugriff).
- Beim API-Aufruf wertet AWS alle Policies des Users aus — direkte und gruppenbasierte.
- Ein explizites Deny in einer SCP oder Bucket Policy überschreibt jeden Allow aus der Gruppe.
IAM Groups in der Praxis: Aufbau und Verwaltung
Eine Gruppe anlegen, eine Policy anhängen, User hinzufügen — das ist der vollständige Workflow. In der Praxis scheitert es oft daran, dass Teams diesen Workflow nicht konsequent durchhalten und irgendwann anfangen, Ausnahmen direkt am User zu konfigurieren. Dann hat man das Schlimmste aus beiden Welten.
Gruppe erstellen
aws iam create-group \
--group-name DevelopersManaged Policy an die Gruppe anhängen
Hier wird eine AWS Managed Policy verwendet. In produktiven Umgebungen sollte das eine eigene Customer Managed Policy sein, die nur die tatsächlich benötigten Berechtigungen enthält.
aws iam attach-group-policy \
--group-name Developers \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccessUser zur Gruppe hinzufügen
aws iam add-user-to-group \
--group-name Developers \
--user-name aliceGruppenmitgliedschaft und Policies prüfen
Diese beiden Befehle sind die erste Anlaufstelle bei jedem Berechtigungs-Audit. Wer in der Gruppe ist, und welche Policies die Gruppe trägt — das sind die zwei Fragen, die alles erklären.
aws iam get-group \
--group-name Developersaws iam list-attached-group-policies \
--group-name DevelopersAlle Gruppen eines Users prüfen
aws iam list-groups-for-user \
--user-name aliceCustomer Managed Policy erstellen und an eine Gruppe anhängen
AWS Managed Policies sind ein guter Ausgangspunkt, aber sie sind selten präzise genug für produktive Workloads. Eine Customer Managed Policy gibt volle Kontrolle über den genauen Berechtigungsumfang.
🔽 Beispiel: Customer Managed Policy für Entwickler (JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ReadAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-dev-bucket",
"arn:aws:s3:::my-dev-bucket/*"
]
},
{
"Sid": "CloudWatchLogsRead",
"Effect": "Allow",
"Action": [
"logs:GetLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/*"
}
]
}aws iam create-policy \
--policy-name DeveloperBasePolicy \
--policy-document file://developer-policy.jsonaws iam attach-group-policy \
--group-name Developers \
--policy-arn arn:aws:iam::123456789012:policy/DeveloperBasePolicyDas Muster, das in der Praxis bricht — und warum
Ein konkretes Szenario aus dem Alltag: Ein neuer Entwickler braucht kurzfristig Zugriff auf einen spezifischen S3-Bucket, den die Gruppe nicht abdeckt. Jemand hängt die Policy direkt an den User — 'nur temporär'. Drei Monate später ist die Person längst in einem anderen Team, die direkte Policy ist vergessen, und ein Audit-Tool meldet einen User mit inkonsistenten Berechtigungen.
Das ist kein Einzelfall. Es ist das strukturelle Problem direkter Policy-Zuweisungen: Sie sind unsichtbar, wenn man auf die Gruppe schaut. list-attached-group-policies zeigt sie nicht. Man muss explizit list-attached-user-policies und list-user-policies aufrufen, um das vollständige Bild zu bekommen.
Berechtigungen bei alice"] --> Diagnose1["Fehldiagnose: Gruppen-Policy
wird geprüft — ist sauber"] Diagnose1 --> Gap["Lücke: Direkte User-Policies
nicht geprüft"] Gap --> RealCause["Ursache: Inline/Managed Policy
direkt am User — vergessen"] RealCause --> Fix1["list-attached-user-policies"] Fix1 --> Fix2["detach-user-policy"] Fix2 --> Fix3["Zugriff über Gruppe neu regeln"]
- Symptom: User hat mehr Rechte als erwartet, obwohl die Gruppe korrekt konfiguriert ist.
- Fehldiagnose: Gruppenrichtlinie wird als Ursache untersucht — sie ist sauber.
- Tatsächliche Ursache: Eine direkt am User hängende Policy, die vor Monaten als 'temporär' angelegt wurde.
- Fix: Direkte Policies identifizieren und entfernen, Zugriff über Gruppe neu regeln.
Direkte Policies am User sind die blinden Flecken im IAM-Audit.
Direkte Policies eines Users prüfen
aws iam list-attached-user-policies \
--user-name aliceaws iam list-user-policies \
--user-name aliceDirekte Managed Policy vom User entfernen
aws iam detach-user-policy \
--user-name alice \
--policy-arn arn:aws:iam::123456789012:policy/DeveloperBasePolicyIAM Groups strukturieren: Empfohlenes Muster
Gruppen nach Funktion, nicht nach Projekt. Das ist die Regel, die in der Praxis am stabilsten bleibt. Projektbasierte Gruppen wachsen unkontrolliert und werden selten aufgeräumt. Funktionsbasierte Gruppen — 'Developers', 'DataEngineers', 'ReadOnlyAuditors' — spiegeln wider, was ein Mensch in seiner Rolle braucht, unabhängig davon, an welchem Projekt er gerade arbeitet.
Eine IAM Group verhält sich wie eine Schablone für Berechtigungen. Wer in die Schablone passt, bekommt den Ausschnitt — nicht mehr, nicht weniger. Direkte Policy-Zuweisungen sind handgeschnittene Ausnahmen, die niemand mehr findet, wenn die Person, die sie erstellt hat, nicht mehr da ist.
Ein User kann Mitglied in mehreren Gruppen sein. Das ist nützlich, aber es erhöht die Komplexität der Berechtigungsauswertung. Wenn ein User in 'Developers' und 'DataEngineers' ist, erhält er die Vereinigung beider Gruppen-Policies. Das kann zu unbeabsichtigten Berechtigungen führen, wenn die Gruppen nicht sauber abgegrenzt sind.
Wichtig: Ein IAM-User kann laut AWS-Dokumentation Mitglied in maximal 10 Gruppen sein. Das ist ein hartes Limit, das bei der Gruppenstruktur berücksichtigt werden muss.
CloudWatch Logs"] DataGroup --> DataPolicy["Policy: Glue, Athena,
S3-Data-Pfade"] AuditGroup --> AuditPolicy["Policy: Read-Only
alle Dienste"]
- Developers-Gruppe: Trägt Policies für Code-Repositories, Lambda-Logs, Dev-S3-Buckets.
- DataEngineers-Gruppe: Trägt Policies für Glue, Athena, spezifische S3-Pfade.
- ReadOnlyAuditors-Gruppe: Trägt eine restriktive Read-Only-Policy quer über alle Dienste.
- User 'alice' ist in Developers und DataEngineers — erhält die Vereinigung beider Policies.
- User 'bob' ist nur in ReadOnlyAuditors — klare, minimale Berechtigungen.
Offboarding: Wo der Unterschied am deutlichsten wird
Jemand verlässt das Unternehmen. Bei direkter Policy-Zuweisung muss man alle Policies des Users kennen, um sicherzustellen, dass nach dem Löschen des Users keine Ressourcen mit verwaisten Berechtigungen zurückbleiben. Bei gruppenbasierter Verwaltung reicht es, den User zu löschen — die Gruppenmitgliedschaft und alle damit verbundenen Berechtigungen verschwinden automatisch.
aws iam remove-user-from-group \
--group-name Developers \
--user-name aliceaws iam delete-user \
--user-name aliceBevor ein User gelöscht werden kann, müssen alle direkten Policies, Zugriffsschlüssel, MFA-Geräte und Gruppenmitgliedschaften entfernt sein. Das ist ein weiterer Grund, direkte Policies zu vermeiden — sie verlängern den Offboarding-Prozess und erhöhen das Risiko, etwas zu vergessen.
IAM Groups und das Zusammenspiel mit SCPs
Ein Detail, das oft übersehen wird: Service Control Policies (SCPs) in AWS Organizations wirken auf Account-Ebene und schränken ein, was überhaupt möglich ist — unabhängig davon, was IAM-Policies erlauben. Eine Gruppe mit einer Allow-Policy für eine bestimmte Aktion kann diese Aktion trotzdem nicht ausführen, wenn eine SCP sie auf Account-Ebene blockiert.
Das bedeutet: Wenn Berechtigungen trotz korrekter Gruppen-Policy nicht funktionieren, ist die SCP-Konfiguration des Accounts der nächste Prüfpunkt — nicht die IAM-Gruppe selbst.
aws organizations list-policies-for-target \
--target-id <account-id> \
--filter SERVICE_CONTROL_POLICYFazit und nächste Schritte mit IAM Groups
Direkte Policy-Zuweisungen an einzelne IAM-User sind in kleinen, statischen Umgebungen handhabbar. Sobald das Team wächst, Rollen wechseln oder Audits stattfinden, werden sie zur operationalen Last. IAM Groups sind kein Feature-Upgrade — sie sind die korrekte Betriebsweise für jede Umgebung mit mehr als einem User.
Der praktische nächste Schritt: Bestehende direkte Policy-Zuweisungen mit list-attached-user-policies identifizieren, in Gruppen-Policies überführen und die direkten Zuweisungen entfernen. Das schafft eine saubere, auditierbare Ausgangslage.
Weiterführende Ressourcen: AWS IAM Groups — offizielle Dokumentation und die IAM Best Practices.
Glossar: Schlüsselbegriffe zu IAM Groups
| Begriff | Bedeutung |
|---|---|
| IAM Group | Verwaltungseinheit, die Policies an mehrere IAM-User gleichzeitig vergibt. Kein eigenständiger Principal. |
| Managed Policy | Eigenständiges IAM-Policy-Objekt, das an User, Gruppen oder Rollen angehängt werden kann. Wiederverwendbar. |
| Inline Policy | Policy, die direkt in ein IAM-Objekt eingebettet ist. Nicht wiederverwendbar, schwerer zu auditieren. |
| SCP (Service Control Policy) | Account-weite Berechtigungsgrenze in AWS Organizations. Überschreibt IAM-Allows auf Account-Ebene. |
| Least Privilege | Sicherheitsprinzip: Nur die minimal notwendigen Berechtigungen vergeben, die für eine Aufgabe erforderlich sind. |
Kommentare
Kommentar veröffentlichen