Bagikan melalui

Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa

  • Artikel

Identitas adalah aspek penting dari solusi multipenyewa apa pun. Komponen identitas aplikasi Anda bertanggung jawab atas kedua hal berikut:

  • Memverifikasi siapa pengguna (autentikasi).
  • Memberlakukan izin pengguna dalam cakupan penyewa (otorisasi).

Pelanggan Anda mungkin juga ingin mengotorisasi aplikasi eksternal untuk mengakses data mereka atau untuk berintegrasi ke solusi Anda. Identitas pengguna menentukan informasi apa yang akan diakses pengguna atau layanan. Penting bahwa Anda mempertimbangkan persyaratan identitas Anda, untuk mengisolasi aplikasi dan data Anda antar penyewa.

Perhatian

Layanan autentikasi dan otorisasi, dalam aplikasi multipenyewa dan SaaS, biasanya disediakan oleh IdP (IdP) pihak ketiga. Penyedia identitas biasanya merupakan bagian integral dari platform identitas sebagai layanan (IDaaS).

Membangun IdP Anda sendiri rumit, mahal, dan sulit dibangun dengan aman. Membangun idP Anda sendiri adalah antipattern. Kami tidak merekomendasikannya.

Sebelum menentukan strategi identitas multipenyewa, Anda harus terlebih dahulu mempertimbangkan persyaratan identitas tingkat tinggi layanan Anda, termasuk persyaratan berikut:

  • Apakah identitas pengguna atau beban kerja akan digunakan untuk mengakses satu aplikasi atau beberapa aplikasi dalam keluarga produk? Misalnya, keluarga produk ritel mungkin memiliki keduanya, aplikasi point-of-sale dan aplikasi manajemen inventori, yang memiliki solusi identitas yang sama.
  • Apakah Anda berencana menerapkan autentikasi dan otorisasi modern, seperti OAuth2 dan OpenID Connect?
  • Apakah solusi Anda hanya menyediakan autentikasi ke aplikasi berbasis UI Anda? Atau, apakah Anda juga menyediakan akses API ke penyewa dan pihak ketiga Anda?
  • Apakah penyewa perlu bergabung ke IdP mereka sendiri, dan apakah beberapa penyedia identitas yang berbeda perlu didukung untuk setiap penyewa? Misalnya, Anda mungkin memiliki penyewa dengan Microsoft Entra ID, Auth0, dan Active Directory Federation Services (ADFS), di mana setiap ingin bergabung dengan solusi Anda. Anda juga perlu memahami protokol federasi idP penyewa mana yang akan Anda dukung, karena protokol memengaruhi persyaratan untuk IdP Anda sendiri.
  • Apakah ada persyaratan kepatuhan khusus yang perlu mereka penuhi, seperti GDPR?
  • Apakah penyewa Anda mengharuskan informasi identitas mereka berada dalam wilayah geografis tertentu?
  • Apakah pengguna solusi Anda memerlukan akses ke data dari satu penyewa atau dari beberapa penyewa dalam aplikasi Anda? Apakah mereka membutuhkan kemampuan untuk beralih antar penyewa dengan cepat atau melihat informasi terkonsolidasi dari beberapa penyewa? Misalnya, pengguna yang telah masuk ke portal Azure dapat dengan mudah beralih antara direktori ID Microsoft Entra yang berbeda dan langganan yang dapat mereka akses.

Setelah menetapkan persyaratan tingkat tinggi, Anda dapat mulai merencanakan detail dan persyaratan yang lebih spesifik, seperti sumber direktori pengguna dan alur pendaftaran/masuk.

Direktori identitas

Agar solusi multipenyewa dapat mengautentikasi dan mengotorisasi pengguna atau layanan, diperlukan tempat untuk menyimpan informasi identitas. Direktori dapat menyertakan rekaman otoritatif untuk setiap identitas, atau mungkin berisi referensi ke identitas eksternal yang disimpan di direktori penyedia identitas lain.

