Tatlong telepono, isang router at isang pagsusuri sa pagsubaybay ay hawak pa rin ang lumang password, at ang isa sa kanila ay muling kumokonekta tuwing siyamnapung segundo. Nagbago ang password ng account sampung minuto ang nakalipas, kaya bawat isa sa mga kliyenteng iyon ay nagsumite na ngayon ng halagang tinatanggihan ng server. Iyon ang sandaling mabubuwag ang alamat: ang pagbabago ng password ay humahawak sa account, hindi sa mga kopya ng lumang halaga na nasa bawat device. Ang sumusunod ay ang trabahong hindi ginawa ng pagbabago.

Ang alamat: isang pagbabago, sabay-sabay sa lahat ng lugar

Ang paniniwala ay ang pagbabago ng password ay nagsa-sign out sa lahat at nagpipilit ng malinis na muling pag-login. Hindi ito nangyayari, dahil sinusubaybayan lamang ng server kung aling kredensyal ang huling tinanggap nito, habang hinahawakan ng mga kliyente ang kanilang na-save. Ang isang device na may naka-save na password ay sumusubok muli ayon sa sarili nitong iskedyul at tahimik na nabibigo hanggang may makapansin na naka-lock ang account. Kapag tinanggap mong nabubuhay ang mga kopya sa labas ng account, hindi na mukhang isang aksyon lamang ang pag-ikot.

Wala sa mga ito ang sumasalungat sa pag-ikot. Sinusuportahan nito ang pagtrato sa mga naka-save na kopya bilang bahagi ng pagbabago at hindi bilang huling-isip. Karaniwang nagmumula ang pagkandado sa magkakasabay na pagsubok muli: patuloy na nagpapadala ang bawat device ng lumang halaga ayon sa sarili nitong iskedyul hanggang umandar ang counter. Pagkatapos ay mukhang inaatake ang account habang binibigyan lamang ito ng mga kredensyal na walang pumalit. Mahalaga ang pagkakaibang iyon, dahil ang solusyon ay isang listahan ng mga device at hindi isang mas mahigpit na patakaran sa pagkandado.

I-inventory ang mga kopya bago mag-ikot

Isulat ang imbentaryo bago buksan ang form ng password. Ilahad ang bawat kliyente, script, automation at pinamamahalaang profile na nagpapatunay bilang account na ito: ang teleponong kusang kumokonekta, ang router na na-configure dalawang taon na ang nakalipas, ang laptop na gumigising lamang tuwing Lunes, at ang pagsusuri sa pagsubaybay na sumusubok bawat minuto. Para sa bawat isa, itala kung saan nakaimbak ang kredensyal, kung maaabot ang device habang nagbabago, at anong ruta ng pagbawi ang umiiral kung hindi ito makakonekta muli. Ang listahang iyon ang nagpapalit ng mapanganib na pagbabago tungo sa naka-iskedyul, at kailangan itong umiral bago tumigil sa paggana ang lumang password.

Ang mga offline na device ang klasikong pagkalimot. Ang laptop sa drawer ay bumabalik pagkalipas ng tatlong linggo at inihaharap ang lumang halaga sa pinakamasamang sandali. Itala rin ang lokasyon at iskedyul nito, dahil kailangan mong habulin ito sa halip na hintayin.

Sa isang fleet ng Linux ang paghahanap ay mekanikal at hindi matalino. Hanapin ang mga profile na tumutukoy sa isang file ng kredensyal, pagkatapos ang mga file ng kredensyal mismo, dahil ang pangalawang listahan ang kailangang isulat muli. Ulitin ang ehersisyo para sa mga desktop client at telepono, kung saan ang imbakan ay isang profile o entry sa keychain at hindi isang landas. Ang layunin ay isang listahang mapagtatrabahuhan mo, hindi isang scan na nagsasabing nahahanap nito ang bawat kopya.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Timbangin ang mga kopya laban sa mga taong nagmamay-ari ng mga ito. Ang device na walang nag-aangkin ay device na walang mag-a-update, at ito rin ang pinakamalamang na magpatuloy sa pagsubok muli.

Aling lihim ang aktwal na iniikot mo

Ang password ng account ay isa lamang kredensyal sa isang deployment ng VPN. Ang pariralang pang-key, ang pagkakakilanlan ng sertipiko at ang opsyonal na lihim ng kapares ay may kanya-kanyang landas ng pagpapalit at may-ari. Ang pagpalit ng password ng account ay walang ginagawa para sa device na nagpapatunay gamit ang sertipiko, at ang muling pag-isyu ng sertipiko ay walang ginagawa para sa kliyenteng may naka-save na password. Pangalanan ang lihim bago pangalanan ang solusyon.

Kung ang pag-ikot ay hinihimok ng hinala at hindi ng patakaran, nangunguna ang proseso ng insidente sa planong pang-kaginhawahan. Bawiin ang hinihingi ng ebidensya at tanggapin ang dagdag na trabaho sa listahan ng device. Ang desisyong iyon ay pag-aari ng may-ari ng insidente, hindi ng sinumang nagkataong may hawak ng form sa pag-reset ng password.

Palitan ang naka-save na halaga sa kinaroroonan nito

Palitan ang kredensyal sa pamamagitan ng mekanismong dokumentado ng serbisyo, pagkatapos i-update ang naka-save na kopya o patakbuhin ang daloy ng pag-sign in sa bawat device na balak mong panatilihin. Huwag i-edit ang nabuong configuration sa likod ng manager na muling nagsusulat nito, dahil ibinabalik ng manager ang lumang halaga sa susunod na pagtakbo at ang edit ay nagiging naantalang pagkasira. I-update ang source na binabasa ng manager, o gamitin ang sariling imbakan ng kredensyal ng kliyente. Alinman, kailangang magtapos ang device sa bagong halaga sa lugar na aktwal na binabasa ng kliyente.

Ang kliyenteng nag-iimbak ng file ng password ay kailangan ang file na muling isinulat, samantalang ang kliyenteng nagtatanong ay kailangan ang natapos na pag-sign in. Itinatago ng NetworkManager ang lihim sa loob ng profile ng koneksyon, kaya ang pagbabago ay dumadaan sa nmcli at hindi sa text editor:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Ang profile na nagbabasa ng file ng kredensyal ay ikatlong kaso. Palitan ang nilalaman ng file na iyon, panatilihing sarado ang mga pahintulot nito, at muling i-load ang kliyente sa halip na i-edit ang profile na tumuturo dito. Hindi nagbago ang profile; ang lihim na binabasa nito lamang ang nagbago.

Muling ikonekta ang bawat target na device nang isang beses, nang sinasadya, at tingnan kung alin ang nabibigo. Kung patuloy na nabibigo ang isang device, tingnan ang account na tinuturo nito at ang imbakang binabasa nito bago palitan muli ang password, dahil ang ikalawang pagbabago ay nagpaparami ng mga kopyang kailangang i-update. Ang device na nabibigo nang dalawang beses ay karaniwang tumuturo sa maling account o nagbabasa ng imbakang hindi mo pa nahahanap. Ayusin iyon, pagkatapos ay kumonekta muli.

Ang mga session at token ay nabubuhay nang mas matagal kaysa sa password

Ang pagpalit ng password ay hindi nagpapatunay na ang mga umiiral na session o hiwalay na sertipiko ay binawi. Ang ilang serbisyo ay nagpapanatili ng session na buhay hanggang ito ay mag-expire o tahasang wakasan, at ang mga inisyung token ay may sariling habang-buhay. Suriin kung ano ang aktwal na ginagawa ng serbisyo sa halip na ipalagay na ang pagbabago ay pandaigdigan. Kung ang pagbabago ay hinimok ng hinala, tahasang wakasan ang mga session at kumpirmahin ang resulta.

Ang gabay sa siklo ng buhay ng kredensyal sa NIST SP 800-63B ay nagpapanatili ng mga authenticator at session sa magkahiwalay na kategorya, kaya ang pagbabago ng password at pandaigdigang logout ay magkaibang operasyon. Ituring ang mga ito bilang dalawang gawain na may dalawang pamantayan ng pagkumpleto. Ang una ay natatapos kapag gumagana ang bagong halaga, at ang pangalawa kapag wala na ang lumang session.

Itala ang pagkumpleto nang hindi isinusulat ang bagong password sa talaan. Ang log ng pag-ikot na naglalaman ng kredensyal ay bagong insidenteng naghihintay sa isang shared drive. Itala ang petsa, ang mga na-update na device at ang mga device na natitira pa.

Kaugnay na mga artikulo