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