Обработка персональных данных в "зарплатных" конфигурациях "1С:Предприятия 8"

Содержание

• Обработка персональных данных в "зарплатных" конфигурациях "1С:Предприятия 8"

Примечание:
* Механизм доступен в конфигурациях "Зарплата и управление персоналом" 2.5.19 и "Зарплата и кадры бюджетного учреждения" 1.0.8 при использовании платформы "1С:Предприятие" версии 8.2.10

Согласно подзаконным актам степень защиты данных зависит от класса информационной системы, который в свою очередь определяется количеством субъектов (в нашем случае физических лиц), количеством организаций и спецификой персональных данных*. Инструментарий конфигураций способен обеспечить защиту персональных данных в соответствии с требованиями Федерального закона от 27.06.2006 № 152-ФЗ (далее - Федеральный закон № 152-ФЗ) к информационным системам классов 3 и 2, в которые и входят большинство систем наших пользователей.

Примечание:
* Подробнее см. статью Организационные вопросы защиты персональных данных.

Что мы предлагаем пользователям для "защиты"?

Для защиты персональных данных в информационных системах класса 3 необходимо фиксировать события аутентификации (входа в систему) и отказа от аутентификации, которые по умолчанию включены. Для соответствия требованиям Федерального закона № 152-ФЗ к информационным системам класса 2 необходимо в числе прочего регистрировать события доступа и отказа в доступе к конкретным персональным данным. Иначе говоря, нужно "уметь" ответить на вопросs "Кто, когда, получил доступ к зарплате Иванова?", и "Кто и когда его получить пытался, но не смог" (из-за ограничения прав)?".

В новой версии 8.2.10 платформы "1С:Предприятие 8" добавлены возможности, которые решают эту задачу. А именно: регистрация событий доступа и отказа в доступе к данным и, соответственно, просмотр сведений о зарегистрированных событиях с точностью до полей данных.

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

• с одной стороны, требуется обеспечить соответствие требованиям закону - защитить все области персональных данных;
• с другой стороны, необходимо минимизировать потери производительности.

Перед разработчиками прикладного решения встает задача - обеспечить гибкую настройку режима соответствия требованиям Федерального закона № 152-ФЗ. В типовых решениях гибкость настройки достигается за счет:

• выделения областей персональных данных;
• управления "детальностью" регистрации событий.

Что сделано в "зарплатных" конфигурациях?

Итак, данные, подпадающие под определение "персональные", разбиваются на четыре области:

• личные сведения;
• сведения об образовании и компетенциях;
• сведения об имуществе;
• сведения о доходах.

Пользователю (администратору информационной системы) предлагается установить области данных, для которых будет выполняться регистрация событий доступа и отказа в доступе (см. рис. 1).

Рис. 1. Форма настройки режима защиты персональных данных.

Это вовсе не означает, что частично "включив" регистрацию событий, мы "частично" выполняем требования закона. Просто наиболее вероятным кажется сценарий, при котором доступ к таким областям данных, как сведения о доходах, например, находится в руках у очень ограниченного круга лиц и детально регистрировать каждое отдельное событие нет необходимости. В этом случае область данных можно "отключить" и снизить нагрузку на систему.

Регистрация списка лиц при доступе к данным определяет "детальность" сведений о событии. От этой настройки зависит, будет ли в журнале расшифровано "чья именно зарплата была прочитана" или будет указано: "была прочитана зарплата" без расшифровки по записям.

Все события фиксируются в журнале регистрации, но просмотреть новые события в удобной форме "ответов на вопросы" можно в форме Управление персональными данными (см. рис. 2). В форму отбираются: фиксированный набор видов событий, одновременно отражается список объектов и данных субъектов для событий доступа и отказ в доступе. Благодаря отбору по субъекту фактически появляется возможность получить ответ на вопрос: "Кто читал данные Иванова? Петрова? Сидорова?"

Рис. 2. Форма Управление персональными данными.

Еще одна настройка связана с обеспечением конфиденциальности сведений о доходах. Необходимо исключить возможность сотрудников видеть сумму зарплаты коллег. Это может произойти при выплате зарплаты по кассовым ведомостям. Настройка Ограничивать количество сотрудников при печати платежных ведомостей запрещает формирование печатной формы для платежных ведомостей, содержащих больше одного сотрудника. Выплату зарплаты в таком случае следует оформлять при помощи расходного кассового ордера.

