Pola untuk mengautentikasi pengguna tenaga kerja di lingkungan hybrid

Last reviewed 2024-06-26 UTC

Dokumen ini adalah bagian kedua dari beberapa seri yang membahas cara memperluas solusi pengelolaan identitas Anda ke Google Cloud agar pengguna tenaga kerja Anda dapat mengautentikasi dan menggunakan layanan di lingkungan komputasi hybrid.

Seri ini terdiri dari dokumen berikut:

Pengantar

Saat memperluas lanskap IT Anda ke Google Cloud sebagai bagian dari strategi hybrid, sebaiknya lakukan pendekatan yang konsisten untuk mengelola identitas di berbagai lingkungan. Saat mendesain dan menyesuaikan arsitektur untuk memenuhi batasan dan persyaratan ini, Anda dapat mengandalkan beberapa pola umum. Pola-pola ini terbagi dalam dua kategori:

  • Pola untuk melakukan penggabungan penyedia identitas (IdP) eksternal dengan Google Cloud. Pola ini bertujuan memungkinkan Google menjadi IdP bagi pengguna tenaga kerja Anda sehingga identitas Google dikelola secara otomatis dan IdP Anda tetap menjadi sumber tepercaya.
  • Pola untuk memperluas IdP ke Google Cloud. Dalam pola ini, Anda mengizinkan aplikasi yang di-deploy di Google Cloud menggunakan kembali IdP Anda, baik dengan menghubungkannya langsung atau dengan mengelola replika IdP Anda di Google Cloud.

Pola untuk melakukan penggabungan IdP eksternal dengan Google Cloud

Untuk mengaktifkan akses ke konsol Google Cloud, Google Cloud CLI, atau resource lain yang menggunakan Google sebagai IdP, pengguna tenaga kerja harus memiliki identitas Google. Menyimpan identitas Google untuk setiap karyawan akan rumit ketika semua karyawan sudah memiliki akun di IdP. Dengan menggabungkan identitas pengguna antara IdP dan Google Cloud, Anda dapat mengotomatiskan pemeliharaan Akun Google dan mengaitkan siklus prosesnya dengan akun yang ada. Federation membantu memastikan hal-hal berikut:

  • IdP Anda akan tetap menjadi satu sumber tepercaya untuk pengelolaan identitas.
  • Untuk semua akun pengguna yang dikelola IdP Anda, atau sebagian kecil akun yang dipilih, Akun Google akan dibuat secara otomatis.
  • Jika akun dinonaktifkan atau dihapus di IdP, Akun Google yang terkait akan ditangguhkan atau dihapus.
  • Untuk mencegah sandi atau kredensial lainnya disalin, tindakan mengautentikasi pengguna didelegasikan ke IdP Anda.

Menggabungkan Active Directory dengan Cloud Identity menggunakan Google Cloud Directory Sync dan AD FS

Jika menggunakan Active Directory sebagai IdP, Anda dapat menggabungkan Active Directory dengan Cloud Identity menggunakan Google Cloud Directory Sync (GCDS) dan Active Directory Federation Services (AD FS):

  • GCDS adalah alat gratis yang disediakan Google untuk menerapkan proses sinkronisasi. GCDS berkomunikasi dengan Identity Platform melalui Secure Sockets Layer (SSL) dan biasanya berjalan di lingkungan komputasi yang ada.
  • AD FS disediakan oleh Microsoft sebagai bagian dari Windows Server. Dengan AD FS, Anda dapat menggunakan Active Directory untuk autentikasi gabungan. AD FS biasanya berjalan di lingkungan komputasi yang ada.

Untuk informasi selengkapnya tentang pendekatan ini, lihat Menggabungkan Google Cloud dengan Active Directory.

Pola: Menggabungkan Active Directory dengan Cloud Identity menggunakan GCDS dan AD FS.

Untuk variasi pola ini, Anda juga dapat menggunakan Active Directory Lightweight Directory Services (AD LDS) atau direktori LDAP lain dengan AD FS atau IdP lainnya yang sesuai dengan SAML.

Pengalaman pengguna

  1. Saat meminta resource yang dilindungi, Anda akan dialihkan ke layar login Google, yang meminta alamat email Anda.
  2. Jika alamat email diketahui terkait dengan akun yang telah disinkronkan dari Active Directory, Anda akan dialihkan ke AD FS.
  3. Bergantung pada konfigurasi AD FS, Anda mungkin melihat layar login yang meminta nama pengguna dan sandi Active Directory Anda. Atau AD FS mungkin mencoba membuat Anda login secara otomatis berdasarkan login Windows (IWA) Anda.
  4. Ketika AD FS telah mengautentikasi, Anda akan dialihkan kembali ke resource yang dilindungi.

