Mengautentikasi pengguna tenaga kerja di lingkungan hybrid

Last reviewed 2024-06-26 UTC

Dokumen ini adalah bagian pertama dari beberapa seri yang membahas cara memperluas solusi pengelolaan identitas Anda ke Google Cloud guna memungkinkan tenaga kerja Anda untuk mengautentikasi dan menggunakan layanan di lingkungan komputasi hybrid.

Rangkaian ini terdiri dari bagian-bagian berikut:

Pengantar

Mengelola akun pengguna dan mengontrol akses karyawan ke aplikasi serta resource komputasi adalah tanggung jawab utama departemen IT perusahaan. Demi memastikan konsistensi dan efisiensi administratif, sebagian besar perusahaan menganggap manajemen identitas sebagai fungsi terpusat dan memanfaatkan sistem terpadu untuk mengelola identitas. Umumnya, perusahaan mengandalkan Microsoft Active Directory Domain Services (AD DS) untuk tujuan ini.

Saat Anda memperluas lanskap IT ke Google Cloud sebagai bagian dari strategi hybrid, Anda ingin mempertahankan titik tunggal tempat identitas dikelola. Sistem manajemen identitas terpadu meminimalkan upaya administratif dalam mengelola akun dan mengontrol akses. Sistem ini juga membantu memastikan bahwa pengguna dan aplikasi dapat melakukan autentikasi dengan aman di seluruh lingkungan hybrid.

Dokumen ini membahas cara mengintegrasikan Google Cloud dengan sistem manajemen identitas Anda. Dokumen ini membantu Anda memilih pendekatan yang paling sesuai dengan persyaratan Anda.

Meskipun sebagian besar pembahasan juga berlaku untuk Google Workspace, dokumen ini hanya berfokus pada Cloud Identity.

Menilai persyaratan untuk pengelolaan identitas hybrid

Cara terbaik untuk memperluas sistem pengelolaan Identitas Anda ke Google Cloud itu semua tergantung pada beberapa faktor:

  • Kumpulan identitas di dalam organisasi Anda
  • Penyedia identitas terbiasa memberikan layanan autentikasi bagi para identitas tenaga kerja Anda
  • Resource dan permohonan yang Anda inginkan agar dapat diakses oleh pengguna di Google Cloud
  • Kebutuhan kelangsungan bisnis Anda

Bagian berikutnya membahas masing-masing faktor tersebut.

Identitas:

Faktor utama yang harus diperhatikan saat mengintegrasikan Google Cloud dengan sistem manajemen identitas yang merupakan cara bagi Anda untuk mengelola dan membedakan antar jenis identitas. Sebagian besar organisasi menggunakan jenis identitas berikut:

  1. Identitas tenaga kerja adalah identitas yang Anda kelola bagi karyawan organisasi Anda. Identitas ini digunakan untuk login ke workstation, mengakses email, atau menggunakan aplikasi perusahaan.
  2. Identitas eksternal adalah identitas yang Anda kelola bagi nonkaryawan seperti kontraktor atau partner yang perlu diberi akses ke resource perusahaan.
  3. Identitas tamu merupakan identitas yang dikeola oleh pihak lain seperti pelanggan atau partner yang membutuhkan akses ke resource perusahaan.
  4. Identitas pelanggan merupakan identitas yang Anda kelola untuk pengguna untuk berinteraksi dengan situs web atau aplikasi yang berhubungan dengan pelanggan Anda.
  5. Identitas beban kerja merupakan identitas yang Anda kelola untuk memungkinkan aplikasi berinteraksi dengan aplikasi lain atau platform yang mendasarinya.

Seringkali, identitas tenaga kerja membentuk satu identity pool yang masing-masing karyawan memiliki satu identitas dan semua identitas dikelola dengan cara yang sama, menggunakan sistem yang sama. Namun, seharusnya hal ini tidak menjadi masalah—sebagai akibat dari merger atau akuisisi, misalnya, Anda mungkin memiliki beberapa pool identitas tenaga kerja yang masing-masing dikelola dengan cara yang tidak sama dan menggunakan sistem yang berbeda. Secara teknis, ini berarti Anda mungkin harus mengintegrasikan beberapa sumber LDAP, forest Active Directory, atau Azure AD tenant dengan Google Cloud.

Mengintegrasikan beberapa pool menambah kompleksitas integrasi dengan Google Cloud. Oleh karena itu, Anda harus mengevaluasi:

  • Apakah semua pool identitas membutuhkan akses ke Google Cloud atau hanya subset tertentu?
  • Apakah semua pool identitas memiliki akses ke organisasi di Google Cloud yang sama, masing-masing pool identitas ke organisasi yang berbeda?
  • Apakah ada opsi untuk mengurangi jumlah pool, misalnya, dengan cara membuat kepercayaan lintas forest antar forest Active Directory?

Identitas eksternal seringkali dianggap mirip dengan identitas tenaga kerja, dengan pengecualian berikut:

  • Akun mereka mungkin valid hanya selama waktu yang terbatas.
  • Identitas tersebut mungkin secara default diberikan hak lebih sedikit.
  • Identitas tersebut mungkin dikelola oleh direktori LDAP terpisah, forest Active Directory, atau tenant Azure AD.

Tidak seperti identitas eksternal, identitas tamu tidak Anda kelola melainkan dikelola oleh pihak lain. Dalam aplikasi SaaS seperti Google Workspace, identitas tamu dapat menghilangkan kebutuhan mempertahankan identitas eksternal bagi para pelanggan atau partner. Anda akan jarang menemui identitas tamu dalam lingkungan lokal.

Dokumen ini berfokus pada identitas tenaga kerja dan identitas eksternal.

Jika Anda pernah menggunakan layanan seperti Google Ads, beberapa karyawan Anda mungkin sudah memiliki Akun Google yang tidak terhubung dengan identitas tenaga kerja mereka, yang artinya, mereka memiliki dua identitas. Jika demikian, pertimbangkan untuk mengonsolidasikan identitas ini.

Penyedia identitas

Faktor kedua yang harus diperhatikan adalah penyedia identitas Anda. Suatu penyedia identitas (IdP) adalah suatu sistem yang menyediakan layanan autentikasi untuk beban kerja Anda dan pada akhirnya menentukan apakah pengguna akan diautentikasi atau tidak.

Selain menyediakan layanan autentikasi, IdP juga sering kali mengelola siklus proses identitas. Namun, hal ini bukan merupakan suatu keharusan, karena identitas mungkin juga disediakan dari sistem sumber daya manusia yang terpisah.

Penyedia identitas umum meliputi:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Penyedia IDaaS seperti ForgeRock, Okta, atau Ping Identity
  • Direktori LDAP lainnya, meliputi Layanan Active Directory Lighweight Directory (AD LDS)

Anda mungkin menggunakan beberapa sistem, bukan hanya menggunakan satu sistem—untuk mengelola berbagai pool pengguna, untuk menangani akun eksternal, atau untuk menyediakan layanan autentikasi yang berbeda untuk pool pengguna yang sama. Contoh tempat beberapa IdP digunakan untuk mengelola pool yang sama meliputi:

  • Active Directory yang digabungkan dengan Azure AD
  • Active Directory yang digabungkan dengan penyedia IDaaS seperti ForgeRock, Okta, atau Ping Identity
  • Active Directory dengan replika AD LDS

Untuk menggunakan IdP di Google Cloud, Anda dapat mengikuti dua pendekatan dasar:

  • Menggabungkan penyedia identitas Anda dengan Cloud Identity: Dengan melakukan penggabungan dengan Cloud Identity, Anda memungkinkan Google menjadi IdP tambahan yang dapat digunakan oleh tenaga kerja Anda dan yang dapat diandalkan oleh aplikasi yang di-deploy di Google Cloud. Daripada mempertahankan identitas Google untuk setiap pengguna Anda, Anda dapat mengandalkan hubungan penggabungan untuk mempertahankan identitas secara otomatis. Hubungan ini juga membantu memastikan apakah IdP Anda tetap menjadi sumber tepercaya.
  • Memperluas penyedia identitas Anda ke Google Cloud: Anda dapat memungkinkan aplikasi yang di-deploy di Google Cloud untuk menggunakan kembali IdP Anda—dengan menghubungkannya ke IdP secara langsung atau dengan mempertahankan replika IdP Anda di Google Cloud.

Bergantung pada faktor pengelolaan identitas lainnya, Anda mungkin perlu menggabungkan kedua pendekatan tersebut untuk mendukung skenario penggunaan hybrid Anda.

Resource

