Microsoft 365/Intune

Intune. App control for business (aka. WDAC) 를 통한 앱 실행 차단 정책 배포

Pepuri 2026. 4. 18. 20:05

시작하기 전에

3rd Party 매체제어 또는 DLP 솔루션에서는 프로그램 실행 차단 기능을 제공하는 경우가 많습니다.

최근에는 AI에 문의하면 각 기능이 어떤 로직으로 동작하는지 파악하는 것도 크게 어렵지 않습니다.
제가 확인했을 당시에는 Windows Native 기능으로 아래 세 가지가 대표적으로 안내되었습니다.

IFEO (Image File Execution Options)
AppLocker
WDAC (Windows Defender Application Control)

이 중 WDAC는 현재 App Control for Business라는 명칭으로 변경되어 사용되고 있습니다.

오늘은 Intune을 통해 App Control for Business 정책을 배포하는 과정을 정리해보겠습니다.

1. App Control for Business(WDAC)란?

App Control for Business는 여전히 현업에서는 WDAC라는 표현으로 많이 불립니다.

그리고 AppLocker와 자주 비교되는데, 주요 차이는 아래와 같습니다.

App Control for Business vs AppLocker

항목	App Control for Business (WDAC)	AppLocker
도입 시기	Windows 10부터	Windows 7부터
동작 계층	커널 / 부트 단계	유저 모드
우회 난이도	매우 높음	상대적으로 낮음
제어 대상	EXE, DLL, 스크립트, 드라이버 등	EXE, DLL, 스크립트 등
신뢰 기준	서명, 해시, 경로, ISG 등	서명, 해시, 경로
Managed Installer	✅ 지원	❌ 미지원
ISG	✅ 지원	❌ 미지원
관리 도구	Intune, SCCM, PowerShell 등	GPO 중심
Microsoft 권장	✅ 신규 도입 1순위	보조 용도

핵심 차이

AppLocker가 User Mode 정책이라면,

WDAC는 Code Integrity 기반 Kernel 수준 제어를 지원한다라는 점이 가장 큰 차이입니다.

2. 정책 생성

WDAC은 우선 XML 형식 정책을 생성해야 합니다.

Microsoft에서 제공하는 아래 도구를 사용합니다.

App Control Policy Wizard 설치

Microsoft App Control Wizard

WDAC은 우선 XML 형식으로 정책을 생성해야 하며, 아래의 사이트에 접속하여 App Control Policy Wizard를 설치합니다.

Microsoft App Control Wizard

Policy Creator

운영은 Base Policy 배포 → Supplemental Policy로 보완하는 흐름으로 진행됩니다. 이때 Supplemental Policy는 허용(Allow) 규칙 추가만 가능하며, Base Policy에서 이미 차단한 항목을 풀거나 새로운 차단 규칙을 더하지는 못합니다.

운영 구조

운영은 보통 아래 흐름으로 갑니다.

Base Policy 배포
↓
Supplemental Policy로 예외 허용 추가

참고

Supplemental Policy 특징

Allow 규칙 추가 가능
기존 Block 해제 불가
새로운 Deny 추가 불가

즉,

차단(Deny)은 Base Policy에서 설계해야 합니다.

이번 글에서는 Supplement Policy 배포에 대해서 다루지 않습니다.

2.1 기본 템플릿 3종

기본적으로 아래 3가지 템플릿을 제공합니다.

템플릿	허용 범위	보안	유연성
DefaultWindows	Windows 필수 바이너리만	🔒🔒🔒	낮음
AllowMicrosoft	+ 모든 MS 서명 앱	🔒🔒	중간
SignedAndReputable (ISG)	+ 평판 좋은 타사 앱	🔒	높음

세 템플릿은 왼쪽(DefaultWindows)으로 갈수록 엄격하고, 오른쪽(SignedAndReputable)으로 갈수록 유연해지는 스펙트럼으로 이해하시면 됩니다. 조직의 보안 요구 수준과 업무 유연성 사이에서 균형점을 선택하면 됩니다.

엄격함
DefaultWindows
↓
AllowMicrosoft
↓
SignedAndReputable
유연함

3. Default Windows Mode 테스트

Default Windows Mode 적용

Audit Mode Disable

동작 확인을 위해 Audit Mode는 Disable.

우선 Next

정책 생성

XML 생성 완료

4. 정책 배포

Intune Admin Center

Endpoint Security → App Control for Business

정책 생성 후

이름 지정

XML Upload

대상 할당 > 정책 생성까지 진행

정책 적용 여부 확인

정책 파일 확인 경로:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

적용 전/후 비교 가능합니다.

테스트

Chrome 실행

결과:

차단됨

PowerShell로 정책 조회

CiTool.exe -lp

Powershell 명령어로도 적용된 Policy 확인 가능.

5. 실무 정책 설계 방향

