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