バックアップ製品に脆弱性359件の修正｜ランサム対策の「最後の砦」は誰がパッチを当てるのか

結論：バックアップに投資した会社ほど、次に問うべきは「その製品を誰が保守しているか」である

2026年7月、Dellがバックアップ製品「PowerProtect Data Manager」のセキュリティアップデートを公開しました。Security NEXTの報道によれば、修正された脆弱性は計359件。内訳は製品固有のものが6件、サードパーティ製コンポーネント由来が353件とされています（件数と内訳は同報道に基づく整理です）。

製品固有のものには、REST APIの入力検証不備（CVE-2026-40712）や、権限昇格につながる不具合が含まれます。このうち CVE-2026-49499 については、Dellが2026年7月22日に公開した情報で、20.2.0.0 より前のバージョンが影響を受け、IAM（認証・認可）コンポーネントにおける不適切なセキュリティトークンの生成に起因する高深刻度の問題とされています。一方、353件のほうはLinuxカーネル関連が130件、その他にApache Log4j、Apache Tomcat、Samba、PostgreSQL、OpenSSL、glibc、Vimなどが挙げられています。対策は、バージョン20.2.0.0以降への更新です。

この7月、日本の企業経営者の間で「ランサムウェア対策はバックアップが決め手だ」という認識が急速に広がりました。実際に暗号化被害を受けた企業がバックアップから復旧できた事例が報じられ、その判断は正しいものとして共有されています。

その直後に押さえておくべきなのが、今回の話です。バックアップ基盤は、それ自体が攻撃対象であり、しかも中身の大半は第三者が作ったオープンソースの集合体であるという構造です。

3行サマリー（先に結論）

• Dell PowerProtect Data Managerに計359件の脆弱性修正（製品固有6件、サードパーティ製コンポーネント353件）。深刻度はCVSS 9.1に達するものを含む。対策は20.2.0.0以降への更新。
• アプライアンス製品の中身は多数のオープンソースの集合体であり、その修正はベンダーの追随速度に依存する。
• 発注側が確認すべきは、①更新の責任が誰にあるか ②サポート期間と脆弱性対応の条件 ③構成部品の情報（SBOM）が提供されるか ④復旧テストを実施しているか、の4点。

要点表：今回のアップデートの概要

※本記事執筆時点で、359件という総数を明示したDell公式アドバイザリを特定できていません。総数・内訳はSecurity NEXTの報道に基づく整理として扱ってください。個別のCVE・対象バージョン・修正版の詳細は、Dellの公式セキュリティアドバイザリ一覧でご確認ください。

「アプライアンス」は箱ではなく、ソフトウェアの集合体である

多くの企業で、バックアップ装置は「箱」として認識されています。ラックに設置され、電源が入り、決められた時間に自動でバックアップを取る。運用担当者が触るのは、たまに管理画面でジョブの成否を確認するときくらいです。

しかし中身は、汎用のサーバハードウェアの上にLinuxが動き、その上でデータベース、Webサーバ、暗号化ライブラリ、各種ツールが動作する、れっきとしたコンピュータです。今回のアップデートで353件のサードパーティ製コンポーネントが更新されたという事実が、それを端的に示しています。

ここから導かれる、重要な帰結が2つあります。

帰結1：世の中で見つかった脆弱性は、遅れて自社の装置にもやってくる Log4jやOpenSSLのように広く使われる部品に脆弱性が見つかると、それを内部で使っているすべての製品が影響を受けます。ただし、利用者がすぐに対処できるわけではありません。製品ベンダーが自社製品への影響を確認し、修正版を作り、検証し、提供するまで待つことになります。ベンダーの追随速度が、そのまま自社のリスク期間になるということです。

帰結2：更新は「あるとき突然、大量に」やってくる 359件という数字は、日々こまめに更新されているわけではなく、一定期間ためて一括で提供される運用を示唆しています。つまり利用者側も、日常的に少しずつではなく、まとまった更新作業を計画的に行う必要があります。

誰が更新するのか、が決まっていない

ここが本題です。バックアップ装置の更新について、次の質問に答えられるでしょうか。

• 現在のバージョンは何で、最後に更新したのはいつか。
• ベンダーからセキュリティ情報が公開されたとき、その通知は誰に届くか。
• 更新作業を実施するのは自社か、導入したSIerか、メーカーの保守サービスか。
• 更新中にバックアップが取得できない時間帯が生じるが、その調整は誰がするか。

