Сачувана VPN лозинка: ко је може дешифровати и када

VPN клијент који приказује шифровану лозинку у свом XML-у није вам рекао готово ништа. Шифровани текст одговара само на то да вредност у том приказу није сачувана као чисти текст. Ко је може дешифровати, којим кључем и у ком корисничком контексту — то су питања која одлучују да ли складиштење помаже. Одговорите на њих пре него што датотеку назовете безбедном или небезбедном.

Утврдите који се објекат чува

Почните од документованог модела складиштења производа. Клијент може чувати лозинку која се може вратити, токен или упуту на складиште акредитива, а свака опција има другачију изложеност. Назив XML елемента није дизајн, а ни низ који личи на base64 није доказ шифровања.

Питајте добављача или администратора која компонента чита вредност при повезивању.

Затим утврдите API заштите ако је документован. У систему Windows CryptProtectData штити податке кључем изведеним из акредитива за пријаву корисника који шифрује, а опција на нивоу рачунара мења ко може дешифровати. То је конкретан пример зашто је обухват важан. То није доказ да било који VPN клијент користи тај API.

Одвојте украдену копију од употребе током рада

Клијенту који се поново повезује без питања потребна је подржана путања за враћање акредитива. Заштита резервне копије не уклања ту могућност. Сваки програм који ради у исправном корисничком контексту може да користи исту путању, зато је сама крајња тачка унутар границе поверења. Дозволе датотека и привилегије процеса сужавају ту границу; не уклањају је.

Управо ту разлику тврдња о ванмрежној датотеци обично погрешно схвата. Шифровање у мировању може зауставити некога ко копира једну датотеку без налога. Не зауставља код који ради као тај налог.

Обе тврдње могу бити тачне истовремено, а друга је она која је важна током одговора на инцидент.

Прочитајте контроле приступа које заиста важе

Проверите ACL датотеке и фасцикле изнад ње, не само режим датотеке. У систему Windows упоредите ефективне дозволе корисничког профила са онима клијентске услуге или заказаног задатка. Тајна заштићена за једног корисника није аутоматски заштићена од администратора, а ни аутоматски му изложена.

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

Забележите који идентитет покреће клијента, јер је тај идентитет субјекат дешифровања.

За управљану флоту релевантна контрола може бити управљање уређајима уместо датотеке. Питајте да ли је акредитив похрањен код треће стране, може ли се опозвати на даљину и какав је поступак када се уређај изгуби.

Планирајте изложеност уместо да тестирате дешифровање

Не покрећите непознат алат за издвајање на датотеци да бисте нешто доказали. Може да успе, може да оштети профил и у сваком случају мења доказе. Користите документовани дизајн и овлашћену процену ако је провера заиста потребна.

Ако је изложеност утврђена, замените акредитиве код власника идентитета.

Брисање сачуваног уноса није опозив. Може спречити тај клијент да поново понуди вредност и не чини ништа у вези с копијом која је већ узета или сесијом која је већ одобрена. Замените акредитиве, окончајте сесије које власник може окончати и забележите шта је замењено и када.

Питања за преглед добављача

Питајте која се тајна чува, која је компонента користи, који кориснички или машински кључ је штити, које контроле приступа важе за уобичајену употребу и резервне копије и како се обрађују политика чувања и даљинско поништавање. Ти пет одговора описују дизајн; XML не.

Чувајте одговоре уз запис о увођењу како следећи прегледач не би понављао вежбу.

Сачувани акредитив је размена између практичности и изложености. Обавите ту размену намерно и запишите ко ју је прихватио.