HTTPフラッド攻撃の脅威と防止策

【注意】本記事は一般的な情報提供であり、実環境の構成・契約条件・障害状況によって最適解は変わります。攻撃の抑え込みや再発防止、ログ保全が必要な場合は、株式会社情報工学研究所のような専門事業者への相談も検討してください。

　

「また 502…」は誰のせいでもない──HTTPフラッドが“正常なHTTP”を武器にする理由

「昨日まで動いていたのに、今日は急に重い」「監視は赤い、でも原因が“攻撃か障害か”すぐ断定できない」──HTTPフラッド（Layer 7 DDoS）は、現場のこういうモヤモヤを増幅させます。ネットワークが飽和していないのに、アプリが先に息切れする。エラーログは増えるが、正規アクセスも混じる。対処しても「それで売上は守れるの？」と聞かれる。まずここを整理するところから始めます。

---

HTTPフラッドの要点：帯域ではなく“処理資源”を狙う

HTTPフラッドは、見た目が「普通のHTTPリクエスト」であることが多く、L3/L4の単純なフィルタだけでは区別しにくいのが特徴です。攻撃者は、アプリケーションや周辺コンポーネントが消費する資源（CPU、メモリ、スレッド／ワーカー、DBコネクション、外部API枠、ストレージI/Oなど）を狙って、処理を“詰まらせる”方向に持っていきます。

例えば、静的ファイルのGETよりも、認証が絡むエンドポイント、検索、PDF生成、画像変換、在庫計算、決済前段など、「サーバ側の仕事量が重い」経路が狙われやすい。ここで重要なのは、攻撃が高度というより、あなたのシステムが“重くなるポイント”を攻撃者が踏むだけで成立するという点です。

---

なぜ“正常なHTTP”が厄介なのか

HTTPは正規ユーザーも攻撃者も同じプロトコルで話します。結果として、単純に「HTTPを閉じる」「ポートを塞ぐ」という選択肢が取りづらい。しかも、ブラウザ風のUser-Agentや一般的なヘッダ、TLS、Cookieまで整えてくるケースもあり、表面的なルールは簡単に回避されます。

ここでの落とし穴は、対策を“強く”しすぎて正規ユーザーまで巻き込むことです。攻撃の抑え込み（ダメージコントロール）と同時に、誤検知を抑え、ビジネス影響を最小化する必要があります。つまりHTTPフラッド対策は、セキュリティの話であると同時に、SRE/運用設計の話でもあります。

---

本記事のゴール：現場が動ける「観測→抑え込み→再発防止」の線を一本にする

本記事では、次の一本線で進めます。

• 観測：攻撃か、ただの負荷かを“数字”で切り分ける
• 抑え込み：入口（CDN/WAF/レート制限）と、アプリ/インフラ側の被害最小化を組み合わせる
• 再発防止：SLOと守るべき経路（クリティカルパス）を定義し、ルールと運用に落とす

一般論で語れる範囲はありますが、実際のボトルネックや最適な制限条件はシステムごとに違います。終盤では「一般論の限界」と、個別案件で検証・設計する価値についても触れます。

　

攻撃者は帯域ではなく“資源”を枯らす──同時接続・ワーカー・DBに刺さる設計図

HTTPフラッドの本質は、「1リクエスト当たりのコスト × リクエスト量」でシステムのどこかを飽和させることです。攻撃者は、必ずしもGbps級の帯域を用意する必要はありません。むしろ、帯域は余っているのにアプリが落ちる、という形を作れれば勝ちです。

---

典型的な“枯れ方”を部位ごとに整理する

部位	枯れる資源	症状の例	攻撃で起きやすいこと
Web/アプリ	CPU、ワーカー/スレッド、イベントループ	5xx増加、応答遅延、キュー滞留	重いAPIの連打、TLS/認証処理の増幅
DB/キャッシュ	コネクション、ロック、I/O	タイムアウト、スロークエリ、ロック待ち	検索・集計・N+1誘発、キャッシュミス増
外部依存	API枠、レート制限、ネットワーク待ち	待ち時間増、連鎖的な遅延	外部API呼び出しが“増幅点”になる
LB/リバプロ	同時接続、バッファ、キュー	接続枯渇、待ち行列の増大	Keep-Alive悪用、低速送信の混在

「どこが先に枯れるか」は構成で決まります。だから、対策も“入口だけ”や“アプリだけ”では完結しません。複数の層で歯止めをかけ、どこか一箇所が詰まっても全体が崩れないようにします。

---

設計として押さえるべき3つの視点

1. リクエスト単価を下げる：静的化・キャッシュ・前段での短絡応答（早く返す）
2. 同時実行を制御する：キュー、タイムアウト、バックプレッシャ（無限に受けない）
3. 重要経路を守る：ログイン、決済、問い合わせ等のクリティカルパスを優先

