サプライチェーン攻撃をどう防ぐ?共通防御の新たな選択肢「Protective DNS(PDNS)」とは

企業のサプライチェーンが複雑化するなか、自社だけでなく、委託先や取引先を起点としたサイバー攻撃への対策が重要になっています。

しかし、数百・数千社に及ぶ取引先すべてに、自社と同水準のセキュリティ対策を求めることは容易ではありません。一方、攻撃者は多数の取引先の中から「侵入しやすい1社」を見つければよく、サイバー攻撃の分業化・低コスト化も進んでいます。

こうした攻撃側と防御側の非対称性に対し、どのような対策が考えられるのでしょうか。

2026年7月7日に開催したウェビナー「委託先管理はしていたはずだったのに…自社のセキュリティ対策が万全でも攻撃されてしまう理由 -サプライチェーンを守る最適解とは-」では、サプライチェーン攻撃が増加する背景と、サプライチェーン全体を効率的に守るための防御アプローチについて解説しました。

本記事ではウェビナーの内容をもとに、サプライチェーンにおける「共通防御」という考え方と、その手段の一つであるProtective DNS(PDNS)についてご紹介します。

動画でご覧になりたい方へ

実際のウェビナー動画も公開しています。
講演を動画でご覧になりたい方は、以下の記事からご視聴いただけます。

この記事のポイント

本記事のポイントは、次の3点です。

  • 自社のセキュリティを強化するだけでは、サプライチェーン攻撃への対策には限界がある
  • 取引先1社1社に対策を求めるだけでなく、サプライチェーン全体を共通の仕組みで守るという考え方がある
  • Protective DNS(PDNS)は、DNSを活用して悪性サイトへのアクセスやC2通信などを遮断する防御手法である

PDNSは、フィッシングサイトへのアクセスだけでなく、感染後のC2通信や悪性の送信先への通信など、攻撃の複数の段階で通信をブロックする防御手法です。

なぜサプライチェーンを狙うサイバー攻撃が増えているのか

攻撃者は「最も侵入しやすい1社」を狙う

大手企業を中心に、EDRやファイアウォール、SOCによる監視など、さまざまなセキュリティ対策が導入されています。それでも、委託先や取引先を起点としたサイバー攻撃によって被害を受けるケースは後を絶ちません。

その背景にあるのが、攻撃対象の変化です。

攻撃者は必ずしも、セキュリティ対策が強固な本命企業を正面から突破する必要はありません。企業が数百・数千社の委託先や取引先とつながっていれば、その中からセキュリティ対策が比較的弱い企業を探し、侵入の突破口として利用できます。

ウェビナーでも、発注元企業を直接攻撃するよりも、数百・数千の侵入口候補から突破口を選べることが、サプライチェーンが狙われる背景として挙げられました。

【サプライチェーン攻撃の構造を「時代劇」で分かりやすく解説】
「なぜ攻撃者は本命企業を直接狙わず、取引先を突破口にするのか」。
この構造をより直感的に理解していただくため、サプライチェーン攻撃を“時代劇”になぞらえたショートムービーを公開しています。

鉄壁の守りを誇る「本丸」を直接狙うのではなく、城下の小さな「呉服屋」を利用して本丸へ迫る――。
サプライチェーン攻撃の特徴を短いストーリーでご覧いただけます。

▼時代劇で分かる「サプライチェーン攻撃」の脅威はこちら
https://constella-sec.jp/blog/cyber-security/supply-chain-attack-jidaigeki/

つまり、攻撃者から見れば、「最も守りが堅い企業」を突破する必要はなく、「最も侵入しやすい1社」を見つければよいのです。

自社のセキュリティ対策だけでは防ぎきれない

ここに、サプライチェーンを守る難しさがあります。

攻撃者は、多数の企業の中から一つの突破口を見つければよい。一方、防御する側は、自社だけでなくサプライチェーン全体に存在するリスクを考える必要があります。

そのため、自社に高度なセキュリティ対策を導入しているからといって、サプライチェーンを起点とするリスクまでなくなるわけではありません。

では、自社とつながるすべての企業のセキュリティ水準を高めれば解決するのでしょうか。
実際には、そこにも大きな課題があります。

取引先ごとのセキュリティ対策だけでは不十分な理由

数百・数千社のセキュリティ水準を引き上げる難しさ

委託先や取引先にセキュリティチェックを実施したり、教育や認証取得を求めたりすることは、サプライチェーンのセキュリティを高めるうえで重要です。

しかし、取引先が数百・数千社に及ぶ場合、各社のセキュリティ水準を個別に引き上げ、それを継続的に管理していくには膨大な時間とコストが必要になります。

ウェビナーでも、チェックシート・教育・認証取得などの取り組みは「必要だが不十分」であり、数百~数千の取引先を個社ごとに引き上げるには、膨大な投資と長い年月を要するという課題を挙げています。

また国内では、サプライチェーン全体のセキュリティ水準向上に向けて「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」の整備も進められています。発注元企業にとって、取引先を含めたセキュリティリスクをどのように管理するかは、今後さらに重要なテーマとなっていくでしょう。

SCS評価制度の概要や、発注元企業に求められる対応については、以下の記事で詳しく解説しています。

▼関連記事:SCS評価制度について詳しくはこちら

「個社を守る」から「サプライチェーン全体を守る」へ

もちろん、個々の企業のセキュリティ対策を強化することは引き続き重要です。

一方で、それだけではなく、サプライチェーン全体で共通して利用できる防御の仕組みを設けるという考え方もあります。

発注元企業が取引先に対して個別に「このセキュリティ製品を導入してください」「この水準まで対策を強化してください」と求め続けるのではなく、発注元側が共通の安全基盤を提供し、取引先が低い負荷で参加できる仕組みを構築するというアプローチです。

ウェビナーでは、この考え方を『「要求するセキュリティ」から「共有するセキュリティ」へ』と表現しました。

では、企業ごとにIT環境や導入しているセキュリティ製品が異なるなかで、サプライチェーン共通の防御ポイントをどこに設ければよいのでしょうか。

その一つの選択肢となるのが、さまざまなインターネット通信で利用されるDNSです。

サプライチェーンの共通防御に活用できる「Protective DNS(PDNS)」とは

Protective DNS(PDNS)とは、DNSによる名前解決の段階でアクセス先のドメインを判定し、悪性ドメインへの通信を遮断するセキュリティ対策です。

危険な通信が成立する前の段階でブロックできることが、PDNSの大きな特徴です。ウェビナーでも「危険な通信を発生前に止める」防御手法として紹介しました。

そもそもDNSとは

DNS(Domain Name System)は、Webサイトなどへアクセスする際に、人が利用するドメイン名とIPアドレスを対応付ける仕組みです。

たとえば、ユーザーがWebサイトへアクセスしようとすると、端末はDNSに問い合わせを行い、ドメイン名に対応するIPアドレスを確認したうえで通信を行います。

このDNSは、企業のさまざまなインターネット通信で利用される共通の仕組みです。

ウェビナーではDNSを、サプライチェーン全体を守るための「共通防御ポイント」と位置付けました。さまざまな通信が通過する「関所」としてDNSを活用することで、通信を効率的に可視化・制御するという考え方です。

Protective DNS(PDNS)の仕組み

通常のDNSでは、端末から問い合わせを受けると、対象となるドメインの名前解決を行います。

PDNSでは、この名前解決の過程でアクセス先のドメインを判定します。

問い合わせ先が安全なドメインであれば通常どおり名前解決を行いますが、悪性ドメインと判定された場合は名前解決を行わず、通信をブロックします。

つまり、実際に悪性サイトや攻撃者のサーバへ接続した後で対処するのではなく、「接続しようとする段階」で通信を止めることができます。

Protective DNS – 危険な通信を発生前に止める

PDNSは攻撃のどの段階で有効なのか

PDNSは、単に危険なWebサイトへのアクセスを防ぐだけではありません。

ウェビナーでは、攻撃の流れを例に、次の3つの段階でPDNSを活用できることを紹介しました。

  1. フィッシングサイトへのアクセス
    ユーザーがフィッシングサイトへアクセスしようとした際、悪性ドメインへの名前解決をブロックすることで、偽サイトへのアクセスを防ぎます。
  2. マルウェア感染後のC2通信
    万が一端末がマルウェアに感染した場合でも、攻撃者が操作に利用するC2サーバのドメインへの名前解決をブロックすることで、攻撃者との通信を遮断します。
  3. 取得情報の外部送信
    攻撃者が窃取した情報を外部へ送信しようとする際も、悪性の送信先への通信をDNSの段階で阻止できる可能性があります。

このようにPDNSは、攻撃の複数の段階に対して防御ポイントを設けることができます。

なぜDNSがサプライチェーンの共通防御に向いているのか