Saat Anda merancang sistem identitas untuk solusi multipenyewa, Anda perlu mempertimbangkan jenis IdP berikut yang mungkin diperlukan penyewa dan pelanggan Anda:

  • IdP lokal. IdP lokal memungkinkan pengguna untuk mendaftar sendiri ke layanan. Pengguna menyediakan nama pengguna, alamat email, atau pengidentifikasi, seperti nomor kartu hadiah. Mereka juga memberikan kredensial, seperti kata sandi. IdP menyimpan pengidentifikasi pengguna dan kredensial.
  • Penyedia identitas sosial. Penyedia identitas sosial memungkinkan pengguna menggunakan identitas yang mereka miliki di jejaring sosial atau idP publik lainnya, seperti Facebook, Google, atau akun Microsoft pribadi.
  • Gunakan direktori ID Microsoft Entra penyewa. Penyewa mungkin sudah memiliki direktori ID Microsoft Entra mereka sendiri, dan mereka mungkin ingin solusi Anda menggunakan direktori mereka sebagai IdP untuk mengakses solusi Anda. Pendekatan ini dimungkinkan ketika solusi Anda dibangun sebagai aplikasi Microsoft Entra multipenyewa.
  • Federasi dengan idP penyewa. Penyewa mungkin memiliki IdP mereka sendiri, selain ID Microsoft Entra, dan mereka mungkin ingin solusi Anda terfederasi dengannya. Federasi memungkinkan pengalaman akses menyeluruh (SSO), dan memungkinkan penyewa untuk mengelola kebijakan siklus hidup dan keamanan pengguna mereka, secara independen dari solusi Anda.

Anda harus mempertimbangkan apakah penyewa Anda perlu mendukung beberapa penyedia identitas. Misalnya, Anda mungkin perlu mendukung identitas lokal, identitas sosial, dan identitas federasi, semuanya dalam satu penyewa. Persyaratan ini umum terjadi ketika perusahaan menggunakan solusi yang baik untuk karyawan mereka sendiri maupun untuk kontraktor. Mereka mungkin menggunakan federasi untuk akses karyawan mereka sendiri ke solusi, sambil juga mengizinkan akses ke kontraktor atau ke pengguna tamu, yang tidak memiliki akun di IdP federasi.

Menyimpan informasi autentikasi dan otorisasi penyewa

Dalam solusi multipenyewa, Anda perlu mempertimbangkan tempat menyimpan beberapa jenis informasi identitas, termasuk jenis berikut:

  • Detail tentang akun pengguna dan layanan, termasuk nama mereka dan informasi lain yang diperlukan oleh penyewa Anda.
  • Informasi yang diperlukan untuk mengautentikasi pengguna Anda dengan aman, termasuk informasi yang diperlukan untuk menyediakan autentikasi multifaktor (MFA).
  • Informasi khusus penyewa, seperti peran dan izin penyewa. Informasi ini digunakan untuk otorisasi.

Perhatian

Kami tidak merekomendasikan untuk membangun proses autentikasi sendiri. IDP modern menyediakan layanan autentikasi ini untuk aplikasi Anda, dan mereka juga menyertakan fitur penting lainnya, seperti MFA dan akses bersyarkat. Membangun idP Anda sendiri adalah antipattern. Kami tidak merekomendasikannya.

Pertimbangkan opsi berikut untuk menyimpan informasi identitas:

  • Simpan semua informasi identitas dan otorisasi di direktori IdP, dan bagikan di antara beberapa penyewa.
  • Simpan kredensial pengguna di direktori IdP, dan simpan informasi otorisasi di tingkat aplikasi, bersama dengan informasi penyewa.

Menentukan jumlah identitas untuk pengguna

