Praktik terbaik untuk menggunakan Workforce Identity Federation

Workforce Identity Federation memfederasikan Google Cloud organisasi Anda dengan penyedia identitas (IdP) eksternal untuk mengaktifkan single sign-on (SSO).

Anda dapat menerapkan praktik terbaik ini untuk menggunakan Workforce Identity Federation secara efektif dan meminimalkan risiko keamanan.

Memilih arsitektur yang tepat

Bagian berikut menjelaskan faktor-faktor utama untuk memilih arsitektur federasi yang sesuai dengan kebutuhan Anda.

Pertimbangan arsitektur:

Pilih pola arsitektur federasi.
Partisi penggunaan federasi menurut layanan, bukan menurut pengguna.

Memilih pola arsitektur federasi

Empat pola berikut menjelaskan cara umum untuk melakukan penggabungan organisasi Google Cloud dengan IdP eksternal:

Sebelum melakukan federasi, pertimbangkan keuntungan dan batasan setiap pola serta pilih pola yang sesuai dengan persyaratan Anda. Untuk mengetahui informasi selengkapnya, lihat Pola arsitektur untuk federasi identitas.

Penggunaan federasi partisi menurut layanan

Secara umum, sebaiknya Anda mempartisi penggunaan federasi menurut layanan, bukan menurut pengguna. Penggunaan partisi menurut layanan secara keseluruhan memiliki lebih sedikit kerugian.

Untuk mengurangi kompleksitas, sebaiknya gunakan Cloud Identity atau Workforce Identity Federation. Namun, bergantung pada persyaratan Anda, Anda mungkin memerlukan keduanya secara paralel seperti yang dijelaskan dalam pola hybrid.

Jika Anda menggunakan federasi Cloud Identity dan Workforce Identity Federation secara paralel, Anda dapat mempartisi penggunaannya dengan cara berikut:

  • Partisi menurut pengguna: Partisi pengguna Anda ke dalam dua kelompok: satu menggunakan Workforce Identity Federation dan satu menggunakan federasi Cloud Identity.

    • Keuntungan: Setiap pengguna memiliki satu identitas di seluruh layanan Google dan satu metode login.

    • Kekurangan: Partisi menurut pengguna memiliki beberapa kekurangan, termasuk yang berikut:

      • Mengelola grup akses bisa jadi rumit karena kebijakan izin IAM harus berisi kombinasi jenis prinsipal dan Anda tidak dapat menggunakan grup yang sama untuk pengguna Cloud Identity dan Workforce Identity Federation.

      • Pengguna dari berbagai kohor tidak dapat saling membagikan link karena konsol Google Cloud , Gemini Enterprise, dan alat lainnya menggunakan URL yang berbeda, bergantung pada cara pengguna login.

      • Pengguna dari berbagai kohor mungkin memiliki akses ke berbagai set fitur.

  • Partisi menurut layanan: Konfigurasi setiap layanan, seperti Google Cloud atau Gemini Enterprise, sehingga layanan tersebut memberikan akses secara eksklusif kepada pengguna Workforce Identity Federation atau pengguna Cloud Identity, tetapi tidak pernah keduanya.

    • Keuntungan: Menyederhanakan administrasi dan memastikan set fitur yang konsisten di seluruh pengguna.
    • Kekurangan: Beberapa karyawan mungkin perlu diberi dua identitas—satu yang menggunakan Workforce Identity Federation dan satu yang menggunakan Cloud Identity.

Sebaiknya lakukan partisi menurut layanan, khususnya memisahkan Gemini Enterprise dan NotebookLM Enterprise dari layanan lainnya. Gemini Enterprise dan konsol Google Cloud adalah alat terpisah yang dirancang untuk tugas yang berbeda. Perbedaan dalam proses login mereka akan berdampak minimal pada keseluruhan pengalaman pengguna.

Untuk membantu menerapkan partisi ini, gunakan batasan kebijakan organisasi.

Memperkuat tata kelola grup

Anda harus mengelola akses menggunakan grup dan membuat proses yang jelas untuk mengatur grup tersebut agar dapat menggunakan Workforce Identity Federation secara efektif.

Izin pengguna untuk mengakses resource tidak ditentukan selama autentikasi. Sebagai gantinya, akses dievaluasi saat pengguna mencoba mengakses resource berdasarkan kebijakan yang terlampir pada resource tertentu tersebut. Kebijakan ini dapat mencakup hal berikut:

Kebijakan menentukan akses untuk setiap akun utama atau set akun utama:

  • Entitas: Pengguna yang diautentikasi dan diidentifikasi oleh ID entitas. ID utama tenaga kerja mirip dengan berikut ini: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    ID prinsipal berisi hal berikut:

    • POOL_ID: mengidentifikasi workforce identity pool secara unik.
    • SUBJECT: mengidentifikasi pengguna tertentu secara unik. Nilai dan format bergantung pada IdP dan pemetaan atribut Anda.

  • Set utama: Pengguna yang cocok dengan kriteria tertentu. Workforce Identity Federation mendukung tiga set utama: berbasis grup (anggota grup), berbasis atribut, dan wildcard (semua pengguna).

Memberikan akses ke setiap prinsipal dapat berguna dalam situasi tertentu, tetapi cenderung tidak dapat diskalakan dengan baik karena masalah berikut:

  • Menambahkan akun utama satu per satu menyebabkan kebijakan izin bertambah dan menjadi semakin sulit dikelola.
  • Pengelolaan akses individual memerlukan perubahan yang sering pada kebijakan izin.
  • Kebijakan dapat menjadi semakin tidak konsisten seiring waktu.

Untuk pengelolaan akses yang efektif dan skalabel, penggunaan set principal berbasis grup memberikan keuntungan berikut:

  • Anda dapat mengelola akses dengan menambahkan atau menghapus anggota dari grup, menggunakan alat dan proses identitas yang ada.
  • Kurangi ukuran dan kompleksitas kebijakan izin.
  • Pastikan pengguna dengan peran yang sama memiliki akses resource yang sama.

Untuk menggunakan grup dalam mengelola akses, Anda harus mengonfigurasi IdP eksternal dengan cara tertentu dan mengetahui batasan apa pun yang diterapkan IdP pada grup.

Bagian berikut menjelaskan praktik terbaik untuk menggunakan grup secara efektif dan menghindari batas IdP.

