サービスを止めるな！ DDoS攻撃へのスマートな備えと最前線の事例

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright coconala Inc. All Rights Reserved. 自己紹介 2 川崎雄太　Yuta Kawasaki @yuta_k0911 株式会社ココナラ Head of Information / Dev Enabling室室長株式会社ココナラテック執行役員情報基盤統括本部長 SRE / 情シス / セキュリティ領域のEM SRE NEXT 2025のコアスタッフ 🆕 AWS Community Builder（Security）

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright coconala Inc. All Rights Reserved. DDoS攻撃とは？ 9 多数が大量のデータを送りつけて、サービスを妨害する攻撃たとえば、以下の攻撃がある。・ボリューム攻撃：NW帯域を圧迫・プロトコル攻撃：機器のリソースを圧迫・アプリケーション層攻撃：大量アクセス目的はDoS攻撃と似通っている。たとえると、「狭いお店にあらかじめ示し合わせた多数の人が一斉に殺到する状態」のこと。

Slide 10

Slide 10 text

Copyright coconala Inc. All Rights Reserved. どんな被害が起きる？ 10 サービスに対する直接的・間接的な影響があるたとえば、以下の被害が発生する。・サービスが停止することで利用者が使いたいときに使えなくなる・売上や信頼を失ってしまう・業務停止やブランドイメージが悪化する・復旧や対策コストが増加する対策はしていてもシステムに何かしらの悪影響が発生してしまい、てんやわんやすることが多い。

Slide 11

Slide 11 text

Copyright coconala Inc. All Rights Reserved. 実際の事例 11 著名なサービス、企業も攻撃の矛先になっている 2024年の年末から2025年の年始にかけて以下の企業がDDoS攻撃を受けたと言われている。・JAL、三菱UFJ銀行、りそな銀行、みずほ銀行、NTTドコモ、日本気象協会、三井住友カード国外に目を向けると、GitHubなども被害にあっているので、決して対岸の火事ではない。

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright coconala Inc. All Rights Reserved. セキュリティ対策体制がどうしても脆弱になりがち 15 プロダクトセキュリティ専門組織が不在　プロダクトプラットフォームグループ情報システムグループインフラ・ SREチーム（5名） CSIRTチーム（2名） CITチーム（5名） - AWSアカウント分離 - IAMロール整備 - 攻撃対策ソリューション導入 - アクセス権限精緻化 - 新デバイス / OS検証・導入 - アクセス権限精緻化 ※SREチームがセキュリティ業務を兼務している企業は少なくない！

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright coconala Inc. All Rights Reserved. 対策が間に合わず、リスクが顕在化した 17 対策はゼロではなかったものの、それをかいくぐられたセキュリティ対策として、WAFやCDNを導入していたものの、DDoS攻撃を想定した設計・設定になっていなかった。結果として、防御機構をかいくぐられ、サービスがスローダウンしたり、最悪のケースでは、サービスがダウンすることが年に数回発生することもあった。上場企業はより狙われやすいかも…？

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright coconala Inc. All Rights Reserved. セキュリティログ分析とは？ 26 システムのコンディション把握と打ち手の創出をすること分析、検知、監査、監視など目的は様々だが、「ある時点のシステムの状態（コンディション）を把握」し、そこから「対応が必要な場合の打ち手を創出する」ことを目的としている。システムの規模が大きくなればなるほど、ログの量が膨大となるため、分析の仕組みが不可欠となる。

Slide 27

Slide 27 text

Copyright coconala Inc. All Rights Reserved. SIEM on Amazon OpenSearch Serviceを用いたWAFログのモニタリング（ 1/3） 27 日次で傾向把握と分析、過去との比較からパターン化ココナラは国内を中心にサービスをしているため、国内・海外の IPアドレスによるアクセス状況 / ブロック状況 / エラー発生状況などをモニタリングする。アクセス状況を見て、WAFルールの点検などを行い、プロアクティブに攻撃への対策を実施。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright coconala Inc. All Rights Reserved. SIEM on Amazon OpenSearch Serviceを用いたELBログのモニタリング（ 1/3） 30 日次で傾向把握と分析、攻撃の芽を早めに摘む 4xx系と5xx系のリクエストが 30秒あたりに100回を超えた場合に怪しいアクセスが増加したと判断し（アラート発報）、随時セキュリティログ分析を行う運用をしている。特に不正なURLへのアクセスを多数確認したら、WAFのIPアドレス拒否リストへ追加する運用を実現。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright coconala Inc. All Rights Reserved. 取り組み事例その4：各種セキュリティモニタリング 34 毎営業日モニタリングを実施し、アクションを創出する毎営業日17:00時点の情報で定点確認（さまざまな観点でレポートを作成）問題があれば、毎営業日18:00に集まり、確認・議論当日〜翌日以降のアクションを決めて、チケット化 ※↑は定常運用なので、異常が発生した場合は　アラートを発報し、随時調査しています！

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Copyright coconala Inc. All Rights Reserved. SRE組織とセキュリティ組織の協業の実現 44 今まで縦割りだったものが、シナジーを創出できたもともとの目指す方向性は同じだが、手段が違う2つの組織の協業を可能にした。たとえば、以下を実現できた。・セキュリティ運用（トイルとなっていたモニタリング、アラート運用）をSREが効率化・SREの観点になかった攻撃と判断するノウハウの共有とそこへの対策オペレーションのスキルトランスファー

Slide 45

Slide 45 text

Copyright coconala Inc. All Rights Reserved. 「SRE × セキュリティ」と「セキュリティ × SRE」というキャリアの掛け算 45 キャリアの掛け算 = 複数ロールの経験は強み複数ロールの掛け算自体が、そもそも希少性を作り出すことができた。たとえば、以下を実現できた。・SRE：DevSecOpsの実践、SRE領域以外のトイル削減 / 運用改善・セキュリティ：IaCの取り組み、監視改善などのプロアクティブな運用改善「キャリア形成」も対策の大事な要素。

Slide 46

Slide 46 text

Copyright coconala Inc. All Rights Reserved. 他社事例やベンダーのアドバイスを取捨選択して、優先度を決めるのが難しい 46 緊急度と影響度から優先度をいかに適切に判断できるか？取りうる策がわかったとしても、それを適切なタイミングでローンチできなければ、効果が薄れる。予算も工数も限られる中で、この意思決定は経営イシューにもなりうるので、しっかりステークホルダーと合意形成をすべき。

Slide 47

Slide 47 text

Copyright coconala Inc. All Rights Reserved. 全社最適と個別最適の技術選定をどう考えるか？ 47 「目的に応じて使い分ける」ことで、技術選定をするなるべくベンダーロックインしないようにすることも含めて、純粋な要件と＋αの要件有無を確認し、プロダクトごとに最適な技術選定をする。また、課題になっていた「なぜこういうアーキテクチャーになっているかわからない」という状態からの脱却を目指し、技術選定方針のドキュメントを確実に残す。

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright coconala Inc. All Rights Reserved. 定期的に点検とアセスメントを実施する 49 放置すると陳腐化するので、放置しないことが大切攻撃や脅威は日々進化している。一度、セキュリティ対策をして終わりではなく、継続したリファクタリングを行う必要がある。・ソリューションは「導入する」よりも「導入後の運用」が大事・「リアクティブ」な対応だけでなく、「プロアクティブ」な仕掛けが重要

Slide 50

Slide 50 text

Copyright coconala Inc. All Rights Reserved. 継続したリファクタリングの実践 50 一度、導入して終わりではなく、継続したリファクタリングを行う攻撃は日々進化しているため、チューニング / リファクタリングが必要。今のアーキテクチャーが最適解では無くなるので、新たなソリューション導入検討も必要なアクションとなる。・閾値によるモニタリングの脱却 → 機械学習による異常予測検知・AIOpsによる速やかな原因分析・・・and more！

Slide 51

Slide 51 text

Copyright coconala Inc. All Rights Reserved. サービスの特性を認識したうえで対策を講じる 51 意外と攻撃やお行儀の悪いアクセスは来ている例えば、◯snbotがとんでもない頻度でアクセス（おそらくスクレイピング）していて、閾値に引っかかっていた。怪しいアクセスは「5xx系」ではなく、「403」で返せれば止まる（諦める）ことが大多数！サービスの提供範囲（たとえば、国・地域）を元にドラスティックに対策するのもあり。

Slide 52

Slide 52 text

Copyright coconala Inc. All Rights Reserved. SREはどんどんセキュリティ領域に進出していくべき 52 キャリアの掛け算を活かしていくことが攻撃対策につながる繰り返しではあるが、「キャリアの掛け算＝強み」であることは自明なので、SRE / セキュリティといった役割・職責の垣根を良い意味で継続して超えられるようにする。その結果、全員が信頼性向上とセキュリティ向上の意識改革ができ、改善に向けて動ければベスト。

Slide 53

Slide 53 text

Copyright coconala Inc. All Rights Reserved. セキュリティはどんどん SRE領域に進出していくべき 53 キャリアの掛け算を〜（大事なことなので 2回）セキュリティエンジニアは「セキュリティ」を手段として、信頼性の向上を実現している。信頼性の向上を実現する手段は複数あるので、SREと協力したり、より良い関係性を構築し、「サイトの信頼性を向上する仲間との信頼性」を高めていくのも大事。