RLS в 1С vs права на объекты: что надёжнее в 2026

RLS в 1С vs права на объекты: что надёжнее в 2026

Почему вопрос защиты данных в 1С стал критичным в 2026 году

Ещё пять лет назад большинство компаний, работающих на платформе 1С:Предприятие, ограничивались базовым разграничением доступа: одним пользователям открывали одни справочники и документы, другим — другие. Сегодня ситуация принципиально изменилась. Регуляторные требования ужесточились, утечки данных стали дорогостоящими, а внутренние угрозы — куда более изощрёнными. Аудиторы и службы безопасности всё чаще задают вопрос: а на каком уровне у вас реализовано разграничение доступа в 1С?

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

В этой статье мы детально разберём архитектуру обоих подходов, сравним их по ключевым критериям — безопасности, производительности, сложности администрирования — и дадим практические рекомендации, какой механизм (или их комбинацию) выбрать в конкретной ситуации. Если вам нужно найти разработчика 1С для настройки системы безопасности, в конце статьи вы найдёте соответствующую ссылку.

Архитектура разграничения прав на уровне объектов

Классическое разграничение прав в 1С строится на концепции ролей. Роль — это набор разрешений на выполнение операций (чтение, добавление, изменение, удаление, просмотр) применительно к конкретным объектам метаданных: справочникам, документам, регистрам, отчётам, обработкам и т.д.

Роли назначаются пользователям напрямую или через профили групп доступа (в управляемом приложении). Платформа проверяет права при каждом обращении к объекту — как в интерактивном режиме, так и в программном коде. Если у пользователя нет права «Чтение» на справочник «Контрагенты», он не увидит ни одной записи этого справочника вне зависимости от того, как именно он пытается получить к ней доступ.

Структура роли и проверка прав

На уровне объектов права проверяются до выполнения запроса к базе данных. Это означает, что СУБД (PostgreSQL или MS SQL Server) даже не получает запрос, если платформа уже на уровне метаданных определила, что у пользователя нет соответствующего права. Это делает данный механизм крайне эффективным с точки зрения производительности.

// Программная проверка права доступа к объекту
// Используется для условного отображения элементов интерфейса

Функция ПользовательИмеетПравоНаЧтениеКонтрагентов()
	
	// Проверяем наличие права «Чтение» у текущего пользователя
	Возврат ПравоДоступа("Чтение", Метаданные.Справочники.Контрагенты);
	
КонецФункции

// Пример использования в форме
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	
	// Скрываем кнопку, если нет права на просмотр
	Если НЕ ПользовательИмеетПравоНаЧтениеКонтрагентов() Тогда
		Элементы.КнопкаОткрытьКонтрагента.Видимость = Ложь;
	КонецЕсли;
	
КонецПроцедуры

Преимущества объектного разграничения

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

Ограничения объектного разграничения

Главный недостаток — гранулярность. Права назначаются на весь объект целиком. Если пользователю нужно видеть только «своих» контрагентов или только документы своего подразделения — объектные права бессильны. Либо открываем всё, либо закрываем всё. Именно здесь на сцену выходит RLS.

Архитектура Row Level Security (RLS) в 1С

RLS — механизм ограничения доступа на уровне отдельных записей внутри объекта. Пользователь технически имеет право читать справочник «Контрагенты», но видит только те записи, которые соответствуют заданному условию: например, только контрагентов своей организации или своего менеджера.

В 1С:Предприятие RLS реализуется через ограничения доступа к данным в настройках роли. Для каждого вида права (Чтение, Изменение, Добавление, Удаление) можно задать условие на языке запросов 1С. Платформа автоматически добавляет это условие к каждому запросу, который выполняет пользователь с данной ролью.

Как работает RLS под капотом

Когда пользователь выполняет запрос к базе данных, платформа 1С анализирует все роли пользователя, собирает условия RLS и добавляет их в текст SQL-запроса, отправляемого в СУБД. Это означает, что фильтрация происходит на уровне СУБД — в отличие от объектных прав, которые проверяются раньше.

// Пример условия RLS для роли «Менеджер по продажам»
// Настраивается в конфигураторе в свойствах роли
// Объект: Справочник.Контрагенты, Право: Чтение

// Текст ограничения (вводится в поле «Ограничение доступа к данным»):
// ГДЕ Ссылка.ОтветственныйМенеджер = &ТекущийПользователь

// Параметр &ТекущийПользователь — стандартный параметр сеанса
// Устанавливается при входе пользователя в систему

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
	
	// Устанавливаем параметр сеанса для использования в RLS
	ПараметрыСеанса.ТекущийПользователь = 
		Пользователи.ТекущийПользователь();
	
	// Дополнительный параметр — подразделение пользователя
	ПользовательОбъект = ПараметрыСеанса.ТекущийПользователь;
	
	Если ЗначениеЗаполнено(ПользовательОбъект) Тогда
		
		ПараметрыСеанса.ПодразделениеПользователя = 
			ПользовательОбъект.Подразделение;
		
	КонецЕсли;
	
КонецПроцедуры

Виды условий RLS и их особенности

Условия RLS в 1С могут быть как простыми (сравнение реквизита с параметром сеанса), так и весьма сложными — с подзапросами, соединениями с таблицами прав доступа и т.д. Типовые конфигурации (например, 1С:Бухгалтерия на Кодерион) используют развитую систему RLS на основе групп доступа и таблиц прав доступа пользователей.

