Security Hubのグローバルリソースに関するコントロールを無効化して不要なコストを削減しよう

こんにちはカスタマーソリューション部のこーへいです！

皆さん、Security Hubの料金を下げたいなと思ったことはありませんか？

AWS Configサービスではグローバルリソースを1つのリージョンのみ記録する。なぜなら全リージョンで記録しちゃうと不要なコストがかかるからということは多くの方がご存知だと思います。

一方で、Security Hubではグローバルリソースに関するコントロールを無効にしている方は少ないんじゃないかということで本記事を確認し、実施いただければと思います。

Security Hubとは

AWS Security Hubのメイン機能としては、「セキュリティ基準機能」と呼ばれるものが挙げられます。これは、Cloud Security Posture Management（CSPM）に相当するサービスで、「AWSリソースのセキュリティ設定がベストプラクティスから逸脱していないか」を自動でチェックします。

【初心者向け】AWS Security Hubとは？概要からメリット、料金まで解説より引用

上記の説明が分かりやすく、Security HubはAWSアカウント内に存在する危険な設定があった場合にユーザーにお知らせしてくれます。

例えばS3バケットが意図せずパブリック公開されていると、Security Hubがその状態を検知しユーザーに教えてくれるので、それに対してパブリック公開の設定を是正することで情報流出などの脅威を未然に防ぐことが可能です。

前提

本記事では、Security Hubで有効化しているセキュリティ基準をAWS Foundational Security Best Practices (FSBP) 標準であることを前提にお話しします。

他のセキュリティ基準でも基本的な考えは同じですが、セキュリティ基準間で使用されているコントロールが異なるため本記事ではAWS FSBP標準を前提とします。

Security Hubのチェックの仕組み

まず、Security Hub自体は各コントロール対象のリソースの状態を直接チェックしているわけではございません。

どういうことなのか？具体例を見てみましょう。

例えば、GuardDuty.1というコントロールは、GuardDutyがアカウント内で有効化されているかどうかを確認し、GuardDutyが有効化されていなければSecurity Hubは失敗ステータスを表示します。

ですが、実はGuardDutyが有効化されているかどうかを確認するのはSecurity Hubではありません。

実際は、AWS Config(以降Config)のConfigルールがGuardDutyが有効化されているのを確認し、その結果をSecurity Hubがチェックしています。

論より証拠ということで、AWS側でも確認しましょう。

Security HubでGuardDuty.1を確認すると調査欄にConfigルールがあります。そしてGuardDutyは有効化されていないのでステータスも失敗が表示されています。

ではConfigルールのリンク先に飛んでみましょう。以下を確認できました。

• GuardDuty.1で利用するルールはSecurity Hubが作成したマネージドルールであること
• ルールの内容は「このAWSコントロールは、Amazon GuardDutyがAWSアカウントとリージョンで有効になっているかどうかをチェックします。※機械翻訳」であること
• GuardDutyが無効化なので、本ルールでもSecuirty Hubの結果と同じくステータスが非準拠(失敗)になっていること

Security HubとConfigルールの関係の詳細はSecurity Hub公式ドキュメントの前提条件と推奨事項のAWS Config の設定の章をご確認ください。

Security Hubのチェック料金

Security Hubのチェック仕組みが分かったところで、チェック料金を確認してみましょう。

以下はSecurity Hub側のチェック料金となります。

次にConfigのルール評価料金となります。

料金体系が同じであることがわかります。

Security Hubの料金ページの記載を確認します。

Security Hub のセキュリティチェックでは、AWS Config が記録した設定項目を利用します。これらのセキュリティチェックには AWS Config が必要です。設定項目は Security Hub とは別の料金が設定されています。詳細については、Config の料金をご覧ください。Security Hub のお客様は、Security Hub によって有効化される AWS Config ルールを無料でご利用いただけます。Security Hub によって有効化される AWS Config ルールは、サービスにリンクされたルールと言います。

Config単体だとConfigルールの料金がかかりますが、Security Hubの機能として必要なConfigルールはSecurity Hub側の料金として計上され、Config側ではかからなくなるとのことですね(注意：Configの料金要素の1つである記録毎に0.003USDについては通常通りかかります)。

不要な料金を削減しよう

そもそもConfigのグローバルリソースは1つのリージョンのみにしてますか

Configでは、グローバルリソースを1つのリージョンのみで記録し、それ以外のリージョンではグローバルリソースを記録してはいけません(語気強め)。

