オープンなコミュニティであり、組織がアプリケーションやAPIを開発、調達、メンテナンスするにあたりそれらが信頼できるようになることに専念しています。10を有効にしておきたい本当はそのあたりのまとめ記事を先に書くつもりでしたが、どうしても動かしたい欲に負けました。rules」を選択WAFの効果を確かめるWAF設定後SQLiを実行すると403が返却されているちなみにWAF(ALB)を通さずに同じ入力をするとSQLiが通る(Adminでログイン処理ができてしまう)でもマネージドルールの中(今回だとOWASPtop10を網羅)のどのルールでブロックされたかはWAFのコンソール画面からだと、分からず、以下の画面ショットの情報しか出ないまた直近3時間の中からサンプルとして抽出する形を取るため完全なログではなく、過去に遡っての確認等にもそのままは使えない。上述したように、「なぜブロックされたか?」と言う情報が十分ではありませんまた誤検知の際に何らか対応を打ちたい場合も少し情報としては不足しているように感じました完全ログの取得(KinesisDataFireHose)を使うことでどこまで上記状態が緩和されるのかを確認したいと思います。fields(ログに記録しないフィールド)は選択なしにしましたログの書き込み確認ALB(WAF)経由で検知するアクセス、しないアクセスをそれぞれ実行S3上の書き込みを確認しますうまくいっていそうです完全ログの確認サンプルログと項目だけを比較すると特に“ruleId”が取れていることが差としては大きいですただしこのルールIDがマネージドルール(今回はOWASPtop10対応)の中のどのようなルールに対応しているかまでは分かりません。このidを利用してルールから除外するという対応を取ることはできるようです。Cloud」のマネージドルールがOrder(優先度)1でその次にIPアドレス用のルールがきました。IPのルールが先に評価されるようにOrderを入れ替えIPのルールをAllowにします上記の状態で、IPアドレスが許可したものにマッチした場合、通信を許可し、後のルールは評価されなくなります。IPのみを判定条件とし後の条件は評価されません。まとめマネージドルールを使っても思っていた以上に運用は難儀な気がする運用を考えた場合、サンプルログだけだと厳しい場面が出そうで、結局KinesisDataFireHoseの導入も合わせて設計や費用面も考える必要があるように感じました。マネージドルールはやはりブラックボックスで「何で引っかかったか?」はURIやクエリストリング等で判断する必要がありそうCloudWacthのAlarmを使用する場合は、高頻度の通知が予想されるため目的に合わせて閾値を設定するべきだと感じましたまたBlockは成功しているので事後の振り返りやレポーティングで十分な場合は必ずしも必要とは感じませんでした。