Išsaugotas VPN slaptažodis: kas ir kada gali jį iššifruoti
Šifruotas tekstas kliento faile beveik nieko neįrodo. Prieš vertindami saugojimą nustatykite rakto savininką, naudojimą vykdymo metu ir prieigos kontrolę.
VPN klientas, kuris savo XML faile rodo šifruotą slaptažodį, jums beveik nieko nepasakė. Šifruotas tekstas atsako tik tai, kad reikšmė tame vaizde nėra saugoma kaip paprastas tekstas. Kas gali jį iššifruoti, kokiu raktu ir kokiame naudotojo kontekste, yra klausimai, lemiantys, ar saugojimas padeda. Atsakykite į juos prieš vadindami failą saugiu ar nesaugiu.
Nustatykite, koks objektas saugomas
Pradėkite nuo dokumentuoto produkto saugojimo modelio. Klientas gali saugoti atkuriamą slaptažodį, žetoną arba nuorodą į kredencialų saugyklą, ir kiekvienas turi skirtingą atskleidimo lygį. XML elemento pavadinimas nėra dizainas, o base64 primenanti eilutė taip pat nėra šifravimo įrodymas.
Paklauskite tiekėjo arba administratoriaus, kuris komponentas skaito reikšmę prisijungimo metu.
Tada nustatykite apsaugos API, jei jis dokumentuotas. Windows sistemoje CryptProtectData apsaugo duomenis raktu, gautu iš šifruojančio naudotojo prisijungimo kredencialų, o jo mašinos masto parinktis keičia, kas gali iššifruoti. Tai konkretus pavyzdys, kodėl mastas svarbus. Tai nėra įrodymas, kad koks nors konkretus VPN klientas naudoja tą API.
Atskirkite pavogtą kopiją nuo naudojimo vykdymo metu
Klientas, kuris prisijungia iš naujo nepaklausęs jūsų, turi turėti palaikomą būdą atkurti kredencialą. Atsarginės kopijos apsauga tos galimybės nepanaikina. Bet kuri programa, veikianti tinkamame naudotojo kontekste, gali naudoti tą patį kelią, todėl pats galinis taškas yra pasitikėjimo ribos viduje. Failų leidimai ir procesų privilegijos susiaurina tą ribą; jie jos nepanaikina.
Būtent šį skirtumą teiginys apie neprisijungusį failą paprastai supranta klaidingai. Šifravimas ramybės būsenoje gali sustabdyti tą, kuris kopijuoja vieną failą be paskyros. Jis nesustabdo kodo, veikiančio kaip paskyra.
Abu teiginiai gali būti teisingi vienu metu, o incidento reagavimo metu svarbus antrasis.
Perskaitykite prieigos kontrolę, kuri iš tikrųjų taikoma
Patikrinkite failo ACL ir virš jo esantį katalogą, ne tik failo režimą. Windows sistemoje palyginkite efektyvius naudotojo profilio leidimus su kliento paslaugos ar suplanuotos užduoties leidimais. Vienam naudotojui apsaugota paslaptis nėra automatiškai apsaugota nuo administratoriaus ir nėra jam automatiškai atskleista.
icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv
Užrašykite, kuri tapatybė vykdo klientą, nes ta tapatybė yra iššifravimo subjektas.
Valdomame parke atitinkama kontrolė gali būti įrenginių valdymas, o ne failas. Paklauskite, ar kredencialas deponuojamas, ar jį galima atšaukti nuotoliniu būdu ir kokia tvarka, kai įrenginys pametamas.
Planuokite atskleidimą, o ne bandykite iššifravimą
Neleiskite nežinomo ištraukimo įrankio prie failo, kad ką nors įrodytumėte. Jis gali suveikti, gali sugadinti profilį ir bet kuriuo atveju pakeičia įrodymus. Naudokite dokumentuotą dizainą ir įgaliotą vertinimą, jei patikra tikrai būtina.
Jei atskleidimas nustatytas, pakeiskite kredencialą pas tapatybės savininką.
Išsaugoto įrašo trynimas nėra atšaukimas. Jis gali sutrukdyti tam klientui vėl pasiūlyti reikšmę ir nieko nepadeda dėl jau paimtos kopijos ar jau autorizuotos sesijos. Pakeiskite kredencialą, užbaikite sesijas, kurias savininkas gali užbaigti, ir užrašykite, kas ir kada pakeista.
Klausimai tiekėjo peržiūrai
Paklauskite, kokia paslaptis saugoma, kuris komponentas ją naudoja, kuris naudotojo ar mašinos raktas ją apsaugo, kokia prieigos kontrolė taikoma įprastam naudojimui ir atsarginėms kopijoms, ir kaip tvarkoma saugojimo politika bei nuotolinis panaikinimas. Tie penki atsakymai apibūdina dizainą; XML ne.
Laikykite atsakymus kartu su diegimo įrašu, kad kitas peržiūrėtojas nekartotų pratybų.
Išsaugotas kredencialas yra mainai tarp patogumo ir atskleidimo. Atlikite mainus sąmoningai ir užrašykite, kas juos priėmė.