Faktor ketiga yang perlu diperhatikan adalah referensi Google Cloud yang akan Anda beri akses kepada pengguna tenaga kerja. Faktor ini mencakup Google Cloud sendiri, Anda harus mengizinkan tim yang bertanggung jawab untuk mengelola Google Cloud dengan menggunakan konsol Google Cloud, gcloud CLI, atau API.

Referensi lainnya mungkin meliputi:

Referensi ini bervariasi dalam hal apakah referensi tersebut harus, dapat, atau tidak dapat menggunakan Google sebagai penyedia identitas. Bagian berikut akan membahas ketiga kasus tersebut.

Referensi yang harus menggunakan Google sebagai IdP

Referensi yang harus menggunakan GOogle sebagai IdP mencakup konsol Google Cloud, gcloud CLI, aplikasi yang dilindungi dengan IAP, dan alat serta layanan Google lainnya. Untuk memberikan akses kepada pengguna tenaga kerja Anda ke referensi ini, Anda harus menyediakan identitas Google untuk masing-masing pengguna.

Mempertahankan identitas Google yang terpisah bertentangan dengan gagasan pengelolaan identitas terpadu. Jadi dengan memberikan akses ke salah satu dari referensi tersebut akan mengharuskan Anda untuk menggabungkan IdP Anda dengan Google Cloud.

Setelah Anda menggabungkan IdP Anda dengan Google Cloud, pertimbangkan untuk menggunakan Google sebagai IdP untuk mendapatkan lebih banyak referensi, meliputi aplikasi yang mungkin menggunakan cara lain untuk mengautentikasi pengguna.

Referensi yang dapat menggunakan Google sebagai IdP

Referensi yang dapat menggunakan Google sebagai IdP, tetapi saat ini tidak menggunakan Google sebagai IdP, mencakup:

  • Aplikasi baru, yang ditujukan untuk pengguna tenaga kerja, yang ingin Anda deploy di Google Cloud.
  • Aplikasi lama, yang ditujukan untuk pengguna tenaga kerja, yang ingin Anda lift-and-shift atau move and improve ke Google Cloud.

Apakah aplikasi ini dapat menggunakan Google sebagai IdP atau tidak bergantung pada protokol yang Anda gunakan untuk autentikasi dan otorisasi.

Protokol single sign-on web

Google mendukung beberapa protokol standar industri untuk menangani autentikasi, otorisasi, dan single sign-on. Protokol yang didukung meliputi:

  • OAuth 2.0, yang digunakan untuk klien seluler, klien fat, dan aplikasi non-browser lainnya.
  • OpenID Connect 1.0 (OIDC), yang digunakan untuk aplikasi berbasis browser.
  • SAML 2.0, yang digunakan untuk mengintegrasikan aplikasi pihak ketiga.

Untuk aplikasi yang akan dikembangkan, OAuth 2.0 atau OIDC sebaiknya menjadi pilihan Anda. Protokol ini digunakan secara luas, dan Anda dapat memanfaatkan banyak library dan alat yang telah teruji dengan baik. Selain itu, mengandalkan protokol tersebut berarti Anda dapat secara opsional menggunakan Google sebagai IdP sekaligus tetap dapat fleksibel untuk beralih penyedia identitas sesuai kebutuhan.

Jika Anda memiliki aplikasi yang menggunakan SAML, OAuth 2.0, atau OIDC, beralih ke Google sebagai penyedia identitas dapat dilakukan hanya dengan sedikit mengubah atau bahkan tanpa mengubah kode.

LDAP

Salah satu protokol yang paling serbaguna dan diandalkan untuk autentikasi dan otorisasi adalah Lightweight Directory Access Protocol (LDAP). Ada beberapa cara agar suatu aplikasi dapat menggunakan LDAP untuk autentikasi dan otorisasi. Dua skenario yang paling umum antara lain:

  1. Menggunakan LDAP untuk autentikasi dan membuat kueri informasi pengguna: Dalam skenario ini, aplikasi tidak menggunakan single sign-on. Sebagai gantinya, sistem akan menampikan formulir masuk yang meminta nama pengguna dan kata sandi, kemudian menggunakan kredensial yang diberikan untuk mencoba operasi bind LDAP. Jika percobaan berhasil, kredensial akan dianggap valid. Selain itu, informasi lebih lanjut mengenai pengguna seperti nama dan keanggotaan grup mungkin mungkin akan dikueri dari direktori dan digunakan untuk melakukan otorisasi akses.

  2. Menggunakan SAML untuk autentikasi dan LDAP untuk membuat kueri informasi pengguna: Dalam skenario ini, aplikasi mengautentikasi pengguna dengan menggunakan protokol single sign-on, aplikasi sering kali menggunakan SAML untuk keperluan ini. Setelah pengguna telah diautentikasi, aplikasi menggunakan server LDAP untuk membuat kueri informasi tambahan mengenai pengguna seperti nama dan keanggotaan grup.

