Progress ShareFile Storage Zone Controllerの脅威：オンプレミスファイルストレージリスクへの影響

あるベンダーのセキュリティ通知により、世界中の組織が最も機密性の高い共有コンテンツを保存しているファイルサーバーの電源を物理的に落とす事態となりました。

Progress Softwareは2026年7月10日、ShareFileの顧客に「信頼性の高い外部からのセキュリティ脅威」がStorage Zone Controller（SZC）を標的にしていると警告するメールを送信しました。SZCは、エンタープライズが自社インフラ上にファイルを物理的に保存しつつ、ShareFileのクラウドベースの共有レイヤーを利用できるオンプレミスサーバーコンポーネントです（Help Net Securityより）。指示は明確で、SZCをホストしているWindowsサーバーの電源を直ちに切り、追加の通知があるまでそのままにするよう求められました。

7月13日までに、Progressは予防措置としてShareFileアカウントへの広範なアクセスを無効化し、攻撃者によるアカウントやファイルへのアクセスが実際に行われた証拠はないと報告しました。また、オンプレミスストレージコンポーネントに依存していない顧客には、クラウドアクセスの段階的な復旧も開始しました。

しかし、基本的な指示は変わっていません。組織がStorage Zone Controllerを運用している場合、Progressから別途指示があるまでオフラインのままにしておく必要があり、根本的な脆弱性経路は未修正かつ未確認のままです。

この「アクティブな脅威」「未解決の根本原因」「利用可能なパッチなし」という組み合わせが、ShareFileを利用していない組織にとっても本件を詳細に理解する価値がある理由です。Kiteworksは本件に一切関与しておらず、ShareFileデータを管理することもありません。ShareFileは競合する独立運営のプラットフォームです。

以下は、本件の公表されている事実に基づくKiteworksの分析と、ファイル転送やコラボレーションアーキテクチャを評価するエンタープライズが特に注目すべき、顧客運用型ストレージサーバーとベンダー管理・ハードニング済み導入の違いについて解説します。

主なポイント

1. Progressは信頼できる脅威を検知後、ShareFile Storage Zone Controllerへのアクセスを無効化。 ベンダーは7月10日に顧客へメールを送り、オンプレミスのStorage Zone Controller（SZC）をホストしているWindowsサーバーの電源を手動で落とすよう指示しました。

2. 最新の更新時点でデータ侵害は確認されていないが、調査は継続中。 Progressは7月13日、ShareFileアカウントやデータへの不正アクセスの兆候はないと発表しましたが、クラウドアクセスの段階的な復旧が進む中でも、顧客には引き続きSZCサーバーをオフラインにしておくよう求めています。

3. 事前認証リモートコード実行を実現するため、過去に公開された2つのCVEが連鎖利用された可能性。 オンラインのセキュリティ議論では、CVE-2026-2699およびCVE-2026-2701がその仕組みであると指摘されていますが、Progressは公式に根本原因を確認していません。

4. この脆弱性はProgressのクラウドではなく、顧客管理インフラに存在。 Storage Zone ControllerはオンプレミスのWindowsサーバーで、組織が自ら設置し、インターネットに公開し、独自にパッチを適用するもので、マルチテナント型のShareFileクラウドサービスとは別物です。顧客管理のインターネット公開型ストレージコンポーネントをすべて棚卸しし、現状のパッチ適用状況やファイアウォールの公開範囲を確認するリスク評価が、この種のインシデントに対応するための基本的なステップです。

5. これは繰り返されるパターンであり、単発の事象ではない。 自己管理型かつインターネット公開型のファイルストレージや転送コンポーネントは、これまでも複数の大規模インシデントの侵入口となっており、ハードニングされ、中央でパッチ適用されるアーキテクチャがまさに解決を目指すリスククラスです。

ShareFile Storage Zone Controllerのセキュリティ脅威：何が起きたのか

ShareFileは、外部のクライアント、パートナー、請負業者、監査人などとファイルを保存・交換する必要があるエンタープライズで広く利用されているプラットフォームです。多くのShareFile導入はProgressのクラウド上で完結していますが、一部の顧客、特にデータレジデンシーやコンプライアンス、パフォーマンス要件がある場合はStorage Zone Controller（SZC）を利用します。これは、実際のファイルストレージを顧客管理のWindowsサーバーでローカルにホストし、ShareFileのクラウドインターフェースがその上で共有・権限・コラボレーションを担う構成です。

このアーキテクチャは責任分担モデルを生み出します。Progressは自社クラウドインフラのパッチ適用とセキュリティを担いますが、SZCサーバー自体（OS、アプリケーションバイナリ、ネットワーク公開、パッチ適用サイクル）は顧客の責任です。7月10日の通知でProgressが求めたのは、修正を待つことではなく、マシンの電源を抜くことでした。Progress自身がまだ穴を塞げない状況だったとみられます。

