Безопасность MCP: 10 лучших практик настройки Model Context Protocol

Безопасность MCP (Model Context Protocol) почти никогда не попадает в фокус на старте проекта: разработчики подключают сервер в development-режиме через claude mcp add, видят, что tool-вызовы работают, и идут дальше. К моменту, когда AI-агенты выходят в production, дефолтная MCP конфигурация превращается в дыру — wildcard-tools, plaintext-credentials в .mcp.json, неограниченные scopes и процесс с полным доступом к $HOME. Эти MCP best practices собраны как инженерный чек-лист из десяти настроек hardening'а: каждую можно применить за один деплой и проверить одной командой. Это не каталог векторов атак (он есть вотдельной статье про утечку credentials), а конкретный список того, что включить, ограничить и залогировать.

Что вы узнаете

• Почему дефолтный MCP-сервер не годится для production и что именно закрывать.
• 10 практик hardening'а: scopes, allowlist, sandbox, eBPF, vault, аудит, policy, бюджет, provenance, таймауты.
• Готовый .mcp.json, systemd-unit и Rego-политика для копирования.
• Чек-маркер для каждой практики — команда проверки, что настройка реально включена.

Почему MCP требует hardening

Model Context Protocol стандартизирует, как LLM вызывает внешние инструменты: клиент (Cursor, Claude Code, Copilot) общается с MCP-сервером по stdio или HTTP/SSE, а сервер превращает запрос модели в реальное действие — SQL-запрос, файловую операцию, HTTP-вызов. Архитектура элегантная, но у неё есть три свойства, которые делают дефолт опасным.

Первое — сервер работает с привилегиями пользователя, который его запустил: студенческий MCP-сервер для чтения ./docs имеет тот же доступ к файловой системе, что и ваш SSH-ключ. Второе — инструмент активируется по текстовой инструкции модели, а значит prompt injection напрямую управляет surface area атаки. Третье— гранулярность доступа задаётся реализацией конкретного сервера, и в большинстве из неё нет: либо «всё разрешено», либо «никаких tools».

Это сочетание подтверждается OWASP Top 10 for LLM Applications (LLM06 — чрезмерное агентское действие) и подробно разбирается в гайде по production-деплою Claude Code. Десять MCP security-практик ниже систематически закрывают каждый зазор: от scopes на уровне протокола до eBPF-мониторинга на уровне ядра.

Практика 1: Минимизация scopes

Практика. Каждому MCP-серверу назначать минимальный набор scopes — ровно те ресурсы, которые нужны для его задачи, и ни одним больше.

Почему важно. Scope определяет, к чему tool-сервер может дотянуться: файлы, базы, API-эндпоинты, конкретные таблицы. Чем шире scope, тем больше blast radius при compromise или prompt injection. Сервер, которому нужен только read-only доступ к одной таблицеdocs, не должен видеть pg_shadow или /etc.

1# .mcp.json — scopes вместо wildcard
2{
3  "mcpServers": {
4    "knowledge-base": {
5      "command": "npx",
6      "args": ["-y", "@flowlink/mcp-pg"],
7      "env": {
8        "DATABASE_URL": "flowlink://ref/docs-db-readonly"
9      },
10      "scopes": [
11        "db:read:public.docs",
12        "db:read:public.snippets"
13      ],
14      "denyScopes": ["db:write:*", "fs:*", "shell:*"]
15    }
16  }
17}

Заметьте паттерн: явные denyScopes поверх позитивного списка. Это защита от будущего — если новая версия сервера запросит расширенные права, они не пройдут молча.

Чек-маркер: ☐ в .mcp.json нет строки "scopes": ["*"] ни у одного сервера.

Практика 2: Allowlist tools вместо wildcard

Практика. Разрешать на уровне хоста только именованные tools, а не весь каталог, который публикует сервер.

Почему важно. Один MCP-сервер может экспортировать десятки tools:read_file, write_file, exec, fetch_url. Дефолтное поведение большинства клиентов — регистрировать все. Allowlist превращает «что умеет сервер» в «что разрешено вызывать модели», и это две разные вещи.

1# Хост-конфиг (flowlink.config.yaml)
2tools:
3  allow:
4    - knowledge-base.search_docs
5    - knowledge-base.get_snippet
6  deny:
7    - "*.exec"
8    - "*.shell"
9    - "*.write_*"
10  requireApproval:
11    - "*.delete_*"
12    - "*.drop_*"

Здесь же — правило requireApproval: деструктивные tools блокируются до явного подтверждения человеком. Это продолжение темызащиты от деструктивных команд в Cursor, применённое уже к MCP-интерфейсу.

Чек-маркер: ☐ flowlink tools list показывает только те tools, что перечислены в allow.

