다음을 통해 공유

단일 테넌트의 리소스 격리

  • 아티클

단일 테넌트 내에서 많은 분리 시나리오를 달성할 수 있습니다. 가능하면 조직에 최상의 생산성과 협업 환경을 제공하도록 단일 테넌트 내 별도의 환경에 관리를 위임하는 것이 좋습니다.

성과

리소스 분리 - Microsoft Entra 디렉터리 역할, 보안 그룹, 조건부 액세스 정책, Azure 리소스 그룹, Azure 관리 그룹, AU(관리 단위) 및 기타 컨트롤을 사용하여 특정 사용자, 그룹 및 서비스 주체에 대한 리소스 액세스를 제한할 수 있습니다. 별도의 관리자가 리소스를 관리할 수 있으며 별도의 사용자, 사용 권한 및 액세스 요구 사항이 있습니다.

리소스 세트에 고유한 테넌트 전체 설정이 필요하거나 테넌트 구성원의 무단 액세스에 대한 최소 위험 허용 오차가 있거나 구성 변경으로 인해 심각한 영향을 받을 수 있는 경우 여러 테넌트에서 격리를 수행해야 합니다.

구성 분리 - 경우에 따라 애플리케이션과 같은 리소스에는 인증 방법이나 명명된 위치와 같은 테넌트 전체 구성에 대한 종속성이 있습니다. 리소스를 격리할 때 이러한 종속성을 고려해야 합니다. 전역 관리자는 리소스에 영향을 주는 리소스 설정과 테넌트 전체 설정을 구성할 수 있습니다.

리소스 세트에 고유한 테넌트 전체 설정이 필요하거나 다른 엔터티에서 테넌트 설정을 관리해야 하는 경우 여러 테넌트를 사용하여 격리를 수행해야 합니다.

관리 분리 - Microsoft Entra ID 위임된 관리를 사용하여 애플리케이션 및 API, 사용자 및 그룹, 리소스 그룹, 조건부 액세스 정책과 같은 리소스 관리를 분리할 수 있습니다.

전역 관리자는 모든 신뢰할 수 있는 리소스에 대한 전체 액세스 권한을 검색하고 얻을 수 있습니다. 감사 및 경고를 설정하여 관리자가 인증된 경우 관리자가 리소스를 변경하는 시기를 알 수 있습니다.

Microsoft Entra ID에서 AU(관리 단위)를 사용하여 일정 수준의 관리 분리를 제공할 수도 있습니다. 관리 단위는 사용자가 정의하는 조직의 모든 부분에 대한 역할의 권한을 제한합니다. 예를 들어 관리 단위를 사용하여 기술 지원팀 관리자 역할을 지역 지원 전문가에게 위임하여 지원하는 지역에서만 사용자를 관리할 수 있도록 할 수 있습니다.

관리 단위를 보여 주는 다이어그램

관리 단위를 사용자, 그룹 및 디바이스 개체를 구분하는 데 사용할 수 있습니다. 이러한 단위 할당은 동적 멤버 관리 규칙에서 관리될 수 있습니다.

PIM(Privileged Identity Management)을 사용하면 조직에서 권한이 높은 역할에 대한 요청을 승인하는 데 가장 적합한 사람을 정의할 수 있습니다. 예를 들어 전역 관리자 액세스 권한이 필요한 관리자는 테넌트 전체에서 변경을 수행합니다.

참고 항목

PIM을 사용하려면 사용자당 Microsoft Entra ID P2 라이선스가 필요합니다.

전역 관리자가 특정 리소스를 관리할 수 없도록 해야 하는 경우 별도의 전역 관리자를 사용하여 별도의 테넌트에서 해당 리소스를 격리해야 합니다. 이는 백업에 특히 중요할 수 있습니다. 이에 대한 예제는 다중 사용자 권한 부여 지침을 참조하세요.

일반적인 사용

단일 테넌트에서 가장 일반적인 여러 환경에 대한 사용 중 하나는 프로덕션을 프로덕션이 아닌 리소스와 분리하는 것입니다. 단일 테넌트 내에서 개발 팀과 애플리케이션 소유자는 테스트 앱, 테스트 사용자 및 그룹 및 해당 개체에 대한 테스트 정책을 사용하여 별도의 환경을 만들고 관리할 수 있습니다. 마찬가지로, Azure 리소스와 신뢰할 수 있는 앱의 프로덕션이 아닌 인스턴스를 만들 수 있습니다.

