Bagian ini memperkenalkan cara menggunakan Cloud Identity untuk mengelola identitas yang digunakan karyawan Anda untuk mengakses layanan Google Cloud.
Penyedia identitas eksternal sebagai sumber kebenaran
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 Anda tidak memiliki penyedia identitas, Anda dapat membuat akun pengguna langsung di Cloud Identity.
Diagram berikut menunjukkan tampilan umum federasi identitas dan single sign-on (SSO). Panduan 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 Anda dengan mekanisme yang tahan terhadap phishing seperti Kunci Keamanan Titan.
Setelan yang direkomendasikan untuk Cloud Identity tidak diotomatiskan melalui kode Terraform dalam cetak biru 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. Principal mencakup Akun Google untuk pengguna, grup Google, akun Google Workspace, domain Cloud Identity, dan akun layanan. Beberapa layanan juga memungkinkan Anda memberikan akses kepada semua pengguna yang diautentikasi dengan Akun Google, atau kepada semua pengguna di internet. Agar akun utama dapat berinteraksi dengan layanan Google Cloud , Anda harus memberikan peran kepada akun utama tersebut di Identity and Access Management (IAM).
Untuk mengelola peran IAM dalam skala besar, sebaiknya tetapkan pengguna ke grup berdasarkan fungsi pekerjaan dan persyaratan akses mereka, lalu berikan peran IAM kepada 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 masing-masing pengguna karena penetapan perorangan dapat meningkatkan kompleksitas pengelolaan dan pengauditan peran.
Blueprint mengonfigurasi grup dan peran untuk akses hanya lihat ke resource dasar. Sebaiknya Anda men-deploy semua resource dalam blueprint melalui pipeline fondasi, dan tidak memberikan peran kepada pengguna untuk mengubah resource fondasi di luar pipeline.
Tabel berikut menunjukkan grup yang dikonfigurasi oleh blueprint untuk melihat resource dasar.
| 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 lainnya. 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 sehari-hari. | 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 memelihara konfigurasi jaringan. | Compute Network Viewer | 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 untuk mengelola, menyimpan, dan mengaudit kredensial dan secret lainnya yang digunakan oleh aplikasi. | Secret Manager Admin | project rahasia |
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 membangun workload Anda sendiri di atas fondasi, Anda membuat grup tambahan dan memberikan peran IAM yang didasarkan pada persyaratan akses untuk setiap workload.
Sebaiknya hindari penggunaan 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 mengetahui praktik terbaik terkait peran IAM, lihat Menggunakan IAM dengan aman.
Akun admin super
Pengguna Cloud Identity dengan akun admin super mengabaikan setelan SSO organisasi dan melakukan autentikasi langsung ke Cloud Identity. Pengecualian ini memang dirancang agar admin super tetap dapat mengakses konsol Cloud Identity jika terjadi kesalahan konfigurasi atau pemadaman SSO. Namun, ini berarti Anda harus mempertimbangkan perlindungan tambahan untuk akun admin super.
Untuk melindungi akun admin super Anda, sebaiknya selalu terapkan 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 Anda melakukan aktivasi ke Google Cloud, ada kemungkinan karyawan organisasi Anda 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 proses aktivasi ke Google Cloud. Jika Anda belum menggunakan Google Workspace untuk semua akun pengguna, sebaiknya blokir akses ke akun konsumen.
Kontrol administratif untuk Cloud Identity
Cloud Identity memiliki berbagai kontrol administratif yang tidak diotomatiskan oleh kode Terraform dalam cetak biru. Sebaiknya Anda menerapkan setiap kontrol keamanan praktik terbaik ini sejak awal proses membangun fondasi Anda.
| Kontrol | Deskripsi |
|---|---|
| Men-deploy verifikasi 2 langkah | Akun pengguna dapat disusupi melalui phishing, rekayasa sosial, penyemprotan sandi, atau berbagai ancaman lainnya. Verifikasi 2 langkah membantu memitigasi ancaman ini. Sebaiknya Anda menerapkan verifikasi 2 langkah untuk semua akun pengguna di organisasi Anda 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 Google Cloud layanan | Token OAuth persisten di workstation developer dapat menjadi risiko keamanan jika terekspos. Sebaiknya Anda menetapkan 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 terekspos. Sebaiknya Anda menerapkan durasi sesi web maksimum dan menyelaraskannya dengan kontrol durasi sesi di penyedia SSO Anda. |
| Membagikan data dari Cloud Identity dengan Google Cloud layanan | Log audit Aktivitas Admin dari Google Workspace atau Cloud Identity biasanya dikelola dan dilihat di Konsol Admin, secara terpisah dari log di lingkungan Google Cloud Anda. Log ini berisi informasi yang relevan untuk lingkungan Anda, seperti peristiwa login pengguna. Google Cloud Sebaiknya bagikan log audit Cloud Identity ke lingkungan Google Cloud Anda untuk mengelola log secara terpusat dari semua sumber. |
| Menyiapkan verifikasi pasca SSO | Blueprint ini mengasumsikan bahwa Anda telah 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 menganggap login pengguna mencurigakan. |
| Atasi 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 terkelola. 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 pemulihan yang dibantu dukungan. |
| Menerapkan dan memantau persyaratan sandi untuk pengguna | Dalam sebagian besar kasus, 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 ulang sandi dan pantau kekuatan sandi untuk setiap pengguna yang menggunakan sandi untuk login ke Cloud Identity, terutama akun admin super. |
| Menetapkan kebijakan seluruh organisasi mengenai penggunaan grup | Secara default, akun pengguna eksternal dapat ditambahkan ke grup di Cloud Identity. Sebaiknya Anda mengonfigurasi setelan berbagi agar pemilik grup tidak dapat menambahkan anggota eksternal. Perhatikan bahwa pembatasan ini tidak berlaku untuk akun admin super atau administrator yang didelegasikan lainnya dengan izin admin Grup. Karena gabungan 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 terapkan pembatasan grup. |
Langkah berikutnya
- Baca tentang struktur organisasi (dokumen berikutnya dalam seri ini).