Share via

Pendekatan arsitektur untuk identitas dalam solusi multipenyewa

  • Artikel

Hampir semua solusi multipenyewa memerlukan sistem identitas. Dalam artikel ini, kami membahas komponen identitas umum, termasuk autentikasi dan otorisasi, dan kami membahas bagaimana komponen ini dapat diterapkan dalam solusi multipenyewa.

Catatan

Tinjau Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa untuk mempelajari lebih lanjut tentang persyaratan dan keputusan utama yang perlu Anda buat, sebelum Anda mulai membangun sistem identitas untuk solusi multipenyewa.

Autentikasi

Autentikasi adalah proses di mana identitas pengguna dibuat. Saat Anda membangun solusi multipenyewa, ada pertimbangan dan pendekatan khusus untuk beberapa aspek proses autentikasi.

Federasi

Anda mungkin perlu melakukan federasi dengan penyedia identitas (IdP) lainnya. Federasi dapat digunakan untuk mengaktifkan skenario berikut:

  • Login sosial, seperti dengan memungkinkan pengguna menggunakan akun Google, Facebook, GitHub, atau Microsoft pribadi mereka.
  • Direktori khusus penyewa, seperti dengan mengaktifkan penyewa untuk menggabungkan aplikasi Anda dengan penyedia identitas mereka sendiri, sehingga mereka tidak perlu mengelola akun di beberapa tempat.

Untuk informasi umum tentang federasi, lihat pola Identitas Federasi.

Jika Anda memilih untuk mendukung penyedia identitas khusus penyewa, pastikan Anda mengklarifikasi layanan dan protokol mana yang perlu Anda dukung. Misalnya, apakah Anda akan mendukung protokol Koneksi OpenID dan protokol Security Assertion Markup Language (SAML)? Atau, apakah Anda hanya akan mendukung federasi dengan instans Microsoft Entra?

Saat Anda menerapkan penyedia identitas apa pun, pertimbangkan skala dan batasan apa pun yang mungkin berlaku. Misalnya, jika Anda menggunakan Azure Active Directory (Azure AD) B2C sebagai penyedia identitas Anda sendiri, Anda mungkin perlu menyebarkan kebijakan kustom untuk bergabung dengan jenis penyedia identitas penyewa tertentu. Azure AD B2C membatasi jumlah kebijakan kustom yang dapat Anda sebarkan, yang mungkin membatasi jumlah penyedia identitas khusus penyewa yang dapat Anda gabungkan.

Anda juga dapat mempertimbangkan untuk menyediakan federasi sebagai fitur yang hanya berlaku untuk pelanggan di tingkat produk yang lebih tinggi.

Akses menyeluruh

Pengalaman akses menyeluruh memungkinkan pengguna beralih antar aplikasi dengan mulus, tanpa diminta untuk mengautentikasi ulang di setiap titik.

Saat pengguna mengunjungi aplikasi, aplikasi mengarahkannya ke IdP. Jika IdP melihat mereka memiliki sesi yang sudah ada, IdP akan mengeluarkan token baru tanpa mengharuskan pengguna untuk berinteraksi dengan proses masuk. Model identitas federasi mendukung pengalaman akses menyeluruh, dengan memungkinkan pengguna menggunakan satu identitas di beberapa aplikasi.

Dalam solusi multipenyewa, Anda mungkin juga mengaktifkan bentuk akses menyeluruh lainnya. Jika pengguna berwenang untuk bekerja dengan data untuk beberapa penyewa, Anda mungkin perlu memberikan pengalaman yang mulus saat pengguna mengubah konteks mereka dari satu penyewa ke penyewa lainnya. Pertimbangkan apakah Anda perlu mendukung transisi yang mulus antara penyewa, dan jika demikian, apakah penyedia identitas Anda perlu membuat ulang token dengan klaim penyewa tertentu. Misalnya, pengguna yang masuk ke portal Azure dapat beralih di antara direktori Microsoft Entra yang berbeda, yang menyebabkan autentikasi ulang, dan mengeluarkan kembali token dari instans Microsoft Entra yang baru dipilih.

