Техническое задание
на разработку CRM

Общие положения

Настоящий документ определяет полный объём работ по проектированию, разработке, развёртыванию и сопровождению CRM-системы для проекта axto.ru. Документ обязателен для исполнения подрядчиком и является основанием для приёмки результата.

Назначение системы

Система предназначена для централизованного учёта клиентов, автомобилей, китайских транзитных номеров с контролем сроков их действия, проводимых работ по русификации, выставленных счетов, выданных доступов (логины/пароли/почтовые ящики), а также для оперативного управления напоминаниями и календарём владельца.

Бизнес-контекст

Заказчик ведёт оказание услуг по русификации автомобилей, оформлению китайских транзитных номеров (срок действия — ограничен, требует контроля), а также организации поставок автомобилей из Китая через партнёров. Часть клиентов — VIP, для них предусмотрена персональная коммуникация и выдача персональных почтовых ящиков на собственном домене.

Источники требований

• Бизнес-процессы заказчика (описаны в разделе 04).
• Федеральный закон № 152-ФЗ «О персональных данных».
• Приказ ФСТЭК России № 21 (требования к защите ПДн).
• Рекомендации OWASP ASVS v4.0 (уровень L2).

Цели и задачи

Бизнес-цели

1. Не упустить ни одного срока китайского номера. Все номера, у которых до истечения осталось ≤ 30/14/7/3/1 дней — автоматически попадают в дашборд и пуш-уведомления.
2. Единая карточка клиента. Вся история работ, авто, номеров, доступов и счетов — в одной карточке с поиском по VIN, телефону, номеру или ФИО за ≤ 1 секунду.
3. Защищённое хранение секретов клиентов. Логины, пароли и реквизиты ящиков — шифрованно, с журналом доступа и невозможностью извлечь массово.
4. Работа в дороге. Мобильный клиент в офлайн-режиме на встречах и в салоне — без зависимости от сети.
5. Масштабирование. Возможность подключать сотрудников и партнёров с ограничением прав без переписывания системы.

Технические задачи

• Спроектировать и реализовать backend на FastAPI + PostgreSQL.
• Реализовать веб-админку (адаптивная, для ПК).
• Реализовать мобильное приложение на Flutter (Android + iOS) с офлайн-БД и фоновой синхронизацией.
• Реализовать сервис генерации почтовых ящиков на собственном домене.
• Реализовать подсистему напоминаний, iCal-фидов и push-уведомлений.
• Внедрить полный комплекс мер защиты данных (раздел 06).
• Развернуть на инфраструктуре заказчика, передать документацию и обучить.

Пользователи и роли

Система реализует ролевую модель доступа (RBAC). Все действия журналируются (см. раздел 06).

Функциональные требования

4.1 Управление клиентами

• Создание, редактирование, архивация клиента. Удаление — только мягкое (soft delete) с записью в журнал.
• Поля: ФИО, телефон (+ доп.), e-mail, мессенджеры (TG, WeChat, WhatsApp), город, флаг VIP, теги, источник, заметки, дата создания.
• Привязка нескольких авто, номеров, работ, доступов и счетов.
• Поиск по любому полю, в т.ч. по VIN и фрагменту телефона/номера, время отклика ≤ 1 с при базе до 50 000 клиентов.
• Дедупликация: при создании — проверка на похожие записи по телефону и VIN.
• История изменений (кто, когда, что изменил).

4.2 Управление автомобилями

• Поля: VIN (уникально, валидация контрольной суммы), марка, модель, год, цвет, дата ввоза, страна происхождения, фотографии (до 20 шт.), статус (на работах / выдан / в пути).
• Привязка к клиенту. История перехода между клиентами (если авто перепродавалось).

4.3 Управление китайскими номерами

• Поля: номер, тип, провайдер/поставщик, дата выдачи, дата истечения, привязка к авто и/или клиенту, статус (активен / истёк / продлён / аннулирован), стоимость, комментарий.
• Цветовая индикация по сроку: зелёный (> 30 дн.), жёлтый (≤ 30), оранжевый (≤ 14), красный (≤ 7), чёрный (истёк).
• Автоматические напоминания (см. 4.7) — за 30, 14, 7, 3, 1 день.
• Журнал продлений: каждое продление — новая запись со ссылкой на предыдущую.
• Массовый импорт из Excel/CSV для миграции существующей базы.

4.4 Журнал работ и стоимость

