App Control / WDAC Lite: Практичне створення списків дозволених програм для звичайних користувачів

Що на практиці означає «WDAC Lite»

«WDAC Lite» — це не офіційний SKU від Microsoft. Це польовий термін для прагматичного підходу до Windows Defender Application Control
(WDAC), де ви:

• Починаєте в Audit, збираєте реальні дані виконання і лише потім переходите до вимкнення.
• Віддаєте перевагу правилам за видавцем/підписом над крихкими правилами за хешем.
• Використовуєте Managed Installer (коли це можливо), щоб ваш канал розповсюдження ПЗ став рушієм списку дозволених.
• Тримайте площу політики малою: ОС + затверджені канали дистрибуції ПЗ + контрольований аварійний вихід.
• Приймаєте, що «створення списків дозволених» — це процес, а не одноразова налаштування.

Частина «Lite» — філософська: ви намагаєтеся досягти 80% покриття, яке блокує більшість масового шкідливого ПЗ і «drive‑by» інструментів,
не намагаючись змоделювати кожен дивний внутрішній скрипт, кожен крайовий випадок робочої станції розробника чи кожен інсталятор постачальника з 2003 року.

WDAC реалізується через Code Integrity в ОС. Якщо ваша політика каже «ні», це кінець розмови.
Ви не зможете умовити ядро. Це добре. Саме тому вам потрібен план розгортання з урахуванням того, що ви щось важливе заблокуєте.

Цікаві факти та коротка історія

Трохи контексту робить дизайн-рішення менш магічними і більше схожими на накопичений бойовий досвід.

1. WDAC виник з Device Guard (епоха Windows 10), який прагнув використовувати віртуалізаційні механізми безпеки для зміцнення виконання коду.
2. AppLocker з’явився першим і все ще широко застосовується, але WDAC працює на нижчому рівні (Code Integrity), що змінює те, що може його обходити.
3. Списки дозволених існували раніше за сучасні EDR; ранні корпоративні продукти для allow‑listing були популярними, бо сигнатурний AV програвав у масштабі.
4. Керівництво Microsoft змінилося з часом: від «жорстко закрийте» до більш практичних поетапних розгортань з аудитом на першому місці.
5. Підписаний код не завжди безпечний; атаки на ланцюги постачання зловживали валідними підписами, тому довіра має бути обмежена (видавець + продукт) де можливо.
6. PowerShell не завжди був стандартним інструментом адміністратора; коли він став повсюдним, контроль скриптів став ключовим драйвером сучасного контролю додатків.
7. Політики CI можна доставляти різними шляхами (MDM/Intune, групова політика, образи, локальні інструменти), і механізм доставки стає частиною історії надійності.
8. Правила за хешем історично популярні, бо вони «просто працюють» в пілотах — до першого автооновлення, яке підірве ваші вихідні дні.
9. Managed Installer — це соціотехнічний контроль: він працює найкраще, коли в організації дійсно використовують кероване розповсюдження ПЗ замість «просто запустити EXE».

Ментальна модель: що дозволяється, що відкидається й чому

WDAC — це рішення про довіру, а не про шляхи файлів

Якщо ви бачили контролі на основі шляхів, ви знаєте трагедію: «Дозволяємо лише C:\Program Files\» і раптом шкідливе ПЗ живе в
C:\Program Files\TotallyLegit\. WDAC розроблено для використання сильніших ідентифікаційних сигналів:

• Правила за видавцем/підписом: «Дозволити бінарні файли, підписані цим видавцем (можна звузити за продуктом/версією).»
• Правила за хешем: «Дозволити цей точний файл.» Надійно й крихко одночасно.
• Правила за шляхом: існують, але їх слід використовувати обережно й цілеспрямовано.
• Managed Installer: «Дозволяти те, що пройшло через цей канал інсталятора.» Це спосіб зробити інструмент розгортання частиною довіри.

Режим аудиту не опціональний

Режим «Enforced» — це місце, де ви маєте рацію. Режим «Audit» — це місце, де ви вчитеся. В аудиті WDAC реєструє те, що він би заблокував.
Це ті дані, які потрібні вам, щоб створити список дозволених, що відповідає реальності, а не архітектурній фантазії.

Є двоє ворогів: шкідливе ПЗ і власний ІТ‑ландшафт

