Где должен храниться закрытый ключ VPN: файл, CNG или TPM?

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

Выберите между копированием и использованием

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

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

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

Согласуйте хранилище с демоном туннеля

Демон ограничивает это сильнее, чем политика безопасности. WireGuard принимает закрытый ключ в base64 из файла или из ввода wg set и не имеет пути в хранилище сертификатов, поэтому ключ интерфейса с поддержкой TPM не рассматривается. OpenVPN, собранный против OpenSSL 3, может загрузить ключ через URI поставщика, а strongSwan поставляет плагин TPM вместе с поддержкой PKCS#11, но оба зависят от того, как собран ваш пакет.

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

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

Инвентаризируйте ключ до переноса

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

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

Последние два дайджеста должны совпадать. Если нет, демон завершает настройку, а затем терпит неудачу при каждой попытке с ошибкой сертификата или подписи, которая не указывает никуда рядом с настоящей причиной. Эквивалент для WireGuard короче, потому что открытый ключ выводится прямо из закрытого: wg pubkey < /etc/wireguard/wg0.key должен вывести ключ пира, который у вашего сервера уже сохранён.

Права доступа относятся к той же инвентаризации. stat -c '%a %U:%G' /etc/wireguard/wg0.key должен вернуть 600 root:root, а всё, что читается группой или всеми, означает, что ключ уже был доступен процессам, которых вы не задумывали.

Проверьте хранилище и путь использования

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

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

В Windows первая команда перечисляет личное хранилище и печатает поставщика ключа рядом с каждой записью, и там всплывает сертификат, который выглядит аппаратно защищённым, но лежит в программном поставщике. Вторая перечисляет ключи, которыми владеет платформенный криптопоставщик, поэтому идентичность VPN, отсутствующая там при наличии сертификата, означает, что закрытая половина живёт в другом месте. На шлюзе Linux ipsec listcerts сообщает, что загрузил strongSwan, включая ключи из плагина TPM. Сравнивайте отпечатки или хеши открытых ключей с инвентаризацией, а не доверяйте числу записей.

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

Запишите обновление и откат

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

Проверяйте истечение, пока оно не стало сбоем: openssl x509 -in vpn.crt -noout -checkend 2592000 завершается с ненулевым кодом, когда сертификат истекает в течение тридцати дней, поэтому строка прямо встраивается в проверку мониторинга. Еженедельный запуск этой строки ловит обновление, которое никто не запланировал.

Удаление происходит на сервере: удалите пира или отзовите серийный номер, затем подтвердите, что туннель отказывает, поскольку клиент с кэшированной сессией может некоторое время скрывать наполовину выполненный отзыв. Отзыв должен доходить и до пути CRL или OCSP концентратора, а не только до базы данных CA. Сертификат — публичный документ, и профиль RFC 5280 описывает, как он проверяется; ничто в этой проверке не защищает закрытый ключ, скопированный до ротации.

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