• Поля: клиент, авто, тип работы (русификация ГБО / магнитола / приборка / прочее — справочник), дата начала, дата завершения, исполнитель, статус, стоимость работ, стоимость материалов, предоплата, остаток, комментарий.
• Возможность прикрепить файлы (акты, фото до/после).
• Сводка по доходам: за день / неделю / месяц / квартал / год.

4.5 Хранилище доступов (Vault)

4.6 Генерация почтовых ящиков для VIP

• Создание ящика вида имя@домен-клиента.ru на собственном почтовом сервере (Mailcow / iRedMail) через API.
• Автогенерация стойкого пароля (длина ≥ 16, символы из 4 классов).
• Сохранение реквизитов в Vault (см. 4.5).
• Передача клиенту через защищённый одноразовый канал (см. ниже).
• Отзыв ящика, смена пароля, форвардинг.

Передача доступов клиенту

Для безопасной передачи реквизитов клиенту реализовать механизм one-time link: система генерирует ссылку, по которой реквизиты можно открыть один раз в течение ограниченного времени (по умолчанию 24 часа), после чего они уничтожаются. Никаких реквизитов в открытом виде в Telegram/SMS/e-mail.

4.7 Напоминания и календарь

• Ручные напоминания (на дату/время, с привязкой к клиенту/делу).
• Автоматические напоминания по правилам (срок номера, срок гарантии работы, день рождения клиента и т.д.).
• Push-уведомления (FCM/APNs), e-mail-уведомления, опционально — Telegram-бот.
• Экспорт в iCal: персональный URL-фид для подписки в Google/Apple/Yandex-календарь. URL подписан HMAC и содержит секретный токен, отзываемый при компрометации.

4.8 Дашборд владельца

• Виджеты: истекающие номера, ожидающие оплаты, активные работы, выручка за месяц, новые клиенты, задачи на сегодня.
• Быстрые действия (добавить клиента, авто, номер, работу).

4.9 Поиск и фильтры

• Глобальный поиск (Ctrl/Cmd+K) по всей системе.
• Фильтры на каждом списке (по статусу, исполнителю, источнику, тегам, периоду).
• Сохранение пользовательских фильтров.

4.10 Уведомления и журналы

• Лента уведомлений в системе.
• Журнал аудита (см. 6.7) — доступ только Owner/Auditor.

Модель данных

Ниже приведены ключевые сущности. Все таблицы содержат обязательные служебные поля: id (UUID v7), created_at, updated_at, version (для optimistic locking), deleted_at (soft delete), created_by, updated_by.

Client (Клиент)

Vehicle (Автомобиль)

ChinesePlate (Китайский номер)

WorkOrder (Заказ-наряд / работа)

VaultEntry (Защищённая запись доступов)

Reminder, AuditLog, User

Дополнительные таблицы: reminders (напоминания и правила), audit_log (журнал аудита, append-only), users (учётные записи), roles, permissions, sessions, sync_queue (очередь синхронизации).

Защита данных

Данные клиентов (особенно — китайские номера, VIN, паспорта, пароли, реквизиты ящиков) являются критически чувствительными. Любая утечка нанесёт прямой репутационный и юридический ущерб. Этот раздел — обязательный к буквальному исполнению.

6.1 Классификация данных

6.2 Шифрование

Транспортное шифрование (in transit)

• TLS 1.3 обязательно. TLS 1.2 — допустим как fallback. Всё ниже — запрещено.
• Сертификаты от Let's Encrypt с автоматическим продлением (acme.sh / certbot).
• HSTS включён (max-age=31536000; includeSubDomains; preload).
• Запрещены слабые шифры (RC4, 3DES, CBC без AEAD).
• Certificate pinning в мобильном приложении (с возможностью обновления через kill-switch).

Шифрование при хранении (at rest)

• Шифрование диска сервера (LUKS / dm-crypt).
• Шифрование базы данных на уровне приложения для чувствительных полей (см. 5).
• Алгоритм: AES-256-GCM для симметричного шифрования, X25519 + ChaCha20-Poly1305 для асимметричного (при необходимости).
• Хеширование паролей пользователей системы: Argon2id (m=64MB, t=3, p=2) или bcrypt cost=12 (резервный вариант).
• Запрещён MD5 и SHA-1 для любых целей, кроме контрольных сумм файлов.

Управление ключами (KMS)

