Права доступа
Предопределённые роли
Сотрудник не видит того, чего ему нельзя, — и не тратит время на поиск в разделах, где для его роли всё равно пусто. 15 ролей поставляются готовыми и узнаются в привычной оргструктуре — при этом это методический ориентир, а не жёсткое ограничение: роли настраиваются под вашу структуру через контур администрирования.
| Роль | Кому в оргструктуре соответствует |
|---|---|
| Сотрудник банка | базовая роль, назначается всем пользователям |
| Бизнес-мейкер | сотрудник, регистрирующий сбои со стороны бизнеса |
| ИТ валидатор | первая линия подтверждения сбоя по своей системе |
| ИТ менеджер | вторая линия подтверждения, точка порождения инцидента |
| Координатор СУОН | риск-координатор процесса операционной надёжности |
| ИТ риск-менеджер | получает эскалацию по зависшим инцидентам |
| ИБ администратор | единственная роль с доступом к контуру администрирования |
| Владелец данных · Менеджер по качеству данных | согласование карточек процессов на стороне бизнес-процессов |
| Менеджер процесса · Владелец процесса уровня 3 | ведение и согласование процессов |
| Сотрудник КПО · Сотрудник ОРМ | согласование процессов по контрольным подразделениям |
| DIT | дополнительная ИТ-роль с правами на поставщиков |
Типы объектов безопасности
Права выдаются не «на модуль целиком», а по 16 отдельным типам объектов защиты — от справочников до статусной модели каждой сущности, — поэтому доступ можно развести настолько тонко, насколько нужно вашей организации.
- СправочникиADD · READ · WRITE · DELETE · FILTER
- ДействияEXECUTE
- Импорт по заявкамREAD · EXECUTE
- ОтчётыREAD
- Разделы карточек5 типов · READ · WRITE
- Статусные модели7 типов · READ · WRITE · EXECUTE
Соберите меню навигатора под роль
Ни один узел не выдан — меню пустое.
Разделение полномочий по разделам карточек
Право на карточку и право на её отдельный раздел — не одно и то же: сотрудник может видеть описание инцидента, но не иметь доступа к вкладке «ФинЦЕРТ» или «Классификаторы», если это не входит в его обязанности.
Пять типов объектов безопасности разводят доступ по разделам карточек отдельно от самой сущности: «Разделы инцидента», «Разделы сбоя», «Разделы объекта», «Разделы поставщиков» и «Разделы процесса» — у каждого свои READ и WRITE. Это защита не от постороннего, а от собственного сотрудника, который случайно правит не тот раздел, потому что видит его на экране, хотя должен был видеть только «Описание».
Фильтры безопасности на данные справочников
Право READ на справочник ещё не значит доступ ко всем его строкам: у типа «Справочники» есть отдельное действие FILTER — сужение видимых записей внутри одного и того же справочника.
Фильтр безопасности настраивается в контуре администрирования отдельно от выдачи самого права READ и позволяет, например, ограничить видимость справочника «Подразделение» тем отделением, за которое отвечает конкретный сотрудник, — вместо того чтобы либо открывать весь справочник целиком, либо не давать его вовсе.
Контур администрирования
Настройка ролей и прав живёт не там же, где рабочие карточки, — у СУОН собственный контур администрирования на отдельном URL, куда попадает только один тип пользователей.
Раздел «Roles» — добавление, изменение и удаление ролей, выдача прав ролям и настройка фильтров безопасности; раздел «Users» — добавление, изменение и удаление пользователей и назначение им ролей; раздел «Экспорт» выгружает данные о правах доступа в формате Enterprise Entitlement Revocation System (EERS) — отдельным правом от обычных отчётов, для процессов управления доступом, а не для оперативной работы.
Что это даёт ИТ-директору. Роли, права и журнал действий контура администрирования СУОН хранятся в собственной схеме, отдельной от рабочих данных модуля, а доступ к самому контуру администрирования есть только у роли «ИБ администратор» — технического согласователя, а не у любого пользователя с широкими правами на карточки. Выгрузка EERS даёт готовый формат для процессов управления доступом, а не требует отдельной интеграции под каждый аудит.
Права на переходы статусных моделей
Право менять статус карточки — отдельное действие, а не следствие права её редактировать: у семи статусных моделей модуля READ, WRITE и EXECUTE разведены явно.
EXECUTE — это не WRITE
Сотрудник может иметь право видеть (READ) и редактировать поля карточки (WRITE), но не иметь права перевести её в следующий статус (EXECUTE) — верификация сбоя, подтверждение инцидента, согласование объекта или поставщика остаются за той ролью, которой это предписано, даже если остальные поля карточки ей открыты для правки.
Статусных моделей семь: сбой, инцидент операционной надёжности, объект инфраструктуры, поставщик, справочные элементы, процесс и технологический процесс — у каждой свой тип объекта безопасности и свой набор переходов, описанных на странице «Управление сбоями и инцидентами».
Показать разграничение прав на вашем стенде
Сборку меню по правам, фильтры безопасности и контур администрирования — на ролях, приближенных к вашей оргструктуре.