כמה תלויות עצמאיות יש לשרשרת הפרטיות שלכם?

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

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

שרטטו את נתיב התעבורה, ואז את נתיב השליטה

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

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

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

מה ספירת קפיצות לא יכולה לראות

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

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

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

מערכת אוטונומית היא גבול ניתוב

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

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

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

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

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

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

מתי תלות משותפת באמת חשובה

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

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

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

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