Когда заходит речь о SoD (segregation of duties или разделении прав доступа) пользователей, то часто кажется что существует словно два мира – мир красивых презентаций о том, почему доверие в бизнесе это важно и мир реальности, где нужно конвертировать красивые слова о стратегии в реалистичную и, желательно, позитивную практику.
Под катом краткое объяснение что такое риск SoD, как это выглядит с точки зрения базы данных SAP, и как с этим работать.
Segregation of duties (SoD) или разделение обязанностей, ролей это превентивный контроль для внутренних сотрудников, суть которого в том, чтобы не допустить концентрацию важных прав доступа в одних руках. Операции с высоким риском, должны быть разделены на несколько этапов, каждый из которых выполняется разными людьми, что позволяет предотвратить мошенничество, а заодно обезопасить сам процесс от ошибок.
В значительной мере SoD как обязательный контроль в организации развился после принятия в США знаменитого Sarbannes Oxley act (SoX) в 2002 году. Закон был направлен на противодействие мошенничеству в финансовой сфере, и ужесточению контроля за финансовой отчетностью, при этом сам акт риски SoD изначально не прописывал, а скорее определял основные направления по которым компания должна была принять меры. Риски были доработаны позже.
Пример финансового риска:
По мере развития аудита, понятие рисков SoD прочно вошло в практику. Если поначалу большинство рисков SoD были определены как финансовые, то впоследствии в матрицах SoD к ним были добавлены риски MM (материальных потоков) и BC (системного администрирования), а также другие.
Набор правил (ruleset) или набор рисков SoD каждая организация определяет для себя сама. Внутренний аудитор или топ менеджмент вправе сказать – для нас рисков всего пять и они все сосредоточены вокруг открытия, закрытия отчетного периода. Или наоборот, рисков 525 и каждый из них считается уникальным.
В действительности, чаще всего ruleset приходит вместе с командой аудиторов (что логично, если вас будут проверять на наличие рисков SoD, надо по крайней мере знать к чему готовиться) или вместе с софтом, который будет проверять систему (например для SAP – SAP GRC), и далее дорабатывается компанией в зависимости от внутренней оценки рисков и возможностей.
Итак, словарь:
Выглядит все это примерно так:
Матрица SoD это таблица сопересечения различных query. Многие организации любят изображать риски SoD в виде матрицы, хотя по сути это тот же самый ruleset, изображенный в двоичной системе координат. Просто так нагляднее.
Риски SoD не привязаны к конкретной базе данных – 1С, Oracle, SAP – и сформулированы достаточно гибко, отражая самое главное – функционал, который может осуществить отдельно взятый сотрудник в случае обладания нужными правами. Но чтобы предотвратить риск, необходимо спуститься на более технический уровень и посмотреть как риск выглядит с точки зрения базы данных.
Мне это удобнее рассматривать с точки зрения SAP, если в других базах данных это устроено по-другому, будет интересно если вы поделитесь опытом.
Также отмечу что чаще всего в SAP аудиторы проверяют только главную систему – ECC или S4HANA, без того чтобы смотреть на права в системах CRM, SRM и других.
Возьмем конкретный финансовый риск, описанный выше:
Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry
Риск состоит из двух частей, что в SAP означает доступ к определенным транзакциям
Но одними транзакциями дело не ограничивается. Чтобы возможно было выполнить тот или иной функционал, в query включаются также и технические объекты, необходимые для выполнения операции. Как правило те, на которых стоят обязательные проверки в программном коде.
Например:
Таким образом чтобы иметь возможность использовать риск SoD, пользователь должен обладать и транзакциями и техническими объектами с нужными значениями.
Еще один пример, риск BC (basic controls), за этот риск как правило отвечает главный администратор системы:
Создание пользователей и предоставление им прав доступа / Maintain users & Assign roles/profiles to users
Как это выглядит технически:
В идеальном мире за создание пользователей и за предоставление им ролей (по крайней мере в продакшн) должны отвечать два разных человека. В реальности это часто не так, но это не мешает стремиться к идеальному.
Что происходит когда приходит аудитор и, проверив систему на наличие рисков, находит 3000 конфликтов SoD? Как правило решить их сразу нет никакой возможности. Но можно выбрать самые критические и сфокусироваться на том, чтобы избавиться от них.
По сути чтобы избавиться от конфликта SoD надо забрать у пользователя доступ к транкзакции или доступ к техническому объекту. Первое кажется самым простым. Очень часто даже организации хитрят и заменяют простые транзакции на Z-транзакции и т.к. ruleset аудиторов просто по определению не может включать в себя кастомизированные транзакции, то на выходе отчет будет чист, будто в системе и нет конфликтов. Но в долгосрочной перспективе такая практика обернется ловушкой для самой организации, ибо будет не решать, а лишь мастировать проблемы.
С транзакциями тем не менее проще:
С тех.объектами сложнее:
Другое коварство баз данных это Accumulation of rights или совмещение доступов – когда буффер авторизаций пользователя (SU56 — User Authorization Buffer) включает в себя все возможные объекты из всех возможных ролей пользователя, независимо от того, под какие процессы были определены роли. Другими словами мы можем создать две разные роли в одну для SU01, другую для PFCG, но если мы дадим обе роли одному пользователю, система будет думать что это одна роль, соответвенно она посчитает это за конфликт SoD.
Стратегия избавления от SoD обычно идти от большого к меньшему. Сначала оценить насколько пользователю необходима сама роль (composite или single) и только потом идти в детали роли и корректировать ее. Но об этом можно поподробнее в другой раз, главное что нужно отметить что это не всегда очевидно, и часто есть предел в том, как сократить количество рисков (похожая аналогия с похудением) – невозможно полностью исключить все риски SoD из системы.
… вот тогда придет GDPR.
Казалось бы, практики определения рисков SoD существуют без малого 20 лет. Крупные компании достаточно активно мониторят свои системы и уже выстроили отлаженные процессы по нахождению, предотвращению и избавлению от рисков SoD. B этот момент появляется нечто новое – закон о защите персональных данных.
Этот закон предписывает что доступ к персональным данным должен быть строго у людей, которым это необходимо по рабочим обязательствам. Соответственно тем, кому это не необходимо, надо исключить возможность такого доступа.
Если перевести это на технический язык SAP – появились новые query – для HR. Их нельзя в полной мере назвать SoD, потому что это не риск связанный с разделением функционала, но тем не менее компании проверяют свои системы на наличие вполне определенного доступа, а после проверки, стараются минимизировать риски.
Пример query HR:
Уверена что когда компании приведут свои системы в порядок в соответствии с нормами GDPR, придет что-то новое. Но до этого пока еще далеко, а аудит SoD пока еще достаточно актуальная тема.
Под катом краткое объяснение что такое риск SoD, как это выглядит с точки зрения базы данных SAP, и как с этим работать.
Предыстория
Segregation of duties (SoD) или разделение обязанностей, ролей это превентивный контроль для внутренних сотрудников, суть которого в том, чтобы не допустить концентрацию важных прав доступа в одних руках. Операции с высоким риском, должны быть разделены на несколько этапов, каждый из которых выполняется разными людьми, что позволяет предотвратить мошенничество, а заодно обезопасить сам процесс от ошибок.
В значительной мере SoD как обязательный контроль в организации развился после принятия в США знаменитого Sarbannes Oxley act (SoX) в 2002 году. Закон был направлен на противодействие мошенничеству в финансовой сфере, и ужесточению контроля за финансовой отчетностью, при этом сам акт риски SoD изначально не прописывал, а скорее определял основные направления по которым компания должна была принять меры. Риски были доработаны позже.
Пример финансового риска:
- Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry >> может привести к тому, что сотрудник может потенциально публиковать записи за предыдущие периоды для достижения ожидаемых внутренних финансовых целей, например открыть закрытый отчетный период и провести проводку «задним» числом, из-за чего финансовая отчетность может быть сфальцифицирована.
По мере развития аудита, понятие рисков SoD прочно вошло в практику. Если поначалу большинство рисков SoD были определены как финансовые, то впоследствии в матрицах SoD к ним были добавлены риски MM (материальных потоков) и BC (системного администрирования), а также другие.
Риски, функциональность и набор правил
Набор правил (ruleset) или набор рисков SoD каждая организация определяет для себя сама. Внутренний аудитор или топ менеджмент вправе сказать – для нас рисков всего пять и они все сосредоточены вокруг открытия, закрытия отчетного периода. Или наоборот, рисков 525 и каждый из них считается уникальным.
В действительности, чаще всего ruleset приходит вместе с командой аудиторов (что логично, если вас будут проверять на наличие рисков SoD, надо по крайней мере знать к чему готовиться) или вместе с софтом, который будет проверять систему (например для SAP – SAP GRC), и далее дорабатывается компанией в зависимости от внутренней оценки рисков и возможностей.
Итак, словарь:
- Ruleset – общий список-набор рисков SoD, их классификация и определение отдельных функциональных разрешений (query);
- SoD – определенный риск, возникающий при комбинации двух функциональных разрешений. SoD может состоять как из двух разрешений, так и из трех, и даже из одного (uni-SoD) но очень важного, например кастомизация системы в продакшн (in SAP — SPRO);
- Query – функциональное разрешение, кирпичик для матрицы SoD. Конкретный функционал, например – проводка в системе, или открытие отчетного периода;
Выглядит все это примерно так:
| № | SoD name | Process | Query A | Query B | Risk description |
| 1 | FI_01_High | FI | Изменение мастер данных клиентов | Оплата счетов | Обслуживание основных данных следует отделить от обработки транзакций. Существует риск того, что пользователь может создать несуществующие счета и переводить на них деньги. |
| 2 | FI_02_Medium | FI | Освободить заблокированные счета-фактуры | Утверждение заказа на поставку | Пользователь может подтвердить заказ на поставку и разблокировать ранее заблокированный счет-фактуру, что приведет к несанкционированной обработке счетов-фактур. |
Матрица SoD это таблица сопересечения различных query. Многие организации любят изображать риски SoD в виде матрицы, хотя по сути это тот же самый ruleset, изображенный в двоичной системе координат. Просто так нагляднее.
Вернемся к SAP
Риски SoD не привязаны к конкретной базе данных – 1С, Oracle, SAP – и сформулированы достаточно гибко, отражая самое главное – функционал, который может осуществить отдельно взятый сотрудник в случае обладания нужными правами. Но чтобы предотвратить риск, необходимо спуститься на более технический уровень и посмотреть как риск выглядит с точки зрения базы данных.
Мне это удобнее рассматривать с точки зрения SAP, если в других базах данных это устроено по-другому, будет интересно если вы поделитесь опытом.
Также отмечу что чаще всего в SAP аудиторы проверяют только главную систему – ECC или S4HANA, без того чтобы смотреть на права в системах CRM, SRM и других.
Возьмем конкретный финансовый риск, описанный выше:
Открытие/закрытие бухгалтерских периодов проводки и записи в журнале проводок / Maintain Posting Periods & Post Journal Entry
Риск состоит из двух частей, что в SAP означает доступ к определенным транзакциям
- Maintain Posting Periods
OB52 C FI Maintain Table T001B
F-60 Maintain Table: Posting Periods
GCP1 FI-SL: Local Posting Periods
GCP2 FI-SL Customizing: T001C
... - Post Journal Entry
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 включаются также и технические объекты, необходимые для выполнения операции. Как правило те, на которых стоят обязательные проверки в программном коде.
Например:
- Maintain Posting Periods
S_TABU_DIS ACTVT 02
S_TABU_DIS DICBERCLS FC31…
- Post Journal Entry
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
Как это выглядит технически:
| Query | Transaction | Authorization object |
| Maintain users | SU01 | S_USER_GRP (01,02) |
| Assign roles/profiles to users | PFCG | S_USER_GRP (02)+S_USER_PRO (22) |
В идеальном мире за создание пользователей и за предоставление им ролей (по крайней мере в продакшн) должны отвечать два разных человека. В реальности это часто не так, но это не мешает стремиться к идеальному.
Избавляемся от SoD
Что происходит когда приходит аудитор и, проверив систему на наличие рисков, находит 3000 конфликтов SoD? Как правило решить их сразу нет никакой возможности. Но можно выбрать самые критические и сфокусироваться на том, чтобы избавиться от них.
По сути чтобы избавиться от конфликта SoD надо забрать у пользователя доступ к транкзакции или доступ к техническому объекту. Первое кажется самым простым. Очень часто даже организации хитрят и заменяют простые транзакции на Z-транзакции и т.к. ruleset аудиторов просто по определению не может включать в себя кастомизированные транзакции, то на выходе отчет будет чист, будто в системе и нет конфликтов. Но в долгосрочной перспективе такая практика обернется ловушкой для самой организации, ибо будет не решать, а лишь мастировать проблемы.
С транзакциями тем не менее проще:
- можно отследить по данным STAD какие сотрудники не использовали транзакции и забрать доступ в первую очередь у них
- многие транзакции дублируются с доступом только в визуализации и большая часть пользователей именно этот доступ и просит
С тех.объектами сложнее:
- нельзя отследить (вернее достаточно сложно) какой объект был использован пользователем, а какой нет
- часто объекты используются различными процессами. И забрав объект, и обезопасив один функционал, в итоге блокируешь другой. Например, как видно из примера с Maintain users & Assign roles/profiles to users, один объект S_USER_GRP – используется обеими query.
Другое коварство баз данных это Accumulation of rights или совмещение доступов – когда буффер авторизаций пользователя (SU56 — User Authorization Buffer) включает в себя все возможные объекты из всех возможных ролей пользователя, независимо от того, под какие процессы были определены роли. Другими словами мы можем создать две разные роли в одну для SU01, другую для PFCG, но если мы дадим обе роли одному пользователю, система будет думать что это одна роль, соответвенно она посчитает это за конфликт SoD.
Стратегия избавления от SoD обычно идти от большого к меньшему. Сначала оценить насколько пользователю необходима сама роль (composite или single) и только потом идти в детали роли и корректировать ее. Но об этом можно поподробнее в другой раз, главное что нужно отметить что это не всегда очевидно, и часто есть предел в том, как сократить количество рисков (похожая аналогия с похудением) – невозможно полностью исключить все риски SoD из системы.
Но если вдруг в системе не останется ни одного SoD...
… вот тогда придет GDPR.
Казалось бы, практики определения рисков SoD существуют без малого 20 лет. Крупные компании достаточно активно мониторят свои системы и уже выстроили отлаженные процессы по нахождению, предотвращению и избавлению от рисков SoD. B этот момент появляется нечто новое – закон о защите персональных данных.
Этот закон предписывает что доступ к персональным данным должен быть строго у людей, которым это необходимо по рабочим обязательствам. Соответственно тем, кому это не необходимо, надо исключить возможность такого доступа.
Если перевести это на технический язык SAP – появились новые query – для HR. Их нельзя в полной мере назвать SoD, потому что это не риск связанный с разделением функционала, но тем не менее компании проверяют свои системы на наличие вполне определенного доступа, а после проверки, стараются минимизировать риски.
Пример query HR:
| Query | Transaction | Authorization object |
| Maintain PA master data IT 0000 | PA30 | P_ORGIN AUTHC W, P_ORGIN INFTY 0000 |
Уверена что когда компании приведут свои системы в порядок в соответствии с нормами GDPR, придет что-то новое. Но до этого пока еще далеко, а аудит SoD пока еще достаточно актуальная тема.
