共有ログインの管理

この状態なら読む

次のような環境を対象にします。

• 業務システム、製造設備、受付端末、古いパッケージソフトなどが利用者別IDを発行できない
• 契約や製品仕様の制約で複数人が同じ資格情報を使わざるを得ない
• すぐに製品更改できず、当面は共有ログインを残す必要がある
• 誰がいつ操作したかをシステム内のユーザーIDだけでは区別できない

個別IDを発行できるのに慣習だけで共有している場合は、このページの対象ではありません。その場合は、可能な範囲から個別IDへ移す方を先に検討します。

ここでは、共有ログインが残るという製品制約を事実として扱いながら、操作主体と資格情報の管理を別の手段で補います。

最初に「本当に個別IDを発行できないか」を確認する

共有ログインを例外として残す前に、製品や契約の制約を確認します。

ベンダーや保守会社には、少なくとも次を聞きます。

• 利用者別IDを追加できるか
• 管理者と通常利用者の権限を分けられるか
• 同時ログイン数やアカウント数に契約上の制限があるか
• 操作履歴に利用者を記録できるか
• 外部認証やSSOへ接続できるか
• 上位版、追加ライセンス、後継製品では個別IDに対応するか
• 共有IDのパスワード変更が他の機器や連携へ影響するか

「昔から1つのIDを使っている」ことと、「製品上1つしか使えない」ことを分けます。

共有ログインでは、システム内のIDだけで本人を区別できない

複数人が同じIDを使うと、システムの記録に同じユーザー名しか残らない場合があります。

そのため、操作履歴が残っていても、その共有IDの内側で誰が操作したかを別に補足しなければ、実際の利用者まで辿れません。

個人情報保護委員会の通則編では、個人データを情報システムで扱う場合の技術的安全管理措置として、アクセス制御やアクセス者の識別・認証などが示されています。

個別IDを発行できないシステムで個人データを扱う場合も、「製品が古いから誰が使ったか分からなくてよい」とはせず、どこまで利用者を区別できるかを別の管理で補います。

代替手段がない共有アクセスでも、管理を置く

英国NCSCは、共有アクセスの代替手段がなく、業務上の必要が残る場合でも、パスワードへのアクセスを監視・継続的に見直し、共有範囲を既知で信頼できる最小グループに限定し、利用権を失った人が出た場合はパスワードを変更することを示しています。

つまり「共有せざるを得ない」と「管理しなくてよい」は別です。

共有ログインを残すなら、少なくとも次の4点を管理対象にします。

1. 誰が使ってよいか
2. どの端末から使ってよいか
3. いつ・何のために使ったか
4. 誰が資格情報を保管・変更するか

利用者を別の記録で補う

システム内で利用者を区別できない場合は、業務に合う簡単な記録を外側へ置きます。

例えば次のような形です。

すべてのクリックを手書きで記録する必要はありません。事故や誤操作が起きたときに、誰がどの時間帯に何をしていたかを絞れる程度から始めます。

紙の記録でも、既存の作業日報でも、受付表でも構いません。新しい台帳を増やすより、すでに現場で記録している業務情報へ利用者と時間を足せるなら、その方が続きやすい場合があります。

利用端末を絞る

共有ログインをどのPCからでも使える状態にすると、資格情報を知る人と利用経路が広がります。

業務上可能なら、利用端末や利用場所を限定します。

• 指定されたPCや設備端末だけから利用する
• 私物端末へ共有パスワードを保存しない
• ブラウザやOSへ自動保存しない
• 不要な遠隔接続経路を増やさない
• 端末の利用者を別のOSログインや入退室記録で区別できるなら活用する

システム側のIDを分けられなくても、端末側の利用者まで同じにする必要があるとは限りません。

パスワードを知る人を必要最小限にする

共有ログインだからといって、部署全員や退職者まで同じパスワードを知り続ける必要はありません。

