여러 위치에서 요구 사항을 충족하도록 Azure 랜딩 존 아키텍처 수정
많은 산업의 조직은 데이터 보존, 데이터 보안 및 데이터 주권 요구 사항을 비롯한 규제 요구 사항의 적용을 받습니다. 일부 조직은 여러 지리적 위치에서 충돌하는 규정을 준수해야 합니다. 이 경우 적용 가능한 모든 규정에 따라 Azure 랜딩 존 아키텍처를 수정해야 합니다.
예를 들어 규정 A와 규정 B라는 두 가지 상반되는 규정이 있을 수 있습니다. 규정 A는 국가 또는 지역 A에서 데이터 상주를 요구할 수 있으며, 규정 B는 국가 또는 지역 B에서 데이터 상주를 요구할 수 있습니다.
이러한 규제 충돌은 다음을 적용할 수 있습니다.
다국적 기업 또는 비정부기구(NGO)와 같은 다국적 조직은 해당 기업이 활동하는 국가 또는 지역의 현지 규정을 준수해야 합니다.
여러 위치에 있는 조직에 솔루션을 제공하는 ISV(독립 소프트웨어 공급업체)이며 솔루션은 각 위치의 현지 규정을 준수해야 합니다.
운영 중인 각 국가 또는 지역의 현지 규정을 준수해야 하는 다국적 조직에 솔루션을 제공하는 ISV.
단일 규정 요구 사항 집합만 충족해야 하는 경우 요구 사항을 충족하도록 Azure 랜딩 존 아키텍처 조정을 참조 하세요.
규정 고려 사항
규정 요구 사항은 일반적으로 데이터 보호, 데이터 보존, 데이터 전송, 격리 또는 직원 허가와 관련이 있습니다. 이러한 요구 사항은 여러 지리적 위치 간에 충돌할 수 있습니다. 예를 들어 유럽 연합(EU) 규정은 EU 국가의 데이터 보존을 요구할 수 있지만 영국 규정은 영국의 데이터 상주를 요구할 수 있습니다.
규정이 충돌하는 정책 제어로 이어질 경우 그에 따라 Azure 랜딩 존 아키텍처 및 정책 할당을 조정해야 합니다. 자세한 내용은 이 문서의 섹션인 수정이 필요한 시나리오를 참조하세요.
여러 규정이 적용되는 경우 다음과 같은 경우 Azure 랜딩 존 아키텍처를 수정할 필요가 없습니다.
여러 규정을 사용하려면 동일한 Azure Policy 할당이 필요합니다.
한 규정의 제어는 다른 규정의 상위 집합입니다. 상위 집합 컨트롤은 두 규정에 자동으로 적용됩니다.
여러 규정의 컨트롤은 겹치지 않습니다. 여러 컨트롤 집합을 구현하는 경우 단일 구현은 모든 규정을 포함합니다. Azure Policy 할당은 보완적입니다.
다양한 규정의 구현 유형이 다릅니다. 규제 관점에서 볼 때 어떤 구현을 선택하든 상관없습니다. 예를 들어 각각 다른 권한 부여 모델이 있는 두 가지 규정이 있을 수 있지만 두 권한 부여 모델은 모두 허용됩니다. 조직에 가장 적합한 구현을 선택할 수 있습니다.
팁
가능한 한 적은 수의 정책 할당과 예외 또는 예외를 갖도록 노력해야 합니다.
ISV에 대한 고려 사항
ISV에 대한 세 가지 배포 모델이 있습니다.
순수 SaaS(Software as a Service): ISV는 솔루션을 서비스로 제공합니다.
배포된 고객: 고객은 자체 환경에서 솔루션을 배포합니다.
이중 배포 SaaS: 이 모델은 고객이 배포한 모델과 순수 SaaS 모델을 결합합니다.
순수 SaaS 모델에서 ISV는 고객을 대신하여 규정 준수를 관리할 책임이 있습니다. ISV는 고객 및 잠재적으로 감사자 또는 규제 기관에 대한 규정 준수를 입증해야 합니다. SaaS 모델을 사용하는 경우 아키텍처에 충돌할 수 있는 여러 규정이 적용될 수 있습니다. ISV는 이러한 다양한 규정 준수를 관리해야 합니다. 자세한 내용은 이 문서의 섹션인 수정이 필요한 시나리오를 참조하세요.
고객이 배포한 모델에서 고객은 규정 준수를 관리할 책임이 있습니다. 이 모델의 경우 ISV는 랜딩 존을 수정할 필요가 없습니다. 그러나 솔루션은 정책 제어 및 사용자 지정 정책을 포함하여 고객이 배포하는 랜딩 존에 배포됩니다.
팁
ISV는 특정 규정 준수 요구 사항에 따라 정책 이니셔티브를 대상으로 하여 솔루션을 테스트할 수 있습니다. 이 사례를 통해 고객이 규정 준수 요구 사항을 충족하는 데 사용하는 정책과 충돌할 가능성을 최소화할 수 있습니다.
이중 배포 SaaS 모델에서 고객 배포 및 순수 SaaS 모델에 대한 모든 고려 사항이 적용됩니다.
다국적 조직에 대한 고려 사항
다국적 조직은 다양한 구조를 사용하여 IT 거버넌스를 구성합니다.
탈중앙화 구조: IT 함수는 각 지리적 위치에서 로컬로 관리됩니다.
중앙 집중식 구조: IT 함수는 중앙 집중식 위치( 일반적으로 조직의 본사)에서 관리됩니다.
하이브리드 구조: 전역 IT 함수는 중앙에서 제공되며 로컬로만 필요한 IT 함수는 각 지리적 위치에서 관리됩니다.
분산형 시나리오에서 로컬 IT 팀은 규정 준수 관리를 담당하며 그에 따라 랜딩 존을 조정할 수 있습니다.
중앙 집중식 시나리오에서 중앙 IT 팀은 규정 준수 관리를 담당하며 솔루션이 다국적 조직이 운영되는 모든 지리적 위치의 로컬 규정 준수 요구 사항을 충족하는지 확인해야 합니다. 다양한 지리적 위치의 규정 준수 요구 사항이 충돌할 수 있으며 랜딩 존을 수정해야 할 수 있습니다.
하이브리드 시나리오에서는 탈중앙화 시나리오와 중앙 집중식 시나리오 모두에 대한 고려 사항이 적용됩니다. 중앙 집중식 조직은 로컬 조직에서 해당 환경에 배포해야 하는 솔루션을 제공합니다. 또한 중앙 집중식 조직은 해당 솔루션이 로컬 조직의 모든 랜딩 존에 배포되도록 테스트합니다.
수정이 필요한 시나리오
다양한 배포에 할당된 충돌하는 정책 집합이 있는 경우 랜딩 존을 수정해야 할 수 있습니다. 여러 솔루션 또는 다양한 지리적 위치 또는 데이터 분류에 사용할 수 있어야 하는 단일 솔루션이 있을 수 있습니다.
필요한 수정의 양은 규정이 요구하는 격리 수준에 따라 달라집니다. 규정이 있는 조건이 많을수록 랜딩 존을 더 많이 수정해야 합니다. 예를 들어 규정에서 지운 직원, 다양한 ID 공급자 또는 디렉터리, 별도의 관리 인프라 또는 별도의 연결 인프라와 같은 조건이 필요한 경우 랜딩 존에는 광범위한 수정이 필요합니다. 규정에 따라 애플리케이션 및 연결 인프라만 격리해야 하는 경우 랜딩 존은 최소한의 수정이 필요합니다.
Microsoft Entra 테넌트
다국적 시나리오를 비롯한 대부분의 시나리오에 단일 Microsoft Entra 테넌트를 사용하는 것이 좋습니다. 그러나 다음과 같이 여러 Microsoft Entra 테넌트가 선호되거나 필요할 수 있는 시나리오가 있습니다.
보안을 개선하고 제품과 비즈니스 작업 간에 명확한 경계를 만들기 위해 회사 Microsoft Entra 테넌트와 SaaS Microsoft Entra 테넌트에서 분리해야 하는 경우.
충돌하는 규정이 적용되고 다른 규제 체제에 대해 별도의 Microsoft Entra 테넌트가 필요한 경우 예를 들어 규정은 Microsoft Entra 테넌트 또는 별도의 테넌트가 필요한 데이터 상주 요구 사항 간에 완전한 격리가 필요한 허가 및 국적 요구 사항이 있을 수 있습니다. 일반적인 시나리오에는 SaaS 솔루션의 격리된 인스턴스를 배포해야 하는 ISV 또는 동일한 솔루션의 격리된 인스턴스를 배포해야 하는 다국적 조직이 포함됩니다.
여러 Microsoft Entra 테넌트에서 공동 작업하는 경우 중요한 과제와 요구 사항을 신중하게 계획해야 합니다. 운영 또는 규정 요구 사항을 충족하는 데 필요한 최소 수의 Microsoft Entra 테넌트만 만듭니다. 다음 섹션에 설명된 대로 관리 그룹 및 Azure RBAC(역할 기반 액세스 제어)를 사용하여 단일 테넌트에서 구독 및 리소스에 대한 액세스를 제어할 수 있습니다.
팁
랜딩 존에 대해 선택한 Microsoft Entra 테넌트는 애플리케이션 수준 인증에 영향을 주지 않습니다. 선택한 테넌트에 관계없이 다른 ID 공급자를 계속 사용할 수 있습니다. 공공 부문 고객 및 규제 산업의 고객의 경우 일반적으로 정부 소유 또는 인증 ID 공급자와 같은 승인된 ID 공급자와 통합할 때 최종 사용자 ID가 제공됩니다.
다음 다이어그램에서는 Microsoft Entra 테넌트 구성에 사용할 수 있는 옵션을 보여 줍니다.
팁
규정 요구 사항을 충족하기 위해 여러 Microsoft Entra 테넌트가 있는 경우 특정 규정이 아닌 지리적 위치에 따라 테넌트 이름을 지정합니다(예 : 예제 다이어그램의 contoso-ops-us.com ).
자세한 내용은 Azure 랜딩 존 및 여러 Microsoft Entra 테넌트 및 Azure 랜딩 존에 대한 ISV 고려 사항을 참조하세요.
관리 그룹
엄격한 격리를 제공하기 위해 별도의 Microsoft Entra 테넌트가 필요하지 않은 경우 단일 Microsoft Entra 테넌트에 여러 Azure 랜딩 존을 배포해야 합니다. 충돌하는 규정의 요구 사항을 해결하기 위해 관리 그룹 계층 구조를 조정할 수 있습니다.
분리하려는 각 규정 집합에 대한 전체 랜딩 존 아키텍처를 배포할 수 있습니다. 이 모델을 사용하려면 최소한의 사용자 지정이 필요하며 배포를 위해 기존 자동화를 활용할 수 있습니다.
참고 항목
이 다이어그램은 모든 관리 그룹을 표시하지 않습니다.
플랫폼 관리 그룹 공유
규정이 허용하는 경우 플랫폼 관리 그룹을 공유할 수 있습니다. 구분해야 하는 각 규정 집합에 대해 랜딩 존 관리 그룹 아래에 별도의 관리 그룹을 만들 수 있습니다. 각 애플리케이션 관리 그룹에 적절한 정책을 할당할 수 있습니다. 애플리케이션 랜딩 존은 플랫폼 관리 그룹 아래에 있는 관리 그룹을 공유합니다. 애플리케이션 관리 그룹의 리소스는 구독 또는 리소스 그룹으로 구분할 수도 있습니다.
이 관리 그룹 계층 구조는 충돌하는 규정으로 애플리케이션을 격리하기 위한 간단하고 비용 효율적인 디자인입니다. 그러나 이 디자인에서는 연결, ID/보안 및 관리를 위한 플랫폼 관리 그룹이 동일한 정책 집합을 공유해야 합니다. 규정에서 연결 인프라, ID 서비스, 키 관리 서비스 또는 전체 환경이 관리되는 인프라 공유에 제한을 적용하는 경우 각 플랫폼 관리 그룹에 대해 서로 다른 정책 집합이 필요할 수 있습니다.
ID 및 보안 격리
규정으로 인해 ID 및 키 관리 인프라를 공유할 수 없는 경우 플랫폼 관리 그룹을 나눌 수 있습니다. 공유 플랫폼 관리 그룹에서 연결 및 관리를 위해 관리 그룹을 유지하고 각 규정 집합과 연결된 ID 및 보안 관리 그룹을 갖습니다.
이 관리 그룹 계층 구조는 플랫폼 관리 그룹을 부분적으로 복제본(replica) 하기 때문에 완전히 공유된 플랫폼 관리 그룹보다 훨씬 더 복잡합니다. 복잡성을 제한하려면 각 규정 집합 및 공유 환경에 대한 전체 계층 구조를 배포하고 불필요한 관리 그룹을 무시하거나 삭제할 수 있습니다.
연결 격리
많은 규정에는 사용자가 애플리케이션에 연결하는 방법에 대한 요구 사항이 거의 없는 특정 지리적 위치에 데이터 처리 및 저장과 관련된 요구 사항이 있습니다. 이러한 규정의 경우 이전 아키텍처와 같이 연결 관리를 공유할 수 있습니다. 여러 지역에서 인프라를 복제해야 하는 규정이 없을 수도 있지만 대기 시간을 위해 필요할 수 있습니다. 할당된 정책은 여러 지역에서 중복 인프라를 지원해야 합니다.
규정의 연결 요구 사항이 충돌하는 경우 각 규정 집합과 연결된 연결 관리 그룹을 만들 수 있습니다. 이 구조는 ID 및 보안 관리 그룹을 각 규정 집합과 연결하는 이전 아키텍처와 유사합니다.
연결 및 ID 및 보안에 대한 규정이 충돌하는 경우 다음 디자인을 사용할 수 있습니다.