Evaluasi risiko masuk

Platform identitas modern mendukung evaluasi risiko selama proses masuk. Misalnya, jika pengguna masuk dari lokasi atau perangkat yang tidak biasa, sistem autentikasi mungkin memerlukan pemeriksaan identitas tambahan, seperti autentikasi multifaktor (MFA), sebelum memungkinkan permintaan masuk untuk melanjutkan.

Pertimbangkan apakah penyewa Anda mungkin memiliki kebijakan risiko berbeda yang perlu diterapkan selama proses autentikasi. Misalnya, jika Anda memiliki beberapa penyewa di industri yang sangat diatur, mereka mungkin memiliki profil risiko dan persyaratan yang berbeda untuk penyewa yang bekerja di lingkungan yang kurang diatur. Atau, Anda dapat memilih untuk mengizinkan penyewa pada tingkat harga yang lebih tinggi untuk menentukan kebijakan masuk yang lebih ketat daripada penyewa yang membeli tingkat layanan Anda yang lebih rendah.

Jika Anda perlu mendukung kebijakan risiko yang berbeda untuk setiap penyewa, sistem autentikasi Anda perlu mengetahui penyewa mana yang masuk pengguna, sehingga dapat menerapkan kebijakan yang benar.

Jika IdP Anda menyertakan kemampuan ini, pertimbangkan untuk menggunakan fitur evaluasi risiko masuk asli IdP. Fitur-fitur ini dapat menjadi kompleks dan rentan terhadap kesalahan untuk mengimplementasikan diri Anda.

Atau, jika Anda bergabung ke penyedia identitas penyewa sendiri, maka kebijakan mitigasi masuk berisiko mereka sendiri dapat diterapkan, dan mereka dapat mengontrol kebijakan dan kontrol yang harus diberlakukan. Namun, penting untuk menghindari penambahan beban yang tidak perlu secara tidak sengaja kepada pengguna, seperti dengan memerlukan dua tantangan MFA - satu dari penyedia identitas rumah pengguna dan satu dari Anda sendiri. Pastikan Anda memahami bagaimana federasi berinteraksi dengan setiap idP penyewa Anda dan kebijakan yang telah diterapkan.

Peniruan

Peniruan memungkinkan pengguna untuk mengasumsikan identitas pengguna lain, tanpa menggunakan kredensial pengguna tersebut.

Secara umum, peniruan identitas berbahaya, dan mungkin sulit untuk diterapkan dan dikendalikan. Namun, dalam beberapa skenario, peniruan adalah persyaratan. Misalnya, jika Anda mengoperasikan perangkat lunak sebagai layanan (SaaS), personel helpdesk Anda mungkin perlu mengasumsikan identitas pengguna, sehingga mereka dapat masuk sebagai pengguna dan memecahkan masalah.

Jika Anda memilih untuk menerapkan peniruan identitas, pertimbangkan bagaimana Anda mengaudit penggunaannya. Pastikan log Anda menyertakan pengguna aktual yang melakukan tindakan dan pengidentifikasi pengguna yang ditiru.

Beberapa platform identitas mendukung peniruan identitas, baik sebagai fitur bawaan atau dengan menggunakan kode kustom. Misalnya, di Azure AD B2C, Anda dapat menambahkan klaim kustom untuk ID pengguna yang ditiru, atau Anda dapat mengganti klaim pengidentifikasi subjek dalam token yang dikeluarkan.

Authorization

Otorisasi adalah proses menentukan apa yang diizinkan untuk dilakukan pengguna.

