여러 테넌트가 있는 리소스 격리
단일 테넌트 경계에서 관리를 위임하는 것이 요구 사항을 충족하지 않는 경우 특정 시나리오가 있습니다. 이 섹션에는 다중 테넌트 아키텍처를 만들도록 유도할 수 있는 요구 사항이 있습니다. 다중 테넌트 조직은 Microsoft Entra 테넌트 두 개 이상에 걸쳐 있을 수 있습니다. 이로 인해 고유한 테넌트 간 협업 및 관리 요구 사항이 발생할 수 있습니다. 다중 테넌트 아키텍처는 관리 오버헤드와 복잡성을 증가시키므로 주의해서 사용해야 합니다. 요구 사항이 아키텍처에서 충족될 수 있으면 단일 테넌트를 사용하는 것이 좋습니다. 자세한 내용은 다중 테넌트 사용자 관리를 참조하세요.
별도의 테넌트는 새 경계를 만들므로 이전 섹션의 설명대로 Microsoft Entra 디렉터리 역할, 디렉터리 개체, 조건부 액세스 정책, Azure 리소스 그룹, Azure 관리 그룹 및 기타 컨트롤의 관리가 분리되었습니다.
별도의 테넌트는 조직의 IT 부서에서 조직의 사용자와 리소스를 보호하면서 Intune, Microsoft Entra Connect 또는 하이브리드 인증 구성과 같은 Microsoft 서비스의 테넌트 전체 변경 사항의 유효성을 검사하는 데 유용합니다. 여기에는 테넌트 전체에 영향을 미칠 수 있고 범위를 프로덕션 테넌트의 사용자 하위 집합으로 지정할 수 없는 서비스 구성 테스트가 포함됩니다.
MS Graph 또는 유사한 API를 사용하여 프로덕션 사용자 개체의 데이터를 변경할 수 있는 사용자 지정 애플리케이션을 개발하는 동안 별도의 테넌트에 프로덕션이 아닌 환경을 배포해야 할 수 있습니다(예: Directory.ReadWrite.All 또는 이와 유사한 전체 범위가 부여된 애플리케이션).
참고 항목
Microsoft Entra Connect는 여러 테넌트에 동기화됩니다. 이는 별도의 테넌트에 프로덕션이 아닌 환경을 배포할 때 유용할 수 있습니다. 자세한 내용은 Microsoft Entra Connect: 지원되는 토폴로지를 참조하세요.
성과
앞서 설명한 대로 단일 테넌트 아키텍처를 통해 달성한 결과 외에도 조직은 리소스와 테넌트 상호 작용을 완전히 분리할 수 있습니다.
리소스 분리
표시 유형 - 다른 테넌트의 사용자와 관리자가 별도의 테넌트 내 리소스를 검색하거나 열거할 수 없습니다. 마찬가지로, 사용량 보고서와 감사 로그는 새 테넌트 경계 내에 포함됩니다. 이러한 가시성 분리를 통해 조직은 기밀 프로젝트에 필요한 리소스를 관리할 수 있습니다.
개체 공간 - Microsoft Graph 또는 기타 관리 인터페이스를 통해 Microsoft Entra ID 및/또는 기타 Microsoft Online 서비스에 쓰는 애플리케이션은 별도의 개체 공간에서 작동할 수 있습니다. 이렇게 하면 개발 팀이 다른 테넌트에 영향을 주지 않고 소프트웨어 개발 수명 주기 동안 테스트를 수행할 수 있습니다.
할당량 - 테넌트 전체 Azure 할당량 및 한도의 사용량은 다른 테넌트와 구분됩니다.
구성 분리
새 테넌트는 테넌트 수준에서 서로 다른 구성이 필요한 요구 사항이 있는 리소스와 트러스팅 애플리케이션을 수용할 수 있는 별도의 테넌트 전체 설정 세트를 제공합니다. 또한 새 테넌트는 Office 365와 같은 새 Microsoft Online 서비스 세트를 제공합니다.
관리 분리
새 테넌트 경계에는 서로 다른 관리자 세트를 구성할 수 있는 별도의 Microsoft Entra 디렉터리 역할 세트가 포함됩니다.
일반적인 사용
다음 다이어그램에서는 단일 테넌트에서 위임된 관리를 통해 얻을 수 있는 것보다 더 많은 분리가 필요한 사전 프로덕션이나 "샌드박스" 환경과 같은 여러 테넌트에서 일반적인 리소스 격리 사용을 보여 줍니다.
Contoso는 ContosoSandbox.com이라는 사전 프로덕션 테넌트를 사용하여 회사 테넌트 아키텍처를 보강한 조직입니다. 샌드박스 테넌트는 Microsoft Graph를 사용하여 Microsoft Entra ID 및 Microsoft 365에 쓰는 엔터프라이즈 솔루션의 지속적인 개발을 지원하는 데 사용됩니다. 이러한 솔루션은 기업 테넌트에 배포됩니다.
샌드박스 테넌트는 개발 중인 애플리케이션이 테넌트 리소스를 사용하고 할당량에 영향을 주거나 할당량을 제한하여 프로덕션 시스템에 직접 또는 간접적으로 영향을 미치지 않도록 하기 위해 온라인 상태가 됩니다.
개발자는 개발 수명 주기 동안 샌드박스 테넌트에 액세스해야 하며 프로덕션 환경에서 제한되는 추가 권한이 필요한 셀프 서비스 액세스를 사용하는 것이 좋습니다. 이러한 추가 권한의 예로는 사용자 계정 만들기, 삭제 및 업데이트, 애플리케이션 등록, Azure 리소스 프로비전 및 프로비전 해제, 정책 변경 또는 환경의 전반적인 구성이 포함될 수 있습니다.
이 예제에서 Contoso는 Microsoft Entra B2B Collaboration을 사용하여 사용자가 자격 증명 여러 개를 관리하지 않고 샌드박스 테넌트의 애플리케이션에서 리소스를 관리하고 액세스할 수 있도록 회사 테넌트의 사용자를 프로비전합니다. 이 기능은 주로 조직 간 협업 시나리오를 지향합니다. 그러나 Contoso와 같은 테넌트가 여러 개 있는 기업은 이 기능을 사용하여 추가 자격 증명 수명 주기 관리와 사용자 환경 복잡성을 방지할 수 있습니다.
외부 ID 테넌트 간 액세스 설정을 사용하여 B2B 협업을 통해 다른 Microsoft Entra 조직과 협업하는 방법을 관리합니다. 이러한 설정은 외부 Microsoft Entra 조직의 사용자가 리소스에 대해 갖는 인바운드 액세스 수준과 사용자가 외부 조직에 대해 갖는 아웃바운드 액세스 수준을 모두 결정합니다. 또한 다른 Microsoft Entra 조직의 MFA(다단계 인증) 및 디바이스 클레임(규정 준수 클레임 및 Microsoft Entra 하이브리드 조인 클레임)을 신뢰할 수 있습니다. 자세한 내용 및 계획 고려 사항은 Microsoft Entra 외부 ID의 테넌트 간 액세스를 참조하세요.
또 다른 방법은 Microsoft Entra Connect의 기능을 활용하여 동일한 온-프레미스 Microsoft Entra 자격 증명을 테넌트 여러 개에 동기화함으로써 같은 암호를 유지하지만 사용자 UPN 도메인에서 차별화하는 것일 수 있습니다.
다중 테넌트 리소스 격리
새 테넌트를 사용하면 별도의 관리자 집합이 있습니다. 조직은 Microsoft Entra B2B 협업을 통해 회사 ID를 사용할 수 있습니다. 마찬가지로, 조직은 프로덕션이 아닌 Azure 구독을 프로덕션에 대응하는 ID로 관리하도록 Azure 리소스의 테넌트 간 관리에 Azure Lighthouse를 구현할 수 있습니다. Azure Lighthouse는 Microsoft Intune과 같은 Azure 외부에서 서비스를 관리하는 데 사용될 수 없습니다. MSP(관리되는 서비스 공급자)의 경우 Microsoft 365 Lighthouse는 Microsoft 365 Business Premium, Microsoft 365 E3 또는 Windows 365 Business를 사용하는 SMB(중소기업) 고객의 대규모 디바이스, 데이터 및 사용자를 보호하고 관리할 수 있는 관리 포털입니다.
이렇게 하면 사용자가 분리의 이점을 얻으면서 회사 자격 증명을 계속 사용할 수 있습니다.
샌드박스 테넌트의 Microsoft Entra B2B 협업에서 Azure B2B 허용/거부 목록을 사용하여 온보딩할 수 있도록 기업 환경의 ID만 허용하도록 구성해야 합니다. B2B에 허용하려는 테넌트에 테넌트 간 다단계 인증\디바이스 트러스트에 테넌트 간 외부 ID 액세스 설정을 사용하는 것이 좋습니다.
Important
외부 ID 액세스를 사용하도록 설정된 다중 테넌트 아키텍처는 리소스 격리만 제공하지만 ID 격리를 사용하지는 않습니다. Microsoft Entra B2B 협업 및 Azure Lighthouse를 사용한 리소스 격리는 ID와 관련된 위험을 완화하지 않습니다.
샌드박스 환경이 회사 환경과 ID를 공유하는 경우 다음 시나리오가 샌드박스 테넌트에 적용됩니다.
회사 테넌트 내 사용자, 디바이스 또는 하이브리드 인프라를 손상시키고 샌드박스 테넌트에 초대되는 악의적인 작업자가 샌드박스 테넌트의 앱과 리소스에 액세스할 수 있습니다.
회사 테넌트의 운영 오류(예: 사용자 계정 삭제 또는 자격 증명 해지)는 샌드박스 테넌트에 초대된 사용자의 액세스에 영향을 줄 수 있습니다.
위험 분석을 수행하고 매우 방어적인 방식이 필요한 중요 비즈니스용 리소스의 테넌트 여러 개를 통한 ID 격리를 고려해야 합니다. Azure Privileged Identity Management는 중요 비즈니스용 테넌트 및 리소스 액세스에 대한 추가 보안을 도입하여 일부 위험을 완화하는 데 도움이 될 수 있습니다.
디렉터리 개체
리소스를 격리하는 데 사용하는 테넌트에는 기본 테넌트와 동일한 유형의 개체, Azure 리소스 및 트러스팅 애플리케이션이 포함될 수 있습니다. 다음 개체 형식을 프로비전해야 할 수 있습니다.
사용자 및 그룹: 솔루션 엔지니어링 팀에서 필요한 ID. 예를 들면 다음과 같습니다.
샌드박스 환경 관리자
애플리케이션 기술 소유자
기간 업무 앱 개발자
최종 사용자 계정을 테스트합니다.
이러한 ID는 다음을 위해 프로비전될 수 있습니다.
Microsoft Entra B2B 협업을 통해 회사 계정을 사용하는 직원
관리, 긴급 관리 액세스 또는 기타 기술적 이유로 로컬 계정이 필요한 직원
프로덕션이 아닌 Active Directory 온-프레미스가 있거나 필요한 고객은 기본 리소스와 애플리케이션에서 필요한 경우 온-프레미스 ID를 샌드박스 테넌트와 동기화할 수도 있습니다.
디바이스: 프로덕션이 아닌 테넌트에는 솔루션 엔지니어링 주기에 필요한 범위까지 디바이스 수가 줄어듭니다.
관리 워크스테이션
개발, 테스트 및 문서에 필요한 프로덕션이 아닌 컴퓨터 및 모바일 디바이스
애플리케이션
Microsoft Entra 통합 애플리케이션: 애플리케이션 개체 및 서비스 주체:
프로덕션 환경에 배포된 애플리케이션(예: Microsoft Entra ID 및 Microsoft Online Services에 쓰는 애플리케이션)의 인스턴스를 테스트합니다.
프로덕션이 아닌 테넌트를 관리하고 유지하는 인프라 서비스로, 잠재적으로 회사 테넌트에서 사용할 수 있는 솔루션의 하위 집합입니다.
Microsoft Online Services:
일반적으로 프로덕션의 Microsoft Online Services를 소유하는 팀은 해당 서비스의 프로덕션이 아닌 인스턴스를 소유해야 합니다.
프로덕션이 아닌 테스트 환경의 관리자는 해당 서비스를 특별히 테스트하지 않는 한 Microsoft Online Services를 프로비전하면 안 됩니다. 이렇게 하면 Microsoft 서비스의 부적절한 사용(예: 테스트 환경에서 프로덕션 SharePoint 사이트 설정)을 방지할 수 있습니다.
마찬가지로, 최종 사용자(임시 구독이라고도 함)가 시작할 수 있는 Microsoft Online Services의 프로비전을 잠가야 합니다. 자세한 내용은 Microsoft Entra ID 셀프 서비스 등록이란?을 참조하세요.
일반적으로 그룹 기반 라이선스를 사용하여 테넌트에 필수가 아닌 모든 라이선스 기능을 사용하지 않아야 합니다. 사용이 허가된 기능 사용의 영향을 모르는 개발자가 잘못 구성하지 않도록 프로덕션 테넌트에서 라이선스를 관리하는 동일한 팀에서 이 작업을 수행해야 합니다.
Azure 리소스
트러스팅 애플리케이션에서 필요한 모든 Azure 리소스도 배포될 수 있습니다. 예를 들어, 데이터베이스, 가상 머신, 컨테이너, Azure 함수 등이 있습니다. 샌드박스 환경의 경우 사용 가능한 보안 기능이 적은 제품 및 서비스에 대해 저렴한 SKU를 사용하여 비용 절감을 고려해야 합니다.
테스트가 완료된 후 변경 사항이 프로덕션으로 복제되는 경우 액세스 제어용 RBAC 모델을 프로덕션이 아닌 환경에서 계속 사용해야 합니다. 그렇지 않으면 비프로덕션 환경의 보안 결함이 프로덕션 테넌트에 전파될 수 있습니다.
여러 테넌트로 리소스 및 ID 격리
격리 결과
리소스 격리가 요구 사항을 충족할 수 없는 제한된 상황이 있습니다. 모든 테넌트 간 협업 기능을 사용하지 않고 별도의 ID 경계를 효과적으로 빌드하여 다중 테넌트 아키텍처에서 리소스와 ID를 모두 격리할 수 있습니다. 이 방법은 회사 테넌트에서 운영 오류 및 사용자 ID, 디바이스 또는 하이브리드 인프라의 손상에 대한 방어책입니다.
일반 사용 격리
별도의 ID 경계는 일반적으로 중요 비즈니스용 애플리케이션과 리소스(예: 고객 관련 서비스)에 사용됩니다. 이 시나리오에서 Fabrikam은 SaaS 고객에게 영향을 주는 직원 ID 손상 위험이 방지되도록 고객 지향 SaaS 제품에 별도의 테넌트를 만들기로 결정했습니다. 다음 다이어그램에서는 이 아키텍처를 보여 줍니다.
FabrikamSaaS 테넌트에는 Fabrikam 비즈니스 모델의 일부로 고객에게 제공되는 애플리케이션에 사용되는 환경이 포함되어 있습니다.
디렉터리 개체 격리
FabrikamSaas의 디렉터리 개체는 다음과 같습니다.
사용자 및 그룹: 솔루션 IT 팀, 고객 지원 직원 또는 기타 필요한 담당자가 필요한 ID는 SaaS 테넌트 내에서 생성됩니다. 격리를 유지하기 위해 로컬 계정만 사용되며 Microsoft Entra B2B 협업은 사용되지 않습니다.
Azure AD B2C 디렉터리 개체: 고객이 테넌트 환경에 액세스하는 경우 Azure AD B2C 테넌트와 관련 ID 개체가 포함될 수 있습니다. 이러한 디렉터리를 보유하는 구독은 격리된 소비자 지향 환경에 적합한 후보입니다.
디바이스: 이 테넌트에는 디바이스 수가 줄어들어 고객 지향 솔루션을 실행하는 데 필요한 솔루션만 포함됩니다.
보안 관리 워크스테이션
지원 담당자 워크스테이션(위 설명대로 "통화 중"인 엔지니어를 포함할 수 있음)
애플리케이션 격리
Microsoft Entra 통합 애플리케이션: 애플리케이션 개체 및 서비스 주체:
프로덕션 애플리케이션(예: 다중 테넌트 애플리케이션 정의)
고객 지향 환경을 관리하고 유지하는 인프라 서비스
Azure 리소스: 고객 지향 프로덕션 인스턴스의 IaaS, PaaS 및 SaaS 리소스를 호스트합니다.