Daftar kontrol akses (ACL) ikhtisar

Daftar kontrol akses Amazon S3 (ACLs) memungkinkan Anda mengelola akses ke bucket dan objek. Setiap bucket dan objek memiliki ACL lampiran padanya sebagai subresource. Ini mendefinisikan Akun AWS atau kelompok mana yang diberikan akses dan jenis akses. Ketika permintaan diterima terhadap sumber daya, Amazon S3 memeriksa yang sesuai ACL untuk memverifikasi bahwa pemohon memiliki izin akses yang diperlukan.

S3 Object Ownership adalah setelan tingkat ember Amazon S3 yang dapat Anda gunakan untuk mengontrol kepemilikan objek yang diunggah ke bucket dan untuk menonaktifkan atau mengaktifkan. ACLs Secara default, Kepemilikan Objek disetel ke setelan diberlakukan pemilik Bucket, dan semuanya ACLs dinonaktifkan. Ketika ACLs dinonaktifkan, pemilik bucket memiliki semua objek di bucket dan mengelola akses ke mereka secara eksklusif dengan menggunakan kebijakan manajemen akses.

Mayoritas kasus penggunaan modern di Amazon S3 tidak lagi memerlukan penggunaan. ACLs Kami menyarankan agar Anda tetap ACLs dinonaktifkan, kecuali dalam keadaan yang tidak biasa di mana Anda perlu mengontrol akses untuk setiap objek secara individual. Dengan ACLs dinonaktifkan, Anda dapat menggunakan kebijakan untuk mengontrol akses ke semua objek di bucket, terlepas dari siapa yang mengunggah objek ke bucket Anda. Untuk informasi selengkapnya, lihat Mengontrol kepemilikan objek dan menonaktifkan bucket ACLs Anda.

penting

Jika bucket Anda menggunakan pengaturan yang diberlakukan pemilik bucket untuk Kepemilikan Objek S3, Anda harus menggunakan kebijakan untuk memberikan akses ke bucket Anda, serta objek di dalamnya. Dengan pengaturan yang diberlakukan pemilik Bucket diaktifkan, permintaan untuk menyetel daftar kontrol akses (ACLs) atau pembaruan ACLs gagal dan mengembalikan kode AccessControlListNotSupported kesalahan. Permintaan untuk membaca ACLs masih didukung.

Saat Anda membuat bucket atau objek, Amazon S3 akan membuat default ACL yang memberi pemilik sumber daya kontrol penuh atas sumber daya. Ini ditunjukkan dalam contoh bucket berikut ACL (objek default ACL memiliki struktur yang sama):

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>*** Owner-Canonical-User-ID ***</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>*** Owner-Canonical-User-ID ***</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy> 

Sampel ACL mencakup Owner elemen yang mengidentifikasi pemilik dengan ID Akun AWS pengguna kanonik. Untuk petunjuk bagaimana menemukan id pengguna kanonik Anda, lihat Menemukan ID Akun AWS pengguna kanonik. GrantElemen mengidentifikasi penerima hibah (baik grup Akun AWS atau yang telah ditentukan sebelumnya) dan izin yang diberikan. Default ini ACL memiliki satu Grant elemen untuk pemilik. Anda memberikan izin dengan menambahkan elemen Grant, dengan setiap pemberian yang mengidentifikasi penerimanya dan izinnya.

catatan

Sebuah ACL dapat memiliki hingga 100 hibah.

Siapa itu penerima?

Penerima hibah dapat berupa Akun AWS atau salah satu grup Amazon S3 yang telah ditentukan sebelumnya. Anda memberikan izin untuk Akun AWS menggunakan alamat email atau ID pengguna kanonik. Namun, jika Anda memberikan alamat email dalam permintaan hibah Anda, Amazon S3 menemukan ID pengguna kanonik untuk akun tersebut dan menambahkannya ke akun. ACL Hasil ACLs selalu berisi ID pengguna kanonik untuk Akun AWS, bukan alamat email dari. Akun AWS

Saat Anda memberikan hak akses, Anda menentukan setiap penerima sebagai pasangan type="value", di mana salah satu dari berikut type ini:

• id— Jika nilai yang ditentukan adalah ID pengguna kanonik dari Akun AWS

• uri–jika Anda memberikan izin untuk grup yang telah ditentukan sebelumnya

• emailAddress–jika nilai yang disebutkan adalah alamat email dari Akun AWS

penting

Menggunakan alamat email untuk menentukan penerima hanya diberi support di Wilayah AWS berikut ini:

• AS Timur (Virginia Utara)

• AS Barat (California Utara)

• AS Barat (Oregon)

• Asia Pasifik (Singapura)

• Asia Pasifik (Sydney)

• Asia Pasifik (Tokyo)

• Eropa (Irlandia)

• Amerika Selatan (Sao Paulo)

Untuk daftar semua wilayah dan titik akhir yang didukung Amazon S3, lihat Wilayah dan Titik Akhir di Referensi Umum Amazon Web Services.

contoh Contoh: Alamat Email

Misalnya, x-amz-grant-read header berikut memberikan izin yang Akun AWS diidentifikasi oleh alamat email untuk membaca data objek dan metadatanya:

x-amz-grant-read: emailAddress="[e-mail]", emailAddress="[e-mail]"

Awas

Saat Anda memberikan Akun AWS akses lain ke sumber daya Anda, ketahuilah bahwa mereka Akun AWS dapat mendelegasikan izin mereka kepada pengguna di bawah akun mereka. Ini dikenal sebagai akses lintas akun. Untuk informasi tentang penggunaan akses lintas akun, lihat Membuat Peran untuk Mendelegasikan Izin kepada IAM Pengguna di Panduan Pengguna. IAM

Menemukan ID Akun AWS pengguna kanonik

ID pengguna kanonik berkaitan dengan Akun AWS Anda. ID ini adalah string panjang karakter, seperti:

79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be

Untuk informasi tentang cara menemukan ID pengguna kanonik untuk akun Anda, lihat Menemukan ID pengguna kanonik untuk Anda Akun AWS di Panduan Referensi Manajemen AWS Akun.

Anda juga dapat mencari ID pengguna kanonik dari sebuah Akun AWS dengan membaca bucket atau objek yang Akun AWS memiliki izin akses. ACL Ketika seseorang Akun AWS diberikan izin oleh permintaan hibah, entri hibah ditambahkan ke ID ACL pengguna kanonik akun tersebut.

catatan

Jika Anda membuat bucket menjadi publik (tidak disarankan), pengguna yang tidak diautentikasi dapat mengunggah objek ke dalam bucket tersebut. Pengguna anonim ini tidak memiliki Akun AWS. Saat pengguna anonim mengunggah objek ke bucket Anda, Amazon S3 menambahkan ID pengguna kanonik khusus 65a011a29cdf8ec533ec3d1ccaae921c () sebagai pemilik objek di. ACL Untuk informasi selengkapnya, lihat bucket Amazon S3 dan kepemilikan objek.

Grup Amazon S3 yang sudah ditentukan sebelumnya

Amazon S3 memiliki serangkaian grup yang telah ditentukan sebelumnya. Saat memberikan akses akun ke grup, Anda menentukan salah satu Amazon URIs S3, bukan ID pengguna kanonik. Amazon S3 menyediakan grup yang telah ditentukan sebelumnya berikut ini:

• Grup Pengguna yang Diautentikasi–Diwakili oleh http://acs.amazonaws.com/groups/global/AuthenticatedUsers.

  Kelompok ini mewakili semua Akun AWS. Izin akses ke grup ini memungkinkan siapa pun Akun AWS untuk mengakses sumber daya. Namun demikian, semua permintaan harus ditandatangani (diautentikasi).

  Awas

  Saat Anda memberikan akses ke grup Pengguna Terautentikasi, setiap pengguna yang AWS diautentikasi di dunia dapat mengakses sumber daya Anda.