• Мастер-ключ (KEK) хранится в HashiCorp Vault (или AWS KMS / YC KMS — на выбор заказчика). Запрещено хранить KEK в коде, .env, репозитории.
• Полевые ключи (DEK) генерируются на каждую чувствительную запись и шифруются KEK (envelope encryption).
• Ротация KEK — раз в 12 месяцев или по инциденту. Процедура ротации — документирована.
• Доступ к KMS — только через сервисный аккаунт backend, с логированием каждого обращения.

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

• Логин по e-mail + пароль (Argon2id).
• Обязательная 2FA для всех ролей с правом записи. TOTP (Google Authenticator / Authy) — обязательно. SMS — запрещено (уязвимо к SIM-swap).
• Резервные коды (10 одноразовых) — выдаются при включении 2FA.
• WebAuthn / Passkeys — рекомендуется для Owner.
• Защита от brute-force: rate-limit, экспоненциальная задержка, CAPTCHA после 3 неудач, временная блокировка после 10 неудач.
• Сессии: JWT access token (TTL 15 мин) + refresh token (TTL 30 дней, ротация при каждом использовании, отзыв при logout/смене пароля).
• Refresh tokens хранятся в БД с возможностью отзыва (revocation list).

6.4 Авторизация

• RBAC + проверка прав на каждом эндпоинте.
• Принцип «запрещено всё, что не разрешено явно» (default deny).
• Многоуровневая проверка: middleware + декоратор на роутере + проверка в сервисе (defense in depth).
• IDOR-защита: на каждом запросе — проверка, что запрашиваемый ресурс принадлежит scope пользователя.

6.5 Защита от уязвимостей (OWASP Top-10)

6.6 Сетевая безопасность

• Backend и БД — в приватной подсети. БД недоступна из интернета. Доступ к ней — только из backend и через SSH-туннель администратора.
• Firewall: открыты только 80/443 (web), 22 (SSH с ограничением по IP / fail2ban).
• WAF на уровне reverse proxy (Nginx + ModSecurity / Caddy + плагин).
• Rate-limiting на каждом эндпоинте API: общий лимит + персональный лимит на эндпоинты логина/смены пароля/расшифровки секретов.
• Защита от DDoS: Cloudflare / Selectel DDoS Protection.
• SSH: только по ключам, root-вход запрещён, MFA для администратора.

6.7 Журнал аудита

Обязательно журналируется:

• Все события аутентификации (успех/неудача, выход, смена пароля, включение/отключение 2FA).
• Любое обращение к Vault (расшифровка пароля/секрета) — с причиной.
• Все CRUD-операции над клиентами, авто, номерами, работами.
• Изменение прав, создание/удаление пользователей.
• Экспорт данных (любой).
• Изменения настроек системы.

Срок хранения журнала — не менее 3 лет. Журнал реплицируется на отдельный «холодный» носитель раз в сутки.

6.8 Защита мобильного приложения

• Локальная БД (Drift / Isar) — зашифрована (SQLCipher / встроенное шифрование Isar). Ключ хранится в Keychain (iOS) / Keystore (Android), привязан к биометрии устройства.
• Биометрический вход (Face ID / Touch ID / отпечаток) — обязателен для приложения.
• Автолок: после 2 минут неактивности — экран блокировки, биометрия.
• Запрет скриншотов на экранах с секретами (FLAG_SECURE на Android, экраны-плейсхолдеры на iOS).
• Запрет работы на rooted/jailbroken устройствах (с предупреждением).
• Certificate pinning, обнаружение MITM.
• Обфускация кода (R8 на Android, --obfuscate на Flutter iOS).
• При удалении сессии / разлогине — wipe локальной БД.

6.9 Защита от внутренних угроз

• Принцип «двух глаз» для критичных операций (массовое удаление, экспорт > 100 записей) — подтверждение второго аккаунта Owner.
• Запрет массового экспорта Vault на уровне API (rate-limit 1 секрет / 10 сек, не более 50 в час).
• Журнал доступа к секретам показывается в карточке клиента (прозрачность для менеджеров).
• Регулярная ревизия активных учётных записей (раз в 3 месяца) — отчёт Owner.

6.10 Реакция на инциденты

• Документированная процедура: обнаружение → изоляция → анализ → восстановление → уведомление.
• Контакты ответственных, шаблоны уведомлений (Роскомнадзор — 24 часа на уведомление при утечке ПДн по 152-ФЗ).
• Kill-switch: возможность одной командой отозвать все сессии и refresh-токены.
• Мониторинг: алерты в Telegram на: 10+ неудачных входов, аномальное число расшифровок, доступ с нового IP/устройства Owner.

6.11 Типовые угрозы и контрмеры