Perbedaan utama di antara kedua skenario tersebut adalah skenario pertama mengharuskan aplikasi dan server LDAP memiliki akses ke kata sandi pengguna untuk memverifikasi kredensial. Sedangkan dalam skenario kedua, aplikasi dan server tidak memerlukan akses ke kata sandi pengguna, aplikasi dapat menjalankan kueri LDAP menggunakan pengguna layanan khusus.

Menggunakan LDAP Aman, Anda dapat mengakses informasi pengguna dan grup di Cloud Identity dengan menggunakan protokol LDAP. Jika Google merupakan IdP utama Anda, LDAP Aman memungkinkan Anda untuk mendukung kedua skenario tersebut. Namun, apabila Anda mengintegrasikan Cloud Identity dengan IdP eksternal, Cloud Identity tidak akan mempertahankan salinan kata sandi pengguna. Sehingga, hanya skenario kedua yang dapat dijalankan menggunakan LDAP Aman.

Kerberos dan NTLM

Jika Anda berencana untuk memigrasikan beban kerja berbasis Windows ke Google Cloud, beberapa aplikasi ini mungkin mengandalkan Integrated Windows Authentication (IWA) daripada menggunakan protokol standar. IWA adalah pilihan umum bagi aplikasi berbasis ASP.NET yang berjalan di Microsoft IIS. IWA populer karena memungkinkan pengalaman single sign-on untuk para pengguna yang telah login ke workstation Windows mereka menggunakan kredensial domain.

IWA bergantung pada NTLM atau Kerberos. IWA mengharuskan antara workstation pengguna dengan server tempat aplikasi dijalankan digabungkan ke dalam domain Active Directory atau untuk mempercayai domain.

Salah satu konsekuensi dari mengandalkan NTLM dan Kerberos adalah suatu aplikasi yang menggunakan IWA tidak dapat menggunakan Google sebagai IdP. Namun, Anda mungkin masih dapat memfaktorkan ulang aplikasi untuk menggunakan OIDC. OIDC tidak mengahruskan workstation pengguna atau server agar tergabung dalam domain. Jadi, pemfaktoran ulang kemungkinan dapat menyederhanakan deployment dan membantu Anda mengupayakan opsi deployment alternatif.

Dengan mempertimbangkan pengalaman single sign-on bebas hambatan yang diberikan oleh IWA, menggunakan OIDC daripada IWA dapat terlihat sebagai langkah mundur dalam hal pengalaman pelanggan. Namun, seharusnya tidak menjadi masalah apabila Anda memastikan bahwa para pengguna dapat masuk ke AD FS atau Azure AD tanpa hambatan:

Diagram berikut menunjukkan contoh sederhana cara Anda dapat menggunakan Cloud Identity, AD FS, dan IWA untuk menerapkan single sign-on bebas hambatan untuk suatu aplikasi web:

Cara menggunakan Cloud Identity, AD FS, dan IWA untuk menerapkan single sign-on bebas hambatan untuk suatu aplikasi web

  1. Browser meminta halaman yang dilindungi menggunakan browser web.
  2. Aplikasi web memulai login menggunakan OIDC (alur autentikasi OIDC). Alur ini mengalihkan browser ke endpoint login Google.
  3. Endpoint login Google mengembalikan halaman login Google kepada pengguna, meminta alamat email.
  4. Pengguna memasukkan alamat email mereka.
  5. Berdasarkan alamat email, endpoint login Google mengidentifikasi akun Cloud Identity sekaligus mengenali bahwa akun tersebut sudah dikonfigurasi untuk digunakan ketika SSO. Endpoint login kemudian memulai login SAML menggunakan AD FS.
  6. AD FS, yang dikonfigurasi untuk menggunakan IWA, meminta browser untuk membuat tiket Kerberos, yang memicu browser untuk meminta sistem operasi Windows yang mendasari untuk memperoleh tiket yang sesuai.
  7. Kecuali jika tiket yang seusai telah di-cache, Windows akan mengontak key distribution center (KDC) Active Directory and kemudian meminta tiket layanan agar dikeluarkan berdasarkan ticket granting ticket (TGT) yang diperoleh ketika pengguna login ke Windows.
  8. Browser membuat tiket yang baru diperoleh ke AD FS.
  9. AD FS memvalidasi tiket dengan memeriksa tanda tangan kriptografinya, mengekstrak identitas pengguna dari tiket, lalu mengeluarkan token SAML ke endpoint login Google.
  10. Dengan menggunakan informasi autentikasi dari token SAML, endpoint login Google menyelesaikan login OIDC dan mengeluarkan token OpenID Connect untuk aplikasi web.
  11. Jika pengguna diautentikasi, halaman yang dilindungi dapat dikembalikan kepada pengguna.

