Arsitektur referensi

Last reviewed 2024-07-11 UTC

Dokumen ini menyajikan arsitektur umum yang dapat Anda gunakan sebagai referensi untuk mengelola identitas perusahaan. Dua prinsip inti pengelolaan identitas perusahaan adalah sebagai berikut:

  • Sumber otoritatif untuk identitas yang merupakan satu-satunya sistem yang Anda gunakan untuk membuat, mengelola, dan menghapus identitas karyawan Anda. Identitas yang dikelola dalam sistem sumber resmi dapat disebarkan ke sistem lain.

  • Penyedia identitas (IdP) pusat yang merupakan satu-satunya sistem untuk autentikasi dan yang memberikan suatu pengalaman pengguna yang login bagi karyawan Anda yang menjangkau aplikasi.

Saat Anda menggunakan Google Cloud atau layanan Google lainnya, Anda harus memilih sistem mana yang digunakan sebagai penyedia layanan identitas dan sistem mana yang digunakan sebagai sumber resmi Anda.

Menggunakan Google sebagai IdP

Dengan menggunakan Cloud Identity Premium atau Google Workspace, Anda dapat menjadikan Google sebagai IdP utama Anda. Google menyediakan banyak pilihan integrasi yang siap digunakan untuk aplikasi pihak ketiga yang umum. Anda juga dapat menggunakan protokol standar seperti SAML, OAuth, dan OpenID Connect untuk mengintegrasikan aplikasi kustom Anda.

Google sebagai IdP dan sumber otoritatif

Anda dapat menggunakan Cloud Identity Premium atau Google Workspace sebagai IdP dan sebagai sumber otoritatif, seperti pada diagram berikut.

Google sebagai IdP dan sumber resmi.

  • Anda menggunakan Cloud Identity Premium atau Google Workspace untuk mengelola pengguna dan grup.
  • Semua layanan Google menggunakan Cloud Identity Premium atau Google Workspace sebagai IdP.
  • Anda mengonfigurasi aplikasi perusahaan dan layanan SaaS lainnya untuk menggunakan Google sebagai IdP.

Pengalaman pengguna

Dalam konfigurasi ini, bagi karyawan, pengalaman pengguna yang login terlihat seperti ini:

  1. Setelah meminta permintaan yang dilindungi atau akses ke aplikasi perusahaan, karyawan akan dialihkan ke layar Login Google yang akan meminta alamat email dan sandi Anda.
  2. Jika Verifikasi 2 Langkah diaktifkan, karyawan akan diminta untuk memberikan faktor kedua seperti kode atau kunci USB.
  3. Ketika karyawan diotentikasi, mereka dialihkan kembali ke sumber yang dilindungi.

Kelebihan

Menggunakan Google sebagai IdP dan sumber resmi memiliki keuntungan berikut:

Kapan arsitektur ini harus digunakan

Pertimbangkan untuk menggunakan Google sebagai IdP dan sumber resmi dalam skenario berikut:

  • Anda telah menggunakan Google Workspace sebagai solusi kolaborasi dan produktivitas.
  • Tidak ada infrastruktur lokal atau IdP yang harus diintegrasikan atau Anda ingin memisahkannya dari semua sumber di Google (di Google Cloud, di Google Ads, dan seterusnya).
  • Anda tidak memerlukan integrasi dengan sistem informasi (HRIS) untuk mengelola identitas.

Google sebagai IdP dengan HRIS sebagai sumber resmi

Jika menggunakan sistem informasi sumber daya manusia (HRIS) untuk mengelola proses orientasi dan penghentian bagi karyawan, Anda tetap dapat menggunakan Google sebagai IdP Anda. Cloud Identity dan Google Workspace menyediakan API yang memungkinkan HRIS dan sistem lain mengontrol pengelolaan pengguna dan grup, seperti yang ditunjukkan dalam diagram berikut.

Google sebagai IdP dengan HRIS sebagai sumber resmi.

  • Anda menggunakan HRIS yang ada untuk mengelola pengguna dan, jika perlu, grup. HRIS tetap menjadi satu-satunya sumber tepercaya untuk pengelolaan identitas dan otomatis menyediakan Cloud Identity atau Google Workspace kepada pengguna.
  • Semua layanan Google menggunakan Cloud Identity Premium atau Google Workspace sebagai IdP.
  • Anda mengonfigurasi aplikasi perusahaan dan layanan SaaS lainnya untuk menggunakan Google sebagai IdP.

