Gambaran umum daftar kontrol akses (ACL)

Daftar kontrol akses Amazon S3 (ACLs) memungkinkan Anda mengelola akses ke bucket dan objek. Setiap bucket dan objek memiliki ACL yang melekat padanya sebagai sumber daya tambahan. Ini mendefinisikan Akun AWS atau kelompok mana yang diberikan akses dan jenis akses. Saat permintaan diterima terhadap sumber daya, Amazon S3 memeriksa ACL yang sesuai untuk memverifikasi bahwa pengirim permintaan 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 membuat ACL bawaan yang memberikan kendali penuh kepada pemilik sumber daya atas sumber daya tersebut. Hal ini ditunjukkan dalam ACL bucket sampel berikut (ACL objek bawaan 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> 

ACL sampel menyertakan elemen Owner yang mengidentifikasi pemilik dengan ID pengguna kanonik Akun AWS. 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. ACL bawaan ini memiliki satu elemen Grant untuk pemilik. Anda memberikan izin dengan menambahkan elemen Grant, dengan setiap pemberian yang mengidentifikasi penerimanya dan izinnya.

catatan

ACL dapat memiliki hingga 100 pemberian.

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 pada permintaan pemberian Anda, Amazon S3 akan menemukan ID pengguna kanonik untuk akun tersebut dan menambahkannya ke 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 menggunakan akses lintas akun, lihat Membuat Peran untuk Mendelegasikan Izin kepada Pengguna IAM dalam 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 Akun AWS dengan membaca ACL bucket atau objek yang Akun AWS memiliki izin akses. Ketika seseorang Akun AWS diberikan izin oleh permintaan hibah, entri hibah ditambahkan ke ACL dengan ID pengguna kanonik akun.

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. Ketika pengguna anonim mengunggah objek ke bucket Anda, Amazon S3 akan menambahkan ID pengguna kanonik kustom (65a011a29cdf8ec533ec3d1ccaae921c) sebagai pemilik objek dalam 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, meskipun WRITE izin menolak kemampuan non-pemilik untuk menimpa atau menghapus objek yang ada, WRITE izin tetap memungkinkan siapa pun untuk menyimpan objek di bucket Anda, yang mana Anda ditagih. 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 menggunakan ACLs, penerima hibah dapat berupa Akun AWS atau salah satu grup Amazon S3 yang telah ditentukan sebelumnya. Namun, penerima tidak dapat berupa pengguna IAM. Untuk informasi lebih lanjut tentang AWS pengguna dan izin dalam IAM, lihat Menggunakan AWS Identity and Access Management.

Izin apa yang dapat saya berikan?

Tabel berikut mencantumkan serangkaian izin yang didukung Amazon S3 di ACL. Serangkaian izin ACL tersebut sama dengan izin untuk sebuah objek ACL dan bucket ACL. Namun, tergantung pada konteks (ACL bucket atau ACL objek), izin-izin ACL 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 izin ACL 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 untuk membaca ACL bucket	Memungkinkan penerima untuk membaca ACL objek
WRITE_ACP	Memungkinkan penerima untuk menulis ACL untuk bucket yang berlaku	Memungkinkan penerima 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 Gambaran umum daftar kontrol akses (ACL) bagian sebelum memberikan izin.

Pemetaan izin ACL dan izin kebijakan akses

Sebagaimana yang ditunjukkan dalam tabel sebelumnya, ACL hanya mengizinkan serangkaian 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 izin ACL memetakan ke izin kebijakan akses yang sesuai. Seperti yang dapat Anda lihat, kebijakan akses memungkinkan lebih banyak izin dibandingkan ACL. Anda menggunakan ACLs terutama untuk memberikan izin baca/tulis dasar, mirip dengan izin sistem file. Untuk informasi lebih lanjut tentang kapan harus menggunakan ACL, lihat Identity and Access Management untuk Amazon S3.

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

Izin ACL	Menyesuaikan izin kebijakan akses ketika izin ACL diberikan pada bucket	Menyesuaikan izin kebijakan akses ketika izin ACL 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 merupakan pemilik bucket, memberikan izin WRITE dalam ACL bucket memungkinkan tindakan s3:DeleteObjectVersion yang harus dilakukan pada versi apa pun dalam bucket tersebut.	Tidak berlaku
READ_ACP	s3:GetBucketAcl	s3:GetObjectAcl dan s3:GetObjectVersionAcl
WRITE_ACP	s3:PutBucketAcl	s3:PutObjectAcl dan s3:PutObjectVersionAcl
FULL_CONTROL	Setara dengan pemberian izin READ, WRITE, READ_ACP, dan izin ACL WRITE_ACP. Oleh karena itu, izin ACL ini dipetakan ke kombinasi izin kebijakan akses yang sesuai.	Setara dengan pemberian izin READ, READ_ACP, dan izin ACL WRITE_ACP. Oleh karena itu, izin ACL ini dipetakan ke kombinasi izin kebijakan akses yang sesuai.

Kunci syarat

Saat Anda memberikan izin kebijakan akses, Anda dapat menggunakan kunci kondisi untuk membatasi nilai ACL pada objek dengan menggunakan kebijakan bucket. Kunci konteks berikut sesuai dengan ACLs. Anda dapat menggunakan kunci konteks ini untuk mewajibkan penggunaan ACL tertentu 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 ACL bucket.

• s3:x-amz-grant-write-acp ‐ Memerlukan akses tulis ke ACL bucket.

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

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

Misalnya kebijakan yang melibatkan header spesifik ACL, 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 operasi S3 API menurut jenis sumber daya S3, lihat. Izin yang diperlukan untuk operasi API Amazon 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 ACL bucket-owner-full-control kalengan, 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 API Amazon S3. Anda dapat menggunakan informasi ini untuk memahami operasi Amazon S3 mana yang bergantung pada otorisasi ACLs . 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

Operasi PutObject dalam tabel berikut ini, kecuali ditentukan lain, menunjukkan permintaan yang tidak menetapkan ACL, kecuali ACL merupakan ACL bucket-owner-full-control. 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
PutObject dengan ACL (kecuali untuk bucket-owner-full-control)	*	Tidak berlaku	*	Ya atau Tidak	Ya	Permintaan pemberian 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	Permintaan pemberian ACL
PutBucketAcl	*	Tidak berlaku	*	Ya atau Tidak	Ya	Permintaan pemberian ACL

catatan

Operasi REST.PUT.OBJECT dalam tabel berikut ini, kecuali ditentukan lain, menunjukkan permintaan yang tidak menetapkan ACL, kecuali ACL merupakan ACL bucket-owner-full-control. 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.OBJECT dengan ACL (kecuali untuk bucket-owner-full-control)	*	Tidak berlaku	*	Ya atau Tidak	Ya	Permintaan pemberian 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	Permintaan pemberian ACL

ACL Sampel

ACL sampel pada suatu bucket berikut ini mengidentifikasi pemilik sumber daya dan serangkaian pemberian. Formatnya adalah representasi XML dari ACL dalam Amazon S3 API REST. Pemilik bucket memiliki FULL_CONTROL sumber daya. Selain itu, 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>

ACL Terekam

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

ACL Terekam	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 menyebutkan ACL terekam ini saat membuat bucket, Amazon S3 akan mengabaikannya.
bucket-owner-full-control	Objek	Pemilik objek dan pemilik bucket mendapatkan FULL_CONTROL atas objek. Jika Anda menyebutkan ACL terekam ini saat membuat bucket, Amazon S3 akan 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 ACL terekam dalam permintaan Anda dengan menggunakan header x-amz-acl permintaan. Ketika Amazon S3 menerima permintaan dengan ACL terekam dalam permintaan tersebut, itu akan menambahkan pemberian yang telah ditentukan sebelumnya ke ACL dari sumber daya itu.