認証の強さと権限の妥当性は別
ログイン時の本人確認が強くても、退職・委託終了後のアクセスや過剰な権限が自動で整理されるとは限りません。認証と認可を分けて考えます。
MicrosoftのEntra監査ログ資料では、ユーザー、グループ、アプリ等の変更を調べられると説明されています。サインイン履歴と管理上の変更履歴は別の用途です。ここではその考え方を、サービスごとの点検へ応用します。
一覧と「あるべき状態」を突き合わせる
- 権限を持つ管理者が、利用者・管理者・ゲスト・連携用アカウントの一覧を取得する。
- 業務担当が、承認された利用者、役割、終了予定と照合する。表示名だけで同一人物と判断しない。
- 覚えのない追加、終了後の有効状態、不要な管理者を抽出する。
- 追加・再有効化・権限変更の日時と実行者を監査履歴で確認する。
- 許可された変更か、申請と管理担当の確認を合わせる。不審なら通常の整理からインシデント対応へ切り替える。
これらは当サイトの点検手順例です。画面名・エクスポート方法・必要権限は提供元資料で確認します。必要以上の権限を点検者へ付与する前提にはしません。
架空例：停止したはずの委託アカウント
架空の保守サービスで「委託作業用B」が作業終了後も有効だったとします。契約延長、別システムからの自動同期、操作ミス、不正な再有効化などを候補として分けます。名前が残っているだけで悪意ある操作とは断定しません。
確認するのは、終了依頼、現在の状態、再有効化の記録、実行者、変更後の利用です。業務上必要なら、用途と終了日を改めて承認します。不要なら依存する処理と復旧経路を確認して是正します。誰が操作したか分からない場合は、未確認のまま責任者へ引き継ぎます。
人のアカウントだけで終わらせない
- 管理者が承認した外部アプリは何にアクセスできるか。
- 定期実行・API連携の所有者と業務用途が分かるか。
- 人の退職やアカウント停止で、連携がどうなるか確認されているか。
- 不要な連携を止める担当と、業務への影響を調べる資料があるか。
画面に出るトークンの値や秘密鍵を点検台帳へコピーする必要はありません。名称、用途、所有する役割、権限範囲、確認日を記録します。連携が別の保存先へデータを送るなら、その先も対象です。
一斉削除・停止を先にしない
連携用アカウントを止めると請求やバックアップが止まることがあります。一方、進行中の不正利用が疑われるときに通常の保守日まで待つのも適切ではありません。責任者と影響・緊急性を判断し、証拠保全と被害拡大防止を並行します。
アカウント停止だけで既存セッションや全サービスのアクセスが必ず止まるとは書けません。提供元の公式手順でセッション・トークン・他システム同期の扱いを確かめ、変更後に対象のアクセスと業務動作を確認します。
次回の点検を楽にする記録
対象、用途、あるべき権限、変更日時、申請の根拠、確認結果、未確認事項、次の見直し条件を残します。退職・異動・委託終了・連携変更の際に見直せる運用にすると、月末の一斉点検だけに頼らずに済みます。最小権限の利点は、正当な利用を維持しながら触れられる範囲を減らすことです。侵害がないことの証明にはなりません。