IT & Information security Journal

  1. UNITIS
  2. 脅威とサイバー攻撃
  3. tenki.jpのDDoS被害事例に学ぶ事業判断と対策フロー AWS Summit Japan 2025レポート

tenki.jpのDDoS被害事例に学ぶ事業判断と対策フロー AWS Summit Japan 2025レポート

2025年1月、天気予報専門メディアである「tenki.jp」は約2週間にわたり、大規模なDDoS攻撃を受け、複数回のサービス障害が発生しました。

2025年6月25日〜26日に開催された「AWS Summit Japan 2025」では、tenki.jpの企画開発を管掌し、DDoS攻撃への対処・復旧にあたった森島 昌洋氏が、被害時の社内の状況や、事後対応のなかで得られた教訓、ソリューション選定時に定めた基準など、対応当時の裏側を明かしました。

この記事のポイント


  • tenki.jpは2025年1月、断続的なDDoS攻撃に見舞われた。台風・地震発生時の高負荷にも耐えられるシステムと運用体制を備えていたが、対応は困難だった

  • セキュリティインシデントが発生した際、事業部門は対応をエンジニアに任せきりにせず、事業的側面からの判断を行わなければならない

  • tenki.jpでは、対策ソリューションの選定にあたり、多くの基準を設けることで検討に時間がかかるのを避けるため、「稼働中のシステムへの導入検証が容易であること」「継続的な改善を支える『生態系(エコシステム)』が存在すること」の2つのポイントに絞って検討した

  • サービスをサイバー攻撃から守るためには、ビジネスサイドの人間が「対策は余分なコストではなく保険」という意識を持つことが重要

高トラフィックに対応可能なシステムを追い込んだDDoS攻撃

tenki.jpは、森島氏が所属する株式会社ALiNKインターネットと一般財団法人日本気象協会が共同運営している天気予報専門メディアで、年間約59億ページビュー(2023年4月~2024年3月)にのぼる国内でも有数のWebサービスです。

そのtenki.jpは2025年1月、断続的なDDoS攻撃に見舞われました 1。平時から1時間あたり50万~150万セッションのトラフィックを処理しており、台風・地震発生時の高負荷にも耐えられるシステム、そして運用体制が整っていましたが、「その実績があっても、今回のDDoS攻撃は対応が非常に困難だった」と、森島氏は振り返ります。

今回のDDoS攻撃が最初に確認されたのは、1月5日の午前中でした。断続的な高負荷のアタックが発生し、やがて運営サーバーを格納しているデータセンターにまで影響を与えるレベルになったことから、tenki.jpへのアクセスをすべて破棄(ブラックホール化)する「RTBH(Remotely Triggered Black Hole)」の措置をとることを決定します。いったんの収束をみたのは、それから約8時間後のことでした。

「前日から豪雪が続いていた地域もあり、tenki.jpへのアクセスが増えやすい状況のなかサービスが停止したため、SNSやマスメディアのニュースでも大きな話題となった 2。サービスをこれだけ多くの方に使ってもらっているんだと改めて気づくと同時に、社会的インフラの1つを一時的にでも潰してしまったんだなと思い、この日から当社では焦りながら対応を始めた」(森島氏)

攻撃はその後、約2週間にわたり断続的に続きました。対応が完了したかと思うと、また豪雨のようなトラフィックが襲ってくる。それも乗り切ったと思うと、また次の攻撃が来る……という波状攻撃に遭い、森島氏は攻撃が非常に執拗で長期化していることを実感したといいます。

森島 昌洋 氏(株式会社ALiNKインターネット 執行役員 兼 サービス統括部部長)
森島 昌洋 氏(株式会社ALiNKインターネット 執行役員 兼 サービス統括部部長)

被害経験から振り返る、DDoS攻撃の4つの特徴

森島氏はこうした被害経験から、昨今のDDoS攻撃の手法について、特に4つの特徴が見られると説明します。

1つ目の特徴は、攻撃「先」のIPアドレスが頻繁に変更されることです。攻撃者は総当たり的にアタックすることで脆弱性を見つけ、そこを突くことを狙っていたのではないかと森島氏は推測します。tenki.jpでは幸い、脆弱性に起因する被害はありませんでした。

2つ目は、攻撃「元」のIPアドレスも頻繁に変更され、多様なIPアドレスから攻撃が仕掛けられる点です。これによって、学習型のIPフィルタリングを行っても防御が追いつかなくなってしまいます。

