Матрица sod что это

Segregation of Duties на примере SAP

Когда заходит речь о SoD (segregation of duties или разделении прав доступа) пользователей, то часто кажется что существует словно два мира – мир красивых презентаций о том, почему доверие в бизнесе это важно и мир реальности, где нужно конвертировать красивые слова о стратегии в реалистичную и, желательно, позитивную практику.

Предыстория

Segregation of duties (SoD) или разделение обязанностей, ролей это превентивный контроль для внутренних сотрудников, суть которого в том, чтобы не допустить концентрацию важных прав доступа в одних руках. Операции с высоким риском, должны быть разделены на несколько этапов, каждый из которых выполняется разными людьми, что позволяет предотвратить мошенничество, а заодно обезопасить сам процесс от ошибок.

В значительной мере SoD как обязательный контроль в организации развился после принятия в США знаменитого Sarbannes Oxley act (SoX) в 2002 году. Закон был направлен на противодействие мошенничеству в финансовой сфере, и ужесточению контроля за финансовой отчетностью, при этом сам акт риски SoD изначально не прописывал, а скорее определял основные направления по которым компания должна была принять меры. Риски были доработаны позже.

Пример финансового риска:

Риски, функциональность и набор правил

Набор правил (ruleset) или набор рисков SoD каждая организация определяет для себя сама. Внутренний аудитор или топ менеджмент вправе сказать – для нас рисков всего пять и они все сосредоточены вокруг открытия, закрытия отчетного периода. Или наоборот, рисков 525 и каждый из них считается уникальным.

В действительности, чаще всего ruleset приходит вместе с командой аудиторов (что логично, если вас будут проверять на наличие рисков SoD, надо по крайней мере знать к чему готовиться) или вместе с софтом, который будет проверять систему (например для SAP – SAP GRC), и далее дорабатывается компанией в зависимости от внутренней оценки рисков и возможностей.

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

Вернемся к SAP

Риски SoD не привязаны к конкретной базе данных – 1С, Oracle, SAP – и сформулированы достаточно гибко, отражая самое главное – функционал, который может осуществить отдельно взятый сотрудник в случае обладания нужными правами. Но чтобы предотвратить риск, необходимо спуститься на более технический уровень и посмотреть как риск выглядит с точки зрения базы данных.

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

Также отмечу что чаще всего в SAP аудиторы проверяют только главную систему – ECC или S4HANA, без того чтобы смотреть на права в системах CRM, SRM и других.

Возьмем конкретный финансовый риск, описанный выше:

Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry

Риск состоит из двух частей, что в SAP означает доступ к определенным транзакциям

FB01 Post Document
FB02 Change Document
FB08 Reverse Document
F-02 Enter G/L Account Posting
F-21 Enter Transfer Posting
F-22 Enter Customer Invoice
.

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

F_BKPF_BUK ACTVT 01, 02, 06
F_BKPF_KOA ACTVT 01, 02, 06
F_BKPF_KOA KOART K

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

Еще один пример, риск BC (basic controls), за этот риск как правило отвечает главный администратор системы:

Создание пользователей и предоставление им прав доступа / Maintain users & Assign roles/profiles to users

Как это выглядит технически:

В идеальном мире за создание пользователей и за предоставление им ролей (по крайней мере в продакшн) должны отвечать два разных человека. В реальности это часто не так, но это не мешает стремиться к идеальному.

Избавляемся от SoD

Что происходит когда приходит аудитор и, проверив систему на наличие рисков, находит 3000 конфликтов SoD? Как правило решить их сразу нет никакой возможности. Но можно выбрать самые критические и сфокусироваться на том, чтобы избавиться от них.

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

С транзакциями тем не менее проще:

Стратегия избавления от SoD обычно идти от большого к меньшему. Сначала оценить насколько пользователю необходима сама роль (composite или single) и только потом идти в детали роли и корректировать ее. Но об этом можно поподробнее в другой раз, главное что нужно отметить что это не всегда очевидно, и часто есть предел в том, как сократить количество рисков (похожая аналогия с похудением) – невозможно полностью исключить все риски SoD из системы.

