Menentukan hierarki resource untuk zona landing Google Cloud Anda

Last reviewed 2024-10-31 UTC

Hierarki resource membantu mengelola resource Anda di Google Cloud. Dokumen ini menjelaskan cara memilih hierarki resource sebagai bagian dari desain zona landing Anda. Ini ditujukan untuk administrator sistem cloud, arsitek, dan praktisi teknis yang terlibat dalam mendesain hierarki resource. Dokumen ini adalah bagian dari rangkaian pada zona landing. Ini mencakup hierarki contoh yang menunjukkan cara umum agar bisnis dapat terstruktur resource di Google Cloud.

Faktor desain untuk hierarki resource

Saat menentukan hierarki resource di Google Cloud, Anda harus mempertimbangkan cara kerja organisasi saat ini dan kondisi akhir yang ideal untuk transformasi cloud Anda. Cara terbaik untuk mengelola resource didasarkan pada cara kerja organisasi Anda yang dimaksudkan di cloud. Karena setiap organisasi berbeda, tidak ada pendekatan terbaik untuk hierarki resource.

Namun, sebaiknya Anda jangan memetakan struktur organisasi perusahaan ke hierarki resource. Sebagai gantinya, fokuskan pada kebutuhan dan operasi bisnis Anda di Google Cloud.

Hierarki resource Google Cloud

Hierarki resource di Google Cloud dimulai dari node root, yang disebut organisasi. Sebaiknya bisnis hanya memiliki satu node root, kecuali untuk situasi tertentu. Anda menentukan tingkat hierarki yang lebih rendah menggunakan folder dan project, dan Anda membuat folder di dalam folder untuk membangun hierarki Anda. Anda dapat membuat project yang menghosting beban kerja di tingkat hierarki mana pun.

Diagram berikut menunjukkan node root yang disebut Organisasi, dan folder di tingkat satu, dua, dan tiga. Project dan subfolder dibuat pada folder di level dua.

Faktor hierarki resource

Saat Anda memutuskan hierarki resource, pertimbangkan faktor-faktor berikut:

• Siapa yang bertanggung jawab atas resource cloud? Apakah departemen Anda, anak perusahaan, tim teknis, atau entitas hukum?
• Apa kebutuhan kepatuhan Anda?
• Apakah Anda memiliki peristiwa bisnis yang akan datang, seperti merger, akuisisi, dan spin-off?

Memahami interaksi resource di seluruh hierarki

Kebijakan organisasi diwariskan oleh turunan dalam hierarki resource, tetapi dapat digantikan oleh kebijakan yang ditentukan di level yang lebih rendah. Untuk mengetahui informasi selengkapnya, lihat memahami evaluasi hierarki. Anda menggunakan batasan kebijakan organisasi untuk menetapkan pedoman di seluruh organisasi atau bagian penting dari organisasi dan tetap mengizinkan pengecualian.

Kebijakan izinkan, sebelumnya dikenal sebagai kebijakan IAM diwarisi oleh turunan, dan kebijakan izinkan pada tingkat yang lebih rendah bersifat aditif. Namun, kebijakan izinkan dapat digantikan oleh kebijakan tolak, yang memungkinkan Anda membatasi izin di tingkat project, folder, dan organisasi. Kebijakan tolak diterapkan sebelum kebijakan izinkan.

Anda juga perlu mempertimbangkan hal berikut:

• Cloud Logging mencangkup sink gabungan yang dapat Anda gunakan untuk menggabungkan log di tingkat folder atau organisasi. Untuk informasi selengkapnya, lihat menentukan keamanan untuk zona landing Google Cloud.
• Penagihan tidak dihubungkan langsung ke hierarki resource, tetapi ditetapkan pada level project. Namun, untuk mendapatkan informasi gabungan di level folder, Anda dapat menganalisis biaya berdasarkan hierarki project menggunakan laporan penagihan.
• Kebijakan firewall hierarkis memungkinkan Anda menerapkan kebijakan firewall yang konsisten di seluruh organisasi atau di folder tertentu. Pewarisan bersifat implisit. Artinya, Anda dapat mengizinkan atau menolak traffic di tingkat mana pun, atau mendelegasikan keputusan ke tingkat yang lebih rendah.

Poin keputusan untuk desain hierarki resource

Diagram alir berikut menunjukkan hal-hal yang harus Anda pertimbangkan untuk memilih hierarki resource terbaik bagi organisasi Anda.

Diagram sebelumnya menguraikan poin-poin keputusan berikut:

