Настройка RLS в 1С:ERP 2026: ограничение прав, аудит и шифрование данных

Автор: Михаил С., Архитектор 1С · Опубликовано: 31.05.2026 · Обновлено: 04.09.2026

Настройка RLS в 1С:ERP 2026: ограничение прав, аудит и шифрование данных

📅 Опубликовано 31 мая 2026 г. · 🔄 Обновлено 4 сентября 2026 г.

Коротко: При консолидации данных в 1С:ERP 2026 ключевыми механизмами безопасности становятся RLS на уровне записей с динамическими ограничениями, расширенный журнал регистрации с фильтрацией по 40+ типам событий, шифрование межфирменных потоков через TLS 1.3 и КриптоПро CSP 5.0, а также сегментация прав по организациям через профили групп доступа. Внедрение полного контура занимает 200–400 часов и закрывает основные каналы утечки данных между юрлицами холдинга.

RLS в 1С:ERP 2026 настраивают через профили групп доступа: список организаций пользователя хранят в индексированном регистре сведений, а условие в шаблоне ограничений пишут через «ВЫБРАТЬ РАЗРЕШЕННЫЕ» без глубокой вложенности подзапросов. Аудит собирают в журнале регистрации и выгружают наружу – в SIEM или лог-коллектор, чтобы записи нельзя было подчистить из базы. Внешние каналы (обмены, публикации, файловые выгрузки) закрывают TLS и сертифицированным криптопровайдером. Обязательный финальный шаг – прогон под тестовыми пользователями: чаще всего ограничения протекают в отчётах, навигационных ссылках и в коде с привилегированным режимом.

RLS в 1С:ERP 2026 включается через профили групп доступа: список доступных организаций хранят в регистре сведений с индексом по пользователю, а условие в шаблоне ограничений пишут через «ВЫБРАТЬ РАЗРЕШЕННЫЕ» с одним уровнем подзапроса. Аудит собирают в журнале регистрации и выгружают наружу – в SIEM или лог-коллектор, чтобы записи нельзя было подчистить изнутри базы. Обмены, публикации и файловые выгрузки закрывают TLS и сертифицированным криптопровайдером (КриптоПро CSP, ViPNet CSP). Готовую настройку обязательно прогоняют под тестовыми пользователями: отчёты, навигационные ссылки и привилегированный режим в доработках обходят RLS чаще всего.

Быстрый ответ – три контура защиты данных в 1С:ERP 2026:

  • Ограничение прав (RLS) – динамические ограничения на уровне записей: пользователь видит только данные своей организации; настраивается через профили групп доступа.
  • Аудит – расширенный журнал регистрации с фильтрацией по 40+ типам событий и выгрузкой в SIEM для контроля критичных операций.
  • Шифрование – межфирменные потоки и файловые выгрузки закрываются TLS 1.3 и сертифицированным КриптоПро CSP 5.0.

Почему консолидация в 1С:ERP 2026 требует нового подхода к безопасности?

Современные холдинги объединяют в одной информационной базе 1С:ERP десятки юридических лиц, обособленных подразделений и обслуживающих компаний. По данным внутренних аудитов крупных внедрений, к 2026 году средний размер консолидированной базы вырос до 2,5–4 ТБ, а число активных пользователей в одном кластере достигает 800–1500 человек. Это создаёт принципиально новую модель угроз: утечка одного документа может скомпрометировать сразу несколько юридических лиц холдинга.

Регуляторное давление также усилилось. Требования ФЗ-152 «О персональных данных», приказ ФСТЭК №21 и постановление правительства №1119 теперь напрямую распространяются на учётные системы холдингов. При проверках Роскомнадзора в 2024–2026 годах основные претензии касались именно отсутствия разграничения доступа между организациями и неполного журналирования действий пользователей.

Какие риски возникают при объединении баз?

  • Горизонтальное расширение доступа – бухгалтер дочерней компании видит платежи материнской структуры
  • Утечка через выгрузки – типовые отчёты СКД позволяют выгрузить весь массив данных в Excel
  • Компрометация служебных учёток – RPA-роботы и интеграции часто работают с правами «Полные права»
  • Отсутствие следов – стандартный журнал регистрации фиксирует только базовые события
  • Передача данных между серверами – межфирменные обмены идут в открытом виде

Как правильно настроить RLS при консолидации?

