AppLocker・App Control for Business(WDAC)와 업무 앱 배포 ── '실행 제어'에 막히기 전에

“고객 PC에 설치했더니 앱이 실행되지 않습니다. 더블클릭해도 아무것도 뜨지 않아요”── 수탁 개발한 Windows 앱을 배포하면서 이런 상담이 들어오는 빈도가 늘고 있습니다. 원인을 조사해 보면, 오류 대화상자조차 띄우지 않고 앱을 멈추게 한 것은 고객 측에서 도입이 진행되고 있는 애플리케이션 실행 제어였습니다.

Windows에는 정해진 앱만 실행되도록 하는 구조가 여러 가지 있습니다. AppLocker, App Control for Business(오랫동안 WDAC=Windows Defender Application Control로 불려온 것), 그리고 개인용 Smart App Control입니다. 보안 대책의 맥락에서는 “도입하는 쪽”의 해설이 많지만, 이 글은 시점을 바꿔 앱을 만들어 배포하는 쪽의 관점에서 정리합니다. 자사의 업무 앱이 고객 환경에서 차단되는 전형적인 패턴, 차단되었을 때 어떤 로그를 보면 확정할 수 있는지, 그리고 개발·배포 측에서 미리 손써 둘 수 있는 방법입니다. 아울러 자사 PC에 도입을 검토하는 정보 시스템 담당자 관점의 요점도 정리합니다.

1. 먼저 결론

• 실행 제어는 4가지로 구분해서 생각합니다. 경고하고 선택하게 하는 SmartScreen, 사용자/그룹 단위로 규칙을 제어하는 AppLocker, 머신 전체를 대상으로 하는 App Control for Business, 개인용으로 자동으로 작동하는 Smart App Control입니다(2장의 판단표).
• “AppLocker는 Enterprise 전용”이라는 상식은 낡았습니다. KB 5024351 이후, Windows 10 버전 2004 이후와 모든 Windows 11에서는 강제 적용에 특정 에디션이 필요하지 않습니다.¹
• App Control for Business는 Windows 10/11의 모든 클라이언트 에디션과 Windows Server 2016 이후에서 사용할 수 있습니다. Microsoft는 가능하다면 AppLocker가 아니라 App Control의 이용을 권장합니다.²
• 배포 측 대책의 핵심은 코드 서명입니다. exe뿐 아니라 DLL을 포함한 모든 바이너리와 설치 프로그램에 일관된 발행자 정보로 서명합니다(5장). Smart App Control의 보급으로, 미서명 앱은 개인 PC에서도 동작하지 않는 경우가 생겼습니다.³
• 차단의 증거는 이벤트 로그로 확정할 수 있습니다. AppLocker라면 “AppLocker - EXE and DLL”의 이벤트 8004, App Control이라면 “CodeIntegrity - Operational”의 이벤트 3077이 핵심입니다(4장의 판단표).⁴⁵
• PowerShell 스크립트는 “차단”이 아니라 “제한 모드로 실행”이 되는 경우가 있습니다. App Control 환경에서는 정책에 맞지 않는 스크립트가 제약된 언어 모드(Constrained Language Mode)로 동작하기 때문에, “동작은 하지만 일부 처리만 실패한다”는 알기 어려운 방식으로 망가집니다.⁵
• 도입하는 쪽은 감사 모드부터 시작합니다. AppLocker도 App Control도 차단하지 않고 “차단되었을 것”을 기록하는 모드가 있으며, 이벤트 8003·3076이 여기에 해당합니다.⁴⁵

2. 4가지 구조를 구분한다

먼저 전체 지도입니다. 이름이 비슷해서 혼동하기 쉬우므로 “누가”, “무슨 단위로”, “어떻게 작동하는가”로 나눕니다.

2.1. SmartScreen ── 유일하게 “경고”로 멈추는 구조

SmartScreen은 “평판이 나쁜 것을 경고한다”는 구조로, 기본값에서는 사용자가 무시하고 진행할 수 있습니다. 다만 관리되는 환경에서는 경고 무시 자체를 금지하는 정책이 활성화되어 있는 경우가 있으며, 이 경우 SmartScreen도 실질적으로 차단으로 작동합니다(이 내용은 「Windows에서 ‘Windows에 의해 PC가 보호되었습니다’가 나타나는 이유」에서 다뤘습니다).

