Сколько независимых зависимостей в вашей цепочке приватности?

Посчитайте блоки на большинстве схем приватности — получите три или пять переходов, каждый с логотипом другой компании. Посчитайте организации, которые действительно могут действовать в отношении этих блоков — и число часто сводится к двум. Цепочка разделяет доверие лишь настолько, насколько независимы её зависимости, а число переходов не измеряет ничего из этого. Именно этот разрыв и есть весь вопрос, который стоит задать.

Помогают две карты. Одна отслеживает, куда идут пакеты; другая фиксирует, кто эксплуатирует, оплачивает, администрирует каждый элемент и кого можно принудить к действию. Вторая карта неэффектна, обычно неполна и гораздо чаще способна изменить решение.

Нарисуйте путь трафика, затем путь контроля

Арендованный прокси перед двумя туннельными сервисами выглядит как три стороны. Запишите хостинг-провайдера, учётную запись панели управления, биллинговую идентичность и адрес, по которому будет вручено юридическое требование, и эти трое могут свестись к одному облачному тенанту с одним почтовым ящиком для восстановления. В пути трафика ничего не изменилось; изменилось описание независимости.

Помечайте каждую строку как известную, выведенную или неизвестную и записывайте, на чём держится пометка. Название бренда устанавливает, кто продал вам услугу. Оно не устанавливает, кому принадлежит машина, и тем более не устанавливает, лежат ли записи клиентов в той же базе данных, что и записи другого сервиса.

Дисциплина важнее таблицы. Как только «неизвестно» становится допустимым значением, схема перестаёт себе льстить и начинает показывать, какой недостающий факт перевернул бы вывод.

Чего не может увидеть число переходов

Переходы описывают инкапсуляцию и пересылку. Они ничего не говорят об общем администрировании, общем вышестоящем транзите, общих платёжных инструментах или общих каналах восстановления, и именно эти четыре места — там, где два номинально разных сервиса тихо становятся одним.

Возьмите схему, первый и последний переход которой принадлежат разным компаниям, но обе стоят за одним транзитным провайдером. С позиции этого провайдера значительная часть метаданных об обоих концах идёт через одну и ту же инфраструктуру. Это не доказательство идентификации; это зависимость, которую сводка числа переходов полностью опускает.

Обратная ошибка столь же распространена. Допущение, что раздельная собственность гарантирует разделение, игнорирует то, что операторы подвергаются взлому, принуждению или просто небрежности одинаковыми способами. Независимость устанавливается пункт за пунктом, её не дарует логотип.

Автономная система — это граница маршрутизации

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

Чтение номеров AS с looking glass — разумный первый шаг для строки транзита на вашей карте. Это не измерение пути, которым ваш трафик шёл в конкретный вечер, и не должно так описываться. Где путь неизвестен, пишите «неизвестно».

Четыре строки, которые нужно заполнить для каждого перехода

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

• Кто может читать содержимое? Назовите сторону, которая завершает уровень защиты, и какой открытый текст или ключи у неё есть.
• Кто может управлять машиной? Отделите владельца инфраструктуры от того, у кого есть доступ к консоли, и проверьте, не разделён ли этот доступ с другим сервисом в цепочке.
• Чьи записи могут связать её с чем-то ещё? Биллинговая идентичность, адрес восстановления, учётная запись поддержки и платёжный инструмент — обычные мосты.
• Кто отвечает на запрос данных? Определите юридическое лицо и юрисдикцию, в которой оно находится, затем спросите, какие данные это лицо вообще хранит.

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

Когда общая зависимость действительно важна

Вопрос приватности никогда не в том, существует ли общая зависимость, а в том, что эта зависимость могла бы связать. Общий административный доступ — иная экспозиция, чем пассивная видимость шифрованного трафика, а связь учётных записей отличается от обоих. Назовите наблюдение, привилегию и сохраняемую запись, прежде чем что-либо заключать.

Обсуждение наблюдателей и корреляции в RFC 6973 даёт работоспособную структуру: перечислите, что узнаёт каждый субъект, затем спросите, что дало бы объединение этих знаний. Наблюдение двумя сторонами схожих метаданных — повод исследовать корреляцию. Это не измеренная вероятность идентификации, и представлять это так нельзя.

При проработке пример с тремя сторонами распадается на отдельные находки. Общий хостинг без общего доступа к консоли — концентрация в цепочке поставок. Общий почтовый ящик восстановления — административный мост. Оба реальны; только второй позволяет одной компрометации пересечь две границы.

То, с чем вы остаётесь, — не сертификат анонимности. Это защитимое утверждение о том, где независимость была проверена, где предположена и какой единственный факт изменил бы ваше мнение. Это лучше ещё одной стрелки на схеме.