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

「고객 PC에 설치했더니 앱이 시작되지 않습니다. 더블클릭해도 아무 것도 나오지 않습니다」──수탁 개발한 Windows 앱 배포에서 이런 문의가 늘어나고 있습니다. 원인을 살펴보면, 오류 대화상자조차 띄우지 않고 앱을 멈추고 있던 것은 고객 측에 도입이 진행 중인 애플리케이션 실행 제어였습니다.

Windows에는 정한 앱만 실행시키기 위한 메커니즘이 여러 개 있습니다. AppLocker, App Control for Business(오랫동안 WDAC=Windows Defender Application Control로 불리던 것), 그리고 개인용 Smart App Control입니다. 보안 대책 맥락에서는 「도입하는 쪽」 설명이 많지만, 이 기사는 관점을 바꿔 앱을 만들어 배포하는 쪽에서 정리합니다. 자사 업무 앱이 고객 환경에서 차단되는 전형 패턴, 차단되었을 때 어느 로그를 보면 확정할 수 있는지, 그리고 개발·배포 측에서 먼저 취할 수 있는 대책입니다. 함께, 자사 PC에 도입을 검토하는 정보시스템 관점의 요점도 정리합니다.

1. 먼저 결론

• 실행 제어는 네 가지를 구분해 생각합니다. 경고하고 선택하게 하는 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이 그에 해당합니다. ⁴⁵

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 36건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 네 가지 메커니즘을 구분한다

먼저 전체 지도입니다. 이름이 비슷해 혼동되기 쉬우므로, 「누가」「어떤 단위로」「어떻게 동작하는지」로 나눕니다.

2.1. SmartScreen ── 유일하게 「경고」로 멈추는 메커니즘

SmartScreen은 「평판이 나쁜 것을 경고하는」 메커니즘이며, 기본값에서는 사용자가 우회할 수 있습니다. 다만 관리되는 환경에서는 경고 우회 자체를 금지하는 정책이 켜져 있는 경우가 있고, 그 경우에는 SmartScreen도 실질적으로 차단으로 동작합니다(이 이야기는 「Windows SmartScreen과 코드 서명」에서 다루었습니다).

배포하는 쪽에서 본 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 Installer·스크립트·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)에 의한 평가, 설치를 시작한 프로세스(managed installer), 파일 경로(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의 실행 정책과 스크립트 서명」).

참고로 「AppLocker - MSI and Script」 로그는 Windows Server Core 에디션에는 존재하지 않습니다. ⁵ 서버에 배치한 앱을 조사할 때는 염두에 두십시오.

5. 배포하는 쪽의 대책 ── 규칙을 「쓰기 쉬운」 앱으로 만든다

차단된 뒤에 대응하는 것이 아니라, 고객의 정보시스템이 안정된 허용 규칙을 작성할 수 있는 상태로 배포하는 것이 정석입니다. 할 일은 많지 않습니다.

