Direkt zum Inhalt

Wie kann ich kontoübergreifenden Zugriff auf Objekte gewähren, die sich in Amazon-S3-Buckets befinden?

Lesedauer: 9 Minute
0

Ich möchte einem anderen AWS-Konto Zugriff auf ein Objekt gewähren, das sich in einem Bucket von Amazon Simple Storage Service (Amazon S3) befindet.

Kurzbeschreibung

Als Kontoadministrator kannst du Benutzern in einem anderen Konto kontoübergreifenden Zugriff auf Objekte gewähren, die du im Konto besitzt.

Du kannst Berechtigungen für bestimmte S3-Ressourcen gewähren, für die kein vollständiger Administratorzugriff erforderlich ist.

Verwende eine der folgenden Methoden, um kontoübergreifenden Zugriff auf Objekte zu gewähren:

  • AWS Identity and Access Management (IAM)-Richtlinien und ressourcenbasierte Bucket-Richtlinien für den rein programmgesteuerten Zugriff auf S3-Bucket-Objekte
  • IAM-Richtlinien und ressourcenbasierte Zugriffssteuerungslisten (ACLs) für den rein programmgesteuerten Zugriff auf S3-Bucket-Objekte
    Hinweis: Wenn du die Einstellung Bucket-Eigentümer erzwungen aktivieren, deaktiviert Amazon S3 alle Bucket- und Objekt-ACLs. Daher kannst du ACLs nicht verwenden, um kontoübergreifenden Zugriff zu gewähren. Standardmäßig ist Bucket-Eigentümer erzwungen für alle neu erstellten Buckets aktiviert. Zur Verwaltung des kontoübergreifenden Zugriffs empfiehlt es sich außerdem, IAM-Richtlinien und Bucket-Richtlinien anstelle von ACLs zu verwenden. Weitere Informationen finden Sie unter Controlling ownership of objects and deactivating ACLs for your bucket.
  • Kontoübergreifende IAM-Rollen für den programmgesteuerten Zugriff und den Konsolenzugriff auf S3-Bucket-Objekte

Wenn der Anforderer ein IAM-Rollen-Prinzipal ist, muss das Konto, dem der Prinzipal gehört, die S3-Berechtigungen über eine IAM-Richtlinie gewähren. Je nach Anwendungsfall muss der Bucket-Eigentümer Berechtigungen auch über eine Bucket-Richtlinie oder ACL gewähren. Nachdem der Zugriff gewährt wurde, entspricht der programmgesteuerte Zugriff auf kontoübergreifende Buckets dem Zugriff auf die Konto-Buckets.

Für den kontoübergreifenden Zugriff mit Amazon S3 Access Points oder AWS Key Management Service (AWS KMS) ist eine zusätzliche Konfiguration erforderlich. Weitere Informationen findest du unter Warum erhalten kontoübergreifende Benutzer die Fehlermeldung „Access Denied“, wenn sie versuchen, auf meine S3-Objekte zuzugreifen, die ich mit einem vom Kunden verwalteten AWS-KMS-Schlüssel verschlüsselt habe?

Für große Datensätze, auf die du als kontoübergreifende Objekte zugreifen musst, empfiehlt es sich, S3-Zugangspunkte zu verwenden. Weitere Informationen finden Sie unter Simplify and scale access management to shared datasets with cross-account Amazon S3 access points.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

In den folgenden Verfahren ist Konto A dein Konto und Konto B das Konto, dem du Objektzugriff gewähren möchtest.

IAM-Richtlinien und ressourcenbasierte Bucket-Richtlinien

Verwende ressourcenbasierte Bucket-Richtlinien, um über den kontoübergreifenden Zugriff zu verwalten und die Berechtigungen des S3-Objekts zu überprüfen.

Wende eine Bucket-Richtlinie auf Bucket-Ebene an, die die Elemente Prinzipal, Ressourcen und Aktion definiert. Wenn du eine Bucket-Richtlinie auf Bucket-Ebene anwendest, kannst du den genauen Zugriff auf verschiedene Objekte innerhalb des Buckets definieren. Du kannst außerdem die Bucket-Richtlinie überprüfen, um zu sehen, wer auf Objekte in einem S3-Bucket zugreifen kann.

