退職者のアカウントを、人事の手続きに組み込んで確実に止める仕組み

「退職の手続きは総務がやってくれているはずだから、アカウントも消えているだろう」——情報システムの担当者が退職者対応でいちばん陥りやすいのが、この思い込みです。総務や人事は、給与の締め、社会保険の手続き、貸与物の回収リストを持っています。しかし「この人がどのクラウドサービスに、どのメールアドレスで、どの権限で入っていたか」という一覧は、たいていどこにも存在しません。

存在しない一覧は、消しようがありません。

退職者のアカウントが残ること自体は、珍しい話ではありません。悪意があって放置されているわけでもなく、たいていは誰も気づかなかっただけです。ただ、気づかれないまま数か月、数年と残り続けたアカウントは、社内の誰にとっても存在しないのと同じものになります。使う人がいない、思い出す人もいない。厄介なのはその先で、思い出す人がいないアカウントほど、外から使われたときに気づかれるまでの時間が長くなります。

この記事で扱うのは、退職者のアカウントを確実に止めるための仕組みを、情報システム担当者の努力ではなく、人事の手続きの側に組み込む形で設計する方法です。前提は一つだけ。情シスは、退職を知らされて初めて動ける。ここに立つと、対策の起点が情シスの注意力ではなく人事の側にあることが見えてきます。

放置されたアカウントは、静かに開いたままの正規の入口になる

退職したご本人に、会社へ不利益を与える意図はまずありません。ほとんどの場合、その人はもう自社のことを気にかけてすらいないでしょう。問題は本人の意思ではなく、そのアカウントが「誰にも見られていない、正規の入口」として残り続けてしまうことにあります。退職者のIDとパスワードが外部に流出し、第三者の手に渡ってしまえば、それは本人の意図とは無関係に、会社のシステムへ入るための正規の鍵として機能します。

厄介なのは、退職者のアカウントによるアクセスが不審に見えないことです。現職の社員であれば、深夜のログインや普段と違う場所からのアクセスは目立ちます。ところが退職者のアカウントは、そもそも誰も日常的にログイン状況を確認していません。業務時間外に動いていても、違和感を覚える人がいないのです。ログの記録自体は残っていても、それを見る人がいなければ、記録は起きたことを事後に説明する材料にしかなりません。

もう一つ見落とされがちなのが、退職者のアカウントが「取引先や顧客からの信頼」を裏書きに使われる場合です。退職者名義のメールアドレスからやり取りが再開されれば、受け取った側は違和感なく応じてしまいます。アカウントの持ち主がすでに社内にいないという事実は、外部からは見えません。見えないからこそ、放置されたアカウントは「本人が知らないところで、本人の信用を使われ続ける」入口になります。

そして、この危うさは時間が経つほど大きくなります。在職中であれば、パスワードは定期的に変わり、権限は異動のたびに見直される機会があります。ところが退職者のアカウントは、その日で更新が止まります。周囲の設定だけが新しくなっていき、そのアカウントだけが当時のまま取り残される。「昔のことだから、もう関係ないだろう」という感覚とは逆に、古いアカウントほど手当てされていない可能性が高いのです。

なぜ、アカウントは自然には止まらないのか

退職者のアカウントを止め忘れる会社は、担当者の意識が低いわけではありません。むしろ真面目に運用しているつもりの会社ほど、仕組みの隙間に気づかないまま同じ抜け漏れを繰り返します。原因は、たいてい次の四つのどれかに当てはまります。

退職の情報が、情シスに届いていない

退職の話は、まず本人と上長、そして人事の間で進みます。情報システム担当者がこの輪に入っていない会社は少なくありません。人事にとって「アカウントを止める」は自分たちの仕事だという意識が薄く、情シスにとっては言われなければ分からないことです。どちらも悪気はないのに、誰も伝えなかったという結果だけが残ります。

どこにアカウントがあるか、誰も把握していない

社内で使っているクラウドサービスの数は、担当者が思っているよりも多いのが普通です。部署ごとに契約したサービス、個人の判断で使い始めたツール、終わったプロジェクトのために作られたまま残っているアカウント。これらは情報システム部門の管理台帳に載っていないことが珍しくありません。載っていないものは、退職時の確認対象にも入ってきません。

業務が止まるのが怖くて、消すに消せない