Архитектура и стек

Технологический стек

Развёртывание

• VPS у российского хостера (Selectel / Yandex Cloud / Timeweb) — данные ПДн обязаны размещаться на территории РФ (152-ФЗ, ст. 18 п. 5).
• Конфигурация: 2 виртуальных сервера для отказоустойчивости (production + резерв) или один с регулярными снапшотами на старте, с миграцией на HA-конфигурацию при росте.
• Минимальная конфигурация production: 4 vCPU, 8 GB RAM, 100 GB NVMe (SSD).
• Отдельное окружение dev/staging — на меньшей конфигурации.
• Все секреты — в Vault / переменных окружения, никогда в коде.
• CI/CD: GitLab CI или GitHub Actions с self-hosted runner.

Принципы архитектуры

• Layered: API → Service → Repository → DB.
• Dependency Injection через FastAPI Depends.
• Идемпотентность POST-эндпоинтов (через ключ Idempotency-Key).
• Все ошибки — единый формат (RFC 7807 Problem Details).
• Все даты — UTC, отдаются в ISO 8601.

API и синхронизация

Общие правила API

• REST + JSON. Версионирование через префикс /api/v1/.
• Документация: OpenAPI (Swagger UI на dev/staging, скрыт на проде).
• Все GET-эндпоинты отдают ETag (weak), поддерживают If-None-Match → 304.
• Все PUT/PATCH требуют If-Match (strong ETag) — для optimistic locking. При несоответствии — 412 Precondition Failed.
• POST с Idempotency-Key — для всех создающих эндпоинтов.
• Пагинация: cursor-based для больших списков.
• Фильтрация: query-параметры по whitelist полей.

Синхронизация мобильного клиента

• Pull (server → client): Эндпоинт GET /api/v1/sync?since=<timestamp> отдаёт изменения с указанной отметки. Курсорная пагинация.
• Push (client → server): Очередь sync_queue на устройстве, фоновая отправка через WorkManager (Android) / Background Tasks (iOS).
• Конфликты: Optimistic locking через ETag. Для большинства полей — Last Write Wins по серверной отметке времени. Для критичных полей (VIN, expires_at номера) — Server Wins с уведомлением пользователя и UI разрешения конфликта.
• Soft delete: Удалённые на устройстве записи помечаются deleted_at, отправляются на сервер, физическое удаление — отложенное (через 30 дней).

Ключевые эндпоинты (фрагмент)

Мобильное приложение

Платформы

• Android 9.0+ (API 28+).
• iOS 15.0+.
• Размер APK / IPA — не более 60 MB.

Ключевые экраны

1. Вход (e-mail + пароль + 2FA + биометрия).
2. Дашборд (виджеты, как в вебе).
3. Список клиентов (поиск, фильтры, инфинит-скролл).
4. Карточка клиента (вкладки: Авто, Номера, Работы, Vault, История).
5. Календарь и напоминания.
6. Vault — отдельный экран с биометрической проверкой при входе.
7. Настройки и профиль.
8. Экран разрешения конфликтов синхронизации.

Офлайн-режим

• Все операции — сначала локально, затем синхронизация.
• Локальная БД — Drift с SQLCipher.
• State: Riverpod 2 + AsyncNotifier.
• Connectivity: connectivity_plus + индикатор офлайн.
• Очередь синхронизации видна пользователю (счётчик «X несинхронизированных изменений»).

Защита мобильного приложения

См. подробно раздел 6.8.

Интеграции

Обязательные интеграции

• Почтовый сервер (Mailcow API) — создание/удаление ящиков для VIP.
• FCM + APNs — push-уведомления.
• iCal-фид — экспорт календаря (HMAC-токен).
• SMTP (через свой почтовый сервер) — отправка системных писем.

Опциональные (вторая очередь)

• Telegram-бот для уведомлений Owner и опционально менеджеров.
• Экспорт в Excel/CSV для бухгалтерии (с журналированием).
• Интеграция с онлайн-кассой / эквайрингом (Тинькофф, ЮКасса) — если планируется приём платежей через систему.
• Webhooks для подключения партнёров.
• Интеграция с социальными платформами (ВКонтакте, Дзен, Rutube) для трекинга источников лидов — на будущее.

Принципы интеграций

• Все исходящие запросы — через белый список доменов.
• Ключи API сторонних сервисов — в Vault / KMS.
• Retry с экспоненциальной задержкой, dead-letter очередь.
• Журналирование всех внешних вызовов (без логирования токенов).