Kelebihan

  • Pendekatan ini memungkinkan pengalaman single sign-on di seluruh aplikasi dan resource lokal di Google Cloud.
  • Jika Anda mengonfigurasiAD FS untuk mewajibkan autentikasi multi-faktor konfigurasi tersebut akan otomatis berlaku untuk Google Cloud.
  • Anda tidak perlu menyinkronkan sandi atau kredensial lainnya ke Google.
  • Karena Cloud Identity API dapat diakses oleh publik, Anda tidak perlu menyiapkan konektivitas hybrid antara jaringan lokal dan Google Cloud.

Praktik terbaik

  • Active Directory dan Cloud Identity menggunakan struktur logika yang berbeda. Pastikan Anda memahami perbedaannya dan menilai cara untuk memetakan domain, identitas, dan grup yang paling sesuai dengan situasi Anda. Lihat panduan kami tentang menggabungkan Google Cloud dengan Active Directory untuk mendapatkan informasi lebih mendetail.
  • Menyinkronkan grup sebagai tambahan pengguna. Dengan pendekatan ini, Anda dapat menyiapkan IAM sehingga Anda dapat menggunakan keanggotaan grup di Active Directory untuk mengontrol siapa yang memiliki akses ke resource di Google Cloud.
  • Deploy dan ekspos AD FS sehingga pengguna tenaga kerja dapat mengaksesnya, tetapi jangan mengeksposnya lebih dari yang diperlukan. Meskipun pengguna tenaga kerja harus dapat mengakses AD FS, tidak ada persyaratan agar AD FS dapat dijangkau dari Google atau dari aplikasi apa pun yang di-deploy di Google Cloud.
  • Pertimbangkan untuk mengaktifkan Integrated Windows Authentication (IWA) di AD FS agar pengguna dapat login secara otomatis berdasarkan login Windows mereka.
  • Jika AD FS tidak tersedia, pengguna mungkin tidak dapat menggunakan Google Cloud Console atau resource lain yang menggunakan Google sebagai IdP. Jadi, pastikan AD FS dan pengontrol domain yang diandalkan AD FS di-deploy dan disesuaikan ukurannya untuk memenuhi tujuan ketersediaan Anda.
  • Jika Anda menggunakan Google Cloud untuk membantu memastikan kelangsungan bisnis, mengandalkan AD FS lokal dapat merusak tujuan penggunaan Google Cloud sebagai salinan independen dari deployment Anda. Oleh karena itu, pertimbangkan untuk men-deploy replika dari semua sistem yang relevan di Google Cloud:
    • Replikasikan Active Directory Anda ke Google Cloud dan deploy GCDS untuk berjalan di Google Cloud.
    • Jalankan server AD FS khusus di Google Cloud. Server ini menggunakan pengontrol domain Active Directory yang berjalan di Google Cloud.
    • Konfigurasikan Cloud Identity untuk menggunakan server AD FS yang di-deploy di Google Cloud untuk single sign-on.

Menggabungkan Azure AD dengan Cloud Identity

Jika Anda adalah pelanggan Microsoft Office 365 atau Azure, Anda mungkin telah menghubungkan Active Directory lokal ke Azure AD. Jika semua akun pengguna yang berpotensi memerlukan akses ke Google Cloud sudah disinkronkan ke Azure AD, Anda dapat menggunakan kembali integrasi ini dengan menggabungkan Cloud Identity dengan Azure AD, seperti yang ditunjukkan dalam diagram berikut.

Menggabungkan Cloud Identity dengan Azure AD.

Untuk informasi selengkapnya tentang pendekatan ini, lihat Menggabungkan Google Cloud dengan Azure Active Directory.

Pengalaman pengguna

  1. Saat meminta resource yang dilindungi, Anda akan dialihkan ke layar login Google, yang meminta alamat email Anda.
  2. Jika alamat email dikaitkan dengan akun yang telah disinkronkan dari Azure AD, Anda akan dialihkan ke Azure AD.
  3. Bergantung pada cara koneksi Active Directory lokal Anda ke Azure AD, Azure AD mungkin akan meminta nama pengguna dan sandi Anda. Atau, Anda mungkin dialihkan ke AD FS lokal.
  4. Setelah berhasil mengautentikasi dengan Azure AD, Anda akan dialihkan kembali ke resource yang dilindungi.

