מסירת גישה לבדיקת אבטחה: היקף, חשבונות וביטול
בודק שמבקש פרטי VPN זקוק למסירה עם היקף מוגדר, לא לכניסה חלופית. אשרו את ההרשאה, נקבו ביעדים, הנפיקו חשבונות ואז בטלו.
בודק מבקש כתובת שער, פרטי DNS פנימי ופרטי VPN, והבקשה מועברת אליכם עם הנושא «נדרשת גישה». הבקשה לבדה אינה אומרת לכם אם מדובר בהערכה פנימית, בבדיקת יישום מאומת או בעבודה על אתר ציבורי שבה מישהו הבין את ההיקף שלא כהלכה. הריצו את המסירה כרצף עם שער בכל שלב, ועצרו בשער הראשון שאינו נפתח. זה הופך בקשה מעורפלת למשהו שאתם יכולים לאשר, למסור ולבטל אחר כך.
התחילו בהרשאה, לא בפרטי הכניסה
לפני שכתובת כלשהי יוצאת מתיבת הדואר שלכם, קבעו מי הבעלים של היעדים ומי רשאי לאשר בדיקות עליהם. אמתו את הבודק דרך איש הקשר של ההתקשרות שארגונכם כבר משתמש בו, ולא דרך האדם שהעביר את הדוא״ל. יחסי לקוח אינם הרשאה לבדוק כל מערכת שנגישה מחשבון, והזמנת רכש אינה מסמך היקף.
כתבו את היעד המאושר במשפט אחד ושמרו אותו לצד המסירה. «העריכו את האימות של פורטל הלקוח» ו«העריכו את הרשת הפנימית» מובילים לחבילות שונות לגמרי, ואת ההבדל יש להכריע לפני ההקצאה ולא אחרי שממצא נוחת. המשפט גם נותן לכם משהו להצביע עליו כשהבקשה גדלה באמצע ההתקשרות.
אם ספק אחסון או צד שלישי אחר נמצא בדרך, הדרישות שלהם קודמות לנוחות שלכם. בדיקת תשתית של אחר ללא רשותו היא בעיה נפרדת מבדיקת היישום שרץ עליה.
נקבו בנקודת המבט וביעדים
נקודת המבט היא השאלה שההערכה מנסה לענות עליה, והיא קובעת את חבילת הגישה יותר מכל כלי שהבודק מתכנן להשתמש בו. בדיקה ציבורית לא מאומתת זקוקה לכתובת URL ולחלון זמן. בדיקה מאומתת זקוקה לחשבונות ייעודיים לתפקידים המסוימים שבהיקף, והערכה פנימית זקוקה לנקודת כניסה מוגדרת עם טווחי יעד מפורשים.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
המקום שבו מנהרה נכנסת אינו אותה עובדה כמו איזה יישום עומד מאחוריה, והוא בוודאי אינו מתיר לבדוק את נקודת הכניסה. אמרו זאת במפורש במסירה, כי המשפט «נתת לי גישה לאותה תת-רשת» מגיע מהר ברגע שממצא שנוי במחלוקת. רשימת יעדים כתובה היא הדבר היחיד שמכריע בכך בדיעבד.
מסרו את שם המארח של TLS לצד כתובת ה-URL. כתובת IP חשופה מכריחה את הבודק לנחש את השם, ושם מנוחש מייצר שגיאות תעודה שמדווחות כממצאים ולא כשגיאת מסירה.
הנפיקו זהויות ייעודיות עם תאריך תפוגה
הקצו חשבונות שקיימים רק עבור ההתקשרות הזו; אל תשאילו את הכניסה היומיומית של עובד. הגדירו נגישות רשת והרשאות יישום לפי המשימות המוסכמות, סדרו רישום אימות במסלול נתמך, ו- צרפו תאריך תפוגה עם אדם נקוב האחראי על הביטול. מסרו את פרטי הכניסה בערוץ מאובטח מוסכם, בנפרד ממסמך ההיקף שמועבר הלאה.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
תעדו מי קיבל מה, ומתי. התיעוד הזה הוא ההבדל בין מסירה מבוקרת לבין סיסמה משותפת שאיש אינו יכול לעקוב אחריה, והוא הדבר הראשון שכל אחד מבקש אחרי תקרית. שמרו אותו עם מסמך ההיקף ולא בשרשור צ'אט, וציינו את ערוץ המסירה לצד הנמען. שורה עם חותמת זמן מנצחת זיכרון בכל פעם.
שדה התפוגה הוא רשת ביטחון, לא התוכנית. מישהו עדיין צריך להסיר את נתיב הרשת ואת תפקיד היישום בסוף, כי כניסה שפגה ברשת שעדיין נגישה אינה גישה מבוטלת.
הוכיחו שהמסירה עובדת לפני שהחלון נפתח
בצעו בעצמכם את הקפיצה הראשונה של הבודק, מעמדה הקרובה ככל האפשר לשלו. פתרו את השם, בדקו את זהות התעודה, ואשרו שהנתיב מגיע לכתובת המיועדת ולא לכתובת שכנה.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
אם הנתיב אינו יכול להגיע ליעד, עצרו ויישרו את המסירה במקום לתת לבודק לגלות מסלול חלופי. נגישות מאולתרת היא הדרך שבה הערכה מתרחבת בשקט מעבר להיקפה, וכמעט שלעולם אינה מתועדת לאחר מכן.
שלחו את איש הקשר התפעולי, השעות המותרות, הפעולות המוחרגות ותנאי העצירה יחד עם פרטי הכניסה. בודק שאינו יכול להשיג איש בשעה 02:00 יקבל החלטה שלא אישרתם, וההחלטה הזו תתואר בדוח כאילו הייתה בהיקף.
NIST SP 800-115 ממסגר הערכה טכנית כבדיקות מתוכננות ואחריהן ניתוח וצמצום, וזו הצורה שהמסירה הזו עוקבת אחריה. השערים שלמעלה הם בחירות עריכה לעיצוב עבור מהנדס תמיכה, ולא רשימת בדיקה שצוטטה מאותו פרסום.
סיימו את ההתקשרות בהסרת הגישה
בטלו בסדר ההפוך להקצאה: תפקידי יישום, אחר כך גישת רשת, ואז הזהות עצמה. אשרו כל שלב במקום להניח שהקונסולה עשתה את מה שהכפתור הבטיח. נעלו את החשבון לפני שאתם הורגים את ההפעלות שלו, אחרת ההפעלה פשוט מאמתת את עצמה מחדש בנתיב הישן. אחר כך בדקו שוב את החיבורים הקיימים לפני שתכריזו על סגירה.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
סדרו כל נתוני בדיקה שנשמרו, ואז עקבו אחרי התיקון דרך תהליך הדיווח שסיכמתם בהתחלה. הדוח צריך לציין את הסביבה, את רמת הגישה, את ההיקף ואת המגבלות, כי הוא רושם ממצאים של הערכה אחת ואינו הצהרה קבועה שהאתר מאובטח.
שמרו את תיעוד הביטול עם תיעוד המסירה. כשההתקשרות הבאה נפתחת, תרצו לדעת בדיוק מה הוסר בפעם הקודמת ומי אישר זאת, ולא לשחזר את התמונה מהזיכרון.