目次：
【1. AWS WAFとWafCharmの2018年を振り返る】
AWS WAFは着々と機能アップデートして、進化を続けています。
ユーザが本当に欲しいと思うような機能を次々とリリースしているため、ぜひご紹介します！
2017年にはRegex Pattern MatchやGeo MatchなどWAFとしてのコア機能がリリースされました。またマネージドルールもリリースされたことでAWS WAFが大幅にアップデートされた年となりました。
2018年には、AWS WAFを実際に運用してみると困るポイントが改善・強化されたリリースが多かったです。
一方、AIによるAWS WAFのルール自動運用サービス「WafCharm」は、2018年2月よりサービスを開始しました。
その後、細かなアップデートを重ねながら、2018年9月1日にはAWS WAFのフルログ記録機能を活用した新機能「通知機能」と「レポート機能」をリリース、2018年11月にはAWS WAFがAmazon API Gatewayに対応したとのことでWafCharmでも追随してAPI Gatewayの保護に対応しました。
WafCharmでは、AWS WAFのルール自動運用というサービス内容に留まらず、検知したことをメールで通知してくれる「通知機能」、検知した結果を月次でレポートする「レポート機能」など、AWS WAFには搭載されていませんが、利用ユーザが欲しい！と思う機能をWafCharmで実現してきました。
2019年におけるWafCharmの機能アップデートもぜひ期待していてください！
それでは、2018年にリリースされたAWS WAFのアップデートを振り返っていきます！
【2. 2018年におけるAWS WAFとWafCharmの主な機能アップデート】
主な機能アップデートをアップデート順に簡単にご紹介していきます。
2.1. クエリ文字列不一致へのクエリを実行する拡張パターンマッチング（2018年6月リリース）
まず、Query Stringとは下記の赤字箇所を指します。
https://www.example.com?userid=wafcharm01&search=rule
さらに、?userid=wafcharm01&search=ruleを分解すると
パラメータ：useridとsearch
値：wafcharm01とrule
といった具合になります。
このアップデート以前は、パラメータと値を区別せずにマッチングさせる方法しかなく、誤検知が発生する原因でもありました。
このアップデート後は、パラメータと値で区別して、マッチングさせることができるようになり、より細かなマッチング条件を設定することができるようになりました。
これにより、誤検知を大幅に軽減することができるようになりました！
2.2. オクテットではない CIDR boundary のサポート（2018年6月リリース）
これまでのIPアドレスでマッチさせる条件としてはCIDR表記のうち、「/8、/16、/24、/32」というネットワークアドレスが、オクテット単位でしか登録することができませんでした。
そのため、192.168.1.0/29をホワイトリストに登録したい場合には、/32のIPアドレスに展開した上で登録する必要がありました。
アップデート前の場合）
192.168.1.0/32、192.168.1.1/32、192.168.1.2/32、192.168.1.3/32、192.168.1.4/32、192.168.1.5/32、192.168.1.6/32、192.168.1.7/32
このアップデートにより、オクテット以外のCIDR表記も含む「/8、/16〜/32」が登録可能となりました。
これにより、192.168.1.0/29をホワイトリストに登録したいという場合には
アップデート後の場合）
192.168.1.0/29
を登録すればよいということでより細かく楽に設定することができるようになりました！
2.3. Lambda@Edge で HTTP POST および PUT 処理のリクエストボディへのアクセスを提供（2018年8月リリース）
本アップデートは、AWS WAFに直接関わるアップデートではありませんが、CloudFrontでAWS WAFを利用しているケースでは重要なアップデートでした！
2018年8月時点では、AWS WAFに関しては検知履歴を全て取得する機能はなく、サンプリングでの取得となっていたため、誤検知調査をする際には難しい環境でしたが、HTTPリクエストのヘッダに限っては、Lambda@EdgeをCloudFrontにて利用することで取得することはできました。
一方のPOSTリクエストボディデータは、Lambda@EdgeをCloudFrontで利用しても取得することはできず、誤検知した原因がPOSTリクエストボディデータだった場合には確認する術がない状況でした。
本アップデートによって、Lambda@Edgeを利用することで、最大長1MBPOSTリクエストボディデータ（ヘッダーと本文を含む、Lambda 関数によって生成されたレスポンスのサイズが1MBまで）を取得することが可能となり、AWS WAFにてPOSTリクエストボディデータで誤検知が発生した場合にも調査できるようになりました。
下記ブログにて、Lambda@EdgeにてPOSTリクエストボディデータを取得する手順をご紹介していますので、ご参考までに。
Lambda@Edgeを使ってPOSTリクエストボディを取得してみる(https://www.wafcharm.com/jp/blog/aws-waf-post-body-lambda-edge-jp/)
2.4. 包括的なログ記録機能(フルログ記録機能)（2018年8月リリース）
本アップデート以前は、直近3時間以内のサンプリングされたログが取得できるサンプルログという機能のみでした。
WAFの運用においては、過去に遡って調査できる検知ログを包括的に取得・保管することが重要ですが、サンプルログだけではこの用途を満たすことは難しい状況でした。
本アップデートにより、フルログ記録機能を活用することで包括的に取得・保管することが可能となり、AWS WAFが大幅に進化しました。
※POSTリクエストボディデータの取得はできません
フルログをS3に出力して、検知履歴をログとして保管する方法は下記ブログで紹介していますので、ご参考までに。
AWS WAF Full Log を S3 に出力する（https://www.wafcharm.com/jp/blog/aws-waf-full-log-s3-output-jp/）
2.5. AWS WAFがAPI Gatewayに対応（2018年11月リリース）
AWS WAFは、リリース当初はCloudFrontにのみ適用することができました。2016年12月には、ALB(Application Load Balancer)に適用することができるようになりました。
そして、本アップデートにより、AWS WAFをAmazon API Gatewayに適用することができるようになりました！
本アップデート以前には、API GatewayのWebセキュリティを保護するためには、API Gatewayの前段にCloudFrontを配備して、そのCloudFrontにAWS WAFを適用するといったことが必要でした。アップデート後は、直接API GatewayにAWS WAFを適用することができるようになり、CloudFrontが不要で、費用的にも設定的にも嬉しいアップデートでした。
本アップデートに関するより詳しい説明は下記ブログをご参照ください。
AWS WAFがAmazon API Gatewayに対応しました！(https://www.wafcharm.com/jp/blog/aws-waf-usage-api-gateway-jp/)
2.6. AWS WAF のマネージドルールでルールグループの例外がサポート開始（2018年12月リリース）
本アップデート以前は、AWS WAFマネージドルール内に含まれる“ある1つのルール”で誤検知が発生した際に、その特定のルールだけをCOUNTモード（遮断せず、検知だけする）に変更することができませんでした。
そのため、マネージドルールをまるごとCOUNTモード（遮断せず、検知だけする）に変更する必要があり、誤検知対応するために、必要以上に防御力が低下してしまうという制約がありました。
本アップデートにより、AWS WAFマネージドルールの中でも誤検知の発生したルールだけをCOUNTモードに変更する細かな操作が可能となり、誤検知対応するのに必要以上に防御力を下がる心配はなくなりました！
今後はマネージドルールの中でも誤検知の発生したルールだけをCOUNTモードに変更する細かな操作が可能となりました。
本アップデートに関するより詳しい説明は下記ブログをご参照ください。
【新機能】AWS WAFのマネージドルールで個々のルールを制御できる「ルールグループの例外機能」がリリース！(https://www.wafcharm.com/jp/blog/aws-waf-managed-rule-rulegourp-exception-jp/)
以上、2018年におけるAWS WAFの機能アップデートのまとめでした！