1. 모든 바이너리에 Authenticode 서명한다. exe뿐 아니라 자사 빌드 DLL, 설치 프로그램(MSI/setup 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. 게시자 정보와 파일의 버전 리소스를 안정시킨다. 인증서를 갱신할 때 subject(조직 이름)가 바뀌면 게시자 규칙이 깨집니다. 회사명 표기·인증서 취득처를 바꾸는 경우에는 고객에 대한 사전 통지를 릴리스 노트에 넣으십시오. 또 하나 놓치기 쉬운 점은, 게시자 규칙의 「제품 이름」「원래 파일 이름」「버전」이 인증서가 아니라 각 파일의 버전 리소스(어셈블리 정보)에서 취해진다는 것입니다. 이 필드를 비우거나, 릴리스마다 제품 이름이나 실행 파일 이름을 바꾸면, 서명자가 같아도 제품·파일 단위로 좁힌 규칙은 깨집니다.
4. 실행 파일 위치를 표준에 맞춘다. Program Files 아래에 설치하고, 실행 시 %TEMP%나 %APPDATA%로 exe/DLL을 풀어 시작하는 설계를 그만둡니다. 쓰기 가능한 장소에서 실행하는 설계는 경로 규칙형 환경과 근본적으로 궁합이 나쁘기 때문입니다.
5. 자동 업데이트 설계를 다시 본다. 업데이트 프로그램 자체에도 서명하고, 업데이트가 「서명된 바이너리를 서명된 바이너리로 교체하는」 닫힌 흐름이 되도록 합니다. Intune이나 Configuration Manager로 배포되는 경우, 고객 측이 그 배포 에이전트를 managed installer로 구성해 두었다면 설치 프로그램을 통해 들어간 바이너리를 허용하는 운용이 가능해집니다. 자동으로 동작하는 것이 아니라 관리자 측의 명시적 구성이 전제이지만, 무인 설치에 대응한 MSI를 마련해 두면 그 선택지를 고객에게 넘길 수 있습니다(자동 업데이트의 안전 설계는 「자동 업데이트의 보안」).
6. 차단 시의 정보 제공을 준비해 둔다. 서명의 subject, 실행에 필요한 바이너리 목록, 설치 경로를 「도입 절차서」에 명시해 두면, 고객의 정보시스템은 그것만으로 규칙을 작성할 수 있습니다. 문제 시에는 4장의 이벤트 ID를 지정해 확인을 요청하면 왕복이 한 번에 끝납니다.

이 6가지는 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도 설치 프로그램도 같은 명령으로 서명할 수 있으므로, 빌드 마지막에 한꺼번에 거는 것이 확실합니다.

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

• 회사명 표기를 바꿨다(예: 인증서 subject를 Komura Soft LLC에서 合同会社小村ソフト로 변경했다). 같은 회사이더라도 문자열이 다르면 다른 게시자입니다.
• CA를 바꿨다. App Control의 Publisher 수준 규칙은 「중간 CA(PCA) 인증서 + 리프 인증서의 CN」 조합이므로, CA가 바뀌면 PCA가 바뀌어 일치하지 않게 됩니다. ⁷
• 실행 파일 이름이나 제품 이름을 바꿨다. FilePublisher 수준 규칙에는 이들에 더해 원래 파일 이름(OriginalFileName)과 최소 버전이 포함됩니다. ⁷

어느 쪽이든 증상은 같고, 업데이트 버전으로 교체한 순간부터, 그 환경에서만 앱이 시작되지 않는다는 형태로 나옵니다. 게다가 고객 쪽에서 보면 「업데이트했더니 깨졌다」이므로, 원인이 서명에 있다고는 알아채지 못합니다. 인증서를 갱신·변경할 때는 신구 서명 정보(subject, 발급 CA)를 나란히 적은 안내를 릴리스 노트에 싣고, 고객의 정보시스템이 규칙을 추가할 수 있게 하십시오.

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

자사 PC에 실행 제어를 넣는 쪽의 절차는, 이 기사의 범위에서는 요점만 적습니다.

1. 기술을 고른다. 원칙은 App Control for Business. 사용자 단위 제어가 필요한 공유 PC나 오래된 OS가 혼재하는 환경에서는 AppLocker를 병용합니다. ² 키오스크 단말과 같은 고정 용도 PC는 먼저 셸 제한(「키오스크 모드와 할당된 액세스」)으로 좁힌 뒤에 생각하면 규칙이 단순해집니다.
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 Installer, 스크립트, 패키지 앱) 「구성」에 체크하고 「감사만」을 고릅니다. 함께 각 컬렉션에 기본 규칙을 만들고, 대상 단말에서 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 cmdlet으로 설정합니다), 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를 보호했습니다」가 나오는 이유
• 자동 업데이트의 보안 설계 - HTTPS만으로는 부족한 이유
• Windows 앱 배포 방식 고르기 - MSI/MSIX/ClickOnce/xcopy/독자 업데이트
• PowerShell의 실행 정책과 스크립트 서명 ── 「Bypass로 덮어 두는」 운용에서 졸업하는 실무 가이드
• Windows Defender의 오탐(False Positive) 대응 가이드
• Windows의 키오스크 모드와 할당된 액세스
• 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과 설치 프로그램까지 포함한 모든 바이너리에 일관된 subject로 서명하고, 타임스탬프를 붙이며, 인증서 갱신 시에도 게시자 정보를 안정적으로 유지하는 것입니다. 게시자 규칙은 그 서명자 정보를 바탕으로 작성되므로, 릴리스마다 서명 상태가 흔들리면 고객 측 규칙이 깨집니다.

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

봐야 할 로그가 두 계통으로 나뉘어 있는 것이 원인인 경우가 많습니다. 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.