Data otorisasi dapat disimpan di beberapa tempat, termasuk di lokasi berikut:

  • Di idP Anda. Misalnya, jika Anda menggunakan ID Microsoft Entra sebagai idP, Anda dapat menggunakan fitur seperti peran dan grup aplikasi untuk menyimpan informasi otorisasi. Aplikasi Anda kemudian dapat menggunakan klaim token terkait untuk menerapkan aturan otorisasi Anda.
  • Di aplikasi Anda. Anda dapat membangun logika otorisasi Anda sendiri, lalu menyimpan informasi tentang apa yang dapat dilakukan setiap pengguna dalam database atau sistem penyimpanan serupa. Anda kemudian dapat merancang kontrol menenangkan untuk otorisasi tingkat peran atau sumber daya.

Di sebagian besar solusi multipenyewa, penetapan peran dan izin dikelola oleh penyewa atau pelanggan, bukan oleh Anda sebagai vendor sistem multipenyewa.

Untuk informasi selengkapnya, lihat Peran aplikasi.

Menambahkan identitas penyewa dan informasi peran ke token

Pertimbangkan bagian, atau bagian mana, dari solusi Anda yang harus melakukan permintaan otorisasi, termasuk menentukan apakah pengguna diizinkan untuk bekerja dengan data dari penyewa tertentu.

Pendekatan umum adalah agar sistem identitas Anda menyematkan klaim pengidentifikasi penyewa ke dalam token. Pendekatan ini memungkinkan aplikasi Anda untuk memeriksa klaim dan memverifikasi bahwa pengguna bekerja dengan penyewa yang diizinkan untuk mereka akses. Jika Anda menggunakan model keamanan berbasis peran, maka Anda dapat memilih untuk memperluas token dengan informasi tentang peran yang dimiliki pengguna dalam penyewa.

Namun, jika satu pengguna diizinkan untuk mengakses beberapa penyewa, Anda mungkin memerlukan cara bagi pengguna Anda untuk memberi sinyal penyewa mana yang mereka rencanakan untuk dikerjakan selama proses masuk. Setelah mereka memilih penyewa aktif mereka, IdP dapat menyertakan klaim dan peran pengidentifikasi penyewa yang benar untuk penyewa tersebut, dalam token yang bermasalah. Anda juga perlu mempertimbangkan bagaimana pengguna dapat beralih antar penyewa, yang memerlukan penerbitan token baru.

Otorisasi berbasis aplikasi

Pendekatan alternatif adalah membuat sistem identitas agnostik untuk pengidentifikasi dan peran penyewa. Pengguna diidentifikasi menggunakan kredensial atau hubungan federasi mereka, dan token tidak menyertakan klaim pengidentifikasi penyewa. Daftar atau database terpisah berisi pengguna mana yang telah diberikan akses ke setiap penyewa. Kemudian, tingkat aplikasi dapat memverifikasi apakah pengguna yang ditentukan harus diizinkan untuk mengakses data untuk penyewa tertentu, berdasarkan mencari daftar tersebut.

Menggunakan ID Microsoft Entra atau Azure AD B2C

Microsoft menyediakan MICROSOFT Entra ID dan Azure AD B2C, yang merupakan platform identitas terkelola yang dapat Anda gunakan dalam solusi multipenyewa Anda sendiri.

