Доступ и контроль
Сотрудник не видит того, чего ему нельзя, — и не ищет там, где для него пусто
Права выдаются не на модуль целиком, а на отдельный объект: справочник, вкладку карточки, конкретное состояние в статусной модели. Пункт меню, за которым сотруднику нечего читать, из навигации исчезает; вкладка, закрытая правами, не отрисовывается; строки чужого подразделения не попадают в выборку. Каждое изменение прав и данных остаётся в журналах.
ОНиВД — обеспечение непрерывности и восстановления деятельности; англоязычное обозначение — Continuity of Бизнес-подразделение (CoB).
Модель прав: объект, действие и, при необходимости, фильтр
Право — это тройка «объект защиты, действие, признак выданности». Объектом может быть не только тип записи, но и один конкретный справочник, одна вкладка карточки или одно состояние статусной модели. Право с непустым условием фильтрации превращается в право на подмножество строк.
| Тип объекта защиты | Действия | Что закрывает |
|---|---|---|
| Справочники | Читать · Изменять · Добавлять · Удалять · Фильтровать | Справочные записи модуля: площадки, резервные стратегии, привязки сотрудников к подразделениям. |
| Отчёты | Читать | Раздел отчётности целиком. |
| Тестирование кризисной команды | Читать · Изменять | Карточки кризисных учений. |
| Статусы справочников | Читать · Изменять · Выполнять | Переходы согласования справочных записей. |
| План | Читать · Изменять | Разделы карточки плана непрерывности. |
| Статусы плана | Читать · Изменять · Выполнять | Каждое состояние плана — отдельно. |
| Статусы тестов | Читать · Изменять · Выполнять | Каждое состояние теста — отдельно. |
| Тестирование офиса | Читать · Изменять | Карточки тестов офисов и площадок. |
| Поставщик | Читать · Изменять | Разделы карточки поставщика. |
| Тестирование поставщика | Читать · Изменять | Карточки тестов поставщиков. |
| Аттестация поставщика | Читать · Изменять | Карточки аттестации поставщиков. |
| Система или приложение | Читать · Изменять | Разделы карточки системы. |
| Тестирование систем или приложений | Читать · Изменять | Карточки тестов систем. |
Права выдаются на отдельный объект, а не только на его тип
Администратор может открыть чтение одной вкладки карточки плана и оставить закрытыми остальные; разрешить выполнение перехода в одно конкретное состояние и не разрешить в соседнее; открыть один справочник и не открывать другой. Это то, чего обычно не хватает в моделях «роль — модуль»: разграничение проходит там, где проходит зона ответственности, а не там, где проходит граница подсистемы.
Роли: набор в поставке и то, как он ложится на вашу оргструктуру
Роль — это именованный набор прав. В поставке восемь ролей, включая системную; каждая привязывается к сотрудникам и редактируется администратором безопасности. Соответствие подразделениям ниже — методический ориентир: роли настраиваются под вашу структуру.
| Роль | Обычно это | Зона ответственности |
|---|---|---|
| Администратор безопасности | Служба информационной безопасности | Роли, права, учётные записи, журнал событий безопасности и выгрузка для процессов управления доступом. |
| Руководитель подразделения | Руководитель бизнес-подразделения — владельца критичного процесса | Планы и аттестация своей ветки оргструктуры. Видимость строк ограничена этой веткой. |
| Координатор восстановления подразделения | Назначенный в подразделении ответственный за непрерывность | Наполнение планов, планирование и проведение тестов подразделения. Видимость строк ограничена веткой. |
| Координатор непрерывности | Служба непрерывности бизнеса или операционных рисков | Сводная картина по организации, согласование, получение уведомлений о смене статусов и о завершении аттестаций. |
| Менеджер приложения | Владелец ИТ-системы | Карточка системы и тесты переключения на резервную схему. |
| DR-координатор приложения | Ответственный за аварийное восстановление системы | Планирование и проведение тестов восстановления по своим системам. |
| Менеджер поставщика | Ответственный за отношения с внешним контрагентом | Карточка поставщика, тесты поставщика и его годовая аттестация. |
| Системная роль | Служебная | Базовые права, необходимые для работы приложения. |
Роли добавляются, переименовываются и удаляются, права внутри роли меняются, роли назначаются и снимаются с сотрудников. Всё это делается в интерфейсе администратора безопасности и попадает в журнал событий безопасности.
Шесть действий и то, что каждое из них закрывает
Действие — вторая половина права. Разделение «читать» и «изменять» очевидно; ценность модели в остальных четырёх, потому что именно они закрывают операции, за которые обычно нет отдельной ответственности.
Читать
Без него объекта для сотрудника нет: пункт меню не появляется, вкладка не отрисовывается, строка не попадает в выборку.
Изменять
Правка полей существующей записи. Отделено от добавления: можно разрешить вести карточку, но не заводить новые.
Добавлять
Создание новых записей справочника. Отдельное право защищает справочники от разрастания дубликатами.
Удалять
Самое узкое право. Выдаётся отдельно и обычно очень немногим — удаление справочной записи затрагивает всё, что на неё ссылается.
Выполнять
Право на переход по статусной модели. Выдаётся на конкретное целевое состояние: «согласовать» и «вернуть на доработку» — два разных права.
Фильтровать
Право с условием отбора. Так задаётся доступ к части строк справочника, а не ко всему справочнику целиком.
Переход выполняется только при двух правах сразу
Чтобы перевести запись в новое состояние, у сотрудника должно быть право «Выполнять» на целевое состояние и право «Читать» на исходное. Поверх этого работает правило разделения полномочий: тот, кто отправил запись на согласование, согласовать её не может. Два условия проверяются независимо, и обойти второе выдачей более широких прав нельзя.
Разделы карточек и меню: пусто там, где нет права
Вкладки карточки собираются из тех разделов, на которые у сотрудника есть право чтения. Если не читается ни один раздел — карточка не открывается, сотрудник получает страницу запрета доступа. Узлы навигации ведут себя так же: пункт, за которым нечего показать, из дерева выбрасывается.
Отметьте права — меню слева соберётся так, как его увидит этот сотрудник. Ровно по этому правилу продукт строит дерево навигации.
Меню сотрудника
Ни одного доступного раздела: сотрудник попадает на страницу запрета доступа.
Выданные права на чтение
Снимите все отметки — меню опустеет целиком, и сотрудник попадёт на страницу запрета доступа. В продукте узел навигации проверяет право на чтение хотя бы одного раздела за ним, а календарь — доступность хотя бы одного вида тестирования или учений.
| Карточка | Вкладок | Состав |
|---|---|---|
| План непрерывности | 7 | Процесс · Описание · Поставщики · Системы и приложения · Годовая аттестация · Комментарии · История изменений |
| Поставщик | 5 | Описание · Тесты · Аттестации · Комментарии · История изменений |
| Система или приложение | 4 | Описание · Тесты · Комментарии · История изменений |
| Кризисное учение | 2 | Описание · История изменений |
| Тест поставщика | 2 | Описание теста · Аттестация поставщика |
| Тест офиса, тест системы, аттестация поставщика | 1 | Описание |
Видимость строк: ограничение проходит по данным, а не по интерфейсу
Скрытая кнопка защищает ровно до первой прямой ссылки. Здесь для двух ролей — руководителя подразделения и координатора восстановления подразделения — ограничение встроено в сам запрос данных: в выборку попадают только записи их ветки оргструктуры.
Состав этапов — как в продукте: действующие согласованные привязки, рекурсивный разворот дерева, подстановка набора подразделений в запрос списка.
Что стоит за элементами схемы: привязки сотрудника · разворот дерева вниз · подстановка в запрос
Почему это важно для безопасности
Ограничение живёт в запросе данных, а не в отрисовке страницы. Строки чужого подразделения не приходят на клиент — ни в списке, ни в выгрузке в таблицу, ни при прямом обращении по адресу карточки.
Почему это важно для работы
Руководитель подразделения видит свою ветку целиком, включая подчинённые уровни, — реорганизация не требует переназначения прав вручную по каждому новому отделу.
Журнал изменений: каждое поле, прежнее и новое значение
Изменение любого поля любой записи фиксируется отдельной записью журнала. Она доступна прямо из карточки на вкладке истории и содержит одиннадцать полей — достаточно, чтобы восстановить картину без обращения к базе данных.
| Поле записи журнала | Что даёт |
|---|---|
| Дата и время | Момент изменения. |
| Сотрудник и его наименование | Кто изменил — идентификатор и читаемое имя. |
| Запись, её тип и наименование | Что именно изменено: план, тест, справочная запись. |
| Поле и его наименование | Какой показатель изменён — с подписью на языке сеанса. |
| Прежнее значение | Что было до изменения. |
| Новое значение | Что стало после. |
Журнал статусов — отдельно
Переходы по статусной модели пишутся в собственный журнал: запись и её тип, исходное и целевое состояние, дата, комментарий с формы возврата, получатели уведомления и сотрудник, выполнивший переход.
Связи с недостатками — тоже
Установка и снятие связи теста с недостатком и с планом корректирующих действий записывается как изменение: было пусто — стало значение, и наоборот.
Журнал событий безопасности: кто и кому выдал доступ
Отдельный журнал ведёт операции с учётными записями и ролями — те самые события, о которых спрашивает служба информационной безопасности и внутренний аудит. Три вида операций: добавление, изменение, удаление.
| Событие | Что записывается |
|---|---|
| Создание учётной записи | Идентификатор сотрудника, домен, логин, ссылка на сотрудника, адрес электронной почты. |
| Изменение учётной записи | Прежние и новые значения идентификатора, домена, логина, ссылки на сотрудника и адреса почты. |
| Удаление учётной записи | Идентификатор сотрудника, домен, логин, ссылка на сотрудника. |
| Назначение ролей | Идентификатор сотрудника и перечень назначенных ролей. |
| Снятие ролей | Идентификатор сотрудника и перечень снятых ролей. |
Раздел администрирования закрыт единственной ролью
Экраны ролей, учётных записей, выгрузки и журнала безопасности открываются только сотруднику с ролью администратора безопасности. У всех остальных попытка перехода заканчивается страницей запрета доступа — независимо от того, какие права на данные им выданы. Администрирование доступа и работа с данными разведены по разным людям.
Учётные записи и аутентификация
Поддерживаются четыре режима работы с учётными данными: общий режим платформы, учётная запись в базе данных и два режима единого входа по SAML — в том числе через внешнего поставщика удостоверений. Из токена доступа разбираются стандартные утверждения: издатель, клиент, имя пользователя, идентификатор субъекта и набор ролей; фиксируются момент выдачи и срок действия. Режим задаётся настройкой площадки, менять код для этого не нужно.
Создание учётной записи требует заполнения идентификатора, домена и логина. При добавлении система находит сотрудника по имени, а если такого нет — заводит карточку сотрудника и связывает её с учётной записью; у существующего сотрудника обновляется адрес почты и снимается отметка неактуальности.
Выгрузка для процессов управления доступом
Журнал безопасности выгружается отдельным файлом в формате, рассчитанном на приём внешним процессом управления доступом. Пять колонок, период по умолчанию — текущий день, кодировка с меткой порядка байтов, чтобы файл корректно открывался в табличных редакторах.
Таблица прокручивается вбок.
| Время события | Кто выполнил действие | Учётная запись, над которой выполнено действие | Выданное право | Наименование системы |
|---|---|---|---|---|
| 09/03/2026 11:14 | Администратор безопасности | Учётная запись сотрудника | Роль «Координатор восстановления подразделения» назначена | Контур непрерывности |
| 09/03/2026 11:16 | Администратор безопасности | Учётная запись сотрудника | Роль «Менеджер приложения» снята | Контур непрерывности |
| 09/03/2026 15:02 | Администратор безопасности | Учётная запись сотрудника | Учётная запись создана | Контур непрерывности |
| 10/03/2026 09:41 | Администратор безопасности | Учётная запись сотрудника | Изменён адрес электронной почты | Контур непрерывности |
Если за выбранный период событий не было, файл всё равно формируется и содержит одну строку об отсутствии событий: пустой ответ отличается от несформированного отчёта.
Состав колонок, полей, этапов и статусов — как в продукте. Данные в строках — пример заполнения.
Материалы для службы безопасности — по запросу
Руководство администратора безопасности, описание модели разграничения доступа с точностью до объекта, схема размещения компонентов и порядок интеграции с корпоративным поставщиком удостоверений передаются по запросу под соглашение о конфиденциальности вместе с демонстрационным стендом.
Запросить материалы после заключения соглашения о конфиденциальности
Что это даёт ИТ-директору
- 13типов объектов защиты и права вплоть до отдельной вкладки и отдельного состояния
- 4режима аутентификации, включая два варианта единого входа по SAML
- 2независимых журнала: изменения данных и события безопасности, с отдельной выгрузкой для управления доступом
- 1роль открывает администрирование доступа — разделение обязанностей встроено в продукт
Проверка права выполняется на сервере при сборке каждого экрана и каждого запроса данных, а не только при отрисовке элементов управления. Права хранятся отдельными признаками по каждому действию, право с условием отбора несёт разобранное дерево условия — это позволяет описать доступ к части строк без написания кода. Аттестация доступа проводится штатной выгрузкой журнала безопасности за период.
Что входит и что настраивается под вашу организацию
Что входит
- Модель прав «объект — действие» с 13 типами объектов защиты и шестью действиями
- Права на отдельные объекты: вкладку карточки, состояние статусной модели, конкретный справочник
- Права с условием отбора строк
- Восемь ролей в поставке и редактор ролей
- Скрытие недоступных пунктов меню и вкладок, страница запрета доступа
- Фильтрация строк по ветке оргструктуры для двух ролей
- Журнал изменений по полям и журнал переходов по статусам
- Журнал событий безопасности и его выгрузка из пяти колонок
- Четыре режима аутентификации и администрирование учётных записей
Что настраивается под вашу организацию
- Состав ролей и их соответствие вашим подразделениям
- Набор прав внутри каждой роли, вплоть до отдельных вкладок и состояний
- Условия отбора строк в правах с фильтрацией
- Привязка сотрудников к подразделениям, задающая видимость строк
- Режим аутентификации и параметры единого входа
- Периодичность выгрузки журнала безопасности и её приёмник
Кому подходит: организациям, где доступ к сведениям о непрерывности разграничен между бизнес-подразделениями, ИТ и службой безопасности, и где выдачу прав нужно не только выполнить, но и предъявить.
Собрать вашу матрицу прав на демонстрации
Принесите список ролей и то, кто у вас что должен видеть, — соберём роли на стенде и покажем, как выглядит интерфейс у сотрудника с ограниченным доступом и что попадает в журналы.