Подробный гайд по внедрению мандатного разграничения доступа (МРД) в 1С
Мандатное разграничение доступа (МРД) в экосистеме 1С — это механизм, который выходит за рамки стандартных ролей и записей регистров (RLS). Если RLS отвечает на вопрос «Какие записи видит пользователь?», то МРД отвечает на вопрос «С какими данными определенной категории секретности имеет право работать пользователь?».
В классической теории (модель Белла — ЛаПадулы) это подразумевает присвоение объектам грифов секретности, а субъектам — уровней допуска. В 1С это чаще всего реализуется через изоляцию данных по грифу секретности (или категории).
«Все примеры кода, названия объектов и уровни доступа являются вымышленными и служат исключительно для демонстрации работы модели безопасности»
1. Теория и отличие от RLS
RLS (Record Level Security) — ограничение на уровне записей. Например, «Менеджер видит только контрагентов из своей группы». Это ограничение задается шаблонами (WHERE).
МРД (Mandatory Access Control) — ограничение на уровне свойств данных, а не структуры подчиненности.
- Объект доступа: Документ, справочник.
- Метка (Мандат): Реквизит объекта, например,
ГрифДоступности(«Общий», «Конфиденциально», «Секретно»). - Допуск субъекта: Уровень доступа пользователя («Пользователь имеет допуск к данным с грифом не выше "Конфиденциально"»).
Главный принцип:
Если у объекта стоит метка «Секретно», а у пользователя допуск «Конфиденциально», пользователь не видит этот объект ни при каких условиях, даже если он администратор БД (с точки зрения бизнес-логики), если только ему явно не выдан допуск.
2. Архитектура решения
Для реализации МРД в 1С необходимо модифицировать конфигурацию.
Шаг 1. Подготовка метаданных
Вам нужен перечень уровней доступа (грифов). Создайте Перечисление или Справочник (если грифы должны быть настраиваемыми).
Лучше использовать Перечисление (Enum), так как на него можно ссылаться в коде и шаблонах, и его сложнее сломать.
Создайте перечисление УровниДоступа:
ОткрытыеДанные(Уровень 0)Конфиденциально(Уровень 1)СтрогоКонфиденциально(Уровень 2)
Шаг 2. Добавление реквизита-мандата объектам
Для каждого объекта метаданных (Справочники, Документы, Регистры сведений), который должен подчиняться МРД, необходимо добавить реквизит.
- В ветке метаданных выберите нужный справочник (например,
Контрагенты). - Добавьте реквизит
ГрифДоступности. - Тип:
ПеречислениеСсылка.УровниДоступа.
Заполнение:
В свойствах реквизита установите «Заполнять из данных заполнения» или «Значение заполнения» = ОткрытыеДанные (по умолчанию безопасный минимум).
Важно:
Если используется режим совместимости, убедитесь, что реквизит участвует в механизме RLS (свойство «Использовать» должно быть «Для всех» или «Независимо»).
Шаг 3. Создание регистра допусков пользователей
Нужен регистр сведений, где будет храниться связка Пользователь -> УровеньДоступа.
Создайте Регистр сведений ДопускиПользователей.
- Измерение 1:
Пользователь(Тип:СправочникСсылка.ПользователиилиСправочникСсылка.Сотрудники). - Ресурс:
УровеньДоступа(Тип:ПеречислениеСсылка.УровниДоступа).
Альтернативный вариант:
Хранить допуск в реквизите справочника «Пользователи». Это проще, если используется стандартный справочник.
Шаг 4. Программная реализация проверки (Серверная логика)
Главная задача МРД — предотвратить утечку на этапе чтения/записи. Лучше всего это работает в привязке к RLS или в модулях объектов (подписки на события).
Вариант А: Гибрид с RLS (Самый мощный способ)
Вы создаете шаблоны ограничений, которые фильтруют списки на уровне СУБД.
Пример шаблона для справочника Контрагенты:
// В шаблоне ограничения доступа к данным
// Условие: Пользователь имеет доступ к грифу
ГрифДоступности В (ВЫБРАТЬ РАЗРЕШЕННЫЕ УРОВНИ ДЛЯ ТЕКУЩЕГО ПОЛЬЗОВАТЕЛЯ)
Но так как RLS не умеет просто так выбирать «разрешенные уровни» из регистра, обычно пишут общую функцию, которая возвращает массив разрешенных грифов.
- Создайте Общий модуль
МРД_Служебный.
2. Создайте функцию:
Функция ПолучитьСписокРазрешенныхГрифов(Пользователь = Неопределено) Экспорт
Если Пользователь = Неопределено Тогда
Пользователь = Пользователи.АвторизованныйПользователь();
КонецЕсли;
// Получаем допуск пользователя
Допуск = РегистрыСведений.ДопускиПользователей.ПолучитьПоследнее(ТекущаяДата(), Новый Структура("Пользователь", Пользователь));
Если Допуск = Неопределено Тогда
// Если допуск не задан - считаем, что доступ открыт только к несекретным данным
Возврат Новый Массив; // или массив с одним значением ОткрытыеДанные
КонецЕсли;
УровеньПользователя = Перечисления.УровниДоступа.Индекс(Допуск.УровеньДоступа);
МассивРазрешенных = Новый Массив;
Для Каждого Уровень Из Перечисления.УровниДоступа Цикл
Если Перечисления.УровниДоступа.Индекс(Уровень) <= УровеньПользователя Тогда
МассивРазрешенных.Добавить(Уровень);
КонецЕсли;
КонецЦикла;
Возврат МассивРазрешенных;
КонецФункции
3. В шаблоне ограничения RLS для справочника Контрагенты пишем:
ГрифДоступности В (&РазрешенныеГрифы)
Где РазрешенныеГрифы — параметр сеанса.
4. В модуле сеанса (УстановкаПараметровСеанса) заполняем этот параметр при старте:
ПараметрыСеанса.РазрешенныеГрифы = МРД_Служебный.ПолучитьСписокРазрешенныхГрифов();
Важно:
Данный подход работает только при использовании СУБД, поддерживающей временные таблицы или подзапросы (SQL, PostgreSQL). В файловой базе RLS работает медленнее, но тоже поддерживается через вычисления на клиенте/сервере (зависит от платформы).
Вариант Б: Контроль в формах и при записи (Без RLS)
Если нет возможности использовать RLS (например, сложная логика), придется "оборачивать" все чтения.
1. Запись: Подписка на событие ОбработкаПроверкиЗаполнения или ПередЗаписью.
Проверяем, если пользователь пытается записать объект с грифом выше его допуска — отменяем операцию.
Процедура МРД_ПередЗаписью(Источник, Отказ) Экспорт
Если Источник.ГрифДоступности > ТекущийДопускПользователя Тогда
Сообщить("Недостаточно прав для сохранения объекта с данным грифом!");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
2. Чтение:
При открытии форм списка необходимо модифицировать запросы динамического списка.
В обработчике ПриСозданииНаСервере формы списка добавляем установку отбора:
Список.Отбор.Элементы.Добавить(Тип("ОтборЭлемента"), "ГрифДоступности", ВидСравнения.ВСписке, МассивРазрешенных);
Минусы:
Легко забыть про какую-то форму, регистры или отчеты. СКД (Система Компоновки Данных) придется настраивать вручную везде.
Шаг 5. Ведение учёта допусков
Разработайте документ или обработку «Изменение допусков», которая пишет записи в регистр ДопускиПользователей.
Обязательно настройте права, чтобы доступ к этому регистру имел только «Режимный отдел» (Security Officer), а не администраторы.
3. Нюансы реализации
3.1. Иерархия грифов
В примере выше использовалась логика «если у тебя допуск 2, ты видишь всё с грифом 0, 1 и 2».
Если требуется иная модель (например, разные отделы видят только свои грифы, «Секретно» не лучше, чем «Конфиденциально», а просто другое), логика функции ПолучитьСписокРазрешенныхГрифов должна быть другой. Обычно используется принцип «Выше или равно».
3.2. Проблема "Записи чужих данных" (Write Access)
МРД должно работать в обе стороны.
- No Read Up (Простое правило безопасности): Пользователь не может читать документы, секретность которых выше его уровня.
- No Write Down (Правило целостности): Пользователь с высоким допуском не может записать секретные данные в несекретный документ или изменить гриф с «Секретно» на «Открытый» (чтобы предотвратить утечку).
В 1С это решается контролем смены грифа:
Процедура МРД_ПередЗаписью(Источник, Отказ) Экспорт
// Исключаем проверку для новых (еще не записанных в базу) документов/элементов
Если Источник.ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// 1. Получаем старое значение из базы данных, чтобы проверить факт изменения
СтарыйГриф = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Источник.Ссылка, "ГрифДоступности");
НовыйГриф = Источник.ГрифДоступности;
Если НовыйГриф <> СтарыйГриф Тогда
// 2. Преобразуем перечисления в числовые уровни (0, 1, 2) для сравнения
УровеньСтарый = ПолучитьЧисловойУровень(СтарыйГриф);
УровеньНовый = ПолучитьЧисловойУровень(НовыйГриф);
// Модель Белла-ЛаПадулы: Запрет "записи вниз" (понижения уровня секретности)
Если УровеньНовый < УровеньСтарый Тогда
// Проверяем право на изменение грифа (обычно только у Режимного отдела)
Если Не РольДоступна("ИзменениеГрифовСекретности") Тогда
ВызватьИсключение "Операция заблокирована! Запрещено снижать гриф секретности для предотвращения утечки данных.";
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
3.3. Аудит (Журнал регистрации)
МРД немыслимо без аудита.
- Включите журнал регистрации для справочников и документов с грифом.
- Логируйте смену грифа обязательно через платформенный журнал или собственный регистр сведений.
- Помните: Пользователь без допуска не должен видеть в журнале регистрации даже названия секретных объектов, если это противоречит политике.
3.4. Производительность
- Если у вас миллионы записей, индекс по реквизиту
ГрифДоступностиобязателен. - Если используется гибрид с RLS, убедитесь, что запрос в шаблоне RLS сконвертирован в быстрый
INилиJOIN.
4. Типовые ошибки
- Защита только списков. Разработчик прячет документы в списке, но забывает про:
- Поиск (Полнотекстовый поиск) — строка может найтись, но не открыться (это плохо).
- Отчеты (СКД) — если в СКД не встроена проверка МРД, пользователь увидит агрегированные суммы по секретным данным в отчете.
- Оборотные регистры — движения документов могут копировать секретные данные в несекретные регистры, если не аккуратно писать код.
- Хранение грифа "в строке", а не в шапке. Для табличных частей нужно либо наследовать гриф шапки, либо (в сложных системах) вводить гриф для каждой строки ТЧ.
- Игнорирование прав на интерактивную работу. Пользователь может через "Все функции..." или через COM-соединение получить данные, если RLS не настроен на уровне СУБД. Всегда сочетайте "Роли" + "RLS" + "Проверки в коде".
5. Важно
Внедрение МРД в 1С — это доработка типового или самописного функционала, требующая дисциплины.
Минимальный набор для старта:
- Перечисление
УровниДоступа. - Реквизит
Грифу ключевых объектов. - Регистр
Допуски. - Параметр сеанса с массивом доступных грифов.
- Шаблоны RLS на чтение (и, желательно, на изменение).
Это позволит построить эшелонированную защиту, соответствующую требованиям регуляторов (ФСТЭК, 152-ФЗ) для государственных и коммерческих нужд.
Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.