Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Richtlinien und Berechtigungen in AWS Identity and Access Management
Verwalten Sie den Zugriff, AWS indem Sie Richtlinien erstellen und diese an IAM-Identitäten (Benutzer, Benutzergruppen oder Rollen) oder Ressourcen anhängen. AWS Eine Richtlinie ist ein Objekt, AWS das, wenn es einer Identität oder Ressource zugeordnet ist, deren Berechtigungen definiert. AWS wertet diese Richtlinien aus, wenn ein IAM-Prinzipal (Benutzer oder Rolle) eine Anfrage stellt. Die Berechtigungen in den Richtlinien legen fest, ob eine Anforderung zugelassen oder abgelehnt wird. Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. AWS unterstützt sieben Arten von Richtlinien: identitätsbasierte Richtlinien, ressourcenbasierte Richtlinien, Berechtigungsgrenzen, AWS Organizations Dienststeuerungsrichtlinien (SCPs), AWS Organizations Ressourcensteuerungsrichtlinien (RCPs), Zugriffskontrolllisten (ACLs) und Sitzungsrichtlinien.
IAM-Richtlinien definieren Berechtigungen für eine Aktion unabhängig von der Methode, die Sie zur Ausführung der Aktion verwenden. Wenn eine Richtlinie die [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)Aktion beispielsweise zulässt, kann ein Benutzer mit dieser Richtlinie Benutzerinformationen von der AWS-Managementkonsole, der oder der AWS CLI API abrufen. AWS Wenn Sie einen IAM-Benutzer erstellen, können Sie auswählen, ob Konsolen- oder Programmzugriff erlaubt sind. Wenn Konsolenzugriff erlaubt ist, kann sich der IAM-Benutzer mit seinen Anmeldeinformationen an der Konsole anmelden. Wenn der programmatische Zugriff zulässig ist, kann der Benutzer Zugriffsschlüssel verwenden, um mit der CLI oder der API zu arbeiten.
## Richtlinientypen
Die folgenden Richtlinientypen, aufgelistet in der Reihenfolge von am häufigsten verwendeten bis zu seltener verwendeten, stehen für die Verwendung in AWS. Weitere Informationen finden Sie in den folgenden Abschnitten zu den einzelnen Richtlinientypen.
+ **[Identitätsbasierte Richtlinien](#policies_id-based)** – Fügen Sie [verwaltete](#managedpolicy) und -Richtlinien an IAM-Identitäten (Benutzer, Gruppen, zu denen Benutzer gehören, oder Rollen) an. Identitätsbasierte Richtlinien erteilen Berechtigungen für eine Identität.
+ **[Ressourcenbasierte Richtlinien](#policies_resource-based)** – Fügen Inline-Richtlinien an Ressourcen an. Die häufigsten Beispiele für ressourcenbasierte Richtlinien sind Amazon S3-Bucket-Richtlinien und Vertrauensrichtlinien für IAM-Rollen. Ressourcenbasierte Richtlinien erteilen dem Auftraggeber Berechtigungen, der in der Richtlinie angegeben ist. Auftraggeber können sich in demselben Konto wie die Ressource oder in anderen Konten befinden.
+ **[Berechtigungsgrenzen](#policies_bound)** – Verwenden Sie eine verwaltete Richtlinie als Berechtigungsgrenze für eine IAM-Entität (Benutzer oder Rolle). Diese Richtlinie definiert die maximalen Berechtigungen, die die identitätsbasierten Richtlinien einer Entität erteilen können, sie erteilt jedoch keine Berechtigungen. Berechtigungsgrenzen definieren nicht die maximalen Berechtigungen, die eine ressourcenbasierte Richtlinie einer Entität erteilen kann.
+ **[AWS Organizations SCPs](#policies_scp)**— Verwenden Sie eine AWS Organizations Service Control Policy (SCP), um die maximalen Berechtigungen für IAM-Benutzer und IAM-Rollen innerhalb von Konten in Ihrer Organisation oder Organisationseinheit (OU) zu definieren. SCPs beschränken Sie die Berechtigungen, die identitätsbasierte Richtlinien oder ressourcenbasierte Richtlinien IAM-Benutzern oder IAM-Rollen innerhalb des Kontos gewähren. SCPs gewähren Sie keine Berechtigungen.
+ **[AWS Organizations RCPs](#policies_rcp)**— Verwenden Sie eine AWS Organizations Ressourcenkontrollrichtlinie (RCP), um die maximalen Berechtigungen für Ressourcen innerhalb von Konten in Ihrer Organisation oder Organisationseinheit (OU) zu definieren. RCPs schränken Sie die Berechtigungen ein, die identitäts- und ressourcenbasierte Richtlinien Ressourcen in Konten innerhalb Ihrer Organisation gewähren können. RCPs gewähren Sie keine Berechtigungen.
+ **[Zugriffskontrolllisten (ACLs)](#policies_acl)** — Wird verwendet ACLs , um zu steuern, welche Principals in anderen Konten auf die Ressource zugreifen können, an die die ACL angehängt ist. ACLs ähneln ressourcenbasierten Richtlinien, obwohl sie der einzige Richtlinientyp sind, der nicht die JSON-Richtliniendokumentstruktur verwendet. ACLs sind kontoübergreifende Berechtigungsrichtlinien, die dem angegebenen Prinzipal Berechtigungen gewähren. ACLs kann Entitäten innerhalb desselben Kontos keine Berechtigungen gewähren.
+ **[Sitzungsrichtlinien](#policies_session)** — Übergeben Sie erweiterte Sitzungsrichtlinien, wenn Sie die AWS API AWS CLI oder verwenden, um eine Rolle oder einen Verbundbenutzer anzunehmen. Sitzungsrichtlinien begrenzen die Berechtigungen, die die identitätsbasierten Richtlinien der Rolle oder des Benutzers der Sitzung zu gewähren. Sitzungsrichtlinien begrenzen Berechtigungen für eine erstellte Sitzung, aber sie gewähren keine Berechtigungen. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)
### Identitätsbasierte Richtlinien
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die steuern, welche Aktionen eine Identität (Benutzer, Benutzergruppen und Rollen) für welche Ressourcen und unter welchen Bedingungen ausführen kann. Identitätsbasierte Richtlinien können weiter kategorisiert werden:
+ **Verwaltete Richtlinien** — Eigenständige identitätsbasierte Richtlinien, die Sie mehreren Benutzern, Gruppen und Rollen in Ihrem System zuordnen können. AWS-Konto Es gibt zwei Typen von verwalteten Richtlinien:
+ **AWS verwaltete Richtlinien** — Verwaltete Richtlinien, die von erstellt und verwaltet werden. AWS
+ **Vom Kunden verwaltete Richtlinien** – Dies sind verwaltete Richtlinien, die Sie in Ihrem AWS-Konto erstellen und verwalten. Vom Kunden verwaltete Richtlinien bieten eine genauere Kontrolle über Ihre Richtlinien als AWS verwaltete Richtlinien.
+ **Inline-Richtlinien** – Richtlinien, die Sie direkt zu einem einzelnen Benutzer, einer einzelnen Gruppe oder einer einzelnen Rolle hinzufügen. Inline-Richtlinien sorgen für eine strikte one-to-one Beziehung zwischen einer Richtlinie und einer Identität. Sie werden gelöscht, wenn Sie die Identität löschen.
Informationen darüber, wie Sie entscheiden können, ob Sie eine verwaltete Richtlinie oder eine Inline-Richtlinie verwenden sollten, finden Sie unter [Auswahl zwischen verwalteten Richtlinien und Inline-Richtlinien](access_policies-choosing-managed-or-inline.md).
### Ressourcenbasierte Richtlinien
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource wie einen Amazon S3-Bucket anfügen. Diese Richtlinien erteilen dem angegebenen Auftraggeber die Berechtigung zum Ausführen bestimmter Aktionen für diese Ressource und definiert, unter welchen Bedingungen dies gilt. Ressourcenbasierte Richtlinien sind Inline-Richtlinien. Es gibt keine verwalteten ressourcenbasierten Richtlinien.
Um kontoübergreifenden Zugriff zu ermöglichen, können Sie ein gesamtes Konto oder IAM-Entitäten in einem anderen Konto als Auftraggeber in einer ressourcenbasierten Richtlinie angeben. Durch das Hinzufügen eines kontoübergreifenden Auftraggebers zu einer ressourcenbasierten Richtlinie ist nur die halbe Vertrauensbeziehung eingerichtet. Wenn der Prinzipal und die Ressource getrennt sind AWS-Konten, müssen Sie außerdem eine identitätsbasierte Richtlinie verwenden, um dem Prinzipal Zugriff auf die Ressource zu gewähren. Wenn jedoch eine ressourcenbasierte Richtlinie Zugriff auf einen Auftraggeber in demselben Konto gewährt, ist keine zusätzliche identitätsbasierte Richtlinie erforderlich. Eine Schritt-für-Schritt-Anleitung für die Gewährung von dienstübergreifendem Zugriff finden Sie unter [IAM-Tutorial: Delegieren Sie den Zugriff über AWS Konten hinweg mithilfe von IAM-Rollen](tutorial_cross-account-with-roles.md).
Der IAM-Service unterstützt nur eine Art von ressourcenbasierter Richtlinie, die als Rollen-*Vertrauensrichtlinie* bezeichnet wird, die einer IAM-Rolle zugewiesen ist. Eine IAM-Rolle ist sowohl eine Identität als auch eine Ressource, die ressourcenbasierte Richtlinien unterstützt. Aus diesem Grund müssen Sie einer IAM-Rolle eine Vertrauensrichtlinie und eine identitätsbasierte Richtlinie anfügen. Vertrauensrichtlinien definieren, welche Auftraggeber-Entitäten (Konten, Benutzer, Rollen und Verbundbenutzer) die Rolle übernehmen können. Informationen darüber, inwieweit sich IAM-Rollen von anderen ressourcenbasierten Richtlinien unterscheiden, finden Sie unter [Kontoübergreifender Zugriff auf Ressourcen in IAM](access_policies-cross-account-resource-access.md).
Informationen darüber, welche anderen Services ressourcenbasierte Richtlinien unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md). Weitere Informationen zu ressourcenbasierten Richtlinien finden Sie unter [Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien](access_policies_identity-vs-resource.md). Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Was ist IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
### IAM-IBerechtigungsgrenzen
Eine Berechtigungsgrenze ist ein erweitertes Feature, die Ihnen ermöglicht, die maximalen Berechtigungen festzulegen, die eine identitätsbasierte Richtlinie einer IAM-Entität gewähren kann. Wenn Sie eine Berechtigungsgrenze für eine Entität festlegen, kann die Entität nur die Aktionen durchführen, die sowohl von den identitätsbasierten Richtlinien als auch den Berechtigungsgrenzen erlaubt werden. Wenn Sie im Hauptelement einer ressourcenbasierten Richtlinie eine Rollensitzung oder einen Benutzer angeben, ist eine explizite Zulassung in der Berechtigungsgrenze nicht erforderlich. Wenn Sie jedoch eine Rollen-ARN im Hauptelement einer ressourcenbasierten Richtlinie angeben, ist eine explizite Zulassung in der Berechtigungsgrenze erforderlich. In beiden Fällen ist eine explizite Verweigerung der Berechtigungsgrenze wirksam. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft. Weitere Informationen über Berechtigungsgrenzen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](access_policies_boundaries.md).
### AWS Organizations Richtlinien zur Dienststeuerung () SCPs
Wenn Sie alle Funktionen in einer Organisation aktivieren, können Sie Dienststeuerungsrichtlinien (SCPs) auf einige oder alle Ihre Konten anwenden. SCPs sind JSON-Richtlinien, die die maximalen Berechtigungen für IAM-Benutzer und IAM-Rollen innerhalb der Konten einer Organisation oder Organisationseinheit (OU) festlegen. Das SCP beschränkt die Berechtigungen für Prinzipale in Mitgliedskonten, einschließlich der einzelnen Konten. Root-Benutzer des AWS-Kontos Eine explizite Verweigerung in einer dieser Richtlinien überschreibt eine Zulassung in anderen Richtlinien.
Weitere Informationen zu AWS Organizations und SCPs finden Sie unter [Richtlinien zur Dienststeuerung (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations Benutzerhandbuch*.
### AWS Organizations Richtlinien zur Ressourcensteuerung (RCPs)
Wenn Sie alle Funktionen in einer Organisation aktivieren, können Sie Ressourcensteuerungsrichtlinien (RCPs) verwenden, um Zugriffskontrollen zentral auf mehrere Ressourcen anzuwenden AWS-Konten. RCPs sind JSON-Richtlinien, mit denen Sie die maximal verfügbaren Berechtigungen für Ressourcen in Ihren Konten festlegen können, ohne die IAM-Richtlinien aktualisieren zu müssen, die jeder Ressource zugeordnet sind, deren Eigentümer Sie sind. Das RCP schränkt die Berechtigungen für Ressourcen in Mitgliedskonten ein und kann sich auf die effektiven Berechtigungen für Identitäten auswirken, einschließlich der Root-Benutzer des AWS-Kontos, unabhängig davon, ob sie zu Ihrer Organisation gehören. Eine explizite Verweigerung in einer anwendbaren RCP überschreibt eine Genehmigung in anderen Richtlinien, die möglicherweise einzelnen Identitäten oder Ressourcen angefügt sind.
Weitere Informationen zu AWS Organizations und RCPs einschließlich einer Liste AWS-Services dieser Unterstützung RCPs finden Sie unter [Richtlinien zur Ressourcenkontrolle (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) im *AWS Organizations Benutzerhandbuch*.
### Zugriffskontrolllisten (ACLs)
Zugriffskontrolllisten (ACLs) sind Dienstrichtlinien, mit denen Sie steuern können, welche Principals in einem anderen Konto auf eine Ressource zugreifen können. ACLs kann nicht verwendet werden, um den Zugriff für einen Prinzipal innerhalb desselben Kontos zu steuern. ACLs ähneln ressourcenbasierten Richtlinien, obwohl sie der einzige Richtlinientyp sind, der nicht das JSON-Richtliniendokumentformat verwendet. Amazon S3 und Amazon VPC sind Beispiele für Dienste, die Unterstützung ACLs bieten. AWS WAF Weitere Informationen finden Sie in der [Übersicht über ACLs die Access Control List (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) im *Amazon Simple Storage Service Developer Guide*.
### Sitzungsrichtlinien
Sitzungsrichtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie programmgesteuert eine temporäre Sitzung für eine Rolle oder einen AWS STS Verbundbenutzerprinzipal erstellen. Die Berechtigungen für eine Sitzung stammen aus den identitätsbasierten Richtlinien für die IAM-Entität (Benutzer oder Rolle), die zum Erstellen der Sitzung und der Sitzungsrichtlinie verwendet wurde. Berechtigungen können auch aus einer ressourcenbasierten Richtlinie stammen. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft.
Sie können eine Rollensitzung erstellen und eine Sitzungsrichtlinie programmgesteuert mithilfe der API-Operationen `AssumeRole`, `AssumeRoleWithSAML` oder `AssumeRoleWithWebIdentity` übergeben. Sie können ein einzelnes JSON-Inline-Sitzungsrichtliniendokument mit dem `Policy`-Parameter übergeben. Sie können mit dem Parameter `PolicyArns` bis zu 10 verwaltete Sitzungsrichtlinien angeben. Weitere Informationen zum Erstellen einer Rollensitzung finden Sie unter [Berechtigungen für temporäre Sicherheits-Anmeldeinformationen](id_credentials_temp_control-access.md).
Wenn Sie eine AWS STS föderierte Benutzerprinzipalsitzung erstellen, verwenden Sie die Zugriffsschlüssel des IAM-Benutzers, um den API-Vorgang programmgesteuert aufzurufen. `GetFederationToken` Außerdem müssen Sie Sitzungsrichtlinien übergeben. Die resultierenden Sitzungsberechtigungen stammen aus der identitätsbasierten Richtlinie und der Sitzungsrichtlinie. Weitere Informationen zum Erstellen von einer Sitzung für Verbundbenutzer finden Sie unter [Anfordern von Anmeldeinformationen über einen benutzerdefinierten Identity Broker](id_credentials_temp_request.md#api_getfederationtoken).
Eine ressourcenbasierte Richtlinie kann den ARN des Benutzers oder der Rolle als Auftraggeber angeben. In diesem Fall werden die Berechtigungen aus der ressourcenbasierten Richtlinie an die Rolle oder die identitätsbasierte Richtlinie des Benutzers vor der Erstellung der Sitzung hinzugefügt. Die Sitzungsrichtlinie beschränkt die Gesamtzahl der Berechtigungen, die von der ressourcenbasierten Richtlinie und der identitätsbasierten Richtlinie erteilt werden. Die resultierenden Sitzungsberechtigungen ergeben sich aus den Sitzungsrichtlinien und entweder der ressourcenbasierten Richtlinie oder der identitätsbasierten Richtlinie.
![\[Auswertung der Sitzungsrichtlinie mit einer ressourcenbasierten Richtlinie, die den Entitäts-ARN angibt\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-session-rbp-id.png)
Eine ressourcenbasierte Richtlinie kann den ARN der Sitzung als Auftraggeber angeben. In diesem Fall werden die Berechtigungen aus der ressourcenbasierten Richtlinie nach dem Erstellen der Sitzung hinzugefügt. Die Berechtigungen der ressourcenbasierte Richtlinie werden nicht von der Sitzungsrichtlinie eingeschränkt. Die resultierende Sitzung verfügt über alle Berechtigungen der ressourcenbasierten Richtlinie *plus* die Berechtigungen, die sowohl von der identitätsbasierten Richtlinie als auch von der Sitzungsrichtlinie erteilt werden.
![\[Auswertung der Sitzungsrichtlinie mit einer ressourcenbasierten Richtlinie, die den Sitzungs-ARN angibt\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-session-rbpsession-id.png)
Ein Berechtigungsgrenze kann für einen Benutzer oder eine Rolle die Höchstzahl der Berechtigungen festlegen, die für die Erstellung der Sitzung verwendet werden. In diesem Fall ergeben sich die resultierenden Sitzungsberechtigungen aus der Sitzungsrichtlinie, der Berechtigungsgrenze und der identitätsbasierten Richtlinie. Eine Berechtigungsgrenze schränkt jedoch nicht die Berechtigungen ein, die von einer ressourcenbasierten Richtlinie gewährt werden, die den ARN der resultierenden Sitzung angibt.
![\[Auswertung der Sitzungsrichtlinie mit einer Berechtigungsgrenze\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## Richtlinien und Stammbenutzer
Die Root-Benutzer des AWS-Kontos wird von einigen Richtlinientypen beeinflusst, von anderen jedoch nicht. Sie können dem Stammbenutzer keine identitätsbasierten Richtlinien zuweisen und Sie können die Berechtigungsgrenze für den Stammbenutzer nicht festlegen. Sie können jedoch die Stammbenutzer; als Auftraggeber in einer ressourcenbasierten Richtlinie oder einer ACL angeben. Ein Stammbenutzer ist immer noch das Mitglied eines Kontos. Wenn dieses Konto Mitglied einer Organisation in ist AWS Organizations, ist der Root-Benutzer von SCPs und RCPs für das Konto betroffen.
## Übersicht über JSON-Richtlinien
Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. Identitätsbasierte Richtlinien und Richtlinien zum Festlegen von Berechtigungsgrenzen sind JSON-Richtliniendokumente, die Sie einem Benutzer oder einer Rolle anfügen. Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anhängen. SCPsund RCPs sind JSON-Richtliniendokumente mit eingeschränkter Syntax, die Sie an den AWS Organizations„Organisationsstamm“, die Organisationseinheit (OU) oder ein Konto anhängen. ACLs sind ebenfalls an eine Ressource angehängt, aber Sie müssen eine andere Syntax verwenden. Sitzungsrichtlinien sind JSON-Richtlinien, die Sie bereitstellen, wenn Sie in einer Sitzung eine Rolle oder einen Verbundbenutzer übernehmen.
Es ist nicht notwendig, dass Sie die JSON-Syntax verstehen. Sie können den visuellen Editor in verwenden, AWS-Managementkonsole um vom Kunden verwaltete Richtlinien zu erstellen und zu bearbeiten, ohne jemals JSON verwenden zu müssen. Wenn Sie jedoch eingebundene Richtlinien für Gruppen oder komplexe Richtlinien verwenden, müssen Sie diese Richtlinien im JSON-Editor unter Verwendung der Konsole erstellen und bearbeiten. Weitere Informationen zur Verwendung des visuellen Editors finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md) und [IAM-Richtlinien bearbeiten](access_policies_manage-edit.md).
Wenn Sie eine JSON-Richtlinie erstellen oder bearbeiten, kann IAM eine Richtlinienvalidierung durchführen, um Ihnen beim Erstellen einer effektiven Richtlinie zu helfen. IAM identifiziert JSON-Syntaxfehler, während IAM Access Analyzer zusätzliche Richtlinienüberprüfungen mit Empfehlungen zur weiteren Verfeinerung Ihrer Richtlinien bietet. Weitere Informationen zur Richtlinienvalidierung finden Sie unter [IAM-Richtlinien-Validierung](access_policies_policy-validator.md). Weitere Informationen zu IAM Access Analyzer Richtlinienvalidierungen und umsetzbaren Empfehlungen finden Sie unter [ IAM Access Analyzer-Richtlinienvalidierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
### JSON-Richtliniendokumentstruktur
Wie in der folgenden Abbildung dargestellt, umfasst ein JSON-Richtliniendokument die folgenden Elemente:
+ Optionale richtlinienweite Informationen oben im Dokument.
+ Eine oder mehrere einzelne Anweisungen**
Jede Anweisung enthält Angaben über die jeweilige Berechtigung. Wenn eine Richtlinie mehrere Aussagen enthält, AWS wendet sie bei deren Auswertung `OR` eine logische Anweisung für alle Anweisungen an. Wenn mehrere Richtlinien auf eine Anfrage AWS zutreffen, wird bei der Bewertung eine logische Regel `OR` auf alle diese Richtlinien angewendet.
![\[JSON-Richtliniendokumentstruktur\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png)
Die Informationen in einer Anweisung sind in einer Reihe von Elementen enthalten.
+ **Version** – Geben Sie die Version der Richtliniensprache an, die Sie verwenden möchten. Wir empfehlen, dass Sie die neueste Version `2012-10-17 ` verwenden. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Version](reference_policies_elements_version.md).
+ **Statement** – Verwenden Sie dieses Haupt-Richtlinienelement als Container für die folgenden Elemente. Sie können mehrere Anweisungen in eine Richtlinie aufnehmen.
+ **Sid** (Optional) – Fügen Sie eine optionale Statement-ID an, um Ihre Anweisungen unterscheiden zu können.
+ **Effect** – Verwenden Sie `Allow` oder `Deny`, um anzugeben, ob die Richtlinie den Zugriff erlaubt oder verweigert.
+ **Principal**(Unter bestimmten Umständen erforderlich) — Wenn Sie eine ressourcenbasierte Richtlinie erstellen, müssen Sie das Konto, den Benutzer, die Rolle oder den AWS STS Verbundbenutzerprinzipal angeben, für das Sie den Zugriff gewähren oder verweigern möchten. Wenn Sie eine IAM-Berechtigung zum Anfügen für einen Benutzer oder eine Rolle erstellen, können Sie dieses Element nicht aufnehmen. Der Auftraggeber wird als dieser Benutzer oder diese Rolle impliziert.
+ **Action** – Binden Sie eine Liste der Aktionen ein, die durch die Richtlinie erlaubt oder verweigert werden.
+ **Resource** (In einigen Fällen erforderlich) – Wenn Sie eine IAM-Berechtigungsrichtlinie erstellen, müssen Sie eine Liste der Ressourcen angeben, für die die Aktionen gelten. Wenn Sie eine ressourcenbasierte Richtlinie erstellen, hängt es von der verwendeten Ressource ab, ob dieses Element erforderlich ist oder nicht.
+ **Condition** (Optional) – Geben Sie die Bedingungen an, unter denen die Richtlinie die Berechtigung erteilt.
Weitere Informationen zu diesen und erweiterten Richtlinienelementen finden Sie unter [Referenz zum IAM-JSON-Richtlinienelement](reference_policies_elements.md).
### Mehrere Anweisungen und mehrere Richtlinien
Wenn Sie mehr als eine Berechtigung für eine Entity (Benutzer, Gruppe oder Rolle) definieren möchten, können Sie in einer einzigen Richtlinie mehrere Anweisungen verwenden. Sie können auch mehrere Richtlinien anfügen. Wenn Sie versuchen, mehrere Berechtigungen in einer einzigen Anweisung zu definieren, gewährt Ihre Richtlinie möglicherweise nicht den Zugriff, den Sie erwarten. Wir empfehlen, dass Sie die Richtlinien nach Ressourcentypen aufteilen.
Aufgrund der [eingeschränkten Größe der Richtlinien](reference_iam-quotas.md)müssen Sie für komplexere Berechtigungen möglicherweise mehrere Richtlinien verwenden. Es ist auch sinnvoll, funktionale Gruppierungen von Berechtigungen in einer separaten, vom Kunden verwalteten Richtlinie zu erstellen. Beispiel: Erstellen Sie eine Richtlinie für die IAM-Benutzerverwaltung, eine für die Selbstverwaltung und eine weitere Richtlinie für die Verwaltung von S3-Buckets. Unabhängig von der Kombination mehrerer Aussagen und mehrerer Richtlinien werden Ihre Richtlinien auf AWS [dieselbe Weise bewertet](reference_policies_evaluation-logic.md).
Die folgende Richtlinie enthält beispielsweise drei Anweisungen, von denen jede einen eigenen Satz Berechtigungen innerhalb eines einzelnen Kontos definiert. Die Anweisungen definieren Folgendes:
+ Mit der ersten Anweisung mit der `Sid` (Statement-ID) `FirstStatement` kann der Benutzer mit der zugeordneten Richtlinie das eigene Passwort ändern. Das `Resource`-Element in dieser Anweisung ist `*` (das bedeutet "alle Ressourcen"). In der Praxis wirkt sich die API-Operation `ChangePassword` (oder der entsprechende CLI-Befehl `change-password`) praktisch nur auf das Passwort des Benutzers aus, der die Anforderung gestellt hat.
+ Über die zweite Anweisung kann der Benutzer alle Amazon S3-Buckets in seinem AWS-Konto auflisten. Das `Resource`-Element in dieser Anweisung ist `"*"` (das bedeutet "alle Ressourcen"). Da aber Richtlinien den Zugriff nicht auf Ressourcen in anderen Konten erteilen können, kann der Benutzer nur die Buckets in seinem eigenen AWS-Konto auflisten.
+ Durch die dritte Anweisung kann der Benutzer beliebige Objekte auflisten und abrufen, die sich in einem Bucket mit dem Namen `amzn-s3-demo-bucket-confidential-data` befinden. Allerdings ist dazu die Authentifizierung des Benutzers durch eine Multi-Factor Authentication (MFA) erforderlich. Das `Condition`-Element in der Richtlinie erzwingt die MFA-Authentifizierung.
Wenn eine Richtlinienanweisung ein `Condition`-Element enthält, ist die Anweisung nur dann wirksam, wenn das `Condition`-Element mit „true“ ausgewertet wird. In diesem Fall wird `Condition` mit „true“ ausgewertet, wenn der Benutzer durch MFA authentifiziert ist. Wenn der Benutzer nicht durch MFA authentifiziert ist, wird `Condition` mit „false“ ausgewertet. In diesem Fall wird die dritte Anweisung in dieser Richtlinie nicht wirksam, sodass der Benutzer keinen Zugriff auf den `amzn-s3-demo-bucket-confidential-data`-Bucket hat.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
```
------
### Beispiele für JSON-Richtliniensyntax
Die folgenden identitätsbasierte Richtlinie erlaubt dem implizierten Auftraggeber, einen einzelnen Amazon S3-Bucket mit dem Namen `amzn-s3-demo-bucket` aufzulisten:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
------
Die folgende ressourcenbasierte Richtlinie kann einem Amazon S3-Bucket angefügt werden. Die Richtlinie ermöglicht es Mitgliedern einer bestimmten Person AWS-Konto , alle Amazon S3 S3-Aktionen in dem genannten Bucket durchzuführen`amzn-s3-demo-bucket`. Sie erlaubt alle Aktionen, die für einen Bucket oder die darin enthaltenen Objekte durchgeführt werden können. (Da die Richtlinie nur dem Konto eine Vertrauensstellung einräumt, müssen den einzelnen Benutzer nach wie vor Berechtigungen für die angegebenen Amazon S3-Aktionen gewährt werden.)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
Beispielrichtlinien für gebräuchliche Szenarien finden Sie unter [Beispiele für identitätsbasierte Richtlinien in IAM](access_policies_examples.md).
## Gewähren der geringsten Berechtigung
Wenn Sie IAM-Richtlinien erstellen, befolgen Sie die Standard-Sicherheitsmaßnahmen, die für das Erteilen von *geringsten Rechten* gelten, d. h. es werden nur die Berechtigungen erteilt, die zum Durchführen einer Aufgabe erforderlich sind. Bestimmen Sie, was Benutzer und Rollen tun müssen, und gestalten Sie dann entsprechende Richtlinien, mit denen die Benutzer *nur* diese Aufgaben ausführen können.
Beginnen Sie mit einem Mindestsatz an Berechtigungen und erteilen Sie bei Bedarf weitere. Dies ist sicherer, als mit Berechtigungen zu beginnen, die zu lax sind, und dann zu versuchen, sie zu einem späteren Zeitpunkt zu verschärfen.
Als Alternative zu Least Privilege können Sie [verwaltete AWS -Richtlinien](access_policies_managed-vs-inline.md#aws-managed-policies) oder Richtlinien mit Wildcard-`*`-Berechtigungen verwenden, um mit Richtlinien zu beginnen. Berücksichtigen Sie das Sicherheitsrisiko, wenn Sie Ihren Auftraggeber mehr Berechtigungen gewähren, als sie für ihre Arbeit benötigen. Überwachen Sie diese Auftraggeber, um zu erfahren, welche Berechtigungen sie verwenden. Schreiben Sie dann Richtlinien mit den geringsten Berechtigungen.
IAM bietet verschiedene Optionen, mit denen Sie die von Ihnen erteilten Berechtigungen verfeinern können.
+ **Zugriffsebenengruppierungen** – Mit Zugriffsebenengruppierungen können Sie die von einer Richtlinie gewährte Zugriffsebene nachvollziehen. [Richtlinienaktionen](reference_policies_elements_action.md) werden als `List`, `Read`, `Write`, `Permissions management`, oder `Tagging` klassifiziert. Beispielsweise können Sie Aktionen aus den Zugriffsebenen `List` und `Read` wählen, um Ihren Benutzern schreibgeschützten Zugriff zu erteilen. Informationen zur Verwendung von Richtlinienzusammenfassungen und Erläuterungen der Berechtigungen auf Zugriffsebene finden Sie unter [Zugriffsebenen in Richtlinienübersichten](access_policies_understand-policy-summary-access-level-summaries.md).
+ **Validieren Ihrer Richtlinien** – Sie können die Richtlinienvalidierung mit IAM Access Analyzer durchführen, wenn Sie JSON-Richtlinien erstellen und bearbeiten. Wir empfehlen, alle vorhandenen Richtlinien zu überprüfen und zu validieren. IAM Access Analyzer bietet über 100 Richtlinienüberprüfungen zur Validierung Ihrer Richtlinien. Es generiert Sicherheitswarnungen, wenn eine Anweisung in Ihrer Richtlinie den Zugriff zulässt, den wir als übermäßig freizügig betrachten. Sie können die umsetzbaren Empfehlungen verwenden, die durch die Sicherheitswarnungen bereitgestellt werden, wenn Sie daran arbeiten, die geringsten Berechtigungen zu erteilen. Weitere Informationen zu den von IAM Access Analyzer bereitgestellten Richtlinienprüfungen finden Sie unter [IAM Access Analyzer-Richtlinienvalidierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
+ **Generieren einer Richtlinie basierend auf -Zugriffsaktivitäten** – Um die Berechtigungen zu verfeinern, die Sie gewähren, können Sie eine IAM-Richtlinie generieren, die auf der Zugriffsaktivität für eine IAM-Entität (Benutzer oder Rolle) basiert. IAM Access Analyzer überprüft Ihre AWS CloudTrail Protokolle und generiert eine Richtlinienvorlage, die die Berechtigungen enthält, die von der Entität in dem von Ihnen angegebenen Zeitraum verwendet wurden. Sie können die Vorlage verwenden, um eine verwaltete Richtlinie mit definierten Berechtigungen zu erstellen und sie dann an die IAM-Rolle anzuhängen. Auf diese Weise gewähren Sie nur die Berechtigungen, die der Benutzer oder die Rolle benötigt, um mit AWS Ressourcen für Ihren speziellen Anwendungsfall zu interagieren. Weitere Informationen finden Sie unter [Richtliniengenerierung für IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).
+ **Verwenden der Informationen zum letzten Zugriff** – Ein weiteres Feature, die bei der Wahrung der geringsten Berechtigung helfen kann, sind *Informationen über den letzten Zugriff*. Sie können diese Informationen auf der Registerkarte **Access Advisor (Advisor aufrufen)** auf der Detailseite für einen IAM-Benutzer, eine Gruppe, eine Rolle oder eine Richtlinie in der -Konsole anzeigen. Die Informationen über den letzten Zugriff enthalten Informationen über einige Aktionen, auf die zuletzt für Amazon EC2, IAM, Lambda und Amazon S3 zugegriffen wurde. Wenn Sie sich mit den Anmeldeinformationen für das AWS Organizations Verwaltungskonto anmelden, können Sie die Informationen zum letzten Zugriff auf den Dienst im **AWS Organizations**Bereich der IAM-Konsole einsehen. Sie können auch die AWS API AWS CLI oder verwenden, um einen Bericht über die zuletzt abgerufenen Informationen für Entitäten oder Richtlinien in IAM oder abzurufen. AWS Organizations Sie können diese Informationen verwenden, um unnötige Berechtigungen zu identifizieren, sodass Sie Ihr IAM oder Ihre AWS Organizations Richtlinien so verfeinern können, dass das Prinzip der geringsten Rechte besser eingehalten wird. Weitere Informationen finden Sie unter [Verfeinern Sie die Berechtigungen für AWS die Verwendung der zuletzt abgerufenen Informationen](access_policies_last-accessed.md).
+ **Kontoereignisse überprüfen in AWS CloudTrail** — Um die Zugriffsrechte weiter einzuschränken, können Sie die Ereignisse Ihres Kontos im AWS CloudTrail **Ereignisverlauf** einsehen. CloudTrail Ereignisprotokolle enthalten detaillierte Ereignisinformationen, anhand derer Sie die Berechtigungen der Richtlinie einschränken können. Die Protokolle enthalten nur die Aktionen und Ressourcen, die Ihre IAM-Entitäten benötigen. Weitere Informationen finden Sie im *AWS CloudTrail Benutzerhandbuch* unter [ CloudTrailEreignisse in der CloudTrail Konsole anzeigen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html).
Weitere Informationen finden Sie in den folgenden Richtlinienthemen für einzelne Services, die Beispiele für das Schreiben von Richtlinien für servicespezifische Ressourcen bieten.
+ [Verwendung ressourcenbasierter Richtlinien für DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html) im *Amazon-DynamoDB-Entwicklerhandbuch*
+ [Bucket-Richtlinien für Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) im *Benutzerhandbuch für Amazon Simple Storage Service*
+ [Übersicht über Zugriffssteuerungsliste (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) im *Benutzerhandbuch für Amazon Simple Storage Service*
# Verwaltete Richtlinien und eingebundene Richtlinien
Wenn Sie die Berechtigungen für eine Identität in IAM festlegen, müssen Sie entscheiden, ob Sie eine verwaltete AWS -Richtlinie, eine vom Kunden verwaltete Richtlinie oder eine Inline-Richtlinie verwenden. In den folgenden Themen erhalten Sie weitere Informationen zu den einzelnen Arten identitätsbasierter Richtlinien und deren Verwendung.
In der folgenden Tabelle werden diese Richtlinien beschrieben:
| Richtlinientyp | Description | Wer verwaltet die Richtlinie? | Berechtigungen ändern? | Anzahl der auf die Richtlinie angewendeten Prinzipale? |
| --- | --- | --- | --- | --- |
| [AWS verwaltete Richtlinien](#aws-managed-policies) | Eigenständige Richtlinie, erstellt und verwaltet von AWS. | AWS | Nein | Mehrere |
| [Kundenverwaltete Richtlinien](#customer-managed-policies) | Richtlinie, die Sie für bestimmte Anwendungsfälle erstellen, die beliebig oft geändert oder aktualisiert werden kann. | Sie | Ja | Mehrere |
| [Eingebundene Richtlinien](#inline-policies) | Richtlinie, die für eine einzelne IAM-Identität (Benutzer, Gruppe oder Rolle) erstellt wurde und eine strikte one-to-one Beziehung zwischen einer Richtlinie und einer Identität aufrechterhält. | Sie | Ja | One |
**Topics**
+ [AWS verwaltete Richtlinien](#aws-managed-policies)
+ [Kundenverwaltete Richtlinien](#customer-managed-policies)
+ [Eingebundene Richtlinien](#inline-policies)
+ [Auswahl zwischen verwalteten Richtlinien und Inline-Richtlinien](access_policies-choosing-managed-or-inline.md)
+ [Konvertieren einer Inline-Richtlinie in eine verwaltete Richtlinie](access_policies-convert-inline-to-managed.md)
+ [Veraltete verwaltete Richtlinien AWS](access_policies_managed-deprecated.md)
## AWS verwaltete Richtlinien
Bei einer von *AWS verwalteten Richtlinie* handelt es sich um eine eigenständige Richtlinie, die von AWS erstellt und verwaltet wird. Eine *eigenständige Richtlinie* bedeutet, dass die Richtlinie ihren eigenen Amazon-Ressourcennamen (ARN) hat, der den Richtliniennamen enthält. `arn:aws:iam::aws:policy/IAMReadOnlyAccess`Ist beispielsweise eine AWS verwaltete Richtlinie. Weitere Informationen zu finden ARNs Sie unter[ICH BIN ARNs](reference_identifiers.md#identifiers-arns). Eine Liste der AWS verwalteten Richtlinien für AWS-Services finden Sie unter [AWS Verwaltete Richtlinien](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/policy-list.html).
AWS Mit verwalteten Richtlinien können Sie Benutzern, IAM-Gruppen und Rollen bequem die entsprechenden Berechtigungen zuweisen. Das ist schneller, als selbst die Richtlinien zu schreiben und beinhaltet Berechtigungen für viele häufige Anwendungsfälle.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. AWS aktualisiert gelegentlich die in einer AWS verwalteten Richtlinie definierten Berechtigungen. Ab wann AWS wirkt sich das Update auf alle Prinzipalentitäten (IAM-Benutzer, IAM-Gruppen und IAM-Rollen) aus, an die die Richtlinie angehängt ist. AWS ist am wahrscheinlichsten, dass eine AWS verwaltete Richtlinie aktualisiert wird, wenn ein neuer AWS Dienst gestartet wird oder neue API-Aufrufe für bestehende Dienste verfügbar werden. Die so genannte AWS verwaltete Richtlinie **ReadOnlyAccess**bietet beispielsweise schreibgeschützten Zugriff auf alle Ressourcen AWS-Services . Wenn ein neuer Dienst AWS gestartet wird, wird die **ReadOnlyAccess**Richtlinie AWS aktualisiert, um schreibgeschützte Berechtigungen für den neuen Dienst hinzuzufügen. Die aktualisierten Berechtigungen werden auf alle Auftraggeber-Entitäten angewendet, an die die Richtlinie angefügt ist.
* AWS Verwaltete Richtlinien für vollen Zugriff*: Diese definieren Berechtigungen für Dienstadministratoren, indem sie Vollzugriff auf einen Dienst gewähren. Zu den Beispielen gehören:
+ [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html)
+ [IAMFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/IAMFullAccess.html)
*Von Power-Usern AWS verwaltete Richtlinien*: Diese bieten vollen Zugriff auf AWS-Services und Ressourcen, erlauben jedoch nicht die Verwaltung von Benutzern und IAM-Gruppen. Zu den Beispielen gehören:
+ [AWSCodeCommitPowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeCommitPowerUser.html)
+ [AWSKeyManagementServicePowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSKeyManagementServicePowerUser.html)
* AWS Verwaltete Richtlinien mit teilweisem Zugriff*: Diese bieten bestimmte Zugriffsebenen, AWS-Services ohne dass [Berechtigungen auf Zugriffsebene für die Berechtigungsverwaltung](access_policies_understand-policy-summary-access-level-summaries.md#access_policies_access-level) gewährt werden. Zu den Beispielen gehören:
+ [AmazonMobileAnalyticsWriteOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonMobileAnalyticsWriteOnlyAccess.html)
+ [AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html)
*Richtlinien, die von Jobfunktionen AWS verwaltet* werden: Diese Richtlinien orientieren sich eng an den in der IT-Branche häufig verwendeten Jobfunktionen und erleichtern die Erteilung von Genehmigungen für diese Jobfunktionen. Ein entscheidender Vorteil der Verwendung von Richtlinien für berufliche Funktionen besteht darin, dass sie bei AWS der Einführung neuer Dienste und API-Operationen beibehalten und aktualisiert werden. Die [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html)Job-Funktion bietet beispielsweise vollen Zugriff und die Delegierung von Berechtigungen für jeden Dienst und jede Ressource in AWS. Wir empfehlen, dass diese Richtlinie nur für den Kontoadministrator verwendet wird. Für Poweruser, die vollen Zugriff auf alle Dienste mit Ausnahme des eingeschränkten Zugriffs auf IAM benötigen AWS Organizations, sollten Sie die [PowerUserAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/PowerUserAccess.html)Job-Funktion verwenden. Eine Liste und Beschreibungen der Richtlinien für Auftragsfunktionen finden Sie unter [AWS verwaltete Richtlinien für Jobfunktionen](access_policies_job-functions.md).
Das folgende Diagramm veranschaulicht AWS verwaltete Richtlinien. Das Diagramm zeigt drei AWS verwaltete Richtlinien: **AdministratorAccess**PowerUserAccess****, und **AWS CloudTrail\$1 ReadOnlyAccess**. Beachten Sie, dass eine einzelne AWS verwaltete Richtlinie an verschiedene Haupteinheiten und an verschiedene AWS-Konten Haupteinheiten in einer einzigen Richtlinie angehängt werden kann AWS-Konto.
![\[Diagramm der AWS verwalteten Richtlinien\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policies-aws-managed-policies.diagram.png)
## Kundenverwaltete Richtlinien
Sie können eigene eigenständige Richtlinien erstellen AWS-Konto , die Sie an Prinzipalentitäten (IAM-Benutzer, IAM-Gruppen und IAM-Rollen) anhängen können. Sie erstellen diese *vom Kunden verwalteten Richtlinien* für Ihre spezifischen Anwendungsfälle und können sie beliebig oft ändern und aktualisieren. Wie bei AWS verwalteten Richtlinien geben Sie, wenn Sie einer Prinzipalentität eine Richtlinie zuordnen, der Entität die in der Richtlinie definierten Berechtigungen. Wenn Sie Berechtigungen in der Richtlinie aktualisieren, werden die Änderungen auf alle Prinzipal-Entitäten angewendet, an die die Richtlinie angefügt ist.
Eine hervorragende Methode zum Erstellen einer vom Kunden verwalteten Richtlinie besteht darin, zunächst eine vorhandene, von AWS verwaltete Richtlinie zu kopieren. So wissen Sie, dass die Richtlinie zu Beginn richtig ist und Sie sie nur an Ihre Umgebung anpassen müssen.
Die vom Kunden verwalteten Richtlinien sind in der folgenden Abbildung dargestellt. Bei der jeweiligen Richtlinie handelt es sich um eine Entität in IAM mit ihrem eigenen [Amazon-Ressourcenname (ARN)](reference_identifiers.md#identifiers-arns), der den Richtliniennamen enthält. Beachten Sie, dass ein und dieselbe Richtlinie mehreren Hauptentitäten zugeordnet werden kann. So ist beispielsweise dieselbe **DynamoDB-books-app**-Richtlinie zwei verschiedenen IAM-Rollen zugeordnet.
Weitere Informationen finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
![\[Diagramm der von Kunden verwalteten Richtlinien\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policies-customer-managed-policies.diagram.png)
## Eingebundene Richtlinien
Eine Inline-Richtlinie ist eine Richtlinie, die für eine einzelne IAM-Identität (einen Benutzer, eine Benutzergruppe oder eine Rolle) erstellt wird. Inline-Richtlinien sorgen für eine strikte one-to-one Beziehung zwischen einer Richtlinie und einer Identität. Sie werden gelöscht, wenn Sie die Identität löschen. Sie können eine Richtlinie erstellen und sie entweder, wenn Sie die Identität erstellen, oder später in eine Identität einbetten. Wenn eine Richtlinie für mehr als eine Entität gelten könnte, ist es besser, eine verwaltete Richtlinie zu verwenden.
Die eingebundenen Richtlinien sind in der folgenden Abbildung dargestellt. Jede Richtlinie ist unabdingbarer Bestandteil des Benutzers, der Gruppe oder der Rolle. Beachten Sie, dass zwei Rollen dieselbe Richtlinie enthalten (die Richtlinie **DynamoDB-books-app**), aber sie verwenden keine Richtlinie gemeinsam. Jede Rolle hat ihre eigene Kopie der Richtlinie.
![\[Diagramm der eingebundenen Richtlinien\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policies-inline-policies.diagram.png)
# Auswahl zwischen verwalteten Richtlinien und Inline-Richtlinien
Berücksichtigen Sie Ihre Anwendungsfälle, wenn Sie zwischen verwalteten und Inline-Richtlinien entscheiden. In den meisten Fällen empfehlen wir, dass Sie verwaltete Richtlinien anstelle von eingebundenen Richtlinien verwenden.
**Anmerkung**
Sie können sowohl verwaltete als auch Inline-Richtlinien zusammen verwenden, um gemeinsame und eindeutige Berechtigungen für eine Prinzipal-Entität zu definieren.
Verwaltete Richtlinien bieten die folgenden Funktionen:
**Wiederverwendbarkeit**
Eine einzelne verwaltete Richtlinie kann an mehrere Auftraggeber-Entitäten (Benutzer, Gruppen und Rollen) angefügt werden. Sie können eine Bibliothek mit Richtlinien erstellen, die nützliche Berechtigungen für Sie definieren AWS-Konto, und diese Richtlinien dann nach Bedarf an Prinzipalentitäten anhängen.
**Zentrale Änderungsverwaltung**
Wenn Sie eine verwaltete Richtlinie ändern, wird die Änderung auf alle Auftraggeber-Entitäten angewendet, an die die Richtlinie angefügt ist. Wenn Sie beispielsweise Berechtigungen für eine neue AWS API hinzufügen möchten, können Sie eine vom Kunden verwaltete Richtlinie aktualisieren oder eine AWS verwaltete Richtlinie zuordnen, um die Berechtigung hinzuzufügen. Wenn Sie eine AWS verwaltete Richtlinie verwenden, AWS aktualisiert die Richtlinie. Bei der Aktualisierung einer verwalteten Richtlinie werden die Änderungen auf alle Prinzipal-Entitäten angewendet, denen die verwaltete Richtlinie angefügt ist. Im Gegensatz dazu müssen Sie zum Ändern einer Inline-Richtlinie jede Identität einzeln bearbeiten, die die Inline-Richtlinie enthält. Wenn beispielsweise eine Gruppe und eine Rolle dieselbe Inline-Richtlinie enthalten, müssen Sie beide Prinzipal-Entitäten individuell bearbeiten, um diese Richtlinie zu ändern.
**Versioning und Rollback**
Wenn Sie eine kundenverwaltete Richtlinie ändern, wird die vorhandene Richtlinie nicht von der geänderten Richtlinie überschrieben. IAM erstellt stattdessen eine neue Version der verwalteten Richtlinie. IAM speichert bis zu fünf Versionen Ihrer vom Kunden verwalteten Richtlinien. Sie können Richtlinienversionen verwenden, um eine frühere Version einer Richtlinie wiederherzustellen, sofern dies erforderlich ist.
Eine Richtlinienversion ist nicht mit dem Richtlinienelement `Version` identisch. Das Richtlinienelement `Version` wird innerhalb einer Richtlinie verwendet und gibt die Version der Richtliniensprache an. Weitere Informationen zu den Richtlinienversionen finden Sie unter [Versioning von IAM-Richtlinien](access_policies_managed-versioning.md). Weitere Informationen zum Richtlinienelement `Version` finden Sie unter [IAM-JSON-Richtlinienelemente: Version](reference_policies_elements_version.md).
**Delegieren der Berechtigungsverwaltung**
Sie können Benutzern in Ihren AWS-Konto Richtlinien das Anhängen und Trennen von Richtlinien gestatten und gleichzeitig die Kontrolle über die in diesen Richtlinien definierten Berechtigungen behalten. Sie können einige Benutzer als Administratoren mit vollständigen Rechten bestimmen, d. h. Administratoren, die Richtlinien erstellen, aktualisieren und löschen können. Anschließend können Sie andere Benutzer als Administratoren mit eingeschränkten Rechten bestimmen. Dies bedeutet, dass Administratoren zwar Richtlinien an andere Prinzipal-Entitäten anfügen können, aber nur die Richtlinien, für die Sie ihnen die Berechtigungen zum Anfügen erteilt haben.
Weitere Informationen zum Delegieren der Berechtigungsverwaltung finden Sie unter [Steuern des Zugriffs auf Richtlinien](access_controlling.md#access_controlling-policies).
**Größere Zeichenbeschränkungen für Richtlinien**
Die maximale Zeichengrößenbeschränkung für verwaltete Richtlinien ist größer als die Zeichenbeschränkung für für Gruppen von Inline-Richtlinien. Wenn Sie die Zeichengrößenbeschränkung der eingebundenen Richtlinie erreichen, können Sie weitere IAM-Gruppen erstellen und die verwaltete Richtlinie der Gruppe zuweisen.
Weitere Informationen zu Kontingenten und Limits finden Sie unter [IAM und Kontingente AWS STS](reference_iam-quotas.md).
**Automatische Updates für AWS verwaltete Richtlinien**
AWS verwaltet AWS verwaltete Richtlinien und aktualisiert sie bei Bedarf, um beispielsweise Berechtigungen für neue AWS Dienste hinzuzufügen, ohne dass Sie Änderungen vornehmen müssen. Die Updates werden automatisch auf die Prinzipalentitäten angewendet, denen Sie die AWS verwaltete Richtlinie zugeordnet haben.
## Erste Schritte mit verwalteten Richtlinien
Es wird empfohlen, Richtlinien zu verwenden, die [die geringsten Rechte gewähren](access_policies.md#grant-least-priv), d. h. nur die für die Durchführung einer Aufgabe erforderlichen Berechtigungen zu gewähren. Die sicherste Methode, die geringste Berechtigung zu erteilen, besteht darin, eine vom Kunden verwaltete Richtlinie mit nur den Berechtigungen zu schreiben, die Ihr Team benötigt. Sie müssen einen Prozess erstellen, damit Ihr Team bei Bedarf weitere Berechtigungen anfordern kann. Es erfordert Zeit und Fachwissen, um [von Kunden verwaltete IAM-Richtlinien zu erstellen](access_policies_create-console.md), die Ihrem Team nur die benötigten Berechtigungen bieten.
Um mit dem Hinzufügen von Berechtigungen zu Ihren IAM-Identitäten (Benutzern, Benutzergruppen und Rollen) zu beginnen, können Sie Folgendes verwenden. [AWS verwaltete Richtlinien](access_policies_managed-vs-inline.md#aws-managed-policies) AWS verwaltete Richtlinien gewähren keine Berechtigungen mit den geringsten Rechten. Sie müssen das Sicherheitsrisiko berücksichtigen, wenn Sie Ihren Auftraggeber mehr Berechtigungen gewähren, als sie für ihre Arbeit benötigen.
Sie können AWS verwaltete Richtlinien, einschließlich Jobfunktionen, an jede IAM-Identität anhängen. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](access_policies_manage-attach-detach.md).
Um zu den Berechtigungen mit den geringsten Rechten zu wechseln, können Sie Access Analyzer ausführen AWS Identity and Access Management , um die Prinzipale mit AWS verwalteten Richtlinien zu überwachen. Nachdem Sie erfahren haben, welche Berechtigungen sie verwenden, können Sie eine vom Kunden verwaltete Richtlinie schreiben oder generieren, die nur die erforderlichen Berechtigungen für Ihr Team beinhaltet. Das ist weniger sicher, bietet aber mehr Flexibilität, wenn Sie erfahren, wie Ihr Team die Daten verwendet AWS. Weitere Informationen finden Sie unter [Generieren von IAM Access Analyzer-Richtlinien](access-analyzer-policy-generation.md).
AWS verwaltete Richtlinien dienen dazu, Berechtigungen für viele gängige Anwendungsfälle bereitzustellen. Weitere Informationen zu AWS verwalteten Richtlinien, die für bestimmte Aufgaben konzipiert sind, finden Sie unter[AWS verwaltete Richtlinien für Jobfunktionen](access_policies_job-functions.md).
Eine Liste der AWS verwalteten Richtlinien finden Sie im [Referenzhandbuch für AWS verwaltete Richtlinien](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html).
## Verwenden von eingebundenen Richtlinien
Inline-Richtlinien sind nützlich, wenn Sie eine strikte one-to-one Beziehung zwischen einer Richtlinie und der Identität, auf die sie angewendet wird, aufrechterhalten möchten. Sie sollten beispielsweise darauf achten, dass die Berechtigungen einer Richtlinie nicht versehentlich einer Identität zugewiesen werden, für die sie nicht vorgesehen sind. Bei Verwendung einer Inline-Richtlinie können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Wenn Sie AWS-Managementkonsole zum Löschen dieser Identität verwenden, werden außerdem die in der Identität eingebetteten Richtlinien ebenfalls gelöscht, da sie Teil der Prinzipalentität sind.
# Konvertieren einer Inline-Richtlinie in eine verwaltete Richtlinie
Wenn Sie eingebundene Richtlinien in Ihrem Konto verwenden, können Sie diese in verwaltete Richtlinien umwandeln. Kopieren Sie hierzu die Richtlinie in eine neue verwaltete Richtlinie. Fügen Sie als Nächstes die neue Richtlinie an die Identität an, die die Inline-Richtlinie enthält. Löschen Sie dann die eingebundene Richtlinie.
## So konvertieren Sie eine eingebundene Richtlinie in eine verwaltete Richtlinie
**So konvertieren Sie eine eingebundene Richtlinie in eine verwaltete Richtlinie**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Klicken Sie im Navigationsbereich auf **Groups (Gruppen)**, **Users (Benutzer)** oder **Roles (Rollen)**.
1. Wählen Sie in der Liste den Namen der Gruppe, des Benutzers oder der Rolle aus, deren bzw. dessen Richtlinie Sie entfernen möchten.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Wählen Sie für IAM-Gruppen den Namen der Inline-Richtlinie aus, die Sie entfernen möchten. Wählen Sie bei Bedarf für Benutzer und Rollen die Option ***n*Mehr anzeigen** aus und erweitern Sie dann die Inline-Richtlinie, die Sie entfernen möchten.
1. Wählen Sie **Copy** (Kopieren) aus, um das JSON-Richtliniendokument für die Richtlinie zu kopieren.
1. Wählen Sie im Navigationsbereich **Richtlinien**.
1. Wählen Sie **Create policy** (Richtlinie erstellen) und anschließend die Option **JSON** aus.
1. Ersetzen Sie den vorhandenen Text durch den Text der JSON-Richtlinie und wählen Sie dann **Next** (Weiter) aus.
1. Geben Sie einen Namen und eine optionale Beschreibung für Ihre Richtlinie ein und wählen Sie dann **Create Policy** (Richtlinie erstellen) aus.
1. Wählen Sie im Navigationsbereich **Groups (Gruppen)**, **Users (Benutzer)** oder **Roles (Rollen)** und dann den Namen der Gruppe, des Benutzers oder der Rolle aus, die die Richtlinie enthält, die Sie entfernen möchten.
1. Wählen Sie die Registerkarte **Permissions** (Berechtigungen) und anschließend die Option **Add Permissions** (Berechtigungen hinzufügen).
1. Aktivieren Sie für IAM-Gruppen das Kontrollkästchen neben dem Namen Ihrer neuen Richtlinie, wählen Sie **Berechtigungen hinzufügen** und dann **Richtlinie anfügen** aus. Wählen Sie für Benutzer oder Rollen **Add permissions (Berechtigungen hinzufügen)**. Wählen Sie auf der nächsten Seite **Vorhandene Richtlinien direkt anfügen** aus, aktivieren Sie das Kontrollkästchen neben dem Namen der neuen Richtlinie und wählen Sie dann **Weiter** und **Berechtigungen hinzufügen** aus.
Die Seite **Summary (Übersicht)** für die Gruppe, den Benutzer oder die Rolle wird erneut angezeigt.
1. Aktivieren Sie das Kontrollkästchen neben der Inline-Richtlinie, die Sie entfernen möchten, und wählen Sie **Entfernen** aus.
# Veraltete verwaltete Richtlinien AWS
AWS Stellt [verwaltete Richtlinien](access_policies_managed-vs-inline.md) bereit, um die Zuweisung von Berechtigungen zu vereinfachen. Dabei handelt es sich um vordefinierte Richtlinien, die Ihren IAM-Benutzern, -Gruppen und -Rollen zugewiesen werden können.
Manchmal AWS muss einer bestehenden Richtlinie eine neue Berechtigung hinzugefügt werden, z. B. wenn ein neuer Dienst eingeführt wird. Durch das Hinzufügen einer neuen Berechtigung zu einer vorhandenen Richtlinie werden keine Eigenschaften oder Fähigkeiten beeinflusst oder gelöscht.
AWS Möglicherweise entscheiden Sie sich jedoch für die Erstellung einer *neuen* Richtlinie, wenn die erforderlichen Änderungen Auswirkungen auf Kunden haben könnten, wenn sie auf eine bestehende Richtlinie angewendet würden. Das Entfernen von Berechtigungen aus einer vorhandenen Richtlinie könnte die Berechtigungen der IAM-Entitäten oder Anwendungen, die von dieser Richtlinie abhängig sind, aufheben und kritische Vorgänge unterbrechen.
Wenn eine solche Änderung erforderlich ist, wird daher eine völlig neue Richtlinie mit den erforderlichen Änderungen AWS erstellt und den Kunden zur Verfügung gestellt. Die alte Richtlinie wird dann als *veraltet* gekennzeichnet. Weitere Informationen finden Sie unter [Veraltete AWS verwaltete Richtlinien](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/about-managed-policy-reference.html#deprecated-managed-policies) im *Referenzhandbuch für AWS verwaltete Richtlinien.*
# Einrichten des Berechtigungs-Integritätsschutzes mithilfe von Datenperimetern
Leitplanken an den Datengrenzen dienen als ständig verfügbare Grenzen, um Ihre Daten über eine Vielzahl von Konten und Ressourcen hinweg zu schützen. AWS Datenperimeter folgen den bewährten IAM-Sicherheitsmethoden, um [Schutzmaßnahmen über mehrere Konten hinweg einzurichten.](best-practices.md#bp-permissions-guardrails) Dieser unternehmensweite Berechtigungs-Integritätsschutz ersetzt nicht Ihre vorhandenen fein abgestuften Zugriffskontrollen. Stattdessen fungieret es als **grob abgestufte Zugriffskontrollen**, die zur Verbesserung Ihrer Sicherheitsstrategie beitragen, indem sie sicherstellen, dass Benutzer, Rollen und Ressourcen eine Reihe definierter Sicherheitsstandards einhalten.
Bei einem Datenperimeter handelt es sich um eine Reihe von Schutzplanken in Ihrer AWS Umgebung, die sicherstellen, dass nur Ihre vertrauenswürdigen Identitäten auf vertrauenswürdige Ressourcen aus den erwarteten Netzwerken zugreifen.
+ Vertrauenswürdige Identitäten: Prinzipale (IAM-Rollen oder Benutzer) in Ihren AWS Konten und Diensten, die in Ihrem Namen handeln. AWS
+ Vertrauenswürdige Ressourcen: Ressourcen, die Ihren AWS Konten oder AWS Diensten gehören, die in Ihrem Namen handeln.
+ Erwartete Netzwerke: Ihre lokalen Rechenzentren und virtuellen privaten Clouds (VPCs) oder Netzwerke von AWS Diensten, die in Ihrem Namen agieren.
**Anmerkung**
In manchen Fällen müssen Sie Ihr Datenperimeter erweitern, um auch den Zugriff durch Ihre vertrauenswürdigen Geschäftspartner einzuschließen. Sie sollten alle beabsichtigten Datenzugriffsmuster berücksichtigen, wenn Sie eine Definition vertrauenswürdiger Identitäten, vertrauenswürdiger Ressourcen und erwarteter Netzwerke erstellen, die speziell auf Ihr Unternehmen und Ihre Nutzung der AWS-Services zugeschnitten ist.
Datenperimeterkontrollen sollten wie jede andere Sicherheitskontrolle im Rahmen des Informationssicherheits- und Risikomanagementprogramms behandelt werden. Dies bedeutet, dass Sie eine Bedrohungsanalyse durchführen sollten, um potenzielle Risiken in Ihrer Cloud-Umgebung zu identifizieren und dann basierend auf Ihrer eigenen Risikoakzeptanzkriterien geeignete Datenperimeterkontrollen auswählen und implementieren sollten. Um den iterativen, risikobasierten Ansatz zur Implementierung von Datenperimetern besser zu informieren, müssen Sie verstehen, welche Sicherheitsrisiken und Bedrohungsvektoren durch Datenperimeterkontrollen berücksichtigt werden und welche Sicherheitsprioritäten Sie haben.
## Datenperimeter-Kontrollen
Mithilfe grob abgestufter Datenperimeterkontrollen können Sie durch die Implementierung verschiedener Kombinationen aus [Richtlinientypen](access_policies.md#access_policy-types) und [Bedingungsschlüsseln](reference_policies_condition-keys.md) sechs verschiedene Sicherheitsziele über drei Datenperimeter hinweg erreichen.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/access_policies_data-perimeters.html)
Sie können sich Datenperimeter so vorstellen, als würden Sie eine feste Grenze um Ihre Daten herum schaffen, um unbeabsichtigte Zugriffsmuster zu verhindern. Obwohl Datenperimeter einen weitreichenden, unbeabsichtigten Zugriff verhindern können, müssen Sie dennoch Entscheidungen zur differenzierten Zugriffssteuerung treffen. Die Einrichtung eines Datenperimeters mindert nicht die Notwendigkeit, Berechtigungen mithilfe von Tools wie [IAM Access Analyzer](what-is-access-analyzer.md) kontinuierlich zu optimieren, um das Prinzip der [geringsten Berechtigungen](best-practices.md#grant-least-privilege) zu erreichen.
Um Datenperimeterkontrollen für Ressourcen durchzusetzen, die derzeit nicht von unterstützt werden RCPs, können Sie ressourcenbasierte Richtlinien verwenden, die Ressourcen direkt zugeordnet sind. Eine Liste der Dienste, die ressourcenbasierte Richtlinien unterstützen, finden Sie unter Richtlinien zur [Ressourcenkontrolle](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) () RCPs und. RCPs [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md)
Um die Kontrolle der Netzwerkgrenzen durchzusetzen, empfehlen wir `aws:VpceOrgID`, `aws:VpceOrgPaths` und `aws:VpceAccount` nur zu verwenden, wenn alle Services, auf die Sie den Zugriff einschränken möchten, derzeit unterstützt werden. Die Verwendung dieser Bedingungsschlüssel mit nicht unterstützten Services kann zu unbeabsichtigten Autorisierungsergebnissen führen. Eine Liste der Services, die die Schlüssel unterstützen, finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md). Wenn Sie die Kontrollen für ein breiteres Spektrum von Services durchsetzen müssen, sollten Sie stattdessen `aws:SourceVpc` und `aws:SourceVpce` verwenden.
## Identitätsperimeter
Bei einem Identitätsperimeter handelt es sich um eine Reihe grob abgestufter präventiver Zugriffskontrollen, die sicherstellen, dass nur vertrauenswürdige Identitäten auf Ihre Ressourcen zugreifen können und nur vertrauenswürdige Identitäten aus Ihrem Netzwerk zugelassen werden. Zu den vertrauenswürdigen Identitäten gehören in der Regel Principals (Rollen oder Benutzer) in Ihren AWS Konten und AWS Diensten, die in Ihrem Namen handeln. Alle anderen Identitäten gelten als nicht vertrauenswürdig und werden durch den Identitätsperimeter blockiert, sofern keine ausdrückliche Ausnahme gewährt wird.
Die folgenden globalen Bedingungsschlüssel helfen bei der Durchsetzung von Identitätsperimeterkontrollen auf Grundlage Ihrer Definition vertrauenswürdiger Identitäten. Verwenden Sie diese Schlüssel in Ressourcenkontrollrichtlinien, um den Zugriff auf Ressourcen einzuschränken, oder in [VPC-Endpunktrichtlinien](https://docs.aws.amazon.com//vpc/latest/privatelink/vpc-endpoints-access.html), um den Zugriff auf Ihre Netzwerke einzuschränken.
### Identitäten, die Ihnen gehören
Sie können die folgenden Bedingungsschlüssel verwenden, um IAM-Prinzipale zu definieren, die Sie in Ihrem erstellen und verwalten. AWS-Konten
+ [aws:PrincipalOrgID](reference_policies_condition-keys.md#condition-keys-principalorgid) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass IAM-Prinzipale, die die Anfrage stellen, zur angegebenen Organisation in AWS Organizations gehören.
+ [aws:PrincipalOrgPaths](reference_policies_condition-keys.md#condition-keys-principalorgpaths)— Sie können diesen Bedingungsschlüssel verwenden, um sicherzustellen, dass der IAM-Benutzer, die IAM-Rolle, der AWS STS Verbundbenutzerprinzipal, der SAML-Bundprinzipal, der OIDC-Verbundprinzipal oder Root-Benutzer des AWS-Kontos der, für den die Anfrage gestellt wurde, zur angegebenen Organisationseinheit (OU) in gehören. AWS Organizations
+ [aws:PrincipalAccount](reference_policies_condition-keys.md#condition-keys-principalaccount) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass nur das in der Richtlinie angegebene Hauptkonto auf Ressourcen zugreifen kann.
### Identitäten von Diensten, die in Ihrem Namen handeln AWS
Sie können die folgenden Bedingungsschlüssel verwenden, um es AWS Diensten zu ermöglichen, ihre eigenen Identitäten für den Zugriff auf Ihre Ressourcen zu verwenden, wenn sie in Ihrem Namen handeln.
+ [aws:PrincipalIsAWSService](reference_policies_condition-keys.md#condition-keys-principalisawsservice) und [aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid) (oder [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths) und [aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount)) – Mit diesen Bedingungsschlüsseln können Sie sicherstellen, dass [AWS-Service -Prinzipale](reference_policies_elements_principal.md#principal-services) beim Zugriff auf Ihre Ressourcen dies nur im Namen einer Ressource in der angegebenen Organisation, Organisationseinheit oder einem Konto in AWS Organizations tun.
Weitere Informationen finden Sie unter [Einrichtung eines Datenperimeters unter AWS: Nur vertrauenswürdigen Identitäten den Zugriff auf Unternehmensdaten erlauben](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/).
## Ressourcenperimeter
Ein Ressourcenperimeter ist eine Reihe grob abgestufter, präventiver Zugriffskontrollen, die sicherstellen, dass Ihre Identitäten nur auf vertrauenswürdige Ressourcen zugreifen können und von Ihrem Netzwerk aus nur auf vertrauenswürdige Ressourcen zugegriffen werden kann. Zu den vertrauenswürdigen Ressourcen gehören in der Regel Ressourcen, die Ihren AWS Konten oder AWS Diensten gehören, die in Ihrem Namen handeln.
Die folgenden globalen Bedingungsschlüssel helfen bei der Durchsetzung von Ressourcenperimeterkontrollen auf Grundlage Ihrer Definition vertrauenswürdiger Ressourcen. Verwenden Sie diese Schlüssel in [Dienststeuerungsrichtlinien (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), um einzuschränken, auf welche Ressourcen über Ihre Identitäten zugegriffen werden kann, oder in [VPC-Endpunktrichtlinien](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html), um einzuschränken, auf welche Ressourcen von Ihren Netzwerken aus zugegriffen werden kann.
### Ressourcen in Ihrem Besitz
Sie können die folgenden Bedingungsschlüssel verwenden, um AWS Ressourcen zu definieren, die Sie in Ihrem erstellen und verwalten. AWS-Konten
+ [aws:ResourceOrgID](reference_policies_condition-keys.md#condition-keys-resourceorgid) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass die Ressource, auf die zugegriffen wird, zur angegebenen Organisation in AWS Organizations gehört.
+ [aws:ResourceOrgPaths](reference_policies_condition-keys.md#condition-keys-resourceorgpaths) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass die Ressource, auf die zugegriffen wird, zur angegebenen Organisationseinheit (OE) in AWS Organizations gehört.
+ [aws:ResourceAccount](reference_policies_condition-keys.md#condition-keys-resourceaccount) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass die Ressource, auf die zugegriffen wird, zum angegebenen AWS-Konto gehört.
### Ressourcen von AWS Diensten, die in Ihrem Namen handeln
In einigen Fällen müssen Sie möglicherweise den Zugriff auf AWS eigene Ressourcen gewähren, d. h. auf Ressourcen, die nicht zu Ihrer Organisation gehören und auf die Ihre Prinzipale oder in Ihrem Namen handelnde AWS Dienste zugreifen. Weitere Informationen zu diesen Szenarien finden Sie unter [Einrichtung eines Datenperimeters unter AWS: Nur vertrauenswürdige Ressourcen aus meiner Organisation zulassen](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-resources-from-my-organization/).
## Netzwerkperimeter
Bei einem Netzwerkperimeter handelt es sich um eine Reihe grob abgestufter präventiver Zugriffskontrollen, die sicherstellen, dass Ihre Identitäten nur über erwartete Netzwerke auf Ressourcen zugreifen können und dass auf Ihre Ressourcen nur über erwartete Netzwerke zugegriffen werden kann. Zu den erwarteten Netzwerken gehören in der Regel Ihre lokalen Rechenzentren und virtuelle private Clouds (VPCs) sowie Netzwerke von AWS Diensten, die in Ihrem Namen agieren.
Die folgenden globalen Bedingungsschlüssel helfen bei der Durchsetzung von Netzwerkperimeterkontrollen auf Grundlage Ihrer Definition erwarteter Netzwerke. Verwenden Sie diese Schlüssel in [Dienststeuerungsrichtlinien (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), um Netzwerke einzuschränken, von denen aus Ihre Identitäten kommunizieren können, oder in [Ressourcensteuerungsrichtlinien (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html), um den Ressourcenzugriff auf erwartete Netzwerke einzuschränken.
### Netzwerke, die Ihnen gehören
Sie können die folgenden Bedingungsschlüssel verwenden, um Netzwerke zu definieren, über die Ihre Mitarbeiter und Anwendungen voraussichtlich auf Ihre Ressourcen zugreifen, z. B. den IP-CIDR-Bereich Ihres Unternehmens und Ihr VPCs
+ [aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass die IP-Adresse des Anforderers innerhalb eines angegebenen IP-Bereichs liegt.
+ [aws:SourceVpc](reference_policies_condition-keys.md#condition-keys-sourcevpc) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass der VPC-Endpunkt, durch den die Anfrage läuft, zur angegebenen VPC gehört.
+ [aws:SourceVpce](reference_policies_condition-keys.md#condition-keys-sourcevpce) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass die Anfrage über den angegebenen VPC-Endpunkt läuft.
+ [aws:VpceAccount](reference_policies_condition-keys.md#condition-keys-vpceaccount)— Sie können diesen Bedingungsschlüssel verwenden, um sicherzustellen, dass Anfragen über VPC-Endpunkte kommen, die dem angegebenen AWS Konto gehören.
+ [aws:VpceOrgPaths](reference_policies_condition-keys.md#condition-keys-vpceorgpaths) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass IAM-Prinzipale, die die Anfrage stellen, zur angegebenen Organisationseinheit (OU) in AWS Organizations gehören.
+ [aws:VpceOrgID](reference_policies_condition-keys.md#condition-keys-vpceorgid) – Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass Anfragen über VPC-Endpunkte im Besitz von Konten in der angegebenen Organisation in AWS Organizations laufen.
`aws:VpceAccount`, `aws:VpceOrgPaths` und `aws:VpceOrgID` sind besonders nützlich für die Implementierung von Netzwerkperimeterkontrollen, die automatisch mit der Nutzung Ihrer VPC-Endpunkte skaliert werden, ohne dass Richtlinien aktualisiert werden müssen, wenn Sie neue Endpunkte erstellen. Eine Liste der AWS-Services , die diese Schlüssel unterstützen, finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md).
### Netzwerke von AWS Diensten, die in Ihrem Namen handeln
Sie können die folgenden Bedingungsschlüssel verwenden, um AWS Diensten den Zugriff auf Ihre Ressourcen von ihren Netzwerken aus zu ermöglichen, wenn sie in Ihrem Namen handeln.
+ [aws:ViaAWSService](reference_policies_condition-keys.md#condition-keys-viaawsservice)— Sie können diesen Bedingungsschlüssel verwenden, um sicherzustellen, dass Sie Anfragen im Namen Ihres Auftraggebers über [Forward Access Sessions (FAS)](access_forward_access_sessions.md) (FAS) stellen AWS-Services können.
+ [aws:PrincipalIsAWSService](reference_policies_condition-keys.md#condition-keys-principalisawsservice)— Sie können diesen Bedingungsschlüssel verwenden, um sicherzustellen, dass AWS-Services Sie über [AWS Dienstprinzipale](reference_policies_elements_principal.md#principal-services)
Es gibt weitere Szenarien, in denen Sie AWS-Services den Zugriff auf Ihre Ressourcen von außerhalb Ihres Netzwerks zulassen müssen. Weitere Informationen finden Sie unter [Einrichtung eines Datenperimeters unter AWS: Zugriff auf Unternehmensdaten nur von erwarteten Netzwerken aus zulassen](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-access-to-company-data-only-from-expected-networks/).
## Ressourcen, um mehr über Datenperimeter zu erfahren
Die folgenden Ressourcen können Ihnen dabei helfen, mehr über Datenperimeter in AWS zu erfahren.
+ [Datenperimeter aktiviert AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/) — Erfahren Sie mehr über Datenperimeter und ihre Vorteile und Anwendungsfälle.
+ [Blogbeitragsserie: Einrichtung eines Datenperimeters am AWS](https://aws.amazon.com/identity/data-perimeters-blog-post-series/) — In diesen Blogbeiträgen finden Sie ausführliche Anleitungen zur Einrichtung Ihres Datenperimeters in großem Maßstab, einschließlich wichtiger Sicherheits- und Implementierungsaspekte.
+ [Beispiele für Datenperimeterrichtlinien](https://github.com/aws-samples/data-perimeter-policy-examples/tree/ce06665ca8b2f07debee7bed5153c3be0f31c73c) — Dieses GitHub Repository enthält Beispielrichtlinien, die einige gängige Muster behandeln, um Sie bei der Implementierung eines Datenperimeters zu unterstützen. AWS
+ [Datenperimeter-Helfer](https://github.com/aws-samples/data-perimeter-helper/tree/main?tab=readme-ov-file) – Dieses Tool unterstützt Sie bei der Gestaltung und Prognose der Auswirkungen Ihrer Datenperimeter-Kontrollen, indem es die Zugriffsaktivität in Ihren [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)-Protokollen analysiert.
# Berechtigungsgrenzen für IAM-Entitäten
AWS unterstützt *Berechtigungsgrenzen* für IAM-Entitäten (Benutzer oder Rollen). Eine Berechtigungsgrenze ist ein erweitertes Feature, bei der Sie eine verwaltete Richtlinie verwenden, um die maximalen Berechtigungen festzulegen, die eine identitätsbasierte Richtlinie einer IAM-Entität gewähren kann. Durch eine Berechtigungsgrenze kann eine Entität nur die Aktionen durchführen, die sowohl von den identitätsbasierten Richtlinien als auch den Berechtigungsgrenzen erlaubt werden.
Weitere Informationen zu Richtlinientypen finden Sie unter [Richtlinientypen](access_policies.md#access_policy-types).
**Wichtig**
Verwenden Sie keine ressourcenbasierten Richtlinienanweisungen, die ein `NotPrincipal`-Richtlinienelement mit einer `Deny`-Wirkung für IAM-Benutzer oder -Rollen enthalten, denen eine Richtlinie mit Berechtigungsgrenzen angefügt ist. Das `NotPrincipal`-Element mit `Deny`-Wirkung lehnt immer jeden IAM-Prinzipal ab, an den eine Richtlinie zur Berechtigungsgrenze angefügt ist, unabhängig von den im `NotPrincipal`-Element angegebenen Werten. Dies führt dazu, dass einige IAM-Benutzer oder -Rollen, die andernfalls Zugriff auf die Ressource hätten, den Zugriff verlieren. Wir empfehlen Ihnen, Ihre ressourcenbasierten Richtlinien dahingehend zu ändern, dass Sie den Bedingungsoperator [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) mit dem [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn)-Kontextschlüssel verwenden, um den Zugriff zu begrenzen, anstatt das `NotPrincipal`-Element. Weitere Informationen zum `NotPrincipal`-Element finden Sie unter [AWS JSON-Richtlinienelemente: NotPrincipal](reference_policies_elements_notprincipal.md).
Sie können eine AWS verwaltete Richtlinie oder eine vom Kunden verwaltete Richtlinie verwenden, um die Grenze für eine IAM-Entität (Benutzer oder Rolle) festzulegen. Diese Richtlinie begrenzt die maximalen Berechtigungen für den Benutzer oder die Rolle.
Gehen Sie beispielsweise davon aus, dass der angegebene `Shirley` IAM-Benutzer nur Amazon S3, Amazon und Amazon CloudWatch EC2 verwalten darf. Um diese Regel durchzusetzen, können Sie die folgende Richtlinie verwenden, um die Berechtigungsgrenze für den Benutzer `Shirley` festzulegen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*"
],
"Resource": "*"
}
]
}
```
------
Wenn Sie eine Richtlinie verwenden, um die Berechtigungsgrenze für einen Benutzer festzulegen, schränkt sie die Berechtigungen des Benutzers ein, erteilt aber selbst keine Berechtigungen. In diesem Beispiel legt die Richtlinie die maximalen Berechtigungen für alle Operationen in Amazon S3 und Amazon EC2 fest. `Shirley` CloudWatch Shirley kann niemals Operationen in einem anderen Service durchführen, einschließlich IAM, selbst wenn sie eine Berechtigungsrichtlinie hat, die dies erlaubt. Sie können z. B. dem Benutzer `Shirley` die folgende Richtlinie hinzufügen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
}
```
------
Diese Richtlinie erlaubt das Erstellen eines Benutzers in IAM. Wenn Sie diese Berechtigungsrichtlinie dem Benutzer `Shirley` anfügen und Shirley versucht, einen Benutzer zu erstellen, schlägt die Operation fehl. Sie schlägt fehl, weil die Berechtigungsgrenze den `iam:CreateUser`-Vorgang nicht zulässt. Angesichts dieser beiden Richtlinien hat Shirley keine Berechtigung, Operationen in AWS durchzuführen. Sie müssen eine andere Berechtigungsrichtlinie hinzufügen, um Aktionen in anderen Diensten zuzulassen, z. B. Amazon S3. Alternativ können Sie die Berechtigungsgrenze so aktualisieren, dass sie einen Benutzer in IAM erstellen kann.
## Auswerten von effektiven Berechtigungen mit Grenzen
Die Berechtigungsgrenze für eine IAM-Entität (Benutzer oder Rolle) legt die maximalen Berechtigungen fest, die die Entität haben kann. Dies kann die effektiven Berechtigungen für diesen Benutzer oder diese Rolle ändern. Die effektiven Berechtigungen für eine Entität sind die Berechtigungen, die von allen Richtlinien gewährt werden, die den Benutzer oder die Rolle betreffen. Innerhalb eines Kontos können die Berechtigungen für eine Entität durch identitätsbasierte Richtlinien, ressourcenbasierte Richtlinien, Berechtigungsgrenzen oder Sitzungsrichtlinien beeinflusst werden. AWS Organizations SCPs Weitere Informationen zu den unterschiedlichen Richtlinientypen finden Sie unter [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md).
Wenn eine dieser Richtlinientypen explizit den Zugriff für eine Operation verweigert, dann wird die Anforderung abgelehnt. Die Berechtigungen, die einer Entität durch mehrere Berechtigungstypen gewährt werden, sind komplexer. Weitere Informationen darüber, wie Richtlinien AWS bewertet werden, finden Sie unter. [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md)
**Identitätsbasierte Richtlinien mit Grenzen** – Identitätsbasierte Richtlinien sind verwaltete oder eingebundene Richtlinien, die einem Benutzer, einer Gruppe von Benutzern oder einer Rolle zugewiesen sind. Identitätsbasierte Richtlinien erteilen die Berechtigung für die Entität, Berechtigungsgrenzen beschränken diese Berechtigungen. Effektive Berechtigungen ergeben sich aus der Überlschneidung der beiden Richtlinientypen. Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis.
![\[Auswertung von identitätsbasierten Richtlinien und Berechtigungsgrenzen\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/permissions_boundary.png)
**Ressourcenbasierte Richtlinien** – Ressourcenbasierte Richtlinien steuern, wie der angegebene Auftraggeber auf die Ressource zugreifen kann, der die Richtlinie angefügt ist.
*Ressourcenbasierte Richtlinien für IAM-Benutzer*
Innerhalb desselben Kontos werden ressourcenbasierte Richtlinien, die einem IAM-Benutzer-ARN (bei dem es sich nicht um eine AWS STS föderierte Benutzerprinzipalsitzung handelt) Berechtigungen gewähren, nicht durch eine implizite Ablehnung in einer identitätsbasierten Richtlinie oder Berechtigungsgrenze eingeschränkt.
![\[Auswertung einer ressourcenbasierten Richtlinie, Berechtigungsgrenze und identitätsbasierte Richtlinie\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-rbp-boundary-id.png)
*Ressourcenbasierte Richtlinien für IAM-Rollen*
**IAM-Rolle** – Ressourcenbasierte Richtlinien, die Berechtigungen für einen IAM-Rollen-ARN erteilen, sind durch eine implizite Verweigerung in einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt.
**IAM-Rollensitzung** – Innerhalb desselben Kontos gewähren ressourcenbasierte Richtlinien, die einem IAM-Rollensitzungs-ARN Berechtigungen erteilen, auch direkt Berechtigungen für die angenommene Rollensitzung. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt. Wenn Sie eine Rolle übernehmen und eine Anfrage stellen, ist der Prinzipal, der die Anfrage stellt, der ARN der IAM-Rollensitzung und nicht der ARN der Rolle selbst.
*Ressourcenbasierte Richtlinien für föderierte Benutzerprinzipalsitzungen AWS STS *
**AWS STS föderierte Benutzerprinzipalsitzungen** — Eine AWS STS föderierte Benutzerprinzipalsitzung ist eine Sitzung, die durch einen Aufruf erstellt wird. [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) Wenn ein Verbundbenutzer eine Anfrage stellt, ist der Prinzipal, der die Anfrage stellt, der ARN des Verbundbenutzers und nicht der ARN des IAM-Benutzers, der den Verbund erstellt hat. Innerhalb desselben Kontos erteilen ressourcenbasierte Richtlinien, die einem Verbundbenutzer-ARN Berechtigungen gewähren, der Sitzung direkt Berechtigungen. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt.
Wenn jedoch eine ressourcenbasierte Richtlinie dem ARN des IAM-Benutzers, der den Verbund erstellt hat, Zugriff gewährt, werden Anfragen, die vom AWS STS Verbundbenutzerprinzipal während der Sitzung gestellt werden, durch eine implizite Verweigerung in einer Berechtigungsgrenze oder Sitzungsrichtlinie eingeschränkt.
**AWS Organizations SCPs**— SCPs werden auf ein Ganzes angewendet. AWS-Konto Sie schränken die Berechtigungen für jede Anforderung ein, die von einem Auftraggeber innerhalb des Kontos gesendet wurden. eine IAM-Entität (Benutzer oder Rolle) kann eine Anforderung stellen, die durch eine SCP, eine Berechtigungsgrenze und eine identitätsbasierte Richtlinie beeinflusst wird. In diesem Fall wird die Anforderung nur gewährt, wenn alle drei Richtlinientypen sie zulassen. Die effektiven Berechtigungen ergeben sich aus der Überschneidung der drei Richtlinientypen. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft.
![\[Auswertung einer SCP, Berechtigungsgrenze und identitätsbasierten Richtlinie\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-scp-boundary-id.png)
Sie können erfahren [ob Ihr Konto als Mitgliedskonto einer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) in AWS Organizations eingerichtet ist. Eine SCP hat möglicherweise Auswirkungen auf Mitglieder einer Organisation. Um diese Daten mithilfe des AWS CLI Befehls oder der AWS API-Operation anzeigen zu können, müssen Sie über Berechtigungen für die `organizations:DescribeOrganization` Aktion für Ihre AWS Organizations Entität verfügen. Sie benötigen zusätzliche Berechtigungen, um den Vorgang in der AWS Organizations Konsole ausführen zu können. Um zu erfahren, ob ein SCP den Zugriff auf eine bestimmte Anfrage verweigert, oder um Ihre aktuellen Berechtigungen zu ändern, wenden Sie sich an Ihren AWS Organizations Administrator.
**Sitzungsrichtlinien** – Sitzungsrichtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie eine temporäre Sitzung für eine Rolle oder einen Verbundbenutzer programmgesteuert erstellen. Die Berechtigungen für eine Sitzung stammen aus der IAM-Entität (Benutzer oder Rolle), die verwendet wird, um die Sitzung zu erstellen, und von der Sitzungsrichtlinie. Die identitätsbasierten Richtlinienberechtigungen der Entität werden von der Sitzungsrichtlinie und der Berechtigungsgrenze eingeschränkt. Die effektiven Berechtigungen für diese Gruppe von Richtlinientypen ergeben sich aus der Überschneidung aller drei Richtlinientypen. Eine explizite Zugriffsverweigerung in einer dieser Richtlinien setzt eine Zugriffserlaubnis außer Kraft. Weitere Informationen zu Sitzungsrichtlinien finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session).
![\[Auswertung einer Sitzungsrichtlinie, einer Berechtigungsgrenze und einer identitätsbasierten Richtlinie\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## Verantwortung mit Hilfe von Berechtigungsgrenzen an andere delegieren
Sie können Berechtigungsgrenzen verwenden, um Berechtigungsverwaltungsaufgaben, wie das Erstellen von Benutzern, an IAM-Benutzer in Ihrem Konto zu delegieren. Dies erlaubt es anderen, Aufgaben in Ihrem Namen innerhalb einer bestimmten Berechtigungsgrenze auszuführen.
Nehmen wir zum Beispiel an, dass María die Administratorin der X-Company ist. AWS-Konto Sie möchte die Aufgaben der Benutzererstellung an Zhang delegieren. Sie muss jedoch sicherstellen, dass Zhang Benutzer erstellt, die sich an die folgenden Unternehmensregeln halten:
+ Benutzer können IAM nicht verwenden, um Benutzer, Gruppen, Rollen oder Richtlinien zu erstellen oder zu verwalten.
+ Benutzer erhalten keinen Zugriff auf den Amazon S3 `logs`-Bucket und keinen Zugriff auf die `i-1234567890abcdef0` Amazon EC2-Instance.
+ Benutzer können ihre eigenen Begrenzungsrichtlinien nicht entfernen.
Um diese Regeln durchzusetzen, führt María die folgenden Aufgaben durch, die im Folgenden näher erläutert werden:
1. María erstellt die verwaltete Richtlinie `XCompanyBoundaries` als Berechtigungsgrenze für alle neuen Benutzer im Konto.
1. María erstellt die verwaltete Richtlinie `DelegatedUserBoundary` und weist sie als Berechtigungsgrenze für Zhang zu. Maria notiert den ARN ihres Administratorbenutzers und verwendet ihn in der Richtlinie, um zu verhindern, dass Zhang darauf zugreifen kann.
1. María erstellt die verwaltete Richtlinie `DelegatedUserPermissions` und fügt sie als Berechtigungsrichtlinie für Zhang hinzu.
1. María informiert Zhang über seine neuen Aufgaben und Grenzen.
**Aufgabe 1:** María muss zuerst eine verwaltete Richtlinie erstellen, um die Grenzen für die neuen Benutzer festzulegen. María wird es Zhang erlauben, den Benutzern die erforderlichen Rechte zu geben, aber sie möchte, dass diese Benutzer eingeschränkt werden. Zu diesem Zweck erstellt sie die folgende kundenverwaltete Richtlinie mit dem Namen `XCompanyBoundaries`. Diese Richtlinie gewährt die folgenden Aktionen:
+ Ermöglicht den Benutzern den vollständigen Zugriff auf mehrere Services
+ Ermöglicht eingeschränkten selbstverwaltenden Zugriff in der IAM-Konsole. Das bedeutet, dass sie ihr Passwort ändern können, nachdem sie sich bei der Konsole angemeldet haben. Sie können ihr anfängliches Passwort nicht festlegen. Um dies zu ermöglichen, fügen Sie die Aktion `"*LoginProfile"` zur Anweisung `AllowManageOwnPasswordAndAccessKeys` hinzu.
+ Verweigert Benutzern den Zugriff auf den Amazon S3 Protokoll-Bucket oder die `i-1234567890abcdef0`-Amazon EC2-Instance
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ServiceBoundaries",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*",
"dynamodb:*"
],
"Resource": "*"
},
{
"Sid": "AllowIAMConsoleForCredentials",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswordAndAccessKeys",
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:ChangePassword",
"iam:GetUser",
"iam:*ServiceSpecificCredential*",
"iam:*SigningCertificate*"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::logs",
"arn:aws:s3:::logs/*"
]
},
{
"Sid": "DenyEC2Production",
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
}
]
}
```
------
Jede Anweisung dient einem anderen Zweck:
1. Die `ServiceBoundaries` Erklärung dieser Richtlinie ermöglicht den vollen Zugriff auf die angegebenen AWS Dienste. Dies bedeutet, dass die Aktionen eines neuen Benutzers in diesen Services nur laut der Berechtigungsrichtlinien begrenzt sind, die dem Benutzer zugeordnet sind.
1. Die `AllowIAMConsoleForCredentials`-Anweisung erlaubt den Zugriff für das Auflisten aller IAM-Benutzer. Dieser Zugriff ist erforderlich, um auf der Seite **Users (Benutzer)** in der AWS-Managementkonsole navigieren zu können. Außerdem können die Passwortanforderungen für das Konto angezeigt werden, was erforderlich ist, wenn Sie Ihr eigenes Passwort ändern.
1. Mit der `AllowManageOwnPasswordAndAccessKeys`-Anweisung können Benutzer nur ihr eigenes Konsolen-Passwort und programmatische Zugriffsschlüssel verwalten. Dies ist wichtig, wenn Zhang oder ein anderer Administrator einem neuen Benutzer eine Berechtigungsrichtlinie mit vollem IAM-Zugriff zuweist. In diesem Fall könnte der Benutzer seine eigenen Berechtigungen oder die anderer Benutzer ändern. Diese Anweisung verhindert, dass dies passiert.
1. Die Anweisung `DenyS3Logs` verweigert explizit den Zugriff auf den `logs`-Bucket.
1. Die Anweisung `DenyEC2Production` verweigert explizit den Zugriff auf die `i-1234567890abcdef0`-Instance.
**Aufgabe 2:** María möchte Zhang erlauben, alle Benutzer für die X-Company Benutzer zu erstellen, aber nur mit der Berechtigungsgrenze `XCompanyBoundaries`. Sie erstellt die folgende kundenverwaltete Richtlinie mit dem Namen `DelegatedUserBoundary`. Diese Richtlinie definiert die maximale Berechtigungen, die Zhang haben kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateOrChangeOnlyWithBoundary",
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy",
"iam:CreateUser",
"iam:DeleteUserPolicy",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
}
}
},
{
"Sid": "CloudWatchAndOtherIAMTasks",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"iam:CreateAccessKey",
"iam:CreateGroup",
"iam:CreateLoginProfile",
"iam:CreatePolicy",
"iam:DeleteGroup",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteUser",
"iam:GetAccountPasswordPolicy",
"iam:GetGroup",
"iam:GetLoginProfile",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListEntitiesForPolicy",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListMFADevices",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:ListSSHPublicKeys",
"iam:ListServiceSpecificCredentials",
"iam:ListSigningCertificates",
"iam:ListUserPolicies",
"iam:ListUsers",
"iam:SetDefaultPolicyVersion",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy",
"iam:UpdateGroup",
"iam:UpdateLoginProfile",
"iam:UpdateUser"
],
"NotResource": "arn:aws:iam::123456789012:user/Maria"
},
{
"Sid": "NoBoundaryPolicyEdit",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": [
"arn:aws:iam::123456789012:policy/XCompanyBoundaries",
"arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
]
},
{
"Sid": "NoBoundaryUserDelete",
"Effect": "Deny",
"Action": "iam:DeleteUserPermissionsBoundary",
"Resource": "*"
}
]
}
```
------
Jede Anweisung dient einem anderen Zweck:
1. Die Anweisung `CreateOrChangeOnlyWithBoundary` erlaubt es Zhang, IAM-Benutzer zu erstellen, aber nur, wenn er die Richtlinie `XCompanyBoundaries` verwendet, um die Berechtigungsgrenze festzulegen. Diese Anweisung erlaubt es ihm auch, die Berechtigungsgrenze für bestehende Benutzer festzulegen, jedoch nur mit der gleichen Richtlinie. Diese Anweisung schließlich erlaubt Zhang, Berechtigungsrichtlinien für Benutzer mit dieser Berechtigungsgrenze zu verwalten.
1. Die Anweisung `CloudWatchAndOtherIAMTasks` ermöglicht es Zhang, andere Aufgaben der Benutzer-, Gruppen- und Richtlinienverwaltung auszuführen. Dieser verfügt über Berechtigungen zum Zurücksetzen von Passwörtern und Erstellen von Zugriffsschlüsseln für alle IAM-Benutzer, die nicht im `NotResource`-Richtlinienelement aufgeführt sind. Dadurch kann er Benutzern bei Anmeldeproblemen helfen.
1. Die Anweisung `NoBoundaryPolicyEdit` verweigert Zhang Zugriff, um die Richtlinie `XCompanyBoundaries` zu aktualisieren. Er darf keine Richtlinien ändern, die dazu dienen, die Berechtigungsgrenze für sich selbst oder andere Benutzer festzulegen.
1. Die `NoBoundaryUserDelete`-Anweisung verweigert Zhang den Zugriff zum Löschen der Berechtigungsgrenze für ihn oder andere Benutzer.
María weist anschließend die`DelegatedUserBoundary` Richtlinie [als Berechtigungsgrenze ](id_users_change-permissions.md#users_change_permissions-set-boundary-console) für den Benutzer `Zhang` zu.
**Aufgabe 3:** Da die Berechtigungsgrenze die maximalen Berechtigungen begrenzt, aber selbst keinen Zugriff gewährt, muss Maria eine Berechtigungsrichtlinie für Zhang erstellen. Sie erstellt die folgende Richtlinie mit dem Namen `DelegatedUserPermissions`. Diese Richtlinie definiert die Operationen, die Zhang innerhalb der definierten Grenzen ausführen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "IAM",
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
},
{
"Sid": "CloudWatchLimited",
"Effect": "Allow",
"Action": [
"cloudwatch:GetDashboard",
"cloudwatch:GetMetricData",
"cloudwatch:ListDashboards",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "S3BucketContents",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::ZhangBucket"
}
]
}
```
------
Jede Anweisung dient einem anderen Zweck:
1. Die `IAM`-Anweisung der Richtlinie gewährt Zhang den vollständigen Zugriff auf IAM. Da seine Berechtigungsgrenze jedoch nur einige IAM-Operationen zulässt, sind seine effektiven IAM-Berechtigungen nur durch seine Berechtigungsgrenze begrenzt.
1. Die `CloudWatchLimited` Aussage ermöglicht es Zhang, fünf Aktionen auszuführen. CloudWatch Seine Rechtegrenze lässt alle Aktionen zu CloudWatch, sodass seine effektiven CloudWatch Berechtigungen nur durch seine Berechtigungsrichtlinie eingeschränkt werden.
1. Mit der `S3BucketContents`-Anweisung kann Zhang den Amazon S3-Bucket `ZhangBucket` auflisten. Allerdings erlaubt seine Berechtigungsgrenze keine Amazon S3-Aktion, so kann er keine S3-Operationen durchführen, unabhängig von seiner Berechtigungsrichtlinie.
**Anmerkung**
Zhangs Richtlinien ermöglichen es ihm, einen Benutzer zu erstellen, der dann auf Amazon S3-Ressourcen zugreifen kann, auf die er nicht zugreifen kann. Durch die Delegation dieser administrativen Maßnahmen vertraut Maria effektiv Zhang mit dem Zugriff auf Amazon S3.
María weist anschließend die `DelegatedUserPermissions`-Richtlinie als Berechtigungsrichtlinie für den Benutzer `Zhang` zu.
**Aufgabe 4:** Sie gibt Zhang Anweisungen, einen neuen Benutzer zu erstellen. Sie sagt ihm, dass er neue Benutzer mit allen erforderlichen Berechtigungen anlegen kann, aber er muss ihnen die Richtlinie `XCompanyBoundaries` als Berechtigungsgrenze zuweisen.
Zhang führt die folgenden Aufgaben aus:
1. Zhang erstellt einen Benutzer mit dem AWS-Managementkonsole. Er gibt den Benutzernamen `Nikhil` ein und aktiviert den Konsolenzugriff für den Benutzer. Er deaktiviert das Kontrollkästchen neben **Passwortrücksetzung erforderlich**, da die oben genannten Richtlinien Benutzern erst dann erlauben, ihr Passwort zu ändern, nachdem sich bei der IAM-Konsole angemeldet haben.
1. Auf der Seite **„Berechtigungen festlegen**“ wählt Zhang die **IAMFullAccess** - und **ReadOnlyAccessAmazonS3-Berechtigungsrichtlinien** aus, die es Nikhil ermöglichen, seine Arbeit zu erledigen.
1. Zhang überspringt den Abschnitt **Set permissions boundary (Berechtigungsgrenze festlegen)** und vergisst die Anweisungen von María.
1. Zhang überarbeitet die Benutzerdetails und wählt **Create user (Benutzer erstellen)**.
Die Operation schlägt fehl und der Zugriff wird verweigert. Die Berechtigungsgrenze `DelegatedUserBoundary` von Zhang fordert, dass alle Benutzer, die er erstellt, die Richtlinie `XCompanyBoundaries` als Berechtigungsgrenze verwenden.
1. Zhang kehrt zurück auf die vorherige Seite. Im Abschnitt **Set permissions boundary (Berechtigungsgrenze festlegen)** wählt er die Richtlinie `XCompanyBoundaries`.
1. Zhang überarbeitet die Benutzerdetails und wählt **Create user (Benutzer erstellen)**.
Der Benutzer wird erstellt.
Wenn Nikhil sich anmeldet, hat er Zugriff auf IAM und Amazon S3, mit Ausnahme der Operationen, die laut der Berechtigungsgrenze verweigert werden. Zum Beispiel kann er sein eigenes Passwort in IAM ändern, aber keinen anderen Benutzer anlegen oder seine Richtlinien bearbeiten. Nikhil hat schreibgeschützten Zugriff auf Amazon S3.
Wenn jemand dem `logs`-Bucket eine ressourcenbasierte Richtlinie zuordnet, die Nikhil das Hinzufügen eines Objekts in den Bucket gewährt, dann kann immer noch nicht auf den Bucket zuzugreifen. Der Grund ist, dass alle Aktionen im `logs`-Bucket durch seine Berechtigungsgrenze explizit verweigert werden. Eine explizite Zugriffsverweigerung in jedem Richtlinientyp führt dazu, dass eine Anforderung verweigert wird. Wenn jedoch eine ressourcenbasierte Richtlinie, die mit einem Secrets Manager-Geheimnis verknüpft ist, Nikhil erlaubt, die `secretsmanager:GetSecretValue`-Aktion durchzuführen, kann Nikhil das Geheimnis abrufen und entschlüsseln. Der Grund dafür ist, dass Secrets Manager-Operationen von seiner Berechtigungsgrenze nicht explizit verweigert werden, und impliziete Zugriffsverweigerungen in Berechtigungsgrenzen beschränken keine ressourcenbasierte Richtlinien.
# Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien
Eine Richtlinie ist ein Objekt, AWS das, wenn es einer Identität oder Ressource zugeordnet ist, deren Berechtigungen definiert. Wenn Sie eine Berechtigungsrichtlinie erstellen, um den Zugriff auf eine Ressource einzuschränken, können Sie zwischen einer *identitätsbasierten Richtlinie* und einer *ressourcenbasierten Richtlinie* wählen.
**Identitätsbasierte Richtlinien** werden an IAM-Benutzer, -Gruppen oder -Rollen angefügt. Mit diesen Richtlinien können Sie festlegen, welche Aktionen diese Identität durchführen darf (ihre Berechtigungen). Sie können die Richtlinie beispielsweise dem IAM-Benutzer John zuordnen und ihm erlauben, die Aktion Amazon EC2 `RunInstances` auszuführen. Die Richtlinie könnte weiterhin besagen, dass John Elemente aus einer Amazon DynamoDB-Tabelle mit dem Namen `MyCompany` abrufen darf. Sie können auch zulassen, dass John seine eigenen IAM-Sicherheitsanmeldeinformationen verwaltet. Identitätsbasierte Richtlinien können [verwaltet oder eingebunden](access_policies_managed-vs-inline.md) sein.
**Ressourcenbasierten Richtlinien** sind an eine Ressource angefügt. Sie können beispielsweise ressourcenbasierte Richtlinien an Amazon-S3-Buckets, Amazon-SQS-Warteschlangen, VPC-Endpunkte, AWS Key Management Service -Verschlüsselungsschlüssel sowie Amazon-DynamoDB-Tabellen und -Streams anfügen. Eine Liste der Services, die ressourcenbasierte Richtlinien unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md).
Mit ressourcenbasierten Richtlinien können Sie festlegen, wer Zugriff auf die Ressource hat und welche Aktionen ausgeführt werden können. Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Was ist IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Ressourcenbasierten Richtlinien sind nur eingebundene Richtlinien, keine verwalteten Richtlinien.
**Anmerkung**
*Ressourcenbasierte* Richtlinien unterscheiden sich von Berechtigungen auf *Ressourcenebene*. Sie können ressourcenbasierte Richtlinien direkt an eine Ressource anfügen, wie in diesem Thema beschrieben. Berechtigungen auf Ressourcenebene beziehen sich auf die Möglichkeit, einzelne Ressourcen in einer Richtlinie [ARNs](reference_identifiers.md#identifiers-arns)zu spezifizieren. Ressourcenbasierte Richtlinien werden nur von einigen Diensten unterstützt. AWS Eine Liste der Services, die ressourcenbasierte Richtlinien und Berechtigungen auf Ressourcenebene unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md).
Wie identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien innerhalb desselben Kontos zusammenwirken, erfahren Sie unter [Richtlinienauswertung für Anfragen innerhalb eines einzelnen Kontos](reference_policies_evaluation-logic_policy-eval-basics.md).
Wie die Richtlinien kontenübergreifend zusammenwirken, erfahren Sie unter [Logik für die kontoübergreifende Richtlinienauswertung](reference_policies_evaluation-logic-cross-account.md).
Um ein besseres Verständnis dieser Konzepte zu erhalten, betrachten Sie die folgende Abbildung. Der Administrator des Kontos `123456789012` hat *identitätsbasierten Richtlinien* an die Benutzer `John`, `Carlos` und `Mary` angefügt. Einige der Aktionen in diesen Richtlinien können für bestimmte Ressourcen ausgeführt werden. Der Benutzer `John` kann beispielsweise einige Aktionen für `Resource X` ausführen. Dies ist eine *Berechtigung auf Ressourcenebene* in einer identitätsbasierten Richtlinie. Der Administrator hat außerdem *ressourcenbasierte Richtlinien* zu `Resource X`, `Resource Y` und `Resource Z` hinzugefügt. Mithilfe von ressourcenbasierten Richtlinien können Sie festlegen, wer auf diese Ressource zugreifen kann. Die ressourcenbasierte Richtlinie für `Resource X` gewährt beispielsweise den Benutzern `John` und `Mary` Lese- und Schreibzugriff auf die Ressource.
![\[Unterschiede zwischen identitätsbasierten und ressourcenbasierten Richtlinien\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/Types_of_Permissions.diagram.png)
Das Kontobeispiel `123456789012` erlaubt den folgenden Benutzern, die aufgeführten Aktionen durchzuführen:
+ **John** – John kann Auflistungs- und Leseaktionen für `Resource X` durchführen. Er erhält diese Berechtigung über die identitätsbasierte Richtlinie seines Benutzers sowie die ressourcenbasierte Richtlinien von `Resource X`.
+ **Carlos** – Carlos kann Auflistungs-, Lese- und Schreibaktionen für `Resource Y` ausführen, nicht jedoch auf `Resource Z` zugreifen. Die identitätsbasierte Richtlinie von Carlos ermöglicht ihm, Auflistungs- und Leseaktionen für `Resource Y` auszuführen. Die ressourcenbasierte Richtlinie von `Resource Y` gewährt ihm Schreibberechtigungen. Aber obwohl er über seine identitätsbasierte Richtlinie Zugriff auf `Resource Z` erhält, wird ihm dieser Zugriff von der ressourcenbasierten Richtlinie `Resource Z` verweigert. Eine explizite Zugriffsverweigerung `Deny` hat Vorrang vor einer Zugriffserlaubnis `Allow` und sein Zugriff auf `Resource Z` wird verweigert. Weitere Informationen finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
+ **Mary** – Mary kann Auflistungs-, Lese- und Schreibvorgänge für `Resource X`, `Resource Y` und `Resource Z` ausführen. Ihre identitätsbasierte Richtlinie gewährt ihr weitere Aktionen für weitere Ressourcen als die ressourcenbasierten Richtlinien, aber keine davon enthält eine Zugriffsverweigerung.
+ **Zhang** – Zhang hat Vollzugriff auf `Resource Z`. Zhang verfügt über keine identitätsbasierten Richtlinien, erhält jedoch über die ressourcenbasierte Richtlinie von `Resource Z` Vollzugriff auf die Ressource. Zhang kann auch Auflistungs- und Leseaktionen für `Resource Y` ausführen.
Sowohl identitätsbasierte als auch ressourcenbasierte Richtlinien sind Berechtigungsrichtlinien, die gemeinsam ausgewertet werden. Bei einer Anfrage, für die nur Berechtigungsrichtlinien gelten, werden AWS zunächst alle Richtlinien auf eine überprüft. `Deny` Ist eine Zugriffsverweigerung vorhanden, wird die Anfrage abgelehnt. Danach sucht AWS nach jedem `Allow`. Wenn die Aktion in der Anforderung von mindestens einer Richtlinienanweisung gewährt wird, wird die Anforderung gewährt. Dabei spielt es keine Rolle, ob `Allow` in der identitätsbasierten oder der ressourcenbasierten Richtlinie vorhanden ist.
**Wichtig**
Diese Logik gilt nur, wenn die Anforderung von einem einzelnen AWS-Konto gesendet wird. Bei Anfragen, die von einem Konto an ein anderes gesendet werden, muss der Anforderer in `Account A` über eine identitätsbasierte Richtlinie verfügen, die es ihm ermöglicht, Anforderungen an die Ressource in `Account B` zu senden. Darüber hinaus muss die ressourcenbasierte Richtlinie in `Account B` dem Anforderer in `Account A` Zugriff auf die Ressource gewähren. In beiden Konten müssen Richtlinien vorhanden sein, die die Operation. Andernfalls schlägt die Anforderung fehl. Weitere Informationen zur Verwendung von ressourcenbasierten Richtlinien für kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Zugriff auf Ressourcen in IAM](access_policies-cross-account-resource-access.md).
Ein Benutzer mit speziellen Berechtigungen kann eine Ressource anfordern, an die ebenfalls eine Berechtigungsrichtlinie angefügt ist. In diesem Fall werden bei der Entscheidung, ob Zugriff auf die Ressource gewährt werden soll, beide AWS Berechtigungssätze ausgewertet. Weitere Informationen über das Auswerten von Richtlinien finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
**Anmerkung**
Amazon S3 unterstützt identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien (als *Bucket-Richtlinien* bezeichnet). Darüber hinaus unterstützt Amazon S3 einen Berechtigungsmechanismus, der auch als *Access Control List (ACL)* bezeichnet wird, der von IAM-Richtlinien und -Berechtigungen unabhängig ist. Sie können IAM-Richtlinien in Kombination mit Amazon S3 ACLs verwenden. Weitere Informationen finden Sie unter [Access Control](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
# Steuern Sie den Zugriff auf AWS Ressourcen mithilfe von Richtlinien
Sie können eine Richtlinie verwenden, um den Zugriff auf Ressourcen innerhalb von IAM oder allen von AWS zu kontrollieren.
Um eine [Richtlinie](access_policies.md) zur Zugriffskontrolle verwenden zu können AWS, müssen Sie wissen, wie der Zugriff AWS gewährt wird. AWS besteht aus Sammlungen von *Ressourcen*. Ein IAM-Benutzer ist eine Ressource. Ein Amazon S3-Bucket ist eine Ressource. Wenn Sie die AWS API, die oder die verwenden AWS CLI, AWS-Managementkonsole um einen Vorgang auszuführen (z. B. einen Benutzer zu erstellen), senden Sie eine *Anfrage* für diesen Vorgang. Ihre Anfrage gibt eine Aktion, eine Ressource, eine *Prinzipal-Entität* (Gruppe oder Rolle) und ein *Prinzipalkonto* an und enthält alle erforderlichen Anfrageinformationen. Diese Informationen stellen den *Kontext* bereit.
AWS überprüft dann, ob Sie (der Principal) authentifiziert (angemeldet) und autorisiert (berechtigt) sind, die angegebene Aktion auf der angegebenen Ressource auszuführen. AWS Überprüft während der Autorisierung alle Richtlinien, die für den Kontext Ihrer Anfrage gelten. Die meisten Richtlinien werden AWS als [JSON-Dokumente](access_policies.md#access_policies-json) gespeichert und spezifizieren die Berechtigungen für Hauptentitäten. Weitere Informationen zu diesen Richtlinienarten und ihrer Verwendung finden Sie unter [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md).
AWS autorisiert die Anfrage nur, wenn jeder Teil Ihrer Anfrage gemäß den Richtlinien zulässig ist. Eine Abbildung dieses Prozesses finden Sie unter [Funktionsweise von IAM](intro-structure.md). Einzelheiten dazu, wie AWS bestimmt wird, ob eine Anfrage zulässig ist, finden Sie unter[Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
Wenn Sie eine IAM-Richtlinie erstellen, können Sie den Zugriff auf Folgendes steuern:
+ **[Prinzipal](#access_controlling-principals)** – Legen Sie fest, welche Aktionen die Person, die die Anfrage stellt (der [Prinzipal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)), durchführen darf.
+ **[IAM-Identitäten](#access_controlling-identities)** – Steuern Sie, auf welche IAM-Identitäten (IAM-Gruppen, -Benutzer und -Rollen) zugegriffen werden kann und wie.
+ **[IAM-Richtlinien](#access_controlling-policies)** – Legen Sie fest, wer vom Benutzer verwaltete Richtlinien erstellen, bearbeiten und löschen und wer verwaltete Richtlinien anfügen und entfernen kann.
+ **[AWS -Ressourcen](#access_controlling-resources)** – Legen sie fest, wer über eine identitätsbasierte oder ressourcenbasierte Richtlinie Zugriff auf Ressourcen hat.
+ **[AWS -Konten](#access_controlling-principal-accounts)** – Legen Sie fest, ob eine Anfrage nur für Mitglieder eines bestimmten Kontos zulässig ist.
Mithilfe von Richtlinien können Sie festlegen, wer Zugriff auf AWS Ressourcen hat und welche Aktionen sie mit diesen Ressourcen ausführen können. Jeder IAM-Benutzer beginnt ohne Berechtigungen. Mit anderen Worten: Benutzer können standardmäßig nichts tun, nicht einmal ihre eigenen Zugriffsschlüssel anzeigen. Um einem Benutzer eine Berechtigung für eine Aktion zu erteilen, können Sie diese zum Benutzer hinzufügen (Sie ordnen dem Benutzer eine Richtlinie zu). Alternativ können Sie den Benutzer einer Gruppe hinzufügen, der die gewünschte Berechtigung bereits zugewiesen wurde.
Sie können beispielsweise einem Benutzer die Berechtigung gewähren, die eigenen Zugriffsschlüssel aufzulisten. Sie können diese Berechtigung auch erweitern, sodass jeder Benutzer die eigenen Schlüssel auch erstellen, aktualisieren und löschen kann.
Wenn Sie einer Gruppe Berechtigungen geben, erhalten alle Benutzer in dieser Gruppe diese Berechtigungen. Beispielsweise können Sie der Benutzergruppe „Administratoren“ die Berechtigung erteilen, alle IAM-Aktionen auf allen AWS-Konto Ressourcen durchzuführen. Ein weiteres Beispiel: Sie können der Gruppe Managers die Berechtigung zum Beschreiben der Amazon-EC2-Instances des AWS-Konto geben.
Informationen zum Delegieren grundlegender Berechtigungen an Ihre Benutzer, IAM-Gruppen und Rollen finden Sie unter [Erforderliche Berechtigungen für den Zugriff auf IAM-Ressourcen](access_permissions-required.md). Weitere Beispiele für Richtlinien, die grundlegende Berechtigungen veranschaulichen, finden Sie unter [Beispielrichtlinien für die Verwaltung von IAM-Ressourcen](id_credentials_delegate-permissions_examples.md).
## Zugriffssteuerung für Prinzipale
Sie können mit Richtlinien steuern, welche Aktionen die Person (der Prinzipal), von der die Anfrage stammt, ausführen darf. Dazu müssen Sie eine identitätsbasierte Richtlinie an die Identität dieser Person (Benutzer, Gruppe von Benutzern oder Rolle) anfügen. Sie können außerdem eine [Berechtigungsgrenze](access_policies_boundaries.md) zum Festlegen der maximalen Berechtigungen, die eine Entität (Benutzer oder Rolle) haben kann, verwenden.
Nehmen Sie beispielsweise an, dass der Benutzer Zhang Wei vollen Zugriff auf Amazon DynamoDB CloudWatch, Amazon EC2 und Amazon S3 haben soll. In diesem Fall erstellen Sie zwei verschiedene Richtlinien, die Sie später aufbrechen können, wenn Sie einen Berechtigungssatz für einen anderen Benutzer benötigen. Alternativ können Sie beide Berechtigungen in einer einzigen Richtlinie vereinen und diese Richtlinie anschließend dem IAM-Benutzer namens Zhang Wei zuweisen. Sie können auch eine Richtlinie zu einer Gruppe zuweisen, der Zhang angehört, oder einer Rolle zuordnen, die Zhang annehmen kann. Wenn Zhang dann die Inhalte eines S3-Buckets anzeigt, werden die Anfragen zugelassen. Wenn der Benutzer versucht, einen neuen IAM-Bucket zu erstellen, wird die Anfrage aufgrund fehlender Berechtigung abgelehnt.
Sie können eine Berechtigungsgrenze für Zhang verwenden, um sicherzustellen, dass er nie Zugriff auf den S3-Bucket `amzn-s3-demo-bucket1` erhält. Dazu bestimmen Sie die *maximalen* Berechtigungen, die Zhang erhalten soll. In diesem Fall steuern Sie, was er unter Verwendung seiner Berechtigungsrichtlinien machen kann. Hier kümmert es Sie nur, dass er nicht auf den vertraulichen Bucket zugreift. Sie verwenden also die folgende Richtlinie, um Zhangs Grenze so zu definieren, dass alle AWS Aktionen für Amazon S3 und einige andere Dienste zulässig sind, aber der Zugriff auf den `amzn-s3-demo-bucket1` S3-Bucket verweigert wird. Da die Berechtigungsgrenze keine IAM-Aktionen zulässt, verhindert sie, dass Zhang seine Grenze (oder die eines anderen Benutzers) löscht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionsBoundarySomeServices",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"dynamodb:*",
"ec2:*",
"s3:*"
],
"Resource": "*"
},
{
"Sid": "PermissionsBoundaryNoConfidentialBucket",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
}
]
}
```
------
Wenn Sie eine solche Richtlinie als Berechtigungsgrenze für einen Benutzer zuweisen, denken Sie daran, dass sie keine Berechtigungen gewährt. Sie legt die maximalen Berechtigungen fest, die eine identitätsbasierte Richtlinie einer IAM-Entität erteilen kann. Weitere Informationen über Berechtigungsgrenzen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](access_policies_boundaries.md).
Weitere Informationen zu den oben genannten Verfahren finden Sie in diesen Ressourcen:
+ Weitere Informationen zum Erstellen einer IAM-Richtlinie, die Sie zu einem Prinzipal zuordnen können, finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
+ Weitere Informationen zum Hinzufügen einer IAM-Richtlinie zu einem Prinzipal finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](access_policies_manage-attach-detach.md).
+ Ein Beispielrichtlinie zum Gewähren eines Vollzugriffs auf EC2 finden Sie unter [Amazon EC2: Gewährt EC2-Vollzugriff innerhalb einer bestimmten Region programmatisch und in der Konsole](reference_policies_examples_ec2_region.md).
+ Zum Gewähren eines Lesezugriffs auf einen S3-Bucket verwenden Sie die ersten beiden Anweisungen der folgenden Beispielrichtlinie: [Amazon S3: Gewährt Lese- und Schreibzugriff auf Objekte in einem S3-Bucket programmgesteuert und in der Konsole](reference_policies_examples_s3_rw-bucket-console.md).
+ Eine Beispielrichtlinie, mit der Benutzer ihre Anmeldeinformationen wie ihr Konsolenkennwort, ihre programmgesteuerten Zugriffsschlüssel und ihre MFA-Geräte festlegen können, finden Sie unter [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md).
## Steuern des Zugriffs auf Identitäten
Sie können IAM-Richtlinien verwenden, um zu steuern, was Ihre Benutzer mit einer Identität machen können, indem Sie eine Richtlinie erstellen, die Sie über eine Gruppe allen Benutzern hinzufügen. Dazu erstellen Sie eine Richtlinie, aus denen die Aktionen hervorgehen, die für eine Identität durchgeführt werden dürfen, oder die festlegt, wer zugriffsberechtigt ist.
Sie können beispielsweise eine Benutzergruppe mit dem Namen **AllUsers**erstellen und diese Benutzergruppe dann allen Benutzern zuordnen. Beim Erstellen der Benutzergruppe können Sie allen Benutzern Zugriff darauf gewähren, ihre Anmeldeinformationen wie im vorherigen Abschnitt beschrieben festzulegen. Anschließend können Sie eine Richtlinie erstellen, die einen Zugriff zum Ändern der Gruppe verweigert, sofern der Benutzername nicht Bestandteil der Richtlinienbedingung ist. Aber dieser Teil der Richtlinie verweigert nur jenen Benutzern den Zugriff, die nicht aufgelistet sind. Sie müssen Berechtigungen einschließen, damit alle Gruppenmitglieder Gruppenverwaltungsaktionen durchführen können. Anschließend weisen Sie diese Richtlinie der Gruppe zu, sodass sie für alle Benutzer gilt. Wenn dann ein Benutzer, der nicht in der Richtlinie angegeben ist, versucht, die Gruppe zu ändern, wird die Anfrage abgelehnt.
**So erstellen Sie diese Richtlinie mit dem visuellen Editor**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Wählen Sie im Navigationsbereich auf der linken Seite **Policies (Richtlinien)**.
Wenn Sie zum ersten Mal **Policies (Richtlinien)** auswählen, erscheint die Seite **Welcome to Managed Policies (Willkommen bei verwalteten Richtlinien)**. Wählen Sie **Get Started**.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Wählen Sie im Bereich **Policy editor** (Richtlinien-Editor) die Option **Visual** aus.
1. Wählen Sie unter **Select a service** (Einen Service auswählen) die Option **IAM** aus.
1. Geben Sie im Feld **Actions allowed** (Zulässige Aktionen) **group** in das Suchfeld ein. Der visuelle Editor zeigt alle IAM-Aktionen, die das Wort `group` enthalten. Aktivieren Sie alle Kontrollkästchen..
1. Wählen Sie **Resources (Ressourcen)** aus, um die Ressourcen für Ihre Richtlinie festzulegen. Basierend auf den ausgewählten Aktionen sollten Sie die Ressourcentypen **group** (Gruppe) und **user** (Benutzer) sehen.
+ **Gruppe** — Wählen Sie **Hinzufügen ARNs**. Wählen Sie für **Resource in** (Ressource in) die Option **Any account** (Beliebiges Konto) aus. Aktivieren Sie das Kontrollkästchen **Beliebiger Gruppenname mit Pfad** und geben Sie dann den Namen der Benutzergruppe **AllUsers** ein. Wählen Sie dann **Add (Hinzufügen) ARNs**.
+ **Benutzer** – Aktivieren Sie das Kontrollkästchen neben **Alle in diesem Konto**.
Eine der Aktionen, die Sie ausgewählt haben, `ListGroups`, unterstützt die Verwendung spezifischer Ressourcen nicht. Sie müssen für diese Aktion nicht **All resources (Alle Ressourcen)** auswählen. Beim Speichern oder Anzeigen der Richtlinie im **JSON**-Editor sehen Sie, dass IAM automatisch einen neuen Berechtigungsblock erstellt, durch den diese Aktion für alle Ressourcen zugelassen wird.
1. Zum Hinzufügen eines weiteren Berechtigungsblocks wählen Sie **Add more permissions** (Weitere Berechtigungen hinzufügen) aus.
1. Wählen Sie **Select a service** (Einen Service auswählen) und dann **IAM** aus.
1. Wählen Sie **Actions allowed** (Zulässige Aktionen) und dann **Switch to deny permissions** (Zu verweigerten Berechtigungen wechseln) aus. Wenn Sie dies durchführen, wird der gesamte Block verwendet, um Berechtigungen zu verweigern.
1. Geben Sie in das Suchfeld **group** ein. Die visuelle Editor zeigt alle IAM-Aktionen an, die das Wort `group` enthalten. Aktivieren Sie die Kontrollkästchen neben den folgenden Aktionen:
+ **CreateGroup**
+ **DeleteGroup**
+ **RemoveUserFromGroup**
+ **AttachGroupPolicy**
+ **DeleteGroupPolicy**
+ **DetachGroupPolicy**
+ **PutGroupPolicy**
+ **UpdateGroup**
1. Wählen Sie **Resources (Ressourcen)** aus, um die Ressourcen für Ihre Richtlinie festzulegen. Basierend auf den Aktionen, die Sie ausgewählt haben, sollten Sie den Ressourcentyp **group (Gruppe)** sehen. Wählen Sie **Hinzufügen ARNs** aus. Wählen Sie für **Resource in** (Ressource in) die Option **Any account** (Beliebiges Konto) aus. Geben Sie für **any group Name With Path** (Jeder Gruppenname mit Pfad) den Gruppennamen **AllUsers** ein. Wählen Sie dann **Add (Hinzufügen) ARNs**.
1. Wählen Sie **Request conditions - *optional*** (Anforderungsbedingungen - optional) und anschließend **Add another condition** (Weitere Bedingung hinzufügen). Füllen Sie das Formular mit den folgenden Werten aus:
+ **Condition key** (Bedingungsschlüssel) – Wählen Sie **aws:username** aus.
+ **Qualifier (Qualifizierer)** – Wählen Sie **Default (Standard)**
+ **Betreiber** — Wählen **StringNotEquals**
+ **Value** (Wert) – Geben Sie **srodriguez** ein und wählen Sie dann **Add** (Hinzufügen) aus, um einen weiteren Wert hinzuzufügen. Geben Sie **mjackson** ein und wählen Sie dann **Add** (Hinzufügen) aus, um einen weiteren Wert hinzuzufügen. Geben Sie **adesai** ein und wählen Sie **Add condition** (Bedingung hinzufügen).
Diese Bedingung stellt sicher, dass der Zugriff auf die angegebenen Gruppenverwaltungsaktionen verweigert wird, wenn der Benutzer, der den Aufruf durchführt, nicht in der Liste enthalten ist. Da dadurch die Berechtigung explizit verweigert wird, wird der vorherige Block überschrieben, der den Benutzern das Aufrufen der Aktionen gestattete. Benutzern auf der Liste wird der Zugriff nicht verweigert. Sie erhalten eine Berechtigung im ersten Block, sodass sie die Gruppe vollständig verwalten können.
1. Wählen Sie danach **Next** aus.
**Anmerkung**
Sie können jederzeit zwischen den Editoroptionen **Visual** und **JSON** wechseln. Wenn Sie jedoch Änderungen vornehmen oder in der Editoroption **Visual** **Next** (Weiter) wählen, strukturiert IAM Ihre Richtlinie möglicherweise um, um sie für den visuellen Editor zu optimieren. Weitere Informationen finden Sie unter [Umstrukturierung einer Richtlinie](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Geben Sie auf der Seite **Review and create** (Überprüfen und erstellen) für **Policy Name** (Richtlinienname) **LimitAllUserGroupManagement** ein. Geben Sie für **Description (Beschreibung)** Folgendes ein: **Allows all users read-only access to a specific user group, and allows only specific users access to make changes to the user group**. Überprüfen Sie **Permissions defined in this policy** (In dieser Richtlinie definierte Berechtigungen), um sicherzustellen, dass Sie die beabsichtigten Berechtigungen erteilt haben. Wählen Sie dann **Create policy (Richtlinie erstellen)** aus, um Ihre neue Richtlinie zu speichern.
1. Fügen Sie die Richtlinie zu Ihrer Gruppe hinzu. Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](access_policies_manage-attach-detach.md).
Alternativ können Sie dieselbe Richtlinie mit diesem Beispieldokument einer JSON-Richtlinie erstellen. So zeigen Sie diese JSON-Richtlinie finden Sie unter [: Ermöglicht spezifischen IAM-Benutzern das Verwalten einer Gruppe programmgesteuert und in der Konsole](reference_policies_examples_iam_users-manage-group.md). Detaillierte Anweisungen zum Erstellen einer Richtlinie mithilfe eines JSON-Dokuments finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
## Steuern des Zugriffs auf Richtlinien
Sie können steuern, wie Ihre Benutzer AWS verwaltete Richtlinien anwenden können. Zu diesem Zweck weisen Sie diese Richtlinie all Ihren Benutzern zu. Idealerweise können Sie dies durch die Verwendung einer Gruppe durchführen.
Sie können beispielsweise eine Richtlinie erstellen, die es Benutzern ermöglicht, einem neuen IAM-Benutzer, einer neuen Benutzergruppe oder Rolle nur die [PowerUserAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/PowerUserAccess) AWS verwalteten Richtlinien zuzuweisen. [IAMUserChangePassword](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/IAMUserChangePassword)
Für vom Kunden verwaltete Richtlinien können Sie steuern, wer diese Richtlinien erstellen, aktualisieren und löschen darf. Sie können steuern, wer Richtlinien an Prinzipal-Entitäten (IAM-Gruppen, Benutzer und Rollen) anfügen und von diesen trennen kann. Sie können auch steuern, welche Richtlinien ein Benutzer welchen Entitäten hinzufügen oder von diesen trennen kann.
So können Sie beispielsweise einem Kontoadministrator Berechtigungen zum Erstellen, Aktualisieren und Löschen von Richtlinien erteilen. Anschließend erteilen Sie einem Teamleiter oder einem anderen Administrator mit eingeschränkten Befugnissen die Berechtigungen, um diese Richtlinien den vom Administrator mit eingeschränkten Befugnissen verwalteten Prinzipal-Entitäten anzufügen und von diesen zu trennen.
Weitere Informationen finden in folgenden Ressourcen:
+ Weitere Informationen zum Erstellen einer IAM-Richtlinie, die Sie zu einem Prinzipal zuordnen können, finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
+ Weitere Informationen zum Hinzufügen einer IAM-Richtlinie zu einem Prinzipal finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](access_policies_manage-attach-detach.md).
+ Ein Beispiel für eine Richtlinie, die die Verwendung verwalteter Richtlinien einschränkt, finden Sie unter [IAM: Beschränkt die verwalteten Richtlinien, die -Benutzern, -Gruppen oder -Rollen zugeordnet werden können](reference_policies_examples_iam_limit-managed.md).
### Kontrollieren der Berechtigungen zum Erstellen, Aktualisieren und Löschen von Berechtigungen für vom Kunden verwaltete Berechtigungen
Sie können mit [IAM-Richtlinien](access_policies.md) steuern, wer vom Kunden verwaltete Richtlinien in Ihrem AWS-Konto erstellen, aktualisieren und löschen darf. Die folgende Liste enthält API-Operationen, die speziell für das Erstellen, Aktualisieren und Löschen von Richtlinien oder Richtlinienversionen vorgesehen sind:
+ [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html)
+ [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html)
+ [DeletePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeletePolicy.html)
+ [DeletePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeletePolicyVersion.html)
+ [SetDefaultPolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetDefaultPolicyVersion.html)
Die API-Operationen in der vorherigen Liste entsprechen Aktionen, die Sie zulassen oder verweigern können, das heißt, Berechtigungen, die Sie mit mithilfe einer IAM-Richtlinie erteilen können.
Betrachten Sie die folgende Beispielrichtlinie. Sie erteilt einem Benutzer die Berechtigung zum Erstellen, Aktualisieren (d. h. zum Erstellen einer neuen Richtlinienversion), Löschen und Festlegen einer Standardversion für alle vom Kunden verwalteten Richtlinien im AWS-Konto. Die Beispielrichtlinie gestattet dem Benutzer auch das Auflisten und Abrufen von Richtlinien. Informationen zum Erstellen einer Richtlinie mit diesem Beispiel-JSON-Richtliniendokument finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
**Example Beispielrichtlinie, die das Erstellen, Aktualisieren, Löschen, Auflisten, Abrufen und Einstellen der Standardversion für alle Richtlinien ermöglicht**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:SetDefaultPolicyVersion"
],
"Resource": "*"
}
}
```
Sie können Richtlinien erstellen, die die Verwendung dieser API-Operationen auf die von Ihnen angegebenen, verwalteten Richtlinien beschränken. Sie möchten beispielsweise einem Benutzer die Berechtigung zum Festlegen der Standardversion und Löschen von Richtlinienversionen ausschließlich für bestimmte, vom Kunden verwaltete Richtlinien erteilen. Geben Sie hierzu den ARN der Richtlinie im Element `Resource` der Richtlinie an, die diese Berechtigungen erteilt
Das folgende Beispiel zeigt eine Richtlinie, mit der ein Benutzer Richtlinienversionen löschen und die Standardversion festlegen kann. Diese Aktionen sind jedoch nur für die vom Kunden verwalteten Richtlinien erlaubt, die den Pfad /TEAM-A/ enthalten. Der ARN der kundenverwalteten Richtlinie ist im Element `Resource` der Richtlinie angegeben. (In diesem Beispiel enthält der ARN einen Pfad und ein Platzhalterzeichen und stimmt so mit allen kundenverwalteten Richtlinien überein, die den Pfad /TEAM-A/ enthalten). Informationen zum Erstellen einer Richtlinie mit diesem Beispiel-JSON-Richtliniendokument finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
Weitere Informationen zur Verwendung von Pfaden in den Namen der von Kunden verwalteten Richtlinien finden Sie unter [Anzeigenamen und -pfade](reference_identifiers.md#identifiers-friendly-names).
**Example Beispielrichtlinie, die das Löschen von Richtlinienversionen und das Einstellen der Standardversion nur für bestimmte Richtlinien erlaubt**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": "arn:aws:iam::111122223333:policy/TEAM-A/*"
}
}
```
### Steuern der Berechtigungen für das Anfügen und Trennen von verwalteten Richtlinien
Sie können auch IAM-Richtlinien verwenden, damit Benutzer nur mit bestimmten verwalteten Richtlinien arbeiten können. Sie können sogar steuern, welche Berechtigungen ein Benutzer anderen Prinzipal-Entitäten erteilen kann.
In der folgenden Liste werden API-Operationen aufgeführt, die sich speziell auf das Anfügen und Trennen von verwalteten Richtlinien an und von Prinzipal-Entitäten beziehen:
+ [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)
+ [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
+ [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html)
+ [DetachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachGroupPolicy.html)
+ [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html)
+ [DetachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachUserPolicy.html)
Sie können Richtlinien erstellen, die die Verwendung dieser API-Operationen so einschränken, dass sie sich nur auf die von Ihnen angegebenen and/or Prinzipalentitäten für bestimmte verwaltete Richtlinien auswirken. Sie möchten beispielsweise einem Benutzer die Berechtigung erteilen, ausschließlich die von Ihnen angegebenen, verwalteten Richtlinien anzufügen. Oder Sie möchten einem Benutzer die Berechtigung erteilen, die verwalteten Richtlinien ausschließlich den von Ihnen angegebenen Prinzipal-Entitäten anzufügen.
Mit der folgenden Beispielrichtlinie kann ein Benutzer verwaltete Richtlinien nur den IAM-Gruppen und -Rollen zuordnen, die den Pfad /TEAM-A/ enthalten. Die Benutzergruppe und ARNs die Rolle sind im `Resource` Element der Richtlinie angegeben. (In diesem Beispiel ARNs enthalten sie einen Pfad und ein Platzhalterzeichen und entsprechen somit allen IAM-Gruppen und -Rollen, die den Pfad /TEAM-A/ enthalten.) Informationen zum Erstellen einer Richtlinie mit diesem Beispiel-JSON-Richtliniendokument finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
**Example Beispielrichtlinie, die es ermöglicht, verwaltete Richtlinien nur bestimmten Benutzergruppen oder Rollen zuzuordnen**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::111122223333:group/TEAM-A/*",
"arn:aws:iam::111122223333:role/TEAM-A/*"
]
}
}
```
Sie können außerdem die Aktionen im vorherigen Beispiel auf bestimmte Richtlinien einschränken. Das heißt, Sie können steuern, welche Berechtigungen ein Benutzer anderen Prinzipal-Entitäten anfügen kann indem Sie eine Bedingung der Richtlinie hinzufügen.
Im folgenden Beispiel stellt die Bedingung sicher, dass die Berechtigungen `AttachGroupPolicy` und `AttachRolePolicy` nur dann zulässig sind, wenn die angefügte Richtlinie mit einer der angegebenen Richtlinien übereinstimmt. Die Bedingung verwendet den `iam:PolicyARN` [Bedingungsschlüssel](reference_policies_elements_condition.md), um festzulegen, welche Richtlinie oder Richtlinien angefügt werden dürfen. Die folgende Beispielrichtlinie erweitert das vorherige Beispiel. Dadurch kann ein Benutzer nur die verwalteten Richtlinien, die den Pfad /TEAM-A/ enthalten, nur den IAM-Gruppen und -Rollen zuordnen, die den Pfad /TEAM-A/ enthalten. Informationen zum Erstellen einer Richtlinie mit diesem Beispiel-JSON-Richtliniendokument finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::111122223333:group/TEAM-A/*",
"arn:aws:iam::111122223333:role/TEAM-A/*"
],
"Condition": {
"ArnLike": {
"iam:PolicyARN": "arn:aws:iam::111122223333:policy/TEAM-A/*"
}
}
}
}
```
------
Diese Richtlinie verwendet den `ArnLike`-Bedingungsoperator, aber Sie können auch den `ArnEquals`-Bedingungsoperator verwenden, weil sich diese beiden Bedingungsoperatoren identisch verhalten. Weitere Informationen zu `ArnLike` und `ArnEquals` finden Sie unter [Bedingungsoperatoren für Amazon-Ressourcennamen (ARN)](reference_policies_elements_condition_operators.md#Conditions_ARN) im Abschnitt *Bedingungstypen* in der *Richtinienelementreferenz*.
Sie können beispielsweise die Verwendung dieser Aktionen einschränken, sodass nur die von Ihnen angegebenen, verwalteten Richtlinien einbezogen werden. Geben Sie hierzu den ARN der Richtlinie im Element `Condition` der Richtlinie an, die diese Berechtigungen erteilt Wenn Sie beispielsweise den ARN einer vom Kunden verwalteten Richtlinie angeben möchten:
```
"Condition": {"ArnEquals":
{"iam:PolicyARN": "arn:aws:iam::123456789012:policy/POLICY-NAME"}
}
```
Sie können auch den ARN einer AWS verwalteten Richtlinie im `Condition` Element einer Richtlinie angeben. Der ARN einer AWS verwalteten Richtlinie verwendet den speziellen Alias `aws` im Richtlinien-ARN anstelle einer Konto-ID, wie in diesem Beispiel:
```
"Condition": {"ArnEquals":
{"iam:PolicyARN": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"}
}
```
## Steuern des Zugriffs auf Ressourcen
Sie können den Zugriff auf Ressourcen mit einer identitätsbasierten oder ressourcenbasierten Richtlinie steuern. Bei einer identitätsbasierten Richtlinie fügen Sie die Richtlinie einer Identität hinzu und geben an, auf welche Ressourcen die Identität zugreifen darf. Bei einer ressourcenbasierten Richtlinie ordnen Sie eine Richtlinie der Ressource zu, die Sie steuern möchten. Sie geben in der Richtlinie an, welche Prinzipale auf die Ressource zugreifen dürfen. Weitere Informationen zu diesen beiden Arten von Richtlinien finden Sie unter [Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien](access_policies_identity-vs-resource.md).
Weitere Informationen finden in folgenden Ressourcen:
+ Weitere Informationen zum Erstellen einer IAM-Richtlinie, die Sie zu einem Prinzipal zuordnen können, finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
+ Weitere Informationen zum Hinzufügen einer IAM-Richtlinie zu einem Prinzipal finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](access_policies_manage-attach-detach.md).
+ Amazon S3 unterstützt die Verwendung von ressourcenbasierten Richtlinien für die Buckets. Weitere Informationen finden Sie unter [Bucket Policy Examples](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html).
**Ersteller von Ressourcen haben nicht automatisch Berechtigungen**
Wenn Sie sich mit den Root-Benutzer des AWS-Kontos Anmeldeinformationen anmelden, sind Sie berechtigt, alle Aktionen mit Ressourcen durchzuführen, die zu dem Konto gehören. Dies gilt jedoch nicht für IAM-Benutzer. Einem IAM-Benutzer kann der Zugriff zum Erstellen einer Ressource gewährt werden, aber die Berechtigungen des Benutzers, selbst für diese Ressource, sind darauf beschränkt, was explizit erteilt wurde. Das bedeutet: Nur weil Sie eine Ressource, beispielsweise eine IAM-Rolle, erstellen, sind Sie nicht automatisch berechtigt, diese Rolle zu bearbeiten oder zu löschen. Darüber hinaus kann Ihre Berechtigung jederzeit vom Kontoinhaber oder einem anderen Benutzer widerrufen werden, dem der Zugriff auf die Verwaltung Ihrer Berechtigungen gewährt wurde.
## Steuern des Zugriffs auf Prinzipale in einem bestimmten Konto
Sie können direkt in Ihrem eigenen Konto IAM-Benutzern Zugriff auf Ihre Ressourcen gewähren. Wenn Benutzer eines anderen Kontos Zugriff auf Ihre Ressourcen benötigen, können Sie eine IAM-Rolle erstellen. Eine Rolle ist eine Entität, die Berechtigungen enthält, aber nicht mit einem bestimmten Benutzer verknüpft ist. Benutzer von anderen Konten können dann die Rolle annehmen und entsprechend den Berechtigungen, die Sie der Rolle zugeordnet haben, auf Ressourcen zugreifen. Weitere Informationen finden Sie unter [Zugriff für einen IAM-Benutzer in einem anderen AWS-Konto , den Sie besitzen](id_roles_common-scenarios_aws-accounts.md).
**Anmerkung**
Einige Services unterstützen ressourcenbasierte Richtlinien wie in [Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien](access_policies_identity-vs-resource.md) beschrieben (wie Amazon S3, Amazon SNS und Amazon SQS). Für diese Services besteht eine Alternative zur Verwendung von Rollen darin, eine Richtlinie an die Ressource (Bucket, Thema oder Warteschlange) anzuhängen, die Sie freigeben möchten. Die ressourcenbasierte Richtlinie kann das AWS Konto angeben, das über Berechtigungen für den Zugriff auf die Ressource verfügt.
# Steuerung des Zugriffs auf und für IAM-Benutzer und IAM-Rollen mithilfe von Tags
Verwenden Sie die Informationen im folgenden Abschnitt, um zu steuern, wer auf Ihre IAM-Benutzer und IAM-Rollen zugreifen kann und auf welche Ressourcen Ihre Benutzer und Rollen zugreifen können. Allgemeinere Informationen und Beispiele für die Steuerung des Zugriffs auf andere AWS Ressourcen, einschließlich anderer IAM-Ressourcen, finden Sie unter[Tags für AWS Identity and Access Management Ressourcen](id_tags.md).
**Anmerkung**
Einzelheiten zur Berücksichtigung der Groß- und Kleinschreibung bei Tag-Schlüsseln und Tag-Schlüsselwerten finden Sie unter [Case sensitivity](id_tags.md#case-sensitivity).
Tags können an die IAM-*Ressourc*e angehängt, in der *Anforderung* übergeben oder an den *Auftraggeber*, der die Anforderung stellt, angehängt werden. Ein Benutzer oder eine Rolle in IAM kann sowohl eine Ressource als auch ein Auftraggeber sein. Sie können beispielsweise eine Richtlinie schreiben, mit der ein Benutzer die Gruppen für einen Benutzer auflisten kann. Diese Operation ist nur zulässig, wenn der Benutzer, der die Anforderung stellt (der Auftraggeber), über das gleiche `project=blue`-Tag verfügt wie der Benutzer, den er anzeigen möchte. In diesem Beispiel kann der Benutzer die Gruppenmitgliedschaft für jeden Benutzer anzeigen, einschließlich sich selbst, solange sie an demselben Projekt arbeiten.
Um den Zugriff auf Grundlage von Tags zu steuern, geben Sie im [Bedingungselement](reference_policies_elements_condition.md) einer Richtlinie Tag-Informationen an. Wenn Sie eine IAM-Richtlinie erstellen, können Sie IAM-Tags und den zugehörigen Tag-Bedingungsschlüssel verwenden, um den Zugriff auf Folgendes zu steuern:
+ **[Ressource](access_tags.md#access_tags_control-resources)** – Steuern Sie den Zugriff auf Benutzer- oder Rollenressourcen basierend auf ihren Tags. Verwenden Sie dazu den *key-name* Bedingungsschlüssel **aws:ResourceTag/**, um anzugeben, welches Tag-Schlüssel-Wert-Paar an die Ressource angehängt werden muss. Weitere Informationen finden Sie unter [Kontrolle des Zugriffs auf AWS Ressourcen](access_tags.md#access_tags_control-resources).
+ **[Anforderung](access_tags.md#access_tags_control-requests)** – Bestimmen, welche Tags in einer IAM-Anforderung weitergeleitet werden können. Verwenden Sie dazu den *key-name* Bedingungsschlüssel **aws:RequestTag/**, um anzugeben, welche Tags einem IAM-Benutzer oder einer IAM-Rolle hinzugefügt, geändert oder daraus entfernt werden können. Dieser Schlüssel wird auf die gleiche Weise für IAM-Ressourcen und andere AWS Ressourcen verwendet. Weitere Informationen finden Sie unter [Steuern des Zugriffs bei Anfragen AWS](access_tags.md#access_tags_control-requests).
+ **[Auftraggeber](#access_iam-tags_control-principals)** – Steuern Sie, welche Aktionen die Person, von der die Anforderung stammt (der Auftraggeber), durchführen darf, auf Grundlage der Tags, die dem IAM-Benutzer oder der Rolle der Person angefügt sind. Verwenden Sie dazu den *key-name* Bedingungsschlüssel **aws:PrincipalTag/**, um anzugeben, welche Tags an den IAM-Benutzer oder die IAM-Rolle angehängt werden müssen, bevor die Anfrage zugelassen wird.
+ **[Beliebiger Teil des Autorisierungsprozesses](#access_iam-tags_control-tag-keys)** — Verwenden Sie den TagKeys Bedingungsschlüssel **aws:**, um zu steuern, ob bestimmte Tag-Schlüssel in einer Anfrage oder von einem Principal verwendet werden können. In diesem Fall spielt der Schlüsselwert keine Rolle. Dieser Schlüssel verhält sich bei IAM und anderen AWS Diensten ähnlich. Wenn Sie jedoch einen Benutzer in IAM markieren, steuert dies auch, ob der Auftraggeber die Anforderung an einen beliebigen Service stellen kann. Weitere Informationen finden Sie unter [Zugriffssteuerung auf der Grundlage von Tag-Schlüsseln](access_tags.md#access_tags_control-tag-keys).
Sie können eine IAM-Richtlinie mit dem visuellen Editor, JSON oder durch Importieren einer vorhandenen verwalteten Richtlinie erstellen. Details hierzu finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
**Anmerkung**
Sie können [Sitzungs-Tags](id_session-tags.md) auch übergeben, wenn Sie eine IAM-Rolle übernehmen oder einen Benutzer in einen Verbund aufnehmen. Diese sind nur für die Dauer der Sitzung gültig.
## Zugriffssteuerung für IAM-Auftraggeber
Sie können steuern, was der Auftraggeber tun darf, basierend auf den Tags, die der Identität dieser Person zugeordnet sind.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es jedem Benutzer in diesem Konto erlaubt, die Gruppenmitgliedschaft für jeden Benutzer, einschließlich sich selbst, anzuzeigen, solange sie am selben Projekt arbeiten. Diese Operation ist nur zulässig, wenn das Ressourcen-Tag des Benutzers und das Tag des Auftraggebers denselben Wert für den Tag-Schlüssel besitzen. `project`. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:ListGroupsForUser",
"Resource": "arn:aws:iam::111222333444:user/*",
"Condition": {
"StringEquals": {"aws:ResourceTag/project": "${aws:PrincipalTag/project}"}
}
}]
}
```
------
## Zugriffssteuerung auf der Grundlage von Tag-Schlüsseln
Sie können Tags in Ihren IAM-Richtlinien verwenden, um zu steuern, ob bestimmte Tag-Schlüssel in einer Anfrage oder von einem Prinzipal verwendet werden können.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es erlaubt, nur das Tag mit dem Schlüssel `temporary` von Benutzern zu entfernen. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:UntagUser",
"Resource": "*",
"Condition": {"ForAllValues:StringEquals": {"aws:TagKeys": ["temporary"]}}
}]
}
```
------
# Steuern des Zugriffs auf AWS Ressourcen mithilfe von Tags
Sie können Tags verwenden, um den Zugriff auf Ihre AWS Ressourcen zu steuern, die Tagging unterstützen, einschließlich IAM-Ressourcen. Sie können IAM-Benutzer und IAM-Rollen markieren, um zu steuern, worauf sie zugreifen können. Weitere Informationen zum Markieren von IAM-Benutzern und IAM-Rollen finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](id_tags.md). Darüber hinaus können Sie den Zugriff auf die folgenden IAM-Ressourcen steuern: von Kunden verwaltete Richtlinien, IAM-Identitätsanbieter, Instance-Profile, Serverzertifikate und virtuelle MFA-Geräte. Ein Tutorial zum Erstellen und Testen einer Richtlinie, die IAM-Rollen mit Auftraggeber-Tags den Zugriff auf Ressourcen mit übereinstimmenden Tags erlaubt, finden Sie unter [IAM-Tutorial: Berechtigungen für den Zugriff auf AWS Ressourcen auf der Grundlage von Tags definieren](tutorial_attribute-based-access-control.md). Verwenden Sie die Informationen im folgenden Abschnitt, um den Zugriff auf andere AWS Ressourcen, einschließlich IAM-Ressourcen, zu steuern, ohne IAM-Benutzer oder -Rollen zu taggen.
Bevor Sie Tags verwenden, um den Zugriff auf Ihre AWS Ressourcen zu steuern, müssen Sie wissen, wie AWS der Zugriff gewährt wird. AWS besteht aus Sammlungen von *Ressourcen*. Eine Amazon EC2-Instance ist eine Ressource. Ein Amazon S3-Bucket ist eine Ressource. Sie können die AWS API, die oder die verwenden AWS CLI, AWS-Managementkonsole um einen Vorgang auszuführen, z. B. das Erstellen eines Buckets in Amazon S3. Wenn Sie dies tun, senden Sie eine *Anforderung* für diese Operation. Ihre Anforderung gibt eine Aktion, eine Ressource, eine *Auftraggeber-Entität* (Gruppe oder Rolle) und ein *Auftraggeberkonto* an und enthält alle erforderlichen Anforderungsinformationen. Diese Informationen stellen den *Kontext* bereit.
AWS überprüft dann, ob Sie (die Haupteinheit) authentifiziert (angemeldet) und autorisiert (berechtigt) sind, die angegebene Aktion auf der angegebenen Ressource auszuführen. AWS Überprüft bei der Autorisierung alle Richtlinien, die für den Kontext Ihrer Anfrage gelten. Die meisten Richtlinien werden AWS als [JSON-Dokumente](access_policies.md#access_policies-json) gespeichert und spezifizieren die Berechtigungen für Hauptentitäten. Weitere Informationen zu diesen Richtlinienarten und ihrer Verwendung finden Sie unter [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md).
AWS autorisiert die Anfrage nur, wenn jeder Teil Ihrer Anfrage gemäß den Richtlinien zulässig ist. Informationen zum Anzeigen eines Diagramms und weitere Informationen über die IAM-Infrastruktur finden Sie unter [Funktionsweise von IAM](intro-structure.md). Weitere Informationen darüber, wie IAM bestimmt, ob eine Anfoderung zulässig ist, finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
Tags sind eine weitere Überlegung in diesem Prozess, da Markierungen an die *Ressource* angefügt werden können oder in der *Anfrage* an Services weitergegeben werden können, die das Markieren unterstützen. Um den Zugriff auf Grundlage von Tags zu steuern, geben Sie im [Bedingungselement](reference_policies_elements_condition.md) einer Richtlinie Tag-Informationen an. Informationen darüber, ob ein AWS Service die Zugriffskontrolle mithilfe von Tags unterstützt, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) und suchen Sie nach den Diensten, für die in der **ABAC-Spalte** **Ja** angegeben ist. Wählen Sie den Namen des Service, um die Dokumentation zur Autorisierung und Zugriffssteuerung für diesen Service anzuzeigen.
Sie können dann eine IAM-Richtlinie erstellen, die den Zugriff auf eine Ressource basierend auf dem Tag dieser Ressource erlaubt oder verweigert. In dieser Richtlinie können Sie Tag-Bedingungsschlüssel verwenden, um den Zugriff auf eine der folgenden Optionen zu steuern:
+ **[Ressource](#access_tags_control-resources)** — Steuern Sie den Zugriff auf AWS Serviceressourcen anhand der Tags auf diesen Ressourcen. Verwenden Sie dazu den *key-name* Bedingungsschlüssel **aws:ResourceTag/**, um anhand der Tags, die der Ressource zugeordnet sind, zu bestimmen, ob der Zugriff auf die Ressource erlaubt werden soll.
+ **[Anforderung](#access_tags_control-requests)** – Steuern, welche Tags an eine Anforderung weitergeleitet werden können. Verwenden Sie dazu den *key-name* Bedingungsschlüssel **aws:RequestTag/**, um anzugeben, welche Tag-Schlüssel-Wert-Paare in einer Anfrage zur Kennzeichnung einer Ressource übergeben werden können. AWS
+ **[Beliebiger Teil des Autorisierungsprozesses](#access_tags_control-tag-keys)** — Verwenden Sie den TagKeys Bedingungsschlüssel **aws:**, um zu kontrollieren, ob bestimmte Tag-Schlüssel in einer Anfrage enthalten sein können.
Sie können eine IAM-Richtlinie visuell mithilfe von JSON oder durch Importieren einer vorhandenen verwalteten Richtlinie erstellen. Details hierzu finden Sie unter [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](access_policies_create.md).
**Anmerkung**
Bei einigen Diensten können Benutzer beim Erstellen der Ressource Tags angeben, wenn sie über die Berechtigung zum Verwenden der Aktion verfügen, mit der die Ressource erstellt wird.
## Kontrolle des Zugriffs auf AWS Ressourcen
Sie können Bedingungen in Ihren IAM-Richtlinien verwenden, um den Zugriff auf AWS Ressourcen auf der Grundlage der Tags dieser Ressource zu steuern. Sie können dies mithilfe des globalen `aws:ResourceTag/tag-key`-Bedingungsschlüssels oder eines servicespezifischen Schlüssels erreichen. Einige Services unterstützen nur die servicespezifische Version dieses Schlüssels und nicht die globale Version.
**Warnung**
Versuchen Sie nicht zu kontrollieren, wer eine Rolle weitergeben kann, indem Sie die Rolle taggen und dann den `ResourceTag`-Bedingungsschlüssel in einer Richtlinie mit der `iam:PassRole`-Aktion verwenden. Dieser Ansatz führt nicht zu zuverlässigen Ergebnissen. Weitere Informationen zu den erforderlichen Berechtigungen, die für das Übergeben einer Rolle an einen Service erforderlich sind, finden Sie unter [Erteilen Sie einem Benutzer die Erlaubnis, eine Rolle an einen AWS Dienst zu übergeben](id_roles_use_passrole.md).
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Starten oder Stoppen von Amazon-EC2-Instances erlaubt. Diese Operationen sind nur zulässig, wenn das Instance-Tag `Owner` den Wert des Benutzernamens dieses Benutzers aufweist. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
}
```
------
Sie können diese Richtlinie den IAM-Benutzern in Ihrem Konto anfügen. Wenn ein Benutzer namens `richard` versucht, eine Amazon EC2-Instance zu starten, muss die Instance mit dem Tag `Owner=richard` oder `owner=richard` versehen sein. Andernfalls wird ihm der Zugriff verweigert. Der Tag-Schlüssel `Owner` stimmt mit `Owner` und `owner` überein, da bei Bedingungsschlüsselnamen nicht zwischen Groß- und Kleinschreibung unterschieden wird. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Condition](reference_policies_elements_condition.md).
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die das Löschen von Benutzern mit dem `team`-Prinzipal-Tag erlaubt. Die Richtlinie gewährt die Erlaubnis, Warteschlangen von Amazon Simple Queue Service zu löschen, jedoch nur, wenn der Warteschlangenname mit dem Teamnamen beginnt, gefolgt von `-queue`. Beispielsweise `qa-queue`, wenn `qa` der Teamname für das `team`-Prinzipal-Tag ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AllQueueActions",
"Effect": "Allow",
"Action": "sqs:DeleteQueue",
"Resource": "arn:aws:sqs:us-east-2:111122223333:${aws:PrincipalTag/team}-queue"
}
}
```
------
## Steuern des Zugriffs bei Anfragen AWS
Sie können Bedingungen in Ihren IAM-Richtlinien verwenden, um zu steuern, welche Tag-Schlüssel-Wert-Paare in einer Anfrage übergeben werden können, die Tags auf eine Ressource anwendet. AWS
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es erlaubt, mithilfe der Amazon-EC2-Aktion `CreateTags` Tags an eine Instance anzuhängen. Sie können Tags nur anfügen, wenn das Tag den `environment`-Schlüssel und die `preprod`- oder `production`-Werte enthält. Wenn Sie möchten, können Sie den `ForAllValues`-Modifikator mit dem `aws:TagKeys`-Bedingungsschlüssel verwenden, um anzugeben, dass nur der `environment`-Schlüssel in der Anforderung zulässig ist. So wird verhindert, dass Benutzer andere Schlüssel einbeziehen und etwa versehentlich `Environment` anstelle von `environment` verwenden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": [
"preprod",
"production"
]
},
"ForAllValues:StringEquals": {"aws:TagKeys": "environment"}
}
}
}
```
------
## Zugriffssteuerung auf der Grundlage von Tag-Schlüsseln
Sie können in Ihren IAM-Richtlinien eine Bedingung verwenden, um zu steuern, ob bestimmte Tag-Schlüssel in einer Anfrage verwendet werden können.
[Wir empfehlen, dass Sie bei der Verwendung von Richtlinien zur Zugriffskontrolle mithilfe von Tags den `aws:TagKeys` Bedingungsschlüssel verwenden.](reference_policies_condition-keys.md#condition-keys-tagkeys) AWS Dienste, die Tags unterstützen, ermöglichen es Ihnen möglicherweise, mehrere Tag-Schlüsselnamen zu erstellen, die sich nur durch Groß- und Kleinschreibung unterscheiden, z. B. das Taggen einer Amazon EC2 EC2-Instance mit `stack=production` und. `Stack=test` Bei den Schlüsselnamen in den Richtlinienbedingungen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Dies bedeutet Folgendes: Wenn Sie `"aws:ResourceTag/TagKey1": "Value1"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Ressourcen-Tag-Schlüssel mit dem Namen `TagKey1` oder `tagkey1` überein, aber nicht mit beiden. Um doppelte Tags mit Schlüsseln zu verhindern, die sich nur in der Groß-/Kleinschreibung unterscheiden, verwenden Sie die `aws:TagKeys`-Bedingung zum Definieren von Tag-Schlüsseln, die Ihre Benutzer anwenden können,, oder verwenden Sie Tag-Richtlinien, die mit AWS Organizations verfügbar sind. Weitere Informationen finden Sie unter [Tag-Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) im *AWS Organizations -Benutzerhandbuch*.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Erstellen und Markieren eines Secrets Manager Geheimnisses erlaubt, jedoch nur mit den Tag-Schlüsseln `environment` oder `cost-center`. Die `Null`-Bedingung stellt sicher, dass die Bedingung zu `false` ausgewertet wird, wenn in der Anfrage keine Tags vorhanden sind.
```
{
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret",
"secretsmanager:TagResource"
],
"Resource": "*",
"Condition": {
"Null": {
"aws:TagKeys": "false"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
}
}
}
```
# Kontoübergreifender Zugriff auf Ressourcen in IAM
Für einige AWS Dienste können Sie mithilfe von IAM kontoübergreifenden Zugriff auf Ihre Ressourcen gewähren. Dazu können Sie eine Ressourcenrichtlinie direkt an die Ressource anfügen, die Sie freigeben möchten, oder eine Rolle als Proxy verwenden.
Um die Ressource direkt freizugeben, muss die Ressource, die Sie freigeben möchten, [ressourcenbasierte Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-resource-based-policies) unterstützen. Im Gegensatz zu einer identitätsbasierten Richtlinie für eine Rolle legt eine ressourcenbasierte Richtlinie fest, wer (welcher Prinzipal) auf diese Ressource zugreifen kann.
Verwenden Sie eine Rolle als Proxy, wenn Sie auf Ressourcen in einem anderen Konto zugreifen möchten, die keine ressourcenbasierten Richtlinien unterstützen.
Einzelheiten zu den Unterschieden zwischen diesen Richtlinientypen finden Sie unter [Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien](access_policies_identity-vs-resource.md).
**Anmerkung**
IAM-Rollen und ressourcenbasierte Richtlinien delegieren den Zugriff auf Konten nur innerhalb einer einzelnen Partition. Beispiel: Sie haben ein Konto in USA West (Nordkalifornien) in der Standardpartition `aws`. Sie haben auch ein Konto in China in der Partition `aws-cn`. Sie können in Ihrem Konto in China keine ressourcenbasierte Richtlinie verwenden, um Benutzern in Ihrem AWS Standardkonto Zugriff zu gewähren.
## Kontoübergreifender Zugriff mithilfe von Rollen
Nicht alle AWS Dienste unterstützen ressourcenbasierte Richtlinien. Für diese Services können Sie kontoübergreifende IAM-Rollen verwenden, um die Berechtigungsverwaltung zu zentralisieren, wenn Sie kontoübergreifenden Zugriff für mehrere Services bereitstellen. Eine kontoübergreifende IAM-Rolle ist eine IAM-Rolle, die eine [Vertrauensrichtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#term_trust-policy) beinhaltet, die es IAM-Prinzipalen in einem anderen Konto ermöglicht, diese Rolle zu übernehmen. AWS Einfach ausgedrückt können Sie in einem Konto eine Rolle erstellen, die bestimmte Berechtigungen an ein AWS anderes Konto delegiert. AWS
Informationen zum Zuweisen einer Richtlinie an eine IAM-Identität finden Sie unter [Verwalten von IAM-Richtlinien](access_policies_manage.md).
**Anmerkung**
Wenn ein Prinzipal zu einer Rolle wechselt, um vorübergehend die Berechtigungen der Rolle zu nutzen, gibt er seine ursprünglichen Berechtigungen auf und übernimmt die Berechtigungen, die der Rolle zugewiesen wurden, die er angenommen hat.
Schauen wir uns den gesamten Prozess an, der für die APN-Partnersoftware gilt, die auf ein Kundenkonto zugreifen muss.
1. Der Kunde erstellt in seinem eigenen Konto eine IAM-Rolle mit einer Richtlinie, die den Zugriff auf die Amazon-S3-Ressourcen ermöglicht, die der APN-Partner benötigt. In diesem Beispiel lautet der Rollenname `APNPartner`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name"
]
}
]
}
```
------
1. Anschließend gibt der Kunde an, dass die Rolle vom AWS Konto des Partners übernommen werden kann, indem er die AWS-Konto ID des APN-Partners in der [Vertrauensrichtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) für die `APNPartner` Rolle angibt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/APN-user-name"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Der Kunde gibt dem APN-Partner den Amazon-Ressourcennamen (ARN) der Rolle. Der ARN ist der vollqualifizierte Name der Rolle.
```
arn:aws:iam::Customer-Account-ID:role/APNPartner
```
**Anmerkung**
Wir empfehlen, in Situationen mit mehreren Mandanten eine externe ID zu verwenden. Details hierzu finden Sie unter [Zugriff auf AWS-Konten Eigentum Dritter](id_roles_common-scenarios_third-party.md).
1. Wenn die Software des APN-Partners auf das Konto des Kunden zugreifen muss, ruft die Software die [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API AWS -Security-Token-Service mit dem ARN der Rolle im Kundenkonto auf. STS gibt einen temporären AWS Berechtigungsnachweis zurück, der es der Software ermöglicht, ihre Arbeit zu erledigen.
Ein weiteres Beispiel für die Gewährung von kontoübergreifendem Zugriff mithilfe von Rollen finden Sie unter [Zugriff für einen IAM-Benutzer in einem anderen AWS-Konto , den Sie besitzen](id_roles_common-scenarios_aws-accounts.md). Sie können auch dem [IAM-Tutorial: Delegieren Sie den Zugriff über AWS Konten hinweg mithilfe von IAM-Rollen](tutorial_cross-account-with-roles.md) folgen.
## Kontoübergreifender Zugriff mit ressourcenbasierten Richtlinien
Wenn ein Konto über ein anderes Konto unter Verwendung einer ressourcenbasierten Richtlinie auf eine Ressource zugreift, funktioniert der Prinzipal weiterhin mit dem vertrauenswürdigen Konto und muss seine Berechtigungen nicht aufgeben, um die Rollenberechtigungen zu erhalten. Mit anderen Worten, der Prinzipal hat nach wie vor Zugriff auf Ressourcen im vertrauenswürdigen Konto, aber gleichzeitig auch Zugriff auf die Ressource im vertrauenden Konto. Dies ist nützlich für Aufgaben wie das Kopieren von Daten in die oder aus der gemeinsam genutzten Ressource im anderen Konto.
Zu den Prinzipalen, die Sie in einer ressourcenbasierten Richtlinie angeben können, gehören Konten, IAM-Benutzer, Verbundbenutzerprinzipale, AWS STS SAML-Verbundprinzipale, OIDC-Verbundprinzipale, IAM-Rollen, Sitzungen mit übernommenen Rollen oder Dienste. AWS Weitere Informationen finden Sie unter [Angeben eines Auftraggebers](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying).
Informationen darüber, ob Prinzipalen in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Identifizieren von Ressourcen, die mit einer externen Entität geteilt wurden](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html#what-is-access-analyzer-resource-identification).
Die folgende Liste enthält AWS einige der Dienste, die ressourcenbasierte Richtlinien unterstützen. **Eine vollständige Liste der wachsenden Anzahl von AWS Diensten, die das Anhängen von Berechtigungsrichtlinien an Ressourcen statt an Prinzipale unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) und suchen Sie in der Spalte Ressourcenbasiert nach den Diensten, für die **Ja** angegeben ist.**
+ **Amazon-S3-Buckets** – Die Richtlinie ist dem Bucket angefügt, allerdings steuert die Richtlinie sowohl den Zugriff auf den Bucket als auch auf die darin befindlichen Objekte. Weitere Informationen finden Sie unter [Bucket-Richtlinien für Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) im *Benutzerhandbuch für Amazon Simple Storage Service*. In einigen Fällen kann es sinnvoll sein, Rollen für den kontoübergreifenden Zugriff auf Amazon S3 zu verwenden. Weitere Informationen finden Sie in den [Beispiel-Walkthroughs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ **Amazon Simple Notification Service (Amazon SNS)-Themen** – Weitere Informationen finden Sie unter [Beispiele für die Zugriffskontrolle in Amazon SNS](https://docs.aws.amazon.com//sns/latest/dg/sns-access-policy-use-cases.html) im *Entwicklerhandbuch zu Amazon Simple Notification Service*.
+ **Amazon Simple Queue Service (Amazon SQS)-Warteschlangen** – Weitere Informationen finden Sie unter [Anhang: Sprache der Zugriffsrichtliniensprache](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html) im *Amazon Simple Queue Service-Entwicklungshandbuch*.
## Ressourcenbasierte Richtlinien zum Delegieren von Berechtigungen AWS
Wenn eine Ressource den Auftraggeber in Ihrem Konto Berechtigungen gewährt, können Sie diese Berechtigungen dann an bestimmte IAM-Identitäten delegieren. Identitäten sind Benutzer, Benutzergruppen oder Rollen in Ihrem Konto. Sie delegieren Berechtigungen, indem Sie eine Richtlinie mit der Identität verknüpfen. Sie können maximal die vom ressourcenbesitzenden Konto gewährten Berechtigungen gewähren.
**Wichtig**
Beim kontoübergreifenden Zugriff benötigt ein Prinzipal `Allow` in der Identitätsrichtlinie **und** der ressourcenbasierte Richtlinie.
Nehmen Sie an, dass eine ressourcenbasierte Richtlinie allen Auftraggeber in Ihrem Konto vollen administrativen Zugriff auf eine Ressource gewährt. Anschließend können Sie Vollzugriff, Lesezugriff oder beliebigen anderen Teilzugriff auf die Prinzipale in Ihrem Konto delegieren. AWS Wenn die ressourcenbasierte Richtlinie nur Listenberechtigungen gewährt, können Sie alternativ nur den Listenzugriff delegieren. Wenn Sie versuchen, mehr Berechtigungen zu delegieren, als Ihr Konto hat, haben Ihre Auftraggeber immer noch nur Listenzugriff.
Weitere Informationen darüber, wie diese Entscheidungen getroffen werden, finden Sie unter [Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html).
**Anmerkung**
IAM-Rollen und ressourcenbasierte Richtlinien delegieren den Zugriff auf Konten nur innerhalb einer einzelnen Partition. Beispielsweise können Sie keinen kontenübergreifenden Zugriff zwischen einem Konto in der `aws`-Standardpartition und einem Konto in der `aws-cn`-Partition hinzufügen.
Nehmen Sie beispielsweise an, dass Sie `AccountA` und `AccountB` verwalten. In KontoA haben Sie einen Amazon-S3-Bucket mit dem Namen `BucketA`.
![\[Eine ressourcenbasierte Richtlinie, die für den Amazon-S3-Bucket erstellt wurde, gewährt KontoB Berechtigungen für KontoAA.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/access_policies-cross-account.png)
1. Sie weisen `BucketA` eine ressourcenbasierte Richtlinie zu, die allen Prinzipalen in KontoB Vollzugriff auf Objekte in Ihrem Bucket gewährt. Sie können beliebige Objekte in diesem Bucket erstellen, lesen oder löschen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::BucketA/*"
}
]
}
```
------
KontoA gewährt KontoB durch die Benennung von KontoA als Prinzipal in der ressourcenbasierten Richtlinie Vollzugriff auf BucketA. Dadurch ist KontoB berechtigt, alle Aktionen im Bucket über KontoA auszuführen und der KontoB-Administrator kann seinen Benutzern in KontoB den Zugriff erteilen.
Der Root-Benutzer von KontoB verfügt über alle Berechtigungen, die dem Konto gewährt werden. Daher hat der Root-Benutzer Vollzugriff auf BucketA.
1. In KontoB fügen Sie dem IAM-Benutzer mit dem Namen Benutzer2 eine Richtlinie an. Diese Richtlinie erlaubt dem Benutzer nur Lesezugriff auf die Objekte in BucketA. Das bedeutet, dass Benutzer2 die Objekte anzeigen, aber nicht erstellen, bearbeiten oder löschen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"s3:Get*",
"s3:List*" ],
"Resource" : "arn:aws:s3:::BucketA/*"
}
]
}
```
------
Die maximale Zugriffsebene, die KontoB delegieren kann, ist die Zugriffsebene, die dem Konto gewährt wird. In diesem Fall gewährt die ressourcenbasierte Richtlinie KontoB Vollzugriff, aber Benutzer2 wird nur der schreibgeschützte Zugriff gewährt.
Der KontoB-Administrator gewährt Benutzer1 keinen Zugriff. Standardmäßig haben Benutzer keine Berechtigungen, außer denen, die ausdrücklich gewährt werden, sodass Benutzer1 keinen Zugriff auf BucketA hat.
IAM wertet die Berechtigungen eines Auftraggebers zu dem Zeitpunkt aus, zu dem der Auftraggeber eine Anforderung stellt. Wenn Sie Platzhalter (\$1) verwenden, um Benutzern vollen Zugriff auf Ihre Ressourcen zu gewähren, können Prinzipale auf alle Ressourcen zugreifen, auf die Ihr Konto Zugriff hat. AWS Dies gilt auch für Ressourcen, die Sie nach der Erstellung der Benutzerrichtlinie hinzufügen oder auf die Sie Zugriff erhalten.
Hätte KontoB im vorhergehenden Beispiel eine Richtlinie an Benutzer2 angefügt, die Vollzugriff auf alle Ressourcen in allen Konten gewährt, hätte Benutzer2 automatisch Zugriff auf alle Ressourcen, auf die KontoB Zugriff hat. Dies schließt den BucketA-Zugriff und den Zugriff auf alle anderen Ressourcen ein, die durch ressourcenbasierte Richtlinien in KontoA gewährt werden.
Weitere Hinweise zur komplexen Verwendung von Rollen, z. B. zum Gewähren von Zugriff auf Anwendungen und Services, finden Sie unter [Gängige Szenarien für IAM-Rollen](id_roles_common-scenarios.md).
**Wichtig**
Gewähren Sie nur Zugriff auf Entitäten, denen Sie vertrauen, und gewähren Sie nur das erforderliche Mindestmaß an Zugriff. Wenn es sich bei der vertrauenswürdigen Entität um ein anderes AWS Konto handelt, kann jedem IAM-Prinzipal Zugriff auf Ihre Ressource gewährt werden. Das vertrauenswürdige AWS Konto kann den Zugriff nur in dem Umfang delegieren, in dem ihm Zugriff gewährt wurde. Es kann nicht mehr Zugriff delegieren, als dem Konto selbst gewährt wurde.
Weitere Informationen über Berechtigungen, Richtlinien und die Sprache der Berechtigungsrichtlinie, mit der Sie die Richtlinien erstellen, finden Sie unter [Zugriffsmanagement für AWS Ressourcen](access.md).
# Forward Access Sessions (FAS)
Forward Access Sessions (FAS) ist eine IAM-Technologie, die von AWS Diensten verwendet wird, um Ihre Identität, Berechtigungen und Sitzungsattribute weiterzugeben, wenn ein AWS Service in Ihrem Namen eine Anfrage stellt. FAS verwendet die Berechtigungen der Identität, die einen AWS Dienst aufruft, in Kombination mit der Identität eines AWS Dienstes, um Anfragen an nachgelagerte Dienste zu stellen. FAS-Anfragen werden erst im Namen eines IAM-Prinzipals an AWS Dienste gestellt, nachdem ein Dienst eine Anfrage erhalten hat, für deren Abschluss Interaktionen mit anderen AWS Diensten oder Ressourcen erforderlich sind. Wenn eine FAS-Anfrage gestellt wird:
+ Der Service, der die erste Anfrage von einem IAM-Prinzipal empfängt, überprüft die Berechtigungen des IAM-Prinzipals.
+ Der Service, der eine nachfolgende FAS-Anfrage empfängt, überprüft auch die Berechtigungen desselben IAM-Prinzipals.
FAS wird beispielsweise von Amazon S3 verwendet, um Aufrufe zur Entschlüsselung eines Objekts AWS Key Management Service zu tätigen, wenn [SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) zur Verschlüsselung verwendet wurde. Beim Herunterladen eines SSE-KMS-verschlüsselten Objekts ruft eine Rolle namens **data-reader** das Objekt gegen Amazon S3 GetObject auf und ruft es nicht direkt auf. AWS KMS Nach Erhalt der GetObject Anfrage und Autorisierung des Datenlesegeräts stellt Amazon S3 dann eine FAS-Anfrage an AWS KMS , um das Amazon S3 S3-Objekt zu entschlüsseln. Wenn KMS die FAS-Anfrage erhält, überprüft KMS die Berechtigungen der Rolle und autorisiert die Entschlüsselungsanforderung nur, wenn „data-reader“ über die richtigen Berechtigungen für den KMS-Schlüssel verfügt. Die Anfragen an Amazon S3 und AWS KMS werden mit den Berechtigungen der Rolle autorisiert und sind nur erfolgreich, wenn der Datenleser über Berechtigungen sowohl für das Amazon S3 S3-Objekt als auch für den AWS KMS-Schlüssel verfügt.
![\[Ein Flussdiagramm einer IAM-Rolle, die als Prinzipal an Amazon S3 und dann an AWS KMSübergeben wird.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/access-fas-example.png)
**Anmerkung**
Zusätzliche FAS-Anfragen können von Services gestellt werden, die eine FAS-Anfrage erhalten haben. In solchen Fällen muss der anfordernde Prinzipal über Berechtigungen für alle von FAS aufgerufenen Services verfügen.
## FAS-Anfragen und IAM-Richtlinienbedingungen
Wenn FAS-Anfragen gestellt werden, werden [aws:CalledVia](reference_policies_condition-keys.md#condition-keys-calledvia)-, [aws:CalledViaFirst](reference_policies_condition-keys.md#condition-keys-calledviafirst)- und [aws:CalledViaLast](reference_policies_condition-keys.md#condition-keys-calledvialast)-Bedingungsschlüssel mit dem Service-Prinzipal des Service gefüllt, der den FAS-Aufruf initiiert hat. Der Wert des [aws:ViaAWSService](reference_policies_condition-keys.md#condition-keys-viaawsservice)-Bedingungsschlüssels wird immer dann auf `true` gesetzt, wenn eine FAS-Anfrage gestellt wird. In der folgenden Abbildung sind für die CloudFormation direkte Anfrage keine `aws:CalledVia` oder keine `aws:ViaAWSService` Bedingungsschlüssel gesetzt. Wenn CloudFormation DynamoDB im Namen der Rolle nachgelagerte FAS-Anfragen stellen, werden die Werte für diese Bedingungsschlüssel aufgefüllt.
![\[Ein Flussdiagramm einer IAM-Rolle, die als Principal an DynamoDB übergeben wird CloudFormation und anschließend die Bedingungsschlüsselwerte an DynamoDB und weitergibt. AWS KMS\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/access-fas-example2.png)
Damit eine FAS-Anfrage gestellt werden kann, wenn sie andernfalls durch eine Deny-Richtlinienanweisung mit einem Bedingungsschlüssel, der Quell-IP-Adressen oder Quelle testet, verweigert würde, müssen Sie Bedingungsschlüssel verwenden VPCs, um in Ihrer Deny-Richtlinie eine Ausnahme für FAS-Anfragen festzulegen. Dies kann für alle FAS-Anfragen mithilfe des `aws:ViaAWSService`-Bedingungsschlüssels erfolgen. Damit nur bestimmte AWS Dienste FAS-Anfragen stellen können, verwenden Sie. `aws:CalledVia`
**Wichtig**
Wenn eine FAS-Anfrage gestellt wird, nachdem eine erste Anfrage über einen VPC-Endpunkt gestellt wurde, werden die Bedingungsschlüsselwerte für `aws:SourceVpce`, `aws:SourceVpc` und `aws:VpcSourceIp` aus der ersten Anfrage nicht in FAS-Anfragen verwendet. Wenn Sie Richtlinien mit `aws:VPCSourceIP` oder `aws:SourceVPCE` schreiben, um bedingten Zugriff zu gewähren, müssen Sie auch `aws:ViaAWSService` oder `aws:CalledVia` verwenden, um FAS-Anfragen zuzulassen. Wenn eine FAS-Anfrage gestellt wird, nachdem eine erste Anfrage bei einem Endpunkt eines öffentlichen AWS Dienstes eingegangen ist, werden nachfolgende FAS-Anfragen mit demselben `aws:SourceIP` Bedingungsschlüsselwert gestellt.
## Beispiel: Amazon-S3-Zugriff von einer VPC oder mit FAS zulassen
Im folgenden Beispiel für eine IAM-Richtlinie sind Amazon S3 GetObject - und Athena-Anfragen nur zulässig, wenn sie von VPC-Endpunkten stammen, an die sie angeschlossen sind*example\$1vpc*, oder wenn es sich bei der Anfrage um eine FAS-Anfrage von Athena handelt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OnlyAllowMyIPs",
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"athena:StartQueryExecution",
"athena:GetQueryResults",
"athena:GetWorkGroup",
"athena:StopQueryExecution",
"athena:GetQueryExecution"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceVPC": [
"vpc-111bbb22"
]
}
}
},
{
"Sid": "OnlyAllowFAS",
"Effect": "Allow",
"Action": [
"s3:GetObject*"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "athena.amazonaws.com"
}
}
}
]
}
```
------
Weitere Beispiele für die Verwendung von Bedingungsschlüsseln, um den FAS-Zugriff zu ermöglichen, finden Sie im Repository [Data Perimeter Policy Examples](https://github.com/aws-samples/data-perimeter-policy-examples).
# Beispiele für identitätsbasierte Richtlinien in IAM
Eine [Richtlinie](access_policies.md) ist ein Objekt, AWS das, wenn es einer Identität oder Ressource zugeordnet ist, deren Berechtigungen definiert. AWS wertet diese Richtlinien aus, wenn ein IAM-Prinzipal (Benutzer oder Rolle) eine Anfrage stellt. Die Berechtigungen in den Richtlinien legen fest, ob eine Anforderung zugelassen oder abgelehnt wird. Die meisten Richtlinien werden in Form AWS von JSON-Dokumenten gespeichert, die an eine IAM-Identität (Benutzer, Benutzergruppe oder Rolle) angehängt sind. Zu identitätsbasierten Richtlinien gehören verwaltete AWS -Richtlinien, kundenverwaltete Richtlinien und eingebundene Richtlinien. Informationen zum Erstellen einer IAM-Richtlinie mithilfe dieser Beispiel-JSON-Richtliniendokumente finden Sie unter [Erstellen von Richtlinien mit dem JSON-Editor](access_policies_create-console.md#access_policies_create-json-editor).
Standardmäßig werden alle Anforderungen verweigert. Daher müssen Sie Zugriffsberechtigungen für alle Services, Aktionen und Ressourcen, auf die die Identität zugreifen soll, erteilen. Wenn Sie auch den Zugriff zur Durchführung der angegebenen Aktionen in der IAM-Konsole gewähren möchten, müssen Sie zusätzliche Berechtigungen erteilen.
Nachstehende Richtlinienbibliothek hilft Ihnen bei der Definition der Berechtigungen für Ihre IAM-Identitäten. Nachdem Sie die benötigte Richtlinie gefunden haben, klicken Sie auf **View this policy (Richtlinie anzeigen)**, um den JSON-Code der Richtlinie anzuzeigen. Sie können das JSON-Richtliniendokument als Vorlage für Ihre eigenen Richtlinien verwenden.
**Anmerkung**
Wenn Sie eine Richtlinie zur Aufnahme in dieses Referenzhandbuch vorschlagen möchten, verwenden Sie die Schaltfläche **Feedback** unten auf der Seite.
## Beispielrichtlinien: AWS
+ Gewährt den Zugriff innerhalb eines bestimmten Datumsbereichs. ([Richtlinie anzeigen](reference_policies_examples_aws-dates.md).)
+ Ermöglicht das Aktivieren und Deaktivieren von AWS Regionen. ([Richtlinie anzeigen](reference_policies_examples_aws-enable-disable-regions.md).)
+ Ermöglicht es MFA-authentifizierten Benutzern, ihre eigenen Anmeldeinformationen auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. ([Richtlinie anzeigen](reference_policies_examples_aws_my-sec-creds-self-manage.md).)
+ Gewährt spezifischen Zugriff bei der Verwendung von MFA in einem bestimmten Datumsbereich. ([Richtlinie anzeigen](reference_policies_examples_aws_mfa-dates.md).)
+ Ermöglicht es Benutzern, ihre eigenen Anmeldeinformationen auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. ([Richtlinie anzeigen](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md).)
+ Ermöglicht es Benutzern, ihr eigenes MFA-Gerät auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. ([Richtlinie anzeigen](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md).)
+ Ermöglicht es Benutzern, ihr eigenes Passwort auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. ([Richtlinie anzeigen](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md).)
+ Ermöglicht es Benutzern, ihr eigenes Passwort sowie ihre eigenen Zugriffsschlüssel und öffentlichen SSH-Schlüssel auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. ([Richtlinie anzeigen](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md).)
+ Verweigert den Zugriff auf AWS basierend auf der angeforderten Region. ([Richtlinie anzeigen](reference_policies_examples_aws_deny-requested-region.md).)
+ Verweigert den Zugriff auf AWS basierend auf der Quell-IP-Adresse. ([Richtlinie anzeigen](reference_policies_examples_aws_deny-ip.md).)
## Beispiel für eine Richtlinie: AWS Data Exchange
+ Verweigern Sie den Zugriff auf Amazon-S3-Ressourcen außerhalb Ihres Kontos, mit Ausnahme von AWS Data Exchange. ([Richtlinie anzeigen](reference_policies_examples_resource_account_data_exch.md).)
## Beispielrichtlinien: AWS Data Pipeline
+ Verweigert den Zugriff auf nicht vom Benutzer erstellte Pipelines ([Richtlinie anzeigen](reference_policies_examples_datapipeline_not-owned.md)).
## Beispielrichtlinien: Amazon DynamoDB
+ Ermöglicht den Zugriff auf eine bestimmte Amazon DynamoDB-Tabelle ([Richtlinie anzeigen](reference_policies_examples_dynamodb_specific-table.md).)
+ Ermöglicht den Zugriff auf bestimmte Amazon DynamoDB-Attribute ([Richtlinie anzeigen](reference_policies_examples_dynamodb_attributes.md)).
+ Ermöglicht den zeilenweisen Zugriff auf Amazon DynamoDB, basierend auf einer Amazon Cognito ID-ID ([Richtlinie anzeigen](reference_policies_examples_dynamodb_items.md).)
## Beispielrichtlinien: Amazon EC2
+ Ermöglicht das Anhängen oder Trennen von Amazon EBS-Volumes an EC2 Amazon-Instances auf der Grundlage von Tags ([Diese Richtlinie anzeigen](reference_policies_examples_ec2_ebs-owner.md).)
+ Ermöglicht das programmgesteuerte Starten von EC2 Amazon-Instances in einem bestimmten Subnetz und in der Konsole ([Diese Richtlinie anzeigen](reference_policies_examples_ec2_instances-subnet.md).)
+ Ermöglicht die programmgesteuerte Verwaltung von EC2 Amazon-Sicherheitsgruppen, die einer bestimmten VPC zugeordnet sind, und zwar programmgesteuert und in der Konsole ([Diese Richtlinie anzeigen](reference_policies_examples_ec2_securitygroups-vpc.md)).
+ Ermöglicht das programmgesteuerte Starten oder Stoppen von EC2 Amazon-Instances, die ein Benutzer markiert hat, und zwar programmgesteuert und in der Konsole ([Diese Richtlinie anzeigen](reference_policies_examples_ec2_tag-owner.md)).
+ Ermöglicht das programmgesteuerte Starten oder Stoppen von EC2 Amazon-Instances auf der Grundlage von Ressourcen- und Prinzipal-Tags ([Diese Richtlinie anzeigen](reference_policies_examples_ec2-start-stop-tags.md)).
+ Ermöglicht das Starten oder Stoppen von EC2 Amazon-Instances, wenn die Ressourcen- und Prinzipal-Tags übereinstimmen ([Sehen Sie sich diese Richtlinie](reference_policies_examples_ec2-start-stop-match-tags.md) an.)
+ Ermöglicht vollen EC2 Amazon-Zugriff innerhalb einer bestimmten Region, programmgesteuert und in der Konsole. ([Richtlinie anzeigen](reference_policies_examples_ec2_region.md).)
+ Ermöglicht das Starten oder Stoppen einer bestimmten EC2 Amazon-Instance und das Ändern einer bestimmten Sicherheitsgruppe programmgesteuert und in der Konsole ([Diese Richtlinie anzeigen](reference_policies_examples_ec2_instance-securitygroup.md)).
+ Verweigert den Zugriff auf bestimmte EC2 Amazon-Operationen ohne MFA ([Sehen Sie sich diese Richtlinie](reference_policies_examples_ec2_require-mfa.md) an.)
+ Beschränkt das Beenden von EC2 Amazon-Instances auf einen bestimmten IP-Adressbereich ([Sehen Sie sich diese Richtlinie](reference_policies_examples_ec2_terminate-ip.md) an.)
## Beispielrichtlinien: AWS Identity and Access Management (IAM)
+ Ermöglicht den Zugriff auf die Richtliniensimulator-API ([Richtlinie anzeigen](reference_policies_examples_iam_policy-sim.md)).
+ Ermöglicht den Zugriff auf die Richtliniensimulator-Konsole ([Richtlinie anzeigen](reference_policies_examples_iam_policy-sim-console.md)).
+ Ermöglicht die Annahme aller Rollen mit einem bestimmten Tag, programmgesteuert und in der Konsole [(Richtlinie anzeigen)](reference_policies_examples_iam-assume-tagged-role.md).
+ Ermöglicht und verweigert den Zugriff auf mehrere Services, programmgesteuert und in der Konsole [(Richtlinie anzeigen)](reference_policies_examples_iam_multiple-services-console.md).
+ Ermöglicht das Hinzufügen eines spezifischen Tags an einen IAM-Benutzer mit einem anderen spezifischen Tag, programmgesteuert und in der Konsole ([Richtlinie anzeigen](reference_policies_examples_iam-add-tag.md)).
+ Ermöglicht das Hinzufügen eines spezifischen Tags zu einem bzw. einer beliebigen IAM-Benutzer oder ‑Rolle, programmgesteuert und in der Konsole ([Richtlinie anzeigen](reference_policies_examples_iam-add-tag-user-role.md)).
+ Ermöglicht das Erstellen eines neuen Benutzers nur mit bestimmten Tags ([Richtlinie anzeigen](reference_policies_examples_iam-new-user-tag.md))
+ Ermöglicht das Generieren und Abrufen von IAM-Berichten zu den Anmeldeinformationen ([Richtlinie anzeigen](reference_policies_examples_iam-credential-report.md)).
+ Ermöglicht die Verwaltung einer Gruppenmitgliedschaft, programmgesteuert und in der Konsole [(Richtlinie anzeigen](reference_policies_examples_iam_manage-group-membership.md)).
+ Ermöglicht das Verwalten eines bestimmten Tags ([Richtlinie anzeigen](reference_policies_examples_iam-manage-tags.md).)
+ Ermöglicht die Übergabe einer IAM-Rolle an einen bestimmten Service ([Richtlinie anzeigen](reference_policies_examples_iam-passrole-service.md)).
+ Ermöglicht schreibgeschützten Zugriff auf die IAM-Konsole ohne Berichterstattung ([Richtlinie anzeigen](reference_policies_examples_iam_read-only-console-no-reporting.md)).
+ Ermöglicht schreibgeschützten Zugriff auf die IAM-Konsole ([Richtlinie anzeigen](reference_policies_examples_iam_read-only-console.md)).
+ Ermöglicht spezifischen Benutzern die Verwaltung einer Gruppe, programmgesteuert und in der Konsole [(Richtlinie anzeigen](reference_policies_examples_iam_users-manage-group.md)).
+ Ermöglicht das Festlegen der Kontopasswortanforderungen, programmgesteuert und in der Konsole ([Richtlinie anzeigen](reference_policies_examples_iam_set-account-pass-policy.md).)
+ Ermöglicht den Benutzern mit einem bestimmten Pfad die Verwendung der Richtliniensimulator-API ([Richtlinie anzeigen](reference_policies_examples_iam_policy-sim-path.md)).
+ Ermöglicht den Benutzern mit einem bestimmten Pfad die Verwendung der Richtliniensimulator-Konsole ([Richtlinie anzeigen](reference_policies_examples_iam_policy-sim-path-console.md)).
+ IAM: Ermöglicht es IAM-Benutzern, MFA-Geräte selbst zu verwalten ([Richtlinie anzeigen](reference_policies_examples_iam_mfa-selfmanage.md).)
+ Ermöglicht IAM-Benutzern, ihre eigenen Anmeldeinformationen programmgesteuert und in der Konsole festzulegen. ([Richtlinie anzeigen](reference_policies_examples_iam_credentials_console.md).)
+ Ermöglicht das Anzeigen von Informationen über den Dienst, auf den zuletzt zugegriffen wurde, für eine AWS Organizations Richtlinie in der IAM-Konsole. ([Richtlinie anzeigen](reference_policies_examples_iam_service-accessed-data-orgs.md).)
+ Beschränkt die verwalteten Richtlinien, die IAM-Benutzern, -Gruppen oder -Rollen zugeordnet werden können ([Richtlinie anzeigen](reference_policies_examples_iam_limit-managed.md)).
+ Erlaubt den Zugriff auf IAM-Richtlinien nur in Ihrem Konto ([Diese Richtlinie anzeigen](resource_examples_iam_policies_resource_account.md).)
## Beispielrichtlinien: AWS Lambda
+ Ermöglicht einer AWS Lambda Funktion den Zugriff auf eine Amazon DynamoDB-Tabelle ([Diese Richtlinie anzeigen](reference_policies_examples_lambda-access-dynamodb.md).)
## Beispielrichtlinien: Amazon RDS
+ Ermöglicht den vollständigen Amazon RDS-Datenbankzugriff innerhalb einer bestimmten Region. ([Richtlinie anzeigen](reference_policies_examples_rds_region.md).)
+ Ermöglicht es, Amazon RDS-Datenbanken programmgesteuert und in der Konsole wiederherzustellen ([Richtlinie anzeigen](reference_policies_examples_rds_db-console.md))
+ Gewährt Tag-Eigentümern Vollzugriff auf die von ihnen markierten Amazon RDS-Ressourcen ([Richtlinie anzeigen](reference_policies_examples_rds_tag-owner.md))
## Beispiele für Richtlinien: Amazon S3
+ Ermöglicht es einem Amazon Cognito-Benutzer, auf Objekte in seinem eigenen Amazon S3-Bucket zuzugreifen ([Richtlinie anzeigen](reference_policies_examples_s3_cognito-bucket.md))
+ Ermöglicht einem Benutzer mit temporären Anmeldeinformationen den Zugriff auf sein eigenes Stammverzeichnis in Amazon S3, programmgesteuert und in der Konsole ([Diese Richtlinie anzeigen](reference_policies_examples_s3_federated-home-directory-console.md)).
+ Ermöglicht vollständigen S3-Zugriff. Verweigert jedoch explizit den Zugriff auf den Produktions-Bucket, wenn der Administrator sich nicht innerhalb der letzten dreißig Minuten mit MFA angemeldet hat, ([Richtlinie anzeigen)](reference_policies_examples_s3_full-access-except-production.md).
+ Ermöglicht es IAM-Benutzern, programmgesteuert und in der Konsole auf ihr eigenes Stammverzeichnis in Amazon S3 zuzugreifen ([Richtlinie anzeigen](reference_policies_examples_s3_home-directory-console.md))
+ Ermöglicht einem Benutzer die Verwaltung eines einzelnen Amazon S3 S3-Buckets und verweigert alle anderen AWS Aktionen und Ressourcen ([Diese Richtlinie anzeigen](reference_policies_examples_s3_deny-except-bucket.md).)
+ Ermöglicht den `Read`- und `Write`-Zugriff auf einen bestimmten Amazon S3-Bucket ([Richtlinie anzeigen](reference_policies_examples_s3_rw-bucket.md))
+ Ermöglicht den `Read`- und `Write`-Zugriff programmgesteuert und in der Konsole auf einen bestimmten Amazon S3-Bucket ([Richtlinie anzeigen](reference_policies_examples_s3_rw-bucket-console.md))
# AWS: Ermöglicht Zugriff basierend auf Datum und Uhrzeit
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Zugriff auf Aktionen basierend auf Datum und Uhrzeit erlaubt. Diese Richtlinie beschränkt den Zugriff auf Aktionen, die zwischen dem 1. April 2020 und dem 30. Juni 2020 (UTC) stattfinden. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Weitere Informationen zum Verwenden mehrerer Bedingungen innerhalb eines `Condition`-Blocks einer IAM-Richtlinie finden Sie unter [Mehrere Werte in einer Bedingung](reference_policies_elements_condition.md#Condition-multiple-conditions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "service-prefix:action-name",
"Resource": "*",
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"},
"DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"}
}
}
]
}
```
------
**Anmerkung**
Sie können eine Richtlinienvariable nicht mit dem Datum-Bedingungsoperator verwenden. Weitere Informationen finden Sie unter [Condition-Element](reference_policies_variables.md#policy-vars-conditionelement)
# AWS: Ermöglicht das Aktivieren und Deaktivieren von Regionen AWS
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es einem Administrator erlaubt, die Region Asien-Pazifik (Hongkong) (ap-east-1) zu aktivieren und zu deaktivieren. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Diese Einstellung wird auf der Seite **Account Settings (Kontoeinstellungen)** in der AWS-Managementkonsole angezeigt. Diese Seite enthält sensible Informationen auf Kontoebene, die nur von Kontoadministratoren angezeigt und verwaltet werden sollten. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
**Wichtig**
Standardmäßig aktivierte Regionen können weder aktiviert noch deaktiviert werden. Sie können nur Regionen einschließen, die standardmäßig *deaktiviert* sind. Weitere Informationen finden Sie unter [Verwalten von AWS -Regionen](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) im *Allgemeine AWS-Referenz*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableDisableHongKong",
"Effect": "Allow",
"Action": [
"account:EnableRegion",
"account:DisableRegion"
],
"Resource": "*",
"Condition": {
"StringEquals": {"account:TargetRegion": "ap-east-1"}
}
},
{
"Sid": "ViewConsole",
"Effect": "Allow",
"Action": [
"account:ListRegions"
],
"Resource": "*"
}
]
}
```
------
# AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern, die mithilfe der [Multi-Faktor-Authentifizierung (MFA)](id_credentials_mfa.md) authentifiziert werden, erlaubt, ihre eigenen Anmeldeinformationen auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. Diese Seite der AWS-Managementkonsole zeigt Kontoinformationen wie z. B. die Konto-ID und die kanonische Benutzer-ID an. Benutzer können auch ihre eigenen Passwörter, Zugriffsschlüssel, MFA-Geräte, X.509-Zertifikate und SSH-Schlüssel und Git-Anmeldeinformationen anzeigen und bearbeiten. Diese Beispielrichtlinie enthält die erforderlichen Berechtigungen zum Anzeigen und Bearbeiten aller Informationen auf der Seite. Außerdem muss der Benutzer MFA einrichten und authentifizieren, bevor er andere Operationen in ausführt. AWS Informationen darüber, wie Benutzern die Verwaltung ihrer eigenen Anmeldeinformationen ohne MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht IAM-Benutzern, ihre eigenen Anmeldeinformationen auf der Seite „Sicherheits-Anmeldeinformationen“ zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md).
Informationen dazu, wie Benutzer auf die Seite **Sicherheits-Anmeldeinformationen** zugreifen können, finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**Anmerkung**
Diese Beispielrichtlinie erlaubt es Benutzern nicht, ein Passwort zurückzusetzen, wenn sie sich zum ersten Mal bei der anmelden. AWS-Managementkonsole Wir empfehlen, dass Sie neuen Benutzern keine Berechtigungen erteilen, bis sie sich angemeldet haben. Weitere Informationen finden Sie unter [Wie erstelle ich sicher IAM-Benutzer?](troubleshoot.md#troubleshoot_general_securely-create-iam-users). Dies verhindert auch, dass Benutzer mit einem abgelaufenen Passwort ihr Passwort während der Anmeldung zurücksetzen können. Sie können dies erlauben, indem Sie `iam:ChangePassword` und `iam:GetAccountPasswordPolicy` der Anweisung `DenyAllExceptListedIfNoMFA` hinzufügen. Wir empfehlen dies jedoch nicht, da es ein Sicherheitsrisiko darstellen kann, Benutzern eine Änderung ihres Passworts ohne MFA zu erlauben.
Wenn Sie diese Richtlinie für den programmatischen Zugriff verwenden möchten, müssen Sie [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) anrufen, um sich bei MFA zu authentifizieren. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
**Was macht diese Richtlinie?**
+ Die `AllowViewAccountInfo`-Anweisung ermöglicht es dem Benutzer, Informationen auf Kontoebene anzuzeigen. Diese Berechtigungen müssen in ihrer eigenen Anweisung vorliegen, da sie keine Ressourcen-ARN unterstützen oder keine angeben müssen. Geben Sie anstelle von Berechtigungen `"Resource" : "*"` ein. Diese Anweisung enthält die folgenden Aktionen, mit denen der Benutzer spezifische Informationen anzeigen kann:
+ `GetAccountPasswordPolicy` – Zeigt die Passwortanforderungen des Kontos beim Ändern seines eigenen IAM-Benutzer-Passworts an.
+ `ListVirtualMFADevices` – Zeigt Details über ein virtuelles MFA-Gerät an, das für den Benutzer aktiviert ist.
+ Mit der `AllowManageOwnPasswords`-Anweisung kann der Benutzer sein eigenes Passwort ändern. Diese Anweisung enthält auch die `GetUser`-Aktion, die erforderlich ist, um die meisten Informationen auf der Seite **My Security Credentials (Meine Sicherheitsanmeldeinformationen)** anzuzeigen.
+ Die `AllowManageOwnAccessKeys`-Anweisung ermöglicht dem Benutzer das Erstellen, Aktualisieren und Löschen seiner eigenen Zugriffsschlüssel. Der Benutzer kann auch Informationen darüber abrufen, wann der angegebene Zugriffsschlüssel zuletzt verwendet wurde.
+ Die `AllowManageOwnSigningCertificates`-Anweisung ermöglicht dem Benutzer das Hochladen, Aktualisieren und Löschen seiner eigenen Signaturzertifikate.
+ Die `AllowManageOwnSSHPublicKeys`-Anweisung ermöglicht dem Benutzer das Hochladen, Aktualisieren und Löschen seiner eigenen öffentlichen SSH-Schlüssel für CodeCommit.
+ Die `AllowManageOwnGitCredentials`-Anweisung ermöglicht dem Benutzer das Erstellen, Aktualisieren und Löschen seiner eigenen Git-Anmeldeinformationen für CodeCommit.
+ Die `AllowManageOwnVirtualMFADevice`-Anweisung ermöglicht dem Benutzer das Erstellen seines eigenen virtuellen MFA-Geräts. Der Ressourcen-ARN in dieser Anweisung erlaubt es dem Benutzer, ein MFA-Gerät mit einem beliebigen Namen zu erstellen, aber die anderen Anweisungen in der Richtlinie erlauben es dem Benutzer nur, das Gerät mit dem aktuell angemeldeten Benutzer zu verknüpfen.
+ Die `AllowManageOwnUserMFA`-Anweisung ermöglicht es dem Benutzer, das virtuelle, U2F- oder physische MFA-Gerät für seinen eigenen Benutzer anzuzeigen oder zu verwalten. Der Ressourcen-ARN in dieser Anweisung gewährt nur Zugriff auf den eigenen IAM-Benutzer des Benutzers. Benutzer können das MFA-Gerät für andere Benutzer nicht anzeigen oder verwalten.
+ Die `DenyAllExceptListedIfNoMFA` Anweisung verweigert den Zugriff auf alle Aktionen in allen AWS Diensten, mit Ausnahme einiger aufgelisteter Aktionen, jedoch ***nur, wenn*** der Benutzer nicht mit MFA angemeldet ist. Die Anweisung verwendet eine Kombination aus `"Deny"` und `"NotAction"`, um den Zugriff auf alle Aktionen, die nicht aufgeführt sind, explizit zu verwehren. Die aufgeführten Elemente werden durch diese Anweisung nicht verweigert oder zugelassen. Die Aktionen werden aber durch andere Anweisungen in der Richtlinie zugelassen. Weitere Informationen zur Logik dieser Anweisung finden Sie unter [NotAction with](reference_policies_elements_notaction.md) Deny. Hat sich der Benutzer mit MFA angemeldet, schlägt der `Condition`-Test fehl und diese Anweisung verwehrt keine Aktionen. In diesem Fall bestimmen andere Richtlinien oder Anweisungen für den Benutzer die Berechtigungen des Benutzers.
Durch diese Anweisung wird sichergestellt, dass der Benutzer, wenn er nicht mit MFA angemeldet ist, nur die aufgeführten Aktionen ausführen kann. Außerdem kann er die aufgelisteten Aktionen nur ausführen, wenn eine andere Anweisung oder Richtlinie den Zugriff auf diese Aktionen gewährt. Dies ermöglicht es einem Benutzer nicht, beim Anmelden ein Passwort zu erstellen, da die `iam:ChangePassword`-Aktion nicht ohne MFA-Autorisierung erlaubt sein sollte.
Die `...IfExists`-Version des `Bool` -Operators stellt sicher, dass bei fehlendem `aws:MultiFactorAuthPresent`-Schlüssel die Bedingung den Wert "True" zurückgibt. Dies bedeutet, dass einem Benutzer, der mit langfristigen Anmeldeinformationen auf eine API zugreift, wie z. B. einem Zugriffsschlüssel, der Zugriff auf die Nicht-IAM-API-Operationen verweigert wird.
Diese Richtlinie ermöglicht es Benutzern nicht, die Seite **Users (Benutzer)** in der IAM-Konsole anzuzeigen oder diese Seite für den Zugriff auf ihre eigenen Benutzerinformationen zu verwenden. Um dies zuzulassen, fügen Sie die Aktion `iam:ListUsers` der Anweisung `AllowViewAccountInfo` und der Anweisung `DenyAllExceptListedIfNoMFA` hinzu. Darüber hinaus ermöglicht sie Benutzern nicht, ihr Passwort auf ihrer eigenen Benutzerseite anzupassen. Um dies zu ermöglichen, fügen Sie die Aktionen `iam:GetLoginProfile` und `iam:UpdateLoginProfile` zur Anweisung `AllowManageOwnPasswords` hinzu. Um es einem Benutzer auch zu ermöglichen, sein Passwort über seine eigene Benutzerseite zu ändern, ohne sich mit MFA anzumelden, fügen Sie die Aktion `iam:UpdateLoginProfile` zur Anweisung `DenyAllExceptListedIfNoMFA` hinzu.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:GetAccessKeyLastUsed"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSigningCertificates",
"Effect": "Allow",
"Action": [
"iam:DeleteSigningCertificate",
"iam:ListSigningCertificates",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnGitCredentials",
"Effect": "Allow",
"Action": [
"iam:CreateServiceSpecificCredential",
"iam:DeleteServiceSpecificCredential",
"iam:ListServiceSpecificCredentials",
"iam:ResetServiceSpecificCredential",
"iam:UpdateServiceSpecificCredential"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/*"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:GetMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
```
------
# AWS: Ermöglicht spezifischen Zugriff mit MFA innerhalb bestimmter Daten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen, die mehrere Bedingungen verwendet, die mithilfe von einem logischen `AND` bewertet werden. Es ermöglicht vollständigen Zugriff auf den Service mit dem Namen `SERVICE-NAME-1`und den Zugriff auf die Aktionen `ACTION-NAME-A` und `ACTION-NAME-B` im Service mit dem Namen `SERVICE-NAME-2`. Diese Aktionen sind nur zulässig, wenn der Benutzer mit der [Multi-Factor Authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) authentifiziert wird. Der Zugriff ist auf Aktionen vom 1. Juli 2017 bis einschließlich 31. Dezember 2017 (UTC) beschränkt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Weitere Informationen zum Verwenden mehrerer Bedingungen innerhalb eines `Condition`-Blocks einer IAM-Richtlinie finden Sie unter [Mehrere Werte in einer Bedingung](reference_policies_elements_condition.md#Condition-multiple-conditions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"service-prefix-1:*",
"service-prefix-2:action-name-a",
"service-prefix-2:action-name-b"
],
"Resource": "*",
"Condition": {
"Bool": {"aws:MultiFactorAuthPresent": true},
"DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
"DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
}
}
}
```
------
# AWS: Ermöglicht IAM-Benutzern, ihre eigenen Anmeldeinformationen auf der Seite „Sicherheits-Anmeldeinformationen“ zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern erlaubt, alle ihre eigenen Anmeldeinformationen auf der Seite **Sicherheitsanmeldeinformationen** zu verwalten. AWS-Managementkonsole Auf dieser Seite werden Kontoinformationen wie die Konto-ID und die kanonische Benutzer-ID angezeigt. Benutzer können auch ihre eigenen Passwörter, Zugriffsschlüssel, X.509-Zertifikate, SSH-Schlüssel und Git-Anmeldeinformationen anzeigen und bearbeiten. Diese Beispielrichtlinie enthält die erforderlichen Berechtigungen zum Anzeigen und Bearbeiten aller Informationen auf der Seite *mit Ausnahme* des MFA-Geräts des Benutzers. Informationen darüber, wie Benutzern die Verwaltung ihrer eigenen Anmeldeinformationen mit MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md).
Informationen dazu, wie Benutzer auf die Seite **Sicherheits-Anmeldeinformationen** zugreifen können, finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**Was macht diese Richtlinie?**
+ Die `AllowViewAccountInfo`-Anweisung ermöglicht es dem Benutzer, Informationen auf Kontoebene anzuzeigen. Diese Berechtigungen müssen in ihrer eigenen Anweisung vorliegen, da sie keine Ressourcen-ARN unterstützen oder keine angeben müssen. Geben Sie anstelle von Berechtigungen `"Resource" : "*"` ein. Diese Anweisung enthält die folgenden Aktionen, mit denen der Benutzer spezifische Informationen anzeigen kann:
+ `GetAccountPasswordPolicy` – Zeigt die Passwortanforderungen des Kontos beim Ändern seines eigenen IAM-Benutzer-Passworts an.
+ `GetAccountSummary` – Zeigt die Konto-ID und die [kanonische Benutzer-ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) des Kontos an.
+ Mit der `AllowManageOwnPasswords`-Anweisung kann der Benutzer sein eigenes Passwort ändern. Diese Anweisung enthält auch die `GetUser`-Aktion, die erforderlich ist, um die meisten Informationen auf der Seite **My Security Credentials (Meine Sicherheitsanmeldeinformationen)** anzuzeigen.
+ Die `AllowManageOwnAccessKeys`-Anweisung ermöglicht dem Benutzer das Erstellen, Aktualisieren und Löschen seiner eigenen Zugriffsschlüssel. Der Benutzer kann auch Informationen darüber abrufen, wann der angegebene Zugriffsschlüssel zuletzt verwendet wurde.
+ Die `AllowManageOwnSigningCertificates`-Anweisung ermöglicht dem Benutzer das Hochladen, Aktualisieren und Löschen seiner eigenen Signaturzertifikate.
+ Die `AllowManageOwnSSHPublicKeys`-Anweisung ermöglicht dem Benutzer das Hochladen, Aktualisieren und Löschen seiner eigenen öffentlichen SSH-Schlüssel für CodeCommit.
+ Die `AllowManageOwnGitCredentials`-Anweisung ermöglicht dem Benutzer das Erstellen, Aktualisieren und Löschen seiner eigenen Git-Anmeldeinformationen für CodeCommit.
Diese Richtlinie erlaubt es Benutzern nicht, ihre eigenen MFA-Geräte anzuzeigen oder zu verwalten. Außerdem können sie die Seite **Users (Benutzer)** in der IAM-Konsole nicht anzuzeigen oder für den Zugriff auf ihre eigenen Benutzerinformationen verwenden. Um dies zu ermöglichen, fügen Sie die Aktion `iam:ListUsers` zur Anweisung `AllowViewAccountInfo` hinzu. Darüber hinaus ermöglicht sie Benutzern nicht, ihr Passwort auf ihrer eigenen Benutzerseite anzupassen. Um dies zu ermöglichen, fügen Sie die Aktionen `iam:CreateLoginProfile`, `iam:DeleteLoginProfile`, `iam:GetLoginProfile` und `iam:UpdateLoginProfile` zur Anweisung `AllowManageOwnPasswords` hinzu.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:GetAccountSummary"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:GetAccessKeyLastUsed"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSigningCertificates",
"Effect": "Allow",
"Action": [
"iam:DeleteSigningCertificate",
"iam:ListSigningCertificates",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnGitCredentials",
"Effect": "Allow",
"Action": [
"iam:CreateServiceSpecificCredential",
"iam:DeleteServiceSpecificCredential",
"iam:ListServiceSpecificCredentials",
"iam:ResetServiceSpecificCredential",
"iam:UpdateServiceSpecificCredential"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
```
------
# AWS: Ermöglicht MFA-authentifizierten IAM-Benutzern die Verwaltung ihres eigenen MFA-Geräts auf der Seite „Sicherheits-Anmeldeinformationen“
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern, die über eine [Multi-Faktor-Authentifizierung (MFA)](id_credentials_mfa.md) authentifiziert wurden, ermöglicht, ihr eigenes MFA-Gerät auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. AWS-Managementkonsole Auf dieser Seite werden Konto- und Benutzerinformationen angezeigt, aber der Benutzer kann nur sein eigenes MFA-Gerät anzeigen und bearbeiten. Informationen darüber, wie Benutzern die Verwaltung aller ihrer eigenen Anmeldeinformationen mit MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md).
**Anmerkung**
Wenn ein IAM-Benutzer mit dieser Richtlinie nicht MFA-authentifiziert ist, verweigert diese Richtlinie den Zugriff auf alle AWS Aktionen außer denen, die für die Authentifizierung mit MFA erforderlich sind. Um die AWS CLI AWS AND-API verwenden zu können, müssen IAM-Benutzer zuerst ihr MFA-Token mithilfe des AWS STS [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html)Vorgangs abrufen und dann dieses Token verwenden, um den gewünschten Vorgang zu authentifizieren. Andere Richtlinien, wie zum Beispiel ressourcenbasierte Richtlinien oder andere identitätsbasierte Richtlinien, können Aktionen in anderen Services erlauben. Diese Richtlinie verweigert den Zugriff, wenn der IAM-Benutzer nicht per MFA authentifiziert wurde.
Informationen dazu, wie Benutzer auf die Seite **Sicherheits-Anmeldeinformationen** zugreifen können, finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**Was macht diese Richtlinie?**
+ Die Anweisung `AllowViewAccountInfo` erlaubt dem Benutzer das Anzeigen von Details zu einem virtuellen MFA-Gerät, das für den Benutzer aktiviert ist. Diese Berechtigung muss als eigene Anweisung vorliegen, da sie nicht die Angabe eines Ressourcen-ARN unterstützt. Stattdessen müssen Sie `"Resource" : "*"` angeben.
+ Die `AllowManageOwnVirtualMFADevice`-Anweisung ermöglicht dem Benutzer das Erstellen seines eigenen virtuellen MFA-Geräts. Der Ressourcen-ARN in dieser Anweisung erlaubt es dem Benutzer, ein MFA-Gerät mit einem beliebigen Namen zu erstellen, aber die anderen Anweisungen in der Richtlinie erlauben es dem Benutzer nur, das Gerät mit dem aktuell angemeldeten Benutzer zu verknüpfen.
+ Die `AllowManageOwnUserMFA`-Anweisung ermöglicht es dem Benutzer, sein eigenes virtuelles, U2F- oder physisches MFA-Gerät anzuzeigen oder zu verwalten. Der Ressourcen-ARN in dieser Anweisung gewährt nur Zugriff auf den eigenen IAM-Benutzer des Benutzers. Benutzer können das MFA-Gerät für andere Benutzer nicht anzeigen oder verwalten.
+ Die `DenyAllExceptListedIfNoMFA` Anweisung verweigert den Zugriff auf alle Aktionen in allen AWS Diensten, mit Ausnahme einiger aufgelisteter Aktionen, jedoch ***nur, wenn*** der Benutzer nicht mit MFA angemeldet ist. Die Anweisung verwendet eine Kombination aus `"Deny"` und `"NotAction"`, um den Zugriff auf alle Aktionen, die nicht aufgeführt sind, explizit zu verwehren. Die aufgeführten Elemente werden durch diese Anweisung nicht verweigert oder zugelassen. Die Aktionen werden aber durch andere Anweisungen in der Richtlinie zugelassen. Weitere Informationen zur Logik dieser Anweisung finden Sie unter [NotAction with](reference_policies_elements_notaction.md) Deny. Hat sich der Benutzer mit MFA angemeldet, schlägt der `Condition`-Test fehl und diese Anweisung verwehrt keine Aktionen. In diesem Fall bestimmen andere Richtlinien oder Anweisungen für den Benutzer die Berechtigungen des Benutzers.
Durch diese Anweisung wird sichergestellt, dass der Benutzer, wenn er nicht mit MFA angemeldet ist, nur die aufgeführten Aktionen ausführen kann. Außerdem kann er die aufgelisteten Aktionen nur ausführen, wenn eine andere Anweisung oder Richtlinie den Zugriff auf diese Aktionen gewährt.
Die `...IfExists`-Version des `Bool` -Operators stellt sicher, dass bei fehlendem `aws:MultiFactorAuthPresent`-Schlüssel die Bedingung den Wert "True" zurückgibt. Dies bedeutet, dass einem Benutzer, der mit langfristigen Anmeldeinformationen auf eine API-Operation zugreift, wie z. B. einem Zugriffsschlüssel, der Zugriff auf die Nicht-IAM-API-Operationen verweigert wird.
Diese Richtlinie ermöglicht es Benutzern nicht, die Seite **Users (Benutzer)** in der IAM-Konsole anzuzeigen oder diese Seite für den Zugriff auf ihre eigenen Benutzerinformationen zu verwenden. Um dies zuzulassen, fügen Sie die Aktion `iam:ListUsers` der Anweisung `AllowViewAccountInfo` und der Anweisung `DenyAllExceptListedIfNoMFA` hinzu.
**Warnung**
Erlauben Sie nicht das Löschen eines MFA-Geräts ohne MFA-Authentifizierung. Benutzer mit dieser Richtlinie könnten möglicherweise versuchen, sich selbst ein virtuelles MFA-Gerät zuzuweisen und eine Fehlermeldung erhalten, da sie zur Ausführung von `iam:DeleteVirtualMFADevice` nicht berechtigt sind. Wenn dies der Fall ist, fügen Sie diese Berechtigung **nicht** zur `DenyAllExceptListedIfNoMFA`-Anweisung hinzu. Benutzer, die nicht über MFA authentifiziert wurden, sollten niemals zum Löschen Ihres MFA-Geräts berechtigt werden. Benutzern könnte diese Fehlermeldung angezeigt werden, wenn sie damit begonnen haben, ein virtuelles MFA-Gerät zu ihrem Benutzer zuzuweisen und den Prozess abgebrochen haben. Um dieses Problem zu beheben, müssen Sie oder ein anderer Administrator das vorhandene virtuelle MFA-Gerät des Benutzers mithilfe der AWS API AWS CLI oder löschen. Weitere Informationen finden Sie unter [Ich bin nicht berechtigt, Folgendes aufzuführen: iam: DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": "iam:ListVirtualMFADevices",
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/*"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:GetMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
}
}
]
}
```
------
# AWS: Ermöglicht es IAM-Benutzern, ihr eigenes Konsolenpasswort auf der Seite Sicherheits-Anmeldeinformationen zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die es IAM-Benutzern ermöglicht, ihr eigenes AWS-Managementkonsole Passwort auf der Seite **Sicherheitsanmeldedaten** zu ändern. AWS-Managementkonsole Auf dieser Seite werden Konto- und Benutzerinformationen angezeigt, aber der Benutzer kann nur auf sein eigenes Passwort zugreifen. Informationen darüber, wie Benutzern die Verwaltung aller ihrer eigenen Anmeldeinformationen mit MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md). Informationen darüber, wie Benutzern die Verwaltung ihrer eigenen Anmeldeinformationen ohne MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht IAM-Benutzern, ihre eigenen Anmeldeinformationen auf der Seite „Sicherheits-Anmeldeinformationen“ zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md).
Informationen dazu, wie Benutzer auf die Seite **Sicherheits-Anmeldeinformationen** zugreifen können, finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**Was macht diese Richtlinie?**
+ Die Anweisung `ViewAccountPasswordRequirements` ermöglicht es dem Benutzer, die Passwortanforderungen des Kontos beim Ändern seines eigenen IAM-Benutzer-Passworts anzuzeigen.
+ Mit der `ChangeOwnPassword`-Anweisung kann der Benutzer sein eigenes Passwort ändern. Diese Anweisung enthält auch die `GetUser`-Aktion, die erforderlich ist, um die meisten Informationen auf der Seite **My Security Credentials (Meine Sicherheitsanmeldeinformationen)** anzuzeigen.
Diese Richtlinie ermöglicht es Benutzern nicht, die Seite **Users (Benutzer)** in der IAM-Konsole anzuzeigen oder diese Seite für den Zugriff auf ihre eigenen Benutzerinformationen zu verwenden. Um dies zu ermöglichen, fügen Sie die Aktion `iam:ListUsers` zur Anweisung `ViewAccountPasswordRequirements` hinzu. Darüber hinaus ermöglicht sie Benutzern nicht, ihr Passwort auf ihrer eigenen Benutzerseite anzupassen. Um dies zu ermöglichen, fügen Sie die Aktionen `iam:GetLoginProfile` und `iam:UpdateLoginProfile` zur Anweisung `ChangeOwnPasswords` hinzu.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewAccountPasswordRequirements",
"Effect": "Allow",
"Action": "iam:GetAccountPasswordPolicy",
"Resource": "*"
},
{
"Sid": "ChangeOwnPassword",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:ChangePassword"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
```
------
# AWS: Ermöglicht es IAM-Benutzern, ihr eigenes Passwort sowie ihre eigenen Zugriffsschlüssel und öffentlichen SSH-Schlüssel auf der Seite Sicherheits-Anmeldeinformationen zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern erlaubt, ihr eigenes Passwort, ihre eigenen Zugriffsschlüssel und X.509-Zertifikate auf der Seite **Sicherheits-Anmeldeinformationen** zu verwalten. Diese Seite der AWS-Managementkonsole zeigt Kontoinformationen wie z. B. die Konto-ID und die kanonische Benutzer-ID an. Benutzer können auch ihre eigenen Passwörter, Zugriffsschlüssel, MFA-Geräte, X.509-Zertifikate, SSH-Schlüssel und Git-Anmeldeinformationen anzeigen und bearbeiten. Diese Beispielrichtlinie enthält die Berechtigungen, die erforderlich sind, um nur ihr Passwort, ihre Zugriffsschlüssel und ihr X.509-Zertifikat anzuzeigen. Informationen darüber, wie Benutzern die Verwaltung aller ihrer eigenen Anmeldeinformationen mit MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht es MFA-authentifizierten IAM-Benutzern, ihr eigenen Anmeldeinformationen auf der Seite Sicherheits-Anmeldeinformationen zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage.md). Informationen darüber, wie Benutzern die Verwaltung ihrer eigenen Anmeldeinformationen ohne MFA ermöglicht wird, finden Sie unter [AWS: Ermöglicht IAM-Benutzern, ihre eigenen Anmeldeinformationen auf der Seite „Sicherheits-Anmeldeinformationen“ zu verwalten](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md).
Informationen dazu, wie Benutzer auf die Seite **Sicherheits-Anmeldeinformationen** zugreifen können, finden Sie unter [Wie IAM-Benutzer ihr eigenes Passwort ändern können (Konsole)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**Was macht diese Richtlinie?**
+ Die `AllowViewAccountInfo`-Anweisung ermöglicht es dem Benutzer, Informationen auf Kontoebene anzuzeigen. Diese Berechtigungen müssen in ihrer eigenen Anweisung vorliegen, da sie keine Ressourcen-ARN unterstützen oder keine angeben müssen. Geben Sie anstelle von Berechtigungen `"Resource" : "*"` ein. Diese Anweisung enthält die folgenden Aktionen, mit denen der Benutzer spezifische Informationen anzeigen kann:
+ `GetAccountPasswordPolicy` – Zeigt die Passwortanforderungen des Kontos beim Ändern seines eigenen IAM-Benutzer-Passworts an.
+ `GetAccountSummary` – Zeigt die Konto-ID und die [kanonische Benutzer-ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) des Kontos an.
+ Mit der `AllowManageOwnPasswords`-Anweisung kann der Benutzer sein eigenes Passwort ändern. Diese Anweisung enthält auch die `GetUser`-Aktion, die erforderlich ist, um die meisten Informationen auf der Seite **My Security Credentials (Meine Sicherheitsanmeldeinformationen)** anzuzeigen.
+ Die `AllowManageOwnAccessKeys`-Anweisung ermöglicht dem Benutzer das Erstellen, Aktualisieren und Löschen seiner eigenen Zugriffsschlüssel. Der Benutzer kann auch Informationen darüber abrufen, wann der angegebene Zugriffsschlüssel zuletzt verwendet wurde.
+ Die `AllowManageOwnSSHPublicKeys`-Anweisung ermöglicht dem Benutzer das Hochladen, Aktualisieren und Löschen seiner eigenen öffentlichen SSH-Schlüssel für CodeCommit.
Diese Richtlinie erlaubt es Benutzern nicht, ihre eigenen MFA-Geräte anzuzeigen oder zu verwalten. Außerdem können sie die Seite **Users (Benutzer)** in der IAM-Konsole nicht anzuzeigen oder für den Zugriff auf ihre eigenen Benutzerinformationen verwenden. Um dies zu ermöglichen, fügen Sie die Aktion `iam:ListUsers` zur Anweisung `AllowViewAccountInfo` hinzu. Darüber hinaus ermöglicht sie Benutzern nicht, ihr Passwort auf ihrer eigenen Benutzerseite anzupassen. Um dies zu ermöglichen, fügen Sie die Aktionen `iam:GetLoginProfile` und `iam:UpdateLoginProfile` zur Anweisung `AllowManageOwnPasswords` hinzu.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:GetAccountSummary"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:GetAccessKeyLastUsed"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
```
------
# AWS: Verweigert den Zugriff auf AWS basierend auf der angeforderten Region
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Zugriff auf alle Aktionen außerhalb der mit dem [`aws:RequestedRegion`-Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion) angegebenen Regionen verweigert, mit Ausnahme der Aktionen in den mit `NotAction` angegebenen Services. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Diese Richtlinie verwendet das `NotAction`-Element mit dem `Deny`-Effekt, der explizit den Zugriff auf alle Aktionen verweigert, die *nicht* in der Anweisung aufgeführt sind. Aktionen in den CloudFront, IAM, Route 53 und Support Diensten sollten nicht verweigert werden, da es sich dabei um beliebte AWS globale Dienste mit einem einzigen Endpunkt handelt, der sich physisch in der `us-east-1` Region befindet. Da alle Anforderungen an diese Services an die Region `us-east-1` gerichtet werden, würden die Anforderungen ohne das `NotAction`-Element verweigert werden. Bearbeiten Sie dieses Element, um Aktionen für andere globale AWS -Services einzuschließen, die Sie verwenden, beispielsweise `budgets`, `globalaccelerator`, `importexport`, `organizations` oder `waf`. Einige andere globale Dienste, wie Amazon Q Developer in Chat-Anwendungen und AWS Device Farm, sind globale Dienste mit Endpunkten, die sich physisch in der `us-west-2` Region befinden. Weitere Informationen zu allen Services mit einem einzigen globalen Endpunkt finden Sie unter [AWS -Regionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html) in der *Allgemeine AWS-Referenz*. Weitere Informationen zur Verwendung des `NotAction`-Elements mit dem `Deny`-Effekt finden Sie unter [IAM-JSON-Richtlinienelemente: NotAction](reference_policies_elements_notaction.md).
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideRequestedRegions",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"organizations:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1",
"eu-west-1",
"eu-west-2",
"eu-west-3"
]
}
}
}
]
}
```
------
# AWS: Verweigert den Zugriff auf AWS basierend auf der Quell-IP
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die den Zugriff auf alle AWS Aktionen im Konto verweigert, wenn die Anfrage von *Principals* außerhalb des angegebenen IP-Bereichs kommt. Die Richtlinie ist nützlich, wenn die IP-Adressen für Ihre Firma innerhalb der angegebenen Bereiche liegen. In diesem Beispiel wird die Anfrage abgelehnt, sofern sie nicht aus dem CIDR-Bereich 192.0.2.0/24 oder 203.0.113.0/24 stammt. Die Richtlinie lehnt Anfragen von AWS Diensten nicht ab, [Forward Access Sessions (FAS)](access_forward_access_sessions.md) da die IP-Adresse des ursprünglichen Anforderers beibehalten wird.
Seien Sie vorsichtig mit negativen Bedingungen in der gleichen Richtlinienaussage wie `"Effect": "Deny"`. Wenn Sie dies tun, werden die in der Richtlinienanweisung angegebenen Aktionen unter allen Bedingungen explizit verweigert, *mit Ausnahme* der angegebenen.
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
Wenn andere Richtlinien Aktionen zulassen, können Auftraggeber Anforderungen innerhalb des IP-Adressbereichs ausgeben. Ein AWS Dienst kann auch Anfragen mit den Anmeldeinformationen des Prinzipals stellen. Wenn ein Auftraggeber eine Anforderung außerhalb des IP-Bereichs ausgibt, wird die Anforderung abgelehnt.
Weitere Informationen über die Verwendung des Bedingungsschlüssels `aws:SourceIp`, einschließlich Informationen darüber, wann `aws:SourceIp` in Ihrer Richtlinie vielleicht nicht funktioniert, finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
}
}
}
}
```
------
# AWS: Verweigern Sie den Zugriff auf Amazon S3 S3-Ressourcen außerhalb Ihres Kontos, außer AWS Data Exchange
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die den Zugriff auf alle Ressourcen verweigert AWS , die nicht zu Ihrem Konto gehören, mit Ausnahme der Ressourcen, die für den normalen Betrieb AWS Data Exchange erforderlich sind. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Sie können eine ähnliche Richtlinie erstellen, um den Zugriff auf Ressourcen innerhalb einer Organisation oder einer Organisationseinheit einzuschränken und gleichzeitig AWS Data Exchange eigene Ressourcen mithilfe der Bedingungsschlüssel `aws:ResourceOrgPaths` und zu berücksichtigen`aws:ResourceOrgID`.
Wenn Sie den Service AWS Data Exchange in Ihrer Umgebung verwenden, erstellt er Ressourcen wie Amazon S3 S3-Buckets, die dem Servicekonto gehören, und interagiert mit diesen. AWS Data Exchange Sendet beispielsweise Anfragen an Amazon S3 S3-Buckets, die dem AWS Data Exchange Service gehören, im Namen des IAM-Prinzipals (Benutzer oder Rolle), der den aufruft. AWS Data Exchange APIs In diesem Fall wird durch die Verwendung von `aws:ResourceAccount` oder `aws:ResourceOrgID` in einer Richtlinie ohne Berücksichtigung AWS Data Exchange eigener Ressourcen der Zugriff auf die Buckets verweigert, die dem Servicekonto gehören. `aws:ResourceOrgPaths`
+ Die Anweisung, `DenyAllAwsResourcesOutsideAccountExceptS3`, benutzt das `NotAction`-Element mit dem [Deny](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html)-Effekt, der explizit den Zugriff auf jede Aktion verweigert, die nicht in der Anweisung aufgeführt ist und die auch nicht zum aufgelisteten Konto gehört. Das `NotAction`-Element gibt die Ausnahmen zu dieser Anweisung an. Diese Aktionen bilden die Ausnahme von dieser Aussage, denn wenn die Aktionen für Ressourcen ausgeführt werden, die von erstellt wurden AWS Data Exchange, werden sie von der Richtlinie verweigert.
+ Die Anweisung, `DenyAllS3ResoucesOutsideAccountExceptDataExchange`, verwendet eine Kombination aus den `ResourceAccount`- und `CalledVia`-Bedingungen, um den Zugriff auf die drei Amazon-S3-Aktionen zu verweigern, die in der vorherigen Anweisung ausgeschlossen wurden. Die Anweisung lehnt die Aktionen ab, wenn Ressourcen nicht in das aufgelistete Konto gehören und wenn der aufrufende Service nicht AWS Data Exchange ist. Die Anweisung verweigert die Aktionen nicht, wenn entweder die Ressource dem aufgelisteten Konto gehört oder der aufgelistete Service-Prinzipal, `dataexchange.amazonaws.com`, die Vorgänge durchführt.
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Sie verwendet den `Deny`-Effekt, der ausdrücklich den Zugriff auf alle in der Anweisung aufgeführten Ressourcen verweigert, die nicht zu dem aufgeführten Konto gehören. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die den Zugriff auf bestimmte Ressourcen gewähren.
Das folgende Beispiel zeigt, wie Sie die Richtlinie konfigurieren können, um den Zugriff auf die erforderlichen Amazon-S3-Buckets zu ermöglichen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAllAwsReourcesOutsideAccountExceptAmazonS3",
"Effect": "Deny",
"NotAction": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
}
}
},
{
"Sid": "DenyAllS3ResourcesOutsideAccountExceptDataExchange",
"Effect": "Deny",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
},
"ForAllValues:StringNotEquals": {
"aws:CalledVia": [
"dataexchange.amazonaws.com"
]
}
}
}
]
}
```
------
# AWS Data Pipeline: Verweigert den Zugriff auf DataPipeline Pipelines, die ein Benutzer nicht erstellt hat
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Zugriff auf Pipelines verweigert, die ein Benutzer nicht erstellt hat. Wenn der Wert des `PipelineCreator`-Feldes dem IAM-Benutzernamen entspricht, dann werden die angegebenen Aktionen nicht verweigert. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die API oder durchzuführen. AWS AWS CLI
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExplicitDenyIfNotTheOwner",
"Effect": "Deny",
"Action": [
"datapipeline:ActivatePipeline",
"datapipeline:AddTags",
"datapipeline:DeactivatePipeline",
"datapipeline:DeletePipeline",
"datapipeline:DescribeObjects",
"datapipeline:EvaluateExpression",
"datapipeline:GetPipelineDefinition",
"datapipeline:PollForTask",
"datapipeline:PutPipelineDefinition",
"datapipeline:QueryObjects",
"datapipeline:RemoveTags",
"datapipeline:ReportTaskProgress",
"datapipeline:ReportTaskRunnerHeartbeat",
"datapipeline:SetStatus",
"datapipeline:SetTaskStatus",
"datapipeline:ValidatePipelineDefinition"
],
"Resource": ["*"],
"Condition": {
"StringNotEquals": {"datapipeline:PipelineCreator": "${aws:userid}"}
}
}
]
}
```
------
# Amazon DynamoDB: Gewährt Zugriff auf eine bestimmte Tabelle
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die den vollen Zugriff auf die `MyTable`-DynamoDB-Tabelle erlaubt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
**Wichtig**
Diese Richtlinie lässt alle Aktionen zu, die für eine DynamoDB-Tabelle ausgeführt werden können. Eine Übersicht über diese Aktionen finden Sie unter [DynamoDB-API-Berechtigungen: Aktionen Ressourcen und Bedingungen Leitfaden](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/api-permissions-reference.html) im* Amazon DynamoDB Developer Guide*. Sie könnten dieselben Berechtigungen bereitstellen, indem Sie jede einzelne Aktion aufführen. Wenn Sie jedoch den Platzhalter (`*`) im `Action`-Element verwenden, z. B. `"dynamodb:List*"`, dann müssen Sie Ihre Richtlinie nicht aktualisieren, wenn DynamoDB eine neue List-Aktion hinzufügt.
Diese Richtlinie lässt Aktionen nur für die DynamoDB-Tabellen zu, die mit dem angegebenen Namen vorhanden sind. Um Ihren Benutzern `Read` Zugriff auf alles in DynamoDB zu gewähren, können Sie auch die [AmazonDynamoDBReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess) AWS verwaltete Richtlinie anhängen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListAndDescribe",
"Effect": "Allow",
"Action": [
"dynamodb:List*",
"dynamodb:DescribeReservedCapacity*",
"dynamodb:DescribeLimits",
"dynamodb:DescribeTimeToLive"
],
"Resource": "*"
},
{
"Sid": "SpecificTable",
"Effect": "Allow",
"Action": [
"dynamodb:BatchGet*",
"dynamodb:DescribeStream",
"dynamodb:DescribeTable",
"dynamodb:Get*",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWrite*",
"dynamodb:CreateTable",
"dynamodb:Delete*",
"dynamodb:Update*",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/MyTable"
}
]
}
```
------
# Amazon DynamoDB: Ermöglicht den Zugriff auf bestimmte Attribute
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Zugriff auf die spezifischen DynamoDB-Attribute erlaubt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die Anforderung `dynamodb:Select` verhindert, dass die API-Aktion jegliche Attribute, die nicht zulässig sind, zurückgibt, z. B. von einer Indexprojektion. Weitere Informationen zu DynamoDB-Bedingungsschlüsseln finden Sie unter [Specifying Conditions: Using Condition Keys](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html#FGAC_DDB.ConditionKeys) im *Amazon DynamoDB Developer Guide*. Weitere Informationen zum Verwenden mehrerer Bedingungen oder mehrerer Bedingungsschlüssel innerhalb eines `Condition`-Blocks einer IAM-Richtlinie finden Sie unter [Mehrere Werte in einer Bedingung](reference_policies_elements_condition.md#Condition-multiple-conditions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem"
],
"Resource": ["arn:aws:dynamodb:*:*:table/table-name"],
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:Attributes": [
"column-name-1",
"column-name-2",
"column-name-3"
]
},
"StringEqualsIfExists": {"dynamodb:Select": "SPECIFIC_ATTRIBUTES"}
}
}
]
}
```
------
# Amazon DynamoDB: Ermöglicht den Zugriff auf DynamoDB auf Elementebene basierend auf einer Amazon Cognito ID
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Zugriff auf Elementebene auf die `MyTable`-DynamoDB-Tabelle anhand einer Amazon-Cognito-Identitätspool-ID ermöglicht. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Um diese Richtlinie nutzen zu können, müssen Sie die DynamoDB-Tabelle so strukturieren, dass die Identitätspool-Benutzer-ID für Amazon Cognito der Partitionsschlüssel ist. Weitere Informationen finden Sie unter [Erstellen eeiner Tabelle](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.CreateTable) im *Amazon DynamoDB Developer Guide*.
Weitere Informationen zu DynamoDB-Bedingungsschlüsseln finden Sie unter [Specifying Conditions: Using Condition Keys](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html#FGAC_DDB.ConditionKeys) im *Amazon DynamoDB Developer Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:Query",
"dynamodb:UpdateItem"
],
"Resource": ["arn:aws:dynamodb:*:*:table/MyTable"],
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
}
}
}
]
}
```
------
# Amazon EC2: Anfügen von Amazon EBS-Volumes anhand von Tags an EC2-Instances oder Trennen dieser Volumes
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es Besitzern von EBS-Volumes erlaubt, ihre mit dem Tag `VolumeUser` definierten EBS-Volumes an EC2-Instances anzufügen oder zu entfernen, die als Entwicklungs-Instances (`Department=Development`) gekennzeichnet sind. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Weitere Informationen zum Erstellen von IAM-Richtlinien zur [Steuerung des Zugriffs auf Amazon-EC2-Ressourcen finden Sie unter Steuerung des Zugriffs auf Amazon-EC2-Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html) im *Amazon-EC2-Benutzerhandbuch*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {"aws:ResourceTag/Department": "Development"}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
"StringEquals": {"aws:ResourceTag/VolumeUser": "${aws:username}"}
}
}
]
}
```
------
# Amazon EC2: Ermöglicht es, EC2-Instances in einem bestimmten Subnetz programmgesteuert und in der Konsole zu starten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Auflisten von Informationen für alle EC2-Objekte und das Launchen von EC2-Instances in einem bestimmten Subnetz erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:GetConsole*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*:*:subnet/subnet-subnet-id",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:security-group/*"
]
}
]
}
```
------
# Amazon EC2: Ermöglicht es, die mit einem bestimmten Tag-Schlüsselwertpaar verknüpfte EC2-Sicherheitsgruppen programmgesteuert und in der Konsole zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die Benutzern die Berechtigung erteilt, bestimmte Aktionen für Sicherheitsgruppen mit demselben Tag durchzuführen. Die folgende Richtlinie erteilt die Berechtigung, Sicherheitsgruppen in der Amazon-EC2-Konsole anzuzeigen, Regeln für ein- und ausgehenden Datenverkehr hinzuzufügen und zu entfernen und Regelbeschreibungen für vorhandene Sicherheitsgruppen, die über das `Department=Test`-Tag verfügen, aufzulisten und zu ändern. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:ModifySecurityGroupRules",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Department": "Test"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySecurityGroupRules"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:security-group-rule/*"
]
}
]
}
```
------
# Amazon EC2: Ermöglicht es, die von einem Benutzer markierten EC2-Instances programmgesteuert und in der Konsole zu starten oder zu stoppen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es einem IAM-Benutzer erlaubt, EC2-Instances zu starten oder zu stoppen, jedoch nur wenn das Instance-Tag `Owner` den Wert des Benutzernamens dieses Benutzers hat. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
}
```
------
# EC2: Instances basierend auf Tags starten oder stoppen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Starten oder Stoppen von Instances mit dem Tag-Schlüssel-Wert-Paar `Project = DataAnalytics` erlaubt, aber nur durch Prinzipale mit dem Tag-Schlüssel-Wert-Paar `Department = Data`. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder durchzuführen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die Bedingung in der Richtlinie gibt "true" zurück, wenn beide Teile der Bedingung erfüllt sind. Die Instance muss das `Project=DataAnalytics`-Tag aufweisen. Darüber hinaus muss der IAM-Auftraggeber (Benutzer oder Rolle), von dem die Anforderung stammt, über das `Department=Data`-Tag verfügen.
**Anmerkung**
Als bewährte Methode können Sie Richtlinien mit dem `aws:PrincipalTag`-Bedingungsschlüssel an IAM-Gruppen anfügen, für den Fall, dass einige Benutzer das angegebene Tag haben und andere nicht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StartStopIfTags",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "DataAnalytics",
"aws:PrincipalTag/Department": "Data"
}
}
}
]
}
```
------
# EC2: Starten oder Stoppen von Instances basierend auf übereinstimmenden Auftraggeber- und Ressourcen-Tags
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es einem Prinzipal erlaubt, eine Amazon-EC2-Instance zu starten oder zu stoppen, wenn das Ressourcen-Tag der Instance und das Tag des Prinzipals denselben Wert für den Tag-Schlüssel `CostCenter` haben. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder durchzuführen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
**Anmerkung**
Als bewährte Methode können Sie Richtlinien mit dem `aws:PrincipalTag`-Bedingungsschlüssel an IAM-Gruppen anfügen, für den Fall, dass einige Benutzer das angegebene Tag haben und andere nicht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"ec2:startInstances",
"ec2:stopInstances"
],
"Resource": "*",
"Condition": {"StringEquals":
{"aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"}}
}
}
```
------
# Amazon EC2: Gewährt EC2-Vollzugriff innerhalb einer bestimmten Region programmatisch und in der Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die vollen EC2-Zugriff innerhalb einer bestimmten Region erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md). Eine Liste der Regionscodes finden Sie unter [Verfügbare Regionen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions) im *Amazon EC2 Leitfaden*.
Alternativ können Sie den globalen Bedingungsschlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion) verwenden, der von allem Amazon EC2-API-Aktionen unterstützt wird. Weitere Informationen finden Sie unter [Beispiel: Einschränken des Zugriffs auf eine bestimmte Region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region) im *Amazon EC2 Leitfaden*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Resource": "*",
"Effect": "Allow",
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-2"
}
}
}
]
}
```
------
# Amazon EC2: Ermöglicht das Starten oder Beenden einer EC2-Instance und das Ändern einer Sicherheitsgruppe (programmatisch und in der Konsole)
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Starten oder Beenden einer bestimmten EC2-Instance und das Ändern einer bestimmten Sicherheitsgruppe erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeStaleSecurityGroups"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/i-instance-id",
"arn:aws:ec2:*:*:security-group/sg-security-group-id"
],
"Effect": "Allow"
}
]
}
```
------
# Amazon EC2: Erfordert MFA (GetSessionToken) für bestimmte EC2-Operationen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die vollen Zugriff auf alle AWS API-Operationen in Amazon EC2 ermöglicht. Dabei wird jedoch explizit der Zugriff auf die API-Operationen `StopInstances` und `TerminateInstances` verweigert, wenn der Benutzer nicht über die [Multi-Factor Authentication (MFA)](id_credentials_mfa.md) authentifiziert wurde. Um dies programmgesteuert durchzuführen, muss der Benutzer optionale `SerialNumber`- und `TokenCode`-Werte beim Aufruf der `GetSessionToken`-Operation einschließen. Diese Operation gibt temporäre Anmeldeinformationen zurück, die per MFA authentifiziert wurden. Weitere Informationen GetSessionToken dazu finden Sie unter. [Anfordern von Anmeldeinformationen für Benutzer in nicht vertrauenswürdigen Umgebungen](id_credentials_temp_request.md#api_getsessiontoken)
Was macht diese Richtlinie?
+ Durch die `AllowAllActionsForEC2`-Anweisung werden alle Amazon EC2-Aktionen gewährt.
+ Die `DenyStopAndTerminateWhenMFAIsNotPresent`-Anweisung verweigert die Aktionen `TerminateInstances` und `StopInstances`, wenn der MFA-Kontext fehlt. Das bedeutet, dass die Aktionen verweigert werden, wenn der MFA-Kontext fehlt (also keine MFA stattgefunden hat). Eine Verweigerung überschreibt mögliche Berechtigungen.
**Anmerkung**
Für die Bedingungsprüfung für `MultiFactorAuthPresent` in der `Deny`-Anwendung sollte nicht `{"Bool":{"aws:MultiFactorAuthPresent":false}}` verwendet werden, da der Schlüssel nicht vorhanden ist und auch nicht ausgewertet werden kann, wenn keine MFA verwendet wird. Verwenden Sie stattdessen die Prüfung `BoolIfExists`, um zu sehen, ob der Schlüssel vorhanden ist, bevor Sie den Wert prüfen. Weitere Informationen finden Sie unter [... IfExists Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_IfExists).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAllActionsForEC2",
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
},
{
"Sid": "DenyStopAndTerminateWhenMFAIsNotPresent",
"Effect": "Deny",
"Action": [
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {"aws:MultiFactorAuthPresent": false}
}
}
]
}
```
------
# Amazon EC2: Beschränkt das Beenden von EC2-Instances auf einen IP-Adressbereich
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die EC2-Instances einschränkt, indem sie die Aktion zulässt, aber den Zugriff ausdrücklich verweigert, wenn die Anforderung von außerhalb des angegebenen IP-Bereichs kommt. Die Richtlinie ist nützlich, wenn die IP-Adressen für Ihre Firma innerhalb der angegebenen Bereiche liegen. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Wenn diese Richtlinie in Kombination mit anderen Richtlinien verwendet wird, die die `ec2:TerminateInstances` Aktion zulassen (z. B. der von [Amazon EC2 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) AWS verwalteten Richtlinie), wird der Zugriff verweigert. Der Grund hierfür liegt darin, dass eine explizite Zugriffsverweigerung Vorrang vor einer Zugriffserlaubnis hat. Weitere Informationen finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md).
**Wichtig**
Der `aws:SourceIp` Bedingungsschlüssel verweigert den Zugriff auf eine AWS-Service, z. B. AWS CloudFormation, die in Ihrem Namen Anrufe tätigt. Weitere Informationen zum Verwenden des `aws:SourceIp`-Bedingungsschlüssels finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ec2:TerminateInstances"],
"Resource": ["*"]
},
{
"Effect": "Deny",
"Action": ["ec2:TerminateInstances"],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
}
},
"Resource": ["*"]
}
]
}
```
------
# IAM: Zugriff auf die Richtliniensimulator-API
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Verwendung der Richtliniensimulator-API für Richtlinien erlaubt, die an einen Benutzer, eine Gruppe oder eine Rolle im aktuellen AWS-Konto angefügt sind. Diese Richtlinie ermöglicht auch den Zugriff auf weniger sensible Richtlinien, die als Zeichenfolgen an die API übergeben werden. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetContextKeysForCustomPolicy",
"iam:GetContextKeysForPrincipalPolicy",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
**Anmerkung**
Informationen darüber, wie ein Benutzer auf die Richtliniensimulator-Konsole zugreifen kann, um Richtlinien zu simulieren, die einem Benutzer, einer Gruppe oder einer Rolle in der aktuellen Version zugewiesen sind AWS-Konto, finden Sie unter. [IAM: Zugriff auf die Richtliniensimulator-Konsole](reference_policies_examples_iam_policy-sim-console.md)
# IAM: Zugriff auf die Richtliniensimulator-Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Verwendung der Richtliniensimulator-Konsole für Richtlinien erlaubt, die an einen Benutzer, einer Gruppe oder einer Rolle im aktuellen AWS-Konto angefügt sind. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI
[Sie können auf die IAM Policy Simulator-Konsole zugreifen unter:/https://policysim.aws.amazon.com](https://policysim.aws.amazon.com/)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetGroup",
"iam:GetGroupPolicy",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListGroups",
"iam:ListGroupPolicies",
"iam:ListGroupsForUser",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:ListUserPolicies",
"iam:ListUsers"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# IAM: Übernehmen von Rollen, die ein bestimmtes Tag haben
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es einem IAM-Benutzer erlaubt, Rollen mit dem Tag-Schlüssel-Wert-Paar `Project = ExampleCorpABC` anzunehmen. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Wenn eine Rolle mit diesem Tag im selben Konto wie der Benutzer vorhanden ist, kann der Benutzer diese Rolle übernehmen. Wenn eine Rolle mit diesem Tag in einem anderen Konto als dem Konto des Benutzers vorhanden ist, sind zusätzliche Berechtigungen erforderlich. Die Vertrauensrichtlinie der kontoübergreifenden Rolle muss dem Benutzer oder allen Mitgliedern des Benutzerkontos erlauben, diese Rolle zu übernehmen. Weitere Informationen zum Verwenden von Rollen für den kontoübergreifenden Zugriff finden Sie unter [Zugriff für einen IAM-Benutzer in einem anderen AWS-Konto , den Sie besitzen](id_roles_common-scenarios_aws-accounts.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeTaggedRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals": {"iam:ResourceTag/Project": "ExampleCorpABC"}
}
}
]
}
```
------
# IAM: Ermöglicht und verweigert den Zugriff auf verschiedene Services, sowohl programmgesteuert als auch über die Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die einen vollständigen Zugriff auf verschiedene Services und begrenzten selbstverwaltenden Zugriff in IAM erlaubt. Verweigert Benutzern den Zugriff auf den Amazon S3 Protokoll-Bucket `logs` oder die `i-1234567890abcdef0`-Amazon EC2-Instance. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
**Warnung**
Diese Richtlinie ermöglicht den vollständigen Zugriff auf alle Aktionen und Ressourcen in verschiedenen Services. Diese Richtlinie sollte nur auf vertrauenswürdige Administratoren angewendet werden.
Sie können diese Richtlinien als Berechtigungsgrenze einsetzen, um die maximale Anzahl von Berechtigungen festzulegen, die eine identitätsbasierte Richtlinie einem IAM-Benutzer erteilen kann. Weitere Informationen finden Sie unter [Verantwortung mit Hilfe von Berechtigungsgrenzen an andere delegieren](access_policies_boundaries.md#access_policies_boundaries-delegate). Wenn die Richtlinie als Berechtigungsgrenze für einen Benutzer verwendet wird, wird durch die Anweisungen die folgende Grenze festgelegt:
+ Die `AllowServices`-Anweisung gewährt den angegebenen AWS -Services einen Vollzugriff. Dies bedeutet, dass die Aktionen eines Benutzers in diesen Services nur laut der Berechtigungsrichtlinien begrenzt sind, die dem Benutzer zugeordnet sind.
+ Die `AllowIAMConsoleForCredentials`-Anweisung erlaubt den Zugriff für das Auflisten aller IAM-Benutzer. Dieser Zugriff ist erforderlich, um auf der Seite **Users (Benutzer)** in der AWS-Managementkonsole navigieren zu können. Sie ermöglicht zudem das Anzeigen von Passwortanforderungen für das Konto. Dies ist erforderlich, damit der Benutzer sein eigenes Passwort ändern kann.
+ Mit der `AllowManageOwnPasswordAndAccessKeys`-Anweisung können die Benutzer nur ihr eigenes Konsolen-Passwort und programmatische Zugriffsschlüssel verwalten. Dies ist wichtig, denn wenn eine andere Richtlinie einem Benutzer einen vollständigen IAM-Zugriff gewährt, kann dieser Benutzer seine eigenen Berechtigungen oder die eines anderen Benutzers ändern. Diese Anweisung verhindert, dass dies passiert.
+ Die Anweisung `DenyS3Logs` verweigert explizit den Zugriff auf den `logs`-Bucket. Diese Richtlinie sorgt dafür, dass einem Benutzer Unternehmensbeschränkungen auferlegt werden.
+ Die Anweisung `DenyEC2Production` verweigert explizit den Zugriff auf die `i-1234567890abcdef0`-Instance.
Diese Richtlinie gewährt nicht den Zugriff auf andere Services oder Aktionen. Wenn die Richtlinie als Berechtigungsgrenze für einen Benutzer verwendet wird, wird die Anfrage AWS abgelehnt, auch wenn andere dem Benutzer zugeordnete Richtlinien diese Aktionen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowServices",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*"
],
"Resource": "*"
},
{
"Sid": "AllowIAMConsoleForCredentials",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswordAndAccessKeys",
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:ChangePassword",
"iam:GetUser",
"iam:*LoginProfile*"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::logs",
"arn:aws:s3:::logs/*"
]
},
{
"Sid": "DenyEC2Production",
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
}
]
}
```
------
# IAM: Hinzufügen eines bestimmten Tags zu einem Benutzer mit einem bestimmten Tag
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Hinzufügen des Tag-Schlüssels `Department` mit den Tag-Werten `Marketing`, `Development` oder `QualityAssurance` zu einem IAM-Benutzer erlaubt. Dieser Benutzer muss bereits das Tag-Schlüssel-Wert-Paar `JobFunction = manager` enthalten. Mit dieser Richtlinie können Sie festlegen, dass ein Manager nur zu einer von drei Abteilungen gehören kann. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Mit der `ListTagsForAllUsers`-Anweisung kann die Anzeige von Tags für alle Benutzer in Ihrem Konto erlaubt werden.
Die erste Bedingung in der `TagManagerWithSpecificDepartment`-Anweisung verwendet den `StringEquals`-Bedingungsoperator. Die Bedingung gibt "true" zurück, wenn beide Teile der Bedingung erfüllt sind. Der zu markierende Benutzer muss bereits über das `JobFunction=Manager`-Tag verfügen. Die Anforderung muss den `Department`-Tag-Schlüssel mit einem der aufgelisteten Tag-Werte aufweisen.
Die zweite Bedingung verwendet den `ForAllValues:StringEquals`-Bedingungsoperator. Die Bedingung gibt "true" zurück, wenn alle Tag-Schlüssel in der Anforderung mit dem Schlüssel in der Richtlinie übereinstimmen. Das bedeutet, dass der einzige Tag-Schlüssel in der Anforderung `Department` sein muss. Weitere Informationen zur Verwendung von `ForAllValues` finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListTagsForAllUsers",
"Effect": "Allow",
"Action": [
"iam:ListUserTags",
"iam:ListUsers"
],
"Resource": "*"
},
{
"Sid": "TagManagerWithSpecificDepartment",
"Effect": "Allow",
"Action": "iam:TagUser",
"Resource": "*",
"Condition": {"StringEquals": {
"iam:ResourceTag/JobFunction": "Manager",
"aws:RequestTag/Department": [
"Marketing",
"Development",
"QualityAssurance"
]
},
"ForAllValues:StringEquals": {"aws:TagKeys": "Department"}
}
}
]
}
```
------
# IAM: Hinzufügen eines bestimmten Tags mit bestimmten Werten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die nur das Hinzufügen des Tag-Schlüssels `CostCenter` und entweder des Tag-Werts `A-123` oder des Tag-Werts `B-456` zu einem beliebigen IAM-Benutzer oder einer Rolle erlaubt. Sie können diese Richtlinie verwenden, um das Markieren auf einen bestimmten Tag-Schlüssel und eine Reihe von Tag-Werten zu beschränken. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Mit der `ConsoleDisplay`-Anweisung kann die Anzeige von Tags für alle Benutzer und Rollen in Ihrem Konto erlaubt werden.
Die erste Bedingung in der `AddTag`-Anweisung verwendet den `StringEquals`-Bedingungsoperator. Die Bedingung gibt "true" zurück, wenn die Anforderung den `CostCenter`-Tag-Schlüssel mit einem der aufgelisteten Tag-Werte aufweist.
Die zweite Bedingung verwendet den `ForAllValues:StringEquals`-Bedingungsoperator. Die Bedingung gibt "true" zurück, wenn alle Tag-Schlüssel in der Anforderung mit dem Schlüssel in der Richtlinie übereinstimmen. Das bedeutet, dass der einzige Tag-Schlüssel in der Anforderung `CostCenter` sein muss. Weitere Informationen zur Verwendung von `ForAllValues` finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConsoleDisplay",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:GetUser",
"iam:ListRoles",
"iam:ListRoleTags",
"iam:ListUsers",
"iam:ListUserTags"
],
"Resource": "*"
},
{
"Sid": "AddTag",
"Effect": "Allow",
"Action": [
"iam:TagUser",
"iam:TagRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/CostCenter": [
"A-123",
"B-456"
]
},
"ForAllValues:StringEquals": {"aws:TagKeys": "CostCenter"}
}
}
]
}
```
------
# IAM: Erstellen neuer Benutzer nur mit bestimmten Tags
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Erstellung von IAM-Benutzern erlaubt, aber nur mit einem oder beiden Tag-Schlüsseln `Department` und `JobFunction`. Der `Department`-Tag-Schlüssel muss entweder den `Development`- oder den `QualityAssurance`-Tag-Wert aufweisen. Der `JobFunction`-Tag-Schlüssel muss den `Employee`-Tag-Wert aufweisen. Mit dieser Richtlinie können Sie festlegen, dass neue Benutzer eine bestimmte Stellenfunktion und Abteilung aufweisen müssen. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die erste Bedingung in der Anweisung verwendet den `StringEqualsIfExists`-Bedingungsoperator. Wenn ein Tag mit dem `Department`- oder dem `JobFunction`-Schlüssel in der Anforderung vorhanden ist, muss das Tag den angegebenen Wert aufweisen. Wenn kein Schlüssel vorhanden ist, wird diese Bedingung als "true" ausgewertet. Die einzige Möglichkeit, dass die Bedingung als "false" ausgewertet wird, ist gegeben, wenn einer der angegebenen Bedingungsschlüssel in der Anforderung vorhanden ist, aber einen anderen Wert als die zulässigen hat. Weitere Informationen zur Verwendung von `IfExists` finden Sie unter [... IfExists Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_IfExists).
Die zweite Bedingung verwendet den `ForAllValues:StringEquals`-Bedingungsoperator. Die Bedingung gibt "true" zurück, wenn alle in der Anforderung angegebenen Tag-Schlüssel mit mindestens einem Richtlinienwert übereinstimmen. Das bedeutet, dass alle Tags in der Anforderung in dieser Liste aufgeführt sein müssen. Die Anforderung kann jedoch nur einen der Tags in der Liste enthalten. Sie können beispielsweise einen IAM-Benutzer nur mit dem `Department=QualityAssurance`-Tag erstellen. Es ist jedoch nicht möglich, einen IAM-Benutzer mit dem `JobFunction=employee`-Tag und dem `Project=core`-Tag zu erstellen. Weitere Informationen zur Verwendung von `ForAllValues` finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TagUsersWithOnlyTheseTags",
"Effect": "Allow",
"Action": [
"iam:CreateUser",
"iam:TagUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"aws:RequestTag/Department": [
"Development",
"QualityAssurance"
],
"aws:RequestTag/JobFunction": "Employee"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"Department",
"JobFunction"
]
}
}
}
]
}
```
------
# IAM: Generieren und Abrufen von -Berichten zu Anmeldeinformationen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die es Benutzern ermöglicht, einen Bericht zu generieren und herunterzuladen, in dem alle IAM-Benutzer in ihrem Verzeichnis aufgeführt sind. AWS-Konto Der Bericht enthält außerdem den Status der Anmeldeinformationen des Benutzers, einschließlich Passwörter, MFA-Geräte und Signaturzertifikate. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die API oder durchzuführen. AWS AWS CLI
Weitere Informationen zu Berichten zu Anmeldeinformationen finden Sie unter [Generieren Sie Anmeldedatenberichte für Ihre AWS-Konto](id_credentials_getting-report.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:GetCredentialReport"
],
"Resource": "*"
}
}
```
------
# IAM: Ermöglicht das Verwalten der Mitgliedschaft einer Gruppe sowohl programmgesteuert als auch über die Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Aktualisierung der Mitgliedschaft der Gruppe mit dem Namen `MarketingTeam` erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Was macht diese Richtlinie?
+ Die `ViewGroups`-Anweisung erlaubt dem Benutzer das Auflisten aller Benutzer und Gruppen in der AWS-Managementkonsole. Darüber hinaus ermöglicht sie dem Benutzer das Anzeigen grundlegender Informationen zu den Benutzern im Konto. Diese Berechtigungen müssen in ihrer eigenen Anweisung vorliegen, da sie keine Ressourcen-ARN unterstützen oder keine angeben müssen. Geben Sie anstelle von Berechtigungen `"Resource" : "*"` ein.
+ Die `ViewEditThisGroup`-Anweisung ermöglicht dem Benutzer, Informationen zur Gruppe `MarketingTeam` anzuzeigen und Benutzer zu dieser Gruppe hinzuzufügen oder aus dieser zu entfernen.
Diese Richtlinie lässt nicht zu, dass der Benutzer die Berechtigungen der Benutzer oder der Gruppe `MarketingTeam` anzeigt oder bearbeitet.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewGroups",
"Effect": "Allow",
"Action": [
"iam:ListGroups",
"iam:ListUsers",
"iam:GetUser",
"iam:ListGroupsForUser"
],
"Resource": "*"
},
{
"Sid": "ViewEditThisGroup",
"Effect": "Allow",
"Action": [
"iam:AddUserToGroup",
"iam:RemoveUserFromGroup",
"iam:GetGroup"
],
"Resource": "arn:aws:iam::*:group/MarketingTeam"
}
]
}
```
------
# IAM: Verwalten eines bestimmten Tags
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die das Hinzufügen und Entfernen des IAM-Tags mit dem Tag-Schlüssel `Department` von IAM-Entitäten (Benutzern und Rollen) erlaubt. Diese Richtlinie schränkt den Wert des `Department`-Tags nicht ein. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:TagUser",
"iam:TagRole",
"iam:UntagUser",
"iam:UntagRole"
],
"Resource": "*",
"Condition": {"ForAllValues:StringEquals": {"aws:TagKeys": "Department"}}
}
}
```
------
# IAM: Übergeben Sie eine IAM-Rolle an einen bestimmten Dienst AWS
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die es ermöglicht, jede IAM-Servicerolle an den Amazon-Service zu übergeben. CloudWatch Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die API oder durchzuführen. AWS AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Eine Servicerolle ist eine IAM-Rolle, die einen AWS Dienst als Principal angibt, der die Rolle übernehmen kann. Auf diese Weise kann der Service die Rolle übernehmen und in Ihrem Namen auf Ressourcen eines anderen Services zugreifen. Damit Amazon CloudWatch die Rolle übernehmen kann, die Sie bestehen, müssen Sie in der Vertrauensrichtlinie Ihrer Rolle den `cloudwatch.amazonaws.com` Service Principal als Principal angeben. Der Dienstauftraggeber wird durch den Service definiert. Um den Dienstauftraggeber für einen Service zu ermitteln, lesen Sie die Dokumentation für diesen Service. Für einige Services finden Sie Informationen unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) und suchen Sie nach den Services, für die **Yes **in der Spalte **Service-Linked Role** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen. Suchen Sie nach `amazonaws.com`, um den Dienstauftraggeber anzuzeigen.
Weitere Informationen zum Übergeben einer Servicerolle an einen Service finden Sie unter [Erteilen Sie einem Benutzer die Erlaubnis, eine Rolle an einen AWS Dienst zu übergeben](id_roles_use_passrole.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {"iam:PassedToService": "cloudwatch.amazonaws.com"}
}
}
]
}
```
------
# IAM: Ermöglicht einen schreibgeschützten Zugriff auf die IAM-Konsole ohne Berichterstellung
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die IAM-Benutzern die Berechtigung zum Ausführen einer IAM-Aktion gewährt, die mit der Zeichenfolge `Get` oder `List` beginnt. Wenn Benutzer die Konsole verwenden, stellt diese Anforderungen an IAM, um Gruppen, Benutzer, Rollen und Richtlinien aufzulisten und Berichte über diese Ressourcen zu generieren.
Das Sternchen dient als Platzhalter. Wenn Sie `iam:Get*` in einer Richtlinie verwenden, enthalten die resultierenden Berechtigungen alle IAM-Aktionen, die mit `Get` beginnen, beispielsweise `GetUser` und `GetRole`. Platzhalter sind nützlich, wenn neue Entitätstypen zu IAM hinzugefügt werden. In diesem Fall wird es dem Benutzer durch die Berechtigungen, die laut der Richtlinie gewährt werden, automatisch erlaubt, Details zu diesen neuen Entitäten aufzulisten und abzurufen.
Diese Richtlinie kann nicht zum Generieren von Berichten oder Dienstdetails verwendet werden, auf die zuletzt zugegriffen wird. Eine andere Richtlinie, die dies zulässt, finden Sie unter [IAM: Gewährt einen schreibgeschützten Zugriff auf die IAM-Konsole](reference_policies_examples_iam_read-only-console.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*"
],
"Resource": "*"
}
}
```
------
# IAM: Gewährt einen schreibgeschützten Zugriff auf die IAM-Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die IAM-Benutzern die Berechtigung zum Ausführen einer IAM-Aktion gewährt, die mit der Zeichenfolge `Get`, `List` oder `Generate` beginnt. Wenn Benutzer die IAM-Konsole verwenden, stellt diese Anforderungen, um Gruppen, Benutzer, Rollen und Richtlinien aufzulisten und Berichte über diese Ressourcen zu generieren.
Das Sternchen dient als Platzhalter. Wenn Sie `iam:Get*` in einer Richtlinie verwenden, enthalten die resultierenden Berechtigungen alle IAM-Aktionen, die mit `Get` beginnen, beispielsweise `GetUser` und `GetRole`. Das Verwenden eines Platzhalters ist hilfreich, insbesondere, wenn neue Entitätstypen zu IAM hinzugefügt werden. In diesem Fall wird es dem Benutzer durch die Berechtigungen, die laut der Richtlinie gewährt werden, automatisch erlaubt, Details zu diesen neuen Entitäten aufzulisten und abzurufen.
Verwenden Sie diese Richtlinie für den Konsolenzugriff, der Berechtigungen zum Generieren von Berichten oder Dienstdetails enthält. Für eine andere Richtlinie, die das Erzeugen von Aktionen nicht zulässt, siehe [IAM: Ermöglicht einen schreibgeschützten Zugriff auf die IAM-Konsole ohne Berichterstellung](reference_policies_examples_iam_read-only-console-no-reporting.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*",
"iam:Generate*"
],
"Resource": "*"
}
}
```
------
# : Ermöglicht spezifischen IAM-Benutzern das Verwalten einer Gruppe programmgesteuert und in der Konsole
Dieses Beispiel zeigt, wie Sie eine IAM-Richtlinie erstellen könnten, die es bestimmten IAM-Benutzern erlaubt, die `AllUsers`-Gruppe zu verwalten. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Was macht diese Richtlinie?
+ Die `AllowAllUsersToListAllGroups`-Anweisung erlaubt das Auflisten aller Gruppen. Dies ist für den Konsolenzugriff erforderlich. Diese Berechtigung muss als eigene Anweisung vorliegen, da sie keinen Ressourcen-ARN unterstützt. Geben Sie anstelle von Berechtigungen `"Resource" : "*"` ein.
+ Die `AllowAllUsersToViewAndManageThisGroup`-Anweisung lässt alle Gruppenaktionen zu, die für den Gruppenressourcentyp durchgeführt werden können. Sie lässt die `ListGroupsForUser`-Aktion nicht zu. Diese Aktion kann für einen Benutzerressourcentyp und nicht für einen Gruppenressourcentyp durchgeführt werden. Weitere Informationen über die Ressourcentypen, die Sie für eine IAM-Aktion angeben können, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_identityandaccessmanagement.html#identityandaccessmanagement-actions-as-permissions).
+ Die `LimitGroupManagementAccessToSpecificUsers`-Anweisung verweigert Benutzern mit den angegebenen Namen den Zugriff auf Gruppenaktionen für die Schreib- und Berechtigungsverwaltung. Wenn ein in der Richtlinie angegebener Benutzer versucht, Änderungen an der Gruppe vorzunehmen, lehnt diese Anweisung die Anforderung nicht ab. Diese Anforderung wird durch die `AllowAllUsersToViewAndManageThisGroup`-Anweisung zugelassen. Wenn andere Benutzer versuchen, diese Operationen durchzuführen, wird die Anforderung abgelehnt. Sie können die -Aktionen, die über die Zugriffsebenen **Write (Schreiben)** oder **Permissions management (Berechtigungsverwaltung)** definiert wurden, anzeigen, während Sie die Richtlinie in der IAM-Konsole erstellen. Wechseln Sie dazu von der Registerkarte **JSON** zur Registerkarte**Visual editor (Visueller Editor)** . Weitere Informationen über Zugriffsebenen finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_identityandaccessmanagement.html#identityandaccessmanagement-actions-as-permissions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAllUsersToListAllGroups",
"Effect": "Allow",
"Action": "iam:ListGroups",
"Resource": "*"
},
{
"Sid": "AllowAllUsersToViewAndManageThisGroup",
"Effect": "Allow",
"Action": "iam:*Group*",
"Resource": "arn:aws:iam::*:group/AllUsers"
},
{
"Sid": "LimitGroupManagementAccessToSpecificUsers",
"Effect": "Deny",
"Action": [
"iam:AddUserToGroup",
"iam:CreateGroup",
"iam:RemoveUserFromGroup",
"iam:DeleteGroup",
"iam:AttachGroupPolicy",
"iam:UpdateGroup",
"iam:DetachGroupPolicy",
"iam:DeleteGroupPolicy",
"iam:PutGroupPolicy"
],
"Resource": "arn:aws:iam::*:group/AllUsers",
"Condition": {
"StringNotEquals": {
"aws:username": [
"srodriguez",
"mjackson",
"adesai"
]
}
}
}
]
}
```
------
# IAM: Ermöglicht das Festlegen der Anforderungen an das Kontopasswort programmgesteuert und in der Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es einem Benutzer erlaubt, die Passwort-Anforderungen für sein Konto anzuzeigen und zu aktualisieren. Die Passwortanforderungen umfassen die Anforderungen an die Komplexität sowie die vorgeschriebenen Wechselperioden für die Passwörter der Kontomitglieder. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff.
Informationen zum Festlegen der Anforderungen an das Kontopasswort für Ihr Konto finden Sie unter [Konto-Passwortrichtlinie für IAM-Benutzer festlegen](id_credentials_passwords_account-policy.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:UpdateAccountPasswordPolicy"
],
"Resource": "*"
}
}
```
------
# IAM: Zugriff auf die Richtliniensimulator-API basierend auf dem Benutzerpfad
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Verwendung der Richtliniensimulator-API nur für Benutzer mit dem Pfad `Department/Development` zulässt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetContextKeysForPrincipalPolicy",
"iam:SimulatePrincipalPolicy"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::*:user/Department/Development/*"
}
]
}
```
------
**Anmerkung**
Informationen zum Erstellen einer Richtlinie, die die Verwendung der Richtliniensimulator-Konsole für diejenigen Benutzer erlaubt, die über den Pfad `Department/Development` verfügen, finden Sie unter [IAM: Zugriff auf die Richtliniensimulator-Konsole basierend auf dem Benutzerpfad](reference_policies_examples_iam_policy-sim-path-console.md).
# IAM: Zugriff auf die Richtliniensimulator-Konsole basierend auf dem Benutzerpfad
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Verwendung der Richtliniensimulator-Konsole nur für die Benutzer mit dem Pfad `Department/Development` zulässt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
[Sie können auf den IAM Policy Simulator zugreifen unter:/https://policysim.aws.amazon.com](https://policysim.aws.amazon.com/)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetPolicy",
"iam:GetUserPolicy"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"iam:GetUser",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListUserPolicies",
"iam:ListUsers"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::*:user/Department/Development/*"
}
]
}
```
------
# IAM: Ermöglicht es IAM-Benutzern, MFA-Geräte selbst zu verwalten
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die IAM-Benutzern erlaubt, ihr [Multi-Faktor-Authentifizierung (MFA)](id_credentials_mfa.md)-Gerät selbst zu verwalten. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI
**Anmerkung**
Wenn ein IAM-Benutzer mit dieser Richtlinie nicht MFA-authentifiziert ist, verweigert diese Richtlinie den Zugriff auf alle AWS Aktionen außer denen, die für die Authentifizierung mit MFA erforderlich sind. Wenn Sie diese Berechtigungen für einen Benutzer hinzufügen, bei dem er angemeldet ist, muss er sich möglicherweise ab- und wieder anmelden AWS, um die Änderungen zu sehen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowListActions",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowUserToCreateVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/*"
},
{
"Sid": "AllowUserToManageTheirOwnMFA",
"Effect": "Allow",
"Action": [
"iam:EnableMFADevice",
"iam:GetMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "AllowUserToDeactivateTheirOwnMFAOnlyWhenUsingMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
],
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Sid": "BlockMostAccessUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListUsers",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
```
------
# IAM: Ermöglicht es IAM-Benutzern, ihre eigenen Anmeldeinformationen programmgesteuert und in der Konsole zu aktualisieren
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern ermöglicht, ihre eigenen Zugriffsschlüssel, Signierzertifikate, servicespezifischen Anmeldeinformationen und Passwörter zu aktualisieren. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:ChangePassword",
"iam:GetUser",
"iam:*ServiceSpecificCredential*",
"iam:*SigningCertificate*"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
}
]
}
```
------
Weitere Informationen dazu, wie ein Benutzer sein eigenes Passwort in der Konsole ändern kann, finden Sie unter [Wie ein IAM-Benutzer sein eigenes Passwort ändert](id_credentials_passwords_user-change-own.md).
# IAM: Informationen über den Dienst, auf den zuletzt zugegriffen wurde, für eine AWS Organizations Richtlinie anzeigen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Anzeige von Informationen über den letzten Zugriff auf einen Service für eine bestimmte AWS Organizations -Richtlinie erlaubt. Diese Richtlinie ermöglicht das Abrufen von Daten für die Service-Kontrollrichtlinie (Service Control Policy, SCP) mit der `p-policy123`-ID. Die Person, die den Bericht generiert und anzeigt, muss mit den Anmeldeinformationen für das AWS Organizations Verwaltungskonto authentifiziert werden. Diese Richtlinie ermöglicht es dem Anforderer, die Daten für jede AWS Organizations Entität in seiner Organisation abzurufen. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Weitere Informationen zu Informationen zum letzten Servicezugriff, darunter zu den erforderlichen Berechtigungen und den unterstützten Regionen, finden Sie unter [Verfeinern Sie die Berechtigungen für AWS die Verwendung der zuletzt abgerufenen Informationen](access_policies_last-accessed.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowOrgsReadOnlyAndIamGetReport",
"Effect": "Allow",
"Action": [
"iam:GetOrganizationsAccessReport",
"organizations:Describe*",
"organizations:List*"
],
"Resource": "*"
},
{
"Sid": "AllowGenerateReportOnlyForThePolicy",
"Effect": "Allow",
"Action": "iam:GenerateOrganizationsAccessReport",
"Resource": "*",
"Condition": {
"StringEquals": {"iam:OrganizationsPolicyId": "p-policy123"}
}
}
]
}
```
------
# IAM: Beschränkt die verwalteten Richtlinien, die -Benutzern, -Gruppen oder -Rollen zugeordnet werden können
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die vom Kunden verwaltete und AWS verwaltete Richtlinien einschränkt, die auf einen IAM-Benutzer, eine Gruppe oder eine IAM-Rolle angewendet werden können. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die API oder durchzuführen. AWS AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy",
"iam:DetachUserPolicy"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"iam:PolicyARN": [
"arn:aws:iam::*:policy/policy-name-1",
"arn:aws:iam::*:policy/policy-name-2"
]
}
}
}
}
```
------
# AWS: Verweigern Sie den Zugriff auf Ressourcen außerhalb Ihres Kontos mit Ausnahme von AWS verwalteten IAM-Richtlinien
Die Verwendung von `aws:ResourceAccount` in Ihren identitätsbasierten Richtlinien kann sich auf die Fähigkeit des Benutzers oder der Rolle auswirken, einige Services zu nutzen, die eine Interaktion mit Ressourcen in Konten erfordern, die einem Service gehören.
Sie können eine Richtlinie mit einer Ausnahme erstellen, um AWS verwaltete IAM-Richtlinien zuzulassen. Ein vom Service verwaltetes Konto außerhalb Ihrer AWS Organizations eigenen verwalteten IAM-Richtlinien. Es gibt vier IAM-Aktionen, die verwaltete Richtlinien auflisten und abrufen AWS. Verwenden Sie diese Aktionen im [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html)-Element der Anweisung. `AllowAccessToS3ResourcesInSpecificAccountsAndSpecificService1` in der Richtlinie.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToResourcesInSpecificAccountsAndSpecificService1",
"Effect": "Deny",
"NotAction": [
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListEntitiesForPolicy",
"iam:ListPolicies"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
}
}
}
]
}
```
------
# AWS Lambda: Ermöglicht einer Lambda-Funktion den Zugriff auf eine Amazon DynamoDB -Tabelle
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den Lese- und Schreibzugriff auf eine bestimmte Amazon-DynamoDB-Tabelle erlaubt. Die Richtlinie ermöglicht auch das Schreiben von Protokolldateien in CloudWatch Logs. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Zur Nutzung dieser Richtlinie fügen Sie sie an eine Lambda [Servicerolle](id_roles_create_for-service.md) an. Eine Servicerolle ist eine Rolle, die Sie in Ihrem Konto erstellen, um einem Service das Ausführen von Aktionen in Ihrem Namen zu ermöglichen. Diese Servicerolle muss AWS Lambda als Principal in der Vertrauensrichtlinie enthalten sein. Einzelheiten zur Verwendung dieser Richtlinie finden Sie unter [So erstellen Sie eine AWS IAM-Richtlinie, um AWS Lambda Zugriff auf eine Amazon DynamoDB-Tabelle zu gewähren im AWS Sicherheitsblog](https://aws.amazon.com/blogs/security/how-to-create-an-aws-iam-policy-to-grant-aws-lambda-access-to-an-amazon-dynamodb-table/).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadWriteTable",
"Effect": "Allow",
"Action": [
"dynamodb:BatchGetItem",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWriteItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/SampleTable"
},
{
"Sid": "GetStreamRecords",
"Effect": "Allow",
"Action": "dynamodb:GetRecords",
"Resource": "arn:aws:dynamodb:*:*:table/SampleTable/stream/* "
},
{
"Sid": "WriteLogStreamsAndGroups",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Sid": "CreateLogGroup",
"Effect": "Allow",
"Action": "logs:CreateLogGroup",
"Resource": "*"
}
]
}
```
------
# Amazon RDS: Gewährt Vollzugriff auf die RDS-Datenbank innerhalb einer bestimmten Region
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die den vollständigen RDS-Datenbankzugriff innerhalb einer bestimmten Region ermöglicht. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "rds:*",
"Resource": ["arn:aws:rds:us-east-1:*:*"]
},
{
"Effect": "Allow",
"Action": ["rds:Describe*"],
"Resource": ["*"]
}
]
}
```
------
# Amazon RDS: Ermöglicht es, RDS-Datenbanken programmgesteuert und in der Konsole wiederherzustellen
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Wiederherstellung von RDS-Datenbanken erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"rds:CreateDBParameterGroup",
"rds:CreateDBSnapshot",
"rds:DeleteDBSnapshot",
"rds:Describe*",
"rds:DownloadDBLogFilePortion",
"rds:List*",
"rds:ModifyDBInstance",
"rds:ModifyDBParameterGroup",
"rds:ModifyOptionGroup",
"rds:RebootDBInstance",
"rds:RestoreDBInstanceFromDBSnapshot",
"rds:RestoreDBInstanceToPointInTime"
],
"Resource": "*"
}
]
}
```
------
# Amazon RDS: Gewährt Tag-Eigentümern Vollzugriff auf die RDS-Ressourcen, die sie markiert haben
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die Tag-Besitzern vollen Zugriff auf RDS-Ressourcen gewährt, die sie markiert haben. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"rds:Describe*",
"rds:List*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"rds:DeleteDBInstance",
"rds:RebootDBInstance",
"rds:ModifyDBInstance"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:db-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:ModifyOptionGroup",
"rds:DeleteOptionGroup"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:og-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:ModifyDBParameterGroup",
"rds:ResetDBParameterGroup"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:pg-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:AuthorizeDBSecurityGroupIngress",
"rds:RevokeDBSecurityGroupIngress",
"rds:DeleteDBSecurityGroup"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:secgrp-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:DeleteDBSnapshot",
"rds:RestoreDBInstanceFromDBSnapshot"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:snapshot-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:ModifyDBSubnetGroup",
"rds:DeleteDBSubnetGroup"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:subgrp-tag/Owner": "${aws:username}"}
}
},
{
"Action": [
"rds:ModifyEventSubscription",
"rds:AddSourceIdentifierToSubscription",
"rds:RemoveSourceIdentifierFromSubscription",
"rds:DeleteEventSubscription"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {"rds:es-tag/Owner": "${aws:username}"}
}
}
]
}
```
------
# Amazon S3: Ermöglicht Amazon Cognito-Benutzern den Zugriff auf Objekte in ihrem Bucket
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die Amazon-Cognito-Benutzern den Zugriff auf Objekte in einem bestimmten Amazon-S3-Bucket ermöglicht. Diese Richtlinie gewährt den Zugriff nur auf Objekte mit einem Namen, der `cognito`, den Namen der Anwendung und die ID des Verbundprinzipals enthält, dargestellt durch die Variable \$1\$1cognito-identity.amazonaws.com:sub\$1. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
**Anmerkung**
Der im Objektschlüssel verwendete "sub"-Wert ist nicht der Sub-Wert des Benutzers im Benutzerpool, sondern die Identitäts-ID, die dem Benutzer im Identitätspool zugeordnet ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListYourObjects",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::bucket-name"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
]
}
}
},
{
"Sid": "ReadWriteDeleteYourObjects",
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
]
}
]
}
```
------
Amazon Cognito bietet Authentifizierung, Autorisierung und Benutzerverwaltung für Ihre Web- und Mobilanwendungen. Ihre Benutzer können sich direkt mit einem Benutzernamen und einem Passwort oder über einen Drittanbieter wie Facebook, Amazon oder Google anmelden.
Die zwei Hauptkomponenten von Amazon Cognito sind Benutzerpools und Identitäten-Pools. Benutzerpools sind Benutzerverzeichnisse, die Registrierungs- und Anmeldungsoptionen für Ihre mobilen Anwendungs-Nutzer bereitstellen. Mithilfe von Identitätspools können Sie Ihren Benutzern Zugriff auf andere AWS Dienste gewähren. Sie können Identitäten-Pools und Benutzerpools getrennt oder zusammen verwenden.
Weitere Informationen zu Amazon Cognito erhalten Sie im [Benutzerhandbuch von Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html).
# Amazon S3: Gewährt Verbundbenutzern programmgesteuert und in der Konsole Zugriff auf ihr Amazon-S3-Stammverzeichnis
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es Verbundprinzipalen ermöglicht, auf ihr eigenes Startverzeichnis-Bucket-Objekt in S3 zuzugreifen. Das Stammverzeichnis ist ein Bucket mit einem `home`-Ordner sowie Ordnern für einzelne Verbundprinzipale. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die Variable `${aws:userid}` in dieser Richtlinie wird in `role-id:specified-name` aufgelöst. Der Teil `role-id` der Verbundprinzipal-ID ist ein eindeutiger Bezeichner für die Rolle des Verbundprinzipals während der Erstellung. Weitere Informationen finden Sie unter [Eindeutige Bezeichner](reference_identifiers.md#identifiers-unique-ids). Dies `specified-name` ist der [RoleSessionName Parameter](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html#API_AssumeRoleWithWebIdentity_RequestParameters), der an die `AssumeRoleWithWebIdentity` Anforderung übergeben wurde, als der Verbundprinzipal seine Rolle übernommen hat.
Sie können die Rollen-ID mit dem AWS CLI Befehl `aws iam get-role --role-name specified-name` anzeigen. Stellen Sie sich z. B. vor, Sie geben als Anzeigenamen `John` an und die CLI gibt die Rolle-ID `AROAXXT2NJT7D3SIQN7Z6` zurück. In diesem Fall ist `AROAXXT2NJT7D3SIQN7Z6:John` die ID des Verbundprinzipals. Diese Richtlinie erlaubt dann dem Verbundprinzipal John den Zugriff auf den Amazon-S3-Bucket mit dem Präfix `AROAXXT2NJT7D3SIQN7Z6:John`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "S3ConsoleAccess",
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:userid}/*"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:userid}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:userid}/*"
]
}
]
}
```
------
# Amazon S3: S3-Bucket-Zugriff, der Zugriff auf den Produktions-Bucket ohne vorherige MFA wird aber verweigert
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die einem Amazon-S3-Administrator den Zugriff auf jeden Bucket erlaubt, einschließlich dem Aktualisieren, Hinzufügen und Löschen von Objekten. Dabei wird jedoch explizit der Zugriff auf den `amzn-s3-demo-bucket-production`-Bucket verweigert, wenn sich der Benutzer nicht innerhalb der letzten 30 Minuten per [Multifaktor-Authentifizierung (MFA)](id_credentials_mfa.md) angemeldet hat. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion in der Konsole oder programmgesteuert mithilfe der API AWS CLI oder AWS auszuführen. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Diese Richtlinie ermöglicht niemals den programmgesteuerten Zugriff auf den `amzn-s3-demo-bucket`-Bucket mit langfristig geltenden Benutzerzugriffsschlüsseln. Dies wird mit dem `aws:MultiFactorAuthAge`-Bedingungsschlüssel mit dem `NumericGreaterThanIfExists`-Bedingungsoperator erreicht. Diese Richtlinienbedingung gibt `true` zurück, wenn MFA nicht vorhanden ist oder wenn das Alter des MFA größer als 30 Minuten ist. In diesen Situationen wird der Zugriff verweigert. Um programmgesteuert auf den `amzn-s3-demo-bucket-production` Bucket zuzugreifen, muss der S3-Administrator temporäre Anmeldeinformationen verwenden, die in den letzten 30 Minuten mithilfe der [GetSessionToken](id_credentials_temp_request.md#api_getsessiontoken)API-Operation generiert wurden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListAllS3Buckets",
"Effect": "Allow",
"Action": ["s3:ListAllMyBuckets"],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "AllowBucketLevelActions",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "AllowBucketObjectActions",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Sid": "RequireMFAForProductionBucket",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-production/*",
"arn:aws:s3:::amzn-s3-demo-bucket-production"
],
"Condition": {
"NumericGreaterThanIfExists": {"aws:MultiFactorAuthAge": "1800"}
}
}
]
}
```
------
# Amazon S3:: Gewährt IAM-Benutzern programmgesteuert und in der Konsole Zugriff auf ihr S3-Stammverzeichnis.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es IAM-Benutzern erlaubt, auf ihr eigenes Startverzeichnis-Bucket-Objekt in S3 zuzugreifen. Das Stammverzeichnis ist ein Bucket mit dem Verzeichnis `home` sowie Verzeichnissen für einzelne Benutzer. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Diese Richtlinie funktioniert nicht bei der Verwendung von IAM-Rollen, da die `aws:username`-Variable bei der Verwendung von IAM-Rollen nicht verfügbar ist. Weitere Informationen zu Hauptschlüsselwerten finden Sie unter [Auftraggeber-Schlüsselwerte](reference_policies_variables.md#principaltable).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "S3ConsoleAccess",
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:username}/*"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
------
# Amazon S3: Beschränken der Verwaltung auf einen bestimmten S3-Bucket
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die die Verwaltung eines Amazon-S3-Buckets auf diesen spezifischen Bucket beschränkt. Diese Richtlinie gewährt die Berechtigung, alle Amazon-S3-Aktionen durchzuführen, verweigert aber den Zugriff auf jeden AWS-Service außer Amazon S3. Sehen Sie sich das folgende Beispiel an. Gemäß dieser Richtlinie können Sie nur auf Amazon-S3-Aktionen zugreifen, die Sie für einen S3-Bucket oder eine S3-Objektressource durchführen können. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die AWS API oder abzuschließen. AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Wenn diese Richtlinie in Kombination mit anderen Richtlinien (wie den von [AmazonS3 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) oder von [Amazon EC2 FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) AWS verwalteten Richtlinien) verwendet wird, die Aktionen zulassen, die durch diese Richtlinie verweigert werden, wird der Zugriff verweigert. Der Grund hierfür liegt darin, dass eine explizite Zugriffsverweigerung Vorrang vor einer Zugriffserlaubnis hat. Weitere Informationen finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md).
**Warnung**
Bei [`NotAction`](reference_policies_elements_notaction.md) und [`NotResource`](reference_policies_elements_notresource.md) handelt es sich um erweiterte Richtlinienelemente, die mit Vorsicht verwendet werden sollten. Diese Richtlinie verweigert den Zugriff auf alle AWS -Services mit Ausnahme von Amazon S3. Wenn Sie diese Richtlinie einem Benutzer anfügen, werden alle anderen Richtlinien, die Berechtigungen für andere Services erteilen, ignoriert und der Zugriff wird verweigert.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
},
{
"Effect": "Deny",
"NotAction": "s3:*",
"NotResource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
]
}
```
------
# Lese- und Schreibzugriff auf Objekte in einem Amazon-S3-Bucket gewähren
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die `Read` und `Write` Zugriff auf Objekte in einem bestimmten Amazon-S3-Bucket gewährt. Diese Richtlinie gewährt die erforderlichen Berechtigungen, um diese Aktion programmgesteuert über die API oder durchzuführen. AWS AWS CLI Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die `s3:*Object`-Aktion verwendet einen Platzhalter als Teil des Namens der Aktion. Die Anweisung `AllObjectActions` erlaubt die Aktionen `GetObject`, `DeleteObject`, `PutObject` und alle anderen Amazon S3-Aktionen, die mit dem Wort "Object" enden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::bucket-name"]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}
```
------
**Anmerkung**
Informationen zum Erlauben von `Read`- und `Write`-Zugriff auf ein Objekt in einem Amazon S3-Bucket und das Einschließen zusätzlicher Berechtigungen für den Konsolenzugriff finden Sie unter [Amazon S3: Gewährt Lese- und Schreibzugriff auf Objekte in einem S3-Bucket programmgesteuert und in der Konsole](reference_policies_examples_s3_rw-bucket-console.md).
# Amazon S3: Gewährt Lese- und Schreibzugriff auf Objekte in einem S3-Bucket programmgesteuert und in der Konsole
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die `Read` und `Write` den Zugriff auf Objekte in einem bestimmten S3-Bucket erlaubt. Diese Richtlinie definiert Berechtigungen für den programmgesteuerten Zugriff und den Konsolenzugriff. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
Die `s3:*Object`-Aktion verwendet einen Platzhalter als Teil des Namens der Aktion. Die Anweisung `AllObjectActions` erlaubt die Aktionen `GetObject`, `DeleteObject`, `PutObject` und alle anderen Amazon S3-Aktionen, die mit dem Wort "Object" enden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "S3ConsoleAccess",
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
}
]
}
```
------