پشتیبان‌گیری از CA خصوصی: آرشیو رمزگذاری‌شده در برابر پشتیبان کلید HSM
آرشیو رمزگذاری‌شده یا کلید پیچیده‌شده در HSM: هر مدل پشتیبان‌گیری CA VPN چگونه بازیابی می‌شود، چه چیزی باید داشته باشد و کدام خرابی را واقعاً می‌توانید پشت سر بگذارید.
پرسشی که بیشتر این موضوع را تعیین می‌کند این نیست که چگونه آرشیو را رمزگذاری می‌کنید. این است که آیا کلید خصوصی CA شما می‌تواند اصلاً از محفظه‌اش خارج شود. اگر کلید یک فایل باشد، می‌توانید کل پوشه CA را در یک بلاب رمزگذاری‌شده کپی کنید و در چند دقیقه تمام کنید. اگر در HSM یا توکنی زندگی می‌کند که کلید را غیرقابل استخراج علامت می‌زند، آن کپی وجود ندارد، و برنامه شما به برنامه‌ای درباره رویه بسته‌بندی و بازیابی فروشنده تبدیل می‌شود. هر دو مدل کار می‌کنند، به شکل‌های متفاوت خراب می‌شوند، و خرابی‌ای که می‌توانید از سر بگذرانید همان است که ارزش طراحی حول آن را دارد.
کجا دو مدل پشتیبان‌گیری از هم جدا می‌شوند
مدل A کپی پوشه است. یک CA به سبک OpenSSL یک پوشه کاری است، نه یک گواهی واحد: ca.key یا cakey.pem، ca.crt، پایگاه داده صدور، شمارنده‌های serial و crlnumber، و openssl.cnf. آن پوشه را با یک رمز متقارن مهر و موم کنید، نتیجه را به رسانه دوم منتقل کنید، و بازیابی یعنی باز کردن، بررسی، امضا. هر چیزی که صادرکننده لازم دارد با هم سفر می‌کند، از جمله هفته‌ها تاریخچه ابطال که هیچ‌کس به یاد ندارد نوشته باشد.
مدل B مهار کلید است. کلید درون یک ماژول PKCS#11 تولید و غیرقابل استخراج علامت‌گذاری می‌شود؛ ماژول می‌تواند آن را برای پشتیبان بپیچد، اما هیچ فرآیندی هرگز بایت‌های خام را نمی‌خواند. پشتیبان شما آنگاه دو قطعه است که باید به ترتیب درست بازیابی شوند: یک بلاب کلید پیچیده‌شده که فقط همان خانواده ماژول می‌تواند باز کند، به‌علاوه یک کپی ساده از پایگاه داده، پیکربندی و گواهی‌ها.
| Attribute | Encrypted archive | HSM key backup |
|---|---|---|
| What you store | one encrypted file | wrapped blob plus CA records |
| Who can restore it | anyone holding the passphrase | holder of the module and the blob, often vendor support |
| If a copy leaks | attacker with the passphrase becomes the CA | blob is inert without the matching module |
| What usually breaks it | forgotten passphrase, one damaged copy | replacement module rejects the blob, contract gap |
مقایسه هرگز درباره این نیست که کدام مدل در انتزاع قوی‌تر است. درباره این است که تیم شما کدام را ساعت 2 بامداد با افرادی که واقعاً بیدارند می‌تواند بازیابی کند. آرشیوی که هیچ‌کس نمی‌تواند رمزگشایی کند و بلاب HSM که هیچ‌کس آزمایش نکرده به یک اندازه بی‌فایده‌اند. تفاوت این است که خرابی آرشیو در یک مدیر گذرواژه ظاهر می‌شود، و خرابی HSM در یک قرارداد پشتیبانی پنهان می‌شود.
هر پشتیبان CA باید چه داشته باشد
هر دو مدل به یک مجموعه رکورد نیاز دارند. در CA OpenSSL آن فایل‌ها index.txt با یک ردیف برای هر گواهی صادرشده است که وضعیت، انقضا، serial و موضوع را پوشش می‌دهد، سپس index.txt.attr، serial که serial بعدی برای صدور را نگه می‌دارد، crlnumber که شماره CRL بعدی را نگه می‌دارد، و openssl.cnf با dir، policy و default_days که CA شما واقعاً با آن‌ها کار می‌کند. راهنمای openssl-ca توضیح می‌دهد که هر یک از این شمارنده‌ها چه چیزی را کنترل می‌کند. easy-rsa همان داده را زیر pki/ نگه می‌دارد، و یک فایل vars فیلدهای گواهی را تعیین می‌کند.
کلید و گواهی بخش‌هایی هستند که نمی‌توانید بازسازی کنید. پایگاه داده بخشی است که نمی‌توانید از حافظه بازسازی کنید. رد کردن index.txt هنوز شما را قادر به امضای گواهی‌های جدید می‌گذارد، و این دقیقاً همان تله است: اولین بار که مشتری می‌پرسد آیا گواهی‌ای ابطال شده است، متوجه می‌شوید که وجود ندارد. اثر انگشت CA را بیرون از پشتیبان ثبت کنید، تا بازیابی با مقداری که به آن اعتماد دارید مقایسه شود، نه با فایلی که همین حالا بازیابی کرده‌اید.
openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pemآزمون‌های بازیابی که صادرکننده را شاخه‌دار نمی‌کنند
دو CA زنده با موضوع یکسان و کلید یکسان برای هر مشتری که به اصل اعتماد دارد یکسان به نظر می‌رسند. دو CRL با شماره یکسان اما محتوای متفاوت همان راهی است که مشتریان بی‌صدا گواهی‌ای را که ابطال کرده‌اید می‌پذیرند. بازیابی را روی میزبانی بدون مسیر به مشتریانتان یا در یک VM یک‌بارمصرف اجرا کنید، و هرگز CRLای که آزمون تولید می‌کند منتشر نکنید.
آزمونی که فقط اثبات می‌کند آرشیو باز می‌شود هیچ چیز درباره صدور اثبات نمی‌کند. توالی‌ای که اهمیت دارد: اثر انگشت ca.crt بازیابی‌شده را با مقدار ثبت‌شده مقایسه کنید، تأیید کنید serial با آنچه آخرین گواهی صادرشده شما حکایت دارد مطابقت دارد، یک گواهی برای یک CN یک‌بارمصرف صادر کنید و ببینید index.txt ردیفی می‌گیرد، سپس آن گواهی را ابطال و CRL را دوباره تولید کنید.
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdateبا HSM همان آزمون از طریق ماژول اجرا می‌شود. بلاب را در دستگاه جایگزین باز کنید، تأیید کنید گواهی CA که ماژول گزارش می‌کند با اثر انگشت ثبت‌شده شما مطابقت دارد، و تنها پس از آن بگذارید امضا کند. اگر ماژول انبار اشیای خودش را دارد، بسته‌بندی باید شیء کلید و برچسب آن را پوشش دهد، چون بازیابی کلید زیر برچسبی متفاوت پیکربندی‌ای را که به آن اشاره می‌کند می‌شکند.
حالت‌های خرابی که انتخاب را تعیین می‌کنند
پنج خرابی بیشتر زیان‌های واقعی را توضیح می‌دهند. عبارت عبور فراموش‌شده آرشیو بدون کپی مستقل از راز، آرشیو را به آجر تبدیل می‌کند. یک کپی روی یک دیسک با همان دیسک می‌میرد، و چک‌سام هرگز نمی‌گوید رمزگشایی هنوز کار می‌کند یا نه. گواهی‌هایی که پس از تاریخ پشتیبان ابطال شده‌اند پس از بازیابی دوباره معتبر به نظر می‌رسند، پس فاصله پشتیبان‌گیری شما نقطه کور ابطال شما هم هست. بازیابی شمارنده serial قدیمی‌تر شماره‌های serial را دوباره استفاده می‌کند و حافظه‌های نهان و جستجوهای CRL مبتنی بر serial را گیج می‌کند. HSM جایگزینی که بلاب پیچیده‌شده را رد کند، تعویض سخت‌افزار را به صدور کامل دوباره تبدیل می‌کند.
مدل A با چهار مورد اول بد اما به‌طور قابل مشاهده کنار می‌آید. مدل B تا زمانی که ماژول یا فرآیند فروشنده خراب شود خوب کنار می‌آید. اگر کلیدهای شما قابل صادرات باشند و تیم کوچک باشد، آرشیو رمزگذاری‌شده انتخاب صادقانه است، با پشتیبانی دو رسانه و یک رویه نوشتاری عبارت عبور. اگر کلید غیرقابل استخراج باشد هیچ انتخابی ندارید، و کار به اثبات مسیر بازیابی فروشنده قبل از روزی که به آن نیاز دارید منتقل می‌شود.
انتخاب مدل و زمان‌بندی آن
سه شرط تصمیم را تعیین می‌کند. آیا کلید را می‌توان بدون فرآیند فروشنده صادر کرد؟ آیا بازیابی باید روی سخت‌افزاری فرود بیاید که هنوز ندارید؟ صدور چه مدت می‌تواند متوقف بماند وقتی با پشتیبانی بحث می‌کنید؟ به آن سه پاسخ دهید و مدل تعیین می‌شود؛ هر چیز بعد از آن زمان‌بندی است.
پس از هر مراسم امضا و پیش از هر تغییر پیکربندی پشتیبان بگیرید، چون پیکربندی بخشی از وضعیت است. دو کپی روی رسانه‌های متفاوت در مکان‌های متفاوت نگه دارید، یکی از آن‌ها آفلاین، و راز رمزگشایی را در دامنه اعتماد متفاوتی از کپی‌ها نگه دارید. تاریخ آخرین بازیابی موفق را روی رکورد پشتیبان بنویسید. پشتیبانی که هرگز بازیابی نشده یک فرضیه است، نه یک کنترل.
پیش از بستن تیکت، این پنج نکته را تأیید کنید:
- اثر انگشت ca.crt جایی بیرون از پشتیبان ثبت شده است.
- index.txt، serial، crlnumber و openssl.cnf همه داخل آرشیو یا مجموعه بلاب هستند.
- نگهداری عبارت عبور یا کلید پیچیده‌شده مستند شده و کسی جز صاحب آرشیو آن را دارد.
- بازیابی روی میزبانی جداافتاده با یک صدور و یک ابطال آزمایش شده است.
- شکاف ابطالی که از فاصله پشتیبان‌گیری شما برمی‌آید به‌صورت کتبی پذیرفته یا کوتاه شده است.