企業によって、利用している端末やネットワーク環境、EDR、UTMなどのセキュリティ製品は異なります。そのため、サプライチェーンに参加するすべての企業へ同一のセキュリティ製品を展開しようとすると、各社の環境に合わせた導入・設定・運用が必要になり、管理負荷やコストが大きくなります。

一方、DNSはさまざまなインターネット通信で利用される共通レイヤーです。

ウェビナーでは、DNSを起点にすることで広い範囲をカバーしやすく、既存環境にも組み込みやすいという考え方を紹介し、「全社共通の通信経路」と位置付けています。

各社に同じセキュリティ製品の導入を求めるだけではなく、共通するDNSというレイヤーを利用して防御する。

これが、PDNSをサプライチェーン全体の防御に活用する考え方です。

CSJ Protective DNSで実現する「共有するセキュリティ」

サプライチェーンを狙う攻撃に対し、すべての取引先へ一律に高度なセキュリティ対策を求め続けることには限界があります。

そこでCSJが提案しているのが、発注元企業が共通の防御基盤を提供し、サプライチェーン全体で利用するという考え方です。

「セキュリティを上げてください」と要求するセキュリティから、共通の仕組みを「共有するセキュリティ」へ。

その実現を支援するサービスが、CSJ Protective DNSです。

ウェビナーでも、個々の企業にセキュリティ強化を要求する形から、サプライチェーンの中でセキュリティを共有する形へ変えていく必要があるという考え方を紹介しました。

取引先に大きな負担をかけずに展開

サプライチェーン全体へのセキュリティ対策を考えるうえで、大きな課題になるのが導入・運用の負担です。

たとえばUTMであれば拠点ごとに機器の調達・設置・設定が必要になり、EDRであれば端末ごとにエージェントを導入・運用する必要があります。対象となる企業や拠点、端末が増えるほど管理負荷も増加します。

CSJ Protective DNSは、DNSの設定変更によって導入でき、新たな専用機器の設置やPCごとの設定変更を必要としません。

取引先の環境へ大きな変更を求めることなく展開できるため、多数の企業が参加するサプライチェーンにおいても導入負荷を抑えることができます。

既存のセキュリティ対策を置き換えずに補完

PDNSは、EDRやIAMなどの既存のセキュリティ対策を置き換えるものではありません。

既存の対策はそのまま活用しながら、その上にDNSという共通の防御レイヤーを加えることで、多層防御を強化するという位置付けです。

CSJ Protective DNSについても、ウェビナーではEDR・IAMなどを置き換えるのではなく、既存対策を補完する共通の観測レイヤーとして整理しています。

サプライチェーン全体を横断的に可視化

複数の企業が同じ基盤を利用することで、個々の企業だけでは把握しにくい通信兆候をサプライチェーン全体で観測できるようになります。

ウェビナーでは、サプライチェーンの中で「どのような攻撃を受けているのか」「誰が攻撃しているのか」といった情報を把握し、次に取るべき対策を検討するための材料として活用できる可能性についても紹介しました。

個社ごとに防御を完結させるだけでなく、参加企業が共通の基盤を利用し、サプライチェーン全体の防御力向上につなげていく。
CSJ Protective DNSは、こうした「共有するセキュリティ」を実現するための一つのアプローチです。

CSJ Protective DNSを無料でお試しいただけます

CSJ Protective DNSは、無料でお試しいただけます。

「多数の取引先へどのように展開すればよいのか」「現在導入しているセキュリティ製品と組み合わせて利用できるのか」など、導入や活用方法についてご興味がございましたら、お問い合わせフォームよりお気軽にご相談ください。

CSJ Protective DNSの機能やサービスの詳細は、[サービス紹介ページ]をご覧ください。

ウェビナー動画でも詳しく解説しています

本記事では、サプライチェーン攻撃が増加する背景から、共通防御という考え方、Protective DNS(PDNS)の仕組みと活用方法についてご紹介しました。

ウェビナー動画では、サプライチェーン攻撃の背景やPDNSの仕組みについて、当日の資料を交えながら詳しく解説しています。

一緒によく読まれている記事

関連したサービスの紹介記事

最新の脅威情報
をお届け

BLOGブログ

情報セキュリティに対する啓蒙のため、
3つのメディアを運用し、
情報発信を行っています。

わたしたちはサイバー領域や
認知領域の未知なる脅威に、
テクノロジーとインテリジェンスで対抗します。

私たちが選ばれる理由

CONTACT リスクマネジメントサービスの
ご相談窓口

コンステラ セキュリティ ジャパンは
最先端のサービスを
お客様のニーズに
カスタマイズして提供し、
効果が出るまで寄り添います。