Kontoübergreifender Ressourcenzugriff in IAM - AWS Identitäts- und Zugriffsverwaltung

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.

Kontoübergreifender Ressourcenzugriff in IAM

Für einige AWS Dienste können Sie kontenübergreifenden Zugriff auf Ihre Ressourcen gewähren, indem IAM Sie. Dazu können Sie eine Ressourcenrichtlinie direkt an die Ressource anfügen, die Sie freigeben möchten, oder eine Rolle als Proxy verwenden.

Um die Ressource direkt freizugeben, muss die Ressource, die Sie freigeben möchten, ressourcenbasierte Richtlinien unterstützen. Im Gegensatz zu einer identitätsbasierten Richtlinie für eine Rolle legt eine ressourcenbasierte Richtlinie fest, wer (welcher Prinzipal) auf diese Ressource zugreifen kann.

Verwenden Sie eine Rolle als Proxy, wenn Sie auf Ressourcen in einem anderen Konto zugreifen möchten, die keine ressourcenbasierten Richtlinien unterstützen.

Einzelheiten zu den Unterschieden zwischen diesen Richtlinientypen finden Sie unter Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien.

Anmerkung

IAMRollen und ressourcenbasierte Richtlinien delegieren den Zugriff auf Konten nur innerhalb einer einzigen Partition. Beispiel: Sie haben ein Konto in USA West (Nordkalifornien) in der Standardpartition aws. Sie haben auch ein Konto in China in der Partition aws-cn. Sie können in Ihrem Konto in China keine ressourcenbasierte Richtlinie verwenden, um Benutzern in Ihrem Standardkonto Zugriff zu gewähren. AWS

Kontoübergreifender Zugriff mithilfe von Rollen

Nicht alle AWS Dienste unterstützen ressourcenbasierte Richtlinien. Für diese Dienste können Sie kontenübergreifende IAM Rollen verwenden, um die Berechtigungsverwaltung zu zentralisieren, wenn Sie kontenübergreifenden Zugriff auf mehrere Dienste gewähren. Eine kontenübergreifende IAM Rolle ist eine IAM Rolle, die eine Vertrauensrichtlinie beinhaltet, die es IAM Prinzipalen in einem anderen AWS Konto ermöglicht, die Rolle zu übernehmen. Einfach ausgedrückt können Sie in einem Konto eine Rolle erstellen, die bestimmte Berechtigungen an ein anderes AWS AWS Konto delegiert.

Informationen zum Anhängen einer Richtlinie an eine IAM Identität finden Sie unterIAMRichtlinien verwalten.

Anmerkung

Wenn ein Prinzipal zu einer Rolle wechselt, um vorübergehend die Berechtigungen der Rolle zu nutzen, gibt er seine ursprünglichen Berechtigungen auf und übernimmt die Berechtigungen, die der Rolle zugewiesen wurden, die er angenommen hat.

Lassen Sie uns einen Blick auf den Gesamtprozess werfen, der für APN Partnersoftware gilt, die auf ein Kundenkonto zugreifen muss.

  1. Der Kunde erstellt in seinem eigenen Konto eine IAM Rolle mit einer Richtlinie, die den Zugriff auf die Amazon S3 S3-Ressourcen ermöglicht, die der APN Partner benötigt. In diesem Beispiel lautet der Rollenname APNPartner.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] }
  2. Anschließend gibt der Kunde an, dass die Rolle vom AWS Konto des Partners übernommen werden kann, indem er die APN AWS-Konto Partner-ID in der Vertrauensrichtlinie für die APNPartner Rolle angibt.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] }
  3. Der Kunde gibt dem APN Partner den Amazon-Ressourcennamen (ARN) der Rolle. Das ARN ist der vollqualifizierte Name der Rolle.

    arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner
    Anmerkung

    Wir empfehlen, in Situationen mit mehreren Mandanten eine externe ID zu verwenden. Details hierzu finden Sie unter Zugriff auf AWS-Konten Eigentum Dritter.

  4. Wenn die Software des APN Partners auf das Konto des Kunden zugreifen muss, ruft die AssumeRoleAPISoftware das AWS Security Token Service zusammen mit ARN der Rolle im Kundenkonto auf. STSgibt einen temporären AWS Berechtigungsnachweis zurück, der es der Software ermöglicht, ihre Arbeit zu erledigen.

Ein weiteres Beispiel für die Gewährung von kontoübergreifendem Zugriff mithilfe von Rollen finden Sie unter Zugriff für einen IAM Benutzer in einem anderen AWS-Konto , den Sie besitzen. Sie können auch dem IAMTutorial: Delegieren Sie den Zugriff über AWS Konten hinweg mithilfe von Rollen IAM folgen.

