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

Источник

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

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

«ВымпелКом» стал первой российской компанией, разместившей свои акции на нью-йоркской фондовой бирже. Это произошло 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). Такая система позволила бы нам построить более эффективные механизмы легализации доступа сотрудников к функциональности ключевых бизнес-процессов. Насколько это осуществимо в новых экономических реалиях, покажет ближайшее будущее.

Источник

AccountingTools

Accounting CPE Courses & Books

AccountingTools

What is Segregation of Duties?

The segregation of duties is the assignment of various steps in a process to different people. The intent behind doing so is to eliminate instances in which someone could engage in theft or other fraudulent activities by having an excessive amount of control over a process. In essence, the physical custody of an asset, the record keeping for it, and the authorization to acquire or dispose of the asset should be split among different people.

The segregation of duties is an essential element of a control system. Auditors will look for duty segregation as part of their analysis of an entity’s system of internal controls, and will downgrade their judgment of the system if there are any segregation failures. When there are segregation failures, the auditors will assume that there is an expanded risk of fraud, and adjust their procedures accordingly. This change in procedures usually involves in increase in the amount of audit work, which is passed through to the client in the form of higher audit fees.

The segregation of duties is more difficult to accomplish in a smaller organization, where there are too few people to effectively shift tasks to different people. Another issue with segregation is that shifting tasks among too many people makes the process flow less efficient. When a higher level of efficiency is desired, the usual trade-off is weaker control because the segregation of duties has been reduced.

Examples of Segregation of Duties

As an example of the segregation of duties, the person who receives goods from suppliers in the warehouse cannot sign checks to pay the suppliers for those goods. As another example, the person who maintains inventory records does not have physical possession of the inventory. And as a third example, the person who sells a fixed asset to a third party cannot record the sale or take custody of the payment from the third party.

Terms Similar to Segregation of Duties

The segregation of duties is also known as the separation of duties.

Источник

Segregation of duties in your ISMS according to ISO 27001 A.6.1.2

Today’s automated solutions and information and communication technologies allow a few people to handle a great deal of information and processes (e.g., stock exchange operators and air traffic controllers).

While this is good to improve productivity, a potential side effect is that these few people may end up gathering excessive knowledge and/or privilege over the operating environment and, in case they are absent or have malicious intent, this can prove to be an unacceptable risk, which must be handled.

This article will present a widely used concept to approach this situation, the segregation of duties, and how ISO 27001 considers it in an ISMS to minimize the risk that a single position may have the opportunity to compromise an organization’s activities.

Segregation of duties general definition, purpose, and principles

Segregation of duties refers to practices where the knowledge and/or privileges needed to complete a process are broken up and divided among multiple users so that no single one is capable of performing or controlling it by himself.

The main reason to apply segregation of duties is to prevent the perpetration and concealment of fraud and error in the normal course of the activities, since having more than one person to perform a task minimizes the opportunity of wrongdoing and increases the chances to detect it, as well as to detect unintentional errors.

The principles that can be applicable to segregation of duties are:

You may note that these principles can be used in isolation or together, depending upon the security an organization requires to protect its processes.

ISO 27001 series objectives and guidance on segregation of duties

ISO 27001 considers segregation of duties to be one of the potential controls to be applicable to control implementation and operation of information security within the organization (control A.6.1.2 from Annex A).

The standard control requires conflicting duties and areas of responsibilities to be segregated in order to reduce the risk of an asset’s unauthorized or unintentional modification or misuse. The determination of whether the control is applicable and which duties and areas should be under A.6.1.2 must be made according the results of a risk assessment.

Since the segregation of duties concept is straightforward, ISO 27002, the standard that provides practices for information security controls, does not provide much additional orientation other than that previously presented, besides for two points:

Implementing segregation of duties

But, how is segregation of duties implemented? Basically, these steps should be followed as part of a risk treatment plan:

Alternatives to segregation of duties

Sometimes the segregation of duties is impractical because the organization is too small to designate functions to different persons. In other cases, breaking down tasks can reduce business efficiency and increase costs, complexity, and staffing requirements.

In these situations, compensating controls should be in place to ensure that even without segregation of duties the identified risks are properly handled. Examples of compensating controls are:

Sometimes, having all your eggs in one basket is not a good idea

Wrongdoing requires three factors to be possible: means, motive, and opportunity. Extremely lean processes increase the risk of wrongdoing by concentrating means and opportunity (access to and privileges over the process). By implementing segregation of duties, an organization minimizes the risk by splitting knowledge and privileges.

However, the benefits of segregation of duties to security must be balanced with the increased cost/effort required. By using the ISO 27001 requirements for risk assessment, an organization can identify the most vulnerable and the most mission-critical elements of the business to which segregation of duties will represent real added value to the business and other interested parties.

To learn how to become compliant with every clause and control from Annex A and get all the required policies and procedures for controls and clauses, sign up for a 30-day free trial of Conformio, the leading ISO 27001 compliance software.

Источник