В законе упоминается обязанность оператора в ряде случаев уничтожить персональные данные по запросу субъекта. Таким образом, по заявлению физического лица работодатель обязан удалить: данные о его доходах, ИНН, страховой номер ПФР и другие сведения, хранить которые работодателя обязывает законодательство. Учитывая специфику зарплатных конфигураций, принято решение выполнять уничтожение только тех персональных данных, которые не подлежат обязательному хранению. Предполагается, что уничтожение данных может быть выполнено, например, по требованию кандидата, который предоставлял свои сведения на этапе подбора персонала, но в последствии так и не стал сотрудником.

Уничтожение сведений выполняется только пользователем с полными правами в новой форме Управление персональными данными (той же, где и производится просмотр событий) - см. рис. 2. При уничтожении выполняется замена значений защищаемых полей пустыми значениями, иначе говоря, очистка полей, а ссылочная целостность базы данных сохраняется.

Как это работает?

Теперь несколько слов о том, как обеспечивается настройка регистрации новых событий Доступ и Отказ в доступе. Методы объектов платформы, выполняющие установку использования регистрации событий, требуют в качестве параметров: имя таблицы информационной базы, массив полей доступа (защищаемые данные), массив полей регистрации (то есть содержащих сведения о субъекте). Например:

• таблица РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций,
• поля доступа: Показатель1, Показатель2, Показатель3, Показатель4, Показатель5, Показатель6, Результат;
• поля регистрации: Сотрудник, Физлицо.

Разумеется, таблиц, в которых содержатся персональные данные, в "зарплатных" конфигурациях немало. Информация о них сведена в таблицу значений, имеющую соответствующие колонки: ИмяТаблицы, ПоляДоступа, ПоляРегистрации. В каждой строке этой таблицы значений содержится информация о ее принадлежности к определенной области данных (одной из четырех), что устанавливает соответствие между данными и настройками режима защиты данных. При включении настройки для области данных выполняется установка использования регистрации событий для таблиц БД, принадлежащих этой области. Таблица значений преобразована в формат XML и в таком виде поставляется в составе конфигурации в макете двоичных данных СведенияОПерсональныхДанных.

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

Обработка персональных данных в "зарплатных" конфигурациях "1С:Предприятия 8"

Примечание:
* Механизм доступен в конфигурациях "Зарплата и управление персоналом" 2.5.19 и "Зарплата и кадры бюджетного учреждения" 1.0.8 при использовании платформы "1С:Предприятие" версии 8.2.10

Согласно подзаконным актам степень защиты данных зависит от класса информационной системы, который в свою очередь определяется количеством субъектов (в нашем случае физических лиц), количеством организаций и спецификой персональных данных*. Инструментарий конфигураций способен обеспечить защиту персональных данных в соответствии с требованиями Федерального закона от 27.06.2006 № 152-ФЗ (далее - Федеральный закон № 152-ФЗ) к информационным системам классов 3 и 2, в которые и входят большинство систем наших пользователей.

Примечание:
* Подробнее см. статью Организационные вопросы защиты персональных данных.

Что мы предлагаем пользователям для "защиты"?

Для защиты персональных данных в информационных системах класса 3 необходимо фиксировать события аутентификации (входа в систему) и отказа от аутентификации, которые по умолчанию включены. Для соответствия требованиям Федерального закона № 152-ФЗ к информационным системам класса 2 необходимо в числе прочего регистрировать события доступа и отказа в доступе к конкретным персональным данным. Иначе говоря, нужно "уметь" ответить на вопросs "Кто, когда, получил доступ к зарплате Иванова?", и "Кто и когда его получить пытался, но не смог" (из-за ограничения прав)?".

В новой версии 8.2.10 платформы "1С:Предприятие 8" добавлены возможности, которые решают эту задачу. А именно: регистрация событий доступа и отказа в доступе к данным и, соответственно, просмотр сведений о зарегистрированных событиях с точностью до полей данных.

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

• с одной стороны, требуется обеспечить соответствие требованиям закону - защитить все области персональных данных;
• с другой стороны, необходимо минимизировать потери производительности.

Перед разработчиками прикладного решения встает задача - обеспечить гибкую настройку режима соответствия требованиям Федерального закона № 152-ФЗ. В типовых решениях гибкость настройки достигается за счет:

