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. # AWS JSON-Richtlinienelemente: Principal Verwenden Sie das `Principal`-Element in einer ressourcebasierten JSON Richtlinie, um den Auftraggeber anzugeben, dem der Zugriff auf eine Ressource erlaubt oder verweigert wird. Sie müssen das `Principal`-Element in [ressourcenbasierten Richtlinien](access_policies_identity-vs-resource.md) verwenden. Mehrere Services unterstützen ressourcenbasierte Richtlinien, einschließlich IAM. Der ressourcenbasierte IAM-Richtlinientyp ist eine Rollenvertrauensrichtlinie. Verwenden Sie in IAM-Rollen das `Principal`-Element in der Rollenvetrauensichtlinie, um anzugeben, wer diese Rolle übernehmen kann. Für den kontoübergreifenden Zugriff müssen Sie die 12-stellige ID des vertrauenswürdigen Kontos angeben. 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). **Anmerkung** Nachdem Sie die Rolle erstellt haben, können Sie das Konto zu „\$1“ ändern, damit jeder die Rolle übernehmen kann. Wenn Sie dies tun, empfehlen wir dringend, dass Sie den Zugriff auf die Rolle mit anderen Mitteln begrenzen, wie z. B. mit einem `Condition`-Element, das den Zugriff auf bestimmte IP-Adressen beschränkt. Schränken Sie den Zugriff auf Ihre Rolle unbedingt ein\$1 Andere Beispiele für Ressourcen, die ressourcenbasierte Richtlinien unterstützen, sind ein Amazon-S3-Bucket oder einen AWS KMS key. Sie können das Element `Principal` nicht in einer identitätsbasierten Richtlinie verwenden. Identitätsbasierte Richtlinien sind Berechtigungsrichtlinien, die Sie an eine IAM-Identität anfügen können, wie z. B. -Benutzer, -Rollen oder -Gruppen. In diesen Richtlinien wird der Prinzipal von der Identität impliziert, der der Richtlinie angefügt ist. **Topics** + [So legen Sie einen Prinzipal fest](#Principal_specifying) + [AWS-Konto Schulleiter](#principal-accounts) + [IAM-Rollenauftraggeber](#principal-roles) + [Rollensitzungsgsprinzipale](#principal-role-session) + [OIDC-Verbundprinzipale](#principal-federated-web-identity) + [SAML-Verbundprinzipale](#principal-saml) + [IAM-Benutzerprinzipal](#principal-users) + [Prinzipale von IAM Identity Center](#principal-identity-users) + [AWS STS föderierte Benutzerprinzipale](#sts-session-principals) + [AWS Dienstprinzipale](#principal-services) + [AWS Dienstprinzipale in Opt-in-Regionen](#principal-services-in-opt-in-regions) + [Alle Prinzipale](#principal-anonymous) + [Weitere Informationen](#Principal_more-info) ## So legen Sie einen Prinzipal fest Sie geben einen Prinzipal in dem `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln an, die Prinzipale unterstützen. Sie können einen der folgenden Auftraggeber in einer Richtlinie angeben: + AWS-Konto und Root-Benutzer + IAM-Rollen + Rollensitzungen + IAM-Benutzer + Verbundbenutzer-Prinzipale + AWS Dienste + Alle Prinzipale Sie können eine Benutzergruppe nicht als Prinzipal in einer Richtlinie (z. B. einer ressourcenbasierten Richtlinie) identifizieren, da sich Gruppen auf Berechtigungen und nicht auf die Authentifizierung beziehen, während Prinzipale authentifizierte IAM-Entitäten sind. Sie können mehrere Auftraggeber für jeden der Auftraggebertypen in den folgenden Abschnitten mithilfe eines Arrays angeben. Arrays können einen oder mehrere Werte enthalten. Wenn Sie mehr als einen Auftraggeber im Element angeben, erteilen Sie jedem Auftraggeber Berechtigungen. Dies ist ein logisches `OR` und kein logisches `AND`, da Sie jeweils als ein Auftraggeber authentifiziert sind. Wenn Sie mehr als einen Wert angeben, verwenden Sie eckige Klammern (`[` und `]`) und trennen Sie jeden Eintrag für das Array durch Kommas. Die folgende Beispielrichtlinie definiert Berechtigungen für das 123456789012-Konto oder das 555555555555-Konto. ``` "Principal" : { "AWS": [ "123456789012", "555555555555" ] } ``` **Anmerkung** Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder eines ARNs zu ersetzen. ## AWS-Konto Schulleiter Sie können AWS-Konto Bezeichner im `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Dadurch wird die Autorität des Kontos delegiert. Wenn Sie den Zugriff auf ein anderes Konto zulassen, muss ein Administrator in diesem Konto dann Zugriff auf eine Identität (IAM-Benutzer oder -Rolle) in diesem Konto gewähren. Wenn Sie eine angeben AWS-Konto, können Sie den Konto-ARN (arn:aws:iam: :root*account-ID*) oder eine verkürzte Form verwenden, die aus dem Präfix gefolgt von der Konto-ID besteht. `"AWS":` Wenn die Konto-ID beispielsweise `123456789012` lautet, können Sie eine der folgenden Methoden verwenden, um das betreffende Konto im Element `Principal` anzugeben: ``` "Principal": { "AWS": "arn:aws:iam::123456789012:root" } ``` ``` "Principal": { "AWS": "123456789012" } ``` Mit dem Konto-ARN und der verkürzten Konto-ID verhält es sich genauso. Beide delegieren Berechtigungen für das Konto. Wenn das Konto ARN im `Principal`-Element verwendet wird, werden die Berechtigungen nicht nur auf den Stamm-Benutzer des Kontos beschränkt. **Anmerkung** Wenn Sie eine ressourcenbasierte Richtlinie speichern, die die verkürzte Konto-ID enthält, konvertiert der Dienst sie möglicherweise in den Haupt-ARN. Dies ändert nichts an der Funktionalität der Richtlinie. Einige AWS Dienste unterstützen zusätzliche Optionen für die Angabe eines Kontoprinzipals. Bei Amazon S3 können Sie beispielsweise eine [kanonische Benutzer-ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) in folgendem Format angeben: ``` "Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` Sie können mithilfe eines Arrays auch mehr als eine AWS-Konto(oder kanonische Benutzer-ID) als Prinzipal angeben. Beispielsweise können Sie mit allen drei Methoden einen Prinzipal in einer Bucket-Richtlinie angeben. ``` "Principal": { "AWS": [ "arn:aws:iam::123456789012:root", "999999999999" ], "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` ## IAM-Rollenauftraggeber Sie können den IAM-Rollenprinzipal ARNs im `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. IAM-Rollen sind Identitäten. In IAM sind Identitäten Ressourcen, denen Sie Berechtigungen zuweisen können. Rollen vertrauen einer anderen authentifizierten Identität, um diese Rolle zu übernehmen. Dies beinhaltet einen Prinzipal in AWS oder einem Benutzer eines externen Identitätsanbieters (IdP). Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. *Wenn sie diese Sitzungsanmeldedaten für die Ausführung von Vorgängen verwenden AWS, werden sie zu Rollen-Sitzungsprinzipalen.* Wenn Sie einen Rollenprinzipal in einer ressourcenbasierten Richtlinie angeben, sind die effektiven Berechtigungen für den Prinzipal durch alle Richtlinientypen begrenzt, die Berechtigungen für die Rolle einschränken. Dies umfasst Sitzungssrichtlinien und Berechtigungsgrenzen. Weitere Informationen zur Auswertung der effektiven Berechtigungen für eine Rollensitzung finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md). Um die Rolle ARN im `Principal`-Element anzugeben, verwenden Sie das folgende Format: ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" } ``` **Wichtig** Wenn Ihr `Principal`-Element in einer Vertrauensrichtlinie einer Rolle einen ARN enthält, der auf eine bestimmte IAM-Rolle verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Prinzipal-ID der Rolle umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen der Rolle erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da IAM bei der Anzeige der Vertrauensrichtlinie eine Rückumwandlung zum Rollen-ARN verwendet. Wenn Sie jedoch die Rolle löschen, wird die Beziehung aufgehoben. Die Richtlinie wird nicht mehr angewendet, selbst wenn Sie die Rolle neu erstellen, da die Auftraggeber-ID der neuen Rolle nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Prinzipal-ID in ressourcenbasierten Richtlinien angezeigt, da sie nicht mehr einem gültigen ARN zugeordnet werden AWS kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Prinzipal-ID mit dem richtigen ARN zu ersetzen, wenn Sie eine mit einem `Principal`-Element einer Vertrauensrichtlinie verknüpfte Rolle löschen und neu erstellen. Der ARN wird beim Speichern der Richtlinie erneut in die neue Auftraggeber-ID der Rolle umgewandelt. Weitere Informationen finden Sie unter [Grundlegendes AWS zum Umgang mit gelöschten IAM-Rollen](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies) in Richtlinien. Alternativ können Sie den Rollenprinzipal als Prinzipal in einer ressourcenbasierten Richtlinie angeben oder [erstellen Sie eine Richtlinie mit breiter Berechtigung](#principal-anonymous) die `aws:PrincipalArn`-Bedingungsschlüssel benutzt. Wenn Sie diesen Schlüssel verwenden, erteilen Sie dem Rollensitzungsprinzipalen die Berechtigungen basierend auf dem übernommenen ARN der Rolle und nicht dem ARN der resultierenden Sitzung. Da der Bedingungsschlüssel AWS ARNs nicht konvertiert wird IDs, bleiben die dem Rollen-ARN gewährten Berechtigungen bestehen, wenn Sie die Rolle löschen und dann eine neue Rolle mit demselben Namen erstellen. Identitätsbasierte Richtlinientypen, wie z. B. Berechtigungsgrenzen oder Sitzungsrichtlinien, schränken die gewährten Berechtigungen nicht ein, indem sie den `aws:PrincipalArn`-Bedingungsschlüssel mit einem Platzhalter (\$1) im `Principal`-Element verwenden, es sei denn, die identitätsbasierten Richtlinien enthalten eine ausdrückliche Verweigerung. ## Rollensitzungsgsprinzipale Sie können Rollensitzungen im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, angeben. Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. Wenn sie diese Sitzungsanmeldedaten für die Ausführung von Vorgängen verwenden AWS, werden sie zu *Rollen-Sitzungsprinzipalen*. Das Format, das Sie für einen Rollensitzungsprinzipal verwenden, hängt von dem AWS STS Vorgang ab, mit dem die Rolle übernommen wurde. **Wichtig** AWS empfiehlt, wo immer [möglich IAM-Rollenprinzipale](#principal-roles) anstelle von Rollensitzungsprinzipalen in Ihren Richtlinien zu verwenden. Verwenden Sie `Condition` Anweisungen und Bedingungsschlüssel, um den Zugriff bei Bedarf weiter einzuschränken. Verwenden Sie das folgende Format, um den ARN des Rollensitzungsprinzipals im `Principal` Element anzugeben: ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" } ``` Darüber hinaus können Administratoren einen Prozess entwerfen, um zu steuern, wie Rollensitzungen ausgegeben werden. Sie können beispielsweise eine Ein-Klick-Lösung für ihre Benutzer bereitstellen, die einen vorhersehbaren Sitzungsnamen erstellt. Wenn Ihr Administrator dies tut, können Sie Rollensitzungsprinzipale in Ihren Richtlinien oder Bedingungsschlüsseln verwenden. Andernfalls können Sie die Rollen-ARN als Prinzipal im `aws:PrincipalArn`-Bedingungsschlüssel angeben. Wie Sie die Rolle als Prinzipal angeben, kann die effektiven Berechtigungen für die resultierend Sitzung ändern. Weitere Informationen finden Sie unter [IAM-Rollenauftraggeber](#principal-roles). ## OIDC-Verbundprinzipale Ein OIDC-Verbundprinzipal ist der Prinzipal, der verwendet wird, wenn die AWS STS `AssumeRoleWithWebIdentity` API mit einem JSON-Webtoken (JWT) von einem OIDC-kompatiblen IDP, auch bekannt als OpenID Provider (OP), aufgerufen wird, um temporäre Anmeldeinformationen anzufordern. AWS [Ein OIDC-Verbundprinzipal kann einen OIDC-IDP in Ihrem AWS Konto oder die 4 integrierten Identitätsanbieter darstellen:Login with Amazon,, und Amazon Cognito. GoogleFacebook](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html) Benutzer, Workloads oder Systeme, denen von ihrem OIDC-IDP ein JWT ausgestellt wurde, können `AssumeRoleWithWebIdentity` mithilfe des JWT anrufen, um temporäre AWS Sicherheitsanmeldedaten für eine IAM-Rolle anzufordern, die so konfiguriert ist, dass sie dem OIDC-IDP, der das JWT ausgestellt hat, vertraut. Das JWT kann ein ID-Token, ein Zugriffstoken oder ein auf anderem Wege übermitteltes JWT-Token sein, sofern es die [Anforderungen von AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites) erfüllt. Weitere Informationen finden Sie unter [Gängige Szenarien](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html) und [Anmeldeinformationen über einen OIDC-Anbieter anfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity). Verwenden Sie diesen Prinzipaltyp in Ihrer Rollen-Vertrauensrichtlinie, um Anrufberechtigungen `AssumeRoleWIthWebIdentity` über einen OIDC-IDP zuzulassen oder zu verweigern, der in Ihrem oder einem der vier integrierten Systeme vorhanden ist. AWS-Konto IDPs Um den OIDC-Verbundprinzipal-ARN im `Principal` Element einer Rollenvertrauensrichtlinie anzugeben, verwenden Sie eines der folgenden vier Formate für das integrierte OIDC: IDPs ``` "Principal": { "Federated": "cognito-identity.amazonaws.com" } ``` ``` "Principal": { "Federated": "www.amazon.com" } ``` ``` "Principal": { "Federated": "graph.facebook.com" } ``` ``` "Principal": { "Federated": "accounts.google.com" } ``` Wenn Sie einen OIDC-Anbieter verwenden, den Sie Ihrem Konto hinzufügen, geben Sie beispielsweise GitHub den ARN des Anbieters in der Vertrauensrichtlinie Ihrer Rolle an. Diese Konfiguration ermöglicht es Ihnen, IAM-Richtlinien zu schreiben, die den Zugriff speziell für Benutzer steuern, die über Ihren benutzerdefinierten Identitätsanbieter authentifiziert wurden. ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" } ``` Wenn beispielsweise GitHub der vertrauenswürdige Web-Identitätsanbieter ist, verwendet der OIDC-Rollensitzungs-ARN im `Principal`-Element einer Rollenvertrauensrichtlinie das folgende Format: ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" } ``` Weitere Informationen finden Sie unter [Konfigurieren von OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). OIDC-Verbundprinzipale werden in anderen Richtlinientypen als Rollenvertrauensrichtlinien nicht unterstützt. ## SAML-Verbundprinzipale Ein *SAML-Verbundprinzipal ist ein Prinzipal*, der verwendet wird, wenn eine AWS STS `AssumeRoleWithSAML` API aufgerufen wird, um mithilfe einer SAML-Assertion temporäre AWS Anmeldeinformationen anzufordern. Sie können sich mit Ihrem SAML-Identitätsanbieter (IDP) anmelden und dann mit diesem Vorgang eine IAM-Rolle übernehmen. Ähnlich wie`AssumeRoleWithWebIdentity`, benötigt `AssumeRoleWithSAML` AWS keine Anmeldeinformationen für die Authentifizierung. Stattdessen authentifizieren sich Benutzer zunächst bei ihrem SAML-Identitätsanbieter und führen dann den `AssumeRoleWithSAML` API-Aufruf mithilfe ihrer SAML-Assertion durch, oder sie werden zur AWS Anmelde-/SAML-Seite weitergeleitet, um sich dort anzumelden. AWS-Managementkonsole Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md). Verwenden Sie diesen Prinzipaltyp in Ihrer Rollenvertrauensrichtlinie, um Berechtigungen basierend auf dem vertrauenswürdigen SAML-Identitätsanbieter zu erteilen oder zu verweigern. Um dem ARN der SAML-Identitäts-Rollensitzung im `Principal`-Element eine Rollenvetrauensrichtlinie zu geben, verwenden Sie das folgende Format: ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" } ``` ## IAM-Benutzerprinzipal Sie können IAM-Benutzer im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. **Anmerkung** Bei einem `Principal`-Element, bei dem Benutzernamen Teil des [*Amazon-Ressourcenname*(ARN)](reference_identifiers.md#identifiers-arns) ist, wird zwischen Groß- und Kleinschreibung unterschieden. ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" } ``` ``` "Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/user-name-2" ] } ``` Wenn Sie Benutzer in einem `Principal`-Element angeben, können Sie keinen Platzhalter (`*`) für "alle Benutzer" verwenden. Auftraggeber müssen stets bestimmter Benutzer angeben. **Wichtig** Wenn Ihr `Principal`-Element in einer Rollenvetrauensichtlinie einen ARN enthält, der auf einen bestimmten IAM-Benutzer verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Auftraggeber-ID des Benutzers umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen des Benutzers erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da bei der Anzeige der Vertrauensrichtlinie auch eine Rückumwandlung in die Benutzer-ARN erfolgt. Wenn Sie jedoch den Benutzer löschen, wird die Beziehung aufgehoben. Die Richtlinie wird dann nicht mehr angewendet, selbst wenn Sie den Benutzer neu erstellen. Dies liegt daran, dass die Auftraggeber-ID des neuen Benutzers nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Prinzipal-ID in ressourcenbasierten Richtlinien angezeigt, da sie nicht mehr einem gültigen ARN zugeordnet werden AWS kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Auftraggeber-ID durch den richtigen ARN zu ersetzen, wenn Sie einen mit einem `Principal`-Element einer Vertrauensrichtlinie verknüpften Benutzer löschen und neu erstellen. IAM wandelt beim Speichern der Richtlinie den ARN erneut in die neue Haupt-ID des Benutzers um. ## Prinzipale von IAM Identity Center In IAM Identity Center muss der Prinzipal in einer ressourcenbasierten Richtlinie als AWS-Konto -Prinzipal definiert werden. Um Zugriff anzugeben, verweisen Sie auf den Rollen-ARN der im Bedingungsblock festgelegten Berechtigung. Einzelheiten finden Sie unter [Referencing permission sets in resource policies, Amazon EKS, and AWS KMS](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html) im *Benutzerhandbuch zu IAM Identity Center*. ## AWS STS föderierte Benutzerprinzipale Sie können *Verbundbenutzersitzungen* im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. **Wichtig** AWS empfiehlt, die Verwendung von AWS STS Verbundbenutzersitzungen einzuschränken. Verwenden Sie stattdessen [IAM-Rollen](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). Ein AWS STS föderierter Benutzerprinzipal wird durch den `GetFederationToken` Vorgang erstellt, der mit langlebigen IAM-Anmeldeinformationen aufgerufen wird. Die Berechtigungen des Verbundbenutzers ergeben sich aus der Schnittmenge des Prinzipals, der `GetFederationToken` aufgerufen hat, und der Sitzungsrichtlinien, die als Parameter an die `GetFederationToken`-API übergeben wurden. In Root-Benutzer des AWS-Kontos können AWS sich IAM-Benutzer oder ein Benutzer mit langfristigen Zugriffsschlüsseln authentifizieren. Weitere Informationen zum Verbünden von Prinzipalen mittles dieser Produktion finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md). + **IAM-Verbundbenutzer** – Ein IAM-Benutzer wird mithilfe des `GetFederationToken`-Vorgangs verbunden, was zu einer Verbundbenutzersitzung für diesen IAM-Benutzer führt. + **Root-Verbundbenutzer** – Ein Root-Benutzer wird mithilfe des `GetFederationToken`-Vorgangs verbunden, was zu einer Verbundbenutzersitzung für diesen Root-Benutzer führt. Wenn ein IAM-Benutzer oder Root-Benutzer temporäre Anmeldeinformationen für diesen Vorgang anfordert, beginnt er eine temporäre Verbundbenutzersitzung. AWS STS Der ARN dieser Sitzung basiert auf der ursprünglichen Identität, die verbunden wurde. Um den ARN der Verbundbenutzersitzung im `Principal`-Element anzugeben, verwenden Sie das folgende Format: ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" } ``` ## AWS Dienstprinzipale Sie können AWS Dienste als `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Ein *Service-Prinzipal* ist eine Kennung für einen Service. *[IAM-Rollen, die von einem Dienst übernommen werden können, werden als AWS Servicerollen bezeichnet.](id_roles.md#iam-term-service-role)* Service-Rollen müssen eine Vertrauensrichtlinie enthalten. *Vertrauensrichtlinien* sind ressourcenbasierte Richtlinien, die einer Rolle zugeordnet sind. Sie definiert, welche Auftraggeber die Rolle übernehmen können. Einige Service-Rollen haben vordefinierte Vertrauensrichtlinien. In einigen Fällen müssen Sie jedoch den Dienstauftraggeber in der Vertrauensrichtlinie angeben. Der Service-Prinzipal in einer IAM-Richtlinie kann nicht `"Service": "*"` sein. **Wichtig** Der Bezeichner für einen Dienstauftraggeber enthält den Servicenamen und hat normalerweise das folgende Format: `service-name.amazonaws.com` Der Dienstauftraggeber wird durch den Service definiert. Sie können den Service-Prinzipal für einige Services finden, indem Sie [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) öffnen, überprüfen, ob der Service in der Spalte **Serviceverknüpfte Rolle** **Ja** hat, und den Link **Ja** öffnen, um die Dokumentation zu serviceverknüpften Rollen für diesen Service anzuzeigen. Suchen Sie den Abschnitt **Service-Linked Role Permissions (Berechtigungen von serviceverknüpften Rollen)** für diesen Service, um den Dienstauftraggeber anzuzeigen. Das folgende Beispiel zeigt eine Richtlinie, die einer Service-Rolle angefügt werden kann. Diese Richtlinie ermöglicht zwei Services, Amazon ECS und Elastic Load Balancing, die Übernahme der Rolle. Die Services können dann sämtliche Aufgaben ausführen, zu denen die Rolle infolge der zugewiesenen Berechtigungsrichtlinie berechtigt ist (nicht dargestellt). Geben Sie zur Angabe von mehreren Dienstauftraggeber nicht zwei `Service`-Elemente an. Sie können nur ein Element angeben. Verwenden Sie stattdessen ein Array mit mehreren Dienstauftraggeber als Wert eines einzelnen `Service`-Elements. ``` "Principal": { "Service": [ "ecs.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] } ``` ## AWS Dienstprinzipale in Opt-in-Regionen Sie können Ressourcen in mehreren AWS Regionen bereitstellen, und für einige dieser Regionen müssen Sie sich entscheiden. Eine vollständige Liste der Regionen, für die Sie sich anmelden müssen, finden Sie im *Allgemeine AWS-Referenz*Leitfaden unter [AWS Regionen verwalten](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html). Wenn ein AWS Dienst in einer Opt-in-Region eine Anfrage innerhalb derselben Region stellt, wird das Format des Dienstprinzipalnamens als die nicht regionalisierte Version seines Dienstprinzipalnamens identifiziert: `service-name.amazonaws.com` Wenn ein AWS Dienst in einer Opt-in-Region eine regionsübergreifende Anfrage an eine andere Region stellt, wird das Format des Dienstprinzipalnamens als die regionalisierte Version seines Dienstprinzipalnamens identifiziert: `service-name.{region}.amazonaws.com` Angenommen, Sie haben ein Amazon-SNS-Thema in der Region `ap-southeast-1` und einen Amazon-S3-Bucket in der Opt-in-Region `ap-east-1`. Sie möchten S3-Bucket-Benachrichtigungen konfigurieren, um Nachrichten im SNS-Thema zu veröffentlichen. Damit der S3-Service Nachrichten im SNS-Thema posten kann, müssen Sie dem S3-Serviceprinzipal über die ressourcenbasierte Zugriffsrichtlinie des Themas die Berechtigung `sns:Publish` erteilen. Wenn Sie in der Themenzugriffsrichtlinie die nicht regionalisierte Version des S3-Serviceprinzipals `s3.amazonaws.com` angeben, schlägt die `sns:Publish`-Anfrage vom Bucket an das Thema fehl. Im folgenden Beispiel wird der nicht regionalisierte S3-Serviceprinzipal im `Principal`-Richtlinienelement der SNS-Themenzugriffsrichtlinie angegeben. ``` "Principal": { "Service": "s3.amazonaws.com" } ``` Da sich der Bucket in einer Opt-In-Region befindet und die Anfrage außerhalb dieser Region gestellt wurde, wird der regionalisierte Name des S3-Serviceprinzipals angezeigt: `s3.ap-east-1.amazonaws.com`. Sie müssen den regionalisierten Dienstprinzipalnamen verwenden, wenn ein AWS Dienst in einer Opt-in-Region eine Anfrage an eine andere Region sendet. Wenn Sie den regionalisierten Namen des Serviceprinzipals angegeben haben und der Bucket eine `sns:Publish`-Anfrage an das SNS-Thema in einer anderen Region stellt, ist die Anfrage erfolgreich. Im folgenden Beispiel wird der regionalisierte S3-Serviceprinzipal im `Principal`-Richtlinienelement der SNS-Themenzugriffsrichtlinie angegeben. ``` "Principal": { "Service": "s3.ap-east-1.amazonaws.com" } ``` Ressourcenrichtlinien oder auf Serviceprinzipalen basierende Zulassungslisten für regionsübergreifende Anfragen von einer Opt-In-Region an eine andere Region sind nur erfolgreich, wenn Sie den regionalisierten Serviceprinzipalnamen angeben. **Anmerkung** Für Vertrauensrichtlinien von IAM-Rollen empfehlen wir, den nicht regionalisierten Serviceprinzipalnamen zu verwenden. IAM-Ressourcen sind global, daher kann dieselbe Rolle in jeder Region verwendet werden. ## Alle Prinzipale Sie können ein Platzhalterzeichen (\$1) verwenden, um alle Prinzipale im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, anzugeben. [Ressourcenbasierte Richtlinien](access_policies.md#policies_resource-based) *Erteilungs*-Berechtigungen und [Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) werden verwendet, um die Bedingungen einer Richtlinienanweisung einzuschränken. **Wichtig** Es wird ausdrücklich empfohlen, keinen Platzhalter (\$1) im `Principal`-Element einer ressourcenbasierten Richtlinie mit `Allow`-Effekt zu verwenden, es sei denn, Sie beabsichtigen, öffentlichen oder anonymen Zugang zu gewähren. Andernfalls geben Sie die beabsichtigten Prinzipale, Services oder AWS -Konten im `Principal`-Element an und schränken dann den Zugriff im `Condition`-Element weiter ein. Dies gilt insbesondere für Vertrauensrichtlinien für IAM-Rollen, da sie es anderen Prinzipalen erlauben, Prinzipale in Ihrem Konto zu werden. Für ressourcenbasierte Richtlinien wird durch die Verwendung eines Platzhalters (\$1) mit einem `Allow`-Effekt der Zugriff auf alle Benutzer, einschließlich anonymer Benutzer (öffentlicher Zugriff), gewährt. Für IAM-Benutzer- und Rollenprinzipale innerhalb Ihres Kontos sind keine weiteren Berechtigungen erforderlich. Für Prinzipale in anderen Konten müssen sie auch identitätsbasierte Berechtigungen in ihrem Konto haben, mit denen sie auf Ihre Ressource zugreifen können. Dies wird als [kontenübergreifender Zugriff](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html) bezeichnet. Für anonyme Benutzer sind die folgenden Elemente gleichwertig: ``` "Principal": "*" ``` ``` "Principal" : { "AWS" : "*" } ``` Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder eines ARNs zu ersetzen. Das folgende Beispiel zeigt eine ressourcenbasierte Richtlinie, die anstelle von [AWS JSON-Richtlinienelemente: NotPrincipal](reference_policies_elements_notprincipal.md) verwendet werden kann, um alle Prinzipale *mit Ausnahme* der im Element `Condition` angegebenen ausdrücklich abzulehnen. Diese Richtlinie sollte [einem Amazon-S3-Bucket hinzugefügt](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html) werden. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny", "Effect": "Deny", "Action": "s3:*", "Principal": "*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*", "arn:aws:s3:::amzn-s3-demo-bucket" ], "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name" } } } ] } ``` ------ ## Weitere Informationen Weitere Informationen finden Sie hier: + [Beispiele für Bucket-Richtlinien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) im *Benutzerhandbuch für Amazon Simple Storage Service* + [Beispielrichtlinien für Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) im *Entwicklerhandbuch für Amazon Simple Notification Service* + [Beispiele für Amazon SQS Richtlinien](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) im *Entwicklerhandbuch für Amazon Simple Queue Service* + [Schlüsselrichtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) im *Entwicklerhandbuch für AWS Key Management Service * + [Kontokennungen](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) in der *Allgemeine AWS-Referenz* + [OIDC-Verbund](id_roles_providers_oidc.md)