そのWAFのブロック、どう活かす？ サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision

2025/10/11
JAWS FESTA 2025 in 金沢
https://jawsfesta2025.jaws-ug.jp/

そのWAFのブロック、どう活かす？ サービスを守るための実践的多層防御と思考法

いちび(@itiB_S144)
ソフトウェアエンジニア

Transcript

1. @itiB_S144 そのWAFのブロック、どう活かす？ サービスを守るための実践的多層防御と思考法 株式会社カミナシ いちび (@itiB_S144) JAWS FESTA 2025 in 金沢 近江町 Track D 16:00 ~ 16:20
2. @itiB_S144 いちび 株式会社カミナシ ソフトウェアエンジニア 𝕏 : @itiB_S144 趣味 : ポケモンカード、キャンプ 出身 : 静岡県浜松市 好きなAWSサービス: CostExplorer 経歴 • 2021/04 ECサイトのSREエンジニア • 2024/10 カミナシ入社
3. @itiB_S144 3 • ある日起きた事件... • インフラでの応急処置と落とし穴 • 立ち止まって考える、本当の最適解 • まとめ 2 1 3 4 3
4. @itiB_S144 4 持ち帰っていただきたい内容 • 技術「WAFのチューニング方法」 • 思考「WAF のチューニングだけに頼らない意思」 • 組織「インフラ・アプリの垣根を越えた共同に よって本当の多層防御を生み出す」
5. @itiB_S144 ある日起きた事件...
6. @itiB_S144 なんか画面がうまく動作しないな... サーバ側のログを漁ってもなんもエラー出してないのに... ローカルではしっかりアプリが動いていること確認できたのに... dev 環境にデプロイしたらなんかうまく動かない ある日起きた事件... 6
7. @itiB_S144 とりあえず curl で止まってる API 叩いてみるか... ある日起きた事件... 7
8. @itiB_S144 Private subnet Virtual private cloud (VPC) 現在の構成 ある日起きた事件... Public subnet Private subnet Aurora AWS WAF ECS Application Load Balancer CloudFront 8
9. @itiB_S144 AWS の提供する WAF(Web Application Firewall) • 様々なマネージドなルールが存在し、 組み合わせることでサービスに合ったルールを作れる • CloudFrontやApplication Load Balancer、 API Gateway等に手軽に接続でき、簡単に導入できる AWS WAF とは ある日起きた事件... 9
10. @itiB_S144 コンソールからブロックの数を確認 AWS WAF の検知とログを確認 ある日起きた事件... 10
11. @itiB_S144 CloudWatch Logs に流したログを確認 ある日起きた事件... 11 詳細なブロック理由がわかる • AWSManagedRulesSQLiRuleSet SQLi_BODY • Body に含まれる offset, limit の文字列
12. @itiB_S144 VendorName: AWS、名前: AWSManagedRulesSQLiRuleSet、WCU: 200 • SQLi_QUERYARGUMENTS • SQLiExtendedPatterns_QUERYARGUMENTS • SQLi_BODY • SQLiExtendedPatterns_BODY • SQLi_COOKIE • SQLi_URIPATH https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-use-case.html#aws-managed-ru le-groups-use-case-sql-db SQL データベースマネージドルールグループ ある日起きた事件... 12
13. @itiB_S144 インフラでの応急処置と落とし穴
14. @itiB_S144 • WAF の無効化 ◦ あらゆる攻撃に対して脆弱になってしまう • WAF のチューニング ◦ うまくチューニングできればよさそう??? • アプリケーションの設計を変更 ◦ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに 対処方法として考えられるもの インフラでの応急処置と落とし穴 14 2 1 3
15. @itiB_S144 • 今回引っかかっているのはどうやら Body の offset, limit 文字列 • WAF を緩めるにしても緩める箇所は最小限にしたい ◦ 対象のパスは限定する ◦ 対象のルールも限定 ◦ 緩めた分、SQLインジェクションされかねない実装がアプリにないか確認 チューニングの方針 インフラでの応急処置と落とし穴 1. /search のパスで 2. Body の文字列 offset, limit は除外 3. AWSManagedRulesSQLiRuleSet.SQLi_BODY の ルールを回避させる 15
16. @itiB_S144 検査（一致ステートメント） - Scope-down statement - グループ内すべてのマネージドルールに影響 - クエリ文字列やパスなどを組み合わせた フィルタを作成 ルールオーバーライド - ルール毎のアクションを設定可能 Block/Challenge/CAPTCHA/Count/Allow AWS WAF のマネージドルールはどんな調整ができるか インフラでの応急処置と落とし穴 16
17. @itiB_S144 • ①カスタムルール 特別に通したい通信にラベルをつける • ②カスタムルール SQLi_BODYラベルのついた通信から ①を除外してブロック 実現の方法 インフラでの応急処置と落とし穴 17 ①カスタムルール (COUNT) SQLi_BODY に引っかかった AND 特定のURLへのリクエスト AND limit の文字列が含まれている AWSManagedRulesSQLiRuleSet SQLi_BODY (COUNT) SQLi_COOKIE (BLOCK) その他 (BLOCK) ②カスタムルール (BlOCK) SQLi_BODY AND not ① Point COUNT で通過した通信には「ラベル」が付き 以降のルールでフィルタ条件に使える
18. @itiB_S144 インフラでの応急処置と落とし穴 18
19. @itiB_S144 インフラでの応急処置と落とし穴 落とし穴にお気づきでしょうか... 19
20. @itiB_S144 キーに limit があれば引っかかるルール = キーに limit さえあれば何でも引っかかる つまり... limit の文字列さえあれば 明らかな SQL インジェクション攻撃でも SQLi_BODY の検知をすり抜けられてしまう 落とし穴 インフラでの応急処置と落とし穴 20
21. @itiB_S144 立ち止まって考える、本当の最適解
22. @itiB_S144 • WAF の無効化 ◦ あらゆる攻撃に対して脆弱になってしまう • WAF のチューニング ◦ 細かいチューニングは複雑かつ限界がある • アプリケーションの設計を変更 ◦ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに • その他の WAF 製品の導入 対処方法として考えられるもの 立ち止まって考える、本当の最適解 22 2 1 3 4
23. @itiB_S144 メリット • WAF の誤検知をアプリケーションの設計に影響させずに済む デメリット • WAF の構成が複雑になる • APIが増えた際に時々インフラに手を入れる必要が出てくる WAF のチューニング 立ち止まって考える、本当の最適解 23
24. @itiB_S144 立ち止まって考える、本当の最適解 手間ふえてない...?? 24
25. @itiB_S144 • WAF の無効化 ◦ あらゆる攻撃に対して脆弱になってしまう • WAF のチューニング ◦ 細かいチューニングは複雑かつ限界がある • アプリケーションの設計を変更 ◦ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに • その他の WAF 製品の導入 対処方法として考えられるもの 立ち止まって考える、本当の最適解 25 2 1 3 4
26. @itiB_S144 今回であれば Body に limit の文字列が含まれなければよい。 APIの構成を変更しアプリを対応させる • WAFの調整は外す • 最適とまではいかないが、 誤検知を回避できる アプリケーションの設計を変更してみる 立ち止まって考える、本当の最適解 26
27. @itiB_S144 WAF のチューニング • WAF に穴をあけている • アプリケーションに穴があると 攻撃が通ってしまう • WAF のルールに更新があった際、 追従が必要な可能性がある • 不要なルールならば消してもOK 対応の比較（防御力編） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 • WAF は元の強度のまま • なにかあっても WAF が弾いてくれ る可能性がある • マネージドな WAF 設定をキープで きる 27
28. @itiB_S144 WAF のチューニング 対応の比較（2回目起きた時編） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 Limit の文字を 使わなければこれは 問題を解決できる✨ また Limit の文字列が 引っかかったので 対応お願いします！ 28
29. @itiB_S144 WAF のチューニング • インフラコスト: WCUの消費↑ • 初回対応: 調査/設定/テスト • スケーラビリティ: X • 必要なスキル ◦ AWS、セキュリティ • 対処療法 対応の比較（その他） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 • インフラコスト: 変化無し • 初回対応: パラメータの変更のみ • スケーラビリティ: O • 必要なスキル ◦ アプリ開発者で完結 • 根本的な対応 29
30. @itiB_S144 結論とまとめ
31. @itiB_S144 最初は WAF の調整すればいいと思っていた • WAF 起因で起きたこと • アプリケーションに影響させたくない サービス全体を見た結果「アプリケーションの設計を変更」を選んだ • 初回にかかる手間も将来的な運用にかかる手間も低い • WAF 本来の防御力に穴を開けずに済む 取った選択肢 結論とまとめ 31
32. @itiB_S144 セキュリティを考えるにはサービス全体を見れることが大事 それぞれの層でできる対応もあるが、最大限の成果を得るには各層の連携が必要 ここから考えられること 結論とまとめ 考えたいこと インフラ WAFの穴を極力作らない状態を維持、ルールの妥当性を検証 APIの構成 WAFを最大限に活用できるAPI構成 アプリケーションのコード そもそも攻撃を受けても問題ない状態 32
33. @itiB_S144 • WAF の誤検知をきっかけにサービス全体を見渡したチューニングを行った ◦ WAF のルールを調整する対応と比較し、 アプリケーションの設計を変更することで効率よく誤検知を回避できた • WAF の調整も可能だが、対処療法になる可能性がある ◦ 軽率な調整は将来の運用負荷になりかねない ◦ もちろん、調整するほうが総合的に良い結果になる可能性もある • 安易に WAF をバイパスさせず、サービス全体を俯瞰して最適解を選ぶ ◦ インフラとアプリケーション、両方の視点で考えて初めて見える解決策がある ◦ 境界を越えて協働できるチーム/エンジニアが真の多層防御を実現できる まとめ 結論とまとめ 33