誰が資格情報へアクセスできるかを決め、異動・退職・委託終了などで利用権を失った人が出たら、必要に応じて資格情報を変更します。

変更時には次も確認します。

• 連携機器や自動処理が古いパスワードを使っていないか
• 保守会社が同じ資格情報を使っていないか
• 紙、共有ファイル、チャット等に旧パスワードが残っていないか
• 変更後の資格情報を誰が保管するか

パスワードの変更責任者を決めず、各自が勝手に変更する運用にはしません。

管理者操作を通常業務から分けられないか確認する

利用者別IDがなくても、製品によっては「管理設定用の資格情報」と「日常操作用の資格情報」を分けられる場合があります。

分けられるなら、日常業務で管理者資格情報を使わないようにします。

分けられない場合は、設定変更やマスタ変更など影響の大きい操作について、次のような外側の管理を検討します。

• 実行前に責任者へ確認する
• 作業日時と作業者を記録する
• 変更前後の値を残す
• 定期的に設定を確認する
• ベンダー保守時の作業内容を記録する

承認を増やしすぎて通常業務を止めるのではなく、誤操作や不正変更の影響が大きい操作へ絞ります。

システムのログが何を記録しているか確認する

共有IDしか使えなくても、製品側に利用時間、端末、操作種別、変更履歴などが残る場合があります。

ベンダーへ次を確認します。

• ログイン・ログアウト時刻を記録するか
• 接続元端末やアドレスを記録するか
• データの登録・更新・削除履歴が残るか
• 管理設定の変更履歴が残るか
• ログを書き出せるか
• 利用者がログを削除・変更できるか
• どの程度の期間保持されるか

製品ログだけで利用者本人を区別できなくても、外側の利用記録と時刻を合わせることで、調査可能性を上げられる場合があります。

「共有アカウント利用者一覧」を持つ

最低限、共有資格情報を使ってよい人を一覧にします。

人数が少ない会社ほど、頭の中だけで管理しがちです。誰か一人が不在でも説明できる形へします。

更改条件を先に決める

共有ログインを「当面の例外」として残すなら、何が起きたら更改・追加契約・別製品への移行を検討するかを決めます。

例えば次のような条件です。

• 利用者が増えて外側の記録では追えなくなった
• 個人データや機密情報の取扱量が増えた
• 遠隔利用が増えた
• 管理者操作を行う人が増えた
• 事故や誤操作の調査で、操作した人を特定できなかった
• 退職・異動のたびに共有パスワード変更が大きな業務負荷になった
• 後継版や追加ライセンスで個別ID・監査機能を使えるようになった

「壊れるまで使う」ではなく、共有状態が現場の管理能力を超える境界を持ちます。

暫定運用として最低限そろえる

すぐ更改できない場合は、まず次をそろえます。

• 個別IDを本当に発行できないことを確認した
• 共有ログインを使ってよい人を一覧にした
• 資格情報の保管・変更責任者を決めた
• 退職・異動時の変更手順を決めた
• 利用端末を必要な範囲へ限定した
• 重要操作について利用者・時間・対象を追える記録を持った
• 製品側のログ機能と保持期間を確認した
• 管理者操作を分けられるか確認した
• ベンダーへ個別ID・監査機能の将来対応を確認した
• 更改を再検討する条件を決めた

この状態でも、個別IDと同じ識別性が得られるわけではありません。製品制約による不足を把握し、何で補っているかを説明できることを目標にします。

この解説が断定しないこと

• 共有ログインを安全な方式だとは扱いません。
• 個別IDを発行できない製品を直ちに廃棄すべきだとは断定しません。
• 外側の利用記録が個別IDと同等の認証になるとは扱いません。
• すべての操作へ二重承認や詳細な手書き記録を要求しません。
• 特定のパスワード管理製品や後継システムを一律に推奨しません。

重要なのは、製品制約を理由に共有状態を無管理のまま固定せず、利用者・資格情報・重要操作・更改条件を別の手段で管理することです。