Kontoübergreifender Zugriff mit ressourcenbasierten Richtlinien

Wenn ein Konto über ein anderes Konto unter Verwendung einer ressourcenbasierten Richtlinie auf eine Ressource zugreift, funktioniert der Prinzipal weiterhin mit dem vertrauenswürdigen Konto und muss seine Berechtigungen nicht aufgeben, um die Rollenberechtigungen zu erhalten. Mit anderen Worten, der Prinzipal hat nach wie vor Zugriff auf Ressourcen im vertrauenswürdigen Konto, aber gleichzeitig auch Zugriff auf die Ressource im vertrauenden Konto. Dies ist nützlich für Aufgaben wie das Kopieren von Daten in die oder aus der gemeinsam genutzten Ressource im anderen Konto.

Zu den Prinzipalen, die Sie in einer ressourcenbasierten Richtlinie angeben können, gehören Konten, IAM Benutzer, Verbundbenutzer, IAM Rollen, Sitzungen mit übernommenen Rollen oder Dienste. AWS Weitere Informationen finden Sie unter Angeben eines Auftraggebers.

Informationen darüber, ob Prinzipalen in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter Identifizieren von Ressourcen, die mit einer externen Entität geteilt wurden.

Die folgende Liste enthält einige AWS Dienste, die ressourcenbasierte Richtlinien unterstützen. Eine vollständige Liste der wachsenden Anzahl von AWS Diensten, die das Anhängen von Berechtigungsrichtlinien an Ressourcen statt an Prinzipale unterstützen, finden Sie unter AWS Dienste, die funktionieren mit IAM und suchen Sie in der Spalte Ressourcenbasiert nach den Diensten, für die Ja angegeben ist.

  • Amazon-S3-Buckets – Die Richtlinie ist dem Bucket angefügt, allerdings steuert die Richtlinie sowohl den Zugriff auf den Bucket als auch auf die darin befindlichen Objekte. Weitere Informationen finden Sie unter Bucket-Richtlinien für Amazon S3 im Amazon Simple Storage Service-Benutzerhandbuch. In einigen Fällen kann es sinnvoll sein, Rollen für den kontoübergreifenden Zugriff auf Amazon S3 zu verwenden. Weitere Informationen finden Sie in den Beispiel-Walkthroughs im Benutzerhandbuch für Amazon Simple Storage Service.

  • Themen zu Amazon Simple Notification Service (AmazonSNS) — Weitere Informationen finden Sie unter Beispielfälle für Amazon SNS Access Control im Amazon Simple Notification Service Developer Guide.

  • Amazon Simple Queue Service (AmazonSQS) -Warteschlangen — Weitere Informationen finden Sie im Anhang: Die Sprache der Zugriffsrichtlinien im Amazon Simple Queue Service Developer Guide.

Ressourcenbasierte Richtlinien zum Delegieren von Berechtigungen AWS

Wenn eine Ressource den Prinzipalen in Ihrem Konto Berechtigungen gewährt, können Sie diese Berechtigungen anschließend an bestimmte Identitäten delegieren. IAM Identitäten sind Benutzer, Benutzergruppen oder Rollen in Ihrem Konto. Sie delegieren Berechtigungen, indem Sie eine Richtlinie mit der Identität verknüpfen. Sie können maximal die vom ressourcenbesitzenden Konto gewährten Berechtigungen gewähren.

Wichtig

Beim kontoübergreifenden Zugriff benötigt ein Prinzipal Allow in der Identitätsrichtlinie und der ressourcenbasierte Richtlinie.

Nehmen Sie an, dass eine ressourcenbasierte Richtlinie allen Auftraggeber in Ihrem Konto vollen administrativen Zugriff auf eine Ressource gewährt. Anschließend können Sie Vollzugriff, Lesezugriff oder beliebigen anderen Teilzugriff an die Prinzipale in Ihrem Konto delegieren. AWS Wenn die ressourcenbasierte Richtlinie nur Listenberechtigungen gewährt, können Sie alternativ nur den Listenzugriff delegieren. Wenn Sie versuchen, mehr Berechtigungen zu delegieren, als Ihr Konto hat, haben Ihre Auftraggeber immer noch nur Listenzugriff.

Weitere Informationen darüber, wie diese Entscheidungen getroffen werden, finden Sie unter Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird.

Anmerkung