3つ目は、被害側の対策状況に合わせた様々な攻撃手法を用いてくるということです。同社への攻撃も、はじめはリフレクション攻撃(※1)だったのが、ある時からSYNフラッドアタック(※2)に変化するなど、1つの攻撃手法に対応すると次の手法に切り替わってしまい、対応に終わりがなかったと森島氏は語りました。

(※1)DNSサーバーなど、問い合わせよりも応答が増幅される特性を持つサーバーに対して、ボットネット(攻撃基盤)から大量の問い合わせを送りつけ、増幅された応答が標的のシステムに集中するよう仕向ける攻撃


(※2)サーバーへの接続要求(SYN)を継続的に送りつけ、サーバーのリソースを枯渇させる攻撃

そして4つ目の特徴が、攻撃の流量を変えてくるということです。いきなり大きな負荷を与えるのではなく段階的に負荷を上げたり、突然スパイク(急激なトラフィックの上昇)を発生させたりするので、対応をどうすべきかの判断が非常に困難になります。

最終的に同社は、最大60Gbps超の攻撃を受けました。大地震や台風の接近時にもビクともせずにレスポンスしていたサービスが止まったことからも、その攻撃規模の大きさがわかります。

有事に大切なのはエンジニアとビジネスサイドの意思統一

攻撃の手法や、攻撃の継続期間を見定めることが困難ななか、tenki.jpではどのような方針を定めて対応を進めたのでしょうか。

森島氏は当初、短期のうちにとにかく通常稼働できるまでに復旧することを目指しました。そこで、初動においては「効果の高低よりも、すぐに実施できる対策かどうかから考える」「システム変更は極力回避する」そして「大規模な防御策を導入するにあたっては、日本気象協会やその他のパートナーにかかるコストを最小化できるようにする」という指針を示しました。

「当時は、とにかく今のインフラやクラウド上で即応できることをすべてやれば乗り越えられると考えた。結果的には不十分で、先ほど申し上げたとおり約2週間の断続的な障害に至ってしまった」(森島氏)

tenki.jpが設定した、短期・中期・長期でのゴールと要求事項
tenki.jpが設定した、短期・中期・長期でのゴールと要求事項

その教訓から森島氏は、障害発生時であっても、ビジネスサイドは中期的・長期的な視点を持って考えることが非常に大切だと語りました。

「当時の自分自身の反省も込めて、攻撃を受けた際にビジネスサイドから『何とかしろ』と指示されたら、エンジニアは怒っていい。ビジネスサイドは『何とかしろ』としか言えないのであれば問題。有事でも適切な判断ができるよう、事業環境やセキュリティリスクについて普段から学んでおかなければならない。エンジニアとビジネスサイドが意思統一して動けることが重要だ」(森島氏)

同社では、改めて中長期的な視野に立ち、まず必要な機能や検証要件を洗い出したうえで、包括的な防御が可能な新ソリューションを導入することを中期目標としました。そのうえで、多くの基準を設けることで検討に時間がかかってしまうことを避けるため、森島氏は選定ポイントを2つに絞ったといいます。1つは「稼働中のシステムへの導入検証が容易であること」、そして「継続的な改善を支える『生態系(エコシステム)』が存在すること」です。

「一度対策したから終わりというわけではない。この意識をビジネスサイドが持っていないと、必ず2度目、3度目のインシデントを起こしてしまう。上層部にも、対策は1回限りではなく、継続的に対策をとることでサービスを安定させていくことを説明した。そうした合意をとっておかないと『◯か月経ったのにまだ事故対応をしている』などと言われ、必要なインシデント対応を継続できなくなってしまう」(森島氏)

導入ソリューションにより、翌月のDDoS攻撃では被害なし

こうした選定ポイントをもとに選ばれたのが、AWSのソリューションでした。

tenki.jpのサービスでは、最短5分単位でデータが更新される天気予報、膨大なデータ生成処理を必要とする雨雲レーダー、地震が起こるとユーザーから頻繁なアクセスが行われる地震の震度情報など、性質が異なる複数のコンテンツを扱っています。

tenki.jpが扱うコンテンツごとの性質の違い
tenki.jpが扱うコンテンツごとの性質の違い

そのため、DDoS対策のためのソリューションとしては、コンテンツそれぞれの特性に合わせた多様なインフラで稼働でき、柔軟な機能・ルールの設定が可能、かつロールバックが簡単で、段階的に実装しながら本番環境できちんと検証できるものが求められました。