Практика 3: Изоляция процесса через systemd sandbox

Практика. Запускать каждый MCP-сервер как изолированный systemd-unit с ограничениями на файловую систему, сеть и системные вызовы.

Почему важно. Scopes и allowlist ограничивают логический слой протокола. Но если в сервере RCE-уязвимость, атака уходит ниже — на уровень ОС. systemd даёт declaraтивный sandbox, который работает независимо от корректности приложения.

1# /etc/systemd/system/mcp-knowledge.service
2[Service]
3Type=simple
4ExecStart=/usr/bin/npx -y @flowlink/mcp-pg
5User=mcp-svc
6Group=mcp-svc
7​
8# Файловая система — только своё и только на чтение остальное
9ProtectSystem=strict
10ProtectHome=true
11PrivateTmp=true
12ReadWritePaths=/var/lib/mcp-knowledge
13​
14# Сеть — только нужный хост
15IPAddressAllow=10.0.1.20
16RestrictAddressFamilies=AF_INET AF_UNIX
17​
18# Системные вызовы — минимальный whitelist
19SystemCallFilter=@system-service
20SystemCallFilter=~@privileged @resources @mount
21NoNewPrivileges=true
22RestrictSUIDSGID=true
23CapabilityBoundingSet=
24​
25[Install]
26WantedBy=multi-user.target

Этот же приём рекомендует NIST SP 800-190 (контейнерная безопасность) для любого сервиса, обрабатывающего недоверенный ввод. Для MCP-сервера недоверенный ввод — это, по сути, весь трафик от модели.

Чек-маркер: ☐ systemd-analyze security mcp-knowledge.service показывает оценку ≤ 3.0 (из 10, где меньше — безопаснее).

Практика 4: eBPF shield для системных вызовов

Практика. Поверх systemd-seccomp поднять eBPF-политику, которая перехватывает системные вызовы и сетевые соединения на уровне ядра, в runtime.

Почему важно. systemd фильтрует по имени syscall, а eBPF — по контексту: кто, когда, к какому хосту, с каким payload-размером. Это позволяет, например, разрешитьconnect() к базе, но заблокировать исходящие на *.amazonaws.com или любые non-TLS соединения. seccomp статичен; eBPF — runtime-observability и enforcement в одном.

1# flowlink shield policy (YAML)
2shield:
3  enabled: true
4  target: mcp-knowledge.service
5  syscalls:
6    deny: [ptrace, keyctl, bpf, unshare]
7  network:
8    egress:
9      allow:
10        - cidr: 10.0.1.20/32
11          port: 5432
12      deny:
13        - cidr: 0.0.0.0/0
14          port: 443   # блокируем exfiltration через HTTPS
15  on_violation: block_and_alert

FlowLink eBPF Shield работает по модели allow-list egress: по умолчанию исходящий трафик запрещён, и вы явно открываете только нужные destination'ы. Это убивает целый класс атак, где скомпрометированный server exfiltrate'ит данные на внешний endpoint.

Чек-маркер: ☐ flowlink shield status mcp-knowledge показывает violations: 0 и egress policy: enforce.

Практика 5: Credential vault вместо plaintext-окружения

Практика. Никогда не класть секреты в env-блок .mcp.jsonнапрямую. Использовать ссылку на vault, которая резолвится только в момент вызова.

Почему важно. Файл .mcp.json попадает в git, в бэкапы, в логи деплоя и в контекст самой модели, если она читает конфиг. Plaintext-токен в env — самая частая причина инцидентов с MCP, и единственная, которую можно устранить за пять минут.

1# Плохо
2"env": { "DATABASE_URL": "postgres://admin:s3cr3t@db:5432/prod" }

1# Хорошо — ссылка на FlowLink Credential Vault
2"env": {
3  "DATABASE_URL": "flowlink://ref/docs-db-readonly"
4},
5"vault": {
6  "provider": "flowlink",
7  "ttlSeconds": 3600,
8  "leakProtection": true
9}

Vault резолвит flowlink://ref/... в реальный DSN только внутри процесса MCP-сервера, ротирует ключи по TTL и помечает их в gitleaks-сканере как known-good, чтобы случайно не поднять ложную тревогу. Подробнее о схеме работы vault — в статье пропять векторов утечки credentials в MCP.

Чек-маркер: ☐ grep -rEn "(password|secret|token|AKIA)" .mcp.json возвращает 0 строк.

Практика 6: Аудит-журнал всех tool-вызовов

Практика. Записывать каждый tool-call в append-only журнал: who, what, when, what-args (без секретов), какой результат, сколько времени.

Почему важно. Без журнала инцидент с MCP невозможно расследовать вообще. Вы не узнаете, какой tool вызвала модель, какие аргументы передала, какой файл она в итоге прочитала. Аудит-журнал — это и форензика, и база для алёртов (практика 8), и compliance по ISO 27001 A.12.4 / SOC 2 CC7.2.

