다중 테넌트 방어 조직에 대한 제로 트러스트 구성

이 문서에서는 Microsoft Entra ID에서 구성을 적용하고 일반적인 방어 제로 트러스트 요구 사항을 충족하는 방법을 다중 테넌트 조직에 보여 줍니다. 이러한 권장 사항에 따라 올바른 다중 테넌트 ID 아키텍처를 설정하고 사용자 환경에서 제로 트러스트를 구현합니다.

그림 1: 제로 트러스트 구성을 사용하는 샘플 다중 테넌트 방어 아키텍처입니다.

ID 아키텍처 확인

Microsoft Entra 테넌트는 ID 아키텍처의 기초입니다. 테넌트는 Microsoft Entra ID의 ID 경계입니다. 하나의 Microsoft Entra 테넌트가 있는 조직에는 단일 테넌트 아키텍처가 있습니다. 둘 이상의 Microsoft Entra 테넌트를 사용하는 조직에는 다중 테넌트 아키텍처가 있습니다.

단일 테넌트 혜택. 단일 테넌트는 운영 효율성을 통해 더 쉽게 관리하고 비용을 절감할 수 있습니다. 이를 통해 제로 트러스트 환경을 더 쉽게 구성할 수 있습니다. 단일 테넌트는 여러 로그인 자격 증명을 사용하여 사용자 환경을 조각화하지 않습니다. 나중에 통합해야 하는 사일로 솔루션도 방지할 수 있습니다. 데이터, Microsoft 365 및 Azure 클라우드 서비스를 단일 테넌트에 두려고 노력해야 합니다. 이미 여러 Microsoft Entra 테넌트가 있는 경우 단일 테넌트를 사용하도록 환경을 통합하는 것이 좋습니다. 보조 테넌트에서 기본 테넌트로 Azure 구독을 전송하여 테넌트 통합을 수행할 수 있습니다. 자세한 내용은 Azure 구독을 다른 Microsoft Entra 디렉터리로 전송하는 것을 참조 하세요.

다중 테넌트 사용 사례. 방어 조직에서 다중 테넌트 아키텍처를 사용하는 데는 이유가 있습니다. 크고 복잡한 방어 조직은 보안, 규정 준수 및 협업을 위해 여러 Microsoft Entra 테넌트가 필요할 수 있습니다(표 1 참조).

표 1. 여러 테넌트가 있거나 여러 테넌트만 만들어야 하는 이유입니다.

여러 Microsoft Entra 테넌트가 필요한 경우 Microsoft Entra 외부 ID(B2B) 및 Azure Lighthouse를 사용해야 합니다. 이러한 기능은 다중 테넌트 방어 환경을 지원하는 데 도움이 됩니다. 자세한 내용은 다중 테넌트 솔루션에 대한 테넌트 모델을 참조 하세요.

테넌트 유형 식별

다중 테넌트 방어 조직은 기본 또는 보조로 사용하는 Microsoft Entra 인스턴스를 분류할 수 있습니다. 각 조직은 하나의 테넌트 하나를 기본 테넌트로 식별하고 지정해야 합니다. 다른 모든 테넌트는 보조 테넌트입니다. 그림 1 은 기본 테넌트와 n 개의 보조 테넌트가 있는 방어 조직(표시된 두 개의 보조 테넌트)을 보여 줍니다.

기본 테넌트 식별 대부분의 방어 조직은 Microsoft 365에 등록할 때 기본 테넌트 만들기 기본 테넌트에는 (1) 모든 사용자 ID 및 Microsoft 365 라이선스, (2) 디바이스 및 (3) 애플리케이션이 포함됩니다(그림 1 참조). 방어 조직은 종종 Microsoft Entra Connect를 사용하여 Active Directory 온-프레미스에서 기본 Microsoft Entra 테넌트로 ID를 동기화합니다.

일부 방어 조직은 외부 기관이 소유하고 운영하는 공유 테넌트에서 Microsoft 365를 사용합니다. 이 기관은 Microsoft 365의 공유 서비스 공급자 역할을 합니다. 조직에서 공유 테넌트 관리 또는 제어를 하지 않을 수 있지만 사용자가 Office 365 및 기타 응용 프로그램에 사용할 수 있는 라이선스가 부여된 Microsoft Entra ID가 포함되어 있습니다. 이 시나리오에서 공유 서비스 공급자 테넌트는 기본 테넌트입니다.