Pengalaman pengguna

Bagi karyawan, pengalaman pengguna login setara dengan menggunakan Google sebagai IdP dan sumber resmi.

Kelebihan

Menggunakan Google sebagai IdP dan sumber resmi memiliki keuntungan berikut:

  • Anda dapat meminimalkan overhead administratif dengan menggunakan kembali alur kerja HRIS yang tersedia.
  • Anda dapat memanfaatkan sepenuhnya fitur autentikasi multi-faktor dan pengelolaan perangkat seluler Google.
  • Anda tidak memerlukan IdP tambahan, yang mungkin menghemat uang Anda.

Kapan arsitektur ini harus digunakan

Pertimbangkan untuk menggunakan Google sebagai IdP dengan HRIS sebagai sumber resmi dalam skenario berikut:

  • Anda memiliki HRIS atau sistem lain yang berfungsi sebagai sumber resmi untuk identitas.
  • Anda telah menggunakan Google Workspace sebagai solusi kolaborasi dan produktivitas.
  • Tidak ada infrastruktur lokal atau IdP yang harus diintegrasikan atau Anda ingin memisahkannya dari aset Google Anda.

Menggunakan IdP eksternal

Jika organisasi Anda sudah menggunakan IdP seperti Active Directory, Azure AD, ForgeRock, Okta, atau Ping Identity, Anda dapat mengintegrasikan Google Cloud dengan IdP eksternal ini dengan menggunakan penggabungan.

Dengan menggabungkan akun Cloud Identity atau Google Workspace dengan IdP eksternal, Anda dapat mengizinkan karyawan menggunakan identitas dan kredensial yang ada untuk login ke layanan Google seperti Google Cloud, Google Marketing Platform, dan Google Ads.

IDaaS eksternal sebagai IdP dan sumber otoritatif

Jika Anda menggunakan penyedia identitas sebagai layanan (IDaaS) seperti ForgeRock, Okta, atau Ping Identity, Anda dapat menyiapkan penggabungan seperti yang diilustrasikan dalam diagram berikut.

IDaaS eksternal sebagai IdP dan sumber otoritatif.

  • Cloud Identity atau Google Workspace menggunakan IDaaS Anda sebagai IdP untuk suatu pengguna yang Login.
  • IDaaS secara otomatis menyediakan pengguna dan grup untuk Cloud Identity atau Google Workspace.
  • Aplikasi perusahaan yang sudah ada dan layanan SaaS lainnya dapat terus menggunakan IDaaS Anda sebagai IdP.

Untuk mempelajari lebih lanjut cara menggabungkan Cloud Identity atau Google Workspace dengan Okta, lihat Penyediaan pengguna dan single sign-on Okta.

Pengalaman pengguna

Bagi karyawan, pengalaman pengguna login terlihat seperti ini:

  1. Setelah memproses sumber yang dilindungi, karyawan dialihkan ke layar Login dengan Google yang akan meminta alamat email mereka.
  2. Login dengan Google akan mengalihkan Anda ke halaman login IDaaS.
  3. Anda melakukan autentikasi dengan IDaaS. Bergantung pada IDaaS Anda, hal ini mungkin mengharuskan Anda untuk memberikan faktor kedua seperti kode.
  4. Setelah mendapatkan autentikasi, Anda akan dialihkan kembali ke sumber yang dilindungi.

Kelebihan

Menggunakan IDaaS eksternal sebagai IdP dan sumber resmi memiliki keuntungan berikut:

  • Anda mengaktifkan pengalaman single sign-on untuk karyawan yang mencakup seluruh layanan Google dan aplikasi lain yang terintegrasi dengan IDaaS Anda.
  • Jika Anda mengonfigurasi IDaaS untuk mewajibkan autentikasi multi-faktor, konfigurasi tersebut akan berlaku secara otomatis untuk Google Cloud.
  • Anda tidak perlu menyinkronkan sandi atau kredensial lainnya dengan Google.
  • Anda dapat menggunakan Cloud Identity versi gratis.

