AWS IAM Access Control: Richtlinien, Rollen & Best Practices

AWS Identity and Access Management (IAM) ist der Dienst, der Authentifizierung und Autorisierung für jeden API-Aufruf in Ihrer AWS-Umgebung steuert. Er bestimmt, wer sich anmelden darf, welche Aktionen ausgeführt werden können und auf welche Ressourcen — über jeden AWS-Service, in jeder Region, für jeden Account. IAM korrekt zu konfigurieren, ist keine Option; laut den eigenen Post-Incident-Analysen von AWS sind fehlkonfigurierte IAM-Richtlinien an der Mehrheit der öffentlich bekannt gewordenen Cloud-Sicherheitsvorfälle beteiligt. Dieser Artikel behandelt die Architektur von IAM, die Auswertungslogik von Richtlinien, praxiserprobte Muster zur Skalierung der Zugriffskontrolle und die operativen Fehler, die das SOC von Opsio immer wieder über Hunderte von AWS-Accounts hinweg vorfindet.

Wichtigste Erkenntnisse

• AWS IAM ist der grundlegende Dienst zur Steuerung, wer was mit welcher AWS-Ressource tun darf — und Fehlkonfigurationen sind die häufigste Ursache für Cloud-Sicherheitsvorfälle.
• Wirksames IAM erfordert die Kombination aus Identity Policies, Resource Policies, Permission Boundaries und Service Control Policies — nicht nur das Anhängen verwalteter Richtlinien an Benutzer.
• Organisationen, die der NIS2-Richtlinie, der DSGVO oder dem BSI C5 unterliegen, müssen IAM-Konfiguration als Compliance-Kontrolle behandeln — nicht nur als operativen Komfort.
• ABAC (Attribute-Based Access Control) auf Basis von Tags ist mittlerweile das empfohlene Skalierungsmuster für Organisationen mit mehr als einer Handvoll Accounts — dennoch setzen die meisten Teams standardmäßig auf RBAC.
• Die gravierendsten IAM-Fehler, die das SOC von Opsio untersucht, sind keine Privilege Escalations — es sind veraltete Zugangsdaten und überprivilegierte Service-Rollen, die niemand überprüft.

Funktionsweise von AWS IAM: Das Kernmodell

IAM arbeitet nach dem Default-Deny-Prinzip. Jede AWS-API-Anfrage wird gegen eine Reihe von Richtlinien ausgewertet, und sofern die Auswertung kein explizites Allow ergibt — das nicht durch ein Deny überschrieben wird — wird die Anfrage abgelehnt. Das Verständnis dieser Auswertungskette ist das wichtigste Konzept in der AWS-Zugriffskontrolle.

Principals, Actions, Resources und Conditions

Jede IAM-Richtlinienaussage besteht aus vier Komponenten:

• Principal — die Entität, die die Anfrage stellt (IAM-Benutzer, IAM-Rolle, föderierte Identität, AWS-Service)
• Action — die spezifische API-Operation (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — die ARN(s), auf die sich die Aktion bezieht
• Condition — optionale Einschränkungen (Quell-IP, MFA-Status, Tageszeit, Resource Tags)

Eine Richtlinie ist ein JSON-Dokument mit einer oder mehreren Aussagen, die jeweils einen Effect von Allow oder Deny haben. Die Stärke — und die Komplexität — ergibt sich daraus, wie mehrere Richtlinien bei der Auswertung zusammenwirken.

Die Richtlinien-Auswertungskette

Wenn ein Principal innerhalb einer AWS Organization eine Anfrage stellt, erfolgt die Auswertung in dieser Reihenfolge:

1. Service Control Policies (SCPs) — Leitplanken auf Organisationsebene, die die maximal zulässigen Berechtigungen für Mitgliedskonten definieren

2. Resource-based Policies — an die Ressource selbst angehängt (z. B. S3 Bucket Policies, KMS Key Policies)

3. IAM Permission Boundaries — die maximalen Berechtigungen, die eine IAM-Entität haben kann, unabhängig von ihren Identity Policies

4. Session Policies — beim Annehmen einer Rolle übergeben, um die Sitzung weiter einzuschränken

5. Identity-based Policies — die an den IAM-Benutzer, die Gruppe oder die Rolle angehängten Richtlinien

Ein explizites Deny auf jeder Ebene überschreibt alle Allow-Aussagen. Dieses geschichtete Modell ermöglicht die Durchsetzung organisationsweiter Leitplanken (über SCPs), selbst wenn einzelne Account-Administratoren breitere Berechtigungen vergeben.

Das Verständnis dieser Kette ist alles andere als akademisch — das NOC von Opsio verfolgt regelmäßig Access-Denied-Fehler zu SCP-Einschränkungen zurück, von denen Account-Administratoren nichts wussten. Wenn Sie einen 403-Fehler bei einem API-Aufruf beheben, bei dem die Identity Policy eindeutig Allow sagt, prüfen Sie zuerst die SCPs.

IAM-Bausteine in der Praxis

IAM Users vs. IAM Roles vs. Föderierte Identitäten

IAM Users sind langlebige Identitäten mit permanenten Zugangsdaten. Sie existieren noch und funktionieren, doch für menschliche Benutzer sollten sie als veraltet betrachtet werden. Die aktuelle Empfehlung von AWS — und die operative Haltung von Opsio — ist die Föderierung des menschlichen Zugriffs über IAM Identity Center (ehemals AWS SSO), das temporäre Zugangsdaten über SAML 2.0 oder OIDC ausstellt.

IAM Roles sind die Arbeitspferde des modernen AWS IAM. Eine Rolle hat keine permanenten Zugangsdaten; stattdessen nehmen Principals die Rolle an und erhalten temporäre Security Tokens (über AWS STS). Rollen werden eingesetzt für:

• Cross-Account-Zugriff (ein Workload in Account A nimmt eine Rolle in Account B an)
• Service-to-Service-Zugriff (ein EC2 Instance Profile, eine Lambda Execution Role)
• Menschlichen Zugriff via Föderation (Rolle annehmen nach Authentifizierung über Ihren IdP)

Föderierte Identitäten authentifizieren sich gegen einen externen Identity Provider (Okta, Azure AD / Entra ID, Google Workspace) und nehmen IAM-Rollen an. Dies ist das Muster, das jede Organisation mit mehr als zehn Mitarbeitenden für Konsolen- und CLI-Zugriff verwenden sollte.

IAM Policies: Managed, Inline und Custom

AWS Managed Policies (z. B. ReadOnlyAccess, PowerUserAccess) werden von AWS gepflegt und decken gängige Muster ab. Sie sind praktisch, für den Produktionsbetrieb jedoch oft zu breit gefasst. AdministratorAccess ist die am häufigsten zugewiesene Managed Policy, die das SOC von Opsio in Audit-Befunden findet — und sie ist für den täglichen Betrieb fast nie gerechtfertigt.

Customer Managed Policies sind der richtige Standard. Schreiben Sie sie selbst, beschränken Sie sie auf Ihre tatsächlichen Workloads, versionieren Sie sie in Git und deployen Sie sie via Infrastructure as Code (Terraform, CloudFormation oder CDK).

Inline Policies sind direkt in einen Benutzer, eine Gruppe oder eine Rolle eingebettet. Sie haben eine strikte 1:1-Beziehung. Verwenden Sie sie nur, wenn eine Richtlinie nicht versehentlich einer anderen Entität zugewiesen werden darf — was selten vorkommt.

Service Control Policies (SCPs)

SCPs sind die mächtigste — und am häufigsten missverstandene — Ebene im IAM-Stack. Sie vergeben keine Berechtigungen; sie definieren die maximale Grenze dessen, was ein Principal in einem Mitgliedskonto tun kann. Eine SCP, die s3:DeleteBucket verweigert, bedeutet, dass niemand in diesem Account einen Bucket löschen kann, selbst mit AdministratorAccess.

Praxiserprobte SCP-Muster, die Opsio für Kunden implementiert:

• Regionsbeschränkung — Verweigerung aller Aktionen außerhalb von eu-central-1 (Frankfurt), eu-central-2 (Zürich) und eu-west-1 (Irland) zur Durchsetzung der Datensouveränität gemäß DSGVO und Schrems II
• Guardrail-SCPs — Verhinderung der Deaktivierung von CloudTrail, Löschung von VPC Flow Logs oder Modifikation der Audit-IAM-Rolle
• Service-Deny-Liste — Blockierung ungenutzter Services (z. B. Lightsail, GameLift) zur Reduzierung der Angriffsfläche

AWS-Sicherheitsleitplanken

RBAC vs. ABAC: Das richtige Modell wählen

RBAC (Role-Based Access Control)

RBAC in AWS bedeutet, für jede Jobfunktion eigene IAM-Rollen zu erstellen — DevOps-Engineer, Data-Analyst, Security-Auditor — und diesen Rollen Richtlinien zuzuweisen. Es ist intuitiv und funktioniert gut, wenn:

• Sie weniger als ca. 20 unterschiedliche Rollen haben
• Teams klar voneinander getrennt sind
• Die Anzahl der Accounts überschaubar bleibt

Der Nachteil ist die kombinatorische Explosion. Bei 5 Jobfunktionen, 4 Umgebungen (Dev/Staging/Prod/Sandbox) und 3 Projekten können 60 Rollendefinitionen erforderlich werden — jede mit separaten Richtlinien.

ABAC (Attribute-Based Access Control)

ABAC nutzt Tags auf Principals und Ressourcen für Autorisierungsentscheidungen. Statt 60 Rollen schreiben Sie einen kleineren Satz von Richtlinien mit Bedingungen wie:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Damit kann ein Entwickler mit den Tags Project=payments, Environment=dev nur auf die gleichartig getaggten Ressourcen zugreifen — ohne projekt- oder umgebungsspezifische Rollen erstellen zu müssen.

Die IAM-Dokumentation von AWS empfiehlt ABAC ausdrücklich als bevorzugtes Modell für die Skalierung. In der Praxis verwenden die meisten von Opsio verwalteten Organisationen einen Hybridansatz: RBAC für die grobe Trennung nach Jobfunktionen, ABAC für feingranulare Ressourcenzuordnung innerhalb dieser Rollen.

Der operative Haken: ABAC funktioniert nur bei diszipliniertem Tagging. Wenn Teams Ressourcen nicht konsistent taggen, greifen die Bedingungen auf unvorhersehbare Weise zu weit oder zu eng. Erzwingen Sie Tagging-Standards mit SCPs und AWS Config Rules, bevor Sie auf ABAC setzen.

Tag-Governance und FinOps

IAM Best Practices: Was in der Praxis wirklich zählt

Das AWS Well-Architected Framework definiert im Security Pillar IAM Best Practices in fünf Bereichen. Hier beschreiben wir, was sich in Produktionsumgebungen tatsächlich als entscheidend erweist — jenseits der Theorie:

1. Langlebige Access Keys eliminieren

Jeder Access Key ist ein Zugangsdatensatz, der exfiltriert werden kann. Das SOC von Opsio hat Vorfälle untersucht, bei denen Access Keys, die in öffentliche GitHub-Repos eingecheckt wurden, innerhalb von Minuten von automatisierten Scannern ausgenutzt wurden. Die Lösung:

• Verwenden Sie IAM-Rollen mit temporären Zugangsdaten für alle Workloads (EC2 Instance Profiles, ECS Task Roles, Lambda Execution Roles)
• Föderieren Sie den menschlichen Zugriff über IAM Identity Center
• Für die seltenen Fälle, in denen Access Keys unvermeidbar sind (Legacy-Integrationen), erzwingen Sie die Rotation über die AWS Config Rule access-keys-rotated mit einem Höchstalter von 90 Tagen

2. MFA durchsetzen — überall dort, wo es zählt

MFA auf dem Root-Account ist das Minimum. Erzwingen Sie MFA darüber hinaus für:

• Alle menschlichen IAM-Benutzer (sofern Sie noch welche haben)
• Rollenannahme für sensitive Rollen (iam:AssumeRole mit Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• Den Authentifizierungsfluss im IAM Identity Center (Push-Notification-MFA, nicht SMS)

3. Least Privilege iterativ umsetzen

Niemand trifft Least Privilege beim ersten Anlauf perfekt. Der praxistaugliche Ansatz:

1. Starten Sie mit AWS Managed Policies, die etwas breiter sind als nötig

2. Aktivieren Sie IAM Access Analyzer, um zu überwachen, welche Berechtigungen tatsächlich genutzt werden

3. Generieren Sie nach 30–90 Tagen eine Least-Privilege-Policy auf Basis der CloudTrail-Zugriffsaktivitäten

4. Ersetzen Sie die breite Richtlinie durch die generierte

5. Wiederholen Sie dies quartalsweise

Die Policy-Generierungsfunktion von IAM Access Analyzer ist genuinermit nützlich und wird zu wenig eingesetzt. Sie liest CloudTrail-Logs und erzeugt eine Richtlinie, die exakt den tatsächlich aufgerufenen Aktionen und Ressourcen entspricht.

4. Permission Boundaries für delegierte Administration nutzen

Wenn Sie Entwicklern oder Teamleitern erlauben, IAM-Rollen zu erstellen (z. B. für Lambda-Funktionen), setzen Sie eine Permission Boundary, die die maximal möglichen Berechtigungen der erstellten Rollen begrenzt. Ohne diese Grenze kann ein Entwickler eine Rolle mit AdministratorAccess erstellen — was einen Privilege-Escalation-Pfad darstellt.

5. Kontinuierlich prüfen, nicht nur jährlich

Eine jährliche IAM-Überprüfung ist eine Alibi-Übung. Stattdessen:

• Betreiben Sie IAM Access Analyzer kontinuierlich, um externen und ungenutzten Zugriff zu erkennen
• Überwachen Sie anomale IAM-API-Aufrufe via CloudTrail + Amazon GuardDuty
• Nutzen Sie AWS Config Rules, um nicht-konforme IAM-Konfigurationen automatisch zu kennzeichnen
• Leiten Sie Findings in ein zentrales SIEM oder die Alerting-Pipeline Ihres SOC weiter

24/7-SOC-Monitoring

IAM in einer Multi-Account AWS Organization

Einzelne AWS-Accounts in Produktionsumgebungen werden zunehmend seltener. AWS Organizations in Kombination mit IAM Identity Center ist das Standardmuster für die Zugriffsverwaltung über Dutzende oder Hunderte von Accounts hinweg.

IAM Identity Center (ehemals AWS SSO)

IAM Identity Center bietet eine zentrale Stelle zur Verwaltung des menschlichen Zugriffs über alle Accounts Ihrer Organisation. Benutzer authentifizieren sich einmal (über Ihren unternehmenseigenen IdP oder das integrierte Verzeichnis) und erhalten temporäre Zugangsdaten für den jeweils ausgewählten Account und Permission Set.

Permission Sets in IAM Identity Center sind Abstraktionen, die in jedem Ziel-Account IAM-Rollen erstellen. Sie definieren sie einmal zentral und weisen sie Benutzern oder Gruppen pro Account zu. Das ist drastisch einfacher als die unabhängige Verwaltung von IAM-Rollen in jedem einzelnen Account.

Cross-Account Role Assumption

Für Service-to-Service-Zugriff über Account-Grenzen hinweg (z. B. eine CI/CD-Pipeline im Tooling-Account, die in Produktion deployt) lautet das Muster:

1. Erstellen Sie eine Rolle im Ziel-Account mit einer Trust Policy, die die Rolle des Quell-Accounts erlaubt

2. Der Quell-Workload ruft sts:AssumeRole auf, um temporäre Zugangsdaten zu erhalten

3. Verwenden Sie External IDs, um Confused-Deputy-Angriffe zu verhindern, wenn Dritte involviert sind

Opsio konfiguriert den Cross-Account-Zugriff nach einem Hub-and-Spoke-Modell: Ein zentraler Security-Account hält Audit-Rollen, die in alle Mitgliedskonten lesen (aber nicht schreiben) können. Dieses Design unterstützt sowohl den SOC-Betrieb als auch die Erhebung von Compliance-Nachweisen.

Multi-Account-Strategie

Compliance-Dimensionen: NIS2, DSGVO und BSI C5

Die IAM-Konfiguration wird in jedem bedeutenden Compliance-Framework, dem Opsio begegnet, direkt referenziert:

NIS2-Richtlinie (EU) — Artikel 21 fordert „Konzepte für die Zugriffskontrolle" einschließlich Privileged Access Management. Organisationen, die als wesentliche oder wichtige Einrichtungen eingestuft werden, müssen nachweisen, dass IAM-Kontrollen dem Risiko angemessen sind, dass privilegierter Zugriff überwacht wird und dass regelmäßige Zugriffsüberprüfungen stattfinden. Für AWS übersetzt sich das in SCPs, CloudTrail, IAM Access Analyzer und dokumentierte Verfahren zur Zugriffsüberprüfung.

DSGVO — Artikel 32 verlangt „die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme und -dienste auf Dauer sicherzustellen", was von Aufsichtsbehörden als einschließlich Identity and Access Management interpretiert wird. Verantwortliche müssen nachweisen, dass der Zugang zu personenbezogenen Daten auf das Personal beschränkt ist, das ihn benötigt — was IAM-Richtlinien bedeutet, die auf spezifische DynamoDB-Tabellen, S3-Prefixes oder RDS-Instanzen mit PII beschränkt sind. Im Kontext von Schrems II ist zudem sicherzustellen, dass Zugriffe aus Drittstaaten technisch unterbunden werden — regionale SCPs in eu-central-1 (Frankfurt) sind hier ein zentrales Instrument.

BSI C5 (Deutschland) — Der Cloud Computing Compliance Criteria Catalogue des BSI adressiert in den Bereichen IDM (Identity and Access Management) explizit die Anforderungen an Zugriffskontrolle, Privilegierte-Zugangs-Verwaltung und Audit-Protokollierung. Für Organisationen, die Cloud-Dienste in der Region Germany West Central (Azure) oder eu-central-1 (AWS Frankfurt) betreiben, sind dokumentierte IAM-Kontrollen, nachvollziehbare Audit-Trails und regelmäßige Berechtigungsreviews essenzielle Nachweispflichten im Rahmen von C5-Audits.

Der gemeinsame Nenner: Alle drei Frameworks verlangen nicht nur, dass Kontrollen existieren, sondern dass sie überwacht und regelmäßig überprüft werden. IAM-Konfiguration ohne CloudTrail-Logging und regelmäßige Zugriffsüberprüfungen erfüllt keines davon.

Häufige IAM-Fehler, die das SOC von Opsio vorfindet

Basierend auf tatsächlichen Vorfällen und Audit-Befunden über unsere Managed Accounts hinweg:

1. Wildcard-Ressourcen-ARNs in Produktionsrichtlinien — "Resource": "*" ist beim Prototyping akzeptabel. In der Produktion bedeutet es, dass ein kompromittierter Principal auf jede Ressource dieses Typs im Account zugreifen kann.

2. Service-Rollen mit AdministratorAccess — Lambda-Funktionen und ECS-Tasks sollten eng gefasste Execution Roles haben. Das Anhängen von Admin-Rechten „weil es einfacher ist" macht jede Anwendungsschwachstelle zu einer vollständigen Account-Kompromittierung.

3. Keine SCP-Leitplanken für Mitgliedskonten — Ohne SCPs kann jeder Account-Administrator sich selbst beliebige Rechte erteilen. SCPs sind der einzige Mechanismus, der sogar den Root-Benutzer des Accounts (in Mitgliedskonten) einschränkt.

4. Veraltete IAM-Benutzer und Access Keys — Wir finden regelmäßig IAM-Benutzer für Mitarbeitende, die die Organisation vor Monaten oder Jahren verlassen haben. Nutzen Sie die AWS Config Rule iam-user-unused-credentials-check und setzen Sie den Schwellenwert auf 45 Tage Inaktivität.

5. Ignorieren von Resource-based Policies — S3 Bucket Policies, KMS Key Policies und SQS Queue Policies können unabhängig von Identity Policies Zugriff gewähren. Ein S3-Bucket mit "Principal": "*" in seiner Bucket Policy ist öffentlich zugänglich, unabhängig davon, wie restriktiv Ihre IAM-Rollen sind.

Erste Schritte: Eine praxistaugliche Reihenfolge

Für Organisationen, die noch keine formalisierte IAM-Governance haben, liefert die folgende Reihenfolge am schnellsten Ergebnisse:

1. CloudTrail aktivieren in allen Accounts, allen Regionen, mit Logging in einen zentralen S3-Bucket in einem dedizierten Log-Archive-Account

2. IAM Access Analyzer aktivieren in jedem Account (kostenlos)

3. Menschlichen Zugriff migrieren von IAM Users auf IAM Identity Center mit MFA

4. Baseline-SCPs deployen — ungenutzte Regionen sperren, Audit-Infrastruktur schützen, Verschlüsselung erzwingen

5. Bestehende IAM-Rollen und -Richtlinien auditieren — Access-Analyzer-Findings nutzen, um ungenutzte Rollen und überprivilegierte Richtlinien zu identifizieren

6. Infrastructure as Code implementieren für alle IAM-Ressourcen — kein ClickOps mehr in der IAM-Konsole

Cloud-Migration und -Modernisierung

Diese Reihenfolge funktioniert unabhängig davon, ob Sie 2 oder 200 Accounts haben. Der Unterschied liegt nur darin, wie lange Schritt 5 dauert.

Häufig gestellte Fragen

Was sind IAM Access Controls?

IAM Access Controls sind die Richtlinien, Rollen und Mechanismen innerhalb von AWS Identity and Access Management, die bestimmen, welche Principals (Benutzer, Rollen, Dienste) welche Aktionen auf welchen Ressourcen ausführen dürfen. Sie arbeiten nach dem Default-Deny-Prinzip: Sofern eine Richtlinie eine Aktion nicht ausdrücklich erlaubt, wird sie abgelehnt. Zu den Kontrollen gehören Identity-based Policies, Resource-based Policies, Permission Boundaries, Session Policies und Service Control Policies auf Organisationsebene.

Ist IAM RBAC oder ABAC?

AWS IAM unterstützt beides. Rollenbasierte Zugriffskontrolle (RBAC) wird durch die Erstellung von IAM-Rollen mit spezifischen Berechtigungssätzen und deren Zuweisung an Benutzer oder Gruppen umgesetzt. Attributbasierte Zugriffskontrolle (ABAC) nutzt Tags auf Principals und Ressourcen für dynamische Autorisierungsentscheidungen. AWS empfiehlt ABAC für die Skalierung über viele Accounts hinweg, da es die Anzahl unterschiedlicher Richtlinien reduziert. Die meisten Produktionsumgebungen verwenden eine Kombination aus beiden Modellen.

Was ist IAM Access in AWS?

IAM Access in AWS bezeichnet die authentifizierte und autorisierte Fähigkeit eines Principals — eines IAM-Benutzers, einer föderierten Identität oder einer IAM-Rolle — mit AWS-Services und -Ressourcen zu interagieren. Jeder API-Aufruf an AWS wird gegen IAM-Richtlinien ausgewertet. Zugriff wird nur gewährt, wenn die anwendbaren Richtlinien ein explizites Allow ergeben und keine anwendbare Richtlinie ein explizites Deny erzeugt.

Was sind die 4 Säulen von IAM?

Die vier Säulen, die im Identity Management üblicherweise genannt werden, sind: Authentifizierung (Nachweis der Identität), Autorisierung (welche Aktionen erlaubt sind), Administration (Verwaltung von Identitäten und Richtlinien im großen Maßstab) und Auditing (Protokollierung und Überprüfung von Zugriffsaktivitäten). In AWS-Begriffen entsprechen diese den IAM-Authentifizierungsmechanismen, IAM Policies, AWS Organizations/IAM Identity Center und AWS CloudTrail.

Wie hängt AWS IAM mit der NIS2-Compliance zusammen?

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen die Implementierung risikogerechter Zugriffskontrollrichtlinien, Incident-Response-Fähigkeiten sowie den Nachweis der Kontrolle über privilegierten Zugriff. AWS IAM stellt die technischen Kontrollen bereit — MFA, Least-Privilege-Richtlinien, SCPs, CloudTrail-Logging — doch Compliance erfordert dokumentierte Prozesse, regelmäßige Zugriffsüberprüfungen und den Nachweis, dass diese Kontrollen aktiv überwacht werden. Ein Managed SOC schließt die Lücke zwischen vorhandenen Kontrollen und deren nachweisbarer Wirksamkeit.