Merupakan hal umum bagi solusi multipenyewa untuk memungkinkan identitas pengguna atau beban kerja mengakses aplikasi dan data beberapa penyewa. Pertimbangkan apakah pendekatan ini diperlukan untuk solusi Anda. Jika ya, maka Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:

  • Haruskah Anda membuat satu identitas pengguna untuk setiap orang, atau membuat identitas terpisah untuk setiap kombinasi pengguna penyewa?
    • Yang terbaik adalah menggunakan satu identitas untuk setiap orang, sedapat mungkin. Menjadi sulit untuk mengelola beberapa akun pengguna, baik untuk Anda, sebagai vendor solusi, dan juga untuk pengguna Anda. Selain itu, banyak perlindungan ancaman cerdas yang ditawarkan oleh IdP modern mengandalkan setiap orang yang memiliki satu akun pengguna.
    • Namun, dalam beberapa situasi, mungkin perlu bagi pengguna untuk memiliki beberapa identitas yang berbeda. Misalnya, jika orang menggunakan sistem Anda baik untuk tujuan kerja maupun pribadi, mereka mungkin ingin memisahkan akun pengguna mereka. Atau, jika penyewa Anda memiliki persyaratan penyimpanan data peraturan atau geografis yang ketat, mereka mungkin mengharuskan seseorang untuk memiliki beberapa identitas sehingga mereka dapat mematuhi peraturan atau undang-undang.
  • Jika Anda menggunakan identitas per penyewa, hindari menyimpan kredensial beberapa kali. Pengguna harus menyimpan kredensial mereka terhadap satu identitas, dan Anda harus menggunakan fitur seperti identitas tamu untuk merujuk ke kredensial pengguna yang sama dari rekaman identitas beberapa penyewa.

Memberi pengguna akses ke data penyewa

Pertimbangkan bagaimana pengguna akan dipetakan ke penyewa. Misalnya, selama proses pendaftaran, Anda mungkin menggunakan kode undangan unik yang mereka masukkan saat pertama kali mengakses penyewa. Dalam beberapa solusi, Anda mungkin menggunakan nama domain alamat email pendaftaran pengguna sebagai cara untuk mengidentifikasi penyewa tempat mereka berada. Atau, Anda dapat menggunakan atribut lain dari catatan identitas pengguna untuk memetakan pengguna ke penyewa. Anda kemudian harus menyimpan pemetaan berdasarkan pengidentifikasi unik yang tidak dapat diubah yang mendasar untuk penyewa dan pengguna.

Jika solusi Anda dirancang sehingga satu pengguna hanya akan mengakses data untuk satu penyewa, maka pertimbangkan keputusan berikut:

  • Bagaimana IdP mendeteksi penyewa mana yang diakses pengguna?
  • Bagaimana IdP mengkomunikasikan pengidentifikasi penyewa ke aplikasi? Umumnya, klaim pengidentifikasi penyewa ditambahkan ke token.

Jika satu pengguna perlu diberikan akses ke beberapa penyewa, maka Anda perlu mempertimbangkan keputusan berikut:

  • Bagaimana solusi Anda mengidentifikasi dan memberikan izin kepada pengguna yang memiliki akses ke beberapa penyewa? Misalnya, bisakah pengguna menjadi administrator di penyewa pelatihan, dan memiliki akses baca-saja ke penyewa produksi? Atau, bisakah Anda memiliki penyewa terpisah untuk departemen yang berbeda dalam organisasi, tetapi Anda perlu mempertahankan identitas pengguna yang konsisten di semua penyewa?
  • Bagaimana pengguna beralih antar penyewa?
  • Jika Anda menggunakan identitas beban kerja, bagaimana identitas beban kerja menentukan penyewa yang perlu diaksesnya?
  • Apakah ada informasi khusus penyewa yang disimpan dalam catatan identitas pengguna yang dapat membocorkan informasi antar penyewa? Misalnya, pengguna mendaftar dengan identitas sosial dan kemudian diberikan akses ke dua penyewa. Penyewa A memperkaya identitas pengguna dengan informasi lebih lanjut. Haruskah penyewa B memiliki akses ke informasi yang diperkaya?

Proses pendaftaran pengguna untuk identitas lokal atau identitas sosial

