Daftar kontrol akses (ACL)

Penggunaan

Halaman ini berisi ringkasan tentang daftar kontrol akses (ACL). Untuk mempelajari cara lain dalam mengontrol akses ke bucket dan objek, baca Ringkasan Kontrol Akses.

Haruskah menggunakan daftar kontrol akses?

Pada umumnya, Identity and Access Management (IAM) adalah metode yang direkomendasikan untuk mengontrol akses ke resource:

• IAM memberikan kontrol akses ke seluruh Google Cloud.
• IAM memiliki kontrol lebih atas tindakan yang boleh dilakukan pengguna.
• Izin IAM yang diberikan ke resource induk, seperti project, akan diwariskan ke resource turunan, seperti bucket dan objek. Dengan begitu, Anda dapat lebih mudah mengontrol akses ke resource.
• Izin IAM dapat diterapkan ke folder terkelola, sedangkan ACL tidak.
• ACL tidak dapat digunakan secara eksklusif untuk mengontrol akses ke resource Anda, karena tidak dapat ditetapkan di keseluruhan project atau resource induk lain.

Dengan menggunakan IAM secara eksklusif dan mengaktifkan akses level bucket yang seragam, Anda dapat menggunakan fitur keamanan Google Cloud lain, seperti fitur berbagi terbatas domain, workforce identity federation, dan Kondisi IAM.

Anda kemungkinan besar akan menggunakan ACL dalam kasus berikut:

• Ketika Anda perlu menyesuaikan akses ke tiap-tiap objek dalam suatu bucket. ACL dapat ditetapkan untuk tiap-tiap objek, sedangkan izin IAM hanya dapat diberikan pada level bucket atau yang lebih tinggi.
• Ketika Anda menggunakan XML API secara eksklusif atau memerlukan interoperabilitas dengan Amazon S3.

IAM dan ACL berfungsi bersama-sama untuk memberikan akses ke bucket dan objek. Dengan kata lain, pengguna hanya memerlukan izin yang relevan dari salah satu sistem ini untuk dapat mengakses bucket atau objek.

Catatan: Pada umumnya, izin yang diberikan oleh kebijakan IAM tidak muncul di ACL. Begitu pula sebaliknya, izin yang diberikan oleh ACL tidak muncul di kebijakan IAM. Satu-satunya pengecualian adalah untuk ACL yang diterapkan langsung di bucket dan kebijakan IAM level bucket tertentu, seperti yang dijelaskan di Hubungan IAM dengan ACL. Untuk mengurangi beban pengelolaan dan pelacakan, Anda harus menonaktifkan sistem ACL dan menggunakan IAM secara eksklusif.

Apa itu daftar kontrol akses?

Daftar kontrol akses (ACL) adalah mekanisme yang bisa digunakan untuk menentukan siapa saja yang memiliki akses ke bucket dan objek Anda, serta tingkat akses yang mereka miliki. Di Cloud Storage, Anda menerapkan ACL ke tiap-tiap bucket dan objek. Setiap ACL terdiri dari satu entri atau lebih. Suatu entri memberi pengguna tertentu (atau grup) kemampuan untuk melakukan tindakan tertentu. Setiap entri terdiri dari dua informasi:

• Izin, yaitu informasi yang menentukan tindakan apa saja yang dapat dilakukan (misalnya, baca atau tulis).

• Cakupan, (kadang disebut sebagai penerima akses), yaitu informasi yang menentukan siapa saja yang dapat melakukan tindakan tertentu (misalnya, pengguna atau grup pengguna tertentu).

Sebagai contoh, anggaplah Anda memiliki bucket yang akses objeknya ingin diberikan kepada semua orang. Namun, Anda juga ingin memberi kolaborator kemampuan untuk menambahkan atau menghapus objek dari bucket itu. Dalam kasus ini, ACL Anda akan terdiri dari dua entri:

• Di satu entri, berikan izin READER untuk cakupan allUsers.

• Di entri lainnya, berikan izin WRITER untuk cakupan kolaborator Anda (ada beberapa cara untuk menetapkan orang ini, seperti menggunakan email mereka).

Jumlah maksimum entri ACL yang dapat Anda buat untuk bucket atau objek adalah 100. Cakupan entri yang berupa grup atau domain akan dihitung sebagai satu entri ACL, berapa pun jumlah pengguna yang ada di dalam grup atau domain.