Kelebihan

  • Anda tidak perlu menginstal software tambahan apa pun di infrastruktur lokal.
  • Pendekatan ini memungkinkan pengalaman single sign-on di Office 365, Azure, dan resource di Google Cloud.
  • Jika Anda mengonfigurasi Azure AD untuk mewajibkan autentikasi multi-faktor (MFA), MFA akan otomatis diterapkan ke Google Cloud.
  • Jika Active Directory lokal Anda menggunakan beberapa domain atau hutan, dan Anda telah menyiapkan konfigurasi Azure AD Connect kustom untuk memetakan struktur ini ke tenant Azure AD, Anda dapat memanfaatkan tugas integrasi ini.
  • Anda tidak perlu menyinkronkan sandi atau kredensial lainnya ke Google.
  • Karena Cloud Identity API dapat diakses oleh publik, Anda tidak perlu menyiapkan konektivitas hybrid antara jaringan lokal dan Google Cloud, atau antara Azure dan Google Cloud.
  • Anda dapat menampilkan konsol Google Cloud sebagai kartu di portal Office 365.

Praktik terbaik

  • Karena Azure AD dan Cloud Identity menggunakan struktur logika yang berbeda, pastikan Anda memahami perbedaannya. Tentukan cara untuk memetakan domain, identitas, dan grup yang paling sesuai dengan situasi Anda. Untuk mengetahui informasi selengkapnya, lihat menggabungkan Google Cloud dengan Azure AD.
  • Menyinkronkan grup sebagai tambahan pengguna. Dengan pendekatan ini, Anda dapat mengatur IAM sehingga Anda dapat menggunakan keanggotaan grup di Azure AD untuk mengontrol siapa yang memiliki akses ke resource di Google Cloud.
  • Jika Anda menggunakan Google Cloud untuk membantu memastikan kelangsungan bisnis, mengandalkan Azure AD untuk autentikasi dapat merusak maksud penggunaan Google Cloud sebagai salinan independen dari deployment Anda.

Pola untuk memperluas IdP eksternal ke Google Cloud

Beberapa aplikasi yang ingin Anda deploy di Google Cloud mungkin memerlukan penggunaan protokol autentikasi yang tidak ditawarkan oleh Cloud Identity. Untuk mendukung beban kerja ini, Anda harus mengizinkan aplikasi ini menggunakan IdP Anda dari dalam Google Cloud.

Bagian berikut menjelaskan pola umum untuk mengizinkan IdP Anda digunakan oleh beban kerja yang di-deploy di Google Cloud.

Mengekspos AD FS lokal ke Google Cloud

Jika aplikasi memerlukan penggunaan WS-Trust atau WS-Federation, atau mengandalkan fitur atau klaim khusus AD FS saat menggunakan OpenID Connect, Anda dapat mengizinkan aplikasi agar langsung menggunakan AD FS untuk autentikasi.

Aplikasi secara langsung menggunakan AD FS untuk autentikasi.

Dengan menggunakan AD FS, aplikasi dapat mengotentikasi pengguna. Namun, karena autentikasi tidak didasarkan pada identitas Google, aplikasi tidak akan dapat melakukan panggilan API apa pun yang diautentikasi dengan kredensial pengguna. Sebagai gantinya, setiap panggilan ke Google Cloud API harus diautentikasi menggunakan akun layanan.

Pengalaman pengguna

  1. Saat meminta resource yang dilindungi, Anda akan dialihkan ke layar login ADFS, yang meminta alamat email Anda. Jika AD FS tidak diekspos secara publik melalui internet, mengakses AD FS mungkin mengharuskan Anda terhubung ke jaringan perusahaan atau VPN perusahaan.
  2. Bergantung pada konfigurasi AD FS, Anda mungkin melihat layar login yang meminta nama pengguna dan sandi Active Directory Anda. Atau AD FS mungkin mencoba membuat Anda masuk secara otomatis berdasarkan login Windows Anda.
  3. Ketika AD FS telah mengautentikasi, Anda akan dialihkan kembali ke resource yang dilindungi.

Kelebihan

  • Anda dapat menggunakan protokol autentikasi yang tidak didukung oleh Cloud Identity, termasuk WS-Trust dan WS-Federation.
  • Jika aplikasi telah dikembangkan dan diuji terhadap AD FS, Anda dapat menghindari risiko yang mungkin muncul karena beralih aplikasi untuk menggunakan Cloud Identity.
  • Tidak perlu menyiapkan konektivitas hybrid antara jaringan lokal dan Google Cloud.

