富士通 ProjectWEBの不正アクセスとは？129社→142社・正規ID悪用・原因・再発防止を整理

富士通 ProjectWEB の不正アクセスで何が起きたのか

最初に固定したいのは、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 社は別の段階で公表された数字であり、後者は後続調査による更新です。

8月11日の第二報で、初めて被害の輪郭と認証悪用の構図が見えました

第二報の重要性は、単に件数を出したことだけではありません。129 のお客様に関して一部情報が不正に閲覧またはダウンロードされたことに加え、第三者が正規の ID とパスワードを使い、正常認証と正常通信に見える形で外部から侵入したと説明している点にあります。ここで初めて、「ただの脆弱性問題」でも「ただの認証情報流出」でもなく、両者が重なった構図が見えます。

閲覧またはダウンロードされた情報の中身も、システム構成情報、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料、そして一部の個人情報と幅があります。したがってこの事案は、単純に名簿が漏れた事故ではなく、プロジェクト運営に関する実務資料がまとまって見られた可能性がある事故と理解した方が実態に近いです。

12月9日の第四報で「どの脆弱性か未特定だが、正常認証で侵入した」という整理が固まりました

第四報では、ProjectWEB に数種類の脆弱性が存在していたことは確認された一方で、悪用された脆弱性の特定には至らなかったと説明されています。そのうえで、第三者がいずれかの脆弱性を用いるなどして正規の ID とパスワードを窃取し、それを使って正常認証・正常通信に見える形で外部から不正アクセスしたと判断したと公表しています。

ここを誤読すると、「脆弱性があったのか、認証情報が悪用されたのか、どちらなのか」が曖昧に見えます。公式発表の立て付けはそうではなく、脆弱性の存在と、正規 ID・パスワードの悪用が連動したと読むのが自然です。だからこそ、再発防止も脆弱性修正だけで終わらず、多要素認証や体制変更、新ツール移行まで広がっています。

129社から142社へ何が更新されたのか

129社と 142社の差は、調査が進んだ結果の更新であって、別事件ではありません

検索では「129 社」と「142 社」の両方が並ぶため、別の事故のように見えやすいですが、第五報を読むとそうではありません。富士通はこれまで 129 と伝えてきたが、外部からの協力等によって 142 となったことが判明したと説明しています。つまり、後者は第二報までの説明を否定する数字ではなく、後続調査で被害範囲が更新された数字です。

したがって、この記事でも「129 社だったが後に 142 社へ更新」と一続きで説明しています。このつながりを切って書くと、SERP で見た数字の違いだけが独り歩きしやすくなります。

見られた可能性があるのは、機微なプロジェクト資料そのものです

第二報で富士通が挙げている資料は、体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続き資料などです。これらは公開資料ではなく、案件運営の実務そのものが読める資料群です。その一部に氏名やメールアドレスといった個人情報が含まれていたことも確認されたとされています。

だからこそ、この事案は単なる「連絡先漏えい」でも「社内文書漏えい」でもなく、顧客プロジェクトの進行や構成情報を含む共有基盤が見られた事故と読む必要があります。この点は、SaaS ベンダーリスクの一般論と重なる部分はありますが、本記事では ProjectWEB 固有の公表内容に絞っています。

原因と再発防止で押さえるべき点

検証委員会の指摘は「脆弱性があった」だけで終わっていません

2022年4月22日の第六報に添付された検証委員会からご指摘頂いた事項↗は、原因を単なるシステム欠陥に絞っていません。情報保護体制の不十分さ、人員や予算制約からセキュリティ強化に手が回らなかったこと、不正アクセスを直ちに検知する体制の不足、テナント管理事項の多くがテナント管理者に委ねられていたことまで挙げています。

さらに発覚後の対応の遅れについても、個別プロジェクトの事故という前提で対応していたこと、属人的運用とログ管理不適切で構造把握に時間がかかったこと、情報の重要性や業務影響の想定が難しかったこと、セキュリティインシデント対応体制が機能しなかったこと、先手を打つ姿勢や準備が不足していたことなどが指摘されています。つまり、技術と組織運用の両方が原因と読むべきです。

再発防止も、システム更改だけでなく全社統制へ広がっています

第六報で富士通が示した再発防止は、多要素認証の実装や情報管理厳格化、CISO 直轄組織による監査・監視・是正管理、インシデント対応プロセス整備、社内 IT システム資産と情報管理の一元化、教育や制度見直し、対外コミュニケーション改善まで並んでいます。つまり、ProjectWEB のパッチや入れ替えだけではなく、全社のセキュリティ統制を組み直す話になっています。

