Мітки пристроїв — не облікові дані VPN: три твердження, які треба розділити

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

Три твердження, які зливають в одне

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

Файл-маркер гірший за серійний номер в одному відношенні: скопіювати його елементарно, і кожна копія виглядає однаково переконливо.

Подивіться, що пристрій справді пред'являє

Подивіться на облікові дані, які клієнт насправді зберігає, перш ніж припускати, що вони стосуються пристрою.

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

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

Апаратний захист потребує доказів

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

Ключ з апаратною підтримкою все одно нічого не каже про рівень оновлень, поточне призначення або те, як використовується сеанс. Для цього потрібні власні засоби контролю.

Зробіть заміну та видалення конкретними

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

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