Удалить парольную фразу ключа или сохранить её? Копия, которую вы создаёте
Незашифрованный файл ключа хранит тот же секрет под более слабой защитой. Сравните риск в состоянии покоя до преобразования и узнайте, что оно не отменяет.
Зашифрованный закрытый ключ и незашифрованный содержат один и тот же ключевой материал. Преобразование не создаёт новую личность, не сбрасывает учётную запись VPN и не делает старый файл недействительным. Оно записывает вторую копию, и эта копия несёт другой риск в состоянии покоя.
Стоит ли обмен того, зависит от того, где будет лежать файл и кто может его прочитать.
Что на самом деле меняет преобразование
До преобразования ключ защищён парольной фразой, которую задаёт оператор. После преобразования его защищают права файловой системы и любой контроль доступа вокруг файла. Криптография не изменилась; изменилось число вещей между злоумышленником и ключом. Вот и всё сравнение.
Таблица делает различие наглядным.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Ни одна из форм не является автоматически безопаснее. Они отказывают по-разному, и только один из этих путей оставляет запись в журнале.
Когда лучше сохранить парольную фразу
Если поддерживаемый клиент может запросить парольную фразу или получить её из одобренного хранилища секретов, преобразование ничего не даёт. Вы сохраняете одну копию, одну границу защиты и на один файл меньше для отслеживания. Большинство VPN-клиентов, принимающих ключи PEM, умеют это делать.
Преобразование также неверный шаг, когда команда делится ключом. Незашифрованный файл на общем хосте становится учётными данными, которые может скопировать любой с доступом к shell.
Когда незашифрованная копия оправдана
Некоторые службы не могут запросить, некоторые контейнеры монтируют секреты только для чтения, а некоторые устройства читают файл ключа при загрузке без интерактивного пути. В таких случаях незашифрованный ключ в правильно ограниченном каталоге может быть поддерживаемым решением. Оправдание — среда, а не удобство.
Если вы не можете сказать, кто может читать файл и почему, ответ — нет.
Команда и её острые края
Для файлового ключа, поддерживаемого OpenSSL 3.5, справка pkey описывает удаление парольной фразы и интерактивный запрос, когда ввод зашифрован и источник пароля не указан. Минимальная форма коротка, и её легко выполнить небрежно.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemТри острых края. Ввод-вывод выходного файла не атомарен, поэтому существующий путь вывода может быть обрезан посреди записи. Не используйте входной путь как выходной и не экспериментируйте на единственной защищённой копии. Вводите парольную фразу в запросе, а не в командной строке, где она попадает в историю shell.
Проверьте результат, прежде чем менять любую конфигурацию VPN: openssl pkey -in new-private-key.pem -pubout должен вывести тот же открытый ключ, который был у вас раньше.
Что преобразование не делает
Оно не отзывает зашифрованную копию, которая по-прежнему существует там, где вы её оставили. Оно не меняет пароль учётной записи VPN или сертификат. И оно не исправляет уже произошедшую утечку. Если ключ утёк, решение — замена и отзыв на стороне сервера, а не локальное изменение формата.
Удалите промежуточный файл намеренно и убедитесь, что удаляемый путь — тот, который вы создали.