조건부 액세스 프레임워크 및 정책
이 문서에서는 조건부 액세스 제로 트러스트 아키텍처에 설명된 것과 같이 가상 사용자 기반 조건부 액세스 아키텍처를 구현하기 위한 프레임워크에 대해 설명합니다. 이 문서에서는 조건부 액세스 정책을 만들고 이름을 지정하는 방법에 대해 자세히 설명합니다. 또한 정책을 만들기 위한 시작점에 대해서도 설명합니다.
명명 표준을 포함하여 여기에 제공된 것과 같은 프레임워크를 사용하지 않으면 시간이 지남에 따라 서로 다른 사용자에 의해 임시로 정책이 생성될 수 있습니다. 그 결과 정책이 겹치는 부분이 발생할 수 있습니다. 정책을 만든 사람이 더 이상 없으면 정책의 목적을 알기도 어려워질 수 있습니다.
구조화된 프레임워크를 따르면 정책을 더 쉽게 파악할 수 있습니다. 또한 모든 시나리오를 보다 쉽게 지원하고 해결 하기 어려운 정책 충돌을 방지할 수 있습니다.
명명 규칙
올바르게 정의된 명명 규칙은 사용자와 동료가 정책의 목적을 이해하는 데 도움이 되며, 이를 통해 정책 관리 및 문제 해결을 더 쉽게 수행할 수 있습니다. 명명 규칙은 정책을 구성하는 데 사용하는 프레임워크에 적합해야 합니다.
권장되는 명명 정책은 가상 사용자, 정책 유형 및 앱을 기반으로 합니다. 다음과 같이 표시됩니다.
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
이 이름의 구성 요소는 다음과 같습니다.
| 명명 구성 요소 | 설명/예제 |
|---|---|
| CA 번호 | 정책 유형 범위 및 순서를 빠르게 식별하는 데 사용됩니다. 예: CA001-CA099. |
| 가상 사용자 | Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| 정책 유형 | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| 앱 | AllApps, O365(모든 Office 365 서비스용), EXO(Exchange Online용). |
| 플랫폼 | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| 제어 권한 부여 | Block, ADHJ, Compliant, Unmanaged(디바이스 상태 조건에 관리되지 않음이 지정된 경우). |
| Description | 정책 목적에 대한 선택적인 설명입니다. |
번호 매기기 체계
쉽게 관리할 수 있도록 번호 매기기 체계가 권장됩니다.
| 가상 사용자 그룹 | 숫자 할당 |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
정책 형식
권장되는 정책 유형은 다음과 같습니다.
| 정책 유형 | 설명/예제 |
|---|---|
| BaseProtection | 각 가상 사용자에는 이 정책 유형으로 지원되는 기준 보호 기능이 있습니다. 관리되는 디바이스 사용자의 경우 일반적으로 알려진 사용자 및 알려진 디바이스입니다. 외부 게스트의 경우 알려진 사용자 및 다단계 인증일 수 있습니다. 기본 보호는 지정된 가상 사용자의 모든 사용자 앱에 대한 기본 정책입니다. 특정 앱에 다른 정책이 있어야 하는 경우 기본 보호 정책에서 해당 앱을 제외하고 해당 앱만 대상으로 하는 명시적 정책을 추가합니다. 예: 내부 기본 보호의 경우 모든 클라우드 앱에 대해 알려진 사용자 및 알려진 디바이스를 필요로 하지만 모든 디바이스에서 웹에서 Outlook을 허용한다고 가정해보세요. 기본 보호 정책에서 Exchange Online을 제외하고 Exchange Online에 대해 별도의 정책을 추가할 수 있습니다. 여기에서는 알려진 디바이스 또는 다단계 인증이 필요합니다. |
| IdentityProtection | 각 가상 사용자에 대해 기본 보호 맨 위에서 ID와 관련된 조건부 액세스 정책을 사용할 수 있습니다. 예: 레거시 인증을 차단하고, 높은 사용자 또는 로그인 위험에 대해 추가 다단계 인증을 필요로 하고, 다단계 인증 등록을 위해 알려진 디바이스를 필요로 합니다. |
| DataProtection | 이 정책 유형은 기본 보호의 추가 레이어로 데이터를 보호하는 델타 정책을 나타냅니다. 예:
|
| AppProtection | 이 정책 유형은 기본 보호에 대한 또 다른 추가 항목입니다. 예제:
|
| AttackSurfaceReduction | 이 정책 유형의 목적은 다양한 공격을 완화하는 것입니다. 예제:
|
| 규정 준수 | 규정 준수 정책을 사용하여 사용자가 고객 서비스에 액세스하는 게스트에 대한 사용 약관을 확인하도록 요구할 수 있습니다. |
앱
다음 표에서는 정책 이름의 앱 구성 요소에 대해 설명합니다.
| 앱 이름 | 설명/예제 |
|---|---|
| AllApps | AllApps는 모든 클라우드 앱이 조건부 액세스 정책의 대상임을 나타냅니다. 조건부 액세스를 지원하는 것과 그렇지 않은 것을 포함하여 모든 엔드포인트가 적용됩니다. 일부 시나리오에서는 모든 앱을 대상으로 지정하는 것이 잘 작동하지 않습니다. 모든 엔드포인트가 정책 범위에 포함되도록 기본 정책에서 모든 앱을 대상으로 지정하는 것이 좋습니다. Microsoft Entra ID에 표시되는 새 앱도 정책을 자동으로 준수합니다. |
| <AppName> | <AppName>은 정책이 적용되는 앱 이름의 자리 표시자입니다. 이름을 너무 길게 만들지 마세요. 이름 예:
|
플랫폼 유형
다음 표에서는 정책 이름의 플랫폼 구성 요소에 대해 설명합니다.
| 플랫폼 유형 | Description |
|---|---|
| AnyPlatform | 이 정책은 모든 플랫폼을 대상으로 합니다. 일반적으로 모든 디바이스를 선택하여 이를 구성합니다. (조건부 액세스 정책에서는 플랫폼 및 디바이스가 모두 사용됩니다.) |
| iOS | 이 정책은 Apple iOS 플랫폼을 대상으로 합니다. |
| Android | 이 정책은 Google Android 플랫폼을 대상으로 합니다. |
| Windows | 이 정책은 Windows 플랫폼을 대상으로 합니다. |
| Linux | 이 정책은 Linux 플랫폼을 대상으로 합니다. |
| WindowsPhone | 이 정책은 Windows Phone 플랫폼을 대상으로 합니다. |
| macOS | 이 정책은 macOS 플랫폼을 대상으로 합니다. |
| iOSAndroid | 이 정책은 iOS 및 Android 플랫폼을 모두 대상으로 합니다. |
| Unknown | 이 정책은 이전에 나열되지 않은 모든 플랫폼을 대상으로 합니다. 일반적으로 모든 디바이스를 포함하고 모든 개별 플랫폼을 제외하여 이를 구성합니다. |
제어 권한 부여 유형
다음 표에서는 정책 이름의 제어 권한 부여 구성 요소에 대해 설명합니다.
| 권한 부여 유형 | 설명/예제 |
|---|---|
| Block | 정책은 로그인을 차단합니다. |
| MFA | 이 정책은 다단계 인증이 필요합니다. |
| 준수 | 이 정책은 디바이스를 Endpoint Manager에서 관리해야 하므로 Endpoint Manager에서 확인된 대로 호환되는 디바이스가 필요합니다. |
| CompliantorAADHJ | 정책에는 규격 디바이스 또는 Microsoft Entra 하이브리드 조인 디바이스가 필요합니다. 표준 회사 컴퓨터가 가입되어 기본 하이브리드 Microsoft Entra ID도 조인됩니다. 공동 관리 또는 Microsoft Entra 가입된 휴대폰 및 Windows 10 컴퓨터는 규격일 수 있습니다. |
| CompliantandAADHJ | 정책에는 규정을 준수하는 디바이스와 Microsoft Entra 하이브리드가 조인되어 있어야 합니다. |
| MFAorCompliant | 이 정책은 호환되는 디바이스 또는 호환되지 않을 경우 다단계 인증이 필요합니다. |
| MFAandCompliant | 이 정책은 호환되는 디바이스 및 다단계 인증이 필요합니다. |
| MFAorAADHJ | 이 정책에는 Microsoft Entra 하이브리드 조인 컴퓨터가 아닌 경우 Microsoft Entra 하이브리드 조인 컴퓨터 또는 다단계 인증이 필요합니다. |
| MFAandAADHJ | 이 정책에는 Microsoft Entra 하이브리드 조인 컴퓨터 및 다단계 인증이 필요합니다. |
| RequireApprovedClient | 정책에는 승인된 클라이언트 앱이 필요합니다. |
| AppProtection | 정책에는 앱 보호가 필요합니다. |
| 비관리형 | 이 정책은 Microsoft Entra ID로 알려지지 않은 디바이스를 대상으로 합니다. 예를 들어 이 권한 부여 유형을 사용하여 모든 디바이스에서 Exchange Online에 대한 액세스를 허용할 수 있습니다. |
명명된 위치
조건부 액세스 정책에 사용할 수 있도록 다음 표준 위치를 정의하는 것이 좋습니다.
- 신뢰할 수 있는 IP/내부 네트워크. 이러한 IP 서브넷은 컴퓨터 시스템 관리, 네트워크 수준 인증 또는 침입 감지와 같이 물리적 액세스 제한 또는 기타 제어가 적용된 위치 및 네트워크를 나타냅니다. 이러한 위치는 더 안전하므로 조건부 액세스 적용이 완화될 수 있습니다. Azure 또는 기타 데이터 센터 위치(IP)를 이 위치에 포함할지 아니면 자체 명명된 위치를 사용할지 여부를 고려합니다.
- Citrix 신뢰 IP. Citrix가 온-프레미스로 있으면 Citrix 세션에서 클라우드 서비스에 연결할 수 있어야 하는 경우 Citrix 팜에 대해 별도의 송신 IPv4 주소를 구성하는 것이 유용할 수 있습니다. 이 경우 필요에 따라 조건부 액세스 정책에서 이러한 위치를 제외할 수 있습니다.
- Zscaler 위치(해당하는 경우). 컴퓨터에 ZPA 에이전트가 설치되어 있고 모든 트래픽을 인터넷으로 또는 Zscaler 클라우드를 통해 전달합니다. 따라서 조건부 액세스에서 Zscaler 소스 IP를 정의하고 모바일 이외 디바이스의 모든 요청이 Zscaler를 통과하도록 요구하는 것이 좋습니다.
- 비즈니스 허용 국가/지역 전 세계에서 직원이 일상적으로 업무를 수행하는 지역을 나타내는 그룹과 다른 위치를 나타내는 그룹의 두 가지 위치 그룹으로 국가/지역을 구분하는 것이 유용할 수 있습니다. 이렇게 하면 조직이 일상적으로 업무를 수행하는 지역 외부에서 발생하는 요청에 추가적인 제어를 적용할 수 있습니다.
- 다단계 인증이 어렵거나 불가능할 수 있는 위치. 일부 시나리오에서는 다단계 인증 요구로 인해 직원의 업무 수행이 어려울 수 있습니다. 예를 들어 직원이 빈번한 다단계 인증 요구에 대응할 수 있는 시간이나 기회가 부족할 수 있습니다. 또는 일부 위치에서는 RF 스크리닝 또는 전기적 간섭으로 인해 모바일 디바이스 사용이 어려울 수 있습니다. 일반적으로 이러한 위치에서는 다른 제어 수단을 사용하거나 사용자를 신뢰할 수 있어야 합니다.
위치 기반 액세스 제어는 요청의 원본 IP에 의존해서 요청 시 사용자의 위치를 확인합니다. 공용 인터넷에서 스푸핑을 수행하는 것이 쉽지 않지만 네트워크 경계로 제공되는 보호는 예전보다 관련성이 낮은 것으로 간주될 수 있습니다. 액세스 조건으로 위치에만 의존하는 것은 권장하지 않습니다. 하지만 비대화형 시나리오에 사용되는 온-프레미스에서 서비스 계정의 액세스를 보호하는 경우와 같이 일부 시나리오에서는 이 기능이 사용할 수 있는 최선의 제어 수단일 수 있습니다.
권장되는 조건부 액세스 정책
권장되는 조건부 액세스 정책이 포함된 스프레드시트가 생성되어 있습니다. 여기에서 스프레드시트를 다운로드할 수 있습니다.
제안된 정책을 시작점으로 사용합니다.
시간이 지남에 따라 비즈니스에 중요한 사용 사례를 수용하기 위해 정책이 변경될 수 있습니다. 다음은 변경이 필요할 수 있는 시나리오의 몇 가지 예입니다.
- 다단계 인증, 앱 보호 및 승인된 클라이언트 앱을 기준으로 관리되지 않는 디바이스를 사용하는 직원에 대해서는 Exchange Online에 대해 읽기 전용 액세스를 구현합니다.
- Azure Information Protection의 향상된 보호 없이는 중요한 정보가 다운로드되지 않도록 정보 보호를 구현합니다.
- 게스트에 의한 복사 및 붙여넣기에 대해 보호를 제공합니다.
여러 미리 보기가 현재 퍼블릭 미리 보기로 제공되므로 제안된 CA(조건부 액세스) 시작 정책 집합에 대한 업데이트가 곧 제공될 예정입니다.
조건부 액세스 지침
이제 조건부 액세스 정책에 대한 시작 설정이 완료되었으므로 제어된 단계별 방식으로 이를 배포해야 합니다. 배포 모델을 사용하는 것이 좋습니다.
한 가지 방법은 다음과 같습니다.
먼저 하나의 가상 사용자 그룹 내에서 적은 수의 사용자에게 정책을 배포하는 것이 좋습니다. 이 배포에는 Persona Ring 0이라는 연결된 Microsoft Entra 그룹을 사용할 수 있습니다. 모든 것이 작동하는지 확인한 후에는 더 많은 구성원이 포함된 가상 사용자 링 1 등으로 그룹 할당을 변경합니다.
그런 다음, 모든 정책이 배포될 때까지 동일한 링 기반 접근 방식에 따라 정책을 사용하도록 설정합니다.
일반적으로 링 0 및 링 1의 구성원은 수동으로 관리합니다. 수백 또는 수천 명의 사용자가 포함된 링 2 또는 3 그룹은 제공된 가상 사용자의 사용자 비율을 기반으로 하는 동적 그룹을 통해 관리할 수 있습니다.
배포 모델의 일부로 링을 사용하는 것은 단순히 초기 배포만을 위한 것이 아닙니다. 새 정책이 필요하거나 기존 정책을 변경해야 할 경우에도 이를 사용할 수 있습니다.
배포가 완료되면 또한 조건부 액세스 원칙에서 설명한 모니터링 제어를 디자인하고 구현해야 합니다.
초기 배포를 자동화하는 것 외에도 CI/CD 파이프라인을 사용하여 정책 변경을 자동화할 수 있습니다. 이 자동화를 위해서는 Microsoft365DSC를 사용할 수 있습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Claus Jespersen | 수석 컨설턴트 ID>초
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
관련 리소스
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기