Beispiele für Richtlinien für ACLs

Sie können Bedingungsschlüssel in Bucket-Richtlinien verwenden, um den Zugriff auf Amazon S3 zu kontrollieren.

Gewährung von PutObject s3-Berechtigungen mit einer Bedingung, die voraussetzt, dass der Bucket-Besitzer die volle Kontrolle erhält

Die Operation PUTObjekt ermöglicht eine Zugriffskontrollliste (ACL), d. h. Header, die Sie verwenden können, um bestimmte Berechtigungen zu erteilenACL. Mit diesen Schlüsseln kann der Bucket-Eigentümer eine Bedingung festlegen, die bestimmte Zugriffsberechtigungen erfordert, wenn der Benutzer ein Objekt hochlädt.

Angenommen, Konto A besitzt einen Bucket und der Kontoadministrator möchte Dave, einem Benutzer in Konto B, Berechtigungen zum Hochladen von Objekten erteilen. Standardmäßig gehören Objekte, die Dave hochgeladen hat, zu Konto B, und Konto A besitzt keine Berechtigungen für diese Objekte. Da der Bucket-Eigentümer die Rechnungen bezahlt, benötigt er volle Berechtigungen für die Objekte, die Dave hochlädt. Das Konto Ein Administrator kann dies tun, indem er Dave die s3:PutObject entsprechende Berechtigung erteilt, allerdings mit der Bedingung, dass die Anfrage ACL spezifische Header enthält, die entweder explizit volle Rechte gewähren oder vordefinierte Header verwenden. ACL Weitere Informationen finden Sie unter PUT Objekt.

Erfordert den x-amz-full-control Header

Sie können in der Anforderung den Header x-amz-full-control mit vollständiger Kontrollberechtigung für den Bucket-Eigentümer anfordern. Die folgende Bucket-Richtlinie erteilt dem Benutzer Dave die Berechtigung s3:PutObject mit einer Bedingung, die den Bedingungsschlüssel s3:x-amz-grant-full-control enthält, in die Anforderung den Header x-amz-full-control aufzunehmen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountB-ID:user/Dave"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::awsexamplebucket1/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID"
        }
      }
    }
  ]
}

Anmerkung

In diesem Beispiel geht es um die kontoübergreifende Berechtigung. Wenn Dave (der die Erlaubnis erhält) jedoch zu den AWS-Konto dem der Bucket gehört, ist diese bedingte Erlaubnis nicht erforderlich. Grund hierfür ist, dass das übergeordnete Konto, dem Dave angehört, Eigentümer von Objekten ist, die der Benutzer hochlädt.

Hinzufügen einer expliziten Zugriffsverweigerung

Die vorherige Bucket-Richtlinie erteilt dem Benutzer Dave in Konto B eine bedingte Berechtigung. Während diese Richtlinie in Kraft ist, ist es Dave möglich, die gleiche Berechtigung ohne Bedingung über eine andere Richtlinie zu erhalten. Beispiel: Dave kann einer Gruppe angehören, der Sie die Berechtigung s3:PutObject bedingungslos erteilen. Um solche Berechtigungslücken zu vermeiden, können Sie eine strengere Zugriffsrichtlinie schreiben, indem Sie eine explizite Zugriffsverweigerung hinzufügen. In diesem Beispiel verweigern Sie explizit die Upload-Berechtigung für Benutzer Dave, wenn er nicht die erforderlichen Header in die Anforderung einbindet, die dem Bucket-Eigentümer volle Berechtigungen gewährt. Eine explizite Verweigerung ersetzt immer eine anderswo erteilte Erlaubnis. Im Folgenden finden Sie das geänderte Zugriffsrichtlinienbeispiel mit hinzugefügter expliziter Ablehnung.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::awsexamplebucket1/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID"
                }
            }
        },
        {
            "Sid": "statement2",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::awsexamplebucket1/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID"
                }
            }
        }
    ]
}

Testen Sie die Richtlinie mit AWS CLI

Wenn Sie zwei haben AWS-Konten, können Sie die Richtlinie mit dem testen AWS Command Line Interface (AWS CLI). Sie hängen die Richtlinie an und verwenden Daves Anmeldeinformationen, um die Berechtigung wie folgt zu testen AWS CLI put-objectBefehl. Sie stellen dem Benutzer Dave die Anmeldeinformationen bereit, indem Sie den Parameter --profile hinzufügen. Sie erteilen dem Bucket-Eigentümer die volle Kontrolle, indem Sie den Parameter --grant-full-control hinzufügen. Weitere Informationen zur Einrichtung und Verwendung des AWS CLI, finden Sie unter Entwickeln mit Amazon S3 über die AWS CLI.

aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile

Erfordert den x-amz-acl Header

Sie können den x-amz-acl Header mit einem voreingestellten Header anfordern, der dem Bucket-Besitzer volle Zugriffsrechte ACL gewährt. Um den Header x-amz-acl in der Anforderung erforderlich zu machen, können Sie das Schlüssel-Wert-Paar im Block Condition ersetzen und den Bedingungsschlüssel s3:x-amz-acl wie im folgenden Beispiel dargestellt angeben.

"Condition": {
    "StringEquals": {
        "s3:x-amz-acl": "bucket-owner-full-control"
    }
}

Um die Berechtigung zu testen, verwenden Sie AWS CLI, geben Sie den --acl Parameter an. Das Tool AWS CLI fügt dann den x-amz-acl Header hinzu, wenn die Anfrage gesendet wird.

aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin

Erteilung der PutObject s3-Berechtigung mit einer Bedingung im x-amz-acl Header

Die folgende Bucket-Richtlinie gewährt die s3:PutObject Erlaubnis für zwei AWS-Konten wenn die Anfrage den x-amz-acl Header enthält, der das Objekt öffentlich lesbar macht. Der Condition-Block verwendet die StringEquals-Bedingung und ist mit dem Schlüssel-Wert-Paar "s3:x-amz-acl":["public-read"] zur Auswertung versehen. Im Schlüssel-Wert-Paar ist s3:x-amz-acl ein Amazon S3–spezifischer Schlüssel, wie durch das Präfix s3: angezeigt ist.

{
    "Version":"2012-10-17",
    "Statement": [ 
        {
	        "Sid":"AddCannedAcl",
            "Effect":"Allow",
	        "Principal": {
                "AWS": [
                "arn:aws:iam::Account1-ID:root",
				"arn:aws:iam::Account2-ID:root"
				]
            },
	        "Action":"s3:PutObject",
            "Resource": ["arn:aws:s3:::awsexamplebucket1/*"],
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl":["public-read"]
                }
            }
        }
    ]
}

Wichtig

Nicht alle Bedingungen machen für alle Aktionen auch Sinn. Beispielsweise ist es sinnvoll, die Bedingung s3:LocationConstraint für eine Richtlinie einzufügen, die die Amazon-S3-Berechtigung s3:CreateBucket erteilt. Es ist jedoch nicht sinnvoll, diese Bedingung in eine Richtlinie aufzunehmen, die die s3:GetObject-Genehmigung erteilt. Amazon S3 kann auf semantische Fehler dieses Typs testen, die Amazon-S3-spezifische Bedingungen beinhalten. Wenn Sie jedoch eine Richtlinie für einen IAM Benutzer oder eine Rolle erstellen und eine semantisch ungültige Amazon S3 S3-Bedingung angeben, wird kein Fehler gemeldet, da die Amazon S3 S3-Bedingungen IAM nicht validiert werden können.