Row-Level Security (ограничение доступа на уровне записей) – фундамент безопасности в консолидированных базах. В 1С:ERP 2026 механизм RLS реализуется через профили групп доступа и условия в шаблонах. Главное правило: RLS должен быть многомерным, то есть учитывать не только организацию, но и подразделение, склад, контрагента, статью ДДС и проект.

Что изменилось в RLS в редакции 2026?

В новой редакции усовершенствован механизм функциональных опций для RLS – теперь можно динамически отключать ограничения для отдельных регламентных заданий без снижения общей защищённости. Также добавлена возможность кэширования значений ограничений на стороне сервера, что снизило накладные расходы RLS на производительность с 25–40% до 8–15%.

// Пример настройки RLS через шаблон для документа "РеализацияТоваровУслуг"
// Условие в шаблоне ограничений доступа

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

Как избежать падения производительности?

Главная ошибка при внедрении RLS – добавление сложных подзапросов с соединениями по таблицам с миллионами записей. Рекомендации из практики внедрений:

  1. Используйте регистр сведений ДоступныеОрганизацииПользователей с индексированием по полю «Пользователь»
  2. Не вкладывайте более двух уровней подзапросов в условие RLS
  3. Применяйте функциональные опции для отключения RLS в фоновых заданиях обмена
  4. Кэшируйте список доступных организаций в параметрах сеанса
  5. Замеряйте время выполнения типовых отчётов до и после внедрения RLS

RLS в 1С: что это такое и чем настройка в 8.3 отличается от ERP

До того как проектировать матрицу на 40 профилей, стоит зафиксировать термины – иначе половина заявок в поддержку будет про «пропавшие документы». RLS (Row Level Security) – это механизм самой платформы 8.3, а не отдельный модуль: в правах роли для конкретной таблицы прописывается условие, и платформа автоматически подмешивает его в каждый запрос к этой таблице – из формы списка, из отчёта, из кода, из OData. Пользователь не получает «отфильтрованный» результат: он просто не видит записи, которые не попали под условие.

Ключевой момент, который путают чаще всего: RLS не выдаёт права, а сужает уже выданные. Сначала роль разрешает чтение объекта, потом ограничение отсекает часть записей. Нет роли – RLS ничего не откроет; есть роль без ограничения – виден весь массив по всем юрлицам. Именно поэтому ограничение прав в 1С – это всегда связка из трёх слоёв: роли, профили групп доступа и условия на уровне записей.

Чем отличается RLS в 1С 8.3 и в типовых конфигурациях

Разница не в платформе, а в надстройке над ней:

  • Самописная конфигурация на 8.3 – условия пишут прямо в ролях, значения берут из параметров сеанса. Гибко, но каждое изменение оргструктуры означает правку конфигурации и обновление.
  • Типовые на БСП (1С:ERP, КА, УТ, «Бухгалтерия») – шаблоны ограничений уже написаны разработчиком, администратор работает с видами доступа, профилями и группами доступа в пользовательском режиме. Конфигурация при этом остаётся на поддержке.

Порядок настройки RLS в 1С 8.3 в типовой конфигурации

  1. В разделе «Администрирование → Настройки пользователей и прав» включить ограничение доступа на уровне записей. Первое включение перезаполняет служебные регистры доступа – делайте это в нерабочее время, на больших базах операция долгая.
  2. Определить виды доступа, по которым будет резаться выборка: организации, склады, группы партнёров, группы номенклатуры, подразделения.
  3. Создать профили групп доступа под должностные функции и указать в них разрешённые виды доступа.
  4. Создать группы доступа на базе профилей, задать конкретные значения (какие организации и склады) и включить в них пользователей.
  5. Прогнать проверку под тестовыми учётками – порядок прогона описан ниже, без него настройка считается незавершённой.

Отдельно проверьте доработки: обращение к данным из общего модуля со свойством «Привилегированный» или после УстановитьПривилегированныйРежим(Истина) идёт мимо любых ограничений, каким бы аккуратным ни был шаблон.

Что нового в журнале аудита 1С:ERP 2026?

Журнал регистрации в 2026 году получил серьёзное развитие. Теперь поддерживается экспорт в формате JSON для интеграции с SIEM-системами (MaxPatrol, Ankey SIEM, KUMA), фильтрация по 40+ типам событий и автоматическое архивирование с шифрованием. Размер журнала перестал быть «бутылочным горлышком» – реализована ротация и сжатие.

Какие события обязательно нужно журналировать?

