Центр юридических услуг

Все о ваших правах

Sap проверка полномочий

Рисунок 103: Проверка полномочий (принципиальная схема)

необходимо также выполнить ведение допустимых операций в отношении объекта. При этом из всех возможных операций выбираются те, применение которых в отношении данного объекта является целесообразным.

sy-subrc = 0 : пользователь имеет требуемые полномочия -> выполнение функции (например, SELECT );

Проверки полномочий

основные записи пользователей посредством профиля полномочий .

© 2006 г. SAP AG All rights reserved. Авторские

При определении объекта полномочий необходимо указать соответствующие поля (без значений). Фактические полномочия создаются путем присвоения значений полям. Полномочия могут быть интегрированы в необходимые

Else : полномочия отсутствуют -> вывод соответствующего сообщения для пользователя.

Для объекта полномочий может быть создано несколько разных видов полномочий (для интеграции в различные основные записи пользователей).

После этого для создания полей используется транзакция SU20 . Поле ACTVT уже существует в системе.

Рисунок 102: Объекты полномочий и полномочия (пример)

В следующем разделе представлено описание двух шагов, выполняемых разработчиком.

Значения полей, которые заранее не известны, например ZLIFNR, оставляем пустыми.

Нужно стать на введенный объект полномочий и нажать кнопку «Изменить значения полей».

Для того чтобы у суперпользователей, имеющих полномочия «SAP_ALL» появились также и все полномочия на ваш объект, нужно перегенерировать этот профиль полномочий (кнопка на панели инструментов).

SAP R

Затем, когда пользователь захочет перейти в режим изменения, выполняем более детальную проверку:

Когда нужно использовать в своих программах проверку полномочий, лучше всего пользоваться готовыми объектами полномочий, однако готовые объекты не всегда имеются в наличии и их приходится создавать.

Далее, выходим из ведения объекта полномочий, поскольку он уже сохранен.

И это полномочие присваиваются пользователю.

Система разделения полномочий в системе R/3 основана на использовании объектов полномочий, которые представляют собой определение структуры, состоящей из простых полей. На основе объектов полномочий для пользователей создаются собственно полномочия, которые представляют собой наборы конкретных значений для полей объектов полномочий.

Для этого объекта полномочий могут быть созданы полномочия

В ABAP программах проверка полномочий производится с помощью оператора

— Создать на базе вашей программы транзакцию, если ее еще нет (тр. SE93)

В операторе перечисляются все поля объекта полномочий и приводятся значения для проверки, либо употребляется ключевое слово dummy если значение конкретного поля нас в данный момент не интересует.

Сначала необходимо спроектировать сам объект полномочий, сформулировать требования к нему и на основе этого определить поля, из которых будет состоять объект. Транзакция su20 выводит список всех доступных полей полномочий.

Объект полномочий создан и настроен. Теперь необходимо создать роль и профиль пользователя. В транзакции su21 через пункты меню «Среда» — «Ведение ролей» переходим на экран создания роли. Вводим название и создаем отдельную роль.

В системе SAP проверка полномочий осуществляется с помощью объектов полномочий. Они представляют собой структуры данных, состоящие из набора полей полномочий. Этим полям присваиваются определенные значения, и таким образом, на основе объектов полномочий создаются роли и профили, которые могут быть присвоены пользователям. В этой статье будет рассмотрено пошаговое создание объекта полномочий на конкретном примере и один из способов настройки роли и профиля пользователя.

На вкладке «Полномочия» у роли теперь появилось имя созданного и сгенерированного профиля. Для того чтобы присвоить роль пользователям, необходимо перейти на вкладку «Пользователи» и указать имена пользователей системы. Назначить роль также можно из транзакции ведения пользователей su01. Чтобы изменения вступили в силу, необходимо осуществить выравнивание основных записей пользователей роли.

На вкладке «Полномочия» генерируем полномочия с помощью кнопки «Изменение данных полномочий» (Без выбора шаблона), и добавляем вручную созданный объект полномочий.

При создании объекта полномочий указывается наименование объекта, которое будет использоваться в программах, текст, класс объектов и список полей.

В транзакции su21 «Ведение объектов полномочий» объекты распределены по классам в соответствии с логикой и принадлежностью к модулям и типам бизнес объектов. Пользовательские объекты полномочий создаются в соответствующем Z-классе.

Проверка полномочий в программах производится с помощью оператора:

Создание объекта полномочий, роли и профиля

Синтаксис вызова можно вставлять в программу автоматически при помощи модели в редакторе кода.

