კერძო 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, რომელიც ინახავს გასაცემ შემდეგ სერიულ ნომერს, 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-ზე დაფუძნებულ ქეშებსა და CRL ძიებებს. შემცვლელი HSM, რომელიც უარყოფს შეფუთულ ბლობს, აპარატურულ ჩანაცვლებას სრულ ხელახალ გაცემად აქცევს.
მოდელი A პირველ ოთხს ცუდად, მაგრამ თვალსაჩინოდ უმკლავდება. მოდელი B მათ კარგად უმკლავდება მანამ, სანამ მოდული ან მომწოდებლის პროცესი ჩავარდება. თუ თქვენი გასაღებები ექსპორტირებადია და გუნდი პატარაა, დაშიფრული არქივი პატიოსანი არჩევანია, ორი მატარებლითა და წერილობითი პაროლის პროცედურით. თუ გასაღები ამოუღებია, არჩევანი საერთოდ არ გაქვთ და სამუშაო გადადის მომწოდებლის აღდგენის გზის დამტკიცებაზე იმ დღემდე, როცა დაგჭირდებათ.
მოდელის არჩევა და დაგეგმვა
სამი პირობა წყვეტს. შეიძლება გასაღების ექსპორტი მომწოდებლის პროცესის გარეშე? უნდა დაეშვას თუ არა აღდგენა იმ აპარატურაზე, რომელიც ჯერ არ გაქვთ? რამდენ ხანს შეიძლება გაცემა გაჩერდეს, სანამ მხარდაჭერას ეკამათებით? უპასუხეთ ამ სამს და მოდელი გადაწყვეტილია; დანარჩენი ყველაფერი დაგეგმვაა.
აიღეთ სარეზერვო ასლი ყოველი ხელმოწერის ცერემონიის შემდეგ და ნებისმიერი კონფიგურაციის ცვლილებამდე, რადგან კონფიგურაცია მდგომარეობის ნაწილია. შეინახეთ ორი ასლი სხვადასხვა მატარებელზე სხვადასხვა ადგილას, ერთი მათგანი ხაზგარეშე, და გაშიფვრის საიდუმლო შეინახეთ ასლებისგან განსხვავებულ ნდობის დომენში. ჩაწერეთ ბოლო წარმატებული აღდგენის თარიღი სარეზერვო ჩანაწერზე. სარეზერვო ასლი, რომელიც არასოდეს აღდგენილა, ჰიპოთეზაა და არა კონტროლი.
სანამ ბილეთს დახურავთ, დაადასტურეთ ეს ხუთი პუნქტი:
- ca.crt-ის თითის ანაბეჭდი სადღაც სარეზერვო ასლის გარეთ არის ჩაწერილი.
- index.txt, serial, crlnumber და openssl.cnf ყველა არქივის ან ბლობების ნაკრების შიგნითაა.
- პაროლის ან შეფუთული გასაღების შენახვა დოკუმენტირებულია და არქივის მფლობელის გარდა ვიღაცას უჭირავს.
- აღდგენა გამოცდილია იზოლირებულ ჰოსტზე ერთი გაცემითა და ერთი გაუქმებით.
- თქვენი სარეზერვო ინტერვალით გამოწვეული გაუქმების ხარვეზი წერილობით მიღებულია ან შემცირებულია.