Praktik terbaik

  • Deploy dan ekspos AD FS sehingga pengguna tenaga kerja dapat mengaksesnya, tetapi jangan mengeksposnya lebih dari yang diperlukan. Meskipun pengguna tenaga kerja harus dapat mengakses AD FS, tidak ada persyaratan agar AD FS dapat dijangkau dari Google atau dari aplikasi apa pun yang di-deploy di Google Cloud.
  • Jika AD FS menjadi tidak tersedia, pengguna mungkin tidak dapat menggunakan aplikasi lagi. Pastikan AD FS dan pengontrol domain yang diandalkan di-deploy dan disesuaikan ukurannya untuk memenuhi tujuan ketersediaan Anda.
  • Pertimbangkan untuk memfaktorkan ulang aplikasi yang mengandalkan WS-Trust dan WS-Federation untuk menggunakan SAML atau OpenID Connect.
  • Jika aplikasi bergantung pada informasi grup yang diekspos sebagai klaim di IdTokens yang dikeluarkan oleh AD FS, pertimbangkan untuk mengambil informasi grup dari sumber lain seperti Directory API ini. Kueri ke Directory API adalah operasi dengan hak istimewa yang memerlukan penggunaan akun layanan yang diaktifkan untuk delegasi seluruh domain Google Workspace.

Mengekspos direktori LDAP lokal ke Google Cloud

Beberapa aplikasi Anda mungkin mewajibkan pengguna memberikan nama pengguna dan sandi, serta menggunakan kredensial ini untuk mencoba operasi pengikatan LDAP. Jika Anda tidak dapat mengubah aplikasi ini untuk menggunakan cara lain seperti SAML untuk melakukan autentikasi, Anda dapat memberi aplikasi tersebut akses ke direktori LDAP lokal.

Memberi pengguna akses ke direktori LDAP lokal.

Kelebihan

  • Anda tidak perlu mengubah aplikasi Anda.

Praktik terbaik

  • Gunakan Cloud VPN atau Cloud Interconnect untuk membuat konektivitas hybrid antara Google Cloud dan jaringan lokal Anda, sehingga Anda tidak perlu mengekspos direktori LDAP melalui internet.
  • Pastikan latensi yang ditimbulkan dengan membuat kueri direktori LDAP lokal tidak berdampak negatif terhadap pengalaman pengguna.
  • Pastikan komunikasi antara aplikasi dan direktori LDAP dienkripsi. Anda dapat mencapai enkripsi ini menggunakan Cloud VPN atau dengan menggunakan Cloud Interconnect dengan LDAP/S.
  • Jika direktori LDAP atau konektivitas pribadi antara Google Cloud dan jaringan lokal Anda menjadi tidak tersedia, pengguna mungkin tidak lagi dapat menggunakan aplikasi berbasis LDAP. Oleh karena itu, pastikan masing-masing server di-deploy dan disesuaikan ukurannya untuk memenuhi tujuan ketersediaan Anda, dan pertimbangkan untuk menggunakan tunnel VPN redundan atau interconnect.
  • Jika Anda menggunakan Google Cloud untuk memastikan kelangsungan bisnis, mengandalkan direktori LDAP lokal dapat merusak tujuan penggunaan Google Cloud sebagai salinan independen dari deployment yang ada. Dalam hal ini, pertimbangkan untuk mereplikasi direktori LDAP ke Google Cloud.
  • Jika Anda menggunakan Active Directory, pertimbangkan untuk menjalankan replika di Google Cloud, terutama jika Anda berencana untuk menggabungkan mesin Windows dengan domain yang berjalan di Google Cloud ke Active Directory.

Mereplikasi direktori LDAP lokal ke Google Cloud

Mereplikasi direktori LDAP lokal ke Google Cloud mirip dengan pola Mengekspos direktori LDAP lokal ke Google Cloud. Untuk aplikasi yang menggunakan LDAP guna memverifikasi nama pengguna dan sandi, pendekatan ini bertujuan untuk menjalankan aplikasi tersebut di Google Cloud. Daripada mengizinkan aplikasi tersebut mengkueri direktori LDAP lokal, Anda dapat mempertahankan replika direktori lokal di Google Cloud.

Mempertahankan replika direktori lokal di Google Cloud.

Kelebihan

  • Anda tidak perlu mengubah aplikasi Anda.
  • Ketersediaan aplikasi berbasis LDAP yang berjalan di Google Cloud tidak bergantung pada ketersediaan direktori lokal atau konektivitas ke jaringan lokal. Pola ini sangat cocok untuk skenario hybrid kelangsungan bisnis.