Шкідливе ПЗ діє опортуністично. Ваша підприємство… творче. Бізнес‑застосунки з неподписаними DLL, драйвери принтерів від постачальника, який вважає SHA1 достатнім,
«тимчасовий» інструмент адміністратора, що став постійним три роки тому. WDAC перемагає, коли ви агресивно стандартизуєте шляхи виконання та доставку ПЗ.

Цитата, що тримає вас чесними

«Сподівання — не стратегія.» — перефразована ідея, яка часто цитується в операційних колах, пов’язана з мисленням про надійність.

У випадку WDAC «сподівання» виглядає так: «Я думаю, що всі інструменти служби підтримки підписані.» Або: «Я впевнений, що VPN‑клієнт не залишить неподписаний допоміжний бінарник.»
Ви не хочете дізнаватися правду в режимі Enforced.

Жарт №1: створення списків дозволених — як дієта: все добре, поки ви не дізнаєтеся, що користувачі вважають «перекусом».

Як побудувати політику без ненависті до життя

Почніть із бази, яку можна захистити

Патерн WDAC «Lite», який працює в більшості підприємств:

• Дозвольте компоненти Microsoft Windows (бінарники ОС, вбудовані інструменти).
• Дозвольте підписані Microsoft загальні платформи, від яких ви залежите (Edge, компоненти Office) відповідно до вашого парку.
• Дозвольте ваш канал керованого ПЗ (агент ConfigMgr/Intune як Managed Installer або підписаний внутрішній інсталятор).
• Дозвольте ключових сторонніх видавців, яких ви реально використовуєте (VPN, EDR, агент резервного копіювання, віддалена підтримка).
• Блокуйте виконання в місцях, доступних для запису користувачем, коли це можливо (Downloads, Temp) — не надавайте там довіри.
• Майте аварійний план «break‑glass», який оперативно реалістичний (процедура заміни політики, доступ для відновлення).

Віддавайте перевагу правилам за видавцем; використовуйте хеші як платні одиниці

Правила видавця переживуть оновлення. Правила хеша — ні. Правила хеша все ще корисні для:

• Короткочасних винятків під час реагування на інциденти.
• Разових внутрішніх інструментів, які ніколи не оновлюватимуться (рідко, але буває).
• Термового фіксу критичного інциденту, поки ви не домовитеся з постачальником про підписану збірку.

Managed Installer: суперсила «Lite»

Managed Installer — найприближеніша до «перекласти проблему на когось іншого (в хорошому сенсі)» річ у WDAC.
Якщо ваші інструменти розгортання розумні, ви можете сказати: «Все, що встановлено через того агента, довіряється.»
Тоді ваше allow‑listing стає питанням управління розгортанням, з яким підприємства вже вміють працювати.

Це також навчає корисної дисципліни: якщо користувачі встановлюють випадкові EXE з електронки, WDAC покарає цю поведінку.
Добре. Ви платите за контроль; ви повинні його отримати.

Проєктуйте на постійні зміни, а не на ідеальний день

Ваша політика змінюватиметься. З’являться нові принтери. Критичний додаток оновиться. Постачальник поміняє сертифікати.
Плануйте:

• Передбачуваний ритм оновлення політики.
• Спосіб збирати журнали аудиту централізовано.
• Чіткий процес винятків (хто погоджує, як він кодується, коли закінчується).
• Історію відкату, яка не включає перевстановлення образів на кінцевих точках.

Практичні завдання (команди, виводи, рішення)

Це те, що ви можете зробити сьогодні на Windows‑машині, щоб зрозуміти, що відбувається, перевірити припущення і вивести безпечнішу політику.
Команди використовують PowerShell, бо це Windows, і страждання традиційні.

Завдання 1: Перевірити стан політики WDAC/App Control

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -Property * | Format-List"
SecurityServicesConfigured : {1, 2}
SecurityServicesRunning    : {1, 2}
CodeIntegrityPolicyEnforcementStatus : 1
UsermodeCodeIntegrityPolicyEnforcementStatus : 1
VirtualizationBasedSecurityStatus : 2

Що це означає: Шукайте поля, пов’язані з примусом Code Integrity. Значення статусу змінюються за збіркою, але «1» зазвичай означає, що примус увімкнено для цього виміру.

Рішення: Якщо примус увімкнено, перестаньте гадати і переходьте до журналів подій, щоб побачити, що блокується. Якщо примус вимкнено, ви в аудиті або не розгорнули політику.

