SAP セキュリティ & GRC
SAP職務分掌（SoD）基礎：違反の見つけ方と是正の進め方
SAPの職務分掌（SoD）を実務で運用するために、リスクの考え方、典型的な違反例、分析から是正・例外管理までの手順を整理します。
SAPの権限運用では、1人のユーザーが相互けん制すべき業務を単独で完結できないように設計します。この考え方が職務分掌（Segregation of Duties、SoD）です。SoDは権限オブジェクトの数を減らすだけの仕組みではなく、業務プロセス上の不正や誤りを発見・防止するための統制として運用します。
本記事では、SAP ERPやSAP S/4HANAでSoDを確認するときの基本的な進め方を、実務担当者が使える形でまとめます。SAP GRCを利用する場合も、利用しない場合も、最初に業務上のリスクと担当者の責任範囲を定義することが重要です。
SoDの基本概念
SoDでは、同じユーザーまたは同じ担当者が、相互にけん制すべき複数の操作を実行できる状態をリスクとして扱います。たとえば、仕入先マスタを登録・変更する担当者が、同じ仕入先への請求書登録や支払処理まで実行できると、架空仕入先の作成から支払までを単独で進められます。
重要なのは、トランザクションコードを単純に組み合わせることではありません。リスクは、業務機能、対象データ、会社コードやプラントなどの組織値、実行可能な操作、承認者の配置を合わせて判断します。FI、MM、SDなど複数モジュールにまたがる業務では、部門単位で権限を分けただけでは十分な分離にならない場合があります。
SoDの判定単位は、通常次のように整理します。
- 業務機能：仕入先登録、請求書登録、支払実行など
- 操作：作成、変更、承認、転記、支払、削除など
- 対象範囲：会社コード、購買組織、プラント、販売組織など
- 関係する担当者：実行者、承認者、監督者、運用管理者
- リスク結果：不正、誤処理、隠蔽、財務報告への影響
代表的なSoD違反の例
実務では、検出された組み合わせをそのまま違反と確定せず、業務プロセスと組織値を確認してから判定します。次の例は、リスク分析の起点として使いやすい代表例です。
| 組み合わせ | 想定されるリスク | 確認する統制 |
|---|---|---|
| 仕入先マスタの登録・変更 + 請求書登録 | 架空仕入先や不正請求 | マスタ変更承認、請求書照合、上長レビュー |
| 発注 + 入庫確認 + 請求書登録 | 架空取引や数量の水増し | 発注・入庫・請求書の三者照合 |
| 顧客マスタ変更 + 売上伝票登録 | 売上先や請求先の不正変更 | マスタ変更ログと売上承認 |
| 仕訳登録 + 支払実行 | 不正な仕訳からの資金流出 | 支払承認、支払リストレビュー |
| 本番プログラム変更 + 本番実行 | 未承認変更や処理結果の隠蔽 | 変更管理、移送承認、実行ログ確認 |
たとえば、発注と入庫を同じ担当者が実行できても、請求書登録や支払承認が別担当であり、入庫数量のレビューが機能していれば、残余リスクを許容できることがあります。一方、同じ権限がテスト用会社コードだけに限定されている場合は、本番業務のSoD違反とは分けて評価します。
SoDリスクの全体像を確認するには、SAP セキュリティとGRCの概要も参照してください。SoDは、ユーザー管理だけでなく、アクセス統制、監査ログ、業務統制を組み合わせて運用します。
リスクルールを設計する
分析を安定させるには、先にリスクルールを定義します。ルールには少なくとも、リスクID、リスク名、関係する業務機能、競合する操作、対象モジュール、重大度、想定される影響、補完統制を記録します。
ルール名は、担当者が業務内容を理解できる表現にします。「権限Aと権限B」のような技術的な名前だけでは、リスク所有者が判断しにくくなります。「仕入先変更と支払実行による不正支払リスク」のように、行為と影響が分かる名称が適しています。
重大度の決定では、次の観点を組み合わせます。
- 金額や取引量への影響
- 不正を実行した場合の発見可能性
- 取引を単独で完結できる範囲
- 財務報告、法令、顧客データへの影響
- 補完統制の頻度と証跡の品質
ルールは一度作って終わりにせず、組織変更、業務追加、SAP S/4HANAへの移行、カスタムトランザクションの追加、承認フロー変更のたびに見直します。リスクルールの所有者と承認者を決め、変更履歴を残すと、監査時に判断の根拠を説明しやすくなります。
SoD分析を実行する
分析は、権限設計の変更前と定期レビューの両方で実行します。SAP GRC Access Controlを利用する場合は、ユーザー、ロール、権限、組織値を対象に分析し、違反の組み合わせと該当ユーザーを一覧化します。SAP GUIで確認した情報や、ユーザー・ロール管理の台帳を補助資料として使う場合も、分析時点をそろえてください。
実務での基本手順は次のとおりです。
- 対象システム、クライアント、会社コード、対象期間を確定する
- 分析対象のユーザーまたはロールを選ぶ
- リスクルールを適用し、SoD違反候補を抽出する
- 付与されたロール、トランザクション、組織値を確認する
- 実際の業務担当、代行者、承認者、利用頻度を確認する
- 真の違反、誤検知、補完統制付きの例外に分類する
- 所有者と期限を設定し、是正または承認手続きへ進める
分析結果には、ユーザーIDだけでなく、対象ロール、リスクルール、組織値、検出日、判定者、対応期限を記録します。ロール単位の分析は設計段階で有効ですが、ユーザー単位では複数ロールや直接付与権限を含めて確認します。
SoD違反を判定する
検出結果の判定では、技術的に権限が存在することと、業務上のリスクが成立することを分けて考えます。まず、対象ユーザーが実際にその処理を担当しているか、権限が本番環境に有効か、対象の会社コードやプラントが一致するかを確認します。
次に、リスクが成立するための一連の操作を単独で実行できるかを確認します。権限があっても、ワークフロー承認や別担当者の照合が必須であれば、補完統制の有効性を評価します。ただし、補完統制が「担当者が気をつける」だけで、実施者、頻度、証跡、未実施時の対応が決まっていない場合は、十分な統制とは扱いません。
判定記録には、次の項目を残します。
- 判定区分：違反、誤検知、補完統制付き例外など
- 業務プロセスと対象組織
- 競合する操作と該当ロール
- リスク所有者と統制実施者
- 補完統制の具体的な手順
- 証跡の保管場所と確認頻度
- 承認日、再評価日、対応期限
同じリスクが複数ユーザーに出ている場合も、まとめて一括承認せず、業務責任と組織範囲が同じか確認します。共通ロールの設計不備が原因なら、個別ユーザーの除外だけでなく、ロール構成の是正を行います。
違反を是正する
是正方法は、リスクをなくす順に検討します。最初の選択肢は、不要な権限やロールを削除し、業務を別担当へ分離することです。次に、組織値を限定する、作成と承認を分ける、期間限定の権限にするなど、業務上必要な範囲へ縮小します。
代表的な対応は次のとおりです。
- 使われていないトランザクションや権限をロールから削除する
- 仕入先登録、請求書登録、支払処理を別ロールに分ける
- 会社コードやプラントなどの組織値を限定する
- 承認権限を実行権限と別の担当者に割り当てる
- 一時的な作業には期間と理由を設定する
- 恒久的な業務要件なら、補完統制と責任者を正式に登録する
Access Controlの機能と運用範囲を確認すると、アクセスリスク分析、申請、承認、レビューをどこまで一体化するかを整理できます。緊急時の特権アクセスを使う場合は、通常ロールへ恒久的な権限を追加せず、SAP Emergency Access Management（Firefighter）の運用に沿って理由、承認、利用ログ、事後レビューを残します。
是正後は、対象ユーザーの再分析を実行します。ロールを削除しただけでなく、別ロール、複合ロール、直接付与、緊急アクセス経路から同じ権限が残っていないか確認します。再分析の結果と変更依頼を関連付け、完了条件を明確にします。
例外と補完統制を管理する
業務規模や組織構造によっては、完全な職務分離が難しい場合があります。その場合は、例外を無期限の承認として扱わず、リスク所有者が期限、理由、補完統制、証跡、再評価日を明示します。
補完統制の例には、次のようなものがあります。
- 支払前に、仕入先変更履歴と請求書を別担当者が照合する
- 高額取引を別承認者が承認する
- 月次で仕訳、支払、マスタ変更をレビューする
- 重要な操作の監査ログを抽出し、実行者と承認者を確認する
- 緊急アクセスの利用後に、操作内容と業務チケットを突合する
補完統制は、設計されているだけでは不十分です。誰が、いつ、何を、どの証跡で確認したかを残し、未実施や異常があった場合のエスカレーション先を定義します。Process Controlを利用する環境では、統制の実施状況や証跡の管理を業務プロセスに組み込みます。
定期レビューと監査証跡を整える
SoD管理は、ロール変更時だけでなく、定期的なユーザーアクセスレビューと組み合わせます。退職、異動、組織変更、プロジェクト終了、委託先契約終了のタイミングでは、不要なアクセスが残っていないかを確認します。
レビューでは、検出件数だけを指標にせず、次の運用指標を追跡します。
- 未対応の高重大度リスク数
- 対応期限を超過した件数
- 例外の平均有効期間
- 再発したリスクの件数
- 補完統制の未実施件数
- 権限変更後の再分析完了率
ユーザーアクセスレビューの進め方を参考に、レビュー対象、承認者、期限、証跡の保管場所を決めます。監査ログを使う場合は、SAPセキュリティ監査ログの基礎も確認し、権限の存在だけでなく、実際の操作実績とレビュー結果を結び付けます。
監査証跡には、分析条件、抽出日時、判定結果、承認履歴、是正変更、再分析結果を含めます。証跡を個人のメールやローカルファイルだけに保存すると、担当者交代時に追跡できなくなるため、管理されたリポジトリやチケットに集約します。
運用を安定させる実務チェック
SoD運用を開始するときは、最初からすべての業務機能を対象にせず、資金、仕入先、顧客、財務報告、本番変更など影響の大きい領域から始めます。業務責任者、権限管理者、内部統制担当者、監査担当者の役割を明確にすると、技術的な検出結果を業務判断へつなげやすくなります。
運用開始前のチェック項目は次のとおりです。
- リスクルールに業務責任者が割り当てられている
- 対象システムと組織値が分析範囲に含まれている
- ユーザー、ロール、直接付与権限を分析できる
- 高重大度リスクの対応期限が決まっている
- 例外承認に有効期限と再評価日がある
- 補完統制の実施者と証跡が決まっている
- 是正後の再分析を完了条件にしている
- 退職・異動・緊急アクセスを定期レビューに含めている
SoDは、権限を一度整理すれば完了する作業ではありません。業務変更、ロール変更、組織変更、緊急対応のたびにリスクを再評価し、違反の削除、例外の期限管理、補完統制の証跡化を継続することで、実効性のある職務分掌を維持できます。