여러 Microsoft Entra 테넌트에 대한 시나리오
조직에 여러 Microsoft Entra 테넌트가 필요하거나 조사하려는 몇 가지 이유가 있습니다. 가장 일반적인 시나리오는 다음과 같습니다.
- 인수 합병
- 규정 또는 국가/지역 규정 준수 요구 사항
- 사업부 또는 조직의 격리 및 자율성 요구 사항
- Azure에서 SaaS 애플리케이션을 제공하는 ISV(독립 소프트웨어 공급업체)
- 테넌트 수준 테스트/Microsoft 365 테스트
- 풀뿌리 / 그림자 IT / 신생
인수 합병
조직이 시간이 지남에 따라 성장함에 따라 다른 회사 또는 조직을 인수할 수 있습니다. 이러한 인수는 기존 Microsoft Entra 테넌트가 이미 해당 호스트를 설정하고 Microsoft 365(Exchange Online, SharePoint, OneDrive 또는 Teams), Dynamics 365 및 Microsoft Azure와 같은 서비스를 회사 또는 조직에 제공할 가능성이 높습니다.
일반적으로 인수에서 두 개의 Microsoft Entra 테넌트는 단일 Microsoft Entra 테넌트로 통합됩니다. 이 통합은 관리 오버헤드를 줄이고, 공동 작업 환경을 개선하며, 다른 회사 및 조직에 단일 브랜드 ID를 제공합니다.
Important
사용자 지정 do기본 이름(예: contoso.com)은 한 번에 하나의 Microsoft Entra 테넌트에만 연결할 수 있습니다. 따라서 병합 또는 인수 시나리오가 발생할 때 모든 ID에서 단일 사용자 지정 do기본 이름을 사용할 수 있으므로 테넌트를 통합하는 것이 좋습니다.
두 개의 Microsoft Entra 테넌트를 하나의 테넌트로 통합하는 복잡성 때문에 경우에 따라 테넌트가 단독으로 남아 있고 연장되거나 무기한으로 분리될 기본 있습니다.
이 시나리오는 다른 조직이 나중에 회사를 인수할 수 있기 때문에 조직이나 회사가 기본 분리하려는 경우에도 발생할 수 있습니다. 조직에서 Microsoft Entra 테넌트를 격리하고 통합하지 않는 경우 향후 단일 엔터티의 합병 또는 인수가 있을 경우 작업이 줄어듭니다.
규정 또는 국가/지역 규정 준수 요구 사항
일부 조직에는 엄격한 규제 또는 국가/지역 규정 준수 제어 및 프레임워크(예: 영국 공식, SOX(Sarbanes Oxley) 또는 NIST)가 있습니다. 조직에서는 이러한 프레임워크를 충족하고 준수하기 위해 여러 Microsoft Entra 테넌트만 만들 수 있습니다.
더 엄격한 데이터 상주 규정을 사용하는 전 세계 사무실과 사용자가 있는 일부 조직에서는 여러 Microsoft Entra 테넌트도 만들 수 있습니다. 그러나 이 특정 요구 사항은 일반적으로 Microsoft 365 Multi-Geo와 같은 기능을 사용하여 단일 Microsoft Entra 테넌트 내에서 해결됩니다.
또 다른 시나리오는 조직이 Azure Government(미국 정부) 또는 Azure 중국(21Vianet에서 운영)을 요구하는 경우입니다. 이러한 국가별 Azure 클라우드 인스턴스에는 자체 Microsoft Entra 테넌트가 필요합니다. Microsoft Entra 테넌트는 해당 국가별 Azure 클라우드 인스턴스에만 사용되며 해당 Azure 클라우드 인스턴스 내의 Azure 구독 ID 및 액세스 관리 서비스에 사용됩니다.
팁
Azure 국가/지역 클라우드의 ID 시나리오에 대한 자세한 내용은 다음을 참조하세요.
이전 시나리오와 마찬가지로 조직에 준수할 규정 또는 국가/지역 규정 준수 프레임워크가 있는 경우 기본 접근 방식으로 여러 Microsoft Entra 테넌트를 요구하지 않을 수 있습니다. 대부분의 조직은 Privileged Identity Management 및 관리istrative units와 같은 기능을 사용하여 단일 Microsoft Entra 테넌트 내의 프레임워크를 준수할 수 있습니다.
사업부 또는 조직의 격리 및 자율성 요구 사항
일부 조직에서는 여러 사업부에 복잡한 내부 구조를 포함하거나 조직의 일부 간에 높은 수준의 격리와 자율성이 필요할 수 있습니다.
이 시나리오가 발생하고 단일 테넌트의 리소스 격리에 대한 도구와 지침이 필요한 수준의 격리를 제공할 수 없는 경우 여러 Microsoft Entra 테넌트를 배포, 관리 및 운영해야 할 수 있습니다.
이와 같은 시나리오에서는 이러한 여러 테넌트의 배포, 관리 및 운영을 담당하는 중앙 집중식 함수가 없는 것이 더 일반적입니다. 대신, 실행 및 관리하기 위해 분리된 사업부 또는 조직의 일부에게 완전히 인계됩니다. 중앙 집중식 아키텍처, 전략 또는 CCoE 스타일 팀은 별도의 Microsoft Entra 테넌트에서 구성해야 하는 모범 사례에 대한 지침과 권장 사항을 계속 제공할 수 있습니다.
Warning
운영 역할 및 책임이 있는 조직은 조직의 Microsoft Entra 테넌트 운영 팀 간에 문제를 만듭니다. Azure는 두 팀 간에 명확한 RACI를 만들고 합의하는 데 우선 순위를 두어야 합니다. 이 작업을 통해 두 팀은 업무와 서비스를 조직에 제공하고 적시에 비즈니스에 가치를 다시 제공할 수 있습니다.
일부 조직에는 Azure를 사용하는 클라우드 인프라 및 개발 팀이 있습니다. 조직은 서비스 주체 만들기 또는 그룹 만들기 및 관리를 위해 회사 Microsoft Entra 테넌트를 제어하는 ID 팀을 사용합니다. 합의된 RACI가 없는 경우 팀 간에 프로세스와 이해가 부족하여 팀과 조직 간에 마찰이 발생하는 경우가 많습니다. 일부 조직에서는 여러 Microsoft Entra 테넌트가 이 문제를 해결할 수 있는 유일한 방법이라고 생각합니다.
그러나 여러 Microsoft Entra 테넌트는 최종 사용자에게 문제를 발생시키고, 여러 테넌트 보안, 관리 및 관리의 복잡성을 증가시키고, 라이선스 비용을 증가시킬 수 있습니다. Microsoft Entra ID P1 또는 P2와 같은 라이선스는 여러 Microsoft Entra 테넌트에 걸쳐 있지 않습니다. 경우에 따라 Microsoft Entra B2B 사용은 일부 기능 및 서비스에 대한 라이선스 중복을 완화할 수 있습니다. 배포에서 Microsoft Entra B2B를 사용하려는 경우 Microsoft Entra B2B 자격에 대한 각 기능 및 서비스의 라이선스 조건 및 지원 가능성을 검토합니다.
이러한 상황에서 조직은 여러 Microsoft Entra 테넌트를 만드는 대신 단일 Microsoft Entra 테넌트에서 팀이 함께 작업할 수 있도록 운영 문제를 해결해야 합니다.
Azure에서 SaaS 애플리케이션을 제공하는 ISV(독립 소프트웨어 공급업체)
고객에게 SaaS(Software as a Service) 제품을 제공하는 ISV는 Azure 사용량에 대해 여러 Microsoft Entra 테넌트를 사용하는 것이 도움이 될 수 있습니다.
ISV인 경우 전자 메일, 파일 공유 및 내부 애플리케이션과 같은 일반적인 비즈니스 활동에 대해 Azure 사용을 포함하여 회사 Microsoft Entra 테넌트 간에 분리될 수 있습니다. Azure 구독이 호스트하고 최종 고객에게 제공하는 SaaS 애플리케이션을 제공하는 별도의 Microsoft Entra 테넌트가 있을 수도 있습니다. 이 방법은 보안 인시던트로부터 사용자와 고객을 보호하기 때문에 일반적이고 합리적입니다.
자세한 내용은 Azure 랜딩 존에 대한 ISV(Independent Software Vendor) 고려 사항을 참조 하세요.
테넌트 수준 테스트/Microsoft 365 테스트
Microsoft Cloud 제품, 서비스 및 제품의 일부 활동 및 기능은 별도의 Microsoft Entra 테넌트에서만 테스트할 수 있습니다. 다음은 몇 가지 예입니다.
- Microsoft 365 – Exchange Online, SharePoint 및 Teams
- Microsoft Entra ID – Microsoft Entra 커넥트, Microsoft Entra ID Protection 위험 수준 및 SaaS 애플리케이션
- Microsoft Graph API를 사용하고 프로덕션에 영향을 미치고 변경할 수 있는 스크립트 테스트
이전 시나리오와 같은 테스트를 수행하려는 경우 별도의 Microsoft Entra 테넌트가 유일한 옵션입니다.
그러나 별도의 Microsoft Entra 테넌트는 환경(예: 개발/테스트)에 관계없이 워크로드가 포함된 Azure 구독을 호스팅하기 위한 것이 아닙니다 . 개발/테스트 환경도 일반 "프로덕션" Microsoft Entra 테넌트에 포함되어야 합니다.
팁
Azure 랜딩 존 환경 내에서 Azure 랜딩 존 및 Azure 워크로드 또는 리소스 테스트를 처리하는 방법에 대한 자세한 내용은 다음을 참조하세요.
풀뿌리 / 그림자 IT / 신생
팀이 신속하게 혁신하려는 경우 가능한 한 빨리 이동할 수 있도록 별도의 Microsoft Entra 테넌트를 만들 수 있습니다. 의도적으로 또는 의도치 않게 혁신을 위해 Azure 환경에 액세스하기 위한 중앙/플랫폼 팀의 프로세스 및 지침을 피할 수 있습니다.
이 시나리오는 비즈니스 및 서비스를 실행, 호스트 및 운영하도록 자체 Microsoft Entra 테넌트 설정이 있는 신생 기업에서 일반적입니다. 일반적으로 예상할 수 있지만 스타트업을 인수할 때 추가 Microsoft Entra 테넌트는 인수 조직의 IT 팀이 앞으로 수행할 작업을 결정하는 의사 결정 지점을 만듭니다.
이 시나리오를 탐색하는 방법에 대한 자세한 내용은 이 문서의 Azure 섹션에서 SaaS 애플리케이션을 제공하는 ISV(인수 합병 및 독립 소프트웨어 공급업체)를 참조하세요.
Important
플랫폼 팀은 조직에 대한 회사 또는 기본 Microsoft Entra 테넌트에 있는 Azure 샌드박스 구독 또는 구독에 대한 액세스 권한을 팀에게 제공하는 쉽고 효율적인 프로세스를 제공하는 것이 좋습니다. 이 프로세스는 섀도 IT 시나리오가 발생하지 않도록 방지하고 향후 관련된 모든 당사자의 문제를 방지합니다.
샌드박스에 대한 자세한 내용은 리소스 조직 디자인 영역 내의 관리 그룹 지침을 참조 하세요.
요약
시나리오에 자세히 설명된 것처럼 조직에서 여러 Microsoft Entra 테넌트가 필요할 수 있는 몇 가지 이유가 있습니다. 그러나 이러한 시나리오 내에서 요구 사항을 충족하기 위해 여러 테넌트만 만들면 복잡성과 운영 작업을 추가하여 기본 여러 테넌트에 도달하고 라이선스 요구 사항에 대한 비용을 추가할 수 있습니다. 자세한 내용은 다중 테넌트 시나리오에서 Azure 랜딩 존에 대한 고려 사항 및 권장 사항을 참조 하세요.