Сохранённый пароль VPN: кто может его расшифровать и когда

Клиент VPN, показывающий зашифрованный пароль в своём XML, почти ничего вам не сообщил. Шифротекст отвечает лишь на то, что значение не хранится в виде открытого текста в этом представлении. Кто может его расшифровать, каким ключом и в каком контексте пользователя — это вопросы, которые решают, помогает ли хранение. Ответьте на них, прежде чем называть файл безопасным или небезопасным.

Определите, какой объект хранится

Начните с документированной модели хранения продукта. Клиент может хранить восстановимый пароль, токен или ссылку на хранилище учётных данных, и у каждого варианта разная подверженность. Имя элемента XML не является проектом, а строка, похожая на base64, тоже не доказывает шифрование.

Спросите поставщика или администратора, какой компонент читает значение при подключении.

Затем определите API защиты, если он документирован. В Windows CryptProtectData защищает данные ключом, производным от учётных данных входа шифрующего пользователя, а параметр уровня машины меняет то, кто может расшифровать. Это конкретный пример того, почему область действия важна. Это не доказательство того, что какой-либо клиент VPN использует этот API.

Отделите украденную копию от использования во время работы

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

Именно это различие обычно искажает утверждение об офлайн-файле. Шифрование при хранении может остановить того, кто копирует один файл без учётной записи. Оно не останавливает код, работающий от имени этой учётной записи.

Оба утверждения могут быть верны одновременно, и во время реагирования на инцидент важно второе.

Прочитайте элементы управления доступом, которые действительно применяются

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

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

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

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

Планируйте подверженность вместо проверки расшифровки

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

Если подверженность установлена, смените учётные данные у владельца идентичности.

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

Вопросы для проверки поставщика

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

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

Сохранённые учётные данные — это обмен между удобством и подверженностью. Совершите этот обмен осознанно и запишите, кто его принял.