Saat pengguna meminta akses ke bucket atau objek, sistem Cloud Storage akan membaca ACL bucket atau objek lalu menentukan apakah akan mengizinkan atau menolak permintaan akses tersebut. Jika ACL memberi pengguna izin untuk operasi yang diminta, permintaan akan diizinkan. Jika ACL tidak memberi pengguna izin untuk operasi yang diminta, permintaan akan gagal dan error 403 Forbidden akan ditampilkan.

Perlu diingat bahwa meskipun ACL dapat digunakan untuk mengelola sebagian besar tindakan yang melibatkan bucket dan objek, kemampuan untuk membuat bucket berasal dari izin project yang sesuai.

Izin

Izin menjelaskan tindakan apa saja yang dapat dilakukan pada objek atau bucket tertentu.

Cloud Storage memungkinkan Anda untuk memberikan izin konsentris berikut pada bucket dan objek, seperti yang ditampilkan pada tabel di bawah:

	Bucket	Objek
READER	Mengizinkan pengguna mencantumkan konten bucket. Juga mengizinkan pengguna membaca metadata bucket, kecuali ACL.	Mengizinkan pengguna mendownload data objek.
WRITER	Memberi pengguna semua akses yang diberikan oleh izin READER. Juga mengizinkan pengguna membuat, mengganti, dan menghapus objek dalam bucket, termasuk membuat objek menggunakan upload multibagian.	T/A. Anda tidak dapat menerapkan izin ini ke objek.
OWNER	Memberi pengguna semua akses yang diberikan oleh izin WRITER. Juga mengizinkan pengguna membaca dan menulis metadata bucket, termasuk ACL, dan memungkinkan pengguna untuk menggunakan tag pada bucket.	Memberi pengguna semua akses yang diberikan oleh izin READER. Dan mengizinkan pengguna membaca dan menulis metadata objek, termasuk ACL.
Default	Bucket memiliki ACL project-private bawaan yang diterapkan saat dibuat. Bucket selalu dimiliki oleh grup project-owners.	Objek memiliki ACL project-private bawaan yang diterapkan saat diupload. Objek selalu dimiliki oleh pemohon permintaan asli yang mengupload objek.

Catatan: Anda tidak dapat memberikan izin terpisah untuk membaca atau menulis ACL atau metadata lain. Untuk mengizinkan pengguna membaca dan menulis ACL, Anda harus memberi mereka izin OWNER .

Di halaman ini, kami umumnya menyebut izin tersebut sebagai READER, WRITER, dan OWNER, sebagaimana digunakan di JSON API dan Konsol Google Cloud. Jika Anda menggunakan XML API, izin yang setara adalah READ, WRITE, dan FULL_CONTROL.

Cakupan

Cakupan menentukan siapa saja yang memiliki izin tertentu.

Suatu ACL terdiri dari satu entri atau lebih, dan setiap entrinya memberikan izin ke suatu cakupan. Anda dapat menentukan cakupan ACL menggunakan entity berikut:

Cakupan ("penerima akses")	Jenis Entity	Contoh
ID khusus untuk semua entitas	Pengguna	allUsers
ID khusus untuk semua akun yang valid	Pengguna	allAuthenticatedUsers
Alamat email akun pengguna	Pengguna	[e-mail]
Alamat email grup Google	Grup	[e-mail]
Nilai praktis untuk project	Project	owners-123456789012
Domain Google Workspace	Domain	USERNAME@YOUR_DOMAIN.com
Domain Cloud Identity	Domain	USERNAME@YOUR_DOMAIN.com
Identitas tunggal dalam kumpulan identitas tenaga kerja	Akun utama	//iam.googleapis.com/locations/global/workforcePools/my-pool/subject/[e-mail]
Semua identitas tenaga kerja dalam grup	PrincipalSet	//iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

• ID khusus untuk semua entitas:

  ID cakupan khusus allUsers mewakili entitas apa pun di Internet. Perlu diperhatikan bahwa meskipun termasuk dalam jenis entity User, ID ini diberi label sebagai jenis entity Public saat menggunakan Konsol Google Cloud.

• ID khusus untuk semua akun yang valid:

  ID cakupan khusus allAuthenticatedUsers mewakili sebagian besar akun yang diautentikasi, termasuk akun layanan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan IAM. Perhatikan bahwa meskipun ID ini adalah jenis entity User, saat menggunakan konsol Google Cloud, ID ini diberi label sebagai jenis entity Public.

• Alamat email akun pengguna:

  Setiap pengguna yang memiliki akun pengguna harus memiliki alamat email unik yang terkait dengan akun tersebut. Anda dapat menentukan cakupan menggunakan alamat email apa pun yang terkait dengan akun pengguna.

  Cloud Storage akan mengingat alamat email yang diberikan di ACL hingga entrinya dihapus atau diganti. Jika pengguna mengubah alamat email, Anda harus memperbarui entri ACL untuk mencerminkan perubahan ini.

