Изоляция данных компаний в личном кабинете на Битрикс: проектирование и проверка доступа

Чтобы пользователь одной компании не видел данные другой, в личном кабинете на 1С-Битрикс нужно заранее определить владельца каждой сущности, ограничить выборку на уровне запросов и проверить доступ по ролям. Ниже — предметная последовательность: от карты данных до чек-листа приёмки и разбора ошибок.

Что значит изоляция данных компаний в личном кабинете и где её границы

Изоляция данных компаний в личном кабинете — это набор правил и технических ограничений, при которых пользователь, вошедший от имени одной организации, не может получить доступ к записям другой. Речь не только о видимых разделах, но и о выборках, файлах, уведомлениях, выгрузках и действиях. Если компания A видит заявку компании B, изоляция нарушена, даже если интерфейс выглядит аккуратно, а данные получены через прямой запрос или API.

Границы задачи для этой статьи — клиентские и партнёрские кабинеты на 1С-Битрикс. Мы не рассматриваем Битрикс24, внутренние порталы и корпоративные мессенджеры. Типовой кабинет магазина и индивидуальный сервис различаются: в магазине чаще достаточно разделения заказов и адресов, в сервисе появляются общие справочники, документы, согласования и роли. Поэтому набор функций зависит от редакции и требований, а не гарантируется «из коробки».

Практический результат, к которому ведёт проектирование, — карта данных и матрица проверок. Карта отвечает на вопросы: какая сущность существует, кто её владелец, кто видит, где фильтруется. Матрица фиксирует, какие роли и сценарии проверяются перед запуском. Без этих артефактов изоляция остаётся набором догадок.

Исходные данные и ответственные: что нужно собрать до проектирования

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

Ответственные распределяются так. Бизнес-заказчик описывает правила: кто в компании видит чужие заявки, может ли руководитель делегировать доступ, что считается общим справочником. Аналитик или проектировщик превращает правила в карту данных и матрицу ролей. Разработчик реализует фильтрацию и проверки на сервере. Тестировщик проверяет сценарии по матрице. Администратор кабинета управляет учётными записями и отзывом доступа.

Важно заранее договориться о терминах. «Компания» — это организация или обособленное подразделение? Может ли один пользователь состоять в нескольких компаниях? Если да, нужен переключатель контекста и явное указание активной компании. Если нет, упрощается выборка, но появляется риск, что при смене компании останутся доступны старые данные.

Варианты организации доступа и критерии выбора

Существует несколько подходов. Первый — жёсткая привязка пользователя к одной компании: все запросы фильтруются по её идентификатору. Второй — членство в нескольких компаниях с переключателем. Третий — роли внутри компании: рядовой сотрудник видит только свои объекты, руководитель — объекты подразделения, администратор компании — все объекты организации. Четвёртый — партнёрский доступ, когда внешняя организация видит ограниченный набор данных.

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

Критерии выбора: количество компаний у пользователя, наличие ролей, потребность в общих справочниках, требования к аудиту, готовность редакции продукта. Не обещайте полный набор в любой редакции: часть возможностей может требовать доработки, так как функционал зависит от конфигурации. Требуется проверка фактической поддержки в вашей конфигурации до начала работ.

Предметная последовательность действий: от карты данных до фильтрации

Начните с карты данных. Для каждой сущности укажите владельца: компания, пользователь, подразделение или «общая». Владелец определяет, по какому полю фильтровать. Если владелец — компания, в таблице должен быть идентификатор компании. Если владелец — пользователь, фильтр идёт по пользователю. Для общих справочников фильтрация не нужна, но нужно убедиться, что в них нет приватных полей.

Затем опишите роли. Роль — это набор прав: просмотр, создание, редактирование, удаление, выгрузка. Роли могут быть системными и настраиваемыми. Важно, чтобы права проверялись на сервере, а не только скрывались в интерфейсе. Скрытие кнопки в интерфейсе не защищает данные, так как запрос может быть выполнен напрямую.

