AWS IAM

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 von Sekunden weltweit repliziert. Der Service bietet 99,99% Verfügbarkeit SLA und ist FIPS 140-2 Level 3 zertifiziert für höchste Sicherheitsanforderungen.

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 Corporate Directory (Active Directory, Okta, Google Workspace) für Single Sign-On und zentrale Verwaltung.

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-Operations), Resource (ARNs), Condition (Kontext wie IP, MFA, Zeit). IAM Policy Simulator ermöglicht das Testen von Policies vor Deployment.

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 STS (Security Token Service) für temporäre Credentials mit 1-12 Stunden Gültigkeit. AssumeRole API gibt Access Key, Secret Key und Session Token zurück. Credentials rotieren automatisch vor Ablauf.

Multi-Factor Authentication (MFA)

MFA erzwingt zweite Authentifizierungsstufe zusätzlich zu Passwort oder Access Keys. Unterstützte MFA-Typen:

Virtual MFA: Apps wie Google Authenticator, Authy, 1Password
Hardware MFA: YubiKey, Gemalto Token (FIPS 140-2 zertifiziert)
SMS-based MFA: Veraltet, nicht empfohlen (SIM Swapping-Risiko)

MFA kann per IAM Policy erzwungen werden für sensible Operationen. Beispiel: S3 Object Deletion nur mit MFA erlauben. Root Account MFA ist Pflicht-Best-Practice.

Typische Anwendungsfälle für AWS IAM

Federation mit Corporate Identity Providers

Single Sign-On zwischen Ihrem Corporate Directory und AWS eliminiert separate AWS-Passwörter. Benutzer authentifizieren sich gegen Active Directory, 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 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: Security-Team in zentralem Security Account übernimmt ReadOnly-Role in Production Accounts für Audits.

Trust Policies definieren, welche Principals eine Role annehmen dürfen. External ID Parameter schützt vor 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. Beispiele:

EC2 zu S3: Instance Profile mit Role, die s3:GetObject erlaubt
Lambda zu DynamoDB: Execution Role mit dynamodb:PutItem Permission
CodePipeline zu CodeBuild: Service Role für Build-Orchestrierung

IAM Roles vermeiden Access Keys im Code, unterstützen automatische Credential-Rotation und ermöglichen granulare Berechtigungen pro Service. CloudTrail loggt alle AssumeRole-Aufrufe für Compliance.

Least-Privilege Access für Entwickler

Entwickler benötigen Zugriff auf AWS-Ressourcen, aber mit Einschränkungen. Best Practice: AWS SSO mit mehreren Roles pro Entwickler:

ReadOnly Role: Standard-Zugriff für Monitoring und Debugging
Developer Role: Deployment-Permissions für Dev/Test Accounts
Production Role: Zeitlich begrenzt, nur nach Approval, nur für Incidents

Permission Boundaries verhindern Privilege Escalation: Entwickler können eigene Roles erstellen, aber nur innerhalb der Boundary. Service Control Policies setzen Guardrails auf Organisationsebene (z.B. keine Ressourcen außerhalb EU-Regionen).

Compliance und Audit

IAM unterstützt Compliance-Anforderungen durch detaillierte Zugriffskontrolle und Audit-Trails:

CloudTrail: Loggt alle IAM API-Calls (CreateUser, AssumeRole, etc.)
IAM Access Analyzer: Identifiziert externe Zugriffe auf Ressourcen
Credential Reports: CSV-Export aller User-Credentials mit letzter Nutzung
Access Advisor: Zeigt, welche Permissions wann zuletzt genutzt wurden

Automatisierte Compliance-Checks mit AWS Config Rules: Alarm bei Root-Account-Nutzung, fehlender MFA, übermäßigen Permissions. AWS Security Hub aggregiert Findings aus mehreren Tools.

Best Practices für AWS IAM

1. Nutzen Sie IAM Roles statt Users

Vermeiden Sie permanente IAM User Credentials. Nutzen Sie stattdessen:

Für Menschen: Federation mit Corporate Identity Provider über AWS SSO
Für Anwendungen: IAM Roles mit EC2 Instance Profiles oder ECS Task Roles
Für CI/CD: OIDC Federation mit GitHub Actions, GitLab CI (keine Access Keys)

Wenn IAM Users unvermeidbar sind (Legacy-Tools): Erzwingen Sie MFA, rotieren Sie Access Keys alle 90 Tage, nutzen Sie AWS Access Analyzer zur Identifikation ungenutzter Keys.

2. Implementieren Sie Least Privilege

Starten Sie mit zero Permissions und fügen Sie schrittweise hinzu, was benötigt wird. Nutzen Sie AWS-managed Policies für Standard-Use-Cases, erstellen Sie Custom Policies für spezifische Anforderungen.

IAM Access Advisor zeigt, welche Permissions in den letzten 90 Tagen genutzt wurden. Entfernen Sie ungenutzte Permissions regelmäßig. Vermeiden Sie Wildcard-Permissions (:) in Production. Nutzen Sie Condition-Statements für Kontext-abhängige Permissions (IP-Range, MFA-Status).

3. Aktivieren Sie MFA für privilegierte Zugriffe

MFA ist Pflicht für Root Account und empfohlen für alle privilegierten IAM Users. Erzwingen Sie MFA per IAM Policy für sensible Operationen:

{
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

Hardware-MFA (YubiKey) bietet höchste Sicherheit gegen Phishing. Virtual MFA ist ausreichend für Standard-Zugriffe. SMS-MFA vermeiden (SIM Swapping-Risiko).

4. Nutzen Sie Service Control Policies (SCPs)

SCPs setzen Guardrails auf AWS Organizations-Ebene und schützen vor versehentlichen oder böswilligen Verstößen. Beispiele:

Region Restriction: Nur EU-Regionen erlaubt (DSGVO-Compliance)
Service Deny List: Verbot teurer oder nicht benötigter Services
Root Account Protection: Blockiere Root-Credentials außer für Break-Glass
Require Encryption: Nur verschlüsselte S3 Buckets, EBS Volumes, RDS Instances

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 (Access Keys) sollten regelmäßig rotiert werden:

90-Tage-Rotation: AWS Config Rule alarmiert bei älteren Keys
Automated Rotation: Secrets Manager rotiert Datenbank-Credentials automatisch
Short-lived Credentials: Rollen-basierte Credentials mit 1-12 Stunden Gültigkeit

Für Anwendungen: Nutzen Sie IAM Roles statt Access Keys. Für CI/CD: OIDC Federation mit kurzlebigen Tokens. Access Keys nur als letztes Mittel, dann mit AWS Secrets Manager verwalten.

6. Implementieren Sie Monitoring und Alerting

Überwachen Sie IAM-Aktivitäten kontinuierlich:

CloudTrail: Alle IAM API-Calls in CloudWatch Logs
EventBridge Rules: Alarmierung bei Root-Login, MFA-Deaktivierung, neuen Access Keys
IAM Access Analyzer: Continuous Monitoring externer Zugriffe
GuardDuty: ML-basierte Anomalie-Erkennung (ungewöhnliche API-Calls)

CloudWatch Alarms für kritische Events: Root Account Activity, Failed Login Attempts, Policy Changes. SNS-Notifications an Security-Team. Automated Response mit Lambda-Funktionen.

7. Verwenden Sie Permission Boundaries

Permission Boundaries setzen maximale Permissions für Users/Roles und verhindern Privilege Escalation. Anwendungsfall: Entwickler dürfen eigene Roles für Lambda-Funktionen erstellen, aber nur innerhalb der Boundary.

Boundary definiert Obergrenze, IAM Policy definiert tatsächliche Permissions. Effective Permissions sind Intersection beider. Ideal für delegierte Administration ohne Sicherheitsrisiko.

8. Regelmäßige IAM-Audits

Führen Sie quartalsweise IAM-Audits durch:

Credential Report: Alle Users, letzte Passwort-Änderung, MFA-Status, letzte Key-Nutzung
Unused Identities: Users/Roles ohne Activity in 90 Tagen deaktivieren
Over-privileged Roles: Access Advisor zeigt ungenutzte Permissions
External Access: Access Analyzer identifiziert Ressourcen mit externem Zugriff

Automatisierung mit AWS Config, AWS Security Hub, Trusted Advisor. Remediation Runbooks für häufige Findings. Compliance-Dashboard für Management-Reporting.

AWS IAM vs. Alternativen

Beim Vergleich von IAM-Lösungen verschiedener Cloud-Provider zeigen sich unterschiedliche Stärken:

AWS IAM vs. Google Cloud IAM

Google Cloud IAM nutzt ein ähnliches Policy-basiertes Modell, aber mit einfacherer Syntax. Google setzt auf hierarchische Ressourcen-Organisation (Organization → Folder → Project), AWS auf flachere Account-Struktur mit Organizations.

AWS-Vorteile: Reifere Federation-Features, umfangreichere Condition-Syntax, bessere Third-Party-Integration, größeres Ökosystem für Identity-Tools.

Google-Vorteile: Einfacheres Policy-Management durch Inheritance, granularere Organizational Policies, VPC Service Controls für Datengrenzen.

AWS IAM vs. Azure Active Directory / Entra ID

Azure nutzt Azure Active Directory (jetzt Entra ID) als zentrales Identity System. Stärkere Integration mit Microsoft-Ökosystem (Office 365, Windows, Active Directory). Azure Managed Identities ähneln AWS IAM Roles.

AWS-Vorteile: Trennung von Identity (IAM) und Directory (AWS Managed Microsoft AD), flexiblere Policy-Engine, bessere Multi-Cloud-Support.

Azure-Vorteile: Unified Identity über Cloud und On-Premises, Conditional Access Policies, stärkere Hybrid-Cloud-Features.

Wann AWS IAM vs. externes IAM-Tool?

AWS IAM wählen bei: Reine AWS-Umgebung, Standard-Compliance-Anforderungen, Integration mit AWS Services, Team mit AWS-Expertise.

Externes Tool (HashiCorp Vault, Okta, Ping) wählen bei: Multi-Cloud-Umgebung (AWS + GCP + Azure), spezielle Compliance-Anforderungen (PCI DSS Level 1), Dynamic Secrets mit kurzer Lebensdauer (Minuten statt Stunden), zentrales Secret Management über Cloud-Grenzen.

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. Best-Practice-Implementierung nach AWS Well-Architected Framework Security Pillar.

Migration: Sichere Überführung bestehender Identitätssysteme zu AWS IAM. Federation-Setup mit Active Directory, Okta, Google Workspace. Migration von IAM Users zu Roles. Automated Access Key Rotation.

Security & Compliance: DSGVO-konforme IAM-Implementierung in EU-Regionen. Least-Privilege-Policies nach Zero-Trust-Prinzip. MFA-Enforcement für privilegierte Zugriffe. Continuous Compliance-Monitoring mit AWS Config, Security Hub, GuardDuty.

Audit & Optimization: IAM-Audits zur Identifikation über-privilegierter Rollen, ungenutzter Credentials, externer Zugriffe. Remediation-Pläne mit Priorisierung nach Risiko. Automated Guardrails mit Service Control Policies.

Schulung & Workshops: IAM Best Practices, Policy-Entwicklung, Federation-Setup, Security-Automation. Hands-on Workshops für Ihr Team mit realen Szenarien.

24/7 Support: Monitoring kritischer IAM-Events (Root Login, Policy Changes, MFA Deactivation). Incident Response bei Security-Vorfällen. Proaktive Optimierung basierend auf Access Patterns.

Kontaktieren Sie uns für eine unverbindliche Beratung zu AWS IAM und Security-Architekturen auf AWS.