7月13日のアップデートでは、ややトーンが和らぎました。Progressは調査の結果、ShareFileアカウントやデータへの不正アクセスの兆候は見つからなかったとし、SZCを運用していない顧客へのクラウドアクセス復旧も開始しました。

これは多くの情報開示がこの段階で到達する状況よりは良いものの、SZCサーバーが初期警告から数日経ってもオフラインのまま指示されていること、根本原因が公表されていないことは、Progressが修正や緩和策に十分な自信を持てていないことを物語っています。

外部ファイル交換を途切れさせずに運用するためのプラットフォームで「サーバーの電源を切っておくこと」が最も厳しい指示であることは明らかです。ベンダーは、継続的な公開によるリスクが、影響を受けるすべての顧客にとって数日間の運用停止というコストを上回ると判断したことになります。

Storage Zone Controller：オンプレミスコンポーネントが弱点となる理由

このインシデントがShareFileのクラウドサービスではなくStorage Zone Controllerに集中している理由はアーキテクチャにあり、同様のパターンはマネージドファイル転送やエンタープライズファイル共有市場全体でも見られます。

Storage Zone Controllerは、一部の顧客がファイルコンテンツをベンダーのマルチテナントクラウドだけに置きたくないというニーズから存在します。データレジデンシーや業界規制、社内ポリシーなど、オンプレミスでのファイル保存を正当化する理由は多々あります。

しかし、その選択はセキュリティ負担の一部を顧客のIT・セキュリティチームに戻すことになります。SZCサーバーのパッチ適用はベンダーではなく顧客のスケジュールで行う必要があり、アクセス制御や検知ツールによるファイアウォール設定や監視も顧客側で担います。

さらに、多くのSZC導入は設計上インターネットに公開されているため、外部関係者がファイルにアクセスできる一方で、ベンダーのハードニングやパッチ適用の枠外にある直接的な標的となります。

これはShareFile特有の批判ではなく、ベンダーが自己管理型サーバーコンポーネントを提供し、パッチ適用や公開、設定を顧客に委ねる製品すべてに共通する構造的な問題です。

このようなコンポーネントでセキュリティの設定ミスやパッチ適用の遅れが発生すると、単一ファイルだけでなく、そのサーバーが保存する全コンテンツゾーンがリスクにさらされます。なぜなら、そのサーバーは通常、認証済みファイル操作をネットワークの境界で処理するプラットフォームから信頼されているからです。

これらのゾーンに保存されているコンテンツにデータ分類を適用し、PIIやPHI、機密ビジネス情報など規制対象データをラベル付けしておくことで、サーバーのコンテンツがアクセスされた場合に最も高い通知・是正義務を負う組織が明確になります。

疑われる根本原因：連鎖CVEと事前認証RCE

執筆時点でProgressは公式な根本原因を公表していませんが、この点は重要です。セキュリティ研究やオンライン議論では、攻撃者がCVE-2026-2699とCVE-2026-2701という2つの既知の脆弱性を連鎖利用し、両方の脆弱性に未対応のインターネット公開型SZCサーバーに対して事前認証リモートコード実行（RCE）を実現したという説が有力です。

事前認証RCEは、脆弱性クラスとしては最悪レベルです。攻撃者は有効な認証情報やフィッシングされたセッショントークン、事前の侵入経路を必要とせず、ネットワーク越しに脆弱なサービスへ直接アクセスし、任意のコードをサーバー上で実行できます。

この説が正しければ、Progressが影響サーバーの物理的な電源断を指示したことも、事前認証RCE経路を深刻に受け止めている証左です。パッチ未適用かつインターネットから到達可能なSZCサーバーは、ルーチンのインターネットスキャンで発見した誰にとっても攻撃対象となり得ました。

現時点で確認されている事実と未確認の点は以下の通りです。Progressは信頼できる脅威、アカウント停止、SZCサーバーのシャットダウン指示を認めていますが、CVE-2026-2699およびCVE-2026-2701が原因であることや、実際に顧客環境で悪用が成功したかどうかは確認していません。

エンタープライズは、CVE連鎖説をセキュリティコミュニティ内の有力な作業仮説として扱い、Progressが事後報告を公表するまでは公式見解とみなさないようにしましょう。

よくあるパターン：オンプレミスファイルサーバーが侵入口になり続ける理由

このインシデントが既視感を覚えるのは、ファイル転送やエンタープライズファイル共有分野で同様の事例が繰り返されてきたからです。インターネット公開型かつ顧客管理のファイル転送・共有サーバーは、外部接続を受け入れる設計で、長年にわたり機密性の高いコンテンツを蓄積し、メールやIDシステムのような基幹インフラほど積極的にパッチ適用されないことも多いため、大規模な攻撃キャンペーンの初期侵入点となることが度々ありました。

