DDoS攻撃の事例と経営リスク|事業継続のための必須対策とは?
DDoS攻撃は、企業の事業継続を脅かす重大なサイバーリスクとして認識されていますが、その具体的な被害の実態を把握するのは容易ではありません。対策の必要性を感じていても、どのような企業がどのような被害を受けたのかを知らなければ、自社にとってのリスクを正しく評価し、適切な投資判断を下すことは困難です。この記事では、国内外で実際に発生したDDoS攻撃の被害事例を業界別に詳しく紹介し、その手口から経営に与える影響、そして企業が取るべき具体的な対策までを解説します。
DDoS攻撃の基本知識
DDoS攻撃の定義と仕組み
DDoS攻撃(Distributed Denial of Service attack)とは、世界中に分散した多数のコンピュータから、特定のサーバーやネットワークに対して一斉に過剰なアクセスを送りつけ、サービスを提供不能に陥らせるサイバー攻撃です。攻撃者は、マルウェアに感染させて乗っ取った第三者のPCやIoT機器で「ボットネット」と呼ばれる巨大なネットワークを構築し、攻撃の踏み台として悪用します。
所有者が気づかないうちに、これらの機器から標的のサーバーへ大量の処理要求が送信されるため、サーバーの処理能力や回線の帯域が限界を超え、システムダウンを引き起こします。攻撃元が膨大かつ分散しているため、単一の送信元からの攻撃(DoS攻撃)と比べて防御が極めて困難になるのが特徴です。
攻撃者の主な目的
DDoS攻撃の背後には、多様な動機や戦略的な目的が存在します。ウェブサービスが社会経済の重要なインフラとなっている現代では、サービスを一時的に麻痺させるだけで標的に大きな打撃を与えられるためです。
- 金銭の要求: 攻撃を停止する見返りに金銭を要求する「ランサムDDoS」と呼ばれる脅迫行為。
- 政治的・社会的な抗議: ハクティビストと呼ばれる活動家集団が、政府機関や大企業に対して抗議の意思を示すために行う妨害行為。
- 競合他社への妨害: 競合企業のサービスを停止させ、自社の優位性を確保しようとする営業妨害。
- 他の攻撃の陽動: DDoS攻撃でシステム担当者の注意を引き、その隙に不正アクセスや情報窃取など、より深刻な攻撃を仕掛けるための目くらまし。
代表的な攻撃手法の種類
DDoS攻撃は、標的とするシステムの弱点に応じて、大きく2種類に分類されます。それぞれ攻撃対象となるOSI参照モデルの階層や、用いる通信プロトコルが異なります。
| 攻撃の分類 | 概要と目的 | 代表的な攻撃手法 |
|---|---|---|
| ネットワーク帯域消費型 | 通信回線やネットワーク機器の許容量(帯域)を大量のデータで飽和させ、通信を物理的に詰まらせる。 | SYNフラッド攻撃:接続要求(SYNパケット)を大量に送りつけ、サーバーの接続待ちリソースを枯渇させる。 |
| UDPフラッド攻撃:応答確認が不要なUDPの性質を悪用し、大量のデータを一方的に送りつける。 | ||
| システム資源消費型 | サーバーやアプリケーションの処理能力(CPU、メモリ)を不正なリクエストで使い果たさせ、機能を停止させる。 | HTTPフラッド攻撃:Webページの表示要求を大量に送信し、Webサーバーやデータベースに過負荷をかける。 |
| スローHTTP攻撃:少量のデータを極めて低速で送り続け、接続を不当に長時間占有してサーバーを疲弊させる。 |
【国内】企業のDDoS攻撃被害事例
航空・運輸業界での事例
国内の航空・運輸業界では、DDoS攻撃によって予約システムや搭乗手続きシステムといった重要インフラが停止し、社会的に広範な影響を及ぼした事例があります。特に、年末年始などの繁忙期に大手航空会社が標的となり、大量のデータ通信によってネットワーク機器がダウンしました。
この結果、空港での自動チェックイン機が使用不能となり、多くの便で出発遅延や欠航が発生するなど、深刻な運航障害につながりました。攻撃者は防御策に応じて攻撃手法を巧妙に切り替えるなど、執拗な攻撃を行ったと報告されており、社会インフラを担う企業の事業継続性を揺るがすリスクが浮き彫りになりました。
金融機関を狙った事例
国内の金融機関を標的としたDDoS攻撃では、インターネットバンキングや決済システムへのアクセスが妨害され、利用者の経済活動に直接的な影響を与えました。金融サービスは社会の信用基盤であるため、わずかなシステム停止でも利用者に大きな不安を与えます。
過去の事例では、都市銀行のオンラインサービスが大量のデータ送信によって長時間にわたり利用不能となり、法人の資金決済業務などが麻痺する事態に至りました。また、自社が直接の標的でなくとも、同じクラウド基盤を利用する他社への攻撃の巻き添え(コロケーション・ダメージ)でサービスが停止する二次被害も発生しており、インフラの可用性を確保することの難しさを示しています。
通信・インフラへの攻撃事例
通信事業者や電力、気象情報といった社会の生命線ともいえる重要インフラ分野も、DDoS攻撃の標的となっています。これらの基盤サービスが停止すると、その上で成り立つ多くのビジネスや社会生活に連鎖的な影響が及ぶため、脅威レベルは極めて高いと認識されています。
実際に、通信事業者のポータルサイトや決済機能が攻撃を受け、スマートフォン決済が一時的に利用できなくなるなど、経済活動に直接的な支障が生じました。また、防災情報を提供する気象専門メディアが攻撃され、情報提供が遅延する事案も発生しています。こうした事態を受け、内閣サイバーセキュリティセンター(NISC)が公式に注意喚起を行うなど、国家レベルでの対策が求められています。
【海外】歴史的な大規模攻撃事例
DNSサービスを狙ったDyn社の事例
2016年、米国のDNSサービス提供大手Dyn社が大規模なDDoS攻撃を受け、インターネットの広範囲な領域で接続障害を引き起こしました。DNSは、ウェブサイトのドメイン名とIPアドレスを対応付ける「インターネットの住所録」の役割を担っており、ここを攻撃されると個別のサイトが正常でもアクセスできなくなります。
この攻撃では、「Mirai」と呼ばれるマルウェアに感染した世界中の脆弱なIoT機器(防犯カメラやルーターなど)数十万台で構成されたボットネットが悪用されました。これにより、著名なSNSや動画配信、通販サイトなどが長時間にわたり利用不能となり、特定のサービスに依存するサプライチェーン全体の脆弱性が露呈した歴史的な事件です。
ソースコード管理サービスGitHubの事例
2018年、ソフトウェア開発プラットフォームであるGitHub社が、当時観測史上最大となる毎秒1.35テラビットに達するDDoS攻撃を受けました。この攻撃では、設定不備のある「Memcached」サーバーを悪用した増幅攻撃(リフレクション攻撃)が用いられました。
攻撃者は送信元IPアドレスをGitHub社のものに偽装し、複数のMemcachedサーバーへ小さなリクエストを送信。リクエストを受け取ったサーバー群は、数万倍に増幅された応答データを一斉にGitHub社へ送り返し、膨大なトラフィックを発生させました。しかし、同社はクラウド型のDDoS対策サービスへ迅速に通信を切り替えることで、サービス停止をわずか数分に留めることに成功し、大規模攻撃に対する防御の好事例ともなりました。
大手クラウドサービスを標的とした事例
近年、Microsoft Azureのような大手クラウドプラットフォーム自体を標的とする超大規模なDDoS攻撃が増加しています。多くの企業が基幹システムをクラウドに移行しているため、クラウド基盤を麻痺させることは世界経済に多大な影響を与える効率的な攻撃手段となりつつあります。
実際に、Azureに対して数百万台のボットネットから数テラビット級の攻撃が複数回仕掛けられました。しかし、クラウド事業者がグローバルに配備している「トラフィックスクラビングセンター」と呼ばれる大規模な洗浄基盤が攻撃トラフィックを自動的に検知・吸収し、不正な通信のみを無害化しました。これにより、サービスを利用する数万の顧客企業への影響はほぼゼロに抑えられ、自社単独での防御には限界がある現代において、大規模プラットフォームの活用が不可欠であることを示しています。
事例から見る経営への影響
事業停止による直接的な売上損失
DDoS攻撃によるウェブシステムの停止は、オンラインビジネスにとって致命的です。ECサイトや予約サイトが停止すれば、その時間内に得られるはずだった売上は完全に失われます。この機会損失は、サービス再開後に取り戻すことができません。
さらに、顧客が競合他社のサービスへ流出し、そのまま戻ってこないという永続的な顧客離反のリスクも伴います。加えて、サービス品質保証(SLA)の不履行に伴う違約金の支払いや、返金対応にかかる事務コストなど、売上減少以外の財務的ダメージも発生し、企業の収益計画に深刻な影響を及ぼします。
顧客信用の低下とブランドイメージ毀損
サービスが必要な時に利用できないという事態は、企業の信頼を根底から揺るがします。特に金融や決済サービスなど、生活に密着したインフラが停止した場合、利用者の不安は計り知れません。「安全ではない」「管理体制がずさんだ」といった悪評はSNSなどを通じて瞬時に拡散され、長期的に築き上げてきたブランドイメージを大きく毀損します。
一度失われた信頼を回復するには、多大な時間とマーケティング費用が必要となり、企業の長期的な成長を阻害する要因となります。サービスの安定稼働、すなわち可用性の確保は、技術的な課題であると同時に、ブランド価値を守るための最優先の経営課題です。
想定外のインフラコストと対応費用
DDoS攻撃は、売上機会の損失だけでなく、想定外の多額な事後対応費用を発生させます。インシデント対応には、専門的な知識と緊急の支出が不可欠です。
- インフラの超過料金: 従量課金制のクラウドサービスでは、攻撃による大量のトラフィックにも課金され、高額な請求が発生するリスクがある。
- 専門家への依頼費用: 攻撃の状況を調査・分析するためのデジタルフォレンジック費用や、セキュリティ専門家へのコンサルティング費用。
- 緊急対策費用: 攻撃を遮断するための防御システムの緊急導入や、代替システムへの切り替えにかかる費用。
- 人件費: 復旧作業や顧客対応のために、情報システム部門や関連部署の従業員が長時間稼働することによる超過人件費。
インシデント発生時の事業継続計画(BCP)との連携
DDoS攻撃のようなサイバー攻撃に備えるには、自然災害を想定した従来の事業継続計画(BCP)を拡張し、サイバーインシデントのシナリオを明確に組み込む必要があります。サイバー攻撃は、物理的な被災と異なり、地理的な制約なく突発的に発生し、代替拠点への切り替えだけでは業務を再開できない特性があります。
そのため、重要システムが停止した場合に、機能制限を設けてサービスを継続する「縮退運転」への移行手順や、オフラインでの代替業務プロセスなどを事前に定めておくことが重要です。技術的な防御が突破されることを前提に、経営レベルで事業継続のための実効性ある計画を策定し、訓練しておくことが真のレジリエンス(回復力)につながります。
企業が取るべきDDoS攻撃対策
WAFによる不正通信の遮断
WAF(Web Application Firewall)は、アプリケーション層を狙う巧妙なDDoS攻撃を防御するための必須の対策です。通常のファイアウォールがIPアドレスやポート番号で通信を制御するのに対し、WAFは通信の中身(HTTPリクエストなど)を詳細に検査し、不正なリクエストを遮断します。
例えば、同一IPアドレスからのリクエスト数を制限する「レート制限」や、低速な通信で接続を占有し続ける「スローHTTP攻撃」を検知して切断するなど、アプリケーションの正常な動作を保護します。これにより、サーバーのリソースが枯渇するのを防ぎ、サービスの安定稼働を支えます。
CDNを活用したトラフィック分散
CDN(Content Delivery Network)は、大規模なネットワーク帯域消費型(ボリューム型)攻撃に対する最も効果的な対策の一つです。世界中に分散配置された多数の「エッジサーバー」が、自社のサーバー(オリジンサーバー)の身代わりとなってトラフィックを受け止めます。
攻撃トラフィックはグローバルに分散したエッジサーバー群に吸収・無害化されるため、オリジンサーバーに過大な負荷が到達するのを防ぎます。これにより、たとえテラビット級の攻撃を受けたとしても、正規のユーザーは最寄りのエッジサーバーから快適にコンテンツを閲覧でき、サービスの可用性を維持することが可能です。
継続的なトラフィック監視と検知
平時からネットワークの通信状況を継続的に監視し、異常な変化を早期に検知する体制を構築することが重要です。攻撃の予兆をいち早く掴むことで、被害が発生する前、あるいは被害が拡大する前に、迅速な初動対応が可能になります。
具体的には、通信量やパケットの種類をリアルタイムで分析する仕組みを導入したり、24時間365日体制で監視を行うSOC(Security Operation Center)サービスを活用したりすることが有効です。平常時の通信パターンを把握しておくことで、異常発生時に的確な防御措置を講じるための意思決定を迅速に行えます。
対策コストと事業リスクのバランスをどう考えるか
DDoS攻撃対策への投資は、単なる「コスト」ではなく、事業の安定稼働と顧客の信頼を確保するための「戦略的投資」と捉えるべきです。安価な対策では、実際に大規模な攻撃が発生した際に防御能力が不足し、意味をなさない可能性があります。
重要なのは、自社のサービスが停止した場合にどれほどの売上損失や信用の低下につながるかを定量的に評価し、その事業リスクに見合ったレベルの対策を講じることです。完璧な防御を目指して過剰なコストをかけるのではなく、事業の重要度に応じた多層防御を組み合わせ、経営体力とリスクのバランスを取った最適な投資判断が求められます。
DDoS攻撃に関するよくある質問
Q. DDoS攻撃とDoS攻撃の違いは何ですか?
目的は同じですが、攻撃元の数に決定的な違いがあります。この違いにより、防御の難易度が大きく異なります。
| 項目 | DoS攻撃 (Denial of Service) | DDoS攻撃 (Distributed Denial of Service) |
|---|---|---|
| 攻撃元の数 | 単一のコンピュータ | 多数のコンピュータ(ボットネット) |
| 攻撃元の特定 | 比較的容易 | 極めて困難 |
| 防御の難易度 | 比較的低い(攻撃元IPアドレスを遮断すればよいため) | 非常に高い(無数の攻撃元を個別に遮断できないため) |
Q. DDoS攻撃の犯人を特定することは可能ですか?
技術的に極めて困難です。攻撃者は、マルウェアに感染させた無関係な第三者の機器を踏み台として利用し、さらに通信経路を匿名化する技術を用いるため、真の攻撃者にたどり着くことはほぼ不可能です。
攻撃パケットの送信元は、あくまで乗っ取られた機器であり、その所有者は加害者であると同時に被害者でもあります。したがって、事後的に犯人を特定して損害賠償を請求することは現実的ではないため、攻撃を受けることを前提とした事前の防御策に資源を集中させることが最も合理的な選択です。
Q. DDoS攻撃はどのような法律で罰せられますか?
DDoS攻撃は、企業の業務を妨害する重大な犯罪行為です。日本の法律では、主に以下の罪に問われる可能性があります。
- 電子計算機損壊等業務妨害罪(刑法第234条の2): 5年以下の懲役または100万円以下の罰金。
過去には、海外の攻撃代行サービスを利用した人物が警察の捜査によって逮捕・検挙された事例もあります。軽い気持ちで行ったとしても、厳しい刑事罰の対象となります。
Q. 自社が攻撃の踏み台にされないための対策は?
自社のサーバーやPCが、他者を攻撃するためのボットネットに組み込まれる(加害者になる)ことを防ぐには、日頃からの基本的なセキュリティ管理が不可欠です。
- 脆弱性管理の徹底: OSやソフトウェアのセキュリティパッチを速やかに適用し、既知の脆弱性を放置しない。
- 不要なサービスの停止: 使用していないポートやサービスを無効化し、攻撃の侵入口を減らす。
- 適切なアクセス制御: 推測されにくい強力なパスワードを設定し、不要な管理者アカウントを削除する。
- 不正通信のフィルタリング: 送信元IPアドレスが偽装されたパケットを外部に送信しないよう、ネットワーク機器でフィルタリング(egress filtering)を設定する。
Q. もしDDoS攻撃を受けたら、まず何をすべきですか?
万が一DDoS攻撃が疑われる場合、パニックにならず、事前に定めた手順に従って冷静に行動することが被害を最小限に抑える鍵となります。以下の初動対応を速やかに実行してください。
- 被害拡大の防止: 契約しているISP(インターネットサービスプロバイダ)やCDN事業者、セキュリティベンダーに緊急連絡し、攻撃トラフィックの遮断や緩和を依頼する。
- 状況の把握と証拠保全: ネットワーク機器やサーバーのアクセスログを確実に保全する。これらのログは、後の原因究明や警察への届け出、保険請求の際に不可欠な証拠となる。
- 関係各所への報告: 経営陣や法務部、広報部など、社内の関係部署へ状況を報告し、連携して対応にあたる。必要に応じて、サイバー保険会社や顧問弁護士にも連絡する。
- 外部への情報開示: 顧客や取引先に対し、ウェブサイトやSNSなどを通じて、障害の発生状況と復旧見込みを誠実に伝える。透明性のあるコミュニケーションが、信頼の低下を防ぐ。
Q. DDoS攻撃による損害はサイバー保険で補償されますか?
はい、多くの場合、サイバー保険で補償を受けることが可能です。DDoS攻撃による損害は、サイバー保険の主要な補償対象の一つに含まれています。
保険契約によりますが、一般的に以下のような損害や費用が補償されます。
- 損害調査費用: 原因究明のためのフォレンジック調査にかかる費用。
- 事業中断損失: サービス停止によって失われた逸失利益や、事業継続のために要した追加費用。
- 対応費用: コールセンター設置費用、広報コンサルティング費用など。
- 賠償責任: 取引先など第三者に与えた損害に対する法律上の賠償金や訴訟費用。
ただし、補償開始までに一定の待機時間(免責時間)が設定されている場合や、企業のセキュリティ管理に重大な過失があった場合は補償が受けられない可能性もあるため、契約内容を事前に詳しく確認することが重要です。
まとめ:DDoS攻撃の事例から学び、事業継続性を確保する
本記事では、国内外のDDoS攻撃の具体的な被害事例とその経営への影響について解説しました。航空、金融、通信といった社会インフラから大手クラウドプラットフォームまで、その攻撃対象は多岐にわたり、事業停止による直接的な売上損失や顧客信用の失墜など、企業に深刻なダメージを与えることがわかります。これらの事例は、DDoS攻撃対策が単なる技術的な問題ではなく、事業継続性を左右する重要な経営課題であることを示しています。まずは自社のサービスが停止した場合の事業リスクを具体的に評価し、そのリスクに見合った対策が講じられているかを確認することが重要です。 その上で、WAFやCDNといった技術的対策と、インシデント発生時のBCPを連携させるなど、多層的な防御体制の構築を検討しましょう。最終的な判断や具体的な実装については、セキュリティ専門家の知見を活用することが不可欠です。