Завдання 2: Перевірити, чи ви в режимі Audit або Enforced (з опцій політики)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root\Microsoft\Windows\CI -ClassName CI_ActivePolicy | Select-Object -ExpandProperty Policy | Format-List"
PolicyID   : {d1f4a6aa-1b6a-4e61-9f47-0e1b0d7c9d2a}
FriendlyName : Corp-WDAC-Base
Mode       : Audit
LastUpdate : 2/5/2026 9:12:44 AM

Що це означає: Показує активну політику і чи вона в режимі аудиту чи примусу.

Рішення: Якщо ви ще не в аудиті, переведіть туди перед розширенням охоплення. Якщо ви вже в примусі в пілоті — добре, але тепер потрібен жорсткий моніторинг і відкат.

Завдання 3: Швидко витягнути події аудиту/блокувань WDAC (журнал Code Integrity)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:21:01 AM 3077 Information      Code Integrity determined that a process ... would have been prevented from running ...
2/5/2026 9:20:57 AM 3033 Warning          Code Integrity determined that a process ... did not meet the Store signing level requirements.

Що це означає: Ідентифікатори подій різняться, але ви шукаєте «would have been prevented» (аудит) і «prevented» (примус). Повідомлення зазвичай включає шлях файлу, інформацію про підпис і деталі політики.

Рішення: Визначте найчастіше блоковані бінарники за частотою та впливом на бізнес. Не починайте з «дозволити все, що блокується». Почніть з «чому це взагалі запускається?»

Завдання 4: Відфільтрувати події для конкретного заблокованого виконуваного файлу

cr0x@server:~$ powershell -NoProfile -Command "$needle='AcmeUpdater.exe'; Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'} | Where-Object {$_.Message -like \"*$needle*\"} | Select-Object -First 5 TimeCreated,Id,Message | Format-List"
TimeCreated : 2/5/2026 9:10:11 AM
Id         : 3077
Message    : Code Integrity determined that a process (\Device\HarddiskVolume3\ProgramData\Acme\AcmeUpdater.exe) would have been prevented from running...

Що це означає: Ви знайшли слід події для конкретного бінарника і де він знаходиться (тут: ProgramData, поширене «ой» місце).

Рішення: Якщо він запускається з місць, доступних для запису користувачем або додатком, виправте шлях встановлення або пакування постачальника. Уникайте широких дозволів за шляхом, які благословляють ProgramData загалом.

Завдання 5: Перевірити стан підпису бінарника

cr0x@server:~$ powershell -NoProfile -Command "Get-AuthenticodeSignature -FilePath 'C:\Program Files\Acme\AcmeClient.exe' | Format-List Status,StatusMessage,SignerCertificate"
Status        : Valid
StatusMessage : Signature verified.
SignerCertificate : [Subject]
  CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US

Що це означає: «Valid» — це бажаний стан. «NotSigned» або «UnknownError» пояснюють більшість болю WDAC.

Рішення: Якщо підпис дійсний — віддавайте перевагу правилу видавця. Якщо неподписаний — не поспішайте дозволяти; дізнайтеся, чи існує підписана версія.

Завдання 6: Переглянути деталі ланцюга сертифікатів, щоб безпечно звузити правила видавця

cr0x@server:~$ powershell -NoProfile -Command "$sig=Get-AuthenticodeSignature 'C:\Program Files\Acme\AcmeClient.exe'; $sig.SignerCertificate | Select-Object Subject,Issuer,NotBefore,NotAfter,Thumbprint | Format-List"
Subject    : CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US
Issuer     : CN=DigiCert EV Code Signing CA, O=DigiCert Inc, C=US
NotBefore  : 8/1/2025 12:00:00 AM
NotAfter   : 8/1/2027 11:59:59 PM
Thumbprint : 9F1A0C2B4D6E7F8899AABBCCDDEEFF0011223344

Що це означає: Ротація сертифікатів — реальна річ. Відбитки змінюються, видавці міняють CA. Звуження до відбитка безпечніше, ніж «дозволяти весь підписаний код», але більш крихке, ніж правило видавця.

Рішення: Використовуйте звуження по видавцю/продукту коли можливо. Використовуйте відбитки лише тоді, коли потрібно обмежити постачальника з неідеальними практиками підписування.

