- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 WDAC(App Control for Business) 코드 무결성 정책을 적용한 뒤 정상 프로그램까지 실행이 막히는 상황에서, 원인을 빠르게 진단하고 안전하게 정책을 해제하거나 예외를 허용하여 업무 중단을 최소화하는 실무 절차를 정리하는 것이다.
1. WDAC로 앱이 실행 불가가 되는 대표 증상과 핵심 원인
WDAC는 “허용된 코드만 실행”하도록 강제하는 방식이라 정책 설계가 조금만 보수적으로 적용되어도 기존에 잘 되던 설치형 앱, 포터블 앱, 사내 배포 툴, 자동화 스크립트, 플러그인 DLL까지 한꺼번에 차단되는 일이 흔하다.
| 증상 | 현장에서 자주 보는 징후 | 가능성이 큰 원인 | 우선 조치 |
|---|---|---|---|
| EXE 실행 시 아무 반응 없음 | 창이 뜨지 않거나 즉시 종료 | 사용자 모드 실행 파일이 WDAC 정책에 미포함 | 이벤트 로그 3077/3089 확인 |
| 관리자 권한으로도 실행 불가 | UAC 승인 후에도 차단 | 관리자 권한은 우회 수단이 아님 | 정책 모드(Audit/Enforce) 확인 |
| 드라이버/보안툴 설치 실패 | 부팅 시 장치 오류, 설치 프로그램 중단 | 커널 모드(드라이버) 규칙 위반 | Boot Audit on Failure 여부 확인 |
| 사내 배포 스크립트/자동화 도구 차단 | PowerShell, Python 실행 흐름 중단 | 스크립트/해시 규칙 미설계, 서명 미적용 | 서명 기반 예외 또는 관리형 설치자 설계 |
주의 : WDAC는 “정책을 적용한 순간부터” 실행 허용 기준이 바뀌는 구조이다. 단순히 파일을 다른 폴더로 옮기거나 관리자 권한으로 실행하는 방식으로 해결되지 않는 경우가 대부분이다.
2. 먼저 해야 하는 진단: 어떤 파일이 어떤 정책에 의해 막혔는지 확인
2.1 Code Integrity 이벤트 로그에서 차단 근거 찾기
차단 원인은 화면 메시지보다 이벤트 로그에 더 정확히 남는다. 다음 경로에서 이벤트를 확인해야 한다.
이벤트 뷰어 → 응용 프로그램 및 서비스 로그 → Microsoft → Windows → CodeIntegrity → Operational
현장에서 가장 유용한 이벤트는 다음 두 가지이다.
- 이벤트 ID 3077: 실제 차단(Enforced) 상황의 대표 차단 이벤트이다.
- 이벤트 ID 3089: 차단된 파일의 서명(퍼블리셔/인증서 체인/서명 개수 등) 정보를 제공한다.
2.2 차단 원인별로 해법이 달라지는 지점
로그에서 다음 중 무엇에 가까운지 빠르게 분류해야 한다.
- 서명된 상용 소프트웨어인데 막힘: 퍼블리셔(Publisher) 규칙 누락 가능성이 크다.
- 무서명(Unsigned) 내부 도구가 막힘: 해시(Hash) 규칙 또는 내부 서명 적용이 필요하다.
- DLL/플러그인만 막힘: 실행 파일은 허용됐지만 로드되는 구성요소가 정책에 포함되지 않았을 수 있다.
- 드라이버가 막힘: 사용자 모드와 별개로 커널 모드 규칙 및 드라이버 차단 규칙 영향이 크다.
주의 : “정상 EXE만 허용하면 끝”이라고 가정하면 실패하는 경우가 많다. WDAC는 실행 파일뿐 아니라 로드되는 DLL, MSI, 드라이버 등 연쇄 요소가 정책을 통과해야 정상 동작한다.
3. 가장 빠른 응급 복구: 정책을 ‘해제’하거나 ‘감사(Audit) 모드’로 전환
업무가 멈춘 상태라면 예외 정책 설계 전에 “일단 실행은 되게” 만드는 응급 복구가 필요하다. 다만 보안 정책의 목적을 훼손하지 않도록, 조직 배포 환경(Intune/GPO/MDM)에서 원인을 제거하는 순서가 바람직하다.
3.1 배포 경로부터 끊기: Intune/GPO/MDM 정책 배포 중지
WDAC는 파일로 남는 정책이므로, 중앙에서 계속 재배포되는 상태면 로컬에서 삭제해도 다시 살아난다. 현장에서는 다음 순서로 확인하는 경우가 많다.
- Intune: App Control for Business 정책 프로필이 할당되어 있는지 확인한다.
- GPO/로컬 정책: Device Guard/WDAC 관련 정책이 적용되어 있는지 확인한다.
- 보안 솔루션/스크립트 배포: CIP 파일을 복사하는 자동화가 있는지 확인한다.
3.2 로컬에서 현재 활성 정책 확인(CiTool 사용)
관리자 권한 PowerShell 또는 명령 프롬프트에서 정책 목록을 확인한다. Windows 버전에 따라 CiTool 사용 가능 여부가 달라질 수 있으나, 현장 점검에는 매우 유용하다.
CiTool.exe -lp목록에서 정책 GUID(PolicyId)를 확보하면, 제거 또는 예외 정책 설계의 기준점이 된다.
3.3 (가능한 경우) CiTool로 정책 제거
응급 복구가 목적이라면 CiTool로 정책을 제거하고 재부팅하는 방식이 가장 단순하다.
CiTool.exe -rp "{정책GUID}"제거 후 반드시 재부팅하여 Code Integrity 엔진이 정책을 다시 로드하도록 해야 한다.
주의 : 조직에서 “서명된 정책”을 배포하는 구조라면 단순 제거가 허용되지 않거나 즉시 재배포될 수 있다. 이 경우 중앙 배포를 중지한 뒤 로컬 조치를 해야 한다.
3.4 수동 삭제 복구(최후 수단): CIP/SiPolicy 파일 제거
정책이 파일로 존재하는 경우 다음 경로에 남아 있을 수 있다. 단, 이 방법은 운영 표준 절차가 아니며 관리자가 구조를 이해한 상태에서만 수행해야 한다.
| 구분 | 경로 | 파일 예시 | 의미 |
|---|---|---|---|
| OS 볼륨 | C:\Windows\System32\CodeIntegrity\CiPolicies\Active\ | {PolicyId}.cip | 활성 WDAC 정책 파일 |
| EFI 시스템 파티션 | \Microsoft\Boot\CiPolicies\Active\ | {PolicyId}.cip | 부팅 단계에서 참조되는 정책 파일 |
| 단일 정책 형식(추가 위치) | C:\Windows\System32\CodeIntegrity\ | SiPolicy.p7b | 레거시 형식 정책 파일 |
| 단일 정책 형식(추가 위치) | \Microsoft\Boot\ | SiPolicy.p7b | EFI 내 레거시 형식 정책 |
EFI 파티션은 기본적으로 드라이브 문자가 없으므로, 필요 시 마운트 후 파일을 확인한다.
mountvol S: /S dir S:\Microsoft\Boot\CiPolicies\Active dir C:\Windows\System32\CodeIntegrity\CiPolicies\Active정책 파일 삭제 후 재부팅한다.
주의 : EFI 파티션 작업은 실수 시 부팅 장애로 이어질 수 있다. 사내 표준 절차가 없거나 BitLocker/보안 부팅 구성 이해가 부족하면 이 방법을 선택하지 않는 것이 안전하다.
4. “해제”가 아니라 “허용”이 목표일 때: 예외(Allow) 정책을 올바르게 추가하는 방법
보안 목적상 WDAC를 유지해야 한다면, 정책 자체를 없애는 대신 “막힌 앱만 합법적으로 허용”하는 방향이 정석이다. 이때 핵심은 감사(Audit) 모드에서 충분히 로그를 수집한 뒤, 보완 정책(보조 정책, Supplemental Policy)을 만들어 운영 모드(Enforced)로 전환하는 방식이다.
4.1 감사(Audit) 모드로 전환 후 로그 수집
감사 모드에서는 앱은 실행되지만 “원래라면 막혔을 파일”이 이벤트로 남는다. 즉, 운영 중단 없이 필요한 허용 목록을 수집할 수 있다.
- 감사 모드로 정책을 설계하거나, 기존 정책에 감사 옵션을 적용한다.
- 업무 시나리오를 실제로 실행해 누락 항목을 의도적으로 발생시킨다.
- CodeIntegrity 이벤트(특히 3077/3089, 또는 감사 관련 이벤트)를 기준으로 허용 규칙을 만든다.
4.2 허용 규칙은 가능한 한 “서명 기반”으로 구성
현장에서 장기 운영 안정성을 생각하면, 허용 규칙 우선순위는 일반적으로 다음 순서가 된다.
- 퍼블리셔(서명자) 규칙: 업데이트에 강하고 관리가 쉽다.
- 파일 경로 규칙: 설치 경로가 고정된 환경에서 유용하나 오남용 시 위험하다.
- 해시 규칙: 가장 확실하지만 업데이트 때마다 규칙을 재생성해야 한다.
주의 : “폴더 전체 허용”은 단기 복구에는 편하지만 보안 모델을 약화시키기 쉽다. 예외를 넓힐수록 WDAC 도입 효과가 급격히 떨어진다.
4.3 차단 이벤트를 기반으로 보조 정책을 생성하는 실무 흐름
현장에서 많이 쓰는 흐름은 다음과 같다.
- 차단 또는 감사 이벤트에서 대상 파일 경로와 서명 정보를 확보한다.
- 퍼블리셔 규칙으로 허용이 가능한지 판단한다.
- 가능하면 보조 정책(Supplemental Policy)로 “허용만 확장”한다.
- 보조 정책 적용 후, 다시 감사→운영 순으로 안정화한다.
WDAC 정책을 PowerShell로 다루는 대표 명령 흐름 예시는 다음과 같다. 조직의 표준 템플릿과 Windows 빌드에 따라 옵션은 달라질 수 있으므로, 명령을 그대로 복사 적용하기보다 구조를 이해하는 용도로 사용해야 한다.
# 1) 기준 정책(또는 보조 정책) XML 생성 예시(개념용) New-CIPolicy -Level Publisher -FilePath "C:\WDAC\Supplemental.xml" -UserPEs -ScanPath "C:\Program Files\대상앱" # 2) 규칙 옵션 적용 예시(환경에 맞게 선택) Set-RuleOption -FilePath "C:\WDAC\Supplemental.xml" -Option 3 # 예: Audit 관련 옵션(정책 설계에 따라 다름) # 3) XML을 바이너리 정책(CIP)로 변환 ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\Supplemental.xml" -BinaryFilePath "C:\WDAC\Supplemental.cip"보조 정책은 기본 정책이 신뢰하는 범위를 “추가로 허용”하는 용도이며, 기본 정책의 차단 방침을 뒤집는 구조가 아니다. 따라서 설계 시 “기본 정책이 무엇을 허용하는지”를 먼저 파악해야 한다.
5. 실무자가 자주 놓치는 포인트 10가지
5.1 사용자 모드만 생각하고 DLL 로드를 놓치는 문제
업데이트 후 갑자기 특정 기능만 안 되는 케이스는 EXE가 아니라 DLL/플러그인이 막힌 경우가 많다. CodeIntegrity 로그에서 “같은 시간대에 반복 등장하는 파일”을 함께 확인해야 한다.
5.2 설치 프로그램(MSI/Setup.exe)과 실행 파일이 다른 서명을 가질 수 있음
설치 파일로 퍼블리셔 규칙을 만들었는데 실제 실행 파일이 다른 서명 체인을 가지면 런타임에서 막힌다. 3089 이벤트로 “실제 막힌 파일의 서명”을 기준으로 규칙을 잡아야 한다.
5.3 포터블 앱/사내용 툴은 무서명 비율이 높음
무서명 파일을 해시로 풀면 운영은 되지만 유지보수 비용이 급증한다. 내부 코드 서명 체계(사내 인증서 기반)를 도입하는 것이 장기적으로 유리하다.
5.4 중앙 배포가 살아 있으면 로컬 해제가 무의미함
삭제 후 몇 분 뒤 다시 막히면 재배포가 원인일 가능성이 높다. MDM/Intune/GPO 할당부터 끊는 것이 우선이다.
5.5 테스트 없이 바로 Enforced로 가면 장애가 발생하기 쉬움
감사 모드로 업무 시나리오를 충분히 돌려 로그 기반으로 예외를 설계한 뒤 운영 모드로 전환해야 한다.
5.6 보안 부팅, BitLocker, EFI 경로 작업의 위험성
EFI 파티션 내 정책 파일 조작은 최후 수단이다. 사전 복구 계획 없이 접근하면 부팅 문제로 장애 범위가 확대될 수 있다.
5.7 “전체 디스크 허용”, “사용자 다운로드 폴더 허용” 같은 과도한 예외
이런 예외는 악성코드 실행 경로를 넓히는 효과가 있어 WDAC 도입 취지와 정면으로 충돌한다.
5.8 드라이버 차단은 사용자 모드 예외로 해결되지 않음
커널 모드 규칙과 드라이버 차단 규칙은 별도로 다뤄야 하며, 하드웨어 제조사 드라이버는 서명 기반 허용이 필수에 가깝다.
5.9 동일 앱이라도 업데이트로 서명 체인이 바뀌는 경우가 있음
퍼블리셔 규칙을 너무 좁게 잡으면 업데이트 때마다 장애가 반복된다. 퍼블리셔/발급자 CA 범위를 적절히 설계해야 한다.
5.10 예외 정책 적용 후 검증 절차 미흡
예외를 추가했다면 반드시 “재부팅 후”, “일반 사용자 계정으로”, “업무 시나리오 전체”를 재검증해야 한다. WDAC는 부팅 및 초기 로딩 단계에서만 반영되는 옵션도 존재한다.
6. 현장 점검용 체크리스트
| 체크 항목 | 확인 방법 | 정상/이상 판단 | 조치 방향 |
|---|---|---|---|
| 차단 이벤트 존재 여부 | CodeIntegrity Operational 로그 확인 | 3077/3089 다수 발생 시 WDAC 영향 가능 | 차단 파일 목록 정리 |
| 활성 정책 파일 존재 | C:\Windows\System32\CodeIntegrity\CiPolicies\Active 확인 | .cip 파일 존재 시 정책 활성 가능 | 배포원 확인 후 해제/수정 |
| 정책 재배포 여부 | 삭제 후 재발생 시간 관찰 | 수 분 내 재발생 시 중앙 배포 가능성 높음 | Intune/GPO 할당 중지 |
| 서명 기반 예외 가능 여부 | 3089에서 서명 정보 확인 | 신뢰 가능한 퍼블리셔이면 서명 규칙 권장 | 보조 정책으로 허용 확장 |
| 무서명 파일 비중 | 3089 TotalSignatureCount 확인 | 0이면 무서명 | 해시/내부서명 중 선택 |
FAQ
WDAC 정책을 삭제했는데도 계속 앱이 막히는 이유는 무엇인가?
대부분 중앙 배포(Intune, MDM, GPO, 보안 솔루션 스크립트)가 살아 있어 정책이 재적용되는 상황이다. 배포 원인을 먼저 끊고, 그 다음 로컬 정책 파일을 정리해야 재발이 멈춘다.
감사(Audit) 모드는 안전한가?
감사 모드는 실행은 허용하되 “원래라면 차단될 것”을 기록하는 운영 방식이다. 신규 정책을 즉시 운영 모드로 올리기 전에 업무 영향도를 파악하는 데 유리하다. 다만 감사 모드는 차단 효과가 없으므로 보안 목표가 강제 차단이라면 검증 기간을 명확히 두고 운영 모드로 전환해야 한다.
무서명 사내 도구를 가장 현실적으로 허용하는 방법은 무엇인가?
단기적으로는 해시 규칙이 가장 빠르지만 업데이트 때마다 정책 갱신이 필요하다. 장기적으로는 내부 코드 서명 체계를 도입해 퍼블리셔 규칙 기반으로 전환하는 방식이 유지보수 비용을 크게 줄인다.
특정 앱만 허용했는데 업데이트 후 다시 막히는 이유는 무엇인가?
업데이트로 실행 파일 또는 구성요소(DLL)의 서명 체인이나 파일 해시가 바뀌었기 때문이다. 퍼블리셔 규칙을 너무 좁게 잡았거나 해시 규칙을 사용한 경우 재발이 쉽다. 3089 이벤트의 서명 정보를 기준으로 규칙 범위를 재설계해야 한다.
EFI 파티션에서 정책 파일을 지우는 방법을 써도 되는가?
업무가 완전히 중단되고, 중앙 배포도 끊었으며, CiTool 제거도 불가한 상황에서만 최후 수단으로 고려하는 것이 일반적이다. EFI 파티션 조작은 부팅 장애 위험이 있으므로 사내 표준 절차와 복구 계획이 없는 경우 권장되지 않는다.