Аудит прав доступа в 1С перед отчётностью Q1 2026

Аудит прав доступа в 1С перед отчётностью Q1 2026

Почему аудит прав доступа критичен перед отчётным периодом

Каждый раз, когда приближается отчётный период, финансовые директора и главные бухгалтеры холдингов сталкиваются с одной и той же проблемой: кто именно имеет доступ к финансовым данным, кто может корректировать проводки задним числом и кто способен несанкционированно изменить отчётные формы. В условиях, когда ФНС всё активнее применяет автоматический перекрёстный контроль деклараций, а аудиторы требуют подтверждения разграничения обязанностей, ответ на эти вопросы становится частью комплаенса, а не просто «ИТ-задачей».

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

В этой статье мы разберём системный подход к аудиту прав доступа в 1С накануне сдачи отчётности за 1 квартал 2026 года. Вы получите готовый чек-лист, практические скрипты на встроенном языке 1С и рекомендации по устранению типовых нарушений.

Архитектура прав доступа в 1С: что нужно понимать перед аудитом

Прежде чем приступать к проверке, необходимо чётко понимать, из каких слоёв состоит система разграничения доступа в платформе 1С:Предприятие 8.3.

Уровни разграничения доступа

  • Роли конфигурации — наборы прав на объекты метаданных (справочники, документы, отчёты, обработки). Назначаются пользователям через конфигуратор или административные инструменты.
  • Профили групп доступа — механизм управляемого приложения, позволяющий группировать роли и назначать их через интерфейс «1С:Предприятия» без конфигуратора.
  • Группы доступа — объединяют пользователей и связывают их с профилями. Именно через группы доступа в большинстве типовых конфигураций (БП, ERP, ЗУП) управляются права в режиме предприятия.
  • RLS (Record Level Security) — ограничения на уровне записей. Позволяют ограничить доступ не просто к типу объекта, а к конкретным записям — например, только к документам своей организации или своего склада.
  • Пользователи операционной системы и СУБД — для клиент-серверных баз важно также контролировать права на уровне SQL Server или PostgreSQL.

Типовые конфигурации и их особенности

В холдинге, как правило, используется несколько конфигураций: 1С:Бухгалтерия на Кодерион для бухгалтерского учёта, задачи по 1С:ERP для управленческого контура, задачи по 1С:ЗУП для расчёта заработной платы. У каждой — свои профили доступа, свои критичные роли и свои точки риска.

Ключевой принцип: аудит прав доступа — это не разовое мероприятие, а регулярный процесс. Перед каждым отчётным периодом он должен выполняться по стандартизированному чек-листу.

Чек-лист аудита: блок 1 — инвентаризация пользователей и ролей

Первый и самый фундаментальный шаг — получить актуальную картину того, кто существует в системе и какие права имеет.

1.1 Список активных пользователей

Выгрузите полный список пользователей информационной базы. Сравните его со списком действующих сотрудников из HR-системы или задачи по 1С:ЗУП. Особое внимание уделите:

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

Для получения списка пользователей с датой последнего входа используйте следующий запрос через консоль запросов или обработку:

// Получение списка пользователей с датой последнего входа
// Работает в конфигурациях на платформе 8.3.x

Функция ПолучитьПользователейСДатойВхода() Экспорт

	Результат = Новый ТаблицаЗначений();
	Результат.Колонки.Добавить("Пользователь", Новый ОписаниеТипов("СправочникСсылка.Пользователи"));
	Результат.Колонки.Добавить("ИмяВхода", Новый ОписаниеТипов("Строка", , Новый КвалификаторыСтроки(100)));
	Результат.Колонки.Добавить("ДатаПоследнегоВхода", Новый ОписаниеТипов("Дата"));
	Результат.Колонки.Добавить("ВходРазрешён", Новый ОписаниеТипов("Булево"));
	Результат.Колонки.Добавить("ДнейБезВхода", Новый ОписаниеТипов("Число", Новый КвалификаторыЧисла(10, 0)));

	// Получаем всех пользователей ИБ
	ВсеПользователи = ПользователиИнформационнойБазы.ПолучитьПользователей();

	ДляКаждого ПользИБ Из ВсеПользователи Цикл

		НоваяСтрока = Результат.Добавить();
		НоваяСтрока.ИмяВхода = ПользИБ.Имя;
		НоваяСтрока.ВходРазрешён = НЕ ПользИБ.НеДействителен;

		// Ищем соответствующего пользователя в справочнике
		Запрос = Новый Запрос();
		Запрос.Текст =
			"ВЫБРАТЬ
			|    Пользователи.Ссылка КАК Ссылка,
			|    Пользователи.ДатаПоследнегоВхода КАК ДатаПоследнегоВхода
			|ИЗ
			|    Справочник.Пользователи КАК Пользователи
			|ГДЕ
			|    Пользователи.ИмяПользователя = &ИмяВхода";

		Запрос.УстановитьПараметр("ИмяВхода", ПользИБ.Имя);
		РезЗапроса = Запрос.Выполнить();

		Если НЕ РезЗапроса.Пустой() Тогда
			Выборка = РезЗапроса.Выбрать();
			Выборка.Следующий();
			НоваяСтрока.Пользователь = Выборка.Ссылка;
			НоваяСтрока.ДатаПоследнегоВхода = Выборка.ДатаПоследнегоВхода;

			// Считаем количество дней без входа
			Если ЗначениеЗаполнено(Выборка.ДатаПоследнегоВхода) Тогда
				НоваяСтрока.ДнейБезВхода = (ТекущаяДата() - Выборка.ДатаПоследнегоВхода) / 86400;
			Иначе
				НоваяСтрока.ДнейБезВхода = 9999; // Никогда не входил
			КонецЕсли;
		КонецЕсли;

	КонецЦикла;

	Возврат Результат;