Beberapa penyewa mungkin perlu mengizinkan pengguna mendaftarkan diri untuk identitas dalam solusi Anda. Pendaftaran layanan mandiri mungkin diperlukan jika Anda tidak memerlukan federasi dengan idP penyewa. Jika proses pendaftaran mandiri diperlukan, maka Anda harus mempertimbangkan pertanyaan berikut:

  • Sumber identitas mana yang diizinkan pengguna untuk mendaftar? Misalnya, dapatkah pengguna membuat identitas lokal dan juga menggunakan IdP sosial?
  • Jika hanya identitas lokal yang diizinkan, hanya domain email tertentu yang diizinkan? Misalnya, dapatkah penyewa menentukan bahwa hanya pengguna yang memiliki @contoso.com alamat email yang diizinkan untuk mendaftar?
  • Apa nama prinsipal pengguna (UPN) yang harus digunakan untuk mengidentifikasi setiap identitas lokal secara unik selama proses masuk? Misalnya, alamat email, nama pengguna, nomor telepon, dan nomor kartu hadiah semuanya merupakan pilihan umum untuk UPN. Namun, UPN dapat berubah dari waktu ke waktu. Saat Anda merujuk ke identitas dalam aturan otorisasi aplikasi atau log audit, adalah praktik yang baik untuk menggunakan pengidentifikasi unik identitas yang tidak dapat diubah yang mendasar. MICROSOFT Entra ID menyediakan ID objek (OID), yang merupakan pengidentifikasi yang tidak dapat diubah.
  • Apakah pengguna akan diminta untuk memverifikasi UPN mereka? Misalnya, jika alamat email atau nomor telepon pengguna digunakan sebagai UPN, bagaimana Anda memverifikasi bahwa informasi tersebut akurat?
  • Apakah administrator penyewa perlu menyetujui pendaftaran?
  • Apakah penyewa memerlukan pengalaman pendaftaran atau URL khusus penyewa? Misalnya, apakah penyewa Anda memerlukan pengalaman pendaftaran bermerek saat pengguna mendaftar? Apakah penyewa Anda memerlukan kemampuan untuk mencegat permintaan pendaftaran dan melakukan validasi tambahan sebelum dilanjutkan?

Akses penyewa untuk pengguna pendaftaran mandiri

Ketika pengguna diizinkan untuk mendaftarkan diri mereka untuk identitas, biasanya perlu ada proses bagi mereka untuk diberikan akses ke penyewa. Alur pendaftaran mungkin mencakup proses pemberian akses, atau dapat diotomatisasi, berdasarkan informasi tentang pengguna, seperti alamat email mereka. Penting untuk merencanakan proses ini dan mempertimbangkan pertanyaan berikut:

  • Bagaimana alur pendaftaran akan menentukan bahwa pengguna harus diberikan akses ke penyewa tertentu?
  • Jika pengguna tidak boleh lagi memiliki akses ke penyewa, apakah solusi Anda akan secara otomatis mencabut akses mereka? Misalnya, ketika pengguna meninggalkan organisasi, harus ada proses manual atau otomatis yang menghapus akses mereka dari penyewa.
  • Apakah Anda perlu menyediakan cara bagi penyewa untuk mengaudit pengguna yang memiliki akses ke penyewa mereka dan izin mereka?

Manajemen siklus hidup akun otomatis

Persyaratan umum untuk pelanggan perusahaan atau perusahaan dari solusi adalah serangkaian fitur yang memungkinkan mereka mengotomatiskan onboarding akun dan off-boarding. Protokol terbuka, seperti System for Cross-domain Identity Management (SCIM), menyediakan pendekatan standar industri untuk otomatisasi. Proses otomatis ini biasanya tidak hanya mencakup pembuatan dan penghapusan rekaman identitas, tetapi juga pengelolaan izin penyewa. Pertimbangkan pertanyaan berikut saat Anda menerapkan manajemen siklus hidup akun otomatis dalam solusi multipenyewa:

  • Apakah pelanggan Anda perlu mengonfigurasi dan mengelola proses siklus hidup otomatis per penyewa? Misalnya, saat pengguna di-onboarding, Anda mungkin perlu membuat identitas dalam beberapa penyewa di aplikasi Anda, di mana setiap penyewa memiliki serangkaian izin yang berbeda.
  • Apakah Anda perlu menerapkan SCIM, atau dapatkah Anda menyediakan federasi penyewa sebagai gantinya, untuk menjaga sumber kebenaran bagi pengguna di bawah kendali penyewa, alih-alih mengelola pengguna lokal?

Proses autentikasi pengguna

