Saan dapat tumira ang pribadong susi ng VPN: file, CNG, o TPM?

Dalawang tanong ang nagtatakda kung saan nararapat ang pribadong susi ng VPN: maaari bang kopyahin ang materyal ng susi mula sa host, at magagamit ba ito ng isang proseso nang walang tao sa keyboard. Hindi sinasagot ng marketing label ng isang imbakan ang alinman. Ang daemon ng tunnel na kailangang bumalik pagkatapos ng reboot ay nangangailangan ng paggamit na walang nagbabantay, na nag-aalis sa lahat ng nakasalalay sa PIN na tina-type ng tao.

Pumili sa pagitan ng pagkopya at paggamit

Iba ang pagkabigo ng pagkopya at paggamit, kaya ituring ang mga ito na dalawang pangangailangan, hindi isa. Ang umaatake na makabasa ng mga byte ng susi ay nagdadala ng pagkakakilanlan sa ibang host, at hindi ito napapansin ng orihinal na makina. Ang umaatake na hindi makabasa ng mga byte ngunit nakarating sa proseso ng pagpirma ay patuloy na nagpapatunay hangga't tumatagal ang access na iyon.

Ang susi sa file ay madaling kopyahin, kaya ito rin ang pinakamadaling i-backup at ibalik. Ang imbakan ng susi sa software ay nagbabago ng API, hindi ng hangganan: tinatanggihan ng provider ang sarili nitong mga tawag sa export, ngunit ang parehong konteksto ng administrator na nag-install ng susi ay karaniwang may ibang ruta patungo sa materyal. Ang hindi maaaring i-export sa isang software provider ay pahayag tungkol sa mga sinusuportahang operasyon, hindi patunay ng pader na hardware. Ituring ito na pampabagal laban sa basta-bastang pagkopya, hindi proteksyon laban sa taong may hawak na ng iyong session.

Ang TPM o smart card ay nagsasagawa ng operasyon ng pagpirma sa loob ng hardware at ibinabalik lamang ang resulta. Isinasara nito ang landas ng pagkopya at iniiwang bukas ang landas ng paggamit sa anumang makakahiling ng pirma.

Itugma ang imbakan sa daemon ng tunnel

Higit na nililimitahan ng daemon ito kaysa sa patakaran sa seguridad. Kumukuha ang WireGuard ng base64 na pribadong susi mula sa file o sa input ng wg set at walang ruta patungo sa imbakan ng sertipiko, kaya ang susi ng interface na suportado ng TPM ay hindi isinasaalang-alang. Ang OpenVPN na itinayo laban sa OpenSSL 3 ay makakapag-load ng susi sa pamamagitan ng URI ng provider, at ang strongSwan ay may plugin ng TPM kasama ng suporta sa PKCS#11, ngunit pareho silang nakasalalay sa kung paano na-compile ang iyong pakete.

Ang daemon na hindi makarating sa piniling imbakan ay ginagawang palamuti ang hangganan ng hardware. May nag-export ng susi nang isang beses, iniiwan ito sa isang file, at tahimik na tumatakbo ang natitirang disenyo sa kopyang iyon.

Ang pag-renew ay ang kabilang kalahati ng pagtutugma, at dito nagkakawatak-watak ang karamihan ng disenyo. Ang imbakan na gumagana sa unang pagpaparehistro ngunit humihingi ng console login para sa bawat muling pag-isyu ay nilalampasan sa unang pagkakataong mag-expire ang sertipiko sa isang oras na hindi maginhawa. Subukan ang landas ng muling pag-isyu habang may mga buwan pa ang kasalukuyang susi.

I-imbentaryo ang susi bago ilipat

Itala kung ano ang susi bago baguhin kung saan ito nakatira, dahil ang paglilipat na nawawalan ng subject alternative names ay sumisira sa tunnel sa paraang mababasa bilang error sa routing. I-dump ang sertipiko, kumpirmahin na mababasa ang pribadong susi sa lugar kung saan inaasahan ito ng daemon, at tiyakin na talagang tumutugma ang pares.

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

