SAP GRC защитит корпорации от мошенничества сотрудников
Компания SAP представила решение SAP GRC, призванное предотвратить миллионные убытки, наносимые организациям злонамеренными действиями сотрудников.
В целом SAP GRC («Управление рисками и соответствие требованиям регулирующих органов») является интегрируемым масштабируемым решением, использующим обширный функционал для обнаружения и управления рисками и непрерывного контроля бизнес-процессов.
Продукт включает в себя следующие компоненты: SAP GRC Access Control — для управления рисками несанкционированного доступа и распределения должностных обязанностей; SAP GRC Process Control — для управления процессами обеспечения соответствия требованиям регуляторов, автоматизации процессов внутреннего контроля и управления рисками достоверности финансовой отчетности; SAP GRC Risk Management — для управления корпоративными рисками. Как сообщили CNews в компании, эти компоненты используют единый пользовательский интерфейс и основные данные, применяемые, например, при документировании бизнес-процессов и контролей.
Реализация системного подхода к управлению рисками требует наличия соответствующих инструментов. Автоматизация процесса внутреннего контроля средствами специализированных информационных систем существенно повышает эффективность процесса контроля, считают в SAP.
По данным компании, решение SAP GRC позволяет компаниям соответствовать требованиям информационной безопасности в части обеспечения безопасности ИСПДн (информационная система персональных данных), а также разграничения полномочий сотрудников, и контролировать риски несанкционированного доступа в режиме реального времени. «Совместная работа решений SAP GRC позволяет выявлять и предотвращать случаи мошенничества не только посредством выявления конфликтов разделения полномочий, но и в случае, когда мошенничество реализуется на уровне разрешённых функций посредством непрерывного мониторинга бизнес-процессов компании», — подчеркнули в SAP.
Вместе с системой SAP GRC компаниям также доступна матрица контроля и мониторинга бизнес-процессов, матрица разделения полномочий и начальный каталог рисков с ключевыми индикаторами риска, среди которых такие факторы, как проверка отклонения цены в счете-фактуре по сравнению с заказом на закупку, проверка отклонения количества закупаемого товара и накладной, проверка на расхождения в дате поставки, динамика изменения цен за последние три месяца, закупка без контракта и др.
Карина Саркисян, партнер группы управления рисками организаций компании «Делойт» считает, что внедрение и поддержание руководством организации системы внутреннего контроля наиболее результативно для снижения рисков мошенничества. Оптимальным решением, по её мнению, может быть сбалансированный подход, при котором организация и исполнение процесса внутреннего контроля является обязанностью руководителей, участвующих в операционной деятельности, а за эффективностью средств контроля следит подразделение внутреннего аудита. «Важным принципом внутреннего контроля является разграничение полномочий сотрудников. Нарушение этого принципа может привести к ошибкам или злонамеренным действиям сотрудников, которые не будут своевременно выявлены», — добавила Карина Саркисян.
Sap grc pc что это
В Москве прошла Открытая конференция ИСП РАН
21.12.2021
Кейс-конференция “Безопасное цифровое производство” 2022
20.12.2021
Во всем мире происходит перелом в сторону интернационализации
20.12.2021
11.12.2021
Что повысит конкурентоспособность?
02.11.2021
21.09.2021
Поможет ли стратегия развитию Open Source в России?
18.08.2021
Платформенный бизнес в России
16.05.2021
13.02.2020
Чат-бот CallShark не требует зарплаты, а работает круглосуточно
24.12.2019
До встречи в «Пьяном Сомелье»!
21.12.2019
Искусство как награда Как изготавливали статуэтки для премии IT Stars им. Георгия Генса в сфере инноваций
04.12.2019
ЛАНИТ учредил премию IT Stars памяти основателя компании Георгия Генса
04.06.2019
Маркетолог: привлекать, продавать, продвигать?
Рубрика: Управление рисками
Управление – риски – соответствие
Этими процессами можно оперировать с помощью решений GRC
Аббревиатура GRC (Governance Risk Appliance) для российского рынка ИТ достаточно нова. Многие наслышаны о ней, однако далеко не каждый ИТ-руководитель сможет внятно объяснить, что это такое, а тем более назвать основных игроков данного направления. В этой статье я рассмотрю концепцию GRC с точки зрения ИТ вообще и информационной безопасности в частности. Также приведу примеры решений и опишу основные трудности, связанные с внедрением этих решений в России.
Начнем с определения термина GRC. Перевод следующий: Governance – стратегическое управление, Risk Management – управление рисками, Compliance – управление соответствием. Объединение этих процессов в одну группу позволяет добиться высокой эффективности их реализации за счет единых источников информации о рисках и контролях, управлении целями на основании результатов анализа рисков и соответствиями с учетом существующего контроля.
Не слишком понятное объяснение, не так ли? Отчасти поэтому на рынке существует довольно большая путаница относительно термина GRC. И пока общепринятого определения не существует. Конкретные требования к GRC могут определяться направлением деятельности компании или эксперта. При этом GRC определяется ими как совокупность технических решений. А требования должны соответствовать нормативам и лучшим практикам при условии оптимизации управления рисками.
На Западе данное направление развивается благодаря требованиям регуляторов, а именно документам SOX (Sarbanes-Oxley Act, финансовая отчетность для предприятий), Basel-II (требования к банковским капиталам), HIPAA (Health Insurance Portability and Accountability Act – требования к хранению медицинских данных граждан) и других. Данные документы прямо указывают на необходимость в организации внутренних систем управления ИТ, которые позволят эффективно управлять рисками. Российские же регуляторы пока не сильно требуют наличия в организации четкого набора правил и процедур, позволяющих эффективно управлять рисками, избегая «тушения пожаров», возникающих из-за несогласованности и размытой ответственности при управлении рисками.
Достичь целей GRC только с помощью развертывания в компании какого-либо ИТ-решения невозможно. Опыт показывает, что для эффективного управления рисками требуются наличие регламентов и процедур для управления ИТ и теми же рисками, эффективное взаимодействие специалистов из различных подразделений, грамотно использующих данные документы. Также все бизнес-процессы в компании должны быть автоматизированы для эффективного контроля всех критичных для GRC задач.
Какие компании используют GRC
Решения GRC достаточно специфичны и, скажем честно, не всем компаниям подходят. И речь здесь не только о бюджетах и размерах организации. Например, если почтовый сервер или каталог Active Directory нужны практически любой компании с численностью более 10 человек, то GRC требуется организациям, к которым предъявляются более критичные требования. Каковы же они?
Прежде всего это наличие сложной гетерогенной ИТ-инфраструктуры, состоящей из множества решений различных вендоров. При этом важным критерием является количество пользователей в корпоративной сети. Для того чтобы внедрение GRC было оправдано, их должно быть не менее тысячи. Также необходимо наличие нескольких критичных бизнес-приложений, сбор сведений с которых необходим для комплексной оценки рисков.
Еще одним немаловажным критерием является необходимость наличия у заказчика высокого уровня развития процессов ИБ. То есть недопустимой является ситуация, когда развитие ИТ и ИБ в организации находится на начальном уровне. Как минимум у руководства должно быть осознание необходимости процессов управления ИБ и предприняты меры по их формализации. Важным практическим аспектом применимости решений GRC является возможность использования многочисленных требований государственных регуляторов. Здесь наглядным примером являются требования российских госорганов к защите персональных данных (ПДн). Зачастую бизнес-приложения построены таким образом, что каждый пользователь (которых несколько тысяч) обрабатывает на своей машине ПДн. И выполнение всех требований законов приведет к многомиллионным затратам, которые выражаются либо в необходимости модификации приложений, либо в установке на них средств защиты. Использование GRC позволит учитывать данные риски при проектировании новых бизнес-систем.
Ну и, наконец, необходимо, чтобы в компании было несколько подразделений, заинтересованных во внедрении GRC. Типичной при внедрении какой-либо системы является ситуация, когда руководитель одного из подразделений (ИТ или ИБ) пытается внедрить в компании то или иное решение и сталкивается с отчаянным сопротивлением своих коллег из других подразделений. Причины такого противостояния могут быть различны, например, нежелание ИТ находиться под контролем ИБ, но результат всегда один – решение не удается внедрить. Таким образом, обязательным условием успешного внедрения GRC является наличие нескольких заинтересованных подразделений (внутренний контроль, операционные риски, соответствие требованиям регуляторов, информационная безопасность, информационные технологии) и их желание усовершенствовать свою деятельность.
Теперь немного поговорим о том, что заказчик получит в результате внедрения. Прежде всего GRC позволяет получить целостную картину состояния ИБ в организации. Будут выявлены наиболее рискованные бизнес-процессы. Также можно будет определить приоритеты для решения тех или иных задач обеспечения ИБ. Благодаря отчетам GRC можно будет получить информацию о том, какие отделы выполняют аналогичные функции, насколько эффективно расходуются выделяемые ресурсы. На основании этих данных можно будет выстраивать соответствие требованиям регуляторов.
Ну а теперь перейдем к описанию непосредственно технических решений, предназначенных для GRC.
SAP GRC – это решение от известного германского разработчика. Возможно использование нескольких модулей в зависимости от решаемых задач.
Модуль Business Objects Process Control встраивается в стандартные бизнес-процессы. Его преимуществом является возможность получать информацию о состоянии рисков напрямую из бизнес-систем посредством автоматического сбора информации Условным недостатком, впрочем, присущим всем GRC-системам, можно назвать необходимость досконального знания бизнес-процессов в организации.
Второй модуль SAP Business Objects Risk Management позволяет создать автоматизированную среду для управления, мониторинга и анализа рисков, а также реакции на инциденты. Здесь решение представляет собой отдельное приложение, которое осуществляет сбор информации с бизнес-приложений посредством коннекторов. Корреляция собранных событий осуществляется ядром системы, которое и производит наблюдение за совокупностью рисков и своевременно сообщает менеджерам о превышении пороговых величин, определенных в компании.
В этом модуле возможно также использование двух компонентов: SAP GRC Access Control и SAP GRC Process Control. SAP GRC Access Control предназначен для управления рисками несанкционированного доступа и контроля использования сотрудниками должностных обязанностей. Здесь реализован функционал, который обычно используется в SIEM-системах, такой как учет неудачных попыток входа в систему, работа под правами администратора, использование административных привилегий и тому подобное. Однако в данном случае модуль Access Control имеет заранее заданный набор правил, по которым и осуществляются контроль событий и проверка на соответствие уже заданным правилам корреляций.
Второй модуль SAP GRC Process Control предназначен для управления процессами обеспечения соответствия требованиям регуляторов. Функционал данного модуля в России будет наиболее полезен для финансовых организаций и банков, так как здесь используются требования таких стандартов, как PCI-DSS, SOX и прочие.
Как и следовало ожидать, данный продукт ориентирован на работу с другими модулями SAP.
Говорить о стоимости внедрения решения можно очень примерно, так как, помимо цены лицензий, необходимо также учитывать огромный объем работы для аналитиков, которые будут внедрять продукт у конкретного заказчика. Тем не менее примерный ценник внедрения SAP GRC начинается от одного миллиона евро за представленный набор модулей.
Компания IBM также представила на рынке свое решение GRC. IBM OpenPages GRC – это не просто приложение, а, по сути, интегрированная платформа управления рисками предприятия и контроля за соблюдением нормативных требований. Это решение также интегрируется в существующую инфраструктуру бизнес-приложений. Стоит отметить, что функционал данного продукта охватывает область рисков и соблюдения нормативных требований западных регуляторов.
В состав IBM OpenPages входит и OpenPages IT Governance, с помощью которого можно настроить правила, позволяющие отслеживать соответствие существующей ИБ-инфраструктуры требованиям стандартов и регуляторов. Здесь также имеется набор готовых правил и корреляций для различных нормативных требований. При необходимости можно составлять и собственные правила.
Еще один модуль IBM OpenPages Financial Controls Management позволяет автоматизировать процесс управления средствами финансового контроля. По сути, он содержит набор правил, для соответствия западным требованиям SOX. Так как на российском рынке это может быть актуально только для организаций, работающих с западными финансовыми компаниями, область применения данного компонента не слишком велика.
И, наконец, последний модуль IBM OpenPages Operational Risk Management позволяет автоматизировать процесс выявления и анализа операционных рисков и управления ими, а также дает возможность предприятиям собирать все данные о рисках в единой среде безопасности.
В целом это решение, так же как и SAP GRC, ориентировано на соответствие западным стандартам и для использования в российских реалиях требует существенной доработки.
Еще один крупный игрок на рынке GRC – компания RSA.Ее продукт RSA Archer eGRC аналогично ориентирован на анализ рисков, позволяет создавать совместную программу eGRC для управления рисками предприятия. Здесь также производится контроль соответствия требованиям регуляторов и контроль управления рисками на предприятии. Гибкая платформа RSA Archer eGRC позволяет интегрировать систему с многочисленными источниками данных без написания программного кода. То есть имеющийся функционал коннекторов, отвечающих за сбор информации с источников, достаточно гибок в использовании и не требует специальных знаний по программированию. Дополнительные компоненты RSA Archer eGRC Community при взаимодействии с Exchange предлагает поддержку работы с пользовательскими рассылками и оперативный обмен приложениями, а также услугами и средствами интеграции.
Еще одна компания, без решений которой на сегодняшний день не обходится ни одно крупное направление, – это HP. На рынке GRC она представляет свой продукт HP EnterpriseView. Ключевыми функциями данного продукта являются возможность объединения ИТ- и бизнес-приоритетов с общими целями и, следовательно, совместное понимание методов решения поставленных задач.
Продукт позволяет осуществлять непрерывный мониторинг рисков и их соответствие западным стандартам даже в постоянно изменяющейся ИТ-инфраструктуре. Используются технологические решения для управления и исправления документов.
Управление активами производится через интуитивно понятные доски управления (dashboards).
Одной из наиболее интересных особенностей HP EnterpriseView является возможность интегрироваться с другим широко известным решением – HP ArcSight. Благодаря этому сбор информации о событиях существенно упрощается, так как за это отвечает ArcSight, и его богатый функционал по подключению различных типов источников позволяет подключать практически любые приложения, которые генерируют журналы событий.
Как и все остальные решения, данный продукт ориентирован на требования западных регуляторов.
Описание основного функционала GRC-решений можно свести в единую таблицу (см. таблицу 1).
Таблица 1. Основной функционал GRC-решений
Оценка и управление ИТ-рисками:
Направление управления рисками и соответствия стандартам является сложным и относительно новым видом деятельности на рынке ИБ. Все задачи GRC нельзя решить только техническими средствами, необходимо также использовать регламенты и иные нормативные документы. Важна также заинтересованность различных подразделений в получаемом результате.
Что касается непосредственно существующих продуктов, то, пожалуй, их основным недостатком является четкая ориентация на иностранные стандарты и нормативные требования. Для разработки правил соответствия необходимо существенно дорабатывать имеющиеся решения.
Реализация бизнес-сценариев в рамках SAP GRC AC 10.0 при помощи технологии BRF+
Парахин Константин
Статья является обзорным материалом для специалистов, которые начинают изучение инструмента BRF+ вкупе с продуктом SAP GRC, но имеют представление об основных бизнес-процессах протекающих в SAP GRC.
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.
Этот инструмент позволяет обеспечить прозрачность конфигурации и настройки правил без программирования в среде 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-систему, после чего выбрать значения параметров.
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), на вход которой мы передаем следующие атрибуты:
В нашем случае мы определили тип запроса «Присвоение ролей и блокировка», в котором разрешено добавлять и роль, и систему. Атрибут «Тип роли» позволяет определить тип объекта в запросе и направить один запрос на разные MSMP-пути.
Ключевым моментом является ввод значения «начальный» («is initial») в таблицу принятия решения для «Типа роли», где значение результата соответствует MSMP-пути без Владельца роли.
В примере типу запроса «Присвоение ролей и блокировка» назначен идентификатор «005».
Мы определили следующие MSMP-пути согласования запроса на доступ:
Таблица принятия решения после выполненных действий представлена на Рис. 1.
Рис.1 Таблица принятия решения
Преимуществом данного подхода является возможность избежать создания двух запросов, один из которых содержит роли, подлежащие отклонению, а второй содержит системы, в которых необходимо изменить срок действия учетной записи. Тем самым значительно сокращается время выполнения процедуры и гарантируется соблюдение условий SLA.
3.2 Бизнес-кейс 2
3.2.1 Пререквизиты
Необходимость в различных процессах (цепочках) согласования запроса возникает в случае расширенной организационной структуры и объемного системного ландшафта в компании. Требования к процессу согласования порой настолько индивидуальны, что реализовать их в системе становится затруднительно.
Мы рассмотрим конкретную задачу, когда при помощи BRF+ удалось реализовать сложную цепочку согласования запросов в системе SAP GRC AC.
3.2.2 Проблематика
Различные запросы в системе SAP GRC AC должны быть отправлены на согласование разным цепочкам участников процесса согласования в зависимости от указанных ниже атрибутов в запросе:
3.2.3 Решение
Решение такой задачи невозможно без использования BRF+, когда на вход таблицы принятия решений мы объявляем множество атрибутов с набором значений.
Основной и самой трудоемкой проблемой является формирование матрицы согласования, в которой указаны все возможные варианты пересечения входящих атрибутов с цепочками участников процесса согласования.
Пример матрицы согласования представлен на Рис. 2:
Рис. 2 Матрица согласования
На примере, в качестве входящих атрибутов указаны тип системы (DEV, QUA, PROD), тип сотрудника (сотрудник компании, сотрудник центра компетенции, внешний сотрудник), тип запроса (создание, изменение, блокировка, разблокировка и разблокировка с изменение учетной записи). Указанные значения атрибутов при создании запроса будут влиять на процедуру согласования.
На основе матрицы необходимо определить и настроить MSMP-пути, состав и порядок цепочек согласования в зависимости от характера входящих данных.
По завершению определения и формирования матрицы согласования мы можем приступать к конфигурированию BRF-правила инициатора, в частности нам необходимо отобразить матрицу согласования в таблице принятия решения.
Для этого удобнее всего воспользоваться встроенным в BRF+ импортом Excel-файлов (см. Рис 3)
Рис 3. Импорт из Excel
Предварительно нужно преобразовать бизнес-формат матрицы согласования в формат импортируемого файла, но только после того, как все обозначенные объекты (типы запросов, типы сотрудников, коннекторы систем разработки, качества и продуктивной системы) созданы в SAP GRC.
Содержание файла после преобразования ( Рис. 4):
Рис. 4 Содержание файла после преобразования
Колонка тип сотрудника (Emp Type) содержит значения:
Колонка тип запроса (Req Type) содержит значения:
Колонка результата содержит значения:
После группировки повторяющихся путей можно упростить содержание таблицы ( Рис. 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-правиле
3.3.3 Решение
После установки SAP-ноты приступаем к созданию BRF-правила агента (Agent rule).
После создания приложения в BRF-правиле первым шагом необходимо создать условие (Операция таблицы) для каждого филиала, в котором планируется назначить отдельного согласующего.
Рис. 9 Условие проверки
На следующем шаге нам необходимо создать таблицу принятия решений, где на входе обозначим все условия (операционные таблицы), созданные ранее. Каждое условие должно соответствовать одному филиалу, таким образом, в таблице принятия решений на входе мы получим колонки с названиями филиалов, а в качестве результата мы обозначим учётные записи пользователей ¾ ответственных за согласование ( Рис. 10).
Рис. 10 Таблица принятия решений
При проверке условия равенства значений атрибута «Компания» операционная таблица для каждого филиала подаст на вход таблицы принятия решений, либо значение «Истина», либо «Ложь». Одна роль не может принадлежать двум филиалам (по нашей концепции), значит только одно из четырех условий вернёт значение «Истина». Получив значение «Истина» для одного из филиалов, механизм BRF+ при помощи таблицы принятия решений найдёт соответствие между филиалом и учетной записью.
4. Заключение
Мы рассмотрели лишь несколько бизнес-кейсов, с которыми можно столкнуться в процессе реализации бизнес-процессов SAP GRC Access Control, но они дают представление о возможностях инструмента BRF+ и вариантах решения поставленных задач. Инструмент является очень гибким, и вариантов реализации одной задачи может быть несколько.
Из преимуществ BRF+ стоит отметить:
Из недостатков стоит отметить невысокую скорость обработки запроса, в котором бизнес-логика реализуется с помощью BRF+.
Об авторе:
Парахин Константин, консультант BearingPoint. Константин окончил Московский государственный технический университет имени Н. Э. Баумана. Участвовал в проектах компании BearingPoint для клиентов Метинвест и Tele2. Специализируется в области информационной безопасности и управления рисками в системах SAP.
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
