VPN klijent koji prikazuje šifriranu lozinku u svom XML-u nije vam rekao gotovo ništa. Šifrirani tekst odgovara samo da vrijednost nije pohranjena kao običan tekst u tom prikazu. Ko je može dešifrovati, kojim ključem i u kojem korisničkom kontekstu pitanja su koja odlučuju pomaže li pohrana. Odgovorite na njih prije nego što datoteku nazovete sigurnom ili nesigurnom.

Utvrdite koji se objekt pohranjuje

Počnite s dokumentiranim modelom pohrane proizvoda. Klijent može pohraniti lozinku koja se može vratiti, token ili uputu na spremište vjerodajnica, a svaki od njih ima drugačiju izloženost. Naziv XML elementa nije dizajn, a ni niz koji izgleda kao base64 nije dokaz šifriranja.

Pitajte dobavljača ili administratora koja komponenta čita vrijednost u trenutku povezivanja.

Zatim utvrdite API za zaštitu ako je dokumentiran. Na Windowsu CryptProtectData štiti podatke ključem izvedenim iz podataka za prijavu korisnika koji šifrira, a njegova opcija na razini stroja mijenja ko može dešifrovati. To je konkretan primjer zašto je opseg važan. To nije dokaz da neki određeni VPN klijent koristi taj API.

Odvojite ukradenu kopiju od upotrebe u radu

Klijent koji se ponovno povezuje bez pitanja treba podržan način da vrati vjerodajnicu. Zaštita sigurnosne kopije ne uklanja tu mogućnost. Svaki program koji radi u ispravnom korisničkom kontekstu može koristiti isti put, zato je samo krajnje računalo unutar granice povjerenja. Dopuštenja datoteka i privilegije procesa sužavaju tu granicu; ne uklanjaju je.

To je razlika koju tvrdnja o izvanmrežnoj datoteci obično pogrešno shvaća. Šifriranje u mirovanju može zaustaviti nekoga ko kopira jednu datoteku bez računa. Ne zaustavlja kod koji radi kao račun.

Obje tvrdnje mogu biti točne istovremeno, a druga je ona koja je važna tijekom odgovora na incident.

Pročitajte kontrolu pristupa koja se stvarno primjenjuje

Provjerite ACL datoteke i direktorij iznad nje, ne samo način rada datoteke. Na Windowsu usporedite efektivna dopuštenja korisničkog profila s onima klijentske usluge ili planiranog zadatka. Tajna zaštićena za jednog korisnika nije automatski zaštićena od administratora, a nije mu ni automatski izložena.

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

Zabilježite koji identitet pokreće klijent, jer je taj identitet subjekt dešifriranja.

Za upravljani park relevantna kontrola može biti upravljanje uređajima, a ne datoteka. Pitajte je li vjerodajnica deponirana, može li se opozvati na daljinu i kakav je postupak kada se uređaj izgubi.

Planirajte izloženost umjesto testiranja dešifriranja

Ne pokrećite nepoznat alat za izdvajanje na datoteci da biste nešto dokazali. Može uspjeti, može oštetiti profil i u svakom slučaju mijenja dokaze. Koristite dokumentirani dizajn i ovlaštenu procjenu ako je provjera doista potrebna.

Ako je izloženost utvrđena, zamijenite vjerodajnicu kod vlasnika identiteta.

Brisanje sačuvanog unosa nije opoziv. Ono može spriječiti taj klijent da ponovno ponudi vrijednost i ne čini ništa u vezi s već uzetom kopijom ili već ovlaštenom sesijom. Zamijenite vjerodajnicu, završite sesije koje vlasnik može završiti i zabilježite što je zamijenjeno i kada.

Pitanja za pregled dobavljača

Pitajte koja se tajna pohranjuje, koja je komponenta koristi, koji korisnički ili strojni ključ je štiti, koja se kontrola pristupa primjenjuje na uobičajenu upotrebu i sigurnosne kopije te kako se upravlja pravilom spremanja i daljinskim poništenjem. Tih pet odgovora opisuje dizajn; XML ne.

Držite odgovore uz zapis o implementaciji da sljedeći pregledatelj ne ponavlja vježbu.

Sačuvana vjerodajnica je razmjena između praktičnosti i izloženosti. Napravite tu razmjenu namjerno i zapišite ko ju je prihvatio.

Povezani članci