- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 WDAC(Windows Defender Application Control, 비즈니스용 App Control) 코드 무결성 정책을 적용한 뒤 정상 앱까지 실행이 막힌 상황에서, 원인을 정확히 확인하고 안전하게 차단을 해제하거나 감사(Audit) 모드로 전환하여 업무 중단을 최소화하는 실무 절차를 정리하는 것이다.
1. WDAC 차단 증상과 핵심 원리
WDAC는 “허용 목록 기반 실행 통제”에 가까운 방식으로 동작하며, 정책이 강제(Enforced) 상태이면 정책에 부합하지 않는 실행 파일(EXE)과 DLL, 스크립트, 드라이버 등이 차단될 수 있다. 정책이 조직 배포(그룹 정책, MDM/Intune, 이미지 내장 등)로 적용되면 로컬에서 파일만 삭제해도 재배포로 다시 활성화될 수 있다.
대표 증상은 다음과 같다.
- 특정 EXE 실행 시 아무 반응이 없거나 “조직에서 앱 실행을 차단함” 유형의 메시지가 발생하는 증상이다.
- 관리자 권한으로 실행해도 동일하게 막히는 증상이다.
- 드라이버 기반 앱(보안 모듈, 계측 장비, 일부 VPN/가상화 구성요소)이 먼저 고장 나는 증상이다.
주의 : WDAC는 보안 통제 장치이므로 “무조건 삭제”는 위험하다. 업무 복구가 목적이라면 먼저 감사(Audit) 모드로 전환하여 차단 원인을 로그로 확인한 뒤, 필요한 앱만 허용 규칙을 추가하는 방식이 가장 안전하다.
2. 지금 무엇이 막는지 먼저 확인하는 방법(가장 중요)
2-1. 이벤트 로그에서 차단 원인 확인이다
차단 여부와 어떤 정책이 막았는지는 이벤트 로그로 확인하는 것이 표준이다. 다음 경로에서 확인한다.
- 이벤트 뷰어 → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational이다.
필터링 기준은 다음이 실무적으로 유용하다.
- 강제(Enforced) 차단은 이벤트 ID 3077이 대표적이다.
- 감사(Audit)에서 “차단되었을 것” 기록은 이벤트 ID 3076이 대표적이다.
2-2. PowerShell로 최근 차단 로그만 뽑는 방법이다
GUI가 번거롭다면 관리자 PowerShell에서 다음과 같이 확인한다.
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" ` | Where-Object { $_.Id -in 3076,3077 } ` | Select-Object TimeCreated, Id, Message -First 20메시지에는 대개 다음 정보가 포함된다.
- 차단된 파일 경로이다.
- 적용된 정책 ID(Policy ID) 또는 정책 이름이다.
- 서명 수준 미충족, 정책 위반 등의 사유이다.
3. 해제 전에 반드시 점검해야 할 체크포인트
같은 “해제”라도 적용 경로에 따라 접근 방식이 달라진다. 아래 표를 먼저 체크하는 것이 재발 방지에 도움이 된다.
| 점검 항목 | 확인 방법 | 의미 | 권장 조치 |
|---|---|---|---|
| 조직 정책(Intune/MDM) 배포 여부 | 회사 단말 정책, MDM 등록 상태 확인이다 | 로컬에서 지워도 재배포될 수 있다 | 배포 중지 또는 예외 정책 적용이 우선이다 |
| 그룹 정책(GPO) 배포 여부 | gpresult /h 결과에서 WDAC 관련 설정 확인이다 | 부팅/로그온 시 다시 적용될 수 있다 | GPO에서 정책 제거 후 로컬 정리이다 |
| 정책 강제(Enforced) 여부 | CodeIntegrity 로그 ID 3077 발생 여부이다 | 실제 실행이 차단된 상태이다 | 업무복구는 감사 모드 전환이 우선이다 |
| 단일 정책(SiPolicy.p7b) 사용 여부 | 지정 경로에 SiPolicy.p7b 존재 확인이다 | 구형 배포 방식일 수 있다 | 해당 파일 처리 절차가 별도로 필요하다 |
주의 : 정책이 “배포 시스템에서 계속 내려오는 구조”이면 로컬 조치만으로는 증상이 반복된다. 단말 복구가 급하더라도, 재배포 중지와 로컬 정리는 반드시 함께 진행해야 한다.
4. 가장 안전한 1차 복구: WDAC를 감사(Audit) 모드로 전환이다
업무 중단을 최소화하면서 원인을 잡는 최선의 실무 접근은 “감사 모드로 바꾸고 로그를 수집”하는 방식이다. 감사 모드는 사용자 업무를 살리면서도, 실제로 무엇이 막혔는지(막혔을지)를 추적할 수 있다.
4-1. 정책을 새로 만들어 감사 모드로 전환하는 개념이다
WDAC 정책 XML에서 “감사 모드 옵션”을 켜면 Audit으로 동작한다. 실무에서는 기존 정책을 그대로 두고, 동일 PolicyId로 감사 모드 정책을 재배포하거나, “일시적으로 허용 규칙(Allow *) 중심”으로 바꾼 완화 정책을 배포하여 즉시 복구하는 방식이 사용된다.
주의 : 이 단계는 조직 배포(Intune/GPO) 환경에서 특히 유효하다. 로컬에서 파일만 삭제하면 보안 통제가 깨지고 재배포로 혼란이 커질 수 있다.
5. 정책을 완전히 제거해야 하는 상황에서의 표준 해제 절차이다
테스트 중 잘못 적용했거나 개인 PC에서 오배포한 경우처럼, “정책 자체를 제거”해야 할 때가 있다. 이때는 운영체제 버전과 정책 형식(여러 정책 형식/단일 정책 형식)에 따라 절차가 나뉜다.
5-1. Windows 11에서 CiTool로 정책 제거가 가능한 경우이다
Windows 11(특정 업데이트 이후)에서는 CiTool.exe로 App Control 정책을 제거할 수 있다. 핵심은 “제거할 정책의 PolicyId(GUID)”를 알아야 한다는 점이다. 이 PolicyId는 CodeIntegrity 이벤트 로그 메시지에서 확인하는 것이 일반적이다.
CiTool.exe -rp "{PolicyId GUID}" -json정책이 여러 개라면 정책마다 제거를 반복해야 한다. 제거 후에는 재부팅이 필요할 수 있다.
5-2. 정책 파일을 직접 제거해야 하는 경우(로컬 단독/복구 상황)이다
배포가 중지된 것이 확실하거나, 단독 PC에서 잘못 적용되어 부팅/실행이 막힌 복구 상황에서는 정책 파일을 직접 정리해야 할 수 있다. 일반적으로 정책 파일은 다음 위치 중 하나 또는 둘 다에 존재한다.
| 정책 위치 | 대표 경로 | 대상 파일 | 비고 |
|---|---|---|---|
| OS 볼륨 | C:\Windows\System32\CodeIntegrity\CiPolicies\Active\ | {PolicyId}.cip | 여러 정책 형식에서 사용된다 |
| EFI 시스템 파티션 | <EFI>\Microsoft\Boot\CiPolicies\Active\ | {PolicyId}.cip | 부팅 단계에도 영향 가능하다 |
| 단일 정책 형식(구형) | C:\Windows\System32\CodeIntegrity\ | SIPolicy.p7b | 환경에 따라 존재한다 |
관리자 권한 PowerShell에서 OS 볼륨 정책 파일을 확인하는 예시는 다음과 같다.
dir "C:\Windows\System32\CodeIntegrity\CiPolicies\Active" -ForceEFI 시스템 파티션은 기본적으로 드라이브 문자가 없으므로, 임시로 마운트하여 확인하는 방식이 실무적이다.
mountvol S: /S dir "S:\Microsoft\Boot\CiPolicies\Active" -Force정책 파일을 제거해야 한다면, 배포 중지가 선행된 상태에서 해당 {PolicyId}.cip 파일을 정리한다. 구형 단일 정책 형식이라면 SIPolicy.p7b도 함께 점검한다.
주의 : EFI 파티션의 정책 파일을 임의 삭제하면 보안 구성이 의도치 않게 변할 수 있다. 기업 단말이라면 보안/IT 정책 담당과 합의된 절차로 처리하는 것이 원칙이다.
6. “앱만 살리고 WDAC는 유지”하는 실무 해법이다
업무용 앱이 막혔다고 WDAC를 완전히 끄는 것은 장기적으로 손해가 크다. 실무에서는 다음 순서가 가장 재현성이 높다.
- 감사(Audit) 모드로 전환하여 실제 차단 대상과 사유를 로그로 수집한다.
- 막힌 앱의 설치 경로, 서명 여부, 배포 방식(MSI/스토어/자체 런처)을 정리한다.
- 허용 규칙을 “서명 기반(권장)”으로 우선 구성한다.
- 부득이한 경우에만 “파일 해시/경로 규칙”을 사용한다.
- 테스트 그룹에서 강제(Enforced)로 전환 후 확산 배포한다.
6-1. 로그 기반으로 허용 대상을 뽑는 방법이다
차단 이벤트(3077) 또는 감사 차단 이벤트(3076)에서 실행 파일 경로를 모아 “허용 후보 리스트”를 만든 뒤, 정책에 반영하는 방식이 가장 빠르다. 운영 중에는 신규 버전 업으로 해시가 바뀌는 경우가 많으므로, 가능하면 서명 규칙으로 설계하는 것이 유지보수에 유리하다.
7. 자주 발생하는 실수와 예방 체크리스트이다
| 실수 | 결과 | 예방책 |
|---|---|---|
| 배포 시스템은 그대로 두고 로컬 파일만 삭제한다 | 재부팅 후 정책이 다시 내려와 증상이 반복된다 | MDM/GPO에서 먼저 배포를 중지한다 |
| 강제 모드로 바로 전환한다 | 업무 앱 대량 차단으로 장애가 커진다 | 감사 모드로 로그 확보 후 전환한다 |
| 경로 규칙만으로 허용한다 | 악성코드가 동일 경로로 침투할 여지가 커진다 | 가능하면 서명 기반 허용을 우선한다 |
| EFI 파티션을 무분별하게 수정한다 | 부팅/보안 구성에 예기치 않은 영향이 생긴다 | 정책 ID 확인 후 필요한 파일만 최소 조치한다 |
FAQ
정책 ID(PolicyId)는 어디서 확인하는 것이 가장 확실한가?
Microsoft-Windows-CodeIntegrity/Operational 로그의 차단 이벤트(3077) 메시지에서 확인하는 방식이 가장 실무적이다. 앱 실행 직후의 최신 이벤트를 보면 정책 ID와 차단 파일 경로가 함께 기록되는 경우가 많다.
CiTool로 제거했는데도 계속 차단되는 이유는 무엇인가?
MDM/Intune 또는 그룹 정책에서 동일하거나 다른 WDAC 정책이 재배포되는 경우가 대표적이다. 배포 중지 없이 로컬에서만 제거하면 재부팅 또는 정책 새로고침 시 다시 적용될 수 있다.
특정 앱만 급하게 살려야 한다면 가장 안전한 우회는 무엇인가?
감사(Audit) 모드로 전환하여 업무를 먼저 복구한 뒤, 차단 로그를 근거로 해당 앱에 대한 서명 기반 허용 규칙을 추가하는 방식이 가장 안전하다. 완전 비활성화는 보안 공백이 커질 수 있다.
드라이버 기반 프로그램만 유독 막히는 이유는 무엇인가?
WDAC는 커널 모드 드라이버 로드까지 통제할 수 있으며, 취약 드라이버 차단이나 서명 수준 요구 조건과 결합되면 장치 드라이버를 사용하는 프로그램이 먼저 실패하는 경우가 많다. 이 경우 CodeIntegrity 로그에서 드라이버 파일 경로를 함께 확인하는 것이 필요하다.