이 글의 목적은 AppLocker 정책으로 인해 UWP(스토어) 앱이 실행되지 않는 환경에서, 보안 수준을 유지하면서 필요한 UWP 앱만 차단 해제(허용)하도록 규칙을 올바르게 구성하는 방법을 실무 관점에서 정리하는 것이다.
1. AppLocker에서 UWP가 막히는 대표 증상과 원인
AppLocker를 적용한 뒤 Microsoft Store 앱, 설정 앱, 사진, 계산기, 캡처 도구 같은 UWP 앱이 실행되지 않거나 즉시 종료되는 증상이 발생할 수 있다. 이 상황은 대개 “패키지 앱 규칙(Packaged app rules)” 컬렉션에서 기본 동작이 “거부”로 해석되는 구성, 또는 필요한 허용 규칙이 없는 구성에서 발생하다.
AppLocker는 실행 파일 규칙, Windows Installer 규칙, 스크립트 규칙, DLL 규칙, 그리고 UWP에 해당하는 “패키지 앱 규칙”을 별도의 규칙 컬렉션으로 관리하다. 많은 운영 환경에서 EXE 규칙만 구성해도 업무가 가능하지만, UWP까지 통제하려면 패키지 앱 규칙을 명확히 설계해야 하다.
2. 사전 점검 체크리스트
2.1 AppLocker 적용 모드 확인
AppLocker는 “감사 전용(Audit only)”과 “강제(Enforce rules)”로 운영할 수 있다. 운영 중에 갑자기 UWP가 막혔다면, 기존에 감사 전용이던 정책이 강제로 바뀌었을 가능성이 높다. 로컬 보안 정책 또는 그룹 정책에서 AppLocker 속성을 확인해야 하다.
2.2 Application Identity 서비스 확인
AppLocker는 Application Identity(AppIDSvc) 서비스가 실행 중이어야 정상 동작하다. 서비스가 꺼져 있으면 규칙이 적용되지 않거나, 일부 환경에서 진단이 어려운 상태가 되다. 운영 표준에서는 자동 시작으로 두는 구성이 일반적이다.
sc query appidsvc sc config appidsvc start= auto sc start appidsvc2.3 이벤트 로그로 차단 항목 확인
“무엇이 왜 막혔는지”를 먼저 확인해야 정확히 풀 수 있다. AppLocker는 이벤트 로그에 차단 정보를 남기므로, 이벤트 뷰어에서 AppLocker 로그를 확인해 패키지 앱이 차단된 기록을 찾아야 하다.
일반적으로 다음 경로에서 확인하다.
| 구분 | 로그 위치 | 의미 | 실무 활용 |
|---|---|---|---|
| 패키지 앱 | Application and Services Logs \ Microsoft \ Windows \ AppLocker \ Packaged app-Execution | UWP 실행 차단/허용 기록 | 차단된 패키지명/게시자/버전 범위 확인에 사용하다 |
| EXE | ...\AppLocker\EXE and DLL | Win32 실행 파일 차단/허용 기록 | UWP와 별개로 함께 점검하다 |
3. 해결 전략: “전체 해제”가 아니라 “필요한 UWP만 허용”으로 구성하기
보안 정책을 운영하는 환경에서 “UWP 전체 허용”은 빠르지만 위험하다. 실무적으로는 다음 우선순위를 권장하다.
| 전략 | 권장 상황 | 장점 | 주의점 |
|---|---|---|---|
| 필수 시스템 UWP만 허용 | 키오스크, 공용 PC, 제한 사용자 | 공격 표면 최소화가 가능하다 | 초기 튜닝이 필요하다 |
| 업무용 UWP만 허용 | 업무 앱이 스토어 기반인 환경 | 업무 연속성 확보가 가능하다 | 게시자/버전 범위를 적절히 잡아야 하다 |
| 특정 사용자/그룹만 예외 허용 | IT 관리자, 테스트 그룹 | 운영 리스크를 단계적으로 낮추다 | 그룹 설계와 권한 통제가 핵심이다 |
4. 구성 절차: 로컬 보안 정책(또는 GPO)에서 UWP 허용 규칙 만들기
4.1 정책 편집기 경로
로컬에서 구성한다면 secpol.msc에서 AppLocker로 이동하다. 도메인 환경이라면 그룹 정책 관리 콘솔에서 컴퓨터 구성의 AppLocker로 이동하다.
| 구분 | 도구 | 경로 |
|---|---|---|
| 로컬 PC | 로컬 보안 정책 | 보안 설정 > 응용 프로그램 제어 정책 > AppLocker |
| 도메인 | 그룹 정책 관리 | 컴퓨터 구성 > Windows 설정 > 보안 설정 > 응용 프로그램 제어 정책 > AppLocker |
4.2 “패키지 앱 규칙” 컬렉션에서 규칙 생성
UWP는 “패키지 앱 규칙”에서 제어하다. 여기에서 “새 규칙 만들기”를 실행하고, 조건(Conditions)을 “게시자(Publisher)” 기반으로 설정하는 구성이 가장 안정적이다.
게시자 기반 조건은 패키지 서명 정보(게시자, 제품명, 패키지명, 버전)를 기준으로 허용 범위를 잡다. 같은 게시자의 같은 앱은 업데이트되어도 허용이 유지되도록 버전 범위를 “모든 버전” 또는 “이상 버전”으로 설계할 수 있다.
4.3 권장 규칙 패턴 3가지
패턴 A: Microsoft Windows 기본 UWP(설정, 스토어 프레임워크 등) 허용
운영체제 자체 기능을 위해 필요한 UWP는 “Microsoft Windows” 계열로 배포되는 경우가 많다. 이 패턴은 OS 안정성을 위해 최소한의 기본 UWP 실행을 허용하는 목적이다.
규칙 조건은 게시자로 두고, 제품/패키지명은 가능한 좁게, 버전은 “모든 버전”으로 두는 구성이 일반적이다.
패턴 B: 특정 업무용 스토어 앱만 허용
업무 앱이 UWP로 배포되었다면, 해당 패키지 하나만 허용 규칙을 추가하는 방식이 가장 안전하다. 이때 패키지명은 이벤트 로그에서 확인한 정확한 패키지 식별자를 기준으로 잡는 것이 실무적으로 가장 확실하다.
패턴 C: 특정 사용자/그룹(예: IT-Exception)에게만 UWP 허용
전사 적용 전에 단계적으로 문제를 줄이고 싶다면, 예외 그룹을 만들고 그 그룹에만 UWP 허용 규칙을 적용하다. AppLocker 규칙은 “사용자 또는 그룹” 범위를 지정할 수 있으므로, 동일 PC에서도 사용자별 정책 차등이 가능하다.
5. PowerShell로 차단 원인 파악과 패키지 정보 확인
GUI에서 규칙을 만들기 전에, 차단된 UWP의 패키지 정보를 PowerShell로 확인하면 설계가 쉬워지다. 특히 패키지명(PackageFullName)과 게시자 정보는 규칙 조건을 좁히는 데 유용하다.
5.1 설치된 UWP 패키지 목록에서 대상 찾기
# 전체 사용자 기준 설치 패키지 조회(권한 필요할 수 있음) Get-AppxPackage -AllUsers | Select-Object Name, PackageFullName, Publisher, Version | Sort-Object Name
현재 사용자 기준
Get-AppxPackage | Select-Object Name, PackageFullName, Publisher, Version | Sort-Object Name5.2 특정 앱만 필터링
# 예: 계산기 Get-AppxPackage *WindowsCalculator* | Select-Object Name, PackageFullName, Publisher, Version
예: 사진 앱
Get-AppxPackage Windows.Photos | Select-Object Name, PackageFullName, Publisher, Version5.3 규칙 설계에 필요한 핵심 필드 정리
| 필드 | 의미 | AppLocker 규칙에서의 활용 |
|---|---|---|
| Publisher | 서명 게시자 | 게시자 조건의 최상위 기준이 되다 |
| Name | 패키지 축약 이름 | 대상 앱 식별에 활용하다 |
| PackageFullName | 버전/아키텍처 포함 전체 이름 | 로그 대조 및 정확한 대상 확인에 활용하다 |
| Version | 버전 | 업데이트 허용 범위를 결정하다 |
6. 운영 품질을 높이는 구성 팁
6.1 감사(Audit)로 먼저 튜닝한 뒤 강제로 전환
즉시 강제로 전환하면 예상치 못한 업무 중단이 발생할 수 있다. 패키지 앱 규칙을 감사로 운영하면서 차단 예정 항목을 로그로 수집하고, 허용 목록을 완성한 뒤 강제로 전환하는 방식이 안전하다.
6.2 허용 규칙은 “최소 범위”로, 유지보수는 “버전 범위”로 조절
패키지 앱은 업데이트가 잦다. 허용 규칙을 너무 타이트하게 잡으면 업데이트 후 다시 막히다. 반대로 너무 넓게 잡으면 불필요한 앱까지 열리다. 실무에서는 “제품/패키지명은 좁게, 버전은 넓게”가 운영 균형이 좋다.
6.3 스토어 자체를 막을지, 스토어 앱 설치만 막을지 분리 설계
스토어 앱 실행을 허용한다고 해서 반드시 스토어에서 임의 설치가 가능한 것은 아니다. 설치 정책은 별도(스토어 정책, 조직용 스토어/패키지 배포, MDM 등)로 통제할 수 있다. AppLocker는 “실행 통제”이므로, 설치 통제와 혼동하지 않는 것이 중요하다.
7. 실무 예시: 규칙 설계 템플릿
현장에서 자주 쓰는 설계 템플릿을 표로 정리하다. 실제 적용 시에는 이벤트 로그와 Get-AppxPackage 결과를 기준으로 대상 패키지를 확정해야 하다.
| 목표 | 규칙 컬렉션 | 조건 | 권장 범위 | 비고 |
|---|---|---|---|---|
| 설정 앱 등 기본 기능 유지 | 패키지 앱 규칙 | 게시자 | 제품/패키지명 특정, 버전은 넓게 | 운영체제 안정성 목적이다 |
| 특정 업무용 UWP 허용 | 패키지 앱 규칙 | 게시자 | 대상 앱 1개 단위로 허용 | 업데이트 고려해 버전 범위를 설계하다 |
| IT 예외 사용자에게만 허용 | 패키지 앱 규칙 | 게시자 | 대상 앱 + 특정 그룹 | 전사 전환 전 단계 적용에 유리하다 |
8. 장애가 계속될 때 확인할 추가 포인트
8.1 EXE 규칙에서 System32, Program Files가 과도하게 막혔는지 확인
UWP 자체는 패키지 앱 규칙으로 제어하지만, 실행 과정에서 호출되는 구성 요소가 EXE/DLL 규칙에 걸리면 UWP도 실패하다. EXE 규칙에서 Windows 및 Program Files 경로 기본 허용이 합리적으로 구성되어 있는지 점검해야 하다.
8.2 WDAC(Windows Defender Application Control)와 동시 적용 여부 확인
일부 환경에서는 WDAC와 AppLocker가 함께 쓰이다. 이 경우 “AppLocker에서 풀었는데도 계속 막힘”이 발생할 수 있다. 조직 표준이 WDAC 중심인지, AppLocker 중심인지부터 확인해야 하다.
8.3 다중 정책(GPO) 충돌과 우선순위 확인
도메인 환경에서는 여러 GPO가 중첩 적용되며, 컴퓨터 OU 이동, 보안 필터링, WMI 필터로 인해 정책이 예상과 다르게 적용되다. 결과 집합 정책(RSoP) 또는 gpresult로 실제 적용 정책을 확인하는 것이 중요하다.
gpresult /h C:\gpresult.htmlFAQ
UWP 전체를 한 번에 허용하는 것이 가능한가?
패키지 앱 규칙에서 게시자 범위를 넓게 잡으면 사실상 전체 허용에 가까운 구성이 가능하다. 다만 실무 보안 관점에서는 불필요한 앱까지 열릴 가능성이 높으므로, 필요한 앱만 최소 범위로 허용하는 방식이 권장되다.
규칙을 추가했는데도 스토어 앱이 계속 실행되지 않다. 무엇을 더 봐야 하나?
패키지 앱 실행 로그에서 차단 이벤트가 계속 발생하는지 확인해야 하다. 차단 로그가 없는데도 실행이 실패한다면 EXE/DLL 규칙, WDAC 동시 적용, 또는 스토어 설치 정책/네트워크 정책 문제일 수 있다. 또한 Application Identity 서비스가 실행 중인지도 반드시 확인해야 하다.
업데이트 후 다시 막히는 것을 방지하려면 어떻게 구성해야 하나?
게시자 조건에서 제품/패키지명을 구체화하되, 버전 범위는 “모든 버전” 또는 “이상 버전”처럼 업데이트를 허용하는 형태로 설계하는 것이 일반적이다. 반대로 버전을 너무 좁게 고정하면 업데이트마다 재작업이 발생하다.
특정 사용자만 예외로 UWP를 허용할 수 있나?
규칙 생성 시 적용 대상 사용자 또는 그룹을 지정할 수 있으므로 가능하다. 전사 정책을 유지하면서 IT 예외 그룹만 단계적으로 허용하는 방식이 운영 안정성과 보안의 균형에 유리하다.