なぜなら全リージョンのConfigでグローバルリソースの記録を有効化していると、リージョンの数分同じ内容が記録されるため無駄に利用費がかかってしまいます(同じ内容なので記録は1リージョンのみで良いです)。

その結果、以下のブログで紹介している失敗談のように料金が高騰することもあります。

Configと同様の理由で、Security Hub側でもグローバルリソースのチェックは1リージョンのみで良いです

では本題に移りましょう。先ほどお伝えした「Configでは、グローバルリソースを1つのリージョンのみ記録する」は実施している方も多いと思いますが、実はSecurity Hubでも同様の作業が必要です。

Configほど料金インパクトは大きくないものの、Security Hub側のグローバルリソースに関するコントロールを無効化しないとConfig同様に、不要な料金が追加されてしまいます。

料金インパクトがそこまで大きくなく気付きにくいのもあり、Security Hub側の知名度は低いと思われます(公式ドキュメント以外のブログ記事も執筆時点で無さそうに見える)。

具体的に無効化すべきコントロールを、無効にする可能性のある Security Hub コントロールのグローバルリソースを処理するコントロールの章で確認しましょう。

こちらで挙げられていてかつ、AWS FSBP標準で使用されているコントロールは以下の12項目となります。

• Account.1
• IAM.1,2,3,4,5,6,7,8,21
• KMS.1,2

イラストでも起こしてみました。

東京リージョンではグローバルリソースをConfigが記録しているので、正しくSecurity Hubでもチェックしステータスが表示されます。

一方でバージニア北部などConfigがグローバルリソースを記録していないのにも関わらず、Security Hub側で上記コントロールを有効化していると、何も評価していないConfigルールをチェックし続けることになり本当に無駄なコストを払う羽目になります。

以下は無効にする可能性のある Security Hub コントロールの記述です。

AWS Config のコストを節約するために、1 つの AWS リージョン を除くすべてのグローバルリソースの記録を無効にすることができます。これを行った後、AWS Security Hub は引き続きコントロールが有効になっているすべてのリージョンでセキュリティチェックを実行し、リージョンごとにアカウントごとのチェック数に基づいて料金を請求します。したがって、Security Hub での検出結果のノイズを減らし、コストを節約するには、グローバルリソースを記録するリージョン以外のすべてのリージョンで、グローバルリソースを処理する以下のコントロールを無効にします。

無効化しよう

以下をCloudShellにて実行しましょう。

# SecurityControlIdの一覧
CONTROLS=("IAM.1" "IAM.2" "IAM.3" "IAM.4" "IAM.5" "IAM.6" "IAM.7" "IAM.8" "IAM.21" "KMS.1" "KMS.2" "Account.1")

# 全リージョンに対してコマンドを実行
for REGION in $(aws ec2 describe-regions --query "sort(Regions[].RegionName)" --output text)
do
    # 東京リージョンを除外
    if [ "$REGION" != "ap-northeast-1" ]; then
        for CONTROL in "${CONTROLS[@]}"
        do
            aws securityhub --region $REGION batch-update-standards-control-associations --standards-control-association-updates "[{\"SecurityControlId\": \"$CONTROL\", \"StandardsArn\": \"arn:aws:securityhub:$REGION::standards/aws-foundational-security-best-practices/v/1.0.0\", \"AssociationStatus\": \"DISABLED\", \"UpdatedReason\": \"Control over global resources\"}]"
        done
    fi
done

実行後、東京リージョン以外で各コントロールが無効化されていることが確認できました(下記画像はオハイオのIAM.2が無効化されている様子)。

またリージョンによっては(執筆時点では大阪リージョン)、コマンド実行中に対象のコントロールがないエラーレスポンスが返ってきました。

どれくらい料金が下がるの

かなりざっくり計算とはなりますが、私の環境では1リージョンあたり１日平均0.005~6ドル程度削減されていました。

なので、0.005(ドル)×30(日)×16(東京以外のリージョン数)=2.4ドルと約数ドル程度下がる見込みで考えていただくと良さそうです。

Configでは東京リージョン以外でグローバルリソースを記録していないので、アカウントによってそこまで大きな料金の変動はない見込みですが検証ベースなので確証は持てていません。

参考：セキュリティチェックの実行スケジュール

まとめ

塵も積もれば山となるように、こちらのコスト削減も地味ながらありがたいですね。

是非実施していきましょう。

関連記事