• Alamat email grup Google:

  Setiap grup Google memiliki alamat email unik yang terkait dengan grup. Sebagai contoh, grup Cloud Storage Announce memiliki alamat email berikut: [e-mail]. Anda dapat menemukan alamat email yang terkait dengan grup Google dengan mengklik Tentang di halaman beranda setiap grup Google.

  Seperti alamat email akun pengguna, Cloud Storage mengingat alamat email grup seperti yang disediakan dalam ACL hingga entrinya dihapus. Anda tidak perlu khawatir memperbarui alamat email Google Grup, karena alamat email Google Grup bersifat permanen dan tidak akan berubah.

• Nilai praktis untuk project:

  Nilai praktis memungkinkan Anda untuk memberikan akses massal kepada viewer, editor, dan pemilik project. Nilai praktis menggabungkan peran project dan nomor project yang terkait. Misalnya, dalam project 867489160491, editor diidentifikasi sebagai editors-867489160491. Anda dapat menemukan nomor project di halaman beranda Konsol Google Cloud.

  Umumnya, Anda sebaiknya menghindari penggunaan nilai kemudahan di lingkungan produksi, karena nilai tersebut memerlukan pemberian peran dasar, yaitu praktik yang tidak disarankan dalam lingkungan produksi.

• Google Workspace atau Cloud Identity:

  Pelanggan Google Workspace dan Cloud Identity dapat mengaitkan akun email mereka dengan nama domain Internet. Saat Anda melakukannya, setiap akun email akan menggunakan format USERNAME@YOUR_DOMAIN.com. Anda dapat menentukan cakupan menggunakan nama domain Internet apa pun yang dikaitkan dengan Google Workspace atau Cloud Identity.

• Identitas tenaga kerja:

  Workforce Identity federation memungkinkan Anda menggunakan penyedia identitas (IdP) eksternal untuk mengautentikasi dan memberi otorisasi grup pengguna menggunakan IAM, sehingga pengguna dapat mengakses layanan Google Cloud.

Izin dan cakupan konsentris

Saat menentukan ACL di Cloud Storage, Anda tidak perlu mencantumkan beberapa cakupan untuk memberikan beberapa izin. Cloud Storage menggunakan izin konsentris. Jadi, saat memberikan izin WRITER, Anda juga memberikan izin READER, dan jika memberikan OWNER, Anda juga memberikan izin READER dan WRITER.

Saat menentukan ACL, sebagian besar alat memungkinkan Anda untuk menentukan beberapa cakupan sekaligus untuk entri yang sama. Izin akses yang paling permisif adalah akses yang diberikan ke cakupan. Misalnya, jika Anda memberikan dua entri untuk seorang pengguna, yaitu satu entri dengan izin READER dan satu lagi dengan izin WRITER di bucket, pengguna tersebut akan memiliki izin WRITER di bucket.

Di XML API, Anda tidak dapat memberikan dua entri ACL dengan cakupan yang sama. Misalnya, jika Anda memberi pengguna izin READ dan WRITE di bucket, error akan ditampilkan. Sebagai gantinya, beri pengguna izin WRITE, yang juga memberikan izin READ kepada pengguna.

ACL bawaan

ACL bawaan, yang sering juga disebut sebagai ACL template, adalah nama lain untuk serangkaian entri ACL tertentu yang dapat Anda gunakan untuk menerapkan banyak entri ACL sekaligus ke bucket atau objek dengan cepat.

Perhatian: Dengan menerapkan ACL bawaan ke bucket atau objek yang ada, Anda sepenuhnya mengganti ACL bucket atau objek yang ada dengan ACL bawaan. Dalam beberapa kasus, perubahan ini dapat menyebabkan hilangnya akses ke ACL bucket atau objek. Sebagai contoh, Anda berada dalam grup project owner, tetapi bukanlah pemilik objek dengan ACL projectPrivate. Kemudian setelah menerapkan ACL bawaan publicRead ke objek, Anda akan kehilangan izin OWNER dan tidak dapat lagi mengakses ACL objek tersebut. Jika hal ini terjadi, Anda dapat menggunakan peran IAM storage.objectAdmin agar memiliki izin yang diperlukan untuk memperbarui ACL objek dan memperbaiki perubahan tersebut.

Tabel berikut berisi daftar ACL bawaan serta entri ACL mana yang diterapkan untuk setiap ACL bawaan. Saat menggunakan tabel berikut, perhatikan bahwa:

