גישת VPN מחשבון שירות: תעודה מול התחברות משותפת
השוו תעודת מכונה לסיסמה שמורה לגישת VPN ללא השגחה, והציבו את מגבלת ההרשאות האמיתית במדיניות שרצה לאחר ההתחברות.
שני עיצובים מכסים כמעט כל התקנת VPN ללא השגחה: התחברות אנושית משותפת שנשמרת בסקריפט, או תעודת מכונה הקשורה למארח. הם נכשלים במקומות שונים, וזה חשוב יותר ממהירות ההתקנה. סיסמה שמורה נשברת כשהבעלים משנה אותה או עוזב; תעודה נשברת כשהיא פגה או כשהמארח נבנה מחדש בלי המפתח. שלושה תנאים קובעים איזה מחיר תוכלו לשאת, ואף אחד מהעיצובים לא מגביל דבר עד שמדיניות ההרשאה עושה זאת.
התחילו מהמשימה, לא מהחשבון
המשימה מגדירה את הגבול: אילו יעדים, אילו שירותים, אילו שעות, כמה זמן הפעלה רשאית להימשך. נתיב מנהרה הוא רק חצי מהגבול הזה. השער מחליט אם ההפעלה מותרת; המשאב שמאחוריו מחליט מה ההפעלה יכולה לעשות. כתבו קודם את הרשימה, עם בעלים בשם, כי שני עיצובי הזהות חייבים למלא אותה.
הפרידו בין אימות להרשאה בזמן הכתיבה. אימות עונה מי מתחבר; הרשאה עונה למה ההפעלה רשאית להגיע לאחר מכן. RADIUS נושא את החלק השני כמאפיינים כמו Filter-Id, Framed-IP-Address, Session-Timeout ו-Class, והשער מצרף אותם ברגע שההתחברות מצליחה. עיצוב שמחליף את ההתחברות ומשאיר את ההרשאה ללא שינוי לא הגביל דבר.
התחברות אנושית משותפת: הסיסמה הופכת לגבול
שימוש חוזר בחשבון אנושי הוא הדרך המהירה ביותר וזו שמזדקנת הכי רע. האישור הוא סיסמה, ולכן היא מגיעה לסקריפט, לקובץ סביבה ולקונפיגורציית מתזמן, וכל עותק צריך סבב. כשהבעלים משנה אותה ביום שישי, המשימה נכשלת בהרצה הבאה ואיש לא מסתכל.
MFA הוא המקום שבו העיצוב הזה בדרך כלל קורס. סקריפט לא יכול לענות לבקשת push, ולכן החשבון מוחרג מהמדיניות, וזה בדיוק החשבון שתוקף היה בוחר. חריגים, עקיפות מיקום מהימן ופטורים לפי חשבון מתרבים, ואף אחד מהם אינו גלוי לאדם הבא שקורא את הגדרות השוכר.
ייחוס הוא העלות האחרת. כל הפעלה ביומן השער נושאת את אותו שם משתמש, ולכן אין דרך להבדיל בין הסנכרון הלילי לבין עבודת האדם שכתב אותו, ו ביטול המשימה פירושו ביטול אותו אדם.
תעודת מכונה: זהות הקשורה למארח
תעודה משנה את השאלה מ'מה החשבון יודע' ל'מה המארח הוא'. עם EAP-TLS הלקוח מציג תעודה ומוכיח בעלות על המפתח הפרטי המתאים; שרת המדיניות ממפה את הנושא או את חשבון המחשב לקבוצה ומחיל את המדיניות של אותה קבוצה. בלי בקשה, בלי סוד משותף שיושב בקובץ טקסט.
הגבול שהיא יוצרת צר ממה שאנשים מצפים. תעודה מאמתת את המארח, לא את המשימה, וכל מי שיש לו הרשאות root או מנהל מקומי יכול להשתמש במפתח הזה באותו מארח. שמרו את המפתח במקום שבו הפלטפורמה מגנה עליו: לא ניתן לייצוא במאגר התעודות של Windows, מגובה TPM היכן שהפרופיל מאפשר, או קובץ 0600 בבעלות root בלינוקס. פגיעה במארח היא פגיעה באישור.
תפוגה היא הכשל החוזר. תעודה שפגה ביום ראשון עוצרת את המשימה ביום ראשון, והשער מדווח בדרך כלל על כשל אימות כללי במקום לנקוב בתאריך. בדקו את התאריכים ממארח המשימה כחלק מה-runbook:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsביטול דורש נתיב שהשער בודק. OpenVPN קורא CRL דרך האפשרות crl-verify, ו-strongSwan תלוי ב-CRL או ב-OCSP לפי איך שנבנה פרופיל החיבור. אם אף אחד מהם אינו מחובר, הסרת מארח פירושה להמתין שהתעודה תפוג.
שלושה תנאים שמכריעים ביניהם
עשו את ההשוואה מול הפלטפורמה שיש לכם, לא מול עיצוב ייחוס.
תנאי ראשון: האם השער יכול להרשות זהות מכונה? אם הוא רק ממפה שם משתמש RADIUS למשתמש בספרייה, תעודה מאמתת את המארח ואז נתקעת בהרשאה. תנאי שני: האם המשימה זקוקה לגישה למשאב שרק חשבון משתמש נושא, כמו שיתוף ממופה או רישיון לפי מושב? אז זהות מכונה לא יכולה להחליף, והתשובה הכנה היא חשבון משתמש ייעודי עם מדיניות מצומצמת. תנאי שלישי: מי יכול לסובב את האישור בלי אדם בלופ? רישום אוטומטי הופך תעודות לזולות לתחזוקה; סיסמה שאדם אחד יודע לא.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
קראו את הטבלה כרשימת עלויות, לא כדירוג. עמודת הסוד השמור מנצחת במהירות הביטול ובתאימות למשאבים שמבינים רק חשבונות משתמש; עמודת התעודה מנצחת בסבב ובאי-החלשת MFA כדי שסקריפט יעבוד.
הציבו את הגבול במדיניות, אחרי האימות
בכל זהות שתבחרו, מגבלת ההרשאות שייכת למדיניות שרצה אחרי האימות. ב-NPS מדיניות רשת מוערכת לפי סדר, והמדיניות הראשונה שמתאימה לכל תנאי מחילה את הגדרותיה, כך שמדיניות רחבה שמעל מדיניות צרה קובעת את התוצאה בלי קשר למה שהלקוח מציג. Microsoft מתעדת את מודל התנאים וההגדרות ב- סקירת מדיניות NPS.
תנו למשימה קבוצה או תנאי מדיניות משל עצמה, בהתבסס על משהו שזהות המכונה נושאת: תבנית תעודה, מזהה תחנת חיוג או כתובת ממאגר ייעודי. אחר כך הגבילו את ההפעלה במאפיינים: Filter-Id לתפקיד שהשער שלכם ממפה אליו, Session-Timeout קצר כדי שמשימה תקועה תאמת מחדש במקום להחזיק הפעלה ימים, ו-Framed-IP-Address ממאגר שאתם מסננים בחומת אש בצד השני. הרשאת יישום נשארת נפרדת: מנהרה לשרת מסד נתונים אינה הרשאה לקרוא טבלה בתוכו.
אמתו סירובים, ואז תכננו הסרה
גישה שעובדת לא מוכיחה דבר על הרשאה מינימלית. בדקו במקום זאת את הסירובים: התחברו עם זהות המשימה ונסו להגיע ליעד מחוץ לרשימה, פתחו הפעלה מקבילה שנייה אם השער אמור להתיר רק אחת, וחזרו על ההתחברות לאחר ביטול האישור.
אחר כך אשרו את אותה הפעלה בשני מקומות. יומן השער מראה את הזהות שאומתה; יומן שרת המדיניות מראה איזו מדיניות התאימה ואילו מאפיינים היא החזירה. ב-OpenVPN השרת רושם את השם הנפוץ של התעודה, ו-ipsec statusall ב-strongSwan מדפיס את המנהרה שהוקמה עם הזהות שבשימוש. אם שני היומנים חלוקים על הזהות, המדיניות מתאימה למשהו אחר ממה שאתם מניחים.
הסרה שייכת לעיצוב, לא לספרינט ניקיון. כתבו את כל מה שצריך למחוק (תעודה או חשבון, חברות בקבוצה, מדיניות רשת, רשומת מאגר, כלל חומת אש ביעד) והריצו אותו פעם אחת בזמן שהמשימה קלה לבנייה מחדש.
אם אתם מתחילים היום, עבדו בסדר הזה: כתבו את רשימת המשאבים, בחרו את הזהות עם שלושת התנאים, הציבו את הגבול במדיניות, ותרגלו סירוב אחד לפני שהמשימה עולה לאוויר.