• выделения областей персональных данных;
• управления "детальностью" регистрации событий.

Что сделано в "зарплатных" конфигурациях?

Итак, данные, подпадающие под определение "персональные", разбиваются на четыре области:

• личные сведения;
• сведения об образовании и компетенциях;
• сведения об имуществе;
• сведения о доходах.

Пользователю (администратору информационной системы) предлагается установить области данных, для которых будет выполняться регистрация событий доступа и отказа в доступе (см. рис. 1).

Рис. 1. Форма настройки режима защиты персональных данных.

Это вовсе не означает, что частично "включив" регистрацию событий, мы "частично" выполняем требования закона. Просто наиболее вероятным кажется сценарий, при котором доступ к таким областям данных, как сведения о доходах, например, находится в руках у очень ограниченного круга лиц и детально регистрировать каждое отдельное событие нет необходимости. В этом случае область данных можно "отключить" и снизить нагрузку на систему.

Регистрация списка лиц при доступе к данным определяет "детальность" сведений о событии. От этой настройки зависит, будет ли в журнале расшифровано "чья именно зарплата была прочитана" или будет указано: "была прочитана зарплата" без расшифровки по записям.

Все события фиксируются в журнале регистрации, но просмотреть новые события в удобной форме "ответов на вопросы" можно в форме Управление персональными данными (см. рис. 2). В форму отбираются: фиксированный набор видов событий, одновременно отражается список объектов и данных субъектов для событий доступа и отказ в доступе. Благодаря отбору по субъекту фактически появляется возможность получить ответ на вопрос: "Кто читал данные Иванова? Петрова? Сидорова?"

Рис. 2. Форма Управление персональными данными.

Еще одна настройка связана с обеспечением конфиденциальности сведений о доходах. Необходимо исключить возможность сотрудников видеть сумму зарплаты коллег. Это может произойти при выплате зарплаты по кассовым ведомостям. Настройка Ограничивать количество сотрудников при печати платежных ведомостей запрещает формирование печатной формы для платежных ведомостей, содержащих больше одного сотрудника. Выплату зарплаты в таком случае следует оформлять при помощи расходного кассового ордера.

В законе упоминается обязанность оператора в ряде случаев уничтожить персональные данные по запросу субъекта. Таким образом, по заявлению физического лица работодатель обязан удалить: данные о его доходах, ИНН, страховой номер ПФР и другие сведения, хранить которые работодателя обязывает законодательство. Учитывая специфику зарплатных конфигураций, принято решение выполнять уничтожение только тех персональных данных, которые не подлежат обязательному хранению. Предполагается, что уничтожение данных может быть выполнено, например, по требованию кандидата, который предоставлял свои сведения на этапе подбора персонала, но в последствии так и не стал сотрудником.

Уничтожение сведений выполняется только пользователем с полными правами в новой форме Управление персональными данными (той же, где и производится просмотр событий) - см. рис. 2. При уничтожении выполняется замена значений защищаемых полей пустыми значениями, иначе говоря, очистка полей, а ссылочная целостность базы данных сохраняется.

Как это работает?

Теперь несколько слов о том, как обеспечивается настройка регистрации новых событий Доступ и Отказ в доступе. Методы объектов платформы, выполняющие установку использования регистрации событий, требуют в качестве параметров: имя таблицы информационной базы, массив полей доступа (защищаемые данные), массив полей регистрации (то есть содержащих сведения о субъекте). Например:

• таблица РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций,
• поля доступа: Показатель1, Показатель2, Показатель3, Показатель4, Показатель5, Показатель6, Результат;
• поля регистрации: Сотрудник, Физлицо.

Разумеется, таблиц, в которых содержатся персональные данные, в "зарплатных" конфигурациях немало. Информация о них сведена в таблицу значений, имеющую соответствующие колонки: ИмяТаблицы, ПоляДоступа, ПоляРегистрации. В каждой строке этой таблицы значений содержится информация о ее принадлежности к определенной области данных (одной из четырех), что устанавливает соответствие между данными и настройками режима защиты данных. При включении настройки для области данных выполняется установка использования регистрации событий для таблиц БД, принадлежащих этой области. Таблица значений преобразована в формат XML и в таком виде поставляется в составе конфигурации в макете двоичных данных СведенияОПерсональныхДанных.

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