다음 다이어그램에서는 프로덕션이 아닌 환경과 프로덕션 환경을 보여 줍니다.

Microsoft Entra 테넌트 경계를 보여 주는 다이어그램.

이 다이어그램에는 비프로덕션 Azure 리소스와 비프로덕션 인스턴스 Microsoft Entra 통합 애플리케이션과 동등한 비프로덕션 디렉터리 개체가 있습니다. 이 예제에서는 디렉터리에 있는 프로덕션이 아닌 리소스가 테스트 목적으로 사용됩니다.

참고 항목

단일 Microsoft Entra 테넌트에서는 Microsoft 365 환경을 두 개 이상 사용할 수 없습니다. 그러나 단일 Microsoft Entra 테넌트에 Dynamics 365 환경이 여러 개 있을 수 있습니다.

단일 테넌트 내에서 격리를 위한 또 다른 시나리오는 위치, 자회사 또는 계층화된 관리 구현("엔터프라이즈 액세스 모델"에 따라)을 분리하는 것입니다.

Azure RBAC 역할 할당을 사용하면 Azure 리소스 관리 범위를 지정할 수 있습니다. 마찬가지로, Microsoft Entra ID를 사용하면 조건부 액세스, 사용자 및 그룹 필터링, 관리 단위 할당, 애플리케이션 할당과 같은 여러 기능을 통해 Microsoft Entra ID 트러스팅 애플리케이션을 세분화하여 관리할 수 있습니다.

Microsoft 365 서비스의 전체 격리(조직 수준 구성 준비 포함)를 보장해야 하는 경우 여러 테넌트 격리를 선택해야 합니다.

단일 테넌트에서 범위가 지정된 관리

Azure 리소스에 대한 범위가 지정된 관리

Azure RBAC를 사용하면 세분화된 범위와 노출 영역으로 관리 모델을 디자인할 수 있습니다. 다음 예제에서는 관리 계층 구조를 고려해 보겠습니다.

참고 항목

조직의 개별 요구 사항, 제약 조건 및 목표에 따라 관리 계층 구조를 정의하는 방법에는 여러 가지가 있습니다. 자세한 내용은 Azure 리소스 구성 방법에 대한 클라우드 채택 프레임워크 지침을 참조하세요.

단일 테넌트의 리소스 격리를 보여 주는 다이어그램

  • 관리 그룹 - 다른 관리 그룹에 영향을 주지 않도록 특정 관리 그룹에 역할을 할당할 수 있습니다. 위의 시나리오에서 HR 팀은 리소스가 모든 HR 구독에 배포되는 지역을 감사하는 Azure Policy를 정의할 수 있습니다.

  • 구독 - 다른 리소스 그룹에 영향을 주지 않도록 특정 구독에 역할을 할당할 수 있습니다. 위 예제에서 HR 팀은 다른 HR 구독이나 다른 팀의 구독을 읽지 않고도 혜택 구독에 대한 읽기 권한자 역할을 할당할 수 있습니다.

  • 리소스 그룹 - 다른 리소스 그룹에 영향을 주지 않도록 특정 리소스 그룹에 역할을 할당할 수 있습니다. 위 예제에서 혜택 엔지니어링 팀은 테스트 리드에 기여자 역할을 할당하여 테스트 DB 및 테스트 웹앱을 관리하거나 리소스를 더 추가할 수 있습니다.

  • 개별 리소스 - 다른 리소스 그룹에 영향을 주지 않도록 특정 리소스에 역할을 할당할 수 있습니다. 위 예제에서 혜택 엔지니어링 팀은 테스트 웹앱 또는 프로덕션 리소스를 방해하지 않고 데이터 분석가에게 Azure Cosmos DB 데이터베이스의 테스트 인스턴스에 대한 Cosmos DB 계정 읽기 권한자 역할을 할당할 수 있습니다.

자세한 내용은 Azure 기본 제공 역할 및 Azure RBAC(Azure 역할 기반 액세스 제어)란?을 참조하세요.