1. Apakah anak perusahaan, grup region, atau unit bisnis yang berbeda memiliki persyaratan kebijakan yang sangat berbeda?
   1. Jika ya, ikuti desain berdasarkan region atau anak perusahaan.
   2. Jika tidak, lanjutkan ke poin keputusan berikutnya.

2. Apakah workload atau tim produk Anda memerlukan otonomi yang kuat atas kebijakan mereka? Misalnya, Anda tidak memiliki tim keamanan pusat yang menentukan kebijakan untuk semua tim produk atau workload.

   1. Jika ya, lihat desain berdasarkan framework akuntabilitas.

   2. Jika tidak, lihat desain berdasarkan lingkungan aplikasi.

Kasus penggunaan spesifik Anda dapat mengarahkan Anda ke desain hierarki resource lain daripada yang disarankan oleh diagram keputusan. Sebagian besar organisasi memilih pendekatan hybrid dan memilih desain yang berbeda di berbagai tingkat hierarki resource, dimulai dengan desain yang paling memengaruhi kebijakan dan akses.

Opsi 1: Hierarki berdasarkan lingkungan aplikasi

Di banyak organisasi, Anda menentukan kebijakan dan kontrol akses yang berbeda untuk lingkungan aplikasi yang berbeda, seperti pengembangan, produksi, dan pengujian. Memiliki kebijakan terpisah yang terstandardisasi di setiap lingkungan akan memudahkan pengelolaan dan konfigurasi. Misalnya, Anda mungkin memiliki kebijakan keamanan yang lebih ketat di lingkungan produksi daripada di lingkungan pengujian.

Gunakan hierarki berdasarkan lingkungan aplikasi jika hal berikut benar:

• Anda memiliki lingkungan aplikasi terpisah yang memiliki persyaratan kebijakan dan administrasi yang berbeda.
• Anda memiliki persyaratan audit atau keamanan terpusat yang harus dapat diterapkan secara konsisten pada semua workload dan data produksi.
• Anda memerlukan peran Identity and Access Management (IAM) yang berbeda untuk mengakses resource Google Cloud di lingkungan yang berbeda.

Hindari hierarki ini jika kondisi berikut benar:

• Anda tidak boleh menjalankan beberapa lingkungan aplikasi.
• Anda tidak memiliki beragam dependensi aplikasi dan proses bisnis di berbagai lingkungan.
• Anda memiliki perbedaan kebijakan yang kuat untuk region, tim, atau aplikasi yang berbeda.

Diagram berikut menunjukkan hierarki untuk example.com, yang merupakan perusahaan teknologi keuangan fiktif.

Seperti yang ditunjukkan pada diagram sebelumnya, example.com memiliki tiga lingkungan aplikasi yang memiliki kebijakan, kontrol akses, persyaratan peraturan, dan proses berbeda. Lingkungannya adalah sebagai berikut:

• Lingkungan pengembangan dan UM (Uji Mutu): Lingkungan ini dikelola oleh developer yang merupakan karyawan dan konsultan internal. Mereka terus mengirim kode dan bertanggung jawab atas jaminan kualitas. Lingkungan ini tidak pernah tersedia untuk konsumen bisnis Anda. Lingkungan ini memiliki persyaratan integrasi dan autentikasi yang kurang ketat dibandingkan dengan lingkungan produksi, dan developer ditetapkan untuk menyetujui dengan izin yang sesuai. Lingkungan Pengembangan dan UM (Uji Mutu) dirancang hanya untuk penawaran aplikasi standar dari example.com.

• Lingkungan pengujian: Lingkungan ini digunakan untuk regresi dan pengujian aplikasi, serta mendukung penawaran business-to-business (B2B) dari klien example.com yang menggunakan API example.com. Untuk tujuan ini, example.com membuat dua jenis project:

  • Project pengujian internal untuk menyelesaikan regresi, performa, dan konfigurasi internal untuk penawaran B2B.
  • Klien UAT mem-project dengan dukungan multi-tenant sehingga klien B2B dapat memvalidasi konfigurasinya dan selaras dengan persyaratan example.com untuk pengalaman pengguna, branding, alur kerja, laporan, dan sebagainya.

• Lingkungan produksi: Lingkungan ini menghosting semua penawaran produk yang divalidasi, diterima, dan diluncurkan. Lingkungan ini tunduk pada peraturan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) menggunakan modul keamanan hardware (HSM), dan terintegrasi dengan pemroses pihak ketiga untuk item seperti autentikasi dan pembayaran penyelesaian. Tim audit dan kepatuhan adalah pemangku kepentingan yang sangat penting dari lingkungan ini. Akses ke lingkungan ini dikontrol ketat dan sebagian besar terbatas untuk proses deployment otomatis.