IAMRollen und ressourcenbasierte Richtlinien delegieren den Zugriff auf Konten nur innerhalb einer einzigen Partition. Beispielsweise können Sie keinen kontenübergreifenden Zugriff zwischen einem Konto in der aws-Standardpartition und einem Konto in der aws-cn-Partition hinzufügen.

Nehmen Sie beispielsweise an, dass Sie AccountA und AccountB verwalten. In KontoA haben Sie einen Amazon-S3-Bucket mit dem Namen BucketA.

Eine ressourcenbasierte Richtlinie, die für den Amazon-S3-Bucket erstellt wurde, gewährt KontoB Berechtigungen für KontoAA.
  1. Sie weisen BucketA eine ressourcenbasierte Richtlinie zu, die allen Prinzipalen in KontoB Vollzugriff auf Objekte in Ihrem Bucket gewährt. Sie können beliebige Objekte in diesem Bucket erstellen, lesen oder löschen.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::AccountB:root"}, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] }

    KontoA gewährt KontoB durch die Benennung von KontoA als Prinzipal in der ressourcenbasierten Richtlinie Vollzugriff auf BucketA. Dadurch ist KontoB berechtigt, alle Aktionen im Bucket über KontoA auszuführen und der KontoB-Administrator kann seinen Benutzern in KontoB den Zugriff erteilen.

    Der Root-Benutzer von KontoB verfügt über alle Berechtigungen, die dem Konto gewährt werden. Daher hat der Root-Benutzer Vollzugriff auf BucketA.

  2. Hängen Sie in AccountB eine Richtlinie an den IAM Benutzer mit dem Namen User2 an. Diese Richtlinie erlaubt dem Benutzer nur Lesezugriff auf die Objekte in BucketA. Das bedeutet, dass Benutzer2 die Objekte anzeigen, aber nicht erstellen, bearbeiten oder löschen kann.

    { "Version": "2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] }

    Die maximale Zugriffsebene, die KontoB delegieren kann, ist die Zugriffsebene, die dem Konto gewährt wird. In diesem Fall gewährt die ressourcenbasierte Richtlinie KontoB Vollzugriff, aber Benutzer2 wird nur der schreibgeschützte Zugriff gewährt.

    Der KontoB-Administrator gewährt Benutzer1 keinen Zugriff. Standardmäßig haben Benutzer keine Berechtigungen, außer denen, die ausdrücklich gewährt werden, sodass Benutzer1 keinen Zugriff auf BucketA hat.

IAMwertet die Berechtigungen eines Prinzipals zu dem Zeitpunkt aus, zu dem der Principal eine Anfrage stellt. Wenn Sie Platzhalter (*) verwenden, um Benutzern vollen Zugriff auf Ihre Ressourcen zu gewähren, können Prinzipale auf alle Ressourcen zugreifen, auf die Ihr AWS Konto Zugriff hat. Dies gilt auch für Ressourcen, die Sie nach der Erstellung der Benutzerrichtlinie hinzufügen oder auf die Sie Zugriff erhalten.

Hätte KontoB im vorhergehenden Beispiel eine Richtlinie an Benutzer2 angefügt, die Vollzugriff auf alle Ressourcen in allen Konten gewährt, hätte Benutzer2 automatisch Zugriff auf alle Ressourcen, auf die KontoB Zugriff hat. Dies schließt den BucketA-Zugriff und den Zugriff auf alle anderen Ressourcen ein, die durch ressourcenbasierte Richtlinien in KontoA gewährt werden.

Weitere Hinweise zur komplexen Verwendung von Rollen, z. B. zum Gewähren von Zugriff auf Anwendungen und Services, finden Sie unter Allgemeine Szenarien für IAM Rollen.

Wichtig

Gewähren Sie nur Zugriff auf Entitäten, denen Sie vertrauen, und gewähren Sie nur das erforderliche Mindestmaß an Zugriff. Wenn es sich bei der vertrauenswürdigen Entität um ein anderes AWS Konto handelt, kann jedem IAM Prinzipal Zugriff auf Ihre Ressource gewährt werden. Das vertrauenswürdige AWS Konto kann den Zugriff nur in dem Umfang delegieren, in dem ihm Zugriff gewährt wurde. Es kann nicht mehr Zugriff delegieren, als dem Konto selbst gewährt wurde.

Weitere Informationen über Berechtigungen, Richtlinien und die Sprache der Berechtigungsrichtlinie, mit der Sie die Richtlinien erstellen, finden Sie unter Zugriffsmanagement für AWS Ressourcen.