Реализация бизнес-сценариев в рамках SAP GRC AC 10.0 при помощи технологии BRF+


3587
1

1. Введение

Продукт GRC Access Control от компании SAP AG является ключевым инструментом в борьбе за соблюдение внутрикорпоративных процедур защиты информации, выявления рисков доступа и корректного распределения полномочий между сотрудниками компании. GRC Access Control состоит из следующих компонентов: Access Risk Analysis, Access Request Management, Business Role Management и Emergency Access Management. Каждый компонент предназначен для решения определенных задач, в реализации которых используется  технология Business Rule Framework Plus (BRF+), о которой пойдет речь в данной статье. 

Статья является обзорным материалом для специалистов, которые начинают изучение инструмента BRF+ вкупе с продуктом SAP GRC, но имеют представление об основных бизнес-процессах протекающих в SAP GRC.

BRF - это инструмент проектирования и настройки правил в различных бизнес-сценариях. Он предоставляет набор классов и визуальный интерфейс, основанный на WebDynpro, для определения и настройки бизнес-правил.

Этот инструмент позволяет обеспечить прозрачность конфигурации и настройки правил без программирования в среде ABAP и, соответственно, без привлечения ABAP- программистов, так как ведение правил не нуждается в изменении программного кода. Из преимуществ также стоит отметить возможность быстрой реакции на изменения в бизнес-процессе и, соответственно, быструю разработку BRF-правил.

В статье рассматривается использование BRF+ совместно с SAP GRC Access Control 10.0. на примере реальных бизнес-сценариев.

2. Постановка задачи

Создание правил в Access Control широко используется при проектировании процессов согласования запроса на доступ или переадресации запроса при выполнении анализа на наличии риска у пользователя либо роли. Задачи, с которыми можно столкнуться в процессе проектирования и реализации бизнес-процессов в системе GRC, различны. Мы рассмотрим наиболее актуальные и предложим вариант их реализации при помощи BRF+. В статье рассматривается создание следующих типов правил: "правила инициатора" (Initiator rule) для определения пути согласования и "правила агента" (Agent rule) для определения ответственных за согласование запроса.

Стоит отметить, что помимо доступного способа реализации процесса создания бизнес-правил при помощи BRF+, ABAP-программирование всегда остается альтернативой данного механизма.

3. Бизнес-кейсы

3.1. Бизнес-кейс 1

3.1.1 Пререквизиты

Каждой SAP-роли в системе GRC AC назначается  множество атрибутов, которые сопровождают роль на протяжении всего жизненного цикла системы. Среди атрибутов наиболее важным является «Владелец роли», который автоматически определяется в цепочке согласования запроса на доступ и обязан принять решение: согласовывать или нет назначение SAP-роли пользователю.

В GRC AC для пользователя создается запрос на доступ, в котором указаны необходимые роли, а также системы, в которых должна создаться/измениться учетная запись пользователя.

К примеру, для уволенного сотрудника мы хотим отклонить назначение ролей в SAP-системе и блокировать его учётную запись с изменением срока действия для исключения её из подсчёта лицензий SAP. Вместо создания двух запросов (один запрос для отклонения назначения ролей, другой для блокировки) мы должны создать один универсальный запрос на изменение/блокировку, в котором указываем роли необходимые отклонить, и системы, в которых выполняется блокировка и изменение срока действия учётной записи пользователя .

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

3.1.2 Проблематика

При обработке такого запроса поток операций (workflow) выдаст ошибку, так как системе, добавленной в запрос, не назначен Владелец. В GRC AC, в отличие от объекта "Роль", объекту "Система" не присваивается Владелец, и GRC AC не умеет отправлять подобные комбинированные запросы на согласование без наличия определенной настройки BRF-правила. Альтернативным вариантом является создание двух запросов для одного сотрудника, но это отнимет время как на создание запросов, так и на их согласование.

3.1.3 Решение

Мы выполним конфигурацию BRF-правила, предназначенного для определения пути согласования, таким образом, чтобы запрос разделялся по типам объектов и попадал на нужный нам MSMP-путь согласования (Multi-stage multi-path), на котором задействованы актуальные участники процесса. Объект "Система" не должен попасть на согласование к Владельцу роли, иначе весь запрос будет ошибочный и не сможет выполниться корректно.

Рассмотрим классическую цепочку участников по согласованию запроса: Руководитель, Владелец роли, Сотрудник СБ (Сотрудник службы безопасности). По нашему замыслу сценарий согласования должен выглядеть следующим образом: руководитель получит запрос со всеми объектами ("роль", "система"), далее Владелец увидит в запросе только объект "роль", в которой он указан как владелец. После согласования запроса Владельцем, Сотрудник СБ сможет согласовать запрос, в котором увидит как роли, так и системы. Последовательность шагов для решения поставленной задачи описано ниже.

При создании BRF-правила определяются атрибуты (тип запроса, тип роли и т.д.), которые будут передаваться на вход таблице принятия решений (Decision Table) для обработки.

Результатом правила является MSMP-путь, по которому будет выполняться поток операций и определяться участники. Все MSMP-пути, задействованные в правиле инициатора, должны быть определены и настроены заранее.

В BRF-правиле инициатора мы должны создать таблицу принятия решений (Decision Table), на вход которой мы передаем следующие атрибуты:

  • Тип запроса (Request type) - является атрибутом запроса, который указывает на характер выполняемых действий (Создание учетной записи, Присвоение ролей, Блокировка учетной записи, Отклонение ролей и блокировка учетной записи и т.д.);
  • Тип роли (Role type) - является системным атрибутом объекта, участвующего в запросе на доступ (Одиночная роль, Производная роль, Групповая роль, Бизнес-роль, Система).

В нашем случае мы определили тип запроса "Присвоение ролей и блокировка", в котором разрешено добавлять и роль, и систему. Атрибут "Тип роли" позволяет определить тип объекта в запросе и направить один запрос на разные MSMP-пути.

Ключевым моментом является ввод значения "начальный" ("is initial") в таблицу принятия решения для "Типа роли", где значение результата соответствует MSMP-пути без Владельца роли.

В примере типу запроса "Присвоение ролей и блокировка" назначен идентификатор "005".

Мы определили следующие MSMP-пути согласования запроса на доступ:

  • ZPATH_MRS - включает в себя участников Руководитель (M - manager), Владелец роли (R - role owner), Сотрудник СБ (S - security);
  • ZPATH_MS - включает Руководителя и Сотрудника СБ.

Таблица принятия решения после выполненных действий представлена на Рис. 1.

Рис.1 Таблица принятия решения

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

3.2 Бизнес-кейс 2

3.2.1 Пререквизиты

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

Мы рассмотрим конкретную задачу, когда при помощи BRF+ удалось реализовать сложную цепочку согласования запросов в системе SAP GRC AC.

3.2.2 Проблематика

Различные запросы в системе SAP GRC AC должны быть отправлены на согласование разным цепочкам участников процесса согласования в зависимости от указанных ниже атрибутов в запросе:

  • Тип запроса - содержит операции, которые предполагается выполнить при согласовании запроса. В SAP GRC AC ведется справочник типов запросов, где каждому типу запроса назначена операция или набор операций, которые разрешены в рамках этого запроса. К примеру, тип запроса "Создать пользователя" может содержать операции "Создать учетную запись" и "Присвоить полномочия". Запрос "Блокировать пользователя" содержит операцию "Блокировать учётную запись".
  • Тип системы - классический трёхзвенный SAP-ландшафт включает в себя системы разработки, качества и продуктивную систему. Процедура согласования доступа в систему разработки или систему качества может отличаться от процедуры согласования в продуктивной системе;
  • Тип

Ограниченный доступ

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

Комментарии:

Оксана Трипутень (Рейтинг: 83) 13:37, 10 марта 2015

Хорошая статья.
Для полноты описания приведенных примеров хорошо бы увидеть анализ возможных действий согласующих лиц и связанные настройки (н-р, отклонение части запроса в первом примере на одном из этапов или маршрутизацию).
Ну и ждем продолжения :)

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»