이 문서에서는 제로 트러스트 원칙을 준수하는 조건부 액세스 아키텍처에 대해 설명합니다. 아키텍처는 가상 사용자 기반 접근 방식을 사용하여 구조적 조건부 액세스 프레임워크를 형성합니다.
조건부 액세스 제로 트러스트 아키텍처
먼저 아키텍처를 선택해야 합니다. 대상 또는 제로 트러스트 조건부 액세스 아키텍처를 고려하는 것이 좋습니다. 이 다이어그램은 해당 설정을 보여줍니다.
대상 및 제로 트러스트 아키텍처에 대한 설정을 보여 주는 
제로 트러스트 조건부 액세스 아키텍처는 제로 트러스트의 원칙에 가장 적합한 아키텍처입니다. 조건부 액세스 정책에서 모든 클라우드 앱 옵션을 선택하면 알려진 사용자 및 알려진 디바이스 또는 규격 디바이스와 같은 제공된 권한 부여 컨트롤에 의해 모든 엔드포인트가 보호됩니다. 그러나 정책은 조건부 액세스를 지원하는 엔드포인트 및 앱에만 적용되는 것이 아닙니다. 사용자가 상호 작용하는 모든 엔드포인트에 적용됩니다.
예를 들어 다양한 새 PowerShell 및 Microsoft Graph 도구에서 사용되는 디바이스 로그인 흐름 엔드포인트가 있습니다. 디바이스 로그인 흐름은 IoT 디바이스와 같이 로그인 화면을 표시할 수 없는 디바이스에서 로그인을 허용하는 방법을 제공합니다.
디바이스 기반 로그인 명령은 지정된 디바이스에서 실행되고 사용자에게 코드가 표시됩니다. 이 코드는 다른 디바이스에서 사용됩니다. 사용자가 https://aka.ms/devicelogin 이동하여 사용자 이름과 암호를 지정합니다. 다른 디바이스에서 로그인한 후 해당 사용자 컨텍스트의 IoT 디바이스에서 로그인이 성공합니다.
이 로그인의 과제는 디바이스 기반 조건부 액세스를 지원하지 않는다는 것입니다. 즉, 모든 클라우드 앱에 대해 알려진 사용자 및 알려진 디바이스가 필요한 기준 정책을 적용하는 경우 아무도 도구와 명령을 사용할 수 없습니다. 디바이스 기반 조건부 액세스와 동일한 문제가 있는 다른 애플리케이션이 있습니다.
대상으로 하는 다른 아키텍처는 조건부 액세스 정책에서 보호하려는 개별 앱만 대상으로 지정한다는 원칙을 기반으로 합니다. 이 경우 Microsoft Entra ID에 대한 그래프 호출과 같이 이전에 모든 클라우드 앱에서 다루는 엔드포인트에 대한 디바이스 로그인은 조건부 액세스 정책에 의해 보호되지 않으므로 계속 작동합니다.
디바이스 로그인을 예로 사용하여 두 아키텍처를 구분하는 경우 디바이스 로그인으로 인증할 수 있습니다. 각 애플리케이션을 대상으로 지정할 수 있으므로 디바이스 기반 로그인이 필요한 조건부 액세스 정책에서 제외될 수 있다는 점을 감안할 때 하나 또는 몇 개의 개별 애플리케이션에 대해 디바이스 로그인을 허용할 수 있습니다.
대상 아키텍처의 과제는 모든 클라우드 앱을 보호하는 것을 잊어버릴 수 있다는 것입니다. 그럼에도 불구하고 조건부 액세스 정책에서 선택할 수 있는 모든 애플리케이션을 선택합니다. 보호를 해제하여 선택할 수 없는 애플리케이션에 대한 액세스 권한을 그대로 둡니다. Office 포털, Azure EA(기업계약) 포털 및 보안 정보 포털에 대한 액세스가 모두 매우 중요한 포털을 예로 들 수 있습니다.
또 다른 고려 사항은 Microsoft와 파트너가 새로운 기능을 릴리스하고 IT 관리자가 다양한 애플리케이션을 Microsoft Entra ID와 통합함에 따라 시간이 지남에 따라 Office 365 및 Microsoft Entra 앱 수가 증가한다는 것입니다. 이러한 모든 애플리케이션에 대한 액세스는 조건부 액세스를 지원하고 자동으로 정책을 적용하는 새 앱을 검색하는 메커니즘이 있는 경우에만 보호됩니다. 이러한 스크립트를 만들고 유지 관리하는 것은 어려울 수 있습니다.
또한 하나의 조건부 액세스 정책에 대해 지원되는 최대 앱 수는 약 250개입니다. 페이로드 초과에 대한 오류가 발생하기 전에 최대 600개의 앱을 추가할 수 있지만 해당 수는 지원되지 않습니다.
조건부 액세스 가상 사용자
조건부 액세스 정책을 구성하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 액세스되는 리소스의 민감도에 따라 정책을 구성하는 것입니다. 실제로 이 방법은 다양한 사용자의 리소스에 대한 액세스를 보호하는 방식으로 구현하기가 어려울 수 있습니다.
예를 들어 게스트와 직원이 모두 액세스해야 하는 중요한 리소스에 액세스하기 위해 알려진 사용자와 알려진 디바이스가 필요한 조건부 액세스 정책을 정의할 수 있습니다. 게스트가 관리되는 디바이스에서 액세스를 시도하는 경우 액세스 요청이 작동하지 않습니다. 두 요구 사항을 모두 충족하도록 조건부 액세스 정책을 조정해야 하며, 이로 인해 일반적으로 보안이 떨어지는 요구 사항을 충족하는 정책이 발생합니다.
또 다른 방법은 사용자가 조직에 있는 위치에 따라 액세스 정책을 정의하려고 시도하는 것입니다. 이 방법을 사용하면 많은 조건부 액세스 정책이 발생할 수 있으며 관리가 불가능할 수 있습니다.
더 나은 방법은 일반적인 액세스 요구 사항과 관련된 정책을 구성하고 동일한 요구 사항이 있는 사용자 그룹에 대한 가상 사용자에 액세스 요구 사항 집합을 번들로 묶는 것입니다. 가상 사용자는 일반적인 엔터프라이즈 특성, 책임, 경험, 목표 및 액세스를 공유하는 ID 형식입니다.
엔터프라이즈 자산 및 리소스가 다양한 가상 사용자에 의해 액세스되는 방식을 이해하는 것은 포괄적인 제로 트러스트 전략을 개발하는 데 필수적입니다.
Microsoft에서 제안된 조건부 액세스 페르소나 중 일부는 다음과 같습니다.
또한 다른 가상 사용자 그룹에 속하지 않는 ID에 대해 별도의 가상 사용자를 정의하는 것이 좋습니다. 이를 전역 가상 사용자라고 합니다. Global은 가상 사용자 그룹에 없는 ID에 대한 정책과 모든 가상 사용자에 적용해야 하는 정책을 적용하기 위한 것입니다.
다음 섹션에서는 몇 가지 권장 가상 사용자를 설명합니다.
전역
Global은 본질적으로 일반적인 정책의 가상 사용자/자리 표시자입니다. 모든 가상 사용자에 적용되거나 하나의 특정 가상 사용자에 적용되지 않는 정책을 정의하는 데 사용됩니다. 다른 가상 사용자가 다루지 않는 정책에 사용합니다. 모든 관련 시나리오를 보호하려면 이 가상 사용자가 필요합니다.
예를 들어 하나의 정책을 사용하여 모든 사용자에 대한 레거시 인증을 차단한다고 가정합니다. 다양한 가상 사용자에 대해 다를 수 있는 레거시 정책 그룹을 사용하는 대신 전역 정책으로 만들 수 있습니다.
또 다른 예: 특정 애플리케이션에서 지정된 계정 또는 사용자를 차단하려는 경우 사용자 또는 계정이 가상 사용자의 일부가 아닙니다. 예를 들어 Microsoft Entra 테넌트에서 클라우드 ID를 만드는 경우 이 ID는 Microsoft Entra 역할이 할당되지 않으므로 다른 가상 사용자의 일부가 아닙니다. 여전히 ID가 Office 365 서비스에 액세스하지 못하도록 차단할 수 있습니다.
가상 사용자가 다루지 않는 ID의 모든 액세스를 차단할 수 있습니다. 또는 다단계 인증을 적용하려고 할 수도 있습니다.
관리자
이 컨텍스트에서 관리자는 Microsoft Entra ID 또는 기타 Microsoft 365 관리자 역할(예: Cloud Apps용 Microsoft Defender, Exchange, 엔드포인트용 Defender 또는 준수 관리자)을 포함하는 비 게스트 ID, 클라우드 또는 동기화된 ID입니다. 이러한 역할이 있는 게스트는 다른 가상 사용자로 처리되므로 게스트는 이 가상 사용자에서 제외됩니다.
일부 회사에는 이 가상 사용자가 기반으로 하는 중요한 관리자 역할에 대한 별도의 계정이 있습니다. 관리자는 PAW(Privileged Access Workstation)에서 이러한 중요한 계정을 최적으로 사용합니다. 그러나 관리자 계정이 표준 워크스테이션에서 사용되는 경우가 많으며, 여기서 사용자는 한 디바이스의 계정 간에 전환합니다.
별도의 계정을 사용하는 대신 클라우드 관리자 역할의 민감도를 기준으로 구분하고 덜 중요한 Azure 역할을 내부 가상 사용자에 할당할 수 있습니다. 그런 다음 JIT(Just-In-Time) 권한 상승을 대신 사용할 수 있습니다. 이 경우 사용자는 각 가상 사용자에 대해 하나씩 두 개의 조건부 액세스 정책 집합의 대상이 지정됩니다. PAW를 사용하는 경우 관리자가 PAW에서만 허용되도록 조건부 액세스에서 디바이스 필터를 사용하여 액세스를 제한하는 정책을 도입할 수도 있습니다.
개발자
개발자 페르소나에는 고유한 요구 사항이 있는 사용자가 포함되어 있습니다. Microsoft Entra ID와 동기화되는 Active Directory 계정을 기반으로 하지만 Azure DevOps, CI/CD 파이프라인, 디바이스 코드 흐름 및 GitHub와 같은 서비스에 대한 특별한 액세스 권한이 필요합니다. 개발자 페르소나는 내부 및 외부로 간주되는 다른 사용자로 간주되는 사용자를 포함할 수 있지만 사용자는 가상 사용자 중 하나에만 있어야 합니다.
내부
내부는 Active Directory 계정이 Microsoft Entra ID와 동기화된 모든 사용자, 회사의 직원 및 표준 최종 사용자 역할로 작업하는 모든 사용자를 포함합니다. 개발자인 내부 사용자를 개발자 페르소나에 추가하는 것이 좋습니다.
외부
이 가상 사용자는 Active Directory 계정이 Microsoft Entra ID와 동기화된 모든 외부 컨설턴트를 보유합니다. 개발자인 외부 사용자를 개발자 페르소나에 추가하는 것이 좋습니다.
게스트
게스트는 고객 테넌트에 초대된 Microsoft Entra 게스트 계정이 있는 모든 사용자를 보유합니다.
GuestAdmins
GuestAdmins 페르소나는 이전에 언급한 관리자 역할이 할당된 Microsoft Entra 게스트 계정이 있는 모든 사용자를 보유합니다.
Microsoft365ServiceAccounts
이 가상 사용자는 관리 서비스 ID 사용과 같이 요구 사항을 충족하는 다른 솔루션이 없는 경우 Microsoft 365 서비스에 액세스하는 데 사용되는 클라우드(Microsoft Entra ID) 사용자 기반 서비스 계정을 포함합니다.
AzureServiceAccounts
이 가상 사용자는 관리 서비스 ID 사용과 같이 요구 사항을 충족하는 다른 솔루션이 없는 경우 Azure(IaaS/PaaS) 서비스에 액세스하는 데 사용되는 클라우드(Microsoft Entra ID) 사용자 기반 서비스 계정을 포함합니다.
CorpServiceAccounts
이 가상 사용자는 다음과 같은 모든 특성을 가진 사용자 기반 서비스 계정을 포함합니다.
- 온-프레미스 Active Directory에서 시작됩니다.
- 온-프레미스 또는 Azure와 같은 다른(클라우드) 데이터 센터의 IaaS 기반 가상 머신에서 사용됩니다.
- Azure 또는 Microsoft 365 서비스에 액세스하는 Microsoft Entra 인스턴스와 동기화됩니다.
이 시나리오는 피해야 합니다.
WorkloadIdentities
이 가상 사용자는 Microsoft Entra 서비스 주체 및 관리 ID와 같은 컴퓨터 ID를 포함합니다. 이제 조건부 액세스는 이러한 계정에서 리소스에 대한 액세스를 보호할 수 있도록 지원하며, 사용 가능한 조건 및 권한 부여 컨트롤과 관련하여 몇 가지 제한 사항이 있습니다.
템플릿 카드 액세스
액세스 템플릿 카드를 사용하여 각 가상 사용자의 특성을 정의하는 것이 좋습니다. 예제는 다음과 같습니다.
각 가상 사용자의 템플릿 카드는 각 가상 사용자에 대한 특정 조건부 액세스 정책을 만들기 위한 입력을 제공합니다.
조건부 액세스 지침
생성된 가상 사용자를 기반으로 정책을 그룹화하기 위한 구조적 접근 방식을 포함하는 조건부 액세스 프레임워크 검토합니다.
참여자
이 문서는 Microsoft에서 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.
주 작성자:
- 클라우스 제스퍼슨 | 보안 주체 컨설턴트 ID&Sec
공용이 아닌 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- 학습 경로: ID 및 액세스 구현 및 관리
- 조건부 액세스란?
- 일반적인 조건부 액세스 정책
관련 리소스
- 조건부 액세스 개요
- 조건부 액세스 디자인 원칙 및 종속성
- 조건부 액세스 프레임워크 및 정책