• Grup project owner memiliki kepemilikan bucket di project, dan pengguna yang membuat objek menjadi pemilik objek tersebut. Jika objek dibuat oleh pengguna anonim, kepemilikan objek diberikan kepada grup project owner.

• Tabel ini menggunakan deskripsi izin JSON API, yaitu OWNER, WRITER, dan READER. Cakupan XML API yang setara adalah FULL_CONTROL, WRITE, dan READ.

  JSON API/gcloud storage	API XML	Deskripsi
  private	private	Memberi pemilik bucket atau objek izin OWNER pada bucket atau objek.
  bucketOwnerRead	bucket-owner-read	Memberi pemilik objek izin OWNER, dan memberi pemilik bucket izin READER. Izin ini hanya digunakan dengan objek.
  bucketOwnerFullControl	bucket-owner-full-control	Memberi pemilik objek dan bucket izin OWNER. Izin ini hanya digunakan dengan objek.
  projectPrivate	project-private	Memberikan izin kepada tim project berdasarkan peran mereka. Semua orang yang menjadi anggota tim memiliki izin READER. Project owner dan editor project memiliki izin OWNER. ACL ini ditetapkan secara default untuk bucket yang baru dibuat. ACL ini juga ditetapkan secara default untuk objek yang baru dibuat, kecuali jika ACL objek default untuk bucket tersebut telah diubah.
  authenticatedRead	authenticated-read	Memberikan izin OWNER kepada pemilik bucket atau objek, dan memberikan izin READER kepada semua pemegang akun pengguna yang diautentikasi.
  publicRead	public-read	Memberi pemilik bucket atau objek izin OWNER, dan memberi semua pengguna, baik yang terautentikasi maupun anonim, izin READER . Saat menerapkannya ke objek, semua orang di internet dapat membaca objek tersebut tanpa perlu melakukan autentikasi. Saat menerapkannya ke bucket, semua orang di internet dapat mencantumkan objek tanpa perlu melakukan autentikasi. * Lihat catatan di akhir tabel tentang penyimpanan data ke dalam cache.
  publicReadWrite	public-read-write	Memberi pemilik bucket izin OWNER, dan memberi semua pengguna, baik yang terautentikasi maupun anonim, izin READER dan WRITER. ACL ini hanya berlaku untuk bucket. Jika Anda menerapkannya ke bucket, semua orang di internet dapat mencantumkan, membuat mengganti, dan menghapus objek tanpa perlu melakukan autentikasi. Penting: Jika bucket ditetapkan ke publicReadWrite, semua orang di internet dapat mengupload apa saja ke bucket Anda. Anda bertanggung jawab atas konten ini. * Lihat catatan di akhir tabel tentang penyimpanan data ke dalam cache.

* Secara default, objek yang dapat dibaca oleh publik disajikan dengan header Cache-Control, sehingga dapat di-cache selama 3.600 detik. Jika perlu memastikan bahwa update segera terlihat, Anda harus menetapkan metadata Cache-Control untuk objek tersebut ke Cache-Control:private, max-age=0, no-transform.

ACL default

Saat bucket dibuat atau objek diupload, ACL default akan diberikan jika Anda tidak menetapkan ACL secara eksplisit pada bucket atau objek tersebut. Anda dapat mengubah ACL default yang ditetapkan ke object tersebut. Caranya dapat Anda temukan di Mengubah ACL objek default. Perlu diperhatikan bahwa jika Anda mengubah ACL default, ACL objek yang sudah ada pada bucket di project tidak akan berubah.

ACL bucket default

Semua bucket dimiliki oleh grup project owner. Project owner juga diberi izin OWNER untuk setiap bucket dalam project yang menggunakan ACL bawaan.

Jika Anda membuat bucket dengan ACL bucket default, yaitu ketika Anda tidak menentukan ACL bawaan saat membuat bucket, ACL projectPrivate bawaan ditetapkan ke bucket tersebut.

ACL objek default

Secara default, setiap pengguna yang memiliki izin OWNER atau WRITER di bucket dapat mengupload objek ke bucket tersebut. Saat mengupload objek, Anda dapat memberikan ACL bawaan atau tidak menentukan ACL sama sekali. Jika Anda tidak menentukan ACL, Cloud Storage akan menerapkan ACL objek default bucket ke objek tersebut. Setiap bucket memiliki ACL objek default, dan ACL ini diterapkan ke semua objek yang diupload ke bucket tersebut yang tidak memiliki ACL bawaan atau ACL yang ditentukan di permintaan (khusus JSON API). Nilai awal ACL objek default untuk setiap bucket adalah projectPrivate.