Завдання 7: Експортувати політику WDAC для перегляду (XML)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item -Path 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Destination $env:TEMP\ -Force; ConvertFrom-CIPolicy -BinaryFilePath $env:TEMP\SIPolicy.p7b -XmlFilePath $env:TEMP\SIPolicy.xml; Select-String -Path $env:TEMP\SIPolicy.xml -Pattern 'RuleOptions' -Context 0,5"
  <RuleOptions>
    <Option>Enabled:Audit Mode</Option>
    <Option>Enabled:Unsigned System Integrity Policy</Option>

Що це означає: Ви можете побачити, чи ввімкнений режим аудиту та інші опції. (XML об’ємний; зазвичай вас цікавить лише кілька параметрів.)

Рішення: Підтвердіть, що наміри політики відповідають фактичному розгортанню. Якщо ви думали, що вона в примусі, а вона в аудиті — ваш «успіх» уявний.

Завдання 8: Створити початкову політику з референсної машини (стартовий хід)

cr0x@server:~$ powershell -NoProfile -Command "New-CIPolicy -Level Publisher -FilePath C:\Temp\CorpBase.xml -UserPEs -ScanPath 'C:\Program Files','C:\Windows' -Fallback Hash"
Scanning files...
Found 18432 files to be scanned.
Creating policy...
Policy written to C:\Temp\CorpBase.xml

Що це означає: Ви згенерували політику з того, що є на диску. Рівень Publisher намагається побудувати правила по підписах; резервний хеш ловить неподписані випадки.

Рішення: Розглядайте це як чорновик. Видаліть сміття, звузьте широкі дозволи і не відправляйте в світ те, що знайшов скан лише на одній машині.

Завдання 9: Злиття кількох політик (бо реальність — це кілька образів і команд)

cr0x@server:~$ powershell -NoProfile -Command "Merge-CIPolicy -PolicyPaths C:\Temp\CorpBase.xml,C:\Temp\FinanceApps.xml -OutputFilePath C:\Temp\Merged.xml"
Merging 2 policies...
Merge completed successfully.

Що це означає: Ви об’єднали фрагменти політик. Це корисно, коли різні власники додатків валідують різні списки дозволених.

Рішення: Тримайте власність зрозумілою: хто може додавати підписувачів? Якщо це може робити будь-хто, ви випадково дозволите весь інтернет через «корисні» широкі правила видавця.

Завдання 10: Явно увімкнути режим Audit у політиці (перед розгортанням)

cr0x@server:~$ powershell -NoProfile -Command "Set-RuleOption -FilePath C:\Temp\Merged.xml -Option 3"
Updated policy rule options.

Що це означає: Номери опцій правил залежать від інструментів/версії, але це часто переключає режим аудиту в політиці CI.

Рішення: Забезпечте аудит-першим для початкового широкого розгортання. Переходьте в примус тільки після того, як ви опрацюєте топ‑удари аудиту і перевірите критичні робочі процеси.

Завдання 11: Скомпілювати XML у бінарну політику (те, що споживають кінцеві точки)

cr0x@server:~$ powershell -NoProfile -Command "ConvertFrom-CIPolicy -XmlFilePath C:\Temp\Merged.xml -BinaryFilePath C:\Temp\SIPolicy.p7b"
Successfully converted C:\Temp\Merged.xml to C:\Temp\SIPolicy.p7b

Що це означає: Бінарна політика — це те, що розгортається на кінцевих точках.

Рішення: Версіонуйте та підписуйте артефакти політик (принаймні зберігайте контрольні суми). Ставтесь до них як до продакшн‑конфігів, а не «якого‑сь файлу в Downloads у когось».

Завдання 12: Локально розгорнути політику для пілота (обережно)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item C:\Temp\SIPolicy.p7b 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Force; gpupdate /force"
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Що це означає: Ви помістили політику туди, де Code Integrity її шукає, і оновили політику. На деяких системах для повного ефекту може знадобитися перезавантаження.

Рішення: Робіть це лише на лабораторних/пілотних машинах з доступом для відновлення. Ваш план відкату повинен бути «замінити політику на відому‑добру», а не «сподіватися, що користувач не перезавантажиться».

Завдання 13: Перевірити потенційний вектор обходу: виконання з шляхів, доступних для запису користувачем

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl $env:USERPROFILE\Downloads | Select-Object -ExpandProperty Access | Select-Object IdentityReference,FileSystemRights,AccessControlType | Format-Table"
IdentityReference     FileSystemRights              AccessControlType
----------------     ----------------              -----------------
BUILTIN\Users        Modify, Synchronize           Allow