Praktik terbaik:

Membedakan berbagai jenis grup.
Gunakan grup akses untuk memberikan akses ke resource.
Gunakan grup penerapan untuk membatasi akses ke resource.
Jangan gunakan grup organisasi dan kolaborasi untuk mengelola akses.
Gunakan grup organisasi dan grup kolaborasi khusus untuk Gemini Enterprise.

Membedakan berbagai jenis grup

Daftar berikut menjelaskan empat jenis grup yang umum ditemukan di organisasi:

  • Grup akses: Hanya digunakan untuk memberikan akses ke layanan atau Google Cloud resource Google. Grup ini mewakili fungsi pekerjaan dan menyederhanakan penetapan peran yang diperlukan untuk melakukan fungsi pekerjaan ini.
  • Grup organisasi: Grup ini mewakili subset struktur organisasi, dan biasanya bersumber dari data sumber daya manusia. Grup ini dapat didasarkan pada departemen, struktur pelaporan, lokasi geografis, atau pengelompokan organisasi lainnya.
  • Grup kolaborasi: Grup ini mewakili grup kerja, anggota project, atau pengguna yang ingin berkolaborasi dalam project atau mendiskusikan topik tertentu dan dapat digunakan untuk distribusi email. Grup kolaborasi sering dibuat secara ad hoc dan layanan mandiri.
  • Grup penerapan: Grup penerapan, yang juga disebut grup kebijakan, digunakan untuk membatasi akses, berbeda dengan grup akses, yang digunakan untuk memberikan akses. Misalnya, batas akses utama, kebijakan penolakan, atau penerapan autentikasi multi-faktor. Grup akses dapat mengizinkan anggota keluar dari grup secara sukarela. Namun, keanggotaan grup penegakan tidak bersifat sukarela.

Grup yang perlu Anda gabungkan bergantung pada layanan berikut yang Anda gunakan:

  • Untuk Google Cloud, Anda hanya memerlukan grup akses dan grup penerapan.
  • Untuk Gemini Enterprise, Anda memerlukan grup akses, grup penerapan, dan—jika menggunakan konektor berbasis penyerapan data—grup organisasi dan kolaborasi tertentu.

Saat mengonfigurasi Workforce Identity Federation, kecualikan jenis grup yang tidak relevan untuk membantu menghindari batas token dengan IdP Anda. Pendekatan ini membantu Anda mengurangi risiko melampaui batasan yang diberlakukan oleh IdP dan memastikan penggunaan grup yang lebih konsisten.

Memberikan akses ke resource menggunakan grup akses

Untuk mengelola akses secara efektif, sebaiknya gunakan set utama yang dipetakan ke grup akses. Grup akses hanya ada untuk memberikan akses. Grup ini mewakili fungsi pekerjaan dan menyederhanakan pemberian peran yang diperlukan untuk melakukan fungsi tersebut.

Konfigurasi grup akses dengan melakukan hal berikut:

  1. Di IdP Anda, buat grup akses yang mewakili fungsi pekerjaan.
  2. Petakan grup akses ke set akun utama untuk menggunakannya di IAM.
  3. Buat pengikatan kebijakan untuk memberikan akses set utama ke resource yang diperlukan untuk setiap fungsi tugas.
  4. Di IdP eksternal, tambahkan atau hapus pengguna dari grup berdasarkan fungsi pekerjaan mereka.

Gunakan grup akses untuk kebijakan yang memberikan akses, termasuk yang berikut:

  • Kebijakan izin IAM
  • Aturan ingress Kontrol Layanan VPC

Pastikan grup akses cukup terperinci. Misalnya, grup berikut mewakili grup akses efektif:

  • widget-sales-dashboard-readers: memberikan akses baca ke set data BigQuery tertentu dan dasbor terkait.

  • dev-ssh-users: memberikan akses Login OS ke VM Compute Engine di lingkungan pengembangan.

    Sebaliknya, jenis grup berikut umumnya tidak cocok untuk digunakan sebagai grup akses:

    • Grup administrator yang luas seperti cloud-admins sering kali tidak memiliki spesifisitas terkait workload atau lingkungan mana yang berlaku.

    • Grup organisasi seperti australia-fte mewakili grup seperti tim atau menurut lokasi, bukan fungsi pekerjaan.

    • Grup komunikasi seperti security-discuss dirancang untuk milis atau kolaborasi, bukan grup akses.

    Untuk menjaga agar grup akses tetap terperinci, buat serangkaian grup akses baru untuk setiap beban kerja atau project yang Anda aktifkan di Google Cloud. Dengan begitu, Anda dapat menskalakan jumlah grup akses agar sesuai dengan jumlah beban kerja yang Anda jalankan di Google Cloud.

Membatasi akses ke resource menggunakan grup penerapan

Grup penegakan mirip dengan grup akses, tetapi biasanya berbeda dalam hal berikut:

  • Grup ini tidak mengizinkan anggota keluar dari grup secara sukarela.
  • Tidak spesifik untuk workload.

Gunakan grup penerapan untuk kebijakan yang mengurangi akses, termasuk hal berikut:

  • Kebijakan penolakan IAM
  • Batas akses utama
  • Kebijakan organisasi

Contoh grup penegakan mencakup users-in-restricted-locations, fedramp-low, dan mfa-users. Jumlah grup penegakan biasanya kecil dan tidak mungkin memengaruhi total keanggotaan grup pengguna.

Jangan menggunakan grup organisasi dan kolaborasi untuk mengelola akses

Untuk mengelola akses secara efektif, Anda dapat menggunakan grup akses dan grup penerapan alih-alih grup organisasi atau kolaborasi.

Grup organisasi mewakili tim atau subset struktur organisasi dan biasanya bersumber dari data sumber daya manusia. Grup ini tidak cocok untuk mengelola akses ke resource Google Cloud karena alasan berikut:

  • Tanggung jawab dan komposisi tim dapat berubah seiring waktu. Misalnya, sebuah tim dapat menyerahkan workload kepada tim lain, atau dua tim dapat bergabung. Mengelola akses dengan grup organisasi mungkin memerlukan serangkaian perubahan kebijakan selama transisi ini.
  • Anggota grup organisasi jarang memerlukan akses yang identik ke resource. Memberikan akses ke grup organisasi sering kali memberi beberapa anggota lebih banyak akses daripada yang mereka butuhkan.

