AI CPO — Техническая документация по безопасности

Для ИБ-отделов, архитекторов и технических руководителей

1. Архитектура платформы

1.1 Стек

1.2 Архитектурная схема

┌──────────────────────────────────────────────────────────┐
│                    КЛИЕНТСКИЙ КОНТУР                      │
│  (Tier 4: всё внутри / Tier 3: только БД внутри)        │
│                                                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────────┐   │
│  │PostgreSQL│  │  Redis   │  │  LLM (Ollama/vLLM)  │   │
│  │(данные)  │  │ (кэш)   │  │  (клиентская модель) │   │
│  └────┬─────┘  └────┬─────┘  └──────────┬───────────┘   │
│       │              │                    │               │
│       └──────────────┼────────────────────┘               │
│                      │                                    │
│              ┌───────┴────────┐                           │
│              │  AI Product    │                           │
│              │  Builder App   │                           │
│              │  (Docker)      │                           │
│              │                │                           │
│              │ ┌────────────┐ │                           │
│              │ │ Encrypted  │ │                           │
│              │ │ Prompts    │ │                           │
│              │ └────────────┘ │                           │
│              │ ┌────────────┐ │                           │
│              │ │ License    │ │                           │
│              │ │ Validator  │ │                           │
│              │ └────────────┘ │                           │
│              └───────┬────────┘                           │
│                      │                                    │
│              ┌───────┴────────┐                           │
│              │  Reverse Proxy │                           │
│              │  (nginx)       │                           │
│              └───────┬────────┘                           │
│                      │                                    │
└──────────────────────┼────────────────────────────────────┘
                       │
               ┌───────┴────────┐
               │  Браузер       │
               │  (TLS/HTTPS)   │
               └────────────────┘

1.3 Потоки данных по тирам

Tier 2: Encrypted

Браузер ──TLS──→ App Server ──→ AR::Encryption ──→ PostgreSQL (AES-256 at rest)
                     │
                     ├──→ Redis (TTL-limited, no PII)
                     │
                     ├──→ LLM API (OpenRouter/Groq/Anthropic)
                     │    ⚠ Данные отправляются в зашифрованном виде
                     │    ⚠ Отключаемо: DATA_TIER=encrypted → sanitized context
                     │
                     └──→ File Storage (AES-256 encrypted at rest)

Tier 3: Hybrid

Браузер ──TLS──→ App Server (наш контур) ──VPN/WireGuard──→ PostgreSQL (контур клиента)
                     │
                     ├──→ Redis (наш контур, no PII, TTL)
                     │
                     ├──→ LLM API (настраиваемый endpoint)
                     │
                     └──→ File Storage (S3/NFS клиента)

Tier 4: Private (air-gap capable)

Браузер ──TLS──→ nginx ──→ App (Docker) ──→ PostgreSQL (локальный)
                                │
                                ├──→ Redis (локальный)
                                │
                                ├──→ LLM (Ollama/vLLM, локальный)
                                │    ✅ Ноль данных наружу
                                │
                                └──→ File Storage (локальный volume)

Внешние подключения: НОЛЬ (при air-gap)
Опциональные: license server ping (отключаемо, grace 30 дней)

2. Шифрование данных

2.1 Encryption at Rest

2.2 Шифруемые поля

Deterministic = можно искать по точному совпадению (WHERE field = value). Non-deterministic = нельзя искать, максимальная безопасность.

2.3 Encryption in Transit

2.4 Ключевое: Zero-Knowledge архитектура (Tier 2+)

При Tier 2+: - Ключ шифрования предоставляет клиент через ENV - Мы не имеем доступа к ключу - Дамп БД без ключа = нечитаемые данные - Бэкапы зашифрованы тем же ключом - При потере ключа данные невосстановимы (by design)

3. Управление доступом

3.1 Аутентификация

3.2 Авторизация (RBAC)

Organization
  ├── Owner (1)     — полный контроль вкл. биллинг и удаление
  ├── Admin (N)     — управление командой, инвайты, все проекты
  ├── Editor (N)    — CRUD проектов, артефактов, комментариев, чат с AI
  └── Viewer (N)    — только чтение + комментирование

Проверка доступа: Teams::PermissionService.can?(user, action, resource) — единая точка на уровне контроллера. Скоупинг запросов через organization_id — невозможно получить данные чужой организации.

3.3 Матрица пермишенов

3.4 Изоляция данных

4. Аудит и мониторинг

4.1 Аудит-трейл

При audit_enabled = true (Tier 2+):

Хранение: таблица workspace_audit_logs. Экспорт: CSV / JSON. Roadmap: SIEM integration (Splunk, ELK).

AI-трансформация: все AI-взаимодействия (чат, генерация артефактов, @AI комментарии) логируются в аудит-лог. Контролируемая точка входа в AI вместо хаотичного использования ChatGPT сотрудниками.

4.2 Логирование

4.3 Мониторинг (Tier 4)

4.4 Штрафы ФЗ-152 (с мая 2025)

С 30 мая 2025 года вступили в силу значительно ужесточённые штрафы за нарушения в области персональных данных:

AI CPO Tier 3-4 обеспечивает полное соответствие ФЗ-152: данные не покидают РФ (Tier 3) или контур клиента (Tier 4). Это не абстрактная безопасность — это защита от оборотных штрафов до 500M ₽.

