שירות MFA נפל: הכריעו על כניסה ל-VPN לפני הכשל

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

שלב 1: תנו שם לשלוש התוצאות בנפרד

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

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

שלב 2: קראו את מצב הכשל שהפרוקסי באמת משתמש בו

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

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

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

עצרו אם איש אינו יכול לומר איזה מצב פעיל. שאר המדריך תלוי בתשובה הזו.

שלב 3: התאימו את הניסיונות החוזרים לזרימה

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

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

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

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

שלב 4: נהלו גישת חירום בנפרד

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

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

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

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