【Security Hub修復手順】[WAF.12] AWS WAF ルールでは CloudWatch メトリクスが有効になっている必要があります
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか?
当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[WAF.12] AWS WAF ルールでは CloudWatch メトリクスが有効になっている必要があります
[WAF.12] AWS WAF rules should have CloudWatch metrics enabled
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。 AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
本コントロールでは、AWS WAFv2の作成したルールグループで「CloudWatch メトリクスの収集」を有効にしているかどうかをが評価されます。
この「CloudWatch メトリクスの収集」はマネジメントコンソール上でルールグループを作成した場合必ず有効になっているもので、コンソール上から無効化/有効化の操作を行うことは出来ません。
また、API経由でルールグループを作成する場合にも必須の設定項目であるため、本コントロールが失敗している場合は意図的に無効化されているケースが考えられます。
AWS WAFv2のルールグループで「CloudWatch メトリクスの収集」を有効にしておくと、トラフィックのフローを可視化することが出来ます。つまり、どのルールがトリガーされ、どのリクエストがAllowされたかBlockされたかといった情報を確認することが出来るのです。この情報はWAFの運用にとって非常に有意なものなので是非有効化したいです。
AWS WAFにおけるCloudWatch メトリクスの詳細については下記リンク先をご参照下さい。
修復手順
1. ステークホルダーに確認を取る
前述の通り、本コントロールは意図的に無効にしていないと検知されない項目です。無効化されている場合、リソース作成者などのステークホルダーに下記の確認を取ります。
- メトリクスの収集を無効化している理由はあるか
- 特に無い場合は以降の手順に沿って有効化します。
2. 対象のリソースを把握する
それではSecurityHubの結果より、対象のルールグループを確認します。東京リージョン(ap-northeast-1)の場合、下記URLから確認可能です。
下図赤枠部が対象のルールグループIDです。
ルールグループIDを押下すると、下図のように対象ルールグループのARNが表示されます。このARNは後述の手順で利用するためメモします。
3. 対象ルールグループのCloudWatch メトリクス収集を有効化する
それでは対象ルールグループのCloudWatch メトリクス収集を有効化します。以降の操作は全てAWS CLI経由で行います。AWS CLIはAmazon CloudShellでの実行を推奨します。
https://dev.classmethod.jp/articles/tsnote-how-to-prepare-environment-for-aws-cli/
まずは現在の状態を確認します。
設定状態の確認には下記コマンドを実行します。下記コマンドは東京リージョンにリソースがある場合のものです。--region
の値はリソースが存在するリージョンを指定して下さい。対象リソースがCloudFrontにアタッチするルールグループの場合は us-east-1
を指定します。
aws wafv2 get-rule-group --arn '手順2で取得したARN' --query '[RuleGroup.VisibilityConfig, LockToken]' --region 'ap-northeast-1'
[cloudshell-user@ip-10-132-82-139 ~]$ aws wafv2 get-rule-group --arn 'arn:aws:wafv2:ap-northeast-1:123456789012:regional/rulegroup/cli-created/abcdefgh-1234-5678-90-12345678' --query '[RuleGroup.VisibilityConfig, LockToken]' --region 'ap-northeast-1' [ { "SampledRequestsEnabled": false, "CloudWatchMetricsEnabled": false, "MetricName": "cli-created" }, "******-****-****-****-************" ]
CloudWatch メトリクスの収集が無効の場合、上記のように "CloudWatchMetricsEnabled": false
となっているはずです。
続いて、下記コマンドを実行してメトリクスの収集を有効化します。有効化の際、上記コマンド結果の最後に表示されているトークンを使用します。
下記コマンドを実行します。
aws wafv2 update-rule-group \ --name 'ルールグループ名' \ --scope 'REGIONAL' \ --region 'ap-northeast-1' --id 'ルールグループID' \ --visibility-config SampledRequestsEnabled=false,CloudWatchMetricsEnabled=true,MetricName=ルールグループ名 \ --lock-token '上記確認手順で取得したトークン'
残念ながら本コマンドはARNでリソースの指定が出来ません。name、scope、region、idはARNから取得します。
ARNが arn:aws:wafv2:ap-northeast-1:123456789012:regional/rulegroup/cli-created/abcdefgh-1234-5678-90-12345678
の場合、nameは cli-created
、scopeは REGIONAL
、regionは ap-northeast-1
、idは abcdefgh-1234-5678-90-12345678
となります。
対象リソースがCloudFrontにアタッチするルールグループの場合は、scopeとして CLOUDFRONT
、regionとして us-east-1
を指定します。
[cloudshell-user@ip-10-132-82-139 ~]$ aws wafv2 update-rule-group \ > --name 'cli-created' \ > --scope 'REGIONAL' \ > --region 'ap-northeast-1' \ > --id abcdefgh-1234-5678-90-12345678 \ > --visibility-config SampledRequestsEnabled=false,CloudWatchMetricsEnabled=true,MetricName=cli-created \ > --lock-token '******-****-****-****-************' { "NextLockToken": "******-****-****-****-************" }
正常に実行された場合、上記のようにNextLockTokenが表示されます。
最後に、もう一度確認を行います。
[cloudshell-user@ip-10-132-82-139 ~]$ aws wafv2 get-rule-group --arn 'arn:aws:wafv2:ap-northeast-1:123456789012:regional/rulegroup/cli-created/abcdefgh-1234-5678-90-12345678' --query '[RuleGroup.VisibilityConfig, LockToken]' --region 'ap-northeast-1' [ { "SampledRequestsEnabled": false, "CloudWatchMetricsEnabled": true, "MetricName": "cli-created" }, "******-****-****-****-************" ]
CloudWatchMetricsEnabled
がtrueになっていれば成功です。
以上で設定は完了です。お疲れ様でした。
補足〜ルールの適用条件について〜
本記事を書いている途中、ルールを持たないルールグループを作成し、本コントロールが検知されるかどうかを確認してみました。
結果、ルールが1つも設定されていないルールグループは、本コントロールもとい元のConfigルール「wafv2-rulegroup-logging-enabled」の検知対象リソースから除外される仕様のようです。
ルールが1つも無い、CloudWatchMetricsEnabled
がfalseのルールグループに任意のルールを追加したところ、即座に検知されました。
ちなみに上記ルールグループはルールが無い状態でも、Configのコンソール上でリソースとしてはされていました。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう!
最後までお読みいただきありがとうございました!どなたかのお役に立てれば幸いです。
以上、べこみんでした。
クラスメソッドメンバーズをご契約の皆さまに
AWS Security Hub 「基礎セキュリティのベストプラクティス」の各チェック項目(コントロール)に対する弊社としての推奨対応やコメントを記載しているClassmethod Cloud Guidebook を提供しています。 クラスメソッドメンバーズポータルの「お役立ち情報」→「組織的な AWS 活用のためのノウハウ」からご参照ください。