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ă.

FormWhat protects itHow it fails
Encrypted keyA passphrase plus file accessWeak passphrase, or an offline attack on the file
Unencrypted keyFile permissions and host security onlyAny 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.pem

Trei 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.

Articole similare