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 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?.

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.

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:

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" 
  ]
}

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: :rootaccount-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.

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 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.

Um die Rolle ARN im Principal-Element anzugeben, verwenden Sie das folgende Format:

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

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 der Bedingungsschlüssel AWS ARNs nicht konvertiert wird IDs, bleiben die dem 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 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.

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 Sitzungsprinzipal mit angenommener Rolle ist ein Sitzungsprinzipal, der sich aus der Verwendung des Vorgangs ergibt. AWS STS AssumeRole Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter AWS STS Referenzen 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.

Verbundene OIDC-Prinzipale

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

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 JWT-Token sein, das mit einer anderen Methode bereitgestellt wird, sofern es die unter aufgeführten Anforderungen erfüllt. AWS STS Weitere Informationen finden Sie unter Allgemeine Szenarien und Anfordern von Anmeldeinformationen über einen OIDC-Anbieter.

Verwenden Sie diesen Prinzipaltyp in Ihrer Rollenvertrauensrichtlinie, um Anrufberechtigungen AssumeRoleWIthWebIdentity über einen OIDC-IDP, der in Ihrem System oder einem der vier integrierten Systeme vorhanden ist AWS-Konto, zuzulassen oder zu verweigern. 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 GitHub es sich beispielsweise um den vertrauenswürdigen Web-Identitätsanbieter handelt, verwendet der ARN der OIDC-Rollensitzung 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 Konfiguration von OpenID Connect in Amazon Web Services.

OIDC-Verbundprinzipale werden in anderen Richtlinientypen als Rollenvertrauensrichtlinien nicht unterstützt.

Verbundene SAML-Prinzipale

Ein SAML-Verbundprinzipal ist ein Prinzipal, der verwendet wird, wenn die AWS STS AssumeRoleWithSAML API aufgerufen wird, um mithilfe einer SAML-Assertion temporäre AWS Anmeldeinformationen anzufordern. Sie können Ihren SAML-Identitätsanbieter (IDP) verwenden, um sich anzumelden, und dann mithilfe dieses Vorgangs eine IAM-Rolle übernehmen. Ähnlich wieAssumeRoleWithWebIdentity, erfordert AssumeRoleWithSAML keine AWS 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 Management Console Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter AWS STS Referenzen vergleichen.

Verwenden Sie diesen Prinzipaltyp in Ihrer Rollenvertrauensrichtlinie, um Berechtigungen auf der Grundlage des vertrauenswürdigen SAML-Identitätsanbieters zuzulassen 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.

"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.

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.

AWS STS föderierte Benutzerprinzipale

Sie können Verbundbenutzersitzungen im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen.

Ein AWS STS föderierter Benutzerprinzipal wird durch den GetFederationToken Vorgang erstellt, der mit langlebigen IAM-Anmeldeinformationen aufgerufen wird. Verbundbenutzerberechtigungen sind die Schnittstelle zwischen dem aufrufenden Principal GetFederationToken und den Sitzungsrichtlinien, die als Parameter an die API übergeben wurden. GetFederationToken

In Root-Benutzer des AWS-Kontos können AWS sich IAM-Benutzer oder ein Unternehmen mit langfristigen Zugriffsschlüsseln authentifizieren. Weitere Informationen zum Verbünden von Prinzipalen mittles dieser Produktion finden Sie unter AWS STS Referenzen vergleichen.

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. 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.

Der Dienstauftraggeber wird durch den Service definiert. Sie können den Dienstauftraggeber für einige Services finden, indem Sie AWS Dienste, die mit IAM funktionieren öffnen, überprüfen, ob der Service in der Spalte Service-linked role (Serviceverknüpfte Rolle) Yes (Ja) hat, und den Link Yes (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-ReferenzLeitfaden unter AWS Regionen verwalten.

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.

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.

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 S3-Bucket hinzugefügt 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: