Перевірка стану пристрою через VPN не блокує? Спершу простежте звіт

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

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

Блокування — це останній крок, а не перший

Автентифікація й стан пристрою відповідають на різні питання. Успішний вхід доводить, що було пред'явлено облікові дані; він нічого не каже про програмне забезпечення, яке працює на машині, що їх пред'явила. Саме цей розрив дозволяє скопійованому профілю клієнта перенести здоровий на вигляд сеанс на нездоровий хост.

Робота над відповідністю кінцевих точок уже має словник для цього ланцюга. Інформаційна еталонна модель NEA в RFC 5209 ділить завдання на збирач, етап оцінювання й точку застосування і прямо каже, що клієнт, який бреше про власний стан, перебуває поза моделлю. Це застереження важливіше за схему: довірений модуль платформи не перетворює самозвітне вимірювання на факт.

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

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

Прочитайте звіт, перш ніж читати правило

Почніть із джерела, а не із зеленої позначки клієнта. У Windows локальне вимірювання береться з Defender або з продукту, який зареєструвався в Security Center, і обидва читаються без консолі постачальника:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

Друга команда повертає ціле число з назвою productState. Його біти задокументовані слабко, і постачальники по-різному пакують прапорці ввімкнення й актуальності, тому підтверджуйте його, а не розбирайте. Пакунки третіх сторін також залишають запис у Security Center після видалення, і він повідомляє про програмне забезпечення, якого більше немає на диску.

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

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

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

Перетворіть кожен стан пристрою на письмовий вердикт

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

Evidence the assessor hasVerdictWhat it protects against
Timestamp inside the policy window, protective service runningAdmit to normal applicationsNothing yet; the other checks still apply
Timestamp older than the windowDeny, admit remediation page onlySignature rollback and dormant laptops
Service disabled or reporting offDeny, escalate to the endpoint ownerAn agent reporting stale success
No report at all for this sessionTreat as deny, never as healthyAgents that fail open under load

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

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

Перевірте шлях застосування запитом, а не панеллю

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

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Відповідь 200 від пристрою, який мав бути заблокований, означає, що рішення так і не дійшло до шляху даних. Дві звичайні причини: політика прив'язана до групи, до якої тестовий обліковий запис ніколи не вступав, або застосунок доступний маршрутом, яким VPN не володіє.

Спершу перевірте припущення про маршрутизацію. Якщо внутрішнє ім'я розв'язується в адресу, до якої клієнт уже доходить через локальну LAN, тунель не має значення і жодна політика не застосується. Порівняйте цю адресу з маршрутом, який просуває шлюз. У OpenVPN політика для кожного клієнта живе у файлах, ключем яким слугує спільне ім'я, тому її легко перевірити:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Файл, що містить disable, повністю відключає цього клієнта, тоді як рядок push "route ..." звужує те, до чого він може дістатися. І те, і те — застосування, і те, і те видно кожному, хто налагоджує звіт.

Перевірте чотири випадки на одному тестовому обліковому записі

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

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

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

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

Схожі статті