Beispiele für Richtlinien zum Delegieren des Zugriffs

Die folgenden Beispiele zeigen, wie Sie einem AWS-Konto Zugriff auf die Ressourcen in einem anderen AWS-Konto gewähren können. Informationen zum Erstellen einer IAM-Richtlinie mithilfe dieser Beispiel-JSON-Richtliniendokumente finden Sie unter Erstellen von Richtlinien mit dem JSON-Editor.

Verwenden von Rollen zum Delegieren des Zugriffs auf die Ressourcen in einem anderen AWS-Konto

Ein Tutorial, in dem die Verwendung von IAM-Rollen zur Erteilung der Zugriffsberechtigung von Benutzern in einem Konto auf die AWS-Ressourcen in einem anderen Konto beschrieben wird, finden Sie unter Tutorial: Delegieren des Zugriffs in allen AWS-Konten mithilfe von IAM-Rollen.

Wichtig

Sie können den ARN für eine bestimmte Rolle oder einen bestimmten Benutzer in das Principal-Element einer rollenbasierten Vertrauensrichtlinie einschließen. Wenn Sie die Richtlinie speichern, wandelt AWS den ARN in eine eindeutigen Auftraggeber-ID um. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen der Rolle oder des Benutzers erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da bei der Anzeige der Vertrauensrichtlinie auch eine Rückumwandlung zum ARN erfolgt. Wenn Sie jedoch die Rolle oder den Benutzer löschen, wird die Beziehung aufgehoben. Die Richtlinie wird nicht mehr angewendet, selbst wenn Sie den Benutzer oder 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 Auftraggeber-ID in der Konsole angezeigt, da AWS sie nicht mehr einem ARN zuordnen kann. Das Ergebnis: Wenn Sie einen Benutzer oder eine Rolle löschen und neu erstellen, auf die beide im Principal-Element einer Vertrauensrichtlinie verwiesen wird, müssen Sie die Rolle bearbeiten, um den ARN zu ersetzen. Beim Speichern der Richtlinie wird dieser ARN in die neue Auftraggeber-ID umgewandelt.

Verwenden einer Richtlinie zum Delegieren des Zugriffs auf Services

Das folgende Beispiel zeigt eine Richtlinie, die einer Rolle angefügt werden kann. Die Richtlinie ermöglicht zwei Services, Amazon EMR und AWS Data Pipeline, 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.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Verwendung einer ressourcenbasierten Richtlinie zur Delegation des Zugriffs auf einen Amazon S3-Bucket in einem anderen Konto

In diesem Beispiel verwendet Konto A eine ressourcenbasierte Richtlinie (eine Amazon S3-Bucket-Richtlinie), um dem Konto B vollen Zugriff auf den S3-Bucket in Konto A zu gewähren. Konto B erstellt dann eine IAM-Benutzerrichtlinie, um diesen Zugriff auf den Bucket in Konto A auf einen Benutzer im Konto B zu delegieren.

Die S3-Bucket-Richtlinie in Konto A sieht beispielsweise folgendermaßen. In diesem Beispiel wird der S3-Bucket im Konto A als mybucket bezeichnet und die Kontonummer von Konto B lautet 111122223333. In der Richtlinie werden keine einzelnen Benutzer oder Gruppen in Konto B angegeben, nur das Konto selbst.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

Alternativ kann Konto A Amazon S3-Zugriffskontrolllisten (ACLs) verwenden, um Konto B Zugriff auf einen S3-Bucket oder ein einzelnes Objekt innerhalb eines Buckets zu gewähren. In diesem Fall besteht der einzige Unterschied darin, wie Konto A dem Konto B die Zugriffsberechtigung erteilt. Konto B verwendet unverändert eine Richtlinie, um den Zugriff an eine IAM-Gruppe in Konto B zu delegieren, wie im nächsten Teil des Beispiels beschrieben. Weitere Informationen zur Zugriffkontrolle auf S3-Buckets und Objekte finden Sie unter Access Control im Benutzerhandbuch für Amazon Simple Storage Service.

