निजी 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 सबै अभिलेख वा ब्लब सेटभित्र छन्।
- पासफ्रेज वा बेरिएको कुञ्जीको संरक्षण लेखिएको छ र अभिलेख मालिकबाहेक अरू कसैसँग छ।
- अलग होस्टमा एक जारी र एक रद्दीकरणसहित पुनर्स्थापना परीक्षण गरिएको छ।
- तपाईंको ब्याकअप अन्तरालले सङ्केत गर्ने रद्दीकरणको खाडल लिखित रूपमा स्वीकारिएको वा छोट्याइएको छ।