대규모 기관을 위한 다중 테넌트 아키텍처 설계
소규모 기관에는 단일 테넌트 아키텍처를 사용하는 것이 좋습니다. 그러나 사용자가 100만 명이 넘는 조직의 경우 Azure 구독 및 할당량과 같은 성능 문제 및 테넌트 제한 사항과 Microsoft Entra 서비스 제한 및 제한을 완화하기 위해 다중 테넌트 아키텍처를 권장합니다.
디자인 원칙
다중 테넌트 아키텍처를 설계할 때 비용을 절감하고 효율성과 보안을 높이기 위해 다음 디자인 원칙을 고려합니다.
비용 절감
온-프레미스 인프라 및 여러 ID 공급자에 대한 의존도를 줄입니다.
사용자가 셀프 서비스(예: 셀프 서비스 암호 재설정 Microsoft Entra)를 사용하여 계정 잠금을 해제하거나 암호를 재설정할 수 있도록 설정합니다.
효율성 향상
테넌트 전체에서 아키텍처, 구성 및 프로세스를 표준화하여 관리 문제를 최소화합니다.
사용자가 한 테넌트에서 다른 테넌트로 이동할 필요 최소화
보안 강화
학생 데이터가 안전한지 확인하는 데 집중합니다.
최소 권한 원칙을 따릅니다. 필요한 작업을 수행하고 JIT(Just in Time) 액세스를 구현하는 데 필요한 권한만 부여합니다.
권한 관리 또는 Microsoft Entra B2B 협업을 통해서만 외부 사용자 액세스를 사용하도록 설정합니다.
작업을 수행할 JEA(Just Enough Access)를 사용하여 특정 작업의 관리를 위임합니다.
여러 테넌트에서 발생하는 일반적인 이유
사용자가 100만 명 미만인 조직은 다른 기준에 따라 여러 테넌트가 필요한 경우가 아니면 단일 테넌트 만들기를 강력히 권장합니다. 사용자 개체가 100만 개 이상인 조직의 경우 지역별 접근 방식을 사용하여 여러 테넌트하는 것이 좋습니다.
별도의 테넌트 만들기는 EDU 환경에 다음과 같은 영향을 줍니다.
관리 분리
중요한 리소스에 영향을 주는 관리 보안 또는 운영 오류의 영향을 제한할 수 있습니다.
손상된 관리자 또는 사용자 계정의 영향을 제한할 수 있습니다.
사용 현황 보고서 및 감사 로그는 테넌트 내에 포함됩니다.
리소스 분리
학생 개인 정보 보호. 학생 사용자 개체는 개체가 있는 테넌트 내에서만 검색할 수 있습니다.
리소스 격리. 별도의 테넌트의 리소스는 다른 테넌트의 사용자 및 관리자가 검색하거나 열거할 수 없습니다.
개체 공간입니다. Microsoft Graph 또는 기타 관리 인터페이스를 통해 Microsoft Entra ID 및 기타 Microsoft Online 서비스에 쓰는 애플리케이션은 로컬 테넌트에서 리소스에만 영향을 줄 수 있습니다.
할당량. 테넌트 전체 Azure 할당량 및 제한 사용 량은 다른 테넌트와 구분됩니다.
구성 분리
다양한 구성 요구 사항이 있는 리소스 및 신뢰 애플리케이션을 수용할 수 있는 별도의 테넌트 수준 설정 집합을 제공합니다.
Office 365 같은 새 Microsoft Online 서비스 집합을 사용하도록 설정합니다.
100만 명 이상의 사용자를 보유하는 것 외에도 다음과 같은 고려 사항으로 인해 여러 테넌트가 발생할 수 있습니다.
관리 고려 사항
시민권 국가, 거주 국가 또는 통관 수준과 같은 기준에 따라 환경을 관리할 수 있는 사용자를 제한하는 규정에 따라 운영됩니다.
특정 지역 지역에서 ID를 만들어야 하는 학생 데이터 개인 정보 보호와 같은 규정 준수 요구 사항이 있습니다.
리소스 고려 사항
규제 또는 비즈니스에 중요한 이유로 기존 관리자가 검색, 열거 또는 인수로부터 보호해야 하는 리소스(연구 및 개발을 위한 리소스)가 있습니다.
대규모로 MS Graph 또는 유사한 API를 사용하여 사용자의 데이터를 변경할 수 있는 사용자 지정 애플리케이션의 개발 주기(예: Directory.ReadWrite.All이 부여된 애플리케이션)
구성 고려 사항
- 허용된 인증 유형, 디바이스 관리 정책, 셀프 서비스 기능 또는 외부 ID에 대한 ID 증명과 같은 기존 테넌트 전체 보안 또는 공동 작업 상태와 충돌하는 요구 사항이 있는 리소스.
다중 테넌트 접근 방식 확인
이 섹션에서는 미국 전체 100개 학교에서 2백만 명의 학생이 있는 미술 학교라는 가상의 대학을 고려합니다. 이 학교에는 총 130,000명의 교사와 30,000명의 정규직 직원과 직원이 있습니다.
다음과 같이 여러 테넌트 배포 시 지역별 접근 방식을 사용하는 것이 좋습니다.
먼저 학생 및 교육자 커뮤니티를 각 지역에 100만 명 미만의 사용자가 포함된 지리적 지역으로 나눠야 합니다.
각 지역에 대한 Microsoft Entra 테넌트 만들기
해당 지역의 직원, 교사 및 학생을 프로비전하여 공동 작업 환경을 최적화합니다.
지역을 사용하는 이유는 무엇인가요?
테넌트 간에 이동하는 사용자 수를 최소화하려면 지역별 접근 방식을 사용하는 것이 좋습니다. 각 학교 수준(예: 초등학교, 중학교 및 고등학교)에 대한 테넌트 를 만든 경우 모든 학년 말에 사용자를 마이그레이션해야 합니다. 대신 사용자가 동일한 지역에 남아 있는 경우 특성이 변경되면 테넌트 간에 이동할 필요가 없습니다.
지역 접근 방식의 다른 이점은 다음과 같습니다.
각 지역 내에서 최적의 공동 작업
다른 테넌트에서 최소한의 게스트 개체가 필요합니다.
테넌트가 100만 명 이상의 사용자를 보유하고 있는 경우 관리 환경 및 도구는 시간이 지남에 따라 저하되는 경향이 있습니다. 마찬가지로 사람 선택기를 사용하는 것과 같은 일부 최종 사용자 환경은 번거롭고 신뢰할 수 없게 됩니다.
강력한 이유 없이 여러 테넌트 배포를 선택하는 소규모 조직은 관리 오버헤드와 사용자 마이그레이션 수를 불필요하게 증가합니다. 이렇게 하려면 테넌트 전체에서 공동 작업 환경을 보장하는 단계도 필요합니다.
Microsoft Entra B2B 협업을 사용하여 테넌트 간에 공동 작업
Microsoft Entra B2B 협업을 통해 사용자는 하나의 자격 증명 집합을 사용하여 여러 테넌트로 로그인할 수 있습니다. 교육 기관의 경우 B2B 협업의 이점은 다음과 같습니다.
여러 테넌트 관리 중앙 집중식 관리 팀
지역 간 교사 공동 작업
자신의 자격 증명으로 부모 및 보호자 온보딩
계약자 또는 연구원과 같은 외부 파트너십
B2B 협업을 사용하면 한 테넌트(홈 테넌트)에서 만든 사용자 계정이 게스트 사용자로 다른 테넌트(리소스 테넌트)에 초대되고 사용자는 홈 테넌트에서 자격 증명을 사용하여 로그인할 수 있습니다. 관리자는 B2B 협업을 사용하여 외부 사용자가 Facebook, Microsoft 계정, Google 또는 엔터프라이즈 ID 공급자와 같은 ID 공급자와의 페더레이션을 설정하여 기존 소셜 또는 엔터프라이즈 계정으로 로그인할 수 있도록 할 수도 있습니다.
멤버 및 게스트
Microsoft Entra 테넌트에서 사용자는 UserType 속성을 기반으로 하는 멤버 또는 게스트입니다. 기본적으로 멤버 사용자는 테넌트가 기본인 사용자입니다. Microsoft Entra B2B 협업 사용자는 기본적으로 UserType = Guest를 사용하는 사용자로 추가됩니다. 게스트는 디렉터리 및 애플리케이션에서 제한된 권한을 갖습니다. 예를 들어 게스트 사용자는 자신의 프로필 정보 이외의 테넌트에서 정보를 찾아볼 수 없습니다. 그러나 게스트 사용자는 UPN(사용자 계정 이름) 또는 objectId를 제공하여 다른 사용자에 대한 정보를 검색할 수 있습니다. 게스트 사용자는 게스트 사용자 권한 제한 설정에 관계없이 그룹 멤버 자격을 포함하여 속한 그룹의 속성을 읽을 수도 있습니다.
경우에 따라 리소스 테넌트는 홈 테넌트에서 사용자를 게스트 대신 멤버로 처리하려고 할 수 있습니다. 그렇다면 Microsoft Entra B2B 초대 관리자 API를 사용하여 홈 테넌트에서 리소스 테넌트로 사용자를 구성원으로 추가하거나 초대할 수 있습니다. 자세한 내용은 Microsoft Entra B2B 협업 사용자의 속성을 참조하세요.
여러 테넌트 중앙 집중식 관리
Microsoft Entra B2B를 사용하여 외부 ID를 온보딩합니다. 그런 다음 외부 ID에 권한 있는 역할을 할당하여 중앙 집중식 IT 팀의 구성원으로 Microsoft Entra 테넌트 관리를 수행할 수 있습니다. Microsoft Entra B2B를 사용하여 지역 또는 지구 수준의 관리자와 같은 다른 직원을 위한 게스트 계정을 만들 수도 있습니다.
그러나 Exchange 관리자 또는 SharePoint 관리자와 같은 서비스별 역할에는 테넌트가 기본인 로컬 계정이 필요합니다.
B2B 계정에 다음 역할을 할당할 수 있습니다.
응용 프로그램 관리자
응용 프로그램 개발자
인증 관리자
B2C IEF 키 집합 관리자
B2C IEF 정책 관리자
클라우드 애플리케이션 B2C IEF 정책 관리자
클라우드 디바이스 B2C IEF 정책 관리자
조건부 액세스 관리자
디바이스 관리자
디바이스 조인
디바이스 사용자
디렉터리 읽기 권한자
디렉터리 작성자
디렉터리 동기화 계정
외부 ID 사용자 흐름 관리자
외부 ID 사용자 흐름 특성 관리자
외부 ID 공급자
그룹 관리자
게스트 초대자
지원 센터 관리자
하이브리드 ID 관리자
Intune 서비스 관리자
라이선스 관리자
암호 관리자
권한 있는 인증 관리자
권한 있는 역할 관리자
보고서 읽기 권한자
제한된 게스트 사용자
보안 관리자
보안 읽기 권한자
사용자 계정 관리자
작업 공간 디바이스 조인
Microsoft Entra ID 사용자 지정 관리자 역할은기본 제공 역할의 기본 권한을 표시하므로 고유한 사용자 지정 역할을 만들고 구성할 수 있습니다. 이 방법을 사용하면 필요할 때마다 기본 제공 역할보다 더 세분화된 방식으로 액세스 권한을 부여할 수 있습니다.
다음은 여러 테넌트에서 위임하고 사용할 수 있는 관리 역할에 대해 관리가 작동하는 방법을 보여 주는 예제입니다.
Susie의 네이티브 계정은 지역 1 테넌트이며, Microsoft Entra B2B는 지역 2 및 지역 3에 대한 테넌트의 중앙 IT 팀에 인증 관리자로 계정을 추가하는 데 사용됩니다.
여러 테넌트에서 앱 사용
다중 테넌트 환경에서 앱 관리와 관련된 문제를 완화하려면 다중 테넌트 앱을 작성하는 것이 좋습니다. 또한 여러 IdP 연결을 지원하는 SaaS 앱도 확인해야 합니다. 여러 IDP 연결을 지원하는 SaaS 앱은 각 테넌트에서 개별 연결을 구성해야 합니다. 여러 IDP 연결을 지원하지 않는 SaaS 앱에는 독립적인 인스턴스가 필요할 수 있습니다. 자세한 내용은 방법: 다중 테넌트 애플리케이션 패턴을 사용하여 Microsoft Entra 사용자 로그인을 참조하세요.
참고: 라이선스 모델은 SaaS 앱마다 다를 수 있습니다. 다중 테넌트 환경에서 여러 구독이 필요한지 여부를 확인하기 위해 공급업체와 검사.
테넌트별 관리
서비스별 역할에는 테넌트별 관리가 필요합니다. 서비스별 역할에는 테넌트가 기본인 로컬 계정이 있어야 합니다. 각 테넌트에서 중앙 집중식 IT 팀을 보유하는 것 외에도 Exchange, SharePoint 및 Teams와 같은 워크로드를 관리하려면 각 테넌트에서 지역 IT 팀이 있어야 합니다.
다음 역할에는 각 테넌트가 기본으로 사용하는 계정이 필요합니다.
Azure DevOps 관리자
Azure Information Protection 관리자
대금 청구 관리자
CRM 서비스 관리자
규정 준수 관리자
규정 준수 데이터 관리자
고객 Lockbox 액세스 승인자
Desktop Analytics 관리자
Exchange 관리자
Insights 관리자
Insights 비즈니스 리더
Kaizala 관리자
Lync 서비스 관리자
메시지 센터 개인 정보 읽기 권한자
메시지 센터 판독기
프린터 관리자
프린터 기술자
검색 관리자
검색 편집기
보안 운영자
서비스 지원 관리자
SharePoint 관리자
Teams 통신 관리자
Teams 통신 지원 엔지니어
Teams 통신 지원 전문가
Teams 서비스 관리자
각 테넌트에서 고유한 관리자
각 지역에 네이티브 IT 팀이 있는 경우 해당 로컬 관리자 중 한 명이 Teams 관리를 관리하도록 할 수 있습니다. 다음 예제에서 Charles는 지역 1 테넌트에서 상주하며 Teams 서비스 관리자 역할을 합니다. Alice와 Ichiro는 각각 2와 3 지역에 있으며 해당 지역에서 동일한 역할을 맡습니다. 각 로컬 관리자는 해당 지역에 네이티브인 단일 계정을 가지고 있습니다.
테넌트 간 역할 관리
각 지역에 대한 로컬 관리자 풀이 없는 경우 Teams 서비스 관리자 역할을 한 명의 사용자에게만 할당할 수 있습니다. 이 시나리오에서는 아래 그림과 같이 중앙 IT 팀의 Bob이 각 테넌트에서 Bob에 대한 로컬 계정을 만들어 세 테넌트 모두에서 Teams 서비스 관리자 역할을 하게 할 수 있습니다.
테넌트 내의 관리자 역할 위임
관리 단위(AU)를 사용하여 사용자 및 그룹에 Microsoft Entra 논리적으로 그룹화해야 합니다. 관리 단위를 사용하여 관리 scope 제한하는 것은 다른 지역, 지구 또는 학교로 구성된 교육 조직에서 유용합니다.
예를 들어, 가상의 미술 학교는 각각 여러 학교를 포함하는 세 지역에 걸쳐 있습니다. 각 지역에는 액세스를 제어하고, 사용자를 관리하고, 해당 학교에 대한 정책을 설정하는 IT 관리자 팀이 있습니다.
예를 들어 IT 관리자는 다음을 수행할 수 있습니다.
지역 1의 각 학교에 대한 AU를 만들어 해당 학교의 모든 사용자를 관리합니다. (그림이 아님)
교사 계정을 관리하기 위해 각 학교의 교사가 포함된 AU를 만듭니다.
학생 계정을 관리하기 위해 각 학교의 학생이 포함된 별도의 AU를 만듭니다.
교사가 학생 암호를 재설정할 수 있지만 다른 사용자의 암호를 재설정할 수는 없도록 학교의 교사에게 학생 AU에 대한 암호 관리자 역할을 할당합니다.
관리 단위로 범위를 지정할 수 있는 역할은 다음과 같습니다.
인증 관리자
그룹 관리자
지원 센터 관리자
라이선스 관리자
암호 관리자
사용자 관리자
자세한 내용은 관리 단위에 범위가 지정된 역할 할당을 참조하세요.
테넌트 간 관리
설정은 각 테넌트에서 개별적으로 구성됩니다. 그런 다음 가능한 경우 테넌트 만들기의 일부로 구성하여 이러한 설정을 다시 방문하지 않아도 되는 것을 최소화합니다. 몇 가지 일반적인 작업을 자동화할 수 있지만 기본 제공 테넌트 간 관리 포털은 없습니다.
대규모 개체 관리
Microsoft Graph(MS Graph) 및 Microsoft Graph PowerShell 을 사용하면 디렉터리 개체를 대규모로 관리할 수 있습니다. 테넌트에서 대부분의 정책 및 설정을 관리하는 데 사용할 수도 있습니다. 그러나 다음과 같은 성능 고려 사항을 이해해야 합니다.
MS Graph는 사용자, 그룹 및 멤버 자격 변경의 생성을 시간당 테넌트당 72,000으로 제한합니다.
MS Graph 성능은 테넌트 내에서 읽기 또는 쓰기 작업과 같은 사용자 기반 작업의 영향을 받을 수 있습니다.
MS Graph 성능은 테넌트 내의 다른 경쟁 IT 관리자 작업의 영향을 받을 수 있습니다.
PowerShell, SDS, Microsoft Entra Connect 및 사용자 지정 프로비저닝 솔루션은 MS Graph를 통해 다양한 속도로 개체 및 멤버 자격을 추가합니다.
다음 단계
Microsoft Entra 테넌트 소개를 검토하지 않은 경우 그렇게 할 수 있습니다. 다음을 참조하세요.