שתי בדיקות התחברות אינן שני גורמים: VPN ו-RADIUS
בדיקת חשבון מקומית יחד עם RADIUS הן שתי אימותות, לא שני סוגי גורמים. השוו מדיניות AND, OR וגיבוי, ואז בדקו את השילוב.
הוספת backend אימות שני לשער VPN מרגישה כמו הוספת גורם שני. בדרך כלל היא מוסיפה בדיקה שנייה, שהיא אובייקט שונה עם מצבי כשל שונים. האם שניהם חייבים להצליח, מה כל אחד מוכיח ומה קורה כשאחד אינו זמין הם שלושה החלטות נפרדות. אם תטעו, השער יוצא מחמיר יותר בהדגמה וחלש יותר בזמן תקלה.
מה backend שני באמת מוכיח
חיפוש בחשבון מקומי מוכיח ששם קיים במסד נתונים ושסיסמה התאימה לו. החלפת RADIUS מוכיחה ששרת RADIUS החזיר Access-Accept עבור התכונות שקיבל. אף אחת מהקביעות אינה מזכירה סוג גורם, כי שניהם מאמתים ידע. כמו כן, מדריך הזהות הדיגיטלית של NIST סופר סוגי גורמים נפרדים ואת המאמתים שלהם, לא שרתים או הנחיות.
קיים עיצוב לגיטימי שבו שני המערכות משתתפות. שירות מרכזי יכול לאמת את האדם בעוד השער בודק באופן עצמאי אם לחשבון הזה יש זכות למנהרה הזו. זו הרשאה שלצד האימות, וקריאה לכך דו-גורמי מבלבלת בין בדיקת מדיניות לבין הוכחת בעלות.
RADIUS יכול לשאת גורם שני אמיתי כשהוא עומד לפני משהו שמאמת אחד, כמו אישור דחיפה או אסימון חומרה. המעטפה אינה אומרת אילו מאמתים המשתמש הציג, אז קראו את מדיניות ה-backend ולא את התווית של השער.
AND, OR וגיבוי הם מוצרים שונים
לפני השוואת מימושים, החליטו מה פירוש שניהם בדרישה שלכם. מדיניות AND דורשת שכל בדיקה בשם תעבור, מדיניות OR מקבלת את זו שמצליחה, וגיבוי מנסה את השנייה רק בתנאי כשל מוצהרים. שלושתם מתנהגים הפוך בזמן תקלה, ובדרך כלל רק אחד מהם הוא מה שהסקירה התכוונה אליו.
הוספת שני רשומות backend למסך תצורה אינה מגלה איזו מדיניות המוצר מיישם. חלק מהשערים משרשרים תוספים לפי סדר ועוצרים בדחייה הראשונה, וזה AND רק כשכל תוסף נדרש. אחרים מתייחסים לחשבון מקומי כעקיפה, מה שהופך תקלה מרכזית לעקיפת אבטחה. התשובה האמינה היא בדיקה שלילית מתועדת לכל נתיב, שתרוץ מול ה-build שאתם פורסים.
הגיבוי ראוי לחשד הרב ביותר, משום שהוא קיים כדי להמשיך לעבוד כשמשהו שבור. גיבוי שמקבל סיסמה מקומית בכל פעם ש-RADIUS אינו נגיש הפך מדיניות מרכזית לדלת שנייה וחלשה יותר.
הבדיקה הכפולה של OpenVPN היא מקרה מוחשי
OpenVPN קהילתי 2.6 דורש גם תעודת לקוח וגם את הסקריפט auth-user-pass-verify המוגדר כאשר שניהם מופעלים. זהו AND מתועד בין אימות תעודה לסקריפט אישורים, ואלה באמת שתי בדיקות. זה עדיין לא אוטומטית שני סוגי גורמים, מכיוון שהסקריפט עשוי לאמת רק סיסמה.
השילוב גם משאיר את שאלת השיוך פתוחה. תעודה מזהה בדרך כלל התקן בעוד האישורים מזהים אדם, ושום דבר בזרימה המוגדרת כברירת מחדל אינו דורש ששניהם יתייחסו לאותו גורם. החליטו אילו זוגות מותרים, ואז אכפו את המפה הזו בתוך סקריפט האימות או בשלב הרשאה מאוחר יותר.
מצב תעודה בלבד הוא בדיקה אחת, שנשענת על מפתח שאולי מוגן ב-PIN ואולי לא. PIN הופך את אותו אישור לידע ועוד בעלות רק אם לא ניתן להשתמש במפתח בלעדיו. השארת המפתח לא מוצפן בדיסק מקטינה את החלק השני להרשאת קובץ.
יצרני מכשירים בונים את האינסטלציה שלהם, לעתים מודול PAM או תוסף RADIUS מאחורי קונסולת ווב. התנהגות הקהילה היא התייחסות לאיך נראות בדיקות כפולות, לא תיאור של איך מכשיר משלב אותן.
בדקו את השילוב בשער שלכם
קראו את התצורה לפני שאתם סומכים על סיכום הקונסולה. השורות שמכריעות במדיניות הן מצב התעודה, סקריפט האישורים וסדר התוספים.
grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123
grep מראה אם נדרשת תעודה ואיזה סקריפט רץ אחריה, והסדר חשוב יותר ממה שהשמות מרמזים. הפלט של התעודה נותן את הזהות שהשער יראה, כולל ה-CN ומספר הסידורי הדרושים למפת השיוך. בדיקת RADIUS היא המקרה השלילי: סיסמה שגויה חייבת להפיק Access-Reject, ונכונה Access-Accept. אם אישור שנדחה עדיין מפיק הפעלה, הסקריפט כלל אינו בנתיב האימות.
אחר כך הריצו את מקרה התקלה במופע מעבדה: עצרו את ה-backend הנדרש והתחברו עם אישורים תקפים. התוצאה הצפויה היא סירוב, וכל דבר אחר הוא מדיניות הגיבוי שאיש לא תיעד.
כתבו את הדרישה כמקרים שליליים
דרישה שמישה היא נוקבת בהוכחות, בחשבונות שמורשים להציג אותן ובתוצאה כאשר מאמת חסר. היא גם מציינת את השיוך המותר בין זהות התקן לזהות האדם. זה מדויק יותר משמות המוצר בהזמנה, ואפשר לבדוק אותו.
הקבלה צריכה לכלול ארבעה סירובים: חשבון מקומי לא כשיר, הוכחה נדרשת חסרה, גורם שני לא תקף ו-backend נדרש שאינו נגיש. כל סירוב צריך שורת יומן שמבדילה אותו מהאחרים, אחרת התקרית הבאה נפתחת בניחושים. תעדו איזה רכיב קיבל כל החלטה, מכיוון שהשער, שרת RADIUS והספרייה יאשימו זה את זה.
הריצו שוב את ארבעת הסירובים אחרי כל שינוי תוסף או קושחה. הם זולים, והמדיניות שהם מגנים עליה היא החלק שתוקף בודק ראשון.