← На главную

Ограничение доступа по организациям является одной из ключевых задач при внедрении и эксплуатации систем класса ERP. Это необходимо для обеспечения конфиденциальности данных, разграничения полномочий сотрудников и правильного ведения учета. Рассмотрим различные подходы к решению этой задачи в 1С ERP, анализируя их преимущества, недостатки и сценарии применения.

RLS (Record Level Security – Ограничение доступа на уровне записей)

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

Производительность RLS: Часто высказывается мнение о замедлении работы системы при использовании RLS. Однако, современные версии платформы 1С (начиная с 8.3.10 и далее) и Библиотеки стандартных подсистем (БСП) включают значительные оптимизации этого механизма. Разработчики заявляют о существенном ускорении, вплоть до 100 раз в отдельных случаях, что делает RLS вполне пригодным для использования. В некоторых сценариях, RLS может даже улучшать производительность за счет уменьшения объема выбираемых данных, так как запросы формируются с учетом прав пользователя, выбирая только разрешенные записи.

Оптимизация RLS для минимизации влияния на производительность:

1. Минимизация шаблонов RLS: Используйте как можно меньше шаблонов для каждого объекта. Избыточное количество шаблонов усложняет анализ запросов платформой.
2. Простые условия в шаблонах: Избегайте сложных вложенных запросов, функций и обращений к большому количеству таблиц в условиях RLS. Чем проще условие, тем быстрее оно будет выполняться.
3. Индексы в базе данных: Убедитесь в наличии необходимых индексов для полей, участвующих в условиях RLS. Отсутствие индексов приводит к полному сканированию таблиц, что критически замедляет работу.
4. Консолидация настроек: Вместо создания множества мелких ролей с дублирующимися ограничениями, старайтесь создавать более обобщенные роли, объединяющие общие права и ограничения.
5. Использование профилей групп доступа: Это помогает централизованно управлять правами и RLS, упрощая администрирование и снижая вероятность ошибок.
6. Актуальные версии платформы и БСП: Регулярные обновления платформы и БСП часто содержат улучшения производительности RLS и исправления ошибок.

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

Разделение данных (разделитель данных)

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

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

Сценарии использования: Этот механизм идеально подходит для облачных сервисов (SaaS), где множество клиентов работают в одной базе, но их данные должны быть полностью изолированы друг от друга, как будто они работают в разных базах.

Преимущества: Главное преимущество – высокая производительность. Условия разделения данных встраиваются платформой на низком уровне, что часто происходит гораздо эффективнее, чем при использовании RLS.

Ограничения и нюансы:

1. Общая НСИ: Если вам необходима общая нормативно-справочная информация (НСИ) для всех организаций, разделение данных может потребовать дополнительных усилий или быть неподходящим, так как оно стремится к полной изоляции. Хотя существуют механизмы, позволяющие выборочно использовать общие справочники даже при включенном разделении, их реализация может быть сложной.
2. Включение и отключение: Включение разделения данных – это серьезное изменение в структуре информационной базы, требующее ее перестройки. Отключить этот механизм без потери данных или сложных манипуляций крайне проблематично, поэтому решение о его использовании должно быть тщательно взвешено.
3. Совместимость и стабильность: Проблемы, упомянутые в старых обсуждениях (например, в 2014 году для 8.3.4), связанные с запросами к виртуальным таблицам, вытеснением и записью в независимые регистры сведений, скорее всего, были связаны с ранними реализациями механизма. В современных версиях платформы (8.3.20+ и выше) и БСП этот механизм значительно доработан, стал стабильнее и является мощным решением для задач мультиарендности.

Распределенная информационная база (РИБ)

РИБ – это механизм обмена данными между несколькими информационными базами. Каждая база в структуре РИБ является полноценной и может работать автономно.

Принцип работы: Обычно создается центральная база (ЦБ) и одна или несколько периферийных баз (ПБ). Обмен данными происходит по определенным правилам, настроенным в конфигурации, что позволяет синхронизировать только необходимые изменения. Например, филиал видит только свои документы и справочники, но при этом данные из филиала отправляются в ЦБ для консолидации.