모든 보조 테넌트(다중 테넌트인 경우)를 식별합니다. 조직에서 관리하는 다른 모든 테넌트는 보조 테넌트입니다. 엔터프라이즈 규모 Azure 랜딩 존을 설정 하기 전에 애플리케이션을 클라우드로 마이그레이션한 경우 보조 테넌트가 있을 수 있습니다. 일반적으로 보조 테넌트는 (4) 외부 사용자(B2B 게스트) 또는 (5) 클라우드 전용 계정으로 Azure 워크로드를 관리합니다(그림 1 참조).

의사 결정 트리를 사용합니다. 기본 테넌트 찾기의 가장 쉬운 방법은 Microsoft Entra ID에 있는 ID 라이선스를 고려하는 것입니다.

Microsoft 365 라이선스가 있는 테넌트는 기본 테넌트입니다(그림 2 참조). 기본 테넌트는 조직에서 만든 첫 번째 테넌트가 아닐 수도 있지만 모든 사용자와 Microsoft 365 라이선스가 있는 주 테넌트가 되어야 합니다.

조직에서 Microsoft 365를 사용하지 않는 경우 EMS(Enterprise Mobility and Security) 라이선스가 있는 Microsoft Entra 테넌트가 기본 테넌트입니다. 이 테넌트는 조직의 도메인 이름을 추가하고 확인한 위치입니다. 테넌트는 종종 하이브리드 ID를 사용하거나 HR(인사) 시스템과 통합됩니다(그림 2 참조).

그림 2. Microsoft Entra 기본 테넌트 및 보조 테넌트를 결정하는 의사 결정 트리입니다.

Microsoft Entra ID를 제로 트러스트 플랫폼으로 설정하려면 사용자 ID로 채워지고 사용자 및 디바이스 기반 액세스 정책에 대한 라이선스가 부여된 테넌트가 필요합니다. Microsoft 365 라이선스는 Office 365와 함께 이러한 제로 트러스트 기능을 번들로 제공합니다. Microsoft 365를 사용하지 않는 경우 Enterprise Mobility + Security E5를 사용하여 제로 트러스트를 위한 클라우드 기반 ID 공급자를 설정하는 것이 좋습니다. 자세한 내용은 ID 기관 선택을 참조 하세요.

제로 트러스트 구성

Microsoft Entra ID에서 ID를 관리할 때 각 테넌트 유형에 대해 다음 권장 사항을 고려해야 합니다. 먼저 채택해야 하는 모든 테넌트 유형에 대한 일반적인 권장 사항이 있습니다. 이러한 일반 권장 사항을 구현한 후 특정 테넌트 유형(기본 또는 보조)에 대한 권장 사항을 찾은 다음 해당 권장 사항을 적용합니다.

신뢰가 없는 Microsoft Entra 테넌트 보안에 대한 자세한 내용은 제로 트러스트 빠른 현대화 계획 및 보안 빠른 현대화 계획을 참조하세요.

모든 테넌트

모든 Microsoft Entra 테넌트에서 다음 권장 사항을 구현해야 합니다.

긴급 액세스 계정 및 절차를 설정합니다. Microsoft Entra 테넌트에서 잠기지 않도록 두 개 이상의 응급 액세스 계정을 만듭니다. 이러한 계정에 전역 관리자 역할을 할당해야 합니다. 계정은 클라우드 전용 계정이어야 합니다. 클라우드 전용 계정은 *.onmicrosoft.com 도메인을 사용합니다. 자세한 내용은 응급 액세스 관리자 계정 관리를 참조 하세요.

온-프레미스 공격으로부터 Microsoft Entra ID를 보호합니다. 권한 있는 액세스 보안에 설명된 모범 사례를 따릅니다. 하드웨어 암호 또는 인증서 기반 인증과 같은 피싱에 강한 자격 증명이 있는 클라우드 전용 사용자 계정에만 Microsoft Entra 권한을 할당합니다. 관리 목적으로 페더레이션 ID를 사용하지 마세요. 자세한 내용은 온-프레미스 공격으로부터 Microsoft 365 보호를 참조 하세요.

Privileged Identity Management를 사용합니다. Microsoft Entra PIM(Privileged Identity Management)을 사용하여 Microsoft Entra ID 및 Azure 역할에 대한 역할 할당을 관리합니다. 또한 PIM을 사용하여 권한 있는 보안 그룹에 적합한 그룹 멤버 자격을 관리해야 합니다. 적격 관리자 및 외부 사용자(B2B 게스트)에 대한 정기 액세스 검토를 설정합니다.