これらのインシデントに共通するのは、単一ベンダーのミスではなく、アーキテクチャ上の問題です。独立したサーバーが設計上インターネットに公開され、顧客のタイムラインでパッチ適用され、すべての導入が初日から自動化された攻撃にさらされることを前提に作られていないソフトウェアが稼働している点です。

このサーバーが侵害されると、影響範囲は単一のメールボックスや共有リンクにとどまらず、そのサーバーが保存・転送を任されていたすべてのデータに及びます。ファイル交換インフラの場合、これはしばしば企業が外部と共有する最も機密性の高いデータ（契約書、財務記録、保護対象保健情報、GDPRやHIPAAなどの規制対象データ）です。

自己管理型ファイルストレージサーバーが規制対象データを扱っていた場合、データ侵害が確認されると通知義務が発生し、運用上の混乱に加えてコンプライアンスリスクも重なります。

どのファイル交換プラットフォーム（ShareFile含む）を評価する際も、アーキテクチャ内の自己管理型コンポーネントごとに「誰が、どのスケジュールでパッチを適用するのか」「ゼロデイがパッチ前に発覚した場合、そのコンポーネントのデータはどうなるのか」という直接的な質問を投げかけるべきです。その答えこそが、単なる機能比較以上に実際のリスクを測る指標となります。

ファイル転送・エンタープライズファイル共有分野では、すでにこのストーリーのさまざまなバリエーションが広く報道されています。インターネット公開型の自己管理アプライアンスやサーバーが、脆弱性の存在すら知らないうちに悪用されていたケースです。

これらのインシデントはいずれも、顧客自身が設置・運用し、外部パートナーに公開する設計で、ShareFile SZC顧客が今経験しているような、緊急パッチ指示、強制ダウンタイム、攻撃者が実際に何に到達したのかの確認待ちという混乱を生み出しました。

この歴史は、現在のProgressインシデントの原因を特定するものではありませんが、セキュリティチームが「自己管理型・インターネット公開型ファイルサーバー」を独立した高リスクカテゴリとして扱う理由を説明しています。どのベンダーの製品であっても同じです。

このリスククラスを正式に評価するサードパーティリスク管理プログラム（ベンダーのクラウドSLAだけでなく、ベンダーが提供する顧客管理コンポーネントも対象とする）は、このパターンを「繰り返される驚き」から「管理・記録されたリスク」へと転換するガバナンス手段となります。

ShareFile SZCを運用している企業が今すぐ取るべき対応

現在Storage Zone Controllerを運用している組織は、独自のリスク判断ではなく、Progressの指示に直接従うべきです。つまり、Progressが明確に復旧可能と通知するまで該当サーバーの電源を切ったままにし、Progressの公式コミュニケーションチャネルを通じて最新情報を確認し、シャットダウン前のログを確認してセキュリティコミュニティが指摘する事前認証RCEパターンの兆候がないか調査しましょう（Progressはこの経路を確認していませんが）。これらのログをSIEMプラットフォームに投入し、既知の脅威アクター指標と相関させることで、異常なアクセスがシャットダウン前に発生していたかどうかを迅速に把握できます。

即時対応を超えて、自己管理型ファイルストレージや転送インフラ（ShareFile SZC含む）を運用しているすべての組織は、該当カテゴリのインターネット公開サーバーを棚卸しし、既知CVEへのパッチ適用状況を確認し、インシデント対応計画が「ベンダーから『修正策はまだないので電源を切ってほしい』と指示される」シナリオを想定しているかを評価しましょう。未修正のベンダー脆弱性に対する明確なインシデント対応計画を持たない組織も多く、本件はそのギャップを埋める良いきっかけとなります。

調達・ベンダーリスクチームもこの議論に加わるべきです。根本原因未確認かつパッチ未提供の信頼できる脅威は、技術的課題だけでなく契約・ガバナンスの問題でもあります。ベンダーのSLAは開示タイムラインについて何と定めているか、主要プラットフォームが長期間オフラインになった場合の外部ファイル共有の代替手段はあるか、修正策が提供された際に運用再開を誰が承認するのか――こうした点を事前に確認しておく必要があります。

次の情報開示前にこの体制を整えておくことは、緊急時に即興で対応するよりもコストが低く済みます。どのコンテンツカテゴリが顧客管理型コンポーネントではなく、ベンダーがハードニングし中央でパッチ適用するプラットフォームを必要とするかを明記したデータガバナンスポリシーを策定しておくことで、調達チームは信頼できる脅威通知が発生する前にこのトレードオフを評価する基準を持つことができます。

