Azure 리소스 관리 기본 사항
Azure 리소스와 관련된 구조와 용어를 이해하는 것이 중요합니다. 다음 이미지는 Azure에서 제공하는 네 가지 범위 수준의 예제를 보여줍니다.
용어
다음은 숙지해야 하는 용어입니다.
리소스 - Azure를 통해 사용할 수 있는 관리 가능한 항목입니다. 리소스의 예로는 가상 머신, 스토리지 계정, 웹앱, 데이터베이스 및 가상 네트워크가 있습니다.
리소스 그룹 - 특정 팀의 관리가 필요한 가상 머신, 연결된 VNet 및 부하 분산 장치 컬렉션과 같은 Azure 솔루션 관련 리소스를 보관하는 컨테이너입니다. 리소스 그룹은 그룹으로 관리하려는 리소스만 포함합니다. 조직에 가장 적합한 요소에 따라 리소스 그룹에 속하는 리소스를 결정합니다. 리소스 그룹은 수명이 같은 모든 리소스를 한꺼번에 삭제하여 수명 주기를 관리하는 데 사용할 수도 있습니다. 이 접근 방식은 악용될 수 있는 조각을 남기지 않음으로써 보안 이점을 제공합니다.
구독 - 조직 계층 구조 관점에서 구독은 리소스와 리소스 그룹의 청구 및 관리 컨테이너입니다. Azure 구독은 Microsoft Entra ID와 트러스트 관계가 있습니다. 구독은 사용자, 서비스 및 디바이스를 인증하기 위해 Microsoft Entra ID를 신뢰합니다.
참고 항목
구독은 하나의 Microsoft Entra 테넌트만 신뢰할 수 있습니다. 그러나 각 테넌트는 여러 구독을 신뢰할 수 있으며 테넌트 간에 구독을 이동할 수 있습니다.
관리 그룹 - Azure 관리 그룹은 구독 위의 다양한 범위에서 정책 및 규정 준수를 적용하는 계층적 방법을 제공합니다. 테넌트 루트 관리 그룹(가장 높은 범위)에 있을 수도 있고 계층의 하위 수준에 있을 수도 있습니다. "관리 그룹"이라는 컨테이너에 구독을 구성하고 거버넌스 조건을 관리 그룹에 적용합니다. 관리 그룹에 속하는 모든 구독은 관리 그룹에 적용되는 조건을 자동으로 상속합니다. 정책 정의는 관리 그룹 또는 구독에 적용할 수 있습니다.
리소스 공급자 - Azure 리소스를 제공하는 서비스입니다. 예를 들어 일반적인 리소스 공급자는 가상 머신 리소스를 제공하는 Microsoft.Compute입니다. Microsoft. Storage는 또 다른 일반적인 리소스 공급자입니다.
Resource Manager 템플릿 - 리소스 그룹, 구독, 테넌트 또는 관리 그룹에 배포할 하나 이상의 리소스를 정의하는 JSON(JavaScript Object Notation) 파일입니다. 템플릿은 리소스를 일관되고 반복적으로 배포하는데 사용할 수 있습니다. 템플릿 배포 개요를 참조하세요. JSON 대신 Bicep 언어를 사용할 수도 있습니다.
Azure 리소스 관리 모델
각 Azure 구독은 Azure Resource Manager에서 사용하는 컨트롤과 연결됩니다. Resource Manager는 Azure용 배포 및 관리 서비스이며, 조직의 ID 관리를 위해 Microsoft Entra ID와 트러스트 관계를, 개인 관리를 위해 MSA(Microsoft 계정)와 트러스트 관계를 맺고 있습니다. Resource Manager는 Azure 구독에서 리소스를 만들고, 업데이트하고, 삭제할 수 있는 관리 계층을 제공합니다. 배포 이후 액세스 제어, 잠금 및 태그와 같은 관리 기능을 사용하여 리소스를 보호하고 구성합니다.
참고 항목
ARM 이전에는 ASM(Azure Service Manager) 또는 "클래식"이라는 또 다른 배포 모델이 있었습니다. 자세한 내용은 Azure Resource Manager 및 클래식 배포를 참조하세요. ASM 모델을 사용한 환경 관리는 이 콘텐츠의 범위를 벗어냅니다.
Azure Resource Manager는 PowerShell, Azure Portal 또는 다른 클라이언트가 리소스 관리에 사용하는 REST API를 호스트하는 프런트 엔드 서비스입니다. 클라이언트가 특정 리소스 관리를 요청하면 Resource Manager는 요청을 완료하기 위해 요청을 리소스 공급자에 프록시합니다. 예를 들어 클라이언트가 가상 머신 리소스 관리를 요청하면 Resource Manager는 요청을 Microsoft. Compute 리소스 공급자에 프록시합니다. Resource Manager를 사용하려면 클라이언트에서 가상 머신 리소스를 관리할 수 있도록 구독 및 리소스 그룹의 식별자를 모두 지정해야 합니다.
Resource Manager가 리소스 관리 요청을 실행하기 전에 컨트롤 세트를 확인해야 합니다.
유효한 사용자 확인 - 리소스 관리를 요청하는 사용자는 관리되는 리소스의 구독과 연결된 Microsoft Entra 테넌트의 계정이 있어야 합니다.
사용자 권한 확인 - 권한은 RBAC(역할 기반 액세스 제어)를 사용하여 사용자에게 할당됩니다. RBAC 역할은 사용자가 특정 리소스에 대해 수행할 수 있는 일련의 사용 권한을 지정합니다. RBAC는 Azure 리소스에 액세스할 수 있는 사용자, 해당 리소스로 수행할 수 있는 작업 및 액세스 권한이 있는 영역을 관리하는 데 도움을 줍니다.
Azure 정책 확인 - Azure 정책은 특정 리소스에 대해 허용되거나 명시적으로 거부된 작업을 지정합니다. 예를 들어 사용자가 특정 형식의 가상 머신만 배포할 수 있도록 허용하는(또는 허용하지 않는) 정책을 지정할 수 있습니다.
다음 다이어그램에는 방금 설명한 리소스 모델이 요약되어 있습니다.
Azure Lighthouse - Azure Lighthouse를 사용하여 모든 테넌트의 리소스를 관리할 수 있습니다. 조직은 구독 또는 리소스 그룹 수준의 역할을 다른 테넌트 ID에 위임할 수 있습니다.
Azure Lighthouse에서 위임된 리소스 관리가 가능한 구독에는 구독 또는 리소스 그룹을 관리할 수 있는 테넌트 ID를 나타내고, 리소스 테넌트의 기본 제공 RBAC 역할을 서비스 공급자 테넌트의 ID로 매핑하는 특성이 있습니다. 런타임에 Azure Resource Manager는 이러한 특성을 사용하여 서비스 공급자 테넌트에서 들어오는 토큰에 권한을 부여합니다.
Azure Lighthouse 자체는 Azure 리소스 공급자로 모델링됩니다. 즉, Azure Policy를 통해 테넌트의 위임 측면을 대상으로 지정할 수 있습니다.
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse는 MSP(관리되는 서비스 공급자)가 Microsoft 365 Business Premium, Microsoft 365 E3 또는 Windows 365 Business를 사용하는 SMB(중소기업) 고객 대신 디바이스, 데이터 및 사용자를 대규모로 보호하고 관리할 수 있는 관리 포털입니다.
Microsoft Entra ID를 사용하여 Azure 리소스 관리
이제 Azure의 리소스 관리 모델을 더 자세히 알아보았으므로, Azure 리소스의 ID 및 액세스를 관리할 수 있는 몇 가지 Microsoft Entra ID 기능을 간략하게 살펴보겠습니다.
결제
일부 청구 역할은 리소스와 상호 작용하거나 리소스를 관리할 수 있으므로, 청구는 리소스 관리에 중요합니다. 청구 방식은 Microsoft와 체결한 계약 유형에 따라 다릅니다.
Azure 기업계약
Azure EA(Azure 기업계약) 고객은 Microsoft와 상업적 계약을 실행하면 Azure EA Portal에 온보딩됩니다. 온보딩 시 ID가 "루트" 엔터프라이즈 관리자 청구 역할에 연결됩니다. 포털에서는 다음과 같은 관리 함수 계층 구조를 제공합니다.
부서는 비용을 논리적 그룹으로 분류하고 부서 수준에서 예산 또는 할당량을 설정하는 데 도움이 됩니다.
계정은 부서를 더욱 세분화하는 데 사용됩니다. 계정을 사용하여 구독을 관리하고 보고서에 액세스할 수 있습니다. EA Portal은 MSA(Microsoft 계정) 또는 Microsoft Entra 계정에 권한을 부여할 수 있습니다(포털에서 "회사 또는 학교 계정"으로 식별됨). EA Portal에서 "계정 소유자" 역할이 부여된 ID는 Azure 구독을 만들 수 있습니다.
엔터프라이즈 청구 및 Microsoft Entra 테넌트
계정 소유자가 기업계약 내에서 Azure 구독을 만들면 구독의 ID 및 액세스 관리는 다음과 같이 구성됩니다.
Azure 구독은 계정 소유자의 동일한 Microsoft Entra 테넌트에 연결됩니다.
구독을 만든 계정 소유자에게는 서비스 관리자 및 계정 관리자 역할이 할당됩니다. (Azure EA Portal은 구독을 관리하기 위해 ASM(Azure Service Manager) 또는 "클래식" 역할을 할당합니다. 자세한 내용은 Azure Resource Manager 및 클래식 배포를 참조하세요.
Azure EA Portal에서 "회사 또는 학교 계정 교차 테넌트" 인증 유형을 설정하여 여러 테넌트를 지원하도록 기업계약을 구성할 수 있습니다. 위의 경우 조직은 아래 다이어그램과 같이 각 테넌트에 대한 여러 계정과 각 계정에 대한 여러 구독을 설정할 수 있습니다.
위에서 설명한 기본 구성은 Azure EA 계정 소유자에게 그들이 만든 구독의 리소스를 관리할 수 있는 권한을 부여한다는 점에 유의해야 합니다. 프로덕션 워크로드를 보유한 구독의 경우 구독을 만든 직후에 구독의 서비스 관리자를 변경하여 청구와 리소스 관리를 분리하는 것이 좋습니다.
계정 소유자가 구독에 대한 서비스 관리자 액세스 권한을 다시 얻을 수 없도록 추가로 분리하기 위해, 구독을 만든 후 구독의 테넌트를 변경할 수 있습니다. 계정 소유자는 구독이 이동되는 Microsoft Entra 테넌트에 사용자 개체가 없는 경우 서비스 소유자 역할을 다시 얻을 수 없습니다.
자세한 내용은 Azure 역할, Microsoft Entra 역할, 클래식 구독 관리자 역할을 참조하세요.
Microsoft 고객 계약
MCA(Microsoft 고객 계약)에 등록된 고객은 자체 역할이 있는 다른 청구 관리 시스템을 사용합니다.
Microsoft 고객 계약의 청구 계정에는 청구서 및 결제 방법을 관리할 수 있는 하나 이상의 청구 프로필이 포함되어 있습니다. 각 청구 프로필에는 청구 프로필의 청구서에 명시된 비용을 정리할 수 있는 하나 이상의 청구서 섹션이 있습니다.
Microsoft 고객 계약에서 청구 역할은 단일 Microsoft Entra 테넌트에서 옵니다. 여러 테넌트에 대한 구독을 프로비전하려면 처음에 MCA와 동일한 Microsoft Entra 테넌트에서 구독을 만든 다음, 구독을 변경해야 합니다. 아래 다이어그램에서는 IT 회사 사전 프로덕션 환경에 대한 구독이 만들어진 후 ContosoSandbox 테넌트로 이동되었습니다.
Azure의 RBAC 및 역할 할당
Microsoft Entra 기본 사항 섹션에서는 Azure RBAC가 Azure 리소스에 대한 세분화된 액세스 관리를 제공하고 많은 기본 제공 역할을 포함하고 있는 권한 부여 시스템이라는 것을 배웠습니다. 사용자 지정 역할을 만들고, 다양한 범위에서 역할을 할당할 수 있습니다. 권한은 Azure 리소스에 대한 액세스를 요청하는 개체에 RBAC 역할을 할당하여 적용됩니다.
Microsoft Entra 역할은 Azure 역할 기반 액세스 제어와 같은 개념을 기반으로 작동합니다. 이러한 두 역할 기반 액세스 제어 시스템의 차이점은, Azure RBAC는 Azure Resource Management를 사용하여 가상 머신 또는 스토리지와 같은 Azure 리소스에 대한 액세스를 제어하고 Microsoft Entra 역할은 Microsoft Entra ID, 애플리케이션 및 Office 365 같은 Microsoft 서비스에 대한 액세스를 제어한다는 것입니다.
Microsoft Entra 역할과 Azure RBAC 역할은 모두 Microsoft Entra Privileged Identity Management와 통합되어 승인 워크플로 및 MFA와 같은 Just-In-Time 활성화 정책을 사용합니다.
Azure의 ABAC 및 역할 할당
ABAC(특성 기반 액세스 제어)는 보안 주체, 리소스 및 환경과 관련된 특성에 따라 액세스를 정의하는 권한 부여 시스템입니다. ABAC를 사용하면 특성을 기반으로 리소스에 대한 보안 주체 액세스 권한을 부여할 수 있습니다. Azure ABAC는 Azure용 ABAC의 구현을 의미합니다.
Azure ABAC는 특정 작업의 맥락에서 특성을 기반으로 역할 할당 조건을 추가하여 Azure RBAC에서 빌드됩니다. 역할 할당 조건은 필요에 따라 역할 할당에 추가하여 보다 세분화된 액세스 제어를 제공할 수 있는 추가 검사입니다. 조건은 역할 정의 및 역할 할당의 일부로 부여된 권한을 필터링합니다. 예를 들어 개체를 읽을 특정 태그를 포함하는 개체를 필요로 하는 조건을 추가할 수 있습니다. 조건을 사용하여 특정 리소스에 대한 액세스를 명시적으로 거부할 수 없습니다.
조건부 액세스
Microsoft Entra 조건부 액세스를 사용하여 Azure 관리 엔드포인트에 대한 액세스를 관리할 수 있습니다. 조건부 액세스 정책을 Windows Azure Service Management API 클라우드 앱에 적용하여 다음과 같은 Azure 리소스 관리 엔드포인트를 보호할 수 있습니다.
Azure Resource Manager 공급자(서비스)
Azure Resource Manager API
Azure PowerShell
Azure CLI
Azure Portal
예를 들어 관리자는 사용자가 승인된 위치에서만 Azure Portal에 로그인할 수 있고 MFA(다단계 인증) 또는 하이브리드 Microsoft Entra 도메인 조인 디바이스가 필요한 조건부 액세스 정책을 구성할 수 있습니다.
Azure 관리 ID
클라우드 애플리케이션을 빌드할 때 일반적으로 직면하는 난관 중 하나는 코드에서 클라우드 서비스에 인증하는 데 사용되는 자격 증명을 관리하는 방법입니다. 자격 증명을 안전하게 보호하는 것이 중요합니다. 자격 증명이 개발자 워크스테이션에 표시되지 않고 소스 제어에 체크 인되지 않는 것이 가장 좋습니다. Azure 리소스의 관리 ID는 Microsoft Entra ID에서 자동으로 관리되는 ID를 Azure 서비스에 제공합니다. 이 ID를 사용하면 코드에 자격 증명을 사용하지 않고도 Microsoft Entra 인증을 지원하는 서비스에 인증할 수 있습니다.
두 가지 종류의 관리 ID가 있습니다.
시스템이 할당한 관리 ID는 Azure 리소스에서 직접 사용하도록 설정됩니다. 리소스를 사용하도록 설정하면 Azure는 연결된 구독의 신뢰할 수 있는 Microsoft Entra 테넌트에 해당 리소스에 대한 ID를 만듭니다. ID가 만들어지면 자격 증명이 리소스에 프로비저닝됩니다. 시스템이 할당한 ID의 수명 주기는 Azure 리소스와 직접적으로 연관됩니다. 리소스가 삭제되면 Azure는 Microsoft Entra ID에서 자격 증명과 ID를 자동으로 정리합니다.
사용자가 할당한 관리 ID는 독립 실행형 Azure 리소스로 생성됩니다. Azure는 리소스가 연결된 구독이 신뢰할 수 있는 Microsoft Entra 테넌트에 ID를 만듭니다. 만들어진 ID는 하나 이상의 Azure 리소스에 할당할 수 있습니다. 사용자가 할당한 ID의 수명 주기는 할당된 Azure 리소스의 수명 주기와 별도로 관리됩니다.
내부적으로 관리 ID는 특정 Azure 리소스에만 사용할 수 있는 특수 유형의 서비스 주체입니다. 관리 ID가 삭제되면 해당하는 서비스 주체가 자동으로 제거됩니다. Graph API 권한 부여는 PowerShell에서만 수행할 수 있으므로, 관리 ID의 일부 기능은 포털 UI를 통해 액세스할 수 없습니다.
Microsoft Entra Domain Services
Microsoft Entra Domain Services는 관리형 도메인을 제공하여 레거시 프로토콜을 사용하는 Azure 워크로드에 대한 인증을 지원합니다. 지원되는 서버는 온-프레미스 AD DS 포리스트에서 이동되어 Microsoft Entra Domain Services 관리형 도메인에 조인되며, 인증에 레거시 프로토콜(예: Kerberos 인증)을 계속 사용합니다.
Azure AD B2C 디렉터리 및 Azure
Azure AD B2C 테넌트는 청구 및 통신을 위해 Azure 구독에 연결됩니다. Azure AD B2C 테넌트의 디렉터리에는 Azure 구독의 Azure RBAC 권한 있는 역할과 독립적인 자체 포함 역할 구조가 있습니다.
Azure AD B2C 테넌트가 처음으로 프로비저닝될 때 B2C 테넌트를 만드는 사용자에게 구독의 기여자 또는 소유자 권한이 있어야 합니다. 나중에 다른 계정을 만들고 디렉터리 역할에 할당할 수 있습니다. 자세한 내용은 Microsoft Entra ID의 역할 기반 액세스 제어 개요를 참조하세요.
연결된 Microsoft Entra 구독의 소유자와 기여자는 구독과 디렉터리 간의 링크를 제거할 수 있으며, 이는 진행 중인 Azure AD B2C 사용 요금 청구에 영향을 줍니다.
Azure의 IaaS 솔루션에 대한 ID 고려 사항
이 시나리오에서는 IaaS(Infrastructure-as-a-Service) 워크로드에 대한 조직의 ID 격리 요구 사항을 다룹니다.
IaaS 워크로드의 격리 관리와 관련된 세 가지 주요 옵션이 있습니다.
독립 실행형 AD DS(Active Directory Domain Services)에 조인된 가상 머신
Microsoft Entra Domain Services 조인된 가상 머신
Azure에서 Microsoft Entra 인증을 사용하여 가상 머신에 로그인
처음 두 옵션에서 숙지해야 하는 주요 개념은 이러한 시나리오와 관련된 두 개의 ID 영역이 있다는 것입니다.
RDP(원격 데스크톱 프로토콜)를 통해 Azure Windows Server VM에 로그인하는 경우, 일반적으로 온-프레미스 AD DS 도메인 컨트롤러 또는 Microsoft Entra Domain Services에 대해 Kerberos 인증을 수행하는 도메인 자격 증명을 사용하여 서버에 로그온하게 됩니다. 또는 서버가 도메인에 조인되지 않은 경우 로컬 계정을 사용하여 가상 머신에 로그인할 수 있습니다.
VM을 만들거나 관리하기 위해 Azure Portal에 로그인할 때 Microsoft Entra ID에 대해 인증(올바른 계정을 동기화한 경우 아마도 동일한 자격 증명을 사용하여)하게 되며, AD FS(Active Directory Federation Services) 또는 통과 인증을 사용하는 경우 이로 인해 도메인 컨트롤러에 대한 인증이 발생할 수 있습니다.
독립 실행형 Active Directory Domain Services에 조인된 가상 머신
AD DS는 조직에서 주로 온-프레미스 ID 서비스 때문에 채택하는 Windows Server 기반 디렉터리 서비스입니다. AD DS 관리자 및 다른 포리스트의 사용자로부터 ID를 격리해야 하는 Azure에 IaaS 워크로드를 배포하는 것이 요구 사항인 경우 AD DS를 배포하면 됩니다.
이 시나리오에서는 다음 사항을 고려해야 합니다.
AD DS 도메인 컨트롤러: 인증 서비스의 고가용성 및 고성능을 확보할 수 있도록 적어도 2개의 AD DS 도메인 컨트롤러를 배포해야 합니다. 자세한 내용은 AD DS 디자인 및 계획을 참조하세요.
AD DS 디자인 및 계획 - 새 AD DS 포리스트를 만들고 다음 서비스를 올바르게 구성해야 합니다.
AD DS DNS(Domain Name Services) - 서버 및 애플리케이션에 대한 이름 확인이 올바르게 작동하도록 AD DS 내부의 관련 영역에 AD DS DNS를 구성해야 합니다.
AD DS 사이트 및 서비스 - 애플리케이션의 대기 시간이 짧고 도메인 컨트롤러에 대한 고성능 액세스가 가능하도록 이러한 서비스를 구성해야 합니다. 서버가 위치한 관련 가상 네트워크, 서브넷 및 데이터 센터 위치는 사이트 및 서비스에 구성해야 합니다.
AD DS FSMO - 필요한 FSMO(Flexible Single Master Operation) 역할을 검토하고 적절한 AD DS 도메인 컨트롤러에 할당해야 합니다.
AD DS 도메인 조인 - 인증, 구성 및 관리를 위해 AD DS가 필요한 모든 서버("jumpbox 제외" 제외)를 격리된 포리스트에 조인해야 합니다.
AD DS GPO(그룹 정책) - 구성이 보안 요구 사항을 충족하고 포리스트 및 도메인 조인 머신에서 구성이 표준화되도록 AD DS GPO를 구성해야 합니다.
AD DS OU(조직 구성 단위) - 구성을 관리하고 적용할 목적으로 AD DS 리소스를 논리 관리 및 구성 사일로로 그룹화하도록 AD DS OU를 정의해야 합니다.
역할 기반 액세스 제어 - 이 포리스트에 조인된 리소스를 관리하고 액세스할 수 있도록 RBAC를 정의해야 합니다. 다음 내용이 포함됩니다.
AD DS 그룹 - 적절한 사용자 권한을 AD DS 리소스에 적용하려면 그룹을 만들어야 합니다.
관리 계정 - 이 섹션의 시작 부분에서 설명한 것처럼 이 솔루션을 관리하는 데 필요한 2개의 관리 계정이 있습니다.
하나는 AD DS 및 도메인 조인 서버에서 필요한 관리를 수행하는 데 필요한 최소 액세스 권한이 있는 AD DS 관리 계정이고,
다른 하나는 Azure Portal에 액세스하여 가상 머신, VNet, 네트워크 보안 그룹 및 기타 필요한 Azure 리소스를 연결, 관리 및 구성하기 위한 Microsoft Entra 관리 계정입니다.
AD DS 사용자 계정 - 이 솔루션이 호스트하는 애플리케이션에 사용자가 액세스할 수 있도록 허용하려면 관련 사용자 계정을 프로비저닝하고 올바른 그룹에 추가해야 합니다.
VNet(가상 네트워크) - 구성 지침
AD DS 도메인 컨트롤러 IP 주소 - 도메인 컨트롤러는 운영 체제 내의 고정 IP 주소로 구성하면 안 됩니다. IP 주소는 항상 동일하게 유지되도록 Azure VNet에 예약해야 하고, DC는 DHCP를 사용하도록 구성해야 합니다.
VNet DNS 서버 - 도메인 컨트롤러를 가리키도록 이 격리된 솔루션에 포함된 VNet에서 DNS 서버를 구성해야 합니다. 이렇게 해야만 애플리케이션 및 서버가 AD DS 포리스트에 조인된 필수 AD DS 서비스 또는 기타 서비스를 확인할 수 있습니다.
NSG(네트워크 보안 그룹) - 도메인 컨트롤러는 필요한 서버(예: 도메인 조인 머신 또는 jumpbox)에서 도메인 컨트롤러에만 액세스할 수 있도록 정의된 NSG가 있는 자체 VNet 또는 서브넷에 있어야 합니다. NSG 만들기 및 관리를 간소화하려면 ASG(애플리케이션 보안 그룹)에 Jumpbox를 추가해야 합니다.
과제: 아래 목록에는 ID 격리를 위해 이 옵션을 사용할 때 해결해야 하는 주요 과제가 강조되어 있습니다.
운영, 관리 및 모니터링할 AD DS 포리스트가 증가하여 IT 팀이 수행할 작업이 더 늘어나게 됩니다.
패치 및 소프트웨어 배포를 관리하려면 추가 인프라가 필요할 수 있습니다. 조직은 이러한 서버를 관리하기 위해 Azure 업데이트 관리, GPO(그룹 정책) 또는 SCCM(System Center Configuration Manager)을 배포하는 방안을 고려해야 합니다.
사용자가 리소스 액세스에 사용할, 따라서 기억해야 하는 자격 증명이 늘어나게 됩니다.
Important
이 격리된 모델의 경우 도메인 컨트롤러에 연결되어 있지 않거나 고객의 회사 네트워크에서 도메인 컨트롤러에 연결되어 있지 않고 다른 포리스트와 구성된 트러스트가 없다고 가정합니다. AD DS 도메인 컨트롤러를 관리 및 운영할 수 있는 지점을 허용하도록 jumpbox 또는 관리 서버를 만들어야 합니다.
Microsoft Entra Domain Services 조인된 가상 머신
AD DS 관리자 및 다른 포리스트의 사용자로부터 ID를 격리해야 하는 Azure에 IaaS 워크로드를 배포하는 것이 요구 사항인 경우 Microsoft Entra Domain Services 관리형 도메인을 배포하면 됩니다. Microsoft Entra Domain Services는 관리형 도메인을 제공하여 레거시 프로토콜을 사용하는 Azure 워크로드에 대한 인증을 지원하는 서비스입니다. 자체 AD DS를 빌드하고 관리하는 기술적 복잡성 없이 격리된 도메인을 제공합니다. 다음 사항을 고려해야 합니다.
Microsoft Entra Domain Services 관리형 도메인 - Microsoft Entra Domain Services 관리형 도메인은 Microsoft Entra 테넌트당 하나만 배포할 수 있으며, 단일 VNet에 바인딩됩니다. 이 VNet은 Microsoft Entra Domain Services 인증을 위해 "허브"를 형성하는 것이 좋습니다. 이 허브에서 서버 및 애플리케이션에 레거시 인증을 허용하도록 "스포크"를 만들고 연결할 수 있습니다. 스포크는 Microsoft Entra Domain Services 조인 서버가 위치하고 Azure 네트워크 게이트웨이 또는 VNet 피어링을 사용하여 허브에 연결되는 추가 VNet입니다.
관리형 도메인 위치 - Microsoft Entra Domain Services 관리형 도메인을 배포할 때 위치를 설정해야 합니다. 위치는 관리되는 도메인이 배포되는 물리적 지역(데이터 센터)입니다. 다음을 수행하는 것이 좋습니다.
Microsoft Entra Domain Services 서비스가 필요한 서버 및 애플리케이션과 지리적으로 가까운 위치를 고려합니다.
고가용성 요구 사항을 충족하기 위한 가용성 영역 기능을 제공하는 지역을 고려합니다. 자세한 내용은 Azure의 지역 및 가용성 영역을 참조하세요.
개체 프로비전 - Microsoft Entra Domain Services는 Microsoft Entra Domain Services가 배포된 구독과 연결된 Microsoft Entra ID에서 ID를 동기화합니다. 연결된 Microsoft Entra ID가 Microsoft Entra Connect와 동기화가 설정된 경우(사용자 포리스트 시나리오) 이러한 ID의 수명 주기도 Microsoft Entra Domain Services에 반영될 수 있습니다. 이 서비스는 Microsoft Entra ID의 사용자 및 그룹 개체를 프로비저닝하는 데 사용할 수 있는 두 가지 모드를 제공합니다.
모두: 모든 사용자와 그룹이 Microsoft Entra ID에서 Microsoft Entra Domain Services로 동기화됩니다.
범위 지정됨: 그룹 범위 내의 사용자만 Microsoft Entra ID에서 Microsoft Entra Domain Services로 동기화됩니다.
Microsoft Entra Domain Services를 처음 배포하면 Microsoft Entra ID의 개체를 복제하도록 자동 단방향 동기화가 구성됩니다. 이 단방향 동기화는 백그라운드에서 계속 실행되므로 Microsoft Entra ID의 변경된 내용을 적용하여 Microsoft Entra Domain Services 관리형 도메인을 최신 상태로 유지합니다. Microsoft Entra Domain Services에서 Microsoft Entra ID로는 동기화가 수행되지 않습니다. 자세한 내용은 Microsoft Entra Domain Services 관리되는 도메인에서 개체 및 자격 증명을 동기화하는 방법을 참조하세요.
동기화 유형을 모두에서 범위 지정됨으로 또는 그 반대로 변경해야 하는 경우 Microsoft Entra Domain Services 관리형 도메인을 삭제하고 다시 만든 후 구성해야 합니다. 또한 조직은 "범위 지정된" 프로비저닝을 사용하여 ID를 Microsoft Entra Domain Services 리소스에 액세스해야 하는 ID로만 줄이는 것이 좋습니다.
GPO(그룹 정책 개체) - Microsoft Entra Domain Services 관리형 도메인에서 GPO를 구성하려면 Microsoft Entra Domain Services 관리형 도메인에 조인된 서버에서 그룹 정책 관리 도구를 사용해야 합니다. 자세한 내용은 Microsoft Entra Domain Services 관리되는 도메인에서 그룹 정책 관리를 참조하세요.
보안 LDAP - Microsoft Entra Domain Services는 보안 LDAP 서비스가 필요한 애플리케이션에서 사용할 수 있는 보안 LDAP 서비스를 제공합니다. 이 설정은 기본적으로 사용하지 않도록 설정됩니다. 보안 LDAP를 사용하도록 설정하려면 인증서를 업로드하고, Microsoft Entra Domain Services가 배포된 VNet을 보호하는 NSG에서 포트 636이 Microsoft Entra Domain Services 관리형 도메인에 연결하도록 허용해야 합니다. 자세한 내용은 Microsoft Entra Domain Services 관리되는 도메인에 대해 보안 LDAP 구성을 참조하세요.
관리 - Microsoft Entra Domain Services에서 관리 업무를 수행하려면(예: 머신 도메인 조인 또는 GPO 편집) 이 작업에 사용되는 계정이 Microsoft Entra DC 관리자 그룹에 포함되어야 합니다. 이 그룹의 구성원인 계정은 도메인 컨트롤러에 직접 로그인하여 관리 작업을 수행할 수 없습니다. 그 대신 Microsoft Entra Domain Services 관리형 도메인에 조인된 관리 VM을 만든 다음, 일반 AD DS 관리 도구를 설치해야 합니다. 자세한 내용은 Microsoft Entray Domain Services의 사용자 계정, 암호 및 관리에 대한 관리 개념을 참조하세요.
암호 해시 - Microsoft Entra Domain Services를 사용한 인증이 작동하려면 모든 사용자의 암호 해시가 NTLM(NT LAN Manager) 및 Kerberos 인증에 적합한 형식이어야 합니다. Microsoft Entra Domain Services를 사용한 인증이 예상대로 작동하도록 하려면 다음과 같은 필수 조건을 충족해야 합니다.
AD DS의 Microsoft Entra Connect와 사용자 동기화 - 레거시 암호 해시를 온-프레미스 AD DS에서 Microsoft Entra ID로 동기화해야 합니다.
Microsoft Entra ID에서 만든 사용자 - Microsoft Entra Domain Services에 사용할 올바른 해시를 생성하려면 사용자의 암호를 다시 설정해야 합니다. 자세한 내용은 암호 해시 동기화 사용을 참조하세요.
네트워크 - Microsoft Entra Domain Services는 Azure VNet에 배포되므로 서버 및 애플리케이션이 보호되며, 관리형 도메인에 올바르게 액세스할 수 있도록 하는 방법을 고려해야 합니다. 자세한 내용은 Microsoft Entra Domain Services의 가상 네트워크 디자인 고려 사항 및 구성 옵션을 참조하세요.
Microsoft Entra Domain Services는 자체 서브넷에 배포해야 합니다. 기존 서브넷 또는 게이트웨이 서브넷을 사용하지 마세요.
NSG(네트워크 보안 그룹) - Microsoft Entra Domain Services 관리형 도메인을 배포하는 동안 만들어집니다. 이 네트워크 보안 그룹에는 올바른 서비스 통신에 필요한 규칙이 포함되어 있습니다. 고유의 사용자 지정 규칙을 사용하여 기존 네트워크 보안 그룹을 만들거나 사용하지 마세요.
Microsoft Entra Domain Services에 3~5개의 IP 주소가 필요 - 서브넷 IP 주소 범위가 이 개수만큼 주소를 제공할 수 있어야 합니다. 사용 가능한 IP 주소를 제한하면 Microsoft Entra Domain Services가 도메인 컨트롤러 2개를 유지하지 못할 수 있습니다.
VNet DNS 서버 - 이전에 "허브 및 스포크" 모델에 대해 설명한 것처럼, Microsoft Entra Domain Services 관리형 도메인에 조인된 서버가 Microsoft Entra Domain Services 관리형 도메인을 확인할 수 있는 올바른 DNS 설정을 갖도록 VNet에서 DNS를 올바르게 구성하는 것이 중요합니다. 각 VNet에는 서버가 IP 주소를 획득할 때 서버에 전달되는 DNS 서버 항목이 있으며, 이러한 DNS 항목은 Microsoft Entra Domain Services 관리형 도메인의 IP 주소여야 합니다. 자세한 내용은 Azure 가상 네트워크에 대한 DNS 설정 업데이트를 참조하세요.
과제 - 다음 목록에는 ID 격리를 위해 이 옵션을 사용할 때 해결해야 하는 주요 과제가 강조되어 있습니다.
일부 Microsoft Entra Domain Services 구성은 Microsoft Entra Domain Services 조인된 서버에서만 관리할 수 있습니다.
Microsoft Entra Domain Services 관리형 도메인은 Microsoft Entra 테넌트당 하나만 배포할 수 있습니다. 이 섹션에서 설명한 것처럼, 다른 VNet의 서비스에 Microsoft Entra Domain Services 인증을 제공하는 데 허브 및 스포크 모델을 사용하는 것이 좋습니다.
패치 및 소프트웨어 배포를 관리하려면 추가 인프라가 필요할 수 있습니다. 조직은 이러한 서버를 관리하기 위해 Azure 업데이트 관리, GPO(그룹 정책) 또는 SCCM(System Center Configuration Manager)을 배포하는 방안을 고려해야 합니다.
이 격리된 모델의 경우 고객의 회사 네트워크에서 Microsoft Entra Domain Services 관리형 도메인을 호스트하는 VNet에 연결되어 있지 않고, 다른 포리스트로 구성된 트러스트가 없다고 가정합니다. Microsoft Entra Domain Services를 관리 및 운영할 수 있는 지점이 되도록 jumpbox 또는 관리 서버를 만들어야 합니다.
Microsoft Entra 인증을 사용하여 Azure에서 가상 머신에 로그인
ID 격리가 필요한 IaaS 워크로드를 Azure에 배포해야 하는 경우, 마지막 옵션은 이 시나리오에서 Microsoft Entra ID를 사용하여 서버에 로그온하는 것입니다. 이렇게 하면 인증을 목적으로 Microsoft Entra ID를 ID 영역으로 만들 수 있으며, 필요한 Microsoft Entra 테넌트에 연결된 관련 구독에 서버를 프로비저닝하여 ID를 격리할 수 있습니다. 다음 사항을 고려해야 합니다.
지원되는 운영 체제: Azure에서 Microsoft Entra 인증을 사용하여 가상 머신에 로그인하는 방법은 현재 Windows 및 Linux에서 지원됩니다. 지원되는 운영 체제에 대한 자세한 내용은 Windows 및 Linux 설명서를 참조하세요.
자격 증명: Azure에서 Microsoft Entra 인증을 사용하여 가상 머신에 로그인하면 일반적으로 가상 머신에 로그인하기 위해 Microsoft Entra 서비스에 액세스하는 데 사용하는 것과 동일한 페더레이션 또는 관리되는 Microsoft Entra 자격 증명을 사용할 수 있다는 장점이 있습니다.
참고 항목
이 시나리오에서 로그인에 사용되는 Microsoft Entra 테넌트는 가상 머신이 프로비저닝된 구독과 연결된 Microsoft Entra 테넌트입니다. 이 Microsoft Entra 테넌트는 ID가 온-프레미스 AD DS에서 동기화된 테넌트일 수 있습니다. 이러한 서버에 로그인하는 데 사용할 구독 및 Microsoft Entra 테넌트를 선택할 때, 조직은 격리 주체에 따라 정보에 입각한 선택을 해야 합니다.
네트워크 요구 사항: 이러한 가상 머신은 인증을 위해 Microsoft Entra ID에 액세스해야 하므로, 가상 머신 네트워크 구성에서 443의 Microsoft Entra 엔드포인트에 대한 아웃바운드 액세스를 허용해야 합니다. 자세한 내용은 Windows 및 Linux 설명서를 참조하세요.
RBAC(역할 기반 액세스 제어): 2개의 RBAC 역할을 사용하여 이러한 가상 머신에 대한 적절한 수준의 액세스를 제공할 수 있습니다. 이러한 RBAC 역할은 Azure Portal 또는 Azure Cloud Shell 환경을 통해 구성할 수 있습니다. 자세한 내용은 VM에 대한 역할 할당 구성을 참조하세요.
가상 머신 관리자 로그온: 이 역할이 할당된 사용자는 관리자 권한으로 Azure 가상 머신에 로그인할 수 있습니다.
가상 머신 사용자 로그온: 이 역할이 할당된 사용자는 일반 사용자 권한으로 Azure 가상 머신에 로그인할 수 있습니다.
조건부 액세스: Microsoft Entra ID를 사용하여 Azure 가상 머신에 로그인하면 로그인 프로세스의 일환으로 조건부 액세스를 적용할 수 있다는 장점이 있습니다. 이를 통해 조직은 가상 머신에 액세스하려면 조건을 충족하도록 요구하고 다단계 인증을 사용하여 강력한 인증을 제공할 수 있습니다. 자세한 내용은 조건부 액세스 사용을 참조하세요.
참고 항목
Microsoft Entra ID에 조인된 가상 머신에 대한 원격 연결은 해당 가상 머신과 동일한 디렉터리에 조인된 Microsoft Entra 또는 하이브리드 Microsoft Entra인 Windows 10, Windows 11 및 클라우드 PC에서만 허용됩니다.
과제: 아래 목록에는 ID 격리를 위해 이 옵션을 사용할 때 해결해야 하는 주요 과제가 강조되어 있습니다.
중앙 관리 또는 서버 구성이 없습니다. 예를 들어 서버 그룹에 적용할 수 있는 그룹 정책 없습니다. 조직은 이러한 서버의 패치 및 업데이트를 관리할 수 있도록 Azure의 업데이트 관리를 배포하는 것을 고려해야 합니다.
이러한 서버 또는 서비스에서 Windows 통합 인증과 같은 온-프레미스 메커니즘을 사용하여 인증해야 하는 요구 사항이 있는 다중 계층 애플리케이션에는 적합하지 않습니다. 조직에서 이렇게 해야 하는 경우, 독립 실행형 Active Directory Domain Services 또는 이 섹션에 설명된 Microsoft Entra Domain Services 시나리오를 살펴보는 것이 좋습니다.
이 격리된 모델의 경우 고객의 회사 네트워크에서 가상 머신을 호스트하는 VNet에 연결되어 있지 않다고 가정합니다. 이러한 서버를 관리 및 운영할 수 있는 지점을 허용하도록 jumpbox 또는 관리 서버를 만들어야 합니다.