この記事のポイント
- 富士通は 2021年5月6日に ProjectWEB で不正アクセスの可能性を認知し、5月25日に初報と運用停止を公表しました。
- 8月11日の第二報では 129 のお客様、2022年3月7日の第五報では 142 のお客様へ更新されており、数字の差は後続調査の反映です。
- 第四報と第六報では、数種類の脆弱性、正規 ID とパスワードの窃取、多要素認証や一元管理、新ツール移行などの再発防止が示されています。
まず無料で確認する
無料でASM診断を開始
富士通 ProjectWEBで触れている論点は、自社ドメインを実際に診断すると優先順位が掴みやすくなります。まずは外部公開資産を無料で可視化してください。
富士通 ProjectWEB の不正アクセスで何が起きたのか
この事案は、1社ごとの個別事故として見るより、複数の顧客プロジェクトが載る共有基盤で起きた不正アクセスとして読む方が全体像をつかみやすくなります。
最初に固定したいのは、5月6日の認知と 5月25日の初報を分けて読むことです
富士通 ProjectWEB 事案で最初に押さえたいのは、社内で不正アクセスの可能性を認知したのは 2021年5月6日であり、対外的な初報は 5月25日だという点です。2021年8月11日の第二報は、5月6日に不正アクセスの可能性を認知して調査を始めたと説明しています。一方、5月25日の初報では、情報窃取の判明と ProjectWEB の運用停止を公表しています。
つまり、この事案は 5月25日に突然発生したのではなく、5月6日から 5月25日までのあいだに、影響範囲と原因を探りながら運用停止と対外公表へ進んだ事案です。この順番を見落とすと、「初報が遅かった事案」だけに見えやすくなりますが、公式発表を素直に読むと、内部認知から初報までの調査期間が挟まっています。
主役は個別案件ではなく、複数顧客の情報を扱う ProjectWEB という共有ツールです
初報と後続報告が共通して主語にしているのは、富士通がプロジェクト運営に際し社内外の関係者と情報を共有するためのツール「ProjectWEB」です。ここが重要で、特定の一社専用環境で起きた事故ではなく、複数のお客様のプロジェクトが載る共有基盤に対する不正アクセスとして読む必要があります。
この読み方を取ると、一般の情報漏えい事案とも切り分けやすくなります。たとえばLINEヤフーの事案は委託先経由の境界管理が主役で、IIJ の事案はメールセキュリティ基盤が主役でした。ProjectWEB 事案では、顧客プロジェクト共有基盤での不正閲覧・ダウンロードが主役です。
時系列で見ると、何が順番に分かったのか
この事案を短時間で追うなら、5月6日の認知、5月25日の初報、8月11日の 129 社公表、9月24日の専任 CISO 任命、12月9日の原因整理と新ツール移行、2022年3月7日の 142 社更新、4月22日の総括という 7 つに分けると読みやすくなります。特に129 社と 142 社は別の段階で公表された数字であり、後者は後続調査による更新です。
5月6日に不正アクセスの可能性を認知し、調査を開始
富士通は第二報で、2021年5月6日に ProjectWEB を利用する一部プロジェクトで不正アクセスの可能性を認知し、調査を開始したと説明しています。読者が最初に押さえるべき起点は、初報日の5月25日ではなく、内部で事象を把握した5月6日です。
認知: 5月6日に調査開始5月25日に初報を出し、ProjectWEB の運用停止を公表
5月25日の初報では、ProjectWEB を利用する一部プロジェクトに第三者からの不正アクセスがあり、お客様から預かった情報の一部が不正に窃取されたこと、さらに不正アクセスが起きないよう ProjectWEB の運用を停止したことを公表しました。この時点では影響範囲と原因は調査中とされています。
初報: 運用停止を公表第二報で 129 のお客様と、正規ID・パスワード悪用の構図を公表
8月11日の第二報では、129のお客様に関して ProjectWEB に保存されていた情報の一部が不正に閲覧またはダウンロードされたと公表しました。同時に、第三者が正規の ID とパスワードを使用し、正常認証と正常通信に見える形で外部から不正アクセスしたこと、何らかの脆弱性悪用の可能性が高いことも示されています。
公表: 129社と認証悪用第三報で 10月1日付の専任 CISO 任命と体制強化を告知
9月24日の第三報では、10月1日付で専任 CISO と CISO 補佐を任命し、情報管理のあり方も含めた新たな情報セキュリティ体制へ移ると公表しました。ここから話題は、被害公表だけでなく、全社統制の立て直しへ進みます。
体制: 専任 CISO を任命第四報で、数種類の脆弱性と新ツール移行を公表
12月9日の第四報では、ProjectWEB に数種類の脆弱性が存在していたこと、悪用された脆弱性の特定には至らなかったこと、第三者がそのいずれかを用いるなどして正規の ID とパスワードを窃取し正常認証で侵入したと判断していることが示されました。あわせて、ProjectWEB を終了し、新ツールへ移行する方針も公表されています。
原因整理: 脆弱性と新ツール移行第五報で被害のあったお客様数が 129 から 142 へ更新
2022年3月7日の第五報では、被害のあったお客様数は 129 と伝えてきたが、外部からの協力などにより 142 となったことが判明したと公表しました。検索でよく見かける 129社と 142社の差は、この更新によるものです。
更新: 129社から142社へ第六報で検証委員会の提言と再発防止策を公表
2022年4月22日の第六報では、3月28日に検証委員会の調査・検証報告書を受領したこと、その提言を受けて多要素認証、情報管理厳格化、監査・監視、社内 IT システムの一元管理、教育、対外コミュニケーション改善を進めることを示しました。ここで初めて、総括に近い形の再発防止が見えてきます。
総括: 提言と再発防止8月11日の第二報で、初めて被害の輪郭と認証悪用の構図が見えました
第二報の重要性は、単に件数を出したことだけではありません。129 のお客様に関して一部情報が不正に閲覧またはダウンロードされたことに加え、第三者が正規の ID とパスワードを使い、正常認証と正常通信に見える形で外部から侵入したと説明している点にあります。ここで初めて、「ただの脆弱性問題」でも「ただの認証情報流出」でもなく、両者が重なった構図が見えます。
閲覧またはダウンロードされた情報の中身も、システム構成情報、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料、そして一部の個人情報と幅があります。したがってこの事案は、単純に名簿が漏れた事故ではなく、プロジェクト運営に関する実務資料がまとまって見られた可能性がある事故と理解した方が実態に近いです。
12月9日の第四報で「どの脆弱性か未特定だが、正常認証で侵入した」という整理が固まりました
第四報では、ProjectWEB に数種類の脆弱性が存在していたことは確認された一方で、悪用された脆弱性の特定には至らなかったと説明されています。そのうえで、第三者がいずれかの脆弱性を用いるなどして正規の ID とパスワードを窃取し、それを使って正常認証・正常通信に見える形で外部から不正アクセスしたと判断したと公表しています。
ここを誤読すると、「脆弱性があったのか、認証情報が悪用されたのか、どちらなのか」が曖昧に見えます。公式発表の立て付けはそうではなく、脆弱性の存在と、正規 ID・パスワードの悪用が連動したと読むのが自然です。だからこそ、再発防止も脆弱性修正だけで終わらず、多要素認証や体制変更、新ツール移行まで広がっています。
129社から142社へ何が更新されたのか
| 論点 | 公式発表で確認できること | 読み方のポイント |
|---|---|---|
| 最初に公表された被害社数 | 2021年8月11日の第二報で 129 のお客様 | この時点で不正閲覧またはダウンロードが判明した範囲です。 |
| 更新後の被害社数 | 2022年3月7日の第五報で 142 のお客様 | 外部からの協力等により、後続調査で更新された数字です。 |
| 見られた可能性のある情報 | 機器類情報、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料、一部の氏名・メールアドレス等 | 単なる連絡先ではなく、プロジェクト運営に関する資料群まで含まれます。 |
| 認証の見え方 | 正規の ID とパスワードによる正常認証、正常通信に見える形 | 検知や切り分けが難しくなりやすい構図です。 |
| 最終的な対応 | ProjectWEB 利用終了、新ツール移行、CISO 主導の再発防止 | 個別パッチで延命せず、共有基盤を入れ替える判断まで進みました。 |
129社と 142社の差は、調査が進んだ結果の更新であって、別事件ではありません
検索では「129 社」と「142 社」の両方が並ぶため、別の事故のように見えやすいですが、第五報を読むとそうではありません。富士通はこれまで 129 と伝えてきたが、外部からの協力等によって 142 となったことが判明したと説明しています。つまり、後者は第二報までの説明を否定する数字ではなく、後続調査で被害範囲が更新された数字です。
したがって、この記事でも「129 社だったが後に 142 社へ更新」と一続きで説明しています。このつながりを切って書くと、SERP で見た数字の違いだけが独り歩きしやすくなります。
見られた可能性があるのは、機微なプロジェクト資料そのものです
第二報で富士通が挙げている資料は、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料などです。これらは公開資料ではなく、案件運営の実務そのものが読める資料群です。その一部に氏名やメールアドレスといった個人情報が含まれていたことも確認されたとされています。
だからこそ、この事案は単なる「連絡先漏えい」でも「社内文書漏えい」でもなく、顧客プロジェクトの進行や構成情報を含む共有基盤が見られた事故と読む必要があります。この点は、SaaS ベンダーリスクの一般論と重なる部分はありますが、本記事では ProjectWEB 固有の公表内容に絞っています。
原因と再発防止で押さえるべき点
5月6日の認知、5月25日の初報、8月11日の129社、3月7日の142社を一連で読む
被害範囲の更新は段階的に起きており、どこか一報だけで全体像は見えないためです。
脆弱性の存在と正規 ID・パスワード悪用を分けずに読む
第四報は、脆弱性の存在と認証情報窃取が連動した構図として事案を整理しているためです。
ProjectWEB の延命ではなく、新ツール移行という判断まで確認する
個別修正だけではなく、共有基盤の位置付けを見直した点がこの事案の重要な結論だからです。
再発防止は多要素認証、監査・監視、一元管理、教育、対外コミュニケーションまでまとめて見る
第六報と検証委員会の提言が、技術対策だけでなく運用・風土まで含めているためです。
検証委員会の指摘は「脆弱性があった」だけで終わっていません
2022年4月22日の第六報に添付された検証委員会からご指摘頂いた事項は、原因を単なるシステム欠陥に絞っていません。情報保護体制の不十分さ、人員や予算制約からセキュリティ強化に手が回らなかったこと、不正アクセスを直ちに検知する体制の不足、テナント管理事項の多くがテナント管理者に委ねられていたことまで挙げています。
さらに発覚後の対応の遅れについても、個別プロジェクトの事故という前提で対応していたこと、属人的運用とログ管理不適切で構造把握に時間がかかったこと、情報の重要性や業務影響の想定が難しかったこと、セキュリティインシデント対応体制が機能しなかったこと、先手を打つ姿勢や準備が不足していたことなどが指摘されています。つまり、技術と組織運用の両方が原因と読むべきです。
再発防止も、システム更改だけでなく全社統制へ広がっています
第六報で富士通が示した再発防止は、多要素認証の実装や情報管理厳格化、CISO 直轄組織による監査・監視・是正管理、インシデント対応プロセス整備、社内 IT システム資産と情報管理の一元化、教育や制度見直し、対外コミュニケーション改善まで並んでいます。つまり、ProjectWEB のパッチや入れ替えだけではなく、全社のセキュリティ統制を組み直す話になっています。
その意味では、この事案は「共有ツールの脆弱性事故」と短く片づけるより、共有基盤の位置付けが曖昧なまま広く使われ、認証と監視と統制が追いつかなかった事故と読む方が自然です。だからこそ、新ツール移行と全社 CISO 体制強化が同じ文脈で出てきます。
事案後の公開接続点棚卸しなら ASM診断 PRO
ASM診断 PRO は ProjectWEB 事案そのものを防いだと主張する製品ではありません。正規 ID 悪用や共有基盤の内部統制を直接代替するものでもありません。ただし、事案後に外から見える接続点を棚卸しするとき、古いホスト、残存した案内ページ、特設問い合わせ導線、不要になったサブドメインを整理する入口としては使いやすい構成です。
特に共有基盤の事故後は、旧 URL や一時公開用ページが残りやすくなります。公開面の整理は原因そのものの是正とは別軸ですが、次の事故を減らすための運用として先に回しておく価値があります。
よくある質問（FAQ）
富士通はいつ ProjectWEB の不正アクセスを把握したのですか？
第二報によると、2021年5月6日に不正アクセスの可能性を認知し、調査を開始しています。対外的な初報は 5月25日です。
129社と 142社のどちらが正しいのですか？
どちらも公式発表に基づく数字ですが、時点が違います。2021年8月11日の第二報では 129 のお客様、2022年3月7日の第五報では後続調査を踏まえて 142 のお客様へ更新されています。
原因の脆弱性は特定されたのですか？
第四報では、ProjectWEB に数種類の脆弱性が存在していたことは確認された一方で、悪用された脆弱性の特定には至らなかったと説明されています。ただし、正規の ID とパスワードが窃取され、正常認証で侵入されたと判断しています。
どのような情報が見られた可能性があるのですか？
システムを構成する機器類に関する情報、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料などで、一部には氏名やメールアドレス等の個人情報も含まれていたと公表されています。
再発防止として何が変わったのですか？
専任 CISO 体制、多要素認証、監査と監視、社内 IT システムの一元管理、教育、対外コミュニケーション改善、新ツール移行が公表されています。システム修正だけではなく、全社統制の見直しまで広がっています。
まとめ
この事案は、脆弱性だけでも認証情報だけでもなく、共有基盤の位置付け、監視、統制をまとめて締め直す必要があった事故として読むと整理しやすくなります。
富士通 ProjectWEB の不正アクセスで押さえるべきなのは、5月6日の認知、5月25日の初報、8月11日の 129 社公表、12月9日の原因整理、2022年3月7日の 142 社更新、4月22日の再発防止という流れです。主役は個別案件ではなく、複数顧客の情報を扱う共有基盤であり、正規 ID とパスワードの悪用、脆弱性、監視不足、統制不足が重なった事案でした。
また、129 社と 142 社は別事件ではなく、後続調査による更新です。最終的には ProjectWEB を終了し、新ツール移行、多要素認証、監査・監視、一元管理、教育まで含む再発防止へ進みました。まずはこの順番で一次資料を押さえ、そのうえで自社の共有基盤や公開接続点の棚卸しへ落とし込むのが自然です。
次のアクション
読み終えたら、無料でASM診断を開始
外部公開資産の現状を無料で確認し、管理漏れや優先して見るべきリスクを洗い出してください。記事で読んだ内容を、そのまま自社の判断へつなげやすくなります。
参考にした一次ソース
重要論点の根拠として参照した一次ソースだけを掲載しています。
2021年5月25日。初報、情報窃取判明、ProjectWEB 運用停止を確認するために参照しました。
2021年8月11日。5月6日の認知、129のお客様、閲覧・ダウンロード対象、正規 ID とパスワードの悪用を確認するために参照しました。
2021年9月24日。10月1日付の専任 CISO 任命と体制強化を確認するために参照しました。
2021年12月9日。数種類の脆弱性、悪用脆弱性未特定、正規 ID とパスワード窃取、新ツール移行方針を確認するために参照しました。
2022年3月7日。被害のあったお客様数が 129 から 142 へ更新されたことを確認するために参照しました。
2022年4月22日。検証委員会報告受領、多要素認証、監査・監視、一元管理、教育、対外コミュニケーション改善を確認するために参照しました。
2022年4月22日。情報保護体制、検知不足、テナント管理、属人的運用、風土改善などの指摘事項を確認するために参照しました。