הרחיקו את מפתח החתימה של ה-CA של OpenVPN מ-/etc/openvpn

שתי תיקיות שנראות דומות במדריך עושות עבודות שונות לגמרי. האחת מחזיקה את רשות האישורים: המפתח הפרטי שלה, מונה הסידורי ורשומת כל מה שהיא חתמה עליו. האחרת מחזיקה את מה שהדמון צריך כדי לעלות ולשרת לקוחות. החזקת שתיהן באותו מארח תחת אותו חשבון נוחה לאחר צהריים אחד ויקרה לשאר חיי הפריסה, כי הדמון אז רץ לצד המפתח היחיד שיכול להנפיק כל זהות שירצה.

מה מכילה סביבת העבודה של ה-CA

תיקיית PKI היא מצב של מנפיק, לא תצורה. היא מכילה את המפתח הפרטי והתעודה של ה-CA, קובץ סידורי, אינדקס של תעודות שהונפקו, ואת החומר של כל זהות שנוצרה מהן.

חתימה על בקשה משנה את המצב הזה, ולכן סביבת העבודה שייכת לחשבון בשליטת מנהל במארח שבו שירות ה-VPN אינו פועל. כל מי שיכול לקרוא את המפתח הפרטי של ה-CA יכול להנפיק תעודה שהשרת יבטח בה, ולכן ההגנה על המפתח היא כל מודל האמון בקובץ אחד. העתקתו למקום שני כדי לחסוך צעד יוצרת דבר שני להגן עליו ודבר שני לשכוח. כל חתימה גם מגדילה את המונה ומוסיפה רשומה לאינדקס, ולכן סביבת העבודה היא עותק אחד של מצב ולא תיקייה של קבצים.

תעודת ה-CA הציבורית שונה. היא נועדה להפצה, והיא מה שהלקוחות והשרתים משתמשים בו כדי לאמת זה את זה.

מה הדמון קורא כשעולה

שרת פעיל צורך סט קטן: התעודה שלו, המפתח הפרטי שלו, תעודת ה-CA לאימות עמיתים, וכל חומר מפתח שהמצב שנבחר דורש. הוא קורא את הנתיבים האלה בעלייה ושוב בטעינה מחדש.

יש להעריך בעלות מול היחידה שבאמת מפעילה, לא מול מעטפת root אינטראקטיבית. בידוד מוצהר יכול להפוך חלק ממערכת הקבצים לקריא בלבד או לבלתי נראה גם כשבדיקה ידנית כ-root מצליחה.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

השורה השלישית היא זו שאנשים מדלגים עליה. היא שואלת את החשבון של הדמון עצמו אם הוא יכול לקרוא את המפתח, וזו הגרסה היחידה של השאלה שחשובה אחרי שנשמטה ההרשאה. יציאה באפס כ-root לא אומרת לכם דבר על מה שקורה אחרי הנפילה.

כדאי להפריד בין שני נתיבי הכשל לפני שמשנים הרשאה כלשהי. כשל חתימה מצביע על תיקיית ה-PKI, על הרשאת החיפוש בתיקיות האב שלה ועל החשבון שמריץ את המנפיק. כשל עלייה מצביע על היחידה, על תיקיית העבודה שלה ועל הנתיבים הנקובים בתצורת השרת. הפיכת כל העץ לקריא לכולם לא מתקנת אף אחד מהם, והיא מסירה את הגבול ששניהם תלויים בו.

למה העתקת מפתח ה-CA לשרת נכשלת מאוחר יותר

ההעתקה מתחילה בדרך כלל כמהלך ניפוי: מישהו רוצה לחדש לקוח במארח ה-VPN, ולכן מפתח ה-CA נוחת ב-/etc/openvpn והחידוש עובד. המשימה המיידית מצליחה, והגבול נעלם.

אחר כך מגבים את השרת, ורשות החתימה מצטרפת לגיבויים. תמונת מצב, חבילת תמיכה או עותק של תיקיית התצורה נושאים עכשיו את היכולת להנפיק זהויות מהימנות כל עוד ה-CA תקף. מי שמחזיק בעותק הזה יכול להנפיק תעודה לכל שם שהשרת מקבל, כולל שמות שמעולם לא הונפקו. הרשומה היחידה של ההנפקה היא זו שהם בוחרים לשמור.

התאוששות ממצב כזה אינה עניין של מחיקת קובץ. צריך להחליט אם המפתח נחשף, לסובב את ה-CA אם כן, ולחלק את האמון מחדש לכל עמית. סביבת עבודה נפרדת מונעת את כל השיחה.

חשבונות, תיקיות, גיבויים

תנו למנפיק חשבון ותיקיית בית משלו, הרחק ממארח ה-VPN היכן שזה מעשי. תנו לדמון חשבון אחר, עם גישה לקריאה לחומר שהופץ ובלי גישת כתיבה לשום דבר שמנפיק תעודות. פרסו על ידי העתקת תעודות ציבוריות החוצה ולעולם לא על ידי משיכת מצב מנפיק פרטי פנימה. גזרו גיבוי לשני התפקידים בנפרד, כי הרגישות וסיפורי השחזור שלהם שונים.

לאחר ביטול, עדכנו את קובץ ה-CRL שתצורת השרת מציינת, ואז טענו מחדש את השירות כדי שחיבורים חדשים יקראו אותו. תיעוד Easy-RSA מכסה את פריסת סביבת העבודה ואת זרימת החתימה; כללי הבעלות סביבה נשארים החלטה לגבי המארח שלכם. ודאו מה השירות טען עם openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate במקום להניח שהטעינה מחדש קלטה אותו.

בדיקה שמוכיחה את הפיצול

בדקו את המקרה השלילי, לא רק את זה שעובד. חתמו על תעודה מחשבון המנפיק כמתוכנן, ואז ודאו שאותו חשבון לא יכול להעלות את השירות או לקרוא את המפתח הפרטי של השרת. אחר כך ודאו שחשבון הדמון לא יכול לקרוא את המפתח הפרטי של ה-CA.

שלוש הבדיקות האלה אורכות כמה דקות ושורדות תחלופת עובדים, כי הן אמירות על הרשאות ולא על הרגל. כתבו את התוצאה עם הנתיבים והחשבונות שהיא כיסתה, ועם התאריך שבו הרצתם אותן. אחרת האדם הבא שיירש את הפריסה הזו יגזור את הגבול מחדש ממדריך שמעולם לא היה בו גבול. רשומה מתוארכת היא גם מה שהופך את הסקירה הבאה לדקות ולא לצהריים.