בדיקת מצב המכשיר ב-VPN לא חוסמת? עקבו קודם אחר הדוח
סוכן נקודת הקצה מדווח על מצב תקין, אך האפליקציה הפנימית עדיין נפתחת. עברו על האספן, הפסיקה והחסימה, ואז הוכיחו את הדחייה בבקשה אחת.
אם מחשב נייד שחתימות האנטי-וירוס שלו הפסיקו להתעדכן לפני שבועות עדיין יכול לפתוח את האפליקציה הפנימית שלכם, רק לעתים רחוקות מסמך המדיניות הוא הדבר הלא נכון. שלוש מערכות נפרדות חייבות להסכים לפני שהגישה נדחית: משהו מודד את נקודת הקצה, משהו ממיר את המדידה לפסיקת אישור או דחייה, ומשהו באמת מפיל את התעבורה. כשמכשיר לא תואם בכל זאת נכנס, בדיוק אחת מהחוליות האלה חסרה או סומכת על ראיות שאסור לה. הבדיקות שלמטה פועלות לפי הסדר הזה, ולכל אחת יש נקודת עצירה.
החסימה היא השלב האחרון, לא הראשון
אימות ומצב המכשיר עונים על שאלות שונות. התחברות מוצלחת מוכיחה שהוצגו פרטי התחברות; היא לא אומרת דבר על התוכנה שרצה במחשב שהציג אותם. הפער הזה הוא הסיבה לכך שפרופיל לקוח מועתק יכול להעביר הפעלה שנראית תקינה אל מארח לא תקין.
לעבודה על תאימות נקודות קצה כבר יש אוצר מילים לשרשרת הזו. מודל הייחוס NEA ב-RFC 5209 מחלק את המשימה לאספן, שלב הערכה ונקודת אכיפה, ואומר במפורש שלקוח שמשקר לגבי מצבו שלו נמצא מחוץ למודל. ההסתייגות הזו חשובה יותר מהתרשים: מודול פלטפורמה מהימן לא הופך מדידה שמדווחת על ידי המכשיר לעובדה.
שמרו על האספן ישר לגבי ההיקף. עליו לדווח על המאפיינים שהמדיניות שלכם נוקבת בהם, במכשיר שמבקש גישה, ומעט אחר. סוכן מלאי שמפרט כל חבילה מותקנת הוא כלי אחר מאספן מצב, וההבדל הוא גם בעיית שימור וגם בעיית דיוק. אם אי אפשר לקשור את הדוח לזהות מכשיר אחת, המעריך מנחש איזה מחשב הוא בדיוק אישר.
לוח מחוונים שמציג מצב אדום אינו בקרה. שאלו למה עדיין יכול להגיע משתמש שנדחה: הוויקי, שיתוף הקבצים, פורט מסד הנתונים? התיקון צריך משטח צר אחד, וכל השאר נמצא מאחורי החסימה.
קראו את הדוח לפני שאתם קוראים את הכלל
התחילו במקור ולא בסימן הירוק של הלקוח. ב-Windows המדידה המקומית מגיעה מ-Defender או מכל מוצר שנרשם ב-Security Center, ושניהם קריאים בלי קונסולת ספק:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateהפקודה השנייה מחזירה מספר שלם בשם productState. הביטים שלו מתועדים באופן רופף וספקים אורזים אחרת את דגלי ההפעלה והעדכניות, לכן אמתו אותו במקום לפרש אותו. חבילות צד שלישי גם משאירות את הרשומה ב-Security Center לאחר הסרה, והיא מדווחת על תוכנה שכבר אינה בדיסק.
גיל הוא השדה שאנשים מדלגים עליו. חתימת זמן של חתימה אומרת משהו רק מול השעון של המחשב שמבצע את ההערכה, לכן המירו אותה למרווח במקום להעריך בעין:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursעכשיו למדיניות יש מספר אחד לקרוא. אם הכלל שלכם אומר 72 שעות, זה המספר שהוא משתמש בו, ומחשב נייד שישן שבוע נכשל בלי שמישהו יפרש תווית. רשמו את הסף לצד הפקודה, כי השניים נפרדים זה מזה כשמחליפים את כלי נקודת הקצה.
המירו כל מצב מכשיר לפסיקה כתובה
רוב המחלוקות על המצב הן למעשה מחלוקות על השורה הלא ידועה. החליטו עליה לפני התקרית הראשונה, בטבלה שמציינת את הראיה, את הפסיקה ואת הבעלים, כדי שאיש לא יאלתר בקונסולת השער.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
השורה התחתונה היא המקום שבו המוצרים נבדלים. יש שערים שדוחים את החיבור ומסבירים למה; אחרים נותנים למנהרה לעלות ומחילים מדיניות מוגבלת; מעטים נופלים חזרה לדוח הטוב הידוע האחרון. רק השניים הראשונים ניתנים להגנה, וכדאי לבדוק איזה מהם עושה שלכם.
שמרו גם על זהות והרשאה במסלולים נפרדים. מחשב נייד שעובר כל בדיקת מצב עדיין זקוק להרשאה אנושית נכונה לאפליקציה, ותעודת מכשיר מוכיחה החזקה במפתח ולא את מצב מערכת הקבצים. דחיסת השלושה לבוליאני אחד היא הדרך שבה חשבון מוקד תמיכה מקבל גישה קבועה לייצור.
בדקו את נתיב האכיפה בבקשה, לא בלוח מחוונים
אכיפה היא תכונה של בקשה, לכן מדדו אותה בבקשה אחת. הציבו מכונה לא תואמת במנהרה ועשו את הקריאה שמשתמש אמיתי היה עושה:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthתשובה 200 ממכשיר שאמור להיות חסום פירושה שההחלטה לא הגיעה לנתיב הנתונים מעולם. שני גורמים נפוצים: המדיניות מחוברת לקבוצה שחשבון הבדיקה לא הצטרף אליה, או שהאפליקציה נגישה בנתיב שה-VPN אינו מחזיק בו.
בדקו קודם את הנחת הניתוב. אם השם הפנימי נפתר לכתובת שהלקוח כבר מגיע אליה דרך ה-LAN המקומי, המנהרה לא רלוונטית ושום מדיניות לא תוחל. השוו את הכתובת הזו לנתיב שהשער דוחף. במערכת OpenVPN, המדיניות לכל לקוח חיה בקבצים שממופתחים לפי השם המשותף, ולכן קל לבדוק:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17קובץ שמכיל disable מנתק את הלקוח הזה לחלוטין, ואילו שורה push "route ..." מצמצמת למה הוא יכול להגיע. שניהם אכיפה, ושניהם גלויים לכל מי שמנפה את הדוח.
בדקו את ארבעת המקרים בחשבון בדיקה אחד
הבדיקה האחרונה היא מטריצה קטנה, לא מסלול מאושר. העבירו חשבון בדיקה אחד בארבעה מצבים: עדכני, חתימה שפגה, הגנה מושבתת, סוכן לא מותקן. בכל אחד רשמו את הפסיקה ביומן ההערכה, את סטטוס ה-HTTP שהאפליקציה מחזירה, והאם נטען דף התיקון.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}שני פרטים קלים לפספוס. ראשית שידור חוזר: דוח שנלכד כשהמכונה הייתה תקינה לא יאושר להפעלה מאוחרת יותר באותו מכשיר, לכן חפשו חתימת זמן שקושרה לחיבור הנוכחי. אחר כך הסרה: הסרת הסוכן אמורה לייצר את אותה דחייה כמו דוח מיושן, לא מעבר נקי, וזה המקרה שלרוב אף פעם לא נבדק.
כשהמטריצה תואמת לטבלה, מסרו שלושה דברים למי שיתפעל את השער בהמשך: הפקודות, הסף וארבע התוצאות הצפויות. המסירה הזו היא התוצר האמיתי, כי עיצוב מצב שחי רק במסמך מדיניות סוטה בפעם הראשונה שכלי נקודת הקצה משנה את שדה הדיווח שלו.