모든 사용자에 대해 클라우드 기반 인증을 사용하도록 설정합니다. 클라우드 기반 인증 방법은 페더레이션 인증보다 더 안전합니다. Microsoft Entra 조인 디바이스와 결합하면 더 나은 Single Sign-On 환경을 제공합니다. 페더레이션 인증은 microsoft Entra ID를 온-프레미스 Active Directory 손상에 노출합니다.

MICROSOFT Entra CBA(인증서 기반 인증) 를 사용하면 Microsoft Entra 도메인을 페더레이션할 필요가 없습니다. Microsoft Entra 인증은 다음과 같은 암호 없는 인증 방법을 지원합니다.

• Passkeys(FIDO2 보안 키)
• 인증서 기반 인증
• Microsoft 인증자
• 비즈니스용 Windows Hello

기준 조건부 액세스 정책을 설정합니다. 조건부 액세스 기준은 조직 및 요구 사항에 따라 다릅니다. 모든 Microsoft Entra 테넌트에 대한 핵심 조건부 액세스 정책 집합을 설정합니다. 정책 집합 내에서 ID, 디바이스, 애플리케이션 및 위험 조건을 사용합니다. 조건부 액세스 정책에서 응급 액세스 계정을 제외합니다.

Microsoft Entra ID Protection 을 사용하면 조직에서 ID 기반 위험을 감지, 조사 및 수정 할 수 있습니다. 위험한 로그인 및 사용자를 보호하려면 위험 조건이 있는 조건부 액세스 정책을 만듭니다. 위험한 사용자 및 위험한 로그인에 대해 별도의 정책을 사용합니다. 각 위험 유형에 대한 위험 수준으로 적용된 컨트롤을 늘입니다. 보안과 사용자 생산성의 균형을 맞추려면 위험 기반 정책에서 차단 컨트롤을 사용하지 않도록 합니다.

예제 조건부 액세스 정책 검사 목록을 사용하여 조직에 대한 조건부 액세스 정책을 디자인합니다(표 2 참조). 프로덕션 환경에 배포하기 전에 보고서 전용 모드를 사용하여 조건부 액세스 정책을 테스트합니다.

표 2: 조건부 액세스 정책 검사 목록 예제입니다.

표 2에 설정된 예제 정책은 모든 사용자가 관리되는 디바이스에서 피싱 방지 MFA만 사용하는 암호 없는 조직을 위한 것입니다. 권한 있는 사용자는 Intune 관리 PAW(Privileged Access Workstations)를 사용합니다. 위험도가 높은 사용자를 위해 암호 변경을 요구하는 대신 위험한 사용자 정책은 인증 강도 및 로그인 빈도 제어를 적용합니다. 이러한 컨트롤은 일부 보호를 제공하지만 Microsoft Entra ID Protection에서 사용자의 위험 수준을 수정하지는 않습니다. 보안 운영 팀은 위험 수준이 높은 사용자를 조사하고 수정해야 합니다.

조건부 액세스 배포에 대한 자세한 내용은 조건부 액세스 배포 계획을 참조하세요.

모든 애플리케이션에 액세스하기 위해 기본 테넌트 ID를 사용합니다. 사용자는 기본 테넌트에서 ID를 사용하여 애플리케이션에 액세스할 수 있어야 합니다. 기본 테넌트에 애플리케이션을 등록해야 합니다. 애플리케이션 인프라 호스팅 위치에 관계없이 기본 테넌트에 애플리케이션을 등록하는 정책을 설정합니다.

최신 인증 프로토콜을 지원하지 않는 레거시 애플리케이션의 경우 기본 테넌트에서 Microsoft Entra 애플리케이션 프록시 서비스를 사용합니다. Microsoft Entra 애플리케이션 프록시는 코드 변경 없이 기존 레거시 애플리케이션에 Microsoft Entra 제로 트러스트 기능을 제공합니다.

공유 서비스 공급자 또는 외부 기관이 기본 테넌트를 제어하는 경우 애플리케이션 등록 권한을 위임해야 합니다. 서비스 공급자가 이 위임을 제공하지 않는 경우 조직에서 제어하는 보조 테넌트에 애플리케이션을 등록해야 합니다. 그러나 사용자는 보조 테넌트에서 새 ID를 만들지 않고도 이러한 애플리케이션에 계속 액세스해야 합니다. 이 설정의 경우 기본 테넌트에서 사용자에 대해 외부 ID(B2B 게스트)를 사용하여 사용자 액세스를 할당합니다. 자세한 내용은 신뢰가 없는 보안 애플리케이션을 참조하세요.

