Contoh kebijakan untuk ACLs

Anda dapat menggunakan kunci kondisi dalam kebijakan bucket untuk mengontrol akses ke Amazon S3.

Pemberian s3: PutObject izin dengan syarat yang mengharuskan pemilik bucket untuk mendapatkan kontrol penuh

Operasi PUTObject memungkinkan access control list (ACL) —header spesifik yang dapat Anda gunakan untuk memberikan izin ACL berbasis. Dengan menggunakan kunci ini, pemilik bucket dapat menetapkan kondisi-kondisi untuk mengharuskan izin akses kustom ketika pengguna mengunggah objek.

Seandainya ketika Akun A memiliki bucket, dan administrator akun ingin memberikan izin kepada Dave, pengguna di Akun B, untuk mengunggah objek. Secara bawaan, objek yang diunggah Dave dimiliki oleh Akun B, dan Akun A tidak memiliki izin pada objek tersebut. Karena pemilik bucket membayar tagihan, pemilik bucket menginginkan izin penuh pada objek yang diunggah oleh Dave. Administrator Akun A dapat melakukannya dengan memberikan s3:PutObject izin kepada Dave, dengan syarat permintaan menyertakan header ACL -specific yang memberikan izin penuh secara eksplisit atau menggunakan kaleng. ACL Untuk informasi selengkapnya, lihat PUTObjek.

Membutuhkan x-amz-full-control header

Anda dapat mengharuskan header x-amz-full-control pada permintaan dengan izin kontrol penuh kepada pemilik bucket. Kebijakan bucket berikut ini memberikan izin s3:PutObject bagi pengguna Dave dengan syarat yang menggunakan kunci syarat s3:x-amz-grant-full-control, yang mengharuskan permintaan untuk menyertakan header x-amz-full-control.

{
  "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"
        }
      }
    }
  ]
}

catatan

Contoh ini adalah tentang izin lintas akun. Namun, jika Dave (yang mendapatkan izin) milik pemilik Akun AWS ember, izin bersyarat ini tidak diperlukan. Hal ini karena akun induk yang merupakan pemilik Dave memiliki objek yang diunggah pengguna.

Menambahkan penolakan eksplisit

Kebijakan bucket sebelumnya memberikan izin bersyarat kepada pengguna Dave yang ada di Akun B. Meskipun kebijakan ini berlaku, Dave mungkin mendapatkan izin yang sama tanpa persyaratan apa pun melalui kebijakan lain. Misalnya, Dave dapat menjadi bagian dari sebuah kelompok, dan Anda memberikan kepada kelompok tersebut izin s3:PutObject tanpa syarat apa pun. Untuk menghindari celah izin seperti itu, Anda dapat membuat kebijakan akses yang lebih ketat dengan menambahkan penolakan secara eksplisit. Dalam contoh ini, Anda secara jelas menolak izin pengunggahan pengguna Dave jika dia tidak menyertakan header yang diperlukan dalam permintaan yang memberikan izin penuh kepada pemilik bucket. Penolakan eksplisit selalu menggantikan izin lain yang diberikan. Berikut ini adalah contoh kebijakan akses yang direvisi dengan ditambahkan penolakan eksplisit.

{
    "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"
                }
            }
        }
    ]
}

Uji kebijakan dengan AWS CLI

Jika Anda memiliki dua Akun AWS, Anda dapat menguji kebijakan menggunakan AWS Command Line Interface (AWS CLI). Anda melampirkan kebijakan dan menggunakan kredensi Dave untuk menguji izin menggunakan perintah berikut. AWS CLI put-object Anda memberikan kredensial Dave dengan menambahkan parameter --profile. Anda memberikan izin kontrol penuh kepada pemilik bucket dengan menambahkan parameter --grant-full-control. Untuk informasi selengkapnya tentang pengaturan dan penggunaan AWS CLI, lihatMengembangkan dengan Amazon S3 menggunakan AWS CLI.

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

Membutuhkan x-amz-acl header

Anda dapat meminta x-amz-acl header dengan kaleng yang ACL memberikan izin kontrol penuh kepada pemilik bucket. Untuk mengharuskan header x-amz-acl pada permintaan, Anda dapat mengganti pasangan nilai kunci dalam pemblokiran Condition dan tentukan kunci syarat s3:x-amz-acl, sebagaimana yang ditunjukkan pada contoh berikut.

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

Untuk menguji izin menggunakan AWS CLI, Anda menentukan --acl parameter. AWS CLI Kemudian menambahkan x-amz-acl header ketika mengirim permintaan.

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

Pemberian s3: PutObject izin dengan kondisi di header x-amz-acl

Kebijakan bucket berikut memberikan s3:PutObject izin untuk dua orang Akun AWS jika permintaan menyertakan x-amz-acl header yang membuat objek dapat dibaca secara publik. Pemblokiran Condition menggunakan kondisi StringEquals dan diberi pasangan nilai kunci, "s3:x-amz-acl":["public-read"], untuk evaluasi. Dalam pasangan nilai kunci, s3:x-amz-acl adalah kunci spesifik–Amazon S3, sebagaimana yang ditunjukkan dengan prefiks s3:.

{
    "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"]
                }
            }
        }
    ]
}

penting

Tidak semua kondisi masuk akal untuk semua tindakan. Misalnya, memasukkan kondisi s3:LocationConstraint dalam kebijakan yang memberikan izin s3:CreateBucket Amazon S3 adalah hal yang masuk akal. Namun, tidak masuk akal untuk memasukkan syarat ini pada kebijakan yang memberikan izin s3:GetObject. Amazon S3 dapat menguji jenis kesalahan semantik seperti ini yang melibatkan syarat spesifik Amazon S3. Namun, jika Anda membuat kebijakan untuk IAM pengguna atau peran dan menyertakan kondisi Amazon S3 yang tidak valid secara semantik, tidak ada kesalahan yang dilaporkan karena tidak dapat IAM memvalidasi kondisi Amazon S3.