1# flowlink audit config
2audit:
3  sink: postgres
4  table: mcp_tool_calls
5  fields:
6    - ts
7    - session_id
8    - principal          # SPIFFE SVID, не "user"
9    - tool
10    - args_hash          # sha256, без plaintext секретов
11    - args_redacted      # секреты замаскированы как ***REDACTED***
12    - result_status
13    - duration_ms
14    - policy_decision    # allow | deny | prompt
15  tamperProtection: forward-chaining-hmac

Запись идёт в mcp_tool_calls с HMAC forward-chaining — каждая строка подписана ключом предыдущей, поэтому удалить или изменить запись незаметно нельзя. Это та же техника, что в блокчейне, и она проходит аудит на tamper-evidence. Как агрегировать эти данные в дашборды и алёрты, описано в материале промониторинг активности AI-агентов на сервере.

Чек-маркер: ☐ SELECT count(*) FROM mcp_tool_calls WHERE ts > now()-interval '1 hour' > 0 после тестового вызова.

Практика 7: Policy engine на OPA/Rego

Практика. Выносить решения «разрешить/запретить» в декларативную policy на Rego, а не раскидывать if-проверки по коду сервера.

Почему важно. Policy в коде невозможно аудировать, версионировать и быстро менять. OPA (Open Policy Agent) с языком Rego — индустриальный стандарт (CNCF graduated), который отделяет enforcement от бизнес-логики. Вы пишете правило один раз и применяете его и к MCP, и к Kubernetes, и к API-gateway.

1# /etc/flowlink/policy/mcp.rego
2package flowlink.mcp
3​
4default allow := false
5​
6# Разрешить только read-доступ к docs в рабочее время
7allow if {
8  input.tool in {"knowledge-base.search_docs", "knowledge-base.get_snippet"}
9  input.action == "read"
10  time.weekday(input.ts) in workdays
11  time.parse_rfc3339(input.ts) >= time.add(now(), -duration("1h")).__val__
12  not sensitive_table(input.args)
13}
14​
15workdays := {"Monday", "Tuesday", "Wednesday", "Thursday", "Friday"}
16​
17sensitive_table(args) if {
18  re_match("(?i)\\b(users|billing|secrets|pg_shadow)\\b", args.query)
19}
20​
21# Деструктивные операции — только с явным approval
22deny[msg] if {
23  input.action == "write"
24  not input.approval
25  msg := sprintf("write requires approval: %v", [input.tool])
26}

Тот же Rego-файл ходит в unit-тесты (opa test mcp.rego mcp_test.rego), в CI и в runtime enforcement. Изменение политики проходит code-review, а не деплой новой версии MCP-сервера.

Чек-маркер: ☐ opa check /etc/flowlink/policy выходит без ошибок; flowlink policy test зелёный.

Практика 8: Бюджетный governor для tool-вызовов

Практика. Ставить rate-limit и стоимостный потолок на tool-вызовы, не только на LLM-токены.

Почему важно. Две группы атак на MCP экономят не токены, а ваши API-лимиты и кошелёк: (1) feedback-loop, где модель рекурсивно вызывает дорогой tool (внешний платный API, тяжёлый SQL), (2) resource exhaustion — SELECT * на таблице в 50 млн строк кладёт базу. Governor ставит hard-cap и на то, и на другое.

1# flowlink budget governor
2budget:
3  window: 1h
4  per_session:
5    max_tool_calls: 200
6    max_cost_usd: 5.00         # внешние API-вызосы
7  per_tool:
8    "knowledge-base.search_docs":
9      max_calls_per_minute: 30
10      max_result_rows: 1000
11  on_exceed:
12    action: throttle
13    alert: "#sec-ai-agents"

Это прямой родственник бюджетного governor'а для LLM-вызовов изсоответствующей статьи — та же механика (скользящее окно, hard/soft limit, throttling вместо молчаливого провала), но применённая к tool-layer.

Чек-маркер: ☐ в Prometheus метрика flowlink_tool_calls_total{status="throttled"} существует (значение может быть 0, метрика должна быть определена).

Практика 9: Подпись и пиннинг MCP-серверов (provenance)

Практика. Пиннинг конкретной версии MCP-сервера и проверка его подписи (SLSA-провенанс) перед запуском. Никаких @latest в production.

Почему важно. Экосистема MCP-серверов — это npm-пакеты и Docker-образы от десятков авторов. Supply-chain-атака (compromised upstream, typosquatting, malicious PR) — реальный вектор: достаточно один раз обновить @example/mcp-db и получить backdoor на всех, кто запускал npx. SLSA + cosign закрывают именно это.

