حذف عبارت عبور کلید یا نگه داشتن آن؟ نسخه‌ای که می‌سازید
یک فایل کلید رمزنگاری‌نشده همان راز را با حفاظت ضعیف‌تر نگه می‌دارد. پیش از تبدیل، ریسک حالت سکون را مقایسه کنید و بدانید چه چیزی را جبران نمی‌کند.
کلید خصوصی رمزنگاری‌شده و کلید رمزنگاری‌نشده همان مواد کلید را در خود دارند. تبدیل هویت تازه‌ای نمی‌سازد، حساب VPN را بازنشانی نمی‌کند و فایل قدیمی را باطل نمی‌کند. یک نسخه دوم می‌نویسد، و آن نسخه ریسک متفاوتی در حالت سکون دارد.
اینکه این معاوضه ارزشش را دارد به این بستگی دارد که فایل کجا زندگی کند و چه کسی بتواند آن را بخواند.
تبدیل در واقع چه چیزی را تغییر می‌دهد
پیش از تبدیل، کلید با عبارتی عبور که اپراتور تأمین می‌کند محافظت می‌شود. پس از تبدیل، با مجوزهای فایل‌سیستم و هر کنترل دسترسی‌ای که فایل را احاطه کرده محافظت می‌شود. رمزنگاری تغییر نکرده است؛ تعداد چیزهایی که میان مهاجم و کلید ایستاده‌اند تغییر کرده است. این تمام مقایسه است.
یک جدول تفاوت را ملموس می‌کند.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
هیچ‌کدام از دو شکل به‌طور خودکار ایمن‌تر نیستند. آن‌ها به روش‌های مختلف شکست می‌خورند، و تنها یکی از آن روش‌ها ورودی در گزارش برجای می‌گذارد.
چه زمانی نگه داشتن عبارت عبور بهتر است
اگر یک کلاینت پشتیبانی‌شده بتواند عبارت عبور را بپرسد یا آن را از مخزن راز تأییدشده بگیرد، تبدیل چیزی نمی‌خرد. یک نسخه، یک مرز حفاظت و یک فایل کمتر برای پیگیری نگه می‌دارید. بیشتر کلاینت‌های VPN که کلیدهای PEM را می‌پذیرند می‌توانند این کار را انجام دهند.
تبدیل هنگامی هم که یک تیم کلید را به اشتراک می‌گذارد حرکت نادرستی است. یک فایل رمزنگاری‌نشده روی میزبان مشترک به اعتبارنامه‌ای تبدیل می‌شود که هر کسی با دسترسی شل می‌تواند کپی کند.
چه زمانی یک نسخه رمزنگاری‌نشده توجیه دارد
برخی سرویس‌ها نمی‌توانند بپرسند، برخی کانتینرها رازها را فقط‌خواندنی سوار می‌کنند، و برخی دستگاه‌ها فایل کلید را هنگام بوت بدون مسیر تعاملی می‌خوانند. در این موارد، کلید رمزنگاری‌نشده درون پوشه‌ای که به‌درستی محدود شده می‌تواند طراحی پشتیبانی‌شده باشد. توجیه، محیط است، نه راحتی.
اگر نمی‌توانید بگویید چه کسی می‌تواند فایل را بخواند و چرا، پاسخ منفی است.
فرمان و لبه‌های تیز آن
برای کلیدی مبتنی بر فایل که OpenSSL 3.5 پشتیبانی می‌کند، مرجع pkey حذف عبارت عبور و یک پرسش تعاملی را مستند می‌کند، هنگامی که ورودی رمزنگاری‌شده است و هیچ منبع گذرواژه‌ای تأمین نمی‌شود. شکل کمینه کوتاه است، و اجرای بی‌دقت آن آسان است.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemسه لبه تیز. ورودی/خروجی فایل خروجی اتمی نیست، بنابراین یک مسیر خروجی موجود می‌تواند در میانه نوشتن قطع شود. مسیر ورودی را به‌عنوان خروجی به کار نبرید، و روی تنها نسخه محافظت‌شده آزمایش نکنید. عبارت عبور را در پرسش وارد کنید نه در خط فرمان، جایی که در تاریخچه شل می‌افتد.
پیش از تغییر هر پیکربندی VPN نتیجه را بررسی کنید: openssl pkey -in new-private-key.pem -pubout باید همان کلید عمومی را چاپ کند که پیش‌تر داشتید.
تبدیل چه کاری انجام نمی‌دهد
نسخه رمزنگاری‌شده را باطل نمی‌کند، که هنوز هر جا رهایش کرده‌اید وجود دارد. گذرواژه حساب VPN یا گواهی را تغییر نمی‌دهد. و افشایی را که پیش‌تر رخ داده ترمیم نمی‌کند. اگر کلیدی نشت کرده باشد، راه‌حل جایگزینی و ابطال در سمت سرور است، نه تغییر قالب محلی.
فایل میانی را آگاهانه حذف کنید و تأیید کنید مسیری که حذف می‌کنید همانی است که ساخته‌اید.