バックドアとは？米英イスラエルの公的資料と国内外の事例から見るリスクと対策|セキュリティ対策 Lab

投稿日時: 2025年04月23日更新日時: 2026年08月02日

バックドアという言葉は、どうしてもマルウェアや不正プログラムの説明に寄りがちです。ただ、ここ数年の事例を追っていると、実務上の問題はそれだけではありません。ソフトウェアの更新経路、OSSの保守体制、CI/CD、ルーターやVPNなどのエッジ機器、外部委託先やサプライヤー管理まで、普段は信頼している経路そのものがバックドア化するケースが増えています。

米国のNISTはバックドアを、コンピューターシステムへアクセスするための文書化されていない手段と整理しています。CISAがSolarWinds事案で示したように、これは単なる侵入後のマルウェアではなく、政府機関、重要インフラ、民間企業を横断するサプライチェーンリスクでもあります。英国NCSCは近年、ソフトウェア供給網と依存関係の管理を強く打ち出しており、イスラエル国家サイバー総局もサプライヤー評価と継続的な監督を方法論として整備しています。

この記事では、バックドアの定義を整理したうえで、米国、英国、イスラエルの公的資料を参照しながら、セキュリティ対策Labの既報で扱ってきたXZ Utils、ASUSルーター、UNC3886、Trivyサプライチェーン攻撃などの事例を横串で見直します。情報システム部門が見るべきポイントは、怪しいファイルを探すことだけではありません。信頼している更新経路や外部コンポーネントが、どのように悪用されるかを前提に管理することが必要です。

バックドアとは？米英イスラエルの公的資料と国内外の事例から見るリスクと対策のサマリー

バックドアは、通常の認証や監査を回避してシステムへアクセスするための隠れた経路を指します
近年のバックドアは、マルウェア単体ではなく、ソフトウェア更新、OSS、CI/CD、ルーターなどの信頼済み経路を悪用する傾向があります
米国CISAやNISTは、SolarWinds以降、バックドアをサプライチェーンリスクや安全な開発プロセスの問題として扱っています
英国NCSCは、OSSパッケージや依存関係、自動更新、開発者アカウントの認証情報を重点的な管理対象としています
イスラエル国家サイバー総局は、サプライヤーを評価し、継続監督する考え方をサプライチェーン防御の中心に置いています
情報システム部門は、EDRだけでなく、SBOM、依存関係管理、エッジ機器の棚卸し、委託先管理、ログ保全を組み合わせてバックドアリスクを下げる必要があります

観点	従来の見方	近年の実務上の見方
バックドアの定義	不正アクセス用に設置された隠しプログラム	認証、更新、開発、委託、機器設定などを悪用した継続アクセス経路
主な侵入口	マルウェア添付、脆弱性悪用	OSS、パッケージマネージャー、CI/CD、正規アップデート、エッジ機器
代表事例	トロイの木馬型マルウェア	SolarWinds、XZ Utils、ASUSルーター、UNC3886、Trivy関連事案
検知の難しさ	不審プロセスや通信の検知	正規機能、正規署名、正規アカウント、公式リポジトリに紛れるため検知が難しい
組織の対応	ウイルス対策ソフト、パッチ適用	サプライチェーン管理、SBOM、ビルド環境保護、委託先監督、エッジ機器更新
経営上の論点	IT部門の技術課題	調達、委託、事業継続、国家安全保障、経済安全保障の課題

バックドアは隠しプログラムではなく、信頼の経路を悪用する仕組み

バックドアを一言で説明すれば、通常の認証やアクセス制御を迂回してシステムへ入るための隠れた経路です。NISTの用語集では、コンピューターシステムへアクセスするための文書化されていない手段と説明されています。古典的には、攻撃者が侵入後に設置するリモート操作用マルウェアや、開発時に残された保守用アカウントが典型例でした。

ただ、現在の企業システムでは、バックドアは必ずしも怪しい実行ファイルの姿をしていません。正規のアップデートに混入する場合もあれば、OSSパッケージに紛れる場合もあります。ルーターの正規設定機能を使ってSSH公開鍵を登録し、再起動後も残るようにされることもあります。CI/CDのトークンやGitHub Actionsのタグが奪われれば、セキュリティツールの公式リリースに見えるものが情報窃取経路になり得ます。

ここで厄介なのは、攻撃者が利用するのが組織側の信頼です。署名済みの更新、よく使われるOSS、正規ベンダーの機器、管理用アカウント、委託先の開発環境。これらは普段の運用では必要なものです。そのためバックドア対策は、不審なファイルを削除する作業だけでは終わりません。何を信頼しているのか、その信頼が壊れたときにどこまで影響が広がるのかを把握する必要があります。

