// シス担のミカタ
認可・アクセス制御

共有アカウントの禁止 きょうゆうあかうんとのきんし

アカウント管理個人認証監査ログアクセス制御内部統制ID管理
共有アカウントの禁止について教えて

簡単に言うとこんな感じ！

「みんなで同じIDとパスワードを使い回すのはダメ！」というルールだよ。誰がいつ何をしたか追えなくなるし、退職した人がそのままログインできちゃう危険もある。1人1アカウントが鉄則なんだ！

共有アカウントの禁止とは

共有アカウントとは、複数の人が同一のID・パスワードを使ってシステムにログインする運用のことです。たとえば「部署全員が admin / password123 でログインしている」「夜勤チームが共通のIDを使い回している」といった状況がこれに当たります。共有アカウントの禁止とは、このような運用を許可せず、必ず1人につき1つの個人アカウントを割り当てることを求めるセキュリティ原則です。

この原則が重要な理由は大きく2つあります。第一に**「誰がやったか」を特定できなくなるという問題です。不正アクセスや情報漏洩が発生しても、ログに残るのは共有IDだけなので犯人や操作者を追跡できません。第二にアカウントのライフサイクル管理が崩壊する**という問題です。メンバーが退職しても「他の人がまだ使っている」という理由でアカウントを削除できず、元社員が引き続きシステムにアクセスできる状態が続いてしまいます。

情報セキュリティの国際標準である ISO/IEC 27001 や、クレジットカード業界のセキュリティ基準 PCI DSS、日本の個人情報保護法対応においても、個人アカウントの付与と共有アカウントの排除は基本要件として明示されています。

なぜ共有アカウントがここまで問題なのか

共有アカウントが引き起こす問題を整理すると、以下のように多岐にわたります。

問題カテゴリ具体的なリスク影響度
追跡不能誰が操作したか特定できない★★★
退職者対応元社員がログインし続けられる★★★
パスワード管理変更時に全員への周知が必要★★
権限過多不要な権限を持つ人が増える★★
内部統制監査・コンプライアンス違反★★★
責任の曖昧化「自分じゃない」の言い訳が成立★★

「誰でも知っている鍵」のたとえ

共有アカウントは「会社の全員が同じ合鍵を持っている」状態に例えられます。誰かが鍵をなくしても交換できないし（他の人が使えなくなる）、退職した人の鍵を回収し忘れてもわからない。侵入者がいても「どの鍵のコピーから入ったか」追えない——まさにそういう状態です。

共有アカウントが生まれやすいシチュエーション

  • システムのライセンス数が少なく「1人1つ」が買えない
  • 昔から使っている古いシステムでアカウント管理機能が弱い
  • 「どうせ同じ部署だから」という油断
  • 管理が面倒で「共通にしてしまえ」という手抜き

歴史と背景

  • 1970年代〜 — メインフレーム時代。端末数が限られており、オペレーター間でIDを共有する運用が珍しくなかった
  • 1990年代 — クライアント・サーバー型システムの普及で個人PCが一般化。個人ログインの概念が広がり始める
  • 2000年代 — SOX法（サーベンス・オクスリー法）や日本の J-SOX（内部統制報告制度） が施行。ログの証跡確保が法令上の義務となり、共有アカウントは「内部統制上のNG事項」として明文化される
  • 2004年 — PCI DSS v1.0 策定。クレジットカード情報を扱うシステムで「各ユーザーに固有のIDを割り当てること」が要件に
  • 2013年 — ISO/IEC 27001:2013 改訂。アクセス制御ポリシーとして個人アカウントの管理が強調される
  • 2020年代 — ゼロトラストセキュリティの普及で「誰が・いつ・何に・どこからアクセスしたか」の完全な把握が前提となり、共有アカウントは根本的に非互換な存在として排除が加速

個人アカウントと共有アカウントの比較

個人アカウント vs 共有アカウント ✅ 個人アカウント 操作ログが個人に紐づく → 「誰が」を即座に特定できる 退職時に即アカウント削除 → アクセス経路を確実に遮断 権限を個人単位で最小化 → 最小権限の原則を実現 MFA（多要素認証）を適用可能 → 本人確認の精度が上がる 監査・コンプライアンス対応 → ISO27001・PCI DSS要件を満たす ❌ 共有アカウント ログが「誰か」を示さない → 不正の追跡・証明が不可能 退職者がそのまま使い続けられる → 不正アクセスのリスクが残存 権限を絞れない → 不要な権限が常に開放状態 MFAが機能しない → 「誰の」デバイスか不明 監査・コンプライアンス違反 → 認証取得・維持ができない

実務でよくある「でも…」への回答

「ライセンス費用が高くて1人1つ買えない」 → 共有アカウントを使うことで発生するインシデント対応コスト・コンプライアンス違反の罰金の方がはるかに高い。ライセンス形態の見直しやSaaS切り替えを検討する。

「たまにしか使わない人のために買うのがもったいない」 → アクセス頻度が低い人こそ「本当に権限が必要か」を見直すタイミング。不要なら削除、必要なら個人アカウントを発行。

「古いシステムがアカウント数の上限を設けている」 → それ自体がシステムの寿命のサイン。リプレースの際に個人アカウント対応を必須要件に入れる。

関連する規格・RFC

規格・基準共有アカウント禁止に関する記述
ISO/IEC 27001:2022A.5.16「識別情報の管理」— 各ユーザーへの固有IDの割り当てを要求
PCI DSS v4.0要件8.2.1 — 「すべてのユーザーに固有のIDを割り当てること」を明示
NIST SP 800-53AC-2「アカウント管理」— 共有・グループアカウントの使用制限を規定
J-SOX（内部統制報告制度）アクセスログの証跡確保のため個人アカウント管理を間接的に要求
GDPR（EU一般データ保護規則）Article 32 — 個人データへのアクセス管理として個人認証を前提とする

関連用語