기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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 설명서를 참조하세요.
이 단원에서 설명한 기준은 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 애플리케이션에 Verified Permissions를 포함하는 것으로 확장됩니다. 또한이 섹션에서는 사일로화된 SaaS 모델 및 [풀링된 SaaS 모델과 같은 핵심 SaaS 격리 모델을](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) 참조합니다. [ SaaS ](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-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)
+ [공유 다중 테넌트 정책 스토어 1개](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 웹 토큰(JWT)의 일부로 올바른 테넌트 자격 증명을 갖게 됩니다.
마찬가지로 권한 부여 요청에 대한 올바른 정책 스토어 선택은 애플리케이션 로직에 의해 결정되어서는 안 됩니다. 특정 권한 부여 요청이 사용해야 하는 정책 스토어를 확인하려면 사용자를 정책 스토어에 매핑하거나 테넌트를 정책 스토어에 매핑합니다. 이러한 매핑은 일반적으로 애플리케이션이 참조하는 Amazon DynamoDB 또는 Amazon Relational Database Service(RDS)와 같은 데이터 스토어에서 유지됩니다. 자격 증명 공급자(IdP)의 데이터로 이러한 매핑을 제공하거나 보완할 수도 있습니다. 그런 다음 테넌트, 사용자 및 정책 저장소 간의 관계는 일반적으로 권한 부여 요청에 필요한 모든 관계가 포함된 JWT를 통해 사용자에게 제공됩니다.
이 예제는 테넌트에 `Alice`속`TenantA`하고 권한 부여를 위해 정책 스토어 ID와 함께 정책 스토어를 사용하는 사용자에 `ps-43214321` 대해 JWT가 어떻게 표시되는지 보여줍니다.
```
{
"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 솔루션에서 매핑을 공유하는 일관된 방법을 제공합니다. IdP의 일부로 유지 관리하거나 DynamoDB와 같은 외부 데이터 소스에서 SaaS 애플리케이션에 매핑을 제공할 수 있습니다. 또한 보안 주체가 테넌트의 일부이고 테넌트의 정책 스토어가 사용되도록 합니다.
이 예제는 `tenant` 사용자의 `policyStoreId` 및가 포함된 JWT가 API 엔드포인트에서 AWS Lambda 권한 부여자의 정책 평가 지점으로 전달되어 요청을 올바른 정책 스토어로 라우팅하는 방법을 보여줍니다.
![\[Amazon Verified Permissions의 테넌트별 정책 스토어 모델\]](http://docs.aws.amazon.com/ko_kr/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":[]
}
]
]
}
}
```
사용자는 테넌트 B에 `Bob` 속하며 policyStoreId`store-b`는의 테넌트 자격 증명에도 매핑`Bob`되어 올바른 정책 스토어 사용을 적용합니다. 이렇게 하면 테넌트 B의 정책이 사용됩니다.
이 정책에서 `Bob`에는 모든 리소스의 데이터를 사용자 지정할 수 있는 권한이 있습니다. 이 예제에서는 테넌트 B에만 적용되는 작업일 `customizeData` 수 있으므로 정책은 테넌트 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를 정책 스토어와 통합할 수 있지만 필수는 아닙니다. 이 통합을 통해 정책은 자격 증명 저장소의 보안 주체를 정책의 보안 주체로 명시적으로 참조할 수 있습니다. Verified Permissions의 IdP로 Amazon Cognito와 통합하는 방법에 대한 자세한 내용은 [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/ko_kr/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에 기록하는 것이 좋습니다.
테넌트별 정책 스토어 접근 방식은 SaaS 솔루션의 운영을 방해하지 않도록 두 가지 [Verified Permissions 할당량](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)에 주의를 기울여야 합니다. 이러한 할당량은 계정*당 리전당 정책 저장소와 계정*당 *리전당 초당 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/) 참조하세요.
# 공유 다중 테넌트 정책 스토어 1개
하나의 공유 다중 테넌트 정책 스토어 설계 모델은 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와 정책 스토어를 공유하는 사용자 `Alice` 및 `store-multi-tenant`에 대해 JWT를 보내는 방법을 보여줍니다. 모든 테넌트가 단일 정책 스토어를 공유하므로 정책 스토어 ID를 토큰 또는 데이터베이스에 유지할 필요가 없습니다. 모든 테넌트는 단일 정책 스토어 ID를 공유하므로 애플리케이션이 정책 스토어를 호출하는 데 사용할 수 있는 환경 변수로 ID를 제공할 수 있습니다.
![\[Verified Permissions 공유 설계 모델\]](http://docs.aws.amazon.com/ko_kr/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는 공유 정책 스토어의 식별자입니다. 다음 요청에서는의 `Role`가 있고 리소스 `Admin`및 보안 주체와 연결된 `Tenant` 속성`User``Alice`이 모두 이므로에 액세스할 수 있습니다`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를 정책 스토어와 통합할 수 있지만 필수는 아닙니다. 이 통합을 통해 정책은 자격 증명 저장소의 보안 주체를 정책의 보안 주체로 명시적으로 참조할 수 있습니다. Verified Permissions의 IdP로 Amazon Cognito와 통합하는 방법에 대한 자세한 내용은 [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/ko_kr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)
운영 및 감사 관점에서 볼 때, 하나의 공유 다중 테넌트 정책 스토어 모델은 [로깅된 각 CloudTrail 호출이 동일한 정책 스토어를 사용하기 때문에의 로깅된 활동에 AWS CloudTrail](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html) 테넌트의 개별 활동을 필터링하기 위해 더 많은 관련 쿼리가 필요하다는 단점이 있습니다. CloudTrail 이 시나리오에서는 적절한 수준의 관찰성 및 감사 기능을 보장하기 위해 테넌트별 차원에 대한 추가 사용자 지정 지표를 Amazon CloudWatch에 로깅하는 것이 유용합니다.
또한 공유 다중 테넌트 정책 스토어 접근 방식 중 하나는 [Verified Permissions 할당량](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)에 주의하여 SaaS 솔루션의 운영을 방해하지 않도록 해야 합니다. 특히 계정 할당량*별로 리전당 초당 IsAuthorized 요청을* 모니터링하여 제한이 초과되지 않도록 하는 것이 좋습니다. 이 할당량 증가를 요청할 수 있습니다.
# 계층형 배포 모델
계층형 배포 모델을 생성하면 우선순위가 높은 "엔터프라이즈 티어" 테넌트를 잠재적으로 더 많은 "스탠다드 티어" 고객으로부터 격리할 수 있습니다. 이 모델에서는 각 계층에 대해 별도로 정책 스토어의 정책에 배포된 모든 변경 사항을 롤아웃할 수 있습니다. 그러면 각 계층의 고객을 해당 계층 외부에서 이루어진 변경 사항과 격리합니다. 계층형 배포 모델에서 정책 스토어는 일반적으로 테넌트가 온보딩될 때 배포되는 대신 각 계층에 대한 초기 인프라 프로비저닝의 일부로 생성됩니다.
솔루션에서 주로 풀링된 격리 모델을 사용하는 경우 추가 격리 또는 사용자 지정이 필요할 수 있습니다. 예를 들어 각 테넌트가 자체 테넌트 티어 인프라를 얻는 "프리미엄 티어"를 생성할 수 있습니다.이 경우 하나의 테넌트로만 풀링된 인스턴스를 배포하여 사일로화된 모델을 생성합니다. 이는 정책 스토어를 포함하여 완전히 분리된 "프리미엄 티어 테넌트 A" 및 "프리미엄 티어 테넌트 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/ko_kr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)