本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Verified Permissions 多租戶設計考量事項
當您在多租用戶 SaaS 解決方案中使用 Amazon Verified Permissions 實作授權時，需要考慮幾個設計選項。在探索這些選項之前，讓我們釐清多租用戶 SaaS 內容中*隔離*和*授權*之間的差異。[隔離](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html)租用戶可防止傳入和傳出資料公開給錯誤的租用戶。授權可確保使用者具有存取租用戶的許可。
在 Verified Permissions 中，政策會存放在政策存放區中。如 [Verified Permissions 文件](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html)中所述，您可以針對每個租用戶使用個別的政策存放區來隔離租用戶的政策，或針對所有租用戶使用單一政策存放區來允許租用戶共用政策。本節討論這兩種隔離策略的優點和缺點，並說明如何使用分層部署模型進行部署。如需其他內容，請參閱 Verified Permissions 文件。
雖然本節討論的 critieria 著重於 Verified Permissions，但一般概念是以[隔離思維](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html)及其提供的指引為基礎。SaaS 應用程式必須一律將[租戶隔離](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html)視為其設計的一部分，而此一般隔離原則延伸到在 SaaS 應用程式中包含驗證許可。本節也參考核心 SaaS 隔離模型，例如[孤立 SaaS 模型](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html)和[集區 SaaS 模型](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)。如需詳細資訊，請參閱 AWS Well-Architected Framework SaaS Lens 中的[核心隔離概念](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html)。
設計多租戶 SaaS 解決方案時的主要考量事項是租戶隔離和租戶加入。租用戶隔離會影響安全性、隱私權、彈性和效能。租戶加入會影響您的營運程序，因為它與營運開銷和可觀測性相關。經歷 SaaS 旅程或實作多租戶解決方案的組織，一律必須優先考慮 SaaS 應用程式處理租用的方式。雖然 SaaS 解決方案可能傾向於特定隔離模型，但在整個 SaaS 解決方案中不一定需要一致性。例如，您為應用程式的前端元件選擇的 隔離模型可能與您為微型服務或授權服務選擇的隔離模型不同。
**Topics**
+ [租戶加入和使用者租戶註冊](avp-design-onboarding-registration.md)
+ [每個租戶政策存放區](avp-design-per-tenant-store.md)
+ [一個共用多租戶政策存放區](avp-design-shared-store.md)
+ [分層部署模型](avp-design-tiered.md)
# 租戶加入和使用者租戶註冊
SaaS 應用程式會觀察[ SaaS 身分](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html)的概念，並遵循將[使用者身分繫結至租用戶身分](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html)的一般最佳實務。繫結涉及將租戶識別符儲存為身分提供者中使用者的宣告或屬性。這會轉移將身分映射到租用戶的責任，從每個應用程式映射到使用者註冊程序。然後，每個已驗證的使用者都會擁有正確的租戶身分，做為 JSON Web Token (JWT) 的一部分。
同樣地，為授權請求選擇正確的政策存放區不應由應用程式邏輯決定。若要判斷特定授權請求應使用的政策存放區，請維護使用者與政策存放區或租用戶與政策存放區的映射。這些映射通常會維護在您的應用程式參考的資料存放區中，例如 Amazon DynamoDB 或 Amazon Relational Database Service (Amazon RDS)。您也可以透過身分提供者 (IdP) 中的資料提供或補充這些映射。然後，租用戶、使用者和政策存放區之間的關係通常會透過 JWT 提供給使用者，其中包含授權請求所需的所有關係。
此範例顯示 JWT 如何為屬於租用戶的使用者 顯示`Alice`，`TenantA`並使用具有政策存放區 ID 的政策存放區`ps-43214321`進行授權。
```
{
"sub":"1234567890",
"name":"Alice",
"tenant":"TenantA",
"policyStoreId":"ps-43214321"
}
```
# 每個租戶政策存放區
Amazon Verified Permissions 中的每個租用戶政策存放區設計模型會將 SaaS 應用程式中的每個租用戶與其自己的政策存放區建立關聯。此模型類似於 SaaS [孤立隔離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html)模型。這兩種模型都需要建立租戶特定的基礎設施，並具有類似的優點和缺點。此方法的主要優點是基礎設施強制執行租用戶隔離、支援每個租用戶的唯一授權模型、消除[雜訊鄰近](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)問題，以及減少政策更新或部署失敗的影響範圍。此方法的缺點包括更複雜的租戶加入程序、部署和操作。如果解決方案具有每個租用戶的唯一政策，則建議使用每個租用戶政策存放區。
如果您的 SaaS 應用程式需要，每個租戶政策存放區模型可以提供高度孤立的租戶隔離方法。您也可以將此模型與[集區隔離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)搭配使用，但您的 Verified Permissions 實作不會共用更廣泛的集區隔離模型的標準優點，例如簡化的管理和操作。
在各租用戶政策存放區中，租用戶隔離是透過在使用者註冊程序期間將租用戶的政策存放區識別符映射至使用者的 SaaS 身分來實現，如前所述。此方法會將租戶的政策存放區與使用者主體緊密關聯，並提供在整個 SaaS 解決方案 中共用映射的一致方式。您可以透過將 SaaS 應用程式維護為 IdP 的一部分或在 DynamoDB 等外部資料來源中提供映射。這也可確保委託人是租用戶的一部分，並使用租用戶的政策存放區。
此範例顯示包含 `tenant` `policyStoreId`和 使用者的 JWT 如何從 API 端點傳遞到 AWS Lambda 授權方中的政策評估點，該授權方會將請求路由到正確的政策存放區。
![\[Amazon Verified Permissions 中的每個租戶政策存放區模型\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png)
下列範例政策說明每個租用戶的政策存放區設計範例。使用者`Alice`屬於 `TenantA.` policyStoreId `store-a`也會對應至 的租戶身分，`Alice,`並強制使用正確的政策存放區。這可確保`TenantA`使用 的政策。
**注意**
每個租用戶的政策存放區模型會隔離租用戶的政策。授權會強制執行允許使用者對其資料執行的動作。使用這個模型的任何假設性應用程式中涉及的資源應使用其他隔離機制進行隔離，如 [AWS Well-Architected Framework SaaS Lens 文件](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html)所定義。
在此政策中， `Alice`具有檢視所有 資源資料的許可。
```
permit (
principal == MultiTenantApp::User::"Alice",
action == MultiTenantApp::Action::"viewData",
resource
);
```
若要提出授權請求並使用 Verified Permissions 政策開始評估，您需要提供對應至對應至租用戶的唯一 ID 的政策存放區 ID`store-a`。
```
{
"policyStoreId":"store-a",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
使用者`Bob`屬於租戶 B，且 policyStoreId `store-b`也會對應至 的租戶身分`Bob`，強制使用正確的政策存放區。這可確保使用租用戶 B 的政策。
在此政策中， `Bob`具有自訂所有資源資料的許可。在此範例中， `customizeData`可能是僅適用於租用戶 B 的動作，因此政策對於租用戶 B 是唯一的。每個租用戶的政策存放區模型本質上支援每個租用戶的自訂政策。
```
permit (
principal == MultiTenantApp::User::"Bob",
action == MultiTenantApp::Action::"customizeData",
resource
);
```
若要提出授權請求並使用 Verified Permissions 政策開始評估，您需要提供對應至對應至租用戶的唯一 ID 的政策存放區 ID`store-b`。
```
{
"policyStoreId":"store-b",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"customizeData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
使用 Verified Permissions，可以但不需要將 IdP 與政策存放區整合。此整合可讓 政策明確參考身分存放區中的委託人做為政策的委託人。如需如何將 與 Amazon Cognito 整合為 Verified Permissions IdP 的詳細資訊，請參閱 [Verified Permissions 文件](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)和 [Amazon Cognito 文件](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)。
當您將政策存放區與 IdP 整合時，每個政策存放區只能使用一個[身分來源](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)。例如，如果您選擇將 Verified Permissions 與 Amazon Cognito 整合，則必須鏡像用於租戶隔離 Verified Permissions 政策存放區和 Amazon Cognito 使用者集區的策略。政策存放區和使用者集區也必須位於相同的 中 AWS 帳戶。
![\[將已驗證許可與每個租用戶的設計模型中的 Amazon Cognito 整合\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png)
在操作層級上，每個租用戶政策存放區具有稽核優勢，因為您可以為每個租用戶單獨查詢 [中的記錄活動](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail 。不過，仍建議您將每個租用戶維度上的其他自訂指標記錄到 Amazon CloudWatch。
每個租用戶的政策存放區方法也需要密切注意兩個[已驗證許可配額](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)，以確保它們不會干擾 SaaS 解決方案的操作。這些配額是*每個帳戶每個區域的政策存放*區，以及*每個帳戶每個區域的每秒 IsAuthorized 請求*。您可以為這兩個配額請求增加。
如需如何實作每個租用戶政策存放區模型的更詳細範例，請參閱 AWS 部落格文章[使用 Amazon Verified Permissions 搭配每個租用戶政策存放區的 SaaS 存取控制](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/)。
# 一個共用多租戶政策存放區
一個共用多租用戶政策存放區設計模型針對 SaaS 解決方案中的所有租用戶，使用 Amazon Verified Permissions 中的單一多租用戶政策存放區。此方法的主要優點是簡化管理和操作，特別是因為您不必在租戶加入期間建立額外的政策存放區。此方法的缺點包括因政策更新或部署中的任何失敗或錯誤而增加影響範圍，以及更容易受到[雜訊鄰近](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)影響。此外，如果您的解決方案需要每個租用戶的唯一政策，我們不建議使用此方法。在此情況下，請改用每個租用戶的政策存放區模型，以確保使用正確租用戶的政策。
一個共用的多租戶政策存放區方法類似於 SaaS [集區隔離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)模型。如果您的 SaaS 應用程式需要，它可以提供租戶隔離的集區方法。如果您的 SaaS 解決方案將[孤立隔離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html)套用至其微服務，您也可以使用此模型。當您選擇模型時，您應該評估租戶資料隔離的需求，以及 SaaS 應用程式獨立所需的 Verified Permissions 政策結構。
若要在整個 SaaS 解決方案中強制執行一致的租用戶識別符共用方式，最佳實務是在使用者註冊期間將識別符映射到使用者的 SaaS 身分，如先前所述。您可以將此映射作為 IdP 的一部分或在 DynamoDB 等外部資料來源中維護，以將此映射提供給 SaaS 應用程式。我們也建議您將共用政策存放區 ID 映射至使用者。雖然 ID 不會用作租戶隔離的一部分，但這是很好的做法，因為它有助於未來的變更。
下列範例顯示 API 端點如何為`Bob`屬於不同租用戶但與政策存放區 ID 共用以進行`store-multi-tenant`授權的使用者`Alice`和 傳送 JWT。由於所有租戶共用單一政策存放區，您不需要在字符或資料庫中維護政策存放區 ID。由於所有租用戶共用單一政策存放區 ID，因此您可以提供 ID 做為環境變數，供應用程式用來呼叫政策存放區。
![\[Verified Permissions 共用設計模型\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png)
下列範例政策說明一個共用的多租用戶政策設計範例。在此政策中，具有父系 `MultiTenantApp::User`的委託人`MultiTenantApp::Role``Admin`具有檢視所有資源資料的許可。
```
permit (
principal in MultiTenantApp::Role::"Admin",
action == MultiTenantApp::Action::"viewData",
resource
);
```
由於單一政策存放區正在使用中，Verified Permissions 政策存放區必須確保與委託人相關聯的租用屬性符合與資源相關聯的租用屬性。這可以透過在政策存放區中包含下列政策來完成，以確保資源和主體上沒有相符租用屬性的所有授權請求都會遭到拒絕。
```
forbid(
principal,
action,
resource
)
unless {
resource.Tenant == principal.Tenant
};
```
對於使用一個共用多租用戶政策存放區模型的授權請求，政策存放區 ID 是共用政策存放區的識別符。在下列請求中，`User``Alice`允許存取 ，因為她具有 `Role`的 `Admin`，並且與資源和主體相關聯的`Tenant`屬性都是 `TenantA`。
```
{
"policyStoreId":"store-multi-tenant",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"viewData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Alice"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[
{
"entityType":"MultiTenantApp::Role",
"entityId":"Admin"
}
]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes": {
{
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents":[]
}
]
}
}
```
使用 Verified Permissions，可以但不需要將 IdP 與政策存放區整合。此整合可讓 政策明確參考身分存放區中的委託人做為政策的委託人。如需如何將 與 Amazon Cognito 整合為 Verified Permissions IdP 的詳細資訊，請參閱 [Verified Permissions 文件](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)和 [Amazon Cognito 文件](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)。
當您將政策存放區與 IdP 整合時，每個政策存放區只能使用一個[身分來源](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)。例如，如果您選擇將 Verified Permissions 與 Amazon Cognito 整合，則必須鏡像用於租戶隔離 Verified Permissions 政策存放區和 Amazon Cognito 使用者集區的策略。政策存放區和使用者集區也必須位於相同的 中 AWS 帳戶。
![\[在共用設計模型中整合 Verified Permissions 與 Amazon Cognito\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)
從操作和稽核的觀點來看，一個共用的多租用戶政策存放區模型具有缺點，因為 [中記錄的活動 AWS CloudTrail](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)需要更多涉及的查詢來篩選租用戶上的個別活動，因為每個記錄的 CloudTrail 呼叫都使用相同的政策存放區。在此案例中，將每個租用戶維度上的其他自訂指標記錄到 Amazon CloudWatch，以確保適當的可觀測性和稽核功能。
一種共用的多租用戶政策存放區方法也需要密切注意[已驗證許可配額](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)，以確保它們不會干擾 SaaS 解決方案的操作。特別是，我們建議您監控*每個區域每個帳戶配額每秒的 IsAuthorized 請求*，以確保不超過其限制。您可以請求提高此配額。
# 分層部署模型
透過建立分層部署模型，您可以隔離高優先順序的「企業層」租用戶與可能更高數量的「標準層」客戶。在此模型中，您可以針對每個層分別推出政策存放區中部署到政策的任何變更，這會隔離每個客戶層與其層之外所做的變更。在分層部署模型中，政策存放區通常會在每個層的初始基礎設施佈建中建立，而不是在租戶加入時部署。
如果您的解決方案主要使用集區隔離模型，您可能需要額外的隔離或自訂。例如，您可以建立一個「高級方案」，其中每個租用戶都會取得自己的租用戶方案基礎設施，透過部署只有一個租用戶的集區執行個體來建立孤立模型。這可以採用完全分開的「Premium Tier 租用戶 A」和「Premium Tier 租用戶 B」基礎設施的形式，包括政策存放區。此方法可為最高層級的客戶產生孤立隔離模型。
在分層部署模型中，每個政策存放區都應該遵循相同的隔離模型，但會分別部署。由於使用多個政策存放區，因此您需要在整個 SaaS 解決方案中強制執行共用與租用戶相關聯之政策存放區識別符的一致方式。如同每個租用戶的政策存放區模型，在使用者註冊期間，將租用戶識別符映射到使用者的 SaaS 身分是很好的做法。
下圖顯示三個層：`Standard Tier`、 `Enterprise Tier`和 `Premium Tier 1`。每個層都會分別部署在自己的基礎設施中，並在層中使用一個共用政策存放區。標準和企業方案包含多個租用戶。 `TenantA`和 `TenantB` 位於 `Standard Tier`， `TenantC` 和 `TenantD` 位於企業方案。
`Premium Tier 1` 僅包含 `TenantP`，因此您可以像解決方案具有完全孤立的隔離模型一樣為高級租戶提供服務，並提供自訂政策等功能。加入新的高級方案客戶將導致建立`Premium Tier 2`基礎設施。
**注意**
高級方案中的應用程式、部署和租戶加入與標準和企業方案相同。唯一的差別在於，進階方案加入工作流程從佈建新的方案基礎設施開始。
![\[Verified Permissions 分層部署模型\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)