5. LLM и обработка данных

5.1 Централизованный LLM-клиент

Все вызовы LLM проходят через единый LlmGateway:

LlmGateway.complete(
  prompt: "...",
  model: "sonnet",       # alias, routing is automatic
  max_tokens: 2048,
  system: "...",
  temperature: 0.7
)

При установке переменной LLM_BASE_URL все вызовы автоматически направляются на локальный LLM-сервер (Ollama, vLLM, LocalAI) через OpenAI-совместимый API:

5.2 Конфигурация LLM по тирам

Важно: на Tier 1-2 данные обрабатываются через API OpenRouter/Groq (серверы в США/ЕС). Системные промпты (методология) не содержат пользовательских данных. Для Tier 2: контент санитизируется перед отправкой (PII redaction). Для полного контроля над данными — Tier 3 (свой LLM endpoint) или Tier 4 (локальные модели, air-gap).

5.3 Какие данные отправляются в LLM

5.4 Data Processing Agreement

Для Tier 2+: - Подписываем DPA с клиентом - Данные обрабатываются только для предоставления сервиса - Не используем данные клиента для обучения моделей - Данные удаляются по запросу (GDPR Art. 17) - Подпроцессоры: OpenRouter, Groq, Anthropic (только для Tier 1-2, отключаемо) - Для Tier 4: подпроцессоров НЕТ — всё на инфре клиента

5.5 Подготовка к ограничениям иностранных AI-моделей

В России обсуждается ограничение доступа к проприетарным иностранным AI-моделям (ChatGPT, Claude, Gemini). AI CPO готов к любому сценарию:

Tier 4 — единственный вариант, который работает при ЛЮБОМ сценарии ограничений. Рекомендуется для компаний, планирующих на 3+ лет.

6. Защита интеллектуальной собственности (Tier 4)

6.1 Docker image

6.2 Лицензирование

7. Развёртывание Tier 4

7.1 Системные требования

Для локального LLM (Ollama с 7B моделью): дополнительно 16 GB RAM + GPU (опционально, NVIDIA).

7.2 Установка

# 1. Получить docker-compose.yml и .env.template от вендора
# 2. Настроить .env
cp .env.template .env
# Обязательные переменные:
#   APP_DOMAIN=product.yourcompany.ru
#   ENCRYPTION_PRIMARY_KEY=<ваш_ключ_256_bit>
#   LICENSE_JWT=<лицензионный_токен>
#   LLM_BASE_URL=http://ollama:11434/v1  (или ваш endpoint)
#   SECRET_KEY_BASE=<rails_secret>

# 3. Запуск
docker-compose up -d

# 4. Инициализация БД
docker-compose exec app bin/rails db:create db:migrate db:seed

# 5. Проверка
curl -k https://product.yourcompany.ru/up
# → 200 OK

7.3 Обновление

# 1. Получить новый image от вендора
docker-compose pull

# 2. Обновить (zero-downtime)
docker-compose up -d --no-deps app

# 3. Миграции (если есть)
docker-compose exec app bin/rails db:migrate

7.4 Бэкап

# PostgreSQL dump (ежедневно, рекомендовано)
docker-compose exec db pg_dump -U postgres ai_product_builder > backup_$(date +%Y%m%d).sql

# Файлы (загрузки пользователей)
docker cp $(docker-compose ps -q app):/rails/storage ./backup_storage/

8. Инцидент-респонс

8.1 Классификация

8.2 При обнаружении уязвимости

1. Уведомление клиента в течение 24ч
2. Патч в течение 72ч (P1) / 7 дней (P2) / 30 дней (P3-P4)
3. Обновлённый Docker image доставляется в private registry клиента
4. Post-mortem с root cause analysis

9. Roadmap безопасности

10. FAQ для ИБ

Q: Где хранятся данные? A: Зависит от тира. Tier 4: исключительно на вашей инфраструктуре. Ноль данных покидает ваш контур.

Q: Используете ли вы данные клиентов для обучения AI? A: Нет. Мы не обучаем модели на данных клиентов. При Tier 4 мы вообще не имеем доступа к данным.

Q: Что происходит при расторжении контракта? A: Tier 1-3: данные удаляются в течение 30 дней. Экспорт доступен до удаления. Tier 4: Docker image перестаёт работать после истечения лицензии. Данные остаются у клиента в PostgreSQL (вы владеете своими данными).

Q: Можно ли использовать без интернета? A: Tier 4: да, полный air-gap. LLM работает локально (Ollama/vLLM). Offline grace лицензии 30 дней. Ресёрч (поиск в интернете) будет недоступен — только manual input.

Q: Какие подпроцессоры задействованы? A: Tier 1-2: OpenRouter (LLM), Groq (LLM), Anthropic (LLM), российский хостинг-провайдер. Tier 3: только LLM-провайдер по выбору клиента. Tier 4: подпроцессоров нет.

Q: Как проходит обновление? A: Новый Docker image доставляется в private registry клиента. docker-compose pull && docker-compose up -d. Миграции БД автоматические. Rollback: docker-compose up -d --force-recreate с предыдущим image.

Q: Есть ли пентест? A: Планируется Q2 2026. До этого — внутренний security audit + автоматизированные проверки (Brakeman, bundler-audit).

Документ подготовлен для технической оценки. Для демонстрации платформы свяжитесь: roman.neverov@aicpo.ru