Инженерия Webship

Безопасное подключение ИИ-агентов к серверу MCP Webship

Настройте изолированную управляющую плоскость MCP Webship с TLS 1.3, сильным токеном носителя, привязкой к loopback, SSH-туннелем, проверкой конфигурации и практическим списком действий при инцидентах.

Опубликовано 10 сентября 2026 г.

# Безопасное подключение ИИ-агентов к серверу MCP Webship

Подключение MCP к веб-серверу — это не виджет чата. Это операционный интерфейс, который может проверять состояние производства, изменять маршрутизацию и политику безопасности, перезагружать сертификаты, активировать статические релизы, координировать изменения в парке серверов и устанавливать подписанное обновление Webship.

Обращайтесь с ним соответственно: как с привилегированным административным API. Наиболее безопасная настройка Webship держит слушатель MCP вне публичной плоскости данных, привязывает его к loopback, защищает с помощью TLS 1.3 и сильного токена носителя, и обращается к нему через аутентифицированный SSH-туннель.

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

Начните с границы доверия

Общественный трафик Webship и трафик MCP используют отдельные слушатели. Плоскость управления MCP по умолчанию отключена и никогда не использует обычный слушатель HTTP, HTTP/2, HTTP/3 или WebTransport. Когда она включена, она обслуживает MCP через выделенный TLS 1.3 HTTP/1.1 endpoint.

Безопасное развертывание имеет четыре независимых элемента управления:

Доступность сети: слушатель MCP подключается к 127.0.0.1, а не к общедоступному или приватному LAN-адресу.
Идентификатор транспорта: клиент проверяет сертификат, выданный удостоверяющим центром (CA), которому он доверяет.
Аутентификация приложения: каждый запрос несет один сильный токен носителя.
Административный доступ: операторы получают доступ к прослушивателю loopback через аутентифицированную SSH-учетную запись и туннель.

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

Подготовьте сертификат и токен

Выпустите специализированный сертификат MCP от вашего внутреннего центра сертификации (CA). Для показанного ниже туннеля включите localhost и 127.0.0.1 в альтернативные имена субъекта сертификата, затем установите центр сертификации, который выдал сертификат, в хранилище доверенных корневых центров машины-клиента MCP. Не исправляйте ошибку доверия с помощью небезопасной опции TLS.

Создайте уникальный токен длиной не менее 32 печатных ASCII-байт без пробелов. 32-байтное случайное значение, закодированное в шестнадцатеричном формате, даст вам 64 безопасных символа:

umask 077
openssl rand -hex 32

Webship в настоящее время считывает токен MCP напрямую из защищенной конфигурации TOML; token_file не поддерживается. Сохраните результат в конфигурационном файле, доступном только учетной записи службы Webship и ее административной группе. Не помещайте токен в юнит systemd, историю оболочки, тикет, сообщение в чате или подсказку, отправляемую модели ИИ.

На типичной системе Debian:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

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

Включить изолированный слушатель

Добавьте этот раздел в активную конфигурацию Webship:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

Пустой список allowed_ips не открывает конечную точку. Клиенты loopback остаются разрешенными по умолчанию. expose_remote = false делает предполагаемую границу явной: если кто-то позже изменит listen на адрес, отличный от loopback, Webship отклонит конфигурацию вместо того, чтобы тихо публиковать контрольную плоскость.

Webship также отвергает включенный MCP-лисенер без TLS, без токена, с коротким токеном или токеном, содержащим пробелы, а также с пустыми путями к сертификатам. Публичные заглушки-токены отклоняются до их удаленного использования.

Проверьте перед перезапуском

Прослушиватель MCP, идентификатор TLS и изменения токена перестраивают управляющую плоскость, поэтому они требуют перезапуска процесса. Сначала проверьте полную конфигурацию:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

Подтвердите, что слушатель существует только на петлевом интерфейсе:

ss -ltn | grep '127.0.0.1:9443'

Не добавляйте порт 9443 в правила публичного файрвола хоста. На следующем шаге к нему будет доступ через SSH.

Создать частный туннель

С рабочей станции администратора перенаправьте локальный порт на прослушиватель loopback Webship:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

Клиент MCP теперь подключается к https://localhost:19443/mcp. TCP достигает SSH-сервера, SSH передает соединение на хост, и хост открывает окончательное соединение с Webship на loopback. Закрытие сессии SSH сразу же удаляет этот путь.