Microsoft Entra ID를 사용하여 다른 클라우드 환경을 관리합니다. Microsoft Entra ID는 Azure 및 Microsoft 365용 ID 플랫폼이 아닙니다. Microsoft Entra ID를 사용하여 다른 클라우드 환경에 액세스할 수 있습니다. 이러한 환경에는 인기 있는 SaaS(Software-as-a-Service) 제품 및 AWS(Amazon Web Services) 및 GCP(Google Cloud Platform)와 같은 클라우드 플랫폼이 포함됩니다. 자세한 내용은 Microsoft Entra 애플리케이션 갤러리를 참조하세요.

SCCA(보안 클라우드 컴퓨팅 아키텍처)를 사용합니다. 각 방어 조직은 SCCA 규격 랜딩 존 아키텍처를 배포해야 합니다. 랜딩 존은 기본 테넌트에 연결된 Azure 구독에 있어야 합니다.

단일 테넌트에서 Azure 리소스 관리를 분할합니다. 엔터프라이즈 규모 Azure 랜딩 존 내의 구독에 대한 리소스 및 관리 격리에 Azure 역할을 사용해야 합니다. 보조 테넌트에서 기본 테넌트로 구독을 전송하는 것이 좋습니다.

Microsoft Entra 사용 권한 관리 사용합니다. Microsoft Entra 사용 권한 관리 Microsoft의 CIEM(클라우드 인프라 권한 관리) 솔루션입니다. 모든 ID에 할당된 권한에 대한 가시성을 위해 Microsoft Entra 사용 권한 관리 사용해야 합니다. 또한 이를 사용하여 조직의 다중 클라우드 환경에서 권한 크리프(creep)를 추적해야 합니다.

Microsoft Entra ID 거버넌스를 사용합니다. Microsoft Entra ID 거버넌스를 사용하여 사용자 및 게스트에 대한 액세스 할당 수명 주기를 자동화합니다. 액세스 검토를 수행하여 더 이상 필요하지 않은 사용자의 클라우드 환경에 대한 액세스를 제거합니다.

워크로드 ID를 보호합니다. Microsoft Entra 워크로드 ID 기능을 사용하여 Microsoft Entra ID의 애플리케이션 ID(서비스 주체)에 대한 적응 제로 트러스트 정책을 관리하고 적용합니다.

엔터프라이즈에 클라우드용 Defender 사용하도록 설정합니다. 다중 클라우드 환경에 클라우드용 Defender 사용합니다. Azure 리소스를 모니터링하고 구성 위험을 수정하기 위해 향상된 보안 기능을 켜야 합니다. 클라우드용 Defender 보호는 하이브리드 및 다중 클라우드 환경을 보호하는 데 도움이 되도록 Azure를 넘어 확장됩니다.

Sentinel을 배포하고 사용 가능한 모든 데이터 원본을 연결합니다. Microsoft Sentinel과 같은 SIEM에서 보안 신호를 집계합니다. Sentinel을 배포하고 데이터 커넥터를 구성 하여 모든 보안 신호 데이터 원본을 연결합니다.

기본 테넌트

기본 테넌트에서만 다음 권장 사항을 구현해야 합니다.

최종 사용자에게는 Entra ID에 ID가 하나만 있습니다. 온-프레미스 Active Directory Domain Services를 기본 Microsoft Entra 테넌트와 동기화합니다. 동기화는 Microsoft Entra ID를 조직의 사용자, 그룹 및 디바이스로 채웁니다. 외부 B2B 게스트는 보조 테넌트에 있을 수 있지만 사용자는 모든 애플리케이션 및 서비스에 대해 하나의 사용자 이름만 기억하면 됩니다. Windows 로그인 및 애플리케이션 액세스를 위해 기본 테넌트에서 ID를 사용하는 경우 사용자 환경 및 제로 트러스트 결과가 가장 좋습니다.

기본 테넌트와 디바이스를 조인하고 관리합니다. 기본 Microsoft Entra 테넌트에는 조직 내의 모든 사용자 및 디바이스가 포함됩니다. Microsoft Entra는 Windows 디바이스를 기본 테넌트에 조인(또는 Microsoft Entra 하이브리드 조인)하고 Microsoft Intune을 사용하여 관리합니다. Intune 정책을 사용하여 확장 검색 및 응답(XDR) 기능을 사용하도록 설정하는 엔드포인트용 Microsoft Defender 배포합니다.

애플리케이션 등록 권한을 위임합니다. 모든 Azure 구독에서 실행되는 애플리케이션 코드를 비롯한 Enterprise Apps는 사용자 ID에 기본 Microsoft Entra ID 테넌트 사용을 사용합니다. Privileged Identity Management를 사용하여 개발자가 애플리케이션 개발자 Microsoft Entra 역할 또는 사용자 지정 앱 등록 역할에 적합하게 만듭니다. 이 구성을 사용하면 보조 테넌트에서 애플리케이션을 빌드하는 개발자가 ID에 대한 기본 테넌트에 등록할 수 있습니다.

