Bagian ini memperkenalkan cara menggunakan Cloud Identity untuk mengelola identitas yang digunakan karyawan Anda guna mengakses layanan Google Cloud.
Penyedia identitas eksternal sebagai sumber tepercaya
Sebaiknya gabungkan akun Cloud Identity Anda dengan penyedia identitas yang sudah ada. Federasi membantu Anda memastikan bahwa proses pengelolaan akun yang ada berlaku untuk Google Cloud dan layanan Google lainnya.
Jika belum memiliki penyedia identitas, Anda dapat membuat akun pengguna langsung di Cloud Identity.
Diagram berikut menunjukkan tampilan umum federasi identitas dan single sign-on (SSO). Contoh ini menggunakan Microsoft Active Directory, yang berada di lingkungan lokal, sebagai contoh penyedia identitas.
Diagram ini menjelaskan praktik terbaik berikut:
- Identitas pengguna dikelola di domain Active Directory yang berada di lingkungan lokal dan digabungkan ke Cloud Identity. Active Directory menggunakan Google Cloud Directory Sync untuk menyediakan identitas ke Cloud Identity.
- Pengguna yang mencoba login ke layanan Google akan dialihkan ke penyedia identitas eksternal untuk single sign-on dengan SAML, menggunakan kredensial yang ada untuk melakukan autentikasi. Tidak ada sandi yang disinkronkan dengan Cloud Identity.
Tabel berikut memberikan link ke panduan penyiapan untuk penyedia identitas.
Penyedia identitas | Panduan |
---|---|
Active Directory | |
Microsoft Entra ID (sebelumnya Azure AD) | |
Penyedia identitas eksternal lainnya (misalnya, Ping atau Okta) |
Sebaiknya Anda menerapkan autentikasi multi-faktor di penyedia identitas dengan mekanisme yang tahan terhadap phishing seperti Kunci Keamanan Titan.
Setelan yang direkomendasikan untuk Cloud Identity tidak diotomatiskan melalui kode Terraform dalam blueprint ini. Lihat kontrol administratif untuk Cloud Identity untuk mengetahui setelan keamanan yang direkomendasikan yang harus Anda konfigurasi selain men-deploy kode Terraform.
Grup untuk kontrol akses
Akun utama adalah identitas yang dapat diberi akses ke resource. Akun utama mencakup Akun Google untuk pengguna, grup Google, akun Google Workspace, domain Cloud Identity, dan akun layanan. Beberapa layanan juga memungkinkan Anda memberikan akses ke semua pengguna yang melakukan autentikasi dengan Akun Google, atau ke semua pengguna di internet. Agar akun utama dapat berinteraksi dengan layanan Google Cloud, Anda harus memberikan peran di Identity and Access Management (IAM).
Untuk mengelola peran IAM dalam skala besar, sebaiknya tetapkan pengguna ke grup berdasarkan fungsi tugas dan persyaratan akses mereka, lalu berikan peran IAM ke grup tersebut. Anda harus menambahkan pengguna ke grup menggunakan proses di penyedia identitas yang ada untuk pembuatan dan keanggotaan grup.
Sebaiknya jangan berikan peran IAM kepada pengguna perorangan karena penetapan perorangan dapat meningkatkan kompleksitas pengelolaan dan pengauditan peran.
Blueprint mengonfigurasi grup dan peran untuk akses hanya lihat ke resource dasar. Sebaiknya deploy semua resource dalam blueprint melalui pipeline fondasi, dan jangan berikan peran kepada pengguna untuk grup guna mengubah resource fondasi di luar pipeline.
Tabel berikut menunjukkan grup yang dikonfigurasi oleh blueprint untuk melihat resource foundation.
Nama | Deskripsi | Peran | Cakupan |
---|---|---|---|
grp-gcp-org-admin@example.com |
Administrator dengan hak istimewa tinggi yang dapat memberikan peran IAM di tingkat organisasi. Mereka dapat mengakses peran lain. Hak istimewa ini tidak direkomendasikan untuk penggunaan sehari-hari. | Organization Administrator | organisasi |
grp-gcp-billing-admin@example.com |
Administrator dengan hak istimewa tinggi yang dapat mengubah akun Penagihan Cloud. Hak istimewa ini tidak direkomendasikan untuk penggunaan harian. | Billing Account Admin | organisasi |
grp-gcp-billing-viewer@example.com |
Tim yang bertanggung jawab untuk melihat dan menganalisis pengeluaran di semua project. | Billing Account Viewer | organisasi |
BigQuery User | project penagihan | ||
grp-gcp-audit-viewer@example.com |
Tim yang bertanggung jawab untuk mengaudit log terkait keamanan. | project logging | |
grp-gcp-security-reviewer@example.com |
Tim yang bertanggung jawab untuk meninjau keamanan cloud. | Security Reviewer | organisasi |
grp-gcp-network-viewer@example.com |
Tim yang bertanggung jawab untuk melihat dan mengelola konfigurasi jaringan. | Penampil Jaringan Compute | organisasi |
grp-gcp-scc-admin@example.com |
Tim yang bertanggung jawab untuk mengonfigurasi Security Command Center. | Security Center Admin Editor | organisasi |
grp-gcp-secrets-admin@example.com |
Tim yang bertanggung jawab mengelola, menyimpan, dan mengaudit kredensial dan secret lainnya yang digunakan oleh aplikasi. | Secret Manager Admin | project secret |
grp-gcp-kms-admin@example.com |
Tim yang bertanggung jawab untuk menerapkan pengelolaan kunci enkripsi guna memenuhi persyaratan kepatuhan. | Cloud KMS Viewer | project kms |
Saat mem-build workload Anda sendiri di atas fondasi, Anda akan membuat grup tambahan dan memberikan peran IAM yang didasarkan pada persyaratan akses untuk setiap workload.
Sebaiknya hindari peran dasar (seperti Pemilik, Editor, atau Pengakses lihat-saja) dan gunakan peran standar sebagai gantinya. Peran dasar terlalu permisif dan berpotensi menimbulkan risiko keamanan. Peran Pemilik dan Editor dapat menyebabkan eskalasi hak istimewa dan pergerakan lateral, dan peran Pelihat mencakup akses untuk membaca semua data. Untuk praktik terbaik tentang peran IAM, lihat Menggunakan IAM dengan aman.
Akun admin super
Pengguna Cloud Identity dengan akun admin super akan mengabaikan setelan SSO organisasi dan melakukan autentikasi langsung ke Cloud Identity. Pengecualian ini memang disengaja, sehingga admin super masih dapat mengakses konsol Cloud Identity jika terjadi kesalahan konfigurasi atau pemadaman SSO. Namun, hal ini berarti Anda harus mempertimbangkan perlindungan tambahan untuk akun admin super.
Untuk melindungi akun admin super, sebaiknya Anda selalu menerapkan verifikasi 2 langkah dengan kunci keamanan di Cloud Identity. Untuk informasi selengkapnya, lihat Praktik terbaik keamanan untuk akun administrator.
Masalah pada akun pengguna konsumen
Jika Anda tidak menggunakan Cloud Identity atau Google Workspace sebelum diaktivasi ke Google Cloud, karyawan organisasi Anda mungkin sudah menggunakan akun konsumen yang terkait dengan identitas email perusahaan mereka untuk mengakses layanan Google lainnya seperti Google Marketing Platform atau YouTube. Akun konsumen adalah akun yang sepenuhnya dimiliki dan dikelola oleh individu yang membuatnya. Karena akun tersebut tidak berada di bawah kendali organisasi Anda dan mungkin mencakup data pribadi dan perusahaan, Anda harus memutuskan cara menggabungkan akun ini dengan akun perusahaan lainnya.
Sebaiknya Anda menggabungkan akun pengguna konsumen yang ada sebagai bagian dari orientasi ke Google Cloud. Jika Anda belum menggunakan Google Workspace untuk semua akun pengguna, sebaiknya blokir pembuatan akun konsumen baru.
Kontrol administratif untuk Cloud Identity
Cloud Identity memiliki berbagai kontrol administratif yang tidak otomatis oleh kode Terraform dalam blueprint. Sebaiknya terapkan setiap kontrol keamanan praktik terbaik ini di awal proses pembuatan fondasi Anda.
Kontrol | Deskripsi |
---|---|
Men-deploy verifikasi 2 langkah | Akun pengguna mungkin disusupi melalui phishing, rekayasa sosial, penyemprotan sandi, atau berbagai ancaman lainnya. Verifikasi 2 langkah membantu mengurangi ancaman ini. Sebaiknya Anda menerapkan verifikasi 2 langkah untuk semua akun pengguna di organisasi dengan mekanisme yang tahan terhadap phishing, seperti Kunci Keamanan Titan atau kunci lain yang didasarkan pada standar FIDO U2F (CTAP1) yang tahan terhadap phishing. |
Menetapkan durasi sesi untuk layanan Google Cloud | Token OAuth persisten di workstation developer dapat menjadi risiko keamanan jika terekspos. Sebaiknya tetapkan kebijakan autentikasi ulang untuk mewajibkan autentikasi setiap 16 jam menggunakan kunci keamanan. |
Menetapkan durasi sesi untuk Layanan Google | (Khusus pelanggan Google Workspace)
Sesi web persisten di seluruh layanan Google lainnya dapat menjadi risiko keamanan jika diekspos. Sebaiknya terapkan durasi sesi web maksimum dan sesuaikan dengan kontrol durasi sesi di penyedia SSO Anda. |
Berbagi data dari Cloud Identity dengan layanan Google Cloud | Log audit Aktivitas Admin dari Google Workspace atau Cloud Identity biasanya dikelola dan dilihat di Konsol Admin, secara terpisah dari log Anda di lingkungan Google Cloud. Log ini berisi informasi yang relevan untuk lingkungan Google Cloud Anda, seperti peristiwa login pengguna. Sebaiknya bagikan log audit Cloud Identity ke lingkungan Google Cloud Anda untuk mengelola log dari semua sumber secara terpusat. |
Menyiapkan verifikasi pasca SSO | Blueprint mengasumsikan bahwa Anda menyiapkan SSO dengan penyedia identitas eksternal. Sebaiknya aktifkan lapisan kontrol tambahan berdasarkan analisis risiko login Google. Setelah Anda menerapkan setelan ini, pengguna mungkin melihat verifikasi login berbasis risiko tambahan saat login jika Google menilai bahwa login pengguna mencurigakan. |
Memperbaiki masalah pada akun pengguna konsumen | Pengguna dengan alamat email yang valid di domain Anda, tetapi tidak memiliki Akun Google, dapat mendaftar ke akun konsumen yang tidak dikelola. Akun ini mungkin berisi data perusahaan, tetapi tidak dikontrol oleh proses pengelolaan siklus proses akun Anda. Sebaiknya Anda mengambil langkah-langkah untuk memastikan bahwa semua akun pengguna adalah akun terkelola. |
Menonaktifkan pemulihan akun untuk akun admin super | Pemulihan mandiri akun admin super dinonaktifkan secara default untuk semua pelanggan baru (pelanggan lama mungkin mengaktifkan setelan ini). Menonaktifkan setelan ini membantu memitigasi risiko bahwa ponsel yang disusupi, email yang disusupi, atau serangan manipulasi psikologis dapat memungkinkan penyerang mendapatkan hak istimewa admin super atas lingkungan Anda. Rencanakan proses internal bagi admin super untuk menghubungi admin super lain di organisasi Anda jika mereka kehilangan akses ke akun mereka, dan pastikan semua admin super memahami proses untuk pemulihan dengan bantuan dukungan. |
Menerapkan dan memantau persyaratan sandi untuk pengguna | Pada umumnya, sandi pengguna dikelola melalui penyedia identitas eksternal Anda, tetapi akun admin super mengabaikan SSO dan harus menggunakan sandi untuk login ke Cloud Identity. Nonaktifkan penggunaan kembali sandi dan pantau kekuatan sandi untuk pengguna yang menggunakan sandi untuk login ke Cloud Identity, terutama akun admin super. |
Menetapkan kebijakan seluruh organisasi untuk menggunakan grup | Secara default, akun pengguna eksternal dapat ditambahkan ke grup di Cloud Identity. Sebaiknya konfigurasikan setelan berbagi agar pemilik grup tidak dapat menambahkan anggota eksternal. Perhatikan bahwa batasan ini tidak berlaku untuk akun admin super atau administrator lain yang didelegasikan dengan izin admin Grup. Karena federasi dari penyedia identitas Anda berjalan dengan hak istimewa administrator, setelan berbagi grup tidak berlaku untuk sinkronisasi grup ini. Sebaiknya tinjau kontrol di penyedia identitas dan mekanisme sinkronisasi untuk memastikan bahwa anggota non-domain tidak ditambahkan ke grup, atau Anda menerapkan pembatasan grup. |
Langkah selanjutnya
- Baca tentang struktur organisasi (dokumen berikutnya dalam seri ini).