情シスが手薄な中堅企業では、これらが決まっていないことが珍しくありません。理由は理解できます。バックアップ装置は導入時に大きな検討を経て入れられ、その後は「動いている」状態が続くため、日常の関心から外れていきます。

しかし、この状態には特有の危うさがあります。バックアップ基盤は、社内のあらゆるシステムのデータが集まる場所です。ファイルサーバ、基幹システム、メール、仮想サーバのイメージ。侵害されれば、個別のサーバを攻撃するより効率よく、社内データを一望できる立場に立たれます。

さらに悪いことに、バックアップ基盤を握られると、復旧手段そのものを奪われます。ランサムウェア攻撃において、攻撃者がまずバックアップの破壊を狙うのは、身代金交渉を有利にするためです。復旧できる手段を残したまま暗号化しても、企業は払いません。

バックアップ運用の点検リスト

今日から確認できる項目を挙げます。技術者でなくても、担当者に問いかける形で進められます。

最後の項目が、この表で最も重要です。

「戻せることを確認したか」という最後の問い

バックアップに関する最大の誤解は、取得できていること＝戻せることだと思ってしまうことです。

実際には、次のような事態が起こり得ます。

• バックアップジョブは成功しているが、対象から外れているデータがある（新しく追加されたサーバ、設定変更で除外されたフォルダ）。
• 取得はできているが、復旧に必要な暗号鍵やライセンス情報が同じ装置にしかない。
• 復旧手順書がなく、担当者の記憶に依存している。その担当者が退職している。
• 復旧に必要な時間を測ったことがなく、実際にやってみたら業務再開まで想定の何倍もかかる。
• 復旧先のハードウェアが確保できず、機器の調達から始める必要がある。

いずれも、実際に復旧してみるまで発覚しません。だからこそ、年に一度でよいので、実際に復旧する訓練を行うべきです。全システムを対象にする必要はありません。重要度の高いシステムを一つ選び、隔離した環境に復旧し、業務データが読めることを確認する。それだけで、上記の落とし穴のほとんどが洗い出せます。

この訓練には、副次的な効果もあります。「復旧に何日かかるか」という問いに、推測ではなく実測で答えられるようになります。これは経営としてBCPを議論する際の、最も基礎的な数字です。

復旧テストの進め方——半日でできる最小構成

「復旧テストが必要」と言われても、大掛かりな訓練を想像すると着手できません。半日で終わる最小構成を示します。

準備（前日まで）

• 対象を1システム選ぶ。まずはファイルサーバなど、業務への影響が読みやすいものが適しています。
• 復旧先を確保する。本番環境に上書きするのは論外なので、隔離された領域（検証用サーバ、仮想環境の一区画）を用意します。
• 復旧手順書があれば用意する。なければ「手順書がない」という事実自体が最初の発見になります。

当日（午前）

• 手順に沿って復旧を実行する。ここで、担当者以外の人が実施するのが理想です。手順書だけで実行できるかを確かめられます。
• 所要時間を記録する。開始から、データが読める状態になるまでの実測値です。

当日（午後）

• 復旧されたデータの中身を確認する。ファイルが開けるか、最新の状態か、欠けているものがないか。
• 業務部門の担当者に見てもらう。技術的に復旧できていても、業務上必要なデータが欠けていることがあります。

振り返り（30分）

• 詰まった箇所、時間がかかった箇所、手順書と実際が違った箇所を記録する。
• 手順書を更新する。

この一連で得られるものは3つあります。実測の復旧時間、手順書の実効性の確認、そして欠けているデータの発見です。いずれも、やってみるまで分かりません。

年1回、この最小構成を回すだけで、いざというときの成否は大きく変わります。

復旧目標を決める——RTOとRPOの実務的な決め方

BCPの議論で登場するRTO（復旧目標時間）とRPO（目標復旧時点）は、専門用語のせいで敬遠されがちですが、中身は経営判断そのものです。

RTO＝どれくらい止まってよいか

システムが使えない状態が何時間・何日続いたら、事業として耐えられなくなるか。判断の材料は、止まったときに何が起きるかです。

• 受注が取れない：機会損失の金額を1日あたりで概算する。
• 出荷ができない：取引先への納期遅延と、その影響。
• 請求ができない：資金繰りへの影響。
• 顧客対応ができない：信用への影響。

これを業務ごとに出すと、システムの優先順位が決まります。すべてを同時に復旧することはできないため、優先順位は必ず必要です。

RPO＝どこまで遡ってよいか

障害の直前の状態まで戻せるのか、前日の夜まで戻せるのか、前週まで戻れば十分なのか。戻れる時点が古いほど、その間の業務データを手作業で再入力することになります。

判断の材料は、「1日分のデータを手作業で復元するのに、何人が何時間かかるか」です。この時間が許容できないなら、バックアップの頻度を上げる必要があります。

決めた数字を、契約と設計に反映する

RTOとRPOを決めたら、それが現在のバックアップ構成で実現できるかを確認します。多くの場合、決めた目標と現状に乖離があります。その乖離を埋める投資が必要か、目標を現実的な水準に下げるかを、経営として判断します。

重要なのは、この乖離を認識したうえで判断することです。認識しないまま「バックアップは取っているから大丈夫」と考えている状態が、最も危険です。

バックアップへの投資配分をどう考えるか

セキュリティ予算の配分を考えるとき、バックアップは「守り」の分類に入り、優先度が下がりがちです。しかし、次の観点から見直す価値があります。

観点1：防御は突破され得るが、復旧は最後の手段である

侵入を防ぐ対策は重要ですが、100%は達成できません。突破された場合に事業を継続できるかは、復旧能力にかかっています。防御に予算を集中させ、復旧を軽視する配分は、リスクの偏りを生みます。

観点2：バックアップは他の障害にも効く

ランサムウェアだけでなく、機器故障、操作ミス、災害、退職者による削除。バックアップはこれらすべてに効きます。投資に対して効く場面が多い領域です。

観点3：復旧時間の短縮は、金額に換算できる

RTOを2日から半日に短縮できるなら、その差は事業機会の損失額として計算できます。「なんとなく不安だから」ではなく、金額で説明できる投資です。

観点4：それでも上限はある

一方で、完璧を目指すと費用は際限なく増えます。重要度の高いシステムに手厚く、そうでないものは簡素にという配分が現実的です。全システムを同じ水準で守る必要はありません。

アプライアンス製品を調達するときに確認すべきこと

今後、バックアップ装置に限らずアプライアンス型の製品を導入する際に、確認しておくべき項目を挙げます。今回のような事態は、製品を問わず起こり得るためです。

確認1：サポート期間とその後の扱い 販売終了はいつか、保守終了はいつか。保守終了後にセキュリティ修正は提供されるか。導入時点で「あと何年使える製品なのか」を把握しておきます。

確認2：脆弱性対応の条件 サードパーティ製コンポーネントの脆弱性について、どのような方針で対応するか。深刻度に応じた対応期間の目安はあるか。通知の方法はどうなっているか。

確認3：構成部品の情報（SBOM） その製品がどのようなソフトウェア部品で構成されているかの一覧を提供できるか。SBOM（Software Bill of Materials／ソフトウェア部品表）と呼ばれるもので、公共調達を中心に要求が広がりつつあります。中堅企業がすぐに活用するのは難しいかもしれませんが、提供できるかどうかを聞くこと自体に意味があります。管理体制の成熟度を測る質問になるためです。

確認4：更新作業の実施主体と費用 更新作業は保守費に含まれるのか、都度費用が発生するのか。作業に伴う停止時間はどの程度か。

確認5：ネットワーク設計上の要件 管理画面へのアクセス制限、業務ネットワークからの分離。導入時に設計しておかないと、後から変更するのは容易ではありません。

バックアップ基盤を守るための構成上の考え方

技術的な詳細は専門家の領域ですが、経営として押さえておくべき考え方を3つ挙げます。

考え方1：3つのコピー、2つの媒体、1つは別の場所 いわゆる3-2-1の原則です。同じ場所の同じ仕組みにコピーが集中していると、その場所ごと被害を受けたときに全滅します。

考え方2：変更できない保管を持つ 一度書き込んだら一定期間削除も変更もできない形式（イミュータブル）での保管があると、攻撃者がバックアップを消そうとしても消せません。近年のバックアップ製品には標準で備わっていることが多いため、その機能を有効にしているかを確認してください。

