Identity & Access Management

Separation of Duties

職務分掌(SoD)

Category: Identity & Access Management / Updated: 2026-05-26

📖

Overview

職務分掌(Separation of Duties:SoD)とは、組織における重要な業務プロセスを複数の担当者に分割し、単独の個人が不正行為を完遂できないようにする内部統制の原則です。一つの取引やプロセスの「承認」「実行」「記録」「検証」を異なる人物が担当することで、不正や誤謬を防止・検出します。

SoDは古くから会計・財務分野で実践されてきた概念ですが、情報システムの高度化に伴い、ITアクセス制御の領域でも不可欠な原則となっています。例えば、ERPシステムにおいて「仕入先の登録」と「支払処理の実行」を同一人物が行えるとすると、架空の仕入先を登録して自分宛に支払いを実行する不正が可能になります。SoDはこのようなリスクを構造的に排除します。

特にSOX法(サーベンス・オクスリー法)の適用を受ける上場企業では、財務報告に関連する業務プロセスにおけるSoDの実装が法的に求められます。SOX法Section 404は、経営者に対して内部統制の有効性を評価・報告することを義務付けており、SoD違反の存在は重大な内部統制上の欠陥(Material Weakness)として報告される可能性があります。

🔬

Details

静的SoD(Static SoD)と動的SoD(Dynamic SoD)

静的SoD(Static Separation of Duties)は、相互に矛盾する権限を同一のユーザーに永続的に付与しないという制約です。例えば、「購買発注」ロールと「支払承認」ロールを同一人物に割り当てることを禁止します。権限の割り当て時点でSoDチェックが行われ、違反する権限の組み合わせは付与されません。

動的SoD(Dynamic Separation of Duties)は、同一のトランザクション内で矛盾する操作を同一人物が実行することを禁止する制約です。ユーザーが両方の権限を保有すること自体は許可されますが、同一の取引において両方の操作を実行することは禁止されます。例えば、あるユーザーが特定の発注書を作成した場合、同じ発注書の承認は別のユーザーが行わなければなりません。

SoDマトリクスの設計

SoDマトリクス(SoD Matrix / Conflict Matrix)は、相互に矛盾する権限の組み合わせを体系的に定義した対照表です。行と列にロールや権限を配置し、交差するセルに矛盾の有無とリスクレベル(高・中・低)を記載します。

SoDマトリクスの設計にあたっては、業務プロセスの深い理解が不可欠です。財務・会計、調達、人事、IT管理など、各業務領域のプロセスフローを分析し、不正や誤謬のリスクが存在するポイントを特定します。代表的なSoDコンフリクトとして、仕入先マスター管理と支払処理、ユーザー作成と権限付与、在庫受入と在庫調整、給与計算と給与支払承認などが挙げられます。

コンフリクト検出とリスク評価

SoDの実効性を維持するためには、既存のアクセス権限に対するコンフリクト検出を定期的に実施する必要があります。IGAソリューションやGRC(ガバナンス・リスク・コンプライアンス)ツールは、定義されたSoDルールに基づいてアクセス権限をスキャンし、違反を自動検出します。

検出されたSoD違反に対しては、リスク評価を行い、対応方針を決定します。権限の削除が可能な場合は速やかに是正しますが、業務上やむを得ない場合は緩和策(Mitigating Control)を適用します。緩和策の例としては、追加の承認フロー、取引のモニタリング、定期的な監査レポートの提出などがあります。

SOX法との関係

SOX法は、2002年のエンロン・ワールドコム事件を受けて制定された米国の法律であり、上場企業に対して財務報告に係る内部統制の整備・運用・評価を義務付けています。SoDはSOX法が要求する内部統制の中核要素の一つです。

SOX法Section 302では経営者による内部統制の評価が、Section 404では外部監査人による内部統制の監査が求められます。SoD違反は、財務報告の信頼性に影響を及ぼす重要な統制上の不備として報告対象となります。日本では金融商品取引法に基づくJ-SOX(内部統制報告制度)として類似の要件が適用されています。

ERPシステムにおけるSoDの実装

SAP、Oracle EBSなどのERPシステムは、業務プロセスの中核を担うため、SoD管理の最重要対象です。ERPシステムでは、トランザクションコード、認可オブジェクト、ロールの組み合わせが膨大であるため、手動でのSoD管理は現実的ではありません。