• Grup Semua Pengguna–Diwakili oleh http://acs.amazonaws.com/groups/global/AllUsers.

  Izin akses ke grup ini memungkinkan siapa pun di dunia mengakses ke sumber daya. Permintaan dapat ditandatangani (diautentikasi) atau tidak ditandatangani (anonim). Permintaan yang tidak ditandatangani menghilangkan header Autentikasi dalam permintaan.

  Awas

  Kami sangat merekomendasikan agar Anda tidak pernah memberikan Grup Semua Pengguna izin WRITE, WRITE_ACP, atau FULL_CONTROL. Misalnya, sementara izin WRITE tidak mengizinkan non-pemilik untuk menimpa atau menghapus objek yang ada, izin WRITE masih memungkinkan siapa pun menyimpan objek dalam bucket Anda, yang akan ditagihkan kepada Anda. Untuk perincian lebih lanjut tentang izin ini, lihat bagian berikut Izin apa yang dapat saya berikan?.

• Grup Log Pengiriman–Diwakili oleh http://acs.amazonaws.com/groups/s3/LogDelivery.

  Izin WRITE pada bucket memungkinkan grup ini menulis log akses server (lihat Pencatatan permintaan dengan pencatatan akses server) ke bucket.

catatan

Saat menggunakanACLs, penerima hibah dapat berupa Akun AWS atau salah satu grup Amazon S3 yang telah ditentukan sebelumnya. Namun, penerima hibah tidak bisa menjadi IAM pengguna. Untuk informasi selengkapnya tentang AWS pengguna dan izin di dalamnyaIAM, lihat Menggunakan AWS Identity and Access Management.

Izin apa yang dapat saya berikan?

Tabel berikut mencantumkan kumpulan izin yang didukung Amazon S3 di file. ACL Kumpulan ACL izin sama untuk objek ACL dan emberACL. Namun, tergantung pada konteksnya (bucket ACL atau objekACL), ACL izin ini memberikan izin untuk bucket atau operasi objek tertentu. Tabel ini mencantumkan izin dan menjelaskan apa artinya dalam konteks objek dan bucket.

Untuk informasi selengkapnya tentang ACL izin di konsol Amazon S3, lihat. Mengkonfigurasi ACLs

Izin	Saat diberikan pada bucket	Saat diberikan pada objek
READ	Memungkinkan penerima untuk mencantumkan objek di dalam bucket	Memungkinkan penerima untuk membaca data objek dan metadatanya
WRITE	Mengizinkan penerima untuk membuat objek baru di dalam bucket. Untuk pemilik bucket dan objek dari objek yang sudah ada, serta mengizinkan penghapusan dan penimpaan objek tersebut.	Tidak berlaku
READ_ACP	Memungkinkan penerima hibah untuk membaca ember ACL	Memungkinkan penerima hibah untuk membaca objek ACL
WRITE_ACP	Memungkinkan penerima hibah untuk menulis ACL untuk ember yang berlaku	Memungkinkan penerima hibah untuk menulis ACL untuk objek yang berlaku
FULL_CONTROL	Memungkinkan penerima pemberian READ, WRITE, READ_ACP, dan WRITE_ACP izin pada bucket	Memungkinkan penerima pemberian READ, WRITE_ACP, dan READ_ACP izin pada objek

Awas

Berhati-hatilah saat memberikan izin akses ke bucket dan S3 Object Anda. Misalnya, memberikan akses WRITE ke bucket mengizinkan penerima membuat, menimpa, dan menghapus objek dalam bucket tersebut. Kami sangat menyarankan Anda membaca seluruh Daftar kontrol akses (ACL) ikhtisar bagian sebelum memberikan izin.

Pemetaan ACL izin dan izin kebijakan akses

Seperti yang ditunjukkan pada tabel sebelumnya, hanya ACL mengizinkan sekumpulan izin terbatas, dibandingkan dengan jumlah izin yang dapat Anda tetapkan dalam kebijakan akses (lihat). Tindakan kebijakan untuk Amazon S3 Masing-masing izin ini memungkinkan satu operasi Amazon S3 atau lebih.

