Bakit kailangang magkahiwalay ang may-ari ng mga susi ng server at ng mga kredensyal ng user

Ang susi na nagpapatunay na ang gateway mo mismo ang kausap at ang kredensyal na nagsasabing maaaring sumali ang isang tao ay parehong lihim, at doon nagtatapos ang pagkakatulad. Tinutukoy ng isa ang isang serbisyo sa bawat kliyente; tinutukoy ng isa ang isang user sa serbisyong iyon. Ang pagsasama ng dalawa ay nakakatipid ng isang hakbang sa pag-set up at nagkakahalaga ng isang hapon sa gitna ng insidente, dahil hindi pareho ang pagbangon para sa bawat isa. Nakababagot i-set up ang paghihiwalay at hindi mo ito makakalimutang laktawan.

Dalawang lihim, dalawang magkaibang may-ari

May hawak ang gateway ng pribadong susi o sertipiko na ang tanging tungkulin ay patunayan ang pagkakakilanlan nito sa panahon ng handshake. Kailangan ng mga kliyente ang tugmang pampublikong materyal para ma-verify ito, at hindi nila kailanman kailangan ang pribadong kalahati. Ang kawalan ng simetrya na iyon ang nagpapangyari sa pagpapatunay ng server nang hindi binibigyan ang bawat user ng kakayahang magpanggap na ang server.

Kabaligtaran ang direksyon ng materyal ng user. Ang pribadong susi ng kliyente, sertipiko ng kliyente o password ay nagpapakita na ang partikular na tao o device na ito ay binigyan ng access. Inaasahang ipapamahagi ito, kokopyahin sa pagitan ng mga device, at sa huli ay bawiin.

Ginagawang halata ng WireGuard ang paghihiwalay dahil may keypair ang bawat kalahok: nananatili sa server ang pribadong susi ng server, at ang configuration file na ibibigay mo sa isang user ay naglalaman ng sarili niyang pribadong susi at ng pampublikong susi ng server. Ang profile na naglalaman ng pribadong susi ng server ay hindi shortcut, ito ay isang kompromiso na naghihintay ng file share.

Tatlong tanong na nagtatakda ng paghihiwalay

Itanong kung sino ang dapat makabasa ng lihim, ano ang magagawa ng attacker kapag naisapubliko ito, at kung isang pagbawi lang o muling pagtatayo ng serbisyo ang solusyon.

Kung mababasa ito ng isang user at pinatutunayan nito ang pagkakakilanlan ng gateway, ang sagot sa ikalawang tanong ay maaaring magpanggap ang attacker na ang server mo sa harap ng bawat kliyente — ang pinakamasamang kinalabasan, dahil dinisenyo ang mga kliyente na magtiwala sa pagkakakilanlan na iyon. Kung isang user lang ang pinatutunayan nito, ibinibigay ng pagkakalantad ang access ng user na iyon sa isang peer, at karaniwang operasyon lang ang pagbawi. Kung susi ito ng certificate authority, mas malala ang pagkakalantad kaysa sa dalawa, dahil makakagawa ang attacker ng mga pagkakakilanlang pinagkakatiwalaan ng bawat endpoint.

Ang tatlong sagot na iyon ang gumagawa ng tuntunin sa pag-iimbak: nasa offline o vault ang susi ng CA, nasa gateway ang susi ng gateway, at nasa mga user ang mga susi ng user. Anumang layout na naglalagay sa tatlo sa isang direktoryo para sa kaginhawahan ay ginawang aksidente ang isang desisyon.

Ang talagang kailangan ng isang kliyente

Kailangan ng kliyente ang pampublikong sertipiko o pampublikong peer key, ang materyal o fingerprint ng CA na dapat nitong pagkatiwalaan, ang sarili nitong pribadong susi, at ang mga detalye ng endpoint. Wala sa listahang iyon ang pag-aari ng pribadong pagkakakilanlan ng gateway.

Sa dokumentasyon nangyayari ang pagtagas na ito. Ang gabay na nagsasabing kopyahin ang direktoryo ng server at tanggalin ang hindi mo kailangan ay nagturo na ng maling modelo, dahil bihira nang may tumitingin sa file na natitira pagkatapos ng hakbang ng pagtanggal.

Bawiin ang isang user nang hindi hinahawakan ang gateway

Dahil hiwalay na inilalabas ang mga pagkakakilanlan ng user, hiwalay din silang maaaring bawiin. Binabawi ng deployment na nakabatay sa sertipiko ang sertipiko ng kliyente at naglalathala ng na-update na listahan ng pagbawi; inaalis naman ng deployment ng WireGuard ang entry ng peer mula sa configuration ng server. Wala sa mga operasyong iyon ang nagbabago sa sariling susi ng gateway.

Itago ang talaan ng pag-isyu, kung hindi ay hindi mo malalaman kung aling pagkakakilanlan ang bawiin. Sapat na ang isang spreadsheet, basta't nakasaad dito ang tao, ang device, ang serial o pampublikong susi at ang petsa, at basta't may nagmamay-ari nito pagkatapos umalis ng taong gumawa nito.

Sinusuri ng mga utos sa ibaba ang isang sertipiko ng kliyente at pagkatapos ay binabawi ito sa pamamagitan ng awtoridad na tulad ng OpenSSL, na siyang daloy na binabalot ng easy-rsa:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Ilathala ang bagong listahan saanman sinusuri ito ng mga kliyente, kung hindi ay tala lang sa isang file ang pagbawi na walang binabago. Kung tinatanggap ng gateway mo ang mga sertipiko ng kliyente nang hindi sinusuri ang listahan ng pagbawi, sabihin ito nang tahasan sa halip na ipahiwatig na gumagana ang pagbawi.

Panatilihing kasing-hiwalay ng mga lihim ang mga backup

Legal na naglalaman ang archive para sa muling pagtatayo ng susi ng gateway at ng materyal ng CA, dahil kung wala ang mga iyon ay hindi maibabalik ng restore ang serbisyo. Hindi dapat naglalaman ang package ng setup ng kliyente, at hindi dapat itago nang magkasama ang dalawa. Lagyan ng label ang bawat archive ayon sa sinumang maaaring humawak nito, hindi ayon sa petsa ng paggawa. Ang label na iyon ang binabasa ng pagod na administrator sa alas-dos ng madaling araw.

Itinatakda rin ng pagkakaibang iyon kung sino ang maaaring kumuha ng bawat isa. Ang pamamahala ng gateway, pag-isyu ng mga pagkakakilanlan ng user at pagbasa ng mga backup ay tatlong magkaibang kapangyarihan, at ang taong nangangailangan ng isa ay hindi awtomatikong nangangailangan ng iba. Isulat ang mga pahintulot na iyon, pagkatapos suriin ang mga ito laban sa aktwal na pinapayagan ng storage mo, dahil tahimik na nagbibigay ng higit sa sinasadya ng patakaran ang inheritance ng direktoryo.