その意味では、この事案は「共有ツールの脆弱性事故」と短く片づけるより、共有基盤の位置付けが曖昧なまま広く使われ、認証と監視と統制が追いつかなかった事故と読む方が自然です。だからこそ、新ツール移行と全社 CISO 体制強化が同じ文脈で出てきます。

日本企業がこの事案から学ぶべき点

共有基盤は『便利な社内ツール』ではなく、顧客情報を預かる基幹サービスとして扱うべきです

富士通 ProjectWEB 事案が重いのは、特定部署の補助ツールで起きた事故ではなく、複数顧客の案件資料と体制情報を預かる共有基盤で起きた事故だったからです。日本企業では、プロジェクト管理、ファイル共有、委託先連携の道具が「業務を回すための便利な基盤」として広く使われる一方、どこからが本番系と同等の統制をかけるべき基盤なのかが曖昧になりやすくなります。

しかし、案件資料、体制図、作業項目一覧、進捗管理表がまとまって載る共有基盤は、顧客情報を横断的に預かる高密度な蓄積点です。ここを一般的なファイル共有や部門ツールと同じ運用で扱うと、認証、監視、権限設計、委託先管理のどこかに穴が残りやすくなります。ProjectWEB 事案は、共有基盤を本番系と同等に扱うべき理由をはっきり示した事案です。

認証対策だけ、脆弱性対策だけでは止まりにくい事案でした

この事案の読みどころは、第四報が数種類の脆弱性の存在と正規 ID・パスワードによる正常認証を同じ流れで説明していることです。つまり、「脆弱性を塞げば終わる」「多要素認証だけ掛ければ終わる」といった単独対策ではなく、入口から運用までを一緒に締め直す必要がありました。

日本企業でも、共有基盤の事故を分析するときに、脆弱性、認証、監視、委託先管理を別々の担当へ切り分けすぎると、どこにも全体責任が残らない状態になりがちです。ProjectWEB 事案では、最終的に CISO 体制、監査・監視、一元管理、教育、対外コミュニケーションまで広がりました。これは、根本原因が一つの設定や一つの装置だけで閉じていなかったことを示しています。

共有基盤事故のあとに残りやすい『公開導線の後始末』も軽視できません

共有基盤の事故では、内部原因の是正と並行して、外から見える案内導線や旧 URL の整理も必要になります。問い合わせ窓口、説明用の特設ページ、旧ホスト名、新ツール移行前の残存導線が長く残ると、社外から見たときに「何が現役で何が停止済みか」が分かりにくくなります。

この点は、技術原因の説明だけでは埋まりません。自社で似た構成を持っている企業は、共有基盤の事故を読んだあとに、今の公開導線に古い名前や未整理の入口が残っていないかまで確認した方が安全です。事案の教訓を「共有基盤の統制」と「公開面の棚卸し」の二つに分けて持つと、再発防止が現場に落ちやすくなります。

共有基盤を持つ企業が自社へ返すべき確認項目

案件共有基盤に、どの種類の資料が集まるかを言える状態へ戻すべきです

ProjectWEB 事案を自社へ返すときに最初に確認したいのは、いま使っている案件共有基盤にどの種類の資料が集まり、誰が閲覧できるのかを説明できるかです。プロジェクト管理基盤は、導入当初は限定利用でも、時間がたつと体制図、進捗表、議事メモ、構成資料、問い合わせ履歴が集約しやすくなります。

その結果、権限設計は案件単位のつもりでも、実際には複数案件をまたぐ高密度な情報蓄積点になりやすくなります。共有基盤事故を防ぐ第一歩は、システム名ではなく、載っている情報の種類と濃さを棚卸しすることです。

委託先や協力会社の利用実態は、基盤管理とは別に持つ方が安全です

共有基盤の統制が崩れやすいのは、社内利用と委託先利用が同じ枠組みに載るからです。案件単位で外部協力会社が入れ替わる運用では、基盤管理者の一覧だけでは、実際の利用者像が見えません。ProjectWEB 事案も、複数顧客・複数関係者が集まる共有基盤だったことが重さを増幅させました。

そのため自社では、基盤の管理権限とは別に、「どの委託先が、どの案件で、どの情報へ届くか」を持つ方が安全です。管理者一覧と利用実態一覧を分けて持つだけでも、平時の見直しと事案後の切り分けはかなり進めやすくなります。

停止判断だけでなく、移行判断まで持てるかが共有基盤では重要です

ProjectWEB 事案では、運用停止、公表、後続調査のあとに、新ツール移行まで進みました。ここから学べるのは、共有基盤の事故ではいまの基盤を延命するか、切り替えるかを早めに考えないと、利用継続と再発防止がぶつかりやすいという点です。

