رمز عبور ذخیره‌شده VPN: چه کسی و چه زمانی می‌تواند آن را رمزگشایی کند
متن رمزشده در یک فایل کلاینت تقریباً هیچ چیز را اثبات نمی‌کند. پیش از داوری درباره ذخیره‌سازی، صاحب کلید، استفاده در زمان اجرا و کنترل‌های دسترسی را مشخص کنید.
کلاینت VPN که رمز عبور رمزشده را در XML خود نشان می‌دهد تقریباً هیچ چیزی به شما نگفته است. متن رمزشده فقط پاسخ می‌دهد که مقدار در آن نمایش به‌صورت متن ساده ذخیره نشده است. اینکه چه کسی می‌تواند آن را رمزگشایی کند، با چه کلیدی و در چه بافت کاربری، پرسش‌هایی هستند که تعیین می‌کنند آیا ذخیره‌سازی کمک می‌کند یا نه. پیش از آنکه فایل را ایمن یا ناایمن بخوانید، به آن‌ها پاسخ دهید.
مشخص کنید چه شیئی ذخیره می‌شود
با مدل ذخیره‌سازی مستند محصول شروع کنید. کلاینت ممکن است رمز عبور قابل بازیابی، توکن یا ارجاعی به مخزن اعتبارنامه ذخیره کند و هر یک در معرض خطر متفاوتی است. نام عنصر XML همان طراحی نیست و رشته‌ای که شبیه base64 است نیز اثبات رمزنگاری نیست.
از فروشنده یا مدیر سیستم بپرسید کدام مؤلفه مقدار را در زمان اتصال می‌خواند.
سپس اگر مستند است، API حفاظتی را مشخص کنید. در Windows، CryptProtectData داده‌ها را با کلیدی محافظت می‌کند که از اعتبارنامه ورود کاربر رمزکننده مشتق شده است و گزینه دامنه ماشین آن تغییر می‌دهد چه کسی می‌تواند رمزگشایی کند. این نمونه‌ای مشخص از اهمیت دامنه است. این اثبات آن نیست که کلاینت VPN خاصی از آن API استفاده می‌کند.
نسخه دزدیده‌شده را از استفاده در زمان اجرا جدا کنید
کلاینتی که بدون پرسیدن از شما دوباره متصل می‌شود به روشی پشتیبانی‌شده برای بازیابی اعتبارنامه نیاز دارد. محافظت از نسخه پشتیبان آن توانایی را حذف نمی‌کند. هر برنامه‌ای که در بافت کاربری درست اجرا شود می‌تواند از همان مسیر استفاده کند، و به همین دلیل خود نقطه پایانی درون مرز اعتماد قرار دارد. مجوزهای فایل و امتیازات فرایند آن مرز را باریک می‌کنند؛ آن را حذف نمی‌کنند.
این همان تمایزی است که ادعای «فایل آفلاین» معمولاً اشتباه می‌فهمد. رمزنگاری در حالت سکون می‌تواند کسی را که یک فایل را بدون حساب کپی می‌کند متوقف کند. اما کدی را که با آن حساب اجرا می‌شود متوقف نمی‌کند.
هر دو گزاره می‌توانند همزمان درست باشند و دومی همانی است که در پاسخ به رخداد اهمیت دارد.
کنترل‌های دسترسی‌ای را بخوانید که واقعاً اعمال می‌شوند
ACL فایل و پوشه بالای آن را بررسی کنید، نه فقط حالت فایل را. در Windows، مجوزهای مؤثر نمایه کاربر را با مجوزهای سرویس یا وظیفه زمان‌بندی‌شده کلاینت مقایسه کنید. رازی که برای یک کاربر محافظت شده به‌طور خودکار از مدیر محافظت نمی‌شود و به‌طور خودکار برای او افشا نیز نمی‌شود.
icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /privثبت کنید کدام هویت کلاینت را اجرا می‌کند، زیرا همان هویت موضوع رمزگشایی است.
برای یک ناوگان مدیریت‌شده، کنترل مرتبط ممکن است مدیریت دستگاه باشد نه فایل. بپرسید آیا اعتبارنامه در امانت سپرده می‌شود، آیا می‌توان آن را از راه دور باطل کرد و رویه هنگام گم شدن دستگاه چیست.
برای افشا برنامه‌ریزی کنید، نه برای آزمودن رمزگشایی
برای اثبات یک نکته ابزار استخراج ناشناخته را روی فایل اجرا نکنید. ممکن است کار کند، ممکن است نمایه را خراب کند و در هر حال شواهد را تغییر می‌دهد. اگر راستی‌آزمایی واقعاً لازم است از طراحی مستند و ارزیابی مجاز استفاده کنید.
اگر افشا ثابت شد، اعتبارنامه را نزد صاحب هویت جایگزین کنید.
حذف ورودی ذخیره‌شده ابطال نیست. این کار می‌تواند مانع شود آن کلاینت دوباره مقدار را ارائه دهد و هیچ کاری درباره نسخه‌ای که پیش‌تر برداشته شده یا نشستی که پیش‌تر مجاز شده انجام نمی‌دهد. اعتبارنامه را جایگزین کنید، نشست‌هایی را که صاحب می‌تواند پایان دهد پایان دهید و ثبت کنید چه چیزی و چه زمانی جایگزین شد.
پرسش‌های بازبینی فروشنده
بپرسید چه رازی ذخیره می‌شود، کدام مؤلفه از آن استفاده می‌کند، کدام کلید کاربر یا ماشین آن را محافظت می‌کند، چه کنترل‌های دسترسی برای استفاده عادی و نسخه‌های پشتیبان اعمال می‌شود و سیاست ذخیره و ابطال از راه دور چگونه مدیریت می‌شود. آن پنج پاسخ طراحی را توصیف می‌کنند؛ XML چنین نمی‌کند.
پاسخ‌ها را همراه سابقه استقرار نگه دارید تا بازبین بعدی تمرین را تکرار نکند.
اعتبارنامه ذخیره‌شده معامله‌ای بین راحتی و افشاست. این معامله را آگاهانه انجام دهید و بنویسید چه کسی آن را پذیرفته است.