Menggunakan hierarki resource untuk kontrol akses

Catatan: Sekarang Anda dapat menggunakan kebijakan penolakan untuk mencegah akun utama menggunakan beberapa izin. Menggunakan kebijakan penolakan dapat menyebabkan fitur yang dijelaskan di halaman ini berfungsi secara berbeda.

Resource Google Cloud diatur secara hierarkis, di mana node organisasi adalah node root dalam hierarki, project adalah turunan organisasi, dan resource lainnya adalah turunan dari project. Anda dapat menetapkan kebijakan izin di berbagai tingkat hierarki resource. Resource mewarisi kebijakan izin resource induk. Kebijakan perizinan yang efektif untuk resource adalah gabungan dari kebijakan izin yang ditetapkan pada resource tersebut dan kebijakan izin yang diwarisi dari induknya.

Halaman ini menjelaskan beberapa contoh cara kerja kebijakan mengizinkan warisan dan menjelaskan praktik terbaik yang harus Anda pertimbangkan saat membuat resource selama deployment Identity and Access Management (IAM).

Prasyarat

• Pahami konsep dasar IAM, khususnya hierarki resource Google Cloud.

Latar belakang

Diagram berikut menunjukkan contoh hierarki resource Google Cloud.

IAM memungkinkan Anda menetapkan kebijakan izin pada tingkat hierarki resource berikut:

• Tingkatan organisasi. Resource organisasi mewakili perusahaan Anda. Peran IAM yang diberikan pada tingkat ini diwarisi oleh semua resources dalam organisasi. Untuk mengetahui informasi selengkapnya, lihat Kontrol akses untuk organisasi yang menggunakan IAM..

• Tingkatan folder. Folder dapat berisi project, folder lain, atau kombinasi keduanya. Peran yang diberikan pada tingkat folder tertinggi akan diwarisi oleh project atau folder lain yang berada di folder induk tersebut. Untuk mengetahui informasi selengkapnya, lihat Kontrol akses untuk organisasi yang menggunakan IAM..

• Level project Project mewakili batas kepercayaan dalam perusahaan Anda. Layanan dalam project yang sama memiliki tingkat kepercayaan default. Misalnya, instance App Engine dapat mengakses bucket Cloud Storage dalam project yang sama. Peran IAM yang diberikan pada level project diwarisi oleh resource dalam project tersebut. Untuk mengetahui informasi selengkapnya, lihat Kontrol akses untuk organisasi yang menggunakan IAM..

• Tingkatan resource. Selain sistem Cloud Storage dan ACL BigQuery yang sudah ada, resource tambahan seperti Set Data Genomics, topik Pub/Sub, dan instance Compute Engine mendukung peran tingkat yang lebih rendah sehingga Anda dapat memberikan izin kepada pengguna tertentu ke satu sumber daya dalam sebuah proyek.

Kebijakan izin bersifat hierarkis dan menyebar ke bawah struktur. Kebijakan perizinan yang efektif untuk resource adalah gabungan dari kebijakan izin yang ditetapkan pada resource tersebut dan kebijakan izin yang diwarisi dari induknya.

Contoh berikut menjelaskan cara kerja kebijakan izin warisan.

Contoh: Pub/Sub

Di Pub/Sub, topik dan langganan adalah resource yang ada dalam project. Asumsikan project_1 memiliki topik topic_a di bawahnya. Jika Anda menetapkan kebijakan izin di project_1 yang memberikan peran Editor ke [e-mail], dan menetapkan kebijakan izin di topic_a yang memberikan peran Penayang kepada [e-mail], Anda secara efektif berikan peran Editor kepada [e-mail] dan peran Penayang kepada [e-mail] untuk topic_a.

Diagram berikut menggambarkan contoh sebelumnya.

