Dengan multi-tenancy, setiap penyewa (misalnya, akun atau organisasi) beroperasi dalam lingkungan terisolasi, membutuhkan kontrol akses unik yang disesuaikan dengan peran pengguna tertentu dalam lingkungan tersebut. Multi-tenant authorization Salah satu cara paling efektif untuk menerapkan otorisasi multi-penyewa adalah dengan menggabungkannya dengan RBAC menyederhanakan manajemen akses dengan mengalokasikan peran predefined yang mendikte izin mereka dalam lingkungan. Role-Based Access Control (RBAC) Kontrol Akses Berbasis Peran (Role-Based Access Control – RBAC) RBAC saja menghadapi tiga tantangan utama karena aplikasi meluas dan membutuhkan izin yang lebih halus: Karena terbatas pada peran (dan bukan atribut dan hubungan), RBAC mungkin tidak memiliki granularitas. Peran statiknya tidak memiliki kemampuan untuk meluas di seluruh penyewa. Ketika aplikasi tumbuh, jumlah peran dapat menjadi tidak dapat dikendalikan, mengakibatkan apa yang disebut “Role Explosion”. a yang memecahkan masalah ini dengan mengstrukturkan akses pengguna , memungkinkan pengalihan peran dan izin dinamis dalam lingkungan terisolasi. alih-alih mengalokasikan peran global tunggal kepada pengguna, izin mereka tergantung pada penyewa mana yang mereka miliki dan peran apa yang mereka miliki dalam penyewa tersebut. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Pikirkan tentang platform manajemen proyek SaaS di mana pengguna dapat menjadi anggota dari beberapa organisasi, masing-masing dengan tingkat akses yang berbeda: Pengguna mungkin admin dalam satu organisasi dengan kontrol penuh, sementara hanya editor di organisasi lain, terbatas pada memodifikasi tugas tetapi tidak mengelola pengguna. Pikirkan tentang platform manajemen proyek SaaS di mana pengguna dapat menjadi anggota dari beberapa organisasi, masing-masing dengan tingkat akses yang berbeda: Pengguna dapat menjadi dalam satu organisasi dengan kontrol penuh, sementara hanya satu lain, terbatas pada memodifikasi tugas tetapi tidak mengelola pengguna. admin editor Multi-tenant RBAC memastikan bahwa izin ditargetkan ke lingkungan yang tepat tanpa kompleksitas yang tidak perlu. Dalam panduan ini, kita akan mengeksplorasi dan menunjukkan bagaimana dapat diterapkan secara efisien dengan menggunakan . importance of Multi-Tenant Authorization izin saya izin saya Kami akan membahas bagaimana mengatur kebijakan, mengalokasikan peran per penyewa, dan memaksakan . fine-grained permissions Mari kita menyelam. Mengapa Multi-Tenant Authorization Penting? Multi-tenant authorization berguna untuk aplikasi di mana pengguna milik beberapa lingkungan independen, masing-masing dengan aturan aksesnya sendiri - kejadian umum di sebagian besar aplikasi berbasis cloud modern. Menggunakan izin di lingkungan terisolasi Dengan multi-tenancy, setiap pengguna dapat menerima pendekatan yang disesuaikan untuk kontrol akses mereka berdasarkan penyewa mereka.Karena pengguna mungkin memiliki peran dan tanggung jawab yang berbeda di antara penyewa yang berbeda, penggunaan multi-tenancy memungkinkan peran tersebut harus dikelola dan diterapkan secara independen. Ini berarti kami dapat menggunakan otorisasi multi-penyewa untuk mempertahankan batas yang jelas antara lingkungan sambil memastikan bahwa pengguna memiliki izin yang tepat di dalam masing-masing. Misalnya, pertimbangkan a Di mana setiap pelanggan (peniaga) menyimpan data sensitif. sangat penting untuk menegakkan kontrol akses yang ketat sehingga pengguna dari satu pelanggan tidak dapat melihat atau memodifikasi data dari yang lain. cloud storage platform Tapi mengapa kita tidak bisa menyelesaikannya hanya dengan RBAC? Mengapa RBAC Tradisional Tidak Cukup untuk Otorisasi Multi-Tenant Banyak yang dapat dikatakan tentang keterbatasan RBAC. Ketika berurusan dengan aplikasi dalam produksi, RBAC dapat terbukti terlalu kaku dan menjadi terlalu kompleks untuk skala. mari kita fokus pada aspek-aspek multi-tenancy dapat memecahkan: Static Roles Don't Scale Across Tenants: In a traditional RBAC implementation, across an application.This means a user assigned an role might have access to edit all resources, even across tenants where they shouldn’t have permissions. roles usually apply globally Editor This problem can present itself as simply as: A project management app where a user is an in one team but should only have access in another. Editor Viewer Multi-Tenant RBAC allows roles to be scoped per tenant, so a user can be an Editor in one organization and a Viewer in another without unnecessary role duplication. Speaking of role duplication - The Role Explosion Problem A basic RBAC model can start simple: . As more users and resource types are introduced, a can occur. If we take our previous example where a single user needs to be an Editor in one team but a Viewer in another, you can easily end up with something like this: Admin, Editor, Viewer role explosion Editor_TeamA Editor_TeamB Viewer_TeamA Viewer_TeamB … and so on for every additional team / potential tenant. This makes the system hard to manage and difficult to update without breaking access rules. by dynamically assigning roles within each tenant instead of hardcoding them. Multi-Tenant RBAC removes the need for tenant-specific roles Multi-Tenant Authorization Requires Granularity RBAC is often too restricted when handling permissions at a granular level. It typically lacks built-in mechanisms to define resource-level or conditional access policies. Think of this policy: "Editors can only modify their own photos" How simple is that? The thing is - there’s no way RBAC can support such a policy without implementing additional logic. Especially at scale. Sebuah aplikasi manajemen proyek di mana pengguna adalah dalam satu tim, tetapi hanya harus akses ke yang lain. Editor Viewer "Editor hanya dapat mengubah foto mereka sendiri" Sebelum kita menyelam ke implementasi dan praktik terbaik, mari kita sebutkan beberapa model multi-tenancy yang sering digunakan: Model Multi-Tenant yang umum Multi-tenant authorization berlaku untuk berbagai aplikasi. Berikut adalah beberapa cara paling umum penyewa terstruktur: Akun – Digunakan dalam aplikasi SaaS konsumen, di mana setiap pengguna milik akun independen (misalnya, Google Drive, Dropbox). Organisasi – Umum dalam aplikasi bisnis, di mana sebuah perusahaan (organisasi) memiliki beberapa pengguna dengan peran yang berbeda (misalnya, Slack, Notion). Grup – berguna untuk lingkungan kolaboratif, di mana pengguna dikelompokkan berdasarkan kebutuhan akses bersama (misalnya, tim GitHub, ruang kerja proyek). Dalam sistem di mana bisnis beroperasi di bawah model franchise, setiap franchise berfungsi secara independen tetapi mengikuti struktur sentral (misalnya, sistem manajemen restoran). Masing-masing model ini mendapat manfaat dari otorisasi Multi-Tenant untuk memastikan isolasi yang tepat dan izin berbasis peran per penyewa. Memahami manfaat otorisasi multi-penyewa, mari kita lanjutkan untuk membahas implementasi. Praktek terbaik untuk menerapkan Multi-Tenant Authorization Strategi efektif untuk mengelola peran, izin, dan skala di seluruh lingkungan terisolasi dalam aplikasi multi-tenant. Rencanakan Strategi Multi-Tenant Authorization Anda Sebelum menyelam dalam menerapkan apa pun, penting untuk merencanakan bagaimana model multi-tenant Anda akan bekerja. Berikut adalah beberapa elemen kunci yang harus Anda definisikan jika Anda menggunakan model RBAC: separate, manageable access controls Pengguna: Individu yang mengakses sistem. masing-masing dapat menjadi bagian dari beberapa penyewa. Penyewa: Lingkungan terpisah di mana pengguna beroperasi (seperti akun, organisasi, atau ruang kerja). Peran: Tingkat izin predefined yang ditugaskan kepada pengguna dalam penyewa. Sumber Daya: Obyek (misalnya, foto, dokumen) yang pengguna berinteraksi dengan, dikendalikan oleh izin. Perizinan: Aturan yang mendefinisikan tindakan yang peran dapat melakukan pada sumber daya tertentu. Dengan menjawab pertanyaan-pertanyaan ini lebih awal, Anda dapat sistem otorisasi yang disesuaikan dengan kebutuhan aplikasi Anda. flexible and scalable Memahami Multi-Tenant Tujuan Sejak a Sistem ini harus menjamin: single user can exist in multiple tenants Tugas ditugaskan per penyewa – izin pengguna harus ditargetkan ke penyewa tertentu mereka. Sumber daya terkait dengan penyewa - Sumber daya harus milik penyewa tertentu. Perizinan dinamis – Ketika pengguna membuat permintaan, sistem memeriksa peran mereka dalam penyewa dan kepemilikan sumber daya. Optimizing Multi-Tenant Authorization: Memisahkan Skema dari Data Tantangan umum dalam sistem multi-tenant adalah mengelola bagaimana Dalam sistem tradisional, peran dan izin sering dikombinasikan dengan data aplikasi. Hal ini dapat menyebabkan komplikasi ketika izin perlu diubah, karena Anda mungkin harus memperbarui kedua aplikasi. Dan yang diri sendiri roles and policies role assignment application data Untuk mengoptimalkan skala: Simpan peran, assignment, dan kebijakan dalam sistem otorisasi khusus (seperti Permit.io), dan simpan data aplikasi terpisah dari logika otorisasi. Penghapusan ini memungkinkan Anda untuk memperbarui peran atau izin secara dinamis tanpa menyentuh data inti atau basis kode aplikasi. Menggunakan Satu Sumber Kebenaran - PDP (Policy Decision Point) Salah satu konsep penting dalam mengoptimalkan otorisasi multi-tenant adalah dengan menggunakan untuk membuat keputusan politik. single source of truth Alih-alih menyimpan informasi peran dan aturan akses dalam setiap layanan atau database pengguna, bertindak sebagai titik pusat di mana semua keputusan akses dibuat. Titik Keputusan Kebijakan (PDP) Titik Keputusan Kebijakan (PDP) Benefits of using a PDP: Konsistensi: PDP memastikan bahwa semua layanan di seluruh aplikasi merujuk pada seperangkat aturan yang sama ketika membuat keputusan otorisasi. Evaluasi Kebijakan Dinamis: Perubahan kebijakan atau pengalihan peran hanya perlu diperbarui di satu lokasi — PDP. Kurang Resiko Kesalahan: Dengan mengandalkan satu titik keputusan terpusat, Anda mengurangi risiko izin yang tidak konsisten di seluruh penyewa dan aplikasi. Meningkatkan RBAC dengan Pengendalian Akses Berbasis Hubungan (ReBAC) Sementara memberikan dasar yang kuat untuk otorisasi multi-penyewa, ada skenario di mana dapat menawarkan kontrol akses yang lebih halus. RBAC Pengendalian Akses Berbasis Hubungan (ReBAC) Pengendalian Akses Berbasis Hubungan (ReBAC) RBAC mendefinisikan izin berdasarkan peran yang ditugaskan kepada pengguna, tetapi mengambil langkah lebih jauh dengan menentukan izin berdasarkan Hal ini sangat berguna dalam situasi di mana izin tergantung pada bagaimana sumber daya terhubung atau terkait satu sama lain. ReBAC relationships Misalnya, bayangkan a Jika pengguna memiliki akses ke a , dan folder tersebut berisi beberapa dokumen. dengan RBAC, Anda perlu menentukan peran seperti atau Namun, dengan Anda bisa menyederhanakan hal ini dengan mengatakan: document management system folder Folder Editor Document Viewer ReBAC "Sebuah pengguna diizinkan untuk mengedit dokumen jika mereka adalah editor folder yang dokumen itu milik." "Sebuah pengguna diizinkan untuk mengedit dokumen jika mereka adalah editor folder yang dokumen itu milik." Ini memungkinkan otorisasi otorisasi yang lebih dinamis dan kontekstual tanpa duplikasi peran untuk setiap sumber daya. : Benefits of ReBAC Perizinan Kontekstual: Memungkinkan kontrol akses berdasarkan hubungan dinamis (misalnya, pengguna yang merupakan editor dalam proyek, dan dengan demikian memiliki akses ke semua tugas terkait). Reduced Role Explosion: Anda tidak perlu membuat peran untuk setiap kombinasi pengguna dan tipe sumber daya, karena hubungan dapat mendefinisikan akses secara dinamis. Dengan memperluas RBAC dengan ReBAC, Anda dapat di mana hubungan antara pengguna dan sumber daya mendikte izin. complex access control scenarios Melakukan Multi-Tenant Authorization dengan izin saya izin saya menawarkan cara mudah untuk menerapkan otorisasi multi-penyewa dengan memungkinkan Anda untuk mendefinisikan peran, kebijakan, dan aturan akses di berbagai lingkungan. Permit.io if (user.role == admin && user.tenant == resource.tenant) { return true; } Tradisional dan statis if Menerapkan pendekatan multi-tenancy const permitted = await permit.check(user, "read", { resource: "document", tenant: "default" }); if (permitted) { return true; } dengan bersih permit.check() Fungsi yang memeriksa multi-tenancy RBAC. Berikut adalah gambaran luas tentang bagaimana otorisasi RBAC multi-tenant dapat diatur di Permit.io: Define Roles, Resources, and Actions: To get started, first define your resources (e.g., documents, photos, tasks) and the actions that can be performed on them (e.g., create, read, update, delete). Add a (e.g., ) to represent the type of object you want to control access to. new resource blog Specify the resource's , which will be used in your API calls. key Define the users should be able to perform on the resource (e.g., create, read, update, delete). actions The screenshot shows an example where is the resource, and actions are defined for it. blog Define the Access Control Policy: You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like , , and are defined, and the policy is set up to specify which actions are permitted for each role. admin public Writer Define the Tenants in the Directory: Each tenant can have its own set of roles, permissions, and policies. To create tenants: Go to the screen and click on . Directory Settings Define the tenants you need (e.g., , , etc.). Tenant 1 Tenant 2 Create Users and Assign Roles: Once the tenants are defined, you can create users and assign them roles specific to each tenant. This ensures that the same user can have different roles in each tenant, depending on what permissions they need. To create a new user: Click in the screen. Add User Directory Assign the user a unique and other user details (e.g., email, first name). key In the section, you can assign the user roles specific to the tenant to which they belong. Permissions Per Tenant For instance, the user could be an in and a in , as shown in the screenshot: Admin Tenant 1 Writer Tenant 2 Di sini, kita dapat melihat semua pengguna kami dan peran apa yang mereka miliki dalam setiap penyewa yang mereka miliki: Beberapa manfaat menggunakan Permit.io untuk otorisasi penyewa multi termasuk: Manajemen kebijakan terpusat: Tentukan dan mengelola semua aturan dan kebijakan otorisasi Anda dari platform terpusat. ini menyederhanakan perubahan kebijakan dan memastikan penegakan yang konsisten di seluruh penyewa Anda. Role-Specific Role Assignment: Mudah menetapkan dan mengelola peran per penyewa, memungkinkan pengguna untuk memiliki peran yang berbeda di lingkungan yang berbeda (misalnya, Admin di satu penyewa, Viewer di lain). Mengimplementasikan izin terperinci untuk setiap sumber daya dan menegakkan izin terperinci yang kompleks (seperti yang didasarkan pada atribut atau hubungan) tanpa perlu logika khusus tambahan. Dukungan ReBAC: Permit.io memperluas model RBAC tradisional dengan ReBAC, memungkinkan Anda untuk mendefinisikan izin berdasarkan tidak hanya peran pengguna tetapi juga hubungan antara pengguna dan sumber daya. Summing Up: Multi-Tenant Authorization dengan RBAC Dalam blog ini, kami telah mengeksplorasi Bagaimana mengkombinasikannya dengan memungkinkan manajemen izin pengguna yang lebih efisien dan dapat diperluas di seluruh lingkungan terpencil. importance of multi-tenant authorization Role-Based Access Control (RBAC) Kami telah membahas tantangan RBAC tradisional dalam aplikasi multi-tenant dan bagaimana Multi-Tenant RBAC memecahkan masalah seperti peran statik, ledakan peran, dan kontrol akses biji halus. Dengan otorisasi multi-penyewa, setiap penyewa dapat memiliki kontrol akses terisolasi sendiri, memastikan bahwa pengguna hanya memiliki akses ke apa yang mereka otorisasi dalam lingkungan tertentu mereka. memungkinkan Anda untuk mengimplementasikan otorisasi multi-penyewa dengan cara yang lebih efisien, berkat manajemen kebijakan terpusat, alokasi peran khusus penyewa, izin halus, dan dukungan untuk Kontrol Akses Berbasis Hubungan (ReBAC). Permit.io What’s Next? Jelajahi dokumentasi Permit.io untuk mulai menerapkan otorisasi multi-tenant dalam aplikasi Anda. Bergabunglah dengan komunitas Permit.io untuk mendiskusikan praktik terbaik dan mendapatkan dukungan.