Saat pengguna masuk ke aplikasi multipenyewa, sistem identitas Anda mengautentikasi pengguna. Anda harus mempertimbangkan pertanyaan berikut, saat merencanakan proses autentikasi:

  • Apakah penyewa Anda perlu mengonfigurasi kebijakan autentikasi multifaktor (MFA) mereka sendiri? Misalnya, jika penyewa Anda berada di industri layanan keuangan, mereka perlu menerapkan kebijakan MFA yang ketat, sementara peritel online kecil mungkin tidak memiliki persyaratan yang sama.
  • Apakah penyewa Anda perlu mengonfigurasi aturan akses bersyar mereka sendiri? Misalnya, penyewa yang berbeda mungkin perlu memblokir upaya masuk dari wilayah geografis tertentu.
  • Apakah penyewa Anda perlu menyesuaikan proses masuk untuk setiap penyewa? Misalnya, apakah Anda perlu menampilkan logo pelanggan? Atau, apakah informasi tentang setiap pengguna perlu diekstrak dari sistem lain, seperti nomor hadiah, dan dikembalikan ke idP untuk ditambahkan ke profil pengguna?
  • Apakah pengguna Anda perlu meniru pengguna lain? Misalnya, anggota tim dukungan mungkin ingin menyelidiki masalah yang dimiliki pengguna lain, dengan meniru akun pengguna mereka tanpa harus mengautentikasi sebagai pengguna.
  • Apakah pengguna Anda perlu mendapatkan akses ke API untuk solusi Anda? Misalnya, pengguna atau aplikasi pihak ketiga mungkin perlu langsung memanggil API Anda untuk memperluas solusi Anda, tanpa antarmuka pengguna untuk menyediakan alur autentikasi.

Identitas beban kerja

Di sebagian besar solusi, identitas sering mewakili pengguna. Beberapa sistem multipenyewa juga memungkinkan identitas beban kerja digunakan oleh layanan dan aplikasi, untuk mendapatkan akses ke sumber daya aplikasi Anda. Misalnya, penyewa Anda mungkin perlu mengakses API yang disediakan oleh solusi Anda, sehingga mereka dapat mengotomatiskan beberapa tugas manajemen mereka.

Identitas beban kerja mirip dengan identitas pengguna, tetapi biasanya memerlukan metode autentikasi yang berbeda, seperti kunci atau sertifikat. Identitas beban kerja tidak menggunakan MFA. Sebagai gantinya, identitas beban kerja biasanya memerlukan kontrol keamanan lain, seperti rolling kunci reguler dan kedaluwarsa sertifikat.

Jika penyewa Anda berharap dapat mengaktifkan akses identitas beban kerja ke solusi multipenyewa Anda, maka Anda harus mempertimbangkan pertanyaan berikut:

  • Bagaimana identitas beban kerja akan dibuat dan dikelola di setiap penyewa?
  • Bagaimana permintaan identitas beban kerja akan dilingkupkan ke penyewa?
  • Apakah Anda perlu membatasi jumlah identitas beban kerja yang dibuat oleh setiap penyewa?
  • Apakah Anda perlu menyediakan kontrol akses bersyarah pada identitas beban kerja untuk setiap penyewa? Misalnya, penyewa mungkin ingin membatasi identitas beban kerja agar tidak diautentikasi dari luar wilayah tertentu.
  • Kontrol keamanan mana yang akan Anda berikan kepada penyewa untuk memastikan bahwa identitas beban kerja tetap aman? Misalnya, rolling kunci otomatis, kedaluwarsa kunci, kedaluwarsa sertifikat, dan pemantauan risiko masuk adalah semua metode mengurangi risiko, di mana identitas beban kerja mungkin disalahgunakan.

Federasi dengan penyedia identitas untuk akses menyeluruh (SSO)

Penyewa, yang sudah memiliki direktori pengguna mereka sendiri, mungkin ingin solusi Anda digabungkan ke direktori mereka. Federasi memungkinkan solusi Anda untuk menggunakan identitas di direktori mereka, alih-alih mengelola direktori lain dengan identitas yang berbeda.

Federasi sangat penting ketika beberapa penyewa ingin menentukan kebijakan identitas mereka sendiri, atau untuk mengaktifkan pengalaman akses menyeluruh (SSO).

