Запросы на правило, по которому подключаться может только одобренный ноутбук, часто заканчиваются записью в межсетевом экране для публичного адреса офиса. Это правило теперь пропускает любое устройство за адресом. Требование и реализация — не одно и то же. Отделите то, чего хочет политика, от того, что может доказать адрес.

Три вопроса в одном запросе политики

Разделите запрос на три части: откуда приходит соединение, какого сервиса оно может достичь и какой компьютер предъявляет учётные данные. Правило адреса источника отвечает на первое, а правило целевого сервиса — на второе. Ни одно не идентифицирует физическую машину, потому что оба работают с сетевыми полями, которые совместно используют многие устройства. Третье требует учётных данных, выданных этому устройству и не допускающих тихого повторного использования.

Запишите три ответа отдельно. Одна строка межсетевого экрана не может удовлетворить требование, в котором названы три.

Что может сказать адрес источника

Трансляция адресов — обычная причина, по которой правило сетевого источника пропускает слишком много. Всё за одним офисным выходом выглядит как один и тот же публичный адрес, поэтому правило даёт доступ всей группе. Фиксированный адрес внутри VPN имеет ту же слабость в другом месте: это назначение, привязанное к сеансу, а не свойство оборудования. Любое устройство с принятыми учётными данными может открыть этот сеанс. Относитесь к адресу как к сетевому ограничению и описывайте его именно так.

Это по-прежнему полезно для ограничения воздействия, и это не аутентификация устройства.

Привяжите доступ к зарегистрированным учётным данным

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

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

Список хранилища показывает сертификат и наличие закрытого ключа, а проверка показывает, ведёт ли цепочка к нужному якорю. Сертификат доказывает владение принятым закрытым ключом в рамках настроенной политики; он не доказывает, на какой физической машине он был, когда этот ключ можно экспортировать и скопировать. Название профиля в честь ноутбука оставляет секрет таким же переносимым, как раньше. Там, где платформа это поддерживает, аппаратно защищённые ключи с политикой аттестации дают более прочную привязку, а регистрация всё ещё должна решить, кто может получить учётные данные.

Проверьте границу, затем планируйте удаление

Оцените два случая: одобренный ноутбук и пользователь должны подключаться, а другое устройство только с учётной записью пользователя — нет. Если проект требует проверки и пользователя, и устройства, убедитесь, что выбранный метод обеспечивает обе в одном сеансе, а не предполагает, что две независимые настройки складываются.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

Отзыв должен удалять принятую идентичность устройства, а работа с активными сеансами заслуживает отдельной проверки. TPM или флаг управляемого устройства не является чистым свидетельством здоровья для каждого процесса на машине.

Запишите сетевое ограничение, учётные данные устройства и решение о регистрации как три контроля с тремя владельцами. Это делает границу проверяемой, и именно этого один адрес никогда не может дать.

Похожие статьи