Захаваны пароль VPN: хто і калі можа яго расшыфраваць

Кліент VPN, які паказвае зашыфраваны пароль у сваім XML, амаль нічога вам не сказаў. Шыфртэкст адказвае толькі на тое, што значэнне не захоўваецца як звычайны тэкст у гэтым прадстаўленні. Хто можа яго расшыфраваць, якім ключом і ў якім кантэксце карыстальніка — гэта пытанні, што вызначаюць, ці дапамагае захаванне. Адкажыце на іх, перш чым назваць файл бяспечным або небяспечным.

Вызначце, які аб'ект захоўваецца

Пачніце з дакументаванай мадэлі захавання прадукту. Кліент можа захоўваць аднаўляльны пароль, токен або спасылку на сховішча ўліковых даных, і кожны з іх мае розную ступень выкрыцця. Назва элемента XML — гэта не дызайн, і радок, падобны да base64, таксама не доказ шыфравання.

Спытайце пастаўшчыка або адміністратара, які кампанент чытае значэнне ў момант падключэння.

Затым вызначце API абароны, калі ён дакументаваны. У Windows CryptProtectData абараняе даныя ключом, вытворным ад уліковых даных карыстальніка, які шыфруе, а яго параметр машыннага ўзроўню змяняе, хто можа расшыфраваць. Гэта канкрэтны прыклад таго, чаму мае значэнне ахоп. Гэта не доказ таго, што нейкі канкрэтны кліент VPN выкарыстоўвае гэты API.

Аддзяліце выкрадзеную копію ад выкарыстання падчас працы

Кліенту, які перападключаецца, не пытаючыся ў вас, патрэбен падтрыманы спосаб аднавіць уліковыя даныя. Абарона рэзервовай копіі не адмяняе гэтай магчымасці. Любая праграма, што працуе ў правільным кантэксце карыстальніка, можа выкарыстаць той жа шлях, і менавіта таму канчатковы пункт сам знаходзіцца ўнутры мяжы даверу. Дазволы на файлы і прывілеі працэсаў звужаюць гэтую мяжу; яны не выдаляюць яе.

Менавіта гэтае адрозненне звычайна памылкова тлумачаць у сцвярджэнні пра афлайн-файл. Шыфраванне ў стане спакою можа спыніць таго, хто капіюе адзін файл без уліковага запісу. Яно не спыняе код, які працуе ад імя ўліковага запісу.

Абодва сцвярджэнні могуць быць праўдзівымі адначасова, і другое з іх мае значэнне падчас рэагавання на інцыдэнты.

Прачытайце кантроль доступу, які рэальна дзейнічае

Праверце ACL файла і каталог над ім, а не толькі рэжым файла. У Windows параўнайце эфектыўныя дазволы профілю карыстальніка з дазволамі службы кліента або запланаванага задання. Сакрэт, абаронены для аднаго карыстальніка, не абараняецца аўтаматычна ад адміністратара і не выкрываецца яму аўтаматычна.

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

Запішыце, якая асоба запускае кліент, бо менавіта гэтая асоба з'яўляецца суб'ектам расшыфроўкі.

Для кіраванага парку адпаведным сродкам кантролю можа быць кіраванне прыладамі, а не файл. Спытайце, ці ўліковыя даныя дэпануюцца, ці можна іх адклікаць дыстанцыйна і які працэс дзейнічае пры страце прылады.

Плануйце выкрыццё замест праверкі расшыфроўкі

Не запускайце незнаёмы інструмент здабывання даных супраць файла, каб нешта даказаць. Ён можа спрацаваць, можа пашкодзіць профіль, і ў любым выпадку ён змяняе доказы. Выкарыстоўвайце дакументаваны дызайн і аўтарызаваную ацэнку, калі праверка сапраўды патрэбная.

Калі выкрыццё ўстаноўлена, змяніце ўліковыя даныя ў уладальніка асобы.

Выдаленне захаванага запісу — гэта не адкліканне. Яно можа перашкодзіць гэтаму кліенту зноў прапанаваць значэнне, але нічога не робіць з ужо знятай копіяй або ўжо аўтарызаванай сесіяй. Замяніце ўліковыя даныя, завершыце сесіі, якія ўладальнік можа завяршыць, і запішыце, што было зменена і калі.

Пытанні для разгляду ў пастаўшчыка

Спытайце, які сакрэт захоўваецца, які кампанент яго выкарыстоўвае, які ключ карыстальніка або машыны яго абараняе, якія сродкі кантролю доступу дзейнічаюць для звычайнага выкарыстання і рэзервовых копій і як апрацоўваюцца палітыка захавання і дыстанцыйнае ануляванне. Гэтыя пяць адказаў апісваюць дызайн; XML — не.

Трымайце адказы разам з запісам разгортвання, каб наступны рэцэнзент не паўтараў практыкаванне.

Захаваныя ўліковыя даныя — гэта абмен паміж зручнасцю і выкрыццём. Рабіце гэты абмен усвядомлена і запішыце, хто яго прыняў.