共有アカウントにおけるリスクと最適な管理方法

組織内の重要なアカウントを不適切に共有してしまうと、内部脅威などによって大規模な侵害に繋がる可能性があります。

しかし、組織内でどうしても共有しなければいけないアカウント情報のリスクについてどう対処すべきかお悩みではありませんか？

そこで、本ブログでは、共有アカウントに潜む一般的なリスクに加え、共有を避けることが難しい特権アカウントの具体例を取り上げ、適切に管理するためのベストプラクティスをご紹介します。

共有アカウントのよくあるリスク

共有アカウントの使用は、一見すると業務の効率化につながるように思えます。しかし、適切に管理されていない場合、あらゆる危険性があります。そこで、ここでは、共有アカウントに関する代表的なリスクを紹介します。

リスク1: 誰がいつどのようにアカウントを使用したのか不明

共有アカウントは複数のユーザーが同じ認証情報を使うため、誰がどの操作を行ったのか特定するのが難しくなります。

その結果、情報漏洩や誤操作が発生しても責任の所在が曖昧になり、迅速な対応ができない可能性があります。特に、セキュリティインシデントが発生した際に、その原因を特定できなければ、被害の拡大を防ぐことが難しくなります。

リスク2: 情報漏洩のリスクが高い

共有アカウントは複数の人に認証情報を伝えることが前提となっているため、パスワードが適切に管理されず、情報流出するリスクが高まります。

例えば、アクセス制御が細かく実施できていなかったり、パスワードのロテーションがされないままだと、退職者や一時的な業務委託先が引き続きアクセスできる状態が続く恐れがあります。

実際に、日本の大手不動産会社では、退職した後もアカウントがそのまま同じ認証情報で使われていたケースもあり、実際に大きな被害を出した事例もあります。このように、内部脅威のリスクがさらに高まります。

また、共有アカウントでは多要素認証（MFA）の適用が難しく、パスワードが漏えいした場合、攻撃者が簡単にログインできてしまいます。さらに、パスワードがメモ帳に書かれたり、スプレッドシートやエクセル上に保存されたりするケースもあり、こうした管理の甘さが情報漏洩の要因となります。

リスク3: 利用規約違反に該当することがある

クラウドサービスやSaaSの多くは、個人単位での利用を前提としており、共有アカウントの使用を禁止している場合があります。利用規約に違反すると、アカウントの凍結や契約の解除といった措置が取られる可能性があり、業務の継続に支障をきたす恐れがあります。

リスク4: 監査やコンプライアンス対応が困難になる

共有アカウントでは、「誰が」「いつ」「どのような操作をしたのか」を正確に記録することが難しく、監査対応が困難になります。例えば、EUのGDPR（一般データ保護規則）やISO 27001に準拠したISMSなどの規制では、アクセス管理の透明性が求められるため、共有アカウントの使用は問題視されることが多く、「誰が」「いつ」「どのような操作をしたのか」を正確に記録されることが求められます。

セキュリティインシデントが発生した際に、アクセスログの記録が不十分だと、原因特定や対策の遅れにつながる可能性だけでなく、取引先や投資家からの信頼を失うリスクもあります。

個人に紐づかない共有されがちな特権アカウントの種類

組織内では、業務の効率化や技術的な要件から、個人に紐づかない特権アカウントが共有されることが少なくありません。しかし、これらのアカウントは強い権限を持つため、適切に管理されていないと、不正アクセスや内部不正のリスクを高める要因となります。そこで、ここでは、特に共有されがちな特権アカウントの種類とそのリスクについて解説します。

管理者アカウント

管理者アカウントは、システムやネットワークの設定を変更できる強い権限を持ち、IT管理者やセキュリティ担当者が使用することが一般的です。

しかし、管理者アカウントが複数の担当者によって共有されると、誰がどの操作を行ったのかを特定することが困難になります。

例えば、Windowsサーバーの「Administrator」アカウントやLinuxの「root」アカウントを複数人で共有して使用すると、特権アクセス管理ソリューションなどを使用していない場合、サーバーの設定変更やユーザー権限の更新、ソフトウェアのインストールなどの操作が誰によって実施されたのか特定することができません。

そのため、システム障害や情報漏洩が発生した際に、原因の特定が難しくなるだけでなく、不正行為があった場合でも責任の所在が不明確になるリスクがあります。

さらに、管理者アカウントのパスワードが一度流出すると、攻撃者は広範な権限を持つシステムに自由にアクセスできるため、組織内を水平展開し、組織全体のセキュリティが大きく損なわれる可能性があります。

サービス・システム連携用アカウント

システム間のデータ連携や外部サービスとの統合のために利用されるアカウントは、特定の個人ではなくシステムやアプリケーションに紐づいているため、管理が曖昧になりやすい傾向があります。例えば、社内の認証システムとクラウドサービスを連携させるための「Azure ADアプリ登録アカウント」や、企業内データベースにアクセスする「MySQLのサービスアカウント」などが該当します。

このようなアカウントは、人が直接ログインすることは少ないものの、システムの重要なデータへアクセスできる高い権限を持ったシークレット情報のため、適切な管理がされていないと第三者による不正利用のリスクが生じます。特に、クラウド環境で利用される「AWS IAMロール」や「Google Cloudサービスアカウント」の認証情報が適切に制限されていない場合、外部の攻撃者がこれらを悪用し、機密データへ不正にアクセスする危険性があります。

さらに、API連携のための認証情報がハードコード（ソースコード内に埋め込まれること）されている場合、開発者や関係者が容易にアクセスでき、意図せず情報が漏洩する可能性が高まります。例えば、「GitHub Actionsのシークレットキー」が適切に管理されず、リポジトリ内に残ってしまうと、外部に公開されるリスクがあります。

アプリケーション共有アカウント

業務アプリケーションやクラウドサービスの利用において、複数の従業員が同じアカウントを使用するケースは少なくありません。たとえば、マーケティングチームが投稿やフォロワーとのやり取りを行うために使用するInstagramやX（旧Twitter）の共有ソーシャルメディアアカウント、あるいは複数のメンバーがウェブサイトのパフォーマンスを確認するために利用するGoogle アナリティクスの共有ログインなどが挙げられます。

このようなアカウントの問題点は、アクセス履歴の追跡が難しくなることです。例えば、複数人で「Google Workspace」の共有アカウントを使用している場合、誰がどのドキュメントを編集したのか特定することができません。このように、共通アカウントを使うと、誰がどのファイルをダウンロードしたのか分からず、情報の不正な持ち出しや誤操作によるデータ改ざんのリスクが高まります。また、共通アカウントはパスワードを頻繁に変更しづらい環境になりやすく、退職者や異動者が引き続きアクセスできる状態が放置される可能性もあります。

特権アカウントなどの共有アカウントのベストプラクティス

特権アカウントや業務上やむを得ず共有されるアカウントは、適切な管理が行われないとセキュリティリスクを招く原因となります。そこで、ここでは特権アカウントなどの共有アカウントにおけるベストプラクティスをご紹介します。

できる限り個人アカウントの利用を優先

最も基本的な対策として、アカウントの共有は避けて、可能な限り個人アカウントを使用することが推奨されます。例えば、「Google Workspace」などの業務ツールで、ユーザーごとにアカウントを発行し、個別の認証情報を管理することで、アクセス履歴の追跡が可能になります。

特に、特権アカウントが必要な場合は、一時的に権限を付与する仕組みを導入することで、共有アカウントの利用を最小限に抑えることができます。

自動パスワードローテーションを導入する

共有アカウントを使用せざるを得ない場合、パスワードの管理が重要になります。パスワードを固定したままにすると、退職者や異動者が引き続きアクセスできる状態が続いたり、不正アクセスのリスクが高まったりします。

そこで、KeeperPAMのようなPAMソリューションを活用し、自動的にパスワードを自動でローテーションする仕組みを導入することで、このようなリスクを低減させることができます。

多要素認証を有効にする

パスワードのみの認証では、フィッシング攻撃や総当たり攻撃（ブルートフォース攻撃）に対して脆弱であるため、可能な限り多要素認証（MFA）を有効にすることが重要です。

共有アカウントに二要素認証などのMFAを有効にすることで、たとえパスワードが漏洩したとしても、追加の認証要素が求められるため、不正アクセスのリスクを大幅に低減できます。

しかし、共有アカウントに個人ごとのMFAを適用することは難しく、一般的なMFAの仕組みでは、特定の個人に紐づいた認証デバイスが求められるため、運用上の課題が生じます。

