בדיקות קבלה לשער VPN וירטואלי עם אימות דו-שלבי

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

מה הספק חייב לאשר על הפריסה הזאת

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

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

הוכיחו שהגורם השני הוא גורם שני

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

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

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

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

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

התאמנו על העותק, לא על השער החי

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

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

מדדו את עומס העבודה שהצוות שלכם יריץ

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

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