배포하는 쪽에서 본 SmartScreen의 특징은 규칙을 작성하는 관리자가 없어도 기본값으로 작동한다는 점과, 차단의 이유가 정책이 아니라 “평판”이라는 점입니다. 따라서 대처 방법도 나머지 세 가지와 달리, 고객에게 허용 규칙을 작성해 달라고 하는 것이 아니라 서명과 평판의 축적으로 해결하게 됩니다. 이후 2.2~2.4는 경고가 아니라 차단하는 구조입니다.

2.2. AppLocker ── 사용자 단위로 제어할 수 있는 원조

AppLocker는 Windows 7에서 도입된 실행 제어로, 코드 서명 증명서의 속성(발행자), 서명 메타데이터에서 유래한 파일 속성(원래 파일 이름·버전)이나 해시, 파일 경로를 기반으로 규칙을 정의합니다. 정책은 컴퓨터 전체에도, 특정 사용자·그룹에도 적용할 수 있습니다.²

에디션 요건은 오해가 많은 부분입니다. 현재 문서는 명확합니다. KB 5024351 이후, Windows 10 버전 2004 이후와 모든 Windows 11에서는 AppLocker 정책의 강제 적용에 특정 에디션이 필요하지 않습니다. 이전 버전(버전 2004 이전의 Windows 10, Windows Server 2019 포함)에서는 그룹 정책 배포를 통한 강제 적용은 Enterprise와 Server 에디션만 가능하고, MDM 배포라면 모든 에디션이 가능하다는 기존 제한이 남아 있습니다.¹

“Pro에서 무엇을 할 수 있는가”를 규칙을 만들 수 있는가와 만든 규칙이 실제로 작동하는가(강제되는가)의 두 가지로 나누어 정리하면 다음과 같습니다. 이 두 가지가 별개라는 점이 낡은 상식이 살아남은 원인입니다.¹

“Pro 환경에서는 작성조차 할 수 없다”고 오해하기 쉽지만, 작성은 어떤 에디션에서든 가능합니다. 예전부터 갈렸던 것은 강제 적용 쪽이었고, 게다가 MDM 배포라면 당시부터 Pro에서도 강제 적용이 가능했습니다. 적용할 수 있는 규칙 종류(실행 파일·Windows 설치 프로그램·스크립트·DLL·패키지 앱)는 에디션에 따라 달라지지 않습니다.¹ 참고로 어떤 에디션이든 Application Identity 서비스(AppIDSvc)가 동작하지 않으면 규칙이 평가되지 않습니다(6장).

다만 AppLocker에는 중요한 단서가 있습니다. Microsoft 스스로 AppLocker가 보안 기능으로서의 서비스 기준(MSRC의 servicing criteria)을 충족하지 않는다고 명시하고 있습니다. 즉 우회 방법이 발견되더라도 그 자체는 보안 취약점으로 취급되지 않습니다.²

2.3. App Control for Business ── 보안 기능으로서의 본명

App Control for Business는 Windows 10에서 “Device Guard”, “구성 가능한 코드 무결성(WDAC)”으로 등장한 구조의 현재 명칭입니다. 정책은 머신 전체에 적용되며 디바이스의 모든 사용자에게 영향을 미칩니다. 규칙의 근거로 삼을 수 있는 것은 서명 증명서의 속성, 파일 속성이나 해시, Microsoft의 Intelligent Security Graph(ISG)에 의한 평가, 설치를 시작한 프로세스(관리형 설치 프로그램), 파일 경로(Windows 10 1903 이후), 실행을 시작한 프로세스입니다.²

이쪽은 MSRC의 서비스 기준으로 정의된 보안 기능으로 설계되어 있습니다. 이용 조건도 넓어서, Windows 10/11의 임의의 클라이언트 에디션, 또는 Windows Server 2016 이후에서 정책을 작성·적용할 수 있습니다. 배포는 Intune 등의 MDM, Configuration Manager, PowerShell을 사용할 수 있습니다. 그룹 정책으로도 배포할 수 있지만, Windows Server 2016/2019에서 동작하는 단일 정책 형식으로 한정됩니다.²

어느 쪽을 사용해야 하는지에 대한 Microsoft의 지침은 명확합니다. App Control로 구현할 수 있다면 그쪽을 사용해야 하며, App Control은 개선이 계속되고 있는 반면 AppLocker는 보안 수정은 받지만 새 기능은 추가되지 않습니다. AppLocker가 적합한 경우는 오래된 Windows가 혼재되어 있어 같은 정책을 배포하고 싶은 경우와, 공유 PC에서 사용자·그룹별로 다른 규칙이 필요한 경우, 그리고 App Control을 보완하기 위해 사용자 단위 제한을 추가하는 경우입니다.²

2.4. Smart App Control ── 개인 PC에 “저절로” 들어와 있는 실행 제어

Smart App Control은 Windows 11의 개인 이용자를 위한 보호 기능입니다. 앱을 실행하려고 하면 클라우드의 보안 서비스가 그 앱의 안전성을 예측할 수 있는지 확인하고, 악의가 있다고 판정된 앱이나, 유효한 서명이 없어 신뢰를 확인할 수 없는 앱을 차단합니다. 새 PC에서는 평가 모드부터 시작하며, 해당 이용자에게 적합한지를 Windows가 자동으로 판정하여 활성화·비활성화가 결정됩니다(개발자처럼 자주 차단될 것 같은 이용자는 자동으로 꺼집니다).³

배포하는 쪽에게 의미는 단순합니다. 기업 관리 아래에 있지 않은 PC, 즉 소규모 사업자나 개인 사업주 고객의 PC에도 실행 제어가 기본값으로 들어가 있는 시대가 되었다는 것입니다. 관리자가 아무도 정책을 작성하지 않았더라도 미서명 앱은 차단될 수 있습니다. Microsoft의 개발자용 안내에서도 차단을 피하기 위해 유효한 증명서로 앱에 서명할 것을 언급하고 있습니다.³

3. 당신의 앱이 차단되는 전형적인 패턴

수탁 개발·패키지 배포 현장에서 실제로 겪는 패턴을 원인별로 나열합니다.

공통되는 구도는 “실행을 허용하는 쪽의 근거(서명·경로·해시)를, 배포하는 쪽이 안정적으로 제공하지 못하고 있다”는 것입니다. 고객의 정보 시스템 담당자가 발행자 규칙을 작성하고 싶어도, 서명이 일부 바이너리에만 되어 있으면 해시 규칙으로 작성할 수밖에 없고, 해시 규칙은 당신이 업데이트판을 낼 때마다 깨집니다. 차단의 책임은 도입하는 쪽에 있는 것처럼 보이지만, 규칙을 깨지기 쉽게 만드는 원인은 배포하는 쪽에 있는 경우가 실제로는 많습니다.

4. 무슨 일이 있었는지 로그로 확정한다

“실행되지 않는다”의 원인이 실행 제어인지는, 추측이 아니라 이벤트 로그로 확정할 수 있습니다. 확인할 곳은 두 계통입니다.

4.1. AppLocker의 이벤트

이벤트 뷰어의 응용 프로그램 및 서비스 로그\Microsoft\Windows\AppLocker 아래를 확인합니다.⁴ 처음 여는 분들을 위해 찾아가는 방법을 적어 둡니다.

이벤트 뷰어(시작 메뉴에서 “이벤트 뷰어” 검색, 또는 실행 창에서 eventvwr.msc)> 응용 프로그램 및 서비스 로그 > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

영어 환경에서는 Applications and Services Logs > Microsoft > Windows > AppLocker입니다. GUI를 따라가지 않고 끝내고 싶다면, PowerShell을 관리자 권한으로 열어 다음 한 줄로 읽을 수 있습니다(고객에게 요청할 때도 이 줄을 전달하는 것이 가장 빠른 방법입니다).

# 최근 24시간의 AppLocker 차단(8004)과 감사(8003)를 추출
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

이벤트에는 대상 파일의 경로, 허용인지 차단인지, 적용된 규칙 종류(경로·해시·발행자)와 규칙 이름, 규칙의 사용자/그룹 SID가 기록됩니다.⁴ 다만 읽는 방법에 주의가 필요합니다. 허용 목록형 운영에서는 차단의 대부분이 “어느 거부 규칙과 일치했다”가 아니라 어느 허용 규칙과도 일치하지 않은 암묵적 거부입니다. 이 경우 8004로 확정할 수 있는 것은 “차단된 사실과 대상 파일”까지이며, 규칙 이름은 단서가 되지 않습니다. 명시적인 거부 규칙에 걸렸을 때는 규칙 이름이 그대로 원인이지만, 암묵적 거부에서는 “어느 허용 규칙이 부족한지”를 적용 중인 정책 쪽과 대조하여 찾아야 합니다.

4.2. App Control for Business(WDAC)의 이벤트

App Control의 차단은 다른 위치인 응용 프로그램 및 서비스 로그\Microsoft\Windows\CodeIntegrity\Operational에 표시됩니다. exe·DLL·드라이버 제어는 이쪽이고, MSI·스크립트·COM 제어는 앞서 나온 “AppLocker - MSI and Script” 로그에 표시된다는 역할 분담입니다.⁵