Untuk mengetahui informasi selengkapnya tentang mendesain hierarki yang didasarkan pada lingkungan aplikasi, lihat Struktur organisasi dalam blueprint fondasi perusahaan.

Opsi 2: Hierarki berdasarkan region atau anak perusahaan

Beberapa organisasi beroperasi di banyak region dan memiliki anak perusahaan yang menjalankan bisnis di wilayah geografis yang berbeda atau merupakan akibat dari penggabungan dan akuisisi. Organisasi seperti ini memerlukan hierarki resource yang menggunakan opsi pengelolaan dan skalabilitas di Google Cloud, serta menjaga independensi untuk berbagai proses dan kebijakan yang ada di antara region atau anak perusahaan. Hierarki ini menggunakan anak perusahaan atau region sebagai tingkat folder tertinggi dalam hierarki resource. Prosedur deployment biasanya berfokus di sekitar region.

Gunakan hierarki ini jika hal berikut benar:

• Setiap region atau anak perusahaan beroperasi secara independen.
• Region atau anak perusahaan memiliki backbone operasional, penawaran platform digital, dan proses yang berbeda.
• Bisnis Anda memiliki standar peraturan dan kepatuhan yang berbeda untuk region atau anak perusahaan.

Diagram berikut menunjukkan contoh hierarki organisasi global dengan dua anak perusahaan dan grup induk dengan struktur regional.

Diagram sebelumnya memiliki struktur hierarki berikut:

• Folder berikut berada di tingkat pertama:
  • Folder Subsidiary 1 dan Subsidiary 2 mewakili dua anak perusahaan dari perusahaan yang memiliki izin akses dan kebijakan yang berbeda dari seluruh organisasi. Setiap anak perusahaan menggunakan IAM untuk membatasi akses ke project dan resource Google Cloud mereka.
  • Folder Holding group menampilkan grup yang memiliki kebijakan umum tingkat tinggi di seluruh region.
  • Folder Bootstrap menunjukkan resource umum yang diperlukan untuk men-deploy infrastruktur Google Cloud Anda, seperti yang dijelaskan dalam blueprint enterprise foundation.
• Pada level kedua, dalam folder Induk grup terdapat folder berikut:
  • Folder APAC, EMEA, dan Americas menampilkan berbagai region dalam grup yang memiliki tata kelola, izin akses, dan kebijakan yang berbeda.
  • Folder Shared infrastructure menampilkan resource yang digunakan secara global di semua region.
• Dalam setiap folder terdapat berbagai project yang berisi resource yang menjadi tanggung jawab anak perusahaan atau region ini.

Anda dapat menambahkan lebih banyak folder untuk memisahkan entitas hukum, departemen, dan tim yang berbeda dalam perusahaan Anda.

Opsi 3: Hierarki berdasarkan framework akuntabilitas

Hierarki berdasarkan framework akuntabilitas akan berfungsi optimal jika produk Anda dijalankan secara independen, atau jika unit organisasi memiliki tim yang memiliki siklus proses produk dengan jelas. Dalam organisasi ini, pemilik produk bertanggung jawab atas seluruh siklus proses produk, termasuk proses, dukungan, kebijakan, keamanan, dan hak akses. Produk Anda independen satu sama lain dan panduan serta kontrol di seluruh organisasi jarang digunakan.

Gunakan hierarki ini jika hal berikut benar:

• Anda menjalankan organisasi yang memiliki kepemilikan dan akuntabilitas yang jelas untuk setiap produk.
• Workload Anda bersifat independen dan tidak berbagi banyak kebijakan umum yang sama.
• Proses dan platform developer eksternal Anda ditawarkan sebagai penawaran layanan atau produk.

Diagram berikut menunjukkan contoh hierarki untuk penyedia platform e-commerce.

Diagram sebelumnya memiliki struktur hierarki berikut:

• Folder berikut berada di tingkat pertama:
  • Folder yang diberi nama Ecommerce Modules dan Logistics and Warehousing Modules menampilkan modul dalam penawaran platform yang memerlukan izin dan kebijakan akses yang sama selama siklus proses produk.
  • Folder Reconciliation and Billing mewakili tim produk yang bertanggung jawab atas modul menyeluruh untuk komponen bisnis tertentu dalam penawaran platform.
  • Folder Bootstrap menunjukkan resource umum yang diperlukan untuk men-deploy infrastruktur Google Cloud Anda, seperti yang dijelaskan dalam blueprint foundation perusahaan.