Tabel berikut menunjukkan cara setiap ACL izin memetakan izin kebijakan akses yang sesuai. Seperti yang Anda lihat, kebijakan akses memungkinkan lebih banyak izin daripada yang ACL dilakukan. Anda menggunakan ACLs terutama untuk memberikan izin baca/tulis dasar, mirip dengan izin sistem file. Untuk informasi selengkapnya tentang kapan harus menggunakanACL, lihatIdentity and Access Management untuk Amazon S3.

Untuk informasi selengkapnya tentang ACL izin di konsol Amazon S3, lihat. Mengkonfigurasi ACLs

ACLizin	Izin kebijakan akses terkait saat ACL izin diberikan pada bucket	Izin kebijakan akses yang sesuai saat ACL izin diberikan pada objek
READ	s3:ListBucket, s3:ListBucketVersions, dan s3:ListBucketMultipartUploads	s3:GetObject dan s3:GetObjectVersion
WRITE	s3:PutObject Pemilik bucket dapat membuat, menimpa, dan menghapus objek apa pun di bucket, dan pemilik objek memiliki FULL_CONTROL atas objek mereka. Selain itu, ketika penerima hibah adalah pemilik bucket, pemberian WRITE izin dalam ember ACL memungkinkan s3:DeleteObjectVersion tindakan dilakukan pada versi apa pun di bucket itu.	Tidak berlaku
READ_ACP	s3:GetBucketAcl	s3:GetObjectAcl dan s3:GetObjectVersionAcl
WRITE_ACP	s3:PutBucketAcl	s3:PutObjectAcl dan s3:PutObjectVersionAcl
FULL_CONTROL	Setara dengan pemberianREAD,, WRITEREAD_ACP, dan WRITE_ACP ACL izin. Dengan demikian, ACL izin ini memetakan ke kombinasi izin kebijakan akses yang sesuai.	Setara dengan pemberianREAD,READ_ACP, dan WRITE_ACP ACL izin. Dengan demikian, ACL izin ini memetakan ke kombinasi izin kebijakan akses yang sesuai.

Kunci syarat

Saat Anda memberikan izin kebijakan akses, Anda dapat menggunakan kunci kondisi untuk membatasi nilai objek ACL pada objek menggunakan kebijakan bucket. Kunci konteks berikut sesuai denganACLs. Anda dapat menggunakan kunci konteks ini untuk mengamanatkan penggunaan spesifik ACL dalam permintaan:

• s3:x-amz-grant-read ‐ Memerlukan akses baca.

• s3:x-amz-grant-write ‐ Memerlukan akses tulis.

• s3:x-amz-grant-read-acp- Memerlukan akses baca ke emberACL.

• s3:x-amz-grant-write-acp- Memerlukan akses tulis ke emberACL.

• s3:x-amz-grant-full-control ‐ Memerlukan kontrol penuh.

• s3:x-amz-acl ‐ Memerlukan Kalengan ACL.

Misalnya kebijakan yang melibatkan header ACL -specific, lihat. Pemberian s3: PutObject izin dengan syarat yang mengharuskan pemilik bucket untuk mendapatkan kontrol penuh Untuk daftar lengkap kunci kondisi khusus Amazon S3, lihat Tindakan, sumber daya, dan kunci kondisi untuk Amazon S3 di Referensi Otorisasi Layanan.

Untuk informasi selengkapnya tentang izin API operasi S3 menurut jenis sumber daya S3, lihat. Izin yang diperlukan untuk operasi Amazon API S3

Nilai aclRequired untuk permintaan Amazon S3 umum

Untuk mengidentifikasi permintaan Amazon S3 yang diperlukan ACLs untuk otorisasi, Anda dapat menggunakan aclRequired nilai di log akses server Amazon S3 atau. AWS CloudTrailaclRequiredNilai yang muncul di log akses server Amazon S3 CloudTrail atau Amazon S3 bergantung pada operasi mana yang dipanggil dan informasi tertentu tentang pemohon, pemilik objek, dan pemilik bucket. Jika tidak ACLs diperlukan, atau jika Anda menyetel bucket-owner-full-control kalengACL, atau jika permintaan diizinkan oleh kebijakan bucket Anda, string aclRequired nilainya adalah "-" di log akses server Amazon S3 dan tidak ada di dalamnya. CloudTrail

