LEM.RU · 2026

Безопасность · 9 мин

Права, приватность и изоляция контуров

Как разделяются публичный демонабор, закрытый пилот и партнёрский экземпляр.

Публичная демонстрация, пилот с реальными командами и отдельный экземпляр организации не могут жить по одной модели доступа. У них разный риск, состав данных и ответственность оператора.

Изоляция строится техническими границами и отзывом доступа, а пользовательское соглашение только дополняет их.
01

Публичный демонабор открыт только для чтения

Для первого знакомства доступна готовая синтетическая библиотека. В этот контур нельзя загрузить свой код, изменить состав демонабора или удалить его. Все материалы созданы специально для показа и не содержат клиентских данных.

02

Закрытый пилот планируется по приглашениям

При запуске пилота 1С-разработчик или аналитик сможет запросить персональный доступ. Принятая модель предусматривает квоты, ограниченный срок хранения, приватность по умолчанию и отзыв адресного доступа. Технический запрет публичного статуса пользовательской библиотеки и фактические условия требуется проверить до открытия набора.

03

Партнёрский контур — отдельный экземпляр

Для партнёрского экземпляра могут быть согласованы собственные правила доступа, мощности, резервирование и журналы. Название заказчика, логотип и кейс не публикуются без отдельного согласования. Эта статья описывает возможную продуктовую модель, а не готовую схему развёртывания.

Три изолированных уровняДанные не перетекают между уровнями по умолчанию.
01Публичный демонабор

Только чтение, лимиты, без пользовательских загрузок.

02Закрытый пилот

Приглашения, приватность, квоты и отзыв.

03Партнёрский экземпляр

Отдельная организация и отдельные правила.

04

Журнал тоже является границей данных

Нельзя записывать токены, персональные данные, полные тела запросов, Idempotency-Key и requestFingerprint. Для диагностики оставляются безопасные технические поля, необходимые для разбора события, и ограничивается срок хранения.

05

Проверка журнала после конфликта

В синтетическом случае ROUTE-409-DUPLICATE разработчику нужны код ошибки, время и техническая координата версии, но не ключ операции и не тело запроса. Агент сначала читает правило logging.md, затем предлагает только разрешённые поля и отдельный негативный тест, который ищет запрещённые значения в результате журналирования.

Это демонстрация правила на вымышленных данных. Политика организации, фактический формат её журнала и работа теста должны быть подтверждены в собственном контуре. Публичный демонабор не принимает пользовательский код и не исполняет проверки.

Синтетический пример

Разобрать ошибку без утечки запроса

Вопрос Q8 проверяет, сможет ли агент предложить полезную диагностику без копирования чувствительных данных.

  1. Спросить агента: «Для ошибки ROUTE-409-DUPLICATE назови поля, которые разрешено записывать в журнал, и точный источник правила; значения ключа и тела запроса не выводи».
  2. Открыть стандарт журналирования и разделить разрешённые технические поля и запрещённые чувствительные значения.
  3. Проверить синтетический пример обработчика, затем вручную оценить, какие поля реально попадают в журнал.
  4. Для собственного проекта добавить негативный тест на отсутствие чувствительных значений; публичное демо не выполняет его код.

Сценарий развёртывания и данные полностью синтетические; реальные политики утверждаются владельцем каждого контура.

Граница доказательства

Что уже можно утверждать, а что нужно проверить

Подтверждено материалом
  • Продуктовая модель разделяет публичный демонабор, закрытый пилот и партнёрский экземпляр.
  • Для пилота зафиксировано требование технически отключить публичный статус пользовательских библиотек.
Проверяется в конкретном контуре
  • Фактическую реализацию доступа, запрета публикации и аудита перед открытием пилота.
  • Сроки хранения, квоты и процедуру реакции на инцидент.