EAP או תעודות לקוח? הכרעה באימות IKEv2

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

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

שני אמצעי זיהוי, שתי טענות

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

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

EAP הוא מכל, לא שיטה

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

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

פריסה מעורבת היא נורמלית

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

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

הכרעה לפי שלב הכשל

סדרו את התצפיות. שגיאת אמון לפני כל הנחיית משתמש היא בעיית תעודת שרת ואף סיסמה לא תתקן אותה. הנחיה שאחריה דחייה היא בעיית אימות משתמש, כאשר השיטה EAP וה-backend חשודים. אימות מוצלח שאחריו כשל child-SA אינו אחד משניהם.

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

תפעול שני המודלים

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

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

לאחר שהזהות מתקבלת

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

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