Reference Architecture
Zero-Trust MCP Deployment — production-архитектура FlowLink, выровненная по OWASP GenAI MCP Security Guide и enterprise best practices.
~8 мин чтения
Модель угроз MCP
FlowLink покрывает ключевые threat vectors для AI-агентов:
| Угроза | Риск | Митигация FlowLink |
|---|---|---|
| Tool Poisoning | Malicious MCP server returns harmful tool definitions | Shield проверяет все tool calls; policy engine валидирует имена, args и targets по allowlists |
| Prompt Injection через Tool | Tool output содержит инструкции, манипулирующие агентом | Output filtering + санитизация; approval queue для чувствительных операций |
| Over-Privileged Tools | Агент имеет доступ к tools, которые не нужны (prod DB из dev) | Per-agent least-privilege политики; tool scoping по environment и role |
| Data Exfiltration | Агент читает чувствительные данные и отправляет наружу | Anomaly detection (scp, rsync, curl); blast radius analysis; secret injection предотвращает утечку credentials |
| Credential Theft | Агент получает доступ к секретам в memory/logs | Zero-trust secret injection — credentials никогда не в контексте агента; runtime-only env vars |
| Unauthorized Access | Скомпрометированный агент обращается к ресурсам за пределами scope | Per-org encryption keys; RBAC; approval queue для cross-service операций |
| Supply Chain Attack | Скомпрометированный MCP server в tool chain | Tool allowlisting; command pattern analysis; audit trail для каждого tool invocation |
Production Topology
┌─────────────────┐
│ Load Balancer │
│ (nginx/caddy) │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌──────▼──────┐┌─────▼──────┐┌──────▼──────┐
│ FlowLink ││ FlowLink ││ FlowLink │
│ Relay #1 ││ Relay #2 ││ Relay #3 │
│ (active) ││(active) ││ (standby) │
└──────┬──────┘└─────┬──────┘└──────┬──────┘
│ │ │
└──────────────┼──────────────┘
│
┌──────────────▼──────────────┐
│ PostgreSQL (Primary) │
│ + Read Replicas │
└──────────────┬──────────────┘
│
┌───────────┬───────────┼───────────┬───────────┐
│ │ │ │ │
┌──────▼────┐┌─────▼─────┐┌───▼────┐┌─────▼────┐┌─────▼────┐
│ Vault ││ SIEM ││ Redis ││ S3 ││ SMTP │
│ (Secrets) ││(Splunk/ ││(Cache) ││(Backups) ││(Email) │
│ ││ QRadar) ││ ││ ││ │
└───────────┘└───────────┘└────────┘└──────────┘└──────────┘Ресурсы компонентов
| Компонент | Small (<50 агентов) | Medium (50-500) | Large (500+) |
|---|---|---|---|
| FlowLink Relay | 2 vCPU, 4GB | 4 vCPU, 8GB ×2 | 8 vCPU, 16GB ×3+ |
| PostgreSQL | 2 vCPU, 4GB, 50GB SSD | 4 vCPU, 16GB, 200GB SSD | 8 vCPU, 32GB, 1TB NVMe |
| Agent (ServerGuard) | 1 vCPU, 512MB | 1 vCPU, 512MB | 2 vCPU, 1GB |
| Redis (optional) | — | 1 vCPU, 2GB | 2 vCPU, 8GB cluster |
| nginx | 1 vCPU, 1GB | 2 vCPU, 2GB | 4 vCPU, 4GB + CDN |
Сетевая безопасность
Агент → RelayWSS (TLS 1.3) port 9080 — mutual TLS или token-based auth
Dashboard → RelayHTTPS port 9081 — httpOnly cookies, CSRF protection
Relay → DatabaseTLS connection to PostgreSQL, SCRAM-SHA-256 auth
Relay → VaultmTLS to HashiCorp Vault, per-org token scoping
Relay → SIEMHTTPS webhook push (Alertmanager / Generic), TLS required
Agent → eBPFServerGuard monitorит файлы через inotify + eBPF, Docker events API, canary tokens
Управление секретами
1. Агент запрашивает tool execution, требующий секрет
│
2. Shield перехватывает → проверяет policy → ALLOW (требуется секрет)
│
3. Relay получает секрет из Vault (org-specific key)
│
4. Секрет внедряется в окружение выполнения:
• Environment variable (FLOWLINK_SECRET_*)
• Temp file (auto-cleaned после выполнения)
• Stdin pipe (никогда не пишется на диск)
│
5. Tool выполняется с доступным секретом
│
6. После выполнения: секрет удалён из памяти и temp files
│
7. Audit log: "secret accessed" (имя секрета, не значение)OWASP MCP Security Checklist
Маппинг фич FlowLink на рекомендации OWASP GenAI MCP Security:
| Рекомендация OWASP | Фича FlowLink | Конфигурация |
|---|---|---|
| Валидировать все tool inputs | Shield pattern matching + risk scoring | Policies → Rules → Patterns |
| Least-privilege доступ | Per-agent политики с tool allowlists | Политики → Agent scoping |
| Human oversight для критичных действий | Approval queue (Telegram / Web / API) | Policy action = "approve" |
| Логировать все tool invocations | Audit log + Command history | Всегда включено |
| Сканировать tool responses на sensitive data | Output filtering + DLP patterns | Shield → Output rules |
| Безопасное управление credentials | Zero-trust secret injection | Secrets → Injection mappings |
| Мониторинг аномального поведения | Anomaly detection (off-hours, lateral movement, privilege escalation) | Forensics → Timeline |
| Rate limiting | Per-agent и per-tool rate limits | Конфигурация → rate_limits |
| Шифрование данных | TLS everywhere, per-org X25519 keys, AES-256-GCM | Auto (TLS), Zero-Trust API |
| Incident response plan | Forensic timeline + snapshots + compliance reports | Forensics dashboard |
Hardening Guide
Relay
- Запуск от non-root с минимальными capabilities
- TLS с сильными cipher suites (ECDHE-ECDSA-AES256-GCM-SHA384)
- cors_allowed_origins — конкретные домены, не
*в production - rate_limits для всех agent IDs
- systemd watchdog
Database
- RLS (Row Level Security) на tenant-scoped таблицах
- service_role только для internal ops, anon для public
- Connection pooling (PgBouncer / Supabase)
- PITR + ежедневные бэкапы
- Шифрование at rest (LUKS)
Агенты
- Каждый агент — уникальный API key
- Минимальный набор политик: deny all → add allows
- Heartbeat для real-time мониторинга
- Auto-update + signature verification
- ServerGuard (--features gitops) — eBPF мониторинг