入社から退職までアカウントを人事イベントに同期させる運用の作り方

新しい社員が入るとき、アカウントは必ず作られます。用意されていなければ初日から仕事が始まらないので、現場が催促し、情報システム担当が手を動かします。ところが異動と退職では事情が変わります。旧部署の権限が残っていても業務は回りますし、退職者のアカウントが有効なままでも、誰かの手が止まるわけではありません。作る作業だけに締切があり、変える作業と止める作業には締切がないという非対称が、そのまま組織の穴になります。

その穴が使われた記録は残っています。IPAの「組織における内部不正防止ガイドライン」第5版には、リモートアクセス接続サービスで元従業員のアカウントが削除されておらず退職後に機密情報を持ち出された事例や、退職後に共有アカウントのパスワードが変更されていなかったため元従業員が機密情報へ不正アクセスしていた事例が収録されています。いずれも高度な攻撃ではなく、止め忘れが起点です。

この記事は、アカウントの発行と停止を運用する情報システム担当と管理部門に向けて、入社(Joiner)、異動(Mover)、退職(Leaver)という人事イベントにIDの状態を同期させる運用の作り方を、IPAと個人情報保護委員会とNISTとCISの一次情報をもとに整理します。

止める作業だけが誰にも急かされない#

アカウントの発行は、業務の開始という締切に引っ張られるので、遅れれば必ず催促が来ます。一方で退職者のアカウントを止める作業は、止めなくても誰の業務も止まりません。督促のない仕事は、忙しい時期に真っ先に後回しになります。

二つ目の理由は、情報の流れが切れていることです。退職や異動の事実を最初に知るのは人事部門ですが、アカウントを操作するのは情報システム担当です。両者をつなぐのが口頭の連絡や月次の名簿だけだと、月中の急な退職や退職日の前倒しが反映されません。人事が使う社員番号とディレクトリのアカウント名とSaaS側のユーザーIDが別々に管理されていれば、同じ人物であることの照合にも手間がかかります。

三つ目は、SaaSが情報システム部門の管理外にあることです。部門がカードで契約したツールや、担当者が個人のメールアドレスで登録した無料プランは管理台帳に載りません。止めるべき対象の一覧が作れないため、止めようがない状態になります。管理の外にあるサービスがどう生まれるかは次の記事で扱っています。

四つ目は共有アカウントです。部署で1つのIDを使い回している場合、そのIDは誰か1人の退職では止められません。パスワードを変えれば残ったメンバーの業務が止まるため、変更が先送りされます。IPAのガイドラインが共有IDを避けるよう求めるのは、内部不正が起きた際にアクセスした利用者を識別できなくなるためです。

IPA「組織における内部不正防止ガイドライン」第5版は、対策(7)で、共有IDおよび共有のパスワードやICカード等を使用せず、個々の利用者IDまたはシステム管理者IDを個別のパスワードやICカード等で認証しなければならないと定め、共有IDでは内部不正発生の際に重要情報にアクセスした利用者を識別できず特定が困難になるとしています。巻末の事例集には、退職後に共有アカウントのパスワードが変更されておらず元従業員が機密情報へ不正アクセスしていた例が収録されています。

異動のたびに足されて引かれない権限#

長く在籍している社員ほど、本人も把握していない権限を持っています。異動のたびに新しい権限が足され、前の権限が外れないまま積み上がるためです。この状態は本人が悪意を持たなくても危険を生みます。そのアカウントが乗っ取られたとき、攻撃者が到達できる範囲が、その人が過去に所属したすべての部署の合計になるからです。

権限が引かれない理由は、たいてい業務上の合理性から始まります。異動直後は前の仕事の引き継ぎが残っているので、しばらく前の権限を残す判断がなされます。ところが「しばらく」の終わりを誰も決めていないため、そのまま定着します。

NIST SP 800-53 Rev.5のPS-5(Personnel Transfer)は、この抜けを正面から扱っています。組織内の他の職位へ配置転換または異動する際に、現在の論理的および物理的なアクセス権限について業務上の必要性が続いているかをレビューして確認すること、定めた期間内に異動に伴う措置を開始すること、必要に応じてアクセス権限を変更すること、定めた関係者へ通知することを求めています。

IPAのガイドラインも同じ方向を示しており、定期的にアクセス権の要件を見直すこと、例として人事異動の時期に一斉に見直すことが望まれるとしています。あわせて、アクセス権限が集中している者に対しては適切性を確認し、不必要なアクセス権限を削除するよう記しています。権限を絞ること自体がなぜ効くのかという原理は次の記事で扱っています。

人事の記録を正としてIDの状態を決める#

運用を仕組みにする第一歩は、どの情報を正とするかを決めることです。人事システムに登録された雇用の事実を唯一の起点とし、そこから各システムのアカウント状態を導出する形にすると、判断の分岐が減ります。逆に情報システム側の台帳が独自に更新される運用を残すと、どちらが正しいかを毎回人間が判断することになり、判断した記録も残りません。

正とする記録に必要な項目は多くありません。社員番号、氏名、雇用区分、所属、上長、入社日、異動日、退職日があれば大半の判定はできます。CIS Controls v8.1のSafeguard 5.1は、企業内で管理するすべてのアカウントの一覧を整備して維持することを求め、その一覧に最低でも利用者アカウントと管理者アカウントとサービスアカウントを含め、少なくとも氏名、ユーザー名、開始日と終了日、部署を持つべきことを示しています。人事側の項目とほぼ重なるので、二重に持たずに同期する設計にできます。

この表で肝心なのは、時期の欄を空欄にしないことです。「速やかに」とだけ書かれた手順は、実際には無期限を意味します。IPAのガイドラインは、異動または退職により不要となった利用者IDおよびアクセス権はただちに削除しなければならないと明記しています。この「ただちに」を自組織の言葉で何時間以内と定義し、守れているかを測れる形にします。

IDを起点にして統制全体を組み直す発想は、境界防御の限界と合わせて考えると理解しやすくなります。

NIST SP 800-53 Rev.5のAC-2(Account Management)は、アカウントの作成と有効化と変更と無効化と削除を組織が定めた方針と手続きに従って行うこと(f)、アカウントが不要になったとき、利用者が退職または異動したとき、個人のシステム利用やneed-to-knowが変化したときに定めた期間内にアカウント管理者へ通知すること(h)、定めた頻度でアカウント管理要件への適合をレビューすること(j)、共有アカウントやグループアカウントの認証情報を個人がグループから外れた際に変更するプロセスを確立して実施すること(k)、アカウント管理のプロセスを人事の退職および異動のプロセスと整合させること(l)を求めています。

自動化でつなげる範囲とつなげられない範囲#

人事の記録を正と決めたら、次はそれを各システムへ届ける経路です。社内システムの多くがディレクトリサービスやIDaaSと連携していれば、人事イベントをディレクトリへ反映するだけで後続のサービスへ伝わります。ここで使われる標準の1つがSCIMです。IETFのRFC 7644はSCIMをHTTPベースのプロトコルとして定義し、その意図は共通のユーザースキーマと拡張モデルとサービスプロトコルを提供することでユーザー管理操作のコストと複雑さを下げることにあると記しています。

CIS Controls v8.1も、Safeguard 5.6でディレクトリまたはIDサービスによるアカウント管理の集中化を、Safeguard 6.7で可能な場合のアクセス制御の集中化を挙げています。集中化が効くのは、停止の作業が1か所で済むからです。サービスごとに個別ログインして無効化する運用は、対象が増えるほど漏れやすくなります。

一方で、標準の連携に乗らない領域は残ります。管理製品のAPIや特権アクセス管理、パスワード保管庫、入退室管理システムを使って自動化できる対象もあるため、まずは自動化できる範囲を広げ、そのうえで残った分をチェックリストで補います。

• ディレクトリ連携に対応していない基幹システムや、業務部門が独自に運用するサーバ
• ベンダーのサポートポータルや、機器の管理コンソールのような社外の管理画面
• 共有アカウントと、部署の代表メールアドレス
• 物理の鍵、入館証、金庫の暗証番号

これらは手作業のチェックリストで受け止めるしかありません。自動化されている範囲と手作業の範囲を分けて書き、手作業の側には必ず担当者と期限を割り当てます。自動化されている前提で誰も見ていないという状態が最も危険です。あわせて、人事データの誤りがそのまま権限へ反映される点にも備えます。反映前の差分を確認する仕組みと、誤って停止したときに戻す手順を用意しておきます。

アカウントを1か所に集約すると、認証を強くする投資も1か所で効きます。方式ごとの強度と使い勝手の違いは次の記事で整理しています。

退職日にどの順で止めるか#

退職時の作業は、順序を決めておくと事故が減ります。先に業務用メールを止めると、本人にしか届かない社外サービスの通知やパスワード再設定の経路が使えなくなり、後続の作業が滞ります。逆に、認証の入口を止める前にアカウントだけ削除すると、有効なセッションやリフレッシュトークンが生き残ることがあります。

NIST SP 800-53 Rev.5のPS-4(Personnel Termination)は、雇用の終了にあたって、定めた期間内にシステムアクセスを無効化すること、その個人に紐づく認証子と資格情報を失効させること、退職面談を行うこと、セキュリティに関係する組織の資産を回収すること、退職者がそれまで管理していた組織の情報とシステムへのアクセスを組織側が引き続き確保することを求めています。解説では、回収対象にハードウェア認証トークンや鍵や身分証や入館証が含まれること、状況によっては退職を通知する前にその個人のシステムアカウントを無効化することを組織が検討する場合があることも述べられています。

IPAのガイドラインも、情報システムから元役職員の利用者IDや権限が削除されたことを確認する必要があり、これにはテレワークのために付与した権限も含まれると記しています。加えて、雇用終了間際に情報の持ち出し等の内部不正が発生しやすいことから、雇用終了前の一定期間からPC等をシステム管理部門等の管理下に置くことが望まれるとし、例としてアクセス範囲の限定、USBメモリの利用制限、モニタリングの強化を挙げています。

正規の権限を持つ人による持ち出しを、機会と動機の両面から抑える統制の作り方は次の記事で扱っています。

引き継ぎを止める作業と一緒に決める#

停止の手順だけを整えると、現場から「消したら困る」という反発が返ってきて、結局アカウントが残ります。止める作業とデータを引き継ぐ作業を同じ手順に置けば、この対立は解消できます。引き継ぎの対象になりやすいのは、メールボックス、個人のドライブ領域、コードリポジトリやCIの権限、外部サービスの管理者権限です。誰に引き継ぐかを事前に決めておかないと、退職後に問い合わせが来て、無効化したアカウントを一時的に戻すという最悪の手順を踏むことになります。

削除と無効化の使い分けも決めておきます。IPAのガイドラインは、利用者IDを消去するとアクセス記録も消える場合には、IDをロックしてログを保全することが必要になると述べています。既定は無効化とし、保存期間を過ぎたものを定期的に削除する運用が扱いやすくなります。退職者宛のメールを上長へ転送する設定にも解除予定日を持たせます。放置すれば、外部から見えない情報の流路になるためです。

CIS Controls v8.1のSafeguard 6.2「Establish an Access Revoking Process」は、利用者の退職、権限の剥奪、役割の変更に際してアカウントを即座に無効化することによりアクセスを取り消すプロセスを、できれば自動化した形で確立して従うことを求め、監査証跡を保存するためにはアカウントを削除するのではなく無効化することが必要になる場合があると記載しています。Safeguard 5.3「Disable Dormant Accounts」は、対応している場合に45日間の非活動の後に休眠アカウントを削除または無効化することを求めています。

棚卸しを形骸化させない回し方#

日々の運用がどれだけ整っても、漏れはゼロになりません。だからこそ定期的な棚卸しが要ります。ただし棚卸しは、やり方を誤ると「全部そのままで問題なし」という回答が並ぶだけの行事になります。

第一に、頻度と対象を先に決めます。CIS Controls v8.1のSafeguard 5.1は、有効なすべてのアカウントが承認されたものであることを最低でも四半期ごとに検証することを、Safeguard 6.8は、役割ごとに必要なアクセス権を文書化したうえで権限の承認状況を検証するアクセス制御のレビューを最低でも年1回実施することを求めています。全部を同じ頻度で見る必要はなく、特権と個人データを扱う領域を高い頻度に振り分けます。

第二に、レビューする人を業務が分かる人にします。その権限が業務上必要かどうかを判断できるのは、情報システム担当ではなく部門の管理職です。ただし管理職に何百行の一覧を渡せば、まとめて承認されて終わります。前回からの差分だけを渡す、高リスクの権限だけを抜き出すといった形で見る量を減らします。

第三に、回答がない場合の既定動作を決めます。期限までに承認も否認もなければ権限を停止するという取り決めがあると、レビューが実際に読まれるようになります。停止された側から連絡が来たときに、元の承認者による再承認を経て戻せる手順を用意しておけば、統制を迂回せずに業務への影響を抑えられます。停止が業務停止に直結する重要システムでは、期限が来た時点で管理職とデータ所有者へ上げる扱いにします。

第四に、証跡を残します。誰がいつ何を承認したか、何件が削除されたかを記録し、次回の棚卸しで前回の削除が実行されているかを確認します。個人情報保護委員会のガイドライン(通則編)も、定期的に自ら行う点検または他部署等による監査の実施を手法の例示に挙げています。

なお、残っているアカウントの有無を確かめる作業は、自組織が管理するシステムに対して、権限のある担当者が承認を得たうえで実施します。退職者のアカウントで実際にログインを試すような検証を自社の管理外のシステムに対して行うと、不正アクセス行為の禁止等に関する法律に触れる可能性があります。確認は管理者側の一覧と監査ログから行います。

人ではないIDをどう数えるか#

人の退職は人事が把握しますが、バッチ処理用のサービスアカウントやAPIキーには退職がありません。作った人が抜けても、そのIDは動き続けます。困るのは動き続けること自体ではなく、誰が面倒を見るのかが分からなくなることです。用途を説明できないアカウントは、更新も停止もできないまま残ります。

CIS Controls v8.1のSafeguard 5.5は、サービスアカウントの一覧を整備して維持することを求め、その一覧に最低でも部門オーナーとレビュー日と目的を含めること、有効なアカウントがすべて承認されたものであることの検証を最低でも四半期ごとに行うことを示しています。部門オーナーという項目が実務的です。所有者を組織の役職に紐づけておけば、個人が抜けても引き継ぎ先が決まります。

APIキーやアクセストークンは、有効期限を持たせることと発行元を集約することが基本になります。開発者が個人のアカウントで発行したトークンがCIに設定されていると、その人の退職とともに自動処理が止まるか、退職後も有効なままアクセス経路として残るかのどちらかになります。自動処理は個人ではなく専用のIDに紐づけます。

共有アカウントを完全になくせない場合は、抜ける人が出るたびに認証情報を変える運用を明文化します。NIST SP 800-53 Rev.5のAC-2が求める共有アカウントの認証情報の変更は、抜けたメンバーがアクセスを保持し続けないようにするための措置だと解説されています。認証子そのものの扱いについては、NIST SP 800-63B-4に、危殆化した認証子を無効化しなかった場合の結果は誤って無効化した場合のサービス妨害の可能性よりも通常は重大である、という一文が添えられています。危殆化が確認された、または疑われる認証子については、迷ったら止めるという判断の根拠になります。退職にともなう停止の根拠は、NIST SP 800-53のPS-4やCIS Controls v8.1のSafeguard 6.2に置きます。

NIST SP 800-63B-4の4.5節(Invalidation)は、認証子の無効化を、認証子と加入者アカウントとの間の結びつきを取り除くことと定義しています。そのうえでCSPは、加入者アカウントが存在しなくなったとき、加入者から要求されたとき、認証子が危殆化したとき、またはCSPが加入者は資格要件をもはや満たしていないと判断したときに、速やかに認証子を無効化しなければならない(SHALL)と定めています。危殆化した認証子を無効化しないことの結果は、誤って無効化した場合のサービス妨害の可能性よりも通常は重大であることも記されています。

雇用契約が自社にないIDの扱い#

委託先、派遣、業務委託、出向者、一時的に入る事業者は、自社の人事システムに載らないことが多く、別の台帳や契約管理システムで扱われます。人事イベントを起点にした自動化の外側になりやすく、ここが最も抜けやすい領域です。

扱い方の基本は、契約の期間をIDの有効期限として持たせることです。契約終了日を過ぎたら自動的に無効になるアカウントにしておけば、止め忘れは起きにくくなります。ただし終了日の未登録や誤登録、期間延長の反映漏れは残るため、期限が近いIDと期限の入っていないIDの一覧を定期的に確認します。NIST SP 800-53 Rev.5のAC-2の管理策拡張(2)は、一時アカウントと緊急用アカウントを種類ごとに定めた期間の経過後に自動的に削除または無効化することを、同(3)は、有効期限が切れたアカウントや利用者に紐づかなくなったアカウント、定めた期間にわたり利用のないアカウントを定めた期間内に無効化することを求めています。

もう1つは、相手方の体制変更を自社へ届ける仕組みです。委託先の中で担当者が交代しても自社は気づけません。IPAのガイドラインは、委託先の従業員の異動や退職によりアカウントの削除漏れ等が発生しないように、体制に変更が生じた場合は変更内容を委託元に報告するといった措置を例に挙げています。契約書や覚書に通知義務と期限を書き込んでおくのが確実です。

保守用のベンダーアカウントは、常時有効にしないという判断が有効です。作業の申請があったときだけ有効化し、作業終了とともに無効に戻せば、契約が続いていても普段は使えない状態を保てます。有効化と無効化の記録が、そのまま作業の証跡にもなります。

IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版は、ユーザーIDおよび管理者IDの発行から削除までを管理するプロセスを定めて必要最小限の割り当てとすること、従業員の異動や退職等に伴う権限の変更や削除の漏れを防止するためにアクセス権限を見直すルールを定めること、退職や任期満了時に情報や機器、ID、鍵等を回収して復元できない方法でデータを消去しチェックリストや証跡で実行状況を可視化すること、取引先との契約終了時には責任者と期限を設定して機密性の高い情報およびアクセス権の回収や破棄をチェックシートで運用し記録を保管することを記載しています。

監査と法令が求めていること#

個人情報取扱事業者が個人データを情報システムで扱う場合、この運用は個人情報保護法にもとづく安全管理措置の一部として求められます(行政機関等には別の規律があります)。個人情報保護委員会のガイドライン(通則編)は、技術的安全管理措置として、担当者および取り扱う個人情報データベース等の範囲を限定するための適切なアクセス制御と、情報システムを使用する従業者が正当なアクセス権を有する者であることを識別した結果にもとづき認証することを定めています。組織的安全管理措置の側では、取扱状況を確認する手段の整備として、責任者と取扱部署、利用目的、そしてアクセス権を有する者をあらかじめ明確化しておくことが例示されています。台帳に「誰が権限を持っているか」の欄を持つことは、この確認手段を満たす実装の一例にあたります。具体的な手法は、事業の規模や取扱状況、リスクに応じて選ぶこととされています。

ISMSの認証を取っている組織にとっても、この領域は審査の対象です。JIPDECのコラムによれば、ISMS適合性評価制度の認証基準であるISO/IEC 27001は2022年10月25日に改訂され、附属書Aの管理策が再構成されて、組織的、人的、物理的、技術的の4分類に簡素化され、数は114から93になりました。分類の形は変わっても、識別とアクセス権の管理が中核に置かれている点は変わりません。

監査で見られるのは、規程に何と書いてあるかよりも、書いたとおりに動いた記録が残っているかです。退職者リストと無効化の実施記録に差がないこと、棚卸しで削除された権限が実際に消えていること、共有アカウントのパスワード変更日が記録されていること。この三つは有力な証跡になります。あわせて、規程と承認、例外の扱い、是正までが一貫しているかも確認されます。

個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(平成28年11月、令和8年6月一部改正)の別添「講ずべき安全管理措置の内容」は、技術的安全管理措置として、担当者および取り扱う個人情報データベース等の範囲を限定するために適切なアクセス制御を行わなければならないこと、個人データを取り扱う情報システムを使用する従業者が正当なアクセス権を有する者であることを識別した結果に基づき認証しなければならないことを定めています。組織的安全管理措置では、取扱状況を確認する手段の整備の例示としてアクセス権を有する者の明確化を挙げています。

まとめ#

アカウントの発行は放っておいても回りますが、変更と停止は放っておくと止まります。催促する人がいないからです。この非対称を運用の努力で埋めようとすると、忙しい時期に必ず破れます。人事の事実を正とし、そこからIDの状態が導かれる形に組み替えるのが解き方になります。

NIST SP 800-53 Rev.5のAC-2は、アカウント管理のプロセスを人事の退職と異動のプロセスに整合させることを独立した要求として置いています。CIS Controls v8.1は、付与のプロセスと取り消しのプロセスを別々のSafeguardとして定義し、休眠アカウントの停止に45日という数字を与えています。IPAの内部不正防止ガイドラインは、異動または退職で不要になった利用者IDとアクセス権をただちに削除することを求めています。どれも、人の記憶や善意ではなく手続きで解くべき問題だと言っています。

着手するときは、対象を全部一度に整えようとしないほうが進みます。まず退職の情報が確実に届く経路を1本作り、次に停止までの時間を数値で決め、その次に自動化の外にある対象を一覧化します。そこまで整えば、棚卸しは差分の確認で済みます。人ではないIDと委託先のIDは、所有者と期限という2つの項目を持たせるところから始めます。