Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa

2025-07-04

Identitas adalah aspek penting dari solusi sistem multipenyewa apa pun. Komponen identitas aplikasi Anda bertanggung jawab atas tugas-tugas berikut:

Memverifikasi identitas pengguna, yang dikenal sebagai autentikasi
Memberlakukan izin pengguna dalam cakupan penyewa, yang dikenal sebagai otorisasi

Pelanggan Anda mungkin juga ingin mengotorisasi aplikasi eksternal untuk mengakses data mereka atau berintegrasi dengan solusi Anda. Identitas pengguna menentukan informasi apa yang dapat 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 perangkat lunak sebagai layanan (SaaS) biasanya disediakan oleh Penyedia Identitas Eksternal (IdP). IdP biasanya merupakan bagian integral dari platform identitas terkelola.

Membangun IdP Anda sendiri kompleks, mahal, dan menantang dalam hal keamanan. Ini dianggap antipattern, dan kami tidak merekomendasikannya.

Sebelum Anda menentukan strategi identitas multipenyewa, pertama-tama pertimbangkan persyaratan identitas tingkat tinggi berikut untuk layanan Anda:

Tentukan apakah pengguna atau identitas beban kerja mengakses satu aplikasi atau beberapa aplikasi dalam keluarga produk. Beberapa keluarga produk mungkin menyertakan aplikasi berbeda yang memiliki infrastruktur identitas yang sama, seperti sistem point-of-sale dan platform manajemen inventarisasi.
Pertimbangkan apakah solusi Anda menerapkan standar autentikasi dan otorisasi modern, seperti OAuth2 dan OpenID Connect.
Mengevaluasi apakah autentikasi terbatas pada aplikasi berbasis UI atau jika akses API juga berlaku untuk penyewa dan sistem pihak ketiga.
Tentukan apakah penyewa perlu melakukan federasi dengan IDP mereka sendiri dan apakah beberapa IDP harus didukung untuk setiap penyewa. Misalnya, Anda mungkin memiliki penyewa dengan Microsoft Entra ID, Auth0, dan Layanan Federasi Direktori Aktif tempat setiap penyewa bergabung dengan solusi Anda. Identifikasi protokol federasi mana yang digunakan IdP mereka karena protokol tersebut menentukan apa yang harus didukung IdP Anda.
Tinjau persyaratan kepatuhan yang berlaku yang perlu mereka penuhi, seperti Peraturan Perlindungan Data Umum (GDPR), yang membentuk strategi identitas Anda.
Tentukan apakah penyewa memerlukan data identitas untuk disimpan di wilayah geografis tertentu untuk memenuhi kebutuhan hukum, kepatuhan, atau operasional.
Menilai apakah pengguna mengakses data dari beberapa penyewa dalam aplikasi. Jika mereka melakukannya, Anda mungkin perlu mendukung transisi antar penyewa yang lancar atau memberikan tampilan konsolidasi di berbagai penyewa untuk pengguna tertentu. Misalnya, pengguna yang masuk ke portal Microsoft Azure dapat dengan mudah beralih antara direktori ID Microsoft Entra dan langganan yang berbeda yang dapat mereka akses.

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

Direktori identitas

Agar solusi multipenyewa dapat mengautentikasi dan mengotorisasi pengguna atau layanan, diperlukan tempat untuk menyimpan informasi identitas. Direktori dapat menyertakan catatan resmi untuk setiap identitas. Atau mungkin berisi referensi ke identitas eksternal yang disimpan di direktori IdP 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 mendaftar sendiri untuk layanan tersebut. 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.
IdP Sosial: IdP sosial memungkinkan pengguna menggunakan identitas yang mereka miliki di jejaring sosial atau IdP publik lainnya, seperti Facebook, Google, atau akun Microsoft pribadi. IdP Sosial umumnya digunakan dalam solusi SaaS bisnis-ke-konsumen (B2C).
Direktori ID Microsoft Entra penyewa: Dalam banyak solusi SaaS business-to-business (B2B), 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 multitenancy.
Federasi dengan IdP penyewa: Dalam beberapa solusi SaaS B2B, penyewa mungkin memiliki IdP mereka sendiri, selain ID Microsoft Entra, dan mereka mungkin ingin solusi Anda terfederasi dengannya. Federasi memungkinkan masuk tunggal (SSO). Ini juga memungkinkan penyewa untuk mengelola siklus hidup dan kebijakan keamanan pengguna mereka secara independen dari solusi Anda.