Що це означає: Користувачі можуть змінювати Downloads. Якщо ваша політика випадково дозволяє виконання там (через широке правило шляху), ви створили проблему самому собі.

Рішення: Уникайте широких дозволів за шляхом у місцях, доступних для запису користувачем. Використовуйте правила за підписом і довіру Managed Installer натомість.

Завдання 14: Знайти «найчастіші» блокування в аудиті (приблизний зріз)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' | Where-Object {$_.Id -in 3076,3077,3033} | ForEach-Object { if ($_.Message -match '(\w:.*\.(exe|dll|ps1|msi))') { $matches[1] } } | Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Count,Name | Format-Table -Wrap"
Count Name
----- ----
  112 C:\ProgramData\VendorX\Updater.exe
   87 C:\Windows\Temp\printdriverinstall.exe
   55 C:\Users\jdoe\AppData\Local\Temp\7zS3A2.tmp\setup.exe

Що це означає: Топ‑елементи, які «були б заблоковані». ProgramData і Temp — постійні злочинці.

Рішення: Боріться з ними, змінивши спосіб розгортання (керована інсталяція), оновивши пакети постачальника або видаливши ПЗ. Не «просто дозволяйте Temp». Саме так ви отримуєте дзвінки в інциденти.

Жарт №2: Найшвидший спосіб виявити недокументовані залежності — включити примус у п’ятницю. Будь ласка, не робіть так.

План швидкої діагностики

Коли щось «не запускається» після змін WDAC/App Control, вам потрібно визначити: чи це точно WDAC, що саме було заблоковано,
і яке найвужче безпечне виправлення.

Спочатку: доведіть, що це WDAC (не EDR, не AV, не зламаний інсталятор)

• Перевірте події Code Integrity Operational на наявність останніх повідомлень про «prevented» навколо часу збоju.
• Якщо бачите події, що відповідають шляху бінарника й часові — це WDAC. Якщо ні, перестаньте звинувачувати WDAC і перевірте журнали AppLocker/ASR/EDR.

По‑друге: класифікуйте блокування

• Непідписаний бінарник: поширено для внутрішніх інструментів, застарілих постачальників, side‑loaded DLL.
• Підписано, але не довірено: відсутнє правило видавця, невірна область видавця, ротація сертифікатів.
• Пов’язано зі скриптами: PowerShell, WSH, MSI‑custom‑actions або підписаний хост, що завантажує неподписаний контент.
• Неправильне місце: виконуваний файл розміщено в Temp/Downloads інсталятором/оновлювачем.

По‑третє: вирішіть найменш ризикове відновлення

1. Віддавайте перевагу зміні шляху доставки (встановити правильно, припинити запуск з Temp) над розширенням довіри політики.
2. Віддавайте перевагу правилу видавця (звуженому) над правилом за хешем.
3. Якщо мусите використати хеш, встановіть строк дії: відстежуйте його і видаляйте після того, як постачальник виправить пакування.
4. Перевірте на канарі перед широким оновленням політики.

Підказки щодо вузьких місць (що сповільнює)

• Якщо у вас немає централізованого збору логів для подій CI, ваш вузький прохід — це видимість, а не авторинг політики.
• Якщо ви постійно додаєте винятки за хешем, ваш вузький прохід — це ланцюг постачання ПЗ (оновлення без передбачуваного підписування).
• Якщо кожен підрозділ має власні звички інсталяторів, ваш вузький прохід — це управління. WDAC реалізує ту правду, яку ви досі ігнорували.

Три корпоративні міні‑історії з полів

Міні‑історія 1: Збой через невірне припущення

Середня компанія перевела WDAC з аудиту в примус на невеликому наборі «низькоризикових» загальних робочих станцій. Припущення було просте:
кіоски запускали лише браузер і кілька постачальницьких додатків, які «безсумнівно підписані».

Наступного ранку друк на кіосках перестав працювати. Не «інколи». Повністю. Потік заявок на підтримку, і служба підтримки зробила те, що роблять служби підтримки:
перевстановила пакет драйвера принтера. Це погіршило ситуацію, бо інсталятор розпаковував допоміжні виконувані файли в C:\Windows\Temp
і запускав їх звідти. Ці допоміжні файли були неподписані.

Команда мала журнали аудиту, але переглядала лише основні виконувані файли. Вони не подивилися на довгий хвіст: драйвери принтера, допоміжні процеси
та компоненти оновлення. Журнали CI були однозначні: заблоковані файли були ті самі, які інсталятор розміщував у Temp.

