Dokumen ini menyajikan praktik terbaik dan panduan yang membantu Anda menyiapkan penggabungan secara konsisten dan aman. Panduan ini dibuat berdasarkan praktik terbaik untuk menggunakan Cloud Identity atau Google Workspace dengan Google Cloud.
Semua layanan Google, termasuk Google Cloud, Google Marketing Platform, dan Google Ads, mengandalkan Login dengan Google untuk mengautentikasi pengguna. Daripada membuat dan mengelola akun pengguna secara manual di Cloud Identity atau Google Workspace untuk setiap karyawan, Anda dapat menggabungkan Cloud Identity atau Google Workspace dengan penyedia identitas (IdP) eksternal such as Active Directory atau Azure Active Directory. Menyiapkan penggabungan biasanya mencakup hal berikut:
- Menyediakan akun pengguna secara otomatis dari sumber otoritatif eksternal ke Cloud Identity atau Google Workspace.
- Memungkinkan pengguna menggunakan IdP eksternal untuk melakukan autentikasi ke layanan Google.
Memetakan identitas
Identitas akun pengguna yang dikelola oleh Cloud Identity atau Google Workspace ditentukan oleh alamat email utamanya. Alamat email utama tercantum sebagai email Akun Google di halaman Akun Google. Agar dianggap valid, alamat email utama harus menggunakan salah satu domain yang telah Anda tambahkan ke akun Cloud Identity atau Google Workspace.
Alamat email utama juga memenuhi tujuan berikut:
- Alamat email utama adalah nama pengguna yang harus diberikan pengguna saat login. Meskipun pengguna dapat menambahkan alamat email alternatif atau alias ke akun Google, alamat ini tidak dianggap sebagai identitas dan tidak dapat digunakan untuk login.
- Saat admin perlu mengirimkan notifikasi untuk pengguna (misalnya, untuk menginformasikan potensi risiko keamanan), notifikasi tersebut hanya dikirim ke alamat email utama.
Untuk menyiapkan single sign-on dan penyediaan pengguna otomatis antara Google dan IdP eksternal, Anda harus memetakan identitas di IdP eksternal ke identitas yang sesuai di Cloud Identity atau Google Workspace. Bagian berikut menjelaskan praktik terbaik untuk membuat pemetaan ini.
Gunakan identitas yang sama di seluruh sistem federasi
Hal-hal yang diperlukan untuk menentukan pemetaan adalah memverifikasi bahwa pernyataan SAML
yang disediakan idP untuk Google berisi
NameID klaim
dengan nilai yang cocok dengan alamat email utama pengguna
Cloud Identity atau Google Workspace yang ada. IdP gratis digunakan untuk
pemetaan atau logika apapun yang berlaku untuk memperoleh klaim NameID yang cocok untuk
pengguna.
Banyak idP yang bergantung pada alamat email (atau umumnya, nama yang mematuhi RFC 822) untuk mengidentifikasi pengguna. Contohnya mencakup:
- Atribut
userPrincipalNamedalam Active Directory adalah nama yang mematuhi RFC 822 yang secara unik mengidentifikasi pengguna dan dapat digunakan untuk login ke Windows atau Active Directory Federation Services (AD FS). - Azure Active Directory menggunakan atribut
UserPrincipalNameuntuk mengidentifikasi pengguna dan mengizinkan mereka login.
Jika pengguna yang dikelola IdP eksternal sudah bergantung pada alamat email sebagai identitas mereka, pengguna dapat menggunakan identitas yang sama dengan alamat email utama di Cloud Identity atau Google Workspace. Menggunakan identitas pengguna yang sama di seluruh sistem federasi memiliki beberapa keuntungan:
Saat login ke alat Google seperti konsol Google Cloud, pengguna diminta untuk memberikan alamat email utama Cloud Identity atau Google Workspace terlebih dahulu sebelum dialihkan ke IdP eksternal. Bergantung pada IdP pengguna, pengguna mungkin akan melihat layar login lain yang meminta nama pengguna dan sandi mereka.
Jika alamat email berbeda untuk langkah-langkah ini, urutan layar login dapat membingungkan pengguna akhir. Sebaliknya, jika pengguna dapat menggunakan identitas umum di semua langkah, mereka tidak akan mengetahui perbedaan teknis antar-IdP, sehingga meminimalkan potensi kebingungan.
Jika tidak perlu memetakan antar-identitas, hal ini akan memudahkan Anda untuk menghubungkan log audit dari Google Cloud dengan log dari sistem lokal.
Demikian pula, jika aplikasi yang di-deploy sistem lokal di Google Cloud memerlukan penukaran data yang berisi identitas pengguna, Anda akan terhindar dari kerumitan memetakan ID pengguna.
Untuk detail selengkapnya mengenai pengguna Active Directory atau pengguna Azure AD pada Cloud Identity atau Google Workspace, lihat panduan Active Directory atau Azure AD.
Pastikan identitas menggunakan alamat email yang dapat dirutekan
Google Cloud menggunakan alamat email utama pengguna untuk mengirim email notifikasi. Contoh notifikasi ini meliputi:
Pemberitahuan anggaran: Jika Anda telah mengonfigurasi pemberitahuan anggaran, Google Cloud mengirimkan notifikasi ke Admin Penagihan dan Pengguna Penagihan saat batas anggaran terlampaui.
Notifikasi pembayaran: Segala notifikasi atau pemberitahuan terkait pembayaran akan dikirim ke alamat email pengguna pembayaran yang dikonfigurasi untuk akun penagihan terkait.
Undangan project: Jika Anda menetapkan peran Admin Project kepada pengguna, yang merupakan bagian dari akun Cloud Identity atau Google Workspace yang berbeda dengan organisasi project terkait, undangan akan dikirim ke pengguna. Sebelum peran yang baru dapat dijalankan, pengguna harus menerima undangan dengan mengklik link pada pesan email.
Balasan untuk kasus dukungan dan notifikasi lainnya dari Dukungan.
Jika Anda menggunakan Google Workspace dan telah mengonfigurasi data MX DNS yang diperlukan dengan benar, Seluruh email notifikasi yang dikirim ke alamat email utama akan sampai ke kotak masuk Gmail pengguna.
Untuk pengguna Cloud Identity, Google Cloud juga mencoba mengirimkan email notifikasi, tetapi email harus ditangani oleh infrastruktur email yang ada. Untuk memastikan bahwa pengguna Cloud Identity tidak melewatkan notifikasi, pastikan sistem email Anda menerima pesan yang dikirim ke alamat email utama Cloud Identity, dan dan merutekannya ke kotak masuk email yang benar. Lakukan tindakan berikut:
Pastikan semua domain yang ditambahkan ke Cloud Identity memiliki data MX DNS yang mengarah ke sistem email Anda.
Pastikan alamat email utama pengguna Cloud Identity sama dengan kotak surat yang ada di sistem email Anda. Jika ada ketidakcocokan antara alamat email utama pada Cloud Identity dan alamat email pengguna, konfigurasikan alias di sistem email yang ada, sehingga email yang dikirim ke setiap alamat email utama akan diarahkan ke kotak surat yang tepat.
Jika solusi ini tidak praktis, pertimbangkan untuk menambahkan Google Workspace ke akun Cloud Identity Anda dan menetapkan lisensi Google Workspace ke pengguna utama yang bertanggung jawab atas tagihan atau interaksi dengan dukungan, dan siapa saja yang paling mungkin menerima notifikasi.
Menilai opsi migrasi untuk akun konsumen yang ada
Jika karyawan Anda menggunakan layanan Google seperti Google Ad Manager, Google AdSense, atau Google Analytics sebelum organisasi Anda mendaftar ke Cloud Identity atau Google Workspace, kemungkinan karyawan Anda telah menggunakan akun konsumen untuk mengakses layanan ini.
Mengizinkan karyawan menggunakan akun konsumen untuk tujuan bisnis dapat berisiko. Untuk mengetahui detail selengkpanya mengenai risiko tersebut dan cara menampilkan akun konsumen yang ada, lihat Menilai akun Google Anda.
Anda dapat menangani akun konsumen yang ada dengan cara berikut:
- Menjaga akun konsumen seperti apa adanya, dan menerima potensi risiko.
- Migrasikan akun ke Cloud Identity atau Google Workspace dengan memulai transfer.
- Mewajibkan pemilik akun pengguna yang tidak dikelola untuk mengubah alamat email agar dapat menggunakan domain lain.
Untuk mengetahui detail selengkapnya tentang cara menggabungkan akun konsumen yang ada, lihat Menilai opsi konsolidasi identitas.
Cara Anda memutuskan menangani akun konsumen akan memengaruhi cara dan urutan penggabungan yang Anda lakukan. Menilai akun konsumen yang pengguna Anda gunakan sebelum Anda mulai membuat akun pengguna atau menyiapkan single sign-on di Cloud Identity atau Google Workspace.
Memetakan kumpulan identitas
Setelah menentukan cara pemetaan identitas individual antara IdP eksternal dan Cloud Identity atau Google Workspace, Anda harus menentukan kumpulan identitas yang akan digunakan untuk mengaktifkan akses ke layanan Google.
Kumpulan identitas yang efektif dapat melakukan autentikasi ke layanan Google adalah dua kumpulan identitas yang berhubungan:
- Identitas eksternal yang dipetakan ke identitas di Cloud Identity atau Google Workspace.
Identitas eksternal yang diizinkan IdP eksternal Anda untuk Single Sign-On ke Cloud Identity atau Google Workspace.
Proses untuk mengontrol pengguna yang diizinkan menggunakan Single Sign-On berbeda, bergantung pada IdP yang Anda gunakan. Misalnya, Azure AD mengandalkan penetapan, sedangkan AD FS mengandalkan kebijakan kontrol akses.
Membatasi kumpulan identitas yang dapat melakukan autentikasi ke layanan Google
Bergantung pada cara Anda menggunakan Google Cloud, Google Workspace, dan alat Google lainnya, semua karyawan organisasi atau sebagian dari mereka harus dapat melakukan autentikasi ke layanan Google.
Jika Anda berencana memberi akses kepada sebagian karyawan organisasi ke layanan Google, sebaiknya batasi autentikasi ke sekelompok pengguna ini. Dengan membatasi sejumlah pengguna yang dapat melakukan autentikasi, Anda membangun lapisan pertahanan yang dapat membantu Anda ketika tidak sengaja mengonfigurasi aturan kontrol akses menjadi terlalu longgar.
Anda dapat membatasi jumlah pengguna yang dapat melakukan autentikasi ke Google dengan cara berikut:
- Minimalkan jumlah akun pengguna di Cloud Identity atau Google Workspace. Jika tidak ada akun pengguna yang dipetakan, upaya apa pun yang dilakukan pengguna untuk mengautentikasi akan gagal, meskipun IdP mengizinkannya untuk ke Cloud Identity atau Google Workspace dengan menggunakan single sign-on.
- Konfigurasi single sign-on di IdP untuk meminimalkan jumlah pengguna yang diizinkan untuk login ke Cloud Identity atau Google Workspace.
Pendekatan terbaik untuk situasi Anda bergantung pada apakah Anda sudah memiliki akun konsumen yang perlu dimigrasikan.
Membatasi kumpulan identitas yang Anda sediakan jika Anda masih perlu memigrasikan akun konsumen
Anda dapat memigrasikan akun konsumen ke Cloud Identity atau Google Workspace, jika Anda belum membuat akun pengguna dengan identitas yang sama di Cloud Identity atau Google Workspace.
Jika masih memiliki akun konsumen yang masih ingin dimigrasikan, Anda perlu berhati-hati agar tidak secara tidak sengaja membuat akun pengguna yang bentrok. Ikuti pedoman berikut:
- Batasi autentikasi dengan membuat Cloud Identity baru atau akun pengguna Google Workspace hanya untuk pengguna yang membutuhkannya dan tidak memiliki akun konsumen.
- Hindari penguncian akun yang dimigrasikan secara tidak sengaja dengan mengizinkan single sign-on. Tidak hanya untuk pengguna yang Anda buatkan akun pengguna di Cloud Identity atau Google Workspace, tetapi juga untuk semua akun konsumen yang belum dimigrasikan.
Diagram berikut menunjukkan cara berbagai jenis identitas tumpang tindih dan saling berhubungan.
Dalam diagram, identitas dengan akun pengguna di Cloud Identity atau Google Workspace ditempatkan dalam elips terkecil (kuning). Elips tersebut dimuat dalam elips kedua (biru), yang berisi identitas yang dapat mengautentikasi. Elips ketiga dan terbesar (merah muda) berisi identitas lain dan identitas yang memiliki akun pengguna di IdP. Untuk mengetahui detail cara mengonfigurasi Active Directory, Azure AD, atau Okta, lihat panduan praktik terbaik yang terpisah.
Mencegah pendaftaran akun konsumen baru
Menambahkan domain seperti example.com ke akun Cloud Identity atau
Google Workspace tidak mencegah karyawan dari mendaftar akun
konsumen baru dengan menggunakan domain yang sama. Akun konsumen baru
ditampilkan sebagai akun yang tidak terkelola di akun Cloud Identity atau
Google Workspace Anda, tetapi akun tersebut tidak diizinkan untuk melakukan single sign-on atau
konfigurasi lain yang Anda terapkan di akun Cloud Identity atau
Google Workspace.
Salah satu cara untuk memblokir pembuatan akun konsumen baru adalah dengan membuat akun
pengguna di Cloud Identity atau Google Workspace dengan alamat email
yang sama. Misalnya, jika Anda membuat pengguna alice@example.com di akun
Cloud Identity atau Google Workspace, setiap upaya
yang dilakukan oleh karyawan untuk mendaftar ke akun konsumen baru dengan identitas yang sama akan
gagal. Namun, jika belum ada pengguna terkait di Cloud Identity atau
Google Workspace, pendaftaran akun konsumen baru akan
berhasil.
Jika tidak ada lagi akun konsumen yang akan dimigrasikan ke Cloud Identity, cegah pendaftaran akun konsumen baru dengan menerapkan konfigurasi berikut:
Batasi autentikasi dengan hanya mengizinkan pengguna yang relevan untuk menggunakan Single Sign-On ke Cloud Identity atau Google Workspace.
Sediakan pengguna Cloud Identity atau Google Workspace untuk semua karyawan. Pastikan seluruh akun pengguna menggunakan alamat email perusahaan milik karyawan sebagai alamat email utama atau alias sehingga akun pengguna baru dapat dibuat dengan menggunakan alamat email yang sama. Jika memungkinkan, biarkan akun pengguna yang tidak diaktifkan untuk single sign-on dalam status ditangguhkan.
Diagram berikut menunjukkan konfigurasi ini.
Jika masih dalam proses migrasi akun konsumen, Anda dapat
memantau pendaftaran akun konsumen baru untuk sementara melalui email verifikasi
yang dikirim selama proses pendaftaran. Email verifikasi menggunakan
alamat pengirim pesan yang cocok dengan *@idverification.bounces.google.com.
Siapkan filter di sistem email Anda yang mengidentifikasi email dengan alamat pengirim
pesan ini dan menahannya untuk peninjauan internal.
Menjadikan Cloud Identity atau Google Workspace sebagai subkumpulan identitas di IdP eksternal Anda
Akun Cloud Identity atau Google Workspace Anda mungkin berisi akun pengguna dengan identitas yang tidak dipetakan ke pengguna di IdP eksternal. Ada dua skenario umum yang dapat menghasilkan akun pengguna:
- Anda dapat membuat akun pengguna baru di Cloud Identity atau Google Workspace dan menggunakan alamat email utama yang tidak dipetakan ke pengguna mana pun di IdP eksternal.
- Anda memiliki akun pengguna di Cloud Identity atau Google Workspace yang memetakan ke identitas di IdP eksternal, tetapi kemudian Anda menghapus identitas di IdP eksternal. Misalnya, Anda mungkin menghapus identitas jika karyawan keluar dari perusahaan.
Ketika Anda mengaktifkan Single Sign-On di Cloud Identity atau Google Workspace, semua pengguna (kecuali admin super) akan dipaksa untuk menggunakan single sign-on. Untuk akun pengguna Cloud Identity atau Google Workspace yang tidak dipetakan ke identitas di IdP eksternal, segala upaya untuk menggunakan single sign-on akan gagal. Akun pengguna tanpa adanya hal yang serupa akan secara efektif dinonaktifkan, tetapi mungkin akan tetap menimbulkan risiko, seperti dalam situasi berikut:
Jika suatu saat single sign-on dinonaktifkan untuk sementara atau secara permanen, akun pengguna tetap dapat digunakan lagi. Langkah ini memungkinkan mantan karyawan untuk login dan mengakses sumber daya perusahaan.
Nama akun pengguna yang dihapus dapat digunakan kembali. Misalnya, karyawan yang bergabung dengan perusahaan mungkin memiliki nama yang sama dengan karyawan lain yang keluar dari perusahaan beberapa bulan atau tahun sebelumnya. Jika akun pengguna karyawan sebelumnya telah dihapus, kemungkinan Anda menetapkan nama pengguna yang digunakan mantan karyawan tersebut sebagai nama pengguna untuk karyawan baru.
Akun pengguna karyawan baru mungkin memiliki ID internal yang berbeda dari akun mantan karyawan. Namun, dari perspektif penggabungan, kedua akun pengguna tersebut dianggap sama jika keduanya dipetakan ke alamat email utama yang sama di Cloud Identity atau Google Workspace. Akibatnya, saat karyawan baru login ke Google, mereka mungkin "mewarisi" data, setelan, dan izin yang ada dari mantan karyawan.
Pengguna admin super Cloud Identity dan Google Workspace dikecualikan dari persyaratan untuk menggunakan Single Sign-On, tetapi mereka tetap diizinkan untuk menggunakan Single Sign-On saat login dimulai oleh IdP. Kemampuan untuk menggunakan single sign-on yang dimulai IdP membuat pengguna super admin sensitif terhadap name squatting jika mereka tidak memiliki padanan di IdP eksternal.
Pertimbangkan contoh berikut: Alice memiliki alice-admin@example.com pengguna admin super
di Cloud Identity atau Google Workspace,
dan ia tidak menggunakan verifikasi dua langkah. Mallory, yang tidak mengetahui sandi Alice,
menemukan cara untuk membuat pengguna baru di IdP eksternal yang dipetakan
kealice-admin@example.com. Meskipun akun pengguna yang baru dibuat mungkin tidak
memiliki hak istimewa khusus dan tidak memiliki hubungannya dengan akun pengguna Alice, fakta bahwa
akun tersebut memiliki identitas yang sama dengan akun admin super Alice sekarang
memungkinkan Mallory menggunakan single sign-on yang dimulai IdP dan mengautentikasi sebagai
alice-admin@example.com.
Untuk mengurangi risiko name squatting, pastikan identitas Cloud Identity atau Google Workspace Anda merupakan subkumpulan identitas di IdP eksternal. Cara terbaik untuk melakukannya adalah dengan memetakan seluruh siklus proses akun pengguna seperti yang diterapkan oleh IdP eksternal ke siklus proses akun pengguna di Cloud Identity atau Google Workspace.
Menggunakan pengguna admin super khusus
Akun admin super Google Workspace dan Cloud Identity memiliki serangkaian izin yang kuat yang tidak hanya diterapkan pada akun Cloud Identity atau Google Workspace, tetapi juga pada organisasi Google Cloud terkait. Karena hanya sedikit aktivitas yang memerlukan hak istimewa admin super, jika memungkinkan, sebaiknya batasi jumlah administrator dengan akses admin super, dan gunakan akun pengguna yang memiliki sedikit hak istimewa untuk administrasi harian akun Anda atau organisasi Google Cloud.
Setelah Anda mengidentifikasi administrator yang memerlukan akses admin super, buatlah akun pengguna admin super khusus—misalnya:
- Buat akun pengguna dengan identitas
alice@example.comdan tetapkan izin reguler. Akun ini harus digunakan setiap hari untuk aktivitas rutin. Buat akun pengguna kedua dengan identitas
alice-admin@example.comdan tetapkan hak istimewa pengguna super. Praktik terbaiknya adalah Alice menggunakan akun ini hanya untuk situasi yang memerlukan hak istimewa admin super.Untuk memastikan bahwa email notifikasi yang dikirim ke alamat email ini telah diterima di kotak surat pengguna, konfigurasikan Google Workspace atau sistem email yang sudah ada sehingga alamat email,
alice-admin@example.comyang merupakan alias, diteruskan kealice@example.com.
Pastikan kedua identitas dikenali oleh IdP eksternal Anda sehingga kumpulan identitas di Cloud Identity atau Google Workspace menjadi subkumpulan identitas di IdP eksternal.
Sebaiknya ikuti skema penamaan untuk akun admin super khusus ini
sehingga dalam log audit, Anda dapat melacak tempat dan cara akun tersebut digunakan. Misalnya,
tambahkan -admin ke nama pengguna, seperti pada contoh sebelumnya.
Membatasi jumlah pengguna layanan di Google Workspace dan Cloud Identity
IdP eksternal Anda mungkin tidak hanya berisi akun pengguna untuk karyawan, tetapi juga ditujukan untuk pengguna mesin seperti aplikasi, alat, atau tugas latar belakang.
Sebaliknya, cara yang direkomendasikan Google Cloud untuk memungkinkan aplikasi mengautentikasi dan mengakses Google API adalah dengan menerapkan salah satu pendekatan berikut:
Aplikasi atau alat web yang perlu mengakses Google API atau layanan pada pengguna akhir harus menggunakan OAuth 2.0 atau OpenID Connect. Dengan menggunakan salah satu protokol ini, aplikasi meminta izin pengguna akhir terlebih dahulu untuk mengakses data pengguna, dan setelah menerima persetujuan, selanjutnya dapat dilakukan akses atas nama pengguna akhir tersebut.
Jika akses ke API atau layanan tidak mengizinkan atas nama pengguna akhir, melainkan atas nama aplikasi itu sendiri, sebaiknya gunakan akun layanan Google Cloud untuk autentikasi, kemudian beri akses akun layanan ke resource dengan menggunakan IAM.
Jika akun layanan Google Cloud diberi peran berdasarkan IAM, akun tersebut dapat digunakan untuk mengautentikasi dan menggunakan segala Cloud API. Jika Anda perlu memberi akun layanan akses ke API yang berada di luar Google Cloud, misalnya, ke Directory API atau Drive API, Anda dapat menggunakan delegasi seluruh domain Google Workspace.
Dengan delegasi seluruh domain Google Workspace, Anda memungkinkan akun layanan untuk bertindak atas nama pengguna Cloud Identity atau Google Workspace. Karena delegasi adalah hak istimewa yang kuat, sebaiknya Anda menggunakan delegasi seluruh domain Google Workspace hanya jika pendekatan OAuth sulit diterapkan.
Gunakan pengguna Cloud Identity atau Google Workspace khusus untuk setiap akun layanan Google Cloud yang diaktifkan untuk delegasi seluruh domain Google Workspace. Buat pengguna ini di IdP eksternal, lalu sediakan di Cloud Identity atau Google Workspace agar kumpulan pengguna tersebut terus menjadi sebagian dari pengguna di IdP eksternal Anda.
Hindari membuat pengguna layanan di Cloud Identity dan Google Workspace yang tidak Anda tujukan untuk delegasi seluruh domain Google Workspace.
Memetakan siklus proses akun pengguna
Akun pengguna di IdP eksternal Anda mengikuti siklus proses tertentu. Biasanya, siklus proses ini mencerminkan hubungan kerja antara karyawan dan perusahaan:
- Akun pengguna baru dibuat untuk karyawan yang bergabung dengan organisasi.
- Akun pengguna mungkin ditangguhkan untuk sementara dan kemudian diaktifkan kembali—misalnya, saat karyawan pergi.
- Saat pengguna keluar dari perusahaan, akun pengguna akan dihapus atau dipertahankan dalam status ditangguhkan selama periode retensi data tertentu sebelum akhirnya dihapus.
Diagram berikut mengilustrasikan siklus proses ini.
Bagian ini mencantumkan praktik terbaik untuk memastikan bahwa siklus proses akun pengguna di Cloud Identity atau Google Workspace mengikuti siklus proses akun pengguna yang sesuai di IdP eksternal Anda.
Menetapkan IdP eksternal Anda sebagai sumber kebenaran
Banyak sistem informasi HR (HRIS), IdP, dan adaptor hanya mendukung penyediaan pengguna satu arah. Ini berarti bahwa perubahan yang dilakukan di HRIS atau IdP akan diterapkan ke Cloud Identity atau Google Workspace, tetapi perubahan yang dilakukan tidak diterapkan kembali.
Untuk mencegah inkonsistensi yang disebabkan oleh penyediaan satu arah, tetapkan IdP eksternal Anda sebagai sumber tepercaya. Gunakan IdP (atau HRIS) eksternal Anda secara eksklusif untuk membuat, mengubah, atau menghapus pengguna, dan mengandalkan penyediaan otomatis agar perubahan diterapkan ke Google Workspace dan Cloud Identity. Dengan menetapkan IdP eksternal sebagai sumber kebenaran, Anda membatasi risiko inkonsistensi dan modifikasi manual yang tergantikan oleh IdP.
Mengotomatiskan penyediaan pengguna ke Cloud Identity atau Google Workspace
Agar karyawan dapat melakukan autentikasi ke Google dengan menggunakan Single Sign-On, Anda harus membuat akun pengguna untuk karyawan tersebut di Cloud Identity atau Google Workspace terlebih dahulu. Untuk memastikan konsistensi dengan IdP eksternal Anda, sebaiknya otomatiskan proses penyediaan akun pengguna di Cloud Identity atau Google Workspace:
- Dengan mengotomatiskan penyediaan, Anda dapat memastikan bahwa identitas Cloud Identity atau Google Workspace merupakan subkumpulan identitas di IdP eksternal.
- Anda meminimalkan risiko ketidakcocokan antara identitas di Cloud Identity atau Google Workspace dan identitas yang sesuai di IdP eksternal secara tidak sengaja. Ketidakcocokan seperti kesalahan ejaan alamat email yang tidak disengaja dapat menyebabkan karyawan mengalami masalah saat login.
- Anda meminimalkan upaya administrasi manual.
Jika Anda menggunakan HRIS untuk mengelola proses orientasi, salah satu cara untuk mengotomatiskan penyediaan pengguna adalah dengan mengonfigurasi HRIS guna menyediakan akun pengguna untuk IdP eksternal dan ke Cloud Identity atau Google Workspace, seperti pada diagram berikut.
Agar penyiapan ini berfungsi dengan baik, Anda harus memastikan bahwa HRIS menyediakan akun pengguna sehingga akun tersebut satu sama lain dapat dipetakan dengan benar. Selain itu, HRIS harus menangani keputusan tentang akun pengguna mana yang akan disediakan untuk Cloud Identity atau Google Workspace.
Cara lain untuk mengotomatiskan penyediaan pengguna yang bekerja secara independen dari HRIS adalah dengan menggunakan IdP eksternal sebagai sumber otoritatif untuk menyediakan pengguna di Cloud Identity atau Google Workspace. Dalam penyiapan ini, konfigurasi untuk memetakan akun pengguna dan sekumpulan akun pengguna dikelola di IdP atau adaptor, seperti yang ditunjukkan diagram berikut.
Jika menggunakan Active Directory sebagai IdP, Anda dapat menduplikasi penyiapan ini menggunakan Google Cloud Directory Sync. IdP lain seperti Azure AD atau Okta memiliki adaptor bawaan untuk penyediaan pengguna ke Google Workspace. Karena Google Workspace dan Cloud Identity didasarkan pada platform yang sama dan menggunakan API yang sama, adaptor ini juga dapat digunakan untuk Cloud Identity.
Memperluas peristiwa penangguhan ke Cloud Identity atau Google Workspace
Ketika seorang karyawan keluar dari organisasi, baik untuk sementara maupun permanen, sebaiknya Anda mencabut akses karyawan tersebut ke layanan Google. Dengan menangguhkan akun pengguna karyawan di IdP eksternal, Anda mencabut kemampuan mereka untuk menggunakan single sign-on untuk mengautentikasi ke Google, tetapi tindakan ini mungkin tidak mencabut akses sepenuhnya ke semua layanan Google. Hal berikut masih dapat terjadi:
- Jika pengguna Cloud Identity atau Google Workspace memiliki sesi browser aktif, sesi tersebut akan terus berfungsi. Token OAuth yang telah diperoleh juga akan tetap valid.
- Jika pengguna memiliki hak istimewa admin super atau jika Anda telah mengonfigurasi network mask, karyawan mungkin masih dapat login menggunakan sandi.
- Akun pengguna mungkin masih menerima notifikasi dari Google Cloud, termasuk pemberitahuan anggaran.
- Jika pengguna memiliki lisensi Google Workspace yang ditetapkan, email akan terus dikirim ke kotak surat pengguna yang masih terdaftar di buku alamat, dan mungkin masih tercantum di Google Kalender.
- Jika Anda mengizinkan pengguna menggunakan aplikasi yang kurang aman, pengguna mungkin masih dapat mengakses Gmail, Google Kalender, dan data lainnya dengan menggunakan sandi aplikasi.
Untuk mencabut akses sepenuhnya ke layanan Google, terapkan penangguhan ke Cloud Identity atau Google Workspace dengan cara berikut:
Pastikan setiap kali akun pengguna ditangguhkan di IdP eksternal, akun pengguna yang terkait di Cloud Identity atau Google Workspace juga akan ditangguhkan. Menangguhkan pengguna di Cloud Identity atau Google Workspace akan menghentikan sesi browser aktif, membatalkan token, dan mencabut semua akses lainnya.
Demikian pula, saat mengaktifkan kembali akun pengguna di IdP eksternal, pastikan Anda juga mengaktifkan kembali akun pengguna yang sesuai di Cloud Identity or Google Workspace.
Menangguhkan akun pengguna di Cloud Identity atau Google Workspace adalah operasi yang tidak merusak. Ketika akun pengguna ditangguhkan, data pengguna akan dipertahankan, lisensi Google Workspace tetap terlampir, dan peran yang ditetapkan di Google Cloud tidak akan berubah.
Memperluas peristiwa penghapusan ke Cloud Identity atau Google Workspace
Saat karyawan keluar dari organisasi secara permanen, Anda mungkin memutuskan untuk tidak hanya menangguhkan akun pengguna karyawan tersebut di IdP eksternal, tetapi juga menghapusnya.
Jika Anda menghapus akun pengguna di IdP eksternal, tetapi tidak menghapus Cloud Identity atau Google Workspace yang terkait, kumpulan pengguna di Cloud Identity dan Google Workspace tidak lagi menjadi subbagian pengguna di IdP eksternal. Hal ini dapat menjadi masalah di masa depan jika karyawan baru yang bergabung ke organisasi Anda memiliki nama yang sama dengan karyawan yang keluar dari perusahaan. Jika membuat akun pengguna di IdP untuk karyawan baru, Anda dapat menggunakan kembali nama pengguna karyawan lama, sehingga akun pengguna baru akan dipetakan ke akun pengguna lama di Cloud Identity atau Google Workspace. Akibatnya, karyawan baru mungkin mendapatkan akses ke data dan pengaturan karyawan lama.
Anda dapat menghindari risiko terkait dengan akun pengguna Cloud Identity atau Google Workspace yang usang dengan cara menghapus pengguna tersebut setelah akun mereka yang tercantum di IdP dihapus.
Menghapus pengguna Cloud Identity atau Google Workspace adalah operasi merusak yang hanya dapat diurungkan dalam jangka waktu tertentu. Bergantung pada layanan Google yang digunakan oleh pengguna, penghapusan pengguna dapat menyebabkan data terhapus secara permanen sehingga mungkin tidak memenuhi persyaratan kepatuhan Anda.
Untuk mempertahankan setelan dan data pengguna selama periode retensi data tertentu sebelum menghapusnya secara permanen, terapkan salah satu pendekatan berikut:
Tunda penghapusan akun pengguna di IdP eksternal dengan mempertahankan penangguhan pengguna selama periode retensi tertentu. Hapus pengguna di IdP dan Cloud Identity/Google Workspace setelah periode retensi data berlalu.
Ketika menghapus akun pengguna di IdP eksternal, tangguhkan pengguna Cloud Identity atau Google Workspace yang sesuai dan ubah alamat email utamanya menjadi nama yang tidak akan menyebabkan masalah. Misalnya, ganti nama
alice@example.commenjadiobsolete-yyyymmdd-alice@example.com, yang manayyyymmddmencerminkan tanggal penghapusan di IdP eksternal Anda. Pertahankan akun pengguna yang namanya diganti dalam status ditangguhkan selama periode retensi data, kemudian hapus setelah periode retensi data selesai.
Untuk menyimpan data Google Workspace bagi pengguna yang ditangguhkan, biarkan lisensi Google Workspace ditetapkan kepada pengguna atau alihkan ke lisensi Arsip Akun Pengguna untuk memastikan Aturan retensi Google Workspace Vault terus berlaku dan data pengguna tetap bertahan.
Single sign-on
Semua produk Google, termasuk layanan seperti Google Cloud,
Google Ads, dan YouTube, menggunakan
Login dengan Google
untuk mengautentikasi pengguna. Layanan memulai proses autentikasi dengan
mengalihkan pengguna ke accounts.google.com tempat pengguna melihat layar login
Google dan diminta memasukkan alamat emailnya. Bergantung pada domain
dari alamat email yang diberikan, akun pengguna akan dicari di Gmail,
direktori akun konsumen, atau apakah domain sesuai dengan
domain primer, sekunder, atau aliasdi
akun Cloud Identity atau Google Workspace.
Diagram berikut mengilustrasikan proses autentikasi ini.
Jika Anda mengonfigurasi akun Cloud Identity atau Google Workspace untuk menggunakan single sign-on, maka pengguna akan dialihkan ke IdP eksternal untuk melakukan autentikasi. Setelah IdP eksternal telah menyelesaikan autentikasi, hasilnya akan dikirimkan kembali ke Login Google melalui pernyataan SAML. Pernyataan SAML ini berfungsi sebagai bukti autentikasi berhasil. Pernyataan berisi alamat email pengguna, dan ditandatangani oleh sertifikat IdP eksternal sehingga Login dengan Google dapat memverifikasi keasliannya.
Proses ini disebut sebagai single sign-on yang dimulai penyedia layanan, dan berlaku untuk semua pengguna kecuali untuk admin super. Admin super tidak pernah dialihkan ke IdP eksternal dan diminta untuk memasukkan sandi.
Beberapa IdP juga mendukung single sign-on yang dimulai IdP. Pada model ini, pengguna melakukan autentikasi di IdP eksternal, lalu mengikuti link yang mengarah ke layanan Google seperti Google Cloud atau Google Ads. Jika Single Sign-On telah diaktifkan untuk akun Cloud Identity atau Google Workspace, semua pengguna akun tersebut akan diizinkan untuk menggunakan single sign-on yang dimulai IdP, termasuk admin super.
Meminimalkan kumpulan atribut yang diteruskan dalam pernyataan SAML
Setelah pengguna melakukan autentikasi di IdP eksternal, Cloud Identity atau
Google Workspace akan menggunakan pernyataan SAML yang diteruskan oleh IdP eksternal
untuk membuat sesi. Selain memvalidasi keasliannya, proses
ini mencakup identifikasi akun pengguna Cloud Identity atau Google Workspace
yang sesuai dengan nilai NameID dalam pernyataan SAML.
Nilai NameID diharapkan berisi alamat email utama akun pengguna yang akan
diautentikasi. Alamat email peka huruf besar/kecil. Alias dan
alamat email alternatif tidak dipertimbangkan.
Untuk menghindari ketidakcocokan ejaan atau huruf besar/kecil yang tidak disengaja, sebaiknya sediakan akun pengguna secara otomatis.
Pernyataan SAML boleh berisi atribut tambahan, tetapi tidak akan dipertimbangkan selama autentikasi. Atribut yang berisi informasi seperti nama depan, nama keluarga, atau keanggotaan grup akan diabaikan karena akun pengguna di Cloud Identity atau Google Workspace dianggap sebagai satu-satunya sumber untuk informasi pengguna ini.
Untuk meminimalkan ukuran pernyataan SAML, konfigurasikan IdP Anda agar tidak menyertakan atribut apa pun yang tidak diperlukan pada saat Login dengan Google.
Menggunakan google.com sebagai penerbit
Sesi Login dengan Google tidak dibatasi untuk satu alat atau domain. Namun, setelah sesi dibuat, sesi tersebut berlaku di semua layanan Google yang telah diberi akses kepada pengguna. Daftar layanan ini mungkin mencakup layanan seperti Google Cloud dan Google Ads, serta layanan seperti Google Penelusuran dan YouTube.
Sifat global suatu sesi tercermin dalam pertukaran protokol SAML: secara
default, Google menggunakan google.com sebagai penerbit (elemen Issuer dalam
permintaan SAML) dalam permintaan SAML, dan yang menginginkan pernyataan SAML untuk menentukan
google.com sebagai audiens (elemen Audience dalam respons SAML).
Anda dapat mengubah setelan default ini dengan mengaktifkan opsi Gunakan penerbit khusus domain
saat mengonfigurasi Single Sign-On di Cloud Identity atau
Google Workspace. Aktifkan opsi penerbit khusus domain hanya jika Anda memiliki lebih dari satu akun Cloud Identity atau Google Workspace (sehingga beberapa domain) dan IdP Anda harus dapat membedakan antara login yang dimulai oleh satu akun Cloud Identity atau Google Workspace dengan akun lain. Saat Anda mengaktifkan opsi ini, permintaan SAML akan menggunakan
google.com/a/DOMAIN sebagai penerbit dan mengharapkan
google.com/a/DOMAIN sebagai audience, dengan
DOMAIN sebagai domain primer
Cloud Identity atau akun Google Workspace.
Dalam kasus lainnya, pertahankan setelan default untuk menggunakan google.com sebagai penerbit
dan konfigurasikan IdP eksternal Anda untuk menentukan google.com sebagai audiens di pernyataan
SAML. Bergantung pada IdP Anda, setelan ini mungkin juga disebut sebagai
penerbit, ID kepercayaan pihak yang mengandalkan, atau ID entitas.
Menyelaraskan durasi dari sesi Google dan sesi IdP
Saat pengguna telah menyelesaikan proses single sign-on dan sesi telah dibuat, sesi Login dengan Google akan tetap aktif selama jangka waktu tertentu. Jika jangka waktu ini berakhir atau jika pengguna logout, pengguna akan diminta untuk melakukan autentikasi ulang dengan mengulangi proses single sign-on.
Secara default, durasi sesi untuk layanan Google adalah 14 hari. Pengguna dengan lisensi Cloud Identity Premium atau Google Workspace Business, dapat mengubah durasi sesi default ke durasi yang berbeda, seperti 8 jam.
Anda dapat mengontrol durasi sesi yang digunakan Google Cloud. Sesi Google Cloud berlaku untuk konsol Google Cloud serta Google Cloud CLI dan klien API lainnya. Anda dapat mengatur durasi sesi Google Cloud di semua jenis akun Cloud Identity dan Google Workspace.
Sebagian besar IdP eksternal juga menjaga sesi untuk pengguna yang diautentikasi. Jika durasi sesi IdP lebih panjang dari durasi sesi Google, autentikasi ulang mungkin akan terjadi secara otomatis. Artinya, pengguna akan dialihkan ke IdP, tetapi mungkin tidak perlu memasukkan kredensial lagi. Autentikasi ulang otomatis dapat merusak intent mempersingkat durasi sesi Google.
Untuk memastikan pengguna memasukkan kredensial mereka lagi setelah sesi Google berakhir, konfigurasikan durasi sesi Google dan sesi IdP sehingga durasi sesi IdP lebih pendek dari sesi Google.
Menonaktifkan single sign-on untuk pengguna admin super
Untuk pengguna admin super, SSO bersifat opsional: Mereka dapat menggunakan SSO saat login dimulai oleh IdP, tetapi mereka juga dapat login menggunakan nama pengguna dan sandi.
Jika tidak berencana menggunakan single sign-on yang dimulai IdP untuk pengguna super-admin, Anda dapat mengurangi risiko dengan menggunakan prosedur berikut:
- Tambahkan unit organisasi khusus untuk admin super.
- Tetapkan profil SSO ke unit organisasi yang menonaktifkan single sign-on.
Atau, jika Anda berencana menggunakan single sign-on yang dimulai IdP, pastikan Anda menerapkan verifikasi pasca-SSO untuk pengguna admin super.
Autentikasi multi-faktor
Mengaktifkan Single Sign-On antara Cloud Identity atau Google Workspace dan IdP eksternal akan meningkatkan pengalaman pengguna bagi karyawan. Pengguna harus lebih jarang melakukan autentikasi dan tidak perlu mengingat kredensial terpisah untuk mengakses layanan Google.
Namun, memungkinkan pengguna untuk melakukan autentikasi dengan lancar di seluruh layanan dan lingkungan juga berarti bahwa potensi dampak dari kredensial pengguna yang disusupi akan meningkat. Jika nama pengguna dan sandi pengguna hilang atau dicuri, penyerang mungkin menggunakan kredensial ini untuk mengakses resource. Tidak hanya di lingkungan Anda yang sudah ada, tetapi juga di satu atau beberapa layanan Google.
Untuk mengurangi risiko pencurian kredensial, sebaiknya gunakan autentikasi multi-faktor untuk semua akun pengguna.
Menerapkan autentikasi multi-faktor untuk pengguna
Setelah Anda mengonfigurasi Single Sign-On untuk akun Cloud Identity atau Google Workspace, pengguna yang tidak memiliki hak istimewa admin super harus menggunakan IdP eksternal untuk melakukan autentikasi.
Konfigurasikan IdP Anda untuk mewajibkan penggunaan faktor kedua (seperti kode sekali pakai atau kunci USB) guna menerapkan autentikasi multi-faktor setiap kali single sign-on ke Google digunakan.
Jika IdP eksternal tidak mendukung autentikasi multi-faktor, sebaiknya aktifkan verifikasi pasca-SSO agar Google melakukan verifikasi tambahan setelah pengguna kembali dari autentikasi dengan perangkat IdP eksternal.
Hindari penggunaan network mask, karena dapat disalahgunakan sebagai upaya menghindari autentikasi multi-faktor bagi pengguna.
Menerapkan autentikasi 2 langkah Google untuk pengguna admin super
Pengguna admin super tidak akan dialihkan ke IdP eksternal saat mencoba login ke Konsol Google Cloud atau situs Google lainnya. Sebagai gantinya, pengguna admin super diminta untuk melakukan autentikasi dengan nama pengguna dan sandi.
Karena pengguna super-admin dapat melakukan autentikasi berdasarkan nama pengguna dan sandi, mereka tidak tunduk pada kebijakan autentikasi multi-faktor yang mungkin diterapkan oleh IdP. Untuk melindungi pengguna admin super, terapkan autentikasi 2 langkah Google untuk semua pengguna admin super.
Pengguna admin super biasanya termasuk dalam salah satu dari dua kategori berikut:
Pengguna admin super yang dipersonalisasi: Pengguna ini dipersonalisasi dan dimaksudkan untuk digunakan oleh satu administrator. Sebaiknya terapkan verifikasi 2 langkah untuk semua pengguna admin super yang dipersonalisasi.
Pengguna super-admin mesin: Meskipun disarankan menghindari akun pengguna ini, terkadang akun pengguna perlu diaktifkan untuk mengaktifkan alat seperti Cloud Directory Sync atau aplikasi galeri Azure AD untuk mengelola pengguna dan grup di Cloud Identity atau Google Workspace.
Batasi jumlah pengguna admin super dan coba aktifkan verifikasi 2 langkah jika memungkinkan.
Untuk pengguna yang tidak menggunakan Single Sign-On, Anda dapat menerapkan autentikasi 2 langkah di salah satu akun secara global, berdasarkan unit organisasi, atau berdasarkan grup:
Jika tidak memiliki pengguna admin super mesin yang tidak dapat menggunakan verifikasi 2 langkah, sebaiknya aktifkan penerapan untuk semua pengguna. Dengan menerapkan verifikasi 2 langkah untuk semua pengguna, Anda terhindar dari risiko kehilangan pengguna tanpa sengaja.
Jika Anda memiliki pengguna admin super mesin yang tidak dapat menggunakan verifikasi 2 langkah, gunakan grup khusus untuk mengontrol verifikasi 2 langkah. Buat grup baru, aktifkan penerapan untuk grup, dan tambahkan semua pengguna super yang relevan ke grup tersebut.
Untuk mengetahui detail selengkapnya tentang penggunaan autentikasi 2 langkah guna mengamankan pengguna super-admin, lihat praktik terbaik keamanan untuk akun administrator kami.
Menerapkan verifikasi pasca-SSO untuk pengguna admin super
Meskipun pengguna admin super tidak diwajibkan menggunakan single sign-on, mereka tetap diizinkan untuk menggunakan single sign-on saat dimulai oleh IdP. Untuk memastikan bahwa pengguna admin super selalu tunduk pada verifikasi 2 langkah, meskipun mereka melakukan autentikasi dengan login dengan IdP, aktifkan verifikasi SSO tambahan dan Verifikasi 2 Langkah untuk semua pengguna admin super.
Verifikasi SSO tambahan mungkin tampak berlebihan jika IdP Anda sudah menerapkan autentikasi multi-faktor, tetapi setelan tersebut dapat membantu melindungi pengguna admin super jika IdP disusupi.
Jangan batasi single sign-on dengan network mask
Saat mengonfigurasi Single Sign-On di Cloud Identity atau Google Workspace, Anda dapat secara opsional menentukan network mask. Jika Anda menentukan penyamaran, hanya pengguna dengan alamat IP yang cocok dengan penyamaran yang akan dikenai single sign-on; pengguna lain diminta untuk memasukkan sandi saat mereka login.
Jika menggunakan network mask, Anda mungkin merusak autentikasi multi-faktor yang diterapkan oleh IdP eksternal. Misalnya, dengan mengubah lokasi atau menggunakan VPN, pengguna mungkin dapat mengontrol apakah network mask berlaku atau tidak. Jika Anda menerapkan autentikasi multi-faktor di IdP eksternal, taktik ini mungkin memungkinkan pengguna atau penyerang mengakali kebijakan autentikasi multi-faktor yang dikonfigurasi pada IdP eksternal.
Untuk memastikan bahwa autentikasi multi-faktor berlaku secara konsisten, terlepas dari lokasi atau alamat IP pengguna, hindari membatasi single sign-on dengan network mask.
Untuk membatasi akses ke resource berdasarkan alamat IP, konfigurasikan daftar yang diizinkan IP yang sesuai di IdP eksternal, atau gunakan akses kontekstual untuk Google Cloud dan Google Workspace.
Langkah selanjutnya
- Pelajari praktik terbaik tambahan:
- Bandingkan pola untuk melakukan penggabungan IdP eksternal dengan Google Cloud.