Как построить модель ролей доступа к цифровому паспорту объекта на производственном предприятии

Цифровой паспорт промышленного объекта собирает в едином репозитории техническую документацию, историю эксплуатации, результаты обследований и данные мониторинга. От того, как организовано разделение прав доступа, зависит, смогут ли инженеры оперативно находить актуальные чертежи, не потеряется ли история изменений при смене персонала и не станет ли система «черным ящиком», которому никто не доверяет. Грамотная модель ролей — это не настройка галочек в интерфейсе, а отражение реальных бизнес-процессов и зон ответственности.

Почему стандартные настройки «из коробки» не работают

Большинство платформ цифровых паспортов предлагают базовые роли: администратор, редактор, наблюдатель. На практике это приводит к двум крайностям. Либо ключевые инженеры не могут загрузить актуальный чертеж после ремонта, потому что у них прав «только чтение», либо операторы ЦРУ получают права редактирования паспортных данных и случайно меняют классификацию оборудования, что ломает отчётность по промышленной безопасности.

Причина проста: типовые роли не учитывают матрицу ответственности конкретного предприятия. В ГОСТ Р 57826-2017 и отраслевых методиках (например, РД 03-615-03 для нефтегаза) зафиксированы требования к составу паспорта и порядку его ведения, но не задан жесткий набор ролей ИС. Каждая организация должна вывести их из своей структуры подразделений, регламентов эксплуатации и модели угроз.

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

Базовый подход — RBAC (Role-Based Access Control) с элементами разграничения по объектам и атрибутам. Ключевые принципы:

• Принцип минимальных привилегий. Роль даёт только те действия, которые необходимы для выполнения должностных инструкций. Никаких «на всякий случай».
• Разделение обязанностей (SoD). Один и тот же сотрудник не может и инициировать изменение паспортных данных, и утверждать его, и загружать исполнительную документацию без независимой проверки.
• Привязка к бизнес-ролям, а не к людям. Роль «Инженер по техническому диагнозированию» существует независимо от того, Иван Петров или Мария Сидорова её исполняет. При смене сотрудника меняется только назначение роли.
• Объектное разграничение. Доступ к паспорту котла №3 не подразумевает доступ к паспорту трубопровода ГПА. Права назначаются на уровень объекта или группы объектов.
• Жизненный цикл записи. Разные этапы (создание, актуализация, архивация, вывод из эксплуатации) могут требовать разных наборов прав и утверждающих лиц.

Типовая матрица ролей для производственного предприятия

Ниже приведён обобщённый набор ролей, который встречается на крупных и средних предприятиях с развитой иерархией технического управления. Названия могут отличаться, но функциональные границы стабильны.

Роль в системе	Бизнес-функция	Ключевые действия с цифровым паспортом	Ограничения
Администратор паспорта (Паспортовед)	Централизованное ведение реестра паспортов, контроль полноты и сроков	Создание карточки объекта, назначение ответственных, контроль этапов жизненного цикла, архивация, формирование отчётов для надзорных органов	Не редактирует технические параметры оборудования, не загружает исполнительскую документацию
Технический куратор объекта (Ответственный за объект)	Инженер эксплуатирующего подразделения, курирующий конкретный объект	Инициирование изменений паспортных данных, загрузка отчётов обследований, подтверждение актуальности данных, согласование изменений	Не может изменить классификацию объекта или его статус без согласования с ТБ/ПБ
Инженер по техническому диагнозированию / НДК	Проведение обследований, расчёт ресурса, формирование заключений	Загрузка протоколов обследований, отчётов НДК, расчётов остаточного ресурса, заключений о пригодности	Только чтение паспортных данных объекта; не может менять базовые атрибуты (год выпуска, заводской номер и т.д.)
Инженер ПБ / ТБ / Промышленная безопасность	Экспертиза изменений, контроль соответствия требованиям нормативных документов	Согласование/отклонение изменений классификации, категории опасности, режима эксплуатации; подписание актов экспертизы	Не загружает исходные данные обследований; работает только с этапом согласования
Ремонтная организация / Подрядчик (внешний доступ)	Выполнение капитального ремонта, модернизации, консервации	Загрузка исполнительской документации по этапам работ, актуализация параметров после ремонта (в рамках согласованного объёма)	Доступ только к паспортам объектов в ремонте; только на период работ; без прав удаления и изменения истории
Диспетчер / Оператор ЦРУ	Оперативный мониторинг параметров, связь с SCADA/АСУ ТП	Чтение актуальных паспортных параметров, привязка тегов телеметрии к атрибутам паспорта	Никаких прав записи в паспорт; только чтение и техническая привязка тегов
Аудитор / Инспектор надзорного органа (внешний доступ)	Плановые и внеплановые проверки	Чтение полной истории изменений, выгрузка пакета документов для проверки, верификация целостности данных	Только чтение; без прав экспорта в редактируемых форматах (только PDF/подписанные XML)
Системный администратор ИС	Техническое сопровождение платформы	Настройка ролей, управление учётными записями, бэкапы, мониторинг журналов аудита, обновления ПО	Нет доступа к содержимому паспортов как к предметной области; работает только с метаданными и инфраструктурой

Этапы внедрения модели ролей: от аудита к эксплуатации

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

1. Инвентаризация объектов и процессов. Составьте реестр всех объектов, подлежащих паспортизации, с указанием explotационного подразделения, категории опасности, наличия экспертного заключения и текущего статуса (эксплуатация, консервация, строительство, утилизация).
2. Сбор матрицы ответственности (RACI). Для каждого типа действия с паспортом (создание, изменение параметров, загрузка НДК, согласование, архивация) зафиксируйте: кто Responsible (исполняет), кто Accountable (утверждает), кто Consulted (даёт заключение), кто Informed (получает уведомление). Это делается совместно с ТБ/ПБ, производством и IT.
3. Проектирование ролевой модели. На основе RACI сформулируйте роли системы. Избегайте ролей-дублеров: если «Инженер ПБ» и «Эксперт промышленной безопасности» делают одно и то же — объедините. Если один человек формально совмещает функции — в системе это должны быть две разные роли, назначаемые независимо.
4. Определение матрицы прав (Permission Matrix). Для каждой роли перечислите CRUD-операции по типам сущностей: карточка объекта, паспортные атрибуты, файлы-документы, этапы жизненного цикла, ссылки на внешние системы. Зафиксируйте в таблице «Роль × Объект × Действие».
5. Настройка в тестовой контуре. Разверните модель на стенде. Прогоните сценарии: «Капитальный ремонт котла», «Перевод в консервацию», «Смена категории опасности», «Внеплановая проверка Ростехнадзора». Проверьте, что ни один сценарий не требует «админских» прав для штатных действий.
6. Пилот на 10–15 объектах. Выберите представительную выборку: разные категории опасности, разные эксплуатирующие подразделения, есть/нет внешних подрядчиков. Работайте 1–2 месяца. Соберите обратную связь: где не хватает прав, где есть избыток, где непонятен интерфейс.
7. Раскатка и обучение. После доработки — массовое назначение ролей через интеграцию с HR/AD (LDAP/SCIM), а не вручную. Проведите краткие инструктажи для каждой роли: что я могу, чего не могу, куда писать, если нужно исключение.
8. Постоянный аудит и пересмотр. Раз в квартал: отчёт «Кто имел доступ, но не заходил 90 дней», «Роли с конфликтами SoD», «Объекты без технического куратора». Раз в год — полный пересмотр модели при реорганизации, изменении нормативной базы или введении новых типов объектов.

Распространённые ошибки и их последствия

• Роль «Суперадмин» у главного механика. Результат: паспортные данные меняются без следа, история исправлений теряется, при проверке невозможно доказать достоверность. Решение: у главного механика роль «Технический куратор» с правом инициирования изменений, но без права прямой правки утверждённых полей.
• Единая роль «Инженер» для всех технических специалистов. Результат: инженер НДК случайно меняет год ввода в эксплуатацию, инженер ПБ не может отклонить изменение, потому что у него те же права. Решение: разделение на «Инженер НДК» (загрузка отчётов) и «Инженер ПБ» (согласование изменений классификации).
• Отсутствие роли внешнего подрядчика. Результат: подрядчику дают общую учётку «Ремонт» с правами редактора. Он видит паспорта всех объектов цеха, может удалить файлы, нет аудита его действий. Решение: отдельная роль с объектным доступом, временным действием, только добавление файлов в раздел «Исполнительская документация», обязательная ЭЦП на загружаемые пакеты.
• Назначение ролей на людей, а не на должности. Результат: ушел сотрудник — права висят год. Пришел новый — ждёт настройки недели. Решение: роли привязаны к должностям в HR-системе, синхронизация по расписанию, автоматический отзыв при увольнении/переводе.
• Игнорирование разделения по этапам жизненного цикла. Результат: после консервации объекта инженеры продолжают загружать отчёты НДК в активный паспорт, хотя объект переведён в архив. Решение: автоматическая смена набора доступных действий при смене статуса объекта (например, статус «Консервация» — только чтение и загрузка отчётов по консервации).

Контроль соответствия и аудит доступа

Модель ролей — не статичный артефакт. Необходимы регулярные процедуры верификации:

• Аттестация прав (Access Recertification). Раз в полгода руководители подразделений подтверждают актуальность назначений ролей своим подчиненным. Автоматизированный workflow: система присылает список «Ваши сотрудники с ролями X, Y, Z — подтвердите или отозовите».
• Анализ журналов аудита (SIEM/встроенный). Поиск аномалий: массовое скачивание файлов, попытки доступа к чужим объектам, изменения в нерабочее время, каскадные отказы в доступе. Настройте корреляционные правила.
• Проверка SoD-конфликтов. Автоматический отчёт: учётные записи, имеющие одновременно роли «Инициатор изменения» и «Утверждающий» на одном объекте. Такие конфликты разрешаются либо организационно (разные люди), либо компенсирующим контролем (двойная подпись, обязательный комментарий).
• Инвентаризация «привилегированных» доступов. Отдельный реестр ролей с правами администрирования паспортов, управления ролями, прямого доступа к БД. Каждое назначение — с обоснованием, сроком действия и ответственным за контроль.