Виправлення не було «дозволити Temp». Виправлення — отримати новіший пакет драйверів із підписаними компонентами та коректним місцем розпакування, а потім додати правило видавця для постачальника.
Вони також оновили контрольний список пілота: «друк і сканування — першорядні робочі процеси», бо користувачі вважають їх базовими, а не периферією.

Справжній урок: найнебезпечніші припущення — ті, що звучать нудно. «Драйвери підписані» звучало нудно. Це було неправдою.

Міні‑історія 2: Оптимізація, що обернулася проти

Велике підприємство хотіло прискорити впровадження WDAC. Команда з безпеки запропонувала оптимізацію:
«Давайте дозволимо весь код, підписаний сертифікатом, що ланцюжиться до довіреного кореня, а потім заблокуємо відомо поганий пізніше.»
Звучало ефективно. Також це тихо відновило ту саму проблему, яку має вирішити allow‑listing.

Кілька тижнів усе було добре. Нічого не ламалося. Дашборди були спокійні. Потім розслідування інциденту виявило комерційний інструмент віддаленого доступу,
що працював на кількох кінцевих точках. Інструмент був легітимно підписаний. Ланцюжок підписування був валідний. І через те, що політика фактично казала «підписано = довірено»,
він виконався без тертя.

Ніхто формально «не помилився». Оптимізація працювала як задумано. Проблема була в дизайні.
Вони побудували контроль, який блокував переважно хобі‑шкідливе ПЗ і мало що робив проти екосистеми підписаних, подвійного використання інструментів.

Відновлення було болючим, але прямолінійним: вони звузили правила до видавців відомого ПЗ, увімкнули Managed Installer для санкціонованого розгортання
і трактували «підписано, але не затверджено» як за замовчуванням недовірене. Помилка була не технічною. Це була категорійна помилка: плутання автентичності з авторизацією.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Інша організація вела WDAC з непоказною дисципліною: кожна зміна політики проходила через канарське кільце, і кожне кільце мало власника,
який міг сказати «ні» без політичних наслідків. Вони також тримали артефакт відомої‑доброї політики і скриптований спосіб його заміни.

Постачальник випустив оновлення для VPN‑клієнта. Бінарники були підписані, але постачальник поміняв сертифікат підпису і реорганізував структуру інсталяції.
Журнали аудиту одразу спрацювали в канарському кільці: оновлення порушило б примус.

Оскільки команда мала рутину, реакція була рутиною: відкрити зміну, додати звужене правило видавця для нового підписувача, перевірити на канарі, потім розгорнути.
Ніяких загальних зборів. Ніякого «тимчасового дозволити все». Жодного відкату.

Нудна частина була дисципліна кілець і гігієна артефактів. Результат був захоплюючим у кращому сенсі: нічого не сталося.
В експлуатації «нічого не сталося» — преміальна властивість.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Якийсь додаток не запускається; немає очевидної помилки»

Корінь: WDAC блокує створення процесу. Додаток може мовчки завершитись або показати загальний діалог «не може виконатися».

Виправлення: Перевірте журнали Code Integrity Operational на подію блокування, що відповідає часу/шляху. Додайте звужене правило підписувача або виправте пакування. Уникайте спалаху хешів.

2) Симптом: «В аудиті все працює, в примусі кілька додатків ламаються»

Корінь: Ви ігнорували обсяг аудиту або переглядали лише «основні EXE», а не DLL, допоміжні процеси, драйвери та задачі оновлення.

Виправлення: В аудиті агрегуйте і ранжируйте події за частотою та важливістю для бізнесу. Перевіряйте повні робочі процеси (друк, сканування, VPN, віддалена підтримка, доповнення Office).

3) Симптом: «Оновлювач запускається з ProgramData/Temp і блокується»

Корінь: Інсталятор постачальника розміщує виконувані файли у записуваних місцях; ці файли неподписані або не покриті правилами дозволу.

Виправлення: Отримайте виправлений пакет від постачальника, перемостіть у власне пакування або розповсюдьте через Managed Installer, щоб кінцеві бінарники були довірені. Не давайте широкий дозвіл для Temp.

4) Симптом: «Ми постійно додаємо правила за хешем кожен Patch Tuesday»

