Visual Studio зазвичай запускається вдома, потім той самий ноутбук підключається до корпоративного тунелю, і кожен запуск півхвилини висить на заставці. Приберіть політику — і затримка зникне разом із нею; приберіть тунель — станеться те саме. Обидва спостереження правильні, тому два компоненти постійно звинувачують один одного. Вирішальне питання: запит відкликання сертифіката чекає на шлях, який дає лише тунель, чи взагалі не знаходить його.

Вимірюйте завантаження, а не запуск

Одна політика WDAC, розгорнута як підписаний SiPolicy.p7b, вирішує, які образи можуть виконуватися на машині. Цілісність коду перевіряє ланцюжок підписів образу перед виконанням, і ця перевірка може містити питання про відкликання. Відповідь залежить від точки розповсюдження CRL або відповідача OCSP, який сертифікат називає всередині себе.

Це звичайні мережеві запити, тож їхня вартість залежить від того, де розташований відповідач. Коли він доступний лише через тунель або його ім'я розв'язується лише через DNS-сервер за тунелем, перевірка чекає, доки тунель буде готовий. Visual Studio під час запуску завантажує велику кількість підписаних збірок і розширень, і невелика затримка на кожен образ стає помітною зупинкою. Нічого не пошкоджено, і політика поводиться точно так, як налаштована, тому видалення політики виглядає як виправлення.

Кожен підписаний образ може спричинити мережевий виклик

Почніть із підписаного бінарного файлу, який уже є на диску, і попросіть платформу перевірити його з тією ж поведінкою завантаження, яку використовує запуск. Виконайте команду один раз у тунелі й один раз поза ним, потім порівняйте рядки завантаження, а не остаточний вердикт.

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

Вивід перелічує ланцюжок, адреси CRL і OCSP та те, чи кожне завантаження вдалося. Відповідач, який у тунелі вичерпує час, а поза ним відповідає, — це потрібний доказ, і він важить значно більше, ніж враження про повільність. Якщо завантаження вдається повільно, запишіть адресу, щоб наступний крок міг перевірити цей хост напряму.

Розв'яжіть ім'я хоста відповідача й перевірте доступність поза застосунком, бо ім'я, яке не розв'язується, ніколи не виправить налаштування клієнта. Операційний журнал CodeIntegrity дає другу половину доказів, пов'язуючи подію перевірки з часом повільного запуску.

Скоротіть затримку, не прибираючи контроль

Вимкнення політики або переведення її в режим аудиту прибирає затримку й знімає контроль, розгорнутий організацією, тож вважайте це неправильним виправленням. Вужчі варіанти — зміна маршрутизації, щоб відповідач був доступний через тунель, виняток у розділеному тунелі для хостів відповідача, виправлення DNS, коли ім'я розв'язується в недосяжну адресу, або підтримуваний кешувальний проксі для даних відкликання. Кожен має іншого власника: команда PKI відповідає за доступність відповідача, мережева команда — за поділ тунелю, а команда кінцевих точок — за політику.

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

Після зміни перевірте холодний запуск

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

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Виправлена конфігурація все ще звертається до відповідача або використовує кешувальний шлях, схвалений вашою командою PKI, а журнал показує, що перевірка завершується, а не спливає за часом. Підтвердьте, що нещодавно підписаний застосунок досі запускається, бо політика, яка дозволяє все, не є успішним виправленням. Перевірте також теку активної політики й стан застосування, щоб було відомо, що політика, яку ви налагоджуєте, — та, яка працює. Тримайте ланцюжок сертифікатів, адресу відповідача й позначки часу запуску в одному тікеті, бо поновлення зазвичай переміщує відповідача й залишає правило винятку або DNS застарілим.

Схожі статті