Далее определите точки фильтрации. Это списки, карточки, поиск, выгрузки, уведомления, файлы. В каждой точке запрос должен содержать условие по владельцу. Если фильтрация есть только в списке, но отсутствует в карточке, доступ сохранится по прямому адресу (ID). Проверяйте все точки входа.

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

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

Роли и права: как не смешать сотрудника, руководителя и партнёра

Роли внутри компании решают, кто видит больше. Рядовой сотрудник обычно видит только свои объекты. Руководитель — объекты своего подразделения или всей компании. Администратор компании — все объекты и управление пользователями. Партнёр — только те данные, которые ему явно предоставлены.

Смешение ролей опасно. Если руководитель видит заявки другой компании, это нарушение изоляции. Если партнёр получает доступ к внутренним документам, это утечка. Поэтому матрица ролей должна быть явной: роль, объект, действие, условие. Например: «руководитель, заявка, просмотр, только своя компания». Условие проверяется на сервере.

Отдельно продумайте делегирование. Может ли руководитель назначить заместителя? Если да, нужно временное право и его отзыв. Делегирование не должно расширять доступ за пределы компании. Проверьте, что заместитель не видит данные других организаций.

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

Где фильтровать: список, карточка, поиск, выгрузка, уведомления

Фильтрация должна быть сквозной. Список — первое место, но не единственное. Карточка открывается по идентификатору, поэтому при загрузке нужно проверить, принадлежит ли объект компании пользователя. Если проверки нет, доступ по прямому адресу сохранится.

Поиск также требует фильтрации. Если поиск ищет по всем записям, пользователь может найти чужую заявку. Уведомления должны формироваться только для получателя. Выгрузки и отчёты должны содержать только доступные данные. Файлы, отдаваемые сервером, проверяются на принадлежность компании.

Отдельная точка — API и внешние интеграции. Если кабинет обменивается данными с другими системами, убедитесь, что интеграция не обходит фильтры. Например, синхронизация может забирать все заявки, а не только по компании. Это нужно проверять.

Кеширование тоже влияет. Если список закеширован для одной компании, другая компания может увидеть его. Настройте кеш с учётом компании или отключите для чувствительных данных.

Матрица проверок доступа по ролям: как составить и использовать

Матрица проверок — это таблица, где строки — роли и сценарии, столбцы — ожидаемый результат. Она помогает тестировщику и заказчику убедиться, что изоляция работает. Составьте её до начала тестирования.

Пример строк: «сотрудник компании A открывает заявку компании B — доступ запрещён», «руководитель компании A видит список заявок компании A — доступ разрешён», «партнёр видит счёт клиента — доступ разрешён только для своих клиентов». Каждый сценарий должен иметь ожидаемый результат и способ проверки.

Матрица не заменяет автоматические тесты, но задаёт их основу. Если сценариев много, сгруппируйте их по сущностям. Важно проверять не только запреты, но и разрешения: пользователь должен видеть то, что ему положено, иначе изоляция превратится в блокировку работы.

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

Учебный пример: компания с двумя юрлицами и партнёрским доступом

Учебный пример. Компания «Альфа» имеет два юрлица: «Альфа-1» и «Альфа-2». В каждом есть руководитель и сотрудники. Партнёр «Бета» должен видеть статусы заявок «Альфа-1», но не «Альфа-2». В кабинете на 1С-Битрикс есть общий справочник товаров, заявки, документы и уведомления. Пример иллюстративный и не заменяет проектную документацию.

Входные условия: пользователь Иванов состоит в «Альфа-1» и «Альфа-2», активная компания — «Альфа-1». Партнёр Петров имеет доступ только к «Альфа-1». Сотрудник Сидоров — только в «Альфа-1».

Действия: Иванов переключается на «Альфа-2» и открывает список заявок. Система должна показать только заявки «Альфа-2». Петров открывает список заявок: видит только заявки «Альфа-1». Сидоров (сотрудник «Альфа-1») пытается открыть заявку «Альфа-2» по прямому адресу — доступ запрещён.

