Разделение публичного и боевого контура
Публичные страницы показывают только synthetic demo. Клиентские перевозки, документы, финансы и телеметрия доступны только в авторизованном кабинете.
Security & Data Governance
Данные клиента не становятся витриной. Они остаются под контролем ролей и процессов
Для промышленной логистики доверие важнее красивого интерфейса: BULLS разделяет публичные демо, клиентский кабинет, сотруднический cockpit, публикации по NDA, заявки с форм и операционные решения с approval gates.
Role-based access
Доступ к данным строится по ролям: клиент, логист, диспетчер, финансы, юрист, администратор и наблюдатель.
Approval gates
Решения с коммерческим или операционным риском не уходят в автопилот: reroute, скидки, спорные документы и претензии подтверждает владелец процесса.
Audit log
Заявки, расчеты, публикации, изменения статусов и согласования должны оставлять след: кто, когда, что изменил и из какого источника.
NDA и публикации
Кейсы, отзывы, логотипы и клиентские показатели публикуются только после согласования и проверки разрешений.
152-ФЗ и минимизация данных
Формы собирают только нужные поля; пользователь видит согласие, а публичные демо не содержат персональных или клиентских данных.
ГосЛог / regulatory readiness
Регуляторные требования превращаются в поля, роли, проверки и журналы
Для 5PL-платформы недостаточно написать “соблюдаем закон”. Нужно, чтобы сайт, партнёрская форма, CRM-роутинг, кабинет, документы и AI OS сохраняли проверяемый след: кто подал сведения, какой статус ГосЛог/ЭПД указан, кто проверил и что можно делать дальше.
ГосЛог / реестр ТЭД
В карточке BULLS и партнёра фиксируются статус уведомления о транспортно-экспедиционной деятельности, номер/дата записи и owner проверки.
ГИС ЭПД
Для перевозочных и экспедиторских документов задаются оператор ИС ЭПД, формат обмена, статус подписания, fallback-сценарий и ответственный за спор.
КЭП / МЧД
Подписанты и сотрудники с правом действия от имени юрлица должны иметь подтверждённые полномочия; события подписания попадают в audit log.
152-ФЗ и CRM
Лиды, запросы демо, партнёрские предложения и клиентский доступ передаются в CRM с источником, согласием, целью обработки и минимальным набором данных.
Квалификация подрядчиков
Перед включением в 5PL-контур проверяются роль, документы, география, SLA, ограничения, ЭДО, допуски к грузам и условия доступа к данным.
КИИ assessment
Если система начнёт управлять критичными транспортными процессами, требуется отдельная оценка применимости 187-ФЗ, категорирование и набор мер защиты.
Data classification
Не все данные одинаковые: публичный контент, демо, клиентский контур и секреты живут по разным правилам
Эта классификация помогает не смешивать сайт, демонстрационные сценарии и боевую логистику. Чем выше чувствительность данных, тем меньше публичности и тем жестче роль, журналирование и approval.
Public content
Маркетинговые страницы, методология, обезличенные кейсы, открытые материалы и SEO-страницы.
Можно индексировать и показывать без логина.
Synthetic demo
Демо Control Tower, Track by ID, web-app и примеры документов без реальных клиентских идентификаторов.
Можно показывать публично, но только как демонстрационный контур.
Client operational data
Перевозки, ETA, SLA, маршруты, события, телеметрия, статусы и комментарии по конкретной компании.
Только авторизованные роли клиента и команды BULLS внутри своего тенанта.
Commercial and documents
Счета, акты, договоры, ставки, КП, претензии, согласования и финансовая история.
Доступ по ролям: финансы, юристы, client manager и уполномоченные лица клиента.
Secrets and credentials
Пароли, API keys, webhook URLs, tokens, JWT secrets, database URLs и внутренние endpoints.
Никогда не попадают в frontend, страницы, PDF, llms.txt, sitemap или публичное демо.
Control plane
Управляемость сайта и платформы строится вокруг четырех контуров
Identity
пользователи, роли, тенанты, доступ к кабинету
Data
источник, свежесть, период, provenance и жизненный цикл данных
Workflow
approval queue, comments, notifications, ответственные роли
Observability
healthchecks, smoke, logs, audit trail, noindex для закрытых зон
Публичное правило
На сайте можно показывать демо, методологию, обезличенные сценарии и согласованные кейсы. Нельзя показывать реальные номера перевозок, платежи, документы, имена ответственных, API-ключи и клиентскую телеметрию.
Role access matrix
Кто что видит в сайте, web-app, кабинете и админском контуре
Матрица не заменяет договорные роли, но задает правильный принцип: пользователь видит только те данные и действия, которые нужны для его работы в цепи поставки.
| Роль | Разрешено | Ограничено |
|---|---|---|
| Гость сайта | Сайт, демо, калькулятор, Track by ID, формы и открытые материалы. | Не видит реальные перевозки, документы, финансы, контакты клиента и служебные токены. |
| Проверенный клиент | Свои перевозки, документы, SLA, approvals, уведомления и историю событий. | Не видит данные других клиентов, внутреннюю CRM, системные настройки и секреты. |
| Client manager | Заявки, карточку компании, коммуникации, коммерческие этапы и согласованные материалы. | Не получает доступ к secrets, системным env и данным других ответственных без роли. |
| Control Tower operator | Операционные события, ETA, инциденты, задачи, статусы маршрутов и approval queue. | Не публикует кейсы и не меняет юридические или финансовые условия без approval gate. |
| Docs / finance | Документы, счета, акты, статусы подписания, закрывающие документы и финансовые approvals. | Не управляет публичным контентом, ролями админки и системными интеграциями. |
| Content manager | Страницы, новости, статьи, кейсы, SEO, медиа и публикационный workflow. | Не видит реальные клиентские документы и не публикует NDA-материалы без разрешения. |
| Superadmin | Роли, конфигурацию, users, collections, globals, критичные публикации и интеграционные настройки. | Требует MFA или step-up, короткие сессии, audit log и принцип least privilege. |
Audit event taxonomy
Что должно попадать в audit log
Для управляемого 5PL-контура важно видеть не только факт ошибки, но и цепочку: источник события, роль пользователя, тенант, время, объект изменения и результат.
вход, выход, refresh/revoke сессии и неуспешная попытка доступа
изменение роли, тенанта, доступа к кабинету или состава команды клиента
создание заявки, TCO-расчета, партнерского предложения или запроса demo
изменение статуса перевозки, ETA, SLA, документа, претензии или approval action
создание, редактирование, публикация и снятие с публикации страницы, кейса, новости или отчета
получение webhook/API-события от CRM, web-app, формы, интеграции или AI OS
экспорт, удаление, ограничение обработки или запрос субъекта персональных данных
ошибка healthcheck, smoke, доставки уведомления, webhook retry или интеграционного сценария
Release controls
Что проверяется перед изменением production
Релиз сайта BULLS не должен ломать формы, CRM-маршрутизацию, AI OS, API, индексацию, админку или клиентские входы. Поэтому даже небольшая правка идет через backup, build и smoke.
Pre-deploy backup
Перед production-изменением создается серверный бэкап изменяемых файлов и, для релизов с БД, отдельный backup/migration plan.
Build and typecheck
Next.js, Payload, API и web-app собираются локально или в контейнере; ошибки типов блокируют выпуск.
Smoke coverage
Проверяются 200/301, формы, API, AI OS, MCP, sitemap, robots, noindex, headers, tracking, web-app, LK и ключевые контентные маркеры.
Secrets never in frontend
Секреты читаются только server-side из env/secret storage и не должны появляться в .next/static, public, sitemap, llms.txt или HTML.
Rollback path
Каждый небольшой web-патч имеет отдельный backup folder на сервере, чтобы быстро вернуть предыдущую версию файла.
Backup / RPO / RTO
Восстановление должно быть договорной частью сервиса, а не надеждой на удачу
Для пилота достаточно зафиксировать owner и порядок восстановления. Для enterprise подключения RPO, RTO, restore drill и границы ответственности лучше прописывать в договоре, DPA или приложении по SLA.
RPO
сколько данных допустимо потерять при аварии и какие таблицы/медиа критичны для восстановления
RTO
за какое время нужно вернуть сайт, API, CMS, кабинет, формы и AI OS в рабочее состояние
Restore drill
как часто проверять восстановление из backup, кто owner и где фиксируется результат
Incident owner
кто принимает решение о блокировке доступа, откате публикации, выключении webhook или уведомлении клиента