Grc access control что это

Обновлено: 14.05.2024

В составе нашей команды опытных специалистов тебе предстоит работать над созданием и развитием комплексных автоматизированных решений по управлению доступом и полномочиями в ИТ-ландшафте, управлению бизнес-процессами внутреннего контроля и риск-менеджмента. В первую очередь это решения на базе продуктов SAP GRC - Access Control, Process Control и Risk Management. При этом мы стараемся не ограничивать кругозор одной линейкой решений, поэтому также занимаемся и другими востребованными на рынке платформами.

Ты будешь участвовать в проектах внедрения и развития информационных систем в роли ведущего консультанта, демонстрируя экспертизу и привнося свой вклад в общее продвижение на всех стадиях проекта от fit-gap анализа до перевода реализованного решения в опытную эксплуатацию. В задачи ведущего консультанта входит ключевое участие в разработке концептуальной проектной документации (методологии, архитектуры, проектных решений, описания интеграций и т.д.), конфигурирование технического решения в соответствии с требованиями клиента, проектирование доработок и взаимодействие с разработчиками для их реализации, обучение пользователей, комплексное тестирование внедрённого решения, взаимодействие в младшими сотрудниками проектной команды, лидирующее участие в организационных и административных аспектах проектной работы. Потребуется также твой вклад в развитие нашего подразделения: изучение новых решений и продуктов, подготовка демо-примеров и их демонстрация, участие в подготовке маркетинговых материалов, презентаций клиентам, коммерческих предложений и т.п.

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

О подразделении:

Эффективное управление рисками в сфере информационных технологий подразумевает учет киберрисков еще на начальном этапе разработки бизнес-стратегии. Мы помогаем компаниям защищать ценные информационные активы и совершенствовать бизнес-процессы, отслеживать киберугрозы и оперативно реагировать на них, в том числе за счёт внедрения специальных автоматизированных решений в сфере управления доступом, управления рисками, внутренним контролем и информационной безопасностью, одними из которых являются SAP GRC, SAP ETD, SAP Audit Management. Уникальный опыт наших специалистов позволяет эффективно предотвращать кибератаки, а также выстраивать внутренние процессы и процесс управления киберрисками, которые открывают новые возможности для бизнеса.

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

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

Контроль доступа SAP GRC помогает организациям автоматически обнаруживать, управлять и предотвращать нарушения рисков доступа и сокращать несанкционированный доступ к данным и информации компании. Пользователи могут использовать автоматическое самообслуживание для доступа к отправке запросов, запросам на управление рабочим процессом и подтверждениям доступа. С помощью SAP GRC Access Control можно использовать автоматические проверки доступа пользователей, авторизации ролей и нарушений рисков.

SAP GRC Access Control решает ключевые проблемы, позволяя бизнесу управлять рисками доступа. Это помогает организациям предотвращать несанкционированный доступ путем определения разделения обязанностей SoD и критического доступа и минимизации времени и затрат на управление рисками доступа.

Как изучить центр управления настройкой доступа?

Запустите транзакцию для NWBC в SAP Easy Access.

Шаг 1. Чтобы получить доступ к рабочим центрам, откройте NetWeaver Business Client, как указано выше. Перейдите к параметру / nwbc вверху, чтобы открыть рабочие центры.

Шаг 2. После нажатия вы будете перенаправлены на домашний экран клиента SAP NetWeaver Business.

Обслуживание правил доступа
Правила исключительного доступа
Критические правила доступа
Сгенерированные правила
организации
Смягчающие средства управления
Назначение суперпользователя
Суперпользовательское обслуживание
Владельцы доступа

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

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

Используя раздел критических правил доступа, вы можете определить дополнительные правила, определяющие доступ к критическим ролям и профилям.

Используя раздел сгенерированных правил, вы можете найти и просмотреть сгенерированные правила доступа.

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

Раздел «Митигационные элементы управления» позволяет управлять элементами управления для смягчения разделения обязанностей, критических действий и нарушений доступа к критическим разрешениям.

В разделе «Владельцы доступа» вы управляете привилегиями владельца для возможностей управления доступом.

О технологии GRC в общем и её применении для управления информационной безопасностью в частности. Часть 1

Концепция “Governance, Risk and Compliance, GRC ” не определена строго, например, Gartner характерезует её как “очень гибкую”. В общем, термин “Governance” относится к управлению деятельностями компании — ИТ, кадровой, финансовой, операционной, юридической и другими, на уровне системы это реализовано как управление политиками; термин “Risk” к управлению рисками и термин “Compliance” к управлению соответствием требованиям стандартов, лучших практик и регуляторов. Хотя, три эти области тесно связаны, но их не спешили объединять, пока в 2002 году не вышел закон Sarbanes-Oxley, в настоящее время требования к бизнесу только возросли, поэтому не стоит понимать GRC как только лишь к средство обеспечения соответствия данному закону.

GRC – это универсальный инструмент, предназначенный для:
— управления политиками;
— управления рисками;
— управления соответствием стандартам, лучшим практикам и требованиям регуляторов;
— управления внутренним аудитом;
— управления непрерывностью бизнеса;
— управления инцидентами;
— управления конфигурациями.
Это основные функции, полный список содержит больше позиций, вернемся к ним позже. Идея GRC заключается не в том, чтобы компания могла реализовать, с её помощью, каждый из перечисленных выше процессов в отдельности, а прежде всего в том, чтобы реализовать их в совокупности, избежав распараллеливания, а также естественным образом замкнув друг на друга, то есть реализовать максимально эффективно. Задача сложная, амбициозная и не очевидно, что выгодная для каждой компании, учитывая стоимость GRC систем. Но, принимая во внимание количество регулируемых активностей, рисков, требований регуляторов (особенно, если компания международная), объем проводимого аудита, а с другой стороны, постоянный бешеный рост бизнеса, диктуемый жесткими условиями выживаемости для современной крупной компании, возможно, применение GRC системы позволит одновременно и выжить в этих условиях и наладить стабильное развитие.
Пока термин GRC не устоялся, та же самая идея могла называться “ERM (Enterprise Risk Management)” или “Corporate Governance”.

Forrester дает следующее определение для GRC: “The coordinated functions that set and enforce the boundaries within which an organization seeks to maximize performance” (TechRadar™ For Risk Management Professionals: GRC, Q4 2012), то есть технология, позволяющая “определить границы” и “максимисимизировать производительность в заданных границах”. В самом деле, можно ли определить границы регулируемой деятельности, не будучи уверенным в том, что учтены с одной стороны все риски, с другой, требования законодателей? Каждая из “G”, “R” и “C” в отдельности не решает задачи, объединние их предоставляет эту возможность.
В этом же отчете, Forrester приводит 16 категорий технологий, относящихся к сфере GRC, это:
Audit management,
Board management,
Business continuity management,
Control monitoring and enforcement,
Corporate social responsibility,
Enterprise and operational risk management,
Environmental management,
Ethics and compliance training,
Financial risk management,
GRC platforms,
Legal and case management,
Policy and compliance management,
Quality management,
Regulatory intelligence and content feed,
Third-party risk management,
Whistleblower and hotline.
В соответствии с видением аналитиков Forrester, GRC включает перечисленные категории. Но что делать, если у компании нет необходимости внедрять их все? И, насколько хорошо GRC система реализует этот функционал, нет ли смысла выбрать узкоспециализированное решение? Ответы зависят от конкретной ситуации и технических решений, и могут быть получены только через экспертную оценку. Но сразу можно сказать, что во первых, GRC система, это не одно решение, а набор, как правило производитель предлагает модули, во вторых, основная ценность GRC систем в том, что они обеспечивают эффективное взаимодействие всех технологий.

GRC системы разделяют на EGRC (Enterprise GRC) и ITGRC (Information Technology GRC). ITGRC ориентированна на ИТ-центричные процессы, другими словами, с ITGRC в основном работают сотрудники ИТ и ИБ департаментов, в то время как с EGRC могут работать также и сотрудники финансового, юридического и департаментов, отвечающих за операционную деятельность и управляющие кадрами. Так как системы EGRC обладают всем тем же функционалом, что и ситемы ITGRC, есть мнение, что ITGRC умирает — см. блог Френча Колдвела (French Caldwell) в сети Gartner. Скорее всего, это преувеличение, так как та же компания Gartner продолжает оценку ITGRC решений, а рост данного сегмента рынка характерезует как ”позитивный”, перечисленные же вендоры (Agiliance, RSAM, Lockpath) имеют высокие рейтинги («MarketScope for IT Governance, Risk and Compliance Management» 7 June 2013). В этом же отчете Gartner утверждается, что ITGRC решения имеют достаточный функционал для поддержки “non-IT decision making, and non-IT executive reporting”, то есть ITGRC – это система безусловно ориентированная на ИТ составляющую, но при этом “повернута лицом к бизнесу”, в том плане, что не ИТ сотрудники имеют возможность пользоваться всеми преимуществами системы для оценки и влияния на ИТ составляющую бизнеса. Есть основание полагать, что ITGRC системы хороши для компаний, бизнес которых основан на ИТ-технологиях, ИТ-ориентированных.
Gartner позиционирует ITGRC как технологию, уже пережившую пик первой популярности, но еще не вошедшую в стадию “стабильной продуктивности”, в отличие от EGRC, которая оценивается как вполне уже состоявшаяся:

Такая оценка основана на том, что еще не сложилось четкого понимания о круге задач, которые целесообразно решать с помощью ITGRC систем, а с другой стороны, уже имеется негативный опыт внедрений. Слишком много существующих ИТ технологий имеют отношение к концепции GRC, некоторые из них являются естественной составляющей, другие — лишним балластом, перегружающим и так слишком сложную и комплексную технологию. По этому поводу Gartner выпустила отдельный отчет — «Technology Overview for IT GRC: Clarifying IT GRC to Match Technology to Need» 24 April 2013. Где, основываясь на наработанном опыте, определила некую горизонтальную черту, отделяющую ”функции контроля и управления, являющиеся источником ИТ информации, необходимой бизнесу для отчетности и принятия решений” от “операционной деятельности в сфере информационной безопасности”:

Все, что ниже черты, Gartner не рекомендует относить к ITGRC. На практике это означает, что попытки производителей встроить такие технологии как Security Information and Event Management (SIEM), Vulnerability Management и другие в ITGRC, скорее всего потерпят неудачу.
Разберем это на примере. Наличие в компании процесса Vulnerability Management (далее — VM) и программы ITGRC важно и необходимо. Аналитики сканируют ИТ ресурсы, результаты имеют прямое отношение к управлению рисками и могут служить причиной изменений в политиках. Логично будет объединить VM и ITGRC в рамках одной системы. Все так, но бизнесу для принятия решений не нужны результаты сканирования, бизнесу понятны формы типа “эта проблема с такой вероятностью остановит этот бизнес-процесс, за что придется заплатить столько”. Значит нужно “подавать” результаты сканирования в виде новых рисков в ITGRC системе. Правильно, только объединение VM и ITGRC в рамках одной системы подразумевает создание некоего интерфейса между ними, другими словами, это объединение может быть оправдано автоматическим заведением результатов сканирования, проведенного подсистемой VM, в реестре рисков подсистемы Risk Management (далее — RM) системы ITGRC. Если этой автоматизации нет, а между VM и RM промежуточное звено – аналитики, есть ли смысл в объединении? Чрезмерное усложнение почти всегда плохо. А автоматизация здесь крайне сложно осуществима, так как одна и та же уязвимость на одном и том же сервере в разное время может быть либо очень критичной, либо совсем не влияющей на бизнес-процессы, либо вообще ложной, а в крупной компании уязвимостей находится сотни и тысячи. Можно возразить, что VM и RM есть смысл объединять, такая необходимость очевидна, если вспомнить о стандарте PCI DSS, и автоматизация в определенных рамках возможна и полезна. Да это так, более того, такие примеры имеют место в жизни, но все же, не встраивать VM в ITGRC, а интегрировать разные системы. Встраивание же систем, обеспечивающих операционную деятельность по ИБ рискует превратить ITGRC в определенный момент вот в такой инструмент:

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

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

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

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

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

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

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

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

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

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

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

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

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

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. на примере реальных бизнес-сценариев.

Налоговый мониторинг через доступ в систему SAP (раскрытие)

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

Я бы дал дополнительное определение налогового мониторинга – это цифровизация камеральных проверок, перевод их из разовых мероприятий в форму постоянного мониторинга деятельности предприятия. Для налогоплательщика появляется возможность управлять налоговыми рисками через мотивированное мнение налогового органа, т.е. получать предупреждения от ФНС с возможностью принять меры для устранения налогового риска.

Существует 3 формы взаимодействия с ФНС в рамках налогового мониторинга:

Информация из открытых источников:

Как видно из слайда, набирает популярность форма взаимодействия с ФНС на основе витрины. Существует достаточно много поставщиков «коробок» для витрины, в том числе и SAP.

В данной статье способ взаимодействия через ТКС рассматривать не будем, т.к. этот способ скорее возможность вступить в налоговый мониторинг организациям, которым по каким-то причинам нужен этот режим, но экспертизы \ времени \ ресурсов не хватает для витрины или прямого доступа. Но, с другой стороны, после того как ГНИВЦ выполнит планы по созданию «облачной системы налогового мониторинга», то способ ТКС, возможно, ждет реинкарнация как интерфейса между облаком ГНИВЦ и учетными системами налогоплательщика.

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

Нужно понимать, что витрина данных никакого отношения к СВК не имеют. СВК можно реализовать в ручном режиме и тут тон задают методологи и написанные ими регламенты. Если говорить про автоматизацию, то другого решения кроме SAP GRC Risk Management and Process Control мне не известны и вряд ли есть. Почему вряд ли – контроли должны быть встроены в бизнес процессы, реализованные в SAP и такая интеграция кажется возможной только силами вендора и его продуктов.

Если смотреть на витрину с точки зрения интерфейса, то создать аналог для прямого доступа в виде АРМ «Налоговый мониторинг» на ABAP не представляется сложным (скриншот примера АРМ ниже).

Рассмотрим решения по блокам \ блокам работ:

Таким образом, для функционального заказчика и ИТ заказчика есть над чем подумать, если расчет налогов осуществляется в SAP, особенно с учетом того, что прямой доступ организует единое пространство работы для налоговых бухгалтеров и ФНС, а витрина заставляет налоговых бухгалтеров работать как в учетной системе, так и в отдельной витрине со всеми вытекающими последствиями в виде дополнительных сверок.

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.

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

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

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

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

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

Об авторе:

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

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

Ключевая особенность

Провести аудит и соответствие требованиям законодательства с различными стандартами аудита, такими как SOX, BSI и ISO.

Автоматическое обнаружение нарушений рисков доступа в системах SAP и не-SAP в организации.

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

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

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

Автоматическое обнаружение нарушений рисков доступа в системах SAP и не-SAP в организации.

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) - является системным атрибутом объекта, участвующего в запросе на доступ (Одиночная роль, Производная роль, Групповая роль, Бизнес-роль, Система).

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

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

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

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

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

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

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

Читайте также: