なぜ古いアクセス権は、業務が終わっても残り続けるのか

古いアクセス権は本来の目的を終えた後も残り続けますが、これを監視している組織はほとんどありません。新しいアクセス権は、申請から1日以内に付与されます。一方、古いアクセス権が取り消されるのは、仮に取り消されるとしても、誰かが促したときだけです。従業員によるサービスアカウントの確認、ローテーション、保管（ボールト化）を支援するツールに携わるなかで、私は何度も痛感してきました。アクセス権の削除は、付与と同じくらい慎重に設計しなければなりません。セキュリティ担当者は、異動時のポリシーとアクセスレビューを少し見直すだけで、この溝を埋められます。

こうした事態は日常的に起きています。ある従業員が別のチームへ異動します。新しい上長は、新しい役割に必要なアクセス権を1日以内に承認し、本人は昼までには戦力になります。ところが、以前の役割のアクセス権は残ったままです。数か月後のアクセスレビューで問われるのは、「まだ必要ですか」という一点だけです。レビュー担当者には権限の横に本人の名前が見えますが、異動後に使われたかどうかはダッシュボードに表示されません。何かが動かなくなるかもしれないので、「いいえ」は押しにくいものです。一方、「はい」を押して困ったことはありません。結局、「はい」を押し、それで済んでしまいます。

なぜ付与は簡単なのに、削除は難しいのか

付与には担当者と期限があります。上長が申請し、承認者が「はい」を押せば、人が関わっているため、ほんの数時間で処理が完了します。削除にはこの2つがありません。権限が不要になっても、誰もチケットを起票しません。気づくのは本人だけで、起票する理由がないからです。権限を残しておくコストは大きいのですが、目に見えず、発生するのも将来です。インセンティブも同じ構図です。チームが保持するアクセスレベルがどれだけ低いかを評価する人はいません。一方、誤って削除した権限が必要になれば、その日のうちに怒りのサポートチケットが届きます。

本来はレビューで対処すべき問題ですが、私の見るところ、実際にはそうなっていません。私が関わったあらゆる認証（アテステーション）や再認定の作業でも、レビュー担当者への問いは基本的に「このアクセス権はまだ有効か」だけでした。「はい」と答えるのは難しくありません。アクセス権は付与済みで、その後に何も起きておらず、数百件をまとめて確認するほうが、特定の1件を調べるより短時間で済むからです。画面に表示されるのは、そうした判断材料ではありません。アカウント名を見ているだけでは、先週使われたのか、1年前なのかが分かりません。

ロールベースアクセス制御（RBAC）は有効ですが、ユーザーが役割を変えたとき、更新されるのはロールだけです。その間に取得した直接のアクセス権、グループ、フォルダーは更新されません。

残ったアクセス権の代償は何か

この点は慎重に述べる必要があります。この指標は、残存するアクセス権そのものを反映したものではないからです。2026年版Verizonデータ漏えい/侵害調査報告書（DBIR）によると、脆弱性の悪用が侵害で最も多く使われた手法で、全体の31%を占めました。以前トップだった認証情報の悪用は13%に低下しています。ただし、このレポートは古い権限の問題とは無関係であることを強調しておきたいと思います。それでも、侵入者がシステムに入り込んだ後に何ができるかは、侵害されたアカウントの権限によって決まります。その権限は、蓄積された権限の数に左右されます。実務では、監査や調査の指摘事項が延々と続く形で表れます。社内データへのアクセスを誰に許可すべきなのか、正確に把握している人がいないためです。

とはいえ、退職者のケースを裏付ける情報はあるものの、ごくわずかです。たとえば、2023年3月に米国の労働者1,000人を対象に実施されたPasswordManager.comの調査では、以前の勤務先のパスワードを使ったことがあると答えた人の58%が、退職後にパスワードを一度も更新していなかったと認めています。これはオンラインで実施された意識調査であり、あくまで目安です。私自身も同じことを実感しました。退職者は人事のオフボーディングチェックリストを通りますが、長年にわたって多くの人が作成してきた権限や証明書は、その対象になりません。