КатегорияСобытиеКритичность
ДоступВход/выход пользователяСредняя
ДоступНеудачные попытки входа (более 3)Высокая
ДанныеИзменение проведённых документов закрытых периодовКритическая
ДанныеУдаление помеченных объектовВысокая
КонфигурацияИзменение прав пользователейКритическая
ЭкспортВыгрузка отчётов с объёмом более 1000 строкВысокая
ИнтеграцияПодключения через COM/HTTP/Web-сервисыСредняя
// Программная запись расширенного события в журнал аудита

Процедура ЗаписатьСобытиеАудита(ИмяСобытия, Уровень, Объект, ДополнительныеДанные = Неопределено)
	
	ДанныеСобытия = Новый Структура;
	ДанныеСобытия.Вставить("Пользователь", ПользователиИнформационнойБазы.ТекущийПользователь());
	ДанныеСобытия.Вставить("КомпьютерКлиента", ПараметрыСеанса.КомпьютерПользователя);
	ДанныеСобытия.Вставить("IPАдрес", ПараметрыСеанса.IPАдресКлиента);
	ДанныеСобытия.Вставить("ВремяСобытия", ТекущаяУниверсальнаяДата());
	
	Если ДополнительныеДанные <> Неопределено Тогда
		ДанныеСобытия.Вставить("Контекст", ДополнительныеДанные);
	КонецЕсли;
	
	// Сериализация в JSON для совместимости с SIEM
	ЗаписьJSON = Новый ЗаписьJSON;
	ПараметрыJSON = Новый ПараметрыЗаписиJSON(ПереносСтрокJSON.Авто, Символы.Таб);
	ЗаписьJSON.УстановитьСтроку(ПараметрыJSON);
	ЗаписатьJSON(ЗаписьJSON, ДанныеСобытия);
	КомментарийСобытия = ЗаписьJSON.Закрыть();
	
	ЗаписьЖурналаРегистрации(
		ИмяСобытия,
		Уровень,
		Объект.Метаданные(),
		Объект,
		КомментарийСобытия
	);
	
КонецПроцедуры

Как настроить интеграцию с SIEM?

Современный подход – не хранить журнал только внутри 1С, а передавать события в реальном времени во внешнюю систему мониторинга. Это решает три задачи: защита журнала от модификации администратором 1С, корреляция событий с другими системами (AD, межсетевой экран, СКУД), долгосрочное хранение (3–5 лет) без раздувания базы 1С.

Типовая схема интеграции: регламентное задание каждые 5 минут читает новые записи журнала через ВыгрузитьЖурналРегистрации(), преобразует в формат CEF или Syslog, отправляет на коллектор по TCP/TLS. Если требуется глубокая кастомизация механизма, имеет смысл привлечь специалистов для задач по 1С:ERP.

Как организовать шифрование межфирменных потоков?

При консолидации данных между базами разных юрлиц или между распределёнными узлами РИБ возникает проблема защиты канала. По умолчанию обмены через планы обмена, HTTP-сервисы или КД 3.0 передают данные в открытом виде. В 2026 году отраслевой стандарт – обязательное шифрование на двух уровнях: транспортном (TLS 1.3) и прикладном (XML Encryption или подпись через КриптоПро).

Какие протоколы использовать?

  • TLS 1.3 – для всех HTTP/HTTPS-обменов между серверами 1С, обязательная проверка сертификатов
  • КриптоПро CSP 5.0 – для подписи и шифрования по ГОСТ 34.10-2018 при обмене с госорганами и контрагентами
  • VPN IPSec – для соединения территориально распределённых офисов
  • SFTP – для файловых обменов между организациями холдинга
// Шифрование пакета обмена перед отправкой между организациями

Функция ЗашифроватьПакетОбмена(ДанныеXML, СертификатПолучателя)
	
	МенеджерКриптографии = Новый МенеджерКриптографии("Infotecs Cryptographic Service Provider");
	МенеджерКриптографии.АлгоритмШифрования = "ГОСТ Р 34.12-2015 Кузнечик";
	
	ДвоичныеДанные = ПолучитьДвоичныеДанныеИзСтроки(ДанныеXML);
	
	Попытка
		ЗашифрованныеДанные = МенеджерКриптографии.Зашифровать(
			ДвоичныеДанные,
			СертификатПолучателя
		);
	Исключение
		ЗаписьЖурналаРегистрации(
			"Обмен.ШифрованиеПакета",
			УровеньЖурналаРегистрации.Ошибка,
			,
			,
			ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())
		);
		ВызватьИсключение;
	КонецПопытки;
	
	Возврат Base64Строка(ЗашифрованныеДанные);
	
КонецФункции

Как защитить файловые выгрузки?

Отдельный класс рисков – экспорт данных в Excel и CSV. Пользователь с правом на чтение может выгрузить весь регистр накопления и унести его на флешке. Контрмеры:

  1. Запрет сохранения отчётов на локальный диск через настройку «Сохранение результата отчёта»
  2. Watermarking – наложение водяных знаков с ФИО пользователя и датой на печатные формы
  3. DLP-интеграция – передача метаданных выгрузок в систему предотвращения утечек
  4. Контроль объёма – алерт при выгрузке более 1000 строк за раз
  5. Шифрование файлов выгрузки сертификатом получателя

Какие практики работают в реальных проектах?

Кейс 1: Холдинг с 12 юрлицами

Производственный холдинг с консолидированной базой 1С:ERP 3,2 ТБ внедрил трёхуровневую модель доступа: матрица «организация × подразделение × роль». Использовали 47 профилей групп доступа вместо стандартных 18. Время отклика типовых отчётов выросло на 12%, но риск пересечения данных между юрлицами снизился до нуля. Аналогичный подход применим и для проектов 1С:Бухгалтерия на Кодерион при объединении нескольких юрлиц.

Кейс 2: Сеть из 80 филиалов

Розничная сеть с РИБ из 80 узлов перевела все обмены на HTTPS с двусторонней аутентификацией по сертификатам. Каждый филиал получил собственный сертификат с привязкой к коду. Попытки несанкционированного подключения (3–5 в месяц) теперь автоматически блокируются на уровне сервера приложений.

Кейс 3: Интеграция с банком

Компания с оборотом 8 млрд руб/год внедрила сквозное шифрование платежных поручений от момента создания в 1С до отправки в банк через DirectBank. Каждый документ подписывается двумя сертификатами (бухгалтер + директор), шифруется сертификатом банка, передаётся по TLS 1.3. Время на отправку платежей выросло с 3 до 7 минут, но риск подделки исключён.

Безопасность – это не разовый проект, а непрерывный процесс. RLS, аудит и шифрование должны пересматриваться раз в квартал вместе с изменениями оргструктуры холдинга.

Сколько стоит внедрить полный контур безопасности?

По данным проектов 2025–2026 годов, ориентировочные трудозатраты на внедрение комплексной защиты данных в консолидированной базе 1С:ERP:

ЭтапЧасыСтоимость (руб)
Аудит текущей модели прав20–4060 000–160 000
Проектирование матрицы доступа30–6090 000–240 000
Настройка RLS и профилей40–80120 000–320 000
Внедрение расширенного аудита20–4060 000–160 000
Интеграция с SIEM40–80120 000–320 000
Шифрование обменов30–6090 000–240 000
Тестирование и документация20–4060 000–160 000

Итого: 200–400 часов работы с бюджетом 600 000 – 1 600 000 рублей в зависимости от сложности и количества организаций. Единых нормативов по срокам у 1С нет – цифры отражают практику внедренцев, а не официальную методику. Подобрать команду можно через найти разработчика 1С или разместить проект на фриланс 1С.

С чего начать защиту данных в 1С:ERP: чек-лист на 2026 год

Если полный контур безопасности данных в 1С:ERP ещё не выстроен, начните с шагов, которые дают максимальное снижение рисков при минимальных трудозатратах:

  1. Инвентаризация прав – выгрузите текущую матрицу ролей и профилей групп доступа, отметьте учётки с «Полными правами» (особенно RPA-роботов и интеграции).
  2. Базовый RLS по организациям – включите разграничение доступа между юрлицами: это закрывает самую частую претензию проверок.
  3. Журналирование критичных событий – настройте аудит входов, изменения прав, выгрузок и проведения документов на крупные суммы.
  4. Шифрование внешних каналов – переведите межфирменные обмены и публикации на TLS 1.3, подключите сертифицированный криптопровайдер.
  5. Регламент пересмотра – закрепите ежеквартальную ревизию матрицы прав и ежемесячный отчёт о неиспользуемых ролях.

Такой порядок закрывает большинство типовых нарушений уже в первые недели, не дожидаясь полного внедрения на 200–400 часов.

Как проверить, что RLS действительно работает: прогон за один вечер

