В современных корпоративных информационных системах требования службы информационной безопасности (ИБ) становятся все более жесткими. Одной из стандартных задач является соблюдение принципа минимальных привилегий. Часто ИБ-аудит выявляет, что регламентные задания (РЗ) выполняются под учетными записями с полными правами, что создает потенциальную уязвимость. Разберем подробно, как определить необходимые права для регламентного задания и правильно настроить технического пользователя.
Прежде всего, нам необходимо уяснить фундаментальный принцип платформы 1С:Предприятие: права доступа не назначаются самому регламентному заданию напрямую. Права всегда привязаны к пользователю информационной базы, под которым выполняется это задание. Проанализируем, как ведет себя система в разных сценариях:
Пользователь, задание выполняется с его набором ролей.Таким образом, наша задача сводится к созданию специального «технического» пользователя для каждого РЗ (или группы схожих заданий) и назначению ему только тех ролей, которые критически необходимы для работы алгоритма.
Чтобы понять, какие права давать, нужно выяснить, к каким данным обращается код регламентного задания. Рассмотрим несколько способов проведения такого анализа.
Способ А: Статический анализ кода
Проанализируем программный код процедуры, которая указана в поле ИмяМетода регламентного задания. Нам нужно выписать все обращения к:
Важно помнить про «цепочки» вызовов. Если процедура РЗ вызывает функцию из общего модуля, необходимо проследить все вложенные вызовы. Это трудоемкий процесс, но он дает наиболее глубокое понимание логики.
Способ Б: Использование замера производительности
Запустим регламентное задание в режиме отладки. Для этого в консоли заданий можно вызвать метод программно. Перед запуском включим замер производительности. После завершения работы мы получим список всех процедур и функций, которые были задействованы. Просматривая этот список, гораздо проще локализовать места обращения к данным.
Способ В: Технологический журнал (для экспертов)
Если код слишком сложный или используется динамическое построение запросов, проанализируем активность через Технологический журнал (ТЖ). Настроим сбор событий SDBL, ограничив его конкретным фоновым процессом. В логах мы увидим реальные имена таблиц базы данных, к которым обращалась система.
Выяснив список объектов, перейдем к настройке прав. Рассмотрим ситуацию: регламентное задание должно обновлять цены номенклатуры на основе данных из внешнего источника. Проанализируем необходимые права:
Чтение справочника Номенклатура.Чтение и Добавление/Изменение регистра сведений ЦеныНоменклатуры.Чтение константы ВалютаУчета.Вместо назначения стандартной роли ПолныеПрава, создадим новую роль, например, РаботаРегламентногоЗаданияОбновлениеЦен. В этой роли отметим только те права, которые мы выписали на этапе анализа.
Важный нюанс: Если в конфигурации используется Библиотека стандартных подсистем (БСП), техническому пользователю часто требуются базовые права для работы самой платформы и БСП (например, доступ к справочнику Пользователи, чтение некоторых общих констант и т.д.). Для этого удобно использовать предопределенные роли типа СтандартныеПрава.
В современных конфигурациях (ЕРП, УТ 11, КА 2, БП 3) управление регламентными заданиями реализовано через интерфейс БСП. Рассмотрим, как назначить пользователя там:
Пользователь выберем заранее созданного технического пользователя с ограниченными правами.Теперь при наступлении времени запуска система создаст фоновое задание именно под этим пользователем, и оно будет ограничено рамками тех ролей, которые мы ему назначили.
Часто в обсуждениях предлагают использовать УстановитьПривилегированныйРежим(Истина). Разберем ситуацию: этот метод временно отключает проверку прав доступа. С точки зрения ИБ — это часто считается нарушением, так как код может выполнить действия, на которые у пользователя нет прав.
Однако существуют сценарии, где без этого не обойтись (например, запись в защищенные системные регистры). Если ваш регламент ИБ запрещает привилегированный режим, вам придется явно прописывать права даже на низкоуровневые операции. Если же использование разрешено, старайтесь ограничивать область его применения минимальным фрагментом кода:
// Пример правильного использования
Процедура ВыполнитьОбработкуДанных()
// Здесь проверка прав работает
Данные = ПолучитьСписокОбъектовДляОбработки();
УстановитьПривилегированныйРежим(Истина);
// Только запись результата под полными правами
ЗаписатьТехническийЛог(Данные);
УстановитьПривилегированныйРежим(Ложь);
КонецПроцедуры
Чтобы система оставалась безопасной, нам нужно убедиться, что ни одно задание не работает "само по себе" (с полными правами). Проанализируем ситуацию программно. Мы можем написать простую обработку, которая проверит всех активных потребителей ресурсов:
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого Задание Из Задания Цикл
Если Задание.Использование И ПустаяСтрока(Задание.ИмяПользователя) Тогда
Сообщить("Внимание! Задание '" + Задание.Метаданные.Синоним + "' запущено без указания пользователя!");
КонецЕсли;
КонецЦикла;
Резюмируем: Для обеспечения безопасности регламентных заданий мы должны отказаться от использования системных учетных записей. Правильный путь — это создание атомарных ролей, привязка их к профилям групп доступа и назначение конкретных технических пользователей для каждого важного процесса в системе. Это не только удовлетворит требования ИБ, но и защитит базу от непреднамеренных ошибок в коде, которые могли бы повредить данные при наличии неограниченных прав.