米国はバックドアをサプライチェーンと連邦調達の問題として扱っている

米国の動きを見ると、バックドアはマルウェア対策の範囲を超え、連邦政府全体のサイバー調達とサプライチェーン管理の問題として扱われています。象徴的なのがSolarWinds事案です。CISAは2020年12月、米政府機関、重要インフラ、民間企業に対するAPTによる侵害を公表し、SolarWinds Orionのサプライチェーン侵害を初期侵入経路の一つとして示しました。CISAはこの脅威について、連邦政府や重要インフラに重大なリスクをもたらすと評価しています。

この事案で重要なのは、侵害されたのが単なる端末ではなく、ネットワーク管理製品の更新経路だったことです。管理ツールは広い権限を持ち、社内ネットワークの中心に置かれます。そこにバックドアが混入すると、攻撃者は個別端末を一つずつ攻めるよりも高い効率で組織内へ足場を作れます。

SolarWinds以降、米国ではNIST SP 800-161 Rev.1によるサイバーサプライチェーンリスク管理、NIST SP 800-218のSecure Software Development Frameworkが、調達側と開発側の共通言語になりました。SP 800-161は、技術の取得、開発、統合、導入に関する可視性不足をサプライチェーンリスクとして扱っています。SP 800-218は、開発ライフサイクルにセキュリティを組み込むことで、脆弱性の数を減らし、未検出の問題が悪用された場合の影響を抑える考え方を示しています。

この流れで見ると、バックドア対策は製品導入後の監視だけでは足りません。どのベンダーから買うのか、更新ファイルの完全性をどう確認するのか、ビルド環境や署名鍵がどう守られているのか、委託先がどのOSSを使っているのか。これらを調達時点から確認しなければ、導入後にSOCが頑張っても限界があります。

英国NCSCは依存関係と自動更新を重点リスクとして見ている

英国NCSCの資料は、より実務者の現場に近い表現でソフトウェア供給網の問題を扱っています。NCSCはサプライチェーンセキュリティの12原則で、リスク理解、統制、確認、継続的改善という流れを示しています。さらに2026年6月のブログでは、攻撃者がOSSパッケージを大規模に侵害し、検出が難しい形でマルウェアを広げていると注意を促しました。

NCSCが強調している点は、依存関係の複雑さです。現代のアプリケーションは、内部コードだけで動いているわけではありません。npm、PyPI、Rust、Goなどのエコシステムから多数のパッケージを取り込み、CI/CDで自動的にビルドし、テストし、本番へ展開します。便利な一方で、どこか一つのパッケージ、メンテナー、トークン、GitHub Actionが侵害されるだけで、利用企業の環境まで影響が届きます。

NCSCは、疑わしいサプライチェーン侵害がある場合の対応として、自動依存関係更新の停止、手動レビュー、認証情報のローテーション、開発者アカウントへのMFA、信頼できるレジストリの利用などを挙げています。これは単なるチェックリストではなく、現場での運用変更を求める内容です。

セキュリティ対策Labの読者である情報システム部門に置き換えると、開発部門が使うパッケージ管理やCI/CDの設定は、もはや開発チームだけの問題ではありません。情報システム部門がSaaS、ID管理、端末管理、ネットワーク境界を見ていても、開発パイプラインのトークンが漏れれば、正規の更新経路からバックドアが入ります。NCSCの見方は、開発と運用を分けすぎる日本企業にも刺さる部分があります。

イスラエルはサプライヤー評価と継続監督を重視している

イスラエル国家サイバー総局の資料は、サプライチェーンをかなり実務寄りに扱っています。同総局は、サプライヤー向けの質問票やサプライチェーン管理の方法論を整備しており、組織が外部事業者から受けるサイバーリスクを評価し、継続的に管理する考え方を示しています。イスラエル政府系資料では、サプライヤーの評価を一度きりの審査ではなく、定期的に見直す対象として扱っている点が目立ちます。

この考え方は、バックドア対策にもそのまま当てはまります。自社の環境にバックドアが置かれる経路は、自社の社員やサーバーだけではありません。委託先の開発環境、保守ベンダーのリモート接続、外部SaaS、マネージドサービス、セキュリティ製品の管理コンソール、クラウド上のCI/CDまで広がっています。