Kapan arsitektur ini harus digunakan

Pertimbangkan untuk menggunakan IDaaS eksternal sebagai IdP dan sumber resmi dalam skenario berikut:

  • Anda sudah menggunakan penyedia IDaaS seperti ForgeRock, Okta, atau Ping Identity sebagai IdP.

Praktik terbaik

Lihat praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.

Active Directory sebagai IdP dan sumber resmi

ika menggunakan Active Directory sebagai sumber terpercaya untuk pengelolaan identitas, kemudian Anda dapat menyiapkan penggabungan seperti yang diilustrasikan dalam diagram berikut.

Active Directory sebagai IdP dan sumber resmi.

  • Anda menggunakan Google Cloud Directory Sync (GCDS) untuk menyediakan pengguna dan grup secara otomatis dari Active Directory untuk Cloud Identity atau Google Workspace. Google Cloud Directory Sync adalah alat gratis yang disediakan oleh Google, yang menerapkan proses sinkronisasi dan dapat dijalankan di Google Cloud atau di lingkungan lokal Anda. Sinkronisasi bersifat satu arah sehingga Active Directory tetap menjadi sumber tepercaya.
  • Cloud Identity atau Google Workspace menggunakan Active Directory Federation Services (AD FS) untuk single sign-on.
  • Aplikasi perusahaan yang ada dan layanan SaaS lainnya dapat terus menggunakan AD FS Andasebagai IdP.

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.

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

Pengalaman pengguna

  1. Setelah meminta sumber yang dilindungi, karyawan dialihkan ke layar Login dengan Google yang akan meminta alamat email mereka.
  2. Login dengan Google mengalihkan karyawan ke halaman login AD FS.
  3. Bergantung pada konfigurasi AD FS, karyawan mungkin melihat layar sign on yang meminta nama pengguna dan sandi Active Directory mereka. Kalau tidak, AD FS mungkin mencoba memproses login karyawan secara otomatis berdasarkan hasil login Windows mereka.
  4. Setelah AD FS mengautentikasi karyawan, mereka akan dialihkan kembali ke resource yang dilindungi.

Kelebihan

Menggunakan Active Directory sebagai IdP dan sumber resmi memiliki keuntungan berikut:

  • Anda mengaktifkan pengalaman single sign-on untuk karyawan yang mencakup seluruh layanan Google dan lingkungan lokal Anda.
  • Jika Anda mengonfigurasi AD FS untuk mewajibkan autentikasi multi-faktor, konfigurasi tersebut akan otomatis berlaku untuk Google Cloud.
  • Anda tidak perlu menyinkronkan sandi atau kredensial lainnya ke Google.
  • Anda dapat menggunakan Cloud Identity versi gratis.
  • Karena API yang digunakan GCDS dapat diakses secara publik, Anda tidak perlu menyiapkan konektivitas hybrid antara jaringan lokal dan Google Cloud.

Kapan arsitektur ini harus digunakan

Pertimbangkan untuk menggunakan Active Directory sebagai IdP dan sumber resmi dalam skenario berikut:

  • Anda sudah memiliki infrastruktur Active Directory.
  • Anda ingin memberikan pengalaman login yang lancar bagi pengguna Windows.

Praktik terbaik

Pertimbangkan praktik terbaik berikut ini:

  • Active Directory dan Cloud Identity menggunakan struktur logika yang berbeda. Pastikan Anda memahami perbedaannya dan menilai metode pemetaan domain, identitas, dan grup yang paling sesuai dengan situasi Anda. Untuk informasi lebih lanjut, lihat panduan cara menggabungkan Google Cloud dengan Active Directory kami.
  • 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.
  • Bagikan dan tunjukkan AD FS sehingga pengguna perusahaan dapat mengaksesnya, tetapi jangan menunjukkan lebih dari yang diperlukan. Meskipun pengguna perusahaan harus dapat mengakses AD FS, tidak ada persyaratan agar AD FS dapat dijangkau dari Cloud Identity atau Google Workspace, atau dari aplikasi apa pun yang dibagikan 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 telah dibagikan dan disesuaikan untuk memenuhi tujuan ketersediaan Anda.
  • Jika Anda menggunakan Google Cloud untuk membantu memastikan kelangsungan bisnis, mengandalkan AD FS lokal dapat merusak maksud penggunaan Google Cloud sebagai salinan independen dari pembagian Anda. Dalam hal ini, pertimbangkan untuk men-deploy replika semua sistem yang relevan di Google Cloud dengan salah satu cara berikut:

    • Perluas domain Active Directory Anda yang sudah ada ke Google Cloud dan deploy GCDS untuk dijalankan 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.

