CSR לבדו אינו הרשמה: מה רשות אישורים של VPN חייבת לבדוק

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

כדאי להשוות שני מודלי הרשמה לפי מה שהם קושרים, ולא לפי באיזה פרוטוקול הם מדברים.

בקשה מצהירה על שם, היא אינה מוכיחה אותו

קראו את הבקשה לפי מה שיש בה באמת: מפתח ציבורי, נושא שהמבקש בחר וחתימה עצמית על שניהם. שום דבר במבנה הזה אינו מפנה למלאי שלכם, לספריית החשבונות או לתהליך האישור. נושא כמו cn=finance-laptop הוא מחרוזת שמישהו הקליד. עד שתהליך ההנפקה יבדוק את המחרוזת הזו מול רשומה שהוא סומך עליה, התעודה היא הצהרה עם חתימה מצורפת. ההבחנה הזו היא כל הסיבה לכך שתהליך הרשמה קיים.

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

השוו את המודלים לפי מה שהם קושרים

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

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

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

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

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

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

אמתו את התעודה שהונפקה, ואז את הגישה

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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