نجی CA کا بیک اپ: خفیہ کردہ محافظ خانہ یا HSM کلید بیک اپ

اس کا بیشتر حصہ طے کرنے والا سوال یہ نہیں کہ آپ محافظ خانے کو کیسے خفیہ کرتے ہیں۔ سوال یہ ہے کہ کیا آپ کی CA نجی کلید اپنے کنٹینر سے بالکل نکل سکتی ہے۔ اگر کلید فائل ہے تو آپ پوری CA ڈائریکٹری ایک خفیہ کردہ بلاب میں نقل کر کے منٹوں میں مکمل کر سکتے ہیں۔ اگر وہ HSM یا ایسے ٹوکن میں رہتی ہے جو کلید کو ناقابلِ استخراج قرار دیتا ہے، تو وہ نقل موجود نہیں، اور آپ کا منصوبہ وینڈر کے لپیٹنے اور بحال کرنے کے طریقہ کار کا منصوبہ بن جاتا ہے۔ دونوں ماڈل کام کرتے ہیں، مختلف طریقوں سے ناکام ہوتے ہیں، اور جس ناکامی سے آپ بچ سکتے ہیں وہی ڈیزائن کے قابل ہے۔

دو بیک اپ ماڈل کہاں الگ ہوتے ہیں

ماڈل A ڈائریکٹری کی نقل ہے۔ OpenSSL طرز کی CA ایک ورکنگ ڈائریکٹری ہے، ایک واحد سرٹیفکیٹ نہیں: ca.key یا cakey.pem، ca.crt، اجرا کا ڈیٹا بیس، serial اور crlnumber کاؤنٹر، اور openssl.cnf۔ اس ڈائریکٹری کو ہم آہنگ سفر سے مہر کریں، نتیجہ دوسرے ذریعے میں منتقل کریں، اور بحالی کا مطلب کھولنا، تصدیق کرنا، دستخط کرنا ہے۔ اجرا کرنے والے کو جو کچھ درکار ہے سب ساتھ سفر کرتا ہے، جن میں ہفتوں کی تنسیخ کی تاریخ بھی شامل ہے جسے کوئی یاد نہیں رکھتا کہ اس نے لکھی تھی۔

ماڈل B کلید کی حفاظت ہے۔ کلید PKCS#11 ماڈیول کے اندر پیدا ہوتی ہے اور ناقابلِ استخراج قرار دی جاتی ہے؛ ماڈیول اسے بیک اپ کے لیے لپیٹ سکتا ہے، مگر کوئی عمل کبھی خام بائٹس نہیں پڑھتا۔ تب آپ کا بیک اپ دو چیزیں ہیں جنہیں صحیح ترتیب میں بحال کرنا ہے: ایک لپٹی کلید بلاب جسے صرف وہی ماڈیول خاندان کھول سکتا ہے، اور ڈیٹا بیس، ترتیب اور سرٹیفکیٹس کی سادہ نقل۔

موازنہ کبھی اس بارے میں نہیں کہ کون سا ماڈل تجریدی طور پر زیادہ مضبوط ہے۔ یہ اس بارے میں ہے کہ آپ کی ٹیم رات 2 بجے واقعی جاگنے والے لوگوں کے ساتھ کسے بحال کر سکتی ہے۔ وہ محافظ خانہ جسے کوئی خفیہ نہیں کر سکتا اور وہ HSM بلاب جسے کسی نے آزمایا نہیں، دونوں یکساں بیکار ہیں۔ فرق یہ ہے کہ محافظ خانے کی ناکامی پاس ورڈ مینیجر میں ظاہر ہوتی ہے، اور HSM کی ناکامی معاونت کے معاہدے میں چھپی رہتی ہے۔

ہر CA بیک اپ میں کیا ہونا چاہیے

دونوں ماڈلوں کو وہی ریکارڈ سیٹ درکار ہے۔ OpenSSL CA میں وہ فائلیں 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 نمبر دوبارہ استعمال کرتا ہے اور serial پر مبنی کیشے اور CRL تلاشیں الجھا دیتا ہے۔ متبادل HSM جو لپٹا بلاب رد کرے ہارڈویئر کی تبدیلی کو مکمل دوبارہ اجرا میں بدل دیتا ہے۔

ماڈل A پہلے چار کو بری طرح مگر نظر آنے والے انداز میں سنبھالتا ہے۔ ماڈل B انہیں اس وقت تک اچھی طرح سنبھالتا ہے جب تک ماڈیول یا وینڈر کا عمل ناکام نہ ہو۔ اگر آپ کی کلیدیں قابلِ برآمد ہیں اور ٹیم چھوٹی ہے تو خفیہ کردہ محافظ خانہ ایماندار انتخاب ہے، جسے دو ذرائع اور تحریری پاس فریز طریقہ کار کی مدد حاصل ہے۔ اگر کلید ناقابلِ استخراج ہے تو آپ کے پاس کوئی انتخاب نہیں، اور کام اس دن سے پہلے وینڈر کے بحالی راستے کو ثابت کرنے کی طرف منتقل ہو جاتا ہے جس دن آپ کو اس کی ضرورت ہوگی۔

ماڈل کا انتخاب اور شیڈولنگ

تین شرطیں فیصلہ طے کرتی ہیں۔ کیا کلید وینڈر کے عمل کے بغیر برآمد ہو سکتی ہے؟ کیا بحالی ایسے ہارڈویئر پر اترنی چاہیے جو آپ کے پاس پہلے سے نہیں؟ معاونت سے بحث کرتے ہوئے اجرا کتنی دیر رک سکتا ہے؟ ان تین کا جواب دیں اور ماڈل طے ہو جاتا ہے؛ اس کے بعد سب شیڈولنگ ہے۔

ہر دستخطی تقریب کے بعد اور کسی بھی ترتیب کی تبدیلی سے پہلے بیک اپ لیں، کیونکہ ترتیب حالت کا حصہ ہے۔ دو نقلیں مختلف جگہوں پر مختلف ذرائع پر رکھیں، ایک آف لائن، اور خفیہ کشائی کا راز نقلوں سے مختلف اعتماد کے دائرے میں رکھیں۔ بیک اپ ریکارڈ پر آخری کامیاب بحالی کی تاریخ لکھیں۔ وہ بیک اپ جو کبھی بحال نہ ہوا مفروضہ ہے، کنٹرول نہیں۔

ٹکٹ بند کرنے سے پہلے یہ پانچ نکات تصدیق کریں:

• ca.crt کا فنگر پرنٹ بیک اپ سے باہر کہیں درج ہے۔
• index.txt، serial، crlnumber اور openssl.cnf سب محافظ خانے یا بلاب سیٹ کے اندر ہیں۔
• پاس فریز یا لپٹی کلید کی حفاظت دستاویزی ہے اور محافظ خانے کے مالک کے علاوہ کسی اور کے پاس ہے۔
• الگ ہوسٹ پر ایک اجرا اور ایک تنسیخ کے ساتھ بحالی آزمائی گئی ہے۔
• آپ کے بیک اپ وقفے سے ظاہر ہونے والا تنسیخ کا خلا تحریری طور پر قبول یا کم کیا گیا ہے۔