Banyak solusi multipenyewa adalah software as a service (SaaS). Pilihan Anda apakah akan menggunakan ID Microsoft Entra atau Azure AD B2C bergantung, sebagian, tentang cara Anda menentukan penyewa atau basis pelanggan Anda.

  • Jika penyewa atau pelanggan Anda adalah organisasi, mereka mungkin sudah menggunakan ID Microsoft Entra untuk layanan seperti Office 365, Microsoft Teams, atau untuk lingkungan Azure mereka sendiri. Anda dapat membuat aplikasi multipenyewa di direktori Microsoft Entra Anda sendiri, untuk membuat solusi Anda tersedia untuk direktori Microsoft Entra lainnya. Anda bahkan dapat mencantumkan solusi Anda di Marketplace Azure dan membuatnya mudah diakses oleh organisasi yang menggunakan ID Microsoft Entra.
  • Jika penyewa atau pelanggan Anda tidak menggunakan ID Microsoft Entra, atau jika mereka individu, bukan organisasi, pertimbangkan untuk menggunakan Azure AD B2C. Azure AD B2C menyediakan serangkaian fitur untuk mengontrol cara pengguna mendaftar dan masuk. Misalnya, Anda dapat membatasi akses ke solusi hanya untuk pengguna yang telah Anda undang, atau Anda mungkin mengizinkan pendaftaran layanan mandiri. Gunakan kebijakan kustom di Azure AD B2C untuk sepenuhnya mengontrol cara pengguna berinteraksi dengan platform identitas. Anda dapat menggunakan branding kustom, dan Anda dapat menggabungkan Azure AD B2C dengan penyewa Microsoft Entra Anda sendiri, untuk memungkinkan staf Anda sendiri masuk. Azure AD B2C juga memungkinkan federasi dengan penyedia identitas lain.
  • Beberapa solusi multipenyewa ditujukan untuk kedua situasi yang tercantum di atas. Beberapa penyewa mungkin memiliki penyewa Microsoft Entra mereka sendiri, dan penyewa lainnya mungkin tidak. Anda juga dapat menggunakan Azure AD B2C untuk skenario ini, dan menggunakan kebijakan kustom untuk mengizinkan pengguna masuk dari direktori Microsoft Entra penyewa. Namun, jika Anda menggunakan kebijakan kustom untuk membuat federasi antar penyewa, pastikan Anda mempertimbangkan batasan jumlah kebijakan kustom yang dapat digunakan oleh satu direktori Azure AD B2C.

Untuk informasi selengkapnya, lihat Pertimbangan untuk menggunakan Azure Active Directory B2C dalam arsitektur multipenyewa.

Antipattern yang perlu dihindari

Membangun atau menjalankan sistem identitas Anda sendiri

Membangun platform identitas modern itu kompleks. Ada berbagai protokol dan standar untuk didukung, dan mudah untuk salah menerapkan protokol dan mengekspos kerentanan keamanan. Standar dan protokol berubah, dan Anda juga perlu terus memperbarui sistem identitas Anda untuk mengurangi serangan dan untuk mendukung fitur keamanan terbaru. Penting juga untuk memastikan bahwa sistem identitas tangguh, karena waktu henti apa pun dapat memiliki konsekuensi parah untuk sisa solusi Anda. Selain itu, dalam kebanyakan situasi, menerapkan Penyedia Identitas tidak menambahkan manfaat bagi bisnis, dan itu hanyalah bagian yang diperlukan untuk menerapkan layanan multipenyewa. Lebih baik menggunakan sistem identitas khusus yang dibangun, dioperasikan, dan diamankan oleh para ahli.

Ketika Anda menjalankan sistem identitas Anda sendiri, Anda perlu menyimpan hash kata sandi atau bentuk kredensial lainnya, yang menjadi target menggiurkan bagi penyerang. Bahkan hashing dan salting password sering kali tidak cukup perlindungan, karena daya komputasi yang tersedia untuk penyerang dapat memungkinkan untuk membahayakan bentuk kredensial ini.

Saat menjalankan sistem identitas, Anda juga bertanggung jawab untuk menghasilkan dan mendistribusikan kode MFA atau kata sandi satu kali (OTP). Persyaratan ini kemudian berarti Anda memerlukan mekanisme untuk mendistribusikan kode-kode ini, dengan menggunakan SMS atau email. Selain itu, Anda bertanggung jawab untuk mendeteksi serangan yang ditargetkan dan brute-force, upaya masuk pembatasan, audit, dan sebagainya.

Alih-alih membangun atau menjalankan sistem identitas Anda sendiri, ini adalah praktik yang baik untuk menggunakan layanan atau komponen di luar rak. Misalnya, pertimbangkan untuk menggunakan ID Microsoft Entra atau Azure AD B2C, yang merupakan platform identitas terkelola. Vendor platform identitas terkelola bertanggung jawab untuk mengoperasikan infrastruktur untuk platform mereka, dan biasanya untuk mendukung standar identitas dan autentikasi saat ini.

Gagal mempertimbangkan persyaratan penyewa Anda

Penyewa sering memiliki pendapat yang kuat tentang bagaimana identitas harus dikelola untuk solusi yang mereka gunakan. Misalnya, banyak pelanggan perusahaan memerlukan federasi dengan penyedia identitas mereka sendiri, untuk mengaktifkan pengalaman akses menyeluruh dan untuk menghindari pengelolaan beberapa set kredensial. Penyewa lain mungkin memerlukan autentikasi multifaktor, atau bentuk perlindungan lainnya di sekitar proses masuk. Jika Anda belum merancang untuk persyaratan ini, mungkin sulit untuk me-retrofit mereka nanti.

Pastikan Anda memahami persyaratan identitas penyewa, sebelum menyelesaikan desain sistem identitas Anda. Tinjau Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa, untuk memahami beberapa persyaratan khusus yang sering muncul.

Membingungkan pengguna dan penyewa

Penting untuk mempertimbangkan dengan jelas bagaimana solusi Anda mendefinisikan pengguna dan penyewa. Dalam banyak situasi, hubungan bisa menjadi kompleks. Misalnya, penyewa mungkin berisi beberapa pengguna, dan satu pengguna mungkin bergabung dengan beberapa penyewa.

Pastikan Anda memiliki proses yang jelas untuk melacak konteks penyewa, dalam aplikasi dan permintaan Anda. Dalam beberapa situasi, proses ini mungkin mengharuskan Anda untuk menyertakan pengidentifikasi penyewa di setiap token akses, dan bagi Anda untuk memvalidasi pengidentifikasi penyewa pada setiap permintaan. Dalam situasi lain, Anda menyimpan informasi otorisasi penyewa secara terpisah dari identitas pengguna, dan Anda menggunakan sistem otorisasi yang lebih kompleks, untuk mengelola pengguna mana yang dapat melakukan operasi mana yang terhadap penyewa mana.

Melacak konteks penyewa pengguna atau token berlaku untuk model penyewa apa pun, karena identitas pengguna selalu memiliki konteks penyewa dalam solusi multipenyewa. Ini bahkan merupakan praktik yang baik untuk melacak konteks penyewa saat Anda menyebarkan stempel independen untuk satu penyewa, yang membuktikan basis kode Anda di masa mendatang untuk bentuk multipenyewa lainnya.

Membingungkan peran dan otorisasi sumber daya

Penting bagi Anda untuk memilih model otorisasi yang sesuai untuk solusi Anda. Pendekatan keamanan berbasis peran dapat mudah diterapkan, tetapi otorisasi berbasis sumber daya memberikan kontrol yang lebih halus. Pertimbangkan persyaratan penyewa Anda, dan apakah penyewa Anda perlu mengotorisasi beberapa pengguna untuk mengakses bagian tertentu dari solusi Anda, dan bukan bagian lain.

Gagal menulis log audit

Log audit adalah alat penting untuk memahami lingkungan Anda dan bagaimana pengguna menerapkan sistem Anda. Dengan mengaudit setiap peristiwa terkait identitas, Anda sering dapat menentukan apakah sistem identitas Anda sedang diserang, dan Anda dapat meninjau bagaimana sistem Anda digunakan. Pastikan Anda menulis dan menyimpan log audit dalam sistem identitas Anda. Pertimbangkan apakah log audit identitas solusi Anda harus tersedia untuk ditinjau oleh penyewa.

Kontributor

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

Penulis utama:

Kontributor lain:

Langkah berikutnya

Tinjau Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa.