멀티 테넌시 고려 사항 - Amazon Verified Permissions

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

멀티 테넌시 고려 사항

애플리케이션을 사용하는 기업이나 테넌트 등 여러 고객이 사용할 애플리케이션을 개발하고 이를 Amazon Verified Permissions와 통합하고 싶을 수 있습니다. 권한 부여 모델을 개발하기 전에 멀티테넌트 전략을 개발하십시오. 하나의 공유 정책 저장소에서 고객 정책을 관리하거나 각 고객에게 테넌트별 정책 저장소를 할당할 수 있습니다.

  1. 공유 정책 저장소 1개

    모든 테넌트는 단일 정책 저장소를 공유합니다. 애플리케이션은 모든 권한 부여 요청을 공유 정책 저장소에 보냅니다.

  2. 테넌트별 정책 저장소

    각 테넌트에는 전용 정책 저장소가 있습니다. 애플리케이션은 요청하는 테넌트에 따라 여러 정책 저장소를 쿼리하여 권한 부여 결정을 내립니다.

두 전략 모두 청구서에 영향을 미칠 수 있는 권한 부여 요청의 양을 상대적으로 많이 생성하지 않습니다. AWS 그렇다면 접근 방식을 어떻게 설계해야 할까요? 다음은 검증된 권한 멀티테넌시 권한 부여 전략에 영향을 미칠 수 있는 일반적인 조건입니다.

테넌트 정책 격리

테넌트 데이터를 보호하려면 각 테넌트의 정책을 다른 테넌트와 분리하는 것이 중요합니다. 각 테넌트에 자체 정책 저장소가 있는 경우 각 테넌트에는 고유한 격리된 정책 집합이 있습니다.

권한 부여 흐름

요청의 정책 저장소 ID와 테넌트별 정책 저장소를 사용하여 권한 부여를 요청하는 테넌트를 식별할 수 있습니다. 공유 정책 저장소에서는 모든 요청이 동일한 정책 저장소 ID를 사용합니다.

템플릿 및 스키마 관리

정책 템플릿과 정책 저장소 스키마는 각 정책 저장소에 일정 수준의 설계 및 유지 관리 오버헤드를 추가합니다.

글로벌 정책 관리

일부 글로벌 정책을 모든 테넌트에 적용할 수 있습니다. 글로벌 정책 관리에 대한 오버헤드 수준은 공유 정책 저장소 모델과 테넌트별 정책 저장소 모델에 따라 다릅니다.

테넌트 오프보딩

일부 테넌트는 해당 사례에 맞는 스키마 및 정책 요소를 제공합니다. 테넌트가 더 이상 조직에서 활동하지 않는 경우 데이터를 제거하려는 경우 노력의 수준은 다른 테넌트와의 격리 수준에 따라 달라집니다.

서비스 리소스 할당량

검증된 권한에는 멀티테넌시 결정에 영향을 미칠 수 있는 리소스 및 요청률 할당량이 있습니다. 할당량에 대한 자세한 내용은 리소스 할당량 섹션을 참조하세요.

공유 정책 저장소와 테넌트별 정책 저장소 비교

공유 및 테넌트별 정책 저장소 모델에서 각 고려 사항마다 고유한 수준의 시간 및 리소스 투입이 필요합니다.

고려 사항 공유 정책 저장소의 노력 수준 테넌트별 정책 저장소의 노력 수준
테넌트 정책 격리 미디엄.Must include tenant identifiers in policies and authorization requests. 낮음. Isolation is default behavior. Tenant-specific policies are inaccessible to other tenants.
인증 흐름 낮음. All queries target one policy store. 미디엄. Must maintain mappings between each tenant and their policy store ID.
템플릿 및 스키마 관리 낮음. Must make one schema work for all tenants. 높음 Schemas and templates might be less complex individually, but changes require more coordination and complexity.
글로벌 정책 관리 낮음. All policies are global and can be centrally updated. 높음 You must add global policies to each policy store in onboarding. Replicate global policy updates between many policy stores.
테넌트 오프보딩 미디엄. Must identify and delete only tenant-specific policies. 낮음. Delete the policy store.
서비스 리소스 할당량 높음 Tenants share resource quotas that affect policy stores like schema size, policy size per resource, and identity sources per policy store. 낮음. Each tenant has dedicated resource quotas.

선택 방법

각 멀티테넌트 애플리케이션은 다릅니다. 아키텍처 결정을 내리기 전에 두 가지 접근 방식과 고려 사항을 주의 깊게 비교하십시오.

애플리케이션에 테넌트별 정책이 필요하지 않고 단일 ID 소스를 사용하는 경우 모든 테넌트를 위한 하나의 공유 정책 저장소가 가장 효과적인 솔루션일 수 있습니다. 따라서 권한 부여 흐름과 글로벌 정책 관리가 단순해집니다. 애플리케이션에서 테넌트별 정책을 삭제할 필요가 없으므로 하나의 공유 정책 저장소를 사용하여 테넌트를 오프보딩하는 데 드는 노력이 줄어듭니다.

그러나 애플리케이션에 많은 테넌트별 정책이 필요하거나 여러 ID 소스를 사용하는 경우에는 테넌트별 정책 저장소가 가장 효과적일 수 있습니다. 각 정책 저장소에 테넌트별 권한을 부여하는 IAM 정책을 사용하여 테넌트 정책에 대한 액세스를 제어할 수 있습니다. 테넌트를 오프보딩하려면 해당 정책 저장소를 삭제해야 합니다. shared-policy-store 환경에서는 테넌트별 정책을 찾아 삭제해야 합니다.