Проверка состояния устройства по VPN не блокирует? Сначала проследите отчёт
Агент конечной точки сообщает о здоровом состоянии, но внутреннее приложение всё равно открывается. Пройдите сборщик, вердикт и блокировку, а затем докажите отказ одним запросом.
Если ноутбук, чьи антивирусные подписи перестали обновляться несколько недель назад, всё ещё может открыть ваше внутреннее приложение, то документ политики редко оказывается тем, что не так. Три отдельные системы должны согласиться, прежде чем доступ будет отклонён: что-то измеряет конечную точку, что-то превращает это измерение в вердикт разрешить или отказать, а что-то действительно отбрасывает трафик. Когда несоответствующее устройство всё же попадает внутрь, ровно одно из этих звеньев отсутствует или доверяет доказательствам, которым не должно. Проверки ниже идут в этом порядке, и у каждой есть точка остановки.
Блокировка — это последний шаг, а не первый
Аутентификация и состояние устройства отвечают на разные вопросы. Успешный вход доказывает, что были предъявлены учётные данные; он ничего не говорит о программном обеспечении, работающем на машине, которая их предъявила. Именно этот разрыв позволяет скопированному профилю клиента перенести здоровую на вид сессию на нездоровый хост.
У работы над соответствием конечных точек уже есть словарь для этой цепочки. Информационная эталонная модель NEA в RFC 5209 делит задачу на сборщик, этап оценки и точку применения и прямо говорит, что клиент, который лжёт о собственном состоянии, находится вне модели. Эта оговорка важнее схемы: доверенный модуль платформы не превращает самоотчётное измерение в факт.
Держите сборщик честным в отношении охвата. Он должен сообщать атрибуты, которые называет ваша политика, на устройстве, запрашивающем доступ, и мало что ещё. Агент инвентаризации, перечисляющий каждый установленный пакет, — другой инструмент, чем сборщик состояния, и разница одновременно является проблемой хранения и точности. Если отчёт нельзя привязать к одной идентичности устройства, оценщик гадает, какую машину он только что пропустил.
Панель с красным статусом — не контроль. Спросите, до чего всё ещё может добраться отклонённый пользователь: до wiki, до файлового ресурса, до порта базы данных? Исправление требует одной узкой поверхности, а всё остальное принадлежит за блокировкой.
Прочитайте отчёт, прежде чем читать правило
Начните с источника, а не с зелёной галочки клиента. В 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 has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents 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
}
Две детали легко упустить. Сначала повтор: отчёт, снятый пока машина была здорова, нельзя принимать для более поздней сессии на том же устройстве, поэтому ищите временную метку, привязанную к текущему соединению. Затем удаление: удаление агента должно давать тот же отказ, что и устаревший отчёт, а не чистый проход, и именно этот случай чаще всего никогда не проверяют.
Когда матрица совпадает с таблицей, передайте три вещи тому, кто будет вести шлюз дальше: команды, порог и четыре ожидаемых результата. Именно эта передача и есть настоящий результат, потому что проект состояния, живущий только в документе политики, сползает при первом же изменении поля отчётности в инструменте конечной точки.