Jika Anda mengharapkan penyewa untuk bergabung dengan solusi Anda, Anda harus mempertimbangkan pertanyaan berikut:

  • Apa proses untuk mengonfigurasi federasi untuk penyewa? Dapatkah penyewa mengonfigurasi federasi itu sendiri, atau apakah prosesnya memerlukan konfigurasi dan pemeliharaan manual oleh tim Anda?
  • Protokol federasi mana yang akan Anda dukung?
  • Proses apa yang diberlakukan untuk memastikan federasi tidak dapat salah dikonfigurasi, untuk memberikan akses ke penyewa lain?
  • Apakah penyedia identitas penyewa tunggal perlu digabungkan ke lebih dari satu penyewa dalam solusi Anda? Misalnya, jika pelanggan memiliki penyewa pelatihan dan produksi, mereka mungkin perlu menggabungkan penyedia identitas yang sama ke kedua penyewa.

Model otorisasi

Tentukan model otorisasi yang paling masuk akal untuk solusi Anda. Dua pendekatan otorisasi umum adalah:

  • Otorisasi berbasis peran. Pengguna ditetapkan ke peran. Beberapa fitur aplikasi dibatasi untuk peran tertentu. Misalnya, pengguna dalam peran administrator dapat melakukan tindakan apa pun, sementara pengguna dalam peran yang lebih rendah mungkin memiliki subset izin di seluruh sistem.
  • Otorisasi berbasis sumber daya. Solusi Anda menyediakan sekumpulan sumber daya yang berbeda, yang masing-masing memiliki serangkaian izinnya sendiri. Pengguna tertentu mungkin merupakan administrator dari satu sumber daya dan tidak memiliki akses ke sumber daya lain.

Model-model ini berbeda, dan pendekatan yang Anda pilih memengaruhi implementasi Anda dan kompleksitas kebijakan otorisasi yang dapat Anda terapkan.

Pemberian izin dan lisensi

Dalam beberapa solusi, Anda dapat menggunakan lisensi per pengguna sebagai bagian dari model harga komersial Anda. Anda akan memberikan tingkat lisensi pengguna yang berbeda dengan kemampuan yang berbeda. Misalnya, pengguna dengan satu lisensi mungkin diizinkan untuk menggunakan subset fitur aplikasi. Kemampuan yang diizinkan untuk diakses pengguna tertentu, berdasarkan lisensi mereka, terkadang disebut hak.

Meskipun pelacakan dan penegakan pemberian izin mirip dengan otorisasi, biasanya ditangani oleh kode aplikasi atau oleh sistem pemberian izin khusus, daripada dikelola oleh sistem identitas.

Skala identitas dan volume autentikasi

Seiring bertambahnya solusi multipenyewa, jumlah pengguna dan permintaan masuk yang perlu diproses oleh solusi akan meningkat. Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:

  • Apakah direktori pengguna akan diskalakan ke jumlah pengguna yang diperlukan?
  • Apakah proses autentikasi akan menangani jumlah rincian masuk dan pendaftaran yang diharapkan?
  • Apakah akan ada lonjakan yang tidak dapat ditangani sistem autentikasi? Misalnya, pada pukul 09.00 PST, semua orang di wilayah Amerika Serikat barat mungkin mulai bekerja dan masuk ke solusi Anda, menyebabkan lonjakan permintaan masuk. Situasi ini terkadang disebut badai masuk.
  • Dapatkah beban tinggi di bagian lain solusi Anda berdampak pada performa proses autentikasi? Misalnya, jika proses autentikasi Anda memerlukan panggilan ke API tingkat aplikasi, apakah jumlah permintaan autentikasi yang tinggi akan menyebabkan masalah untuk solusi Anda lainnya?
  • Apa yang akan terjadi jika IdP Anda menjadi tidak tersedia? Apakah ada layanan autentikasi cadangan yang dapat mengambil alih untuk memberikan kelangsungan bisnis, sementara IdP tidak tersedia?

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lain:

Langkah berikutnya

Tinjau Pendekatan arsitektur untuk identitas dalam solusi multipenyewa.