Если необходимо, с помощью транзакции su20 можно создавать пользовательские Z-поля, указав имя и элемент данных. Например, создадим поле для вида движения:

Указываем какие действия над какими объектами разрешено совершать в рамках данного профиля. Перед сохранением необходимо сгенерировать созданный профиль.

Поле ACTVT обозначает действие производимое над объектом. Оно используется в большинстве случаев, однако не является обязательным. Для поля ACTVT необходимо выбрать допустимые операции, полномочия на которые устанавливаем. Например, устанавливаем правила только на просмотр и изменение.

В данном случае ошибка состоит в том, что консультанты чаще всего пользуются вполне логичным и напрашивающимся отчетом «Роли — по присвоению транзакции». Однако он не дает полной картины ролей с полномочиями на запуск определенной транзакции. В данном случае в списке отобразятся только те роли транзакции в которых были присвоены через вкладку «Меню». Проиллюстрирую на небольшом примере. Я создал роль Z_TEST_ROLE1 и добавил на вкладке «Меню» транзакцию MIGO — Движение материалов. При добавлении транзакции через «Меню» все необходимы для работы с ней объекты полномочий автоматически добавляются в роль. Затем я скопировал эту роль в новую Z_TEST_ROLE2 после чего в первую роль я добавил новую транзакцию SE16n через Меню, а во вторую вручную через добавление объекта полномочий «S_TCODE — Проверка на код транзакции при запуске» со значением поля TCD — SE16n. Вот так выглядят объекты полномочий в ролях после добавления транзакции SE16n

2. Генерация профилей. Допустим необходимо добавить сотруднику некоторые полномочия. Мы находим нужную роль и присваиваем ее соответствующему пользователю, но его полномочия в системе не изменяются. Ошибка, в данном случае в том, что мы, присвоив пользователю роль не проверили ее профиль полномочий. Это может выглядеть, например, вот так:

Метки: Autorization, SAP ( 11 ), SAP Autorization concept, SAP Security ( 2 ), SUIM

После того как профиль сгенерирован можно присваивать роль пользователю.

SAP, IT and all

Профиль полномочий — это совокупность всех объектов полномочий чаще всего привязанная к роли. Он состоит из тех объектов полномочий и их значений которые мы добавили в роль. Первоначально в роли отсутствует профиль полномочий, его нужно генерировать. Это касается как новых Z* так и стандартных ролей SAP. Каждое изменение в значениях полномочий в роли требует перегенерации ее профиля.

Как мы можем убедимся в список отчета «Роли — по присвоению транзакции» при поиске ролей в которых есть транзакция MIGO попадут обе мои тестовые роли, а при поиске прав на SE16 только первая в которую мы добавили полномочия через меню.

Значения полномочий в роли Z_TEST_ROLE2

Системы SAP имеют интересную реализацию предоставления полномочий. Подробнее о Концепции авторизации SAP (SAP Authorization concept) я напишу в следующих постах. Сегодня же я хочу поговорить о тех ошибках, которые иногда совершают консультанты при работе с ролями и полномочиями в SAP NW AS ABAP.

1. Полномочия на доступ к транзакции. Нам требуется найти роль в которой содержатся полномочий к определенной транзакции или транзакциям. Для поиска таких ролей чаще всего пользуются транзакцией SUIM.

Значения полномочий в роли Z_TEST_ROLE1

Генерация профиля производится через транзакцию PFCG (Role Maintenance and the Profile Generator ) на вкладке «Полномочия»

Правильно будет воспользоваться другим отчетом «Роли — по значения полномочий» с указанием искомых транзакций в качестве значений поля TCD объекта полномочий S_TCODE

Самое интересное, что полчаса назад "само прошло".

Обнаружено несколько ролей у сотрудников бухгалтерии, где выше перечисленные полномочия есть.

Sap проверка полномочий

Сделал нового пользователя, сделал для него роль только на эту транзакцию, попробовал под ним и "прошло".

— Может ли настоящий мастер кунг-фу получить по морде?

Если первое — то что в этом плохого? Ну проверяет и проверяет. никто же не обязывает давать эти полномочия?

а вы воспроизводили ситуацию? Может оказаться так, что любопытный пользователь жмет например F1 на поле и в дальнейшем пытается провалиться в программу, на что получает закономерный отлуп. А полчаса назад ему это надело

Под собой запускаю Z-транзакцию, и при появлении экрана ввода у меня уже есть проверка полномочий на отладчик.

