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.

Angeben eines Auftraggebers

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:: Account-ID:root) 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 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 Sitzungsanmeldedaten für die Ausführung von Vorgängen verwenden AWS, werden sie zu einer Rolle als Sitzungsprinzipal.

IAM-Rollen sind Identitäten, die in IAM existieren. Rollen vertrauen einer anderen authentifizierten Identität, z. B. einem Prinzipal in einem externen Identitätsanbieter AWS oder einem Benutzer von einem externen Identitätsanbieter. Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhält er temporäre Sicherheitsanmeldeinformationen. Sie können diese Anmeldeinformationen dann als Rollensitzungsprinzipal verwenden, um Vorgänge in AWS durchzuführen.

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 Bedingungsschlüssel-ARNs AWS nicht in IDs konvertiert werden, 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 (*) 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 Vergleich der AWS STS API-Operationen.

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

Ein OIDC-Sitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung des Vorgangs ergibt. AWS STS AssumeRoleWithWebIdentity Sie können einen externen OIDC-Anbieter (IdP) verwenden, um sich anzumelden, und dann mit diesem Vorgang eine IAM-Rolle annehmen. Dies nutzt den Identitätsverbund und gibt eine Rollensitzung aus. Weitere Informationen darüber, welche Prinzipale bei dieser Produktion eine Rolle übernehmen können, finden Sie unter Vergleich der AWS STS API-Operationen.

Wenn Sie eine Rolle von einem OIDC-Anbieter ausgeben, erhalten Sie diesen speziellen Sitzungsprinzipaltyp, der Informationen über den OIDC-Anbieter enthält.

Verwenden Sie diesen Prinziptyp in Ihrer Richtlinie, um den Zugriff basierend auf dem vertrauenswürdigen Web-Identitätsanbieter zuzulassen oder abzulehnen. Verwenden Sie das folgende Format, um den ARN der OIDC-Rollensitzung im Principal Element einer Rollenvertrauensrichtlinie anzugeben:

"Principal": { "Federated": "cognito-identity.amazonaws.com" }

"Principal": { "Federated": "www.amazon.com" }

"Principal": { "Federated": "graph.facebook.com" }

"Principal": { "Federated": "accounts.google.com" }

SAML-Sitzungssprinzipale

Ein SAML-Sitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung des Vorgangs ergibt. AWS STS AssumeRoleWithSAML Sie können sich mit einem externen SAML-Identitätsanbieter (IdP) anmelden und dann mit dieser Produktion eine IAM-Rolle übernehmen. Dies nutzt den Identitätsverbund und gibt eine Rollensitzung aus. Weitere Informationen darüber, welche Prinzipale bei dieser Produktion eine Rolle übernehmen können, finden Sie unter Vergleich der AWS STS API-Operationen.

Wenn Sie eine Rolle von einem SAML-Identitätsanbieter ausstellen, erhalten Sie diesen speziellen Typ von Vortrasprinzipal, der Informationen über den SAML-Identitätsanbieter enthält.

Verwenden Sie diesen Prinziptyp in Ihrer Richtlinie, um den Zugriff basierend auf dem vertrauenswürdigen SAML-Identitätsanbieter zuzulassen oder abzulehnen. 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 Prinzipale für föderierte Benutzersitzungen

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

Ein AWS STS föderierter Benutzersitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung des AWS STS GetFederationToken Vorgangs ergibt. In diesem Fall verwendet AWS STS Identitätsverbund als Methode, um temporäre Zugriffstoken zu erhalten, anstatt IAM-Rollen zu verwenden.

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 Vergleich der AWS STS API-Operationen.

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 Dienstprinzipal in einer IAM-Richtlinie kann das nicht sein. "Service": "*"

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 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 Serviceprinzipale 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 Spezifizieren von NotPrincipal mit Deny verwendet werden kann, um alle Prinzipale mit Ausnahme der im Element Condition angegebenen ausdrücklich abzulehnen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::BUCKETNAME/*",
        "arn:aws:s3:::BUCKETNAME"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
        }
      }
    }
  ]
}

Weitere Informationen

Weitere Informationen finden Sie hier: