システムの保守やデータ移行、業務の委託などで、社外の担当者に自社システムのアカウントを渡す場面は少なくありません。ところが、こうして渡したアカウントは自社の従業員のアカウントとは別の扱いになりやすく、誰に何の権限を渡しているのかが把握されていない状態が生まれがちです。この記事では、社外に渡したアカウントを統制するための実務を整理します。社内のアカウント管理の基本についてはアカウント管理システムとは？の解説記事もあわせてご覧ください。
社外に渡したアカウントが管理から外れてしまう理由
自社の従業員のアカウントは、入社・異動・退職といった人事イベントをきっかけに見直されます。一方、委託先や保守ベンダーのアカウントには、こうしたきっかけが自社側に存在しません。相手先の担当者が交代しても、契約が実質的に終わっていても、自社の人事情報には何も現れないため、棚卸しの対象から静かに外れていきます。
もうひとつの要因は、情報の分断です。契約や発注の経緯は事業部門や購買が把握し、アカウントの発行や権限設定は情報システム部門が行うことが多いため、「この契約はもう終わっている」という情報がアカウントの管理側に届かないことがあります。悪意や怠慢ではなく、役割の境目に情報が落ちてしまう構造的な問題です。
よくある状態を洗い出す
実際に確認してみると、次のような状態が見つかることがあります。まずは自社に当てはまるものがないか点検してみてください。
- 共用アカウントの使い回し — 相手先の複数の担当者が同じIDとパスワードを共有しており、実際に誰が操作したのか判別できない状態です(共有アカウントの廃止で詳しく扱っています)
- 作業終了後も有効なまま — 導入や移行の作業が終わったのに、そのとき発行したアカウントが有効なまま残っている状態です
- 常時アクセスできる経路 — リモート保守のために開いた経路が、作業のない期間も開いたままになっている状態です
- 強い権限が付いたまま — 作業を確実に進めるために付与した広い権限が、そのまま維持されている状態です
なぜこの領域のリスクが大きいのか
自社の対策が十分であっても、社外に渡したアカウントは相手先の環境で管理されています。相手先が何らかの被害を受けた場合、そのアカウントが自社への入り口になりうるという点が、この領域を軽く扱えない理由です。取引関係を経由して侵入が広がる経路は、現実に注意が必要な領域として広く認識されています。攻撃側から見た構図についてはサプライチェーン攻撃の解説記事で整理しています。
また、強い権限が付いたアカウントは、それ自体が影響範囲を大きくします。権限の考え方は権限管理の解説記事、サーバー側の管理者アカウントの扱いはWindows Serverの特権アカウント管理を参照してください。
渡し方のルールとして決めておくこと
社外にアカウントを渡す前に、次の項目を取り決めとして決めておくと、後の管理が大きく楽になります。個別の交渉ごとにせず、社内の共通ルールとして持っておくことが重要です。
- 担当者ごとに発行する — 会社単位の共用アカウントではなく、実際に作業する人ごとにアカウントを発行します
- 必要な範囲の権限に限定する — 依頼した作業に必要な機能とデータの範囲だけを許可します
- 作業期間を決める — いつからいつまで使うアカウントかを決め、期間外は無効にしておきます
- アクセス経路を限定する — 接続元や接続方法を絞り、どこからでも到達できる状態を避けます(VPN機器の脆弱性も参照)
- 操作の記録を残す — いつ誰が何をしたのかを後から確認できるようにしておきます
- 担当者交代時の通知 — 相手先の担当者が変わったときに連絡をもらう取り決めを、契約や覚書に含めておきます
作業が終わったあとの確認
アカウントの発行時よりも抜けやすいのが、終了後の処理です。次の三点を仕組みとして組み込んでおくと、放置が起きにくくなります。
- 作業終了時の無効化 — 依頼した作業の完了報告と、アカウントの無効化をひとつの手続きとして扱います
- 定期棚卸しの対象に含める — 社内アカウントの棚卸しの際に、社外に渡したアカウントも必ず対象に入れます(ID棚卸しの実務で手順を解説しています)
- 契約終了時のチェックリスト — 契約が終わる際の事務手続きに、アカウントの停止確認の項目を入れておきます
契約・依頼のときに文書で決めておく項目
委託先アカウントの問題は、技術ではなく取り決めの不備から生まれます。次の項目を、作業依頼書や契約書のどこかに明記しておくと、後の確認が楽になります。
- アカウントの発行単位 — 会社単位ではなく、実際に作業する担当者ごとに発行するか
- 有効期限 — 作業期間に合わせて期限を切るか、恒常的に有効とするか
- 作業担当者の変更時の連絡義務 — 相手先で担当者が交代したときに、こちらへ通知してもらう取り決め
- 接続元の限定 — どこからの接続を許可するか
- 作業記録の扱い — 誰がいつ何をしたかを、どちら側で記録として残すか
- 契約終了時の措置 — アカウントの停止時期と、その確認を誰が行うか
特に「相手先で担当者が交代したときの連絡」は抜けやすい項目です。これがないと、すでに退職した相手先の担当者名義のアカウントが、こちらの環境で生き続けることになります。
契約終了時の確認リスト
保守契約や開発案件が終わった時点で、次を確認してください。作業が終わったこととアカウントが止まっていることは別です。
- 発行したアカウントを無効化したか — 複数人ぶん発行していた場合、全員ぶんを確認します
- 接続経路を閉じたか — VPNやリモート接続の許可設定が残っていないか
- 共有したパスワードを変更したか — 既存アカウントを一時的に貸していた場合、そのパスワードは変更が必要です
- 渡したデータの扱いを確認したか — 作業のために提供した情報の返却・破棄
- 止めたことを記録に残したか — 後から「いつ止めたか」を説明できる状態にします
取引先や監査から管理状況を問われた際の整理のしかたは アカウント管理と各種基準・監査対応にまとめています。
保守ベンダーの管理者アカウントを止める前に、自社だけで管理画面に入れる状態を確保しておいてください。ベンダー任せにしていた認証情報を無効化した結果、自社の誰も入れなくなる事故が起こり得ます(緊急用の管理者アカウントを用意する手順)。
相手先に配慮しながら進めるための考え方
こうした取り決めを依頼すると、相手を疑っているように受け取られないかと気になるかもしれません。ここで大切なのは、これらのルールが相手を監視するためのものではなく、双方が事故の当事者にならないための取り決めであると位置づけて説明することです。万一の事態が起きたときに、どこまでが誰の作業だったのかを示せる記録があることは、委託先にとっても自らを守る材料になります。
取引先から自社の管理状況を問われる機会も増えています。社外アカウントの扱いを整えておくことは、そうした確認への回答をしやすくする準備でもあります(SCS評価制度の解説記事も参照)。
アカウントの管理とは別に、委託先の体制そのものを確認する場面もあります。実態が出る設問の作り方は 委託先のセキュリティを確認する項目で扱っています。
まずは自社の状況を確認する
社外に渡したアカウントがどれだけあり、どのような権限と経路で残っているかは、実際に洗い出してみないと見えてきません。applippliの無料診断では、約3分の質問に回答するだけで、自社のID・アカウント管理の対応状況を確認できます。委託先アカウントの見直しを始める前の現状把握としてご活用ください。