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

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-ландшафт включает в себя системы разработки, качества и продуктивную систему. Процедура согласования доступа в систему разработки или систему качества может отличаться от процедуры согласования в продуктивной системе;
• Тип сотрудника - уровень сотрудника в организационной структуре компании влияет на цепочку согласования. К примеру, рядовому сотруднику компании требуется полная процедура согласования в отличие от CFO, CTO или CEO.
• Компания - различные филиалы или компании, составляющие структуру концерна или холдинга. Филиал компании с малочисленным штатом сотрудников может иметь упрощенную цепочку согласования доступа в SAP-системы;
• Список атрибутов достаточно большой и их использование зависит от внутренних политик авторизации в компании.

3.2.3 Решение

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

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

Пример матрицы согласования представлен на Рис. 2:

Рис. 2 Матрица согласования

На примере, в качестве входящих атрибутов указаны тип системы (DEV, QUA, PROD), тип сотрудника (сотрудник компании, сотрудник центра компетенции, внешний сотрудник), тип запроса (создание, изменение, блокировка, разблокировка и разблокировка с изменение учетной записи). Указанные значения атрибутов при создании запроса будут влиять на процедуру согласования.

На основе матрицы необходимо определить и настроить MSMP-пути, состав и порядок цепочек согласования в зависимости от характера входящих данных.

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

Для этого удобнее всего воспользоваться встроенным в BRF+ импортом Excel-файлов (см. Рис 3)

Рис 3. Импорт из Excel

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

Содержание файла после преобразования (Рис. 4):

Рис. 4 Содержание файла после преобразования

Колонка тип сотрудника (Emp Type) содержит значения:

• 001 - Сотрудник компании;
• 002 - Сотрудник центра компетенции
• 003 - Внешний сотрудник.

Колонка тип запроса (Req Type) содержит значения:

• 001 - Создание новой учетной записи
• 002 - Разблокировка и изменение учетной записи
• 003 - Изменение учетной записи
• 004 - Блокировка
• 005 - Разблокировка

Колонка результата содержит значения:

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

После группировки повторяющихся путей можно упростить содержание таблицы (Рис. 5):

Рис. 5 Упрощение содержания таблицы

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

Если структура импортированного файла не нарушена и учтен синтаксис при перечислении значений, то процедура импорта пройдет без ошибок. Таблица принятия решений в BRF-правиле будет выглядеть как на Рис. 6:

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

На последнем шаге решения следует сохранить и активировать текущую версию таблицы принятия решения, функцию и приложение BRF.

3.3 Бизнес-кейс 3

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

Компания с организационной структурой филиалов планирует определять Владельца ролей в контексте филиала, за который отвечает соответствующий Владелец ролей (Role owner). Владелец выбирается в зависимости от компании. Роли, относящиеся к одному из филиалов, должны согласовываться сотрудником или рядом сотрудников, отвечающих за их изменение и/или распределение. Решение должно обеспечивать гибкость внесения изменений в случае замены согласующего лица.

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

Реализация данной задачи достигается путём использования предусмотренного в каждой роли атрибута "Компания", который ведётся средствами SAP GRC AC (Рис. 7).

Рис. 7 Одиночная роль атрибута «Компания»

Для решения задачи необходимо  создать BRF-правило агента (Agent rule), где на вход таблицы принятия решения подать атрибут "Компания". На первый взгляд задача проста, но выясняется, что для этого бизнес-кейса возможности системы ограничены.

Дело в том, что атрибут "Компания" отсутствует как входной параметр в BRF-правиле (Рис. 8):

Рис. 8 Входной параметр в BRF-правиле

При поддержке компании SAP была выпущена нота "2009630 - UAM: Company attribute is not available in BRF rule structure for Role Approval Workflow", расширяющая набор атрибутов в структуре GRAC_S_ROLE_RULE_ATTRIBUTES.

3.3.3 Решение

После установки SAP-ноты приступаем к созданию BRF-правила агента (Agent rule).

После создания приложения в BRF-правиле первым шагом необходимо создать условие (Операция таблицы) для каждого филиала, в котором планируется назначить отдельного согласующего.

В нашем решении для филиала "11" создано условие проверки соответствия значения атрибута "Компания", указанного в роли, со значением атрибута в условии. Если роль содержит значение "11", то при проверке на равенство значений условие вернет значение "Истина", в противном случае - "Ложь" (Рис. 9 ).

Рис. 9 Условие проверки

На следующем шаге нам необходимо создать таблицу принятия решений, где на входе обозначим все условия (операционные таблицы), созданные ранее. Каждое условие должно соответствовать одному филиалу, таким образом, в таблице принятия решений на входе мы получим колонки с названиями филиалов, а в качестве результата мы обозначим учётные записи пользователей ¾ ответственных за согласование (Рис. 10).

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

При проверке условия равенства значений атрибута "Компания" операционная таблица для каждого филиала подаст на вход таблицы принятия решений, либо значение "Истина", либо "Ложь". Одна роль не может принадлежать двум филиалам (по нашей концепции), значит только одно из четырех условий вернёт значение "Истина". Получив значение "Истина" для одного из филиалов, механизм BRF+ при помощи таблицы принятия решений найдёт соответствие между филиалом и учетной записью.

Результатом выполнения BRF-правила будет являться учётная запись - пользователь, который будет согласовывать роль, относящуюся к конкретному филиалу. При необходимости мы можем расширить список согласующих для одного или нескольких филиалов, добавив еще одну строку со значением "Истина" и с учетной записью в качестве результата.

4. Заключение

Мы рассмотрели лишь несколько бизнес-кейсов, с которыми можно столкнуться в процессе реализации бизнес-процессов SAP GRC Access Control, но они дают представление о возможностях инструмента BRF+ и вариантах решения поставленных задач. Инструмент является очень гибким, и вариантов реализации одной задачи может быть несколько.

Из преимуществ BRF+ стоит отметить:

• Быструю реакцию на изменение бизнес-процессов;
• Прозрачность в настройке правил;
• Отсутствие необходимости в коммуникации между ABAP-программистами и бизнес-экспертами;
• Встроенный инструмент тестирования правил;
• Удобство графического представления.

Из недостатков стоит отметить невысокую скорость обработки запроса, в котором бизнес-логика реализуется с помощью BRF+.

Об авторе:

Парахин Константин, консультант BearingPoint. Константин окончил Московский государственный технический университет имени Н. Э. Баумана. Участвовал в проектах компании BearingPoint для клиентов Метинвест и Tele2. Специализируется в области информационной безопасности и управления рисками в системах SAP.