کلید امضای CA در OpenVPN را بیرون از /etc/openvpn نگه دارید

دو پوشه که در یک آموزش شبیه هم به نظر می‌رسند، دو کار کاملاً متفاوت انجام می‌دهند. یکی مرجع صدور گواهی را نگه می‌دارد: کلید خصوصی‌اش، شمارنده سریالش و سابقه هر چیزی که امضا کرده است. دیگری آنچه را دیمن برای شروع و سرویس‌دهی به کلاینت‌ها لازم دارد نگه می‌دارد. گذاشتن هر دو روی یک میزبان و زیر یک حساب برای یک بعدازظهر راحت و برای بقیه عمر استقرار پرهزینه است، چون دیمن آن‌گاه کنار تنها کلیدی کار می‌کند که می‌تواند هر هویتی را که بخواهد بسازد.

فضای کاری CA چه دارد

پوشه PKI وضعیت صادرکننده است، نه پیکربندی. کلید خصوصی و گواهی CA، فایل سریال، فهرست گواهی‌های صادرشده و مواد هر هویتی که از آن‌ها ساخته شده را در خود دارد.

امضای یک درخواست آن وضعیت را تغییر می‌دهد، به همین دلیل فضای کاری به حسابی تحت کنترل مدیر روی میزبانی تعلق دارد که سرویس VPN رویش اجرا نمی‌شود. هر کس کلید خصوصی CA را بخواند می‌تواند گواهی‌ای صادر کند که سرور به آن اعتماد خواهد کرد، پس محافظت از کلید همان کل مدل اعتماد در یک فایل است. کپی کردنش به محل دوم برای صرفه‌جویی در یک قدم، چیز دومی برای محافظت و چیز دومی برای فراموش کردن می‌سازد. هر امضا هم سریال را زیاد می‌کند و هم مدخلی به فهرست می‌افزاید، از این رو فضای کاری یک نسخه از وضعیت است نه پوشه‌ای از فایل‌ها.

گواهی عمومی CA متفاوت است. قرار است توزیع شود، و همان چیزی است که کلاینت‌ها و سرورها با آن یکدیگر را بررسی می‌کنند.

دیمن هنگام شروع چه می‌خواند

سرور در حال اجرا مجموعه کوچکی را مصرف می‌کند: گواهی خودش، کلید خصوصی خودش، گواهی CA برای بررسی همتاها، و هر مواد کلیدی که حالت برگزیده‌اش لازم دارد. این مسیرها را هنگام راه‌اندازی و دوباره هنگام بازبارگذاری می‌خواند.

مالکیت را باید نسبت به واحدی سنجید که واقعاً اجرا می‌کند، نه نسبت به پوسته روت تعاملی. جداسازی اعلام‌شده می‌تواند بخشی از سیستم فایل را فقط‌خواندنی یا نامرئی کند، حتی وقتی آزمایش دستی با روت موفق می‌شود.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

خط سوم همان است که مردم از آن می‌گذرند. از حساب خود دیمن می‌پرسد که آیا می‌تواند کلید را بخواند، و این تنها نسخه‌ای از پرسش است که پس از کنار گذاشتن امتیاز اهمیت دارد. خروج صفر با روت چیزی درباره آنچه پس از کنار گذاشتن امتیاز رخ می‌دهد نمی‌گوید.

دو مسیر خرابی را پیش از تغییر هر مجوزی باید جدا کرد. شکست امضا به پوشه PKI، مجوز جست‌وجو در پوشه‌های والدش و حسابی که صادرکننده را اجرا می‌کند اشاره دارد. شکست راه‌اندازی به واحد، پوشه کارش و مسیرهای نام‌برده در پیکربندی سرور اشاره دارد. خواندنی کردن کل درخت برای همه هیچ‌کدام را درست نمی‌کند، و مرزی را که هر دو به آن وابسته‌اند برمی‌دارد.

چرا کپی کردن کلید CA روی سرور بعداً شکست می‌خورد

کپی معمولاً به‌عنوان اقدامی برای اشکال‌زدایی آغاز می‌شود: کسی می‌خواهد کلاینتی را روی میزبان VPN تمدید کند، پس کلید CA در /etc/openvpn می‌افتد و تمدید کار می‌کند. کار فوری موفق می‌شود و مرز از میان می‌رود.

سپس از سرور نسخه پشتیبان گرفته می‌شود و مرجع امضا به پشتیبان‌ها می‌پیوندد. یک اسنپ‌شات، یک بسته پشتیبانی یا نسخه‌ای از پوشه پیکربندی اکنون توان صدور هویت‌های مورد اعتماد را تا زمانی که CA معتبر است با خود دارد. هر کس آن نسخه را داشته باشد می‌تواند برای هر نامی که سرور می‌پذیرد گواهی بسازد، از جمله نام‌هایی که هرگز صادر نشده‌اند. تنها سابقه آن صدور همان است که خودشان بخواهند نگه دارند.

بازیابی از چنین وضعیتی به حذف یک فایل مربوط نیست. باید تصمیم بگیرید کلید افشا شده است یا نه، اگر شده CA را بچرخانید، و اعتماد را دوباره میان همه همتاها توزیع کنید. فضای کاری جداگانه کل این گفت‌وگو را حذف می‌کند.

حساب‌ها، پوشه‌ها، پشتیبان‌ها

به صادرکننده حساب و پوشه خانگی خودش را بدهید، هر جا عملی است دور از میزبان VPN نگه دارید. به دیمن حساب دیگری بدهید، با دسترسی خواندن به مواد مستقرشده و بدون دسترسی نوشتن به هر چیزی که گواهی صادر می‌کند. با کپی کردن گواهی‌های عمومی به بیرون مستقر کنید و هرگز وضعیت خصوصی صادرکننده را به درون نکشید. از دو نقش جداگانه پشتیبان بگیرید، چون حساسیت و داستان بازیابی‌شان فرق دارد.

پس از ابطال، فایل CRL را که پیکربندی سرور نام می‌برد به‌روز کنید، سپس سرویس را بازبارگذاری کنید تا اتصال‌های جدید آن را بخوانند. مستندات Easy-RSA چیدمان فضای کاری و روند امضا را پوشش می‌دهد؛ قواعد مالکیت پیرامونش همچنان تصمیمی درباره میزبان شماست. با openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate تأیید کنید سرویس چه بارگذاری کرده، به‌جای فرض اینکه بازبارگذاری آن را برداشته است.

آزمایشی که تفکیک را اثبات می‌کند

حالت منفی را بررسی کنید، نه فقط حالت کارکننده را. گواهی‌ای را طبق طرح از حساب صادرکننده امضا کنید، سپس تأیید کنید همان حساب نمی‌تواند سرویس را راه بیندازد یا کلید خصوصی سرور را بخواند. سپس تأیید کنید حساب دیمن نمی‌تواند کلید خصوصی CA را بخواند.

این سه بررسی چند دقیقه وقت می‌گیرند و از تغییر کارکنان جان سالم به در می‌برند، چون جمله‌هایی درباره مجوزها هستند نه درباره عادت. نتیجه را همراه مسیرها و حساب‌هایی که پوشش داده و تاریخ اجرا بنویسید. وگرنه نفر بعدی که این استقرار را به ارث می‌برد، مرز را دوباره از آموزشی استخراج می‌کند که هرگز مرزی نداشت. سابقه تاریخ‌دار همچنین همان چیزی است که بازبینی بعدی را چند دقیقه می‌کند نه یک بعدازظهر.