Корінь: Ви використовуєте правила хеша для часто оновлюваного ПЗ, або ваш метод генерації політики за замовчуванням використовує хеші через неподписані компоненти.

Виправлення: Перейдіть на правила видавця, коли можливо. Для неподписаних компонентів змусьте постачальників/внутрішніх розробників підписувати. Хеші — лише тимчасові винятки з терміном дії.

5) Симптом: «Підписаний інструмент блокується, хоча він легітимний»

Корінь: Ви дозволили інший обсяг видавця, ніж фактичний підписувач бінарника; ротація сертифіката або інша продуктова лінійка використовує інший сертифікат.

Виправлення: Повторно перевірте деталі Authenticode підпису. Додайте нового підписувача/видавця, звуженого до того постачальника/продукту, який вам потрібен.

6) Симптом: «Оновлення політики нічого не змінило на кінцевих точках»

Корінь: Механізм розгортання не застосувався (MDM синхронізація, GPO не оновився, неправильне розміщення файлу), або ви скомпілювали/розгорнули не той артефакт.

Виправлення: Перевірте активну політику через CIM, переконайтеся, що файл присутній у шляху CodeIntegrity, підтвердіть час оновлення. Трактуйте політику як версійний реліз.

7) Симптом: «Розробники в люті; скрипти та інструменти збірки ламаються»

Корінь: Ви застосували політику для робочих станцій розробників без моделювання toolchain (компілятори, пакетні менеджери, локальні вихідні дані збірки).

Виправлення: Використовуйте окремі кільця/політики. Для dev дозволяйте підписані toolchain і джерела керованої інсталяції, але все одно блокуйте випадкові бінарники з шляхів, доступних для запису користувачем. І: підписуйте внутрішні інструменти.

8) Симптом: «Ми широко дозволили ‘Microsoft’, і тепер сумнівний інструмент запускається»

Корінь: Занадто широка довіра до підписаного коду, поєднана з легітимними, але небезпечними інструментами, підписаними шанованими видавцями.

Виправлення: Звузьте до явних видавців/продуктів, які ви маєте намір дозволити. Використовуйте додаткові контролі (ASR‑правила, EDR) для інструментів подвійного призначення. WDAC — не єдиний ваш запобіжник.

Контрольні списки / покроковий план

Покрокове розгортання, що не закінчується сльозами

1. Визначте мету: блокувати несанкціоновані бінарники в користувацькому просторі; не намагайтеся вирішити всі крайові випадки скриптів в перший день.
2. Налаштуйте видимість журналів: збирайте події Code Integrity Operational централізовано. Якщо не видно — не керуєте.
3. Створіть референсний образ: чиста машина зі стандартним набором додатків. Згенеруйте чорнову політику з нього.
4. Нормалізуйте доставку ПЗ: вирішіть, що вважається «керованою інсталяцією» у вашій організації і забезпечте це соціально та технічно.
5. Увімкніть режим Audit по флоту (або широкому кільцю): не переходьте в примус до як мінімум одного повного циклу патчів.
6. Опрацюйте топ‑удари аудиту: виправте пакування, замініть ПЗ, додайте звужені правила видавця.
7. Визначте процес винятків: хто погоджує, на який термін, які докази потрібні (інформація про підпис, власник бізнесу).
8. Канарське кільце для примусу: невелике кільце з швидкою підтримкою та доступом для відкату. Перевіряйте критичні робочі процеси, а не лише «чи запускається додаток».
9. Прогресивні кільця: розширюйте примус на більші кільця. Очікуйте різного болю: фінансові додатки, інструменти кол‑центру, драйвери виробництва.
10. Дисципліна оновлення політик: контроль змін, версіонування, поетапне розгортання і перегляд журналів після змін.
11. Вимірюйте результати: рахуйте заблоковані несанкціоновані запуски, кількість аварійних винятків, час на усунення блокувань.
12. Тримайте аварійний вихід робочим: протестований план відкату і план відновлення кінцевих точок.

Контроль готовності перед примусом

• Журнали аудиту централізовані й доступні для пошуку.
• Топ‑заблоковані бінарники зрозумілі (що це, хто їх власник, чому вони запускаються).
• Критичні робочі процеси протестовано наскрізь (VPN, друк, віддалена підтримка, інсталяція ПЗ, бізнес‑додатки).
• Артефакти політики версіоновані; ви можете визначити, що розгорнуто на кінцевій точці.
• Процедура відкату протестована на реальному пристрої, а не просто записана у вікі.
• Персонал підтримки знає, як збирати докази CI‑подій і ескалювати з корисними даними.