이벤트 뷰어 > 응용 프로그램 및 서비스 로그 > Microsoft > Windows > CodeIntegrity > Operational(영어 환경에서는 Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# App Control의 차단(3077)·감사(3076)와 대응하는 서명 정보(3089)를 함께 확인
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

“어느 구조로 차단되었는지 알 수 없다”는 상태일 때는, 이 두 로그를 같은 시간대로 나란히 놓고 대조하는 것이 확실합니다.

3089는 놓치기 쉽지만 중요합니다. 파일의 서명마다 1건씩 생성되며, 미서명 파일이라면 서명 수 0인 1건이 나옵니다. “분명 서명했는데 미서명으로 취급되고 있다”, “오래된 증명서의 서명이 남아 있다” 같은 배포 측의 문제는 여기서 확정할 수 있습니다.⁵

스크립트의 동작에는 특유의 주의점이 있습니다. 이벤트 8029는 “스크립트가 차단되었다”는 것을 나타내지만, 실제 강제는 스크립트 호스트 쪽의 동작에 맡겨져 있으며, 예를 들어 PowerShell은 정책에 맞지 않는 스크립트를 완전히 멈추는 것이 아니라 제약된 언어 모드(Constrained Language Mode)로 실행합니다.⁵ .NET 객체 생성이 폭넓게 제한되기 때문에, “스크립트 자체는 동작했지만 중간의 한 줄만 실패한다”는 어중간한 방식으로 망가집니다. 앱에 스크립트를 동봉한 경우, 이런 망가짐 방식을 모르면 조사가 길어집니다(스크립트 서명의 실무는 「PowerShell 실행 정책과 스크립트 서명 ── ‘Bypass로 덮어두는’ 운용에서 졸업하는 실무 가이드」).

참고로 “AppLocker - MSI and Script” 로그는 Windows Server Core 에디션에는 존재하지 않습니다.⁵ 서버에 배포한 앱을 조사할 때는 기억해 두시기 바랍니다.

5. 배포하는 쪽의 대책 ── 규칙을 “작성하기 쉬운” 앱으로 만든다

차단된 후에 대처하는 것이 아니라, 고객의 정보 시스템 담당자가 안정된 허용 규칙을 작성할 수 있는 상태로 배포하는 것이 정도(正道)입니다. 해야 할 일은 많지 않습니다.

1. 모든 바이너리에 Authenticode 서명을 한다. exe뿐 아니라 자체 빌드한 DLL, 설치 프로그램(MSI/설치용 exe), 동봉된 스크립트까지. 발행자 규칙은 서명 메타데이터(발행자·제품명·파일명·버전)를 근거로 하므로, 서명이 되어 있으면 “이 발행자의 이 제품은 버전에 상관없이 허용”이라는 업데이트에 견디는 규칙을 작성해 받을 수 있습니다.² 증명서는 신뢰할 수 있는 인증 기관이 발급한 RSA 기반의 것을 선택해 주십시오. 자체 서명 증명서나 사내 CA의 증명서는 해당 CA를 신뢰하지 않는 고객 PC에서는 통하지 않으며, Smart App Control에서도 지원되지 않습니다. 또한 Smart App Control의 서명 검사는 ECC(타원 곡선) 서명을 지원하지 않기 때문에, ECC 증명서로 서명하면 개인 PC에서는 미서명이나 다름없는 취급을 받을 수 있습니다.⁶ 같은 제약이 App Control에도 있어서, 서명자 기반 규칙은 RSA(최대 4096비트)만 지원하며, ECDSA 서명 파일은 발행자 규칙으로 허용할 수 없습니다(서명 정보의 3089 이벤트에 VerificationError = 23이 표시됩니다).⁷ “ECC 쪽이 더 새롭고 강력하다”고 생각해서 선택하면, 실행 제어 관점에서는 역효과가 됩니다.
2. 타임스탬프를 반드시 붙인다. 증명서 기한이 만료되어도 서명의 유효성이 유지됩니다. 서명의 실무 절차와 SmartScreen의 관계는 다른 글에 정리해 두었습니다.
3. 발행자 정보와 파일의 버전 리소스를 안정시킨다. 증명서를 갱신할 때 서브젝트(조직명)가 바뀌면 발행자 규칙이 깨집니다. 회사명 표기나 증명서 발급처를 변경하는 경우에는 고객에게 사전 통지를 릴리스 노트에 포함해 주십시오. 또 하나 놓치기 쉬운 점은, 발행자 규칙의 “제품명”, “원래 파일 이름”, “버전”이 증명서가 아니라 각 파일의 버전 리소스(어셈블리 정보)에서 가져온다는 것입니다. 이 필드들을 비워 두거나 릴리스마다 제품명이나 실행 파일 이름을 바꾸면, 서명자가 같아도 제품·파일 단위로 좁힌 규칙은 깨집니다.
4. 실행 파일 위치를 표준에 맞춘다. Program Files 아래에 설치하고, 실행 시 %TEMP%나 %APPDATA%로 exe/DLL을 전개해 실행하는 설계를 그만둡니다. 쓰기 가능한 위치에서 실행하는 설계는 경로 규칙형 환경과 근본적으로 궁합이 나쁘기 때문입니다.
5. 자동 업데이트 설계를 재검토한다. 업데이트 프로그램 자체도 서명하고, 업데이트가 “서명된 바이너리를 서명된 바이너리로 교체하는” 닫힌 흐름이 되도록 합니다. Intune이나 Configuration Manager로 배포되는 경우, 고객 측이 해당 배포 에이전트를 관리형 설치 프로그램으로 구성해 두었다면, 설치 프로그램을 경유해 들어온 바이너리를 허용하는 운영이 가능해집니다. 자동으로 작동하는 것이 아니라 관리자 측의 명시적인 구성이 전제이지만, 사일런트 설치를 지원하는 MSI를 준비해 둠으로써 그 선택지를 고객에게 넘길 수 있습니다(자동 업데이트의 안전한 설계는 「자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스」).
6. 차단 시 정보 제공을 준비해 둔다. 서명 서브젝트, 실행에 필요한 바이너리 목록, 설치 경로를 “도입 절차서”에 명시해 두면, 고객의 정보 시스템 담당자는 그것만으로 규칙을 작성할 수 있습니다. 문제가 생겼을 때는 4장의 이벤트 ID를 지정해 확인을 요청하면 왕복이 한 번으로 끝납니다.

이 여섯 가지는 Smart App Control에 대한 대비로도 그대로 유효합니다. 서명되고 평판이 쌓인 바이너리는 개인 PC의 자동 차단에도 걸리기 어려워집니다.³

5.1. 처음으로 코드 서명 증명서를 발급받을 때

“서명합시다”에서 멈추면 앞으로 나아갈 수 없으므로, 증명서를 가지고 있지 않은 경우의 다음 한 수를 적어 둡니다.

증명서 선택 방법. 사용할 수 있는 것은 퍼블릭 인증 기관(상용 CA)이 발급하는 코드 서명 증명서입니다. 자체 서명 증명서나 사내 CA의 증명서는 해당 CA를 신뢰하지 않는 고객 PC에서는 검증할 수 없으므로 배포물에는 사용할 수 없습니다. 퍼블릭 CA의 증명서에는 기업 실재 확인을 하는 OV와, 더 엄격한 심사를 거치는 EV가 있지만, AppLocker나 App Control의 발행자 규칙이라는 관점에서는 어느 쪽이든 똑같이 규칙을 작성할 수 있습니다. App Control에는 “EV 서명을 필수로 한다”는 규칙 옵션(Required:EV Signers)이 마련되어 있기는 하지만, 현재로서는 지원되지 않는다고 문서에 명시되어 있으므로, 실행 제어를 위해 EV를 선택할 이유는 지금으로서는 없습니다.⁷

비용 개념. 금액은 CA와 유효 기간에 따라 달라지므로 견적을 받는 것을 전제로 하지만, 내역 구조만 알아두어도 비교하기 쉬워집니다. 2023년 6월 1일 이후, CA/Browser Forum의 기준에 따라 OV·EV를 불문하고 개인 키를 FIPS 140-2 레벨 2 상당 이상의 하드웨어(HSM나 USB 토큰)에서 생성·보관하는 것이 필수가 되었습니다.⁸ 즉 비용은 “증명서 본체”뿐 아니라 “토큰이나 HSM, 또는 CA가 제공하는 클라우드 서명 서비스 이용료”를 포함합니다. CI/CD로 자동 서명하고 싶은 경우에는 물리 토큰보다 클라우드 서명 서비스 쪽이 구성하기 쉬우므로, 견적을 받을 때 서명 운영 방법까지 포함해 상담해 주십시오.

최소한의 서명 명령. Windows SDK에 포함된 signtool을 사용합니다.

:: 서명한다(SHA-256으로 해시하고, RFC 3161 타임스탬프를 붙인다)
signtool sign /fd sha256 /tr <타임스탬프 서버의 URL> /td sha256 /a MyApp.exe

:: 서명을 확인한다(Authenticode 정책으로 검증하고 상세 내용을 표시)
signtool verify /pa /v MyApp.exe

/fd가 파일 해시 알고리즘, /tr이 RFC 3161 타임스탬프 서버의 URL, /td가 타임스탬프의 해시 알고리즘, /a가 증명서 저장소에서 적절한 증명서를 자동 선택하는 지정입니다. 타임스탬프 서버 URL은 증명서를 구매한 CA가 안내하는 것을 사용해 주십시오. 토큰이나 HSM의 키로 서명하는 경우에는 CSP/KSP 지정이 CA의 절차서에 실려 있습니다. DLL도 설치 프로그램도 같은 명령으로 서명할 수 있으므로, 빌드의 마지막에 한꺼번에 걸어 두는 것이 확실합니다.

증명서를 갱신할 때 무엇이 깨지는가. 발행자 규칙은 서명의 발행자 정보(증명서 체인과 서브젝트)를 근거로 합니다. 따라서 다음과 같은 변경으로 고객 측 규칙이 조용히 일치하지 않게 됩니다.

• 회사명 표기를 바꿨다(예: 증명서의 서브젝트를 Komura Soft LLC에서 합동회사 코무라소프트로 변경했다). 같은 회사여도 문자열이 다르면 다른 발행자입니다.
• CA를 갈아탔다. App Control의 Publisher 레벨 규칙은 “중간 CA(PCA) 증명서 + 리프 증명서의 CN” 조합이므로, CA가 바뀌면 PCA가 바뀌어 일치하지 않게 됩니다.⁷
• 실행 파일 이름이나 제품명을 바꿨다. FilePublisher 레벨 규칙에는 이에 더해 원래 파일 이름(OriginalFileName)과 최소 버전이 포함됩니다.⁷

어느 쪽이든 증상은 같아서, 업데이트판으로 교체한 순간부터 그 환경에서만 앱이 실행되지 않는다는 형태로 나타납니다. 게다가 고객 측에서 보면 “업데이트했더니 깨졌다”이기 때문에 원인이 서명에 있다고는 눈치채지 못합니다. 증명서를 갱신·변경할 때는 신구 서명 정보(서브젝트, 발급 CA)를 나란히 놓은 안내를 릴리스 노트에 싣고, 고객의 정보 시스템 담당자가 규칙을 추가할 수 있도록 해 주십시오.

6. 도입하는 쪽(정보 시스템)의 요점

자사 PC에 실행 제어를 도입하는 쪽의 절차는, 이 글의 범위에서는 요점만 다룹니다.

1. 기술을 선택한다. 원칙은 App Control for Business. 사용자 단위 제어가 필요한 공유 PC나 오래된 OS가 혼재된 환경에서는 AppLocker를 병용합니다.² 키오스크 단말과 같은 고정 용도 PC는, 먼저 셸 제한(「키오스크 모드로 업무 단말을 고정한다 ── Assigned Access・Shell Launcher 선택법과 운영 설계」)으로 좁혀 놓고 생각하면 규칙이 단순해집니다.
2. 반드시 감사 모드부터 시작한다. AppLocker의 “감사만”이라면 이벤트 8003·8006, App Control의 감사 모드라면 이벤트 3076·8028에 “강제 적용했다면 차단되었을 것”이 기록됩니다.⁴⁵ 업무가 한 바퀴 돌 때까지 수집한 뒤 강제 적용으로 전환하는 흐름은 SMB 서명이나 NTLM 제한과 완전히 같습니다. 참고로 AppLocker를 사용하는 경우에는 전제 조건이 하나 있습니다. AppLocker의 정책은 Application Identity 서비스(AppIDSvc)가 동작하지 않으면 평가되지 않으며, 감사 모드로 해도 이벤트가 나오지 않습니다. 감사를 시작하기 전에 대상 단말에서 이 서비스의 자동 시작을 구성해 주십시오.
3. 예외를 대장으로 관리한다. 미서명 상태로 계속 사용하는 오래된 업무 앱은 해시 규칙으로 예외 등록하게 됩니다. 그 목록은 “언젠가 교체해야 할 것”의 목록 그 자체이므로, 자산 관리와 연계해 매년 재검토해 주십시오.

절차 2의 “감사 모드부터 시작한다”는 다른 글로 보내지 않아도 되도록, 최소한의 흐름을 여기에 적어 둡니다.

AppLocker의 경우(3단계)

1. 감사 모드를 활성화한다. 그룹 정책 관리 편집기(로컬이라면 secpol.msc)에서 컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 응용 프로그램 제어 정책 > AppLocker를 열고, AppLocker를 마우스 오른쪽 버튼으로 클릭해 속성을 선택합니다. 규칙 컬렉션마다(실행 파일, Windows 설치 프로그램, 스크립트, 패키지 앱) “구성”에 체크하고 “감사만”을 선택합니다. 아울러 각 컬렉션에 기본 규칙을 생성하고, 대상 단말에서 Application Identity 서비스(AppIDSvc)를 자동 시작으로 구성합니다(이것이 동작하지 않으면 정책이 평가되지 않고 이벤트도 나오지 않습니다).

2. 이벤트를 수집한다. 업무가 한 바퀴 돌 때까지 Microsoft-Windows-AppLocker/EXE and DLL의 이벤트 8003(exe/DLL)과 MSI and Script의 8006(스크립트·MSI)을 수집합니다.⁴ 여기서 주의가 필요합니다. 4장의 PowerShell은 로그 이름을 “EXE and DLL”로 고정하고 있으므로, 그대로는 스크립트와 MSI의 8006을 수집하지 못합니다. 로그가 나뉘어 있는 이상, 다음과 같이 두 개를 흘려야 합니다.

    # 감사 모드에서 "강제 적용했다면 차단되었을 것"을 두 로그에서 수집
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   해당 이벤트가 하나도 없는 로그에서는 Get-WinEvent가 오류를 반환하기 때문에, -ErrorAction SilentlyContinue를 붙였습니다. 패키지 앱도 제어 대상으로 하고 있다면 Packaged app-Deployment / Packaged app-Execution도 같은 형태로 추가해 주십시오. 월간·연간 배치까지 포함해 수집되었는지 확인합니다.

3. 강제 적용으로 전환한다. 8003과 8006에 나온 것을 허용 규칙에 반영한 다음, 같은 속성 화면에서 “규칙 적용”으로 변경합니다. 전환 후에는 8004(exe/DLL 차단)와 8007(스크립트·MSI 차단)을 모니터링합니다.

App Control for Business의 경우도 흐름은 같아서, 정책 XML에 규칙 옵션 3(Enabled:Audit Mode)을 넣은 상태로 배포하고(App Control Policy Wizard, 또는 Set-RuleOption 명령렛으로 설정합니다), 3076과 8028을 수집한 뒤 이 옵션을 삭제해 강제 적용으로 전환합니다. Microsoft도 먼저 Enabled:Audit Mode로 영향을 확인할 것을 권장합니다.⁷

7. 정리

• 실행 제어는 “경고하는” SmartScreen과 “차단하는” AppLocker / App Control for Business / Smart App Control을 구분해서 생각합니다(다만 SmartScreen도 경고 무시를 금지하는 관리 정책 아래에서는 실질적으로 차단으로 작동합니다).
• AppLocker의 에디션 제한은 이미 완화되었고(Windows 10 2004 이후·Windows 11 모든 에디션), App Control은 원래부터 모든 클라이언트 에디션에서 사용할 수 있습니다. “우리 고객은 Pro니까 상관없다”는 더 이상 성립하지 않습니다.¹²
• Smart App Control로 인해 아무도 관리하지 않는 개인 PC에도 실행 제어가 들어왔습니다. 미서명 배포물은 그것만으로 동작하지 않는 경우가 있습니다.³
• 차단 확정은 이벤트 로그로. AppLocker는 8004(EXE and DLL 로그), App Control은 3077과 서명 정보의 3089(CodeIntegrity - Operational 로그)가 핵심입니다.⁴⁵
• 배포하는 쪽의 대책은 모든 바이너리에 대한 일관된 서명, 타임스탬프, 표준적인 설치 경로, 서명된 자동 업데이트, 그리고 도입 절차서를 통한 정보 제공입니다. 고객이 규칙을 작성하기 쉬운 앱으로 만드는 것이 차단 대책의 전부입니다.
• 도입하는 쪽은 감사 모드(8003 / 3076)로 한 바퀴 분량을 수집한 뒤 강제 적용으로. 이 흐름은 다른 보안 강화와 같습니다.

관련 글

• Windows에서 ‘Windows에 의해 PC가 보호되었습니다’가 나타나는 이유
• 자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스
• Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표
• PowerShell의 실행 정책과 스크립트 서명 ── ‘Bypass로 덮어버리는’ 운영에서 벗어나는 실무 가이드
• 자사 개발 Windows 앱이 바이러스로 오탐되었다면 ── Microsoft Defender 오탐 대응과 성능 영향에 대처하는 법
• 키오스크 모드로 업무 단말을 지키다 ── Assigned Access・Shell Launcher 선택법과 운영 설계
• Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표

관련 상담 영역

합동회사 코무라소프트는 실행 제어 환경(AppLocker / App Control for Business)에서 동작하는 업무 앱의 개발·개수, 코드 서명을 포함한 배포·자동 업데이트 설계, 고객 환경에서 앱이 실행되지 않는 현상의 조사를 다루고 있습니다.

• Windows 앱 개발
• 기존 Windows 소프트웨어의 개수·유지보수
• 결함 조사·원인 분석
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

AppLocker는 Pro 에디션에서는 사용할 수 없는 것 아닌가요?

그 상식은 갱신되었습니다. KB 5024351 이후, Windows 10 버전 2004 이후와 모든 Windows 11에서는 AppLocker 정책의 강제 적용에 특정 에디션이 필요하지 않게 되었습니다. 예전의 '그룹 정책 배포를 통한 강제 적용은 Enterprise와 Server 에디션만'이라는 제한이 적용되는 것은 버전 2004보다 오래된 Windows 10과 Windows Server 2019까지입니다(이 경우에도 MDM을 통한 배포라면 모든 에디션에서 사용할 수 있습니다). 중소기업의 Pro 단말이 중심인 환경에서도 이제는 AppLocker가 선택지에 들어갑니다.

코드 서명 증명서는 EV를 사야 하나요?

AppLocker나 App Control for Business의 발행자 규칙이라는 관점에서는, OV(기업 실재 확인)와 EV 어느 증명서든 서명자 정보에 기반한 규칙을 만들 수 있습니다. 참고로 'EV라면 SmartScreen 경고가 처음부터 사라진다'는 이해는 낡은 것으로, 현재는 EV로 서명한 파일도 OV와 마찬가지로 평판의 축적을 전제로 생각할 필요가 있습니다(이 논점은 다른 글 「Windows SmartScreen과 코드 서명」에 정리해 두었습니다). 중요한 것은 증명서의 종류보다, exe뿐 아니라 DLL이나 설치 프로그램을 포함해 모든 바이너리에 일관된 서브젝트로 서명하고, 타임스탬프를 붙이고, 증명서 갱신 시에도 발행자 정보를 안정시키는 것입니다. 발행자 규칙은 그 서명자 정보를 근거로 작성되기 때문에, 릴리스마다 서명 상태가 흔들리면 고객 측 규칙이 깨집니다.

고객 환경에서 자사 앱이 차단된 것 같은데, 로그에서 아무것도 찾을 수 없습니다. 어디를 보면 될까요?

확인해야 할 로그가 두 계통으로 나뉘어 있는 것이 원인인 경우가 많습니다. AppLocker에 의한 exe/DLL 차단은 'AppLocker - EXE and DLL' 로그의 이벤트 8004(감사 모드라면 8003), 스크립트와 MSI는 'AppLocker - MSI and Script' 로그의 8007(감사 모드는 8006)에 나옵니다. 한편 App Control for Business(WDAC)에 의한 차단은 'CodeIntegrity - Operational' 로그의 이벤트 3077(감사 모드라면 3076)에 나오고, 대응하는 서명 정보가 3089에 기록됩니다. 또한 스크립트·MSI·COM이 App Control에 걸린 경우에는 'AppLocker - MSI and Script' 로그의 8029·8036·8040에 나옵니다. 어느 구조가 작동하고 있는지 알 수 없는 상태에서 조사할 때는 CodeIntegrity - Operational과 AppLocker 아래 로그 둘 다를 시각으로 대조해 주십시오.

Smart App Control에서 자사 앱이 차단되지 않으려면 무엇이 필요한가요?

실질적으로는 코드 서명입니다. Smart App Control은 앱을 실행할 때 클라우드 보안 서비스에 의한 안전성 예측과, 앱이 유효한 서명을 가지고 있는지를 확인하여, 악의가 있다고 판정된 앱이나 신뢰를 확인할 수 없는 미서명 앱을 차단합니다. Microsoft도 개발자용 안내로 유효한 증명서로 앱에 서명할 것을 언급하고 있습니다. 다만 서명 알고리즘에 주의가 필요한데, Smart App Control의 서명 검사는 타원 곡선 암호(ECC) 서명을 지원하지 않으며, RSA 기반 증명서로 서명된 앱이 실행을 허용받는 대상입니다. Smart App Control은 기업 관리 기능이 아니라 Windows 11의 개인 이용자를 위한 보호 기능으로, 평가 모드부터 자동으로 활성화·비활성화가 결정되기 때문에, 배포하는 쪽에서는 '서명되지 않은 실행 파일은 개인 PC에서 동작하지 않을 수 있다'는 전제로 다루는 것이 안전합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.