Tabel berikut mencantumkan aclRequired nilai yang diharapkan dalam CloudTrail atau log akses server Amazon S3 untuk berbagai operasi Amazon API S3. Anda dapat menggunakan informasi ini untuk memahami operasi Amazon S3 mana yang bergantung pada otorisasiACLs. Dalam tabel berikut, A, B, dan C mewakili akun berbeda yang terkait dengan pemohon, pemilik objek, dan pemilik bucket. Entri dengan tanda bintang (*) menunjukkan salah satu akun A, B, atau C.

catatan

PutObjectoperasi dalam tabel berikut, kecuali ditentukan lain, menunjukkan permintaan yang tidak menetapkanACL, kecuali ACL adalah a bucket-owner-full-controlACL. Nilai null untuk aclRequired menunjukkan bahwa tidak aclRequired ada dalam AWS CloudTrail log.

Tabel berikut menunjukkan aclRequired nilai untuk CloudTrail.

Nama operasi	Peminta	Pemilik objek	Pemilik bucket	Kebijakan bucket memberikan akses	Nilai aclRequired	Alasan
GetObject	A	A	A	Ya atau Tidak	null	Akses akun yang sama
GetObject	A	B	A	Ya atau Tidak	null	Akses akun yang sama dengan pemilik bucket diberlakukan
GetObject	A	A	B	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
GetObject	A	A	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
GetObject	A	A	B	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
GetObject	A	B	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
GetObject	A	B	C	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
GetObject	A	B	C	Tidak	Ya	Akses lintas akun bergantung pada ACL
PutObject	A	Tidak berlaku	A	Ya atau Tidak	null	Akses akun yang sama
PutObject	A	Tidak berlaku	B	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
PutObject	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
PutObjectdengan ACL (kecualibucket-owner-full-control)	*	Tidak berlaku	*	Ya atau Tidak	Ya	Minta hibah ACL
ListObjects	A	Tidak berlaku	A	Ya atau Tidak	null	Akses akun yang sama
ListObjects	A	Tidak berlaku	B	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
ListObjects	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
DeleteObject	A	Tidak berlaku	A	Ya atau Tidak	null	Akses akun yang sama
DeleteObject	A	Tidak berlaku	B	Ya	null	Akses lintas akun yang diberikan oleh kebijakan bucket
DeleteObject	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
PutObjectAcl	*	*	*	Ya atau Tidak	Ya	Minta hibah ACL
PutBucketAcl	*	Tidak berlaku	*	Ya atau Tidak	Ya	Minta hibah ACL

catatan

REST.PUT.OBJECToperasi dalam tabel berikut, kecuali ditentukan lain, menunjukkan permintaan yang tidak menetapkanACL, kecuali ACL adalah a bucket-owner-full-controlACL. String aclRequired nilai "-" menunjukkan nilai nol di log akses server Amazon S3.

Tabel berikut menunjukkan aclRequired nilai untuk log akses server Amazon S3.

Nama operasi	Peminta	Pemilik objek	Pemilik bucket	Kebijakan bucket memberikan akses	Nilai aclRequired	Alasan
REST.GET.OBJECT	A	A	A	Ya atau Tidak	-	Akses akun yang sama
REST.GET.OBJECT	A	B	A	Ya atau Tidak	-	Akses akun yang sama dengan pemilik bucket diberlakukan
REST.GET.OBJECT	A	A	B	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.GET.OBJECT	A	A	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.GET.OBJECT	A	B	B	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.GET.OBJECT	A	B	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.GET.OBJECT	A	B	C	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.GET.OBJECT	A	B	C	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.PUT.OBJECT	A	Tidak berlaku	A	Ya atau Tidak	-	Akses akun yang sama
REST.PUT.OBJECT	A	Tidak berlaku	B	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.PUT.OBJECT	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.PUT.OBJECTdengan ACL (kecualibucket-owner-full-control)	*	Tidak berlaku	*	Ya atau Tidak	Ya	Minta hibah ACL
REST.GET.BUCKET	A	Tidak berlaku	A	Ya atau Tidak	-	Akses akun yang sama
REST.GET.BUCKET	A	Tidak berlaku	B	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.GET.BUCKET	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.DELETE.OBJECT	A	Tidak berlaku	A	Ya atau Tidak	-	Akses akun yang sama
REST.DELETE.OBJECT	A	Tidak berlaku	B	Ya	-	Akses lintas akun yang diberikan oleh kebijakan bucket
REST.DELETE.OBJECT	A	Tidak berlaku	B	Tidak	Ya	Akses lintas akun bergantung pada ACL
REST.PUT.ACL	*	*	*	Ya atau Tidak	Ya	Minta hibah ACL

