Запазена парола за VPN: кой може да я дешифрира и кога

VPN клиент, който показва шифрована парола в своя XML, не ви е казал почти нищо. Шифротекстът отговаря само, че стойността не се съхранява като обикновен текст в това представяне. Кой може да я дешифрира, с какъв ключ и в какъв потребителски контекст са въпросите, които решават дали съхранението помага. Отговорете на тях, преди да наречете файла безопасен или небезопасен.

Установете какъв обект се съхранява

Започнете с документирания модел на съхранение на продукта. Клиентът може да съхранява възстановима парола, токен или препратка към хранилище на идентификационни данни и всяко от тях има различно излагане. Името на XML елемента не е дизайнът и низ, подобен на base64, също не е доказателство за криптиране.

Попитайте доставчика или администратора кой компонент чете стойността при свързване.

След това идентифицирайте API за защита, ако е документиран. В Windows CryptProtectData защитава данни с ключ, извлечен от идентификационните данни за вход на потребителя, който криптира, а опцията му за машинен обхват променя кой може да дешифрира. Това е конкретен пример защо обхватът има значение. Това не е доказателство, че който и да е конкретен VPN клиент използва този API.

Отделете откраднато копие от използване по време на работа

Клиент, който се свързва отново, без да ви пита, се нуждае от поддържан начин да възстанови идентификационните данни. Защитата на резервно копие не премахва тази възможност. Всяка програма, работеща в правилния потребителски контекст, може да използва същия път, поради което крайната точка сама е вътре в границата на доверие. Разрешенията на файловете и привилегиите на процесите стесняват тази граница; те не я премахват.

Това е разликата, която твърдението за офлайн файл обикновено разбира погрешно. Криптирането в покой може да спре някого, който копира един файл без акаунта. То не спира код, който работи като акаунта.

И двете твърдения могат да са верни едновременно и второто е това, което има значение при реакция на инциденти.

Прочетете контролите за достъп, които действително се прилагат

Проверете ACL на файла и директорията над него, а не само режима на файла. В Windows сравнете ефективните разрешения на потребителския профил с тези на услугата на клиента или планираната задача. Тайна, защитена за един потребител, не е автоматично защитена от администратор и не е автоматично изложена на такъв.

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

Запишете коя идентичност стартира клиента, защото тази идентичност е субектът на дешифрирането.

За управляван парк съответната контрола може да е управлението на устройства, а не файлът. Попитайте дали идентификационните данни се депонират, дали могат да бъдат отменени дистанционно и какъв е процесът при загуба на устройство.

Планирайте излагане вместо тестване на дешифриране

Не стартирайте непознат инструмент за извличане срещу файла, за да докажете нещо. Може да работи, може да повреди профила и във всеки случай променя доказателствата. Използвайте документирания дизайн и оторизирана оценка, ако проверката наистина е необходима.

Ако излагането е установено, сменете идентификационните данни при собственика на идентичността.

Изтриването на запазения запис не е отмяна. То може да попречи на този клиент да предложи стойността отново и не прави нищо за вече взето копие или вече оторизирана сесия. Заменете идентификационните данни, прекратете сесиите, които собственикът може да прекрати, и запишете какво е сменено и кога.

Въпросите за прегледа на доставчика

Попитайте каква тайна се съхранява, кой компонент я използва, кой потребителски или машинен ключ я защитава, какви контроли за достъп се прилагат при нормална употреба и резервни копия и как се обработват политиката за запазване и дистанционното анулиране. Тези пет отговора описват дизайна; XML не.

Пазете отговорите с записа за внедряване, за да не повтаря следващият рецензент упражнението.

Запазените идентификационни данни са размяна между удобство и излагане. Направете размяната съзнателно и запишете кой я е приел.