Kiteworksアーキテクチャがこのリスククラスをどう低減するか

Kiteworksは本件のデータ経路には一切関与していません。ShareFileはKiteworksが運用・管理・可視化していないサードパーティプラットフォームであり、ここで述べる内容はProgressのエンジニアリングやインシデント対応を評価するものではありません。公開タイムラインを見る限り、Progressは迅速かつ積極的に対応しています。

本件が明確に示しているのは、顧客運用型オンプレミスストレージサーバーがネットワークの境界に位置し、パッチ適用が顧客任せになっている場合のリスクプロファイルです。これはまさに、Kiteworksのセキュアなファイル共有やKiteworksプラットフォームのハードニング済み仮想アプライアンスモデルが解決を目指すリスククラスです。Kiteworksは、顧客が独自スケジュールでパッチ適用する汎用Windowsサーバーではなく、ハードニング済みのシングルテナントアプライアンスとして提供され、ロックダウンされたOS、ベンダー管理のパッチ適用サイクル、不要な攻撃対象面をインターネットに公開しない設計です。

中央集権型のアクセスガバナンスももう一つの重要な要素です。独立したストレージサーバーがネットワーク境界で独自に認可判断を行うのではなく、Kiteworksは統合されたゼロトラスト・アーキテクチャとロールベースアクセス制御、中央で定義されたポリシーエンフォースメントを通じてファイルアクセスをルーティングし、CISOダッシュボードで可視化、すべてのファイルアクセス・共有・権限変更を一元的に記録する統合監査ログで裏付けます。

属性ベースアクセス制御（ABAC）ポリシーは、ユーザーロール、コンテンツ分類、リクエストコンテキストをすべてのアクセスイベントで評価し、セッションや認証情報が侵害されても許可範囲外のコンテンツにサイレントに到達できないようにします。保存データはFIPS 140-2認証暗号化で保護され、特定の法域内にデータを留める必要がある組織も、独自パッチ適用のストレージサーバーを立てることなく、サポートされた導入オプションで要件を満たせます。

本件の機密コンテンツが自己管理型ShareFile Storage Zone Controllerではなく、このモデルで管理されていれば、上述のパッチ適用・アクセス制御アーキテクチャによって「顧客運用・インターネット公開・独立パッチタイムラインのサーバー」というリスククラスを低減できたはずです。

ただし、この主張はKiteworks内での構成やパッチ適用サイクル、導入選択に依存し、Progressが本件で最終的に確認する根本原因については何も言及しません。どのプラットフォームも脆弱性から完全に無縁ではありません。重要なのは、パッチ適用やアクセス制御の負担がベンダーと顧客のどちらにあるか、信頼できる脅威が表面化した際にどれだけ迅速かつ中央集権的に対応できるかという点です。

データセキュリティ・コンプライアンス担当者への広範な教訓

本インシデントはまだ進行中であり、現時点での適切な見方は冷静さを保つことです。ベンダーは信頼できる脅威を検知し、迅速にアクセスを無効化し、影響サーバーの電源断を顧客に指示し、現時点で侵害の証拠は見つかっていません。不確実な状況下での妥当な対応であり、Progressは初動・フォローアップともに迅速に動いた点で一定の評価に値します。

エンタープライズのセキュリティ・コンプライアンスチームが得るべき持続的な教訓は、ShareFile固有の話ではありません。自己管理型・インターネット公開型ストレージやファイル転送コンポーネントを運用するか、中央集権的にガバナンスされたベンダーハードニング済みプラットフォームを使うかという意思決定のリスク計算にあります。

データレジデンシーやコンプライアンス要件は現実的なものであり、自己管理サーバーのパッチリスクが高いからといって消えるものではありません。変わるのは、導入前にベンダーへ投げかけるべき質問です。「このコンポーネントに信頼できる脅威が発生した場合、誰がギャップを埋める責任を持ち、どれくらいの期間で対応できるのか」。

このようなファイル交換インフラに紐づくサードパーティおよびサプライチェーンリスク管理は、セキュリティ・コンプライアンスチームの注力分野として拡大しており、Kiteworks 2026年データセキュリティ＆コンプライアンスリスク年次予測レポートでも取り上げられています。本件のようなインシデントは、その重要性が高まる理由を示す事例です。

自己管理型・インターネット公開型ファイルストレージサーバーが生むリスクの低減についてさらに知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース 

• ブログ記事
  エンタープライズ向けベストセキュアファイル共有ソリューション5選
• ブログ記事
  安全にファイルを共有する方法
• 動画
  Kiteworks Snackable Bytes：セキュアファイル共有
• ブログ記事
  セキュアファイル共有ソフトウェアの必須要件12選
• ブログ記事
  エンタープライズ＆コンプライアンス向け最も安全なファイル共有オプション