खाजगी 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, पुढील CRL क्रमांक ठेवणारा crlnumber, आणि तुमची CA खरोखर चालणाऱ्या dir, policy व default_days असलेला openssl.cnf। 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 सर्व आर्काइव्ह किंवा ब्लॉब संचात आहेत।
- पासफ्रेज किंवा गुंडाळलेल्या कीची जपणूक नोंदवली आहे आणि आर्काइव्हच्या मालकाशिवाय दुसऱ्या कोणाकडे आहे।
- वेगळ्या होस्टवर एक इश्यू आणि एक रद्दीकरणासह पुनर्संचयनाची चाचणी केली आहे।
- तुमच्या बॅकअप अंतरालने सूचित होणारी रद्दीकरणाची तफावत लेखी स्वीकारली आहे किंवा कमी केली आहे।