異動はさらに大きな問題ですが、研究は多くありません。退職の場合は、少なくともオフボーディングのプロセスが始動し、何かが起こります。異動では何も始動しません。だからこそ、異動は退職と同等に重視すべきだと私は考えています。標準規格がまさにそれを求めているからです。組織で広く使われているセキュリティ・プライバシー管理策のカタログNIST SP 800-53 Rev. 5には、アカウント管理（AC-2）と最小権限（AC-6）の管理策があります。これらは、アカウントのレビュー、異動と退職の処理、個人の役割に必要な権限のみの付与を求めています。

残存アクセスを放置できなくする3つの対策

ここからは、変更を確実に定着させる方法を紹介します。新しい技術を導入する必要はありません。必要なのは、削除プロセスの責任者を決めることだけです。

1. あらゆる異動を「削除イベント」として扱う

まず、システム上の人事記録を起点にします。異動が発生したら、異動元と異動先の双方の上長にタスクを生成し、答えてもらう質問は1つだけにします。「この人が今後不要になるものは何か」です。アクセス権の一覧を示し、回答までの時間は10分とします。この期間に本人が作成したアクセス権には、すべて所有者を付ける必要があります。3つの対策のうち1つしか実施できないなら、これを選んでください。

2. すべての権限に固有の所有者と有効期限を設定する

プロジェクトフォルダーへのアクセス権、特別な権限、本番システムへのアクセス権には、特定の有効期限を設けるべきです。期限は、プロジェクトの終了日とするか、デフォルトでは付与から3か月後とし、所有者が更新しない限り失効させます。所有者はメールアドレスではなく、実名の個人でなければなりません。私は、アカウント、所有者、アカウントがアクセスするアプリケーションをグラフとして捉えています。アカウントに変更があれば、1回のクエリで、その人が何を所有し、何に依存しているかを割り出せるからです。更新はワンクリックで行えるようにします。ただし、その人が不在になった場合は上長を通じて更新し、見落としを防ぎます。これがデフォルト設定です。現状では、何もしなければ権限はそのまま残ります。つまり、怠慢が危険な道になっています。権限の更新をデフォルトの操作にしてはいけません。

3. すべてのレビューに最終使用情報を表示し、その場で対処できるようにする

IDプロバイダーとアプリケーションログから最終ログインと最終アクティビティのタイムスタンプを取得し、各権限と並べて表示します。使用頻度が最も低いアクセス権を一覧の先頭に並べて削除対象として選択状態にし、残す場合はレビュー担当者に理由の説明を求めます。経験上、「この権限は7か月間使われていません」と画面に表示されれば、人は喜んで確認してくれます。そのうえで、最善と考える対応を取れるようにします。アテステーションを1つのツールで行い、ローテーションや保管（ボールト化）を別のツールで行うと、確認だけして実際の対応を飛ばす人が出てきます。そのため私は、アクセス権のアテステーション、ローテーション、保管、廃止を1つのプロセスにまとめるようにしました。ただし、この方法には限界があることも覚えておいてください。すべてのアプリケーションが利用ログを保持しているわけではなく、使用頻度は低くても正当なアクセスもあります。四半期決算用のアカウントや、緊急用（ブレークグラス）アカウントが一例です。こうしたアカウントには、所有者とメモを割り当てておくべきです。

従業員は、自分にもう必要ないものを把握できます。ただし、それが機能するのは、安全かつ簡単に対応できる仕組みがある場合に限られます。これが、上記3つの対策を実施すべきもう1つの理由です。

今四半期は、機密データを保管している1つのシステムから始め、そのシステムで最終使用レポートを実行してください。最初に対象とするのは、過去1年以内に別の役割へ異動したユーザーです。それ以降、誰も彼らのアクセス権をレビューしていないからです。過去6か月間にそのシステムを使っていないユーザーの一覧をシステム所有者に送り、シンプルな質問を1つだけ投げかけましょう。「これはまだ必要ですか」。その結果だけで、どんなフレームワークよりも説得力をもって、他のシステムへの展開を後押しできるはずです。