「このアカウントを止めたら、動いている何かが止まるかもしれない」。情報システム担当者なら、一度は感じたことがあるはずです。夜間の自動処理がそのアカウントの権限で動いている、外部サービスとの連携がそのアカウントのトークンにぶら下がっている。実際に起こります。そして確認には手間がかかるので、止めるという判断そのものが先送りされます。

共有アカウントは、そもそも「誰かが辞めた」という出来事に反応しない

個人に割り当てられたアカウントであれば、退職という出来事がきっかけになります。しかし複数人で使い回している共有アカウントは、特定の個人の退職とひも付いていません。その人が知っていたパスワードは、その人が辞めても誰も変えようとしないまま、ずっと有効であり続けます。これは後ほど改めて取り上げます。

情シスの努力ではなく、人事の手続きに組み込む

対策の設計は、情シスの警戒心を高めることではなく、人事がすでに持っている手続きの中に、情シスへの連絡を組み込むことから始めます。ここまで挙げた四つの原因は、どれも「情報システム担当者がもっと注意していれば防げた」という話ではないからです。情シスは、退職という出来事そのものを知らされない限り、動きようがありません。

具体的には、退職に関わる三つの日付を、決まったタイミングで情シスに渡す流れを作ります。一つ目は「退職の意思表示があった日」、つまり退職届が受理された日で、この時点で停止の準備に入れます。二つ目は「最終出社日」。実際にアカウントを止めるべきなのは、多くの場合この日であって、退職日ではありません。三つ目が「退職日」で、雇用契約上の最終的な失効日にあたります。

この三つを分けて考える理由は、業務の実態と契約上の区切りが一致しないからです。最終出社日を過ぎれば、その人はもう社内の誰とも直接やり取りをせず、システムを使う正当な理由もなくなります。それでも退職日まで、有給休暇の消化期間をまるごとアカウントが生きたままになっている会社は、意外なほど多く見受けられます。理由を尋ねると「まだ在籍しているので」という説明が返ってきます。けれど、在籍していることと、システムを使う必要があることは、本来まったく別の話です。停止の判断基準を「在籍しているかどうか」から「業務上アクセスする必要があるかどうか」に置き換えるだけで、対応すべきタイミングは自然と最終出社日に寄っていきます。

仕組みといっても、新しく作るものはありません。人事がすでに使っている退職手続きのチェックリストに、「情シスへ三つの日付を連絡する」という一行を足すだけで成立します。新しい会議体も、新しい申請フォームも要りません。既存の手続きの通り道に、宛先を一つ増やす。それだけです。

落とし穴はむしろ対象範囲の方にあります。派遣社員、業務委託、インターン、そして役員。同じ組織のシステムに入っている以上、同じ流れに乗せます。ところが実際には、雇用契約の枠組みが異なるために、人事の退職手続きとは別のところで契約が終了し、情シスへの連絡だけが抜け落ちます。契約形態が違っても、アカウントを止めるという行為の重さは変わりません。むしろ、社外の人が持っていたアカウントの方が、止め忘れに気づかれるまでの時間は長くなります。

何を止めるか——停止のチェックリストで網羅する

人事から三つの日付が届いたら、次は「何を止めるか」です。頭の中だけで思い出そうとすると、必ず何かが抜けます。あらかじめ項目を固定したチェックリストにしておき、退職者ごとに上から機械的に潰していく形にします。

表の中でいちばん見落とされやすいのが、連携アプリのトークンです。あるサービスから別のサービスへアクセスするために発行される、パスワードの代わりとなる認証情報で、退職者本人のアカウントを介して許可された連携は、本人のアカウントを止めても自動的には切れないことがあります。本人が便利さのために個人の判断でつなげたものほど、この一覧から漏れます。許可した記録が残っていなければ、チェックリストの項目として確認しようがありません。どのサービス同士が連携しているかを日頃から把握しておくことが、退職時の確認を実のあるものにします。

なお、このチェックリストは「今どこに何があるか」が分かっている前提の話です。そもそも自社がどんな機器やサービス、権限を保有しているかという台帳の整備そのものは、別の記事で扱っています。台帳が整っていなければ、ここに並べた項目の多くは「確認できない」で止まってしまいます。

共有アカウントと外部委託先という、二つの抜け穴

個人に割り当てられたアカウントは、ここまでの仕組みで止められます。残るのは、特定の個人に結びついていないアカウントです。代表が共有アカウントで、複数人が同じIDとパスワードを使い回している状態を指します。店舗の共通端末、部署の代表メールアドレス、古くから使われている外部サービスの管理者アカウントなどが典型です。共有アカウントは、誰が辞めても「誰かが辞めた」という出来事そのものに反応しない構造になっています。退職した人が知っていた合言葉は、その人が辞めた後もずっと有効なままです。

この構造を根本的に解く方法は、共有アカウントをできる限り個人アカウントに寄せることです。一人ひとりが自分のアカウントでログインし、それぞれの権限で必要な範囲にアクセスする形にできれば、退職時の処理は個人アカウントの停止と同じ手順で済みます。個々の認証を一つの基盤にまとめて管理できれば、この移行はさらに進めやすくなります。

とはいえ、どうしても共有アカウントとしてしか運用できないものは残ります。その場合は「消せない」で終わらせず、少なくとも年に一度は棚卸しをして、誰が合言葉を知っているかを確認し、退職者が出るたびに変更する手順をあらかじめ決めておきます。手順が決まっていなければ、変更作業そのものが「いつか誰かがやること」として先送りされ続けます。

もう一つの抜け穴が、外部委託先が持っているアカウントです。システムの保守や開発を委託している会社の担当者に、自社のシステムへのアクセス権限を渡しているケースは珍しくありません。契約が終了したタイミングで止めるのが原則ですが、実際にはもう一段厄介な問題があります。委託先の担当者が交代しても、その情報は自社には伝わってこないという前提を置かなければならないことです。委託先の中でその人が異動しても退職しても、自社側からは見えません。契約終了時の停止と合わせて、定期的な棚卸しの中でこうしたアカウントを拾い上げる運用が要ります。契約書に、担当者交代時の通知義務やアカウント停止の条件を明記しておくことも、あわせて検討する価値があります。契約や委託先管理の相談はこちらから承っています。

止めるだけでなく、「止まったこと」を確認する

停止の操作をした「つもり」と、実際に止まっている状態との間には、思っている以上に差が生まれます。権限が複数の階層で付与されているサービスでは、上位の設定を止めても下位の個別設定が残ることがありますし、反映に時間がかかるサービスでは、操作した直後の確認では「止まっていない」ように見えることもあります。

最後の一手は、停止操作のあとに、実際のアカウント一覧を出力して突き合わせることです。「止めたつもり」のリストと、システム側が示す「実際に有効なアカウント」の一覧を並べて、差分がないかを見る。退職者が出るたびの作業として組み込んでおきます。

個別の退職対応とは別に、定期的な棚卸しの仕組みも持っておきます。四半期に一度、在籍者の名簿と、各サービスのアカウント一覧を突き合わせる運用です。個別対応をどれだけ丁寧に組んでも、手順そのものから漏れた退職者や、そもそもチェックリストに載っていなかったサービスは、この定期の突き合わせでしか見つかりません。個別対応が「そのつど止める」仕組みだとすれば、定期棚卸しは「止め忘れを見つける」ための、性質の異なるもう一つの仕組みです。

この突き合わせは、専任の担当者がいなくても回せます。人事が持つ在籍者名簿と、情シスが持つアカウント一覧を、決まった時期に照らし合わせるだけの、単純な作業だからです。むしろ大がかりな仕組みを新しく導入しようとすると、準備に時間がかかり、結局始まらないまま先送りされます。

棚卸しを続けていくと、名簿とアカウント一覧のどちらか一方だけでは気づけなかった食い違いが見えてきます。名簿にはいない人のアカウントが残っていた、在籍しているはずの人のアカウントがなぜか見当たらない。こうした食い違いは、仕組みのどこかに抜けがあることを示すサインでもあります。一度の棚卸しで完璧にしようとするのではなく、繰り返すたびに抜けを一つずつ塞いでいくものだと捉えておくと、運用として長続きします。人事の手続きへの組み込み方や、定期棚卸しの設計について具体的に相談したい場合はお問い合わせください。

参考になる公的資料

• 情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン」
• 経済産業省・IPA「サイバーセキュリティ経営ガイドライン」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」
• NISC「サイバーセキュリティ関係法令Q&Aハンドブック」