Beispiele für Richtlinien zum Delegieren des Zugriffs

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

Verwenden von Rollen, um den Zugriff auf die Ressourcen einer anderen Person zu delegieren AWS-Konto Ressourcen

Für ein Tutorial, das zeigt, wie Sie Benutzern in einem Konto mithilfe von IAM Rollen Zugriff gewähren auf AWS Ressourcen, die sich in einem anderen Konto befinden, finden Sie unterIAMTutorial: Delegieren des Zugriffs in allen AWS -Konten mithilfe von Rollen IAM.

Wichtig

Sie können das ARN für eine bestimmte Rolle oder einen bestimmten Benutzer in das Principal Element einer Rollenvertrauensrichtlinie aufnehmen. Wenn Sie die Richtlinie speichern, AWS wandelt das in eine eindeutige Prinzipal-ID ARN um. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen der Rolle oder des Benutzers erweitert. Diese ID wird normalerweise nicht in der Konsole angezeigt, da es auch eine umgekehrte Transformation zurück zu dem ARN Zeitpunkt gibt, zu dem die Vertrauensrichtlinie angezeigt wird. 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 Prinzipal-ID aus folgenden Gründen in der Konsole angezeigt AWS kann es nicht mehr einem zuordnenARN. Wenn Sie also einen Benutzer oder eine Rolle löschen und neu erstellen, auf die in einem Principal Element einer Vertrauensrichtlinie verwiesen wird, müssen Sie die Rolle bearbeiten, um die zu ersetzen. ARN 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 Dienste, Amazon EMR und AWS Data Pipeline, um 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.

{
  "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. Anschließend erstellt Konto B eine IAM Benutzerrichtlinie, um diesen Zugriff auf den Bucket von Konto A an einen der Benutzer in Konto B zu delegieren.

Die S3-Bucket-Richtlinie in Konto A sieht beispielsweise folgendermaßen. In diesem Beispiel hat der S3-Bucket von Konto A den Namen amzn-s3-demo-bucket 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:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Alternativ kann Konto A Amazon S3 Access Control Lists (ACLs) verwenden, um Konto B Zugriff auf einen S3-Bucket oder ein einzelnes Objekt innerhalb eines Buckets zu gewähren. In diesem Fall ändert sich lediglich die Art und Weise, wie Konto A Zugriff auf Konto B gewährt. Konto B verwendet weiterhin eine Richtlinie, um den Zugriff an eine IAM Gruppe in Konto B zu delegieren, wie im nächsten Teil dieses 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.

Um diese Richtlinie zu implementieren, verwendet Konto BIAM, um sie dem entsprechenden Benutzer (oder der Gruppe) in Konto B zuzuordnen.

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

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

Im folgenden Beispiel hat Konto A eine SQS Amazon-Warteschlange, die eine ressourcenbasierte Richtlinie verwendet, die an die Warteschlange angehängt ist, um Konto B Warteschlangenzugriff zu gewähren. Anschließend verwendet Konto B eine IAM Gruppenrichtlinie, um den Zugriff an eine Gruppe in Konto B zu delegieren.

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 AmazonSQS, um diese Richtlinie umzusetzen.

{
  "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 verwendetIAM, um diese Richtlinie einer Gruppe (oder einem Benutzer) zuzuordnen.

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

Im obigen Beispiel für eine IAM Benutzerrichtlinie verwendet Konto B einen Platzhalter, um seinem Benutzer Zugriff auf alle SQS Amazon-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 ReceiveMessage Aktionen SendMessage und ausführen, die in der SQS Amazon-Warteschlangenrichtlinie von Konto A definiert sind.

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

Importieren in &S3; 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 ausdrücklich verweigert hat. 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. Konto B schreibt jedoch eine IAM Benutzerrichtlinie, die einem Benutzer in Konto B Zugriff auf den Bucket von Konto A gewährt. Die ausdrückliche Ablehnung, die auf den S3-Bucket von Konto A angewendet wird, wird auf die Benutzer in Konto B übertragen. Sie setzt die IAM Benutzerrichtlinie außer Kraft, die dem Benutzer in Konto B Zugriff gewährt. (Weitere Informationen zur Bewertung von Berechtigungen finden Auswertungslogik für Richtlinien Sie unter.)

Die Richtlinie des Buckets in Konto A sieht beispielsweise folgendermaßen. In diesem Beispiel hat der S3-Bucket von Konto A den Namen amzn-s3-demo-bucket 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:::amzn-s3-demo-bucket/*"
  }
}

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