האצלת הנפקת אישורי VPN בלי מפתח השורש
הנפקת אישורים היא הרשאה; החזקת מפתח השורש היא יכולת. אישור ביניים מגביל את הראשונה, והסרת חשבון אינה פריצה.
לתת למישהו את היכולת לרשום לקוחות VPN ולתת לו עותק נייד של מפתח השורש הם שני מעשים שונים, וההבדל נעשה גלוי רק כאשר אותו אדם עוזב או אותו מפתח דולף. הראשון מעניק פעולה בתוך תהליך עבודה שאתם שולטים בו; השני מעניק את היכולת ליצור אמון בכל מקום, במצב לא מקוון, ללא הגבלת זמן. החליטו איזה מהשניים העבודה דורשת לפני שאתם נוגעים בחומר מפתח כלשהו. תרשים היררכיה לא יענה לכם על השאלה הזו.
כתבו את עבודת הרישום כשלוש שאלות: מי רשאי לבקש, מי מאשר, ומה מותר לרכיב המנפיק לחתום.
החליטו איזו יכולת אתם מעניקים
שירות מנפיק יכול לחשוף תהליך אישור ובמקביל להחזיק את חומר החתימה אצל בעלים נפרד. מפעיל מאשר בקשת מכשיר, השירות מיישם מדיניות ורושם את ההנפקה, ואיש מהמעורבים אינו מחזיק במפתח ה-CA. תעדו את הזהויות המותרות, המאשרים ואת הטווח של מה שהשירות רשאי לחתום; לאחר מכן הגנו על הניהול שלו בזהירות כמו על המפתח. בקשת חתימה על אישור היא בקשה, לא החלטת הרשאה.
אחסון בגיבוי חומרה משנה את הסיכון להעתקת המפתח, לא את הצורך בהרשאה. לא ניתן לייצוא פירושו שלא ניתן לשלוף את המפתח, וזה לא אומר שכל מי שיכול לקרוא לממשק החתימה זכאי לאישור. העריכו את שתי התכונות הללו בנפרד.
אישור ביניים מגביל את הסמכות
שורש יכול להנפיק אישור ביניים להנפקה יומיומית, כך שעבודה שגרתית אינה נוגעת יותר במפתח השורש, כל עוד נהלי החתימה והשחזור של השורש עצמו נשארים מוגנים. זהו גבול אמיתי והוא אינו בחינם: עוד אישור, עוד מפתח, עוד חידוש ועוד רשימת ביטולים לתחזוקה. השתמשו באחד כשהוא מייצג גבול ניהול או גבול סיכון מכוון. יצירת מנפיק לכל מנהל מייצרת יותר מכל דבר ואינה קונה דבר שתהליך העבודה לא סיפק כבר.
ודאו שמאמתי ה-VPN בונים את השרשרת כפי שאתם מצפים. שליחת אישור ביניים לבניית שרשרת והתקנתו כעוגן מהימן ישירות הם הסדרים שונים.
pathLen אפס לא אומר מה שאתם חושבים
RFC 5280 סעיף 4.2.1.9 מגדיר את האילוצים הבסיסיים, ושדה אורך הנתיב שלו מגביל כמה אישורי ביניים שאינם מונפקים לעצמם יכולים לבוא אחריו בנתיב תקף. ערך אפס מגביל עומק ביניים נוסף; הוא אינו מגביל את מספר אישורי ישות הקצה. אנשים קוראים אותו כאפס אישורים מותרים ואז תוהים מדוע ההנפקה עדיין עובדת. קראו את השדה כמגבלת עומק על רשויות אישורים, וההתנהגות הופכת לצפויה.
אותו סעיף מרמיז שעוגן אמון הוא קלט לאימות נתיב ולא אישור רגיל בתוך הנתיב. לכן פרסום רשומת ביטול לשורש חתום עצמית אינו מסיר אותו באופן אמין מכל מאגר.
עזיבת עובד אינה פריצה למפתח
כאשר העוזב החזיק רק בחשבון ניהול אישי, בטלו את הגישה ואת ההפעלות שלה דרך תהליך הזהות הנתמך, ואז עברו על הפעילות והאישורים שהיא יצרה. אישורי לקוח שהונפקו קודם אינם נעשים פסולים משום שהמאשר שלהם עזב, והתייחסות אליהם כאל פרוצים יוצרת רישום מחדש גדול ומיותר. השבתת חשבון גם אינה יכולה לבטל מפתח חתימה שהועתק, לכן התגובה תלויה ביכולת שהוחזקה.
כאשר אישור ביניים נפרץ, יש לשלול את הרשאתו ולהחליף כל זהות שהוא ערב לה, לפי המדיניות שהמאמת אוכף. אמון השורש זקוק לתגובה משלו, משום שהעוגן חי במאגרי אמון שאולי אינכם שולטים בהם.
קבלו את התכנון עם ארבעה מקרים קונקרטיים: מכשיר כשיר נרשם, בקשה שלא אושרה נדחית, מפעיל שהוסר אינו יכול עוד להנפיק, ומנפיק שהוצא לגמלאות אינו מעניק עוד גישה. ארבע התוצאות הללו הן ה-runbook.