최종 사용자 ID가 필요한 PaaS(Platform-as-a-Service) 서비스를 연결합니다. Azure Files 및 Azure Virtual Desktop과 같은 일부 PaaS 서비스는 하이브리드 ID 구성 또는 라이선스 자격에 따라 달라집니다. 기본 테넌트에서 Azure 구독에 이러한 서비스를 배포해야 합니다.

보조 테넌트

보조 테넌트에서 다음 권장 사항을 구현해야 합니다.

Microsoft Entra 관리에 필요한 라이선스를 조달합니다. 보조 테넌트에서 고급 보안 기능을 켜려면 라이선스가 필요합니다. 사용자, 워크로드 및 디바이스에 필요한 라이선스를 고려합니다.

사용자 ID. 테넌트 관리자 및 응급 액세스 계정에 대한 Microsoft Entra ID Premium P2 라이선스가 있어야 합니다. 외부 ID(B2B 게스트) 관리 모델을 사용하는 경우 테넌트에서 로컬 사용자에게 Microsoft Entra ID Premium P2 라이선스를 하나 이상 할당해야 합니다. 이 설정을 사용하면 조건부 액세스 및 ID 보호와 같은 프리미엄 기능을 사용하도록 설정할 수 있습니다. 자세한 내용은 다중 테넌트 사용자 관리에 대한 일반적인 고려 사항을 참조하세요.

워크로드 ID. 워크로드 ID 프리미엄을 사용하여 MS Graph API와 같은 기본 테넌트에서 리소스에 액세스할 수 있는 워크로드 ID를 보호해야 합니다.

장치 관리. 보조 테넌트에서 Microsoft Intune을 사용하여 디바이스를 관리해야 할 수도 있습니다. 그렇다면 EMS(Enterprise Mobility and Security) 라이선스를 조달해야 합니다.

XTAP(테넌트 간 액세스 정책)를 구성합니다. Microsoft Entra 외부 ID(Microsoft Entra B2B 협업) 테넌트 간 액세스 설정을 사용하면 보조 테넌트가 홈 주 테넌트에서 특정 클레임을 신뢰할 수 있습니다. 기본 Microsoft Entra 테넌트를 조직으로 추가하고 다음을 포함하도록 인바운드 트러스트 설정을 업데이트합니다.

• Microsoft Entra 테넌트에서 MFA(다단계 인증) 신뢰
• 호환 장치 신뢰
• Microsoft Entra 하이브리드 조인 디바이스 신뢰
• 선택 사항: 테넌트에 초대를 자동으로 사용

주 테넌트에서 ID를 사용하여 보조 테넌트 관리 주 테넌트에서 외부 사용자(B2B 게스트)를 사용하여 보조 테넌트 및 Azure 리소스를 관리하여 관리 오버헤드 및 비용을 줄입니다. Microsoft Entra Privileged Identity Management를 사용하여 작업별로 최소 권한 Microsoft Entra 역할에 따라 Microsoft Entra 역할을 할당합니다. 최종 사용자가 시작한 액세스 또는 테넌트 간 동기화를 사용하여 보조 테넌트에서 외부 ID를 온보딩하는 관리 오버헤드를 줄입니다.

Azure Lighthouse를 사용하여 기본 테넌트에서 Sentinel 액세스를 용이하게 합니다. Azure Lighthouse 는 테넌트 전체에서 Azure를 관리하는 또 다른 방법을 제공합니다. Azure Lighthouse는 ARM(Azure Resource Manager) 템플릿을 사용하여 외부 테넌트에서 ID에 Azure 역할을 할당합니다. 이 방법은 B2B 게스트 사용자 개체를 사용하지 않습니다. 관리자가 Azure를 관리하기 위해 포털에 로그인하면 모든 테넌트에서 모든 리소스가 표시됩니다. 이 통합 보기에는 Azure Lighthouse에서 할당한 권한이 있는 구독이 포함됩니다. B2B 게스트 개체가 없으므로 관리자는 디렉터리를 전환할 필요가 없습니다. Azure Lighthouse를 사용하여 테넌트 전체에서 Microsoft Sentinel을 쉽게 관리할 수 있습니다.

다음 단계

관련 링크

• ID 필수 요소
• 제로 트러스트 구성
• 중앙 집중식 보안 작업