Peran Owner, Editor, dan Viewer bersifat konsentris; yaitu, peran Owner menyertakan izin dalam peran Editor, dan peran Editor menyertakan izin peran Viewer. Jika Anda memberikan peran yang lebih luas dan terbatas (seperti Editor dan Viewer) kepada orang yang sama, hanya peran yang lebih luas yang akan diberikan kepada mereka. Misalnya, Anda memberikan peran Editor kepada [e-mail] di level project dan memberikan peran Viewer kepada [e-mail] untuk topic_a, Bob akan diberi peran Editor untuk topic_a. Hal ini karena Anda telah memberi Bob peran Editor untuk topic_a, yang diwarisi dari kebijakan izinkan yang ditetapkan di project_a.

Diagram berikut menggambarkan contoh sebelumnya.

Contoh: Cloud Storage

Di Cloud Storage, bucket dan objek adalah resource, dan objek terletak di bucket. Contoh penggunaan IAM dengan Cloud Storage adalah mengizinkan akses baca ke file yang diupload.

Pertimbangkan sebuah skenario saat banyak pengguna mengupload file ke bucket, tetapi mereka tidak dapat membaca atau menghapus file yang diupload oleh pengguna lain. Pakar pemrosesan data Anda seharusnya dapat membaca dan menghapus file yang diupload, tetapi tidak dapat menghapus bucket karena orang lain menggunakan lokasi bucket tersebut untuk mengupload file mereka. Dalam skenario ini, Anda akan menetapkan kebijakan izin pada project sebagai berikut:

• Berikan peran Amin Storage Object kepada pakar pemrosesan data Anda, Alice di [e-mail].
  • Alice memiliki hak admin objek di level project dan dapat membaca, menambahkan, serta menghapus objek apa pun di bucket mana pun dalam project.
• Berikan Storage Object Creator ke grup pengguna, [e-mail].
  • Kebijakan izin ini berarti siapa pun yang merupakan anggota grup [e-mail] dapat mengupload file ke bucket.
  • Anggota grup memiliki file yang mereka upload, tetapi mereka tidak dapat membaca atau menghapus file yang diupload pengguna lain.

Diagram berikut menggambarkan contoh sebelumnya.

Contoh: Compute Engine

Di perusahaan yang lebih besar, pengelolaan resource jaringan dan keamanan seperti firewall biasanya dikelola oleh tim khusus, yang berbeda dengan tim pengembangan. Tim pengembangan mungkin menginginkan fleksibilitas untuk meluncurkan instance dan melakukan tindakan lain yang terkait dengan instance dalam project mereka. Memberikan peran Admin Compute Network pada tingkat organisasi kepada [e-mail] dan Compute Instance Admin kepada [e-mail] di project-nya project_2 memungkinkan Alice melakukan tindakan apa pun pada instance sekaligus mencegahnya membuat perubahan pada resource jaringan yang terkait dengan projectnya. Hanya Bob yang dapat melakukan perubahan pada resource jaringan dalam organisasi dan pada project apa pun dalam organisasi tersebut.

Izin untuk melihat kebijakan yang diwariskan

Guna melihat kebijakan IAM yang diwarisi dari resource induk, Anda memerlukan izin untuk melihat kebijakan IAM resource induk. Misalnya, untuk melihat semua kebijakan IAM yang diwariskan untuk sebuah project, Anda perlu izin untuk melihat kebijakan IAM organisasi induk project dan untuk melihat kebijakan IAM folder induk.

Guna mendapatkan izin yang diperlukan untuk melihat kebijakan IAM yang diwarisi dari resource induk, minta administrator untuk memberi Anda peran IAM berikut:

• Melihat kebijakan IAM yang diwarisi dari organisasi: Administrator Organisasi (roles/resourcemanager.organizationAdmin) pada organisasi tersebut
• Melihat kebijakan IAM yang diwarisi dari folder: Folder Admin (roles/resourcemanager.folderAdmin) di folder tersebut
• Melihat kebijakan IAM yang diwarisi dari sebuah project: Admin IAM Project (roles/resourcemanager.projectIamAdmin) pada project tersebut

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses.

Peran yang telah ditetapkan ini berisi izin yang diperlukan untuk melihat kebijakan IAM yang diwarisi dari resource induk. Untuk melihat izin yang benar-benar diperlukan, perluas bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk melihat kebijakan IAM yang diwarisi dari resource induk:

