FortiGate VPN MFA: אסימון מקומי, RADIUS או SAML?

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

טקס הכניסה קובע מי הבעלים של הגורם

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

ההבדל הזה קובע איזה ראיות אפשר לאסוף. כשהשער מאמת, פלט הניפוי שלו עצמו אומר לכם מה קרה. כשספק זהות מאמת, השער יודע רק שקביעה הגיעה, והתשובה לשאלה «האם MFA באמת נדרש» נמצאת ביומני הספק, לא ביומני חומת האש. קריאת היומן הלא נכון היא הדרך הנפוצה ביותר לאבחן באופן שגוי פריסה שמתנהגת בדיוק כמתוכנן. גם השירות עצמו מגביל את הטקס: FortiOS 7.6.3 מסיר את מצב המנהרה של SSL VPN לטובת IPsec, בעוד שמצב האינטרנט ממשיך כ-Agentless VPN בדגמים נתמכים, כך שטקס שהוכח בשירות אחד אינו זמין אוטומטית בשירות אחר.

אימות מקומי: אסימונים וקודים בדואר

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

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

גם דרישות הבטחה שייכות לכאן, לפני בחירת המוצר. NIST SP 800-63B רואה בדואר אלקטרוני אמצעי בלתי קביל לאימות מחוץ לערוץ, ולכן פריסה שמצהירה על תאימות אינה יכולה להשתמש בקוד בדואר כגורם השני, עד כמה שהוא נוח. קיומה של תכונה במכשיר אינו הצהרה שהתכונה עומדת בתקן נתון.

RADIUS: השער שואל, הקצה האחורי מחליט

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

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

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

diagnose debug application fnbamd -1
diagnose debug enable

SAML: הדפדפן עוזב את השער

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

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

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

שחזור הוא חלק מהמנגנון

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

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