Konservita VPN-pasvorto: kiu povas malĉifri ĝin kaj kiam

VPN-kliento, kiu montras ĉifritan pasvorton en sia XML, preskaŭ nenion diris al vi. La ĉifrita teksto respondas nur, ke la valoro ne estas konservita kiel ebena teksto en tiu reprezento. Kiu povas malĉifri ĝin, per kiu ŝlosilo kaj sub kiu uzantokunteksto estas la demandoj, kiuj decidas, ĉu la konservado helpas. Respondu ilin antaŭ ol nomi la dosieron sekura aŭ nesekura.

Difinu, kiu objekto estas konservata

Komencu per la dokumentita konserva modelo de la produkto. Kliento povas konservi restaŭreblan pasvorton, ĵetonon aŭ referencon al akreditaĵa konservejo, kaj ĉiu havas malsaman elmetiĝon. La nomo de la XML-elemento ne estas la dezajno, kaj signoĉeno simila al base64 ankaŭ ne estas pruvo de ĉifrado.

Demandu la vendiston aŭ administranton, kiu komponanto legas la valoron dum konektiĝo.

Poste identigu la protektan API se ĝi estas dokumentita. En Windows, CryptProtectData protektas datumojn per ŝlosilo derivita de la ensalutaj akreditaĵoj de la ĉifranta uzanto, kaj ĝia maŝinnivela opcio ŝanĝas, kiu povas malĉifri. Tio estas konkreta ekzemplo pri kial la amplekso gravas. Ĝi ne estas pruvo, ke iu ajn specifa VPN-kliento uzas tiun API.

Apartigu ŝtelitan kopion de uzado dum plenumo

Kliento, kiu rekonektiĝas sen demandi vin, bezonas subtenatan manieron restaŭri la akreditaĵon. Protekti sekurkopion ne forigas tiun kapablon. Ajna programo kuranta en la ĝusta uzantokunteksto povas uzi la saman vojon, kaj tial la finpunkto mem estas ene de la fida limo. Dosierpermesoj kaj procesprivilegioj mallarĝigas tiun limon; ili ne forigas ĝin.

Tiu distingo estas tio, kion aserto pri eksterreta dosiero kutime maltrafas. Ĉifrado dum ripozo povas haltigi iun, kiu kopias unu dosieron sen la konto. Ĝi ne haltigas kodon, kiu kuras kiel la konto.

Ambaŭ asertoj povas esti veraj samtempe, kaj la dua estas tiu, kiu gravas dum incidenta respondo.

Legu la alirkontrolojn, kiuj efektive validas

Kontrolu la ACL de la dosiero kaj la superan dosierujon, ne nur la dosiermodon. En Windows, komparu la efektivajn permesojn de la uzantprofilo kun tiuj de la servo aŭ planita tasko de la kliento. Sekreto protektita por unu uzanto ne estas aŭtomate protektita kontraŭ administranto, kaj ĝi ankaŭ ne estas aŭtomate elmetita al tia.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Notu, kiu idento funkciigas la klienton, ĉar tiu idento estas la subjekto de malĉifrado.

Por administrata aro, la koncerna kontrolo povas esti aparatadministrado anstataŭ la dosiero. Demandu, ĉu la akreditaĵo estas deponita, ĉu ĝi povas esti revokita malproksime, kaj kia estas la procezo kiam aparato perdiĝas.

Planu por elmetiĝo anstataŭ testi malĉifradon

Ne rulu nekonatan eltiran ilon kontraŭ la dosiero por pruvi punkton. Ĝi povas funkcii, ĝi povas damaĝi la profilon, kaj ĉiukaze ĝi ŝanĝas la pruvojn. Uzu la dokumentitan dezajnon kaj rajtigitan taksadon, se verigo estas vere necesa.

Se elmetiĝo estas konstatita, rotaciu la akreditaĵon ĉe la posedanto de la idento.

Forigi la konservitan enskribon ne estas revoko. Ĝi povas malhelpi tiun klienton proponi la valoron denove, kaj ĝi faras nenion pri kopio jam prenita aŭ seanco jam rajtigita. Anstataŭigu la akreditaĵon, finu la seancojn, kiujn la posedanto povas fini, kaj notu, kio estis rotaciita kaj kiam.

La demandoj por vendista revizio

Demandu, kiu sekreto estas konservata, kiu komponanto uzas ĝin, kiu uzanta aŭ maŝina ŝlosilo protektas ĝin, kiuj alirkontroloj validas por normala uzo kaj sekurkopioj, kaj kiel estas traktataj la konserva politiko kaj malproksima nuligo. Tiuj kvin respondoj priskribas la dezajnon; la XML ne.

Konservu la respondojn kun la deploja registro, por ke la sekva revizianto ne ripetu la ekzercon.

Konservita akreditaĵo estas interŝanĝo inter oportuno kaj elmetiĝo. Faru la interŝanĝon intence, kaj skribu, kiu akceptis ĝin.