การสำรองข้อมูล CA ส่วนตัว: คลังเก็บที่เข้ารหัสหรือการสำรองคีย์ HSM

คำถามที่ตัดสินเรื่องนี้ส่วนใหญ่ไม่ใช่ว่าคุณเข้ารหัสคลังเก็บอย่างไร แต่เป็นว่า คีย์ส่วนตัวของ CA คุณออกจากคอนเทนเนอร์ได้หรือไม่ ถ้าคีย์เป็นไฟล์ คุณคัดลอกไดเรกทอรี CA ทั้งหมดลงในบลอบที่เข้ารหัสแล้วเสร็จในไม่กี่นาที ถ้าคีย์อยู่ใน HSM หรือโทเคนที่ทำเครื่องหมายว่าแยกออกไม่ได้ สำเนานั้นไม่มีอยู่จริง และแผนของคุณก็กลายเป็นแผนเกี่ยวกับขั้นตอนการห่อและการกู้คืนของผู้จำหน่าย ทั้งสองแบบทำงานได้ ล้มเหลวต่างกัน และความล้มเหลวที่คุณอยู่รอดได้คือสิ่งที่ควรออกแบบให้รองรับ

จุดที่สองแบบของการสำรองข้อมูลแยกจากกัน

แบบ A คือการคัดลอกไดเรกทอรี CA สไตล์ OpenSSL เป็นไดเรกทอรีทำงาน ไม่ใช่ใบรับรองเดียว: ca.key หรือ cakey.pem, ca.crt, ฐานข้อมูลการออกใบรับรอง, ตัวนับ serial และ crlnumber และ openssl.cnf ปิดผนึกไดเรกทอรีนั้นด้วยรหัสสมมาตร ย้ายผลลัพธ์ไปยังสื่อที่สอง และการกู้คืนหมายถึงแกะ ตรวจสอบ เซ็นชื่อ ทุกสิ่งที่ผู้ออกใบรับรองต้องการเดินทางไปด้วยกัน รวมถึงประวัติการเพิกถอนหลายสัปดาห์ที่ไม่มีใครจำได้ว่าเขียนไว้

แบบ B คือการกักคีย์ คีย์ถูกสร้างภายในโมดูล PKCS#11 และทำเครื่องหมายว่าแยกออกไม่ได้ โมดูลห่อคีย์เพื่อสำรองได้ แต่ไม่มีกระบวนการใดอ่านไบต์ดิบเลย สำรองของคุณจึงเป็นสองสิ่งที่จะต้องกู้คืนตามลำดับที่ถูกต้อง: บลอบคีย์ที่ห่อแล้วซึ่งมีเพียงตระกูลโมดูลนั้นจะเปิดได้ บวกสำเนาธรรมดาของฐานข้อมูล การกำหนดค่า และใบรับรอง

การเปรียบเทียบไม่เคยเป็นเรื่องว่าแบบไหนแข็งแกร่งกว่าในเชิงนามธรรม แต่เป็นเรื่องว่าทีมของคุณกู้คืนอันไหนได้เมื่อตี 2 กับคนที่ตื่นอยู่จริง คลังเก็บที่ไม่มีใครถอดรหัสได้และบลอบ HSM ที่ไม่มีใครทดสอบมีค่าไร้ประโยชน์เท่ากัน ความต่างคือความล้มเหลวของคลังเก็บปรากฏในตัวจัดการรหัสผ่าน ส่วนความล้มเหลวของ HSM ซ่อนอยู่ในสัญญาบริการ

สิ่งที่การสำรองข้อมูล CA ทุกชุดต้องมี

ทั้งสองแบบต้องมีชุดบันทึกเดียวกัน ใน CA แบบ OpenSSL ไฟล์เหล่านั้นคือ 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 -nextupdate

กับ HSM การทดสอบเดียวกันวิ่งผ่านโมดูล แกะบลอบเข้าไปในอุปกรณ์ทดแทน ยืนยันว่าใบรับรอง CA ที่โมดูลรายงานตรงกับลายนิ้วมือที่คุณบันทึกไว้ แล้วจึงให้เซ็นชื่อ ถ้าโมดูลมีที่เก็บวัตถุของตัวเอง การห่อต้องครอบคลุมวัตถุคีย์และป้ายกำกับของมัน เพราะการกู้คืนคีย์ภายใต้ป้ายอื่นจะทำให้การกำหนดค่าที่ชี้ไปยังคีย์นั้นเสีย

