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 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?.
Anmerkung
Nachdem Sie die Rolle erstellt haben, können Sie das Konto zu „*“ ä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!
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.
Themen
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-Services
-
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-Prinzipale
Sie können AWS-Konto-Kennungen 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 ein AWS-Konto angeben, können Sie den Konto-ARN (arn:aws:iam::account-ID:root) oder eine Kurzform verwenden, die aus dem "AWS":-Präfix, gefolgt von der Konto-ID, besteht.
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-Services unterstützen zusätzliche Optionen für die Angabe eines Kontoauftraggebers. Bei Amazon S3 können Sie beispielsweise eine kanonische Benutzer-ID in folgendem Format angeben:
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }Sie können auch mehr als ein AWS-Konto angeben (oder kanonische Benutzer-ID) als Prinzipal, der ein Array verwendet. 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 IAM-Rollenprinzipal-ARNs im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, 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 Sitzungsanmeldeinformationen verwenden, um Vorgänge in AWS auszuführen, werden sie Rollensitzungsprinzipal.
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.
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 AWS sie nicht mehr einem gültigen ARN zuordnen 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 Understanding AWS's Handling of Deleted IAM roles in Policies
Alternativ können Sie den Rollenprinzipal als Prinzipal in einer ressourcenbasierten Richtlinie angeben oder erstellen Sie eine Richtlinie mit breiter Berechtigung 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 AWS-Bedingungsschlüssel-ARNs nicht in IDs konvertiert, bleiben die für die Rollen-ARN erteilten 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 (*) 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 Sitzungsanmeldeinformationen verwenden, um Vorgänge in AWS durchzuführen, werden sie Rollensitzungsprinzipal.
Das Format, das Sie für einen Rollensitzungsprinzipal verwenden, hängt von der AWS STS-Produktion ab, die verwendet wurde, um die Rolle zu übernehmen.
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.
Sitzungsauftraggeber mit übernommener Rolle
Ein Prinzipal mit angenommener Rollensitzung ist ein Sitzungssprinzipal, der sich aus der Verwendung der AWS STS-AssumeRole-Produktion ergibt. Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter AWS STS-Anmeldeinformationen vergleichen.
Um den ARN mit angenommener Rollensitzung im Principal-Element anzugeben, verwenden Sie das folgende Format:
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
Wenn Sie eine Sitzung mit übernommener Rolle in einem Principal-Element angeben, können Sie keinen Platzhalter „*“ verwenden, der "alle Sitzungen" bedeutet. Auftraggeber müssen immer eine bestimmte Sitzung benennen.
OIDC-Verbundprinzipale
Ein OIDC-Verbundprinzipal ist der Prinzipal, der verwendet wird, wenn die AssumeRoleWithWebIdentity-API von AWS STS mit einem JSON-Web-Token (JWT) von einem OIDC-kompatiblen IDP, auch bekannt als OpenID Provider (OP), aufgerufen wird, um temporäre AWS-Anmeldeinformationen anzufordern. Ein OIDC-Verbundprinzipal kann einen OIDC-IDP in Ihrem AWS-Konto oder die 4 integrierten Identitätsanbieter darstellen: Login with Amazon, Google, Facebook und Amazon Cognito.
Benutzer, Workloads oder Systeme, denen von ihrem OIDC-IDP ein JWT ausgestellt wurde, können AssumeRoleWithWebIdentity mithilfe des JWT aufrufen, um temporäre AWS-Sicherheitsanmeldeinformationen 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 erfüllt. Weitere Informationen finden Sie unter Gängige Szenarien und Anmeldeinformationen über einen OIDC-Anbieter anfordern.
Verwenden Sie diesen Prinzipaltyp in Ihrer Rollenvertrauensrichtlinie, um Berechtigungen für den Aufruf von AssumeRoleWIthWebIdentity über einen in Ihrem AWS-Konto vorhandenen OIDC-IDP oder einen der vier integrierten IDPs zu erteilen oder zu verweigern. Um den ARN des OIDC-Verbundprinzipals im Principal-Element einer Rollenvertrauensrichtlinie anzugeben, verwenden Sie eines der folgenden vier Formate für die integrierten 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, z. B. GitHub, geben Sie 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
OIDC-Verbundprinzipale werden in anderen Richtlinientypen als Rollenvertrauensrichtlinien nicht unterstützt.
SAML-Verbundprinzipale
Ein SAML-Verbundprinzipal ist ein Prinzipal, der beim Aufrufen der AssumeRoleWithSAML-API von AWS STS verwendet wird, um temporäre AWS-Anmeldeinformationen mithilfe einer SAML-Assertion 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 keine AWS-Anmeldeinformationen zur Authentifizierung. Stattdessen authentifizieren sich Benutzer zunächst bei ihrem SAML-Identitätsanbieter und führen dann den AssumeRoleWithSAML-API-Aufruf mit ihrer SAML-Assertion durch oder werden zur AWS-Anmelde-/SAML-Seite weitergeleitet, um sich bei der AWS-Managementkonsole anzumelden. Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter AWS STS-Anmeldeinformationen vergleichen.
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) 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 AWS sie nicht mehr einem gültigen ARN zuordnen 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 im Benutzerhandbuch zu IAM Identity Center.
Verbundbenutzer-Prinzipale von AWS STS
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 Verbundbenutzersitzungen von AWS STS einzuschränken. Verwenden Sie stattdessen IAM-Rollen.
Ein Verbundbenutzer-Prinzipal von AWS STS 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 AWS können sich IAM-Benutzer oder ein Root-Benutzer des AWS-Kontos mit langfristigen Zugriffsschlüsseln authentifizieren. Weitere Informationen zum Verbünden von Prinzipalen mittles dieser Produktion finden Sie unter AWS STS-Anmeldeinformationen vergleichen.
-
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 Stammbenutzer temporäre Anmeldeinformationen von AWS STS mit diesem Vorgang anfordert, beginnen sie eine temporäre Verbundbenutzersitzung. 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-Dienstauftraggeber
Sie können AWS-Services im 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 AWS-Dienst übernommen werden können, werden als -Servicerollen bezeichnet. 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-Services, die mit IAM funktionieren ö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-Serviceprinzipale in Opt-in-Regionen
Sie können Ressourcen in mehreren AWS-Regionen starten. Für einige dieser Regionen müssen Sie sich anmelden. Eine vollständige Liste der Regionen, für die Sie sich anmelden müssen, finden Sie im Allgemeine AWS-Referenz-Handbuch unter AWS-Regionen verwalten.
Wenn ein AWS-Service in einer Opt-In-Region eine Anfrage innerhalb derselben Region stellt, wird das Format des Serviceprinzipalnamens als die nicht regionalisierte Version seines Serviceprinzipalnamens erkannt:
service-name.amazonaws.com
Wenn ein AWS-Service in einer Opt-In-Region eine regionsübergreifende Anfrage stellt, wird das Format des Serviceprinzipalnamens als die regionalisierte Version seines Serviceprinzipalnamens erkannt:
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 Namen des Serviceprinzipals verwenden, wenn ein AWS-Service in einer Opt-In-Region eine Anfrage an eine andere Region stellt. 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 (*) verwenden, um alle Prinzipale im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, anzugeben. Ressourcenbasierte Richtlinien Erteilungs-Berechtigungen und Bedingungsschlüssel werden verwendet, um die Bedingungen einer Richtlinienanweisung einzuschränken.
Wichtig
Es wird ausdrücklich empfohlen, keinen Platzhalter (*) 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 (*) 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 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 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 werden.
Weitere Informationen
Weitere Informationen finden Sie hier:
-
Beispiele für Bucket-Richtlinien im Benutzerhandbuch für Amazon Simple Storage Service
-
Beispielrichtlinien für Amazon SNS im Entwicklerhandbuch für Amazon Simple Notification Service
-
Beispiele für Amazon SQS Richtlinien im Entwicklerhandbuch für Amazon Simple Queue Service
-
Schlüsselrichtlinien im Entwicklerhandbuch für AWS Key Management Service
-
Kontokennungen in der Allgemeine AWS-Referenz