Grup kolaborasi biasanya dikelola sendiri, sehingga anggota dapat bergabung dengan persetujuan dari anggota lain atau tanpa persetujuan. Penggunaan grup kolaborasi untuk memberikan akses dapat menyebabkan pemberian izin berlebih dan eskalasi hak istimewa.

Untuk mencegah grup kolaborasi dan organisasi digunakan untuk pengelolaan akses, konfigurasi IdP Anda agar mengecualikan keanggotaan grup ini dalam token atau pernyataan yang digunakan untuk Workforce Identity Federation.

Hanya gunakan grup organisasi dan grup kolaborasi untuk Gemini Enterprise

Meskipun grup organisasi dan kolaborasi tidak cocok untuk mengelola akses ke resource, Anda mungkin memerlukannya untuk Gemini Enterprise: Google Cloud

  • Evaluasi ACL: Saat Anda menggunakan konektor berbasis penyerapan data untuk mengintegrasikan Gemini Enterprise dengan Microsoft 365, konektor tersebut mungkin menemukan dokumen dengan daftar kontrol akses (ACL) yang merujuk ke grup organisasi dan kolaborasi. Jika Gemini Enterprise tidak memiliki akses ke keanggotaan pengguna dalam grup ini, Gemini Enterprise mungkin tidak dapat mengevaluasi dengan benar apakah pengguna tersebut berwenang untuk mengakses dokumen tersebut.
  • Berbagi notebook: NotebookLM memungkinkan pengguna berbagi notebook. Mengizinkan pengguna membagikan notebook kepada grup kolaborasi sering kali lebih mudah daripada membatasi berbagi kepada pengguna perorangan.

Untuk memastikan bahwa grup organisasi dan kolaborasi hanya tersedia untuk Gemini Enterprise, Anda dapat mengonfigurasi IdP Anda sebagai berikut:

  • Gunakan SCIM untuk menyediakan grup organisasi dan kolaborasi serta keanggotaannya.
  • Mengecualikan keanggotaan grup kolaborasi dan organisasi dalam token atau pernyataan yang digunakan untuk Workforce Identity Federation.

Mengelola workforce identity pool

Workforce identity pool menentukan namespace untuk ID utama dan berfungsi sebagai penampung untuk konfigurasi federasi Anda. Tidak seperti direktori pengguna, pool tidak menyimpan informasi tentang pengguna atau grup.

Praktik terbaik:

Gunakan satu pool per IdP.
Pilih nama kumpulan yang unik dan bermakna.
Perlakukan kumpulan sebagai resource dengan hak istimewa tinggi.
Pertimbangkan risiko saat memperluas federasi ke partner.

Menggunakan satu pool per IdP

Workforce identity pool adalah resource tingkat organisasi, bukan resource tingkat project. Desain ini mencerminkan bahwa workforce identity pool mengelola autentikasi di seluruh organisasi, bukan project atau beban kerja individual. Google Cloud

Untuk sebagian besar organisasi, jumlah workforce identity pool harus sama dengan jumlah IdP:

  • Jika organisasi Anda menggunakan satu IdP untuk mengelola autentikasi, gunakan satu kumpulan workload identity.
  • Jika organisasi Anda menggunakan beberapa IdP—misalnya, karena akuisisi—gunakan satu kumpulan identitas tenaga kerja per IdP.

Membatasi jumlah workforce identity pool membantu Anda memastikan hal berikut:

  • Anda tidak perlu membuat atau mengubah workforce identity pool saat mengaktivasi workload baru ke Google Cloud.
  • Anda dapat menggunakan IAM untuk mengontrol project dan resource yang dapat diakses oleh pengguna perorangan. Google Cloud

Pilih nama kelompok yang unik dan bermakna

Untuk membuat ID utama unik secara global, identitas tenaga kerja mengenkode nama workforce identity pool ke dalam ID utama. Saat memilih nama untuk workforce identity pool, pertimbangkan batasan berikut:

  • Keunikan: Pilih nama yang unik di seluruh Google Cloud dan belum diklaim oleh organisasi lain.
  • Tidak dapat diubah: Anda tidak dapat mengubah nama workforce identity pool. Pilih nama yang tetap bermakna dari waktu ke waktu, hindari nama inisiatif sementara.
  • Pengalaman pengguna: Bergantung pada konfigurasi login Anda, pengguna mungkin perlu memasukkan nama kumpulan selama login. Pilih nama singkat yang mudah diingat.

Memperlakukan kumpulan sebagai resource dengan hak istimewa tinggi

Kumpulan dan penyedia identitas tenaga kerja menentukan cara pengguna login dan mengontrol cara identitas dan keanggotaan grup diperoleh dari IdP eksternal. Karena komponen ini mengontrol logika autentikasi, komponen ini sangat penting bagi keamanan organisasi Anda. Google Cloud Kompromi pada komponen ini dapat memungkinkan pihak tidak bertanggung jawab melakukan serangan spoofing.

Untuk melakukan serangan spoofing, pihak tidak bertanggung jawab dapat mencoba tindakan berikut:

  • Mengubah pemetaan atribut: Mengubah pemetaan atribut dapat memungkinkan pihak tidak bertanggung jawab mengautentikasi diri sebagai orang lain dan mendapatkan akses istimewa yang tidak sah.
  • Menambahkan penyedia berbahaya: Menambahkan penyedia dapat memungkinkan pihak tidak bertanggung jawab melewati IdP organisasi Anda dan mengautentikasi menggunakan IdP lain yang dikontrolnya.

Penyedia dan kumpulan identitas tenaga kerja adalah resource penting untuk keamanan yang memerlukan perlindungan berikut:

  • Membatasi akses ke pengguna non-federasi: Batasi akses administratif ke sejumlah kecil pengguna Cloud Identity atau Google Workspace, termasuk setidaknya satu pengguna akses darurat.
  • Melindungi pengguna administratif: Mewajibkan verifikasi dua langkah untuk semua pengguna administratif dan pengguna akses darurat.
  • Akses tepat waktu: Gunakan Privileged Access Manager (PAM) untuk memberikan akses administratif tepat waktu, bukan memberikan akses permanen.

Mempertimbangkan risiko saat memperluas federasi ke partner

