職務の分離

職務の分離(SoD) は、職務の分離とも呼ばれ、タスクを完了するために複数の人員が必要であるという概念です。これは、組織が詐欺、妨害行為、盗難、情報の悪用、その他のセキュリティ侵害を防ぐために使用する管理制御です。政治の世界では、政府が立法府、行政府、司法府の3 つの独立した部門に分かれている民主主義国で見られるように、権力の分離として知られています。

職務の分離は内部統制の重要な概念です。不正やエラーからの保護を強化するには、必要なコストや労力の増加とバランスを取る必要があります。

本質的に、SoD は個人の活動に対して適切なレベルのチェックとバランスを実行します。IBM Systems Journalの RA Botha と JHP Eloff は SoDを次のように説明しています。

セキュリティ原則としての職務分離の主な目的は、詐欺やエラーの防止です。この目的は、特定のビジネス プロセスのタスクと関連する権限を複数のユーザーに分散させることで達成されます。この原則は、小切手に 2 つの署名が必要であるという職務分離の従来の例で実証されています。^[1]

実際の役職名や組織構造は、企業の規模や性質に応じて、組織ごとに大きく異なります。したがって、階級や階層よりも、関係する個人のスキルセットや能力の方が重要です。SoD の概念では、ビジネス上重要な職務は、承認、保管、記録保持、調整の 4 つの機能に分類できます。完璧なシステムでは、1 人の担当者が複数の機能を担当することはありません。

基本的に、部分的または完全に異なるパラダイムとして、いくつかのアプローチがオプションで実行可能です。

• 連続分離（2署名原則）
• 個人分離（四眼原則）
• 空間分離（別々の場所での別々の行動）
• 因子分離（複数の要因が完成に寄与する）

複数の機能的役割を担う人物は、それらの権限を乱用する機会があります。リスクを最小限に抑えるパターンは次のとおりです。

1. 不可欠だが、悪用される可能性のある機能から始めます。
2. 機能を、機能が動作するために必要なステップ、またはその機能を悪用できるようにする権限に必要なステップに分割します。
3. 各ステップを異なる人物または組織に割り当てます。

分離する機能の一般的なカテゴリ:

• 承認機能
• 記録機能、例: ソースドキュメントやコード、パフォーマンスレポートの作成
• 直接的または間接的な資産の保管。例: 郵便で小切手を受け取ったり、ソース コードやデータベースの変更を実装したりすること。
• 調整または監査
• 1つのセキュリティキーを責任者間で2つ（以上）に分割する

主に、個人の分離が唯一の選択肢として扱われます。

SoD という用語は、財務会計システムではすでによく知られています。あらゆる規模の企業は、小切手 (口座支払い) の受け取りと償却の承認、現金の入金と銀行取引明細書の照合、タイムカードの承認と給与小切手の保管などの役割を兼務しないことを理解しています。SoD はほとんどの情報技術 (IT) 部門にとってかなり新しいものですが、サーベンス・オクスリー法の内部監査の問題の多くは IT から生じています。^[2]

情報システムでは、職務の分離は、1 人の人物の行動による潜在的な損害を軽減するのに役立ちます。IS またはエンド ユーザー部門は、適切な職務の分離を実現するように組織化する必要があります。ISACA の職務の分離制御マトリックス^[3]によると、一部の職務は 1 つのポジションにまとめるべきではありません。このマトリックスは業界標準ではなく、どのポジションを分離する必要があるか、および組み合わせる場合にどのポジションを補償制御する必要があるかを示す一般的なガイドラインにすぎません。

会社の規模によって、機能と役割は異なります。職務分掌のない小規模な会社では、通常、支払いサイクルで不正な購入や支払いが発生する可能性があるという懸念に直面します。^[4]職務を分離できない場合は、代替管理を導入する必要があります。代替管理は、既存または潜在的な管理上の弱点のリスクを軽減することを目的とした内部管理です。1 人の人物が日常業務の遂行中にエラーや不正行為を実行し、それを隠蔽できる場合、その人には職務分掌と相容れない職務が割り当てられています。職務分掌の実施に役立つ管理メカニズムがいくつかあります。

1. 監査証跡により、 IT 管理者または監査人は、トランザクションの発生時点から更新されたファイルに存在する時点までの実際のトランザクション フローを再現できます。適切な監査証跡は、トランザクションを開始した人物、エントリの時刻と日付、エントリの種類、含まれている情報フィールド、更新されたファイルに関する情報を提供できるようにする必要があります。
2. アプリケーションの調整と独立した検証プロセスは最終的にはユーザーの責任であり、これにより、アプリケーションが正常に実行されたという信頼度を高めることができます。
3. 例外レポートは監督レベルで処理され、例外が適切かつタイムリーに処理されたことを示す証拠によって裏付けられます。通常、レポートを作成した人の署名が必要です。
4. 処理されたすべてのシステム コマンドまたはアプリケーション トランザクションを記録する、手動または自動のシステムまたはアプリケーション トランザクション ログを維持する必要があります。
5. 監督レビューは観察と調査を通じて実行する必要があります。
6. 規定の手順に従ってミスや意図的な失敗を補うために、独立したレビューが推奨されます。このようなレビューは、エラーや不規則性を検出するのに役立ちます。

会計専門家は、何百年にもわたる会計実務を通じて蓄積されたリスクを認識しているため、職務の分離に多大な投資を行ってきました。

対照的に、米国の多くの企業は、サーベンス・オクスリー法の内部統制の問題の予想外に高い割合がIT に起因することを発見しました。大規模な IT 組織では、不正または悪意のあるコードやデータを検出されずに持ち込む立場にある人が 1 人だけにならないように、職務の分離が一般的に使用されています。役割ベースのアクセス制御は、 SoD が必要な IT システムで頻繁に使用されます。最近では、成長中の組織で役割の数が増えるにつれて、属性ベースのアクセス制御を備えたハイブリッド アクセス制御モデルが、役割ベースのアクセス制御の制限を解決するために使用されています。^[5]

ソフトウェアとデータの変更を厳密に制御するには、同じ人物または組織が次のいずれかの役割のみを実行する必要があります。

• 要件（または変更要求）の特定（例：ビジネスパーソン）
• 認可と承認（例：ITガバナンス委員会またはマネージャー）
• 設計と開発（例：開発者）
• レビュー、検査、承認。例: 別の開発者または建築家。
• 運用環境での実装。通常はソフトウェアの変更またはシステム管理者が担当します。

これはソフトウェア開発ライフサイクルの包括的な説明ではなく、職務の分離に適用可能な重要な開発機能のリストです。

情報システムにおける職務の分離を成功させるには、いくつかの懸念事項に対処する必要があります。

• システム内での個人の承認権限が組織内での役割と一致していることを確認するために使用されるプロセス。
• パスワードの知識、オブジェクト（キー、トークン）の所有、または生体認証特性など、使用される認証方法。
• システム内の権限の回避は、データベース管理アクセス、ユーザー管理アクセス、バックドア アクセスを提供するツール、またはサプライヤーがインストールしたユーザー アカウントを通じて発生する可能性があります。この特定の問題に対処するには、アクティビティ ログの確認などの特定の制御が必要になる場合があります。

• Wayback MachineのNick Szaboの職務分離に関するエッセイ(2016 年 3 月 6 日アーカイブ)
• 「職務分離の定義」、ISACA
• 「セキュリティリスクを軽減するための職務の分離」、Datamation
• 「透明性、分割、分離、責任のローテーションおよび監督」、ISM3