退職した人のパソコンを回収しても、クラウドやVPNのアカウントが使えるまま残ることがあります。異動した人が以前の部署の資料を開ける場合もあります。人の在籍や仕事が変わったときに、IDと権限を確実に変更する手続が必要です。
今回は、IDの付与・変更・削除の申請と承認、共有IDの利用者の特定、不要なIDと権限への対応を説明します。ユーザIDは利用者を識別するための情報、アクセス権はその利用者が見たり操作したりできる範囲です。両方を分けて考えると、異動時の作業が明確になります。
図1 今回扱う全4基準 申請承認と利用者の特定と不要時の対応
本稿では、サービスを利用するための登録を「アカウント」と呼び、その利用者を識別するIDや権限を管理の対象として説明します。メール、ファイル共有、業務システム等、実際に使うサービスごとに確認します。
退職者のVPNアカウントが悪用された公表事例
ワイエイシイガーターは、2026年3月26日の続報で、ランサムウェア被害の原因として、退職者のVPNアカウントを悪用した不正アクセスと、侵入検知の遅れによる被害拡大を公表しました。VPNは、社外から社内環境等へ接続する際に使われる仕組みです。
この事案の異常検知は2025年11月25日未明です。親会社のワイエイシイホールディングスが翌26日に発表しており、2026年3月は原因等を公表した続報の時点です。攻撃の発生時期と報告日を混同しないようにします。
| 確認できること | 公表資料の内容 |
| 悪用されたもの | 退職者のVPNアカウント |
| 分かっていないこと | VPNアカウントの認証情報が流出した原因 |
| 確認された影響 | 社内サーバーへの不正アクセスとランサムウェア感染によるシステム障害 |
| 漏えいの評価 | 持出しの明確な証跡は確認されず、漏えいの可能性は完全には否定できない |
同社は、認証情報が流出した原因は判明していないとしています。退職者本人が攻撃した、退職時の削除忘れが公表された、VPN製品の脆弱性が原因だった、と読み替えることはできません。表は公表内容を整理したものです。
人が退職したこととログインできないことは別に確認する
この事例から自社の運用を考えると、退職届の処理や端末回収に加え、使っていたサービスでIDが使えなくなったかを確かめる必要があります。社内システムだけでなく、社外から使えるクラウドやVPNにも、停止の対象があるためです。
例えば、人事担当が退職を把握していても、サービス管理者に連絡が届かなければ、設定変更へ進めません。連絡が届いても対象サービスの一覧がなければ、一部のIDが残るおそれがあります。これは本稿の実務上の考察であり、当該企業でそのような連絡不備があったと述べるものではありません。
不要なIDを停止する意味
不要なIDを使えなくしておけば、そのIDの認証情報を入手した第三者による利用を防ぐための対策になります。ID停止だけであらゆる侵入を防げるわけではありませんが、業務上の必要がなくなった接続手段を残さないことは、自社で整えられる管理です。
4-1-1-1 付与と変更と削除を申請承認制にする
一つ目の基準は、自社の役員、従業員、派遣社員、受入出向者に対するIDの付与・変更・削除を、申請・承認制にすることです。新しいIDの発行だけでなく、内容を変えるとき、不要なIDを削除するときも対象になります。
図2 申請と承認を設定作業へつなぐ実務例 担当を必ず四人に分けるという意味ではない
申請には、誰が、どのサービスを、何のために使うかを示します。公式解説書は、必要となった理由、承認者、承認日等の記録や、本人以外の上司等による申請確認を望ましい方法として示しています。
| 場面 | 申請で示す内容の例 |
| 入社や受入れ | 対象者、所属、利用目的、必要なサービス、利用開始日 |
| 異動や担当変更 | 変更理由、不要になる権限、追加する権限、変更時点 |
| 退職や業務終了 | 対象者、対象IDとサービス、最終利用時点、引継ぎの要否 |
紙の申請書や特定の製品が必須ということではありません。公式ガイドは、ワークフローの記録や管理ツール等も「申請・承認」に含めています。 既存の仕組みを使う場合も、申請内容と承認結果が対応して分かる状態にします。
申請、承認、実施の担当を必ず別の三人にするとの一律規定は、この基準にはありません。組織の規模に合わせて担当を決め、誰の判断で何を変更するかを曖昧にしないことが大切です。
4-1-1-2 共有IDを使う場合も利用者を特定する
二つ目の基準は、IDを共有しないこと、または、やむを得ず共有が必要な場合に実際の利用者を特定できるようにすることです。公式ガイドは、システムの仕様で利用人数分のIDを発行できない場合を、やむを得ない事情の例に挙げています。
「営業部で使うID」と分かるだけでは、誰が使ったかの特定になりません。個人ごとにIDを発行できるなら、同じ権限を持つ個別IDを使う方法が考えられます。手間を省くために共有を広げるのではなく、個人単位で利用できるかを先に確認します。
図3 共有IDの利用者を特定する記録の考え方 利用可能者の一覧だけでは足りない
| 記録する内容の例 | 架空の利用記録 |
| 対象IDと利用者 | 旧業務システムの共通ID／利用者は山田太郎 |
| 利用した時間 | 2026年11月13日 9時10分から9時25分 |
| 作業と確認先 | 月次データの出力／作業日報とアクセス記録を対応させる |
アクセス管理簿や作業日報で利用実績を残す方法は、公式解説書の例です。同じ時間帯に複数人が利用して、記録から区別できない場合は、利用方法や記録の粒度を見直します。利用者の候補を挙げられることと、実際の利用者を特定できることは異なります。
共有する人が異動・退職等でそのIDを利用する必要がなくなった場合は、その人が使えない状態にします。共有パスワードの変更等は公式解説書が挙げる対応例です。利用可能者一覧を書き換えるだけで、認証情報を知る人の利用を止めたことにはなりません。
4-1-1-3 不要なIDを速やかに削除又は無効化する
三つ目の基準は、不要になったIDを速やかに削除又は無効化することです。退職した場合のほか、一定期間使用されなかった場合も例示されています。どのように不要と判断し、誰へ連絡し、どう対応するかを手続にします。
図4 不要なIDへの対応例 棚卸の日まで停止を待つ運用にしない
停止する時点と担当を具体化する
「速やかに」について、この基準は全社共通の何時間以内・何日以内という数値を定めていません。例えば、予定された退職では利用終了時点を事前に決め、申請・承認と実施担当への連絡を済ませ、必要な時点に停止する運用が考えられます。これは実務上の例です。
長期間利用がないIDも、利用部署に必要性を確認します。季節的な業務で必要なIDまで一律に削除するのではなく、用途、次の利用予定、責任者を確かめて判断します。未使用日数の一律のしきい値は、この基準では指定されていません。
引継ぎにデータが必要でも本人の利用は止める
退職者の作成資料を残す必要がある場合は、データの引継ぎとIDの利用停止を分けて考えます。製品の仕様に合わせ、IDを無効化して必要なデータを管理者が保管する等の方法を検討します。データを残すために本人がログインできる状態を続ける運用は避けます。
パスワードを変更しただけで、当該ID自体を削除・無効化したとは限りません。サービスの停止機能や権限設定を確認し、目的に合う操作を選びます。実施後に状態を確認する方法は、手続を確実に運用するための実務例です。
4-1-1-4 IDを残す場合も不要なアクセス権は外す
四つ目の基準は、IDに付与したアクセス権が不要になった場合、その権限を速やかに削除又は無効化することです。利用者の業務上の役割が変わる場合等が該当します。退職のようにID全体が不要になる場面とは、作業の対象が異なります。
図5 異動時にIDを継続する架空例 必要性を権限ごとに判断する
新しい権限を追加するときに古い権限も確認する
営業担当から別業務へ異動する人に、新しい仕事で使う権限だけを足すと、過去の権限が積み重なることがあります。異動後に必要なものと、不要になるものを対で確認し、旧業務の資料を引き続き見られる理由があるかを確かめます。
| 確認する場所の例 | 見落としを減らす確認 |
| 個人への直接付与 | 本人に個別付与した閲覧や編集の許可を確認する |
| 所属グループ | 旧部署や旧案件のグループから付く権限を確認する |
| 個別の共有先 | 共有フォルダーや資料に直接招待された権限を確認する |
表は実務例です。グループから外しても、個別の招待で同じ資料を見られる場合があります。どの経路で権限が付いているかはサービスにより異なるため、実際の設定を確かめます。
公式解説書は、重要なデータや機器を事前に抽出し、そのアクセス権を比較的高い頻度で見直すこと等を望ましい方法として示しています。ただし、この基準に一律の点検周期はありません。定期的な見直しを行う場合も、不要と分かった権限への対応を次の点検まで待たせないようにします。
人事の連絡を各サービスの設定変更までつなぐ
四つの基準を日々の業務へ組み込むには、入社・異動・退職の情報と、サービス管理者の作業を対応させます。人事担当、所属部門、システム担当が別々の場合も、連絡の受け手と完了を確認する人を決めておくと、処理の途中で止まった案件を見つけやすくなります。
退職予定者一人について確認する架空例
| 管理する内容 | 記入例 |
| 対象者と理由 | 山田太郎／営業部／退職に伴う利用終了 |
| 利用終了時点 | 2026年11月30日17時 この例で定めた時点 |
| 対象サービス | 会社メール、ファイル共有、顧客管理、VPN |
| 申請と承認 | 受付番号ID-2026-113／申請者、承認者、承認日時 |
| 実施担当と作業 | 各サービスの担当者／対象IDの無効化と不要権限の削除 |
| 結果の確認 | 実施日時、停止状態、確認者、残作業と担当を記録 |
この表は公式の必須様式ではありません。実際には、使っているサービスを漏らさず把握し、各サービスで対応結果を確認します。社員番号等で本人とIDを対応させておくと、同姓同名や表記揺れによる取り違えを減らせます。
一つのログインで使うサービスも停止結果を確認する
一つの認証で複数サービスを使う仕組みは、シングルサインオン、略してSSOと呼ばれます。まとめて管理していても、連携の設定、サービス側に残る個別ID、既にログインしている状態の扱いは製品によって異なります。認証元の停止が、必要な範囲へ反映されるか確認します。
各サービスの手順に沿って、必要に応じてログイン状態や連携の認証情報も失効させます。これは停止を実効性のあるものにするための実務例です。操作方法はサービスごとに異なるため、自社が使うサービスの管理画面や提供者の手順で確認します。
定期的な棚卸を日々の対応を補う作業にする
公式解説書は、ID管理部署から利用部署へ棚卸を依頼すること等を有効な方法として示しています。退職者が残っていないかだけでなく、利用者不明、用途不明、期限切れのIDや共有者を確認できます。棚卸の周期は自社で決め、この4基準に年1回等の一律義務があるとは扱いません。
入社・異動・退職時の対応で変化を反映し、棚卸で見落としを探す。この二つを組み合わせると、担当者の記憶だけに頼らず管理を続けやすくなります。
四つの評価基準と確認資料を対応させる
公式ガイドの自己評価方法は、ID管理規程、台帳、管理システム等によって、申請・承認や共有の扱い、不要時に対応する手続を確認する形です。全4基準とも、個別の対象外条件は「該当なし」です。
| 評価基準番号 | 自己評価で確認する内容 |
| 4-1-1-1 | 役員・従業員・派遣社員・受入出向者への付与・変更・削除を申請承認制にする規程等と、その文書名 |
| 4-1-1-2 | 共有しない手続、又はやむを得ず共有する場合に実際の利用者を特定できる手続の適用 |
| 4-1-1-3 | 不要なIDを速やかに削除又は無効化する手続を定めていること |
| 4-1-1-4 | 不要なアクセス権を速やかに削除又は無効化する手続を定めていること |
4-1-1-3と4-1-1-4の自己評価では、速やかに対応する手続の整備を確認します。一方、評価基準は実際の削除又は無効化を求めています。規程を整えた後も、対象の発生を把握し、定めた手続に沿って運用することが必要です。
申請・承認の履歴、共有IDの利用記録、停止後の管理画面等は、運用を説明する資料として役立ちます。これらを全サービス共通の指定様式として求めているわけではありません。既存の管理ツール等を使い、どの基準に対応するか分かるように整理します。
本日の確認
まず、付与、変更、削除のすべてに申請と承認があるかを確認します。対象を正社員だけに限定せず、役員、派遣社員、受入出向者も含めて手続を確認します。
次に、共有IDがある場合は、その必要性と、実際に誰が使ったかを特定する方法を確かめます。利用できる人の一覧と、利用した人の記録を区別して確認します。
最後に、退職した人と異動した人を一人ずつ例に取り、どのサービスのIDや権限を、誰が、いつ変更するかを手順で追ってみてください。IDを止める作業と、不要な権限だけを外す作業が、両方含まれているかが確認点です。
次回は強い権限を持つ管理者ID
11月14日は、4-1-2「管理者IDの管理手続」です。サーバーやネットワーク機器を管理する強い権限について、担当者の指定、権限の限定、申請・承認等の全8基準を説明します。
連載の関連項目とご相談
第1回は連載目次、第12回は3-1-4「機密区分に応じた情報の管理」です。認証の強度は第15回、アクセス権の付与は第19回でも扱います。今回は利用者の変化をIDと権限に反映する手続を整理しました。
ライトハウスコンサルタントでは、★3を見据えた現状確認や、規程・台帳・記録の準備を支援しています。利用しているサービスと人事の手続を照らし合わせ、IDの発行から利用終了までの管理を整理するお手伝いをしています。
