Збережений пароль VPN: хто може його розшифрувати і коли

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

Визначте, який об'єкт зберігається

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

Запитайте в постачальника або адміністратора, який компонент читає значення під час підключення.

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

Відокремте викрадену копію від використання під час роботи

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

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

Обидва твердження можуть бути правдивими одночасно, і під час реагування на інцидент важливе друге.

Прочитайте засоби контролю доступу, які справді застосовуються

Перевірте ACL файлу та каталогу над ним, а не лише режим файлу. У Windows порівняйте дійсні дозволи профілю користувача з дозволами служби або запланованого завдання клієнта. Секрет, захищений для одного користувача, не стає автоматично захищеним від адміністратора і не стає автоматично йому доступним.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Запишіть, яка ідентичність запускає клієнт, бо саме ця ідентичність є суб'єктом розшифрування.

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

Плануйте вразливість замість перевірки розшифрування

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

Якщо вразливість встановлено, змініть облікові дані у власника ідентичності.

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

Питання для перевірки постачальника

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

Зберігайте відповіді разом із записом про розгортання, щоб наступний перевіряльник не повторював цю вправу.

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