Настройка RLS в 1С:ERP 2026 заканчивается не сохранением профиля, а проверкой под тестовыми пользователями. Ограничения регулярно протекают там, где их не ждут: в отчётах, в навигационных ссылках и в доработках с привилегированным режимом.

Порядок прогона:

  1. Разверните копию базы и создайте по одному пользователю на каждый профиль: test_buh_org1, test_sklad_org2, test_snab_all. Одного «универсального» тестового пользователя недостаточно – дырки видны только на срезах.
  2. Откройте журналы документов под каждым и сверьте количество строк с тем же списком под полными правами. Совпало – RLS не применился.
  3. Прогоните универсальный отчёт по регистрам накопления (расчёты с клиентами, товары на складах) с группировкой по организации. В списке организаций не должно быть чужих.
  4. Подставьте в строку адреса навигационную ссылку на чужой документ вида e1cib/data/Документ.РеализацияТоваровУслуг?ref=.... Ожидаемый результат – ошибка прав доступа, а не открытая форма.
  5. Проверьте боковые входы: «Связанные документы» у общего контрагента, история, избранное, полнотекстовый поиск, отчёты по рассылке (регламентное задание рассылки работает от имени её владельца, а не получателя).
  6. Найдите в конфигурации и расширениях УстановитьПривилегированныйРежим(Истина) и общие модули со свойством «Привилегированный» – внутри них RLS не действует вообще. Каждое вхождение в коде обменов и печатных форм разбирайте отдельно.

Быстрый тест на активность ограничений – два запроса в консоли под тестовым пользователем:

// 1) Без РАЗРЕШЕННЫЕ запрос должен упасть с ошибкой прав доступа,
//    если пользователю закрыта хотя бы часть записей
ВЫБРАТЬ КОЛИЧЕСТВО(*) КАК Кво
ИЗ Документ.РеализацияТоваровУслуг

// 2) С РАЗРЕШЕННЫЕ вернётся только доступный срез –
//    сравните число с результатом под полными правами
ВЫБРАТЬ РАЗРЕШЕННЫЕ КОЛИЧЕСТВО(*) КАК Кво
ИЗ Документ.РеализацияТоваровУслуг

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

Что делать со служебными учётками: роботы, обмены и HTTP-сервисы

Служебные пользователи – место, где ограничение прав, аудит и шифрование данных чаще всего расходятся с документацией: в схеме безопасности робот описан аккуратно, а в базе у него «Полные права» и пароль в тексте обработки. Любая интеграция с такими правами обнуляет весь контур RLS.

Что закрыть по каждой служебной учётке:

  1. Одна интеграция – один пользователь. Отдельные учётки под банк, маркетплейс, RPA-робота, обмен с розницей. Общая «Обмен» не даёт понять по журналу, кто именно выгрузил данные.
  2. Профиль вместо полных прав. Соберите профиль под задачу: роли на чтение и запись только нужных объектов плюс собственный набор доступных организаций. HTTP-сервисы и OData подчиняются RLS так же, как интерактивный сеанс, если код не переведён в привилегированный режим.
  3. Урезанный состав OData. Стандартный интерфейс по умолчанию открывает всё, к чему у пользователя есть права. Оставьте только объекты интеграции.
  4. Запрет лишних точек входа. В файле публикации отключите неиспользуемые web-сервисы, HTTP-сервисы и OData; на веб-сервере ограничьте доступ к каталогу публикации по IP-адресам систем-потребителей.
  5. Никаких внешних обработок. Снимите с служебного пользователя право открытия внешних отчётов и обработок и роль администратора – иначе через учётку робота в базу загрузят произвольный код.
  6. Пароли вне кода. Реквизиты подключения – в защищённом хранилище (например, в безопасном хранилище данных или внешнем secret-менеджере), с ротацией при смене администратора интеграции.
  7. Отдельный мониторинг. Настройте фильтр журнала по служебным пользователям и алерт на два события: вход вне окна расписания обмена и вход с неожидаемого IP или компьютера.
// Ограничение состава стандартного интерфейса OData
// Выполняется один раз, состав хранится в базе

