Как скрыть данные об окладах в 1С:ЗУП и реализовать доступ по паролю?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом Управленческий учет
← На главную

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

Метод 1. Ограничение доступа на уровне записей и полей (RLS)

Прежде чем приступать к написанию сложного кода с паролями, проанализируем возможности механизма Row Level Security (RLS). Это штатный инструмент платформы «1С:Предприятие 8.3», который позволяет гибко настраивать права доступа. В конфигураторе мы можем определить роль, которая запрещает чтение конкретного поля Оклад в справочниках и регистрах.

Рассмотрим по шагам, как работает этот механизм:

  1. В конфигурации определяются объекты, содержащие данные об окладах (например, регистр сведений ПлановыеНачисления).
  2. Для выбранной роли настраивается ограничение доступа, где для поля Размер (или аналогичного) прописывается условие «Ложь» или проверяется принадлежность пользователя к определенной группе.
  3. В результате, когда пользователь без соответствующих прав открывает отчет или форму, система вместо числа выводит сообщение «Объект не найден» или оставляет поле пустым.

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

Метод 2. Использование расширений для динамического маскирования данных

Запрос пользователя «видеть нечто, а при пароле — данные» лучше всего реализуется через расширения конфигурации. Это позволяет не снимать основную программу с поддержки. Проанализируем ситуацию: нам нужно перехватить вывод данных на экран.

Разберем алгоритм реализации:

  1. Создаем расширение и заимствуем форму документа или справочника, где отображается оклад.
  2. Добавляем на форму реквизит типа Булево, например, ДоступОткрыт, и кнопку «Показать оклады».
  3. В событии ПриЧтенииНаСервере или ПриСозданииНаСервере прописываем логику, которая скрывает данные, если флаг доступа не установлен.

Рассмотрим пример кода для управления видимостью элементов формы:


&НаСервере
Процедура Расш1_ПриЧтенииНаСервереПосле(ТекущийОбъект)
    Элементы.Оклад.Видимость = Ложь; // По умолчанию скрываем
    Элементы.Оклад.ТекстЗаполнитель = "***";
КонецПроцедуры

&НаКлиенте
Процедура Расш1_КомандаПоказатьОклады(Команда)
    Пароль = "";
    Если ВвестиЗначение(Пароль, "Введите пароль для просмотра окладов", "Строка") Тогда
        Если ПроверитьПарольНаСервере(Пароль) Тогда
            Элементы.Оклад.Видимость = Истина;
        Иначе
            Сообщить("Неверный пароль!");
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

В данном примере мы используем метод ВвестиЗначение для вызова диалогового окна. Функция ПроверитьПарольНаСервере должна сравнивать хэш введенного текста с эталоном, хранящимся в защищенных константах или дополнительных сведениях пользователя.

Метод 3. Проблема целостности данных в отчетах

Выясним причину, по которой простое «зануление» оклада в отчетах считается плохой практикой. Если мы просто подменим число на 0 для «стесняющегося» сотрудника, то итоги по подразделению в расчетной ведомости станут неверными. Опытный бухгалтер или аналитик легко вычислит скрытый оклад, вычтя известные суммы из общего итога.

Чтобы избежать этой проблемы, рекомендуется использовать один из двух подходов:

Метод 4. Криптография и «Запароленный ZIP»

Рассмотрим более экзотический, но надежный способ, упомянутый в обсуждении — хранение данных в зашифрованном виде. Платформа 1С поддерживает работу с объектом МенеджерКриптографии.

Посмотрим на пример логики работы:

  1. Данные об окладах при записи шифруются с использованием сертификата или ключа.
  2. В базе данных вместо числа хранится бинарный объект в поле типа ХранилищеЗначения.
  3. Для расшифровки система требует от пользователя закрытый ключ или ввод пароля, который инициирует процедуру дешифрации в оперативной памяти сервера.

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

Метод 5. Административные меры и 152-ФЗ

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

Проанализируем преимущества этого подхода:

Метод 6. Архитектурное разделение (ЗУП КОРП)

Если безопасность данных является критическим приоритетом, рассмотрим стратегию разделения баз. В версии ЗУП КОРП предусмотрена возможность вести кадровый учет в одной базе, а расчет зарплаты — в другой. Кадровики работают с должностями и штатным расписанием, не видя реальных начислений, премий и надбавок, которые рассчитываются в «закрытом контуре» расчетчиками зарплаты.

Резюме по реализации

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

← На главную