Claude Platform Docs
MessagesТуннели MCP

Безопасность туннелей MCP

Рекомендации по усилению защиты, ротации учётных данных, реагированию на взлом и выводу из эксплуатации для развёртываний туннелей MCP.

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

Лучшие практики

  • Требуйте OAuth на каждом сервере MCP. Настройте каждый вышестоящий сервер MCP так, чтобы он требовал OAuth, как описано в спецификации авторизации MCP. OAuth обеспечивает эшелонированную защиту поверх транспортной аутентификации туннеля и позволяет выполнять авторизацию на уровне пользователя на уровне данных.
  • Включите SSO для вашей организации. Туннели, правила федерации и сервисные аккаунты управляются в Claude Console. SSO применяет средства управления сеансами вашего поставщика удостоверений к администраторам, которые могут их изменять.
  • Ограничьте upstream.allowed_ips. Используйте наименьшие диапазоны CIDR, покрывающие ваши серверы MCP. Это основная защита прокси от SSRF.
  • Отслеживайте журналы. Настройте оповещения о предупреждениях, ошибках и необычных шаблонах трафика от стека туннеля.
  • Выполняйте ротацию учётных данных. Регулярно меняйте сертификат сервера и токен туннеля по расписанию, а также немедленно при подозрении на компрометацию.
  • Поддерживайте образы в актуальном состоянии. Отслеживайте новые выпуски прокси и закрепляйте образы по дайджесту SHA-256.
  • Ограничьте сетевую доступность. Прокси и cloudflared должны иметь доступ только к адресатам, перечисленным в сетевых требованиях. Используйте NetworkPolicy (Kubernetes) или правила межсетевого экрана хоста (Compose).
  • Ограничьте область действия серверов MCP. Каждый сервер должен предоставлять только те инструменты и данные, которые необходимы для его назначения.
  • Защищайте учётные данные при хранении. Применяйте принятые в вашей организации практики управления секретами к закрытым ключам и токенам туннеля.

Реагирование на предполагаемый взлом

Если вы считаете, что ваш токен туннеля, ключи TLS или хост прокси были скомпрометированы:

  1. Остановите стек туннеля

    helm uninstall mcp-tunnel -n mcp-tunnel

  2. Отключите вышестоящие серверы MCP

    Удалите вышестоящие серверы MCP из всех сеансов Managed Agent, которые их используют, и прекратите передавать их URL-адреса в блоке mcp_servers запросов Messages API.

  3. Архивируйте туннель

    Архивирование делает токен туннеля недействительным и отсоединяет домен. В Console архивируйте туннель из списка MCP tunnels. Чтобы вместо этого выполнить архивирование через API, см. раздел Архивирование туннеля.

  4. Свяжитесь с Anthropic

    Сообщите о предполагаемой компрометации в службу поддержки Anthropic.

  5. Выполните ротацию нижестоящих учётных данных

    Заново подготовьте новый туннель и выполните ротацию всех токенов OAuth, выданных затронутыми серверами MCP.

  6. Проверьте журналы перед восстановлением работы

    Изучите журналы прокси, cloudflared и серверов MCP за период предполагаемой компрометации, прежде чем вводить новый туннель в эксплуатацию.

Вывод туннеля из эксплуатации

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

  1. Остановите стек туннеля

    helm uninstall mcp-tunnel -n mcp-tunnel

  2. Архивируйте туннель

    В Console архивируйте туннель из списка MCP tunnels.

  3. Удалите сохранённые учётные данные

    При программном доступе компонент настройки создал один Secret, названный по имени релиза. Без программного доступа вы сами создали mcp-tunnel-token и mcp-tunnel-cert. Удалите те из них, которые применимы:

    kubectl -n mcp-tunnel delete secret \
  mcp-tunnel mcp-tunnel-token mcp-tunnel-cert \
  --ignore-not-found

Was this page helpful?