職務分離（SoD）とは？内部不正を防ぐアクセス権限の設計と情シス実践ガイド

セキュリティの教科書では「最小権限の原則」がよく語られますが、中小企業の現場でより見落とされがちな概念があります。それが「職務分離（SoD: Segregation of Duties）」です。

「うちには1人しか情シスがいないから無理」「小さな会社に職務分離なんて大袈裟」——こういった声をよく聞きます。しかし実際のインシデント調査を見ると、アクセス権の集中こそが内部不正を見えにくくし、外部攻撃者が侵入後に暴れ回れる原因になっています。

この記事では、職務分離の本質的な意味から、情シス1人の中小企業でも実践できる権限設計の手順まで、現場目線で解説します。

職務分離（SoD）とは？なぜ今これが重要か

職務分離（SoD）とは、「1人の人物が単独で完結させてはならない業務の組み合わせを定義し、それを複数の担当者に分ける」という情報セキュリティと内部統制の基本原則です。

もともとは財務・会計の世界で発展した概念です。「発注担当者が承認もできる」「支払い処理と照合を同じ人がやる」といった権限の集中が横領や不正を生む、という経験則から来ています。現代のITシステムでも同じ原則が適用されます。

なぜ今、特に重要か。

理由は二つあります。一つは、クラウドサービスの普及でアクセス権の設定ミスが起きやすくなったこと。もう一つは、攻撃者がアカウントを乗っ取った後、過剰権限を持つ単一アカウントを使って被害を拡大する手口が一般化していることです。

職務分離が機能していれば、攻撃者が1つのアカウントを制圧しても「できること」が限定されます。攻撃の連鎖を断ち切る構造的な防御になるのです。

攻撃者が狙う「権限集中」の穴

攻撃者の視点から見ると、職務分離が崩れている環境は非常に動きやすい標的です。

シナリオ1：管理者アカウントの乗っ取り

多くの中小企業では、1人の担当者が「ファイルサーバーのアクセス権設定」「アクセスログの管理」「ユーザーアカウントの作成・削除」を兼任しています。攻撃者がこのアカウントを乗っ取ると、自分の行動をログから消しながら、自由にデータを抜き出せます。ログの管理者が自分自身だからです。

シナリオ2：内部不正の隠蔽

退職予定の従業員が自分のアクセスログを削除し、機密データを持ち出す——こういったケースが実際に起きています。「自分のアクセス記録を自分で消せる」状況がなければ、不正は記録に残り、それ自体が抑止力になります。

職務分離の観点で特に危険な権限の組み合わせを整理すると、次のようになります。

# 職務分離の観点から見た危険な権限の組み合わせ
危険な組み合わせ1: アカウント作成権限 + ログ削除権限
危険な組み合わせ2: データアクセス権限 + アクセスログ管理権限
危険な組み合わせ3: 支払い申請権限 + 支払い承認権限
危険な組み合わせ4: システム変更権限 + 変更承認権限
危険な組み合わせ5: バックアップ実行権限 + バックアップ削除権限
→ これらを同一人物に持たせない設計が職務分離の基本

職務分離の具体的な実装手順

1. 職務マトリクスで「誰が何をできるか」を可視化する

まず、現状のアクセス権を棚卸しします。縦軸に業務タスク、横軸にユーザーまたはロールを並べた表（職務マトリクス）を作成し、現在誰が何をできるかを一覧化します。

・棚卸しの対象: Active Directory / Azure AD のグループメンバーシップ、クラウドサービスのIAMロール、ファイルサーバーの共有権限
・確認すべき組み合わせ: 申請・実行・承認・監査の4役を同一人物が担っていないか
・ツール活用: Microsoft 365環境なら「Azure AD アクセスレビュー」機能を活用すると棚卸しを効率化できます

この棚卸し作業は最初が大変ですが、一度やると「誰がどんな権限を持っているか誰も知らない」という状態を解消できます。現場では意外と多い問題です。

2. ロール設計で職務分離を技術的に実現する