Untuk mempelajari lebih lanjut, lihat Praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksterna.

Azure AD sebagai IdP dengan Active Directory sebagai sumber resmi

ika Anda adalah pelanggan Microsoft Office 365 atau Azure, Anda mungkin telah menghubungkan Active Directory lokal Anda ke Azure AD. Jika semua akun pengguna yang mungkin 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.

Azure AD sebagai IdP dengan
Active Directory sebagai sumber resmi.

  • Anda menggunakan Azure AD untuk menyediakan pengguna dan grup secara otomatis ke Cloud Identity atau Google Workspace. Azure AD sendiri dapat terintegrasi dengan Active Directory lokal.
  • Cloud Identity atau Google Workspace menggunakan Azure AD untuk Single sign-on.
  • Aplikasi perusahaan yang sudah ada dan layanan SaaS lainnya dapat terus menggunakan Azure AD sebagai IdP.

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

Pengalaman pengguna

  1. Setelah meminta resource yang dilindungi, karyawan dialihkan ke layar Login dengan Google yang akan meminta alamat email mereka.
  2. Login dengan Google akan mengalihkan mereka ke halaman login AD FS.
  3. Bergantung pada cara Active Directory lokal mereka terhubung ke Azure AD, Azure AD mungkin meminta nama pengguna dan sandi mereka, atau mungkin mengalihkan mereka ke AD FS lokal.
  4. Setelah karyawan diautentikasi dengan Azure AD, mereka akan dialihkan kembali ke sumber yang dilindungi.

Kelebihan

Menggunakan Azure AD sebagai IdP dengan Active Directory sebagai sumber resmi memiliki beberapa keuntungan:

  • Anda mengaktifkan pengalaman single sign-on untuk karyawan yang mencakup seluruh layanan Google, Azure, dan lingkungan lokal Anda.
  • Jika Anda mengonfigurasi Azure AD untuk mewajibkan autentikasi multi-faktor, konfigurasi tersebut akan otomatis berlaku untuk Google Cloud.
  • Anda tidak perlu menginstal software tambahan apa pun di infrastruktur lokal.
  • Jika Active Directory lokal Anda menggunakan beberapa domain atau forest dan Anda telah menyiapkan konfigurasi Azure AD Connect kustom untuk memetakan struktur pada tenant Azure AD, Anda dapat memanfaatkan tugas integrasi ini singkat ini.
  • Anda tidak perlu menyinkronkan sandi atau kredensial lainnya ke Google.
  • Anda dapat menggunakan Cloud Identity versi gratis.
  • Anda dapat menampilkan konsol Google Cloud sebagai kartu di portal Office 365.
  • Karena API yang digunakan Azure AD dapat diakses oleh publik, Anda tidak perlu menyiapkan konektivitas hybrid antara Azure dan Google Cloud.

Kapan arsitektur ini harus digunakan

Pertimbangkan untuk menggunakan Azure AD sebagai IdP dengan Active Directory sebagai sumber resmi dalam skenario berikut:

  • Anda sudah menggunakan Azure AD dan telah mengintegrasikannya dengan infrastruktur Active Directory yang telah tersedia.
  • Anda ingin memberikan pengalaman login yang lancar bagi pengguna di seluruh Azure dan Google Cloud.

Praktik terbaik

Ikuti praktik terbaik berikut:

  • Karena Azure AD dan Cloud Identity menggunakan struktur logika yang berbeda, pastikan Anda memahami perbedaannya. Tentukan metode pemetaan 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 menyiapkan IAM sehingga Anda dapat menggunakan keanggotaan grup di Azure AD untuk mengontrol siapa yang memiliki akses ke resource mana di Google Cloud.
  • ika 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.

Untuk mempelajari lebih lanjut, lihat Praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.

Langkah berikutnya