• Melihat kebijakan IAM yang diwariskan dari organisasi: resourcemanager.organizations.getIamPolicy pada organisasi tersebut
• Melihat kebijakan IAM yang diwarisi dari folder: resourcemanager.folders.getIamPolicy di folder tersebut
• Melihat kebijakan IAM yang diwariskan dari project: resourcemanager.projects.getIamPolicy pada project tersebut

Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

Catatan: Di Google Cloud Console, halaman IAM resource hanya menampilkan peran yang diwariskan jika peran tersebut dapat diberikan pada resource.

Praktik terbaik

• Mencerminkan struktur hierarki resource Google Cloud Anda ke struktur organisasi Anda. Hierarki resource Google Cloud harus mencerminkan pengaturan perusahaan Anda, baik itu startup, UKM, atau perusahaan besar. Startup dapat dimulai dengan hierarki resource datar tanpa resource organisasi. Saat lebih banyak orang mulai berkolaborasi pada project dan jumlah project meningkat, mendapatkan resource organisasi mungkin merupakan hal yang masuk akal. Resource organisasi direkomendasikan untuk perusahaan besar yang memiliki beberapa departemen dan tim, di mana setiap tim bertanggung jawab atas kumpulan aplikasi dan layanan mereka sendiri.

• Gunakan project untuk mengelompokkan resource yang memiliki batas kepercayaan yang sama. Misalnya, resource untuk produk atau microservice yang sama dapat dimiliki project yang sama.

• Berikan peran ke grup Google, bukan ke masing-masing pengguna jika memungkinkan. Lebih mudah mengelola anggota di grup Google daripada memperbarui kebijakan izin. Pastikan untuk mengontrol kepemilikan grup Google yang digunakan dalam kebijakan izin.

  Untuk informasi lebih lanjut tentang cara mengelola grup Google, lihat bantuan Google Grup.

• Gunakan prinsip keamanan hak istimewa terendah untuk memberikan peran IAM; yaitu, hanya memberikan jumlah akses paling sedikit yang diperlukan untuk resource Anda

  Untuk menemukan peran bawaan yang sesuai, lihat referensi peran standar. Jika tidak ada peran bawaan yang sesuai, Anda juga dapat membuat peran khusus sendiri.

• Berikan peran pada cakupan terkecil yang diperlukan. Misalnya, jika pengguna hanya memerlukan akses untuk memublikasikan pesan ke topik Pub/Sub, berikan peran Penayangan kepada pengguna untuk topik tersebut.

• Perlu diingat kebijakan izin untuk resource turunan mewarisi dari kebijakan izin untuk resource induknya. Misalnya, jika kebijakan izin untuk suatu project memberi pengguna kemampuan untuk mengelola instance virtual machine (VM) Compute Engine, maka pengguna dapat mengelola VM Compute Engine apa pun dalam project tersebut, terlepas dari kebijakan izin yang Anda tetapkan pada setiap VM.

• Di setiap project, pastikan setidaknya dua akun utama memiliki peran Owner (roles/owner). Selain itu, berikan peran Pemilik ke grup Google yang berisi setidaknya dua akun utama.

  Praktik ini membantu memastikan jika salah satu prinsipal keluar dari perusahaan, Anda masih memiliki cara untuk mengelola project.

• Jika Anda perlu memberikan peran kepada pengguna atau grup yang mencakup beberapa project, tetapkan peran tersebut di level folder, bukan menetapkannya di level project.

• Menggunakan label untuk menganotasi, mengelompokkan, dan memfilter resource.

• Audit kebijakan izin Anda untuk memastikan kepatuhan. Log audit berisi semua panggilan setIamPolicy(), sehingga Anda dapat melacak kapan kebijakan izin dibuat atau diubah.

• Audit kepemilikan dan keanggotaan grup Google yang digunakan dalam kebijakan izin.

• Jika Anda ingin membatasi pembuatan project di organisasi, ubah kebijakan akses organisasi untuk memberikan peran Project Creator ke yang Anda kelola.