Процедура ОграничитьСоставOData() Экспорт
	
	Состав = Новый Массив;
	Состав.Добавить(Метаданные.Справочники.Номенклатура);
	Состав.Добавить(Метаданные.Справочники.Партнеры);
	Состав.Добавить(Метаданные.Документы.ЗаказКлиента);
	
	УстановитьСоставСтандартногоИнтерфейсаOData(Состав);
	
	ЗаписьЖурналаРегистрации(
		"Безопасность.СоставOData",
		УровеньЖурналаРегистрации.Информация,
		,
		,
		"Состав интерфейса OData ограничен: " + Состав.Количество() + " объектов"
	);
	
 КонецПроцедуры

Если RPA-роботу нужен именно интерактивный вход, привяжите учётку к рабочему месту: в подписке на начало работы системы сверяйте ИмяКомпьютера() со списком разрешённых и завершайте сеанс с записью в журнал при несовпадении. Так украденный пароль робота не сработает с чужой машины.

Пользователь не видит нужный документ: как найти причину за 15 минут

После включения RLS в поддержку идут два типа жалоб: «пропали документы» и «ошибка доступа при открытии отчёта». Разбирать их наугад – потерянный день. Порядок проверки от самого частого к редкому:

  1. Перезаход в базу. Список доступных организаций обычно кэшируется в параметрах сеанса при старте. Права выдали, а пользователь работает в открытом с утра сеансе – изменения он не увидит. Первое действие: завершить сеанс и войти заново.
  2. Состав групп доступа. Откройте карточку пользователя и посмотрите не роли, а группы доступа и их профили. Права по разным группам складываются: если человек попал в «Бухгалтер ОРГ-1» и «Кладовщик ОРГ-2», он видит объединение, а не пересечение. Обратная ситуация – не попал ни в одну – даёт пустые списки везде.
  3. Записи в регистре доступа. Проверьте регистр сведений с доступными организациями по этому пользователю. Типовая ошибка – организацию завели, а строку не добавили: RLS работает корректно, данных просто нет.
  4. Незаполненные реквизиты в самих документах. Документ с пустой организацией или пустым подразделением под ограничением исчезает у всех, включая автора. Такие записи находятся запросом по пустой ссылке и заполняются до, а не после включения RLS.
  5. Отчёт без «РАЗРЕШЕННЫЕ». Ошибка вида «недостаточно прав» при формировании – признак того, что в схеме компоновки или во внешней обработке запрос читает таблицу напрямую. Правится добавлением ключевого слова в запрос набора данных.
  6. Перезаписанный шаблон после обновления. Если проблема появилась ровно после установки релиза, сравните текст шаблона ограничений с эталоном из вашей документации: типовые шаблоны при обновлении конфигурации возвращаются к поставке вместе с доработанным условием.

Точечная проверка конкретного документа – один запрос в консоли под учёткой жалующегося пользователя:

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

Разбор фиксируйте в одной таблице: дата, пользователь, объект, причина, что изменили. Через месяц-два такой список показывает системные дыры – обычно это две-три организации с незаполненными реквизитами и один профиль, собранный неаккуратно.

Как выдавать и снимать доступы, чтобы матрица прав не разъехалась за полгода

Ограничение прав, аудит и шифрование данных держатся не на разовой настройке, а на дисциплине выдачи доступов. Типичная картина через полгода после внедрения: 40 профилей превратились в 90, половина создана «под сотрудника», а уволенные полгода назад люди числятся активными.

Рабочий регламент состоит из пяти правил.

  1. Профиль привязан к должности, а не к человеку. Заявка звучит «доступ как у кладовщика склада №3», а не «сделайте как у Иванова». Новый профиль создаётся, только если появилась новая должностная функция – это решение владельца процесса, а не администратора.
  2. Заявка с двумя подписями. Руководитель подразделения указывает профиль и перечень организаций, владелец данных подтверждает. Отправная точка – приказ о приёме или переводе, а не сообщение в мессенджере. Хранить заявки удобно прямо в базе задачами: тогда к любой строке матрицы прав есть основание.
  3. Отключение в день увольнения. Учётку блокируют (снимают признак входа в программу), но не удаляют – удалённый пользователь ломает читаемость журнала регистрации и историю изменения объектов. Отдельный триггер – перевод между юрлицами: доступ к прежней организации снимают, иначе матрица тихо расширяется.
  4. Временный доступ с датой окончания. Подрядчики, аудиторы, замещение на время отпуска – всегда с явным сроком. Регламентное задание раз в сутки проверяет дату и блокирует просроченные учётки с записью в журнал. Без автоматики «временный» доступ живёт годами.
  5. Ежемесячный отчёт по трём срезам. Кто не входил в базу 60 дней и старше; у кого профиль с полными правами; какие профили не назначены никому. Первый список идёт на блокировку, второй – на разбор, третий – на удаление.

