Боты без границ: Новая эра цифровой идентификации в сети

По мере того как боты и агенты начинают криптографически подписывать свои запросы, у операторов веб-сайтов возникает растущая потребность узнавать открытые ключи при настройке своих сервисов. Я могу найти материалы открытых ключей для известных сборщиков и краулеров, но что насчёт следующих 1000 или 1 000 000? И как мне найти их материалы открытых ключей, чтобы проверить, что они являются теми, за кого себя выдают? Эта проблема называется обнаружением.

Мы разделяем эту проблему с Amazon Bedrock AgentCore, комплексной платформой для создания, развертывания и эксплуатации высокопроизводительных агентов в масштабе, и их AgentCore Browser, быстрым, безопасным облачным браузерным окружением для взаимодействия ИИ-агентов с веб-сайтами в масштабе. Команда AgentCore хочет упростить для каждого из своих клиентов возможность подписывать собственные запросы, чтобы Cloudflare и другие операторы CDN-инфраструктуры видели подписи агентов от отдельных агентов, а не от AgentCore как монолита. (Примечание: этот метод не идентифицирует отдельных пользователей.) Для этого Cloudflare потребовался способ массового приёма и регистрации открытых ключей клиентов AgentCore.

В этом посте блога мы предлагаем реестр ботов и агентов как способ легко обнаруживать их в Интернете. Мы также описываем, как Web Bot Auth может быть расширен с помощью формата реестра. Подобно спискам IP-адресов, которые могут быть созданы кем угодно и легко импортированы, формат реестра представляет собой список URL-адресов для получения ключей агентов и может быть легко создан и импортирован.

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

Потребность в более надёжной аутентификации

В мае мы представили предложение протокола под названием Web Bot Auth, которое описывает, как разработчики ботов и агентов могут криптографически подписывать запросы, исходящие из их инфраструктуры.

На сегодняшний день существует несколько реализаций предложенного протокола, от Vercel до Shopify и Visa. Он активно обсуждался, и в него были внесены contributions. Web Bot Auth знаменует собой первый шаг к переходу от ненадёжной идентификации, такой как IP-адреса и пользовательские агенты, к более доверенной криптографической аутентификации. Однако, как и IP-адреса, криптографические ключи являются псевдонимной формой идентичности. Если вы управляете веб-сайтом без масштаба и охвата крупных CDN, как вы обнаруживаете открытый ключ известных краулеров?

Первое предложение протокола предлагало один подход: операторы ботов будут предоставлять новый HTTP-заголовок Signature-Agent, который ссылается на HTTP-эндпоинт, размещающий их ключи. Подобно IP-адресам, по умолчанию разрешено всё, но если конкретный оператор делает слишком много запросов, вы можете начать принимать меры: увеличить его лимит запросов, связаться с оператором и т.д.

Вот пример из онлайн-магазина Shopify:

Signature-Agent: "https://shopify.com"

Формат реестра

Учитывая всё вышесказанное, мы приходим к следующей проблеме. Как Cloudflare может обеспечить клиентам контроль над трафиком, который они хотят разрешить, с разумными настройками по умолчанию, одновременно способствуя развитию открытой экосистемы курирования, которая не привязывает клиентов или небольшие источники?

Такая экосистема существует для списков IP-адресов (например, avestel-bots-ip-lists) и robots.txt (например, ai-robots-txt). Для обоих типов вы можете найти канонические списки в Интернете, чтобы легко настроить свой веб-сайт для разрешения или запрета трафика с этих IP-адресов. Они предоставляют прямую конфигурацию для вашего nginx или haproxy, и вы можете использовать её для настройки своей учётной записи Cloudflare. Например, я мог бы импортировать следующий robots.txt:

User-agent: MyBadBot
Disallow: /

Именно здесь появляется формат реестра, предоставляющий список URL-адресов, указывающих на ключи Signature Agent:

# AI Crawler
https://chatgpt.com/.well-known/http-message-signatures-directory
https://autorag.ai.cloudflare.com/.well-known/http-message-signatures-directory
 
# Test signature agent card
https://http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directory

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

Любой может поддерживать и размещать эти списки. Подобно спискам IP или robots.txt, вы можете разместить такой реестр на любой публичной файловой системе. Это означает, что вы можете иметь репозиторий на GitHub, поместить файл в Cloudflare R2 или отправить его как вложение по электронной почте. Cloudflare намерен предоставить один из первых экземпляров этого реестра, чтобы другие могли вносить в него свой вклад или ссылаться на него при создании собственных.

Узнать больше о входящем запросе

