本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 隔離層級 您將客戶轉移到多租用戶模型中的次數越多，他們就越擔心一個租用戶存取另一個租用戶的資源的可能性。SaaS 系統包含明確的機制，可確保每個租用戶的資源（即使在共用基礎架構上執行）都是隔離的。 這就是我們所說的*租戶隔離*。租用戶隔離背後的想法是，您的 SaaS 架構引入了可嚴格控制資源存取的結構，並阻止任何嘗試存取其他租用戶資源的嘗試。 請注意，租用戶隔離與一般安全性機制是分開的。您的系統將支援驗證和授權；不過，租用戶使用者經過驗證並不表示您的系統已達到隔離狀態。隔離與可能是應用程式一部分的基本驗證和授權分開套用。 為了更好地理解這一點，假設您已經使用身份提供者來驗證對 SaaS 系統的訪問。此驗證體驗的 Token 也可能包含使用者角色的相關資訊，這些資訊可用來控制該使用者對特定應用程式功能的存取。這些結構提供安全性，但不是隔離。事實上，用戶可以通過身份驗證和授權，並且仍然可以訪問另一個租用戶的資源。關於身份驗證和授權的任何內容都不會阻止此訪問。 租用戶隔離專門著重於使用租用戶內容來限制對資源的存取。它會評估目前承租人的前後關聯，並使用該前後關聯來決定該承租人可存取的資源。它會將此隔離套用至該承租人內的所有使用者。 當我們研究如何在所有不同的 SaaS 架構模式中實現租戶隔離時，這會變得更具挑戰性。在某些情況下，可以透過將整個資源堆疊專用於租用戶來實現隔離，而網路 (或更粗糙的) 原則會阻止跨租用戶存取。在其他情況下，您可能有共用資源 ([Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 表格中的項目)，這些資源需要更精細的政策來控制對資源的存取。 任何嘗試存取承租人資源的作用範圍應僅限於屬於該承租人的資源。SaaS 開發人員和架構師的工作是確定哪些工具和技術組合將支援特定應用程式的隔離需求。