退職者と前の委託先のアカウント棚卸し、業務システムで見落としやすい入り口

退職者のアカウント整理というと、多くの会社ではメールやチャット、グループウェアのアカウントを止めるところで終わります。人事から退職の連絡が来て、情シスが一覧を見ながら一つずつ無効にしていく。社員が使うサービスについては、それでかなりの部分が片づきます。

ただ、自社の業務システムを持っている会社だと、それだけでは足りません。システムを作った開発会社、保守していた会社、社内でサーバーを触っていた担当者。こうした人たちが使っていた入り口は、社員名簿にもSaaSの管理画面にも出てこないところにあります。他社が作ったシステムを引き継いでサーバーを調べると、誰が登録したのかわからない接続用の鍵や、何年も前に契約が終わった会社の名前が付いたユーザーが見つかることは珍しくありません。

この記事では、そうした「人の名前では探せない入り口」の棚卸しを、どこから手をつければいいかという順番で書きます。読んでいただきたいのは、エンジニアではないけれど、業務システムの面倒を見る立場になった発注担当や情シスの方です。

公的なガイドラインが求めていること

最初に、何を目指すのかを確認しておきます。

IPA（情報処理推進機構）の「組織における内部不正防止ガイドライン」は、異動や退職で不要になった利用者IDとアクセス権は「ただちに削除しなければならない」としています。雇用が終わったときだけでなく、請負などの契約先との契約が終わったときにも、与えていた利用者IDや権限を削除しなければならない、と書かれています。さらに、元役職員のIDや権限が削除されたことを確認すること、その削除は雇用終了直後に速やかに行うことが肝要だ、とも述べています（IPA 組織における内部不正防止ガイドライン）。

前の委託先も対象に含まれている、というのが大事なところです。同じガイドラインには、委託先の従業員が異動・退職したときに削除漏れが起きないよう、体制の変更を委託元に報告してもらう、という例も挙がっています。契約が終わった会社だけでなく、契約が続いている会社の担当者の入れ替わりも、棚卸しの対象になるということです。

顧客情報などの個人データを扱うシステムであれば、個人情報保護法のガイドラインも関係します。個人情報保護委員会のガイドライン（通則編）では、技術的安全管理措置として、アクセス制御と、アクセスする人の識別と認証を「講じなければならない」措置に挙げています（個人情報の保護に関する法律についてのガイドライン（通則編） 10-6）。もう関係のない人のIDが生きたままになっていれば、この措置が働いていない状態だと考えるのが自然です。

IPAの「情報セキュリティ10大脅威 2026」の組織編では、「サプライチェーンや委託先を狙った攻撃」が2位、「内部不正による情報漏えい等」が7位に入っています（IPA 情報セキュリティ10大脅威 2026）。前の委託先のアカウントは、この両方にまたがる話です。

人の一覧からではなく、入り口の一覧から始める

棚卸しというと、「退職者リスト」や「過去の委託先リスト」を作って、その人のアカウントを探しに行く進め方を思い浮かべるかもしれません。私たちは、業務システムについてはその逆をおすすめしています。先に入り口の一覧を作り、それぞれに誰がいるかを見ていく方法です。

理由は単純で、業務システムの入り口は、人の名前が付いていないことが多いからです。管理画面の「admin」、サーバーの「deploy」、データベースの「app_user」。開発会社が作業のために作った「test」というアカウントが、そのまま本番に残っていることもあります。退職者の名前で検索しても、こうしたものは出てきません。

もうひとつの理由は、共有アカウントの存在です。何人かで同じIDとパスワードを使っていた場合、辞めた人のアカウントを消すという発想ではたどり着けません。IPAのガイドラインの事例集には、退職した従業員が退職後に社内システムの機密情報に不正にアクセスしていた事例が載っていて、その主な原因のひとつに「退職後に共有アカウントのパスワードが変更されていなかった」ことが挙げられています。止めるべきなのはアカウントではなく、その人が知っていたパスワードだった、ということです。

業務システムで見落としやすい場所

下の表は、私たちがシステムを引き継ぐときに、人の出入りが残っていないか確認している場所を、発注側の方向けに整理したものです。右の列は、社内にエンジニアがいない場合に、誰に聞けば確認できるかの目安です。

場所	残りやすいもの	確認を頼む相手
サーバーへの接続（SSH）	登録された接続用の鍵、作業用のOSユーザー	現在の保守会社、サーバーの管理者
ファイルのアップロード（FTP・SFTP）	制作会社用に作ったFTPアカウント	保守会社、レンタルサーバーの管理画面
レンタルサーバーやクラウドの管理画面	前の委託先の担当者のログイン、契約者のメールアドレス	契約している自社の担当者
クラウドのアクセスキー（AWSなど）	外部から操作するためのキー、使われていない利用者	保守会社、クラウドの契約者
データベース	外部から接続できる設定のユーザー、データベース管理ツールのログイン	保守会社
業務システムの管理画面	共有の管理者アカウント、テスト用アカウント	社内の利用部門、保守会社
ソースコードの置き場所（GitHubなど）	前の委託先の組織にあるリポジトリ、自動で本番に出すための鍵	保守会社
外部サービスとの連携	決済・メール配信・地図などのAPIキー、その発行者のアカウント	各サービスの契約者
通知の宛先	エラー通知やバッチの結果を受け取るメールアドレス	保守会社
接続元の許可設定	前の委託先の事務所からだけ入れるようにしたIPアドレスの許可	保守会社
ドメインとDNS	管理会社のログイン、登録メールアドレス	ドメインの契約者

上の段ほど技術的で、非エンジニアの方が自分で確かめるのは難しくなります。そこは保守会社に「この表の項目について、今登録されているものを一覧で出してください」と頼むのが現実的です。そのとき、一覧には「誰のものか」と「最後に使われたのはいつか」も書いてもらってください。誰のものかわからないものが出てきたら、それがまさに棚卸しで見つけたかったものです。

下の段、管理画面の利用者やドメイン、外部サービスの契約は、発注側でも確かめられます。特に外部サービスは、自社の名前ではなく前の委託先の担当者の個人アドレスで登録されていた、ということがあります。そうなると、APIキーを止めたくても、そもそもそのサービスにログインできません。請求書がどこに届いているかをたどると、手がかりになることが多いです。

止める順番を間違えると、システムが止まる

入り口が見つかったら、すぐに消したくなります。ただ、業務システムでは、ここで急ぐと別の事故が起きます。

よくあるのは、前の委託先のものだと思って消した鍵やアカウントが、実は夜間のバックアップやデータ連携に使われていたというケースです。人が使うアカウントと、プログラムが使うアカウントが同じだった、ということは古いシステムほど起きやすいです。データベースのパスワードも同様で、管理ツールでのログインと、システム本体からの接続に同じものを使っていると、パスワードを変えた瞬間に画面が動かなくなります。

そこで私たちは、次の順番をおすすめしています。

まず、消す前に止めます。ログインできない状態にして、数日から1か月ほど様子を見ます。月末にだけ動く処理があるなら、月末をまたいでください。IPAのガイドラインでも、IDを消すとアクセス記録も消えてしまうシステムでは、IDをロックしてアクセスできない状態にし、記録を残すことが必要だとしています。後から「あのとき誰が何をしたか」を調べられるようにしておく意味でも、いきなり消さないほうが安全です。

次に、共有のパスワードと、外部に知られている鍵を替えます。プログラムが使っているものは、設定ファイルの書き換えとセットで行う必要があるので、保守会社と日時を決めて作業してもらいます。

止めても何も困らないことが確認できたら、そこで削除します。止めたまま何年も放っておくのは、消し忘れと大きくは変わりません。

前の委託先には、言いにくくても伝えておく

前の委託先のアカウントを止めるとき、事前に一言伝えるかどうかで迷う方もいます。悪意を疑っているように受け取られないか、という心配です。

私たちは、伝えたうえで止めるほうがよいと考えています。理由は二つあります。ひとつは、前の委託先しか知らない使われ方があるかもしれないからです。「その鍵は監視の仕組みで使っています」と教えてもらえれば、止めたあとで慌てずに済みます。もうひとつは、相手の側にも、手元に残ったデータやパスワードの控えを片づけてもらう必要があるからです。IPAのガイドラインも、契約終了時には取り扱いを委託した情報資産をすべて返却または完全に消去させなければならないとし、契約先のPCなどに保存されていた重要情報を消去した旨の確証を契約先からとることが望まれる、としています。

保守会社を切り替える場合の段取り全体は、他社システムの保守移管の進め方とチェックリストで書きました。そちらでは切り替え後のアカウント停止に少し触れただけなので、この記事はその続きとして読んでいただけると思います。開発会社とそもそも連絡が取れない場合は、開発会社と連絡が取れないシステムのセキュリティリスクも参考にしてください。

一度で終わらせないために

棚卸しは、一度やればしばらく安心、というものではありません。人は辞めますし、委託先の担当者も入れ替わります。次に同じ作業をするときに楽になるよう、二つだけ残しておくことをおすすめします。

一つは、今回作った入り口の一覧です。表の各行に、今は誰が使っているか、何のために使っているか、止めるときは誰に頼むかを書いておけば、次の退職や委託先の変更のときに、その表を上から見直すだけで済みます。

もう一つは、退職や契約終了の手続きに、業務システムの確認を組み込むことです。IPAのガイドラインも、IDや権限の登録・変更・削除に漏れがないよう、人事手続きと連携した運用にすることや、人事異動の時期に一斉に見直すことを挙げています。退職届を受け取った総務の方が、メールアカウントの停止と一緒に「業務システムの保守会社にも連絡」と書かれたチェック欄を目にする。その程度の仕組みでも、何もないよりはずっと漏れが減ります。

業務システムの入り口は、作った人や保守していた人がいちばんよく知っています。だからこそ、その人たちがいなくなる前、契約が終わる前が、棚卸しにいちばん向いた時期です。もう誰もいなくなってしまった後でも、サーバーを調べれば入り口はたどれますが、手間も費用も大きくなります。

ディレクターズ・リベロでは、他社が開発・保守してきたシステムの実行環境を調査し、引き継ぎと、その後の保守を行っています。「サーバーに誰が入れるのか、今の状態を知りたい」という調査だけのご相談もお受けしています。詳しくはシステム引き継ぎ・保守とサーバー運用保守サポートのページをご覧いただくか、info@directorz-libero.co.jp までご連絡ください。