Раз в квартал добавляйте подтверждение доступов руководителями: выгрузка «сотрудник – профиль – организации» уходит в подразделения, ответ «подтверждаю / снять у этих» возвращается письменно. Процедура занимает пару дней и снимает большую часть накопленных лишних прав – заодно это готовый комплект документов для внешнего аудита, который иначе собирают в авральном режиме за неделю до проверки.

Как обновления и релизы 1С:ERP влияют на настроенную безопасность

1С:ERP – это конфигурация на поддержке, и релизы для неё выходят регулярно, несколько раз за год, не считая исправительных версий. Каждое обновление – это не только новые возможности учёта, но и потенциальная дыра в контуре доступа: в базе появляются объекты метаданных, о которых ваша матрица прав ничего не знает.

Три сценария, по которым безопасность «съезжает» после установки релиза:

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

Регламент обновления с учётом безопасности

  1. Перед установкой прочитайте описание релиза и отдельно – раздел про настройки пользователей и прав: что добавлено, что переименовано, какие роли изменились.
  2. Обновляйте сначала копию базы, а не рабочую. На копии сразу прогоняйте тест-план под тестовыми учётками – тот самый, что собран при внедрении RLS.
  3. Сравните шаблоны ограничений и состав профилей до и после: расхождения выписывайте списком и разбирайте до переноса на продуктив.
  4. Проверьте новые объекты метаданных на предмет того, попадают ли они под ваши виды доступа, и при необходимости расширьте схему.
  5. После обновления перепроверьте периметр интеграций: состав OData, публикацию на веб-сервере, работоспособность криптопровайдера и обменов по TLS. Обновление платформы иногда меняет поведение проверки сертификатов.
  6. Зафиксируйте результат: номер релиза, дата, кто проверял, какие отклонения нашли. Это же станет доказательной базой при внешнем аудите.

Практическое правило: обновление консолидированной базы – это мини-проект на несколько дней с тестовым контуром, а не операция «в ночь на понедельник». Пропущенная проверка прав после релиза обходится дороже, чем задержка обновления на неделю.

Часто задаваемые вопросы

Насколько RLS замедляет работу 1С:ERP?

При корректной настройке с использованием индексированных регистров и кэширования замедление составляет 8–15%. При неоптимальных условиях с вложенными подзапросами замедление может достигать 40–60%, что неприемлемо для продуктивной эксплуатации.

Можно ли использовать стандартный журнал регистрации для аудита по ФЗ-152?

Частично. Стандартный журнал фиксирует базовые события, но для полного соответствия требованиям ФСТЭК нужно расширить состав логируемых событий и обеспечить защищённое хранение журнала вне базы 1С – обычно через интеграцию с SIEM-системой.

Какой сертифицированный криптопровайдер выбрать?

Для большинства задач подходит КриптоПро CSP 5.0 – он сертифицирован ФСБ, поддерживает ГОСТ 34.10-2018 и интегрирован с типовыми механизмами 1С. Альтернатива – ViPNet CSP для случаев работы с защищёнными сетями.

Нужно ли шифровать обмены внутри РИБ?

Если узлы РИБ соединены через интернет – обязательно (TLS 1.3 минимум). Внутри локальной сети формально не требуется, но рекомендуется для защиты от внутренних угроз и упрощения прохождения аудитов.

Как часто пересматривать матрицу прав доступа?

Минимум раз в квартал, а также при любых изменениях оргструктуры: приём/увольнение сотрудников, появление новых юрлиц, изменение бизнес-процессов. Автоматический отчёт о неиспользуемых правах должен формироваться ежемесячно.

Что делать, если внешний аудит выявил нарушения?

Составить план устранения с приоритизацией по критичности, начиная с разграничения доступа между юрлицами и журналирования критичных операций. Параллельно подготовить документацию: модель угроз, описание мер защиты, регламенты администрирования.

Можно ли защитить данные от администратора 1С?

Полностью – нет, администратор всегда имеет техническую возможность доступа. Но можно минимизировать риски: разделить роли (администратор ИТ ≠ администратор данных), включить аудит действий администраторов с выгрузкой в независимую систему, использовать принцип «двух пар глаз» для критичных операций.

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

Читайте также: внедрение и поддержка 1С:ERP

Читайте также