Eliminați fraza de acces a unei chei sau o păstrați? Copia pe care o creați
Un fișier de cheie necriptat păstrează același secret sub o protecție mai slabă. Comparați riscul în repaus înainte de conversie și aflați ce nu anulează.
O cheie privată criptată și una necriptată conțin același material de cheie. Conversia nu creează o identitate nouă, nu resetează un cont VPN și nu invalidează fișierul vechi. Ea scrie o a doua copie, iar acea copie poartă un risc în repaus diferit.
Dacă schimbul merită depinde de locul în care va sta fișierul și de cine îl poate citi.
Ce schimbă de fapt conversia
Înainte de conversie, cheia este protejată de o frază de acces furnizată de operator. După conversie, este protejată de permisiunile sistemului de fișiere și de orice control de acces din jurul fișierului. Criptografia nu s-a schimbat; numărul de lucruri dintre un atacator și cheie s-a schimbat. Aceasta este întreaga comparație.
Un tabel face diferența concretă.
| 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 |
Niciuna dintre forme nu este automat mai sigură. Ele eșuează în moduri diferite, și doar unul dintre aceste moduri lasă o intrare în jurnal.
Când este mai bine să păstrați fraza de acces
Dacă un client acceptat poate cere fraza de acces sau o poate prelua dintr-un depozit de secrete aprobat, conversia nu cumpără nimic. Păstrați o copie, o singură graniță de protecție și un fișier mai puțin de urmărit. Majoritatea clienților VPN care acceptă chei PEM pot face acest lucru.
Conversia este și mișcarea greșită când o echipă partajează cheia. Un fișier necriptat pe un host partajat devine o acreditare pe care oricine are acces la shell o poate copia.
Când este justificată o copie necriptată
Unele servicii nu pot cere, unele containere montează secrete numai pentru citire, iar unele aparate citesc un fișier de cheie la pornire fără o cale interactivă. În acele cazuri, o cheie necriptată într-un director bine restricționat poate fi proiectul acceptat. Justificarea este mediul, nu confortul.
Dacă nu puteți spune cine poate citi fișierul și de ce, răspunsul este nu.
Comanda și marginile ei ascuțite
Pentru o cheie bazată pe fișier acceptată de OpenSSL 3.5, referința pkey documentează eliminarea frazei de acces și o solicitare interactivă atunci când intrarea este criptată și nu se furnizează nicio sursă de parolă. Forma minimă este scurtă, și este ușor să o executați neglijent.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTrei margini ascuțite. Operațiile de I/O ale fișierului de ieșire nu sunt atomice, așa că o cale de ieșire existentă poate fi trunchiată la mijlocul scrierii. Nu folosiți calea de intrare ca ieșire și nu experimentați pe singura copie protejată. Introduceți fraza de acces la solicitare, nu pe linia de comandă, unde ajunge în istoricul shell-ului.
Verificați rezultatul înainte de a modifica orice configurație VPN: openssl pkey -in new-private-key.pem -pubout ar trebui să afișeze aceeași cheie publică pe care o aveați înainte.
Ce nu face conversia
Nu revocă copia criptată, care încă există oriunde ați lăsat-o. Nu schimbă parola contului VPN sau certificatul. Și nu repară o expunere care s-a produs deja. Dacă o cheie a scăpat, soluția este înlocuirea și revocarea pe partea serverului, nu o schimbare locală de format.
Ștergeți intenționat fișierul intermediar și confirmați că calea pe care o ștergeți este cea pe care ați creat-o.