테넌트 간 협업을 위한 토폴로지
조직은 종종 인수 및 합병, 규제 요구 사항 또는 관리 경계로 인해 여러 테넌트를 관리해야 하는 상황에 처하게 됩니다. 시나리오에 관계없이 Microsoft Entra는 테넌트 간에 계정을 프로비전하고 원활한 협업을 촉진하는 유연하고 바로 사용할 수 있는 솔루션을 제공합니다. Microsoft Entra는 다음 세 가지 모델을 수용하며 변화하는 조직의 요구 사항에 맞게 조정할 수 있습니다.
- 허브 및 스포크
- 메시
- 적시
허브 및 스포크
허브 및 스포크 토폴로지에서는 다음과 같은 두 가지 일반적인 패턴을 제공합니다.
옵션 1(애플리케이션 허브): 이 옵션에서는 일반적으로 사용되는 애플리케이션을 조직 전체의 사용자가 액세스할 수 있는 중앙 허브 테넌트에 통합할 수 있습니다.
옵션 2(사용자 허브): 또는 옵션 2에서 단일 테넌트에 있는 모든 사용자를 중앙 집중화하고 리소스가 관리되는 스포크 테넌트에 프로비전합니다.
몇 가지 실제 시나리오를 살펴보고 이러한 각 모델에 맞게 조정하는 방법을 살펴보겠습니다.
인수 및 합병(애플리케이션 허브)
인수 및 합병 중에는 협업을 신속하게 가능하게 하는 기능이 중요하므로 복잡한 IT 의사 결정이 이루어지는 동안 기업이 응집력 있게 작동할 수 있습니다. 예를 들어, 새로 인수한 회사의 직원이 내부 지원 센터 티켓팅 시스템이나 복지 애플리케이션과 같은 애플리케이션에 즉시 액세스해야 하는 경우 테넌트 간 동기화가 매우 중요합니다. 이러한 동기화 프로세스를 통해 인수한 회사의 사용자는 첫날부터 애플리케이션 허브에 프로비전되어 SaaS 앱, 온프레미스 애플리케이션 및 기타 클라우드 리소스에 대한 액세스 권한을 부여받을 수 있습니다. 대상 테넌트 내에서 관리자는 비즈니스에 중요한 데이터가 포함된 Salesforce 및 Amazon Web Services와 같은 추가 애플리케이션에 대한 시간 제한 액세스 권한을 부여하도록 액세스 패키지를 설정할 수 있습니다. 다음 다이어그램은 최근에 인수한 테넌트(왼쪽)와 해당 사용자가 모회사의 테넌트로 프로비전되어 사용자에게 필요한 리소스에 대한 액세스 권한을 부여하는 것을 보여줍니다.
별도의 협업 및 리소스 테넌트(사용자 허브)
조직에서 Azure 사용량을 확장함에 따라 중요한 Azure 리소스를 관리하기 위한 전용 테넌트를 만드는 경우가 많습니다. 한편, 사용자 프로비전은 중앙 허브 테넌트에 의존합니다. 이 모델을 통해 허브 테넌트의 관리자는 중앙 보안 및 거버넌스 정책을 수립하는 동시에 개발 팀에 필요한 Azure 리소스를 배포할 수 있는 더 큰 자율성과 민첩성을 부여할 수 있습니다. 테넌트 간 동기화는 관리자가 사용자의 하위 집합을 스포크 테넌트로 프로비전하고 해당 사용자의 수명 주기를 관리할 수 있도록 하여 이 토폴로지를 지원합니다.
메시
일부 기업은 단일 테넌트 내에서 사용자를 중앙 집중화하는 반면, 어떤 기업은 각 테넌트에 애플리케이션, HR 시스템 및 Active Directory 도메인을 통합하여 보다 분산된 구조를 가지고 있습니다. 테넌트 간 동기화는 각 테넌트에 프로비전되는 사용자를 유연하게 선택할 수 있습니다.
포트폴리오 회사 내에서 협업(부분 메시)
이 시나리오에서 각 테넌트는 동일한 부모 조직 내의 다른 회사를 나타냅니다. 각 테넌트의 관리자는 대상 테넌트에 프로비전할 사용자 하위 집합을 선택합니다. 이 솔루션은 각 테넌트가 독립적으로 운영할 수 있는 유연성을 제공하는 동시에 사용자가 중요한 리소스에 액세스해야 할 때 협업을 촉진합니다.
한 가지 방법으로 테넌트 간 동기화가 있습니다. 내부 구성원 사용자는 외부 사용자로 여러 테넌트로 동기화할 수 있습니다. 토폴로지에서 양방향으로 진행되는 동기화가 표시되면 각 방향의 고유한 사용자 집합이며 각 화살표는 별도의 구성입니다.
사업부 간 협업(풀 메시)
이 시나리오에서 조직은 각 사업부에 대해 서로 다른 테넌트를 지정했습니다. 사업부는 특히 Microsoft Teams를 사용하여 긴밀하게 협력합니다. 결과적으로 각 테넌트는 조직의 4개 테넌트에 걸쳐 모든 사용자를 프로비전하기로 선택했습니다. 신규 사용자가 회사에 합류하거나 퇴사하면 프로비전 서비스에서 사용자 만들기 및 삭제를 담당합니다. 또한 조직은 4개의 테넌트를 모두 포함하는 다중 테넌트 조직을 구성했습니다. 이제 사용자가 Teams에서 협업해야 할 때 회사 전체에서 사용자를 쉽게 찾고 해당 사용자와 채팅 및 모임을 시작할 수 있습니다.
적시
지금까지 논의한 시나리오는 조직 내 협업을 다루고 있지만, 조직 간 협업이 필수적인 경우도 있습니다. 이는 합작 투자 또는 독립 법인의 조직과 같은 맥락에서 발생할 수 있습니다. 연결된 조직 및 권한 관리를 사용하면 연결된 조직 전반에서 리소스에 액세스하는 정책을 정의하고 사용자가 필요한 리소스에 대한 액세스를 요청할 수 있습니다.
합작 투자
다년간의 합작 투자에 참여한 별도의 조직인 Contoso와 Litware를 예로 들어 보겠습니다. 이들은 긴밀하게 협업해야 합니다. Contoso의 관리자는 Litware 사용자가 요구하는 리소스를 포함하는 액세스 패키지를 정의했습니다. Litware의 새로운 직원이 Contoso의 리소스에 액세스해야 하는 경우 액세스 패키지에 대한 액세스를 요청할 수 있습니다. 승인되면 필요한 리소스로 프로비전됩니다. 액세스 권한은 시간 제한이 있을 수 있으며 Contoso의 거버넌스 요건을 준수하기 위해 주기적으로 검토될 수 있습니다.
다음 다이어그램은 연결된 조직 및 권한 관리를 사용하여 두 조직이 적시에 협업하는 방법을 보여줍니다.
지원되는 시나리오
테넌트 간 동기화는 소스 테넌트에서 내부 사용자를 가져오고 대상 테넌트에서 외부 사용자를 프로비전하는 작업을 지원합니다.
| 소스 테넌트 자격 증명 | 소스 테넌트 userType | 대상 테넌트 자격 증명 | 대상 테넌트 userType | 지원되는 시나리오가 있나요? |
|---|---|---|---|---|
| 내부 | 구성원 | 외부 | 구성원 | 예 |
| 내부 | 구성원 | 외부 | 게스트 | 예 |
| 내부 | 게스트 | 외부 | 구성원 | 예 |
| 내부 | 게스트 | 외부 | 게스트 | 예 |
| 내부 | 구성원 | 내부 | 구성원 | 아니요 |
| 내부 | 구성원 | 내부 | 게스트 | 아니요 |
| 내부 | 게스트 | 내부 | 구성원 | 아니요 |
| 내부 | 게스트 | 내부 | 게스트 | 아니요 |
| 외부 | 구성원 | 외부 | 구성원 | 아니요 |
| 외부 | 구성원 | 외부 | 게스트 | 아니요 |
| 외부 | 게스트 | 외부 | 구성원 | 아니요 |
| 외부 | 게스트 | 외부 | 게스트 | 아니요 |