四半期のIT監査で、内部監査室の担当者が人事部から受け取った退職者一覧と、会計システムのユーザー一覧を並べて照合していました。表計算ソフトの照合関数が返した結果は、一致しない行が3件。そのうち1件は、半年前に退職した元経理担当者のIDで、最終ログイン日は退職日の2週間後になっていました。
調べてみると、ログインしたのは後任者でした。引き継ぎの間だけ使うつもりで、前任者のパスワードを聞いていたのです。悪意はありません。しかし、その期間に誰がどの仕訳を承認したのか、システムの記録からは正しく説明できなくなっていました。
アクセス管理は、ITGC（IT全般統制）の中でも最も不備が見つかりやすい領域の一つです。本記事では、退職者アカウント、特権ID、アクセス権の棚卸という3つの論点を中心に、内部監査部門が実施する監査手順を、架空のモデルケースと記入例を交えて解説します。
この記事の要点
- アクセス管理の目的は「誰が何をしたか」を説明できる状態を保つことです。権限は放置すると増え続けるため、入社・異動・退職の各時点での統制と、定期的な棚卸の両方が必要です
- 退職者アカウントの監査は、サンプルではなく人事データとID一覧の全件突合が効率的で確実です
- 特権IDは「使わせない」より「誰がいつ何のために使ったか記録し、第三者が確認する」統制が現実的です
- アクセス権棚卸は、実施したことより「元の一覧が完全か」「レビューが実質的か」を確かめることが監査の要点です
アクセス管理とは何か、なぜ監査で重視されるのか
実施基準におけるアクセス管理
金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」（以下、実施基準）は、ITに係る全般統制の例として「内外からのアクセス管理などシステムの安全性の確保」を挙げています。監査人の手続としても、企業がデータ、システム、ソフトウェア等の「不正使用、改竄、破壊等を防止するために」、適切なアクセス管理等の方針を定めているかを確認するとしています。
興味深いのは、実施基準がITに係る業務処理統制（ITAC）の例にも「システムの利用に関する認証、操作範囲の限定などアクセスの管理」を挙げている点です。アクセス管理は二つの層にまたがっています。IDを誰に付与し、いつ削除するかという手続はITGC、業務システムの中で起票者と承認者を分ける権限設定はITACとして扱うのが一般的です。両者の違いはITACとITGCの違い｜自動統制の評価手順で整理しています。
なぜアクセス管理が崩れやすいのか
アクセス管理の不備が多い理由は、権限が「足し算」でしか増えない性質にあります。新しい業務を担当すれば権限が追加されますが、前の業務の権限を外す依頼はほとんど出されません。困る人がいないからです。こうして異動を重ねるたびに権限が積み上がる現象は、権限の肥大化（privilege creep）と呼ばれます。
さらに、アクセス管理は複数部門の連携に依存します。退職の事実を知っているのは人事部、IDを削除するのは情報システム部、業務上の権限の要否を判断できるのは各業務部門です。どこか1か所で連絡が途切れると、統制は機能しなくなります。監査では、個々の手続だけでなく、部門間の情報の受け渡しに注目することが大切です。
国際的な枠組みとの対応
アクセス管理の考え方は、国際的な規格や枠組みでも共通しています。ISO/IEC 27002:2022は、アクセス制御（5.15）、識別情報の管理（5.16）、認証情報（5.17）、アクセス権（5.18）、特権的アクセス権（8.2）などの管理策を示しています。米国NISTのSP 800-53 Rev.5では、アカウント管理（AC-2）や最小権限（AC-6）が該当します。
これらに共通する原則は、業務に必要な最小限の権限だけを与える「最小権限」と、一人の人がある取引を最初から最後まで完結できないようにする「職務分離」です。サイバーセキュリティの観点も含めた監査の枠組みはサイバーセキュリティ監査の進め方｜NIST CSF 2.0の活用で解説しています。
IDのライフサイクル：入社・異動・退職の3時点
アクセス管理の統制は、IDのライフサイクルに沿って整理すると漏れがなくなります。海外ではJoiner（入社）、Mover（異動）、Leaver（退職）の頭文字からJMLと呼ばれることもあります。
| 時点 | 主なリスク | 期待される統制 | 監査で確認する証跡 |
|---|---|---|---|
| 付与（入社・新規利用） | 承認のない付与、過剰な権限 | 申請書に上長と権限管理者の承認、ロール（職務別の権限セット）に基づく付与 | 申請書、承認記録、付与日時のログ |
| 変更（異動・兼務） | 旧部署の権限の残存 | 人事異動情報を起点とした権限見直し、旧権限の削除 | 異動一覧と権限変更記録の照合 |
| 削除（退職・契約終了） | 退職者・契約終了者のIDの残存、なりすまし | 人事からの退職連絡に基づく期限内の無効化 | 退職者一覧とID一覧の突合結果 |
| 定期見直し | 上記の漏れの蓄積 | 業務部門の責任者による定期棚卸 | 棚卸結果、修正依頼と対応記録 |
「期限内」は誰が決めるのか
退職者IDの削除について、「退職日当日」「3営業日以内」「月末まで」など、企業によって基準はさまざまです。実施基準に具体的な日数の定めはありません。重要なのは、自社の規程で期限を明確に定め、それをリスクに見合った水準にしておくことです。
判断のポイントは、退職後にIDが残った場合、誰がそのIDを使えるかです。社外からアクセスできるSaaSや、リモート接続が可能なシステムでは、退職者本人がログインできる可能性があるため、期限を短くする必要があります。一方、社内ネットワークからしか接続できず、ネットワークアカウントが退職日に無効化されるなら、個別システムのIDは多少遅れても実質的なリスクは限られます。監査では、期限の妥当性そのものも評価の対象になります。
退職者アカウントの監査手順
サンプルではなく全件突合を選ぶ理由
退職者IDの削除は、件数が少ない統制ならサンプルで検証することもできます。しかし、この統制は「漏れた1件」が問題になる性質のものです。25件のサンプルで漏れがなくても、残りの母集団に漏れがないとは言えません。サンプル数の考え方は内部監査のサンプル数はなぜ25件？で解説していますが、データが手に入るなら全件突合のほうが効率的で確実です。
全件突合は、人事システムの退職者一覧と対象システムのユーザー一覧を、社員番号などのキーで照合するだけで実施できます。表計算ソフトでも可能ですし、件数が多ければデータ分析ツールを使います。手法はデータ分析監査（CAAT）入門が参考になります。
手順
- 母集団の確定：評価対象期間の退職者一覧を人事部から入手し、件数を人事システムの画面や月次の人員報告と照合して完全性を確かめる
- ID一覧の入手：対象システムのユーザー一覧を、監査人の立会いのもとで出力するか、出力条件と日時が記録されたものを入手する
- キーの整備：社員番号がID一覧にない場合は、氏名・メールアドレスで照合し、表記ゆれを調整する
- 突合：退職者のうち、ID一覧で「有効」のまま残っているもの、または無効化日が規程の期限を超えているものを抽出する
- 利用有無の確認：抽出したIDの最終ログイン日時を確認し、退職日以降の利用があれば、その期間の操作ログを調査する
- 原因の特定と報告：連絡漏れ、手続の遅延、共有利用など原因を分類し、是正を依頼する
手順1の完全性確認を省くと、突合の前提が崩れます。人事部の出力した一覧から一部の退職者（例えば契約社員や出向者）が漏れていれば、突合結果は「異常なし」と出てしまうからです。
調書の記入例
架空のモデルケースとして、サービス業C社の会計システムについての突合結果を示します。
| 項目 | 記載内容 |
|---|---|
| 対象システム | クラウド会計システム（SSO連携なし、個別ID管理） |
| 対象期間 | 当年4月1日〜翌年3月31日 |
| 母集団 | 退職者87名（正社員61、契約社員19、出向復帰7）。人事システムの月次人員報告の退職者数合計と一致 |
| ID一覧 | 3月31日17時に情報システム部が出力。出力画面のキャプチャを保存 |
| 規程の期限 | 退職日から3営業日以内に無効化 |
| 突合結果 | 会計システムにIDがあった退職者23名。うち20名は期限内に無効化。2名は期限超過（5営業日、8営業日）、1名は3月31日時点で有効 |
| 利用状況 | 有効のまま残った1名のIDで、退職後に12回のログインと仕訳承認4件を確認。後任者による共有利用と判明 |
| 評価 | 不備。共有利用により承認者の特定ができない期間があり、職務分離の前提が損なわれた。承認された仕訳4件は内容の妥当性を別途検証し、誤りなし |
| 是正依頼 | 人事部から情報システム部への退職連絡を人事システムの自動通知に変更、引継ぎ時のID共有禁止を規程に明記 |
最後の2行が重要です。不備を見つけたら、そのIDで何が行われたかまで確かめ、財務報告への影響を評価します。是正の進捗管理は発見事項フォローアップの運用を参考にしてください。
特権IDの監査手順
特権IDとは何か
特権IDとは、システムの設定変更、ユーザーの作成・削除、データの直接修正など、通常の業務権限を超える操作ができるIDのことです。OSの管理者アカウント、データベースの管理者アカウント、業務アプリケーションの管理者ロール、SaaSのテナント管理者などが該当します。人が使わず、プログラム同士の連携に使うサービスアカウントやAPIキーも、強い権限を持つ場合は同じ扱いが必要です。
特権IDが監査で重視されるのは、他のすべての統制を迂回できるからです。承認フローを経ずにデータベースの金額を書き換えられる人がいれば、業務プロセス上の統制がどれほど整っていても、財務データの信頼性は保証されません。不正リスクの観点からは不正リスクと内部監査｜不正のトライアングルとレッドフラグもあわせてご覧ください。
「使わせない」ではなく「記録して確かめる」
システムの保守には特権IDが欠かせないため、使用そのものを禁じることは現実的ではありません。そこで一般的なのは、次の4つを組み合わせる統制です。
- 保有者の限定：特権IDを使える人を必要最小限にし、一覧で管理する
- 貸出管理：使用の都度、目的と時間を申請・承認し、パスワードを貸し出す（使用後に変更する）
- 操作ログの取得：誰がいつ何をしたかをログとして記録し、改ざんできない場所に保管する
- ログレビュー：特権IDの使用者から独立した人が、申請内容とログを照合する
特権IDの監査チェックリスト
| # | 確認項目 | 手続 | 不備の典型例 |
|---|---|---|---|
| 1 | 特権IDの一覧は完全か | システムから特権ロール保有者を出力し、管理台帳と照合 | 台帳にない管理者IDが存在する |
| 2 | 保有者は必要最小限か | 保有者ごとに業務上の必要性を確認 | 開発者が本番環境の管理者権限を常時保有 |
| 3 | 共有IDの使用者を特定できるか | 貸出記録と使用時刻の照合 | 「admin」を複数人で共用し、貸出記録がない |
| 4 | 貸出は承認されているか | 貸出記録からサンプル抽出し、承認と目的を確認 | 事後承認が常態化している |
| 5 | ログは取得・保全されているか | ログの設定と保管場所、アクセス権を確認 | 特権ID自身がログを削除できる |
| 6 | ログレビューは独立かつ実質的か | レビュー記録から、申請外の操作を検出・調査した実績を確認 | 使用者本人がレビューしている、確認印だけで調査の記録がない |
6番目の「実質的か」は見落とされがちな観点です。1年間のレビュー記録で指摘がゼロの場合、本当に問題がなかったのか、レビューが形式化しているのかを見極める必要があります。レビューに使ったログが全件か、申請との照合方法が決まっているかを確認します。
アクセス権棚卸の監査：「やった」から「効いた」へ
棚卸の2つの落とし穴
アクセス権棚卸（ユーザーアクセスレビュー）は、業務部門の責任者が自部門のメンバーの権限一覧を見て、不要な権限を削除するよう依頼する統制です。多くの企業が年1回以上実施していますが、監査では次の2点に注意が必要です。
一つ目は、レビューに使った一覧の完全性です。情報システム部が作った一覧からIDが漏れていれば、そのIDは誰の目にも触れません。これはITACとITGCの違いで触れたIPE（企業が作成した情報）の問題そのものです。二つ目は、レビューの精度です。数百行の一覧に一括で「確認済み」とだけ記入されている場合、責任者が一つ一つの権限を検討したとは言いにくくなります。
棚卸の監査手順と記入例
| 手順 | 確認内容 | C社での結果（架空のモデルケース） |
|---|---|---|
| 1. 一覧の完全性 | 棚卸用の一覧の件数を、同日時点のシステム上のユーザー数と照合 | 一覧412件、システム415件。差分3件はシステム連携用IDで、別途特権ID管理の対象であることを確認 |
| 2. レビュー者の適切性 | レビュー者が対象メンバーの業務を理解している責任者か | 各部長がレビュー。情報システム部の管理者IDは情報システム部長が自己レビューしていたため、経理部長による確認を追加するよう提言 |
| 3. レビューの精度 | 削除・変更の判断が記録されているか、権限の意味が理解できる形で提示されているか | 権限名がシステム内部のコード表記で、業務部門が意味を判断しにくい状態。権限の説明列の追加を提言 |
| 4. 是正の完了 | 削除依頼が実際にシステムに反映されたか | 削除依頼17件のうち17件の反映をシステム上で確認 |
| 5. 適時性 | 規程で定めた時期に実施されたか | 年1回（2月）実施、規程どおり |
手順4を省略する監査は少なくありませんが、削除を依頼しただけで実際には消えていない例もあります。依頼と反映の両方を確かめて初めて、棚卸が「効いた」と言えます。
レビューを実質化する工夫
棚卸の精度を上げるには、レビュー者の負担を減らす設計が有効です。前回からの差分（新たに付与された権限）だけを重点的に確認させる、高リスクの権限（承認、マスタ変更、支払データ作成）に色を付ける、長期間ログインのないIDを別表にする、といった工夫です。内部監査部門がこうした改善を提言することは、統制の有効性を高めるうえで価値のある貢献になります。
SaaS・SSO時代のアクセス管理
SSOで「一元化」したつもりの落とし穴
シングルサインオン（SSO）を導入すると、認証基盤（IDプロバイダー）でIDを無効化すれば、連携する各SaaSにもログインできなくなります。退職者対応の効率は大きく上がりますが、次のような抜け道が残ることがあります。
- SSOを経由しない、SaaS上のローカル管理者アカウント
- APIキーや連携用のトークン（SSOの無効化では失効しない場合がある）
- SSO導入前から存在する個別ID
- 取引先や委託先に発行したゲストアカウント
したがって、SSOを導入していても、主要なSaaSについてはSaaS側のユーザー一覧を直接出力し、認証基盤の一覧と照合する手続を残しておくのが安全です。ID連携の自動化（SCIMなどのプロビジョニング）を使っている場合も、連携の対象外となるアカウントの有無を確かめます。
SOC報告書のCUECとの関係
SaaSのSOC報告書には、利用者側で実施すべき統制（CUEC）として、ユーザーの付与・削除や権限の定期見直しが記載されていることがほとんどです。つまり、SaaSのアクセス管理はSOC報告書の対象外で、自社の統制として評価する必要があります。SOC報告書の読み方はITGC（IT全般統制）とは？クラウド時代の評価ポイントとSOC報告書の見方で詳しく解説しています。
よくある失敗と対策
失敗1：退職者一覧の完全性を確かめずに突合する
人事部から受け取った一覧をそのまま使うと、契約社員、派遣社員、出向者などが漏れていても気づけません。人員報告や給与データなど、別の情報源と件数を照合してから突合します。
失敗2：「IDは無効化済み」で終わらせる
期限超過のIDを見つけても、無効化されたことだけを確認して終わる例があります。退職後にログインがあったか、あればどんな操作が行われたかまで確認しなければ、財務報告への影響を評価できません。
失敗3：特権IDのログレビューを使用者本人が行っている
小規模なIT部門では、管理者が自分の操作ログを自分でレビューしていることがあります。独立性が確保できない場合は、業務部門の責任者や内部監査部門がレビューに加わる、申請との照合だけを別の担当者が行う、といった代替策を検討します。
失敗4：棚卸の依頼と反映を突き合わせていない
削除依頼の記録だけを見て有効と判断するケースです。依頼とシステム上の反映を照合する手順を監査プログラムに組み込みます。
失敗5：SSOの一覧だけで全SaaSを評価したつもりになる
ローカルアカウントやAPIキーは認証基盤の一覧に現れません。主要なSaaSは個別の一覧で確認します。
よくある質問
Q1. 退職者IDの削除期限は何日以内が適切ですか？
実施基準に日数の定めはなく、自社のリスクに応じて規程で定めます。社外から接続できるシステムや、支払・承認権限を持つIDは短い期限が求められます。監査では、規程の期限が守られているかと、期限そのものがリスクに見合っているかの両面を評価します。
Q2. 共有ID（複数人で使うID）は一切認められないのですか？
システムの制約で共有IDが避けられない場合もあります。その場合は、貸出記録によって特定の時刻に誰が使っていたかを説明できるようにし、パスワードを使用後に変更する運用が考えられます。業務システムで承認操作を行うIDは、承認者の特定が統制の前提になるため、個人IDを使うのが原則です。
Q3. アクセス権棚卸は年1回で十分ですか？
多くの企業で年1回以上とされていますが、適切な頻度はリスクによって変わります。異動や退職の統制が有効に機能していれば、棚卸は補完的な役割となり、年1回でも十分なことがあります。逆に、入退社や異動時の統制に不備が多い場合は、頻度を上げることを検討します。最終的には自社と監査人の判断になります。
Q4. 小規模な会社で特権IDを持つ人が1人しかいない場合はどうすればよいですか？
職務分離が難しい場合は、発見的な統制を強化します。特権IDの操作ログを月次で出力し、IT部門以外の責任者が申請や作業報告と照合する、データベースの直接修正の件数と内容を経理部門に報告する、といった方法です。自社のアクセス管理の成熟度はITGC簡易診断のアクセス管理領域（5設問）で確認できます。
まとめ
アクセス管理の監査は、「誰が何をしたか」を説明できる状態が保たれているかを確かめる作業です。権限は放っておけば増え続けるため、入社・異動・退職の各時点の統制と、定期的な棚卸の両方が必要になります。監査手続の要点は、退職者の全件突合、特権IDの記録と独立したレビュー、棚卸に使った一覧の完全性とレビューの精度、の3つです。
次の一歩として、まず主要な財務システム1つを選び、退職者一覧との全件突合を試してみてください。半日ほどで終わり、アクセス管理の実態が一目で分かります。IT全般統制全体の弱点はITGC簡易診断で把握できます。関連記事としてITGCとSOC報告書の見方、サイバーセキュリティ監査の進め方もご覧ください。
アクセス管理の監査設計や手続の見直しについて支援が必要な場合は、お問い合わせからご相談ください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日）https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日）
- ISO/IEC 27002:2022「Information security, cybersecurity and privacy protection — Information security controls」
- NIST SP 800-53 Rev.5「Security and Privacy Controls for Information Systems and Organizations」
- IIA「Global Technology Audit Guide（GTAG）」シリーズ
