アクセス権の棚卸しは何を確認する？ 異動後の業務と引き継ぎの期限
営業から企画へ異動した社員が、以前の担当顧客の情報を今も編集できる。引き継ぎがあるからと権限を残したが、いつ終わるのかは決まっていない。棚卸しのメールに上司が「継続」と回答して、また半年が過ぎる。
これは説明のための架空例である。問題は、その社員を信用するかどうかではない。いま必要な仕事と、与えている操作範囲が対応しているかだ。人は同じでも、所属と役割が変われば、必要な権限は変わる。
本稿は、終了した仕事の権限は回収し、残る引き継ぎには対象・操作・期限を限った権限を与える。必要性が分からないものを、上司の一括承認で恒久化しないと提案する。特定製品の設定手順ではなく、情報を持つ部門と業務責任者が何を判断するかを扱う。
この記事の目次
アカウントが必要でも、昔の権限まで必要とは限らない
米国NISTのSP 800-53 Rev.5は、アカウント管理を人事上の退職・異動と連動させることや、権限の必要性を定期的に見直すことを扱っている。最小権限の考え方は、仕事に必要なアクセスへ範囲を合わせるものである。NISTの原資料：AC-2、AC-6(7)
これは統制の設計に関する米国の公的資料であり、日本企業で権限を何％減らせば事故が何％減るかを示す実験ではない。棚卸しの周期や解除までの時間も、あらゆる組織に同じ数字を指定するものとしては読めない。
この考え方を冒頭の例へ当てはめると、企画担当としてアカウントを使い続けることと、営業時代の全顧客を編集できることを分けられる。新しい仕事に必要な権限を付ける際、以前の役割をそのまま積み上げない。
上司に尋ねる内容も「このアカウントは要りますか」だけでは粗い。「どの仕事で、どの情報に、何の操作が必要か」なら、残す理由を照合できる。企画部の上司が営業の顧客情報を把握していない場合は、情報の責任者にも確認を求める必要がある。
引き継ぎを理由に残すなら、何を終えれば返すのか
仮に、異動後も前月の契約変更を一件だけ説明する必要があるとする。過去の契約を読むだけで足りるなら、全顧客の価格を変更できる権限を残す理由にはならない。対象の記録を確認できる方法へ狭めることを検討する。
条件を変え、旧担当として訂正入力まで行う責任が正式に残っているなら、閲覧だけでは仕事が終わらない。担当取引と必要な操作を定め、誰が完了を確認し、いつ解除するかを決めたうえで一時的に残す案がある。同じ異動でも、残る仕事が違えば判断は変わる。
ただし、画面上の権限を細かく分けられない場合もある。そのときは「システム上できない」で広い権限を無期限に残さず、現担当が訂正し旧担当が説明する、管理された代行手順を使うなど、別の業務配置を比較する。
これらは編集上の運用案であり、どの会社にも同じ対応を義務付けるものではない。機密性の高い情報や、金額を確定する操作は、残す範囲の妥当性を特に丁寧に確かめたい。引き継ぎの便利さだけで、他部署の情報へ広く触れられる状態を決めない。
「最近使っていない」だけで消すと、必要な仕事も止まる
棚卸しを効率化するため、利用履歴から不要な権限を探すことは考えられる。しかし、長く使っていないことと、不要であることは同じではない。年次の決算処理や非常時の対応のように、頻度の低い仕事もある。
例えば、平時に使わない復旧用の権限があるとする。履歴がないから削除するだけでは、必要なときに対応できなくなるかもしれない。一方、誰でも常時使えるまま残す必要があるとも限らない。利用の開始条件、使える人、終了後の確認を定めた仕組みを比較する。
反対に、頻繁に使われていても必要性が正当とは限らない。異動後も旧業務を個人的に手伝っているため、役割の整理が進んでいない可能性がある。履歴は事実の材料であり、継続承認の理由そのものではない。
そのため、本稿では利用実績と業務上の必要性を二つの欄で確認することを提案する。実績がなく必要性もなければ回収へ、必要性があれば通常権限か一時的な手段かを選ぶ。説明のない使用が続くなら、業務の分担と権限の両方を見直す。
中央の設定を変えただけでは、解除完了とは言えない
判断が適切でも、変更が対象のアプリへ届いていなければ意味がない。人事側で異動を登録した日、管理側で権限を外した日、実際に操作できなくなった時点は、同じとは限らない。
Microsoft Entra IDの公式資料は、アプリ自身が発行したセッションを、Entra IDから直接取り消せない場合を説明している。既存のアクセスがいつ終わるかは、アプリ側の認証・認可や連携の仕組みに依存する。中央での操作だけで、すべての利用先から即時にアクセスが消えるとは扱えない。Microsoftのアクセス取消しに関する説明
これは同製品の技術資料であり、すべてのサービスが同じ動作をするという意味ではない。本稿も、退職時の緊急対応手順を示すものではない。異動の通常運用で重要なのは、使っているサービスごとに変更がどこまで届くかを把握することだ。
例えば、共通ログインに連動する権限と、アプリ内で直接付けた権限が別にあるなら、一方だけを外しても後者が残る場合がある。権限表の更新を完了条件にせず、対象側の状態や、許可された検証方法で変更の反映を確かめる。
同時に、解除とデータ削除を混同しない。本人が操作できなくすることと、業務記録を保存・引き継ぎすることは別の判断である。過去の取引の説明に必要な記録まで失えば、アクセス管理の改善が別の業務障害を生む。
人の異動で、定期処理まで止めないために
もう一つ、引き継ぎで見落としたくないのが、その人のアカウントで動く定期処理である。仮に、旧担当の権限を使って毎朝集計しているなら、本人の仕事が終わっても処理は残る。権限を外す際は、この依存を確かめる必要がある。
だからといって、旧担当へ広い権限を残し続けることを結論にしない。処理の責任者と必要な操作を特定し、管理できる実行方法へ移す案を作る。人の異動と、自動処理の所有者変更を同時に進めるのである。これは本稿の運用提案で、個別環境の変更手順ではない。
変更後は、権限を回収できたことと、必要な集計が予定どおり動いたことを別々に確認する。処理が動くから旧権限も適切、権限を消したから引き継ぎも完了、のどちらとも扱わない。アクセスを減らす目的と、継続する仕事の責任を両立させる。
異動後に確かめたいのは、新しい職務の操作ができ、不要な操作はできないことです。閲覧を残す必要があっても、承認権限まで残す理由にはなりません。人の無効化と定期処理の継続を分けたうえで、セッションやトークンの失効は各アプリの実装に沿って確認します。 秘密変更と侵害対応
棚卸しの成果は、チェックの回収率だけでは測れない
上司から回答が戻れば棚卸し完了、という設計では、実際の解除や例外の期限切れが抜けやすい。回答した人、判断理由、変更する対象、実施結果をつなぎ、未完の権限変更を追えるようにする。
また、必要性が判断できない項目が大量にあるなら、上司の返答を督促する前に、役割名や権限の説明が分かるかを見たい。意味不明のグループ名を並べられても、業務責任者は必要性を判断できない。情報システム部門が、業務と操作の言葉へ対応させる仕事が残る。
改善の確認では、不要と決めた権限が残った件数、期限付きの例外が無期限になった件数、誤って解除して仕事を止めた事例を分ける。削除数だけを目標にすれば必要な権限まで消す誘因が生まれ、継続率だけを目標にすれば変更が進まない。
異動前の全権限を残すか、一括で消すかという二択にしない。終了した仕事からは返してもらい、残る仕事には必要な範囲だけを、終わりが分かる形で渡す。 棚卸しとは名簿に印を付ける行事ではなく、変わった仕事にアクセスの範囲を追従させる判断である。