J-SOX 内部統制テストで指摘されやすい業務システムのアクセス権限 5 パターン

1. 「管理者」 ロールが何でもできる

業務システムの初期設計で、 「管理者」 ロールが全権限を持っているケースは多いです。これは小規模時には便利ですが、内部統制テストでは職務分掌違反として落ちます。

会計関連の操作・人事関連の操作・運用関連の操作・委託先関連の操作を別ロールに分け、 「ある操作を実行できる人」 と 「その操作を承認できる人」 を別人になるようロール設計を変更します。

2. 特権 ID を複数人で共有

本番環境の特権 ID (root / admin / supervisor) を複数のオペレーターで共有している運用は、操作者の追跡ができないため指摘されます。

個人 ID で本番にログインし、特権が必要な操作はsudo 相当の権限昇格で実行する設計に変更します。業務システムのアプリケーション層でも同様で、 「個人 ID + 必要時の権限昇格」 の構造を持ちます。

3. 退職者・異動者のアカウントが残る

人事システムと業務システムのアカウント連動ができていないと、退職者・異動者のアカウントが残り続けます。

業務システム側に人事マスタとの自動連携 (HRIS API / Workday / freee HR 等) を組み込み、退職・異動が反映された日にアクセス権限を自動で無効化・付け替えする仕組みを入れます。連携が難しい場合でも、月次でのバッチ照合と通知だけは必ず実装します。

4. ロール定義が文書化されていない

ロールの定義が業務システムのコードや設定にしか存在せず、文書化されていないケースは多いです。これは内部統制テストで 「何ができるロールなのか客観的に確認できない」 として指摘されます。

業務システムの管理画面に、ロール定義 (権限一覧・対象データ・操作種別) を表示する画面を作り、それを文書化された定義書とリンクさせる運用にします。

5. アクセスログが粒度不足

アクセスログを 「ログインの有無」 程度しか取得していないと、内部統制テストでは不十分とされます。

業務システムでは、認証・特権操作・データ参照 (特に個人情報・財務情報)・データ変更・データ削除・権限変更・委託先設定変更を、操作者・対象・日時・前後値で記録します。改ざん防止のために、書き込み専用の保管先に転送し、削除権限を本番権限と分離します。