Praktik terbaik

  • Gunakan Cloud VPN atau Cloud Interconnect untuk membuat konektivitas hybrid antara Google Cloud dan jaringan lokal Anda, sehingga Anda tidak perlu mengekspos direktori LDAP melalui internet.
  • Pastikan replikasi antara direktori LDAP lokal dilakukan melalui saluran aman.
  • Deploy beberapa replika direktori LDAP di beberapa zona atau region untuk memenuhi tujuan ketersediaan Anda. Anda dapat menggunakan load balancer internal untuk mendistribusikan koneksi LDAP di antara beberapa replika yang di-deploy di region yang sama.
  • Gunakan project Google Cloud yang terpisah dengan VPC Bersama untuk men-deploy replika LDAP dan memberikan akses ke project ini berdasarkan hak istimewa terendah.

Memperluas Active Directory lokal ke Google Cloud

Beberapa beban kerja yang ingin Anda deploy di Google Cloud mungkin bergantung pada Layanan Domain Active Directory, misalnya:

  • Komputer Windows yang harus bergabung dengan domain
  • Aplikasi yang menggunakan Kerberos atau NTLM untuk autentikasi
  • Aplikasi yang menggunakan Active Directory sebagai direktori LDAP untuk memverifikasi nama pengguna dan password

Untuk mendukung beban kerja tersebut, Anda dapat memperluas forest Active Directory lokal ke Google Cloud, misalnya dengan men-deploy forest resource ke Google Cloud dan menghubungkannya ke forest Active Directory lokal Anda, seperti dalam diagram berikut.

Menghubungkan forest resource ke forest Active Directory lokal Anda.

Untuk informasi selengkapnya tentang pendekatan ini dan cara lain untuk men-deploy Active Directory di lingkungan hybrid, lihat Pola untuk menggunakan Active Directory dalam lingkungan hybrid.

Memperluas forest Active Directory lokal Anda ke Google Cloud dengan men-deploy pengontrol domain tambahan di Google Cloud.

Kelebihan

  • Beban kerja Anda dapat memanfaatkan Active Directory sepenuhnya, termasuk kemampuan untuk menggabungkan komputer Windows ke domain Active Directory.
  • Ketersediaan aplikasi berbasis Active Directory yang berjalan di Google Cloud tidak bergantung pada ketersediaan resource lokal atau konektivitas ke jaringan lokal. Pola ini sangat cocok untuk skenario hybrid kelangsungan bisnis.

Praktik terbaik

  • Gunakan Cloud VPN atau Cloud Interconnect untuk membuat konektivitas hybrid antara Google Cloud dan jaringan lokal Anda.
  • Untuk meminimalkan komunikasi antara Google Cloud dan jaringan lokal Anda, buat situs Active Directory terpisah untuk deployment Google Cloud. Anda dapat menggunakan satu situs per VPC Bersama atau, untuk meminimalkan komunikasi antar-region, satu situs per VPC Bersama dan region.
  • Buat domain Active Directory terpisah yang didedikasikan untuk resource yang di-deploy di Google Cloud dan tambahkan domain ke forest yang ada. Menggunakan domain terpisah membantu mengurangi overhead replikasi dan ukuran partisi.
  • Untuk meningkatkan ketersediaan, deploy setidaknya dua pengontrol domain, yang tersebar di beberapa zona1. Jika Anda menggunakan beberapa region, pertimbangkan untuk men-deploy pengontrol domain di setiap region.
  • Gunakan project Google Cloud yang terpisah dengan VPC Bersama untuk men-deploy pengontrol domain dan memberikan akses ke project ini dengan hak istimewa terendah. Dengan membuat sandi atau mengakses konsol serial instance pengontrol domain, anggota project berbahaya mungkin dapat menyusupi domain.
  • Pertimbangkan untuk men-deploy server farm AD FS dan GCDS di Google Cloud. Pendekatan ini memungkinkan Anda menggabungkan Active Directory dengan Cloud Identity tanpa bergantung pada ketersediaan resource atau konektivitas ke jaringan lokal.

Langkah selanjutnya

  1. Region Meksiko, Montreal, dan Osaka memiliki tiga zona dalam satu atau dua pusat data fisik. Region ini sedang dalam proses perluasan ke minimal tiga pusat data fisik. Untuk mengetahui informasi selengkapnya, lihat Lokasi Cloud dan SLA Google Cloud Platform. Untuk membantu meningkatkan keandalan workload Anda, pertimbangkan deployment multi-regional.  ↩