Fjern en nøgleadgangsfrase eller behold den? Kopien, du opretter
En ukrypteret nøglefil gemmer den samme hemmelighed bag svagere beskyttelse. Sammenlign risikoen i hvile, før du konverterer, og vid, hvad det ikke fortryder.
En krypteret privat nøgle og en ukrypteret en rummer det samme nøglemateriale. Konvertering skaber ikke en ny identitet, nulstiller ikke en VPN-konto og ugyldiggør ikke den gamle fil. Den skriver en anden kopi, og den kopi bærer en anden risiko i hvile.
Om byttet er værd at gøre, afhænger af, hvor filen skal ligge, og hvem der kan læse den.
Hvad konvertering egentlig ændrer
Før konvertering beskyttes nøglen af en adgangsfrase, som operatøren angiver. Efter konvertering beskyttes den af filsystemtilladelser og den adgangskontrol, der omgiver filen. Kryptografien er ikke ændret; antallet af ting mellem en angriber og nøglen er. Det er hele sammenligningen.
En tabel gør forskellen konkret.
| 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 |
Ingen af formerne er automatisk sikrere. De fejler på forskellige måder, og kun én af de måder efterlader en logpost.
Hvornår det er bedre at beholde adgangsfrasen
Hvis en understøttet klient kan spørge om adgangsfrasen eller hente den fra et godkendt hemmeligt lager, køber konvertering intet. Du beholder én kopi, én beskyttelsesgrænse og én fil mindre at holde styr på. De fleste VPN-klienter, der accepterer PEM-nøgler, kan gøre dette.
Konvertering er også det forkerte træk, når et team deler nøglen. En ukrypteret fil på en delt vært bliver en adgangsoplysning, som enhver med shell-adgang kan kopiere.
Hvornår en ukrypteret kopi er berettiget
Nogle tjenester kan ikke spørge, nogle containere monterer hemmeligheder skrivebeskyttet, og nogle apparater læser en nøglefil ved opstart uden en interaktiv vej. I de tilfælde kan en ukrypteret nøgle i en korrekt begrænset mappe være det understøttede design. Begrundelsen er miljøet, ikke bekvemmelighed.
Hvis du ikke kan angive, hvem der kan læse filen, og hvorfor, er svaret nej.
Kommandoen og dens skarpe kanter
For en filbaseret nøgle, der understøttes af OpenSSL 3.5, pkey-referencen dokumenterer fjernelse af adgangsfrasen og en interaktiv forespørgsel, når inputtet er krypteret, og der ikke er angivet en adgangskilde. Den minimale form er kort, og den er let at køre uforsigtigt.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTre skarpe kanter. Udfilens I/O er ikke atomær, så en eksisterende udstigning kan blive afskåret midt i skrivningen. Brug ikke inputstien som output, og eksperimentér ikke med den eneste beskyttede kopi. Indtast adgangsfrasen ved forespørgslen i stedet for på kommandolinjen, hvor den ender i shell-historikken.
Kontroller resultatet, før du ændrer nogen VPN-konfiguration: openssl pkey -in new-private-key.pem -pubout bør udskrive den samme offentlige nøgle, som du havde før.
Hvad konvertering ikke gør
Den tilbagekalder ikke den krypterede kopi, som stadig findes, hvor du end efterlod den. Den ændrer ikke VPN-kontoens adgangskode eller certifikatet. Og den reparerer ikke en eksponering, der allerede er sket. Hvis en nøgle er lækket, er løsningen udskiftning og tilbagekaldelse på serversiden, ikke en lokal formatændring.
Slet mellemfilen med vilje, og bekræft, at den sti, du sletter, er den, du oprettede.