多租戶應用程式中的租戶隔離
租戶隔離是多租戶應用程式中的一個關鍵概念。在本文中，我們將討論什麼是租戶隔離以及如何實現它。
Product & Design
大家好！在這一章中，我們將基於之前關於多租戶主題的討論進行拓展。如果你還沒有閱讀之前的文章，我們建議先從那些文章開始！
在討論多租戶應用程式時，重要的是考慮租戶隔離。這意味著在共享系統（例如，雲基礎設施或多租戶應用程式）中保持不同租戶的數據和資源分開並安全。
租戶隔離的目標是確保每個租戶的數據和操作在使用相同的底層資源時仍然保持獨立和安全。
在軟體即服務（SaaS）的場景中，租戶隔離涉及在 SaaS 框架內創建嚴格管理資源訪問的結構。這防止任何未經授權的嘗試來訪問其他租戶的資源。
雖然解釋可能顯得抽象，我們將使用示例和關鍵細節進一步解釋隔離的思維方式。
租戶隔離不違反多租戶的"共享"思維方式
這是因為租戶隔離不一定是基礎設施資源級別的結構。在多租戶和隔離的領域中，有些人將隔離視為實際基礎設施資源之間的嚴格劃分。這通常導致每個租戶都擁有單獨的資料庫、計算實例、賬戶或私有雲的模型。在共享資源的場景中，比如多租戶應用程式，實現隔離的方式可以是一種邏輯結構。
租戶隔離專注於使用“租戶”上下文來限制資源的訪問。它評估當前租戶的上下文，並使用該上下文來確定哪些資源對該租戶是 可訪問的。它將這種隔離應用於該租戶內的所有用戶。任何訪問租戶資源的嘗試都應局限於該租戶所屬的資源。
隔離存在不同的層次
當我們明白隔離並不完全與基礎設施資源級別相關，也不是物理基礎設施之間的明確分離時，就會有這樣的結論：
與其將隔離視為簡單的“是”或“否”，不如將其視為一個光譜。你可以根據需求設置你的系統以使部分功能更加或較少隔離。
下圖說明了這個隔離的光譜。
認證和授權不等同於“隔離”
使用認證和授權來控制 SaaS 環境的訪問是重要的，但它不足以實現完全隔離。這些機制只是安全拼圖的一部分。
人們常常提出一個問題，我能否使用通用授權解決方案和基於角色的訪問控制來實現租戶隔離？你可以構建一個多租戶應用程式，但你不能說你已經實現並採用了租戶隔離策略作為最佳實踐。 我們通常不推薦這樣做，因為
為了說明這一點，想想這樣一種情況，你已經為你的 SaaS 系統設置了認證和授權。當用戶登錄時，他們會收到一個包含其角色信息的令牌，規定他們在應用程式中可以做什麼。這種方法提高了安全性，但不能保證隔離。
現在，問題來了：如果不加入像租戶 ID 這樣的“租戶”上下文來限制資源的訪問，單靠認證和授權無法防止具有正確角色的用戶訪問其他租戶的資源。
這就是租戶隔離發揮作用的地方。它使用租戶特定的識別符建立邊界，就像牆壁、門和鎖一樣，確保租戶之間有明確的分離。
多租戶應用程式中的身份
我們討論了租戶隔離，那麼身份呢？你如何決定你的身份是否應該被“隔離”？
對於“身份隔離”的概念通常存在混淆。它可能指的是一個真實世界的用戶在一般理解中有兩個身份的情況。
- 這兩個身份可以存在於一個身份系統中。例如，Sarah 可能有一個註冊的個人電子郵件，以及用單一登錄（SSO）連接的公司電子郵件。
- 用戶在不同的身份系統中保持兩個不同的身份，代表完全不同的產品。這些產品彼此完全無關。
有時，這些場景被稱為"身份隔離"。然而，這個標籤可能對做決定沒有幫助。
與其決定是否需要“身份隔離”，不如考慮你或你的業務或產品的某個部分是否需要維持單獨的身份系統。這個答案可以指導你的身份和訪問管理（IAM）系統設計。對於有關多租戶應用程式的簡短回答，
在大多數情況下，在多租戶應用程式中，身份是共享的，同時每個租戶的資源是隔離的。
在多租戶應用程式中，身份，不同於租戶特定的資源和數據，是在多個租戶之間共享的。把自己想像成建築管理者；你不會想要維持兩個單 獨的名單來管理租戶的身份。
當目標是租戶隔離時，你可能會注意到反覆強調的"組織"這個術語，它通常被視為構建多租戶應用程式的最佳實踐。
通過使用“組織”這一概念，你可以在維持統一身份系統的同時實現在多租戶應用程式中的租戶隔離。這允許多個“組織”共存，獨立存在，但在應用程式內共享與租戶無關的資源。就像住在建築物中的居民，每個組織在不必擔心鄰居的情況下使用應用程式，因為"組織"以牆壁、走廊、門和鎖的形式提供必要的分離。它們共享整體建築基礎設施、內部設計系統以及各種有形或無形組件。
Logto 在十一月引入"組織"功能
Logto 目前正在積極開發 "組織"功能，預計在 2023 年 11 月推出。這一功能旨在滿足構建 SaaS 產品所需的租戶隔離要求，符合行業標準和最佳實踐。
在即將到來的章節中，我們將深入探討 "組織" 功能，以及 Logto 如何促進構建多租戶應用程式的最佳實踐。