תכנון תבניות AD CS לתפקידי שער VPN ולקוח

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

כתבו את טבלת התפקידים לפני פתיחת מסוף התבניות

שני תפקידים, שתי מטרות. השער מוכיח זהות של שירות, ולכן התעודה שלו זקוקה ל-Server Authentication (1.3.6.1.5.5.7.3.1), לשימוש במפתח של חתימה דיגיטלית והצפנת מפתח, ולשם המארח שאליו הלקוחות מתחברים בתוך שם חלופי של הנושא. לקוחות שמאמתים באמצעות תעודות זקוקים ל-Client Authentication (1.3.6.1.5.5.7.3.2) ולזהות שמתאימה למה שהשער מצפה לו בבדיקת הצד השני. תעודת משתמש ותעודת מחשב אינן ניתנות להחלפה, מפני שהן נמצאות במאגרים שונים ומשתמשים בהן תהליכים שונים.

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

שכפלו תבנית במקום לערוך תבנית משותפת

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

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

החליטו מאיפה מגיע הנושא

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

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

פרסמו את התבנית ואז צמצמו הרשאות

יצירת אובייקט התבנית ב-AD DS ופרסומו ב-CA המנפיק הן פעולות נפרדות, שנעשות במסופים שונים. פרסמו את העותק ממסוף Certification Authority תחת Certificate Templates, ואז ודאו משורת הפקודה שה-CA מציע אותו כעת:

certutil -CATemplates
certutil -TCAInfo

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

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

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

certlm.msc
certutil -dump vpn-gateway.cer

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