Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # 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 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](about-object-ownership.md). **penting** Jika bucket tujuan umum Anda menggunakan setelan yang diberlakukan pemilik Bucket untuk Kepemilikan Objek S3, Anda harus menggunakan kebijakan untuk memberikan akses ke bucket tujuan umum dan 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): **Example** ``` 1. 2. 3. 4. *** Owner-Canonical-User-ID *** 5. 6. 7. 8. 10. *** Owner-Canonical-User-ID *** 11. 12. FULL_CONTROL 13. 14. 15. ``` 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](#finding-canonical-id). `Grant`Elemen 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. **Topics** + [Siapa itu penerima?](#specifying-grantee) + [Izin apa yang dapat saya berikan?](#permissions) + [Nilai `aclRequired` untuk permintaan Amazon S3 umum](#aclrequired-s3) + [ACL Sampel](#sample-acl) + [ACL Terekam](#canned-acl) ## Siapa itu penerima? 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 sebuah Akun AWS + `uri`–jika Anda memberikan izin untuk grup yang telah ditentukan sebelumnya **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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) 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](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) 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](access-policy-language-overview.md#about-resource-owner). ### 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?](#permissions). + ****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](ServerLogs.md)) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## 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](managing-acls.md). | 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\$1ACP | Memungkinkan penerima untuk membaca ACL bucket | Memungkinkan penerima untuk membaca ACL objek | | WRITE\$1ACP | Memungkinkan penerima untuk menulis ACL untuk bucket yang berlaku | Memungkinkan penerima untuk menulis ACL untuk objek yang berlaku | | FULL\$1CONTROL | Memungkinkan penerima pemberian READ, WRITE, READ\$1ACP, dan WRITE\$1ACP izin pada bucket | Memungkinkan penerima pemberian READ, WRITE\$1ACP, dan READ\$1ACP 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)](#acl-overview) 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](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)). 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 read/write izin dasar, mirip dengan izin sistem file. Untuk informasi lebih lanjut tentang kapan harus menggunakan ACL, lihat [Identity and Access Management untuk Amazon S3](security-iam.md). Untuk informasi selengkapnya tentang izin ACL di konsol Amazon S3, lihat [Mengkonfigurasi ACLs](managing-acls.md). | 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\$1ACP | s3:GetBucketAcl | s3:GetObjectAcl dan s3:GetObjectVersionAcl | | WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl dan s3:PutObjectVersionAcl | | FULL\$1CONTROL | Setara dengan pemberian izin READ, WRITE, READ\$1ACP, dan izin ACL WRITE\$1ACP. Oleh karena itu, izin ACL ini dipetakan ke kombinasi izin kebijakan akses yang sesuai. | Setara dengan pemberian izin READ, READ\$1ACP, dan izin ACL WRITE\$1ACP. 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](#canned-acl). Misalnya kebijakan yang melibatkan header spesifik ACL, lihat. [Pemberian s3: PutObject izin dengan syarat yang mengharuskan pemilik bucket untuk mendapatkan kontrol penuh](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1) *Untuk daftar lengkap kunci kondisi khusus Amazon S3, lihat [Tindakan, sumber daya, dan kunci kondisi untuk Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html) 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](using-with-s3-policy-actions.md) ## 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 CloudTrail`aclRequired`Nilai 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 yang `bucket-owner-full-control` dikalengkan, 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 (\$1) 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) | \$1 | Tidak berlaku | \$1 | 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 | \$1 | \$1 | \$1 | Ya atau Tidak | Ya | Permintaan pemberian ACL | | PutBucketAcl | \$1 | Tidak berlaku | \$1 | 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) | \$1 | Tidak berlaku | \$1 | 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 | \$1 | \$1 | \$1 | 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. **Example** ``` 1. 2. 3. 4. Owner-canonical-user-ID 5. 6. 7. 8. 9. Owner-canonical-user-ID 10. 11. FULL_CONTROL 12. 13. 14. 15. 16. user1-canonical-user-ID 17. 18. WRITE 19. 20. 21. 22. 23. user2-canonical-user-ID 24. 25. READ 26. 27. 28. 29. 30. http://acs.amazonaws.com/groups/global/AllUsers 31. 32. READ 33. 34. 35. 36. http://acs.amazonaws.com/groups/s3/LogDelivery 37. 38. WRITE 39. 40. 41. 42. ``` ## 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\$1CONTROL. Tidak ada orang lain yang memiliki hak mengakses (default). | | public-read | Bucket dan objek | Pemilik mendapatkan FULL\$1CONTROL. Grup AllUsers (lihat [Siapa itu penerima?](#specifying-grantee)) mendapat akses READ. | | public-read-write | Bucket dan objek | Pemilik mendapatkan FULL\$1CONTROL. Grup AllUsers mendapatkan akses READ dan WRITE. memberikan ini pada bucket umumnya tidak disarankan. | | aws-exec-read | Bucket dan objek | Pemilik mendapatkan FULL\$1CONTROL. Amazon EC2 mendapatkan akses READ ke sebuah paketan Amazon Machine Image (AMI) GET dari Amazon S3. | | authenticated-read | Bucket dan objek | Pemilik mendapatkan FULL\$1CONTROL. Grup AuthenticatedUsers mendapat akses READ. | | bucket-owner-read | Objek | Pemilik objek mendapat FULL\$1CONTROL. 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\$1CONTROL 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\$1ACP pada bucket. Untuk informasi lebih lanjut tentang log, lihat ([Pencatatan permintaan dengan pencatatan akses server](ServerLogs.md)). | **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.