השתמשו ב-CA הארגוני הקיים שלכם עבור עמיתי OpenVPN

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

הנפיקו שני תפקידים במקום זהות משותפת אחת

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

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

חברו את קלטי האמון בכל צד

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

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

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

מסרו תעודות ביניים בלי להרחיב את האמון

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

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

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

החליטו איך הביטול מגיע בפועל

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

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

הוכיחו קבלה עם לקוח אמיתי

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

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