• Dalam setiap folder, terdapat berbagai project yang berisi modul independen yang menjadi tanggung jawab berbagai tim produk.

Untuk mengetahui informasi lebih lanjut, lihat Hierarki resource framework Terraform Fabric FAST.

Praktik terbaik untuk hierarki resource

Bagian berikut menjelaskan praktik terbaik untuk mendesain hierarki resource yang kami rekomendasikan, apa pun hierarki resource yang Anda pilih.

Untuk mengetahui praktik terbaik lainnya mengenai cara mengonfigurasi akun dan organisasi Cloud Identity dan Google Workspace, lihat Praktik terbaik untuk merencanakan akun dan organisasi.

Gunakan satu node organisasi

Untuk menghindari overhead pengelolaan, gunakan satu node organisasi jika memungkinkan. Namun, pertimbangkan untuk menggunakan beberapa node organisasi untuk mengatasi kasus penggunaan berikut:

• Anda ingin menguji perubahan besar pada level IAM atau hierarki resource.
• Anda ingin bereksperimen di lingkungan sandbox yang tidak memiliki kebijakan organisasi yang sama.
• Organisasi Anda menyertakan sub-perusahaan yang kemungkinan akan dijual atau dijalankan sebagai entitas yang sepenuhnya terpisah di masa mendatang.

Gunakan konvensi penamaan standar

Gunakan konvensi penamaan standar di seluruh organisasi Anda. Blueprint security foundation memiliki contoh konvensi penamaan yang dapat Anda sesuaikan dengan kebutuhan Anda.

Menjaga agar resource bootstrap dan layanan umum tetap terpisah

Simpan folder terpisah untuk melakukan bootstrap lingkungan Google Cloud menggunakan infrastruktur sebagai kode (IaC) dan untuk layanan umum yang digunakan bersama antara lingkungan atau aplikasi. Tempatkan folder bootstrap tepat di bawah node organisasi dalam hierarki resource.

Tempatkan folder untuk layanan umum di berbagai tingkat hierarki, bergantung pada struktur yang Anda pilih.

Tempatkan folder untuk layanan umum tepat di bawah node organisasi jika hal berikut benar:

• Hierarki Anda menggunakan lingkungan aplikasi di level tertinggi dan tim atau aplikasi di lapisan kedua.
• Anda memiliki layanan bersama seperti pemantauan yang umum di antara lingkungan.

Tempatkan folder untuk layanan umum di tingkat yang lebih rendah, di bawah folder aplikasi, jika hal berikut benar:

• Anda memiliki layanan yang digunakan bersama di antara aplikasi dan men-deploy instance terpisah untuk setiap lingkungan deployment.

• Aplikasi berbagi microservice yang memerlukan pengembangan dan pengujian untuk setiap lingkungan deployment.

Diagram berikut menunjukkan contoh hierarki yang berisi folder infrastruktur bersama yang digunakan oleh semua lingkungan dan folder layanan bersama untuk setiap lingkungan aplikasi pada level yang lebih rendah dalam hierarki:

Diagram sebelumnya memiliki struktur hierarki berikut:

• Folder pada tingkat pertama adalah sebagai berikut:
  • Folder Development environment dan Production environment berisi lingkungan aplikasi.
  • Folder Shared infrastructure berisi resource umum yang digunakan bersama di seluruh lingkungan, seperti pemantauan.
  • Folder Bootstrap berisi resource umum yang diperlukan untuk men-deploy infrastruktur Google Cloud Anda, seperti yang dijelaskan dalam blueprint foundation perusahaan.
• Pada tingkat kedua, terdapat folder berikut:
  • Folder di setiap lingkungan untuk setiap aplikasi (App 1 dan App 2) yang berisi resource untuk aplikasi ini.
  • Folder Shared untuk kedua lingkungan aplikasi yang berisi layanan yang digunakan bersama antar-aplikasi, tetapi bersifat independen untuk setiap lingkungan. Misalnya, Anda mungkin memiliki project secret level folder sehingga Anda dapat menerapkan kebijakan izin yang berbeda untuk secret produksi dan secret non-produksi.
• Dalam setiap folder aplikasi terdapat berbagai project yang berisi modul independen yang merupakan bagian dari setiap aplikasi.

Langkah selanjutnya

• Desain jaringan untuk zona landing Anda (dokumen berikutnya dalam rangkaian ini).
• Tinjau blueprint dasar-dasar perusahaan.
• Baca blueprint dan laporan resmi yang tersedia di pusat praktik terbaik keamanan Google Cloud.