Знание Signature-Agent — это хорошо, но недостаточно. Например, чтобы быть проверенным ботом, Cloudflare требует указать способ связи на случай, если запросы из этой инфраструктуры внезапно перестанут работать или изменят формат таким образом, что вызовут непредвиденные ошибки выше по потоку. На самом деле, исходному серверу может потребоваться много информации: имя оператора, способ связи, логотип, ожидаемая частота обхода и т.д.

Поэтому в дополнение к формату реестра мы предложили формат карточки сигнатурного агента, который расширяет каталог JWKS (RFC 7517) дополнительными метаданными. Подобно старой визитной карточке, она включает всю важную информацию, которую кто-то может захотеть узнать о вашем агенте или краулере.

Мы приводим пример ниже для иллюстрации. Обратите внимание, что поля могут измениться: введение jwks-uri, более описательный логотип и т.д.

{
  "client_name": "Example Bot",
  "client_uri": "https://example.com/bot/about.html",
  "logo_uri": "https://example.com/",
  "contacts": ["mailto:bot-support@example.com"],
  "expected-user-agent": "Mozilla/5.0 ExampleBot",
  "rfc9309-product-token": "ExampleBot",
  "rfc9309-compliance": ["User-Agent", "Allow", "Disallow", "Content-Usage"],
  "trigger": "fetcher",
  "purpose": "tdm",
  "targeted-content": "Cat pictures",
  "rate-control": "429",
  "rate-expectation": "avg=10rps;max=100rps",
  "known-urls": ["/", "/robots.txt", "*.png"],
  "keys": [{
    "kty": "OKP",
    "crv": "Ed25519",
    "kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
    "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs",
    "use": "sig",
    "nbf": 1712793600,
    "exp": 1715385600
  }]
}

Эксплуатация реестра

Amazon Bedrock AgentCore, платформа для создания и развертывания ИИ-агентов в масштабе, приняла Web Bot Auth для своего сервиса AgentCore Browser (подробнее в их посте). AgentCore Browser намерен перейти от ключа подписи сервиса, который в настоящее время доступен в их публичной предварительной версии, к клиентским ключам, как только протокол созреет. Cloudflare и другие операторы сервисов защиты исходных серверов смогут видеть и проверять подписи от отдельных клиентов AgentCore, а не от AgentCore в целом.

Cloudflare также предлагает реестр ботов и агентов, которым он доверяет, предоставляемый через Radar. Он использует формат реестра, чтобы позволить использовать ботов, доверенных Cloudflare, на вашем сервере.

Вы можете использовать эти реестры уже сегодня — мы предоставили демо на Go для сервера Caddy, которое позволило бы нам импортировать ключи из нескольких реестров. Оно находится на cloudflare/web-bot-auth. Конфигурация выглядит так:

:8080 {
    route {
        # Здесь используется middleware httpsig
        httpsig {
            registry "http://localhost:8787/test-registry.txt"
            # Вы можете указать несколько реестров. Все теги будут проверяться независимо
            registry "http://example.test/another-registry.txt"
        }

        # Срабатывает при валидной подписи
        handle {
            respond "Проверка подписи успешна!" 200
        }
    }
}

Существует несколько причин, по которым вам может потребоваться управление и ведение реестра с использованием формата Signature Agent Card:

  1. Мониторинг входящих Signature-Agent. Это позволяет собирать карты агентов подписи, которые обращаются к вашему домену.

  2. Импорт из существующих реестров и самостоятельная категоризация. Можно создать общий реестр на основе мониторинга, но реестры с большим количеством категорий могут быть полезнее.

  3. Установление прямых отношений с агентами. Cloudflare делает это для своего реестра ботов, или вы можете использовать публичный GitHub-репозиторий, где пользователи могут создавать issues.

  4. Изучение потребностей пользователей. Если вы предоставляете сервис безопасности, разрешение клиентам указывать реестры/агенты подписи, которые они хотят пропускать, дает ценную аналитику.

Дальнейшее развитие

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

С введением легковесного формата и спецификации для прикрепления метаданных к Signature-Agent и их систематизации в виде реестров мы начинаем удовлетворять эту потребность. Формат каталога HTTP Message Signature расширяется для включения самоподтвержденных метаданных, а реестр поддерживает экосистему кураторства.

В перспективе мы прогнозируем, что клиенты и источники будут выбирать доверенных signature-agent, использовать общий формат для миграции конфигурации между провайдерами CDN и полагаться на сторонние реестры для кураторства. Мы работаем над интеграцией этих возможностей в наши системы управления ботами и механизмы правил.