Но если вдруг в системе не останется ни одного SoD.

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

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

Если перевести это на технический язык SAP – появились новые query – для HR. Их нельзя в полной мере назвать SoD, потому что это не риск связанный с разделением функционала, но тем не менее компании проверяют свои системы на наличие вполне определенного доступа, а после проверки, стараются минимизировать риски.

Уверена что когда компании приведут свои системы в порядок в соответствии с нормами GDPR, придет что-то новое. Но до этого пока еще далеко, а аудит SoD пока еще достаточно актуальная тема.

Источник

Segregation of Duties на примере SAP

Когда заходит речь о SoD (segregation of duties или разделении прав доступа) пользователей, то часто кажется что существует словно два мира – мир красивых презентаций о том, почему доверие в бизнесе это важно и мир реальности, где нужно конвертировать красивые слова о стратегии в реалистичную и, желательно, позитивную практику.

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

Предыстория

Segregation of duties (SoD) или разделение обязанностей, ролей это превентивный контроль для внутренних сотрудников, суть которого в том, чтобы не допустить концентрацию важных прав доступа в одних руках. Операции с высоким риском, должны быть разделены на несколько этапов, каждый из которых выполняется разными людьми, что позволяет предотвратить мошенничество, а заодно обезопасить сам процесс от ошибок.

В значительной мере SoD как обязательный контроль в организации развился после принятия в США знаменитого Sarbannes Oxley act (SoX) в 2002 году. Закон был направлен на противодействие мошенничеству в финансовой сфере, и ужесточению контроля за финансовой отчетностью, при этом сам акт риски SoD изначально не прописывал, а скорее определял основные направления по которым компания должна была принять меры. Риски были доработаны позже.

Пример финансового риска:

Риски, функциональность и набор правил

Набор правил (ruleset) или набор рисков SoD каждая организация определяет для себя сама. Внутренний аудитор или топ менеджмент вправе сказать – для нас рисков всего пять и они все сосредоточены вокруг открытия, закрытия отчетного периода. Или наоборот, рисков 525 и каждый из них считается уникальным.

В действительности, чаще всего ruleset приходит вместе с командой аудиторов (что логично, если вас будут проверять на наличие рисков SoD, надо по крайней мере знать к чему готовиться) или вместе с софтом, который будет проверять систему (например для SAP – SAP GRC), и далее дорабатывается компанией в зависимости от внутренней оценки рисков и возможностей.

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

Вернемся к SAP

Риски SoD не привязаны к конкретной базе данных – 1С, Oracle, SAP – и сформулированы достаточно гибко, отражая самое главное – функционал, который может осуществить отдельно взятый сотрудник в случае обладания нужными правами. Но чтобы предотвратить риск, необходимо спуститься на более технический уровень и посмотреть как риск выглядит с точки зрения базы данных.

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

Также отмечу что чаще всего в SAP аудиторы проверяют только главную систему – ECC или S4HANA, без того чтобы смотреть на права в системах CRM, SRM и других.

Возьмем конкретный финансовый риск, описанный выше:

Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry

Риск состоит из двух частей, что в SAP означает доступ к определенным транзакциям

FB01 Post Document
FB02 Change Document
FB08 Reverse Document
F-02 Enter G/L Account Posting
F-21 Enter Transfer Posting
F-22 Enter Customer Invoice
.

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

F_BKPF_BUK ACTVT 01, 02, 06
F_BKPF_KOA ACTVT 01, 02, 06
F_BKPF_KOA KOART K

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

Еще один пример, риск BC (basic controls), за этот риск как правило отвечает главный администратор системы:

Создание пользователей и предоставление им прав доступа / Maintain users & Assign roles/profiles to users

Как это выглядит технически:

В идеальном мире за создание пользователей и за предоставление им ролей (по крайней мере в продакшн) должны отвечать два разных человека. В реальности это часто не так, но это не мешает стремиться к идеальному.

Избавляемся от SoD

Что происходит когда приходит аудитор и, проверив систему на наличие рисков, находит 3000 конфликтов SoD? Как правило решить их сразу нет никакой возможности. Но можно выбрать самые критические и сфокусироваться на том, чтобы избавиться от них.

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

С транзакциями тем не менее проще:

Стратегия избавления от SoD обычно идти от большого к меньшему. Сначала оценить насколько пользователю необходима сама роль (composite или single) и только потом идти в детали роли и корректировать ее. Но об этом можно поподробнее в другой раз, главное что нужно отметить что это не всегда очевидно, и часто есть предел в том, как сократить количество рисков (похожая аналогия с похудением) – невозможно полностью исключить все риски SoD из системы.

Но если вдруг в системе не останется ни одного SoD.

… вот тогда придет GDPR.

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

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

Если перевести это на технический язык SAP – появились новые query – для HR. Их нельзя в полной мере назвать SoD, потому что это не риск связанный с разделением функционала, но тем не менее компании проверяют свои системы на наличие вполне определенного доступа, а после проверки, стараются минимизировать риски.

Уверена что когда компании приведут свои системы в порядок в соответствии с нормами GDPR, придет что-то новое. Но до этого пока еще далеко, а аудит SoD пока еще достаточно актуальная тема.

Источник

Разграничение полномочий

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

«ВымпелКом» стал первой российской компанией, разместившей свои акции на нью-йоркской фондовой бирже. Это произошло 13 лет назад, еще до печально знаменитого скандала с корпорацией Enron, где на протяжении нескольких лет систематически фальсифицировалась публичная финансовая отчетность и вводились в заблуждение инвесторы и акционеры. Когда же разразился скандал, а вслед за ним был принят акт Сарбейнса—Оксли (SOX), призванный не допустить повторения подобных событий, «ВымпелКом», как и все компании, котирующиеся на нью-йоркской фондовой бирже, получил предписание привести свою деятельность в соответствие с требованиями этого закона. Поэтому мы уже четыре года — начиная с 2005 года — сертифицируемся по SOX.

Сертификация по SOX означает построение такой системы внутреннего контроля, которая бы свела к минимуму риски мошеннических махинаций в управлении активами, финансами, информационными материалами и средами, предотвратила искажение публичной финансовой отчетности с целью введения в заблуждение инвесторов и акционеров компании. В 2005 году мы представили выстроенную нами систему контрольных процедур на рассмотрение компании Ernst & Young, проводившей сертификацию, и получили положительный отзыв с минимумом замечаний. В резюме, составленном по итогам аудита, указывалось, что у нас разработаны в целом зрелые процедуры контроля по большинству самых уязвимых направлений и критичных бизнес-процессов. Однако к следующей сертификации нам следовало устранить выявленные недочеты, приведя в соответствие с требованиями SOX те процедуры и механизмы, эффективность которых была признана недостаточной.

Задача

В замечаниях, полученных нами от Ernst&Young, речь шла, в частности, об обязательности внедрения в компании принципов разграничения доступа и минимизации полномочий для ключевых бизнес-процессов (Segregation Of Duties, SOD) — одного из ключевых контрольных механизмов SOX. Как следствие, в 2006 году стартовал проект по внедрению принципов SOD. Сами работы по управлению рисками избыточности полномочий велись начиная с 2007 года.

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

Теперь о масштабе предстоявших работ. На момент начала проекта в штате компании числилось около 15 тыс. человек (сейчас, после слияния с компаниями «Корбина телеком» и «Голден Телеком», у нас более 35 тыс. сотрудников). Почти половина этих людей — приблизительно 7 тыс. — обладала теми или иными полномочиями, подлежавшими разграничению, а различных полномочий насчитывалось примерно пять сотен. Объем задачи, очевидно, превосходил возможности ручной обработки, так что процесс управления рисками избыточности требовалось автоматизировать. С этой целью мы закупили специализированное программное обеспечение компании LogicalApps, позволяющее осуществлять аналитику, — в то время отдельный модуль Oracle EBS, называвшийся AppsAccess. К приобретенной нами программе прилагалась матрица разграничения полномочий, так называемые лучшие мировые практики (Best Practices), основанные на рекомендациях «большой четверки» аудиторов — PricewaterhouseCoopers, Deloitte, Ernst & Young и KPMG. Эту матрицу мы наложили на наши бизнес-процессы, актуализировав в соответствии с их реальными особенностями, а затем загрузили в ERP‑систему.

Имевшееся распределение обязанностей и полномочий разительно отличалось от предлагаемого, что вполне естественно — ведь оно формировалось по мере развития компании, чаще всего без учета требований безопасности. При необходимости как‑либо модифицировать свой процесс сотрудники бизнес-подразделений «ВымпелКома» используют стандартную процедуру запроса на изменение (Request For Change, RFC). Если запрос достаточно обоснован и технически может быть удовлетворен, изменение вносится в ERP‑систему; все это не очень сложно, так что многие менеджеры и эксперты, считавшие, что им нужны дополнительные функциональности в полномочиях, заказывали себе таковые и получали их. В результате в большинстве ключевых бизнес-процессов образовались пересечения функциональностей полномочий, многократно увеличивающие риски бесконтрольных искажений и мошеннических операций со стороны сотрудников компании. По самой первой оценке, общее количество пересечений составило почти 2 миллиона (правда, реально опасных и подлежащих устранению было все‑таки значительно меньше).

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

Сотрудничество с бизнесом

Требовалось исправить положение, приведя распределение бизнес-функций сотрудников в соответствие с матрицей. Но реорганизацию бизнес-процесса может провести только его владелец — это сугубо его зона ответственности и компетенции. Сотрудники службы безопасности не имели полномочий на то, чтобы отправиться к менеджерам высокого ранга и заявить им: вам и вашим подчиненным назначены избыточные функции; на самом деле вы не должны иметь права делать это, это и это, а то‑то и то‑то вам необходимо делать только по согласованию с таким‑то. Проект, очевидно, нуждался в поддержке на уровне высшего руководства — и получил ее.

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

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

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

Сейчас реорганизация ключевых бизнес-процессов в соответствии с принципами разграничения полномочий в «ВымпелКоме» в целом завершена. Остается только ежегодно актуализировать матрицы SOD, поскольку наши бизнес-процессы живые и могут меняться, а также поддерживать операционную деятельность по отслеживанию избыточности, возникающей в результате передачи сотрудникам новых полномочий или изменения их существующих полномочий. Наши наработки по созданию бесконфликтного пула полномочий, подходы к принятию рисков и схемы компенсирующего контроля активно используются в других странах присутствия «ВымпелКома», в частности, в Казахстане и Армении, при миграции бизнес-процессов в ERP‑систему. Единственное, чего, может быть, недостает в построенной нами системе разграничения доступа, — это превентивный контроль избыточности. Из-за технических ограничений он происходит только постфактум, а не на этапе предоставления прав доступа. Некоторым утешением здесь может служить то, что время, в течение которого мы обнаруживаем вновь возникший конфликт избыточности, достаточно мало, поэтому фигурант обычно не успевает разобраться в том, какие злоупотребления он мог бы совершить, воспользовавшись лишними полномочиями. Безусловно, утешение слабое. Процесс напоминает бесконечную борьбу снаряда с броней и явно требует корректировки. Логичным продолжением проекта нам представляется переход к полномасштабной системе GRC (Governance, Risk and Compliance). Такая система позволила бы нам построить более эффективные механизмы легализации доступа сотрудников к функциональности ключевых бизнес-процессов. Насколько это осуществимо в новых экономических реалиях, покажет ближайшее будущее.

Источник