Anda harus mempertimbangkan apakah penyewa Anda perlu mendukung beberapa IdP. Misalnya, satu penyewa mungkin perlu mendukung identitas lokal, identitas sosial, dan identitas federasi. Persyaratan ini khas ketika perusahaan menggunakan solusi yang ditujukan untuk karyawan dan kontraktor mereka. Mereka mungkin menggunakan federasi untuk memberikan akses kepada karyawan, sekaligus mengizinkan akses bagi kontraktor atau pengguna 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 penyewa Anda.
Informasi yang diperlukan untuk mengautentikasi pengguna Anda dengan aman, termasuk informasi untuk autentikasi multifaktor (MFA).
Informasi yang spesifik untuk penyewa, seperti peran dan hak akses penyewa, dalam konteks 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 penyedia identitas 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. Simpan data otorisasi di tingkat aplikasi, bersama informasi penyewa.

Menentukan jumlah identitas untuk pengguna

Solusi multipenyewa sering memungkinkan identitas pengguna atau identitas beban kerja untuk mengakses sumber daya dan data aplikasi antar penyewa. Ketika pendekatan ini diperlukan, pertimbangkan faktor-faktor berikut:

Tentukan apakah akan membuat satu identitas pengguna untuk setiap orang atau membuat identitas terpisah untuk setiap kombinasi pengguna penyewa.
- Gunakan satu identitas untuk setiap orang jika memungkinkan. Ini menyederhanakan manajemen akun untuk penyedia solusi dan pengguna. Selain itu, banyak perlindungan ancaman cerdas yang diberikan IDP modern mengandalkan setiap orang yang memiliki satu akun pengguna.
- Gunakan beberapa identitas yang berbeda dalam beberapa skenario. 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.
Hindari menyimpan kredensial beberapa kali jika Anda menggunakan identitas per penyewa. 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 Anda berencana untuk memetakan pengguna ke penyewa. Misalnya, selama proses pendaftaran, Anda mungkin memberikan kode undangan unik bagi pengguna untuk dimasukkan saat mereka mengakses penyewa untuk pertama kalinya. Dalam beberapa solusi, nama domain alamat email pendaftaran pengguna dapat mengidentifikasi penyewa terkait. Atau, Anda dapat menggunakan atribut lain dari catatan identitas pengguna untuk menentukan pemetaan penyewa. Asosiasi ini kemudian harus disimpan berdasarkan pengidentifikasi unik yang tidak dapat diubah untuk penyewa dan pengguna.

Jika solusi Anda membatasi setiap pengguna untuk mengakses data untuk satu penyewa, pertimbangkan keputusan berikut:

Tentukan bagaimana IdP mendeteksi tenant mana yang diakses pengguna.
Jelaskan bagaimana IdP mengkomunikasikan pengidentifikasi penyewa ke aplikasi. Biasanya, klaim pengidentifikasi penyewa ditambahkan ke token.

Jika satu pengguna perlu diberikan akses ke beberapa penyewa, pertimbangkan keputusan berikut:

Solusi harus mendukung logika untuk mengidentifikasi pengguna dan memberikan izin yang sesuai di seluruh penyewa. Misalnya, pengguna mungkin memiliki hak administratif dalam satu penyewa tetapi akses terbatas di penyewa lain. 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?
Mekanisme yang jelas harus memungkinkan pengguna beralih antar penyewa. Pendekatan ini memastikan pengalaman pengguna yang mulus dan mencegah akses antar-tenant yang tidak disengaja.
Identitas beban kerja, jika Anda menggunakannya, harus menentukan penyewa mana yang coba mereka akses. Persyaratan ini mungkin termasuk menyematkan konteks khusus penyewa dalam permintaan autentikasi.
Pertimbangkan apakah informasi khusus penyewa yang disimpan dalam catatan identitas pengguna dapat secara tidak sengaja bocor di antara penyewa. Misalnya, jika pengguna mendaftar dengan identitas sosial dan mendapatkan akses ke dua penyewa, dan Penyewa A memperkaya profil pengguna, tentukan apakah Penyewa B harus memiliki akses ke informasi yang diperkaya tersebut.

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 faktor-faktor berikut:

Tentukan sumber identitas mana yang diizinkan pengguna untuk mendaftar. Misalnya, tentukan apakah pengguna dapat membuat identitas lokal dan juga menggunakan IdP sosial.
Tentukan apakah solusi Anda hanya mengizinkan domain email tertentu jika identitas lokal digunakan. Misalnya, tentukan apakah penyewa dapat membatasi pendaftaran kepada pengguna dengan @contoso.com alamat email.
Nama prinsipal pengguna (UPN) yang digunakan untuk mengidentifikasi identitas lokal harus dibuat dengan jelas. UPN umum mencakup alamat email, nama pengguna, nomor telepon, atau pengidentifikasi keanggotaan. Karena UPN dapat berubah, disarankan untuk merujuk pada pengidentifikasi unik yang tidak dapat diubah sebagai dasar untuk otorisasi dan audit. Contohnya adalah ID objek (OID) di MICROSOFT Entra ID.
Verifikasi UPN mungkin diperlukan untuk memastikan akurasinya. Proses ini dapat mencakup memvalidasi kepemilikan alamat email atau nomor telepon sebelum memberikan akses.
Beberapa solusi mungkin mengharuskan administrator penyewa menyetujui pendaftaran pengguna. Proses persetujuan ini memungkinkan kontrol administratif atas siapa yang bergabung dengan penyewa.
Tentukan apakah penyewa memerlukan pengalaman pendaftaran atau URL khusus penyewa. Misalnya, tentukan apakah penyewa Anda memerlukan pengalaman pendaftaran bermerek saat pengguna mendaftar, atau kemampuan untuk mencegat permintaan pendaftaran dan melakukan validasi tambahan sebelum melanjutkan.

Jika pengguna dapat mendaftarkan diri mereka untuk identitas, tentukan proses untuk memberi mereka akses ke penyewa. Alur pendaftaran mungkin menyertakan proses pemberian akses manual atau proses otomatis berdasarkan informasi tentang pengguna, seperti alamat email mereka. Penting untuk merencanakan proses ini dan mempertimbangkan faktor-faktor berikut:

Tentukan bagaimana alur pendaftaran menentukan bahwa pengguna diberikan akses ke penyewa tertentu.
Tentukan apakah solusi Anda secara otomatis mencabut akses pengguna ke penyewa jika sesuai. Misalnya, ketika pengguna meninggalkan organisasi, harus ada proses manual atau otomatis untuk menghapus akses mereka.
Berikan kemampuan audit pengguna sehingga penyewa dapat meninjau pengguna mana yang memiliki akses ke lingkungan mereka dan memahami izin yang ditetapkan.

Manajemen siklus hidup akun otomatis

Persyaratan umum untuk pelanggan korporat atau bisnis dari solusi adalah memiliki serangkaian fitur yang memungkinkan mereka mengotomatiskan onboarding dan offboarding akun. Protokol terbuka, seperti System for Cross-Domain Identity Management (SCIM), menyediakan pendekatan standar industri untuk otomatisasi. Proses otomatis ini biasanya mencakup pembuatan dan penghapusan rekaman identitas dan pengelolaan izin penyewa. Pertimbangkan faktor-faktor berikut saat Anda menerapkan manajemen siklus hidup akun otomatis dalam solusi multipenyewa:

Tentukan apakah pelanggan Anda perlu mengonfigurasi dan mengelola proses siklus hidup otomatis untuk setiap 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.
Tentukan apakah Anda perlu menerapkan SCIM atau menawarkan federasi. Federasi memungkinkan penyewa untuk mempertahankan kontrol atas manajemen pengguna dengan menjaga sumber kebenaran dalam sistem mereka sendiri alih-alih mengelola pengguna lokal dalam solusi Anda.

Proses autentikasi pengguna

Saat pengguna masuk ke aplikasi multipenyewa, sistem identitas Anda mengautentikasi pengguna. Pertimbangkan faktor-faktor berikut saat Anda merencanakan proses autentikasi:

Beberapa penyewa mungkin memerlukan kemampuan untuk mengonfigurasi kebijakan 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.
Opsi untuk menentukan aturan akses kondisional kustom mungkin penting bagi penyewa. Misalnya, penyewa yang berbeda mungkin perlu memblokir upaya masuk dari wilayah geografis tertentu.
Tentukan apakah penyewa perlu menyesuaikan proses masuk satu per satu. Misalnya, solusi Anda mungkin perlu menampilkan logo pelanggan. Atau mungkin perlu mengambil informasi pengguna, seperti nomor hadiah, dari sistem lain dan mengembalikannya ke IdP untuk memperkaya profil pengguna.
Beberapa pengguna mungkin 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.
Akses API mungkin diperlukan untuk beberapa pengguna atau aplikasi eksternal. Skenario ini mungkin termasuk memanggil API solusi secara langsung, yang melewati alur autentikasi pengguna standar.

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 solusi Anda sehingga mereka dapat mengotomatiskan tugas manajemen mereka.