Наблюдаемый результат: списки и карточки соответствуют активной компании и роли. Уведомления приходят только участникам. Выгрузка содержит только доступные заявки. Если какой-то пункт не выполняется, изоляция нарушена.

Проверка: тестировщик проходит по матрице. Для каждой роли и сценария фиксируется результат. Ошибки описываются с шагами воспроизведения. После исправления проверка повторяется.

Чек-лист приёмки изоляции данных компаний

• Определены владельцы всех сущностей: компания, пользователь, подразделение или общая.
• Для каждой сущности указано поле фильтрации и проверено его наличие в запросах.
• Роли описаны и проверены на сервере, а не только в интерфейсе.
• Списки, карточки, поиск, выгрузки и уведомления фильтруются по владельцу.
• Переключатель компаний (если есть) обновляет контекст и не оставляет старые данные.
• Партнёрский доступ ограничен явно предоставленными данными.
• Отзыв доступа прекращает сессии и блокирует получение данных.
• Кеширование учитывает компанию или отключено для чувствительных данных.
• Матрица проверок пройдена для всех ролей и сценариев.
• Зафиксированы ограничения и известные ошибки.

Ограничения, типичные ошибки и следующий шаг

Ограничения. Не любая редакция 1С-Битрикс поддерживает нужный набор ролей и фильтрацию «из коробки». Часть требований может потребовать доработки. Юридические и персональные данные требуют отдельной проверки профильным специалистом; статья не заменяет юридическое заключение. Не обещайте полный набор функций без проверки конфигурации. Учебные условия не заменяют права покупателя.

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

Следующий шаг — составить карту данных и матрицу проверок для вашего кабинета. Если нужна помощь в проектировании и реализации, обратитесь к разработке личных кабинетов на 1С-Битрикс. Дополнительно можно изучить проектирование, роли и приёмку личного кабинета на корпоративном сайте и особенности B2B-кабинета: остатки, цены и повторные заказы.

Как проверить, что фильтрация работает на всех уровнях доступа

Даже если в списках заявок и документов настроена фильтрация по компании, доступ может остаться через другие точки. Проверку стоит строить не по разделам интерфейса, а по способам получения данных. Начните с прямых адресов: если карточка заявки открывается по идентификатору, при загрузке нужно убедиться, что объект принадлежит компании текущего пользователя. Отсутствие такой проверки — одна из частых причин утечки, потому что список может быть отфильтрован, а карточка — нет.

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

Кеширование — ещё одна точка, где изоляция может нарушиться. Если список закеширован для одной компании, другая компания может увидеть его. Настройте кеш с учётом компании или отключите его для чувствительных данных. Проверка кеша требует отдельного сценария: войдите под пользователем одной компании, откройте список, затем под пользователем другой компании откройте тот же список и убедитесь, что данные различаются.

Проверка файлов и вложений

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

Проверка действий, а не только просмотра

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

Развилки при проектировании: общие справочники, подразделения и делегирование

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

Подразделения внутри компании добавляют ещё один уровень. Если сотрудники делятся по отделам, руководитель отдела видит только свои заявки, а руководитель компании — все. Здесь важно не смешать подразделение и компанию: фильтр по подразделению не должен открывать доступ к данным другого подразделения той же компании, если это не предусмотрено. Проверьте, что при смене подразделения пользователь теряет доступ к старым объектам, если они ему больше не положены.

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

Развилка: один пользователь в нескольких компаниях

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

Развилка: партнёрский доступ

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

Отзыв доступа и завершение сессий: что проверить

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

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

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

Проверка отзыва доступа

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

Ограничения и условия проверки

Не любая редакция 1С-Битрикс поддерживает нужный набор ролей и фильтрацию без доработки. Проверьте фактическую поддержку в вашей конфигурации до начала работ. Если функция не подтверждена, опишите способ проверки: запросите у разработчика или администратора демонстрацию на тестовом стенде. Юридические и персональные данные требуют отдельной проверки профильным специалистом; статья не заменяет юридическое заключение. Не обещайте полный набор функций без проверки конфигурации.