segregation of duties что это

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

Смотреть что такое «segregation of duties» в других словарях:

segregation of duties — The separation of individual employees’ duties and responsibilities to enhance an organization’s *internal controls. A fundamental aspect of segregation of duties is the notion that persons having the custody of control of assets should not also… … Auditor’s dictionary

Segregation of Duties — Funktionstrennung bedeutet, das bestimmte Aufgaben eines Geschäftsprozesses nicht durch ein und dieselbe Person oder Organisationseinheit durchgeführt werden sollen. Der Begriff wird im Bereich der Funktionalen Organisation und der Informatik… … Deutsch Wikipedia

Separation of duties — (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.General descriptionSeparation of duties is one of the key concepts… … Wikipedia

division of duties — An alternative term for *segregation of duties … Auditor’s dictionary

Systems Applications Products audit — is when a computer system from SAP undegoes an audit to check its security and data integrity. SAP is the acronym for Systems, Applications, Products. It is a system that provides users with a soft real time business application. It contains a… … Wikipedia

Information security audit — An information security audit is an audit on the level of information security in an organization. Within the broad scope of auditing information security there are multiple type of audits, multiple objectives for different audits, etc. Most… … Wikipedia

Entity-Level Controls — Accountancy Key concepts Accountant · Accounting period · Bookkeeping · Cash and accrual basis · Cash flow management · Chart of accounts … Wikipedia

Information security — Components: or qualities, i.e., Confidentiality, Integrity and Availability (CIA). Information Systems are decomposed in three main portions, hardware, software and communications with the purpose to identify and apply information security… … Wikipedia

Change management auditing — Change management is an auditing procedure for mitigating risks associated with the changes made to an IT system. Limiting unauthorized changes and having proper segregation of duties controls in place is essential to reduce the risk of… … Wikipedia

Internal control — In accounting and organizational theory, Internal control is defined as a process effected by an organization s structure, work and authority flows, people and management information systems, designed to help the organization accomplish specific… … Wikipedia

Zugriffschutz — Zugriffskontrolle (engl. access control) bezeichnet die Überwachung des Zugriffs auf bestimmte Ressourcen. Im Konkreten entscheidet die Zugriffskontrolle, ob der Zugang zu einer bestimmten Ressource gewährt oder verwehrt wird. Das Ziel der… … Deutsch Wikipedia

Источник

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 пока еще достаточно актуальная тема.

Источник

segregation of duties

1 segregation of duties

2 segregation of duties

3 segregation of duties

4 segregation of duties

5 segregation of duties

6 разделение обязанностей

См. также в других словарях:

segregation of duties — The separation of individual employees’ duties and responsibilities to enhance an organization’s *internal controls. A fundamental aspect of segregation of duties is the notion that persons having the custody of control of assets should not also… … Auditor’s dictionary

Segregation of Duties — Funktionstrennung bedeutet, das bestimmte Aufgaben eines Geschäftsprozesses nicht durch ein und dieselbe Person oder Organisationseinheit durchgeführt werden sollen. Der Begriff wird im Bereich der Funktionalen Organisation und der Informatik… … Deutsch Wikipedia

Separation of duties — (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.General descriptionSeparation of duties is one of the key concepts… … Wikipedia

division of duties — An alternative term for *segregation of duties … Auditor’s dictionary

Systems Applications Products audit — is when a computer system from SAP undegoes an audit to check its security and data integrity. SAP is the acronym for Systems, Applications, Products. It is a system that provides users with a soft real time business application. It contains a… … Wikipedia

Information security audit — An information security audit is an audit on the level of information security in an organization. Within the broad scope of auditing information security there are multiple type of audits, multiple objectives for different audits, etc. Most… … Wikipedia

Entity-Level Controls — Accountancy Key concepts Accountant · Accounting period · Bookkeeping · Cash and accrual basis · Cash flow management · Chart of accounts … Wikipedia

Information security — Components: or qualities, i.e., Confidentiality, Integrity and Availability (CIA). Information Systems are decomposed in three main portions, hardware, software and communications with the purpose to identify and apply information security… … Wikipedia

Change management auditing — Change management is an auditing procedure for mitigating risks associated with the changes made to an IT system. Limiting unauthorized changes and having proper segregation of duties controls in place is essential to reduce the risk of… … Wikipedia

Internal control — In accounting and organizational theory, Internal control is defined as a process effected by an organization s structure, work and authority flows, people and management information systems, designed to help the organization accomplish specific… … Wikipedia

Zugriffschutz — Zugriffskontrolle (engl. access control) bezeichnet die Überwachung des Zugriffs auf bestimmte Ressourcen. Im Konkreten entscheidet die Zugriffskontrolle, ob der Zugang zu einer bestimmten Ressource gewährt oder verwehrt wird. Das Ziel der… … Deutsch Wikipedia

Источник

segregation of duties

Смотреть что такое «segregation of duties» в других словарях:

segregation of duties — The separation of individual employees’ duties and responsibilities to enhance an organization’s *internal controls. A fundamental aspect of segregation of duties is the notion that persons having the custody of control of assets should not also… … Auditor’s dictionary

Segregation of Duties — Funktionstrennung bedeutet, das bestimmte Aufgaben eines Geschäftsprozesses nicht durch ein und dieselbe Person oder Organisationseinheit durchgeführt werden sollen. Der Begriff wird im Bereich der Funktionalen Organisation und der Informatik… … Deutsch Wikipedia

Separation of duties — (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.General descriptionSeparation of duties is one of the key concepts… … Wikipedia

division of duties — An alternative term for *segregation of duties … Auditor’s dictionary

Systems Applications Products audit — is when a computer system from SAP undegoes an audit to check its security and data integrity. SAP is the acronym for Systems, Applications, Products. It is a system that provides users with a soft real time business application. It contains a… … Wikipedia

Information security audit — An information security audit is an audit on the level of information security in an organization. Within the broad scope of auditing information security there are multiple type of audits, multiple objectives for different audits, etc. Most… … Wikipedia

Entity-Level Controls — Accountancy Key concepts Accountant · Accounting period · Bookkeeping · Cash and accrual basis · Cash flow management · Chart of accounts … Wikipedia

Information security — Components: or qualities, i.e., Confidentiality, Integrity and Availability (CIA). Information Systems are decomposed in three main portions, hardware, software and communications with the purpose to identify and apply information security… … Wikipedia

Change management auditing — Change management is an auditing procedure for mitigating risks associated with the changes made to an IT system. Limiting unauthorized changes and having proper segregation of duties controls in place is essential to reduce the risk of… … Wikipedia

Internal control — In accounting and organizational theory, Internal control is defined as a process effected by an organization s structure, work and authority flows, people and management information systems, designed to help the organization accomplish specific… … Wikipedia

Zugriffschutz — Zugriffskontrolle (engl. access control) bezeichnet die Überwachung des Zugriffs auf bestimmte Ressourcen. Im Konkreten entscheidet die Zugriffskontrolle, ob der Zugang zu einer bestimmten Ressource gewährt oder verwehrt wird. Das Ziel der… … Deutsch Wikipedia

Источник