Нефункциональные требования

Производительность

• P95 времени ответа GET — ≤ 200 мс при нагрузке до 100 RPS.
• P95 поиска по 50 000 клиентам — ≤ 1 с.
• Загрузка дашборда — ≤ 1.5 с на 4G.
• Холодный старт мобильного — ≤ 2 с.

Надёжность

• Uptime — ≥ 99.5% в месяц (≤ 3.6 ч простоя).
• Health-check эндпоинт + автоматический рестарт при падении.
• Graceful shutdown при деплое.

Масштабируемость

• Архитектура поддерживает горизонтальное масштабирование backend (stateless API).
• До 50 одновременных пользователей и 200 000 клиентов в БД — без деградации производительности.

Доступность интерфейса

• Все интерфейсы — на русском языке.
• Адаптивный веб (от 1280px до 1920px+ для админок, оптимизация под десктоп).
• WCAG 2.1 AA — рекомендуемый ориентир (контраст, фокус-стейты, клавиатурная навигация).

Совместимость

• Браузеры: Chrome / Edge / Yandex / Firefox / Safari — последние 2 версии.
• Мобильные: см. раздел 9.

Резервное копирование

Бэкап — отдельная критичная подсистема. Сам бэкап — потенциальная точка утечки, поэтому шифрование обязательно.

Стратегия 3-2-1

• 3 копии данных (оригинал + 2 бэкапа).
• 2 разных носителя (например, локальный диск + объектное хранилище).
• 1 копия — offsite (другой провайдер / физически другой ЦОД).

Расписание

• Полный бэкап БД — ежедневно в ночное время.
• Инкрементальный бэкап WAL — каждый час.
• Бэкап файлового хранилища — ежедневно.
• Бэкап журнала аудита — ежедневно на «холодный» носитель (write-only S3 / Glacier).
• Сроки хранения: ежедневные — 30 дней, еженедельные — 12 недель, ежемесячные — 12 месяцев.

Защита бэкапов

• Все бэкапы шифруются GPG / age перед загрузкой в offsite-хранилище.
• Ключ дешифрования бэкапов хранится отдельно от бэкапов (в Vault и у Owner).
• Доступ к бэкапам — только сервисный аккаунт + Owner.
• Регулярная проверка восстановления — раз в квартал (DR drill).

RTO / RPO

• RPO (допустимая потеря данных): ≤ 1 час.
• RTO (время восстановления): ≤ 4 часа.

Юридические требования

Соответствие 152-ФЗ «О персональных данных»

• Хранение ПДн граждан РФ — только на серверах в РФ (ст. 18 п. 5).
• Подача уведомления в Роскомнадзор о начале обработки ПДн (форма на pd.rkn.gov.ru).
• Назначение ответственного за обработку ПДн (приказ внутри компании).
• Разработка локальных актов: Политика обработки ПДн, Положение об обработке ПДн, Согласие на обработку ПДн.
• Согласие клиента на обработку ПДн — обязательно при заключении договора оказания услуг.
• Уведомление об утечке — в Роскомнадзор в течение 24 часов с момента обнаружения, подробный отчёт — в течение 72 часов (242-ФЗ от 2022 года, поправки).
• Право клиента на удаление своих ПДн — реализовано в системе (Owner может удалить клиента полностью, с журналированием).

Документация

• Политика конфиденциальности — публикуется на axto.ru.
• Пользовательское соглашение для клиентов CRM (если будет клиентский портал — на будущее).
• Внутренний регламент обращения с ПДн для сотрудников.
• NDA с подрядчиком на разработку и сопровождение.

Этапы и приёмка

Критерии приёмки

• Все требования разделов 4–13 реализованы и приняты по чек-листу.
• Покрытие unit-тестами — не менее 70% для бизнес-логики.
• Покрытие интеграционными тестами — все эндпоинты API.
• Пройден внешний аудит безопасности с устранением всех критичных и высоких замечаний.
• Произведено успешное восстановление из бэкапа (DR drill).
• Подготовлена документация: README, API (Swagger), руководство администратора, руководство пользователя, журнал миграций.
• Передан исходный код в репозиторий заказчика. Все права на код — у заказчика.

Гарантия

• Подрядчик предоставляет гарантию 12 месяцев с момента ввода в эксплуатацию.
• В гарантию входит устранение ошибок, не входит — реализация новых функций.
• Время реакции на критичный инцидент — 4 часа, устранение — 24 часа.

Глоссарий