Sampel ACL

Contoh berikut ACL pada bucket mengidentifikasi pemilik sumber daya dan satu set hibah. Formatnya adalah XML representasi dari ACL di Amazon S3 RESTAPI. Pemilik bucket memiliki FULL_CONTROL sumber daya. Selain itu, ini ACL menunjukkan bagaimana izin diberikan pada sumber daya ke dua Akun AWS, diidentifikasi oleh ID pengguna kanonik, dan dua grup Amazon S3 yang telah ditentukan sebelumnya yang dibahas di bagian sebelumnya.

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>Owner-canonical-user-ID</ID>
    <DisplayName>display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>Owner-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
    
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user1-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user2-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
      </Grantee>
      <Permission>READ</Permission>
    </Grant>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

  </AccessControlList>
</AccessControlPolicy>

Kalengan ACL

Amazon S3 mendukung serangkaian hibah yang telah ditentukan, yang dikenal sebagai kaleng. ACLs Setiap kaleng ACL memiliki sekumpulan penerima hibah dan izin yang telah ditentukan sebelumnya. Tabel berikut mencantumkan kumpulan kaleng ACLs dan hibah yang telah ditentukan sebelumnya.

Kalengan ACL	Berlaku untuk	Izin ditambahkan ke ACL
private	Bucket dan objek	Pemilik mendapatkan FULL_CONTROL. Tidak ada orang lain yang memiliki hak mengakses (default).
public-read	Bucket dan objek	Pemilik mendapatkan FULL_CONTROL. Grup AllUsers (lihat Siapa itu penerima?) mendapat akses READ.
public-read-write	Bucket dan objek	Pemilik mendapatkan FULL_CONTROL. Grup AllUsers mendapatkan akses READ dan WRITE. memberikan ini pada bucket umumnya tidak disarankan.
aws-exec-read	Bucket dan objek	Pemilik mendapatkan FULL_CONTROL. Amazon EC2 mendapatkan READ akses ke GET bundel Amazon Machine Image (AMI) dari Amazon S3.
authenticated-read	Bucket dan objek	Pemilik mendapatkan FULL_CONTROL. Grup AuthenticatedUsers mendapat akses READ.
bucket-owner-read	Objek	Pemilik objek mendapat FULL_CONTROL. Pemilik bucket mendapat akses READ. Jika Anda menentukan kalengan ini ACL saat membuat ember, Amazon S3 mengabaikannya.
bucket-owner-full-control	Objek	Pemilik objek dan pemilik bucket mendapatkan FULL_CONTROL atas objek. Jika Anda menentukan kalengan ini ACL saat membuat ember, Amazon S3 mengabaikannya.
log-delivery-write	Bucket	Grup LogDelivery mendapatkan izin WRITE dan READ_ACP pada bucket. Untuk informasi lebih lanjut tentang log, lihat (Pencatatan permintaan dengan pencatatan akses server).

catatan

Anda hanya dapat menentukan satu dari kaleng ini ACLs dalam permintaan Anda.

Anda menentukan kaleng ACL dalam permintaan Anda dengan menggunakan header x-amz-acl permintaan. Saat Amazon S3 menerima permintaan dengan kalengan ACL dalam permintaan, Amazon S3 menambahkan hibah yang telah ditentukan ke sumber daya. ACL