イスラエルがサプライヤー評価を重視する背景には、国家安全保障と民間経済がサイバー空間で強く接続しているという現実があります。重要インフラや防衛産業だけが狙われるわけではなく、その周辺にいる比較的小さな企業や委託先が、実質的な入口になることがあります。日本でも、防衛、製造、通信、医療、金融、官公庁向けシステムを扱う企業は、この発想を持つ必要があります。

サプライヤーに質問票を送るだけでは、バックドアは防げません。ただし、更新経路、開発環境、委託範囲、ログ保管、リモート接続、インシデント通知義務を契約と運用に落とし込むことで、怪しい挙動を早く見つける余地は増えます。海外の公的機関がサプライチェーンを繰り返し取り上げるのは、技術的に完全な防御が難しいからこそ、管理の見える化が必要だからです。

XZ Utilsはコードではなく、OSSの信頼関係を狙った事例だった

セキュリティ対策Labの既報「XZ Utilsにバックドアが仕込まれていた (CVE-2024-3094)」で扱ったXZ Utils事案は、バックドアを考えるうえで非常に示唆的です。問題になったのは、Linux環境で広く使われる圧縮関連ライブラリに、SSH認証を迂回し得るバックドアが仕込まれていた点です。

この事案が怖いのは、単に悪意あるコードが混入したことではありません。攻撃者とみられる人物が長い時間をかけてOSSプロジェクト内で信頼を得て、保守体制そのものに入り込んだと見られている点です。これは、コードレビューや脆弱性スキャンだけでは拾いきれない問題です。誰が権限を持っているのか、リリース権限が集中していないか、テストファイルやビルドスクリプトの変更まで確認されているか、メンテナーが孤立していないかといった、コミュニティ運営の問題に踏み込んでいます。

企業側でできることは限られますが、何もできないわけではありません。利用しているOSSの棚卸し、重要コンポーネントのバージョン固定、検証環境での挙動確認、SBOMの整備、緊急時に依存パッケージを戻せる手順は現実的な対策です。OSSは危ないから使わない、という話ではありません。OSSの上に自社サービスが成り立っているなら、OSS由来のリスクも自社のリスクとして扱う必要があります。

ルーターとエッジ機器はバックドアの長期拠点になりやすい

バックドアの話では、PCやサーバーに目が行きがちですが、近年はルーター、VPN、ファイアウォール、仮想化基盤などのエッジ機器が非常に重要な標的になっています。エッジ機器はインターネットに面しており、通信の通り道にあります。それにもかかわらず、EDRが入っていない、ログが取りづらい、古いファームウェアが残る、所有部門が曖昧という弱点を抱えがちです。

既報「9,000台超のASUSルーターが不正アクセスによる侵害、永続的バックドアでボットネット化しサイバー攻撃に悪用」では、ASUSルーターに対する永続的なSSHバックドア事案を取り上げました。GreyNoiseの調査によれば、攻撃者は正規機能を悪用してSSHアクセスを有効化し、攻撃者の公開鍵を登録し、設定をNVRAMに保存していました。ファームウェア更新や再起動だけでは消えない点が重要です。

既報「中国系スパイグループ「UNC3886」がサポート終了した Juniper ルーターを標的にサイバー攻撃」で扱ったUNC3886の事例も同じ流れです。Mandiantは、Juniper NetworksのJunos OSルーターにカスタムバックドアが展開されていたと報告しています。対象にはサポート終了ハードウェアやソフトウェアが含まれており、エッジ機器が監視の薄い長期拠点として使われる構図が見えます。

この種のバックドアは、端末のウイルス対策ソフトでは見つかりません。情報システム部門が確認すべきなのは、インターネットに面した機器の一覧、ファームウェア更新状況、管理画面の公開範囲、不要なSSHやTelnet、VPNアカウント、ログ転送設定、サポート終了機器の有無です。特に中小企業や拠点が多い企業では、数年前に設置したルーターがそのまま残り、実質的なバックドアの入口になることがあります。

セキュリティツール自身もバックドア化される時代になった

もう一つ見落としやすいのが、セキュリティツールや開発支援ツール自身が攻撃経路になるパターンです。既報「Ciscoのソースコード流出疑惑、Trivyのサプライチェーンサイバー攻撃か」で触れたTrivy関連事案は、まさにこの問題を示しています。

Aqua SecurityとGitHubのアドバイザリによれば、2026年3月、攻撃者は侵害された認証情報を使い、Trivy v0.69.4の悪意あるリリースや、trivy-action、setup-trivyへの不正な変更を行いました。GitHub Actionsのタグが強制更新され、認証情報を盗むコードが仕込まれた点は、開発者にとって特に深刻です。セキュリティスキャンのために導入したツールが、CI/CDのシークレットへアクセスする経路になるためです。