その要求に応えるソリューションとして選定されたのが、AWS WAFと Amazon CloudFrontでした。Amazon CloudFrontはWebコンテンツの配信を高速化するCDNサービスです。分散配置した拠点のサーバーにコンテンツが置かれ、ユーザーから閲覧を求められた際には、レイテンシー(遅延時間)が最も短いエッジロケーション(拠点)から当該コンテンツを配信。これによって配信速度を上げると同時に、サーバーの負荷を下げることができます。

各ソリューションの導入は、「稼働中のシステムへの導入検証が容易であること」という選定ポイントのとおりスムーズに進み、さらに継続的なチューニングを実施したことで、同社のDDoS攻撃への耐性は格段に進化しました。森島氏は、翌月に約30分間で数百万リクエストという規模のDDoS攻撃を受けたものの、サービスには支障がなかったとその効果に言及しました。

ソリューション導入後のPDCAを支える「エコシステム」

こうした導入効果が得られたのは、AWSのソリューションの性能に加えて、適切なPDCAサイクルを回したことも要因だと森島氏は言います。導入段階ではAmazon CloudFrontに用意されているマネージドルールをベースにして迅速に立ち上げたうえで、tenki.jpのサービスそれぞれに合わせてカスタムルールを追加、その後はログをモニタリングして、ルールをさらに最適化していくという工程を繰り返したのです。

また、AWSのソリューションを導入したことによって、コスト面のPDCAも回せるようになったといいます。同社では、設定した予算を超えるとアラートが出るAWS Budgetsを利用し、特に変動幅が大きいWAFのBot Control 3 では、コントロール状況とコストを見比べながら「コストに対してそれほどアタックがない領域は外す、アタックを受けている領域についてはある程度コストを積んでもルールを追加する」といったようにルール設定を変更するなど、コスト抑制のための手立てを講じることができるようになりました。

こうした改善を日々繰り返すことで、各サービスのパフォーマンス、システム負荷、そしてコストを最適な状態に保てるようになったといいます。

AWSソリューションの導入から最適化までのPDCA
AWSソリューションの導入から最適化までのPDCA

森島氏は、こうした改善が行えるのは「継続的な改善を支える『生態系(エコシステム)』の存在」のおかげだとして、周辺ツールや管理機能が豊富なこと、ナレッジサポートはもちろん、関連コミュニティなどのエコシステムに蓄積された豊富な事例やノウハウがあること、そして異なる強みを持つ多くのAWSパートナーがいることを、AWSの強みとしてあげました。

導入後の改善を可能にするAWSのエコシステム
導入後の改善を可能にするAWSのエコシステム

セキュリティ対策は余分なコストではなく保険

tenki.jpは、インシデント発生から約1か月でAWSソリューションの導入を決定した後は、アマゾンウェブサービスジャパン合同会社やパートナー企業の技術支援のもと、わずか10日ほどで本番環境の実装にまでたどり着きました。

「これはAWSソリューションの優秀さ、パートナー企業の存在、そして私たちのエンジニアの努力の賜物だったと思っている」(森島氏)

最後に森島氏は、サービスを守るためには、ビジネスサイドの人間が「対策は余分なコストではなく保険」という意識を持つことの重要性に触れました。不幸にしてインシデントが起こってしまった時は、対応をエンジニアサイドに任せっきりにせず、エンジニアが一生懸命やっていることを整理する、あるいはどこまでのリスクや損失を飲み込めるかの判断を下し、事業を安定的に運用するのがビジネスサイドの役割だと、森島氏は強調しました。

「tenki.jpは、一度はサービス障害を起こしてしまった。ただ、『災い転じて福となす』ではないが、AWSソリューションを継続的に運用することで、皆さまの安心を守るサービスとして今後も進化を続け、新しい価値、安心をお届けしたいと思っている」(森島氏)

(文:渡邊智則)


この記事は会員限定です。
登録すると続きをお読みいただけます。

UNITIS 利用規約に同意のうえ

このサイトはreCAPTCHAによって保護されており、
Googleの プライバシーポリシー利用規約 が適用されます。

UNITISは、IT・セキュリティ担当者へ、実務家・専門家による解説や他社事例等を伝えるメディアです。セキュリティ・法律の専門家による実務解説や分析、第一線の実務家による事例・ノウハウをお届けします。

あわせて読みたい

この記事をシェアする

TOP