รูปแบบความล้มเหลวที่กำหนดทางเลือก

ความล้มเหลวห้าอย่างอธิบายการสูญเสียจริงส่วนใหญ่ รหัสผ่านคลังเก็บที่ลืมโดยไม่มีสำเนาความลับแยกต่างหากทำให้คลังเก็บเป็นอิฐ สำเนาเดียวบนดิสก์เดียวตายไปพร้อมดิสก์นั้น และเช็กซัมไม่เคยบอกว่าการถอดรหัสยังทำงานได้หรือไม่ ใบรับรองที่ถูกเพิกถอนหลังวันที่สำรองดูใช้ได้อีกครั้งหลังการกู้คืน ช่วงเวลาสำรองของคุณจึงเป็นจุดบอดในการเพิกถอนด้วย การกู้คืนตัวนับ serial เก่าใช้หมายเลขซีเรียลซ้ำและทำให้แคชและการค้นหา CRL ที่อิง serial สับสน HSM ทดแทนที่ปฏิเสธบลอบที่ห่อแล้วเปลี่ยนการเปลี่ยนฮาร์ดแวร์เป็นการออกใบรับรองใหม่ทั้งหมด

แบบ A รับมือสี่ข้อแรกได้แย่แต่เห็นได้ชัด แบบ B รับมือได้ดีจนกระทั่งโมดูลหรือกระบวนการของผู้จำหน่ายล้มเหลว ถ้าคีย์ของคุณส่งออกได้และทีมเล็ก คลังเก็บที่เข้ารหัสคือทางเลือกที่ซื่อสัตย์ โดยมีสื่อสองชุดและขั้นตอนรหัสผ่านเป็นลายลักษณ์อักษร ถ้าคีย์แยกออกไม่ได้คุณไม่มีทางเลือกเลย และงานจะย้ายไปที่การพิสูจน์เส้นทางกู้คืนของผู้จำหน่ายก่อนวันที่คุณต้องใช้มัน

การเลือกแบบและการจัดตาราง

เงื่อนไขสามข้อตัดสินการตัดสินใจ คีย์ส่งออกได้โดยไม่ต้องมีกระบวนการของผู้จำหน่ายหรือไม่ การกู้คืนต้องลงบนฮาร์ดแวร์ที่คุณยังไม่มีหรือไม่ การออกใบรับรองหยุดได้นานแค่ไหนขณะที่คุณเถียงกับฝ่ายสนับสนุน ตอบสามข้อนั้นแล้วแบบก็ถูกตัดสิน ทุกอย่างหลังจากนั้นคือการวางแผน

สำรองข้อมูลหลังพิธีเซ็นชื่อทุกครั้งและก่อนการเปลี่ยนแปลงการกำหนดค่าใด ๆ เพราะการกำหนดค่าเป็นส่วนหนึ่งของสถานะ เก็บสำเนาสองชุดบนสื่อต่างกันในที่ต่างกัน หนึ่งในนั้นออฟไลน์ และเก็บความลับในการถอดรหัสไว้ในโดเมนความเชื่อถือที่ต่างจากสำเนา เขียนวันที่กู้คืนสำเร็จล่าสุดลงในบันทึกการสำรอง สำรองที่ไม่เคยถูกกู้คืนคือสมมติฐาน ไม่ใช่การควบคุม

ก่อนปิดตั๋ว ให้ยืนยันห้าข้อนี้:

• ลายนิ้วมือของ ca.crt ถูกบันทึกไว้ที่ใดที่หนึ่งนอกสำรอง
• index.txt, serial, crlnumber และ openssl.cnf อยู่ในคลังเก็บหรือชุดบลอบทั้งหมด
• การดูแลรหัสผ่านหรือคีย์ที่ห่อแล้วมีเอกสารและอยู่กับคนอื่นที่ไม่ใช่เจ้าของคลังเก็บ
• การกู้คืนถูกทดสอบบนโฮสต์แยกที่มีการออกหนึ่งครั้งและการเพิกถอนหนึ่งครั้ง
• ช่องว่างการเพิกถอนที่ช่วงเวลาสำรองของคุณสื่อถึงได้รับการยอมรับเป็นลายลักษณ์อักษรหรือถูกทำให้สั้นลง