На этой странице
Инструкции описывают рабочие сценарии. Доступность действий зависит от конфигурации UNIUM и прав вашей организации.
Разделите роль, область и действие
Матрица доступа описывает, какой субъект может выполнить действие над определёнными данными. Должность в оргструктуре помогает понять ответственность человека, но сама по себе не является достаточным описанием технических прав.
Начните с рабочих сценариев: сотрудник выполняет поручение, руководитель проверяет результат, администратор управляет настройками, интеграция передаёт согласованные данные. Для каждого сценария определите организацию, рабочую область, объект и допустимые действия. Затем сопоставьте их с механизмами вашей поставки.
| Уровень | Что зафиксировать |
|---|---|
| Субъект | Сотрудник, администратор или отдельная сервисная учётная запись. |
| Организация и область | Где полномочия действуют и какие соседние области исключены. |
| Объект и поля | Какие записи и сведения доступны в данном контексте. |
| Действие | Просмотр, изменение, решение по маршруту, экспорт или настройка. |
| Условия | Срок, участие в процессе, замещение и правила отзыва. |
Подготовьте матрицу полномочий
Составляйте матрицу вместе с владельцами процессов. Права на чтение, изменение, согласование и экспорт нужно рассматривать отдельно. Пользователю может быть нужен доступ к документу для решения, но не право менять справочник организации.
Составьте матрицу по рабочим ролям: для каждой укажите объекты, разрешённые действия и границы доступа. Отдельно опишите чувствительные поля, замещение сотрудников и полномочия администраторов.
| Субъект | Рабочий доступ | Отдельная проверка |
|---|---|---|
| Исполнитель | Назначенные задачи и материалы в согласованной области. | Видит ли сведения других подразделений и чужие вложения? |
| Согласующий | Чтение рассматриваемой версии и решение своего этапа. | Может ли менять текст или принимать решение другого участника? |
| Руководитель | Сводка и проверка результатов своей области. | Нужен ли экспорт и какие поля попадут в него? |
| Администратор | Управление доступом в назначенном контуре. | Отделены ли настройки от чтения чувствительных рабочих данных? |
| Интеграция | Только операции и объекты конкретного обмена. | Исключены ли соседние организации и ненужные изменения? |
Выдавайте доступ по понятному основанию
- Получите запрос с организацией, рабочей задачей, объектами и требуемыми действиями.
- Проверьте согласование владельца данных или процесса.
- Выберите минимальный набор полномочий, достаточный для сценария.
- Для временного доступа определите срок и ответственного за отзыв.
- Назначьте права предусмотренным способом и сохраните основание решения.
- Проверьте доступ обычной учётной записью пользователя, включая ограничения.
Не выдавайте административную роль только для обхода ошибки. Сначала установите, какого права не хватает и почему. Если требуется замещение, уточните период, область и допустимые решения; после завершения проверьте отзыв временных полномочий.
Проверьте и разрешённые, и запрещённые сценарии
Успешный вход и видимая кнопка не доказывают корректность разграничения. Для каждой роли нужен положительный сценарий в своей области и отрицательный сценарий вне неё. Проверять ограничения следует на уровне приложения и согласованных API, а не только скрытия пунктов меню.
- Откройте разрешённую запись и выполните допустимое действие.
- Проверьте прямую ссылку на запись другой организации или области.
- Проверьте вложения, связанные документы, поиск и отчётные выборки.
- Проверьте экспорт: состав строк и полей должен соответствовать полномочиям.
- Повторите проверки после отзыва доступа или смены роли.
Смена роли, выход сотрудника и сервисные аккаунты
При смене подразделения пересмотрите старые области доступа, активные назначения и замещения. Новые полномочия не должны просто накапливаться поверх прежних без решения владельца. Поручения и владение документами передайте так, чтобы рабочий процесс продолжался.
При выходе сотрудника определите порядок прекращения входа, отзыва полномочий и передачи незавершённой работы. Завершение активных сессий и отзыв выданных ключей должны быть предусмотрены выбранным механизмом доступа и подтверждены проверкой.
Для интеграции используйте отдельного субъекта с владельцем, назначением и ограниченным набором операций. Не привязывайте промышленный обмен к личной учётной записи сотрудника. Порядок выдачи, хранения, замены и отзыва учётных данных согласуйте до запуска.
Пересмотр доступа и разбор проблем
Период пересмотра определяет политика организации. Проверяйте активных пользователей, временные права, административные роли и сервисные субъекты. Для каждого исключения должно быть действующее основание и ответственный.
| Симптом | Проверка |
|---|---|
| Запись исчезла после смены роли | Сопоставьте прежнюю и новую область, участие в процессе и доступ к объекту. |
| Пользователь видит лишние данные | Проверьте назначенные роли, наследование, общие области и экспорт. |
| Интеграция получает отказ | Проверьте субъект, организацию, действие и срок полномочий. |
| Временные права остались | Найдите основание, срок и владельца отзыва; повторите отрицательный сценарий. |
Сохраняйте результаты проверок и решения о корректировке. Для технического разбора нужны субъект, объект, действие, время и идентификатор запроса, если он доступен. Секреты авторизации в обращение не включайте.
Нужна помощь с вашим сценарием?
Опишите задачу и раздел системы. Команда UNIUM поможет разобраться в рабочем сценарии.