גיבוי CA פרטי: ארכיון מוצפן מול גיבוי מפתח HSM
ארכיון מוצפן או מפתח עטוף ב-HSM: כיצד משוחזר כל מודל גיבוי של CA ל-VPN, מה הוא חייב להכיל ואיזו תקלה באמת אפשר לשרוד.
השאלה שמכריעה את רוב זה אינה איך מצפינים את הארכיון. היא אם המפתח הפרטי של ה-CA שלכם יכול בכלל לצאת מהמכל שלו. אם המפתח הוא קובץ, אפשר להעתיק את כל ספריית ה-CA לבלוב מוצפן אחד ולסיים בדקות. אם הוא חי ב-HSM או בטוקן שמסמן את המפתח כבלתי ניתן לחילוץ, העתקה כזו אינה קיימת, והתוכנית שלכם הופכת לתוכנית על נוהל העטיפה והשחזור של הספק. שני המודלים עובדים, הם נכשלים אחרת, והתקלה שאתם יכולים לשרוד היא זו ששווה לתכנן סביבה.
היכן שני מודלי הגיבוי נפרדים
מודל A הוא העתקת ספרייה. CA בסגנון OpenSSL היא ספריית עבודה, לא תעודה אחת: 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 חייב להכיל
שני המודלים זקוקים לאותה קבוצת רשומות. ב-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 ישן יותר משתמש מחדש במספרי serial ומבלבל מטמונים וחיפושי CRL שממופתחים לפי serial. HSM חלופי שמסרב לבלוב העטוף הופך החלפת חומרה להנפקה מחדש מלאה.
מודל A מתמודד עם ארבעת הראשונים רע אבל באופן גלוי. מודל B מתמודד איתם היטב עד שהמודול או תהליך הספק נכשל. אם המפתחות שלכם ניתנים לייצוא והצוות קטן, הארכיון המוצפן הוא הבחירה הכנה, מגובה בשתי מדיות ובנוהל סיסמה כתוב. אם המפתח בלתי ניתן לחילוץ אין לכם שום בחירה, והעבודה עוברת להוכחת מסלול השחזור של הספק לפני היום שבו תזדקקו לו.
בחירת המודל ותזמונו
שלושה תנאים מכריעים. אפשר לייצא את המפתח בלי תהליך ספק? שחזור חייב לנחות על חומרה שאין לכם כבר? כמה זמן ההנפקה יכולה לעצור בזמן שאתם מתווכחים עם התמיכה? ענו על השלושה והמודל נקבע; כל מה שאחרי זה הוא תזמון.
קחו גיבוי אחרי כל טקס חתימה ולפני כל שינוי תצורה, כי התצורה היא חלק מהמצב. החזיקו שני העתקים על מדיות שונות במקומות שונים, אחד מהם לא מקוון, והחזיקו את סוד הפענוח בתחום אמון שונה מההעתקים. כתבו את תאריך השחזור המוצלח האחרון על רשומת הגיבוי. גיבוי שמעולם לא שוחזר הוא השערה, לא בקרה.
לפני שתסגרו את הפנייה, אשרו את חמשת הנקודות האלה:
- טביעת האצבע של ca.crt רשומה במקום כלשהו מחוץ לגיבוי.
- index.txt, serial, crlnumber ו-openssl.cnf כולם בתוך הארכיון או מערך הבלובים.
- החזקת הסיסמה או המפתח העטוף מתועדת ונמצאת אצל מישהו אחר מאשר בעל הארכיון.
- שחזור נבדק על מארח מבודד עם הנפקה אחת וביטול אחד.
- פער הביטול שמשתמע ממרווח הגיבוי שלכם התקבל בכתב או קוצר.