Autentikasi kunci publik SSH

Saat Anda berencana menjalankan mesin virtual (VM) Linux di Google Cloud, kemungkinan Anda akan membutuhkan akses SSH untuk mesin virtual ini. Metode autentikasi paling umum untuk SSH adalah autentikasi kunci publik.

Tidak seperti protokol single sign-on yang dibahas sebelumnya, autentikasi kunci publik SSH tidak mengandalkan IdP terpusat untuk membuat keputusan autentikasi. Sebaliknya, keputusan autentikasi bersifat desentralisasi, setiap mesin menangani autentikasi berdasarkan serangkaian kunci publik lokal yang diberi otorisasi.

Anda dapat menghapus kesenjangan antara autentikasi kunci publik SSH terdesentralisasi dengan pengelolaan identitas terpusat dengan menggunakan Login OS. Login OS mengaitkan siklus proses kunci SSH ke siklus proses akun pengguna dengan cara:

  • Memublikasikan kunci pubik SSH ketika seorang pengguna membuat atau mencoba menggunakan SSH untuk pertama kalinya.
  • Menyediakan kunci publik pengguna untuk mesin yang berhak diakses seorang pengguna.
  • Mencabut kunci publik pengguna ketika akses akun tercabut, dinonaktifkan atau dihapus.

Menggunakan Login OS secara efektif menjadikan Cloud Identity sebagai IdP untuk instance Linux Anda.

Referensi yang tidak dapat menggunakan Google sebagai IdP

Beberapa referensi tidak dapat langsung Google sebagai IdP secara langsung. Tetapi, Anda masih dapat mengakomodasi referensi ini di Google Cloud dengan menggabungkan dua pendekatan:

Jika suatu referensi mengandalkan protokol yang tidak didukung oleh Google IdP, referensi tersebut tidak dapat menggunakan Google sebagai IdP. Protokol yang dimaksud meliputi:

  • LDAP untuk autentikasi: Meskipun Anda dapat menggunakan LDAP Aman untuk memudahkan pembuatan kueri informasi pengguna dari Cloud Identity melalui LDAP, Cloud Identity tidak mendukung penggunaan LDAP untuk autentikasi jika digabungkan dengan IdP eksternal.

    Agar aplikasi dapat menggunakan LDAP untuk autentikasi, Anda dapat mengekspos atau mereplikasi direktori LDAP lokal atau Anda dapat memperluas Active Directory Anda ke Google Cloud.

  • WS-Trust, WS-Federation: Terutama jika ANda menggunakan AD FS, Anda mungkin masih harus mengandalkan WS-Trust atau WS-Federation untuk menangani autentikasi berbasis token. Kecuali Anda dapat mengubah aplikasi yang mendapatkan pengaruh untuk menggunakan SAML atau OpenID Connect, sebaiknya ekspos AD FS lokal Anda ke Google Cloud dan jadikan aplikasi agar menggunakan AD FS secara langsung.

  • OpenID Connect dengan klaim khusus AD FS-: AD FS dan Google mendukung OpenID Connect. Jika Anda telah menggunakan AD FS sebagai penyedia OpenID Connect, Anda mungkin mengandalkan klaim khusus AD FS-tertentu yang belum didukung Google. Jika ya, pertimbangkan untuk mengekspos AD FS lokal Anda ke Google Cloud dan jadikan aplikasi yang terpengaruh agar menggunakan AD FS secara langsung.

  • Kerberos, NTLM: Jika beberapa aplikasi Anda menggunakan Kerberos atau NTLM untuk autentikasi, Anda mungkin dapat mengubahnya agar menggunakan OpenID Connect atau SAML. Jika cara di atas tidak memungkinkan, Anda dapat men-deploy aplikasi ini di server Windows yang tergabung dengan domain dan antara mengekspos atau mereplikasi Active Directory lokal Anda ke Google Cloud.

  • Virtual machine Windows: Jika Anda menjalankan beban kerja Windows di Google Cloud, Anda harus dapat login ke VM ini melalui Protokol Desktop Jarak Jauh (RDP), melalui Gateway Desktop Jarak Jauh, atau dengan cara lainnya. Jika seorang pengguna memiliki akses tulis ke proyek Google Cloud tempat VM dibuat, Google Cloud memungkinkan pengguna membuat pengguna dan kata sandi, yang membuat akun di database Pengelola Akun Keamanan (SAM) lokal VM. Terlebih, akun SAM Windows yang dibuat belum terhubung dengan Akun Google pengguna dan tidak berada dalam siklus proses akun yang sama. Jika dengan cara Anda menangguhkan atau menghapus Akun Google dan akun Windows SAM pengguna belum memberikan dampak dan kemungkinan tetap memberikan akses ke VM.

    Jika Anda memiliki jumlah banyak atas VM Windows dan pengguna yang harus dapat login ke mesin ini, maka memungkinkan agar para pengguna membuat akun dan kata sandi pengguna Windows mungkin merupakan pendekatan yang tepat. Namun, saat mengelola fleet server Windows dalam jumlah yang lebih besar, sebaiknya perluas satu Active Directory lokal ke Google Cloud dan selalu ingat untuk menggabungkan server masing-masing ke domain. Server yang tergabung dengan domain juga merupakan persyaratan jika Anda mengandalkan Autentikasi Tingkat Jaringan.

