Permissions: from matrix to verified accessДоступы: от матрицы до проверки

Describe actions and data scopeОписать действия и область данных

The process owner builds a matrix from actual tasks. Each row identifies a role, object, action, data scope and permitted object state. For example, reception may need to edit a contact on an unfinished request at its location, while another operation requires a manager’s decision. These are business requirements to map against system capabilities. Department names without actions are not a sufficient configuration brief.Владелец процесса собирает матрицу из реальных задач. В строке указывают роль, объект, действие, область данных и допустимое состояние объекта. Например, сотрудник приёма может изменять контакт в незавершённой заявке своей точки, но подтверждение иной операции требует решения руководителя. Это требования бизнеса, которые предстоит сопоставить с возможностями системы. Названия отделов без перечня действий не дают достаточного задания на настройку.

List viewing, creation, editing, approval, cancellation and export separately. Identify the fields needed for work and those the role should not access. Do not infer export permission from viewing permission. Record the operational reason and decision owner for each restriction, so disputed access can be resolved against a task rather than a familiar job title.Отдельно перечислите просмотр, создание, изменение, подтверждение, отмену и выгрузку. Укажите, какие поля нужны для работы, а какие не должны быть доступны данной роли. Не выводите право выгрузки из права просмотра. Для каждого ограничения запишите рабочую причину и лицо, принимающее решение; это позволит разбирать спорный доступ по задаче, а не по привычному названию должности.

Map roles to named accountsСопоставить роли и учётные записи

The administrator maps matrix rows to available settings and marks unsupported conditions. If a permission bundle is too broad, the process owner must revise the workflow or explicitly agree an acceptable arrangement before launch. Do not describe manual approval as an enforced system restriction. The assignment list includes the person, role, working scope, reason and effective date; a shared account makes action ownership difficult to verify.Администратор сопоставляет строки матрицы с доступными настройками и отмечает неподдерживаемые условия. Если право выдаётся слишком крупным набором, владелец процесса должен пересмотреть маршрут либо явно согласовать приемлемое решение до запуска. Не представляйте ручное согласование как встроенный запрет. Список назначений включает человека, роль, рабочую область, основание и дату начала; общая учётная запись затрудняет проверку того, кто выполнил действие.

Check the person’s effective access with all assigned roles combined. An additional role may expose an operation restricted in the main role. Review technical accounts used for data exchange separately: they need an owner and purpose but do not follow an employee’s shift. Document required access and its approval path without placing credentials in the working matrix.Проверьте итоговые права человека со всеми его ролями вместе. Дополнительная роль может открыть действие, запрещённое в основной. Технические учётные записи для обмена данными рассмотрите отдельно: у них есть владелец и назначение, но нет обычной смены сотрудника. На этом этапе фиксируют необходимые права и порядок согласования, не перенося секреты в рабочую матрицу.

Define integration ownershipОпределить владельцев интеграций

Test permission and denialПроверить разрешение и отказ

The tester prepares fictional records in the required states and signs in under each operational role. For each matrix row, perform the allowed action and a neighboring prohibited one: another location, a closed document or a different edit type. Establish the expected outcome before execution. Success under an administrator account does not demonstrate that an employee can perform the task.Проверяющий готовит вымышленные записи нужных состояний и входит под каждой рабочей ролью. Для каждой строки матрицы выполняют разрешённое действие и соседнее запрещённое: чужая точка, закрытый документ или иной тип изменения. Проверку проводят с заранее известным ожидаемым результатом. Успех под учётной записью администратора не является доказательством готовности сотрудника к работе.

Test available routes to the same data: search, direct links, reports and exports where included in the configuration. A hidden button alone does not establish that an operation is restricted. Record the role, configuration version, test record, expected outcome and actual result. An untested route remains untested rather than being counted as a successful denial.Проверьте доступные пути к тем же данным: поиск, прямую ссылку, отчёт и выгрузку, если они входят в конфигурацию. Скрытая кнопка сама по себе не подтверждает ограничение действия. В протоколе сохраняют роль, версию настройки, тестовую запись, ожидаемый и фактический результат. Непроверенный путь отмечают как непроверенный, а не как успешный отказ.

Define temporary access exceptionsЗадать порядок временных исключений

For temporary cover or a one-off task, prepare a request naming the action, scope, reason and end time. The designated owner approves, the administrator applies the change and a reviewer verifies the result. If automatic expiry is unavailable, assign a specific person and checkpoint for manual removal. Urgency alone does not determine the appropriate breadth of access.Для замены коллеги или разовой задачи подготовьте заявку с нужным действием, областью, причиной и сроком окончания. Решение принимает назначенный владелец, изменение выполняет администратор, а проверяющий подтверждает результат. Если автоматическое окончание недоступно, назначьте конкретного ответственного и контрольное время ручного снятия. Срочность задачи не определяет сама по себе необходимый объём прав.

After removing the exception, repeat the denial test and check that normal work remains possible. When someone changes roles, consider removal of previous assignments alongside new ones. Route access failures through a clear review channel with the affected operation described; borrowing another person’s account is not a resolution.После снятия исключения повторите запрещённый сценарий и проверьте, что обычная работа осталась возможной. При переводе человека между ролями рассматривайте удаление прежних назначений вместе с новыми. Ошибка доступа должна попадать в понятный канал разбора с описанием операции; передача чужой учётной записи не является решением такой ошибки.

Hand over verified configurationПередать проверенную настройку

Before launch, the process owner reconciles the matrix, actual assignments and test evidence. Any mismatch needs a decision rather than a completion mark. For SABSUS, verify permission granularity, combined-role behavior and available change evidence in the selected configuration. This establishes results for specific scenarios; it does not replace a separate assessment of the business’s data-protection requirements.Перед запуском владелец процесса сверяет матрицу, фактические назначения и результаты тестов. Расхождение получает решение, а не отметку о завершении. В SABSUS подтвердите гранулярность прав, поведение совместных ролей и доступные свидетельства изменений в выбранной конфигурации. Проверка подтверждает конкретные сценарии; она не заменяет отдельную оценку требований бизнеса к защите данных.

The handover names the matrix owner, change administrator and triggers for renewed checks: a new role, workflow change or expiry of temporary access. The recipient should be able to explain each exception and reproduce the checks without the original configurator. This keeps permission management workable after the implementation project ends.В передаче укажите владельца матрицы, исполнителя изменений и события для повторной проверки: новая роль, изменение процесса или завершение временного доступа. Получатель должен уметь объяснить основание каждого исключения и воспроизвести проверку без автора настройки. Так схема прав остаётся управляемой после завершения проекта внедрения.

Include permissions in acceptance testingВключить права в приёмочные испытания

Quick answersКороткие ответы