Скільки незалежних залежностей у вашому ланцюгу приватності?

Порахуйте блоки на більшості схем приватності — отримаєте три або п'ять стрибків, кожен із логотипом іншої компанії. Порахуйте організації, які справді можуть діяти щодо цих блоків — і число часто зводиться до двох. Ланцюг розділяє довіру лише настільки, наскільки незалежні його залежності, а кількість стрибків цього не вимірює. Саме цей розрив і є всім питанням, яке варто поставити.

Допомагають дві карти. Одна відстежує, куди йдуть пакети; друга фіксує, хто експлуатує, оплачує, адмініструє кожен елемент і кого можна змусити діяти. Друга карта не ефектна, зазвичай неповна і значно частіше здатна змінити рішення.

Намалюйте шлях трафіку, потім шлях контролю

Орендований проксі перед двома тунельними сервісами виглядає як три сторони. Запишіть хостинг-провайдера, обліковий запис панелі керування, білінгову ідентичність і адресу, за якою буде вручено юридичну вимогу, і ці троє можуть звестися до одного хмарного орендаря з однією поштовою скринькою для відновлення. У шляху трафіку нічого не змінилося; змінився опис незалежності.

Позначайте кожен рядок як відомий, виведений або невідомий і записуйте, на чому тримається позначка. Назва бренду встановлює, хто продав вам послугу. Вона не встановлює, кому належить машина, і тим більше не встановлює, чи записи клієнтів лежать у тій самій базі даних, що й записи іншого сервісу.

Дисципліна важливіша за таблицю. Щойно «невідомо» стає припустимим значенням, схема перестає собі лестити й починає показувати, який відсутній факт перевернув би висновок.

Чого не може побачити кількість стрибків

Стрибки описують інкапсуляцію та пересилання. Вони нічого не кажуть про спільне адміністрування, спільний вищий транзит, спільні платіжні інструменти чи спільні канали відновлення, і саме ці чотири місця є там, де два номінально різні сервіси тихо стають одним.

Візьміть схему, перший і останній стрибок якої належать різним компаніям, але обидва стоять за одним транзитним провайдером. З позиції цього провайдера значна частина метаданих про обидва кінці проходить через одну й ту саму інфраструктуру. Це не доказ ідентифікації; це залежність, яку зведення кількості стрибків цілком пропускає.

Зворотна помилка так само поширена. Припущення, що окрема власність гарантує розділення, ігнорує те, що оператори зазнають зламу, примусу або просто недбалості однаковими способами. Незалежність встановлюється пункт за пунктом, її не дарує логотип.

Автономна система — це межа маршрутизації

Номер AS ідентифікує домен, який подає своїм пірам узгоджений погляд на маршрутизацію. Це твердження про політику маршрутизації, а не про корпоративну власність, персонал, юрисдикцію чи розділення облікових даних. Два сервіси за різними номерами AS можуть мати одного власника, а один сервіс, розподілений по кількох номерах AS, усе ще один оператор.

Читання номерів AS із looking glass — розумний перший крок для рядка транзиту на вашій карті. Це не вимірювання шляху, яким ваш трафік ішов певного вечора, і не повинно так описуватися. Де шлях невідомий, пишіть «невідомо».

Чотири рядки, які треба заповнити для кожного стрибка

Пройдіть кожну кінцеву точку тими самими чотирма питаннями в тому самому порядку, щоб прогалини залишалися видимими, а не згладжувалися впевненим підсумковим реченням.

• Хто може читати вміст? Назвіть сторону, яка завершує рівень захисту, і який відкритий текст або ключі вона має.
• Хто може керувати машиною? Відрізняйте власника інфраструктури від того, хто має доступ до консолі, і перевірте, чи не поділений цей доступ з іншим сервісом у ланцюгу.
• Чиї записи можуть пов'язати її з чимось іншим? Білінгова ідентичність, адреса відновлення, обліковий запис підтримки та платіжний інструмент — звичайні мости.
• Хто відповідає на запит даних? Визначте юридичну особу та юрисдикцію, в якій вона перебуває, потім запитайте, які дані ця особа взагалі зберігає.

Потім запишіть, звідки взявся кожен відповідь: документація постачальника, опублікована політика, пряме спостереження або висновок, який ви зробили, бо альтернатива була незручною. Рядок, підкріплений конкретною заявою про зберігання, — сильніший доказ, ніж рядок, підкріплений тим, що сайт виглядав професійно.

Коли спільна залежність справді важлива

Питання приватності ніколи не в тому, чи існує спільна залежність, а в тому, що ця залежність могла б поєднати. Спільний адміністративний доступ — інша експозиція, ніж пасивна видимість зашифрованого трафіку, а зв'язок облікових записів відрізняється від обох. Назвіть спостереження, привілей і збережений запис, перш ніж щось висновувати.

Обговорення спостерігачів і кореляції в RFC 6973 дає робочу структуру: перелічіть, що дізнається кожен суб'єкт, потім запитайте, що дало б поєднання цих знань. Спостереження двома сторонами схожих метаданих — привід дослідити кореляцію. Це не виміряна ймовірність ідентифікації, і подавати це так не можна.

Коли це опрацювати, приклад із трьома сторонами розпадається на окремі знахідки. Спільний хостинг без спільного доступу до консолі — концентрація в ланцюгу постачання. Спільна поштова скринька відновлення — адміністративний міст. Обидва реальні; лише другий дозволяє одному компрометування перетнути дві межі.

Те, чим ви завершуєте, — не сертифікат анонімності. Це захисне твердження про те, де незалежність було перевірено, де припущено і який єдиний факт змінив би вашу думку. Це краще за ще одну стрілку на схемі.