העברת backend לאימות VPN בלי לעשות שימוש חוזר בגיבובים ישנים
העברת זהויות VPN היא חיתוך, לא העתקה: מיפוי שרשרת האימות, העברת קבוצת פיילוט, בדיקת שינויי אישורים ותכנון שחזור שאיפוס אינו מבטל.
שמות משתמש מופיעים במדריך החדש, ההעברה מוכרזת כמושלמת, וההתחברויות עדיין נכשלות. לשער עדיין דרושים נתיב אימות נתמך ותוצאת הרשאה נכונה, ואף אחד מהם אינו נובע ממדריך שמכיל כעת את החשבונות. העברת backend היא חיתוך עם מחזור חיים, לא עבודת העתקה. התסמין שלהלן הוא זה שמגלה בדרך כלל את ההבדל.
התסמין: החשבונות קיימים, ההפעלות לא
המדריך החדש מכיל כל שם משתמש, כריכה לבדיקה מצליחה, ולקוח ה-VPN עדיין מחזיר כשל אימות. השילוב הזה אומר שהזהות קיימת, אבל נתיב האימות שהשער משתמש בו אינו מגיע אליה, או מגיע אליה בשיטה שאינה יכולה לספק אותה. שניהם תצורה, ואלה בעיות שונות.
הראשון הוא תִקשור: השער מצביע על backend שאינו עונה, משתמש בסוד משותף שהצד השני אינו מצפה לו, או מבקש מאפיין שהשירות החדש אינו מחזיר. השני הוא קריפטוגרפי: השיטה דורשת את הסוד המקורי, והמאגר החדש מחזיק רק גיבוב שלו. טקסט השגיאה דומה בשני המקרים, ולכן השניים מטופלים כבעיה אחת.
הפרדת השניים לפני נגיעה בחשבונות חוסכת שבוע. האחד הוא שאלת ניתוב ואמון, האחר הוא החלטה על איפוס אישורים, וערבובם מייצר שינויים שאיש אינו יכול לייחס.
מפו את השרשרת לפני שמעבירים מישהו
רשמו שישה דברים לכל פרופיל לקוח: שיטת האימות החיצונית, שיטה פנימית אם קיימת, זהות השרת שהלקוח מצפה לה, הממשק בין השער ל-backend, המאפיין שהשער ממפה לחברות בקבוצה, ומדיניות המשאבים הנובעת מכך. קריאה לפי הסדר מראה לאיזו חוליה אין בעלים. לכל פריט יש אחראי, והחיתוך נכשל בזה שאיש לא בדק.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
התחברות רגילה למדריך כמעט אינה עוברת דבר מהשרשרת הזו. היא מוכיחה שהחשבון קיים והסיסמה עובדת, כלומר בדיוק החלק שמעולם לא היה מוטל בספק.
גיבובים אינם נוסעים בין שיטות
יש לבדוק את תאימות האישורים פעם אחת, לפני שקבוצה כלשהי עוברת. FreeRADIUS מתעד את החלוקה בבירור: בדיקת CHAP שהשרת מבצע בעצמו דורשת את הסיסמה בפועל, ו-MS-CHAP מקבל את הסיסמה הזו או חומר NT מתאים. גיבוב שנוצר למטרה אחרת אינו מתאים לאף אחד מהמקרים, חזק ככל שיהיה.
ההבחנה היא במי מחשב את ההוכחה. שיטה שמאמתת על ידי כריכה למדריך מאפשרת למדריך לבדוק מה שהוא יכול לבדוק. שיטה שמאמתת על ידי חישוב מחדש של תגובת אתגר צריכה את הסוד עצמו, כי השרת חייב לבצע את אותו חישוב.
כשהחומר חסר, האפשרויות ההגונות הן איפוס נתמך, רישום מחדש, שירות אימות חיצוני או שינוי שיטה. ייצוא זמני של סיסמאות ברות שחזור אינו ברשימה הזו. הוא יוצר מאגר אישורים בטקסט גלוי בשבוע הכאוטי ביותר של הפרויקט, והוא בדרך כלל שורד את ההעברה.
קבוצת פיילוט, ואז שינויי מחזור חיים
העבירו קבוצה קטנה של זהויות מאושרות עם הלקוח האמיתי, ובדקו ארבעה דברים: התחברות טרייה, אישור שגוי בכוונה, המשאבים שההפעלה רשאית להגיע אליהם, והמשאבים שאסור לה. בדקו גם את זהות השרת שהלקוח קיבל, כי אי-התאמה בשם תעודה אינה נראית עד שמישהו קורא את יומן הלקוח.
לאחר מכן תרגלו את השינויים שהפריסה באמת תלויה בהם. שנו סיסמה, חדשו או רשמו מחדש תעודה, והסירו גישה מחשבון פיילוט אחד. אחרי כל אחד, אשרו איזה מאמת טיפל בניסיון, כי הפעלה שנוצרה לפני החיתוך עשויה להמשיך לעבוד ולא מוכיחה דבר על ההתחברות הבאה.
הפרידו את אספקת הפרופיל מהחלפת הזהות. כל קבוצה צריכה את הפרופיל המיועד שלה, את מצב האישור או הרישום שלה, את שירות האימות שבו עליה להשתמש ואיש קשר לתמיכה, ואף אחד מהרשומות האלה לא יכיל סוד.
אם הנתיב הישן והחדש מתקיימים במקביל, הגבילו אותם בתאריך סיום. נסיגה אוטומטית עלולה להכניס חשבון דרך אישור ישן לאחר שהבעלים החדש הסיר את הגישה, וזו רגרסיית אבטחה בתחפושת של זמינות.
שחזור לאחור אינו יכול להחזיר אישור
היפוך החיתוך משאיר את המדריך בדיוק במצבו כעת. סיסמה שאופסה נשארת מאופסת, תעודה שבוטלה נשארת מבוטלת, ופורמט אישור ששונה נשאר משונה. אלה אירועים במדריך, והשער מעולם לא היה המקור שלהם. יש להגדיר שחזור לכל אירוע, ושום חלק מזה לא יכול להיות תלוי בשחזור סוד מגיבוב בלתי תואם.
השאירו נתיב ניהולי שאינו משתמש בחיבור המועבר. כשהאימות החדש נכשל, עצרו את הקבוצה והשתמשו בנתיב השחזור המתועד שלה במקום להחליש את האימות לכולם כדי לעמוד בלוח זמנים.
לאחר כיסוי הקבוצות, הוציאו משימוש את האישורים, הפרופילים ויחסי האמון הישנים של ה-backend דרך הבעלים שלהם. אשרו שהנתיב הישן אינו מכניס יותר משתמשים, ושמרו את מיפוי הזהות למדיניות נטול הסודות שהתמיכה עדיין צריכה. העברה מסתיימת כשמחזור החיים החדש עובד ואיש אינו נכנס יותר דרך הנתיב הישן, לא כשהחשבונות נראים שלמים.