Как проверять право на действие и область финансовых данных в программе, обрабатывать отказ и тестировать положительные и отрицательные сценарии.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Проверка полномочий должна совпадать с бизнес-действием и областью данных, которую пользователь пытается обработать. Наличие кнопки, скрытого поля, транзакционного кода или роли в интерфейсе само по себе не доказывает, что чувствительное действие защищено в приложении.
Для каждой операции перечислите объект, действие и область: например, просмотр, создание, изменение, сторнирование или выпуск документа для заданной компании, ledger или организационной единицы. Сначала проверьте, подходит ли стандартный объект полномочий. Если требуется собственный объект, задайте поля под реальный сценарий и согласуйте его с владельцем ролей.
AUTHORITY-CHECK передаёт объект и значения его полей, например activity и область организации. Успешный результат нужно трактовать по контракту проверки; любой ненулевой sy-subrc должен приводить к безопасному отказу или диагностике. Не продолжайте операцию после ошибки проверки, не маскируйте неверный объект как обычный отказ и не показывайте пользователю данные, которые проверка должна была ограничить.
Проверку размещайте у серверного действия до чтения или изменения защищённых данных. В UI можно скрыть недоступное действие для удобства, но повторно проверяйте его в вызываемой программе или API. Для пакетных заданий отдельно зафиксируйте технического пользователя и нужный ограниченный набор полномочий; интерактивная проверка пользователя не переносится автоматически в background job.
Классическая модель использует объекты полномочий с наборами полей и значений, назначаемыми пользователям через роли. Для ABAP CDS существует механизм access control на основе DCL; он может добавлять условия к чтению CDS entity через ABAP SQL. Эта модель сосуществует с классическими проверками, но защищает другой уровень.
DCL не заменяет start authorization приложения, а AUTHORITY-CHECK в одном действии не гарантирует фильтрацию всех последующих чтений CDS. Проверяйте, что нужный CDS entity действительно связан с access control и что потребитель не отключает её в сценарии, где ограничение требуется. Уточните поля области: отсутствие строки из-за фильтра не всегда равно отказу на команду изменения.
Разделяйте ожидаемый отказ в доступе, отсутствие строки в области полномочий и техническую ошибку в объекте или параметрах проверки. Показывайте понятное сообщение без раскрытия запрещённых значений. Для расследования записывайте код действия, тип объекта, безопасный ключ корреляции и результат проверки; не помещайте секреты и полные персональные данные в журнал.
Не запрашивайте у пользователя широкую роль как универсальное исправление. Передайте администратору роль и объект полномочий, необходимые поля, фактические проверяемые значения, транзакцию или приложение, время и результат диагностики. Изменение назначений выполняет владелец процесса управления доступом согласно правилам организации.
Для чтения и изменения подготовьте пользователей с разрешённым, ограниченным и отсутствующим доступом. Проверьте как минимум компанию, организационную область, действие и набор документов, включая попытку изменить ключ или вызвать тот же API в обход интерфейса. Для CDS проверьте корректную строку, отфильтрованную строку, отсутствие DCL и явно разрешённые тестовые обходы, если они предусмотрены.
Убедитесь, что отказ не изменил документ, не выполнил update task и не оставил частичный пакет. Повторите проверку для фонового и внешнего вызова с его собственной идентичностью. Доступ и финансовый результат сверяйте отдельно: успешная проверка полномочий не подтверждает корректность проводки.
Источники описывают ABAP Authorization Concept и CDS authorization для указанных редакций и выпусков. Фактический объект полномочий, роли и политики определяются целевой системой. В этом проекте нет SAP runtime или матрицы ролей; AUTHORITY-CHECK, DCL и отказ доступа не запускались.
An authorization check must match the business action and data scope the user is trying to process. A visible button, hidden field, transaction code, or UI role alone does not prove that a sensitive action is protected in the application.
For each operation, list the object, action, and scope: for example, display, create, change, reverse, or release a document for a specific company, ledger, or organizational unit. First check whether a standard authorization object fits. If a custom object is needed, design fields for the actual scenario and agree them with the role owner.
AUTHORITY-CHECK passes an object and values for its fields, such as activity and organizational scope. Interpret the result according to the check contract; any nonzero sy-subrc must lead to a safe denial or diagnosis. Do not continue after a failed check, mask an invalid object as an ordinary denial, or reveal data that the check was meant to restrict.
Place the check at the server-side action before reading or changing protected data. The UI can hide an unavailable action for convenience, but verify again in the called program or API. For background jobs, record the technical user and the minimum required authorization separately; an interactive user's check does not automatically carry over to a background job.
The classic model uses authorization objects with sets of fields and values assigned to users through roles. ABAP CDS has an access-control mechanism based on DCL; it can add conditions to reads of CDS entities through ABAP SQL. These models coexist but protect different layers.
DCL does not replace an application's start authorization, and an AUTHORITY-CHECK in one action does not guarantee that every later CDS read is filtered. Verify that the required CDS entity is actually linked to access control and that a consumer does not disable it in a scenario where the restriction is required. Clarify scope fields: a row hidden by a filter is not always the same as denial of a change command.
Distinguish an expected access denial, a row outside the permitted scope, and a technical error in the object or check parameters. Show a clear message without revealing restricted values. For investigation, record action code, object type, safe correlation key, and check result; do not place secrets or full personal data in a log.
Do not ask the user to receive a broad role as a generic fix. Provide the administrator with the role and authorization object, required fields, checked values, transaction or application, time, and diagnostic result. The owner of the organization's access-management process changes assignments under its rules.
For reading and changing, prepare users with allowed, restricted, and absent access. Check company, organizational scope, action, and document set, including attempts to change a key or call the same API outside the UI. For CDS, check an allowed row, a filtered row, absent DCL, and explicitly permitted test bypasses if applicable.
Verify that denial did not change a document, execute an update task, or leave a partial batch. Repeat for background and external calls using their own identities. Check access and financial result separately: successful authorization does not prove a correct posting.
The sources describe the ABAP Authorization Concept and CDS authorization for the cited editions and releases. The actual authorization object, roles, and policies are defined by the target system. This project has no SAP runtime or role matrix; AUTHORITY-CHECK, DCL, and access denial were not executed.