Разделение публичного и боевого контура
Публичные страницы объясняют сервисы и порядок работы. Клиентские перевозки, документы, финансы и телеметрия доступны только в авторизованном кабинете.
Security & Data Governance
Данные клиента не становятся витриной. Они остаются под контролем ролей и процессов
Для промышленной логистики доверие важнее красивого интерфейса: BULLS разделяет публичный сайт, клиентский кабинет, сотруднический cockpit, публикации по NDA, заявки с форм и операционные решения с approval gates.
Role-based access
Доступ к данным строится по ролям: клиент, логист, диспетчер, финансы, юрист, администратор и наблюдатель.
Approval gates
Решения с коммерческим или операционным риском не уходят в автопилот: reroute, скидки, спорные документы и претензии подтверждает владелец процесса.
Audit log
Заявки, расчеты, публикации, изменения статусов и согласования должны оставлять след: кто, когда, что изменил и из какого источника.
NDA и публикации
Кейсы, отзывы, логотипы, обезличенные примеры и клиентские показатели публикуются только после согласования и проверки разрешений.
152-ФЗ и минимизация данных
Формы собирают только нужные поля; пользователь видит согласие, а рабочие данные не попадают в открытые страницы сайта.
ГосЛог / regulatory readiness
Регуляторные требования превращаются в поля, роли, проверки и журналы
Для 5PL-платформы недостаточно написать “соблюдаем закон”. Нужно, чтобы сайт, партнёрская форма, маршрутизация обращений, кабинет и документы сохраняли проверяемый след: кто подал сведения, какой статус ГосЛог/ЭПД указан, кто проверил и что можно делать дальше.
ГосЛог / реестр ТЭД
В карточке BULLS и партнёра фиксируются статус уведомления о транспортно-экспедиционной деятельности, номер/дата записи и owner проверки.
ГИС ЭПД
Для перевозочных и экспедиторских документов задаются оператор ИС ЭПД, формат обмена, статус подписания, fallback-сценарий и ответственный за спор.
КЭП / МЧД
Подписанты и сотрудники с правом действия от имени юрлица должны иметь подтверждённые полномочия; события подписания попадают в audit log.
152-ФЗ и обращения
Лиды, запросы подключения, партнёрские предложения и клиентский доступ передаются в рабочий контур BULLS с источником, согласием, целью обработки и минимальным набором данных.
Квалификация подрядчиков
Перед включением в 5PL-контур проверяются роль, документы, география, SLA, ограничения, ЭДО, допуски к грузам и условия доступа к данным.
КИИ assessment
Если система начнёт управлять критичными транспортными процессами, требуется отдельная оценка применимости 187-ФЗ, категорирование и набор мер защиты.
Data classification
Не все данные одинаковые: публичный контент, клиентский контур и секреты живут по разным правилам
Эта классификация помогает не смешивать сайт, точки входа и рабочую логистику. Чем выше чувствительность данных, тем меньше публичности и тем жестче роль, журналирование и approval.
Public content
Маркетинговые страницы, методология, обезличенные кейсы, открытые материалы и SEO-страницы.
Можно индексировать и показывать без логина.
Protected workspace entry
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, уведомления и историю событий. | Не видит данные других клиентов, внутренние рабочие данные, системные настройки и секреты. |
| 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-расчета, партнерского предложения или запроса подключения
изменение статуса перевозки, ETA, SLA, документа, претензии или approval action
создание, редактирование, публикация и снятие с публикации страницы, кейса, новости или отчета
получение webhook/API-события от рабочего контура, web-app, формы или интеграции
экспорт, удаление, ограничение обработки или запрос субъекта персональных данных
ошибка healthcheck, smoke, доставки уведомления, webhook retry или интеграционного сценария
Release controls
Что проверяется перед изменением production
Релиз сайта BULLS не должен ломать формы, маршрутизацию обращений, 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, 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, кабинет и формы в рабочее состояние
Restore drill
как часто проверять восстановление из backup, кто owner и где фиксируется результат
Incident owner
кто принимает решение о блокировке доступа, откате публикации, выключении webhook или уведомлении клиента