記事
小さな会社ほど共有パスワードをやめた方が、むしろ運用は楽になる
少人数の職場では一つのIDを共有した方が簡単に見えますが、退職・端末紛失・権限変更のたびに全員へ影響します。個人ごとのIDへ分けると、止める人と残す人を分けられ、事故時の対応も単純になります。
共有アカウントは「最初だけ」手間が少ない
新しいクラウドサービスを導入した日に、代表アドレスと一つのパスワードを全員へ渡せば、確かにすぐ使い始められます。しかし、その便利さは利用者が増えず、誰も辞めず、端末も失わず、事故も起きない間だけです。人が一人抜けるたびにパスワードを全員へ再配布する運用は、人数が少なくても面倒になります。短期の手軽さと、半年後の管理しやすさは別に考える必要があります。
個人IDにすると「その人だけ止める」ができる
一人一つのIDがあれば、退職者や外部委託先のアカウントだけを無効化できます。ほかの利用者のパスワードを変更する必要がなく、業務を止める範囲も小さくできます。サービス側に操作履歴がある場合も、個人IDの方が誰の操作か確認しやすくなります。事故対応では、この「対象を限定できること」が大きな利点になります。
全員を管理者にしないだけでも事故範囲は狭くなる
個人IDを作ると、役割ごとに権限を分けやすくなります。請求情報を触れる人、ユーザー追加ができる人、日常作業だけする人を分ければ、一つの操作ミスが全体へ及ぶ可能性を下げられます。小規模組織では細かな権限設計を作り込む必要はありません。「普段は一般権限、管理者は必要な人だけ」という単純な形から始めれば十分です。
退職日の作業が短くなる仕組みにする
共有アカウントでは、退職者が知っているパスワードをすべて洗い出して変更する必要があります。個人IDなら、対象アカウントを停止し、必要なら所有データを引き継ぐ流れにできます。退職時だけでなく、委託終了や担当変更でも同じ手順を使えます。人の入れ替わりを例外扱いせず、最初から停止しやすい設計にしておく方が実務では楽です。
続くルールは三つくらいでいい
専任IT担当がいない職場ほど、複雑なルールは回りません。「一人一ID」「重要サービスは多要素認証」「退職・契約終了日に停止」のように、誰でも説明できる形へ絞ります。サービスが個人IDに対応していない場合だけ例外として扱い、共有が標準にならないようにします。セキュリティ強化というより、日々の人事とアカウント管理を同じ流れにする、と考えると定着しやすくなります。