ここで現場が言いたくなるのが、たぶんこれです。

「また新しい対策？結局、運用が増えるだけじゃないの？」

この疑いは健全です。だからこそ、対策を“点”で追加するのではなく、観測と連動した“線”にして、運用負荷を増やさない形に落とす必要があります。たとえば、平常時は緩く、異常時にだけ段階的に厳しくする（クールダウン/被害最小化の設計）などが典型です。

---

誤検知と過剰遮断を避ける前提

HTTPフラッド対策で最悪なのは、「攻撃は止まったが、正規ユーザーも入れなくなった」です。したがって“強い遮断”は最後の手段にして、段階的に制限を上げる設計が現実的です。具体策（チャレンジ、レート制限、IP/国/ASN単位、URI単位、認証前後での別ルールなど）は後章で扱います。

なお、契約（CDN/WAFのプラン）、ログ取得範囲、個人情報の扱い、証跡保全の要件などは組織や業界で変わります。もし「どこまでやるべきか」で迷ったら、株式会社情報工学研究所のような専門家と一緒に、要件と優先順位を固めるのが近道です。

　

まずは分類から：L7（HTTP）フラッド／L4（SYN等）／低速持続型を切り分ける

「HTTPフラッド対策」と言っても、実際には複数タイプが混ざります。最初に“型”を誤ると、対策が空振りします。ここでは、現場で最低限切り分けたい分類と、見分ける観測点を整理します。

---

攻撃タイプの大づかみ（現場で使う分類）

分類	狙い	観測の当たり	有効になりやすい対策
L7: HTTPフラッド	アプリ/DB等の処理資源	RPS増、特定URI集中、p95/p99悪化	WAF/CDN、URI単位レート制限、キャッシュ、短絡
L4: SYN等	接続枯渇・ネットワーク処理	接続数/半開増、LB側の異常	L4防御、SYN cookies、LB設定、上流防御
低速持続型（Slow系）	ワーカー占有・タイムアウト誘発	同時接続増、転送遅、ワーカー枯渇	リバプロのタイムアウト/バッファ、接続制限

“HTTPが原因に見える”事象でも、実はL4寄りやSlow寄りが混ざることがあり、入口のチューニングだけでは改善しません。逆に、L7が主因なのにL4対策だけ厚くしても、アプリは相変わらず苦しいままです。

---

切り分けの第一歩：URIと状態コードと遅延分位を見る

現場でまず見たいのは、次の3点です。

• どのURIが増えたか：特定のAPI/ページに偏りがあるか（検索、ログイン、画像生成など）
• 状態コードの変化：4xxが増えるのか、5xxが増えるのか、タイムアウトが増えるのか
• 遅延の分位（p95/p99）：平均ではなく“尻尾”が悪化しているか

HTTPフラッドでは、攻撃対象のURIが“重い経路”に偏ると、まずp95/p99が悪化し、その後に5xx（ゲートウェイ、アプリ、DB起因）が増える、という流れが典型です。一方、L4が主因の場合は、アプリに到達する前に接続周りで詰まり、LBやネットワーク層の指標が先に崩れます。

---

「攻撃か障害か」ではなく「どこが飽和しているか」を問う

判断を早くするコツは、「攻撃かどうか」を最初から断定しないことです。代わりに、次の問いに変えます。

• 飽和しているのはCPUか、ワーカーか、DBか、外部APIか、接続枯渇か
• 飽和点（ここを超えると崩れる）はどこか
• 守るべき経路（問い合わせ・ログイン等）を残すには何を優先的に落とすべきか

この問いに答えられると、対策は“強い遮断”だけでなく、段階的な抑え込み（被害最小化、ブレーキ、クールダウン）へ落とし込めます。次章以降では、具体的なメトリクス（RPS、同時接続、キュー長、タイムアウト、DBコネクションなど）と、入口（WAF/CDN/Rate Limit）＋アプリ/インフラの組み合わせ方を、運用負荷が増えにくい形で整理していきます。

　

兆候は数字に出る：RPS・同時接続・待ち行列・p95/p99遅延で“飽和点”を見つける

HTTPフラッド対策が難しく見える最大の理由は、「攻撃っぽい／障害っぽい」の議論が感覚論になりやすいことです。現場では、上司や非技術部門に説明する必要もありますし、当日対応では時間がありません。そこで、まず“数字で話す”土台を作ります。ここでやるべきことは、派手な検知AIではなく、飽和点（ここを超えると崩れる）を把握し、異常の形を定義することです。

---

まず押さえる観測点：4つの「軸」

HTTPフラッドの兆候を捉えるには、最低限次の4軸を揃えるのが現実的です（ベンダーや製品に依存しない考え方です）。