Используйте аутентификацию SSH на основе ключей, ограничьте, какие администраторы могут открывать туннель, и применяйте обычные средства контроля доступа к хосту. Если требуется промежуточный хост, держите слушателя MCP на интерфейсе loopback хоста Webship и расширяйте путь SSH, а не увеличивайте область прослушивания слушателя.

Настройте клиент MCP

Форматы конфигурации клиента различаются, но типичная запись HTTP MCP выглядит так:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

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

Держите проверку сертификатов включенной. Если клиент отклоняет сертификат, исправьте альтернативные имена субъекта сертификата или установите правильный внутренний CA. Не добавляйте постоянное обходное решение.

Сделайте первую сессию только для чтения

После подключения туннеля и клиента начните с обнаружения и проверки:

Запросите tools/list; его ответ является авторитетной схемой аргументов для текущего выпуска.
Вызовите webship.get_config и зафиксируйте текущую версию конфигурации.
Проверьте webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status и webship.tls.get_status по мере необходимости.
Используйте webship.policy.explain или webship.security.simulate перед изменением политики.
Подтвердите, что возвращаемая конфигурация скрывает токены носителя.

Только после этого тестируйте мутацию в непроизводственной среде. Мутации конфигурации Webship требуют текущего идентификатора версии. Старое изменение отклоняется вместо того, чтобы перезаписать более новое. Политику-кандидат можно проверить с помощью теневой верификации и сценариев traffic-lab перед активацией.

Webship также отвергает выбранные живые понижения безопасности. Запрос MCP не может отключить активный WAF, слой DDoS, API Shield, проверку ботов, политику edge-auth или слой заголовков ответа. Изменения, связанные с слушателем, протоколом, рабочим процессом, средой выполнения и аутентификацией MCP, требуют преднамеренной перезагрузки.

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

Если удаленное связывание неизбежно

Loopback плюс SSH является рекомендуемой схемой. Если ваша среда требует слушателя в частной сети, сделайте это исключение явным:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

Сохраните блок TLS из предыдущего примера, используйте сертификат, соответствующий приватному DNS-имени, и обеспечьте соблюдение того же диапазона источников на брандмауэрах хоста и сети. Никогда не используйте 0.0.0.0/0 или ::/0 в качестве удобного списка разрешений. Помните, что список разрешений приложения видит исходный адрес, который фактически достигает Webship; проверьте поведение, когда перед ним находятся балансировщик нагрузки, шлюз NAT или сервисная сетка.

Удалённый доступ увеличивает ценность централизованных журналов доступа, коротких операционных окон и быстрой ротации. Он не требуется только потому, что клиент MCP работает на другой машине; именно это решает SSH-туннель.

Управляйте управляющей плоскостью обдуманно

Используйте этот контрольный список для производства:

Оставьте MCP отключённым там, где он не нужен агенту или оператору.
Привязаться к петлевому интерфейсу и использовать SSH-туннель по умолчанию.
Используйте отдельный TLS-идентификатор и сохраняйте включённую проверку сертификата.
Создайте уникальный токен носителя для каждой среды Webship.
Защитите TOML, конфигурацию клиента, TLS-ключ и SSH-ключи с помощью разрешений файловой системы.
Отдельные учетные данные для разработки, тестирования и производства.
Начинайте сеансы с инструментов для проверки статуса и моделирования политик перед мутациями.
Сохраняйте и просматривайте события аудита безопасности Webship.
Поверните токен и перезапустите Webship после предполагаемого воздействия.
Закрывайте туннели по окончании административной сессии.

Для реагирования на инциденты закройте активные туннели, ограничьте доступ к SSH-аккаунту, замените MCP-токен в защищённом TOML, перезапустите Webship и просмотрите последние записи аудита безопасности и версии конфигурации. Если приватный ключ TLS может быть скомпрометирован, выдайте новый сертификат и ключ в рамках того же перезапуска. После этого протестируйте старый токен и убедитесь, что он отклонён.

Плоскость управления должна оставаться плоскостью управления

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

Держите границу простой: отдельный слушатель, проверяемая доступность через loopback, проверенный TLS, один защищённый идентификатор носителя, аутентифицированный туннель, изменения с проверкой версии и процесс проверки человеком для мощных операций. Webship предоставляет протокол и защитные механизмы; оператор решает, кто может к ним подключаться.

Это руководство основано на документации оператора Webship 1.3.1, примерах поставляемой конфигурации, проверке MCP и коде транспортировки, средствах защиты конфигурации во время выполнения и каталоге инструментов. Перед применением к другой версии ознакомьтесь с текущей документацией Webship и ответом работающего сервера tools/list.