КонецФункции

1.2 Проверка критичных ролей

Определите список «критичных» ролей, назначение которых требует особого обоснования. Для бухгалтерских баз это:

  • ПолныеПрава — абсолютный доступ ко всему. Должна быть только у системного администратора.
  • АдминистраторСистемы — управление пользователями и настройками.
  • РедактированиеДвиженийДокументов — возможность ручной правки проводок.
  • УдалениеПомеченныхОбъектов — необратимое удаление данных.
  • ИзменениеЗакрытогоПериода — правка документов в закрытых периодах.

Чек-лист аудита: блок 2 — анализ RLS и ограничений на уровне записей

RLS (Record Level Security) — наиболее сложный и часто игнорируемый уровень контроля доступа. Именно здесь скрываются самые неочевидные уязвимости холдинга.

2.1 Проверка доступа к организациям

В мультиорганизационной базе критично убедиться, что бухгалтер ООО «Альфа» не видит документы ООО «Бета». Для этого проверяется настройка RLS в профилях групп доступа. Типовые конфигурации используют параметр ОсновнаяОрганизация или список организаций в группе доступа.

// Проверка настроек RLS для пользователей — какие организации доступны
// Выполняется в режиме предприятия с правами администратора

Процедура ПроверитьДоступПользователейКОрганизациям()

	Запрос = Новый Запрос();
	Запрос.Текст =
		"ВЫБРАТЬ
		|    ГруппыДоступаПользователи.Пользователь КАК Пользователь,
		|    ГруппыДоступаПользователи.Ссылка.Наименование КАК ГруппаДоступа,
		|    ГруппыДоступаЗначения.ЗначениеДоступа КАК Организация
		|ИЗ
		|    Справочник.ГруппыДоступа.Пользователи КАК ГруппыДоступаПользователи
		|        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ГруппыДоступа.ЗначенияДоступа КАК ГруппыДоступаЗначения
		|        ПО ГруппыДоступаПользователи.Ссылка = ГруппыДоступаЗначения.Ссылка
		|ГДЕ
		|    ТИП(ГруппыДоступаЗначения.ЗначениеДоступа) = ТИП(Справочник.Организации)
		|    И НЕ ГруппыДоступаПользователи.Ссылка.ПометкаУдаления
		|УПОРЯДОЧИТЬ ПО
		|    Пользователь,
		|    ГруппаДоступа";

	Результат = Запрос.Выполнить().Выгрузить();

	// Выводим результат для анализа
	ДляКаждого Строка Из Результат Цикл
		Сообщить("Пользователь: " + Строка.Пользователь
			+ " | Группа: " + Строка.ГруппаДоступа
			+ " | Организация: " + Строка.Организация);
	КонецЦикла;

КонецПроцедуры

2.2 Проверка доступа к складам и подразделениям

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

Чек-лист аудита: блок 3 — журнал регистрации и следы аномалий

Журнал регистрации — главный инструмент ретроспективного аудита. Перед закрытием квартала необходимо проанализировать события за последние 90 дней.

3.1 Что искать в журнале регистрации

Тип события Уровень важности Что означает
Изменение прав пользователя Критический Кто и когда менял роли
Удаление данных Критический Необратимые операции
Вход в систему в нерабочее время Высокий Возможный несанкционированный доступ
Массовое изменение документов Высокий Пакетные операции без обоснования
Изменение закрытого периода Критический Правка уже закрытых данных
Экспорт данных во внешние файлы Высокий Возможная утечка

