Метки устройств — не учётные данные VPN: три утверждения, которые нужно разделить

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

Три утверждения, которые сливают в одно

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

Файл-маркер хуже серийного номера в одном отношении: скопировать его элементарно, и каждая копия выглядит одинаково убедительно.

Посмотрите, что устройство действительно предъявляет

Посмотрите на учётные данные, которые клиент действительно хранит, прежде чем предполагать, что они относятся к устройству.

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, HasPrivateKey
certutil -store My <thumbprint>

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

Аппаратная защита требует доказательств

Сертификат — публичная информация, поэтому значимый вопрос в том, где живёт закрытый ключ и была ли эта защита подтверждена. Аттестация ключа TPM описывает заявителя, который доказывает удостоверяющему центру, что ключ защищён доверенным TPM, и это сильнее, чем указать в запросе аппаратного поставщика. Это ещё и архитектура с собственными допущениями доверия, а не то, что клиент VPN включает по умолчанию. Подтвердите, что принимает издатель и что шлюз требует в отношении полученных учётных данных, потому что хранение, аттестация и политика допуска — три компонента.

Ключ с аппаратной поддержкой всё равно ничего не говорит об уровне обновлений, текущем назначении или о том, как используется сеанс. Для этого нужны собственные средства контроля.

Сделайте замену и удаление конкретными

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

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