Penggabungan Google Cloud dengan IdP eksternal menggunakan Workforce Identity Federation akan membuat hubungan tepercaya. Dengan menggunakan penggabungan, Anda mengandalkan IdP eksternal untuk melakukan tindakan berikut:

  • Lakukan autentikasi multi-faktor (MFA) yang memenuhi persyaratan keamanan Anda.
  • Membuat pernyataan yang akurat terkait identitas pengguna dan keanggotaan grup.
  • Ikuti proses tata kelola identitas yang memastikan pengguna dihentikan aksesnya dengan cepat dan keanggotaan grup secara akurat mencerminkan peran saat ini.

Workforce Identity Federation menyediakan mekanisme terbatas untuk memvalidasi pernyataan yang dibuat oleh IdP eksternal. Secara khusus, Workforce Identity Federation tidak mendukung MFA pasca-SSO dengan cara yang sama seperti Cloud Identity.

Sebelum menggunakan Workforce Identity Federation untuk mengizinkan partner atau kontraktor eksternal mengakses Google Cloud resource Anda, tentukan apakah tingkat kepercayaan ini sesuai. Jangan gunakan Workforce Identity Federation untuk akses partner kecuali jika Anda memercayai partner dan IdP mereka untuk secara konsisten memenuhi standar keamanan Anda.

Kelola penyedia workforce identity pool

Penyedia kumpulan identitas tenaga kerja menentukan hubungan federasi dengan IdP eksternal dan berisi konfigurasi untuk hal berikut:

  • IdP yang digunakan untuk single sign-on.
  • Pemetaan atribut yang akan digunakan untuk mendapatkan ID utama dari token atau pernyataan yang disediakan oleh IdP.
  • Opsional: tenant SCIM yang akan digunakan untuk mencari informasi keanggotaan grup.

Praktik terbaik:

Pilih nama penyedia yang bermakna.
Gunakan portal aplikasi IdP Anda untuk mengekspos layanan individual.
Menggunakan satu penyedia per pool untuk menghindari konflik subjek.
Gunakan kumpulan dan penyedia yang sama untuk konsol Google Cloud dan Gemini Enterprise.
Gunakan URI penerbit khusus tenant.
Hindari penggunaan alur implisit OpenID Connect (OIDC).

Pilih nama penyedia yang bermakna

Saat membuat penyedia workforce identity pool, Anda harus menetapkan nama untuknya. Tidak seperti nama workforce identity pool, nama ini tidak harus unik secara global dan tidak dienkode ke dalam ID utama. Namun, bergantung pada konfigurasi login Anda, pengguna mungkin perlu memasukkan nama penyedia saat login. Untuk meningkatkan pengalaman pengguna, pilih nama yang bermakna dan mudah diingat—misalnya, entra atau staff.

Hindari penggunaan nama seperti oidc atau saml, karena akronim ini mungkin tidak dikenal oleh pengguna.

Menampilkan layanan individual di portal aplikasi IdP Anda

Penyedia identitas seperti Microsoft Entra ID dan Okta menyediakan portal aplikasi yang memungkinkan pengguna menemukan dan mengakses aplikasi yang ditetapkan kepada mereka. Gunakan portal untuk mengoptimalkan pengalaman pengguna dengan melakukan hal berikut:

  • Konfigurasi portal untuk menampilkan layanan Google yang relevan satu per satu, bukan menampilkan satu Google Cloud link.
  • Konfigurasi link untuk membuat pengguna login secara otomatis.

Tabel berikut mencantumkan layanan Google umum yang mendukung Workforce Identity Federation dan URL untuk login otomatis:

Aplikasi URL
Google Cloud Konsol Workforce Identity Federation, yang juga dikenal sebagai konsol (gabungan) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
Aplikasi web IAP URL aplikasi, seperti https://iap.example.com/

Ganti kode berikut:

  • POOL: nama workforce identity pool.
  • PROVIDER: nama penyedia pool.
  • WEBAPP_ID: ID aplikasi web Gemini Enterprise.
  • PROJECT_NUMBER: nomor project NotebookLM Enterprise.

Menggunakan satu penyedia per pool untuk menghindari konflik subjek

Anda dapat menggunakan Workforce Identity Federation untuk menambahkan beberapa penyedia ke workforce pool. Menambahkan penyedia kedua berguna selama migrasi saat Anda mengizinkan pengguna untuk mengautentikasi menggunakan IdP yang berbeda untuk sementara. Selain situasi sementara, hindari penggunaan beberapa penyedia karena alasan berikut:

  • Benturan subjek: Menggunakan beberapa penyedia akan menimbulkan risiko benturan subjek. Dalam benturan tersebut, pemetaan atribut google.subject untuk satu penyedia menampilkan nilai yang sama dengan penyedia lain. Konflik ini memetakan beberapa identitas eksternal ke IAM utama yang sama, sehingga identitas eksternal tersebut tidak dapat dibedakan di Cloud Audit Logs.
  • Kompatibilitas IAP: IAP mewajibkan workforce identity pool memiliki satu penyedia untuk mengalihkan pengguna yang tidak diautentikasi ke IdP secara otomatis. Jika Anda menambahkan penyedia tambahan, IAP tidak dapat mengautentikasi pengguna.

Jika Anda perlu melakukan federasi dengan beberapa penyedia, buat beberapa kumpulan tenaga kerja dan konfigurasi satu penyedia untuk setiap kumpulan.

Gunakan kumpulan dan penyedia yang sama untuk Google Cloud console dan Gemini Enterprise

Jika Anda menggunakan Workforce Identity Federation untuk Gemini Enterprise dan Google Cloud, gunakan satu penyedia untuk memastikan pengguna dapat mengakses kedua layanan secara bersamaan tanpa perlu login lagi. Jika Anda menggunakan penyedia terpisah dengan pemetaan atribut yang berbeda, pengguna mungkin mengalami situasi saat akses mereka ke resource berbeda, bergantung pada penyedia yang mereka gunakan untuk login.

Menggunakan URI penerbit khusus tenant