現状確認が終わったら、RBACの考え方に基づいてロール（役割）を再設計します。人ではなくロールに権限を付与し、そのロールを人に割り当てる構造にすることで、権限の見直しが格段に楽になります。

・基本ロール例（中小企業向け）:
一般ユーザー: 自分の業務に必要なファイルの読み書きのみ
部門マネージャー: 自部門のアクセス権申請の承認権限（実行権限は持たない）
情シス担当: アカウント作成・権限設定（ただしログ削除権限は持たない）
監査担当: ログの閲覧のみ（設定変更権限は持たない）

・重要な原則: ロールを設計するとき、「実行」と「承認」の分離を最優先にします。この1点だけでも、内部不正リスクは大きく下がります

3. 定期的なアクセス権限レビューで形骸化を防ぐ

職務分離の最大の落とし穴は「最初は守っていたが、気づいたら形骸化していた」という状態です。異動・退職に伴って権限が放置され、気づけば1人が複数の矛盾する権限を持つ状況に戻っていることがあります。

・四半期に1回: ユーザーアカウントの棚卸し（退職者・異動者のアカウント確認）
・異動・退職のたびに: 新旧業務で権限の組み合わせに問題がないか確認
・年1回: 全アクセス権限の一斉レビュー（「ゾンビアカウント」の撲滅）

アクセス権レビューの記録は、インシデント発生時の証拠にもなります。面倒でも記録を残す習慣が重要です。

中小企業でも今日からできること

「人が少なくて職務分離なんてできない」という声をよく聞きます。しかし、完璧な分離が難しくても「リスクを下げる一歩」は今日から踏み出せます。

最優先でやること3つ

・ログの管理を別の人に持たせる: これが最も効果的な一手です。ITの実作業担当者がログを削除できない設計にするだけで、不正の隠蔽ができなくなります。外部のSIEMサービスや、変更不可のクラウドストレージへのログ転送も有効です
・管理者と一般ユーザーのアカウントを分ける: 管理作業専用のアカウントと、日常業務用のアカウントを別にします。管理者アカウントはメールやWeb閲覧などの日常業務では使わない習慣をつけます
・重要な変更には第2の目を持つ: アカウント作成・大量削除・権限変更などの重要操作は、実施後に別の担当者が確認するルール（またはメール通知）を設けます

予算がなくても、ルールと設計の工夫だけでリスクを大幅に下げることができます。

アクセス権の具体的な設計手法については、アクセス制御モデル（DAC・MAC・RBAC）の解説記事もあわせてご参照ください。

また、職務分離が崩れた環境で実際に起きやすいリスクは、インサイダー脅威（内部不正）の記事で詳しく解説しています。

IAMの全体設計については、IAM（アイデンティティ・アクセス管理）の実践ガイドも参考にしてください。

よくある誤解と注意点

誤解1: 「小規模組織には職務分離は意味がない」

職務分離は人数の問題ではなく、設計の問題です。2人いれば「実行」と「承認」を分離できます。1人の場合でも、「自分の作業ログは外部の監査ツールが保管する」という仕組みで部分的な代替が可能です。

誤解2: 「職務分離を徹底したら業務が非効率になる」

全ての操作に承認フローを挟む必要はありません。管理者権限の付与、大量データの削除、財務系の変更など「リスクの高い操作」に絞って分離を適用するのが現実的です。日常の軽微な作業に分離を強制すると、担当者が承認を形式的に処理するようになり、かえって形骸化します。

誤解3: 「クラウドサービスは自動的に安全」

クラウドでもアクセス権の設計は利用者の責任です。AWS・Azure・Google Cloudでは、IAMロールの設計ミスを原因とする情報漏洩が多数報告されています。クラウド環境でこそ、職務分離を意識したロール設計が欠かせません。

本記事のまとめ

職務分離は「大企業だけのもの」ではありません。むしろ、監視の目が届きにくい中小企業こそ、設計の段階でリスクを封じ込める仕組みが必要です。

まず今日できること——ログ管理の権限を別の人間（または別のシステム）に持たせること——この一点から始めてみてください。

Linuxサーバー上のファイルアクセス権限設計については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。