Was ist AWS IAM?
AWS IAM (Identity and Access Management) ist der zentrale Service zur Steuerung von Zugriff auf AWS-Ressourcen. IAM ermöglicht die Verwaltung von Benutzern, Gruppen, Rollen und detaillierten Berechtigungen über Policies. Der Service ist kostenlos und bildet das Fundament jeder sicheren AWS-Architektur.
IAM arbeitet als globaler Service über alle AWS-Regionen hinweg. Änderungen an Policies oder Rollen werden innerhalb kurzer Zeit weltweit repliziert.
AWS IAM unterstützt sowohl direkte Benutzerverwaltung (IAM Users) als auch Federation mit externen Identity Providern (SAML 2.0, OpenID Connect). Best Practice für Unternehmen: Federation mit dem Corporate Directory (Microsoft Entra ID, Okta, Google Workspace) für Single Sign-On und zentrale Verwaltung, idealerweise über AWS IAM Identity Center.
Wie funktioniert AWS IAM?
IAM basiert auf einem Policy-basierten Autorisierungsmodell. Jede Anfrage an AWS wird gegen alle anwendbaren Policies evaluiert. Das Prinzip: Deny by Default, explizite Allow-Statements erforderlich, explizite Deny-Statements haben Vorrang.
IAM Policies
Policies sind JSON-Dokumente, die Permissions definieren:
Identity-based Policies: An Users, Groups, Roles angehängt Resource-based Policies: Direkt an Ressourcen (S3 Buckets, KMS Keys) Permission Boundaries: Maximale Permissions für Users/Roles Service Control Policies: Guardrails auf AWS-Organizations-Ebene Session Policies: Einschränkung temporärer Credentials
Policies nutzen Effect (Allow/Deny), Action (Service-Operationen), Resource (ARNs), Condition (Kontext wie IP, MFA, Zeit). Für die genauen aktuellen Größen- und Mengenlimits von Policies, Usern und Rollen verweisen wir auf die offizielle IAM-Quotas-Dokumentation, da sich Standard- und maximale Kontingente ändern können.
IAM Roles
Roles sind temporäre Identitäten ohne permanente Credentials. Anwendungsfälle:
Service Roles: EC2-Instanzen greifen auf S3 zu ohne Access Keys im Code Cross-Account Roles: Account A delegiert Zugriff an Account B Federation Roles: Externe Benutzer erhalten temporäre AWS-Credentials Lambda Execution Roles: Lambda-Funktionen mit Least-Privilege-Permissions
Roles nutzen AWS STS (Security Token Service) für temporäre Credentials. Die maximale Gültigkeitsdauer einer Rollensitzung lässt sich je Rolle konfigurieren (bis zu 12 Stunden); ohne Angabe gilt in der Regel eine Stunde. Die AssumeRole-API gibt Access Key, Secret Key und Session Token zurück, die vor Ablauf automatisch erneuert werden müssen.
Multi-Factor Authentication (MFA)
MFA erzwingt eine zweite Authentifizierungsstufe zusätzlich zu Passwort oder Access Keys. Unterstützte MFA-Typen:
Virtual MFA: Apps wie Google Authenticator, Authy, 1Password Hardware MFA: FIDO-Sicherheitsschlüssel und andere Hardware-Token SMS-basierte MFA: Von AWS aus Sicherheitsgründen nicht empfohlen (Risiko von SIM-Swapping)
MFA kann per IAM-Policy für sensible Operationen erzwungen werden, beispielsweise das Löschen von S3-Objekten nur mit aktiver MFA. MFA für den Root-Account gilt als zwingende Best Practice.
Typische Anwendungsfälle für AWS IAM
Federation mit Corporate Identity Providern
Single Sign-On zwischen dem Corporate Directory und AWS eliminiert separate AWS-Passwörter. Benutzer authentifizieren sich gegen Microsoft Entra ID, Okta oder Google Workspace. Der Identity Provider stellt SAML-Assertions aus, AWS tauscht diese gegen temporäre IAM-Role-Credentials.
Vorteile: zentrale Benutzerverwaltung, automatisches Onboarding/Offboarding bei Personalwechsel, keine Passwort-Synchronisation, Audit-Trails im Corporate Directory. AWS IAM Identity Center (ehemals AWS SSO) vereinfacht das Setup für Multi-Account-Umgebungen.
Cross-Account Access Management
In Multi-Account-Architekturen (AWS Organizations) ermöglichen IAM Roles sicheren Zugriff zwischen Accounts. Beispiel: Ein Security-Team im zentralen Security Account übernimmt eine ReadOnly-Role in Production Accounts für Audits.
Trust Policies definieren, welche Principals eine Role annehmen dürfen. Ein External-ID-Parameter schützt vor dem Confused-Deputy-Problem. Session Tags ermöglichen Attribute-based Access Control (ABAC) für granulare Permissions basierend auf Benutzer-Attributen.
Service-to-Service Authorization
AWS Services nutzen IAM Roles für sichere Kommunikation ohne hardcodierte Credentials, etwa EC2-Instance-Profile mit S3-Leseberechtigung oder Lambda-Execution-Roles mit DynamoDB-Zugriff. IAM Roles vermeiden Access Keys im Code, unterstützen automatische Credential-Rotation und ermöglichen granulare Berechtigungen pro Service. CloudTrail protokolliert alle AssumeRole-Aufrufe für Compliance-Zwecke.
Least-Privilege Access für Entwickler
Entwickler benötigen Zugriff auf AWS-Ressourcen, aber mit Einschränkungen. Best Practice: zentrales Login über IAM Identity Center mit mehreren Rollen pro Entwickler, ReadOnly-Zugriff als Standard und erweiterte Permissions nur zeitlich begrenzt und nach Approval. Permission Boundaries verhindern, dass Entwickler sich selbst weitreichendere Rechte verschaffen als vorgesehen.
Compliance und Audit
IAM unterstützt Compliance-Anforderungen durch detaillierte Zugriffskontrolle und Audit-Trails: CloudTrail protokolliert alle IAM-API-Aufrufe, IAM Access Analyzer identifiziert externe Zugriffe auf Ressourcen, Credential Reports zeigen die Nutzung aller Zugangsdaten, und Access Advisor zeigt, welche Permissions zuletzt genutzt wurden. AWS Config Rules und AWS Security Hub ermöglichen automatisierte Compliance-Checks über mehrere Konten hinweg.
Best Practices für AWS IAM
1. Nutzen Sie IAM Roles statt Users
Vermeiden Sie permanente IAM-User-Credentials. Nutzen Sie stattdessen Federation mit einem Corporate Identity Provider über IAM Identity Center für Menschen, IAM Roles mit EC2-Instance-Profiles oder ECS-Task-Roles für Anwendungen und OIDC-Federation für CI/CD-Pipelines. Wo IAM Users unvermeidbar sind, sollten MFA erzwungen und Access Keys regelmäßig rotiert werden.
2. Implementieren Sie Least Privilege
Starten Sie mit minimalen Permissions und ergänzen Sie schrittweise, was tatsächlich benötigt wird. Nutzen Sie AWS-Managed Policies für Standardfälle und Custom Policies für spezifische Anforderungen. IAM Access Advisor zeigt genutzte Permissions der letzten Zeit; ungenutzte Rechte sollten regelmäßig entfernt werden.
3. Aktivieren Sie MFA für privilegierte Zugriffe
MFA ist Pflicht für den Root-Account und empfohlen für alle privilegierten IAM-Benutzer. MFA lässt sich per IAM-Policy für sensible Operationen erzwingen, etwa über eine Condition auf aws:MultiFactorAuthPresent. Hardware-MFA bietet höheren Schutz gegen Phishing als Virtual MFA; SMS-basierte MFA sollte vermieden werden.
4. Nutzen Sie Service Control Policies (SCPs)
SCPs setzen Guardrails auf AWS-Organizations-Ebene und schützen vor versehentlichen oder böswilligen Verstößen, etwa durch Region-Restriktionen, Verbotslisten für bestimmte Services oder Verschlüsselungspflichten. SCPs wirken als Filter vor IAM-Policies: Auch ein Administrator im Member Account kann keine Operationen ausführen, die die SCP verbietet.
5. Automatisieren Sie Credential-Rotation
Permanente Credentials wie Access Keys sollten regelmäßig rotiert werden. AWS Config Rules können bei veralteten Keys alarmieren, AWS Secrets Manager kann Datenbank-Credentials automatisch rotieren. Wo möglich, sollten kurzlebige, rollenbasierte Credentials permanente Access Keys ersetzen.
6. Implementieren Sie Monitoring und Alerting
Überwachen Sie IAM-Aktivitäten kontinuierlich über CloudTrail-Logs in CloudWatch, EventBridge-Regeln für kritische Events wie Root-Login oder neue Access Keys, IAM Access Analyzer für externe Zugriffe und Amazon GuardDuty für ML-basierte Anomalie-Erkennung.
7. Verwenden Sie Permission Boundaries
Permission Boundaries setzen maximale Permissions für Users/Roles und verhindern Privilege Escalation. Ein typischer Anwendungsfall: Entwickler dürfen eigene Roles für Lambda-Funktionen erstellen, jedoch nur innerhalb der definierten Boundary.
8. Regelmäßige IAM-Audits
Führen Sie regelmäßige IAM-Audits durch: Credential Reports zeigen Passwort-Alter, MFA-Status und Key-Nutzung, Access Advisor identifiziert über-privilegierte Rollen, und Access Analyzer zeigt Ressourcen mit externem Zugriff. AWS Config, Security Hub und Trusted Advisor unterstützen die Automatisierung dieser Prüfungen.
AWS IAM vs. Alternativen
AWS IAM vs. Google Cloud IAM
Google Cloud IAM nutzt ein ähnliches Policy-basiertes Modell, setzt aber auf eine hierarchische Ressourcen-Organisation (Organization → Folder → Project), während AWS auf eine flachere Account-Struktur mit AWS Organizations setzt. AWS bietet ein sehr ausgereiftes Federation- und Condition-Modell; Google punktet mit einfacherem Policy-Management durch Vererbung und granularen Organizational Policies.
AWS IAM vs. Microsoft Entra ID
Microsoft Entra ID (ehemals Azure Active Directory) ist das zentrale Identity-System im Microsoft-Ökosystem mit starker Integration in Microsoft 365 und Windows. AWS trennt Identity (IAM) und Verzeichnisdienst (AWS Managed Microsoft AD) stärker voneinander und bietet eine flexible, Multi-Cloud-fähige Policy-Engine. Entra ID punktet mit einheitlicher Identität über Cloud und On-Premises sowie Conditional-Access-Richtlinien.
Wann AWS IAM vs. externes IAM-Tool?
AWS IAM eignet sich gut für reine AWS-Umgebungen mit Standard-Compliance-Anforderungen. Für Multi-Cloud-Umgebungen, besondere Compliance-Anforderungen oder zentrales Secret-Management über Cloud-Grenzen hinweg kann ein spezialisiertes externes Tool wie HashiCorp Vault, Okta oder Ping sinnvoll sein. Als Multi-Cloud-Experten beraten wir Sie herstellerneutral zur optimalen Lösung für Ihre Anforderungen.
AWS IAM Integration mit innFactory
Als AWS Reseller unterstützt innFactory Sie bei:
Architektur-Design: Wir konzipieren sichere, skalierbare IAM-Architekturen mit Federation, Cross-Account-Access, Service Control Policies und Permission Boundaries, orientiert am AWS Well-Architected Framework Security Pillar.
Migration: Sichere Überführung bestehender Identitätssysteme zu AWS IAM, Federation-Setup mit Microsoft Entra ID, Okta oder Google Workspace, Migration von IAM Users zu Roles und automatisierte Access-Key-Rotation.
Security & Compliance: DSGVO-konforme IAM-Implementierung, Least-Privilege-Policies nach Zero-Trust-Prinzip, MFA-Enforcement für privilegierte Zugriffe und kontinuierliches Compliance-Monitoring mit AWS Config, Security Hub und GuardDuty.
Audit & Optimization: IAM-Audits zur Identifikation über-privilegierter Rollen, ungenutzter Credentials und externer Zugriffe, inklusive priorisierter Remediation-Pläne.
Schulung & Workshops: IAM Best Practices, Policy-Entwicklung, Federation-Setup und Security-Automation als Hands-on-Workshops für Ihr Team.
Kontaktieren Sie uns für eine unverbindliche Beratung zu AWS IAM und Security-Architekturen auf AWS.
Verfügbare Varianten & Optionen
IAM Users & Groups
- Direkte Benutzerverwaltung in AWS
- Permanente Credentials
- Geeignet für kleine Teams
- Keine zentrale Identitätsverwaltung
- Schwierig bei vielen Benutzern
IAM Roles & Federation
- Temporäre Credentials
- Integration mit Corporate Identity Providers
- Keine Passwort-Verwaltung in AWS
- Automatische Rotation
- Erfordert Identity Provider Setup
Typische Anwendungsfälle
Häufig gestellte Fragen
Was ist AWS IAM?
AWS IAM (Identity and Access Management) ist der zentrale Service zur Verwaltung von Zugriffen auf AWS-Ressourcen. IAM ermöglicht die Erstellung von Benutzern, Gruppen und Rollen sowie die Definition detaillierter Berechtigungen. Der Service ist kostenlos und bildet die Grundlage jeder sicheren AWS-Architektur.
Was kostet AWS IAM?
AWS IAM ist kostenlos nutzbar. Es entstehen keine Gebühren für Benutzer, Gruppen, Rollen oder Policies, auch nicht für Multi-Factor Authentication. Kosten können lediglich für Hardware-MFA-Geräte oder die Nutzung externer Identity Provider anfallen.
Was ist der Unterschied zwischen IAM Users und IAM Roles?
IAM Users sind permanente Identitäten mit festen Credentials (Passwort, Access Keys), geeignet für wenige administrative Benutzer. IAM Roles sind temporäre Identitäten ohne Passwort, die von AWS Services, Anwendungen oder federierten Benutzern übernommen werden. Best Practice: Roles statt Users verwenden, insbesondere bei Federation mit Corporate Identity Providern.
Wie funktioniert Federation mit IAM?
Federation ermöglicht Single Sign-On (SSO) zwischen einem Corporate Identity Provider (z. B. Microsoft Entra ID, Okta, Google Workspace) und AWS. Benutzer authentifizieren sich gegen den Provider, dieser stellt SAML-Assertions oder OIDC-Tokens aus, AWS tauscht diese gegen temporäre IAM-Role-Credentials. Vorteile: zentrale Benutzerverwaltung, keine AWS-Passwörter, automatisches Onboarding/Offboarding.
Was ist das Least-Privilege-Prinzip?
Das Least-Privilege-Prinzip bedeutet, nur die minimal notwendigen Berechtigungen zu vergeben: mit möglichst wenigen Permissions starten und schrittweise ergänzen, was tatsächlich benötigt wird. IAM Access Analyzer hilft, ungenutzte Permissions zu identifizieren; Wildcard-Permissions wie '*:*' sollten in Production vermieden werden.
Was sind Service Control Policies (SCPs) in AWS Organizations?
SCPs sind Guardrails auf Organisationsebene, die maximale Permissions für Accounts definieren. Sie überschreiben keine IAM-Policies, sondern setzen Obergrenzen, etwa das Verbot, Ressourcen außerhalb bestimmter Regionen anzulegen. Auch Administratoren in Member Accounts können diese Obergrenzen nicht überschreiten.
Was ist IAM Access Analyzer?
IAM Access Analyzer identifiziert Ressourcen wie S3-Buckets, KMS-Schlüssel oder IAM-Rollen, die mit externen Principals geteilt werden, und alarmiert bei unerwarteten Zugriffen. Zusätzlich prüft Policy Validation neue Policies auf Best Practices, und Unused Access Analyzer zeigt ungenutzte Permissions.
Wie sichere ich den AWS Root Account?
Der Root Account hat uneingeschränkten Zugriff und sollte entsprechend geschützt werden: starkes, einzigartiges Passwort, aktivierte MFA (Hardware-MFA bevorzugt), keine dauerhaften Access Keys, sichere Aufbewahrung der Zugangsdaten und Nutzung nur in Ausnahmefällen. Tägliche Operationen sollten über IAM-Benutzer oder -Rollen mit Least Privilege erfolgen.
Hinweis: Alle Produktinformationen auf dieser Seite wurden sorgfältig zusammengestellt, sind jedoch ohne Gewähr und können veraltet oder unvollständig sein. Cloud-Services entwickeln sich schnell weiter — Funktionen, Preise, SLAs und Verfügbarkeit ändern sich laufend. Verbindliche und aktuelle Informationen finden Sie ausschließlich auf der offiziellen Produktseite von AWS (offizielle Dokumentation). Diese Seite stellt kein Angebot von AWS dar.