Gehe wie folgt vor, um Bucket-Richtlinien für die Verwaltung des S3-Bucket-Zugriffs zu verwenden:

  1. Erstelle einen S3-Bucket in Konto A.

  2. Erstellen Sie einen IAM-Benutzer oder eine IAM-Rolle in Konto B.

  3. Erteile dem IAM-Benutzer oder der IAM-Rolle in Konto B die Berechtigungen GetObject und PutObject. Erteilen Sie dem IAM-Benutzer oder der IAM-Rolle außerdem die Berechtigung, PutObjectAcl aufzurufen, das dem Bucket-Eigentümer die Objektberechtigung erteilt:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:PutObject",
                    "s3:PutObjectAcl"
                ],
                "Resource": "arn:aws:s3:::AccountABucketName/*"
            }
        ]
    }
    

    Hinweis: Ersetze in der obigen Richtlinie die Beispielwerte durch die Werte des Benutzers.
    Du kannst optional den Zugriff auf einen bestimmten Bucket-Ordner in Konto A beschränken. Definiere dazu den Ordnernamen im Resource-Element, z. B. „arn:aws:s3:::KontoABucketName/OrdnerName/*“. Weitere Informationen findest du unter Wie kann ich einem Benutzer Zugriff auf einen bestimmten Ordner in meinem Amazon S3-Bucket gewähren? Oder führe den Befehl create-policy in AWS CLI aus, um eine identitätsbasierte IAM-Richtlinie zu erstellen.

  4. Konfigurieren Sie die Bucket-Richtlinie für Konto A, um dem IAM-Benutzer oder der IAM-Rolle, die Sie in Konto B erstellt haben, die Berechtigungen GetObject und PutObject zu gewähren:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::AccountB:user/AccountBUserName"
                },
                "Action": [
                    "s3:GetObject",
                    "s3:PutObject",
                    "s3:PutObjectAcl"
                ],
                "Resource": [
                    "arn:aws:s3:::AccountABucketName/*"
                ]
            }
        ]
    }

    Du kannst auch den Befehl put-bucket-policy in AWS CLI ausführen, um eine S3-Bucket-Richtlinie zu erstellen.

Um den Zugriff auf einen bestimmten Bucket-Ordner zu beschränken, definieren Sie den Ordnernamen im Resource-Element, z. B. "arn:aws:s3:::KontoABucketName/OrdnerName/*". Wenn du die s3:PutObject-Berechtigung mit einem Bedingungsschlüssel verwendest, hat der Bucket-Eigentümer die volle Kontrolle über die Objekte, die andere Konten hochladen. Der API-Aufruf PutObject erzwingt die ACL mit bestimmten Headern.

IAM-Richtlinien und ressourcenbasierte ACLs

Sie können auch Objekt-ACLs verwenden, um Berechtigungen für bestimmte Szenarien zu verwalten.

Mit Amazon-S3-ACLs können Benutzer nur die Berechtigungssätze READ, WRITE, READ_ACP, WRITE_ACP und FULL_CONTROL definieren. Sie können nur ein Konto oder eine der vordefinierten Amazon-S3-Gruppen als Empfänger für die Amazon-S3-ACL verwenden. Wenn Sie eine E-Mail-Adresse oder eine kanonische Benutzer-ID für ein Konto angeben, gilt die ACL für alle Identitäten im Empfängerkonto. Beispielsweise können Sie eine ACL nicht verwenden, um den Zugriff auf einzelne IAM-Benutzer oder -Rollen einzuschränken. Du kannst ACLs auch nicht auf verschiedene Objekte anwenden, die dieselben Präfixe verwenden.

Hinweis: Die ACL unterstützt nicht die Bedingung für den S3-Vorgang, die die ACL autorisiert. Der Bucket-Eigentümer hat daher möglicherweise nicht die volle Kontrolle über die Objekte, die der ACL-Empfänger hochgeladen hat.

Gehe wie folgt vor, um Bucket- und Objekt-ACLs zur Verwaltung des S3-Bucket-Zugriffs zu verwenden:

  1. Erstellen Sie einen IAM-Benutzer oder eine IAM-Rolle in Konto B.

  2. Erteilen Sie der Rolle oder dem Benutzer Berechtigungen, um die erforderlichen Amazon-S3-Operationen auszuführen. Benutzer, die PutObject und GetObject aufrufen, müssen über die Berechtigungen verfügen, die im Abschnitt Ressourcenbasierte Richtlinien und IAM-Richtlinien aufgeführt sind.

  3. Konfiguriere die Bucket-ACL so, dass sie mindestens die WRITE-Berechtigung für Konto B enthält. Mit der WRITE-Berechtigung können IAM-Benutzer oder -Rollen von Konto B Objekte in einen Bucket hochladen, der Konto A gehört:

    ...<AccessControlPolicy>
      <Owner>
        <ID> AccountACanonicalUserID </ID>
        <DisplayName> AccountADisplayName </DisplayName>
      </Owner>
      <AccessControlList>
    ...
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <ID> AccountBCanonicalUserID </ID>
            <DisplayName> AccountBDisplayName </DisplayName>
          </Grantee>
          <Permission> WRITE </Permission>
        </Grant>
        ...
      </AccessControlList>
    </AccessControlPolicy>

    Hinweis: Informationen zum Ermitteln der CanonicalUserID findest du unter Ermitteln der kanonischen Benutzer-ID für ein AWS-Konto.

  4. Konfiguriere Objekt-ACLs so, dass sie mindestens die READ-Berechtigung für Konto B enthalten. READ-Berechtigungen ermöglichen es den IAM-Rollen oder -Benutzern in Konto B Objekte aus einem Bucket herunterzuladen, der Konto A gehört:

    ...<AccessControlPolicy>
      <Owner>
        <ID> AccountACanonicalUserID </ID>
        <DisplayName> AccountADisplayName </DisplayName>
      </Owner>
      <AccessControlList>
    ...
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <ID> AccountBCanonicalUserID </ID>
            <DisplayName> AccountBDisplayName </DisplayName>
          </Grantee>
          <Permission> READ </Permission>
        </Grant>
        ...
      </AccessControlList>
    </AccessControlPolicy>

Die ACL-Berechtigungen variieren je nach S3-Ressource, Bucket oder Objekt, auf das du eine ACL anwendest. Weitere Informationen findest du unter Übersicht über die Zugriffssteuerungsliste (ACL). Wenn Sie einen Bucket erstellen oder ein Objekt in einen vorhandenen Bucket hochladen, konfigurieren Sie Bucket- und Objekt-ACLs.

Kontoübergreifende IAM-Rollen

Nicht alle AWS-Services unterstützen ressourcenbasierte Richtlinien. Verwende stattdessen kontoübergreifende IAM-Rollen, um die Berechtigungsverwaltung zu zentralisieren, wenn du kontoübergreifenden Zugriff auf mehrere Services gewährst. Diese Methode ermöglicht den kontoübergreifenden Zugriff auf Objekte, die einem anderen Konto oder AWS-Service gehören oder von diesem hochgeladen wurden. Wenn Sie keine kontoübergreifenden IAM-Rollen verwenden, müssen Sie die Objekt-ACL ändern. Weitere Informationen finden Sie unter How Amazon S3 authorizes a request for an object operation.

Gehen Sie wie folgt vor, um kontoübergreifende IAM-Rollen für die Verwaltung des S3-Bucket-Zugriffs zu verwenden:

  1. Erstellen Sie eine IAM-Rolle in Konto A.

  2. Erteilen Sie der Rolle Berechtigungen, um die erforderlichen S3-Operationen auszuführen. Gewähren Sie in der Vertrauensrichtlinie der Rolle einer Rolle oder einem Benutzer aus Konto B die Berechtigungen, die Rolle in Konto A zu übernehmen:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::AccountB:user/AccountBUserName"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }

    Hinweis: IAM-Rollen müssen über eine Vertrauensrichtlinie verfügen, die die Prinzipale definiert, die die Rolle übernehmen können und wann die Rollen sie übernehmen können. IAM-Rollen können mehrere Berechtigungsrichtlinien haben, die definieren, welche Berechtigungen ein Prinzipal ausführen kann, der die Rolle übernimmt und die Ressourcen, die sie verwenden.

    Du kannst auch den Befehl create-role in AWS CLI ausführen, um eine Rolle mit der Vertrauensrichtlinie zu erstellen.

    Die folgende Zugriffsrichtlinie ermöglicht es einem Benutzer, der die Rolle übernommen hat, Objekte programmgesteuert über die Amazon-S3-Konsole herunter- und hochzuladen. Wenn du nur programmgesteuerten Zugriff benötigst, kannst du die ersten beiden Anweisungen in der Richtlinie entfernen:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "s3:ListAllMyBuckets"
                ],
                "Effect": "Allow",
                "Resource": [
                    "arn:aws:s3:::*"
                ]
            },
            {
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation"
                ],
                "Effect": "Allow",
                "Resource": "arn:aws:s3:::AccountABucketName"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:PutObject"
                ],
                "Resource": "arn:aws:s3:::AccountABucketName/*"
            }
        ]
    }

    Weitere Informationen findest du unter Wie kann ich einem Benutzer Zugriff auf einen bestimmten Ordner in meinem Amazon S3-Bucket gewähren? Oder führe den Befehl create-policy in AWS CLI aus, um eine identitätsbasierte IAM-Richtlinie zu erstellen.

  3. Gewähre einer IAM-Rolle oder einem IAM-Benutzer in Konto B die Berechtigung, die IAM-Rolle anzunehmen, die du in Konto A erstellt hast. Du musst die folgende Richtlinie als Berechtigungsrichtlinie für den IAM-Benutzer oder die IAM-Rolle hinzufügen:

    {
        "Version": "2012-10-17",
        "Statement": {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::AccountA:role/AccountARole"
        }
    }

    Oder führe den Befehl create-policy in AWS CLI aus, um eine identitätsbasierte IAM-Richtlinie zu erstellen.

  4. Nimm von einer Rolle in Konto B aus die Rolle in Konto A an, damit die IAM-Identitäten in Konto B die erforderlichen S3-Operationen ausführen können. 
    Hinweis: Wenn du eine IAM-Rolle in Konto A übernimmst, bestimmt Amazon S3 den Vorgang auf der Grundlage der Zugriffsrichtlinie. Die IAM-Rolle funktioniert als API-Aufruf, den eine lokale IAM-Identität in Konto A aufgerufen hat. Eine Bucket-Richtlinie oder eine ACL für den kontoübergreifenden Zugriff ist nicht erforderlich. Weitere Informationen finden Sie unter Policy actions for Amazon S3.

Verwandte Informationen

Actions, resources, and condition keys for Amazon S3

Examples of Amazon S3 bucket policies

Identity-based policy examples for Amazon S3

Cross-account policy evaluation logic