会社で使っているシステムを見直していると、こんなアカウントが見つかることがあります。
- 営業部みんなで使う1つのログインID
- 受付担当が交代で使う共通アカウント
- 昔から同じパスワードで使っている管理画面
- 誰が作ったか分からないが、止めると困るSaaSのアカウント
セキュリティだけを考えれば、「1人1アカウントにしましょう」で話は終わります。
でも、現場の人も好きで共有しているとは限りません。
古いシステムが個別アカウントに対応していない、担当者が頻繁に交代する、アカウントを増やす運用が重いなど、共有になった理由があることも多いです。
だから、共有アカウントを見つけたときに大切なのは、いきなり禁止することではありません。
なぜ共有しているのかを確認し、その便利さをできるだけ残しながら、後で困る部分を減らしていくことです。
先に結論：できるなら個人アカウント。難しいなら「誰が使えるか分かる共有」に近づける
基本的には、社員ごとに個別のアカウントを作り、必要な権限だけを付ける方が管理しやすくなります。
理由はシンプルで、
- 誰が操作したか分かりやすい
- 退職・異動した人だけ止められる
- 権限を人ごとに調整できる
- MFAなど本人確認を使いやすい
からです。
一方で、共有をすぐやめられないシステムもあります。
その場合は、少なくとも次の状態を目指します。
- 何のための共有アカウントか分かる
- 誰が使ってよいか分かる
- パスワードを必要以上に広く配らない
- 退職・異動時にアクセスを外す手順がある
- 可能なら、誰がいつ使ったか追える
「共有アカウントをゼロにする」より、まず「管理されていない共有アカウントを減らす」と考える方が現場では進めやすいです。
この記事でいう「共有アカウント」とは
ここで扱うのは、複数人が同じIDとパスワードを使って、1つのアカウントとしてログインする状態です。
たとえば、
ID: sales@example.jp
Password: チーム全員が知っている同じパスワードのような状態です。
一方、共有メールボックスや共有フォルダを複数人で使っていても、各社員が自分の会社アカウントでログインしているなら話は別です。
見た目は「みんなで同じものを使っている」ようでも、システム側では誰がアクセスしたか区別できます。
まずは、共有しているのが「データや機能」なのか、「ログインIDそのもの」なのかを分けて考えると整理しやすくなります。
共有アカウントで一番困るのは「誰がやったか分からない」こと
共有アカウントの分かりやすい問題は、操作履歴に共通IDしか残らないことです。
たとえば、顧客情報が削除されていたとします。
ログには、
sales-team が 15:32 に削除と残っていても、その時間に誰が sales-team を使っていたのか分からなければ、原因確認に時間がかかります。
これは「犯人探しをしたい」という話だけではありません。
- 誤操作なのか
- 操作方法に問題があったのか
- 権限設定を見直すべきなのか
- 不正アクセスなのか
を切り分けるためにも、誰の操作だったかは重要です。
IPAも、共有IDでは重要情報へアクセスした利用者を識別しにくくなり、問題が起きたときの追跡が難しくなると説明しています。
退職・異動した人だけを外せない
個人アカウントなら、Aさんが退職したときはAさんのアカウントだけ無効化できます。
共有アカウントの場合、Aさんがパスワードを知っているなら、Aさんだけを外すことができません。
確実にアクセスできなくするには、共有パスワードを変更し、残ったメンバーへ新しい情報を渡す必要があります。
人数が多いほど、ここが面倒になります。
その結果、
- 誰かが退職してもパスワードを変えない
- 何年も同じパスワードを使う
- 元社員が知っているかもしれない状態が続く
という運用になりがちです。
NISTのアカウント管理に関する管理策でも、共有・グループアカウントを使う場合は、メンバーが外れたときに認証情報を変更するプロセスを持つことが示されています。
パスワードを配るほど、管理場所が増える
共有アカウントは「1つのIDだから管理が楽」に見えます。
でも実際には、パスワードを複数人へ伝える必要があります。
すると、
- チャットの過去ログ
- メール
- Excelの一覧
- 共有フォルダのメモ
- ブラウザの保存パスワード
- 紙のメモ
など、認証情報が残る場所が増えやすくなります。
パスワードを変更したときには、それらを全部更新しなければなりません。
人数が増えるほど「全員に同じ秘密を覚えてもらう運用」は難しくなります。
MFAを付けたいときにも運用が難しくなる
多要素認証（MFA）は、不正ログイン対策として有効です。
ただ、共有アカウントへMFAを設定しようとすると、
- 誰のスマートフォンを登録するのか
- 担当者が休みの日はどうするのか
- 認証コードをどう共有するのか
- 担当者が異動したときにどう入れ替えるのか
という別の問題が出てきます。
ここでMFAのコードまでチャットで共有し始めると、せっかく本人確認を強くした意味が薄くなります。
サービスが個人アカウントに対応しているなら、各自が自分のアカウントでMFAを使う方が自然です。
それでも共有アカウントが残るのは、利便性にも理由がある
共有アカウントには問題がありますが、現場側の便利さもあります。
たとえば、
- 担当交代のたびにアカウントを作らなくてよい
- 誰かが休んでも同じ業務を続けやすい
- 古いシステムでも複数人で運用できる
- 個別ユーザー管理の仕組みがないサービスを使い続けられる
といった点です。
つまり、セキュリティと利便性は確かに天秤になる部分があります。
ただし、「安全にするほど不便になる」と決まっているわけではありません。
SSOやグループ権限、共有メールボックス、権限委任などを使うと、利用者は自分のアカウントでログインしつつ、チームとして同じ業務を続けられる場合があります。
大切なのは、共有アカウントが提供している便利さが何なのかを先に見つけることです。
いきなり禁止する前に「なぜ共有しているか」を聞く
情シス側から見ると、共有アカウントは早くなくしたくなります。
でも、理由を確認せず「明日から禁止」とすると、現場では別の共有方法が生まれることがあります。
たとえば、個人アカウントを作ったのに、
- 忙しいから結局1人のアカウントをみんなで使う
- MFAが面倒なので認証済みPCを共用する
- パスワードをチャットで送り合う
となれば、ルールだけ増えて実態は変わりません。
まずは、次のように聞く方が建設的です。
- なぜこのアカウントは共有になっている？
- 何人が使う？
- 担当者はどのくらい入れ替わる？
- 個別アカウントにすると何が面倒？
- このアカウントが使えないと、どの業務が止まる？
「共有をやめる」ではなく「この便利さを別の方法で残せないか」と考えると、現場と話しやすくなります。
個人アカウントにできるなら、権限はグループでまとめる
共有アカウントをやめると「社員全員の権限を1人ずつ設定するのが大変」という問題が出ることがあります。
その場合、サービスにグループやロールの機能があれば、
営業部グループ
├ Aさん
├ Bさん
└ Cさんのように、グループへ権限を付ける方法が使えます。
Aさんが異動したらグループから外すだけです。
個人ごとの識別を残しつつ、運用負荷は抑えられます。
「共有メールアドレス」が必要なら、ログインまで共有しなくてよい場合もある
代表アドレスを複数人で確認したいだけなら、1つのメールアカウントのパスワードを全員で共有する必要がない場合があります。
Microsoft 365やGoogle Workspaceなどには、共有メールボックス、グループ、委任といった仕組みがあります。
各社員は自分のアカウントでログインしつつ、info@ や support@ のような共通窓口を扱えます。
「みんなで同じメールを見る」ことと「みんなが同じログイン情報を知る」ことは分けられます。
どうしても1つのIDしか使えないなら、パスワードを直接配らない方法も考える
古い業務システムや一部のWebサービスでは、どうしても1つのアカウントを複数人で使わなければならないことがあります。
その場合でも、全員へパスワードをそのまま知らせる以外の方法があります。
たとえば、会社で利用しているID管理やパスワード管理の仕組みによっては、
- 利用を許可された人だけが使える
- 本人は共有パスワードそのものを知らない
- 個人アカウント側でMFAする
- 誰が利用したかログを残す
といった運用ができます。
Microsoft Entra IDも、共有資格情報を利用者へ直接見せず、個人の認証を経由してアプリへログインさせる方法を案内しています。
すべての会社で同じ仕組みを導入する必要はありません。
共有アカウントの数が少ない会社なら、まず対象を把握して管理責任者を決めるだけでも前進です。
どうしても共有するなら、最低限ここを決めておく
すぐに個人アカウントへ移行できない場合は、次の項目だけでも整理しておくと管理しやすくなります。
| 確認すること | 例 |
|---|---|
| 何のアカウント？ | 受発注システムの営業部共通アカウント |
| 管理する人は？ | 営業部長 + 情シス |
| 誰が使ってよい？ | 営業部の受発注担当5名 |
| 認証情報はどこで管理？ | 会社承認のパスワード管理ツール |
| MFAはどうする？ | システムの仕様に合わせて管理方法を決める |
| 退職・異動時は？ | 利用者を見直し、必要ならパスワード変更 |
| ログは確認できる？ | 月1回または事故発生時に確認できる状態にする |
| ライセンス条件は？ | 契約上、複数人利用が認められているか確認 |
ここで重要なのは、難しい管理表を作ることではありません。
「誰が管理しているのか分からない」「誰がパスワードを知っているか分からない」という状態をなくすことです。
会社の小さなツールやアカウントを、作った人・知っている人だけに依存させない考え方は、AIで社内ツールを作る前に考えたいこと｜Excelマクロ時代から続く「属人化」への備えでも整理しています。
サービスの料金・ライセンス条件も別に確認する
共有アカウントを個人化すると、サービスによっては利用料金が増えることがあります。
逆に、1つの契約アカウントを複数人で共有すること自体が、サービスの契約条件に合っていない場合もあります。
これはセキュリティとは別の問題です。
「技術的にはログインできるから使ってよい」とは限らないため、利用規約や契約プランも確認しておきましょう。
共有アカウントを見つけたときの現実的な順番
全部を一度に直そうとすると進みにくいので、次の順で十分です。
- どんな共有アカウントがあるか把握する
- 何人が、何のために使っているか確認する
- 個人アカウント + 権限共有へ変更できるか調べる
- できない場合は管理責任者と利用者を決める
- 退職・異動時の変更方法を決める
- MFA・ログ・認証情報の管理方法をできる範囲で改善する
特に、管理者権限を持つ共有アカウントや、顧客情報・機密情報へアクセスできるアカウントから優先するとよいでしょう。
まとめ：共有を責めるより、共有しなくても仕事が回る形を探す
共有アカウントは、誰が使ったか分かりにくく、退職・異動時のアクセス停止やパスワード管理も難しくなります。
だからといって、「危険だから禁止」で終わらせると、現場の業務が回らなくなることがあります。
まず確認したいのは、その共有アカウントが何の便利さを支えているのかです。
個人アカウント、グループ権限、共有メールボックス、SSOなどで同じ便利さを残せるなら、そちらへ移していく。
どうしても共有が必要なら、誰が使えるか、誰が管理するか、退職・異動時にどうするかだけでも明確にする。
セキュリティと利便性のどちらか一方だけを選ぶのではなく、現場が使い続けられる範囲で、少しずつ「後で困らない共有」に変えていくのが現実的です。