1# Пиннинг по digest и проверка подписи
2{
3  "mcpServers": {
4    "knowledge-base": {
5      "command": "npx",
6      "args": [
7        "-y",
8        "@flowlink/mcp-pg@1.4.2",
9        "--integrity", "sha512-L0gq...8w=="
10      ],
11      "provenance": {
12        "verify": true,
13        "sigstore": true,
14        "expectedIssuer": "https://token.actions.githubusercontent.com",
15        "expectedSource": "github.com/flowlink/mcp-pg",
16        "expectedDigest": "sha256:a1b2c3..."
17      }
18    }
19  }
20}

При каждом запуске FlowLink проверяет Sigstore-подпись образа, сравнивает source-uri с ожидаемым и сверяет digest. Любое несовпадение — server не стартует, в audit-журнал летит событие provenance_mismatch. Это уровень защиты, рекомендованный SLSA Build Level 3.

Чек-маркер: ☐ flowlink verify --all показывает verified для каждого сервера; ни одного @latest в конфиге.

Практика 10: Таймауты и circuit breaker

Практика. На каждый tool навесить жёсткий таймаут и circuit breaker, который размыкается после N ошибок подряд.

Почему важно. Зависший tool — это не просто медленный ответ. В синхронной модели это заблокированный session, в асинхронной — накапливающиеся connection'ы и падение по OOM. Circuit breaker переводит каскадный сбой в graceful degradation: несколько таймаутов подряд → tool временно отключается → модель получает понятное сообщение вместо зависания.

1# flowlink resilience config
2resilience:
3  default:
4    timeout_ms: 5000
5    retry: { max_attempts: 2, backoff: exponential }
6  circuitBreaker:
7    enabled: true
8    failure_threshold: 5           # 5 ошибок подряд
9    failure_window: 60s
10    open_duration: 120s            # 2 минуты в открытом состоянии
11    half_open_probes: 1
12  per_tool:
13    "knowledge-base.search_docs":
14      timeout_ms: 3000
15      failure_threshold: 3
16    "external.weather_api":
17      timeout_ms: 2000
18      circuitBreaker:
19        open_duration: 600s        # внешний — дольше "отдыхает"

Таймаут и breaker решают и проблему безопасности: длинный зависший запрос — частый признак SSRF-попытки или эксплуатации time-based SQL injection. Быстрый fail = меньше окно атаки.

Чек-маркер: ☐ метрика flowlink_circuit_breaker_state{tool="..."} присутствует; тест с искусственным таймаутом переводит state в open.

Готовый .mcp.json

Ниже — собранный воедино .mcp.json, в котором применены все десять практик. Это отправная точка для production-деплоя: замените имена серверов и resource-refs на свои и прогоните чек-маркеры сверху вниз.

1{
2  "$schema": "https://flowlink.dev/schema/mcp.json",
3  "mcpServers": {
4    "knowledge-base": {
5      "command": "npx",
6      "args": ["-y", "@flowlink/mcp-pg@1.4.2",
7               "--integrity", "sha512-L0gq...8w=="],
8      "env": { "DATABASE_URL": "flowlink://ref/docs-db-readonly",
9               "LOG_LEVEL": "warn" },
10      "scopes": ["db:read:public.docs", "db:read:public.snippets"],
11      "denyScopes": ["db:write:*", "fs:*", "shell:*"],
12      "vault": { "provider": "flowlink", "ttlSeconds": 3600 },
13      "provenance": { "verify": true, "sigstore": true,
14                      "expectedSource": "github.com/flowlink/mcp-pg" },
15      "tools": { "allow": ["search_docs", "get_snippet"] },
16      "resilience": { "timeout_ms": 3000,
17                      "circuitBreaker": { "failure_threshold": 3,
18                                          "open_duration": 120 } }
19    }
20  },
21  "policy": { "engine": "opa", "path": "/etc/flowlink/policy/mcp.rego" },
22  "budget": { "window": "1h",
23              "per_session": { "max_tool_calls": 200, "max_cost_usd": 5.00 } },
24  "audit": { "sink": "postgres", "tamperProtection": "forward-chaining-hmac" },
25  "shield": { "enabled": true, "egress": "allow-list" }
26}

Сводный чек-лист: 10 практик MCP security

Десять настроек покрывают стек целиком: протокол (scopes, allowlist) → ядро ОС (systemd, eBPF) → данные (vault, аудит) → логика (policy, budget) → инфраструктура (provenance, resilience). Применяйте их сверху вниз — так каждая следующая MCP конфигурацияопирается на уже включённую предыдущую, и к концу прохода вы получаете воспроизводимый, аудируемый деплой по этим MCP best practices, а не набор разрозненных твиков.