이는 계층 구조이므로 높은 계층 구조에서는 범위, 표시 유형 및 영향이 높아질수록 수준은 낮아집니다. 최상위 범위는 Microsoft Entra 테넌트 경계의 모든 Azure 리소스에 영향을 줍니다. 즉, 여러 수준에서 권한을 적용할 수 있습니다. 이로 인해 발생하는 위험은 계층 구조에서 역할을 더 높게 할당하면 의도한 범위보다 낮은 범위에 더 많은 액세스 권한을 제공할 수 있는 위험입니다. Microsoft Entra(공식적으로 CloudKnox)는 위험을 줄이는 데 도움이 되는 표시 유형과 수정 기능을 제공하는 Microsoft 제품입니다. 세부 정보는 다음과 같습니다.

  • 루트 관리 그룹은 모든 구독과 리소스에 적용할 Azure 정책 및 RBAC 역할 할당을 정의합니다.

  • 전역 관리자는 모든 구독과 관리 그룹에 대한 액세스 권한을 승격할 수 있습니다.

두 최상위 범위 모두 엄격하게 모니터링되어야 합니다. 네트워킹과 같은 리소스 격리의 다른 차원을 계획하는 것이 중요합니다. Azure 네트워킹에 대한 일반적인 지침은 네트워크 보안에 대한 Azure 모범 사례를 참조하세요. IaaS(서비스 제공 인프라) 워크로드에는 ID 및 리소스 격리가 전체 설계와 전략의 일부가 되어야 하는 특별한 시나리오가 있습니다.

Azure 랜딩 존 개념 아키텍처에 따라 중요한 리소스나 테스트 리소스를 격리하는 것이 좋습니다. 예를 들어 ID 구독을 분리된 관리 그룹에 할당해야 하며 개발 목적으로 모든 구독을 "샌드박스" 관리 그룹에서 구분할 수 있습니다. 자세한 내용은 엔터프라이즈 규모 문서를 참조하세요. 단일 테넌트 내에서 테스트 목적으로 분리하는 것도 참조 아키텍처의 관리 그룹 계층 구조에서 고려됩니다.

Microsoft Entra ID 트러스팅 애플리케이션에 대한 범위가 지정된 관리

Microsoft Entra ID 트러스팅 애플리케이션의 관리 범위를 지정하는 패턴은 다음 섹션에 설명되어 있습니다.

Microsoft Entra ID는 독립적인 사용자 할당이 있는 같은 디렉터리에 대해 사용자 지정 및 SaaS 앱의 인스턴스를 여러 개 구성할 수 있지만 대부분의 Microsoft 서비스를 구성할 수 없습니다. 위 예제에는 여행 앱의 프로덕션 및 테스트 버전이 모두 포함되어 있습니다. 회사 테넌트에 대해 사전 프로덕션 버전을 배포하여 워크로드 소유자가 회사 자격 증명으로 테스트를 수행할 수 있도록 앱별 구성과 정책 분리를 달성할 수 있습니다. 테스트 사용자 및 테스트 그룹과 같은 프로덕션이 아닌 디렉터리 개체는 해당 개체의 별도 소유권을 가진 프로덕션이 아닌 애플리케이션에 연결됩니다.

Microsoft Entra 테넌트 경계 내 모든 트러스팅 애플리케이션에 영향을 주는 테넌트 전체 측면은 다음과 같습니다.

  • 전역 관리자는 모든 테넌트 전체 설정을 관리할 수 있습니다.

  • 사용자 관리자, 애플리케이션 관리자 및 조건부 액세스 관리자와 같은 다른 디렉터리 역할은 역할 범위 내에서 테넌트 전체 구성을 관리할 수 있습니다.

허용되는 인증 방법, 하이브리드 구성, 도메인의 B2B 협업 허용 목록 및 명명된 위치와 같은 구성 설정은 테넌트 전체 설정입니다.

참고 항목

Microsoft Graph API 권한과 동의 권한은 범위를 관리 단위의 그룹이나 구성원으로 지정할 수 없습니다. 이러한 권한은 디렉터리 수준에서 할당되며 리소스별 동의만 리소스 수준의 범위를 허용합니다(현재 Microsoft Teams 채팅 권한으로 제한됨).

Important

Office 365, Microsoft Dynamics 및 Microsoft Exchange와 같은 Microsoft SaaS 서비스의 수명 주기는 Microsoft Entra 테넌트에 바인딩됩니다. 따라서 이러한 서비스의 여러 인스턴스에는 Microsoft Entra 테넌트 여러 개가 필요합니다. 개별 서비스에 대한 문서를 확인하여 특정 관리 범위 지정 기능을 자세히 알아보세요.

다음 단계