Berdasarkan cara objek diupload, ACL objek diterapkan sebagai berikut:

• Upload yang Diautentikasi

  Jika membuat permintaan terautentikasi untuk mengupload objek dan tidak menentukan ACL objek apa pun saat menguploadnya, Anda akan dicantumkan sebagai pemilik objek dan ACL projectPrivate bawaan diterapkan ke objek secara default. Artinya:

  • Anda (orang yang mengupload objek) dicantumkan sebagai pemilik objek. Kepemilikan objek tidak dapat diubah dengan memodifikasi ACL. Anda dapat mengubah kepemilikan objek hanya dengan mengganti objek.

  • Anda (pemilik objek) diberi izin OWNER pada objek. Jika Anda mencoba memberikan izin yang lebih rendah dari OWNER kepada pemilik, Cloud Storage akan otomatis mengeskalasi izin tersebut menjadi OWNER

  • Grup project owner dan editor project memiliki izin OWNERpada objek.

  • Grup anggota tim project memiliki izin READER pada objek.

• Upload Anonim

  Jika pengguna yang tidak diautentikasi (anonim) mengupload objek, yang bisa terjadi jika bucket memberi grup allUsers izin WRITER atau OWNER, ACL bucket default akan diterapkan ke objek tersebut seperti yang dijelaskan di atas.

  Pengguna anonim tidak dapat menentukan ACL bawaan selama objek diupload.

Penting: Jika Anda mengubah ACL objek default untuk bucket, perubahan tersebut mungkin memerlukan waktu untuk diterapkan, dan objek baru yang dibuat di bucket mungkin masih mendapat ACL objek default lama dalam jangka waktu singkat (lihat Konsistensi). Untuk memastikan bahwa objek baru yang dibuat di bucket mendapat ACL objek yang baru, Anda harus menunggu minimal 30 detik untuk perubahan ACL objek default dan pembuatan objek baru.

Perilaku ACL

Cloud Storage membantu Anda mengikuti praktik terbaik dengan menerapkan beberapa aturan modifikasi ACL, yang mencegah Anda agar tidak menetapkan ACL yang membuat data tidak dapat diakses.

• Anda tidak dapat menerapkan ACL yang menentukan bucket atau pemilik objek yang berbeda.

  Kepemilikan bucket dan objek tidak dapat diubah dengan memodifikasi ACL. Jika Anda menerapkan ACL baru ke bucket atau objek, pastikan pemilik bucket atau objek tidak diubah di ACL baru.

• Pemilik bucket atau objek selalu memiliki izin OWNER pada bucket atau objek.

  Pemilik bucket adalah grup project owner, dan pemilik objek adalah pengguna yang mengupload objek, atau grup project owner jika objek diupload oleh pengguna anonim.

  Saat Anda menerapkan ACL baru ke bucket atau objek, Cloud Storage menambahkan izin OWNER ke bucket atau menambahkan pemilik objek jika Anda menghapus pemberian aksesnya. Tindakan ini tidak memberi grup project owner izin OWNER untuk objek (kecuali jika objek dibuat oleh pengguna anonim), jadi Anda harus menyertakannya secara eksplisit.

Anda tidak dapat menerapkan ACL yang mengubah kepemilikan bucket atau objek (yang tidak boleh disamakan dengan izin OWNER). Setelah dibuat di Cloud Storage, kepemilikan bucket dan objek bersifat permanen. Namun, Anda dapat mengubah kepemilikan objek (bukan bucket) secara efektif dengan menggantinya. Penggantian ini pada dasarnya adalah operasi penghapusan yang langsung diikuti dengan operasi upload. Selama operasi upload, orang yang melakukan upload akan menjadi pemilik objek tersebut. Perlu diingat bahwa untuk mengganti objek, orang yang melakukan penggantian (dan mendapat kepemilikan objek karenanya) harus memiliki izin WRITER atau OWNER pada bucket tempat objek diupload.

Catatan: Anda dapat menonaktifkan semua properti kepemilikan bucket serta objek di dalamnya dengan mengaktifkan akses level bucket yang seragam. Tindakan ini juga akan menghapus semua penggunaan ACL di bucket, sehingga menjadikan kebijakan IAM sebagai satu-satunya sistem kontrol akses yang digunakan oleh bucket.

Langkah selanjutnya

• Pelajari cara menggunakan ACL.
• Pelajari cara menyederhanakan kontrol akses menggunakan akses level bucket seragam.
• Pelajari praktik terbaik untuk menggunakan ACL.