Unde ar trebui să locuiască o cheie privată VPN: fișier, CNG sau TPM?

Două întrebări decid unde își are locul o cheie privată VPN: dacă materialul cheii poate fi copiat de pe gazdă și dacă un proces o poate folosi fără nimeni la tastatură. Eticheta de marketing a unui depozit nu răspunde la niciuna. Un demon de tunel care trebuie să revină după o repornire are nevoie de utilizare nesupravegheată, ceea ce exclude tot ce depinde de un PIN tastat de un om.

Alegeți între copiere și utilizare

Copierea și utilizarea eșuează diferit, așa că tratați-le ca două cerințe în loc de una. Un atacator care poate citi octeții cheii duce identitatea pe altă gazdă, iar mașina originală nu observă. Un atacator care nu poate citi octeții, dar poate ajunge la procesul de semnare, se autentifică în continuare cât timp durează acel acces.

O cheie în fișier este trivial de copiat, motiv pentru care este și cea mai ușor de salvat și restaurat. Un depozit software de chei schimbă API-ul, nu granița: furnizorul își refuză propriile apeluri de export, dar același context de administrator care a instalat cheia are de obicei alte rute către material. Neexportabil la un furnizor software este o afirmație despre operațiile acceptate, nu dovada unui zid hardware. Tratați-o ca pe o limitare pentru copierea întâmplătoare, nu ca protecție împotriva cuiva care vă are deja sesiunea.

Un TPM sau un card inteligent execută operația de semnare în hardware și returnează doar rezultatul. Aceasta închide calea de copiere și lasă calea de utilizare deschisă pentru orice poate cere o semnătură.

Potriviți depozitul cu demonul de tunel

Demonul limitează acest lucru mai mult decât politica de securitate. WireGuard preia o cheie privată base64 dintr-un fișier sau din intrarea comenzii wg set și nu are nicio rută către un depozit de certificate, așa că o cheie de interfață susținută de TPM nu este o opțiune. OpenVPN compilat împotriva OpenSSL 3 poate încărca o cheie printr-un URI de furnizor, iar strongSwan livrează un plugin TPM alături de suportul PKCS#11, dar ambele depind de modul în care a fost compilat pachetul.

Un demon care nu poate ajunge la depozitul ales transformă granița hardware în decor. Cineva exportă cheia o dată, o lasă într-un fișier, iar restul proiectului rulează în liniște pe acea copie.

Reînnoirea este cealaltă jumătate a potrivirii, și aici pică majoritatea proiectelor. Un depozit care funcționează la prima înrolare, dar cere autentificare la consolă pentru fiecare reemitere, este ocolit prima dată când un certificat expiră la o oră incomodă. Testați calea de reemitere cât timp cheia actuală mai are luni de valabilitate.

Inventariați cheia înainte de a o muta

Notați ce este cheia înainte de a schimba unde locuiește, pentru că o migrare care pierde subject alternative names rupe tunelul într-un mod care se citește ca o defectare de rutare. Descărcați certificatul, confirmați că cheia privată este lizibilă acolo unde demonul o așteaptă și verificați că perechea chiar se potrivește.

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

Ultimele două rezumate trebuie să fie identice. Dacă nu sunt, demonul își termină configurarea și apoi eșuează la fiecare încercare cu o eroare de certificat sau de semnătură care nu indică nicăieri aproape de cauza reală. Echivalentul WireGuard este mai scurt, deoarece cheia publică derivă direct din cea privată: wg pubkey < /etc/wireguard/wg0.key trebuie să afișeze cheia de peer pe care serverul dumneavoastră o are deja.

Permisiunile fac parte din același inventar. stat -c '%a %U:%G' /etc/wireguard/wg0.key ar trebui să returneze 600 root:root, iar orice este lizibil pentru grup sau pentru lume înseamnă că cheia a fost deja disponibilă pentru procese la care nu v-ați gândit niciodată.

Verificați depozitul și calea de utilizare

Verificarea are trei părți, iar a treia este cea care se sare. Confirmați că cheia există în depozitul ales, confirmați că demonul a încărcat acea cheie și nu o copie rămasă, apoi confirmați că încă pornește după ce artefactul de export a dispărut.

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Pe Windows prima comandă listează depozitul personal și afișează furnizorul cheii lângă fiecare intrare, iar acolo apare un certificat care pare susținut de hardware, dar stă în furnizorul software. A doua listează cheile deținute de furnizorul criptografic al platformei, deci o identitate VPN care lipsește acolo în timp ce certificatul este prezent înseamnă că jumătatea privată locuiește altundeva. Pe o poartă Linux, ipsec listcerts raportează ce a încărcat strongSwan, inclusiv cheile venite din pluginul TPM. Comparați amprente sau hash-uri de cheie publică cu inventarul în loc să vă bazați pe numărul de intrări.

Testul negativ este cel care demonstrează proiectul. Mutați cheia exportată în afara directorului de configurare al demonului, reporniți serviciul și citiți în jurnal ce identitate prezintă. Un tunel care tot urcă folosește depozitul; o pornire eșuată înseamnă că proiectul rula într-adevăr pe o copie.

Notați reînnoirea și revenirea

Revenirea diferă puternic între cele două familii, iar diferența aceea aparține notei de proiect, nu unui apel de incident. O cheie în fișier poate fi salvată criptat și restaurată, deci o migrare eșuată este reversibilă. O cheie neexportabilă nu poate fi salvată deloc, ceea ce face din reemitere și reînrolare singura cale de recuperare atunci când dispozitivul moare.

Verificați expirarea înainte de a deveni o întrerupere: openssl x509 -in vpn.crt -noout -checkend 2592000 se termină cu un cod diferit de zero când certificatul expiră în treizeci de zile, deci se potrivește direct într-o verificare de monitorizare. O rulare săptămânală a acelei linii prinde reînnoirea pe care nimeni nu a planificat-o.

Eliminarea are loc pe server: ștergeți peerul sau revocați numărul de serie, apoi confirmați că tunelul eșuează, fiindcă un client cu o sesiune în cache poate ascunde o revocare pe jumătate pentru un timp. Revocarea trebuie să ajungă și pe calea CRL sau OCSP a concentratorului, nu doar în baza de date a CA. Un certificat este un document public, iar profilul RFC 5280 acoperă modul în care este validat; nimic din acea validare nu protejează o cheie privată copiată înainte de rotație.

Scrieți decizia într-un singur loc: ce depozit ține cheia, ce proces o poate folosi, cine o poate reemite și care este revenirea. Acel paragraf este ce cer auditorii și ce supraviețuiește unei schimbări de personal.