Сценарии использования: РИБ хорошо подходит, когда филиалы или обособленные подразделения компании работают независимо друг от друга, возможно, в разных географических точках или с ограниченным доступом к центральному серверу. Центральный офис при этом собирает и анализирует консолидированные данные со всех периферийных баз. РИБ также может быть вариантом, когда требуется максимальная изоляция данных по организациям на уровне физической базы данных.

Преимущества:

1. Высокая степень изоляции данных: Каждая периферийная база содержит только свои данные, что обеспечивает высокий уровень безопасности и конфиденциальности.
2. Автономная работа: Филиалы могут работать независимо, даже при отсутствии связи с центральной базой.
3. Потенциально лучшая производительность: Периферийные базы работают с меньшим объемом данных, что может повысить их производительность для локальных пользователей.
4. Снижение нагрузки на центральный сервер: Основная часть оперативной работы распределяется между периферийными узлами.

Недостатки:

1. Сложность администрирования: Необходимо поддерживать и управлять несколькими информационными базами, следить за состоянием обмена, решать вопросы с коллизиями.
2. Задержки в получении актуальных данных: Актуальность данных в центральной базе зависит от частоты обмена с периферийными узлами. Это может быть критично для оперативного анализа.
3. Потенциальные коллизии: При параллельной работе с одними и теми же объектами в разных узлах могут возникать коллизии, которые требуют ручного разрешения.
4. Требования к инфраструктуре: Каждая база требует своего места для хранения и ресурсов.

Самописные механизмы ограничения доступа (собственный код)

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

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

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

Преимущества:

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

Недостатки:

1. Высокие затраты на разработку: Создание, отладка и поддержка такого механизма требует значительных временных и финансовых ресурсов.
2. Риск ошибок безопасности: Собственная реализация увеличивает риск допущения ошибок в логике безопасности, что может привести к несанкционированному доступу к данным.
3. Сложность обновления конфигурации: При обновлении типовой конфигурации придется вручную переносить и адаптировать все самописные проверки.
4. Потенциальное снижение производительности: Если самописный механизм реализован неоптимально, он может оказаться даже медленнее, чем правильно настроенный RLS. Каждая проверка в коде требует ресурсов.
5. Дублирование логики: Придется следить за тем, чтобы проверки были реализованы во всех необходимых местах (формах, отчетах, движениях документов), что очень трудоемко.

Консолидация для отчетов

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

Принцип работы: В этом случае основная база данных может иметь строгие ограничения доступа для большинства пользователей (например, через RLS или другие методы), но для руководителей или для целей аналитики данные собираются в отдельную базу или в специализированные хранилища. Мы можем создать специальные самописные данные, куда в плоском виде записываются агрегированные или преобразованные данные для отчетов. Это может быть реализовано через выгрузки из центральной базы в отдельные периферийные базы, предназначенные исключительно для аналитики, или в специальные регистры сведений внутри той же базы.

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

Преимущества:

1. Отчеты работают очень быстро: Поскольку данные заранее подготовлены, агрегированы и оптимизированы для отчетности, отчеты могут строиться буквально "пулей".
2. Не затрагивает производительность оперативной работы: Механизмы подготовки данных для отчетности работают асинхронно и не влияют на производительность повседневной работы пользователей в основной базе.
3. Гибкость: Мы можем создавать любые структуры данных, оптимальные для конкретных отчетов.

Недостатки:

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

Таким образом, выбор метода ограничения доступа по организациям в 1С ERP зависит от конкретных требований к безопасности, производительности, сложности структуры компании и потребностей в отчетности. Мы рекомендуем в первую очередь рассмотреть RLS, активно используя современные методы его оптимизации и актуальные версии платформы. Если требуется полная изоляция данных для каждой организации и нет сложной общей НСИ, то механизм разделения данных является мощным и производительным решением. РИБ подходит для распределенных структур с автономными филиалами, а самописные решения и консолидация для отчетов — для более специфических случаев.