Видалити парольну фразу ключа чи зберегти її? Копія, яку ви створюєте
Незашифрований файл ключа зберігає той самий секрет під слабшим захистом. Порівняйте ризик у стані спокою до перетворення і знайте, що воно не скасовує.
Зашифрований закритий ключ і незашифрований містять той самий ключовий матеріал. Перетворення не створює нової особи, не скидає обліковий запис 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 або сертифікат. І воно не виправляє вже наявний витік. Якщо ключ витік, рішення — заміна та відкликання на боці сервера, а не локальна зміна формату.
Видаліть проміжний файл навмисно і переконайтеся, що шлях, який ви видаляєте, — той, який ви створили.