Microsoft Entra mendukung identitas beban kerja, dan IDP lainnya juga biasanya mendukungnya.

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 pergantian kunci secara reguler dan masa berlaku sertifikat.

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

Tentukan bagaimana identitas beban kerja dibuat dan dikelola di setiap penyewa.
Tentukan bagaimana cakupan kebutuhan identitas beban kerja ke penyewa.
Evaluasi jika Anda perlu membatasi jumlah identitas beban kerja yang dibuat setiap penyewa.
Tentukan apakah kontrol akses bersyarat diperlukan untuk identitas beban kerja di setiap penyewa. Misalnya, penyewa mungkin ingin membatasi identitas beban kerja agar tidak diautentikasi dari luar wilayah tertentu.
Identifikasi kontrol keamanan mana yang Anda berikan kepada penyewa untuk memastikan bahwa identitas beban kerja tetap aman. Misalnya, pembaruan kunci otomatis, kedaluwarsa kunci, kedaluwarsa sertifikat, dan pemantauan risiko saat masuk membantu mengurangi risiko penyalahgunaan identitas beban kerja.

Federasi dengan IdP untuk 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 SSO.

Jika Anda mengharapkan penyewa untuk bergabung dengan solusi Anda, pertimbangkan faktor-faktor berikut:

Pertimbangkan langkah-langkah untuk mengonfigurasi federasi bagi penyewa. Tentukan apakah penyewa mengonfigurasi federasi itu sendiri atau apakah prosesnya memerlukan konfigurasi dan pemeliharaan manual oleh tim Anda.
Tentukan protokol federasi mana yang didukung solusi Anda.
Buat proses yang mencegah kesalahan konfigurasi federasi memberikan akses ke penyewa yang tidak diinginkan.
Pertimbangkan apakah IdP penyewa tunggal perlu difederasikan ke lebih dari satu penyewa dalam solusi Anda. Misalnya, jika pelanggan memiliki penyewa pelatihan dan penyewa produksi, mereka mungkin perlu memfederasikan IdP yang sama dengan masing-masing penyewa.

Model otorisasi

Tentukan model otorisasi yang paling masuk akal untuk solusi Anda. Pertimbangkan pendekatan otorisasi umum berikut:

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.

Hak dan lisensi

Dalam beberapa solusi, Anda dapat menggunakan lisensi per pengguna sebagai bagian dari model harga komersial Anda. Dalam skenario ini, Anda menyediakan berbagai tingkat lisensi pengguna yang memiliki 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.

Kode aplikasi atau sistem pemberian hak khusus biasanya melacak dan memberlakukan pemberian hak alih-alih sistem identitas. Proses ini mirip dengan otorisasi tetapi terjadi di luar lapisan manajemen identitas.

Skala identitas dan volume autentikasi

Seiring bertambahnya solusi multipenyewa, jumlah pengguna dan permintaan masuk yang perlu diproses solusi meningkat. Pertimbangkan faktor berikut:

Menilai apakah direktori pengguna diskalakan untuk mendukung jumlah pengguna yang diperlukan.
Mengevaluasi apakah proses autentikasi menangani jumlah proses masuk dan pendaftaran yang diharapkan.
Tentukan apakah ada lonjakan yang tidak dapat ditangani sistem autentikasi. Misalnya, pada pukul 09.00 Waktu Pasifik, semua orang di Amerika Serikat bagian barat mungkin mulai bekerja dan masuk ke solusi Anda, sehingga menyebabkan lonjakan permintaan masuk. Skenario ini terkadang disebut serangan login.
Tentukan apakah beban tinggi di bagian solusi Anda memengaruhi performa proses autentikasi. Misalnya, jika autentikasi memerlukan panggilan ke API tingkat aplikasi, lonjakan permintaan autentikasi dapat memengaruhi performa sistem secara keseluruhan.
Tentukan bagaimana solusi Anda bereaksi jika IdP menjadi tidak tersedia. Pertimbangkan apakah layanan autentikasi cadangan harus disertakan untuk menjaga kelangsungan bisnis.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

John Downs | Insinyur Perangkat Lunak Utama
Daniel Scott-Raynsford | Ahli Strategi Teknologi Mitra
Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

Jelle Druyts | Teknisi Pelanggan Utama, FastTrack untuk Azure
Landon Pierce | Insinyur Pelanggan Senior
Sander van den Hoven | Ahli Strategi Teknologi Mitra Senior
Nick Ward | Arsitek Solusi Cloud Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Pendekatan arsitektur untuk manajemen identitas dalam solusi multitenant