Почему контактную информацию в БСП перенесли в табличные части и как теперь ограничить к ней доступ?

← На главную

Переход подсистемы «Контактная информация» (КИ) в Библиотеке стандартных подсистем (БСП) с единого регистра сведений на табличные части объектов-владельцев вызвал немало вопросов в сообществе разработчиков 1С. Главное опасение программистов и архитекторов связано с безопасностью: если раньше доступ к контактным данным легко разграничивался на уровне записей (RLS) в одном регистре, то теперь контактная информация хранится непосредственно в табличных частях справочников. Как известно, механизм RLS на уровне платформы 1С не умеет ограничивать доступ к отдельным строкам табличных частей.

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

Часть 1. Почему «1С» отказалась от общего регистра сведений?

На первый взгляд, хранение контактной информации в едином регистре сведений казалось идеальным решением. Однако по мере роста масштабов внедрений и объемов баз данных в крупных конфигурациях (1С:ERP, 1С:Управление торговлей, 1С:Комплексная автоматизация) эта схема начала приводить к серьезным техническим проблемам.

Проанализируем ключевые причины, из-за которых было принято решение перенести КИ в табличные части:

Оптимизация производительности СУБД (избавление от составных типов данных). В старой архитектуре регистр сведений имел ключевое измерение Объект с составным типом, который включал десятки справочников (Контрагенты, Физические лица, Организации, Пользователи, Партнеры и т.д.). На уровне СУБД (MS SQL Server, PostgreSQL) индексы по полям с составными типами работают крайне неэффективно. При поиске и выборке контактных данных СУБД приходилось выполнять сложные соединения таблиц, что вызывало существенную деградацию производительности. Перенос КИ в табличные части конкретных справочников полностью устранил составные типы в индексах этой информации.
Борьба с транзакционными блокировками. При использовании одного общего регистра КИ любая запись контактных данных (например, при массовой загрузке контрагентов или обновлении информации о клиентах) накладывала транзакционную блокировку на таблицы регистра. В высоконагруженных многопользовательских системах это регулярно вызывало конфликты блокировок и взаимные блокировки (deadlocks) между пользователями, работающими с совершенно разными разделами учета. Использование табличных частей изолирует блокировки исключительно на уровне конкретного изменяемого элемента справочника.
Целостность данных и их жизненный цикл. В схеме с регистром сведений при программном удалении контрагента или физического лица записи в регистре контактной информации часто оставались «сиротами», засоряя базу данных неактуальным мусором. С табличными частями очистка КИ происходит автоматически «под капотом» СУБД при удалении самого элемента справочника.
Упрощение обмена данными. Поскольку контактная информация теперь физически находится внутри самого объекта-владельца, ее сериализация и десериализация при интеграциях (через XML, JSON, EnterpriseData или стандартные планы обмена) стали тривиальными. Отпала необходимость настраивать сопутствующие правила регистрации изменений для стороннего регистра сведений.
Наследование базовых прав доступа. Контактная информация — это неотъемлемая часть самого объекта. Если пользователю разрешено читать данные контрагента, он должен автоматически видеть и его контакты. Это избавило от необходимости дублировать и усложнять стандартные настройки прав.

Часть 2. Проблема конфиденциальности данных и RLS в табличных частях

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

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

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

Часть 3. Практические способы ограничения доступа к КИ в табличных частях

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

Шаг 1. Разделение данных на уровне архитектуры

Самое главное правило при проектировании систем на БСП — чувствительная информация не должна храниться в подсистеме контактной информации. Критически важные персональные данные (паспортные данные, СНИЛС, военные билеты, банковские счета) категорически запрещено записывать в КИ.

В типовых конфигурациях (например, 1С:ЗУП 3.1) для паспортных данных используется специализированный регистр сведений ДокументыФизическихЛиц. Права на чтение этого регистра жестко ограничены специализированными ролями, а доступ к нему контролируется стандартным RLS:


#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляРегистра("ИдентификаторыОбъектовМетаданных.РегистрСведенийДокументыФизическихЛиц", "Физлицо", "", "", "", "")
#Иначе
#ПоЗначениям( "РегистрСведений.ДокументыФизическихЛиц","Чтение","",
"ГруппыФизическихЛиц","Физлицо",
"","","","", "","","","","", "","","","","", "","","","","", "","","","","", "","","","","" )
#КонецЕсли

Если вам требуется ограничить доступ к конфиденциальным сведениям, сначала проверьте, правильно ли выбрано место для их хранения. Все, что касается документов и удостоверений личности, выносите в отдельные регистры сведений с настроенным RLS.

Шаг 2. Ограничение доступа через справочник «Виды контактной информации»

Для разделения прав на обычные виды КИ (например, «Личный телефон» и «Служебный телефон») в БСП предусмотрена возможность настройки прав доступа на уровне справочника ВидыКонтактнойИнформации. Если у пользователя нет прав на чтение определенного вида КИ, система не позволит ему получить эти данные.

Рассмотрим, как настроить RLS для справочника ВидыКонтактнойИнформации. Вы можете ограничить чтение элементов этого справочника по группам доступа или ролям. Если пользователь не может прочесть сам элемент вида КИ, то и связанные с ним строки в табличной части справочника-владельца не будут отображаться в интерфейсе, так как система не сможет сопоставить идентификатор вида контактной информации.

Шаг 3. Программная фильтрация данных на уровне управляемых форм

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

Проанализируем пример программного скрытия личных контактов сотрудников на форме элемента справочника ФизическиеЛица. Мы можем перехватить процедуру ПриСозданииНаСервере и скрыть конфиденциальные строки табличной части в зависимости от ролей пользователя.

Рассмотрим пример кода для расширения формы:


&После("ПриСозданииНаСервере")
Процедура Расш_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Проверим, обладает ли текущий пользователь правами на просмотр личных контактов
    Если Не РольДоступна("ПросмотрЛичныхКонтактныхДанных") Тогда
        
        // Адрес объекта на форме обычно связан с реквизитом "Объект"
        ТабличнаяЧастьКИ = Объект.КонтактнаяИнформация;
        
        // Массив строк, которые необходимо удалить из отображения на форме
        СтрокиДляУдаления = Новый Массив;
        
        Для Каждого СтрокаКИ Из ТабличнаяЧастьКИ Цикл
            // Определяем конфиденциальные виды контактной информации
            Если СтрокаКИ.Вид = Справочники.ВидыКонтактнойИнформации.ЛичныйТелефонФизическиеЛица 
               Или СтрокаКИ.Вид = Справочники.ВидыКонтактнойИнформации.АдресМестаПроживанияФизическиеЛица Тогда
                
                СтрокиДляУдаления.Добавить(СтрокаКИ);
            КонецЕсли;
        КонецЦикла;
        
        // Удаляем строки из коллекции формы, чтобы пользователь не увидел их в интерфейсе
        Для Каждого СтрокаИз КИ Из СтрокиДляУдаления Цикл
            ТабличнаяЧастьКИ.Удалить(СтрокаИзКИ);
        КонецЦикла;
        
    КонецЕсли;
    
КонецПроцедуры

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

Шаг 4. Ограничение вывода данных в отчетах через СКД

При построении отчетов, выводящих контактную информацию, используйте механизм ограничения доступа к полям на уровне Системы компоновки данных (СКД). В схеме компоновки данных вы можете настроить условное оформление или ограничить доступность полей КИ для определенных ролей пользователей на вкладке «Права» схемы компоновки, либо программно модифицировать состав выводимых полей перед компоновкой результата.

Резюме

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

Для реализации разграничения доступа к КИ в современных конфигурациях 1С используйте правильное разделение данных (не храните паспорта в КИ), настраивайте RLS для справочника ВидыКонтактнойИнформации и внедряйте программную фильтрацию строк в формах через расширения конфигурации.