Dokumen ini menyajikan praktik terbaik untuk menentukan jumlah akun Cloud Identity atau Google Workspace, organisasi Google Cloud, dan akun penagihan yang perlu Anda gunakan. Dokumen ini memberikan panduan tentang cara mengidentifikasi desain yang memenuhi persyaratan keamanan dan organisasi Anda.
Di Google Cloud, pengelolaan akses dan identitas didasarkan pada dua pilar:
Akun Cloud Identity dan Google Workspace adalah penampung untuk pengguna dan grup. Oleh karena itu, akun ini merupakan kunci untuk mengautentikasi pengguna perusahaan dan mengelola akses ke resource Google Cloud Anda. Akun Cloud Identity atau Google Workspace menunjukkan direktori pengguna, bukan akun pengguna perorangan. Setiap akun pengguna disebut sebagai pengguna atau akun pengguna.
Organisasi adalah penampung untuk project dan resource di dalam Google Cloud. Organisasi memungkinkan resource disusun secara hierarkis dan merupakan kunci untuk mengelola resource secara terpusat dan efisien.
Dokumen ini ditujukan terutama untuk pelanggan yang menyiapkan lingkungan perusahaan.
Akun Cloud Identity dan Google Workspace
Google Workspace adalah rangkaian aplikasi kolaborasi dan produktivitas berbasis cloud yang terintegrasi. Layanan ini mencakup alat yang memungkinkan Anda mengelola pengguna, grup, dan autentikasi.
Cloud Identity menyediakan subset fitur Google Workspace. Seperti Google Workspace, Cloud Identity memungkinkan Anda mengelola pengguna, grup, dan autentikasi, tetapi tidak mencakup semua fitur kolaborasi dan produktivitas Google Workspace.
Cloud Identity dan Google Workspace menggunakan platform teknis
yang sama dan menggunakan kumpulan API serta alat administratif yang sama. Produk tersebut
memiliki konsep akun sebagai penampung untuk pengguna dan grup. Penampung
ini diidentifikasi dengan nama domain seperti example.com. Untuk mengelola
pengguna, grup, dan autentikasi, kedua produk dapat dianggap
setara.
Gabungkan Cloud Identity dan Google Workspace dalam satu akun
Karena Cloud Identity dan Google Workspace menggunakan platform yang sama, Anda dapat menggabungkan akses ke semua produk dalam satu akun.
Jika Anda sudah mengelola akun Google Workspace dan ingin memungkinkan lebih banyak pengguna menggunakan Google Cloud, Anda mungkin tidak ingin menetapkan lisensi Google Workspace kepada semua pengguna. Dalam hal ini, tambahkan Cloud Identity Free ke akun Anda yang sudah ada. Kemudian, Anda dapat mengaktivasi lebih banyak pengguna tanpa biaya tambahan dan menentukan pengguna mana yang seharusnya memiliki akses ke Google Workspace dengan menetapkan lisensi Google Workspace kepada mereka.
Demikian pula, jika Anda sudah mengelola akun Cloud Identity Free atau Premium, Anda dapat memberikan hak kepada pengguna tertentu untuk menggunakan Google Workspace. Daripada membuat akun Google Workspace terpisah untuk pengguna tersebut, Anda dapat menambahkan Google Workspace ke akun Cloud Identity yang ada. Setelah Anda menetapkan lisensi Google Workspace kepada pengguna yang dipilih tersebut, mereka dapat menggunakan aplikasi produktivitas dan kolaborasi.
Gunakan akun sesedikit mungkin, tetapi sebanyak yang diperlukan
Agar pengguna dapat berkolaborasi menggunakan Google Workspace, dan untuk meminimalkan overhead administratif, sebaiknya kelola semua pengguna melalui satu akun Cloud Identity atau Google Workspace dan berikan satu akun pengguna untuk setiap individu. Pendekatan ini membantu memastikan setelan seperti kebijakan sandi, single sign-on, dan verifikasi dua langkah diterapkan secara konsisten pada semua pengguna.
Terlepas dari manfaat penggunaan satu akun Cloud Identity atau Google Workspace, Anda dapat memperoleh fleksibilitas dan otonomi administratif dengan menggunakan beberapa akun. Saat Anda memutuskan jumlah akun Cloud Identity atau Google Workspace yang akan digunakan, pertimbangkan semua persyaratan yang menyarankan penggunaan beberapa akun. Kemudian, gunakan jumlah terkecil akun Cloud Identity atau Google Workspace yang memenuhi persyaratan Anda.
Gunakan akun terpisah untuk staging dan produksi
Untuk sebagian besar setelan yang dapat dikonfigurasi di Cloud Identity dan Google Workspace, Anda dapat memilih cakupan tempat setiap setelan harus diterapkan—misalnya, Anda dapat menentukan lokasi geografis untuk data Anda menurut pengguna, grup, atau unit organisasi. Saat berencana menerapkan konfigurasi baru, awalnya Anda dapat memilih cakupan kecil (misalnya, berdasarkan pengguna) dan memverifikasi apakah konfigurasi memenuhi harapan Anda. Setelah memverifikasi konfigurasi, Anda dapat menerapkan setelan yang sama ke kumpulan grup atau unit organisasi yang lebih besar.
Tidak seperti sebagian besar setelan, integrasi akun Cloud Identity atau Google Workspace dengan penyedia identitas (IdP) eksternal memiliki dampak global:
- Mengaktifkan single sign-on adalah setelan global yang berlaku untuk semua pengguna selain admin super.
- Bergantung pada IdP eksternal Anda, menyiapkan penyediaan pengguna juga dapat berdampak global. Kesalahan konfigurasi yang tidak disengaja di IdP eksternal dapat menyebabkan pengguna secara tidak sengaja diubah, ditangguhkan, atau bahkan dihapus.
Untuk mengurangi risiko ini, buat akun Cloud Identity atau Google Workspace staging dan produksi terpisah:
- Gunakan akun staging untuk memverifikasi perubahan konfigurasi yang berisiko sebelum menerapkan perubahan yang sama ke akun produksi Anda.
- Buat beberapa pengguna uji coba di akun staging yang dapat Anda dan administrator lain gunakan untuk memverifikasi perubahan konfigurasi. Namun, jangan beri pengguna Anda akses ke akun staging,
Jika Anda memiliki instance staging dan produksi terpisah dari IdP eksternal, lakukan langkah-langkah berikut:
- Integrasikan akun Cloud Identity atau Google Workspace staging dengan instance IdP staging.
- Integrasikan akun Cloud Identity produksi atau Google Workspace Anda dengan instance IdP produksi.
Misalnya, Anda berencana untuk menyiapkan penggabungan dengan Active Directory dan memiliki hutan Active Directory terpisah untuk tujuan pengujian. Dalam hal ini, Anda mengintegrasikan akun Cloud Identity atau Google Workspace staging dengan Forest staging dan produksi Cloud Identity atau Google Workspace dengan hutan utama Anda. Terapkan pendekatan pemetaan yang sama untuk domain DNS, pengguna, dan grup pada pasangan forest/akun, seperti yang ditunjukkan dalam diagram berikut:
Forest dan domain Active Directory produksi dan staging Anda mungkin menggunakan domain DNS yang tidak memungkinkan Anda menerapkan pendekatan pemetaan domain yang sama untuk staging dan produksi. Dalam hal ini, pertimbangkan untuk mendaftarkan lebih banyak domain akhiran Nama Utama Pengguna (UPN) di hutan staging Anda.
Demikian pula, jika Anda berencana untuk menyiapkan penggabungan dengan Azure Active Directory, sebaiknya lakukan pendekatan berikut:
- Integrasikan akun Cloud Identity staging atau Google Workspace dengan tenant Azure Active Directory staging.
- Integrasikan akun Cloud Identity produksi atau Google Workspace dengan tenant Azure Active Directory utama Anda.
Terapkan pendekatan pemetaan yang sama untuk domain DNS, pengguna, dan grup untuk pasangan tenant/akun:
Tenant Azure Active Directory produksi dan staging Anda mungkin menggunakan domain DNS yang tidak memungkinkan Anda menerapkan pendekatan pemetaan domain yang sama untuk staging dan produksi. Dalam hal ini, pertimbangkan untuk menambahkan domain tambahan ke tenant staging Anda.
Gunakan domain DNS yang terpisah-pisah di antara akun Cloud Identity dan Google Workspace
Saat pertama kali menambahkan domain seperti example.com ke
akun Cloud Identity atau Google Workspace, Anda harus
memverifikasi bahwa Anda adalah pemilik domain.
Setelah menambahkan dan memverifikasi domain, Anda dapat menambahkan subdomain seperti
marketing.example.com dan finance.example.com tanpa harus memverifikasi setiap
subdomain satu per satu.
Namun, jika Anda menambahkan subdomain tanpa memverifikasi setiap subdomain, konflik dapat terjadi jika Anda memiliki akun Cloud Identity atau Google Workspace lain yang sudah menggunakan subdomain ini. Untuk menghindari konflik ini, sebaiknya gunakan domain yang terpisah untuk setiap akun. Misalnya, jika Anda memerlukan dua akun Cloud Identity atau Google Workspace, coba hindari penggunaan dua domain yang satu domain merupakan subdomain dari domain lainnya. Sebaliknya, gunakan dua domain yang bukan subdomain dari yang lain. Praktik ini berlaku untuk domain primer dan domain sekunder.
Jangan pisahkan Google Workspace dan Google Cloud
Jika Anda sudah menggunakan Google Workspace, beberapa pengguna di akun Google Workspace Anda mungkin telah diberi hak istimewa admin super sehingga mereka dapat melakukan tugas administratif.
Pengguna dengan hak istimewa admin super diberi izin secara implisit untuk mengubah kebijakan Identity and Access Management (IAM) node organisasi. Izin ini memungkinkan admin super menetapkan peran administrator organisasi atau peran lain apa pun dalam organisasi Google Cloud kepada diri mereka sendiri. Memiliki akses admin super ke akun Cloud Identity atau Google Workspace juga memungkinkan pengguna untuk menghapus akun tersebut, organisasi Google Cloud terkaitnya, dan semua resource-nya. Oleh karena itu Anda harus berasumsi bahwa admin super memiliki akses penuh ke semua resource dalam organisasi.
Fakta bahwa admin super juga merupakan administrator organisasi mungkin menjadi masalah keamanan jika administrator Google Workspace yang ada adalah kumpulan pengguna yang berbeda dari pengguna yang akan bertanggung jawab mengelola organisasi Google Cloud Anda. Dalam hal ini, Anda mungkin memutuskan untuk membuat akun Cloud Identity terpisah yang dikhususkan untuk Google Cloud guna membatasi akses admin super Google Workspace ke resource Google Cloud. Memisahkan Google Workspace dan Google Cloud dapat menyebabkan beberapa konsekuensi yang tidak diinginkan.
Misalnya, Anda dapat mencoba membuat pengguna terpisah di akun Cloud Identity, lalu membatasi akses ke akun Cloud Identity bagi pengguna organisasi Google Cloud. Hal ini akan memastikan bahwa deployment Google Cloud dan Google Workspace Anda sepenuhnya terisolasi. Namun, menduplikasi pengguna akan berdampak negatif pada pengalaman pengguna dan overhead administratif. Selain itu, Anda tidak akan dapat menerima email notifikasi yang dikirim oleh Google Cloud karena domain yang digunakan oleh Cloud Identity harus berbeda dari domain yang digunakan untuk Google Workspace, sehingga tidak cocok untuk pemilihan rute email.
Jika Anda merujuk pengguna dari akun Google Workspace di organisasi Google Cloud, Anda merusak isolasi antara Google Workspace dan Google Cloud:
Admin super Google Workspace dapat menggunakan delegasi seluruh domain untuk meniru identitas pengguna mana pun di akun Google Workspace yang sama. Admin super yang jahat dapat menggunakan hak istimewanya yang ditingkatkan untuk mendapatkan kembali akses ke Google Cloud.
Pendekatan yang lebih efektif daripada menggunakan akun terpisah adalah memisahkan tanggung jawab antara administrator Google Workspace dan Google Cloud untuk mengurangi jumlah admin super:
Sebagian besar tugas administratif di Google Workspace tidak memerlukan hak istimewa admin super. Gunakan peran administratif standar atau peran administrator khusus sebagai ganti hak istimewa admin super untuk memberikan kepada administrator Google Workspace izin akses yang diperlukan untuk melakukan tugasnya.
Pertahankan hanya sedikit pengguna admin super dan jangan lakukan penggunaan sehari-hari.
Manfaatkan audit untuk mendeteksi aktivitas yang mencurigakan di antara pengguna administratif.
Mengamankan IdP eksternal Anda saat menggunakan single sign-on
Dengan Cloud Identity dan Google Workspace, Anda dapat menyiapkan single sign-on dengan IdP eksternal, seperti Active Directory, Azure Active Directory, atau Okta (beberapa contohnya) singkat ini. Jika single sign-on diaktifkan, Cloud Identity dan Google Workspace akan memercayai IdP eksternal untuk mengautentikasi pengguna atas nama Google.
Mengaktifkan Single Sign-On memberikan beberapa keuntungan:
- Pengguna dapat menggunakan kredensial yang sudah ada untuk login ke layanan Google.
- Pengguna tidak perlu memasukkan sandi lagi jika sudah memiliki sesi login.
- Anda dapat menerapkan kebijakan autentikasi multi-faktor yang konsisten di seluruh aplikasi dan semua layanan Google.
Namun, mengaktifkan Single Sign-On juga menimbulkan risiko. Jika Single Sign-On diaktifkan dan pengguna perlu diautentikasi, Cloud Identity atau Google Workspace akan mengalihkan pengguna ke IdP eksternal Anda. Setelah mengautentikasi pengguna, IdP akan menampilkan pernyataan SAML yang menyatakan identitas pengguna kepada Google. Pernyataan SAML ditandatangani. Oleh karena itu, Google dapat memverifikasi keaslian pernyataan SAML dan memverifikasi bahwa penyedia identitas yang benar telah digunakan. Namun, Cloud Identity atau Google Workspace tidak dapat memverifikasi bahwa IdP membuat keputusan autentikasi yang tepat dan menyatakan identitas pengguna dengan benar.
Jika Single Sign-On diaktifkan, keamanan dan integritas deployment Google secara keseluruhan akan bergantung pada keamanan dan integritas IdP Anda. Akun Cloud Identity atau Google Workspace Anda dan semua resource yang mengandalkan pengguna yang dikelola oleh akun tersebut berisiko jika salah satu dari hal berikut dikonfigurasi secara tidak aman:
- IdP itu sendiri
- Komputer yang dijalankan oleh penyedia
- Database pengguna tempat penyedia mendapatkan informasi pengguna
- Sistem lain yang diandalkan penyedia
Agar Single Sign-On tidak menjadi link lemah dalam postur keamanan Anda, pastikan IdP dan semua sistem yang menjadi dependensinya telah dikonfigurasi dengan aman:
- Batasi jumlah pengguna yang memiliki akses administratif ke IdP Anda atau ke sistem apa pun yang diandalkan penyedia.
- Jangan beri pengguna akses administratif ke sistem ini kepada pengguna yang juga tidak akan Anda beri hak istimewa admin super di Cloud Identity atau Google Workspace.
- Jangan gunakan Single Sign-On jika Anda tidak yakin dengan kontrol keamanan yang diterapkan untuk IdP eksternal.
Akses aman untuk zona DNS Anda
Akun Cloud Identity dan Google Workspace diidentifikasi oleh nama domain DNS primer. Saat membuat akun Cloud Identity atau Google Workspace baru, Anda harus memverifikasi kepemilikan domain DNS dengan membuat data DNS khusus di zona DNS yang sesuai.
Pentingnya DNS dan dampaknya terhadap keamanan deployment Google secara keseluruhan melampaui proses pendaftaran:
Google Workspace mengandalkan data MX DNS untuk merutekan email. Dengan memodifikasi data MX ini, penyerang mungkin dapat mengarahkan email ke server lain dan mendapatkan akses ke informasi sensitif.
Jika penyerang dapat menambahkan kumpulan data ke zona DNS, penyerang mungkin dapat mereset sandi pengguna admin super dan mendapatkan akses ke akun tersebut.
Agar DNS tidak menjadi link lemah dalam postur keamanan Anda, pastikan server DNS Anda telah dikonfigurasi dengan aman:
Batasi jumlah pengguna yang memiliki akses administratif ke server DNS yang mengelola domain primer yang digunakan untuk Cloud Identity atau Google Workspace.
Jangan beri pengguna akses administratif ke server DNS Anda kepada siapa pun yang tidak akan Anda beri hak istimewa admin super di Cloud Identity atau Google Workspace.
Jika Anda berencana men-deploy beban kerja di Google Cloud yang memiliki persyaratan keamanan yang tidak terpenuhi oleh infrastruktur DNS yang ada, pertimbangkan untuk mendaftarkan domain DNS baru yang menggunakan server DNS terpisah atau domain DNS terkelola untuk beban kerja tersebut layanan DNS.
Ekspor log audit ke BigQuery
Cloud Identity dan Google Workspace mengelola beberapa log audit untuk melacak perubahan konfigurasi dan aktivitas lain yang mungkin relevan dengan keamanan akun Cloud Identity atau Google Workspace Anda. Tabel berikut merangkum log audit ini.
| Log | Aktivitas terekam |
|---|---|
| Admin | Tindakan yang dilakukan di Konsol Google Admin |
| Login | Upaya login yang berhasil, gagal, dan mencurigakan ke domain Anda |
| Token | Contoh pemberian otorisasi atau pencabutan akses ke aplikasi web atau seluler pihak ketiga |
| Grup | Perubahan pada grup dan keanggotaan grup |
Anda dapat mengakses log audit ini melalui Konsol Admin atau melalui Reports API. Untuk sebagian besar log audit, data dipertahankan selama 6 bulan.
Jika Anda beroperasi di industri yang teregulasi, menyimpan data audit selama 6 bulan mungkin tidak cukup. Untuk menyimpan data dalam jangka waktu yang lebih lama, konfigurasikan log audit untuk diekspor ke BigQuery.
Untuk membatasi risiko akses tidak sah ke log audit yang diekspor, gunakan project Google Cloud khusus untuk set data BigQuery. Agar data audit tetap aman dari modifikasi atau penghapusan, berikan akses ke project dan set data dengan hak istimewa terendah.
Log audit Cloud Identity dan Google Workspace merupakan pelengkap untuk log Cloud Audit Logs. Jika Anda juga menggunakan BigQuery untuk mengumpulkan log Cloud Audit Logs dan log audit khusus aplikasi lainnya, Anda dapat menghubungkan peristiwa login dengan aktivitas yang telah dilakukan pengguna di Google Cloud atau dalam aplikasi Anda. Kemampuan menghubungkan data audit di berbagai sumber dapat membantu Anda mendeteksi dan menganalisis aktivitas yang mencurigakan.
Penyiapan ekspor BigQuery memerlukan lisensi Google Workspace Enterprise. Setelah Anda menyiapkan log audit utama, log tersebut akan diekspor untuk semua pengguna, termasuk pengguna yang tidak memiliki lisensi Google Workspace. Log tertentu seperti log audit Drive dan Seluler diekspor untuk pengguna yang memiliki setidaknya lisensi Google Workspace Business.
Jika sebagian besar pengguna Anda menggunakan Cloud Identity Free, Anda masih dapat mengekspor ke BigQuery dengan menambahkan Google Workspace Enterprise ke akun Cloud Identity yang sudah ada dan membeli Google Workspace lisensi untuk sekumpulan administrator yang dipilih.
Organisasi
Organisasi memungkinkan Anda mengatur resource ke dalam hierarki project dan folder, dengan node organisasi sebagai root. Organisasi dikaitkan dengan akun Cloud Identity atau Google Workspace, dan namanya diambil dari nama domain primer akun terkait. Organisasi dibuat secara otomatis saat pengguna dari akun Cloud Identity atau Google Workspace membuat project pertama.
Setiap akun Cloud Identity atau Google Workspace hanya dapat memiliki satu organisasi. Faktanya, tidak mungkin membuat organisasi tanpa akun yang sesuai. Terlepas dari dependensi ini, Anda dapat memberi pengguna dari beberapa akun yang berbeda akses ke resource dalam satu organisasi:
Fleksibilitas untuk mereferensikan pengguna dari akun Cloud Identity atau Google Workspace yang berbeda memungkinkan Anda memisahkan cara Anda memperlakukan akun dan organisasi. Anda dapat memisahkan keputusan jumlah akun Cloud Identity atau Google Workspace yang diperlukan untuk mengelola pengguna dari keputusan jumlah organisasi yang diperlukan untuk mengelola resource.
Jumlah organisasi yang Anda buat dan tujuannya dapat sangat memengaruhi postur keamanan, otonomi tim dan departemen Anda, serta konsistensi dan efisiensi administrasi Anda.
Bagian berikut menjelaskan praktik terbaik untuk menentukan jumlah organisasi yang akan digunakan.
Gunakan organisasi sesedikit mungkin, tetapi sebanyak yang diperlukan
Dengan hierarki resource organisasi, Anda dapat mengurangi upaya pengelolaan kebijakan IAM dan kebijakan organisasi dengan memanfaatkan pewarisan. Dengan mengonfigurasi kebijakan di level folder atau organisasi, Anda memastikan bahwa kebijakan diterapkan secara konsisten di seluruh sub-hierarki resource, dan Anda akan menghindari pekerjaan konfigurasi yang berulang. Untuk meminimalkan overhead administratif, sebaiknya gunakan organisasi sesedikit mungkin.
Sebaliknya, Anda bisa mendapatkan fleksibilitas dan otonomi administratif tambahan dengan menggunakan beberapa organisasi. Bagian berikut menjelaskan kapan Anda mungkin memerlukan fleksibilitas atau otonomi tambahan tersebut.
Bagaimanapun, saat Anda menentukan jumlah organisasi yang akan digunakan, pertimbangkan semua persyaratan yang menyarankan penggunaan beberapa organisasi. Kemudian gunakan jumlah organisasi terkecil yang memenuhi persyaratan Anda.
Gunakan organisasi untuk menandai otoritas administratif
Dalam hierarki resource, Anda dapat memberikan izin di tingkat resource, project, atau folder. Tingkat akhir yang dapat Anda gunakan untuk memberikan izin pengguna adalah organisasi.
Pengguna yang telah diberi peran Organization Administrator di tingkat organisasi memiliki kontrol penuh atas organisasi, resource-nya, dan kebijakan IAM-nya. Administrator Organisasi dapat mengontrol resource apa pun dalam organisasi dan bebas mendelegasikan akses administratif kepada pengguna lain.
Namun, kemampuan Administrator Organisasi terbatas pada organisasi, sehingga organisasi menjadi cakupan utama otoritas administratif:
- Administrator Organisasi tidak dapat mengakses resource apa pun di organisasi lain kecuali diberi izin secara eksplisit.
- Tidak ada pengguna di luar organisasi yang dapat mengambil alih kendali dari Administrator Organisasi organisasi tersebut.
Jumlah organisasi yang tepat untuk digunakan bergantung pada jumlah grup pengguna administratif independen di perusahaan Anda:
- Jika perusahaan Anda diatur berdasarkan fungsi, Anda mungkin memiliki satu departemen yang bertugas mengawasi semua deployment Google Cloud.
- Jika perusahaan Anda diatur berdasarkan divisi atau memiliki sejumlah anak perusahaan yang dikelola secara otonom, mungkin tidak ada satu departemen yang bertanggung jawab.
Jika ada satu departemen yang bertugas mengawasi deployment Google Cloud, sebaiknya gunakan satu node organisasi Google Cloud. Dalam organisasi, gunakan folder untuk membuat struktur resource dan memberikan tingkat akses yang berbeda ke tim dan departemen lain.
Jika Anda menangani beberapa departemen independen, mencoba memusatkan administrasi dengan menggunakan satu organisasi dapat menyebabkan hambatan:
- Jika Anda menunjuk satu departemen untuk mengelola organisasi, Anda mungkin akan menghadapi penolakan dari departemen lain.
- Jika Anda mengizinkan beberapa tim atau departemen untuk menjadi pemilik satu organisasi bersama-sama, mungkin akan sulit untuk mempertahankan hierarki resource yang konsisten serta memastikan bahwa kebijakan IAM dan kebijakan organisasi digunakan secara konsisten di seluruh resource Anda.
Untuk mencegah hambatan semacam ini, gunakan beberapa organisasi dan buat struktur folder terpisah di setiap organisasi. Dengan menggunakan organisasi yang terpisah, Anda menetapkan batas antara berbagai kelompok pengguna administratif, sehingga membatasi otoritas administratif mereka.
Gunakan organisasi staging terpisah
Untuk membantu memastikan konsistensi dan menghindari pekerjaan konfigurasi berulang, atur project Anda ke dalam hierarki folder dan terapkan kebijakan IAM serta kebijakan organisasi di level folder atau organisasi.
Memiliki kebijakan yang berlaku untuk banyak project dan resource memiliki kelemahan. Setiap perubahan pada kebijakan itu sendiri atau hierarki resource tempat kebijakan berlaku mungkin memiliki konsekuensi yang luas dan tidak diinginkan. Untuk mengurangi risiko ini, sebaiknya uji perubahan kebijakan sebelum Anda menerapkannya di organisasi utama Anda.
Sebaiknya buat organisasi staging terpisah. Organisasi ini membantu Anda menguji perubahan hierarki resource, kebijakan IAM, kebijakan organisasi, atau konfigurasi lain yang memiliki potensi dampak di seluruh organisasi seperti tingkat akses dan policies.
Untuk memastikan bahwa hasil pengujian atau eksperimen yang dilakukan di organisasi staging juga berlaku untuk organisasi produksi, konfigurasikan organisasi staging agar menggunakan struktur folder yang sama dengan organisasi utama, tetapi hanya dengan sejumlah kecil jumlah proyek. Kapan pun, IAM dan kebijakan organisasi dalam organisasi staging harus sesuai dengan kebijakan organisasi produksi atau harus mencerminkan versi kebijakan berikutnya yang ingin Anda terapkan ke organisasi produksi.
Seperti yang ditunjukkan pada diagram berikut, Anda menggunakan akun Cloud Identity atau Google Workspace staging sebagai dasar untuk organisasi staging. Gunakan akun staging (atau IdP eksternal yang terintegrasi dengan akun staging) untuk membuat pengguna pengujian khusus dan struktur grup yang mencerminkan grup yang Anda gunakan di Cloud Identity produksi atau Google Workspace. Kemudian, Anda dapat menggunakan pengguna dan grup pengujian khusus ini untuk menguji kebijakan IAM tanpa memengaruhi pengguna yang sudah ada.
Hindari penggunaan organisasi pengujian terpisah
Untuk setiap beban kerja produksi yang ingin di-deploy di Google Cloud, Anda mungkin memerlukan satu atau beberapa lingkungan pengujian, yang dapat digunakan oleh tim pengembangan dan DevOps untuk memvalidasi rilis baru.
Dari perspektif keamanan, agar rilis yang belum diuji tidak memengaruhi beban kerja produksi secara tidak sengaja, Anda perlu memisahkan lingkungan pengujian dari lingkungan produksi. Demikian pula, kedua jenis lingkungan memiliki persyaratan yang berbeda untuk kebijakan IAM. Misalnya, agar Anda dapat memberi developer dan penguji fleksibilitas yang mereka butuhkan, persyaratan keamanan untuk lingkungan pengujian Anda mungkin jauh lebih longgar dibandingkan dengan lingkungan produksi Anda.
Seperti yang ditunjukkan diagram berikut, dari perspektif konfigurasi, Anda ingin mempertahankan lingkungan pengujian semirip mungkin dengan lingkungan produksi. Perbedaan apa pun meningkatkan risiko kegagalan deployment yang berfungsi dengan baik di lingkungan pengujian saat di-deploy ke produksi.
Untuk mencapai keseimbangan antara menjaga lingkungan tetap terisolasi dan konsisten, gunakan folder dalam organisasi yang sama untuk mengelola lingkungan pengujian dan produksi:
- Terapkan kebijakan IAM atau kebijakan organisasi yang umum di seluruh lingkungan pada tingkat organisasi (atau dengan menggunakan folder induk umum).
- Gunakan folder masing-masing untuk mengelola kebijakan IAM dan kebijakan organisasi yang berbeda di antara berbagai jenis lingkungan.
Jangan gunakan organisasi staging Anda untuk mengelola lingkungan pengujian. Lingkungan pengujian sangat penting bagi produktivitas tim pengembangan dan DevOps. Mengelola lingkungan tersebut di lingkungan staging akan membatasi kemampuan Anda dalam menggunakan organisasi staging untuk bereksperimen dan menguji perubahan kebijakan; setiap perubahan tersebut dapat mengganggu pekerjaan tim ini. Singkatnya, jika Anda menggunakan organisasi staging untuk mengelola lingkungan pengujian, Anda merusak tujuan organisasi staging.
Gunakan organisasi terpisah untuk bereksperimen
Untuk mendapatkan hasil maksimal dari Google Cloud, biarkan tim pengembangan, DevOps, dan operasi Anda memahami platform ini dan memperluas pengalaman mereka dengan menjalankan tutorial. Dorong mereka untuk bereksperimen dengan fitur dan layanan baru.
Gunakan organisasi terpisah sebagai lingkungan sandbox untuk mendukung jenis aktivitas eksperimental ini. Dengan menggunakan organisasi terpisah, Anda dapat menjaga eksperimen tanpa terhalang oleh kebijakan, konfigurasi, atau otomatisasi yang Anda gunakan di organisasi produksi.
Hindari penggunaan organisasi staging Anda untuk bereksperimen. Lingkungan staging Anda harus menggunakan IAM dan kebijakan organisasi yang serupa dengan organisasi produksi Anda. Oleh karena itu, lingkungan staging mungkin memiliki batasan yang sama dengan lingkungan produksi Anda. Pada saat yang sama, menyesuaikan kebijakan untuk memungkinkan eksperimen akan merusak tujuan organisasi staging Anda.
Untuk mencegah organisasi eksperimental Anda menjadi tidak teratur, dari menghasilkan biaya yang berlebihan, atau dari risiko keamanan, terbitkan pedoman yang menentukan cara tim diizinkan untuk menggunakan organisasi, dan siapa yang memikul tanggung jawab untuk memelihara organisasi/pengaturan. Selain itu, pertimbangkan untuk menyiapkan otomatisasi agar otomatis menghapus resource, atau bahkan seluruh project, setelah beberapa hari tertentu.
Seperti yang ditunjukkan diagram berikut, saat membuat organisasi untuk bereksperimen, Anda harus membuat akun Cloud Identity khusus terlebih dahulu. Kemudian, gunakan pengguna yang ada dari akun Cloud Identity atau Google Workspace utama Anda untuk memberi pengguna akses ke organisasi eksperimental.
Untuk mengelola akun Cloud Identity tambahan, Anda memerlukan setidaknya satu akun pengguna admin super di akun Cloud Identity. Untuk mengetahui informasi tentang cara mengamankan akun pengguna admin super ini, lihat Praktik terbaik akun administrator super.
Gunakan fitur berbagi yang dibatasi domain untuk menerapkan hubungan kepercayaan
Dengan kebijakan IAM, Anda dapat menambahkan identitas Google yang valid sebagai anggota. Artinya, saat mengedit kebijakan IAM resource, project, folder, atau organisasi, Anda dapat menambahkan anggota dari sumber yang berbeda, termasuk yang berikut:
- Pengguna dari akun Cloud Identity atau Google Workspace yang terkait dengan organisasi, serta akun layanan dari organisasi yang sama
- Pengguna dari akun Cloud Identity atau Google Workspace lain
- Akun layanan dari organisasi lain
- Akun pengguna konsumen, termasuk pengguna
gmail.comdan akun konsumen yang menggunakan alamat email perusahaan
Kemampuan merujuk pengguna dari berbagai sumber berguna untuk skenario dan project yang mengharuskan Anda berkolaborasi dengan afiliasi atau perusahaan lain. Dalam sebagian besar kasus lainnya, sebaiknya batasi kebijakan IAM untuk hanya mengizinkan anggota dari sumber tepercaya.
Gunakan berbagi yang dibatasi domain untuk menentukan kumpulan akun Cloud Identity atau Google Workspace tepercaya yang ingin Anda izinkan untuk menambahkan anggota ke kebijakan IAM. Tentukan kebijakan organisasi ini di level organisasi (sehingga berlaku untuk semua project) atau di folder di dekat bagian atas hierarki resource (untuk mengizinkan project tertentu dikecualikan).
Jika Anda menggunakan akun dan organisasi Cloud Identity atau Google Workspace yang terpisah untuk memisahkan lingkungan staging, produksi, dan eksperimen, gunakan kebijakan berbagi yang dibatasi domain untuk menerapkan pemisahan seperti yang tercantum dalam tabel berikut:
| Organisasi | Akun Google Workspace atau Cloud Identity tepercaya |
|---|---|
| Staging | Staging |
| Produksi | Produksi |
| Experiments | Produksi |
Gunakan nama domain netral untuk organisasi
Organisasi diidentifikasi dengan nama domain DNS seperti example.com. Nama
domain diambil dari nama domain primer akun
Cloud Identity atau Google Workspace terkait.
Jika ada nama domain DNS kanonis yang digunakan di seluruh perusahaan Anda, gunakan domain tersebut sebagai domain primer di akun Cloud Identity atau Google Workspace produksi Anda. Dengan menggunakan nama DNS kanonis, Anda memastikan bahwa karyawan dapat dengan mudah mengenali nama node organisasi.
Jika perusahaan Anda memiliki beberapa anak perusahaan atau memiliki berbagai merek yang berbeda, mungkin tidak ada nama domain kanonis. Daripada memilih salah satu domain yang ada secara acak, pertimbangkan untuk mendaftarkan domain DNS baru yang netral dan dikhususkan untuk digunakan oleh Google Cloud. Dengan menggunakan nama DNS netral, Anda menghindari mengekspresikan preferensi untuk merek, anak perusahaan, atau departemen tertentu dalam perusahaan Anda karena dapat berdampak negatif pada adopsi cloud. Tambahkan domain lain khusus merek sebagai domain sekunder sehingga dapat digunakan di ID pengguna dan untuk Single Sign-On.
Gunakan akun penagihan pada seluruh organisasi Google Cloud
Akun penagihan menentukan siapa yang membayar sekumpulan resource Google Cloud tertentu. Meskipun dapat berada di luar organisasi Google Cloud, akun penagihan paling sering terkait dengan organisasi.
Saat akun penagihan dikaitkan dengan organisasi, akun tersebut dianggap sebagai sub-resource organisasi dan tunduk pada kebijakan IAM yang ditetapkan dalam organisasi. Yang terpenting, ini berarti Anda dapat menggunakan peran IAM Penagihan untuk menentukan pengguna atau grup mana yang diizinkan untuk mengelola atau menggunakan akun.
Pengguna yang telah diberi peran Billing Account User dapat menautkan project
ke akun penagihan, yang menyebabkan resource ditagih ke akun ini.
Menautkan project ke akun penagihan dapat dilakukan dalam organisasi yang sama, tetapi
juga di seluruh organisasi.
Jika menggunakan beberapa organisasi, Anda dapat memanfaatkan fakta bahwa akun penagihan dapat digunakan di seluruh organisasi. Hal ini memungkinkan Anda memutuskan jumlah akun penagihan yang diperlukan, terlepas dari berapa banyak organisasi yang dibutuhkan.
Jumlah akun penagihan yang tepat bergantung secara eksklusif pada persyaratan komersial atau kontraktual Anda, seperti mata uang, profil pembayaran, dan jumlah invoice terpisah yang Anda butuhkan. Seperti yang Anda lakukan pada akun dan organisasi, untuk meminimalkan kompleksitas, Anda ingin menggunakan jumlah akun penagihan terkecil yang memenuhi persyaratan Anda.
Untuk mengelompokkan biaya yang terakumulasi di beberapa organisasi, konfigurasikan
akun penagihan Anda untuk
mengekspor data penagihan ke BigQuery.
Setiap data yang diekspor ke BigQuery tidak hanya berisi nama dan
ID project, tetapi juga ID organisasi yang terkait dengan project tersebut
(di kolom project.ancestry_numbers).
Langkah selanjutnya
- Membuat akun Cloud Identity baru
- Pelajari cara Google Cloud memungkinkan Anda mengautentikasi pengguna perusahaan di lingkungan hybrid dan pola umum.
- Tinjau praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.
- Cari tahu cara menggabungkan Google Cloud dengan Active Directory atau Azure Active Directory.
- Tinjau praktik terbaik untuk mengelola identitas dan akses.