모든 격리 아키텍처에 대한 모범 사례

다음은 모든 격리 구성의 디자인 고려 사항입니다. 이 콘텐츠에는 많은 링크가 포함되어 있습니다. 콘텐츠를 여기서 복제하는 대신 링크를 제공하므로, 언제든지 최신 정보에 액세스할 수 있습니다.

Microsoft Entra (격리된 또는 격리되지 않은) 테넌트를 구성하는 방법에 대한 일반적인 지침은 Microsoft Entra 기능 배포 가이드를 참조하세요.

격리 보안 원칙

격리된 환경을 설계할 때는 다음 원칙을 고려해야 합니다.

• 최신 인증만 사용 - 격리된 환경에 배포된 애플리케이션은 페더레이션, Microsoft Entra B2B 협업, 위임, 동의 프레임워크 등의 기능을 사용할 수 있도록 클레임 기반 최신 인증(예: SAML, * Auth, OAuth2 및 OpenID Connect)을 사용해야 합니다. 이렇게 하면 NTLM(NT LAN Manager)과 같은 레거시 인증 방법에 종속된 레거시 애플리케이션은 더 이상 격리된 환경에서 진행되지 않습니다.

• 강력한 인증 적용 - 격리된 환경 서비스 및 인프라에 액세스할 때 항상 강력한 인증을 사용해야 합니다. 가급적이면 비즈니스용 Windows Hello 또는 FIDO2 보안 키 같은 암호 없는 인증을 사용해야 합니다.

• 보안 워크스테이션 배포 - 보안 워크스테이션은 플랫폼과 플랫폼이 나타내는 ID를 제대로 증명하고 악용되지 않도록 보호하는 메커니즘을 제공합니다. 고려해야 할 다른 두 가지 방법이 더 있습니다.

  • Microsoft Graph API와 함께 Windows 365 클라우드 PC(클라우드 PC)를 사용합니다.

  • 조건부 액세스를 사용하고 디바이스를 조건으로 필터링합니다.

• 레거시 트러스트 메커니즘 제거 - 격리된 디렉터리 및 서비스는 Active Directory 트러스트와 같은 레거시 메커니즘을 통해 다른 환경과 트러스트 관계를 설정하면 안 됩니다. 환경 간의 모든 트러스트는 페더레이션 및 클레임 기반 ID와 같은 최신 구문을 사용하여 설정해야 합니다.

• 서비스 격리 - 기본 ID 및 서비스 인프라를 노출로부터 보호하여 노출 영역을 최소화합니다. 서비스에 대한 최신 인증과 인프라에 대한 보안 원격 액세스(최신 인증으로도 보호됨)를 통해서만 액세스할 수 있도록 설정합니다.

• 디렉터리 수준 역할 할당 - 디렉터리 수준 역할 할당(AU 범위 지정 대신 디렉터리 범위의 사용자 관리자) 또는 컨트롤 플레인 작업이 있는 서비스별 디렉터리 역할(보안 그룹 멤버 자격을 관리할 수 있는 권한이 있는 지식 관리)을 피하거나 줄입니다.

Microsoft Entra 일반 작업 가이드의 지침 외에도 격리된 환경에 대한 다음 사항을 고려하는 것이 좋습니다.

휴먼 ID 프로비저닝

권한 있는 계정

환경을 운영하는 관리 담당자 및 IT 팀을 위해 격리된 환경에서 계정을 프로비전합니다. 이렇게 하면 보안 워크스테이션에 대한 디바이스 기반 액세스 제어와 같은 보다 강력한 보안 정책을 추가할 수 있습니다. 이전 섹션에서 설명한 것처럼, 비프로덕션 환경은 잠재적으로 Microsoft Entra B2B 협업을 통해 프로덕션 환경에서 권한 있는 액세스를 위해 설계된 것과 동일한 태세 및 보안 제어를 사용하여 비프로덕션 테넌트에 권한 있는 계정을 온보딩할 수 있습니다.

클라우드 전용 계정은 Microsoft Entra 테넌트에서 사람 ID를 프로비전하는 가장 간단한 방법이며 녹색 필드 환경에 적합합니다. 그러나 격리된 환경(예: 사전 프로덕션 또는 관리형 Active Directory 포리스트)에 해당하는 기존 온-프레미스 인프라가 있는 경우에는 해당 인프라에서 ID 동기화를 고려할 수 있습니다. 여기에서 설명한 온-프레미스 인프라가 솔루션 데이터 평면을 관리하기 위해 서버에 액세스해야 하는 IaaS 솔루션에도 사용되는 경우에 특히 그렇습니다. 이 시나리오에 대한 자세한 내용은 온-프레미스 공격으로부터 Microsoft 365 보호를 참조하세요. 스마트 카드 전용 인증과 같은 규정 준수 요구 사항이 있는 경우 격리된 온-프레미스 환경에서 동기화해야 할 수도 있습니다.

위험 수준이 높은 역할 아웃소싱

Azure B2B 협업을 사용하거나 CSP 파트너 또는 Lighthouse를 통해 액세스를 위임하여 전역 관리자 및 권한 있는 역할 관리자 역할에 대한 액세스를 관리형 서비스 공급자에게 아웃소싱하는 방법으로 내부 위협을 완화할 수 있습니다. 이 액세스는 Azure PIM(Privileged Identity Management)의 승인 흐름을 통해 사내 직원이 제어할 수 있습니다. 이 접근 방식은 내부 위협을 크게 줄일 수 있습니다. 우려가 있는 고객의 규정 준수 요구를 충족하는 데 사용할 수 있는 방법입니다.

사람이 아닌 ID 프로비전

응급 액세스 계정

Microsoft에서는 조직에 전역 관리자 역할이 영구적으로 할당된 두 개의 클라우드 전용 긴급 액세스 계정을 보유하는 것이 좋습니다. 이러한 계정은 높은 권한을 부여받으며 특정 개인에게 할당되지 않습니다. 계정은 일반 계정을 사용할 수 없거나 다른 모든 관리자가 실수로 잠긴 긴급 또는 “비상” 시나리오로 제한됩니다. 이러한 계정은 긴급 액세스 계정 권장 사항에 따라 만들어져야 합니다.

Azure 관리 ID

서비스 ID가 필요한 Azure 리소스에 대한 관리 ID를 사용합니다. Azure 솔루션을 디자인할 때 관리 ID를 지원하는 서비스 목록을 확인합니다.

관리 ID가 지원되지 않거나 가능하지 않은 경우 서비스 주체 개체를 프로비저닝하는 것이 좋습니다.

하이브리드 서비스 계정

온-프레미스 리소스와 클라우드 리소스에 모두 액세스해야 하는 하이브리드 솔루션이 있습니다. 사용 사례의 예로는 온-프레미스 도메인 가입 서버에 액세스하기 위해 AD DS의 서비스 계정을 사용하고 Microsoft 온라인 서비스에 액세스해야 하므로 Microsoft Entra ID에 계정도 있는 애플리케이션을 들 수 있습니다.

온-프레미스 서비스 계정은 일반적으로 대화형으로 로그인할 수 없습니다. 즉, 클라우드 시나리오에서는 다단계 인증과 같은 강력한 자격 증명 요구 사항을 충족할 수 없습니다. 이 시나리오에서는 온-프레미스에서 동기화되는 서비스 계정을 사용하지 말고, 관리 ID/서비스 주체를 대신 사용합니다. SP(서비스 주체)의 경우 인증서를 자격 증명으로 사용하거나 조건부 액세스로 SP를 보호합니다.

이렇게 할 수 없는 기술 제약 조건이 있고 온-프레미스와 클라우드 모두에 동일한 계정을 사용해야 하는 경우 조건부 액세스와 같은 보정 컨트롤을 구현하여 특정 네트워크 위치에서 제공되는 하이브리드 계정을 잠급니다.

리소스 할당

엔터프라이즈 솔루션은 여러 Azure 리소스로 구성될 수 있으며, 해당 액세스는 할당의 논리적 단위인 리소스 그룹으로 관리 및 제어되어야 합니다. 이 시나리오에서는 Microsoft Entra 보안 그룹을 만들고 모든 솔루션 리소스에서 적절한 권한 및 역할 할당과 연결할 수 있으며, 이러한 그룹에서 사용자를 추가하거나 제거하면 전체 솔루션에 대한 액세스가 허용 또는 거부됩니다.

액세스를 제공하기 전에 라이선스 시트 할당을 전제 조건으로 사용자에 의한 Microsoft 서비스(예: Dynamics 365, Power BI)에는 그룹 기반 라이선싱 및 보안 그룹을 사용하는 것이 좋습니다.

Microsoft Entra 클라우드 네이티브 그룹은 Microsoft Entra 액세스 검토 및 Microsoft Entra 권한 관리와 결합될 때 기본적으로 클라우드에서 제어할 수 있습니다.

또한 Microsoft Entra ID는 타사 SaaS 서비스(예: Salesforce, Service Now) 및 온-프레미스 애플리케이션에 사용자를 직접 할당하여 Single Sign-On 및 ID 프로비전을 수행할 수 있습니다. 리소스에 대한 직접 할당은 Microsoft Entra 액세스 검토 및 Microsoft Entra 권한 관리와 결합될 때 기본적으로 클라우드에서 제어할 수 있습니다. 직접 할당은 최종 사용자 쪽 할당에 적합할 수 있습니다.

일부 시나리오에서는 온-프레미스 Active Directory 보안 그룹을 통해 온-프레미스 리소스에 대한 액세스 권한을 부여해야 할 수도 있습니다. 이러한 경우 프로세스 SLA를 디자인할 때 Microsoft Entra ID로의 동기화 주기를 고려해야 합니다.

인증 관리

이 섹션에서는 조직의 보안 태세에 따라 자격 증명 관리 및 액세스 정책에 대해 수행할 검사와 취할 조치에 대해 설명합니다.

자격 증명 관리

강력한 자격 증명

격리된 환경의 모든 휴먼 ID(로컬 계정 및 B2B 협업을 통해 프로비전된 외부 ID)는 다단계 인증 또는 FIDO 키와 같은 강력한 인증 자격 증명을 통해 프로비저닝되어야 합니다. 스마트 카드 인증과 같은 강력한 인증을 사용하는 기본 온-프레미스 인프라가 있는 환경은 클라우드에서 스마트 카드 인증을 계속 사용할 수 있습니다.

암호 없는 자격 증명

암호 없는 솔루션은 가장 편리하고 안전한 인증 방법을 보장하는 최상의 솔루션입니다. FIDO 보안 키 및 비즈니스용 Windows Hello 같은 암호 없는 자격 증명은 권한 있는 역할이 부여된 사용자 ID에 사용하는 것이 좋습니다.

암호 보호

환경이 온-프레미스 Active Directory 포리스트에서 동기화되는 경우 Microsoft Entra 암호 보호를 배포하여 조직에서 취약한 암호를 제거해야 합니다. Microsoft Entra 스마트 잠금을 하이브리드 또는 클라우드 전용 환경에도 사용하여 사용자의 암호를 추측하거나 무차별 암호 대입 방법을 사용하여 로그인하려는 악의적인 행위자를 차단해야 합니다.

셀프 서비스 암호 관리

암호를 변경하거나 재설정해야 하는 사용자가 지원 센터 통화량과 비용의 가장 큰 원인 중 하나입니다. 비용 외에도 사용자 위험을 완화하기 위한 도구로서 암호를 변경하는 것은 조직의 보안 태세를 개선하는 기본적인 단계입니다. 적어도 암호를 사용하는 사용자 및 테스트 계정에 대한 셀프 서비스 암호 관리를 배포하여 지원 센터 호출을 줄여야 합니다.

외부 ID 암호

Microsoft Entra B2B 협업을 사용하면 초대 및 상환 프로세스를 통해 파트너, 개발자 및 하도급업체와 같은 외부 사용자가 자신의 자격 증명을 사용하여 회사의 리소스에 액세스할 수 있습니다. 이렇게 하면 격리된 테넌트에 더 많은 암호를 도입할 필요가 없습니다.

서비스 주체 자격 증명

서비스 주체가 필요한 시나리오의 경우 서비스 주체에 대한 인증서 자격 증명 또는 워크로드 ID에 대한 조건부 액세스를 사용합니다. 필요한 경우 조직 정책의 예외로 클라이언트 암호를 사용합니다.

두 경우 모두 Azure 관리 ID와 함께 Azure Key Vault를 사용하여 런타임 환경(예: Azure 함수)이 키 자격 증명 모음에서 자격 증명을 검색할 수 있습니다.

인증서 자격 증명을 사용하여 서비스 주체를 인증하려면 자체 서명된 인증서를 사용하는 서비스 주체 만들기 예제를 확인하세요.

액세스 정책

다음 섹션에서는 Azure 솔루션에 대한 권장 사항에 대해 설명합니다. 개별 환경의 조건부 액세스 정책에 대한 일반적인 지침은 조건부 액세스 모범 사례, Microsoft Entra 운영 가이드 및 제로 트러스트에 대한 조건부 액세스를 확인하세요.

• Windows Azure 서비스 관리 API 클라우드 앱에 대한 조건부 액세스 정책을 정의하여 Azure Resource Manager에 액세스할 때 ID 보안 태세를 적용합니다. 여기에는 보안 워크스테이션을 통해서만 액세스할 수 있도록 MFA에 대한 컨트롤과 디바이스 기반 컨트롤이 포함되어야 합니다(자세한 내용은 ID 거버넌스의 권한 있는 역할 섹션에서 설명). 또한 조건부 액세스를 사용하여 디바이스를 필터링합니다.

• 격리된 환경에 온보딩된 모든 애플리케이션에는 온보딩 프로세스의 일부로 명시적 조건부 액세스 정책이 적용되어야 합니다.

• 온-프레미스의 안전한 신뢰 프로세스 루트를 반영하는 보안 정보 등록에 대한 조건부 액세스 정책을 정의합니다(예: IP 주소로 식별 가능하며 직원이 직접 방문하여 확인해야 하는 물리적 위치의 워크스테이션).

• 조건부 액세스를 사용하여 워크로드 ID를 제한하는 것이 좋습니다. 위치 또는 기타 관련 환경에 따라 액세스를 제한하거나 보다 효율적으로 제어하는 정책을 만듭니다.

인증 과제

• Microsoft Entra B2B를 통해 프로비전된 외부 ID는 리소스 테넌트에서 다단계 인증 자격 증명을 다시 프로비전해야 할 수도 있습니다. 이 작업은 리소스 테넌트에서 테넌트 간 액세스 정책이 설정되지 않은 경우에 필요할 수 있습니다. 즉, 시스템 온보딩은 단일 요소로 부트스트랩됩니다. 이 방법을 사용하면 조직에서 B2B 초대를 발급하기 전에 사용자 및 자격 증명 위험 프로필을 증명하는 프로세스를 갖추게 되므로 위험이 완화됩니다. 또한 앞에서 설명한 대로 등록 프로세스에 대한 조건부 액세스를 정의합니다.

• 외부 ID 테넌트 간 액세스 설정을 사용하여 B2B 협업 및 B2B 직접 연결을 통해 다른 Microsoft Entra 조직 및 기타 Microsoft Azure 클라우드와 협업하는 방법을 관리합니다.

• 특정 디바이스 구성 및 제어의 경우 조건부 액세스 정책에서 디바이스 필터를 사용하여 특정 디바이스를 대상으로 지정하거나 제외할 수 있습니다. 이렇게 하면 지정된 SAW(보안 관리자 워크스테이션)에서 이루어지는 Azure 관리 도구 액세스를 제한할 수 있습니다. Azure 가상 데스크톱, Azure Bastion 또는 클라우드 PC를 사용하는 방법도 있습니다.

• Azure EA Portal 또는 MCA 청구 계정과 같은 청구 관리 애플리케이션은 조건부 액세스 대상 지정을 위한 클라우드 애플리케이션으로 표시되지 않습니다. 보상 제어로써 별도의 관리 계정을 정의하고 "모든 앱" 조건을 사용하여 해당 계정에 대한 조건부 액세스 정책을 대상으로 지정합니다.

ID 거버넌스

권한 있는 역할

다음은 격리에 대한 모든 테넌트 구성에서 고려해야 하는 ID 거버넌스 원칙입니다.

• 고정 액세스 권한 없음 - 그 어떤 휴먼 ID도 격리된 환경에서 권한 있는 작업을 수행할 수 있는 고정 액세스 권한이 없어야 합니다. Azure RBAC(역할 기반 액세스 제어)는 Microsoft Entra PIM(Privileged Identity Management)과 통합됩니다. PIM은 다단계 인증, 승인 워크플로 및 제한된 기간과 같은 보안 게이트에 의해 결정되는 Just-In-Time 활성화를 제공합니다.

• 관리자 수 - 조직은 비즈니스 연속성 위험을 완화하기 위해 권한 있는 역할을 보유하는 최소 및 최대 사용자 수를 정의해야 합니다. 권한이 있는 역할이 너무 적으면 표준 시간대 적용 범위가 충분하지 않을 수 있습니다. 최소 권한 원칙에 따라 관리자 수를 최소화하여 보안 위험을 완화해야 합니다.

• 권한 있는 액세스 제한 - 높은 권한 또는 중요한 권한에 대한 클라우드 전용 및 역할 할당 가능 그룹을 만듭니다. 이렇게 하면 할당된 사용자 및 그룹 개체를 보호할 수 있습니다.

• 최소 권한 액세스 - ID에는 조직 내 역할에 따라 권한 있는 작업을 수행하는 데 필요한 권한만 부여해야 합니다.

  • Azure RBAC 사용자 지정 역할을 사용하면 조직의 요구에 따라 최소 권한 역할을 디자인할 수 있습니다. 특수 보안 팀에서 사용자 지정 역할 정의를 작성 또는 검토하여 의도하지 않은 과도한 권한 위험을 완화하는 것이 좋습니다. 사용자 지정 역할 작성은 Azure Policy를 통해 감사할 수 있습니다.

  • 조직 내에서 광범위하게 사용할 목적으로 작성되지 않은 역할이 뜻하지 않게 사용되는 위험을 완화하려면 Azure Policy를 사용하여 액세스를 할당하는 데 사용할 수 있는 역할 정의를 명시적으로 정의해야 합니다. 이 GitHub 샘플에서 자세히 알아보세요.

• 보안 워크스테이션에서 권한 있는 액세스 - 모든 권한 있는 액세스는 안전하고 잠긴 디바이스에서 발생해야 합니다. 이러한 중요한 작업과 계정을 매일 사용하는 워크스테이션 및 디바이스에서 분리하면 피싱 공격, 애플리케이션 및 OS 취약성, 다양한 가장 공격 및 자격 증명 도난 공격(예: 키 입력 로깅, Pass-the-Hash 및 Pass-The-Ticket)으로부터 권한 있는 계정을 보호할 수 있습니다.

권한 있는 액세스 스토리의 일부로 보안 디바이스 사용 시나리오에 사용할 수 있는 방법으로는 조건부 액세스 정책을 사용하여 특정 디바이스를 대상으로 하거나 제외하는 방법, Azure 가상 데스크톱, Azure Bastion 또는 Cloud PC를 사용하는 방법, Azure 관리형 워크스테이션 또는 권한 있는 액세스 워크스테이션을 만드는 방법이 있습니다.

• 권한 있는 역할 프로세스 가드레일 - 조직은 규정 요구 사항을 준수하면서 필요할 때마다 권한 있는 작업을 실행할 수 있도록 프로세스 및 기술 보호책을 정의해야 합니다. 다음은 보호책 조건의 예입니다.

  • 권한 있는 역할이 있는 사람의 자격(예: 상근 직원/공급업체, 허가 수준, 시민권)

  • 역할의 명시적 비호환성(의무 분리라고도 함) 예를 들어 Microsoft Entra 디렉터리 역할이 있는 팀은 Azure Resource Manager 권한 있는 역할 등을 관리할 책임이 없어야 합니다.

  • 직접 사용자 또는 그룹 할당이 선호되는 역할

• Microsoft Entra PIM 외부의 IAM 할당을 모니터링하는 것은 Azure 정책을 통해 자동화되지 않습니다. 완화 방법은 엔지니어링 팀에 구독 소유자 또는 사용자 액세스 관리자 역할을 부여하지 않는 것입니다. 대신 기여자와 같은 최소 권한 역할에 할당된 그룹을 만들고 해당 그룹의 관리를 엔지니어링 팀에 위임합니다.

리소스 액세스

• 증명 - 권한 있는 역할을 보유한 ID를 정기적으로 검토하여 멤버 자격을 최신 상태로 유지하고 정당화해야 합니다. Microsoft Entra 액세스 검토는 Azure RBAC 역할, 그룹 멤버 자격 및 Microsoft Entra B2B 외부 ID와 통합됩니다.

• 수명 주기 - 권한 있는 작업을 수행하려면 기간 업무 애플리케이션, SaaS 애플리케이션, Azure 리소스 그룹 및 구독과 같은 여러 리소스에 액세스해야 할 수도 있습니다. Microsoft Entra 권한 관리를 사용하면 사용자에게 단위로 할당된 리소스 세트를 나타내는 액세스 패키지를 정의하고 유효 기간, 승인 워크플로 등을 설정할 수 있습니다.

테넌트 및 구독 수명 주기 관리

테넌트 수명 주기

• 새 회사 Microsoft Entra 테넌트를 요청하는 프로세스를 구현하는 것이 좋습니다. 프로세스에서 다음을 고려해야 합니다.

  • 테넌트를 만들어야 하는 비즈니스 근거. 새 Microsoft Entra 테넌트를 만들면 복잡성이 크게 증가하므로 새 테넌트가 필요한지 확인하는 것이 중요합니다.

  • 테넌트를 만들어야 하는 Azure 클라우드(예: 상업용, 정부 등)입니다.

  • 프로덕션인지 아니면 비프로덕션인지 여부

  • 디렉터리 데이터 상주 요구 사항

  • 관리 대상

  • 일반적인 보안 요구 사항의 학습과 이해

• 승인되면 Microsoft Entra 테넌트가 생성되고, 필요한 기준 컨트롤로 구성되고, 청구 플레인, 모니터링 등에 온보딩됩니다.

• 관리되는 프로세스 외부에서 테넌트가 만들어지는 것을 탐지하고 발견하려면 청구 플레인에서 Microsoft Entra 테넌트의 정기적인 검토를 구현해야 합니다. 자세한 내용은 이 문서의 인벤토리 및 표시 유형 섹션을 참조하세요.

• Azure AD B2C 테넌트 만들기는 Azure Policy를 사용하여 제어할 수 있습니다. Azure 구독이 B2C 테넌트에 연결될 때(청구를 위한 필수 구성 요소) 정책이 실행됩니다. 고객은 Azure AD B2C 테넌트 만들기를 특정 관리 그룹으로 제한할 수 있습니다.

• 조직에 테넌트를 꼭 만들어야 하는 기술 컨트롤은 없습니다. 그러나 활동은 감사 로그에 기록됩니다. 청구 플레인에 온보딩하는 것은 게이트의 보정 컨트롤입니다. 대신 모니터링 및 경고로 보완해야 합니다.

구독 수명 주기

다음은 관리되는 구독 수명 주기 프로세스를 설계할 때 고려해야 할 몇 가지 사항입니다.

• Azure 리소스가 필요한 애플리케이션 및 솔루션의 분류를 정의합니다. 구독을 요청하는 모든 팀은 구독을 요청할 때 "제품 식별자"를 제공해야 합니다. 이 정보 분류는 다음을 결정합니다.

  • 구독을 프로비전할 Microsoft Entra 테넌트

  • 구독 만들기에 사용할 Azure EA 계정

  • 명명 규칙

  • 관리 그룹 할당

  • 태그 지정, 교차 청구, 제품 보기 사용 등과 같은 기타 측면입니다.

• 포털 또는 다른 수단을 통한 임시 구독 만들기를 허용하지 마세요. 대신 Azure Resource Manager를 사용하여 프로그래밍 방식으로 구독을 관리하고 프로그래밍 방식으로 사용 및 청구 보고서를 끌어들이는 것이 좋습니다. 이렇게 하면 구독 프로비저닝을 권한 있는 사용자로 제한하고 정책 및 분류 목표를 적용하는 데 도움이 될 수 있습니다. 다음 AZOps 보안 주체에 대한 지침을 사용하여 실용적인 솔루션을 만들 수 있습니다.

• 구독이 프로비전되면 Microsoft Entra 클라우드 그룹을 만들어 기여자, 읽기 권한자 및 승인된 사용자 지정 역할과 같은 애플리케이션 팀에서 필요한 표준 Azure Resource Manager 역할을 보유합니다. 이렇게 하면 제어된 권한 있는 액세스를 대규모로 사용하여 Azure RBAC 역할 할당을 관리할 수 있습니다.

  1. 활성화 정책, 액세스 검토, 승인자 등과 같은 해당 컨트롤이 있는 Microsoft Entra PIM을 사용하여 Azure RBAC 역할에 적합하도록 그룹을 구성합니다.

  2. 그런 다음, 솔루션 소유자에게 그룹 관리를 위임합니다.

  3. 보호책으로써, Microsoft Entra PIM 외부의 역할을 실수로 직접 할당하거나 구독을 다른 테넌트로 완전히 변경하는 일이 없도록 제품 소유자를 사용자 액세스 관리자 또는 소유자 역할에 할당하지 마세요.

  4. Azure Lighthouse를 통해 비프로덕션 테넌트에서 테넌트 간 구독 관리를 사용하도록 선택하는 고객의 경우 구독 관리를 인증할 때 프로덕션 권한 계정(예: 보안 워크스테이션의 권한 있는 액세스만)의 동일한 액세스 정책이 적용되도록 해야 합니다.

• 조직에 사전 승인된 참조 아키텍처가 있는 경우 구독 프로비저닝을 Azure Blueprints 또는 Terraform과 같은 리소스 배포 도구와 통합할 수 있습니다.

• Azure 구독에 대한 테넌트 선호도를 고려할 때 구독 프로비전은 여러 테넌트에서 동일한 사람 작업자(직원, 파트너, 공급업체 등)의 여러 ID를 인식하고 그에 따라 액세스 권한을 할당해야 합니다.

EA 및 MCA 역할

• Azure Enterprise(Azure EA) 계약 포털은 Azure RBAC 또는 조건부 액세스와 통합되지 않습니다. 이에 대한 완화 방법은 정책 및 추가 모니터링을 통해 대상으로 지정할 수 있는 전용 관리 계정을 사용하는 것입니다.

• Azure EA Enterprise 포털은 감사 로그를 제공하지 않습니다. 이를 완화하려면 위에서 설명한 고려 사항에 따라 구독을 프로비저닝하고 전용 EA 계정을 사용하여 인증 로그를 감사하는 자동화된 관리 프로세스를 고려합니다.

• MCA(Microsoft 고객 계약) 역할은 기본적으로 PIM과 통합되지 않습니다. 완화 방법은 전용 MCA 계정을 사용하고 이러한 계정 사용을 모니터링하는 것입니다.

Azure AD B2C 테넌트

• Azure AD B2C 테넌트에서 기본 제공 역할은 PIM을 지원하지 않습니다. 보안을 강화하려면 Microsoft Entra B2B 협업을 사용하여 Azure 테넌트에서 CIAM(고객 ID 액세스 관리)을 관리하는 엔지니어링 팀을 온보딩하고 Azure AD B2C 권한 있는 역할에 할당하고 이러한 전용 관리 계정에 조건부 액세스 정책을 적용하는 것이 좋습니다.

• Azure AD B2C 테넌트의 권한 있는 역할은 Microsoft Entra 액세스 검토와 통합되지 않습니다. 완화 방법은 조직의 Microsoft Entra 테넌트에 전용 계정을 만들고, 이러한 계정을 그룹에 추가하고, 이 그룹에 대한 정기적인 액세스 검토를 수행하는 것입니다.

• 위의 Microsoft Entra에 대한 긴급 액세스 지침을 따른 후에는 위에서 설명한 외부 관리자 외에 동등한 응급 액세스 계정을 만드는 것이 좋습니다.

• 나머지 Azure 구독이 B2C 솔루션에 사용되는 것과 동일한 방식으로 B2C 테넌트 기본 Microsoft Entra 구독의 논리적 소유권이 CIAM 엔지니어링 팀과 일치하는 것이 좋습니다.

작업

다음은 여러 격리된 환경과 관련된 Microsoft Entra의 추가 운영 고려 사항입니다. 개별 환경을 운영하기 위한 자세한 지침은 Azure 클라우드 채택 프레임워크, Microsoft 클라우드 보안 벤치마크 및 Microsoft Entra 운영 가이드를 참조하세요.

환경 간 역할 및 책임

엔터프라이즈 수준 SecOps 아키텍처 - 조직 내 모든 환경의 운영 및 보안 팀 구성원이 공동으로 다음을 정의해야 합니다.

• 환경을 만들거나 통합하거나 사용 중단해야 하는 시기를 정의하는 원칙

• 각 환경에서 관리 그룹 계층 구조를 정의하는 원칙

• 청구 플레인(EA 포털/MCA) 보안 태세, 운영 태세 및 위임 접근 방식

• 테넌트 만들기 프로세스

• 엔터프라이즈 애플리케이션 분류

• Azure 구독 프로비저닝 프로세스

• 모든 팀과 환경의 격리 및 관리 자치권 경계와 위험 평가

• 모든 환경에서 사용할 일반적인 기준 구성 및 보안 컨트롤(기술 및 보상)과 운영 기준

• 여러 환경(예: 모니터링, 프로비저닝)에 걸쳐 있는 일반적인 표준 운영 절차 및 도구

• 여러 환경에서 역할 위임에 동의

• 모든 환경에서 의무 분리.

• 권한 있는 워크스테이션의 일반적인 공급망 관리.

• 명명 규칙.

• 환경 간 상관 관계 메커니즘

테넌트 만들기 - 특정 팀은 엔터프라이즈 수준 SecOps 아키텍처에 정의된 표준화된 절차에 따라 테넌트 만들기를 소유해야 합니다. 다음 내용이 포함됩니다.

• 기본 라이선스 프로비저닝(예: Microsoft 365)

• 회사 청구 플랜(예: Azure EA 또는 MCA)에 온보딩

• Azure 관리 그룹 계층 구조 만들기

• ID, 데이터 보호, Azure 등 다양한 경계에 대한 관리 정책 구성입니다.

• 진단 설정, SIEM 온보딩, CASB 온보딩, PIM 온보딩 등을 포함하여 합의된 사이버 보안 아키텍처별로 보안 스택 배포입니다.

• 합의된 위임에 따라 Microsoft Entra 역할 구성.

• 초기 권한 있는 워크스테이션의 구성 및 배포

• 응급 액세스 계정 프로비저닝

• ID 프로비저닝 스택 구성

환경 간 도구 아키텍처 - ID 프로비저닝 및 소스 제어 파이프라인과 같은 일부 도구는 여러 환경에서 작동해야 할 수도 있습니다. 이러한 도구는 인프라에 중요한 것으로 간주되며 그에 맞게 설계, 디자인, 구현 및 관리되어야 합니다. 따라서 환경 간 도구를 정의해야 할 때마다 모든 환경의 설계자가 참여해야 합니다.

인벤토리 및 표시 유형

Azure 구독 검색 - 검색된 각 테넌트에 대해 Microsoft Entra 전역 관리자는 액세스 권한을 상승하여 환경 내 모든 구독을 볼 수 있습니다. 이 권한 상승은 루트 관리 그룹에서 사용자 액세스 관리자 기본 제공 역할을 할당합니다.

리소스 검색에 읽기 액세스 사용 - 관리 그룹은 여러 구독에서 대규모로 RBAC 할당을 사용합니다. 고객은 루트 관리 그룹에서 역할 할당을 구성하여 중앙 집중식 IT 팀에 읽기 권한자 역할을 부여할 수 있으며, 이는 환경의 모든 구독에 전파됩니다.

리소스 검색 - 환경에서 리소스 읽기 액세스 권한을 얻은 후에는 Azure Resource Graph를 사용하여 환경의 리소스를 쿼리할 수 있습니다.

로깅 및 모니터링

중앙 보안 로그 관리 - 전체 전반에서 일관적인 모범 사례(예: 진단 설정, 로그 보존, SIEM 수집 등)에 따라 중앙 집중식으로 각 환경의 로그를 수집합니다. Azure Monitor는 엔드포인트 디바이스, 네트워크, 운영 체제의 보안 로그 등과 같은 다양한 원본에서 로그를 수집하는 데 사용할 수 있습니다.

자동화된 프로세스 또는 수동 프로세스와 도구를 사용하여 보안 작업의 일부로 로그를 모니터링하는 방법에 대한 자세한 내용은 Microsoft Entra 보안 작업 가이드에서 확인할 수 있습니다.

일부 환경에는 주어진 환경을 떠날 수 있는 데이터(있는 경우)를 제한하는 규정 요구 사항이 있을 수 있습니다. 환경 전체에서 중앙 집중식 모니터링을 사용할 수 없는 경우 팀은 환경 간 횡적 이동 시도와 같은 감사 및 포렌식 목적을 위해 환경 전체의 ID 활동을 상호 연결하는 운영 절차를 갖추어야 합니다. ID 프로비저닝 시스템의 일부로 동일한 사람에 속하는 개체 고유 식별자를 검색할 수 있는 것이 좋습니다.

로그 전략에는 조직에서 사용되는 각 테넌트에 대한 다음과 같은 Microsoft Entra 로그가 포함되어야 합니다.

• 로그인 작업

• 감사 로그

• 위험 이벤트

Microsoft Entra ID는 로그인 활동 로그 및 감사 로그에 대한 Azure Monitor 통합을 제공합니다. 위험 이벤트는 Microsoft Graph API를 통해 수집할 수 있습니다.

다음 다이어그램에서는 모니터링 전략의 일부로 통합해야 하는 다양한 데이터 원본을 보여줍니다.

Azure AD B2C 테넌트는 Azure Monitor와 통합할 수 있습니다. 위에서 Microsoft Entra ID에 대해 설명한 것과 동일한 조건을 사용하여 Azure AD B2C를 모니터링하는 것이 좋습니다.

Azure Lighthouse에서 테넌트 간 관리를 사용하도록 설정한 구독은 Azure Monitor에서 로그를 수집하는 경우 테넌트 간 모니터링을 사용하도록 설정할 수 있습니다. 해당하는 Log Analytics 작업 영역은 리소스 테넌트에 상주할 수 있으며 중앙에서 Azure Monitor 통합 문서를 사용하여 관리 테넌트에서 분석할 수 있습니다. 자세한 내용은 대규모로 위임된 리소스 모니터링 - Azure Lighthouse를 참조하세요.

하이브리드 인프라 OS 보안 로그

모든 하이브리드 ID 인프라 OS 로그는 노출 영역 영향을 고려하여 계층 0 시스템으로 보관하고 신중하게 모니터링해야 합니다. 다음 내용이 포함됩니다.

• AD FS 서버 및 웹 애플리케이션 프록시

• Microsoft Entra Connect

• 애플리케이션 프록시 에이전트

• 암호 쓰기 저장 에이전트

• 암호 보호 게이트웨이 머신

• Microsoft Entra 다단계 인증 RADIUS 확장이 있는 NPS

Microsoft Entra Connect Health를 배포하여 모든 환경의 ID 동기화 및 페더레이션(해당하는 경우)을 모니터링해야 합니다.

로그 스토리지 보존 - 모든 환경에는 일관적인 도구 집합(예: Azure Sentinel 같은 SIEM 시스템), 일반적인 쿼리, 조사 및 포렌식 플레이북을 용이하게 하기 위한 응집력 있는 로그 스토리지 보존 전략, 디자인 및 구현이 있어야 합니다. Azure Policy를 사용하여 진단 설정을 수립할 수 있습니다.

모니터링 및 로그 검토 - ID 모니터링과 관련된 운영 작업은 일관적이어야 하며 각 환경에 소유자가 있어야 합니다. 위에서 설명한 것처럼, 환경 전체에서 규정 준수 및 격리 요구 사항이 허용하는 범위까지 이러한 책임을 통합하기 위해 노력해야 합니다.

다음 시나리오를 명시적으로 모니터링하고 조사해야 합니다.

• 의심스러운 활동 - 모든 Microsoft Entra 위험 이벤트의 의심스러운 활동을 모니터링해야 합니다. 모든 테넌트는 위치 기반 신호의 탐지 노이즈를 방지하도록 네트워크 명명된 위치를 정의해야 합니다. Microsoft Entra ID 보호는 기본적으로 Azure Security Center와 통합됩니다. 위험 탐지 조사에는 ID가 프로비저닝된 모든 환경이 포함되는 것이 좋습니다. 예를 들어 사용자 ID에서 회사 테넌트의 활성 위험이 탐지되는 경우 고객 쪽 테넌트를 운영하는 팀은 해당 환경에서 이루어진 해당 계정의 활동도 조사해야 합니다.

• UEBA(사용자 엔터티 동작 분석) 경고 - UEBA를 사용하여 변칙 검색을 기반으로 인사이트 정보를 얻어야 합니다. Microsoft 365 클라우드용 Defender 앱은 클라우드에서 UEBA를 제공합니다. 고객은 Microsoft 365 ID용 Defender의 온-프레미스 UEBA를 통합할 수 있습니다. MCAS는 Microsoft Entra ID 보호 신호를 읽습니다.

• 응급 액세스 계정 활동 - 응급 액세스 계정을 사용하는 모든 액세스를 모니터링하고 조사를 위한 경고를 만들어야 합니다. 이 모니터링에는 다음이 포함되어야 합니다.

  • 로그인

  • 자격 증명 관리

  • 그룹 멤버 자격에 대한 모든 업데이트.

  • 애플리케이션 할당

• 청구 관리 계정 - Azure EA 또는 MCA에서 청구 관리 역할이 있는 계정의 민감도와 높은 권한을 감안하여 다음을 모니터링하고 경고하는 것이 좋습니다.

  • 청구 역할이 있는 계정의 로그인 시도

  • EA Portal 이외의 애플리케이션에 인증 시도

  • MCA 청구 작업에 전용 계정을 사용하는 경우 Azure Resource Management 이외의 애플리케이션에 인증 시도

  • MCA 청구 작업에 전용 계정을 사용하여 Azure 리소스에 할당

• 권한 있는 역할 활동 - Microsoft Entra PIM에서 생성한 보안 경고를 구성하고 검토합니다. 기술 제어를 통해 직접 RBAC 할당 잠금을 완전히 적용할 수 없는 경우(예: 제품 팀이 작업을 수행할 수 있도록 소유자 역할을 부여해야 함) 사용자가 Azure RBAC를 통해 구독에 액세스하도록 직접 할당될 때마다 경고를 생성하여 PIM 외부의 권한 있는 역할 직접 할당을 모니터링합니다.

• 클래식 역할 할당 - 조직은 클래식 역할 대신 최신 Azure RBAC 역할 인프라를 사용해야 합니다. 따라서 다음 이벤트를 모니터링해야 합니다.

  • 구독 수준에서 클래식 역할에 할당

• 테넌트 수준 구성 - 테넌트 수준 구성 서비스는 시스템에서 경고를 생성해야 합니다.

  • 사용자 지정 도메인 업데이트

  • 브랜딩 업데이트

  • Microsoft Entra B2B 허용/차단 목록

  • Microsoft Entra B2B 허용 ID 공급자(직접 페더레이션 또는 소셜 로그인을 통한 SAML IDP)

  • 조건부 액세스 정책 변경

• 애플리케이션 및 서비스 주체 개체

  • 조건부 액세스 정책이 필요할 수 있는 새 애플리케이션/서비스 주체

  • 애플리케이션 동의 활동

• 관리 그룹 활동 - 관리 그룹의 다음 ID 측면을 모니터링해야 합니다.

  • MG의 RBAC 역할 할당

  • MG에서 적용되는 Azure 정책

  • MG 간에 이동된 구독

  • 루트 MG에 대한 보안 정책의 모든 변경 내용

• 사용자 지정 역할

  • 사용자 지정 역할 정의 업데이트

  • 만들어진 새 사용자 지정 역할

• 사용자 지정 업무 분리 규칙 - 조직에서 업무 분리 규칙을 설정한 경우 Microsoft Entra 권한 관리 호환되지 않는 액세스 패키지를 사용하여 업무 분리를 적용하고 관리자의 위반을 감지하도록 경고를 만들거나 주기적인 검토를 구성하세요.

기타 모니터링 고려 사항 - 로그 관리에 사용되는 리소스를 포함하고 있는 Azure 구독은 중요한 인프라(계층 0)로 간주해야 하며 해당 환경의 보안 운영 팀으로 고정되어야 합니다. Azure Policy 같은 도구를 사용하여 이러한 구독에 추가 컨트롤을 적용하는 것이 좋습니다.

운영 도구

환경 간 도구 디자인 고려 사항:

• 각 테넌트에서 여러 인스턴스의 재배포를 방지하고 운영 비효율성을 방지할 수 있도록, 가급적이면 여러 테넌트에서 사용되는 운영 도구는 Microsoft Entra 다중 테넌트 애플리케이션으로 실행되도록 설계해야 합니다. 구현에는 사용자와 데이터 간의 격리가 유지되도록 하는 권한 부여 논리가 포함되어야 합니다.

• 경고 및 탐지를 추가하여 환경 간 자동화(예: ID 프로비저닝) 및 비상 안전 장치의 임계값 제한을 모니터링합니다. 예를 들어 사용자 계정의 프로비전을 해제하면 광범위한 영향을 미칠 수 있는 버그 또는 운영 오류의 가능성이 있으므로, 사용자 계정의 프로비전 해제가 특정 수준에 도달하면 경고를 표시하려 할 수 있습니다.

• 환경 간 작업을 오케스트레이션하는 모든 자동화는 높은 권한이 있는 시스템으로 작동해야 합니다. 다른 환경의 데이터가 필요한 경우 이 시스템을 가장 보안이 강력한 환경으로 보내고 외부 원본에서 가져와야 합니다. 시스템 무결성을 유지하려면 데이터 유효성 검사 및 임계값을 적용해야 합니다. 일반적인 환경 간 작업은 모든 환경에서 퇴사한 직원의 ID를 제거하는 ID 수명 주기 관리입니다.

IT 서비스 관리 도구 - ServiceNow 같은 ITSM(IT 서비스 관리) 시스템을 사용하는 조직은 활성화 목적의 일부로 티켓 번호를 요청하도록 Microsoft Entra PIM 역할 활성화 설정을 구성해야 합니다.

마찬가지로, Azure Monitor는 IT 서비스 관리 커넥터를 통해 ITSM 시스템과 통합할 수 있습니다.

운영 사례 - 환경에 직접 액세스해야 하는 운영 활동을 사용자 ID로 최소화합니다. 그 대신 일반적인 작업(예: PaaS 솔루션에 용량 추가, 진단 실행 등)을 실행하는 Azure Pipelines로 모델링하고, Azure Resource Manager 인터페이스에 대한 직접 액세스를 “비상” 시나리오로 모델링합니다.

운영 과제

• 서비스 주체 모니터링 활동은 일부 시나리오로 제한됩니다.

• Microsoft Entra PIM 경고에 API가 없습니다. 완화 방법은 PIM 경고를 정기적으로 검토하는 것입니다.

• Azure EA Portal은 모니터링 기능을 제공하지 않습니다. 완화 방법은 전용 관리 계정을 사용하고 계정 활동을 모니터링하는 것입니다.

• MCA가 청구 작업을 위한 감사 로그를 제공하지 않습니다. 완화 방법은 전용 관리 계정을 사용하고 계정 활동을 모니터링하는 것입니다.

• 환경을 운영하는 데 필요한 Azure의 일부 서비스는 다중 테넌트 또는 다중 클라우드일 수 없으므로 모든 환경에서 다시 배포하고 다시 구성해야 합니다.

• 코드 제공 인프라(Infrastructure as code)를 완벽하게 달성하기 위한 Microsoft Online Services의 전체 API 범위가 없습니다. 완화 방법은 API를 최대한 많이 사용하고 나머지에는 포털을 사용하는 것입니다. 이 오픈 소스 이니셔티브는 현재 환경에 적합할 수 있는 접근 방식을 결정하는 데 도움이 됩니다.

• 관리 테넌트의 ID에 대한 구독 액세스 권한이 위임된 리소스 테넌트를 검색하는 프로그래밍 방식 기능이 없습니다. 예를 들어 fabrikam.com 테넌트의 구독을 관리하도록 이메일 주소에서 contoso.com 테넌트의 보안 그룹을 설정한 경우 contoso.com 관리자가 이 위임이 발생한 것을 검색할 수 있는 API가 없습니다.

• 특정 계정(예: 비상 계정, 청구 관리 계정) 활동 모니터링이 기본 제공되지 않습니다. 완화 방법은 고객이 자체 경고 규칙을 만드는 것입니다.

• 테넌트 수준 구성 모니터링이 기본 제공되지 않습니다. 완화 방법은 고객이 자체 경고 규칙을 만드는 것입니다.

다음 단계

• 위임된 관리 및 격리된 환경 소개

• Microsoft Entra 기본 사항

• Azure 리소스 관리 기본 사항

• 단일 테넌트의 리소스 격리

• 여러 테넌트가 있는 리소스 격리