3.2 Скрипт анализа журнала регистрации

// Анализ журнала регистрации на предмет критичных событий
// за указанный период

Функция ПолучитьКритичныеСобытияЖурнала(ДатаНачала, ДатаОкончания) Экспорт

	// Фильтр для журнала регистрации
	Фильтр = Новый Структура();

	// Отбираем события уровня «Ошибка» и «Предупреждение»
	МассивУровней = Новый Массив();
	МассивУровней.Добавить(УровеньЖурналаРегистрации.Ошибка);
	МассивУровней.Добавить(УровеньЖурналаРегистрации.Предупреждение);
	Фильтр.Вставить("Уровень", МассивУровней);

	// Период анализа
	Фильтр.Вставить("ДатаНачала", ДатаНачала);
	Фильтр.Вставить("ДатаОкончания", ДатаОкончания);

	// Критичные события: изменение прав и удаление
	МассивСобытий = Новый Массив();
	МассивСобытий.Добавить("_$Access$_.Access"); // Изменение прав
	МассивСобытий.Добавить("_$Data$_.Delete"); // Удаление объектов
	МассивСобытий.Добавить("_$User$_.Delete"); // Удаление пользователей
	Фильтр.Вставить("Событие", МассивСобытий);

	ЗаписиЖурнала = Новый ТаблицаЗначений();
	ВыгрузитьЖурналРегистрации(ЗаписиЖурнала, Фильтр);

	// Дополнительно: ищем входы в нерабочее время (до 8:00 и после 20:00)
	ФильтрВходов = Новый Структура();
	ФильтрВходов.Вставить("Событие", "_$Session$_.Start");
	ФильтрВходов.Вставить("ДатаНачала", ДатаНачала);
	ФильтрВходов.Вставить("ДатаОкончания", ДатаОкончания);

	ЗаписиВходов = Новый ТаблицаЗначений();
	ВыгрузитьЖурналРегистрации(ЗаписиВходов, ФильтрВходов);

	АномальныеВходы = Новый ТаблицаЗначений();
	АномальныеВходы.Колонки.Добавить("Дата");
	АномальныеВходы.Колонки.Добавить("Пользователь");
	АномальныеВходы.Колонки.Добавить("ИмяКомпьютера");

	ДляКаждого Запись Из ЗаписиВходов Цикл
		ЧасВхода = Час(Запись.Дата);

		// Вход до 8 утра или после 20 вечера — аномалия
		Если ЧасВхода < 8 ИЛИ ЧасВхода >= 20 Тогда
			НоваяСтрока = АномальныеВходы.Добавить();
			НоваяСтрока.Дата = Запись.Дата;
			НоваяСтрока.Пользователь = Запись.Пользователь;
			НоваяСтрока.ИмяКомпьютера = Запись.ИмяКомпьютера;
		КонецЕсли;
	КонецЦикла;

	Результат = Новый Структура();
	Результат.Вставить("КритичныеСобытия", ЗаписиЖурнала);
	Результат.Вставить("АномальныеВходы", АномальныеВходы);

	Возврат Результат;

КонецФункции

Чек-лист аудита: блок 4 — проверка разделения обязанностей (SoD)

Принцип разделения обязанностей (Segregation of Duties) требует, чтобы один пользователь не мог выполнить критичную операцию от начала до конца без контроля другого сотрудника. Это ключевое требование как внутреннего аудита, так и внешних проверяющих.

4.1 Конфликты ролей, которые нужно выявить

Следующие комбинации ролей являются недопустимыми с точки зрения SoD:

  • Создание поставщика + Проведение платёжного поручения — один человек может создать фиктивного контрагента и перевести ему деньги.
  • Начисление зарплаты + Выплата зарплаты — классический риск мошенничества в расчётном отделе.
  • Ввод первичных документов + Закрытие периода — возможность скрыть ошибки путём закрытия.
  • Администрирование пользователей + Проведение финансовых операций — администратор может назначить себе права и провести несанкционированную операцию.
  • Доступ к настройкам RLS + Доступ к финансовым данным — возможность снять с себя ограничения.

4.2 Матрица несовместимых ролей

Рекомендуется составить и поддерживать в актуальном состоянии матрицу несовместимых ролей. Пример для 1С:Бухгалтерии 3.0:

Роль A Роль B Тип конфликта Допустимые исключения
БухгалтерПоБанку НастройкаПараметровУчёта Критический Нет
КадровикРасширенный РасчётЗарплаты Высокий Только малый бизнес
ПолныеПрава Любая роль Критический Только администратор
УдалениеПомеченных ВводПервичныхДокументов Высокий Нет

Найдите специалиста для решения этой задачи на koderion.ru