Безопасность MCP: чему я научился после 95 сбоев в продакшене

Я думал, что безопасность — это просто. Обновляйте зависимости. Используйте HTTPS. Не хардкодьте секреты.

Я ошибался.

После 95 сбоев в продакшене и 1800 часов разработки я понял, что безопасность Model Context Protocol (MCP) устроена иначе. Она не похожа на стандартную безопасность REST API.

MCP создает новые риски, потому что клиентом является LLM, а не человек.

Вот что вам нужно знать, чтобы ваш MCP-сервер оставался в безопасности.

1. Модель угроз MCP

В REST вы точно знаете, кто вызывает ваш API. В MCP посредником выступает LLM. Это меняет всё:

  • LLM могут галлюцинировать при вызове инструментов или передаче параметров.
  • Пользователи не вызывают инструменты напрямую. Они общаются с LLM, а LLM общается с вашим сервером.
  • Вредоносные клиенты могут прощупывать ваш сервер на наличие скрытых инструментов в процессе обнаружения (discovery).

Ваша главная угроза — это не только хакер. Это может быть добросовестная LLM, совершающая случайную ошибку, которая обрушит вашу систему.

2. Управление API-ключами

Многие разработчики передают API-ключи в параметрах запроса (query parameters) для удобства. Это ошибка. Параметры запроса отображаются в каждом логе сервера и прокси-сервера.

Следуйте этим правилам:

  • Используйте аутентификацию через заголовки (Authorization: Bearer).
  • Избегайте передачи ключей в теле JSON.
  • Выпускайте отдельный API-ключ для каждого клиента. Это поможет вам отслеживать использование и отзывать доступ, не нарушая работу всей системы.

3. Строгая валидация входных данных

LLM будут ошибаться. Они будут присылать неверные типы данных и лишние параметры. Вы должны валидировать каждый вызов:

  • Сначала проверьте, существует ли имя инструмента в вашем списке.
  • Отклоняйте вызовы с лишними параметрами. Не просто игнорируйте их.
  • Строго сопоставляйте типы параметров. Не выполняйте автоматическое приведение типов.
  • Установите строгие лимиты на размер строк и массивов, чтобы предотвратить сбои из-за нехватки памяти.
  • Очищайте (sanitize) все пути к файлам, чтобы предотвратить обход директорий (directory traversal).

4. Многоуровневое ограничение частоты запросов

Один запрос пользователя может инициировать десять вызовов инструментов одновременно. Это может за секунды исчерпать ваш пул соединений.

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

  • Лимиты на каждый API-ключ для контроля использования клиентом.
  • Лимиты на каждый IP для предотвращения brute-force атак.
  • Лимиты на количество одновременных соединений, чтобы ваш сервер оставался работоспособным во время всплесков нагрузки.

5. Риски инъекций промптов (Prompt Injection)

Пользователь может обманом заставить LLM вызвать деструктивный инструмент. Если пользователь скажет LLM «удали все заметки», LLM может действительно это сделать.

Защитите себя:

  • Разделяйте операции чтения и записи.
  • Требуйте ручного подтверждения пользователем для любого действия по удалению или обновлению.
  • Используйте принцип наименьших привилегий для пользователя вашей базы данных.

Безопасность — это непрерывный процесс. Начните с улучшения управления ключами и строгой валидации. Эти шаги решают большинство проблем.

Источник: https://dev.to/kevinten10/mcp-security-what-i-learned-securing-my-mcp-server-after-95-production-outages-3hc0

Дополнительное сообщество для обучения: https://t.me/GyaanSetuAi