企業の現場では、セキュリティ製品やOSSツールは比較的強く信頼されます。脆弱性スキャナ、CI/CD補助ツール、IaCスキャナ、コード品質ツールは、多くの場合、リポジトリ、クラウド認証情報、コンテナレジストリ、成果物に触れます。そこが侵害されると、攻撃者は開発環境の内側から情報を抜き出せます。

この教訓は、セキュリティツールを疑えという単純な話ではありません。むしろ、セキュリティツールほど権限を絞るべきです。GitHub Actionsはタグではなく完全なコミットSHAに固定する、CI/CDで使うシークレットは最小権限にする、ワークフローごとに権限を分離する、外部Actionの更新をレビューする、緊急時にトークンを一括ローテーションできるようにしておく。こうした地味な運用が、バックドア化された供給網からの被害を抑えます。

バックドア対策で見るべき五つの領域

バックドア対策を考えるとき、EDRやアンチウイルスだけに頼ると見落としが出ます。現実的には、次の五つの領域を分けて確認した方が整理しやすいです。

領域	確認すべきこと
ソフトウェア資産	利用中のOSS、商用ソフト、バージョン、更新経路、SBOM、サポート期限
開発・CI/CD	GitHub Actions、ビルド権限、署名鍵、トークン、外部Action、依存関係更新ポリシー
エッジ機器	ルーター、VPN、ファイアウォール、WAF、ロードバランサ、管理画面、ファームウェア
アカウントと権限	管理者アカウント、委託先アカウント、MFA、長期トークン、不要アカウント
委託先・サプライヤー	開発委託、保守委託、SaaS、MSP、インシデント通知、再委託、ログ提出可否

この中で特に後回しにされがちなのが、エッジ機器と委託先です。サーバーやPCは資産管理台帳に載っていても、各拠点のルーターやVPN装置はネットワーク図の片隅に残りがちです。委託先アカウントも、プロジェクト終了後に無効化されないまま残ることがあります。攻撃者にとっては、そこが使いやすい入口になります。

NIST、CISA、NCSC、イスラエル国家サイバー総局の資料に共通しているのは、技術対策と管理対策を分けていない点です。開発、調達、委託、運用、監視をつなげて考えています。日本企業でも、情報システム部門だけで完結させようとすると限界があります。開発部門、購買部門、法務、委託先管理、経営層を巻き込む必要があります。

情報システム部門への示唆

情報システム部門が直近で取り組むべきことは、バックドアを特定のマルウェア名として追うのではなく、自社の信頼経路を棚卸しすることです。どのソフトウェアを、どの経路で更新しているのか。どのOSSや外部Actionを使っているのか。どのベンダーがリモート保守できるのか。どのルーターやVPNがインターネットに露出しているのか。ここが見えていなければ、バックドアの有無を判断する前提がありません。

すぐに始めやすい対応としては、インターネット公開資産の棚卸し、サポート終了機器の洗い出し、ルーターやVPNの管理画面の公開制限、ファームウェア更新、不要なSSHやTelnetの無効化があります。ASUSルーター事案のように、ファームウェア更新だけでは不正設定が消えない場合もあるため、設定そのものを確認することが大切です。

開発環境では、依存関係の自動更新ルールを見直し、重要システムでは新しい依存パッケージを即時に取り込まない運用も検討すべきです。GitHub Actionsや外部Actionは、安易にタグ指定で使わず、可能な限り完全なコミットSHAに固定します。CI/CDに与えるトークンは最小権限にし、漏えい時に短時間でローテーションできる手順を用意しておくべきです。

委託先管理では、契約書にセキュリティ条項を入れるだけでは不十分です。委託先がどの環境で開発しているのか、再委託があるのか、事故時に何時間以内に通知されるのか、ログや証跡を提出できるのか、外部コンポーネントの管理をどうしているのかを確認する必要があります。イスラエル国家サイバー総局のように、サプライヤーを継続評価する考え方は、日本企業でも取り入れやすいはずです。

バックドア対策は、完全に侵入を防ぐというより、攻撃者に長く居座らせないための活動です。更新経路を検証し、権限を絞り、ログを残し、怪しい設定変更を見つけ、委託先まで含めて説明できる状態にする。この地味な積み上げが、国家支援型攻撃にもサイバー犯罪にも効く現実的な防御になります。