Ta heqësh frazën e fshehtë të një çelësi apo ta mbash? Kopja që krijon
Një skedar çelësi i paenkriptuar mban të njëjtin sekret nën mbrojtje më të dobët. Krahasoni rrezikun në prehje përpara konvertimit dhe dijeni çfarë nuk zhbën.
Një çelës privat i enkriptuar dhe një i paenkriptuar mbajnë të njëjtin material çelësi. Konvertimi nuk krijon një identitet të ri, nuk rivendos një llogari VPN dhe nuk e bën të pavlefshëm skedarin e vjetër. Ai shkruan një kopje të dytë, dhe ajo kopje mbart një rrezik tjetër në prehje.
Nëse shkëmbimi ia vlen varet nga ku do të jetojë skedari dhe kush mund ta lexojë.
Çfarë ndryshon në të vërtetë konvertimi
Përpara konvertimit, çelësi mbrohet nga një frazë e fshehtë që jep operatori. Pas konvertimit, ai mbrohet nga lejet e sistemit të skedarëve dhe çdo kontroll aksesi rreth skedarit. Kriptografia nuk ka ndryshuar; ka ndryshuar numri i gjërave midis një sulmuesi dhe çelësit. Ky është i gjithë krahasimi.
Një tabelë e bën diferencën konkrete.
| 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 |
Asnjëra formë nuk është automatikisht më e sigurt. Ato dështojnë në mënyra të ndryshme, dhe vetëm një nga ato mënyra lë një zë në regjistër.
Kur është më mirë të mbash frazën e fshehtë
Nëse një klient i mbështetur mund të kërkojë frazën e fshehtë ose ta marrë nga një depo sekretesh e miratuar, konvertimi nuk blen asgjë. Mbani një kopje, një kufi mbrojtjeje dhe një skedar më pak për të ndjekur. Shumica e klientëve VPN që pranojnë çelësa PEM mund ta bëjnë këtë.
Konvertimi është gjithashtu lëvizja e gabuar kur një ekip ndan çelësin. Një skedar i paenkriptuar në një host të përbashkët bëhet një kredencial që kushdo me akses në shell mund ta kopjojë.
Kur një kopje e paenkriptuar justifikohet
Disa shërbime nuk mund të kërkojnë, disa kontejnerë montojnë sekrete vetëm për lexim, dhe disa pajisje lexojnë një skedar çelësi në nisje pa një rrugë interaktive. Në ato raste, një çelës i paenkriptuar brenda një drejtorie të kufizuar si duhet mund të jetë dizajni i mbështetur. Justifikimi është mjedisi, jo komoditeti.
Nëse nuk mund të thuash kush mund ta lexojë skedarin dhe pse, përgjigjja është jo.
Komanda dhe skajet e saj të mprehta
Për një çelës të bazuar në skedar të mbështetur nga OpenSSL 3.5, referenca pkey dokumenton heqjen e frazës së fshehtë dhe një kërkesë interaktive kur hyrja është e enkriptuar dhe nuk jepet asnjë burim fjalëkalimi. Forma minimale është e shkurtër, dhe është e lehtë ta ekzekutosh me pakujdesi.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTre skaje të mprehta. I/O i skedarit të daljes nuk është atomik, kështu që një shteg daljeje ekzistues mund të pritet në mes të shkrimit. Mos e përdorni shtegun e hyrjes si dalje dhe mos eksperimentoni në kopjen e vetme të mbrojtur. Fusni frazën e fshehtë në kërkesë dhe jo në rreshtin e komandës, ku përfundon në historikun e shell.
Kontrolloni rezultatin përpara se të ndryshoni çdo konfigurim VPN: openssl pkey -in new-private-key.pem -pubout duhet të printojë të njëjtin çelës publik që kishit më parë.
Çfarë nuk bën konvertimi
Ai nuk e revokon kopjen e enkriptuar, e cila ekziston ende kudo që e keni lënë. Ai nuk ndryshon fjalëkalimin e llogarisë VPN ose certifikatën. Dhe nuk rregullon një ekspozim që ka ndodhur tashmë. Nëse një çelës ka rrjedhur, zgjidhja është zëvendësimi dhe tërheqja në anën e serverit, jo një ndryshim lokal formati.
Fshijeni me qëllim skedarin e ndërmjetëm dhe konfirmoni që shtegu që fshini është ai që krijuat.