Das Administrator von Konto B erstellt möglicherweise die folgende Beispielrichtlinie. Die Richtlinie gewährt Lesezugriff auf eine Gruppe oder einen Benutzer in Konto B. Die vorhergehende Richtlinie gewährt Zugriff auf Konto B. Einzelne Gruppen und Benutzer in Konto B haben jedoch erst Zugriff auf die Ressource, nachdem eine Gruppen- oder Benutzerrichtlinie explizit Berechtigungen für die Ressource gewährt hat. Die Berechtigungen in dieser Richtlinie können nur eine Untermenge der Berechtigungen in der vorhergehenden kontoübergreifenden Richtlinie sein. Konto B kann seinen Gruppen und Benutzern nicht mehr Berechtigungen erteilen, als jene, die das Konto A dem Konto B in der ersten Richtlinie erteilt hat. In dieser Richtlinie werden im Element Action explizit nur die Aktionen List zugelassen und das Element Resource in dieser Richtlinie stimmt mit der Resource in der von Konto A eingesetzten Bucketrichtlinie überein.

Zur Implementierung dieser Richtlinie verwendet Konto B IAM, um sie dem entsprechenden Benutzer (oder der entsprechenden Gruppe) in Konto B anzufügen.

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

Verwendung einer ressourcenbasierten Richtlinie zur Delegation des Zugriffs auf eine Amazon SQS-Warteschlange in einem anderen Konto

Im folgenden Beispiel verfügt Konto A über eine Amazon SQS-Warteschlange, die eine der Warteschlange angefügte ressourcenbasierte Richtlinie verwendet, um dem Konto B Zugriff auf die Warteschlange zu gewähren. Konto B verwendet dann eine IAM-Gruppenrichtlinie zum Delegieren des Zugriffs an eine Gruppe in Konto B.

Die folgende Beispielrichtlinie für eine Warteschlange erteilt Konto B die Berechtigung, SendMessage- und ReceiveMessage-Aktionen in der Warteschlange des Kontos A mit dem Namen queue1 ausschließlich am 30. November 2014 zwischen 12:00 und 15:00 Uhr auszuführen. Die Kontonummer des Kontos B lautet 1111-2222-3333. Konto A verwendet Amazon SQS zum Implementieren dieser Richtlinie.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

Die Richtlinie für das Delegieren des Zugriffs auf eine Gruppe in Konto B könnte folgendermaßen aussehen. Konto B verwendet IAM, um die Richtlinie einer Gruppe (oder einem Benutzer) anzufügen.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

Im vorangegangenen Beispiel der IAM-Benutzerrichtlinie verwendet Konto B einen Platzhalter, um seinem Benutzer Zugriff auf alle Amazon SQS-Aktionen in der Warteschlange von Konto A zu gewähren. Konto B kann den Zugriff jedoch nur in dem Umfang delegieren, in dem Konto B Zugriff gewährt wurde. Die Gruppe in Konto B, die über die zweite Richtlinie verfügt, kann nur zwischen 12:00 Uhr und 15:00 Uhr am 30. November 2014 auf die Warteschlange zugreifen. Der Benutzer kann nur die Aktionen SendMessage und ReceiveMessage ausführen, wie in der Amazon SQS-Warteschlangenrichtlinie von Konto A definiert.

Delegieren des Zugriffs ist nicht möglich, wenn dem Konto der Zugriff verweigert wird

Ein AWS-Konto kann den Zugriff auf die Ressourcen eines anderen Kontos nicht delegieren, wenn das andere Konto den Zugriff auf das übergeordnete Konto des Benutzers explizit verweigert. Die Zugriffsverweigerung wird den Benutzern in diesem Konto propagiert, unabhängig davon, ob diese Benutzer über Richtlinien verfügen, die ihnen Zugriffsberechtigungen erteilen.

In Konto A ist beispielsweise eine Bucketrichtlinie für den S3-Bucket in Konto A definiert, die dem Konto B den Zugriff auf den Bucket in Konto A explizit verweigert. Andererseits enthält Konto B eine IAM-Benutzerrichtlinie, die einem Benutzer in Konto B den Zugriff auf den Bucket in Konto A gewährt. Die explizite Zugriffsverweigerung auf den S3-Bucket in Konto A wird den Benutzern in Konto B propagiert. Sie überschreibt die IAM-Benutzerrichtlinie, die dem Benutzer in Konto B die Zugriffsberechtigung erteilt (weitere Informationen, wie Berechtigungen ausgewertet werden, finden Sie unter ). Auswertungslogik für Richtlinien.)

Die Richtlinie des Buckets in Konto A sieht beispielsweise folgendermaßen. In diesem Beispiel wird der S3-Bucket im Konto A als mybucket bezeichnet und die Kontonummer von Konto B lautet 1111-2222-3333. Konto A verwendet Amazon S3; zum Implementieren dieser Richtlinie.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::mybucket/*"
  }
}

Diese explizite Zugriffsverweigerung überschreibt alle Richtlinien in Konto B, die zum Zugriff auf den S3-Bucket in Konto A berechtigen.