クラウド時代のDDoS対策：可用性を守るためのベストプラクティス
こんにちは！
株式会社ココナラのHead of Informationの ゆーた（@yuta_k0911）です。
AWS Community Builders Advent Calendar 2025 シリーズ2 18日目の記事です。
また、株式会社ココナラ 2/2 Advent Calendar 2025 18日目の記事も兼ねています。
2025年から AWS Community Builder（Security） に選出されました！🎉
正直なところ、「まさか自分が選出されるとは…」と思いました。
本当にありがたいことですので、Securityの領域で記事を書きたいと思います。
セキュリティに関する発信活動の中で、「DDoS攻撃対策」についてイベント登壇を2回行ったので、その内容を掘り下げてブログにしようと思います。
本記事の内容
今年の7月に1,400人以上の申込みがあった 「DEEP SECURITY CONFERENCE」 というイベントに登壇させていただきました。
その内容からポイントを抜粋したり、説明しきれなかった部分をご説明します！
登壇資料は以下に公開されていますので、あわせてご確認ください。
builders.flashにも寄稿していますので、良かったらそちらもご確認ください。
DDoS攻撃の実情
2024年の年末はDDoS攻撃によるシステム障害が多かったですよね😥
2025年もその傾向は続いています。
この記事を読んでくださっている方はDDoS攻撃が何か？をご存知な方が多いと思いますが、触れますね。
DDoS攻撃とは
DDoS攻撃とは、多数のデバイスから大量のデータを送りつけて、サービスを妨害する攻撃です。
主な攻撃タイプ:
- ボリューム攻撃: ネットワーク帯域を圧迫
- プロトコル攻撃: 機器のリソースを圧迫
- アプリケーション層攻撃: 大量アクセスでサーバーを圧迫
攻撃の目的:
- 競争相手のビジネス妨害
- 政治的・社会的な抗議活動
- シンプルに嫌がらせ
たとえると、「狭いお店にあらかじめ示し合わせた多数の人が一斉に殺到する状態」です。
著名なサービスや企業が対象になりやすい傾向ではあるものの、決して対岸の火事ではない攻撃とも言えます。
名だたる企業が対策しているにもかかわらず被害にあっているという事実も否定できません🤔
DDoS攻撃のやっかいなところは 「正常なリクエストで大量アクセス」 がされるかも知れないところです。
不正なリクエストならいくらでも防ぎようがあるのですが、正常なリクエストだと防御機構をかいくぐられる可能性があります。
また、残念ながらWAFを”導入しただけ”では、突破される可能性が高いのです…😢
ココナラで実現したDDoS攻撃対策
ココナラのプロダクトはAWS上で稼働していますので、これ以降はAWSに特化した内容となります🙇
また、ここでご紹介する対策はココナラで実現している対策の一部です。
さまざまなレイヤーで多段防御していますので、その点ご認識ください🙇
3段構えの準備をする
先に書いたようにAWS WAFは導入しただけではダメなので、運用を行うためのポイントを3つご紹介します。
- WafCharmにルールの運用をしてもらうことで、工数の問題を解決
- マネージドルールを併用することで、AWSの知見を活かす
- レートベースルールをより厳格に適用する（ここが意外と漏れがち）
SIEM on Amazon OpenSearch Serviceの利活用
セキュリティログ分析で攻撃の芽を早めに検知し、摘むようにしています。
その手段として、SIEM on Amazon OpenSearch Serviceを利活用しています。
詳細はbuilders.flashとFindy Toolsに寄稿していますので、そちらもご参照ください。
セキュリティモニタリングを徹底する
普段と違うアクセス状況（国別、パス別、など）を検知したら、もしかしたら攻撃の予兆かもしれないと疑ってかかることが大事です。
ココナラではSIEM on Amazon OpenSearch Serviceを中心として、AWS WAFのダッシュボードも活用しつつ、モニタリングを行っています。
効果と振り返り
まずは「DDoS攻撃の回避は難しいが、いなすことはできる」という点です。
「DDoS攻撃は来るもの」と想定しておくことで、対策をプロアクティブに講じることができました。
また、防御機構が突破されることも想定して、
・対応フロー整備
・障害対応演習
・マイクロサービス化
などを事前に行うとより良いです。
つぎに「SRE組織とセキュリティ組織の協業」ができたという点も重要です。
もともとの2つの組織の目指す方向性は同じですが、手段が違う2つの組織の協業を可能にしました。
たとえば、以下を実現できています。
・セキュリティ運用（トイルとなっていたモニタリング、アラート運用）をSREが効率化
・SREの観点になかった攻撃と判断するノウハウの共有とそこへの対策オペレーションのスキルトランスファー
今後の取り組み
サービスの特性を認識したうえで対策を講じることが重要と考えます。
意外と攻撃やお行儀の悪いアクセスは来ているものと認識することが重要です。
怪しいアクセスには「5xx系」ではなく「403」で応答することで、攻撃者が諦めるケースが大多数なので、攻撃に対する応答が大事です。
また、サービスの提供範囲（たとえば、国・地域）を元にドラスティックに対策するのも効果的な対策の1つです。
攻撃への対策は多段で行っておくことと、万が一の事態に備えておくことがとても大事です！😁
組織開発も対策の1つです！
とくにPSIRTを設けていない企業もあると思いますので、有事の際の取り決めや日頃のモニタリング、セキュリティ対策の役割分担を日頃から会話すると良いと思います。
ココナラもCSIRTしかいない組織構造になっていますので、そのあたりを意識して取り組んでいます。
今回整理した内容が少しでも安心安全なプロダクト運用に繋がると嬉しいです！
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion