設置多租戶認證與授權的終極指南
創建多租戶應用可能很複雜。本文收集了我們過去所有關於多租戶和組織策略的文章。我們希望它可以幫助你節省時間並輕鬆開始。
Product & Design
構建多租戶應用是具有挑戰性的，需要考慮很多方面。本文匯集了我們先前所有對多租戶和組織實踐的博客文章。為了快速開始和節省時間，只需查看這篇文章，它包含你需要的所有內容！
一般指導原則概括在以下步驟中：
- 了解多租戶架構
- 映射你的多租戶應用用例
- 實現租戶隔離
- 定義你想如何管理身份
- 選擇合適的授權模型
什麼是多租戶架構
軟件多租戶是一種軟件架構，其中單一實例的軟件在服務器上運行並為多個租戶服務。這種設計的系統是“共享的”（而不是“專用的”或“隔離的”）。
租戶是一組共享對軟件實例的特定權限訪問的用戶。
多租戶的一個關鍵思想是“共享”。在多租戶的更廣泛定義中，成為多租戶應用並不意味著解決方案中的每一個組件都是共享的。相反，這意味着解決方案的至少一些組件在多個租戶之間重用。廣泛地理解這個術語可以更好地幫助你理解客戶的需求及其來源。
一旦你了解了多租戶架構，下一步就是將你的應用應用到現實場景中，專注於具體的產品和業務需求。
多租戶應用的用例有哪些？
SaaS 中的多租戶
多租戶應用經常出現在業務對業務 (B2B) 解決方案中，例如生產力工具、協作軟件和其他軟件即服務 (SaaS) 產品。在這種情況下，每個“租戶”通常代表一個商業客戶，商業客戶可能擁有多個用戶（即其員工）。此外，商業客戶可能會擁有多個租戶來代表不同的組織或業務部門。
一般 B2B 用例中的多租戶
B2B 應用超出了 SaaS 產品的範圍，並且通常涉及多租戶應用的使用。在 B2B 情境中，這些應用作為一個共同的平台，供不同的團隊、商業客戶和合作公司訪問你的應用。
例如，考慮一家提供 B2C 和 B2B 應用的網約車公司。B2B 應用服務於多個商業客戶，採用多租戶架構可以幫助管理他們的員工和資源。舉例來說，如果該公司希望維持一個統一的用戶身份系統，它可以設計如以下示例的架構：
Sarah 既有個人身份又有商業身份。她以乘客身份使用網約車服務，也在空閒時以司機身份工作。在她的職業角色中，她同時管理她的業務，並使用這一商業身份與企業 1 成為合作夥伴。
為什麼應該在 SaaS 產品中使用多租戶架構
利用多租戶進行擴展
對於企業業務，多租戶是有效滿足其對可用性、資源管理、成本管理和數據安全需求的關鍵。在技術層面，採用多租戶方法簡化了開發流程，最小化了技術挑戰，並促進了無縫的擴展。
創建統一的體驗
檢查 SaaS 產品的根源時，它類似於一棟房子中的不同公寓。所有租戶共享諸如水、電、煤氣等公共設施，但他們仍然對管理自己的空間和資源保持獨立控制。這種方法簡化了管理。
通過租戶隔離確保安全
在多租戶架構中，引入了“租戶”這個術語，以創建邊界並在共享實例中將不同租戶的資源和數據隔離並保護起來。這確保即便是使用相同的底層資源，每個租戶的數據和運營仍然保持獨立和安全。
為什麼應該實現租戶隔離？
討論多租戶應用時，始終需要實現 租戶隔離。這意味著在共享系統中（例如，雲基礎設施或多租戶應用程序）將不同租戶的數據和資源分開並保持安全。這可以防止任何未經授權的企圖訪問其他租戶的資源。
儘管解釋可能看起來很抽象，但我們將使用示例和關鍵細節來進一步解釋隔離思維方式，以及實現租戶隔離的最佳實踐。
租戶隔離並不違背多租戶的“共享”心態
這是因為租戶隔離不一定是一個基礎設施資源級別的構造。在多租戶和隔離的領域中，有些人將隔離視為對實際基礎設施資源的嚴格區分。這通常導致一個模型，每個租戶擁有單獨的數據庫、計算實例、帳戶或私有雲。在共享資源的情景中，如多租戶應用，實現隔離可以是一種邏輯上的構造。
租戶隔離專注於使用“租戶”上下文來限制對資源的訪問。它評估當前租戶的上下文，並使用該上下文來確定哪些資源對該租戶是可訪問的。
認證和授權不等於“隔離”
使用認證和授權來控制對你 SaaS 環境的訪問是很重要的，但單靠它們還不足以完成隔離。這些機制只是安全拼圖的一部分。
人們常常問一個問題，我可以使用通用授權解決方案和基於角色的訪問控制來實現租戶隔離嗎？
事實上，你可以建立多租戶應用，但不能說你實現並採用了租戶隔離策略作為最佳實踐。我們通常不推薦這樣做，因為
舉例來說，考慮你已經為你的 SaaS 系統設置了認證和授權。當用戶登錄時 ，他們會收到一個包含其角色信息的令牌，指示他們可以在應用中做什麼。這種方法提高了安全性，但不保證隔離。
使用“組織”來代表 SaaS 產品租戶，以實現租戶隔離
僅依靠認證和授權無法阻止具有正確角色的用戶訪問另一租戶的資源。因此，我們需要納入“租戶”上下文，如租戶 ID，以限制對資源的訪問。
這就是租戶隔離發揮作用的地方。它使用租戶特定的標識符來建立邊界，就像牆壁、門和鎖一樣，確保租戶之間有明確的分隔。
多租戶應用中的身份管理
我們討論了租戶隔離，但身份呢？如何決定你的身份是否應該“隔離”？
在“身份隔離”這個概念上經常存在混淆。通常指的是一個現實世界用戶在一般理解中擁有兩個身份的情況。
- 兩個身份可以存在於單一身份系統中。例如，Sarah 可能同時註冊了一個個人郵箱和一個通過單一登錄 (SSO) 連接的公司郵箱。
- 用戶在單獨的身份系統中維持兩個不同的身份，代表完全不同的產品。這些產品彼此完全無關。
有時，這些情景被稱為“身份隔離”，但這個標籤可能無助於做出決定。
而不是決定你是否需要“身份隔離”，可以考慮
這個答案可以指導你的系統設計。關於多租戶應用的簡短回答是，
在多租戶應用中，身份與租戶特定的資源和數據不同，它們在多個租戶之間共享。想像你自己是建築管理員，你不會想要維持兩份獨立的名冊來管理你的租戶身份。
當旨在實現租戶隔離時，你可能已經注意到對“組織”這個術語的反覆強調，這通常被視為構建多租戶應用的最佳實踐。
通過使用“組織”的概念，你可以在你的多租戶應用中實現租戶隔離，同時保持統一的身份系統。
如何選擇和設計適當的授權模型
當選擇合適的授權模型時，考慮以下問題：
- 你是在開發 B2C、B2B 還是兩者結合的產品？
- 你的應用是否具有多租戶架構？
- 根據業務單位，是否有必要在你的應用中設置某個隔離級別？
- 在組織的上下文中需要定義哪些許可權和角色，哪些不需要？
Logto 中有哪些不同的授權模型可用？
基於角色的訪問控制
RBAC（基於角色的訪問控制）是一種根據用戶角色授權許可的管理資源訪問的方法。
這種常見技術為訪問控制提供支持，是 Logto 授權功能的關鍵組成部分。作為一個全面的身份管理平台，Logto 為不同層次和實體提供量身定做的解決方案，以滿足開發者和企業的多樣化產品架構需求。
API 基於角色的訪問控制
為了保護那些非特定於任何組織且不需要上下文限制的 API 資源，API RBAC 功能是理想之選。
只需註冊 API 並將許可權賦予每個資源。然後，通過角色與用戶之間的關係來控制訪問。
這裡的 API 資源、角色和許可權在統一的身份系統下是“民主化的”。這在具有較少層次結構且不需要非常深層隔離的 B2C 產品中非常常見。
組織基於角色的訪問控制
在 B2B 和多租戶環境中，需要租戶隔離。為了實現這一點，組織被用作隔離的上下文，這意味着 RBAC 只有當用戶屬於特定組織時才有效。
組織 RBAC 專注於在組織級別的訪問控制而不是API級別的，這從長遠來看為組織級別的自我管理提供了顯著的靈活性，同時仍在統一的身份系統中。
組織 RBAC 的一個關鍵特點是角色和許可權通常在默認情況下在所有組織中都是相同的，這使得 Logto 的“組織模板”在提高開發效率方面非常有意義。這與多租戶應用的共享 理念相一致，訪問控制策略和身份是所有租戶（應用租戶）的共同基礎設施組件，這在 SaaS 產品中是一種常見做法。
結束語
本文提供了所有你需要的信息來準備和配置多租戶應用。今天就試試 Logto，開始應用多租戶應用開發的最佳實踐與方案。