실무적으로 기업 업무 환경에서는 AllowMicrosoft 또는 SignedAndReputable 을 Base Policy로 출발한 뒤, LOB 앱에 대한 Allow 규칙과 위험 바이너리에 대한 Deny 규칙을 조직 상황에 맞게 설계·보완하는 방향으로 운영하는 것이 일반적입니다.

DefaultWindows는 이론상 가장 안전하지만, 일반 사무 환경에서는 예외 처리 부담이 지나치게 커서 규제 산업·고정 업무 단말 등 한정된 시나리오에 주로 적용됩니다.

5.1 AllowMicrosoft 정책 설계

템플릿 생성

Allow Microsoft Mode 선택

Chrome 차단 확인

기본 상태에서는 Chrome 실행 차단.

이벤트 로그 확인

참고로 이벤트 로그에서도 기록을 확인할 수 있습니다.

Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational

Chrome.exe 파일이 적용된 Policy ID에서 요구하는 조건에 충족하지 못해서 차단되었다는 메시지를 확인할 수 있었습니다.

본격적인 화이트리스트 운영을 위해서는 템플릿 자체는 변경하지 않고, 필요한 예외 경로만 추가하는 방식으로 정책을 설계했습니다. 아래는 실제로 추가한 예외 경로 예시입니다.

화이트리스트 경로 예외 추가

Add Custom

경로별로 일일이 규칙을 만드는 대신, 주요 예외 경로는 와일드카드(*)를 활용해 포괄적으로 등록했습니다.

이렇게 하면 하위 폴더나 신규 파일이 추가되더라도 정책을 매번 수정할 필요가 없어 유지보수 부담을 크게 줄일 수 있습니다. 다만 와일드카드 범위가 지나치게 넓으면 악성 코드 우회 지점이 될 수 있으므로, 꼭 필요한 최소 범위로 한정하는 것이 원칙입니다.

예시

아래와 같이 Allow 규칙 완성 후 정책 배포

결과

아래와 같이 Chrome은 실행되는 것을 확인할 수 있습니다.

허용 경로 외의 파일은 모두 차단됩니다. 예를 들어 Chrome 설치 파일을 바탕화면에서 실행하면 다음과 같이 차단됩니다. 이를 통해 사용자의 임의 앱 설치를 억제할 수 있으며, 필요 시 Downloads 등 특정 경로를 Allow 규칙에 추가해 설치를 허용할 수 있습니다.

정책에 의해 차단됨 확인

의미

이 구조는 다음과 같은 효과를 가집니다.

임의 앱 설치 억제
승인 경로만 실행 허용

5.2 SignedAndReputable 정책 설계

이번에는 마지막으로 Signed and Reputable Mode로 진행해보겠습니다.

템플릿 선택

Signed and Reputable Mode

정책 적용 확인

이벤트 로그 확인.

Chrome 실행 테스트

정상 실행.

ISG 평판 기반 허용으로 판단.

6. ISG(Intelligent Security Graph)

참고로 표시된 ISG는 Microsoft가 가진 전 세계 보안 신호를 참고해서, “이 앱을 믿어도 되는지” 판단하는 평판 기반 허용 장치입니다.

ISG(Intelligent Security Graph)를 사용하여 평판 좋은 앱에 권한 부여 | Microsoft Learn

기존에 화이트리스트 기반 정책을 운영해본 경험이 없는 기업이라면, 이 템플릿으로 출발하는 것이 가장 현실적입니다.

대부분의 IT 환경에서는 "기본은 폭넓게 허용하되, 문제 있는 특정 앱만 Block으로 걸러내는" 방식으로 운영되는데, 이 흐름에 가장 잘 맞는 것이 바로 SignedAndReputable 모드입니다.

SignedAndReputable 설계 흐름을 정리하면 다음과 같습니다.

7. SignedAndReputable 운영 설계 흐름

Step 1

SignedAndReputable Base Policy

Step 2

Managed Installer 활성화

(Intune 배포 앱 자동 신뢰)

Step 3

주요 경로 Allow

Step 4

특정 위험 앱 Deny

예시: Winrar

결과

Chrome → Allow

WinRAR → Deny

중요

Deny는 Allow보다 우선합니다.

장치가 온보딩되어 있다면, Advanced hunting을 통해서 모니터링할 수 있습니다.

DeviceEvents
| where ActionType in ("AppControlCodeIntegrityPolicyAudited", 
                        "AppControlCodeIntegrityPolicyBlocked")
| summarize 
    AuditCount = countif(ActionType endswith "Audited"),
    BlockCount = countif(ActionType endswith "Blocked"),
    LastSeen = max(Timestamp)
    by DeviceName, FileName, FolderPath
| sort by AuditCount + BlockCount desc

개인적으로는

SignedAndReputable + 주요 실행 경로 Allow + 특정 위험 앱 Deny

조합이 가장 현실적인 출발점이라고 생각합니다.

저작자표시 비영리 변경금지 (새창열림)