Аварійний контрольний список «щось не працює»

• Визначте, чи це аудит чи примус на ураженому пристрої.
• Захопіть подію CI Operational, що посилається на заблокований бінарник.
• Перевірте стан підпису бінарника і чи він з безпечного місця.
• Якщо критично для бізнесу, застосуйте найвужчий тимчасовий фікс (хеш‑правило з терміном) поки ви працюєте над довгостроковим правилом видавця або виправленням пакування.
• Оновіть політику в канарі, а потім розгорніть.

Питання та відповіді (FAQ)

1) Чи слабкіше безпека при «WDAC Lite»?

Це інша стратегія: поетапне розгортання, мінімальна необхідна довіра і оперативна життєздатність. Трохи менш сувора політика, але яка реально впроваджена, краща за ідеальну політику, що живе у презентації.

2) Чи варто використовувати замість цього AppLocker?

AppLocker може бути простішим для деяких сценаріїв на основі шляхів і користувача, але примус WDAC на рівні ядра важче обійти. У 2026 році, якщо ви починаєте для корпоративних кінцевих точок, WDAC зазвичай кращий у довгостроковій перспективі.

3) Чому б просто не дозволити все підписане?

Бо «підписане» означає «автентичне», а не «затверджене». Багато легітимних підписаних інструментів також корисні для атакувальників. Дозвольте лише тих видавців/продукти, які ви справді маєте на увазі, а інші трактуйте як недовірені.

4) Який найшвидший спосіб зменшити кількість винятків?

Managed Installer плюс стандартизована доставка ПЗ. Перетворіть «випадковий EXE з електронної пошти» на «запит на програму в каталозі», і політика стане стабільною.

5) Чи виправдані правила за хешем?

Так, як тимчасова пластирка або для рідкісних статичних бінарників. Але якщо ви використовуєте хеші для Chrome/Teams/VPN‑клієнтів, ви створили бігове колесо, і ви — хом’як.

6) Як працювати з постачальниками, які доставляють неподписані компоненти?

По‑перше, наполягайте на підписаних збірках. По‑друге, розгляньте репакування і контроль над тим, де компоненти живуть і хто може там писати. По‑третє, якщо мусите дозволити неподписане, звужуйте це і вважаєте технічним боргом з відповідальним власником і терміном.

7) Що робити, коли сертифікат ротаційований і щось починає блокуватися?

Підтвердіть через інспекцію Authenticode і події CI. Додайте нового підписувача/видавця у політику в аудиті, перевірте на канарі, потім розгорніть. Не «тимчасово дозволяйте весь підписаний код», якщо не хочете потім очищати ці тимчасові дозволи.

8) Чи замінює WDAC EDR/AV?

Ні. WDAC — превентивний контроль виконання. EDR дає виявлення, розслідування, реагування та телеметрію. Потрібні обидва: WDAC зменшує, що може запуститися; EDR допомагає зрозуміти, що намагалося.

9) Як уникнути блокування внутрішніх інструментів розробників?

Розділіть політики за класом пристроїв (розробник vs стандартний користувач). Для dev‑пристроїв дозволяйте підписані toolchain і керовані джерела інсталяції, але все ще блокуйте випадкові бінарники з шляхів, доступних для запису користувачем. І: підписуйте внутрішні інструменти. Це 2026 рік.

10) Яка найменш оцінена частина операцій WDAC?

Гігієна логів і відповідальність. Якщо ніхто не володіє «топ‑заблокованими подіями», політика поступово перетвориться на суп винятків, і ви почнете торгуватися зі своєю ж базовою безпекою.

Практичні наступні кроки

Якщо ви нічого більше не зробите, зробіть ці три речі в такому порядку:

1. Увімкніть режим Audit для значущого кільця і збирайте події Code Integrity централізовано.
2. Виправте топ‑10 блокувань зміною пакування і моделі довіри (правила видавця, керована інсталяція), а не благословляючи Temp.
3. Перейдіть у примус на канарському кільці з протестованим артефактом відкату і людиною на виклику, яка реально може надіслати оновлення політики.

WDAC Lite — це не про боягузтво. Це про виваженість. Ви будуєте систему, яка каже «ні» на межі ядра.
Це потужно, і силу найкраще використовувати з рукописним планом дій, а не на відчуттях.