Журнал PC Magazine/RE №11/2011

Наконец, в некоторых задачах «суперпользователю» (предприятию-владельцу информационного пространства) требуется работать со всей совокупностью данных как с единым целым, например, расчетному центру, как минимум, нужно формировать консолидированную отчетность. Реализация такого требования влечет за собой как интенсивный обмен данными между узлами РИБ (что опять же означает дополнительную нагрузку на оборудование), так и дублирование данных не менее чем в двух разных базах.

Более сложное, но конструктивно более правильное решение – работать с единой информационной базой, а для изоляции «персональных областей данных пользователей» друг от друга использовать механизм RLS (Record Level Security, доступ на уровне записей). Преимущества этого решения зеркально повторяют недостатки первого:

1. Администрировать и поддерживать нужно только одну информационную базу.

2. Все регламентные процедуры выполняются только в одной информационной базе, не создавая лишней нагрузки на оборудование.

3. Общие данные не дублируются и всегда актуальны для всех пользователей.

4. Для «консолидированных» операций над полной совокупностью данных не требуется выполнять постоянную синхронизацию, и данные не дублируются.

При этом пользователи-абоненты имеют доступ только к «своим» данным и могут даже не подозревать о наличии в системе данных других пользователей. Такая архитектура называется «multitenancy» (множественная аренда) – единый экземпляр прикладного решения обслуживает множество независимых абонентов.

Собственно, именно такую архитектуру и обеспечивает новый механизм разделения данных, реализованный в версии 8.2.14 «1С: Предприятия». В чем же заключается принципиальная разница? Принципиальная разница – в технической реализации разграничения доступа.

Механизм RLS в «1С: Предприятии» работает следующим образом: для совокупности сущностей «объект метаданных, роль, право доступа» разработчик конфигурации описывает дополнительные ограничения доступа к данным. Ограничения описываются на языке запросов и могут представлять собой довольно сложные конструкции. При работе пользователя с объектами данных информационной базы стандартные запросы, выполняемые платформой в СУБД, дополняются запросами RLS. Например, если в RLS задано ограничение «роль Кладовщик имеет право чтения документа Накладная только в том случае, если пользователь прикреплен к нужному складу», в любой запрос СУБД, выполняющий чтение соответствующих таблиц, будет добавляться соответствующее условие.

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

Настройка разделителя данных