← Privacy Pass / privacy-pass / concepts

Модели развертывания

На этой странице рассказывается, как устроено развертывание Privacy Pass: кто отвечает за каждую из четырех ролей, подробные примеры моделей развертывания, какие модели развертывания подходят для разных потребностей клиентов, а также как Privacy Pass используется в составе других продуктов.

Хотя токены Privacy Pass обеспечивают криптографическую защиту за счет слепых подписей и больших наборов анонимности, для гарантий приватности роли также должны быть достаточно разделены между собой. Типичное развертывание Cloudflare устроено следующим образом:

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

• Attester: знает, кто такой Клиент, и любую идентифицирующую информацию, переданную на этапе аттестации, но не знает личность Origin.
• Издатель: знает только то, что Клиент прошёл аттестацию и ему причитается подписанный токен. (Это зависит от развёртывания: если Аттестатор и Издатель являются одной и той же организацией, Издатель может узнать информацию о личности, но личность Origin остаётся скрытой.)
• Origin: знает только то, что Клиент проверен.

Важно понимать, что невозможность связать выдачу токена с его погашением, которую обеспечивает Privacy Pass, лишь отчасти опирается на разделение ролей. Для реальной приватности множество анонимности (например, группа клиентов, использующих одну и ту же схему развертывания) также должно оставаться большим. Все, что заставляет клиентов видеть разные схемы, дробит их на более мелкие группы и снижает анонимность.

Дополнительные сведения см. в RFC Privacy Pass рекомендации ↗.

Главный структурный вопрос в том, пересекаются ли организации, управляющие Аттестатором, Издателем и Источником, или они полностью разделены. Полностью раздельная модель наиболее безопасна, но объединение определенных сущностей может быть выгодно в зависимости от сценария использования. Среди других возможных моделей: совместная модель Аттестатор-Издатель и совместная модель Издатель-Источник, которые не нарушают гарантии приватности, если дополнительные рекомендации ↗ соблюдаются.

Apple создала PAT ↗ практически полностью обойти проверки CAPTCHA для пользователей iOS 16 и новее в Safari, в участвующих приложениях и сторонних браузерах. В этом развёртывании Apple использует свою роль поставщика оборудования, чтобы подтверждать подлинность устройства по таким признакам, как действующий Apple ID и проверки целостности устройства, вместо CAPTCHA. Разделение ролей здесь выглядит так:

В этом развертывании используется полностью раздельная модель, при которой все роли выполняют не сговаривающиеся между собой стороны. Раздельная модель идеально подходит Apple, поскольку их работа как поставщика оборудования и инфраструктуры естественно вписывается в роль Аттестатора. Однако клиентам, выступающим в роли Origin, эта модель может быть менее удобна: либо приходится привлекать третью сторону на роль Аттестатора, либо роли нужно распределять между Cloudflare и самим клиентом, чтобы все три роли были задействованы.

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

В этом развертывании используется совместная модель Аттестатор-Издатель, в которых Cloudflare эксплуатирует и Издателя, и Аттестатора. Если клиент выступает в роли Origin, ему обычно не следует одновременно эксплуатировать и Аттестатора: это создало бы единую сущность Origin-Аттестатор, которой известны и личность пользователя, и адресат запроса, что значительно усложняет обеспечение приватности. Когда Cloudflare эксплуатирует Аттестатора совместно с Издателем, не нужно привлекать полностью новую третью сторону, хотя это и не обязательно. Совместная модель Аттестатор-Издатель полезна и в обратной ситуации, когда клиент сам является поставщиком идентификации (например, корпоративным IdP или SSO-провайдером) и хочет предложить приватную проверку для своих Origin.

Privacy Pass также используется в существующих продуктах Cloudflare. Самый известный пример: Privacy Proxy, используемого с одним хопом (Microsoft Edge Secure Network ↗) и с двумя хопами (Apple Private Relay ↗) развёртываниях, где Privacy Pass отвечает за первичную аутентификацию между клиентом и прокси (или первым прокси, если хопов два). Если ваш сценарий подходит под уже существующий продукт, это может быть самым простым путём. Архитектуру на уровне прокси см. в Модели развертывания Privacy Proxy.

• Протокол Privacy Pass
• Тестирование развертывания в продакшене: как выглядит развёртывание одной из этих моделей с Cloudflare.
• Замена CAPTCHA на Private Access Tokens (Apple WWDC22) ↗: обзор развёртывания Private Access Token от Apple.