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.

ResourceGoogle Cloud diatur secara hierarkis, dengan 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 resourceGoogle 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. Peran IAM yang diberikan pada level project diwarisi oleh resource dalam project tersebut. Untuk mengetahui informasi selengkapnya, lihat Kontrol akses untuk project yang menggunakan IAM.

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

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 kepada Kalani, dan menetapkan kebijakan izin di topic_a yang memberikan peran Penayang kepada Nur, Anda secara efektif memberikan peran Editor kepada Kalani dan peran Penayang kepada Nur untuk topic_a.

Diagram berikut menggambarkan contoh sebelumnya.

Jika peran yang diwariskan sudah memberi akun utama semua izin yang diperlukan, Anda tidak perlu memberinya peran tambahan pada resource itu sendiri. Memberikan peran lain yang berisi izin yang sama atau lebih sedikit adalah redundan, dan tidak akan berpengaruh.

Misalnya, pertimbangkan peran dasar Pemilik, Editor, dan Viewer. Peran ini bersifat konsentris; yaitu, peran Pemilik menyertakan izin dalam peran Editor, dan peran Editor menyertakan izin peran Viewer. Akibatnya, jika Anda memberi Kalani peran Editor di tingkat project, memberikan peran Viewer di topic_a akan menjadi redundan. Hal ini karena Kalani sudah memiliki semua izin dalam peran Pelihat melalui peran Editor, yang diwarisi dari kebijakan izin project.

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 Storage Object Admin (roles/storage.objectAdmin) kepada pakar pemrosesan data Anda, Nur. Peran ini memungkinkan Nur membaca, menambahkan, dan menghapus objek apa pun di bucket mana pun dalam project.
• Berikan peran Storage Object Creator (roles/storage.objectCreator) ke grup data-uploaders. Peran ini memungkinkan anggota grup mengupload file ke bucket, tetapi tidak mengizinkan mereka 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.

Dalam situasi seperti ini, Anda dapat mengonfigurasi kebijakan izin sebagai berikut:

• Berikan peran Compute Network Admin (roles/compute.networkAdmin) kepada administrator jaringan dan keamanan Anda, Kalani, di tingkat organisasi. Peran ini memungkinkan Kalani melakukan perubahan pada resource jaringan dalam organisasi dan dalam project apa pun dalam organisasi tersebut.
• Berikan peran Compute Instance Admin (roles/compute.instanceAdmin) kepada pimpinan tim pengembangan, Nur, di project-nya project_2. Peran ini memungkinkan Nur melakukan tindakan apa pun pada instance-nya sekaligus mencegahnya melakukan perubahan pada resource jaringan yang terkait dengan project-nya. Namun, hal ini tidak memungkinkan mereka membuat perubahan pada resource jaringan di project lain.

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.

Untuk 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 project: Project IAM Admin (roles/resourcemanager.projectIamAdmin) pada project tersebut

Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

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, luaskan 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 konsol Google Cloud , 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, bukan ke masing-masing pengguna jika memungkinkan. Lebih mudah mengelola anggota dalam grup daripada memperbarui kebijakan izin. Pastikan untuk mengontrol kepemilikan grup 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 Pemilik (roles/owner). Selain itu, berikan peran Pemilik ke grup 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 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.