自社でも、認証、監視、権限設計、委託先利用、公開導線の後始末まで見たうえで、「この基盤は修正で足りるのか、移行が必要なのか」を判断できる材料を持つべきです。共有基盤事故は、個別パッチだけで閉じず、基盤の位置付けそのものを問い直す事故になりやすいからです。

さらに、共有基盤の見直しでは、事故後に作る説明資料や問い合わせ導線も、どの基盤にひも付いているかを整理した方が安全です。案件共有基盤は周辺に説明用の補助導線が増えやすく、基盤停止後もしばらく残ることがあります。

そうした周辺導線まで含めて棚卸しすると、共有基盤の事故対応を「侵入原因の説明」だけで終わらせず、基盤の後始末と移行後運用まで一続きで設計しやすくなります。

さらに、共有基盤の事故では、基盤管理者が把握している構成と、案件現場が実際に使っている導線がずれていることがあります。ProjectWEB 事案を読むときも、現場運用と統制資料のずれを確認する観点を持つと、自社の見直し先が見えやすくなります。

自社に返す教訓としては、案件共有基盤を本番系と同等に扱い、委託先利用、移行判断、公開導線の後始末を一つの論点として見直すことです。共有基盤事故は、便利さの裏で統制が遅れた部分をまとめて洗い出す機会として読む方が実務に合います。

とくに、複数顧客案件をまたぐ共有基盤では、「どの案件の情報が、どの委託先や協力会社へ届くか」を言える状態へ戻すことが重要です。ProjectWEB 事案は、共有基盤の便利さが統制の遅れを覆い隠しやすいことを示した事案として読むと、自社の確認項目を作りやすくなります。

共有基盤を持つ企業は、この事案を「大企業の昔の事故」と流さず、自社の案件共有基盤を本当に説明できるかを確かめる材料として使うべきです。

共有基盤の事故は、停止判断だけでなく、基盤の位置付けを再定義する機会として読むと実務に返しやすくなります。

ProjectWEB 事案は、共有基盤を本番系として扱う必要性を示した事案でした。

共有基盤の説明責任を持つことが、再発防止の起点になります。

共有基盤を持つ企業は、この事案を自社の権限設計、委託先利用、移行判断へ引き戻して読むべきです。

事案後の公開接続点棚卸しなら ASM診断 PRO

ASM診断 PRO は ProjectWEB 事案そのものを防いだと主張する製品ではありません。正規 ID 悪用や共有基盤の内部統制を直接代替するものでもありません。ただし、事案後に外から見える接続点を棚卸しするとき、古いホスト、残存した案内ページ、特設問い合わせ導線、不要になったサブドメインを整理する入口としては使いやすい構成です。

特に共有基盤の事故後は、旧 URL や一時公開用ページが残りやすくなります。公開面の整理は原因そのものの是正とは別軸ですが、次の事故を減らすための運用として先に回しておく価値があります。

たとえば、旧 Project 名を含むホスト名、停止済みの説明ページ、期限切れの問い合わせ導線、移行前の環境に向いた URL が残っていないかを外から確認できる形で洗い出すと、事案後の後始末が進めやすくなります。共有基盤の事故では、内部統制の見直しと公開面の整理が別担当になりやすいため、外部観点の棚卸しを並行して持つ価値があります。

もし自社でも、複数顧客向けポータル、案件共有基盤、委託先向け導線を持っているなら、事故が起きてから慌てて確認するのではなく、平時から外から見える接続点を一覧化しておく方が安全です。ASM診断 PRO は、その確認を小さく始める入口として使えます。

よくある質問（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 を終了し、新ツール移行、多要素認証、監査・監視、一元管理、教育まで含む再発防止へ進みました。まずはこの順番で一次資料を押さえ、そのうえで自社の共有基盤や公開接続点の棚卸しへ落とし込むのが自然です。

日本企業にとっての教訓は、共有基盤を「便利な社内ツール」と見なさず、顧客情報を横断的に預かる基幹サービスとして扱うことです。脆弱性、認証、監視、委託先管理のどれか一つだけではなく、共有基盤の位置付けと責任分界まで含めて見直さないと、同じ構造の事故は繰り返しやすくなります。

さらに、事故後は内部統制の再設計だけでなく、旧 URL や残存案内導線の整理も必要になります。ProjectWEB 事案を「昔の大規模事故」で終わらせず、自社の共有基盤と公開面を同時に見直すきっかけとして読むと、再発防止が実務へ落ちやすくなります。