Dapat magkapareho ang huling dalawang digest. Kung hindi, tinatapos ng daemon ang setup at pagkatapos ay nabigo sa bawat pagtatangka sa error ng sertipiko o pirma na hindi tumuturo kahit saan malapit sa tunay na dahilan. Ang katumbas sa WireGuard ay mas maikli, dahil ang pampublikong susi ay hinango nang direkta mula sa pribado: dapat i-print ng wg pubkey < /etc/wireguard/wg0.key ang susi ng peer na nakatago na sa iyong server.

Kasama sa parehong imbentaryo ang mga pahintulot. Dapat ibalik ng stat -c '%a %U:%G' /etc/wireguard/wg0.key ang 600 root:root, at anumang nababasa ng grupo o mundo ay nangangahulugang ang susi ay dati nang magagamit ng mga prosesong hindi mo kailanman inaasahan.

Suriin ang imbakan at ang landas ng paggamit

Tatlo ang bahagi ng pagpapatunay, at ang pangatlo ang madalas laktawan. Kumpirmahin na umiiral ang susi sa piniling imbakan, kumpirmahin na ang daemon ay nag-load ng susing iyon at hindi ng natirang kopya, pagkatapos ay kumpirmahin na nagsisimula pa rin ito kapag wala na ang artifact ng export.

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

Sa Windows, inililista ng unang utos ang personal na imbakan at ipiniprint ang provider ng susi sa tabi ng bawat entry, at doon lumalabas ang sertipikong mukhang suportado ng hardware ngunit nakaupo sa software provider. Ang pangalawa ay naglilista ng mga susing hawak ng crypto provider ng platform, kaya ang pagkakakilanlang VPN na wala roon habang naroon ang sertipiko nito ay nangangahulugang sa ibang lugar nakatira ang pribadong kalahati. Sa gateway na Linux, iniuulat ng ipsec listcerts kung ano ang na-load ng strongSwan, kasama ang mga susing galing sa plugin ng TPM. Ihambing ang mga fingerprint o hash ng pampublikong susi sa imbentaryo sa halip na magtiwala sa bilang ng entry.

Ang negatibong pagsubok ang nagpapatunay ng disenyo. Ilipat ang na-export na susi palabas ng configuration directory ng daemon, i-restart ang serbisyo, at basahin sa log kung anong pagkakakilanlan ang ipinapakita nito. Ang tunnel na umaangat pa rin ay gumagamit ng imbakan; ang nabigong pagsisimula ay nangangahulugang talagang tumatakbo ang disenyo sa isang kopya.

Isulat ang renewal at pag-urong

Malaki ang pagkakaiba ng pag-urong sa pagitan ng dalawang pamilya, at ang pagkakaibang iyon ay kabilang sa design note, hindi sa tawag ng insidente. Ang susi sa file ay maaaring i-backup nang naka-encrypt at ibalik, kaya ang nabigong paglilipat ay mababalik. Ang susing hindi maaaring i-export ay hindi maaaring i-backup kahit ano pa man, na ginagawang muling pag-isyu at muling pagpaparehistro ang tanging landas ng pagbawi kapag namatay ang device.

Suriin ang pag-expire bago ito maging outage: ang openssl x509 -in vpn.crt -noout -checkend 2592000 ay nagtatapos sa di-zero na code kapag mag-expire ang sertipiko sa loob ng tatlumpung araw, kaya deretso itong pumapasok sa isang monitoring check. Ang lingguhang pagpapatakbo ng linyang iyon ay humuhuli sa renewal na walang nagplano.

Nangyayari ang pag-alis sa server: tanggalin ang peer o bawiin ang serial number, pagkatapos ay kumpirmahin na nabigo ang tunnel, dahil ang client na may naka-cache na session ay maaaring magtago ng kalahating-tapos na revocation nang ilang sandali. Dapat ding maabot ng revocation ang CRL o OCSP na landas ng concentrator, hindi lamang ang database ng CA. Ang sertipiko ay pampublikong dokumento, at saklaw ng profile ng RFC 5280 kung paano ito binibigyang-katwiran; wala sa pagpapatunay na iyon ang nagpoprotekta sa pribadong susing kinopya bago ang rotation.

Isulat ang desisyon sa isang lugar: aling imbakan ang may susi, aling proseso ang maaaring gumamit, sino ang makakapag-isyu muli, at ano ang pag-urong. Ang talatang iyon ang itinatanong ng mga auditor, at ito ang tumatagal kapalit ng tauhan.