Чтобы убедиться, что проверка полномочий на чтение инфотипов автоматически активируется, запустим следующий вариант программы

При таких исходных данных, таблицы lt_pa0002 и lt_1000 оказались пустыми, что, в общем, логично, исходя из тех полномочий, которые есть у пользователя.

N.B. После того, как вы отключили проверку структурных полномочий и получили в ходе выполнения программы необходимые данные, проверку следует включить. Для этого необходимо вызвать ФМ RH_AUTHORITY_CHECK_ON. Для чтения же инфотипов проверку включать не нужно, так как она отключается непосредственно перед самим чтением, и затем будет автоматически активирована.

Про полномочия в SAP HCM можно говорить много. Тема довольно обширная, и посвятить ей одну заметку, как мне кажется, мало. Поэтому делать этого в настоящий момент не буду.

Рассмотрим простой пример. Есть пользователь DEMO_USER1 в роли которого присутствует объект полномочий P_ORGIN со следующим наполнением

Отключение проверки полномочий в ABAP программе.

Отключение проверки полномочий в ABAP программе

Пишем простенькую программу для чтения инфотипа 0002 — «Personal Data» и чтения инфотипа 1000 — «Object» для объекта S — «Position» без отключенной проверки полномочий.

Мягко говоря, полномочия не очень-то уж и «обширные».

Теперь пишем программу, в которой проверка полномочий будет отключена. Для этих целей, в самом начале программы необходимо вызвать два функциональных модуля:

Помимо объекта полномочий P_ORGIN с доступом к инфотипу 0001 — «Organizational Assignment» в роли присутствует объект полномочий PLOG, в котором содержится несколько инфотипов для объекта O — «Organizational Unit»

Плюс ко всему, ему присвоен структурный профиль полномочий для просмотра только объектов O — «Organizational Unit»

Как видите, таблицы lt_pa0002 и lt_1000 были заполнены каким-то значениями. Хотя эти же таблицы были пустыми в первой «редакции» программы.

В SAP-системе предусмотрен гибкий универсальный метод обеспечения безопасности данных. Однако из-за недостаточного внимания к изменениям в распределении полномочий в продуктивных системах могут возникать несоответствия между желаемой концепцией полномочий и фактическими возможностями пользователей.

Услуга «User & Role Analysis» позволяет быстро проанализировать действия пользователей и их полномочия, оценить корректность назначения и степень использования ролей, а также правильность присвоения/использования лицензий. Эта информация даст возможность управлять своими лицензиями SAP и выявить потенциальные источники сокращения затрат на лицензирование.

Воспользуйтесь этой услугой, если Ваша компания удовлетворяет следующим критериям:

Анализируются критические действия и полномочия пользователей на соответствие внутренним стандартам безопасности SOD (Segregation of Duties) и внешним требованиям согласно закона SOX (Sarbanes-Oxley Act).

  • Анализ использования лицензий

    Сравниваются лицензионные данные с фактическими действиями пользователей в системе, проводится оценка правильности присвоения/использования лицензий.

  • Полученные результаты позволят регулировать свою стратегию авторизаций, чтобы удовлетворять оперативным потребностям пользователей. Именно с этого начинается эффективное использование SAP-системы.

  • Проверка и поддержка безопасности

    • Вы используете решение SAP;
    • Вы планируете приобретение дополнительных лицензий SAP для новых проектов;
    • Перед Вами стоит задача проверить существующую систему полномочий на соответствие SOX/SOD.
    • При оказании услуги проводится документирование действий пользователей в контексте назначенных им авторизаций. Вы получите исчерпывающую информацию о том, как в действительности используется Ваш Концепт полномочий.

    • Оптимизация системного использования

      Выявление и исправление нарушений в двойном принципе контроля приведет к существенным улучшениям в вопросах информационной безопасности.

    • Оценка ситуации с лицензированием

      Проводится сравнение существующих авторизаций пользователей с действиями, которые они в действительности выполняют в системе.

    • Проверка безопасности

      Услуга «User & Role Analysis» включает следующие сервисы:

      Анализ использования лицензий позволит выявить неиспользуемые лицензии, которые в дальнейшем можно направить на новые проекты развития. Эффективное управление лицензиями приводит к более сбалансированным административным затратам.

    Затем понятное дело нужно добавить в своего пользователя данное полномочия для тестирования.

    1. Согласовать с клиентом список статусов (и кто за них будет отвечать)
    2. Подвесить проверку авторизации и непосредственно в транзакции F-47, FB02

    Сначала заходим в транзакцию SU20 и добавляем нужное поле.

    Осталось в тудузник ещё отложить пункты:

    Добавлять свои элементы в интерфейс — сложно, так как отчетик был написан на базе  ‘REUSE_ALV_GRID_DISPLAY_LVC’.

    В первую очередь мне хотелось избежать сложности включения управления этим статусом .

    Сначала заходим в бухгалтерский документ и смотрим техническую информацию.

    У нас это разведено, поэтому для выполнения такого дела мне понадобилось обратиться к администратору.

    Проверяем, всё работает правильно (и даже не смотря на включенный профиль SAP_ALL).

    Справочник по таблице T008 – очень хорошо.

    Иван Болховитинов

    Сначала у меня был стандартный интерфейс ввода «Требований авансового платежа» (f-47) и свой собственный отчетик следующего вида:

    Добавляем сюда наш элемент данных и экраны где он участвует.

    Параметр AUTSW ADAYS в той же таблице отвечает за количество дней, в течение которых пользователь будет иметь доступ к «устаревшему» объекту. Например, если у пользователя есть полномочия на «Отдел 1», а сотрудника перевели 10 марта в «Отдел 2», то у пользователя будет доступ к этому сотруднику то количество календарных дней, которое указано в параметре ADAYS. Например, если там стоит 10, то 21 марта доступ к переведенному сотруднику пропадет. Следует отметить, что параметр применим и к обычной проверке доступа через объект P_ORGIN. Если установить значение параметра в 0, то ограничения снимаются.

    Не забывайте, что структурные полномочия применимы только к данным HR. Другие объекты полномочий не имеют ссылки на профиль структурных полномочий и не могут работать вышеуказанным способом.

    Но нет полномочий на ведение отсутствий у нее же.

    SAP HR от Поцелуева

    Одним из способов может быть отключение индексирования полномочий на время дневного бодрствования и включение ночью перед загрузкой в BW.

    И еще один нюанс со структурными полномочиями. Мы можем напрямую сказать, какой профиль структурных полномочий к какому пользователю применять. Система сама по себе не понимает какой профиль считывать для предоставления полномочий, несмотря на то что мы указали профиль в роли. Для этого существует отдельная таблица/ракурс OOSB. В ней мы можем указать пользователей поименно с нужными профилями. А можем указать системную запись «SAP*», которая будет по умолчанию применяться ко всем пользователям, которых мы не указали. Я бы рекомендовал сделать один профиль структурных полномочий, если это возможно, присвоить его системному пользователю «SAP*», чтобы этот профиль работал для всех пользователей. А системным пользователям для фоновых заданий и расчетчикам, которые запускают заработную плату по всей организационной структуре, присвоил бы профиль «ALL» – вся структура.

    Для начала мы стали видеть все табельный номера.

    Возможно отказаться от использования индексов, что в небольшой компании никак не скажется на производительности. Но, если у вас есть планы использовать систему аналитичеcкой отчетности SAP BW и использовать структурные полномочия из системы HR, то индексы необходимы. Стандартное решение SAP предполагает загрузку этих индексов в BW для целей управления полномочиями.

    На текущий момент автору известен один побочный эффект. Существует возможность индексировать структурные полномочия, что ускоряет доступ к данным, так как системе не приходится каждый раз вызывать функциональные модули и «обходить» все объекты организационного менеджмента согласно настроенному пути анализа. Но бесплатно бывает только сыр в мышеловке. За индексацию приходится платить… отсутствием полномочий. На одном из проектов мы столкнулись с ситуацией, когда в момент индексации у пользователей пропадал доступ. Процедура индексации обычно длилась одну минуту, и если в это время совпадало так, что в индексе не было нужного объекта, а пользователь пытался обратиться к нему, то системе сообщала об отсутствии полномочий. Например, вы делаете перевод сотрудника из одного подразделения в другое, и сразу же после сохранения данных в системе запускается индексация (например, по расписанию). Есть минимальный, но шанс, что при попытке открыть этого сотрудника уже в новом подразделении вы не сможете, так как момент вашей попытки совпадет с моментом индексации полномочий. Также, если вы создаете новую организационную единицу, то ее новый ID может выпасть из индекса, а следовательно, у вас не будет полномочий на нее сразу же после сохранения записи.

    Что мы сделали? Мы создали профиль структурных полномочий, который пока «сам по себе и никакой власти не имеет». В профиле мы обозначили тип объекта – O “Организационная единица”. Можно указать идентификатор напрямую в поле “ИдОбъекта”, а можно указать функциональный модуль, который должен вернуть перечень объектов, к которым разрешен доступ. В нашем случае модуль возвращает только один объект – вышестоящую организационную единицу. Чтобы получить подчиненную структуру со всеми штатными должностями и табельными номерами (лицами), мы указываем путь анализа, который и предоставляет нужную информацию.

    Есть доступ на инфотип 0008 девушки из первого отдела.

    Логика работы структурных полномочий достаточно простая. В «PFCG роли» доступ к данным определяется не объектом P_ORGIN, как мы привыкли в HR, а объектом P_ORGINCON (описание можно посмотреть в транзакции SU21). Разница лишь в том, что в последнем есть дополнительное поле PROFL, где указывается профиль структурных полномочий. В свою очередь профиль структурных полномочий определяет к каким объектам организационного менеджмента предоставить доступ. Таким образом, если в профиле указаны все объекты типа P (Лицо), то система предоставит доступ ко всем табельным номерам. Если указать, например, путь анализа C-P, то доступ будет предоставлен только к определенным табельным номерам, которые присвоены к указанной должности (наш пример с секретарями и старшим).

    Система честно предупредила, что «есть еще, но не дам». Если вернуться к организационной структуре выше, то вы увидите, что обе девушки работают в «Отдел 1». Заходим в инфотип 0008 «Основные выплаты» в режиме изменения.

    2. Введите нового пользователя в поле User ID (см. рис. 8.15 для пользователя MUSTERMANN). Пользователь уже должен быть определен.

    ► С — Объект полномочий проверяется для транзакции

    — Создать или изменить значения объекта полномочий, выбрав соответствующий символ в строке. Например, если обратиться к рис. 8.14, то рекомендуется создать значения полномочий на устройства в системе спула R/3. Эти значения описывают имена устройств, на которые распространяются полномочия. Например, D* означает все имена устройств, начинающиеся с D.

    Затем можно вручную изменить объекты полномочий или составных профилей для отдельных транзакций. Для этого используется ►Check Indicators в Customizing (см. рис. 8.9).

    Для определения пользователя надо ввести уникальное имя пользователя в поле User. В Basic Release 4.6C и более поздних версиях можно использовать поле Alias (псевдоним) для выбора пользователей с помощью дополнительного идентификатора, которые пользователи создают, например, из транзакций Интернет в области самообслуживания. В этом месте нельзя создать псевдоним. В следующем примере предполагается, что пользователь MUSTERMANN создан с помощью User names • Create или с помощью соответствующей пиктограммы.

    3. Задайте тип пользователя. Тип часто соответствует прикладной области и ограничивает права пользователя. Например, «KNA1» означает, что данную транзакцию Интернета может выполнять только сам пользователь.

    При создании нового пользователя администратор присваивает начальный пароль, который пользователь должен изменить во время первой регистрации в системе. Этот пароль вместе с именем пользователя требуется для регистрации в системе SAP. Для пароля есть несколько правил, некоторые из которых предопределены и неизменяемы, а другие могут изменяться с помощью параметров профилей. Предопределенными правилами являются следующие:

    Пользователь с типом Service является диалоговым пользователем, который доступен для большой анонимной группы пользователей, например для доступа через Интернет Transaction Server (ITS). Для этого типа пользователей не выполняется никакой проверки окончания срока действия или начальных паролей, и явно разрешена множественная регистрация. Однако по соображениям безопасности необходимо только назначать таких пользователей с большой осторожностью и с ограниченными полномочиями.

    ► Конфигурирование административного пользователя в центральной системе

    Профили в R/3 могут иметь разные состояния:

    ГЛАВА 8 ПОЛЬЗОВАТЕЛИ И ИХ ПОЛНОМОЧИЯ В СИСТЕМЕ R

    Все описанные в предыдущих разделах данные можно снова изменить позже в таких же транзакциях. Одновременное изменение нескольких пользователей может быть крайне трудоемким. К счастью, для этого существует специальная функция ►Mass Change, которая позволяет создавать и выполнять большинство изменений при администрировании пользователей для выбранного множества пользователей.

    Полномочия системного администрирования также должны разделяться в соответствии с областями ответственности и распределяться с помощью ролей (см. раздел 8.3.8). Система SAP имеет несколько профилей, которые особенно важны для администрирования и которые иногда должны назначаться явно (см. таблицу 8.4).

  • Proudly powered by WordPress