Ketersediaan

Faktor terakhir yang harus diperhatikan adalah ketersediaan. Kemampuan untuk mengautentikasi pengguna kemungkinan akan sangat penting bagi berbagai beban kerja Anda dan penghentian layanan IdP dapat menimbulkan konsekuensi dalam selang waktu jangka panjang. Pendekatan yang tepat untuk memastikan ketersediaan yang sesuai bergantung pada cara dan maksud Anda dalam menggunakan Google Cloud dan bagaimana pendekatan ini sesuai dengan strategi hybrid.

Workload terdistribusi

Untuk memanfaatkan kemampuan unik yang ditawarkan masing-masing lingkungan komputasi kepada Anda, Anda mungkin ingin menggunakan pendekatan multi-cloud hybrid untuk mendistribusikan beban kerja di seluruh lingkungan tersebut. Lingkungan ini mungkin memiliki dependensi satu sama lain yang sangat penting untuk ketersediaan beban kerja Anda. Dependensi mungkin meliputi VPN atau interconnect, aplikasi yang berkomunikasi satu sama lain, atau sistem yang mengakses data di seluruh lingkungan komputasi.

Ketika menggabungkan atau memperluas IdP eksternal Anda ke Google Cloud, pastikan bahwa ketersediaan IdP eksternal Anda dan sistem lainnya diperlukan agar autentikasi memenuhi atau melampaui ketersediaan dependensi penting lainnya. Persyaratan ini berarti Anda mungkin perlu men-deploy IdP eksternal dan dependensinya secara redundan serta memastikan konektivitas jaringan redundan.

Workload redundan

Jika Anda menggunakan Google Cloud untuk memastikan keberlangsungan bisnis, beban kerja Anda di Google Cloud akan menunjukkan beberapa workload yang Anda miliki di lingkungan komputasi Anda. Tujuan penyiapan tersebut adalah untuk memungkinkan satu lingkungan komputasi untuk mengambil alih peran lingkungan lain jika satu lingkungan komputasi lain mengalami kegagalan. Oleh karena itu, Anda harus memeriksa setiap dependensi di antara lingkungan ini.

Dengan menjadikan Google Cloud mengandalkan IdP eksternal yang berjalan secara lokal, Anda sudah membuat dependensi. Dependensi tersebut dapat merusak intent dari Google Cloud yang akan menjadi salinan independen dari lingkungan komputasimu.

Coba replikasi IdP Anda ke Google Cloud sehingga semua workload di Google Cloud tidak terpengaruh oleh penghentian lingkungan komputasi lokal atau konektivitas Anda antara Google Cloud dan jaringan lokal Anda.

Langkah berikutnya