考え方3：バックアップ基盤を業務ネットワークから分ける バックアップ基盤の管理画面が、業務用のパソコンから普通に開ける状態だと、パソコンが侵害された時点でバックアップも危険にさらされます。管理のための経路を分けておくことが望ましい設計です。

これら3つは、いずれも「導入済みの製品でも設定で改善できる」場合があります。買い替えの前に、現在の設定を確認してください。

FAQ

Q1. Dell製品ではないので関係ないですか。 A. 今回のアップデートそのものは該当しません。ただし、アプライアンス製品がサードパーティ製コンポーネントの集合体であるという構造は、メーカーを問いません。点検リストの部分はそのまま使えます。

Q2. 359件という数字は異常に多いのではないですか。 A. 一括提供の運用では珍しい数字ではありません。むしろ、サードパーティ製コンポーネントまで含めて追跡し、まとめて修正している姿勢は評価できる側面もあります。なお、この総数は報道に基づくもので、本記事執筆時点でDell公式の同一表記は確認できていません。判断すべきは件数ではなく、自社がその修正を適用できているかです。

Q3. 更新すると業務が止まりませんか。 A. バックアップ取得の一時停止は生じます。ただし、業務システム自体は通常稼働できます。取得のタイミングを調整して実施するのが一般的です。

Q4. 保守契約が切れています。どうすればよいですか。 A. 修正版の提供を受けられない状態のため、優先度の高い課題です。契約の再開、または更改の検討が必要です。それまでの間、管理画面へのアクセス制限を厳しくすることで露出を下げてください。

Q5. SBOMを求めても、提供してもらえるとは限らないのでは。 A. 現状ではそのとおりです。提供されない場合でも、「どのような方針でサードパーティ部品の脆弱性を管理しているか」を文書で回答してもらうだけで、判断材料になります。

Q6. 復旧テストはどのくらいの規模でやればよいですか。 A. 最初は一つのシステム、一部のデータで構いません。「復旧手順書に従って、担当者以外の人が復旧できるか」を確認するのが目的です。規模より、実際にやってみることに意味があります。

Q7. クラウドのバックアップサービスなら安全ですか。 A. 運用の負担は軽くなりますが、考えるべき論点は変わりません。データの取り出し方、保管期間、アクセス権の管理、サービス提供者側の障害時の扱い。むしろ「自社では手が出せない部分が増える」ため、契約内容の確認は重要になります。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、製品の話に入る前に体制の整理をおすすめします。

• バックアップは取っているが、実際に復旧できるかを確認したことがない。
• バックアップ装置の更新を誰が担当しているか、社内で明確でない。
• ランサムウェア対策としてバックアップを強化したいが、何から手を付けるべきか分からない。
• アプライアンス製品の調達にあたって、確認すべき条件を整理したい。

GXOはバックアップ製品を販売する立場ではないため、「新しい装置を買いましょう」に着地しない前提で、現在の構成と運用を点検できます。バックアップを含むセキュリティ体制の点検はセキュリティ診断・対策の相談、継続的な脆弱性監視と対応判断の伴走はセキュリティ顧問（リテーナー）、侵害を受けた場合の初動はインシデント対応の相談、システム構成そのものの見直しはシステム開発・DXの相談が入口です。復旧テストの設計からお手伝いすることもできます。まずはお問い合わせよりご状況をお聞かせください。

バックアップに投資した判断は正しかったはずです。あと一歩必要なのは、その装置を「守られるもの」ではなく「守るべきもの」として扱うことです。

参考文献

• Security NEXT「『Dell PowerProtect Data Manager』にアップデート - 脆弱性359件を修正」（二次・報道。総数359件・内訳・CVSS値の出所）: https://www.security-next.com/187759
• Dell Technologies セキュリティアドバイザリ一覧（一次・メーカー公式）: https://www.dell.com/support/security/

※本稿は2026年7月24日時点で公開されていた情報をもとに執筆しています。総数359件を明示したDell公式アドバイザリは執筆時点で特定できておらず、当該数値は報道に基づく整理です。CVE-2026-49499（20.2.0.0より前が影響／IAMコンポーネント／高深刻度）はDellが2026年7月22日に公開した情報として確認しています。対象バージョンと修正版は、必ずメーカーの公式アドバイザリでご確認ください。