• 負荷量：RPS（requests/sec）、帯域、同時接続数
• 遅延：平均ではなく p95/p99（分位）
• 失敗：HTTPステータス（2xx/3xx/4xx/5xx）、タイムアウト率
• 資源：CPU、メモリ、ワーカー/スレッド、DBコネクション、キュー長

「数字が多すぎる」と感じるかもしれませんが、逆です。必要最低限の軸がないと、結局“雰囲気”で判断することになります。特にp95/p99は重要で、HTTPフラッドでは平均より先に“尻尾”が悪化しやすいからです。

---

現場で効く切り口：URI単位で見る（トップN）

次に、必ず「URI（パス）別」に見ます。全体のRPSが増えていなくても、特定の重いエンドポイントに集中していれば、アプリやDBは落ちます。ログやメトリクスで次を出せると、当日の判断速度が上がります。

• URI別リクエスト数 Top N（例：/login, /search, /api/*）
• URI別 p95/p99 遅延 Top N
• URI別 5xx/タイムアウト Top N

ここでありがちな“心の会話”はこれです。

「結局、どの画面（どのAPI）が悪さしてるの？それが分からないと何もできない…」

その通りで、HTTPフラッド対策は「全体を守る」ではなく「守るべき経路を残す」設計に寄せると成功率が上がります。だからこそ、URI単位の可視化が最初の勝ち筋になります。

---

飽和点の決め方：SLOと“崩壊の前兆”を定義する

飽和点は、単にCPUが100%になる地点ではありません。サービスの品質（SLO）に対して、どの指標が先行して悪化するかを見ます。例として、次のような“前兆ルール”を定義しておくと、当日のブレーキ（抑え込み）を掛けるタイミングを作れます。

前兆	例	意味	初動
p99遅延の急上昇	平常の3倍以上が5分継続	キュー滞留・資源枯渇の兆候	段階的レート制限/チャレンジ開始
特定URIの5xx増	/search の 5xx が急増	重い経路の破綻	当該URIを優先的に制限・キャッシュ
DBコネクション逼迫	プール枯渇、待ち増	下流が詰まり上流が連鎖	アプリ側で短絡応答、外部依存を遮断

ここまで決めると、「攻撃か障害か」の議論は後回しにできます。重要なのは、品質が崩れる前に歯止めをかけることです。

---

ログの扱い：当日と事後で“目的”が違う

当日は抑え込みが最優先です。ログは「判断に必要な最小限」を確保しつつ、取りすぎでディスクやI/Oを圧迫しない設計が必要です。事後は再発防止・証跡のために、期間・範囲・保全方法を決めます。ここは契約や法務要件に絡むこともあるため、個別案件では一般論だけで決めるのは危険です。必要なら株式会社情報工学研究所のような専門家に相談し、保全範囲と責任分界（クラウド/委託先含む）を整理するのが安全です。

　

入口で落とす基本：WAF / CDN / Rate Limit の「効く条件」と「効かない条件」

観測軸が揃ったら、次は入口での抑え込みです。HTTPフラッドで最初に検討されるのは、CDN、WAF、レート制限（Rate Limit）ですが、ここでの失敗パターンはだいたい同じです。

「WAFを入れたのに落ちる」
「CDNを使っているのに重い」
「レート制限を入れたら正規ユーザーが弾かれた」

これらは道具が悪いのではなく、“効く条件”が揃っていないことが多いです。

---

役割分担：同じ「入口」でも守っているものが違う

手段	主目的	得意	苦手
CDN	オリジン保護・キャッシュ	静的/キャッシュ可能なコンテンツの吸収	動的APIや個別レスポンス中心だと効果が薄い
WAF	悪性トラフィックの判別・遮断	既知パターン、bot制御、チャレンジ	正規に見える攻撃、誤検知コストが高い
Rate Limit	過剰リクエストの抑制	URI単位・ユーザー単位で歯止めを掛ける	閾値設計を誤ると正規ユーザーに直撃

道具は役割が違うので、単体で万能ではありません。一般に、HTTPフラッドは「動的な重い経路」を狙うため、CDNだけでは不十分になりがちです。WAFとRate Limitを、URIや認証状態に応じて併用するのが現実的です。

---

効く条件：制限単位を“IPだけ”にしない

IP単位の制限は基本ですが、NATやモバイル回線、企業プロキシなどで正規ユーザーが同一IPに集約されるケースがあります。IPだけで強く絞ると、誤検知の爆発につながります。現実的には、次のように“キー”を複合します（実装可能性は環境で変わります）。

• URI（特定エンドポイントのみ厳しく）
• 認証前/認証後（ログイン前は厳しく、ログイン後はユーザーID単位など）
• セッション/トークン単位（正規クライアントの継続性を利用）
• ヘッダ特性（完全に信用はしないが、補助信号にする）

ここでの“心の会話”はこうです。

「でもそれ、設定が複雑になって運用が増えるんじゃ…」

この不安は自然です。だから、対策は“平常時の複雑さ”ではなく、“異常時に自動で段階的に上がる設計”に寄せます。たとえば「通常は緩いレート、p99が悪化したら特定URIにだけ厳しいレートを適用」など、観測と連動させることで運用負荷を抑えられます。

---

効かない条件：オリジンへ到達してから判断している

HTTPフラッドで致命的なのは、オリジン（アプリ/DB）が仕事をしてしまうことです。入口対策の狙いは、できるだけ“手前”で落とし、オリジンの負担を減らすことです。もしWAFの判定が遅かったり、レート制限がオリジン側でしか掛からない設計だと、すでに資源が枯れた後に弾くことになり、改善が弱くなります。

---

段階的制限（ソフトランディング）の考え方

いきなり全面ブロックではなく、段階的に抑え込みます。例としては次の順序が現場では扱いやすいことが多いです。

1. 特定URIにだけレート制限（歯止め）
2. 疑わしいトラフィックにだけチャレンジ（人間判定/実行環境判定）
3. 条件が揃ったら遮断（地域/ASN/IP/指紋など）

ただし、どの段階を採るかは、サービス形態（BtoB、会員制、公開サイト等）、ユーザー分布、契約（CDN/WAF機能範囲）で変わります。個別案件で設計が必要な場合は、株式会社情報工学研究所のような専門家に相談し、効果検証と運用設計まで含めて詰めるのが安全です。

　

アプリ側の被害最小化：キャッシュ・静的化・タイムアウト・バックプレッシャの入れどころ

入口で抑え込みをしても、HTTPフラッドは“抜けてくる”前提で設計する必要があります。攻撃の完全遮断に賭けると、条件が変わった瞬間にまた崩れます。アプリ側では、攻撃時にサービス全体が落ちないよう、被害最小化の仕組み（ダメージコントロール）を入れます。

---

基本方針：「重い処理」を“薄める”か“早く諦める”

アプリ側で効果が出やすいのは、次の4つです。

• キャッシュ：同じ結果を繰り返し計算しない
• 静的化：動的生成を減らし、前段で配れる形に寄せる
• タイムアウト：下流待ちでワーカーを占有しない
• バックプレッシャ：受けすぎない（キューを無限に伸ばさない）

この4つは、攻撃対策であると同時に、平常時のレイテンシ改善にも効きます。つまり“攻撃のためだけ”に複雑な仕組みを追加せずに済む余地がある、ということです。

---

キャッシュ：何をキャッシュしてはいけないかも決める

キャッシュは強力ですが、誤ると事故になります。個人情報やユーザー固有のレスポンスを共有キャッシュしてしまうと情報漏えいにつながります。HTTPフラッド対策でキャッシュを検討する場合、次の観点を必ず押さえます。

• 公開情報だけをキャッシュする（ユーザー固有情報は分離）
• キー設計（クエリ文字列、言語、デバイス、権限など）
• TTL（短すぎると効果が薄い、長すぎると鮮度問題）

ここはシステムの仕様と契約（個人情報の扱い、SLA等）に直結します。一般論で「キャッシュしよう」と言うのは簡単ですが、個別案件では検証が必要です。

---

タイムアウトとリトライ：連鎖を止める“歯止め”

HTTPフラッド時に起きがちなのが、下流の遅延→上流の待ち→ワーカー枯渇→全体崩壊、という連鎖です。これを止めるには、タイムアウトとリトライを整理します。

項目	ありがちな失敗	対策の方向性
タイムアウト	長すぎてワーカーを占有	上流ほど短く、下流は用途別に設定
リトライ	一斉リトライで負荷増幅	指数バックオフ、上限、ジッタ、状況別に抑制
サーキットブレーカ	導入が重くて敬遠	重要依存から段階導入、フォールバックを用意

“正しさ”よりも、“崩壊を防ぐ”を優先する場面があります。攻撃下では完璧な結果を返すより、機能を絞ってでもサービスを継続するほうが現実的なことが多いからです。

---

バックプレッシャ：無限に受けない（落とす場所を決める）

バックプレッシャは「受けたくても受けない」仕組みです。HTTPフラッド下で全リクエストを処理しようとすると、結局は全体が落ちます。重要なのは、落とす場所と優先順位を設計することです。

• キュー長に上限を設け、超えたら早めにエラー応答（例：429や軽量なエラーページ）
• 重い経路を優先的に制限し、重要経路を残す
• フォールバック（簡易表示、メンテ表示、キャッシュ表示）を用意する

これは“実装”だけではなく、ビジネス判断（どの機能を落としてよいか）も必要です。もし社内調整が難しい、契約上のSLA/SLOが絡む、顧客影響の説明が必要、といった状況なら、株式会社情報工学研究所のような専門家と一緒に、優先順位と運用ルールを固めるとスムーズです。

　

インフラ側の被害最小化：LB/リバプロ設定、接続プール、オートスケール、ボトルネック分離

入口（CDN/WAF）とアプリ側の工夫だけでは、HTTPフラッドの“抜け”を完全には防げません。インフラ側では、接続や待ち行列が暴れたときに、サービス全体が崩れないように「防波堤」を作ります。ここでの狙いは、一点の詰まりが全体障害に連鎖しない構造にすることです。

---

リバプロ/LBで効くのは「接続の取り扱い」を決めること

HTTPフラッドでは、リバースプロキシやロードバランサに“接続”が集中し、上流（アプリ）へ過剰に流れてしまうとワーカー枯渇に直結します。典型的に見直すのは次の観点です。

• 同時接続の上限：無限に受けない（上限設定と超過時の扱い）
• タイムアウト：読み取り/書き込み/アイドルの上限を明確化し、占有を防ぐ
• バッファ/ボディサイズ：過大なリクエストでメモリ/ディスクを消費しない
• Keep-Alive：効率化に有効だが、占有・偏りが出るなら見直す

重要なのは「平常時の最速」ではなく、「異常時に落ちない設計」です。設定値はシステム特性で変わるため一般化はできませんが、方針としては“上流ほど短く、下流ほど用途別に”が安全側になりやすいです。

---

接続プールとDB：枯渇が起きたら“全滅”しやすい

HTTPフラッドで実務上つらいのは、アプリが落ちる前にDBや外部依存の枠が枯れて、正常系まで巻き込まれることです。ここでの歯止めは次の2段です。

1. 枠を守る：DBコネクションプールの上限、待ち時間、キュー長を設ける
2. 枠が危ないときの短絡：重い経路を早めに落とす／フォールバックを返す

「枠が枯れたらアプリも詰まる」ではなく、「枠が危ない段階でアプリが自分から引く」状態にします。これがダメージコントロールの基本です。

---

オートスケールは“万能”ではない：スケール前に詰まる箇所を分離する

「スケールすればいい」は半分正解で半分不正解です。オートスケールが効くのは、ボトルネックがCPU等で、水平分割しやすい場合です。一方で、DB・外部API・共有ストレージ・単一キューなどが詰まると、アプリを増やしても悪化します。

そのため、設計としては次の優先順位になります。

• ボトルネックの分離：静的配信、重いバッチ、検索、画像処理などを分ける
• 重要経路の隔離：ログイン/問い合わせ/決済などのクリティカルパスを別枠で守る
• スケール条件の見直し：CPUだけでなく、キュー長・p95/p99・エラー率で判断する

---

「構成の正解」は案件ごと：要件と制約を揃えてから決める

ここまでの話は方向性であって、数値や構成は個別です。例えば、BtoBで固定顧客が多いのか、一般公開サイトなのか、ピーク特性、ログ保全要件、クラウド契約、WAF/CDNの機能範囲などで最適解が変わります。

「結局どこまでやれば、現実的な抑え込み（歯止め）になるのか」を詰める段階では、株式会社情報工学研究所のような専門家と一緒に、現状のボトルネック測定（観測）と、段階的な制限設計（入口＋アプリ＋インフラ）をセットで固めるのが安全です。

　

正規ユーザーを殺さない：誤検知を抑える段階的制限（チャレンジ、例外、動的ルール）

HTTPフラッド対策で“勝ったはずなのに負ける”典型は、強い制限で正規ユーザーまで弾いてしまうことです。特にBtoBやSaaSでは、顧客の業務が止まると損失が大きく、「攻撃は収束したがクレームが増えた」という最悪の着地（軟着陸の失敗）になりかねません。ここでは、誤検知を抑えながら抑え込みを効かせる設計を整理します。

---

段階的制限の基本：いきなり遮断しない

段階的制限は、抑え込みの強度を状況に応じて上げ下げする考え方です。一般に次の順が扱いやすいです。

1. 軽い歯止め：特定URIだけレート制限、リクエスト単価を下げる（キャッシュ/短絡）
2. 疑わしい群だけ強化：チャレンジ、厳しめのレート、追加検証
3. 明確に悪いものを遮断：継続的に異常なIP/ASN/指紋/挙動をブロック

この順序のメリットは、正規ユーザーの生存率を高めつつ、攻撃の温度を下げられることです。

---

例外設計：BtoBでは「守るべき相手」が明確なことが多い

BtoBでは、取引先の固定IP、社内プロキシ、特定VPN経由など、正規アクセスが“ある程度わかる”ケースがあります。こういうときは、例外（allowlist）を適切に設けることで、抑え込みの強度を上げても顧客影響を抑えられます。

ただし、allowlistは運用資産でもあります。更新漏れが起きると、今度は正規ユーザーが入れません。したがって、例外を作るなら「更新手順」「期限」「変更履歴」「責任分界」を決めておきます。ここは社内調整が絡むため、作りっぱなしにしない設計が必要です。

---

動的ルール：観測値と連動させると運用が増えにくい

人手でルールを出し入れするほど、当日対応は荒れます。そこで、前章で整理した観測軸（p95/p99、エラー率、URI別集中など）と連動して、段階的に制限を上げる設計が現実的です。

• p99が一定時間悪化 → 特定URIに強いレート制限
• 特定URIの5xx/タイムアウト増 → 当該URIをフォールバック/簡易応答へ
• 全体が沈静化 → 制限を段階的に解除（急に戻さない）

解除も重要です。一気に戻すと再燃しやすいので、クールダウンしながら戻す（温度を下げる）ほうが安全です。

---

誤検知はゼロにできない：だから「説明できる仕組み」にする

HTTPフラッド対策で誤検知をゼロにするのは現実的ではありません。だからこそ、誤検知が起きた場合に「なぜ弾いたか」「どう解除するか」を説明できる仕組みが必要です。具体的には次のような整理が有効です。

• 遮断・制限の条件（何が閾値だったか）
• 影響範囲（どのURI/どの顧客/どの期間）
• 解除手順（例外追加、ルールの段階的解除、監視の確認）

この“説明可能性”があると、社内調整・対人の摩擦が減り、結果として運用が楽になります。

なお、例外の設計やログ保全、顧客説明の範囲は契約や業界要件で変わります。「一般論のまま運用に落とすと危ない」と感じたら、株式会社情報工学研究所のような専門家と一緒に、運用と技術をセットで設計するのが安全です。

　

当日対応ランブック：遮断→緩和→復旧→証跡（ログ保全と再現可能な振り返り）

HTTPフラッドの厄介さは、「技術だけ」では終わらないことです。当日は判断が連続し、社内連絡、顧客影響、証跡、復旧後の振り返りまで含めて“手順化”されていないと、対応が属人化します。ここでは、現場が動ける形のランブック（たたき台）を提示します。

---

0. 前提：最初に決めるのは「守るものの優先順位」

当日に迷いが出るのは、守るべき経路が曖昧だからです。たとえば、ログイン、問い合わせ、決済、管理画面など、落としてはいけない経路を決めておきます。逆に、重い検索やレコメンドなど、最悪落としてもよい経路も決めます。これが“抑え込み”の判断を速くします。

---

1. 検知：攻撃断定より「飽和点の把握」

1. p95/p99、エラー率、RPS、同時接続、DBコネクション等を確認
2. URI別 Top N（リクエスト数／遅延／5xx）を確認
3. 飽和している部位（アプリ/DB/LB/外部依存）を特定

ここで「攻撃だ」と断定できなくても構いません。どこが詰まっているかが分かれば、歯止めは掛けられます。

---

2. 抑え込み：段階的に強度を上げる（ソフトランディング）

1. 特定URIにレート制限・キャッシュ・短絡応答を適用
2. 疑わしい群にチャレンジ/追加制限を適用
3. 明確に悪いトラフィックを遮断（必要なら範囲を絞って）

ポイントは“いきなり全面遮断しない”ことです。正規ユーザーの影響が大きいほど、段階的制限が有効になります。

---

3. 緩和と復旧：一気に戻さず、段階的に解除する

攻撃や異常が沈静化した後に、制限を一気に解除すると再燃することがあります。解除も段階的に行い、p95/p99とエラー率が安定していることを確認しながら戻します。復旧の確認は、監視だけでなく、実際のユーザー導線（ログイン→主要画面→重要操作）を最小限の手動/自動で確認できるようにしておくと安全です。

---

4. 証跡：ログ保全は「目的」と「範囲」を決めてから

証跡は、再発防止（技術改善）と、説明責任（社内・顧客・場合によっては法務）に使われます。むやみに全ログを長期保存すると、コストや個人情報の扱いが問題になります。したがって次を決めます。

• 保全の目的：再発防止／顧客説明／法務対応 など
• 対象期間：開始・終了の基準（いつからいつまで）
• 対象データ：WAF/CDNログ、LBログ、アプリログ、DB指標、設定変更履歴
• 保全方法：改ざん防止、アクセス制御、保管期限

この部分は、契約・規程・業界要件で変わります。「一般論で決めると危ない」領域でもあるため、必要に応じて株式会社情報工学研究所のような専門家に相談し、技術とガバナンスをセットで整えるのが安全です。

---

5. 振り返り：再発防止は“仕組み化”しないと戻る

振り返りでは、個人の頑張りではなく仕組みの改善に落とします。たとえば、観測（トップN可視化）、段階的制限（ルールの自動化）、重要経路の隔離（構成改善）などです。次章では、この全体をSLOとクリティカルパスに結びつけ、「一般論の限界」と「個別設計の価値」を自然に整理していきます。

　

帰結：SLOと“守るべき経路”を定義し、攻撃に強い運用へ──一般論の限界と個別設計の価値

ここまで、HTTPフラッドを「観測→抑え込み→再発防止」の一本線で見てきました。帰結として言えるのは、HTTPフラッド対策は“道具の導入”ではなく、SLO（サービス目標）と守るべき経路（クリティカルパス）を中心に据えた運用設計だということです。WAFやCDNやレート制限は重要ですが、それ単体で勝てるとは限りません。逆に言えば、SLOとクリティカルパスが定義されていれば、対策は段階的に積み上げられます。

---

「守るべき経路」を先に決めると、当日の判断が速くなる

HTTPフラッドの現場で一番つらいのは、技術的に正しいことよりも「何を優先して守るべきか」をその場で決めなければならない点です。そこで、平時に次を決めておくと、当日の抑え込み（歯止め）が“迷いにくく”なります。

• 絶対に守る：問い合わせ、ログイン（BtoB/SaaSなら特に重要）、決済、管理系の最低限
• 守りたいが落としても致命傷ではない：検索、一覧の高度な絞り込み、レコメンド、重い集計
• 攻撃時は落としてよい：高コストな生成系（PDF/画像変換など）、外部API依存が強い処理

この優先順位があると、「特定URIだけ強く抑え込み、重要経路を残す」という設計に自然につながります。結果として、全面遮断のような荒い対応を避けやすくなり、正規ユーザーの影響も被害最小化できます。

---

SLOとエラーバジェットで「いつ強めるか」を決める

対策が属人化するのは、“強めるタイミング”が曖昧だからです。そこでSLO（例：成功率、p95/p99遅延、可用性）と、エラーバジェットの消費状況を見て、段階的制限の発動条件を決めます。たとえば次のような考え方です。

• p99遅延が一定時間悪化 → まず特定URIを抑え込み（軽いブレーキ）
• 5xx/タイムアウトが増加 → チャレンジや強いレート制限へ（温度を下げる）
• クリティカルパスが危険 → 重い経路のフォールバック/簡易応答（軟着陸を狙う）

ここで大事なのは「攻撃をゼロにする」発想ではなく、「SLOを守り、事業影響を最小化する」発想です。攻撃が存在しても、守るべき経路が成立していれば、現場の勝ち筋は見えます。

---

一般論の限界：数値・閾値・ログ保全は“契約と構成”で変わる

本記事は事実に基づく一般的な整理として書いていますが、ここに明確な限界があります。HTTPフラッド対策で本当に効く「閾値」「制限単位」「例外」「ログ保全」は、次の要素で大きく変わるからです。

• システム構成：単体/分散、DB形態、外部依存、キャッシュ、キューの有無
• ユーザー特性：NAT/プロキシ比率、BtoB固定顧客、地域分布、ピークの形
• 契約・責任分界：CDN/WAFの機能範囲、ログの取得可否、保管義務、委託先
• 法務・規程：個人情報、監査、保存期間、アクセス権限、証跡要件

たとえば「IP単位の制限」は一般に使えますが、企業プロキシ配下の正規ユーザーを巻き込む可能性があります。「全部ログを残す」も技術的にはできても、個人情報や保管コスト、運用体制がボトルネックになりえます。つまり、一般論をそのまま当てはめると、別のリスク（誤検知・運用破綻・説明不能）を生むことがあります。

---

“現場が楽になる”着地点：対策を線にして、運用を増やさない

最後に、現場の本音に戻ります。

「また新しい対策？どうせ運用が増えるだけじゃないの？」

この疑いは正しいです。だからこそ、HTTPフラッド対策は単発の追加機能ではなく、次のように“線”で設計するのが現実的です。

1. 観測を揃える（URI別Top N、p95/p99、エラー率、資源）
2. 段階的制限を決める（軽い歯止め→チャレンジ→遮断）
3. 重要経路を守る（優先順位、隔離、フォールバック）
4. ランブック化する（当日手順、解除手順、証跡）
5. 振り返りで仕組みに戻す（属人化を防ぐ）

ここまで落とし込めると、攻撃が来ても「手順通りに温度を下げる」「沈静化したら段階的に戻す」という運用が可能になります。そして、この“運用の筋”ができて初めて、WAF/CDN/レート制限の投資が活きます。

---

結論：個別案件では、専門家と一緒に「要件→検証→設計→運用」まで詰める価値がある

HTTPフラッド対策は、技術・契約・運用・説明責任が絡むため、個別案件で悩みが出やすい領域です。たとえば「どのURIを守るべきか」「誤検知をどこまで許容するか」「ログをどこまで保全するか」「クラウド/委託先を含む責任分界はどうするか」など、一般論だけでは決めにくいポイントが必ず出ます。

そういうときは、単にツールを追加するより、株式会社情報工学研究所のような専門家に相談し、現状の観測からボトルネックを特定し、段階的制限と運用手順を“あなたの環境に合わせて”設計することが、結果的に最短距離になることがあります。

　

付録：主要プログラミング言語別の注意点（HTTPフラッド対策の実装・運用で破綻しやすい点）

最後に、HTTPフラッド対策をアプリ側で実装・調整するときに、言語やランタイム特性で“つまずきやすいポイント”を整理します。ここで挙げるのは、特定製品の宣伝ではなく、一般的に起こりやすい設計上の注意点です。最終的な実装や設定は、フレームワーク・インフラ構成・契約条件に依存します。

言語/実行系	HTTPフラッド時に露呈しやすい弱点	実務上の注意点（例）
JavaScript / Node.js	イベントループのブロッキングで全体が詰まる	CPU重処理は別プロセス/ワーカーへ分離、同期I/Oを避ける、タイムアウト/上限を必ず設定
Python	同期I/O中心だとワーカー枯渇、GILでCPU並列が効きにくい場面	WSGI/ASGIのモデル差を理解、ワーカー数・タイムアウト・キュー上限を設計、重処理はジョブ化/別サービス化
Java（例：JVM系）	スレッド/コネクション枯渇、GC影響が遅延の尻尾に出る	スレッドプール/DBプールの上限と待ち時間を明確化、タイムアウトを多段で設定、観測（p99/GC/プール）を必須化
Go	ゴルーチンを無制限に増やしてメモリ・下流を圧迫	contextでタイムアウト/キャンセルを徹底、同時実行数を制限、バックプレッシャ（キュー上限/早期終了）を設計
Rust	非同期実装でも“待ち”が多いと実行枠が詰まる、設定が複雑化しやすい	タイムアウト/制限/フォールバックを最初から設計、メトリクスで詰まり点を可視化、過剰最適化より運用可能性を優先
PHP（例：FPM）	プロセス枯渇、重い処理で待ちが連鎖	FPMの同時実行上限とタイムアウトを明確化、重い処理は分離、キャッシュと静的化でオリジン負荷を下げる
Ruby	並列性の制約、ワーカー枯渇、依存先待ちで詰まりやすい	アプリサーバのワーカー/スレッド/タイムアウト設計を明確化、重処理はジョブ化、段階的制限とセットで運用
C / C++	リソースリークや例外系の抜けで長期運用に弱点、実装差が大きい	ソケット/メモリ/スレッドの上限設計、エラー処理の徹底、負荷試験でリーク検出、入口側の抑え込みも必須
C# / .NET	スレッドプール枯渇、同期ブロックで遅延の尻尾が伸びる	async/awaitの前提を守る、HttpClient等の使い回しとタイムアウト設計、下流待ちの切断（キャンセル）を徹底

---

言語を問わず共通で重要な注意点

• タイムアウトは必ず多段で：入口（LB/リバプロ）→アプリ→下流（DB/外部API）で「占有」を防ぐ
• 同時実行は必ず上限を持つ：スレッド、ワーカー、ゴルーチン、キューの無限増殖を避ける
• リトライは“増幅装置”になり得る：指数バックオフ、上限、ジッタ、状況別抑制が必要
• 重い経路を分離する：生成系・検索・外部依存は、重要経路と同じ枠で動かさない
• 観測がない対策は続かない：URI別Top N、p95/p99、エラー率、資源、設定変更履歴を揃える

---

付録の結論：実装は簡単でも、運用と契約が絡むと一気に難しくなる

HTTPフラッド対策は「コードを書けば終わり」ではなく、誤検知、例外運用、ログ保全、責任分界、顧客影響の説明まで含めて成立します。ここまで含めて“筋の良い設計”にするには、一般論だけでは足りない場面が多いのが実情です。

具体的な案件・契約・システム構成で悩んだときは、株式会社情報工学研究所のような専門家に相談し、観測→検証→設計→運用の形に落とし込むことで、結果として早く・安全に“抑え込み”と再発防止に到達できます。