# 共有ツールの ID とパスワードが盗まれて侵入された事案から分かる、ID の発行と管理、多要素認証

正規の ID とパスワードが盗まれ、正常なログインに見える形で顧客から預かった情報が窃取されました。影響は 142 の顧客に及び、検証委員会は情報保護の体制と利用組織ごとの管理の不備を指摘しました。

更新日: 2026-09-18

2021 年 5 月 25 日、ある情報サービス会社が、プロジェクトの情報を関係者で共有するツールへの第三者からの[不正アクセス](/guides/incidents/what-is-unauthorized-access)を公表しました。顧客から預かった情報の一部が盗まれた、という内容です。以後、2022 年 4 月 22 日の第六報まで 6 回にわたって公表しています。

## 何が起きたか

初報の時点で会社は、さらなる不正アクセスを防ぐためそのツールの運用を停止し、影響範囲と原因を調査中としました。第二報は、第三者が正規の ID とパスワードを使い、正常な認証と通信によって外部から不正アクセスを行ったものだとしています。ツールの何らかの欠陥を悪用した可能性が高い、とも書いています。影響を受けた顧客は 129 とされ、第五報で 142 に改められました。

第四報は、そのツールに数種類の欠陥があったことを確認したものの、悪用された欠陥の特定には至らなかったとしています。そのうえで、第三者がそのいずれかを使うなどして正規の ID とパスワードを盗んだ、と判断しています。

## 公表された原因

第六報の別紙は、外部の有識者で構成された検証委員会の指摘をまとめています。不正アクセスの原因は 4 点です。

1. 情報保護の体制が不十分だった。
2. 人員・予算の制約などから、そのツールのセキュリティの強化・管理に手が回らなかった。
3. 不正アクセスを直ちに検知する体制が整っていなかった。
4. 利用する会社ごとの環境の管理の多くが、その会社側の管理者に任されていた。

発覚後の対応が遅れた原因は 6 点挙がっています。そのうち ID と記録の管理に関わる 2 点は、個別プロジェクトの問題という前提で対応したことと、属人的な運用と記録の管理が適切でなくツールの構造の把握に時間を要したことです。真因として委員会が挙げたのは次の 4 点です。「当初の想定より幅広い環境と目的でなし崩し的に使われ、その性質や利用状況に沿った扱いがされていなかったこと」「組織が縦割りの傾向にあり、社内システムの管理が全社で一元的に行われていなかったこと」「利便性やコスト削減の意識から、情報管理やセキュリティが優先されない場合があったこと」「インシデント対応で主体的に先手を打つ姿勢が十分でなかったこと」です。

## 公表された再発防止策

第四報は、そのツールに代わる新しいツールの方針を書いています。多要素認証(2 つ以上の方法でログインを確かめる仕組み)で不正ログインを防ぎ、複数の記録を一元的に集めて不審な動きを監視する、という内容です。第六報は再発防止策を 5 項目にまとめました。項目の名前と、公表文の要点は次のとおりです。

1. セキュリティ対策強化と管理・監督の徹底。セキュリティの枠組みを標準化し、多要素認証の導入や情報管理の厳格化を行う。CISO(情報セキュリティの責任者)直轄の組織が監査・監視・是正を行う。
2. セキュリティインシデント対応の強化。事故対応の体制を強化する。
3. 社内 IT システムの一元管理と各プロジェクト部門の自律的な是正促進。社内のシステムを一元的に管理し、各部門の是正を促す。
4. 全社のセキュリティ意識徹底とリテラシー向上に向けた教育、制度の見直し。教育と制度を見直す。
5. 対外コミュニケーションの改善。顧客や関係当局への情報伝達を改める。

検証委員会の提言 8 項目には、社内 IT システムの一元管理と各システムの位置づけの明確化が含まれます。情報管理やセキュリティを利便性やコスト削減に劣後させない風土づくりも、その 1 つです。

## 同じ型の事故で一般に問われる管理

複数の会社や案件の関係者が 1 つのツールを使う場面では、ID を誰に発行し、誰が管理し、いつ消すかが問われます。

IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部 実践編で、ユーザー ID と管理者 ID の発行・変更・削除の手続きを定めるよう勧めています。発行から削除までを管理する手順を作り、ID は必要な人にだけ与える、という内容です。共有 ID はなるべく使わず、やむを得ず使う場合は、共有 ID を使った人を特定できる仕組みを整えて運用することも挙げています。アクセス権限の運用や利用状況を監視する仕組みも勧めています。ID の管理を各部門や各案件の管理者に任せる場合でも、全体の手順と監視の仕組みは会社側で持つ、という考え方です。

米国 NIST の SP 800-63B(ログインの本人確認についての基準)第 4 版は、本人が意図してログインの秘密を共有する行為は技術的に検知・防止しにくい、と書いています。1 人 1 ID にしても、ID とパスワードを人から人へ渡す運用が残れば、誰が使ったかは記録に残りません。パスワードの使い回しについての NIST の考え方は、アカウントの乗っ取りの型の記事で扱っています。

## 自分の現場を点検する問い

1. 取引先や委託先と共有しているツールの ID は、誰が発行し、誰が一覧を持っているか。
2. 案件が終わった後、その案件用の ID を消す手順と期限があるか。
3. 1 つの ID を複数の人で使っているツールで、使った人を特定できる記録があるか。
4. ID とパスワードだけでログインできるツールに、2 つ目の確認を付けられるか。
5. 各部門・各案件の管理者に任せている設定を、会社側が定期的に確かめているか。


## よくある質問

**正規の ID でログインされる攻撃は防げますか**

公表文は、第三者が盗んだ正規の ID とパスワードで、正常な認証に見える形でアクセスしたとしています。会社が挙げた再発防止策は、多要素認証と、記録を一元的に集めた監視です。

**そのツールはその後どうなりましたか**

初報で運用を停止し、第四報で新しいツールへ移行して利用を終了すると判断したことを公表しています(終了の時期は書かれていません)。新しいツールは多要素認証と記録の一元管理を行います。

**影響を受けた顧客はいくつですか**

第二報で 129、第五報で 142 に改められました。案件数や、盗まれた情報の種類は公表文に書かれていません。

## 参考資料

- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html)

## Junify の場合

**人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。

**Junify なら** Junify を使っていれば、この経路は成立しません。ID とパスワードは管理者が登録し、担当者には渡さないからです。担当者の手元にパスワードがなければ、そこから盗んで使うことはできません。認証アプリに出るコードも Junify が入力し、案件が終われば割り当てを外すだけです。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。
- [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。
- [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。