النسخ الاحتياطي لسلطة شهادة خاصة: أرشيف مشفّر مقابل نسخة احتياطية لمفتاح HSM

السؤال الذي يحسم معظم هذا ليس كيف تشفّر الأرشيف. إنه ما إذا كان مفتاح CA الخاص بك يستطيع مغادرة حاويته أصلاً. إذا كان المفتاح ملفاً، يمكنك نسخ دليل CA كله إلى كتلة مشفّرة واحدة والانتهاء في دقائق. وإذا كان يقيم داخل HSM أو رمز يعلّم المفتاح على أنه غير قابل للاستخراج، فإن تلك النسخة غير موجودة، وتتحول خطتك إلى خطة حول إجراء اللف والاستعادة لدى المورّد. كلا النموذجين يعملان، ويفشلان بطرق مختلفة، والعطل الذي تستطيع تجاوزه هو الذي يستحق أن تُصمّم حوله.

أين ينفصل نموذجا النسخ الاحتياطي

النموذج A هو نسخ الدليل. سلطة شهادة بأسلوب OpenSSL هي دليل عمل لا شهادة واحدة: ca.key أو cakey.pem، وca.crt، وقاعدة بيانات الإصدار، وعدّادا serial وcrlnumber، وملف openssl.cnf. اختم ذلك الدليل بشيفرة متماثلة، وانقل الناتج إلى وسيط ثانٍ، فتكون الاستعادة فكّ ضغط وتحققاً وتوقيعاً. كل ما يحتاجه المُصدر يسافر معاً، بما في ذلك أسابيع من تاريخ الإبطال لا يتذكر أحد أنه كتبه.

النموذج B هو احتواء المفتاح. يُولَّد المفتاح داخل وحدة PKCS#11 ويُعلَّم غير قابل للاستخراج؛ تستطيع الوحدة لفه للنسخ الاحتياطي، لكن لا عملية تقرأ البايتات الخام أبداً. نسختك الاحتياطية عندئذ قطعتان يجب استعادتهما بالترتيب الصحيح: كتلة مفتاح ملفوفة لا تفكّها إلا عائلة تلك الوحدة، ونسخة عادية من قاعدة البيانات والإعدادات والشهادات.

المقارنة ليست أبداً عن أي نموذج أقوى في المجرد. إنها عن أيّهما يستطيع فريقك استعادته في الساعة 2 صباحاً مع الأشخاص المستيقظين فعلاً. أرشيف لا يستطيع أحد فك تشفيره وكتلة HSM لم يختبرها أحد عديمَا الفائدة بالقدر نفسه. الفرق أن عطل الأرشيف يظهر في مدير كلمات المرور، وعطل HSM يختبئ في عقد دعم.

ما يجب أن تحتويه كل نسخة احتياطية لسلطة الشهادة

يحتاج النموذجان المجموعة نفسها من السجلات. في سلطة شهادة OpenSSL تكون تلك الملفات index.txt بسطر واحد لكل شهادة صادرة يغطي الحالة والانتهاء والرقم التسلسلي والموضوع، ثم index.txt.attr، وserial الذي يحمل الرقم التسلسلي التالي للإصدار، وcrlnumber الذي يحمل رقم CRL التالي، وopenssl.cnf بما فيه dir وpolicy وdefault_days التي تعمل بها سلطة شهادتك فعلاً. يوضّح دليل openssl-ca ما يتحكم فيه كل من تلك العدّادات. ويحفظ easy-rsa البيانات نفسها تحت pki/، مع ملف vars يحدد حقول الشهادة.

المفتاح والشهادة هما الجزءان اللذان لا يمكنك إعادة بنائهما. قاعدة البيانات هي الجزء الذي لا يمكنك إعادة تركيبه من الذاكرة. تخطّي index.txt يتركك قادراً على توقيع شهادات جديدة، وهذا هو الفخ بالضبط: تكتشف أنه ناقص أول مرة يسأل فيها عميل هل أُبطلت شهادة. سجّل بصمة سلطة الشهادة خارج النسخة الاحتياطية، حتى تُقارن الاستعادة بقيمة تثق بها لا بالملف الذي استعدته للتو.

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

اختبارات استعادة لا تنشئ نسخة ثانية من المُصدر

