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

ארבעה צדדים מאחורי רשומה אחת

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

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

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

בקשו את המסמך שמתאים לטענה

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

Field in a listingWhat it evidencesWhat it cannot evidence
Hostname or addressA reachable endpoint existed when the entry was publishedWho runs it, or what it stores
Protocols offeredWhich client configurations should interoperateWhether logging was disabled on that deployment
CountryWhere the endpoint claims to be locatedWhich legal process could reach the operator
Availability scoreHow often the entry answered a probeAnything about data handling

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

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

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

החליטו מה אתם קונים עם כל אפשרות

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

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

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

curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'

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

הפרידו בין השאלות בצד הלקוח

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

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

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

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

מאמרים קשורים