При разработке систем на базе 1С:ERP часто возникает задача разграничения доступа к персональным данным. Типичный сценарий: пользователю необходимо оставить возможность выбирать физическое лицо в документах и видеть его ФИО, но при этом скрыть конфиденциальную информацию, такую как ИНН, паспортные данные или адрес проживания. Однако при настройке ролей в расширении разработчики часто сталкиваются с ситуацией, когда, несмотря на отсутствие галочек на «секретных» реквизитах, пользователь все равно видит все данные. В этой статье мы подробно разберем, почему так происходит и какими способами можно добиться корректного ограничения прав.
Прежде всего, проанализируем базовый принцип работы системы прав в 1С, для чего может быть полезна обработка для быстрой проверки прав доступа на объекты метаданных. Важно помнить, что в платформе реализован принцип аддитивности (суммирования) прав. Если у пользователя назначено несколько ролей, то итоговое право вычисляется по логическому оператору «ИЛИ». Это означает, что если хотя бы одна роль (из основной конфигурации или из любого расширения) дает право на просмотр реквизита, то расширение не сможет «запретить» это действие. Поэтому важно провести детальный анализ прав доступа к конкретному объекту. Если вы создаете роль в расширении для ограничения доступа, сначала убедитесь, что в основной конфигурации у пользователя нет ролей типа ПолныеПрава или специализированных ролей для чтения НСИ. Помочь в этом может инструмент для просмотра ролей для объекта, которые уже открывают доступ к справочнику ФизическиеЛица.
Одной из самых распространенных причин, по которой пользователь видит лишние данные, является каскадное наследование прав. Рассмотрим, как это работает по умолчанию. Когда мы даем право Чтение или Просмотр на весь справочник, платформа автоматически применяет эти права ко всем его реквизитам, табличным частям и их атрибутам.
Чтобы разорвать эту связь и настроить права точечно, выполним следующие шаги:
Справочник.ФизическиеЛица.Просмотр на сам справочник и на реквизит Наименование, но снять его с реквизитов ИНН или ДатаРождения.Важный нюанс: Если этот флаг снят, то наличие права на объект метаданных автоматически открывает доступ ко всему его содержимому. Это фундаментальное правило настройки безопасности в 1С.
Разберем ситуацию, когда пользователю необходим механизм «Ввода по строке» для быстрого подбора физических лиц в документах. Проанализируем техническую сторону: для того чтобы платформа могла выполнять поиск и предлагать варианты в выпадающем списке, ей требуется право Просмотр на уровне всего справочника. Если мы оставим только право Чтение, механизм ввода по строке перестанет работать, так как он завязан на интерактивные возможности интерфейса.
Однако здесь кроется ловушка: как только мы включаем Просмотр для справочника (даже с включенными независимыми правами), система должна сформировать представление объекта. Если в свойство «Основное представление» справочника или в поля ввода по строке включены данные, к которым мы закрыли доступ, это может вызвать конфликты. Подобные сложности часто возникают, когда требуется ограничение прав в отчетах и списках СКД, что приводит к неожиданному отображению пустых строк.
Если настройки интерфейса недостаточно, рассмотрим более надежный метод — RLS (Record Level Security) на уровне полей. Начиная с современных версий платформы 8.3, мы можем настраивать ограничения не только на целые строки (записи), но и на конкретные колонки.
В конструкторе ограничений прав доступа для роли в расширении можно прописать условие для права Чтение. Если поле (например, ИНН) не будет включено в список разрешенных полей в шаблоне RLS, то при попытке обращения к нему (через консоль отчетов, программно или в списке) система вернет NULL. Это «железный» способ защиты данных, который не зависит от того, скрыто ли поле на форме или нет.
В случаях, когда права настроить сложно из-за их пересечения в основной конфигурации, мы можем прибегнуть к программному методу в расширении. Это менее безопасно (данные все еще можно будет вытащить через отчеты), но эффективно для настройки интерфейса.
Разберем пример кода, который можно разместить в расширении формы справочника или документа в процедуре ПриСозданииНаСервере:
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверяем наличие специальной роли, созданной в расширении
Если Не РольДоступна("Расш1_ЧтениеПерсональныхДанныхФЛ") Тогда
// Скрываем элементы формы, содержащие конфиденциальную информацию
ЭлементИНН = Автофигура.Найти("ИНН"); // Или поиск по имени элемента
Если ЭлементИНН <> Неопределено Тогда
ЭлементИНН.Видимость = Ложь;
КонецЕсли;
// Аналогично для других полей
Попытка
Элементы.ГруппаПаспортныеДанные.Видимость = Ложь;
Исключение
// Обработка случая, если элемент на форме отсутствует
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Использование метода РольДоступна() позволяет гибко управлять видимостью элементов. Однако помните, что для полной уверенности в сохранности данных этот метод должен сочетаться с настройкой прав в роли, как было описано в Решении 1.
Проанализируем, почему изменения могут не вступать в силу немедленно:
Таким образом, для корректной работы ограничения доступа к реквизитам через расширение, мы рекомендуем использовать комбинацию настройки «Независимые права подчиненных объектов» и проверку на отсутствие дублирующих прав в основной конфигурации. Это обеспечит работоспособность «Ввода по строке» при сохранении конфиденциальности данных.