В крупных организациях вопрос конфиденциальности данных о заработной плате стоит очень остро. Часто возникает ситуация, когда службе безопасности или руководству необходимо выяснить, кто из расчетчиков или кадровиков «любопытствовал» и просматривал доходы конкретного сотрудника. Стандартный Журнал регистрации 1С фиксирует только общие события (открытие форм, изменение объектов), но не дает ответа на вопрос: «Какие именно параметры фильтров установил пользователь в отчете?». Рассмотрим подробнее, как решить эту задачу с помощью встроенных механизмов системы и программной доработки.
Прежде чем приступать к разработке собственных расширений, проанализируем возможности системы, предоставляемые Библиотекой стандартных подсистем (БСП). В конфигурации 1С:ЗУП 3.1 реализован механизм, соответствующий требованиям 152-ФЗ «О персональных данных».
Для активации этого механизма выполним следующие шаги:
После этого система начнет записывать в Журнал регистрации события типа Доступ к данным. Разберем ситуацию: если пользователь откроет карточку сотрудника или документ «Начисление зарплаты и взносов», в журнале появится запись. Однако у этого метода есть существенный минус — он фиксирует факт работы с объектом, но не всегда детализирует формирование сложных отчетов, где данные выводятся списком по всему подразделению.
В вопросе упоминалась Панель истории, которая отображает последние действия пользователя. Выясним, можно ли использовать эти данные для аудита. Данные истории хранятся в системном хранилище настроек. Программно к ним можно обратиться через объект ИсторияРаботыПользователя.
Посмотрим на пример кода, который позволяет получить последние записи истории:
ВыборкаИстории = ИсторияРаботыПользователя.Получить();
Для Каждого Запись Из ВыборкаИстории Цикл
Сообщить("Дата: " + Запись.Дата + ", Метаданные: " + Запись.Данные);
КонецЦикла;
Проанализируем ситуацию: данный метод покажет нам, что пользователь открывал форму отчета «Анализ зарплаты по сотрудникам», но он не сохраняет значения отборов, которые были применены. Мы увидим факт запуска отчета, но не узнаем, чью именно фамилию пользователь ввел в поле фильтра. Таким образом, стандартная история полезна только для общего понимания активности, но не для точного аудита просмотра зарплаты конкретного лица.
Наиболее эффективным решением, как было предложено в обсуждении, является создание собственного регистра сведений для логирования. Почти все отчеты в 1С:ЗУП 3.1 построены на Системе компоновки данных (СКД). Нам нужно перехватить момент формирования отчета и считать установленные пользователем настройки.
Разберем по шагам создание такой системы контроля через расширение:
ЛогПросмотраОтчетов) с измерениями: Пользователь, Отчет, Дата и ресурсом ПараметрыОтборов (строка или хранилище значений).ПриКомпоновкеРезультата. Это ключевое событие, которое происходит в момент нажатия кнопки «Сформировать».Рассмотрим пример кода в расширении для перехвата данных:
&После("ПриКомпоновкеРезультата")
Процедура Лог_ПриКомпоновкеРезультата(РезультатТабличныйДокумент, ДанныеРасшифровки, СтандартнаяОбработка)
Настройки = КомпоновщикНастроек.ПолучитьНастройки();
ТекстОтборов = "";
// Обходим все установленные отборы
Для Каждого ЭлементОтбора Из Настройки.Отбор.Элементы Цикл
Если ЭлементОтбора.Использование И ТипЗнч(ЭлементОтбора.ЛевоеЗначение) = Тип("ПолеКомпоновкиДанных") Тогда
ТекстОтборов = ТекстОтборов + Строка(ЭлементОтбора.ЛевоеЗначение) + " = " + Строка(ЭлементОтбора.ПравоеЗначение) + "; ";
КонецЕсли;
КонецЦикла;
// Записываем данные в наш регистр
ЗаписьЛога = РегистрыСведений.ЛогПросмотраОтчетов.СоздатьМенеджерЗаписи();
ЗаписьЛога.Период = ТекущаяДата();
ЗаписьЛога.Пользователь = Пользователи.ТекущийПользователь();
ЗаписьЛога.Отчет = ЭтотОбъект.Метаданные().Имя;
ЗаписьЛога.ПараметрыОтборов = ТекстОтборов;
ЗаписьЛога.Записать();
КонецПроцедуры
В данном примере мы программно извлекаем коллекцию Настройки.Отбор.Элементы. Если пользователь выбрал в отчете конкретного сотрудника, его ФИО попадет в переменную ТекстОтборов и будет сохранено в базе данных. Теперь у администратора будет четкая картина: кто, когда и по кому формировал отчеты.
Иногда лучшим решением является не аудит «постфактум», а предотвращение несанкционированного доступа. В ЗУП 3.1 механизм RLS (Record Level Security) позволяет разграничить доступ к данным сотрудников по группам доступа.
Проанализируем этот подход: если мы создадим группы доступа и привяжем расчетчиков только к их подразделениям, они физически не смогут сформировать отчет по сотрудникам «чужих» отделов (например, администрации). В этом случае отчет просто выведет пустой результат или ошибку доступа. Это снимает необходимость в тотальной слежке, так как права доступа изначально ограничивают круг видимых лиц.
В сообщениях форума упоминался радикальный метод — «вывод сотрудника из общей базы». Это актуально для топ-менеджмента. Суть заключается в том, что расчет зарплаты по руководству ведется в отдельной информационной базе, к которой имеет доступ только главный бухгалтер или доверенное лицо. В общую базу ЗУП, к которой имеют доступ рядовые расчетчики, данные попадают только в виде сводных проводок для выгрузки в бухгалтерию, без детализации по фамилиям. Это гарантирует 100% защиту от «любопытства» персонала.
Резюме: Если вам нужно просто отслеживать действия, используйте расширение с перехватом ПриКомпоновкеРезультата в СКД. Если задача — обеспечить безопасность данных, комбинируйте настройки RLS и регистрацию доступа к персональным данным в Журнале регистрации.