// Пример сложного условия RLS с использованием
// вспомогательной таблицы прав доступа
// Объект: Документ.РеализацияТоваровУслуг, Право: Чтение

// Текст ограничения:
// ГДЕ
// 	Ссылка.Организация В
// 		(ВЫБРАТЬ
// 				ТаблицаПрав.Организация
// 			ИЗ
// 				РегистрСведений.ПраваДоступаПользователей КАК ТаблицаПрав
// 			ГДЕ
// 				ТаблицаПрав.Пользователь = &ТекущийПользователь
// 				И ТаблицаПрав.ВидДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыДоступа.Организация))

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

Сравнение по критерию безопасности

Рассмотрим оба механизма через призму реальных угроз безопасности, актуальных в 2026 году.

Защита от внутреннего нарушителя

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

Победитель по гранулярности защиты: RLS.

Защита от обхода через прямой SQL

Здесь важно понимать принципиальное различие: оба механизма 1С работают на уровне платформы, а не СУБД. Если злоумышленник получит прямой доступ к базе данных (через SQL Management Studio или psql), ни RLS 1С, ни объектные права его не остановят. Это фундаментальное ограничение архитектуры 1С — защита данных на уровне СУБД должна обеспечиваться отдельными средствами.

Нативный RLS PostgreSQL или SQL Server, который можно настроить параллельно с 1С, обеспечивает защиту даже при прямом SQL-доступе. Однако его интеграция с логикой 1С требует отдельной работы.

Победитель по защите от прямого SQL: ничья (оба не защищают без дополнительных мер).

Устойчивость к ошибкам конфигурирования

Объектные права проще в настройке и реже содержат ошибки. Условия RLS — особенно сложные, с подзапросами — могут содержать логические ошибки, которые либо дают лишний доступ, либо, наоборот, блокируют нужные данные. Тестирование RLS требует значительно больше усилий.

Победитель по надёжности конфигурирования: объектные права.

Сравнение по производительности: главная боль RLS

Производительность — ахиллесова пята RLS в 1С. Это нужно понимать чётко, прежде чем принимать архитектурное решение.

Почему RLS замедляет систему

Каждый запрос, выполняемый пользователем с активным RLS, получает дополнительное условие в WHERE-клаузе. Если условие простое (сравнение с параметром сеанса), накладные расходы минимальны. Но если условие содержит подзапрос к регистру сведений с тысячами записей — каждый основной запрос превращается в коррелированный подзапрос, и производительность может упасть в разы.

Типичная проблема: в системе с 50 000 документов реализации и сложным RLS по организациям формирование отчёта «Продажи» для менеджера занимает 40 секунд вместо 2 секунд без RLS. Это не гипотетический пример — с подобными ситуациями регулярно сталкиваются разработчики.

Стратегии оптимизации RLS

// ПЛОХОЙ пример условия RLS (коррелированный подзапрос)
// Выполняется для каждой строки основного запроса
// ГДЕ ИСТИНА В
// 	(ВЫБРАТЬ ПЕРВЫЕ 1 ИСТИНА
// 		ИЗ РегистрСведений.ПраваДоступа КАК ПД
// 		ГДЕ ПД.Пользователь = &ТекущийПользователь
// 			И ПД.Организация = Ссылка.Организация)

// ХОРОШИЙ пример — использование временной таблицы прав
// Права рассчитываются один раз и кешируются

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

Индексирование и RLS

Поля, участвующие в условиях RLS, обязательно должны быть проиндексированы. Если в условии RLS используется реквизит «Организация» документа, а индекса по этому полю нет — каждый запрос будет выполнять полное сканирование таблицы. В крупных базах это катастрофа производительности. Проверяйте планы запросов в СУБД после включения RLS — это обязательный шаг.

При работе с задачи по 1С:ERP с большими объёмами данных оптимизация RLS становится отдельным серьёзным проектом.

Сравнение по сложности администрирования

Объектные права: просто, но негибко

Администрирование объектных прав интуитивно понятно. В конфигураторе или через стандартный интерфейс «Пользователи и права» администратор видит, какие роли назначены пользователю, и может быстро добавить или убрать роль. Аудит прав прозрачен: стандартный отчёт «Права доступа» показывает полную картину.

Проблема возникает при масштабировании: если в компании 200 пользователей с разными комбинациями прав, количество ролей начинает расти неконтролируемо. Появляются роли «ДляМенеджераПетрова» и «ДляБухгалтераИвановойКромеЗарплаты» — это антипаттерн, который делает систему прав неуправляемой.

RLS: гибко, но сложно

RLS решает проблему масштабирования прав: вместо 200 ролей достаточно одной роли с условием RLS, которое динамически фильтрует данные на основе таблицы прав. Добавление нового пользователя сводится к записи в регистр сведений — без изменения конфигурации.

Однако отладка RLS — отдельная боль. Когда пользователь жалуется, что «не видит нужный документ», диагностика требует проверки: какие роли назначены, какие условия RLS активны, правильно ли заполнена таблица прав, корректно ли установлен параметр сеанса. Это значительно сложнее, чем диагностика объектных прав.

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

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

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