Сценарии выбора: как адаптировать модель под ваше предприятие

Единого шаблона не существует. Ориентируйтесь на следующие факторы:

• Количество объектов и их разнородность. 50 однотипных насосов — можно обобщить роли по цехам. 500 объектов разных типов (котельные, трубопроводы, резервуары, компрессорные станции) — нужны роли с привязкой к типам объектов и категориям опасности.
• Наличие внешних подрядчиков. Если капитальные ремонты выполняет свой ремонтный цех — роль «Подрядчик» может не понадобиться, её функции перейдут к «Ремонтному мастеру». Если работают 10 внешних организаций — роль «Внешний подрядчик» с объектным и временным доступом обязательна.
• Уровень интеграции с АСУ ТП / SCADA / EAM. Если паспорт — источник справочных данных для АСУ ТП (диапазоны датчиков, паспортные параметры для аварийной защиты), роль «Диспетчер/Интегратор» с правом настройки маппинга тегов становится критичной.
• Требования регулятора. В нефтегазе и химии Ростехнадзор ожидает видимость полной истории изменений с ЭЦП ответственных лиц. Модель ролей должна гарантировать, что каждое изменение паспортных данных имеет цепочку: инициатор → загрузка документа → ЭЦП куратора → ЭЦП ПБ → фиксация в журнале. Никакая роль не должна иметь права «переписать историю».
• Зрелость процессов управления документами. Если на предприятии внедрена ЕДО (1С:Документооборот, Directum, DIADOC) и все подписания идут через неё, роли в паспорте могут делегировать подписание во внешнюю систему. Если ЕДО нет — в паспорте нужны встроенные механизмы ЭЦП и маршрутов согласования, что усложняет модель ролей.

Практический следующий шаг

Начните с заполнения простой таблицы для 3–5 наиболее критичных объектов. Столбцы: Действие с паспортом (создание, изменение паспортного параметра, загрузка НДК, согласование, архивация) × Должность/Подразделение × R/A/C/I. Это займёт 2–3 часа совместной работы паспортоведа, инженера ПБ и представителя эксплуатирующего цеха. Результат — основа для проектирования ролевой матрицы в системе. Не пытайтесь сразу охватить все объекты: пилот на представительной выборке покажет 80% проблем за 20% усилий.

FAQ

Нужно ли создавать отдельную роль для чтения паспорта «всем сотрудникам»?

Нет. Открытый доступ ко всем паспортам нарушает принцип минимальных привилегий и создаёт риск утечки информации об объектах повышенной опасности. Давайте доступ на чтение только тем, чья работа требует обращения к паспортным данным (диспетчеры, планировщики ремонтов, инженеры НДК). Для разовых запросов используйте процедуру выдачи временного доступа по заявке.

Как быть, если один сотрудник совмещает функции инженера НДК и инженера ПБ?

В системе назначьте ему обе роли. Но настройте рабочие процессы так, чтобы действия требовали переключения контекста или дополнительного подтверждения (например, повторная аутентификация при смене роли «Исполнитель» на «Утверждающий»). В журналах аудита должно быть видно, в какой роли выполнялось каждое действие. Организационно зафиксируйте в должностной инструкции порядок разделения этих функций во времени.

Можно ли использовать группы Active Directory вместо ролей в приложении?

Можно и часто удобно для аутентификации и первичного назначения (Group-Based Access Control). Но внутри приложения всё равно нужны свои роли (Application Roles), отображающие предметные полномочия. AD-группа «ИНЖЕНЕР_ЦЕХ_1» маппится на роль «Технический куратор» для объектов цеха 1. Это даёт гибкость: при реорганизации меняете маппинг, не переписывая логику приложения.

Что делать с доступом уволенного сотрудника, если синхронизация с HR идёт раз в сутки?

Настройте процесс «срочного отзыва»: у вользователя есть кнопка/скрипт «Заблокировать доступ сразу», который отзывает все активные сессии и отключает учётку в приложении до следующей синхронизации. Это компенсирующий контроль на случай задержки HR-процесса.

Как документировать модель ролей для аудитора?

Подготовьте пакет: 1) Матрица прав (Роль × Объект × Действие) в Excel/PDF с версией и датой утверждения. 2) Описание бизнес-процессов с паспортом (BPMN или текстовые регламенты) со ссылками на роли. 3) Протокол тестирования модели на стенде (сценарии, результаты, найденные дефекты). 4) Журнал изменений модели ролей (кто, когда, зачем изменил). 5) Отчёт последней аттестации прав. Это покрывает запросы и Ростехнадзора, и внутренней аудита, и ISO 27001.