@itiB_S144 そのWAFのブロック、どう活かす？ サービスを守るための実践的多層防御と思考法 株式会社カミナシ いちび (@itiB_S144) JAWS FESTA 2025 in 金沢 近江町 Track D 16:00 ~ 16:20 

@itiB_S144 いちび 株式会社カミナシ ソフトウェアエンジニア 𝕏 : @itiB_S144 趣味 : ポケモンカード、キャンプ 出身 : 静岡県浜松市 好きなAWSサービス: CostExplorer 経歴 ● 2021/04 ECサイトのSREエンジニア ● 2024/10 カミナシ入社 

@itiB_S144 3 ● ある日起きた事件... ● インフラでの応急処置と落とし穴 ● 立ち止まって考える、本当の最適解 ● まとめ 2 1 3 4 3 

@itiB_S144 4 持ち帰っていただきたい内容 ● 技術「WAFのチューニング方法」 ● 思考「WAF のチューニングだけに頼らない意思」 ● 組織「インフラ・アプリの垣根を越えた共同に よって本当の多層防御を生み出す」 

@itiB_S144 ある日起きた事件... 

@itiB_S144 なんか画面がうまく動作しないな... サーバ側のログを漁ってもなんもエラー出してないのに... ローカルではしっかりアプリが動いていること確認できたのに... dev 環境にデプロイしたらなんかうまく動かない ある日起きた事件... 6 

@itiB_S144 とりあえず curl で止まってる API 叩いてみるか... ある日起きた事件... 7 

@itiB_S144 Private subnet Virtual private cloud (VPC) 現在の構成 ある日起きた事件... Public subnet Private subnet Aurora AWS WAF ECS Application Load Balancer CloudFront 8 

@itiB_S144 AWS の提供する WAF(Web Application Firewall) ● 様々なマネージドなルールが存在し、 組み合わせることでサービスに合ったルールを作れる ● CloudFrontやApplication Load Balancer、 API Gateway等に手軽に接続でき、簡単に導入できる AWS WAF とは ある日起きた事件... 9 

@itiB_S144 コンソールからブロックの数を確認 AWS WAF の検知とログを確認 ある日起きた事件... 10 

@itiB_S144 CloudWatch Logs に流したログを確認 ある日起きた事件... 11 詳細なブロック理由がわかる ● AWSManagedRulesSQLiRuleSet SQLi_BODY ● Body に含まれる offset, limit の文字列 

@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 

@itiB_S144 インフラでの応急処置と落とし穴 

@itiB_S144 ● WAF の無効化 ○ あらゆる攻撃に対して脆弱になってしまう ● WAF のチューニング ○ うまくチューニングできればよさそう??? ● アプリケーションの設計を変更 ○ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに 対処方法として考えられるもの インフラでの応急処置と落とし穴 14 2 1 3 

@itiB_S144 ● 今回引っかかっているのはどうやら Body の offset, limit 文字列 ● WAF を緩めるにしても緩める箇所は最小限にしたい ○ 対象のパスは限定する ○ 対象のルールも限定 ○ 緩めた分、SQLインジェクションされかねない実装がアプリにないか確認 チューニングの方針 インフラでの応急処置と落とし穴 1. /search のパスで 2. Body の文字列 offset, limit は除外 3. AWSManagedRulesSQLiRuleSet.SQLi_BODY の ルールを回避させる 15 

@itiB_S144 検査（一致ステートメント） - Scope-down statement - グループ内すべてのマネージドルールに影響 - クエリ文字列やパスなどを組み合わせた フィルタを作成 ルールオーバーライド - ルール毎のアクションを設定可能 Block/Challenge/CAPTCHA/Count/Allow AWS WAF のマネージドルールはどんな調整ができるか インフラでの応急処置と落とし穴 16 

@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 で通過した通信には「ラベル」が付き 以降のルールでフィルタ条件に使える 

@itiB_S144 インフラでの応急処置と落とし穴 18 

@itiB_S144 インフラでの応急処置と落とし穴 落とし穴にお気づきでしょうか... 19 

@itiB_S144 キーに limit があれば引っかかるルール = キーに limit さえあれば何でも引っかかる つまり... limit の文字列さえあれば 明らかな SQL インジェクション攻撃でも SQLi_BODY の検知をすり抜けられてしまう 落とし穴 インフラでの応急処置と落とし穴 20 

