প্রাইভেট CA ব্যাকআপ: এনক্রিপ্টেড আর্কাইভ বনাম HSM কী ব্যাকআপ
এনক্রিপ্টেড আর্কাইভ বা HSM-মোড়ানো কী: প্রতিটি VPN CA ব্যাকআপ মডেল কীভাবে পুনরুদ্ধার হয়, তাতে কী থাকতে হবে, এবং কোন ব্যর্থতা আপনি সত্যিই টিকে থাকতে পারেন।
এটির বেশিরভাগ নির্ধারণ করে যে প্রশ্নটি তা নয় যে আপনি আর্কাইভটি কীভাবে এনক্রিপ্ট করেন। প্রশ্নটি হলো আপনার CA প্রাইভেট কী আদৌ তার কন্টেইনার ছাড়তে পারে কি না। যদি কী একটি ফাইল হয়, আপনি পুরো CA ডিরেক্টরি একটি এনক্রিপ্টেড ব্লবে কপি করে মিনিটের মধ্যে শেষ করতে পারেন। যদি এটি এমন HSM বা টোকেনে থাকে যা কীটিকে নন-এক্সট্রাক্টেবল হিসেবে চিহ্নিত করে, তবে সেই কপি নেই, এবং আপনার পরিকল্পনা ভেন্ডরের মোড়ানো-ও-পুনরুদ্ধার পদ্ধতি নিয়ে পরিকল্পনায় পরিণত হয়। উভয় মডেল কাজ করে, তারা ভিন্নভাবে ব্যর্থ হয়, এবং যে ব্যর্থতা আপনি টিকে থাকতে পারেন সেটিই ডিজাইনের কেন্দ্রে রাখার যোগ্য।
দুটি ব্যাকআপ মডেল কোথায় আলাদা হয়
মডেল A হলো ডিরেক্টরি কপি। OpenSSL-ধাঁচের CA একটি কাজের ডিরেক্টরি, একটি একক সার্টিফিকেট নয়: 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 ব্যাকআপে কী থাকতে হবে
উভয় মডেলের একই রেকর্ড সেট দরকার। OpenSSL CA-তে সেই ফাইলগুলি হলো index.txt, প্রতিটি ইস্যুকৃত সার্টিফিকেটের জন্য একটি সারি যাতে স্ট্যাটাস, মেয়াদ, সিরিয়াল ও সাবজেক্ট থাকে, তারপর index.txt.attr, 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-এর ফিঙ্গারপ্রিন্ট আপনার লিখে রাখা মানের সাথে তুলনা করুন, সিরিয়ালটি আপনার শেষ ইস্যুকৃত সার্টিফিকেট যা বোঝায় তার সাথে মেলে কিনা নিশ্চিত করুন, একটি ফেলনা CN-এর জন্য একটি সার্টিফিকেট ইস্যু করুন এবং index.txt একটি সারি পাচ্ছে দেখুন, তারপর সেই সার্টিফিকেট প্রত্যাহার করুন এবং CRL পুনরায় তৈরি করুন।
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdateHSM-এর সাথে একই পরীক্ষা মডিউলের মধ্য দিয়ে চলে। ব্লবটি প্রতিস্থাপন ডিভাইসে খুলুন, মডিউল যে CA সার্টিফিকেট জানায় তা আপনার লিখিত ফিঙ্গারপ্রিন্টের সাথে মেলে নিশ্চিত করুন, এবং কেবল তখনই এটি সাইন করতে দিন। যদি মডিউলের নিজস্ব অবজেক্ট স্টোর থাকে, মোড়ানোকে কী অবজেক্ট ও তার লেবেল কভার করতে হবে, কারণ ভিন্ন লেবেলের অধীনে কী পুনরুদ্ধার করলে যে কনফিগারেশন সেটির দিকে ইশারা করে তা ভেঙে যায়।
যে ব্যর্থতার ধরনগুলি সিদ্ধান্ত নির্ধারণ করে
পাঁচটি ব্যর্থতা বেশিরভাগ বাস্তব ক্ষতির কারণ। গোপনীয়তার স্বাধীন কপি ছাড়া ভুলে যাওয়া আর্কাইভ পাসফ্রেজ আর্কাইভকে ইট বানিয়ে দেয়। এক ডিস্কে একক কপি সেই ডিস্কের সাথে মরে, আর চেকসাম কখনও বলে না ডিক্রিপশন এখনও কাজ করে কি না। ব্যাকআপের তারিখের পরে প্রত্যাহার করা সার্টিফিকেট পুনরুদ্ধারের পরে আবার বৈধ দেখায়, তাই আপনার ব্যাকআপ ব্যবধানই আপনার প্রত্যাহারের অন্ধ স্থান। পুরোনো সিরিয়াল কাউন্টার পুনরুদ্ধার করলে সিরিয়াল নম্বর পুনরায় ব্যবহৃত হয় এবং সিরিয়াল-কীড ক্যাশ ও CRL লুকআপ বিভ্রান্ত হয়। প্রতিস্থাপন HSM যদি মোড়ানো ব্লব প্রত্যাখ্যান করে, তবে হার্ডওয়্যার বদল পূর্ণ পুনঃইস্যুতে পরিণত হয়।
মডেল A প্রথম চারটির সাথে খারাপভাবে কিন্তু দৃশ্যমানভাবে মোকাবেলা করে। মডেল B সেগুলির সাথে ভালোভাবে মোকাবেলা করে যতক্ষণ না মডিউল বা ভেন্ডর প্রক্রিয়া ব্যর্থ হয়। যদি আপনার কী এক্সপোর্টযোগ্য হয় এবং দলটি ছোট হয়, এনক্রিপ্টেড আর্কাইভই সৎ পছন্দ, দুইটি মাধ্যম ও লিখিত পাসফ্রেজ পদ্ধতি দ্বারা সমর্থিত। যদি কী নন-এক্সট্রাক্টেবল হয়, আপনার কোনো পছন্দই নেই, এবং কাজটি সেই দিনের আগে ভেন্ডরের পুনরুদ্ধার পথ প্রমাণের দিকে সরে যায় যেদিন আপনার এটি দরকার।
মডেল বাছাই ও সময়সূচি
তিনটি শর্ত সিদ্ধান্তটি নিষ্পত্তি করে। ভেন্ডর প্রক্রিয়া ছাড়া কী এক্সপোর্ট করা যায় কি? পুনরুদ্ধার কি এমন হার্ডওয়্যারে পড়তে হবে যা আপনার ইতিমধ্যে নেই? সাপোর্টের সাথে তর্ক করার সময় ইস্যু কতক্ষণ থামতে পারে? এই তিনটির উত্তর দিন এবং মডেল নির্ধারিত; এর পরে সবকিছু সময়সূচি।
প্রতিটি সাইনিং অনুষ্ঠানের পরে এবং যেকোনো কনফিগারেশন পরিবর্তনের আগে ব্যাকআপ নিন, কারণ কনফিগারেশন অবস্থার অংশ। ভিন্ন জায়গায় ভিন্ন মাধ্যমে দুটি কপি রাখুন, একটি অফলাইন, এবং ডিক্রিপশন গোপনীয়তাটি কপিগুলির থেকে ভিন্ন বিশ্বাস ডোমেইনে রাখুন। ব্যাকআপ রেকর্ডে শেষ সফল পুনরুদ্ধারের তারিখ লিখুন। যে ব্যাকআপ কখনও পুনরুদ্ধার হয়নি তা একটি অনুমান, নিয়ন্ত্রণ নয়।
টিকিট বন্ধ করার আগে এই পাঁচটি বিষয় নিশ্চিত করুন:
- ca.crt-এর ফিঙ্গারপ্রিন্ট ব্যাকআপের বাইরে কোথাও লিখিত আছে।
- index.txt, serial, crlnumber ও openssl.cnf সবই আর্কাইভ বা ব্লব সেটের ভিতরে।
- পাসফ্রেজ বা মোড়ানো কী-এর হেফাজত নথিভুক্ত এবং আর্কাইভ মালিক ছাড়া অন্য কারও কাছে।
- বিচ্ছিন্ন হোস্টে একটি ইস্যু ও একটি প্রত্যাহার দিয়ে পুনরুদ্ধার পরীক্ষা করা হয়েছে।
- আপনার ব্যাকআপ ব্যবধান যে প্রত্যাহার ফাঁক বোঝায় তা লিখিতভাবে মেনে নেওয়া হয়েছে বা কমানো হয়েছে।