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 JSONpolitische Elemente: Principal

Verwenden Sie das Principal Element in einer ressourcenbasierten JSON Richtlinie, um den Prinzipal anzugeben, dem der Zugriff auf eine Ressource gewährt oder verweigert wird.

Sie müssen das Principal-Element in ressourcenbasierten Richtlinien verwenden. Verschiedene Dienste unterstützen ressourcenbasierte Richtlinien, darunter. IAM Der IAM ressourcenbasierte Richtlinientyp ist eine Rollenvertrauensrichtlinie. Verwenden Sie in IAM Rollen das Principal Element in der Rollenvertrauensrichtlinie, um anzugeben, wer die 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 Prinzipale in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder vertrauenswürdiges Konto) Zugriff haben, um Ihre Rollen zu übernehmen, finden Sie unter Was ist IAM Access Analyzer? .

Andere Beispiele für Ressourcen, die ressourcenbasierte Richtlinien unterstützen, sind ein Amazon S3 S3-Bucket oder AWS KMS key.

Sie können das Element Principal nicht in einer identitätsbasierten Richtlinie verwenden. Identitätsbasierte Richtlinien sind Berechtigungsrichtlinien, die Sie IAM Identitäten (Benutzern, Gruppen oder Rollen) zuordnen. In diesen Richtlinien wird der Prinzipal von der Identität impliziert, der der Richtlinie angefügt ist.

Wie spezifiziert man einen Prinzipal

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 in einer Richtlinie (z. B. einer ressourcenbasierten Richtlinie) nicht als Prinzipal identifizieren, da sich Gruppen auf Berechtigungen und nicht auf Authentifizierung beziehen und Prinzipale authentifizierte Entitäten sind. IAM

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 Prinzipale

Sie können Folgendes angeben AWS-Konto Bezeichner im Principal Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen. Dadurch wird die Autorität des Kontos delegiert. Wenn Sie den Zugriff auf ein anderes Konto zulassen, muss ein Administrator dieses Kontos dann Zugriff auf eine Identität (IAMBenutzer oder Rolle) in diesem Konto gewähren. Wenn Sie eine angeben AWS-Konto, können Sie das Konto verwenden ARN (arn:aws:iam::account-ID:root) oder eine verkürzte Form, 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" }

Das Konto ARN und die verkürzte Konto-ID verhalten sich genauso. Beide delegieren Berechtigungen für das Konto. Durch die Verwendung des Kontos ARN im Principal Element werden die Berechtigungen nicht nur auf den Root-Benutzer des Kontos beschränkt.

Etwas 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 auch mehr als einen angeben AWS-Konto, (oder kanonische Benutzer-ID) als Principal unter Verwendung eines Arrays. 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"
}

IAMRollenprinzipale

Sie können IAM Rollenprinzipale ARNs im Principal Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. IAMRollen sind Identitäten. In sind Identitäten RessourcenIAM, denen Sie Berechtigungen zuweisen können. Rollen vertrauen einer anderen authentifizierten Identität, um diese Rolle zu übernehmen. Dazu gehört ein Principal in AWS oder ein Benutzer von einem externen Identitätsanbieter (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 verwenden, um Operationen auszuführen in AWS, werden sie zu einer Rolle als Sitzungsprinzipal.

IAMRollen sind Identitäten, die in IAM existieren. Rollen vertrauen einer anderen authentifizierten Identität, z. B. einem Principal in AWS oder ein 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 Rollen-Sitzungsprinzipal verwenden, um Operationen auszuführen in AWS.

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.

Verwenden Sie das folgende Format, um die Rolle ARN im Principal Element anzugeben:

"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, werden dem Hauptbenutzer der Rollensitzung die Berechtigungen erteilt, die auf ARN der Rolle basieren, die übernommen wurde, und nicht auf der Rolle ARN der resultierenden Sitzung. Weil AWS konvertiert den Bedingungsschlüssel ARNs nicht inIDs, die der Rolle gewährten Berechtigungen ARN bleiben 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 verwenden, um Operationen auszuführen in AWS, werden sie zu einer Rolle als Sitzungsprinzipal.

Das Format, das Sie für einen Rollensitzungsprinzipal verwenden, hängt von AWS STS Vorgang, der zur Übernahme der Rolle verwendet 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 Rolle ARN als Principal 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 IAMRollenprinzipale.

Sitzungsauftraggeber mit übernommener Rolle

Ein Sitzungsprinzipal mit angenommener Rolle ist ein Sitzungsprinzipal, der sich aus der Verwendung von AWS STS AssumeRoleOperation. Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter AWS STS Referenzen vergleichen.

Verwenden Sie das folgende Format, um die Sitzung mit angenommener Rolle ARN im Principal Element anzugeben:

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

OIDCSitzungsprinzipale

Ein OIDCSitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung von AWS STS AssumeRoleWithWebIdentityOperation. Sie können einen externen OIDC Anbieter (IdP) verwenden, um sich anzumelden, und dann mithilfe dieses Vorgangs 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 AWS STS Referenzen vergleichen.

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 die OIDC Rollensitzung ARN 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" }

SAMLSitzungsprinzipale

Ein SAMLSitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung von AWS STS AssumeRoleWithSAMLOperation. Sie können einen externen SAML Identitätsanbieter (IdP) verwenden, um sich anzumelden, und dann mithilfe dieses Vorgangs 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 AWS STS Referenzen vergleichen.

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

Verwenden Sie diesen Prinzipaltyp in Ihrer Richtlinie, um den Zugriff auf der Grundlage des vertrauenswürdigen SAML Identitätsanbieters zuzulassen oder zu verweigern. Verwenden Sie das folgende Format, um die SAML Identitätsrollensitzung ARN im Principal Element einer Rollenvertrauensrichtlinie anzugeben:

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

IAMBenutzerprinzipale

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.

IAMIdentity Center-Prinzipale

In IAM Identity Center muss der Prinzipal in einer ressourcenbasierten Richtlinie definiert werden als AWS-Konto Prinzipal. Um den Zugriff zu spezifizieren, verweisen Sie im Bedingungsblock auf die Rolle ARN des Berechtigungssatzes. Einzelheiten finden Sie unter Referenzieren von Berechtigungssätzen in RessourcenrichtlinienEKS, Amazon und AWS KMSim IAMIdentity Center-Benutzerhandbuch.

AWS STS Hauptbenutzer verbundener Benutzersitzungen

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

Ein AWS STS Der Sitzungsprinzipal für Verbundbenutzer ist ein Sitzungsprinzipal, der sich aus der Verwendung von ergibt AWS STS GetFederationTokenOperation. In diesem Fall AWS STS verwendet den Identitätsverbund als Methode, um temporäre Zugriffstoken zu erhalten, anstatt IAM Rollen zu verwenden.

In AWS, IAM Benutzer oder ein Root-Benutzer des AWS-Kontos kann sich mit langfristigen Zugangsschlü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 von anfordert AWS STS Mit diesem Vorgang beginnen sie eine temporäre Verbundbenutzersitzung. Die dieser Sitzung ARN basiert auf der ursprünglichen Identität, die zusammengeführt wurde.

Verwenden Sie das folgende Format, um die Verbundbenutzersitzung ARN im Principal Element anzugeben:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }

AWS Dienstprinzipale

Sie können angeben AWS Dienste im Principal Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen. Ein Service-Prinzipal ist eine Kennung für einen Service.

IAMRollen, die von einem übernommen werden können AWS Dienste 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 Dienstprinzipal in einer IAM Richtlinie kann nicht sein"Service": "*".

Der Dienstauftraggeber wird durch den Service definiert. Sie können den Dienstauftraggeber für einige Services finden, indem Sie AWS Dienste, die funktionieren mit IAM ö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. Die Richtlinie ermöglicht es zwei Diensten, Amazon ECS und Elastic Load Balancing, die Rolle zu übernehmen. 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 Service-Principals in Opt-in-Regionen

Sie können Ressourcen in mehreren Ländern starten AWS Regionen und einige dieser Regionen, für die Sie sich anmelden müssen. Eine vollständige Liste der Regionen, für die Sie sich anmelden müssen, finden Sie unter Verwalten AWS Regionen in der Allgemeine AWS-ReferenzFührer.

Wann ein AWS Ein Dienst in einer Opt-in-Region stellt eine Anfrage innerhalb derselben Region, wird das Format des Dienstprinzipalnamens als die nicht regionalisierte Version seines Dienstprinzipalnamens identifiziert:

service-name.amazonaws.com

Wenn ein AWS Ein Dienst in einer Opt-in-Region stellt eine regionsübergreifende Anfrage an eine andere Region, wird das Format des Dienstprinzipalnamens als die regionalisierte Version seines Dienstprinzipalnamens identifiziert:

service-name.{region}.amazonaws.com

Sie haben beispielsweise ein SNS Amazon-Thema in Region ap-southeast-1 und einen Amazon S3-Bucket in der Opt-in-Regionap-east-1. Sie möchten S3-Bucket-Benachrichtigungen so konfigurieren, dass Nachrichten zu SNS diesem Thema veröffentlicht werden. Damit der S3-Dienst Nachrichten zu dem SNS Thema posten kann, müssen Sie dem S3-Dienstprinzipal über die ressourcenbasierte Zugriffsrichtlinie des Themas die sns:Publish entsprechende Berechtigung 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-Dienstprinzipal im Policy-Element des Principal SNS Themas Access Policy 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 Ein Dienst in einer Opt-in-Region stellt eine Anfrage an eine andere Region. Wenn der Bucket nach der Angabe des regionalisierten Dienstprinzipalnamens eine sns:Publish Anfrage zu einem SNS Thema in einer anderen Region sendet, ist die Anfrage erfolgreich. Im folgenden Beispiel wird der regionalisierte S3-Dienstprinzipal im Policy-Element des SNS Themas Access Principal Policy 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 in Ihrem Konto 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 einem Teil eines Prinzipalnamens oder zuzuordnen. ARN

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