SAP GRC Access Control、Saviynt、Pathlock(旧Security Weaver)などの専門ツールは、ERP固有のSoDルールセットをプリビルトで提供し、リアルタイムのSoD違反検出、権限申請時のSoDシミュレーション、緩和策の管理、コンプライアンスレポートの自動生成などの機能を備えています。

🛡️

Security Measures

  • 01
    包括的なSoDマトリクスの策定と維持:財務、調達、人事、IT管理など、主要な業務領域ごとにSoDマトリクスを策定してください。マトリクスは業務プロセスの変更に合わせて定期的に見直し、新たなリスクに対応するルールを追加していくことが重要です。
  • 02
    権限申請時のリアルタイムSoDチェック:ユーザーにロールや権限を付与する際に、リアルタイムでSoD違反チェックを実行する仕組みを導入してください。違反が検出された場合は、自動的に申請をブロックするか、上位権限者による特別承認フローに回しましょう。
  • 03
    既存の権限に対する定期的なSoDスキャン:すべてのユーザーの現行アクセス権限に対して、少なくとも四半期ごとにSoD違反スキャンを実施してください。検出された違反には期限を設けて是正計画を策定し、是正が完了するまでの間は緩和策を適用しましょう。
  • 04
    緩和策の文書化と有効性の検証:業務上やむを得ないSoD違反に対して適用する緩和策は、リスク評価、承認者、有効期間、モニタリング方法を含めて文書化してください。緩和策の有効性を定期的に検証し、形骸化を防止することが重要です。
  • 05
    緊急アクセス(Firefighter Access)の厳格な管理:障害対応など緊急時に一時的にSoDルールを逸脱するアクセスが必要な場合は、事前に承認されたFirefighterアカウントを使用し、すべての操作を詳細にログ記録してください。事後レビューを必ず実施しましょう。
  • 06
    SoDポリシーの組織全体への教育と啓発:SoDの重要性と自社のSoDルールについて、全従業員に対する定期的な教育を実施してください。特に管理職やシステム管理者には、SoD違反のリスクと適切な権限管理の方法について深い理解を促すことが重要です。
⚠️

Incidents

📋 仏大手銀行ソシエテ・ジェネラルの巨額損失事件(2008年)

2008年、フランスのソシエテ・ジェネラル銀行において、トレーダーのジェローム・ケルビエルが不正取引により約49億ユーロ(約7,600億円)の損失を発生させる事件が起きました。ケルビエルは以前にバックオフィス(管理部門)に在籍しており、リスク管理システムの仕組みを熟知していました。

この事件の根本原因の一つとして、フロントオフィス(取引執行)とバックオフィス(取引管理・検証)の職務分掌が不十分であったことが指摘されています。ケルビエルは管理部門時代の知識を活用して取引の記録を操作し、リスク管理システムによる検出を長期間にわたって回避しました。

📋 ERPシステムにおけるSoD違反を悪用した購買不正(2020年)

ある製造業企業のERPシステムにおいて、購買部門の担当者が「仕入先マスターの登録・変更」と「発注処理の実行」の両方の権限を保有していたことが発覚しました。当該担当者は、架空の仕入先を登録し、その仕入先への発注を自ら実行することで、約3年間にわたり総額約1.5億円の資金を不正に流出させていました。

調査の結果、同社のERPシステムにはSoDチェック機能が実装されておらず、権限の付与が業務部門の裁量に委ねられていたことが判明しました。この事件を契機に、同社はSAP GRC Access Controlを導入し、SoDマトリクスに基づく自動的なコンフリクト検出と権限管理の厳格化を実施しました。

📋 IT管理者のSoD不備による内部情報漏洩(2022年)

あるテクノロジー企業において、システム管理者がユーザーアカウントの作成権限と監査ログの管理権限の両方を保有していたことを悪用した内部不正が発生しました。当該管理者は、架空のユーザーアカウントを作成して機密データにアクセスし、その痕跡を監査ログから消去していました。

不正は約2年間にわたって検出されず、外部からの通報によって初めて発覚しました。このケースは、IT管理領域におけるSoDの重要性を示しています。アカウント管理、権限管理、監査ログ管理は異なる担当者が行い、相互牽制が機能する体制を構築する必要があります。

🔗

Related Terms