سلطتا شهادة حيّتان بالموضوع نفسه والمفتاح نفسه تبدوان متطابقتين لكل عميل يثق بالأصل. ووجود قائمتي CRL بالرقم نفسه لكن بمحتوى مختلف هو كيف يقبل العملاء بهدوء شهادة أبطَلتها. شغّل الاستعادة على مضيف لا طريق له إلى عملائك، أو في جهاز افتراضي يُرمى، ولا تنشر أبداً قائمة CRL التي ينتجها الاختبار.

اختبار يثبت فقط أن الأرشيف يُفتح لا يثبت شيئاً عن الإصدار. التسلسل الذي يهم: قارن بصمة ca.crt المستعادة بالقيمة التي سجّلتها، وتأكد أن الرقم التسلسلي يطابق ما تدل عليه آخر شهادة أصدرتها، وأصدر شهادة واحدة لاسم 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 التي تبلّغ عنها الوحدة تطابق بصمتك المسجلة، وبعد ذلك فقط دعها توقّع. إذا كانت للوحدة مخزن كائنات خاص بها، فيجب أن يغطي اللف كائن المفتاح وتسميته، لأن استعادة المفتاح تحت تسمية مختلفة تكسر الإعداد الذي يشير إليه.

أنماط الفشل التي تحسم الاختيار

خمسة أعطال تفسّر معظم الخسائر الحقيقية. عبارة مرور منسية للأرشيف دون نسخة مستقلة من السر تحوّل الأرشيف إلى طوبة. نسخة واحدة على قرص واحد تموت بموت ذلك القرص، والمجموع الاختباري لا يخبرك أبداً هل فك التشفير ما زال يعمل. الشهادات التي أُبطلت بعد تاريخ النسخة تبدو صالحة مجدداً بعد الاستعادة، ففترة نسخك الاحتياطي هي أيضاً نقطتك العمياء في الإبطال. استعادة عدّاد تسلسلي أقدم تعيد استخدام الأرقام التسلسلية وتشوش على الذاكنات المؤقتة وعمليات بحث CRL المرتبطة بالرقم التسلسلي. وحدة HSM بديلة ترفض الكتلة الملفوفة تحوّل تبديل جهاز إلى إعادة إصدار كاملة.

يتعامل النموذج A مع الأعطال الأربعة الأولى بشكل سيئ لكن مرئي. ويتعامل النموذج B معها جيداً حتى تفشل الوحدة أو عملية المورّد. إذا كانت مفاتيحك قابلة للتصدير والفريق صغير، فالأرشيف المشفّر هو الخيار الصادق، مدعوماً بوسيطين وإجراء مكتوب لعبارة المرور. وإذا كان المفتاح غير قابل للاستخراج فلا خيار لك على الإطلاق، وتنتقل المهمة إلى إثبات مسار استعادة المورّد قبل اليوم الذي تحتاجه فيه.

اختيار النموذج وجدولته

ثلاثة شروط تحسم القرار. هل يمكن تصدير المفتاح دون عملية مورّد؟ هل يجب أن تحل الاستعادة على عتاد لا تملكه بالفعل؟ كم يمكن أن يتوقف الإصدار بينما تتجادل مع الدعم؟ أجب عن تلك الثلاثة ويُحسم النموذج؛ وكل ما بعد ذلك جدولة.

خذ نسخة احتياطية بعد كل حفل توقيع وقبل أي تغيير في الإعدادات، لأن الإعدادات جزء من الحالة. احتفظ بنسختين على وسيطين مختلفين في مكانين مختلفين، إحداهما بلا اتصال، واحفظ سر فك التشفير في نطاق ثقة مختلف عن النسخ. اكتب تاريخ آخر استعادة ناجحة على سجل النسخة الاحتياطية. النسخة التي لم تُستعد قط فرضية لا ضابط.

قبل أن تغلق التذكرة، تأكد من هذه النقاط الخمس:

• بصمة ca.crt مسجّلة في مكان ما خارج النسخة الاحتياطية.
• index.txt وserial وcrlnumber وopenssl.cnf كلها داخل الأرشيف أو مجموعة الكتل.
• حيازة عبارة المرور أو المفتاح الملفوف موثّقة ويحتفظ بها شخص غير مالك الأرشيف.
• جُرّبت استعادة على مضيف معزول بإصدار واحد وإبطال واحد.
• الفجوة في الإبطال التي تدل عليها فترة النسخ الاحتياطي مقبولة كتابةً أو مُقصَّرة.