Saat mengonfigurasi penyedia, Anda menentukan URI penerbit untuk mengidentifikasi IdP Anda secara unik. Namun, bergantung pada konfigurasi IdP Anda, URI penerbit mungkin tidak unik untuk tenant organisasi Anda. Misalnya, jika Anda menggunakan URI penerbit generik atau bersama seperti endpoint umum Microsoft Entra ID (https://login.microsoftonline.com/common/v2.0), Anda mungkin secara tidak sengaja mengizinkan pengguna dari organisasi lain untuk mengautentikasi ke organisasi Google CloudAnda.

Untuk membantu mencegah akses lintas tenant yang tidak diinginkan, gunakan URI penerbit khusus tenant. Jika IdP Anda tidak menyediakan URI penerbit khusus tenant, konfigurasi kondisi atribut untuk membatasi akses ke tenant tertentu Anda.

Hindari penggunaan alur implisit OpenID Connect (OIDC)

Saat mengonfigurasi penyedia OIDC, pilih alur kode otorisasi daripada alur implisit. Alur implisit tidak digunakan lagi di spesifikasi OAuth versi 2.1 karena rentan terhadap kebocoran dan injeksi token. Menggunakan alur kode otorisasi membantu mengurangi risiko penyadapan token.

Kelola pengguna

Anda dapat mengelola pengguna menggunakan Workforce Identity Federation. Workforce Identity Federation mendapatkan ID utama pengguna dari token atau pernyataan pengguna dengan melakukan langkah-langkah berikut:

  1. Tentukan ID subjek dengan menerapkan pemetaan atribut untuk google.subject. ID subjek harus mengidentifikasi pengguna secara unik dalam workforce identity pool, tetapi tidak harus unik di seluruh Google Cloud.

  2. Dapatkan ID utama dengan menambahkan ID subjek ke awalan yang mengidentifikasi workforce identity pool. ID prinsipal yang dihasilkan bersifat unik di seluruh Google Cloud dan memiliki format berikut:

    principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
subject/SUBJECT

Saat pengguna yang diautentikasi menggunakan Workforce Identity Federation mengakses resource, IAM menggunakan ID utama untuk mengevaluasi binding peran dalam kebijakan izinkan dan mencatatnya dalam Log Audit Cloud.

Praktik terbaik:

Gunakan ID subjek yang tidak dapat diubah.
Jangan menggunakan kembali ID subjek.
Microsoft Entra ID: menggunakan UPN sebagai ID subjek.

Menggunakan ID subjek yang tidak dapat diubah

Jika ID subjek pengguna berubah, ID pokoknya juga akan berubah. Akibatnya, Google Cloud tidak lagi mengenali mereka sebagai pengguna yang sama:

  • Pengguna tidak dapat mengakses resource yang sebelumnya telah diberi akses karena ID utama barunya tidak lagi cocok dengan ID utama yang tercantum dalam kebijakan izin.
  • Entri Cloud Audit Logs hanya berisi ID akun utama baru dan tidak dapat lagi dikorelasikan dengan log yang menggunakan ID akun utama lama.

Untuk menjaga agar ID utama pengguna tetap stabil, gunakan pemetaan atribut yang menghasilkan nilai stabil untuk google.subject.

Banyak IdP otomatis membuat ID unik berformat numerik atau UUID untuk pengguna. ID ini unik dan stabil, sehingga menjadi kandidat yang baik untuk google.subject. Namun, menggunakan ID ini sebagai google.subject dapat menghasilkan ID utama yang panjang dan sulit dipahami yang mungkin sulit digunakan.

Untuk membantu Anda memilih ID untuk google.subject, pertimbangkan persyaratan berikut dalam urutan prioritas menurun:

  1. Keunikan: nilai secara unik mengidentifikasi pengguna di IdP Anda.
  2. Kegunaan: nilainya bermakna, atau setidaknya dapat ditelusuri dengan mudah di direktori pengguna IdP Anda.
  3. Tidak dapat diubah: nilai tidak dapat diubah, atau setidaknya hanya dapat diubah oleh administrator.

Jangan menggunakan kembali ID subjek

Banyak IdP menerapkan batasan keunikan pada ID pengguna tertentu, tetapi mengizinkan ID digunakan kembali. Misalnya, IdP mungkin tidak mengizinkan Anda membuat dua pengguna dengan nama pengguna bob yang sama. Namun, setelah Anda menghapus akun pengguna bob, IdP mungkin mengizinkan Anda membuat akun pengguna baru dan menetapkan nama pengguna bob yang sama lagi.

Jika pemetaan atribut penyedia Anda untuk google.subject merujuk ke ID pengguna yang memungkinkan penggunaan ulang, Anda mungkin mengalami bentrokan subjek: Workforce Identity Federation tidak dapat membedakan antara pengguna lama dan pengguna baru jika google.subject mereka sama. Akibatnya, pengguna baru mungkin mendapatkan akses ke resource yang hanya ditujukan untuk pengguna lama.

Untuk mencegah tabrakan subjek, lakukan salah satu atau kedua hal berikut:

Microsoft Entra ID: menggunakan UPN sebagai ID subjek

Praktik terbaik ini hanya berlaku jika Anda menggunakan Microsoft Entra ID sebagai IdP.

Jika Anda menggunakan Microsoft Entra ID, ID yang dapat Anda gunakan sebagai ID subjek mencakup yang berikut:

  • Nama utama pengguna (upn)
  • ID Objek (oid)
  • Alamat email (alamat utama di proxyAddresses)

Di antara opsi ini, sebaiknya gunakan nama pokok pengguna sebagai ID subjek karena alasan berikut:

  • Semua pengguna memiliki nama utama pengguna.
  • Nama akun utama pengguna mengidentifikasi pengguna secara unik.
  • Nama akun utama pengguna cenderung bermakna dan mudah digunakan.
  • Nama prinsipal pengguna menyematkan nama domain, yang secara unik mengidentifikasi tenant Microsoft Entra ID yang terkait dengan pengguna.
  • Organisasi Anda mungkin memiliki kebijakan yang melarang atau mengatur penggunaan kembali ID utama pengguna.

Sebaliknya, ID Objek dan alamat email pengguna kurang cocok karena alasan berikut:

  • ID Objek (oid) tidak dapat diubah, tetapi diformat sebagai GUID. Format ini menyulitkan penggunaannya dan tidak bermakna bagi manusia.
  • Alamat email bukan atribut wajib, dan mungkin tidak diisi untuk semua pengguna.

Terlepas dari ID yang Anda pilih, sebaiknya hindari penerapan transformasi seperti mengubah ID menjadi huruf kecil.

Kelola grup

Workforce Identity Federation dapat menentukan keanggotaan grup pengguna dari sumber berikut:

  • Pernyataan SAML atau token ID yang diberikan oleh IdP.
  • Microsoft Graph API, jika Anda menggunakan Microsoft Entra ID sebagai IdP.
  • Tenant SCIM yang terkait dengan penyedia workforce identity pool.

Secara default, Workforce Identity Federation hanya menggunakan pernyataan SAML atau token ID:

Sumber Google Cloud Gemini Enterprise
Token SAML atau ID
Microsoft Graph API - -
Tenant SCIM - -

Jika Anda menggunakan Microsoft Entra ID sebagai IdP, Anda dapat mengaktifkan fitur atribut tambahan. Kemudian, Workforce Identity Federation hanya menggunakan Microsoft Graph API sebagai sumber untuk keanggotaan grup:

Sumber Google Cloud Gemini Enterprise
Token SAML atau ID - -
Microsoft Graph API
Tenant SCIM - -

Jika Anda menggunakan Gemini Enterprise, Anda dapat mengonfigurasi Workforce Identity Federation untuk menggunakan tenant SCIM, yang mengubah perilaku sebagai berikut:

  • Gemini Enterprise menggunakan keanggotaan grup dari tenant SCIM dan mengabaikan informasi keanggotaan grup dari pernyataan SAML atau token ID.
  • Google Cloud menggunakan informasi keanggotaan grup dari pernyataan SAML atau token ID dan mengabaikan informasi keanggotaan grup dari tenant SCIM.
Sumber Google Cloud Gemini Enterprise
Token SAML atau ID -
Microsoft Graph API - -
Tenant SCIM -

Untuk setiap keanggotaan grup, Workforce Identity Federation mendapatkan ID principal dengan melakukan langkah-langkah berikut:

  1. Tentukan ID grup dengan melakukan salah satu tindakan berikut:
    • Pernyataan SAML atau token ID: Terapkan pemetaan atribut untuk google.groups.
    • Tenant SCIM: Terapkan pemetaan klaim untuk google.group.
    • Microsoft Graph API: Ikuti extra-attributes-type dalam konfigurasi penyedia.

  2. Dapatkan ID prinsipal dengan menambahkan ID grup ke awalan yang mengidentifikasi workforce identity pool. ID prinsipal yang dihasilkan bersifat unik di seluruh Google Cloud dan memiliki format berikut:

    principalSet://iam.googleapis.com/locations/global/workforcePools/\
POOL_ID/group/GROUP_ID

Saat pengguna yang melakukan autentikasi menggunakan Workforce Identity Federation mengakses resource, IAM menggunakan ID akun utama ini untuk mengevaluasi binding peran dalam kebijakan izin.

Praktik terbaik:

Gunakan ID grup yang tidak dapat diubah.
Mengurangi keanggotaan grup dalam pernyataan atau token.
Microsoft Entra ID: gunakan ID Objek sebagai ID grup.

Menggunakan ID grup yang tidak dapat diubah

Semua kebijakan IAM mereferensikan grup berdasarkan ID akun utamanya. Jika Anda mengganti nama grup di IdP sehingga ID-nya berubah, Google Cloud tidak lagi mengenalinya sebagai grup yang sama:

  • Binding peran IAM yang ada akan terus merujuk ke ID akun utama lama dan menjadi tidak efektif.
  • Anggota grup yang diganti namanya akan kehilangan akses karena ID prinsipal baru grup tidak lagi cocok dengan binding peran IAM mana pun.

Untuk mencegah gangguan ini, konfigurasikan pemetaan atribut dan klaim Anda untuk menggunakan nilai yang stabil dan tidak dapat diubah, seperti ID unik yang dihasilkan IdP. Hindari penggunaan nama tampilan atau alamat email sebagai ID grup, karena ID ini dapat berubah selama perubahan organisasi.

Mengurangi keanggotaan grup dalam pernyataan atau token

Secara default, IdP Anda mungkin menyertakan lebih banyak keanggotaan grup dalam pernyataan SAML atau token ID daripada yang Anda butuhkan untuk mengelola akses ke Gemini Enterprise dan Google Cloud resource. Menyertakan keanggotaan grup yang tidak diperlukan menimbulkan beberapa risiko:

  • Kehilangan akses sebagian: Banyak IdP memberlakukan batasan pada jumlah keanggotaan grup yang dapat mereka sertakan dalam token atau pernyataan. Jika pengguna melampaui batas ini (kelebihan grup), IdP dapat menghapus beberapa keanggotaan grup, sehingga pengguna kehilangan akses ke resource tertentu.
  • Kegagalan login: Workforce Identity Federation membatasi ukuran dan jumlah keanggotaan grup yang dapat dihasilkan oleh pemetaan atribut google.groups. Pengguna yang melampaui salah satu batas ini tidak dapat login.
  • Penggunaan grup yang tidak konsisten: Jika Anda mengekspos grup ke Google Cloud, pemilik project dapat memutuskan untuk menggunakan grup tersebut guna mengelola akses ke resource, meskipun Anda tidak pernah bermaksud agar grup tertentu digunakan di Google Cloud.

Pendekatan berikut dapat membantu Anda mengurangi risiko ini dan mengurangi jumlah keanggotaan grup dalam pernyataan atau token:

  • Memfilter menurut jenis grup: Beberapa IdP, termasuk Microsoft Entra ID, memungkinkan Anda mengonfigurasi filter yang menentukan grup mana yang akan disertakan dalam pernyataan atau token. Anda dapat mengonfigurasi filter untuk mengecualikan jenis grup yang tidak relevan berdasarkan konfigurasi Anda dan layanan yang akan Anda gunakan.

    Tabel berikut menunjukkan jenis grup yang mungkin perlu Anda sertakan dalam pernyataan atau token, bergantung pada layanan yang akan Anda gunakan:

    Jenis Grup Google Cloud Gemini (Tanpa Sinkronisasi) Gemini (SCIM)
    Grup akses -
    Grup penerapan -
    Grup organisasi Tidak diperlukan * -
    Grup kolaborasi Tidak diperlukan * -

    * Hanya diperlukan jika menggunakan konektor berbasis penyerapan data.

    • Untuk mengelola akses ke Google Cloud, Anda harus menyertakan grup akses dan grup penerapan.
    • Filter yang diperlukan untuk mengelola akses ke Gemini Enterprise bergantung pada apakah Anda menggunakan SCIM. Jika Anda menggunakan SCIM, Gemini Enterprise mengabaikan keanggotaan grup yang disertakan dalam pernyataan atau token, sehingga Anda tidak perlu menyertakan grup apa pun yang khusus untuk Gemini Enterprise. Jika Anda tidak menggunakan SCIM, Anda harus menyertakan grup akses dan grup penegakan yang diperlukan untuk Gemini Enterprise. Bergantung pada apakah Anda berencana menggunakan konektor berbasis penyerapan data, Anda mungkin juga perlu menyertakan grup kolaborasi dan organisasi tertentu.

  • Penetapan: Beberapa IdP, termasuk Microsoft Entra ID, memungkinkan Anda membatasi keanggotaan grup dalam token dan pernyataan ke grup yang ditetapkan, yaitu grup yang Anda tetapkan secara eksplisit ke konfigurasi pihak tepercaya.

  • Filter atribut tambahan: Jika Anda menggunakan Microsoft Entra ID dan telah mengaktifkan fitur atribut tambahan, Anda dapat menentukan filter menggunakan tanda --extra-attributes-filter. Workforce Identity Federation meneruskan filter ini ke Microsoft Graph API saat meminta keanggotaan grup.

Untuk menguji atau memecahkan masalah filter, gunakan alat Debug token IdP di konsol Google Cloud atau aktifkan pencatatan audit mendetail.

Microsoft Entra ID: menggunakan ID Objek sebagai ID grup

Praktik terbaik ini hanya berlaku jika Anda menggunakan Microsoft Entra ID sebagai IdP.

Jika Anda menggunakan Microsoft Entra ID, ID yang dapat Anda gunakan sebagai ID grup mencakup yang berikut:

  • ID Objek (oid)
  • Alamat email
  • Nama tampilan

Di antara opsi ini, sebaiknya gunakan ID Objek (oid) sebagai ID kelompok karena alasan berikut:

  • Semua grup memiliki ID Objek. Sebaliknya, alamat email adalah kolom opsional yang mungkin diisi hanya untuk grup Microsoft 365.
  • ID Objek bersifat unik dan tidak dapat diubah. Sebaliknya, nama tampilan grup dapat berubah dan mungkin tidak unik.

Terlepas dari ID yang Anda pilih, sebaiknya hindari penerapan transformasi seperti memaksa ID menjadi huruf kecil.

Kelola akses

Praktik terbaik untuk batas akses dan pengelolaan just-in-time (JIT).

Praktik terbaik:

Menggunakan pengguna Cloud Identity untuk akses darurat.
Gunakan Cloud Identity untuk akses dengan hak istimewa tinggi.
Gunakan batasan kebijakan organisasi untuk mengatur federasi.
Jangan berikan akses ke semua anggota kumpulan.
Membatasi durasi sesi.
Menyelaraskan durasi sesi dengan persyaratan akses JIT.

Menggunakan pengguna Cloud Identity untuk akses darurat

Untuk membantu memastikan akses berkelanjutan ke lingkungan Google Cloud Anda, buat pengguna akses darurat untuk setiap lingkungan.

Pengguna akses darurat memberikan akses ke lingkungan Google Cloud Anda jika layanan salah dikonfigurasi, disusupi, atau tidak beroperasi secara normal. Pengguna akses darurat memiliki hak istimewa yang tinggi. Mengandalkan Workforce Identity Federation untuk mengautentikasi pengguna akses darurat menimbulkan risiko berikut:

  • Kesalahan dalam konfigurasi penyedia workforce identity pool dapat menyebabkan Anda terkunci.
  • Gangguan layanan yang memengaruhi IdP eksternal dapat mencegah Anda menggunakan pengguna akses darurat saat Anda sangat membutuhkannya.
  • Jika IdP eksternal disusupi, pihak tidak bertanggung jawab dapat mengautentikasi diri sebagai pengguna akses darurat dan mendapatkan akses luas ke resource Anda. Google Cloud

Untuk mengurangi risiko ini, gunakan Cloud Identity atau Google Workspace untuk pengguna akses darurat, meskipun Anda menggunakan Workforce Identity Federation untuk pengguna lain:

  • Buat pengguna akses darurat di Cloud Identity.
  • Mengecualikan pengguna ini dari single sign-on dan mengizinkan mereka melakukan autentikasi menggunakan nama pengguna dan sandi.
  • Amankan pengguna ini dengan mendaftarkan mereka ke verifikasi dua langkah dengan kunci keamanan.

Untuk mengetahui informasi selengkapnya tentang pengguna akses darurat, lihat Praktik terbaik untuk akses berkelanjutan ke Google Cloud.

Menggunakan Cloud Identity untuk akses dengan hak istimewa tinggi

Pengguna dengan hak istimewa tinggi memiliki akses luas ke lingkungan Google Cloud Anda. Contoh pengguna ini meliputi:

  • Pengguna dengan peran Organization Administrator (roles/resourcemanager.organizationAdmin)
  • Pengguna dengan peran Admin Keamanan (roles/iam.securityAdmin) atau peran serupa yang dapat mengubah kebijakan izinkan di berbagai bagian penting hierarki resource Google Cloud Anda

Jika Anda menggunakan Workforce Identity Federation untuk pengguna dengan hak istimewa tinggi, setiap kesalahan konfigurasi atau kompromi di IdP eksternal Anda dapat memengaruhi keamanan resource Anda. Google Cloud Khususnya, jika IdP eksternal disusupi, pihak tidak bertanggung jawab dapat mengautentikasi diri sebagai pengguna dengan hak istimewa tinggi dan mendapatkan akses luas ke resource Google Cloud Anda.

Untuk mengurangi risiko ini, gunakan Cloud Identity untuk pengguna dengan hak istimewa tinggi:

  • Buat pengguna dengan hak istimewa tinggi di Cloud Identity.
  • Amankan pengguna ini dengan mendaftarkan mereka ke verifikasi dua langkah dengan kunci keamanan.
  • Jika Anda telah memfederasikan Cloud Identity dengan IdP eksternal, aktifkan verifikasi SSO tambahan dan verifikasi dua langkah untuk pengguna ini.

Verifikasi SSO tambahan mungkin tampak berlebihan jika IdP Anda sudah menerapkan autentikasi multi-faktor, tetapi setelan ini membantu melindungi pengguna jika IdP disusupi. Verifikasi SSO tambahan adalah fitur yang didukung oleh Cloud Identity, tetapi tidak tersedia untuk Workforce Identity Federation.

Menggunakan batasan kebijakan organisasi untuk mengatur federasi

Jika Anda menggunakan Cloud Identity untuk tujuan selain akses darurat atau akses dengan hak istimewa tinggi, partisikan penggunaan Cloud Identity Federation dan Workforce Identity Federation Anda menurut layanan. Untuk menerapkan praktik ini, gunakan batasan kebijakan organisasi kustom untuk membatasi jenis akun utama yang diizinkan dalam project tertentu.

Misalnya, Anda dapat membatasi Workforce Identity Federation ke Gemini Enterprise dengan melakukan hal berikut:

  • Terapkan batasan kebijakan organisasi kustom ke project Gemini Enterprise Anda yang menggunakan fungsi MemberTypeMatches untuk membatasi jenis utama yang diizinkan menjadi iam.googleapis.com/WorkforcePoolPrincipal dan iam.googleapis.com/WorkforcePoolPrincipalSet. Berikut adalah jenis utama yang digunakan oleh Workforce Identity Federation.
  • Untuk semua project lainnya, terapkan batasan yang mengizinkan semua jenis akun utama, kecuali iam.googleapis.com/WorkforcePoolPrincipal dan iam.googleapis.com/WorkforcePoolPrincipalSet.

Menggunakan batasan kebijakan organisasi kustom membantu Anda memastikan konsistensi dan membantu mencegah penggunaan jenis pokok yang salah secara tidak sengaja.

Jangan berikan akses ke semua anggota kumpulan

Workforce Identity Federation mendukung ID prinsipal wildcard yang menggunakan format berikut:

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

ID ini cocok dengan setiap pengguna yang diizinkan IdP Anda untuk mengautentikasi ke Google Cloud.

Jangan gunakan ID karakter pengganti ini untuk memberikan izin. Seiring bertambahnya basis pengguna IdP Anda, pemberian akses dengan ID utama karakter pengganti akan menyebabkan pemberian izin berlebih.

Sebagai gantinya, buat grup akses di IdP Anda dan gunakan grup ini untuk mengelola akses ke resource. Pendekatan ini membantu memastikan bahwa akses diatur oleh keanggotaan grup yang disengaja, bukan autentikasi yang berhasil, sehingga mengurangi risiko pemberian izin berlebih.

Membatasi durasi sesi

Saat pengguna login, Workforce Identity Federation akan memulai sesi. Sesi ini memungkinkan pengguna melakukan hal berikut:

  • Gunakan dan navigasikan antara konsol (gabungan), Gemini Enterprise, atau portal lain yang mendukung Workforce Identity Federation.
  • Gunakan aplikasi web yang dilindungi IAP.
  • Dapatkan token refresh federasi dan token akses federasi—misalnya, dengan menjalankan gcloud auth login.

Sesi tetap valid hingga salah satu hal berikut terjadi:

  • Durasi sesi mencapai batas yang ditentukan oleh workforce identity pool.
  • Durasi sesi mencapai batas yang ditentukan dalam atribut SessionNotOnOrAfter di pernyataan SAML pengguna, jika ada.
  • Pengguna logout.

Mengizinkan sesi tetap valid dalam jangka waktu yang lebih lama meningkatkan risiko pencurian token dan dapat menyebabkan informasi keanggotaan grup menjadi tidak berlaku:

  • Pengguna mungkin mempertahankan akses lebih lama dari yang dimaksudkan jika izin dicabut di IdP.
  • Pengguna mungkin tidak dapat menggunakan akses yang baru diberikan hingga mereka melakukan autentikasi ulang dan membuat sesi baru.

Untuk mengurangi risiko ini, batasi durasi sesi sehingga pengguna harus login lagi setidaknya sekali sehari.

Menyelaraskan durasi sesi dengan persyaratan akses JIT

Untuk mengelola akses istimewa, IdP Anda mungkin mendukung grup just-in-time (JIT) yang dapat diaktifkan sementara oleh anggota. Menggunakan grup tepat waktu untuk mengelola akses istimewa ke Google Cloud atau Gemini Enterprise dapat menimbulkan risiko berikut:

  • Aktivasi tertunda: Jika pengguna memiliki sesi Workforce Identity Federation yang aktif saat mengaktifkan keanggotaan grup just-in-time, perubahan keanggotaan tidak akan berlaku hingga pengguna logout dan login kembali. Atau, jika penyedia kumpulan identitas tenaga kerja menggunakan SCIM, perubahan keanggotaan tidak akan berlaku hingga perubahan keanggotaan grup disediakan.
  • Pencabutan yang ditunda: Jika masa berlaku keanggotaan grup berakhir, pengguna tidak akan kehilangan akses istimewa hingga mereka logout dan login kembali atau perubahan keanggotaan grup disediakan menggunakan SCIM. Bergantung pada durasi sesi Anda, penundaan ini dapat mengurangi tujuan masa berlaku langganan.

Untuk mengurangi risiko ini, konfigurasikan durasi sesi workforce identity pool Anda agar cukup singkat.

Memantau aktivitas

Setiap kali Anda melihat aktivitas mencurigakan yang memengaruhi resource di Google Cloud, Cloud Audit Logs memberikan informasi penting untuk menentukan kapan aktivitas tersebut terjadi dan pengguna mana yang terlibat.

Mengaktifkan log akses data

Workforce Identity Federation dapat membuat log yang memungkinkan Anda melacak aktivitas penukaran token dan login. Security Token Service API menulis log ini, yang mencakup metode berikut:

  • google.identity.sts.SecurityTokenService.WebSignIn
  • google.identity.sts.SecurityTokenService.WebSignOut
  • google.identity.sts.v1.SecurityTokenService.ExchangeToken
  • google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

Semua log yang terkait dengan aktivitas login dan pertukaran token diklasifikasikan sebagai log akses data dan dinonaktifkan secara default. Untuk merekam log ini, aktifkan log akses data untuk Security Token Service API di seluruh Google Cloud organisasi Anda. Untuk meningkatkan detail log login lebih lanjut, aktifkan logging audit mendetail.

Untuk melacak aktivitas terkait autentikasi lainnya, sebaiknya aktifkan dan gunakan log berikut:

Langkah berikutnya