निजी 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 हैं जिसमें हर जारी प्रमाणपत्र के लिए एक पंक्ति होती है जो स्थिति, समाप्ति, 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 -nextupdateHSM के साथ वही परीक्षण मॉड्यूल से होकर जाता है। ब्लॉब को प्रतिस्थापन उपकरण में खोलें, पुष्टि करें कि मॉड्यूल जो CA प्रमाणपत्र बताता है वह आपकी दर्ज फ़िंगरप्रिंट से मेल खाता है, और तभी उसे हस्ताक्षर करने दें। अगर मॉड्यूल का अपना ऑब्जेक्ट स्टोर है, तो रैप को कुंजी ऑब्जेक्ट और उसके लेबल को कवर करना होगा, क्योंकि अलग लेबल के तहत कुंजी बहाल करने से वह कॉन्फ़िगरेशन टूट जाता है जो उसकी ओर इंगित करता है।
विफलता के वे तरीके जो चुनाव तय करते हैं
पाँच विफलताएँ अधिकांश वास्तविक नुकसान की व्याख्या करती हैं। रहस्य की स्वतंत्र प्रतिलिपि के बिना भूली हुई आर्काइव पासफ़्रेज़ आर्काइव को ईंट बना देती है। एक डिस्क पर एक ही प्रतिलिपि उस डिस्क के साथ मर जाती है, और चेकसम कभी नहीं बताता कि डिक्रिप्शन अब भी काम करता है या नहीं। बैकअप तिथि के बाद निरस्त किए गए प्रमाणपत्र बहाली के बाद फिर वैध दिखते हैं, इसलिए आपका बैकअप अंतराल ही आपका निरसन अंधा धब्बा है। पुराने serial काउंटर को बहाल करने से serial नंबर दोबारा इस्तेमाल होते हैं और serial पर आधारित कैश और CRL लुकअप उलझ जाते हैं। ऐसा प्रतिस्थापन HSM जो लिपटे ब्लॉब को अस्वीकार करता है, हार्डवेयर बदलने को पूर्ण पुनःजारी में बदल देता है।
मॉडल A पहले चार को बुरी तरह पर दृश्य रूप से संभालता है। मॉडल B उन्हें तब तक अच्छी तरह संभालता है जब तक मॉड्यूल या विक्रेता प्रक्रिया विफल न हो जाए। अगर आपकी कुंजियाँ निर्यातयोग्य हैं और टीम छोटी है, तो एन्क्रिप्टेड आर्काइव ईमानदार चुनाव है, जिसे दो माध्यम और लिखित पासफ़्रेज़ प्रक्रिया का सहारा है। अगर कुंजी नॉन-एक्सट्रैक्टेबल है तो आपके पास कोई चुनाव नहीं है, और काम उस दिन से पहले विक्रेता के बहाली मार्ग को सिद्ध करने की ओर चला जाता है जिस दिन आपको उसकी ज़रूरत होगी।
मॉडल चुनना और उसकी समय-सारणी
तीन शर्तें निर्णय तय करती हैं। क्या कुंजी विक्रेता प्रक्रिया के बिना निर्यात की जा सकती है? क्या बहाली ऐसे हार्डवेयर पर होनी चाहिए जो आपके पास पहले से नहीं है? जब आप सहायता से बहस कर रहे हों तब जारी करना कितनी देर रुक सकता है? उन तीन का उत्तर दें और मॉडल तय हो जाता है; उसके बाद सब कुछ समय-सारणी है।
हर हस्ताक्षर समारोह के बाद और किसी भी कॉन्फ़िगरेशन परिवर्तन से पहले बैकअप लें, क्योंकि कॉन्फ़िगरेशन स्थिति का हिस्सा है। अलग-अलग जगहों पर अलग-अलग माध्यमों पर दो प्रतिलिपियाँ रखें, उनमें से एक ऑफ़लाइन, और डिक्रिप्शन रहस्य को प्रतिलिपियों से अलग विश्वास डोमेन में रखें। बैकअप रिकॉर्ड पर अंतिम सफल बहाली की तारीख लिखें। जो बैकअप कभी बहाल नहीं हुआ वह परिकल्पना है, नियंत्रण नहीं।
टिकट बंद करने से पहले इन पाँच बिंदुओं की पुष्टि करें:
- ca.crt की फ़िंगरप्रिंट बैकअप के बाहर कहीं दर्ज है।
- index.txt, serial, crlnumber और openssl.cnf सभी आर्काइव या ब्लॉब सेट के अंदर हैं।
- पासफ़्रेज़ या लिपटी कुंजी की अभिरक्षा दर्ज है और आर्काइव के मालिक के अलावा किसी और के पास है।
- एक जारी और एक निरसन के साथ अलग होस्ट पर बहाली का परीक्षण किया गया है।
- आपका बैकअप अंतराल जो निरसन अंतराल दर्शाता है, लिखित रूप में स्वीकार किया गया है या छोटा किया गया है।