Сотрудник не видит того, чего ему нельзя, — и не ищет там, где пусто
Право выдаётся не только на объект, но на раздел карточки и на конкретный переход статуса. Недоступный раздел не показывается заблокированным — его просто нет в меню. А каждое действие, которое всё-таки состоялось, остаётся в журнале с автором и временем.
Шесть действий над объектом защиты
Право в продукте — это пара «что за объект» и «что с ним можно». Действий шесть, и они разделены не для красоты: право читать справочник и право его править — разные права, и выдаются они разным людям.
| Действие | Что оно разрешает | Что защищает |
|---|---|---|
| Просмотр | Видеть объект и его раздел | Данные, которые сотруднику не нужны по работе, ему не показываются |
| Изменение | Изменять содержимое | Правка карточки отделена от её просмотра |
| Создание | Создавать записи | Наполнение справочника не смешивается с его использованием |
| Удаление | Удалять записи | Самое опасное действие выдаётся отдельно от правки |
| Выполнение действия или смена статуса | Выполнять действие или переход статуса | Двигать карточку по маршруту может не всякий, кто её видит |
| Ограничение видимости записей | Ограничивать выборку строк для субъекта | Сотрудник работает со своим срезом данных, а не со всем реестром |
Субъекту назначаются роли, роль содержит права, право — это объект защиты вместе с действием. Каждая операция в интерфейсе проверяется по этой цепочке.
Права на разделы карточки и смену статуса
Это то, что отличает настоящее разделение полномочий от галочки «доступ к модулю». Охраняемым объектом является не только сущность, но и раздел её карточки и её статусная модель. Всего в продукте зарегистрировано 16 охраняемых типов.
| Охраняемый тип | Действия | Что это значит на практике |
|---|---|---|
| Справочник | создание, просмотр, изменение, удаление, ограничение видимости записей | Ведение классификаторов отделено от работы с обращениями |
| Действие | выполнение действия | Операции вроде импорта выдаются поимённо |
| Отчёт | просмотр | Право видеть выгрузку отдельно от права видеть реестр |
| Обращение | просмотр, изменение | Базовое право на сущность обращения |
| Изменение | просмотр, изменение | Базовое право на сущность изменения |
| Раздел карточки проблемы | просмотр, изменение | Классификация и последствия открыты не всем, кто видит проблему |
| Раздел карточки процесса | просмотр, изменение | Разделы процесса выдаются по отдельности |
| Раздел карточки события | просмотр, изменение | Разделы события выдаются по отдельности |
| Раздел карточки ЗНО | просмотр, изменение | Разделы запроса на обслуживание выдаются по отдельности |
| Раздел карточки поставщика | просмотр, изменение | Договорные сведения о подрядчике видит не вся служба |
| Статусная модель обращения | просмотр, изменение, смена статуса | Право перевести обращение по маршруту |
| Статусная модель инцидента | просмотр, изменение, смена статуса | Право передать инцидент на линию или подрядчику |
| Статусная модель ЗНО | просмотр, изменение, смена статуса | Право согласовать или вернуть запрос на обслуживание |
| Статусная модель процесса | просмотр, изменение, смена статуса | Право провести процесс через ступень согласования |
| Статусная модель поставщика | просмотр, изменение, смена статуса | Право согласовать карточку поставщика |
| Статусная модель элемента | просмотр, изменение, смена статуса | Право согласовать запись реестра |
Право «на модуль»
Сотрудник получает доступ к разделу целиком. Дальше действует договорённость: «эту вкладку не трогай», «этот статус ставит только руководитель». Договорённость нарушается молча.
Право на раздел и на переход
Раздел карточки и статусная модель — самостоятельные охраняемые объекты. Кнопки перехода, на который нет права, в карточке нет. Нарушить договорённость не получится, потому что это уже не договорённость.
Согласование нельзя пройти в одиночку
Согласование процесса идёт тремя ступенями подряд: Владелец данных, затем сотрудник КПО, затем менеджер по ОРМ. Право выполнять переход выдаётся на статусную модель, а возврат на доработку требует комментария. Один человек не заводит нарушение, согласовывает его и закрывает.
Права на действие и на отчёт
Кроме объектов и разделов, отдельными охраняемыми сущностями объявлены операции и выгрузки — именно те, через которые данные покидают систему.
Импорт
Загрузка данных — самостоятельное охраняемое действие с правом на выполнение. Массовое изменение реестра доступно не каждому, кто может править одну карточку.
Справочники
Работа со справочниками объявлена отдельным действием. Классификаторы, на которых держится вся отчётность, не правятся по ходу разбора инцидента.
Отчёт по инцидентам
Отчёт зарегистрирован в модели прав как охраняемый объект с действием чтения. Надзорная выгрузка выдаётся адресно.
Фильтрующие права в модели
Ограничение видимости записей — полноценное действие модели прав наравне с чтением и записью. В модели есть фильтрующее право и стратегия его разрешения: доступ ограничивается не только тем, какие объекты видны, но и тем, какие строки попадают в выборку.
Практический смысл: подразделение видит свои обращения, а не весь поток службы, при этом отдельного реестра для него не заводится. Правило отбора строк настраивается под структуру вашей организации на внедрении.
Роли и подразделения заказчика
Роли настраиваются под вашу структуру: состав ролей и матрица прав по модулям редактируются в самой системе. Ниже — роли справочника продукта и подразделение, которому такая роль обычно соответствует. Это методический ориентир для внедрения — узнайте в нём собственную оргструктуру.
| Роль в продукте | Кто это обычно в организации |
|---|---|
| Пользователь | Любой работник, который обращается в службу поддержки |
| VIP пользователь | Руководство и подразделения, обращения которых обрабатываются в первую очередь |
| Оператор | Первая линия: приём и первичная обработка обращений |
| Исполнитель | Специалист, за которым закреплено обращение |
| Руководитель группы | Руководитель группы исполнителей: распределение и контроль очереди |
| 3 линия поддержки | Экспертные и сопровождающие подразделения, включая работу с подрядчиком |
| Менеджер инцидентов | Владелец процесса управления инцидентами |
| IT Менеджер | Руководитель ИТ-направления |
| Согласующий | Тот, чьё согласование требуется по маршруту запроса или процесса |
| Владелец данных | Подразделение — владелец сведений о процессе, первая ступень согласования |
| Владелец процесса уровня 3 | Ответственный за процесс нижнего уровня иерархии |
| Менеджер процесса | Ответственный за поддержание описания процесса в актуальном виде |
| Менеджер по качеству данных | Подразделение, отвечающее за полноту и качество реестров |
| Сотрудник КПО | Вторая ступень согласования процесса |
| Сотрудник ОРМ | Операционные риски: третья ступень согласования процесса |
| Сотрудник банка | Базовая роль работника организации, от которой наследуется общий доступ |
| Системная роль | Служебная роль продукта для фоновых операций |
Названия ролей приведены так, как они заведены в справочнике продукта. Состав ролей и их наименования настраиваются при внедрении.
Четыре режима аутентификации
Режим входа выбирается одним свойством конфигурации — под то, как в вашей организации уже устроен доступ. Отдельная учётная база «ещё для одной системы» не появляется.
| Режим | Где живут учётные записи | Когда выбирают |
|---|---|---|
| Файл | Список пользователей в файле конфигурации | Стенд и изолированная площадка, где каталог недоступен |
| База | Учётные записи в базе приложения | Автономная установка со своей учётной базой |
| OAuth2 / OIDC | Внешний провайдер единого входа | В организации уже работает единый вход |
| каталог учётных записей по LDAP | Корпоративный каталог | Доступ выдаётся и отзывается через каталог |
Что настраивается для каталога
Домен, сервер, база поиска и фильтр поиска задаются свойствами. Сотрудник, которого отключили в каталоге, перестаёт входить и в службу поддержки — отдельная процедура отзыва доступа не нужна.
Единый вход берёт данные сотрудника из провайдера
При входе через OAuth2 / OIDC личность сотрудника читается из данных провайдера: идентификатор сессии, имя учётной записи и отображаемое имя. Отдельные ошибки предусмотрены для случая, когда сотрудник провайдеру известен, а в системе — ещё нет.
Административный вход обслуживается отдельной цепочкой с собственным адресом входа и собственным поставщиком проверки — он не смешивается с пользовательским. Прямой запрос шаблонов представлений запрещён: экраны нельзя вытянуть в обход приложения.
Консоль администрирования
Права ведутся в самой системе, а не в конфигурационных файлах. Пункт «Администрирование» появляется в меню пользователя только у того, у кого есть на это право.
- РолиСписок ролей и форма редактирования
- СубъектыСписок субъектов и назначение им ролей
- Матрица прав по модулямПрава раскладываются по вкладке на каждый модуль
- Добавление объектов защитыФорма добавления охраняемого объекта в роль
- Пароли и настройки учётной записиСброс и смена пароля, персональные настройки
- ЖурналыЖурнал безопасности и журнал работы пользователей
Два журнала аудита: безопасности и работы
Вопрос «кто это сделал» закрывается в системе, а не восстановлением по почте. Журналов два, и они отвечают на разные вопросы.
Журнал безопасности
События входа и работы с доступом: кто вошёл, под какой учётной записью, что происходило с правами. Отдельный экран просмотра в консоли администрирования.
Журнал работы
Действия пользователей в системе, доступные для просмотра тем же экраном. Разбор инцидента с доступом не требует привлечения администратора базы данных.
Журнал переходов — третий след, и он на карточке
Каждая смена статуса пишется в сквозной журнал переходов, у которого есть собственный экран просмотра прямо на карточке обращения и на карточке процесса. Кто перевёл, когда и из какого статуса — видно тому, кто разбирает эту карточку, а не только администратору.
Что настраивается под вашу организацию
- Состав ролей, их наименования и матрица прав по модулям.
- Соответствие ролей продукта подразделениям вашей организации.
- Режим аутентификации и параметры подключения к каталогу или провайдеру единого входа.
- Правила отбора строк для фильтрующих прав.
Что это даёт ИТ-директору
- Глубина ролевой модели. Шестнадцать охраняемых типов, шесть действий, права на раздел карточки и на переход статуса. Модель выдерживает требование разделения полномочий, а не только разграничения доступа к модулю.
- Механизмы аутентификации. Четыре режима переключаются одним свойством: файл, база, OAuth2 / OIDC, каталог учётных записей по LDAP. Административный вход обслуживается отдельной цепочкой.
- Фильтрация данных по принадлежности. ограничение видимости записей — первоклассное действие модели с собственной стратегией разрешения.
- Журнал событий. Журнал безопасности, журнал работы пользователей и сквозной журнал переходов статусов с просмотром на карточке.
- Выгрузки для процессов управления доступом. Роли и субъекты ведутся в консоли, а состав прав по модулям виден матрицей — материал для регулярного пересмотра доступов готовится в системе.
Требования к контуру · Переходы, которые проверяются правами · Право на отчёт
Разложить ваши полномочия по ролям на нашем стенде
Возьмём одну вашу процедуру согласования и покажем, как она раскладывается по ролям: какое право закрывает какой шаг, что видит каждый участник в меню и что остаётся в журналах. Состав показа согласуем заранее.