この問題を解決する方法の一つとして、二要素認証コードをパスワード管理ツールやセキュアなボルトで共有し、必要なユーザーのみがアクセスできるようにする運用が考えられます。例えば、KeeperPAMのようなツールを活用することで、共有アカウントの認証情報とMFAコードを安全に保管し、必要なときにのみ認証情報を取得できる仕組みを構築できます。

アカウントのログの取得と監査

共有アカウントの利用を完全に防ぐことが難しい場合でも、アクセス履歴を記録し、定期的に監査を行うことで、不正アクセスのリスクを抑えることができます。適切なログ管理ができていないと、インシデント発生時に原因の特定が困難になるため、特に共有アカウントでは「誰が」「いつ」「どの操作を行ったのか」を明確にすることが重要です。アクセスログの取得には、SIEM（Security Information and Event Management）ツールを活用し、異常なアクセスパターンを分析することが有効です。

しかし、SIEM単体では、共有アカウントの利用において「誰が操作を行ったのか」という特定が難しい場合があります。

この課題を解決するために、PAMとSIEMを統合することで、特権アカウントのアクセス管理をより厳格にすることができます。PAMを導入することで、共有アカウントの使用時に個人の認証を追加し、操作の記録を取得できるため、「どの従業員が」「いつ」「どのような操作を行ったのか」を明確にできます。さらに、PAMが取得したセッションログやコマンド履歴をSIEMに連携することで、特権アクセスの監視と分析を強化し、より高度なセキュリティ対策を実現できます。

最小権限の原則に基づいたアクセス制御

最小権限の原則（Principle of Least Privilege）とは、ユーザーやシステムに対して業務に必要最小限の権限のみを付与することで、セキュリティリスクを低減するアプローチです。この原則を守ることで、万が一アカウントが侵害された場合でも、被害範囲を限定できるほか、誤操作や内部不正の防止にもつながります。特に、共有アカウントを利用する場合、この原則を適用しないと、不要な権限を持つユーザーが増え、セキュリティ上のリスクが高まります。

最小権限を実現するためには、ロールベースアクセス制御（RBAC）を導入し、役職や業務ごとに適切な権限を割り当てることが重要です。例えば、データベースにアクセスする共有アカウントがある場合、すべてのデータを編集できる権限を与えるのではなく、特定のデータの読み取りのみを許可することでリスクを低減できます。

また、特定の操作に対して一時的に権限を付与するジャストインタイムアクセスを実施すれば、不要な特権の付与を防ぐことができます。

パスワードのベストプラクティスに従う

共有アカウントを運用する場合でも、パスワードの適切な管理が欠かせません。適切なパスワードポリシーを設定し、強力なパスワードを使用することで、アカウントへの侵害を防ぐことができます。特に、パスワードの長さや複雑性を確保し、辞書攻撃や総当たり攻撃に耐えられるものを設定することが重要です。最低でも16文字以上のパスワードを使用し、英字（大文字・小文字）、数字、記号を組み合わせることで、安全性を高めることが推奨されます。

さらに、パスワードの保存方法も適切に管理する必要があります。共有アカウントのパスワードをメモやスプレッドシートに記録するのではなく、セキュアなパスワード管理ツールを使用することで、安全に保管しつつ必要なユーザーだけがアクセスできるように制御できます。

まとめ：組織の共有アカウントはPAMなどの管理が求められる

組織で共有アカウントを運用する場合、適切な管理を行わなければ、セキュリティリスクが高まります。

パスワードの強度や管理方法、多要素認証の設定、アクセスの監査、最小権限の原則の適用など、適切な対策を講じることで、内部脅威や情報漏えいのリスクを抑えることができます。

しかし、これらを手動で管理しようとすると、パスワードの共有や更新が煩雑になり、適切に管理されないまま放置されるリスクがあります。また、アクセスの追跡がほぼ不可能になり、ヒューマンエラーによって、誤ったパスワードの共有やアクセス権の設定ミスが発生し、大きなセキュリティインシデントにつながる可能性もあります。

そのため特に、KeeperPAMのようなPAMソリューションを活用することで、パスワードの自動ローテーションやアクセスの記録・監査、動的なアクセス制御などを実現し、より安全に特権アカウントを含む共有アカウントの運用が可能になります。
KeeperPAMのデモをリクエストして、組織の共有アカウントを含む特権アカウントをどのように保護できるかをご確認ください。