@itiB_S144 立ち止まって考える、本当の最適解 

@itiB_S144 ● WAF の無効化 ○ あらゆる攻撃に対して脆弱になってしまう ● WAF のチューニング ○ 細かいチューニングは複雑かつ限界がある ● アプリケーションの設計を変更 ○ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに ● その他の WAF 製品の導入 対処方法として考えられるもの 立ち止まって考える、本当の最適解 22 2 1 3 4 

@itiB_S144 メリット ● WAF の誤検知をアプリケーションの設計に影響させずに済む デメリット ● WAF の構成が複雑になる ● APIが増えた際に時々インフラに手を入れる必要が出てくる WAF のチューニング 立ち止まって考える、本当の最適解 23 

@itiB_S144 立ち止まって考える、本当の最適解 手間ふえてない...?? 24 

@itiB_S144 ● WAF の無効化 ○ あらゆる攻撃に対して脆弱になってしまう ● WAF のチューニング ○ 細かいチューニングは複雑かつ限界がある ● アプリケーションの設計を変更 ○ WAF の誤検知がアプリケーションの設計に影響を及ぼし、境界があいまいに ● その他の WAF 製品の導入 対処方法として考えられるもの 立ち止まって考える、本当の最適解 25 2 1 3 4 

@itiB_S144 今回であれば Body に limit の文字列が含まれなければよい。 APIの構成を変更しアプリを対応させる ● WAFの調整は外す ● 最適とまではいかないが、 誤検知を回避できる アプリケーションの設計を変更してみる 立ち止まって考える、本当の最適解 26 

@itiB_S144 WAF のチューニング ● WAF に穴をあけている ● アプリケーションに穴があると 攻撃が通ってしまう ● WAF のルールに更新があった際、 追従が必要な可能性がある ● 不要なルールならば消してもOK 対応の比較（防御力編） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 ● WAF は元の強度のまま ● なにかあっても WAF が弾いてくれ る可能性がある ● マネージドな WAF 設定をキープで きる 27 

@itiB_S144 WAF のチューニング 対応の比較（2回目起きた時編） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 Limit の文字を 使わなければこれは 問題を解決できる✨ また Limit の文字列が 引っかかったので 対応お願いします！ 28 

@itiB_S144 WAF のチューニング ● インフラコスト: WCUの消費↑ ● 初回対応: 調査/設定/テスト ● スケーラビリティ: X ● 必要なスキル ○ AWS、セキュリティ ● 対処療法 対応の比較（その他） 立ち止まって考える、本当の最適解 アプリケーションの設計を変更 ● インフラコスト: 変化無し ● 初回対応: パラメータの変更のみ ● スケーラビリティ: O ● 必要なスキル ○ アプリ開発者で完結 ● 根本的な対応 29 

@itiB_S144 結論とまとめ 

@itiB_S144 最初は WAF の調整すればいいと思っていた ● WAF 起因で起きたこと ● アプリケーションに影響させたくない サービス全体を見た結果「アプリケーションの設計を変更」を選んだ ● 初回にかかる手間も将来的な運用にかかる手間も低い ● WAF 本来の防御力に穴を開けずに済む 取った選択肢 結論とまとめ 31 

@itiB_S144 セキュリティを考えるにはサービス全体を見れることが大事 それぞれの層でできる対応もあるが、最大限の成果を得るには各層の連携が必要 ここから考えられること 結論とまとめ 考えたいこと インフラ WAFの穴を極力作らない状態を維持、ルールの妥当性を検証 APIの構成 WAFを最大限に活用できるAPI構成 アプリケーションのコード そもそも攻撃を受けても問題ない状態 32 

@itiB_S144 ● WAF の誤検知をきっかけにサービス全体を見渡したチューニングを行った ○ WAF のルールを調整する対応と比較し、 アプリケーションの設計を変更することで効率よく誤検知を回避できた ● WAF の調整も可能だが、対処療法になる可能性がある ○ 軽率な調整は将来の運用負荷になりかねない ○ もちろん、調整するほうが総合的に良い結果になる可能性もある ● 安易に WAF をバイパスさせず、サービス全体を俯瞰して最適解を選ぶ ○ インフラとアプリケーション、両方の視点で考えて初めて見える解決策がある ○ 境界を越えて協働できるチーム/エンジニアが真の多層防御を実現できる まとめ 結論とまとめ 33