ITの内部監査｜アクセス権限と特権IDの確認手順

📌 結論　ITの内部監査は権限と記録の2点に絞る

ITの内部監査というと専門知識が必要に思われがちですが、上場準備の段階で求められる水準はそこまで高くありません。押さえるべきは、誰が何をできる状態になっているかという権限の話と、実際に何が行われたかを後から追えるかという記録の話の2点です。この2点が押さえられていれば、他の領域の内部統制も動かせます。

逆にここが崩れていると、購買や販売の統制をどれだけ丁寧に設計しても、システム上で1人が承認まで完結できてしまうため、統制として機能しません。ITの内部監査は、他の領域の監査結果の前提を確かめる作業でもあります。

🧭 アクセス権限の棚卸しはどう進めるか

アクセス権限の確認で最初にやるべきことは、比べる2つのリストの基準日をそろえることです。人事から受け取る在籍者名簿と、システムから出力するアカウント一覧の時点がずれていると、差分のほとんどが時点のずれによるものになり、本当に見るべき項目が埋もれます。基準日を月末に固定し、両方をその日で出してもらうところから始めます。

突合の結果として出てくる差分は、退職者のアカウントが残っている、異動したのに前の部署の権限が付いたまま、担当者名のないシステム用のIDがある、の3つに分かれます。3つ目は必ずしも問題ではありませんが、用途と管理者がはっきりしないIDは指摘の対象になります。

差分の確認が終わったら、次は権限の中身を見ます。会計システムであれば、仕訳を入力できる人と承認できる人が分かれているか、マスタを変更できる人が限られているかを確かめます。ここは職務分掌表と照らし合わせる作業になるため、内部監査が単独で判断するのではなく、業務部門の責任者に権限の必要性を説明してもらう形をとると精度が上がります。

🗂 特権IDをどう扱うか

特権IDは、通常の権限を越えてデータの直接変更やシステム設定の変更ができるIDです。数は少ないため、サンプル抽出ではなく全件を対象にできます。内部監査で見るのは、台帳が整備されているかではなく、使用のたびに申請と承認があり、実際の操作ログと突き合わせられるかどうかです。

実務でよく出てくるのが、障害対応で先に特権IDを使い、後から報告するという運用です。緊急時の対応そのものは否定されるものではありませんが、事後承認の期限が決まっていること、そして事後承認が実際に行われた記録が残っていることが必要になります。期限が決まっていない運用は、実質的に承認がないのと同じと見なされます。

もうひとつ扱いが難しいのが、保守を委託している業者に渡している権限です。常時付与したままにしている会社は少なくありませんが、必要な期間だけ有効にする仕組みに変えられないかを検討します。変えられない場合は、操作ログを会社側が定期的に確認しているかが代わりの統制になります。

📊 変更管理とログの確認

変更管理では、本番環境への反映が申請と承認を経ているかを確かめます。抽出の仕方としては、リリース記録から数件を選んで申請書までさかのぼる方向と、申請書から選んでリリース記録に到達する方向の両方をやると、記録されていない反映があるかどうかが見えます。片方向だけだと、記録に残っていない作業は最後まで見つかりません。

ログについては、取得しているかどうかよりも、誰かが見ているかどうかが論点です。ログを取得していると説明されたら、直近数か月の確認記録を見せてもらいます。確認記録がなければ、ログは事後の調査には使えても統制としては機能していないことになります。指摘としては、確認の頻度と確認者、確認した内容の記録方法を定めることを求めます。

バックアップも同じ考え方で、取得記録があるかではなく、復旧できることを確かめた記録があるかを見ます。復旧テストを一度も行っていない会社は多いため、年1回の実施を是正案として提案するのが現実的です。

⚖️ 個人情報を扱うシステムの見方

顧客の個人情報を扱うシステムがある場合は、アクセスできる範囲が業務上必要な人に限られているかを重点的に見ます。個人情報の保護に関する法律は、取り扱う事業者に安全管理の措置を求めており、上場審査でも管理体制の説明を求められる領域です。

内部監査として確認しやすいのは、閲覧権限を持つ人数の推移と、ダウンロード機能の利用状況です。人数が増え続けている場合は、権限を付与する基準が緩んでいる可能性があります。大量のデータをダウンロードできる機能については、実行できる人を絞り、実行のログを残しているかを確かめます。

📄 指摘の書き方と情報システム部門との関係

ITの指摘は、技術的な表現になりすぎると経営に伝わりません。権限が分離されていないという事実だけを書くのではなく、その状態だと1人で仕入から支払まで完結できるという業務上の帰結まで書きます。読む側が判断できる形にするのが内部監査の役割です。

情報システム部門は人数が少ないことが多く、指摘を出しても対応する余力がないという状況が起きます。そのため是正案は、すぐにできるものと時間のかかるものに分け、優先順位をつけて示します。権限の棚卸しの定例化のように運用で対応できるものと、システム改修が必要なものを混ぜて並べると、全体が止まります。

また、情報システム部門が自ら統制を運用している領域を、その部門自身に確認させると独立性の問題が生じます。特権IDの使用記録の確認のように、統制の実施者と確認者が同じになりやすい領域では、内部監査が確認の役割を担うのではなく、別部門または上位者が確認する体制になっているかを見るという立ち位置を保ちます。

❓ よくある質問

📄 まとめ

ITの内部監査は、権限と記録の2点に絞れば専門知識がなくても進められます。他の領域の統制が成立する前提を確かめる作業だと考えると位置づけがはっきりします。

アクセス権限の棚卸しは基準日をそろえることから始めます。ここが揃っていないと差分がノイズだらけになり、本当に見るべき項目が埋もれます。

特権IDは全件を対象にでき、申請と操作ログの突合が中心になります。事後承認の期限が決まっているかが実務上の分かれ目です。

指摘は技術的な事実だけでなく、その状態が業務上どういう帰結を生むかまで書きます。是正案はすぐできるものと改修が要るものを分けて示します。

本記事は一般的な情報提供を目的としたものであり、個別の事案に対する助言ではありません。実際の制度設計や運用にあたっては、監査法人および主幹事証券会社にご確認ください。

📚 参考（公的な一次情報）

• 会社法（e-Gov法令検索）
• 個人情報の保護に関する法律（e-Gov法令検索）
• 内部監査基準（一般社団法人日本内部監査協会）
• 新規上場ガイドブック（日本取引所グループ）