[アップデート] Security HubにVPC ブロックパブリックアクセス (BPA) の有効化をチェックするコントロール(EC2.172)が追加されました

あしざわです。

Security Hub、使っていますか？

先日Security Hub のAWS 公式ドキュメントのHistory が更新されました。

その更新内容は、Security Hub に[EC2.172] EC2 VPC Block Public Access settings should block internet gateway trafficという新しいコントロールが追加されたことを示すものでした。

VPC Block Public Access といえば、2024年の年末に発表された記憶に新しいアップデートです。

https://dev.classmethod.jp/articles/try-vpc-block-public-access/

CloudFront のVPC Origin Access と合わせて、ネットワークのベストプラクティスの変容の予感を感じさせる私も注目していたアップデートだったのですが、年を跨いでSecurity Hub のコントロールにも追加されたようです。

このブログでは、Security Hub に追加されたVPC Block Public Access(以下VPC BPAと略します) に関するコントロールがどのようなものなのかチェックした様子をお届けします。

このブログを参考にすれば内容や仕様を把握でき、あなたのAWSアカウントで対応が必要か検討できるようになるはずです！

概要

今回のコントロールは、皆さん大好きSecurity Hub コントロールを一覧化した公式ドキュメントのEC2 のページに記載されています。

https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-172

概要をまとめたものがこちらです。

このコントロールでは、対象のアカウント(リージョン)でVPC BPA が有効化されているかチェックします。
機能が有効化されている場合はPASS(準拠)、有効化されていない場合はFAILED(非準拠)となります。

アカウントのデフォルト設定ではVPC BPA はオフになっているため、明示的にBPA を利用していないアカウントすべてで検出されているはずです。

基本的にVPC のパブリックアクセスを利用しない環境だったり、そもそもVPC を利用しない環境では対応することが推奨されますが、NAT Gateway の利用がありパブリックアクセスが必須な環境では対応が難しいと考えます。

状況に応じてコントロールを無効化・抑制してください。

補足：カスタムパラメータの仕様について

カスタムパラメータの仕様について補足します。

EC2.172のコントロールでは、カスタムパラメータとしてblock-bidirectional か block-ingressのどちらかを指定します。

このパラメータはVPC BPA のインターネットゲートウェイのブロック方向の設定である、双方向 と Ingress-only(インバウンドのみ)に対応しています。双方向がblock-bidirectionalで、Ingress-onlyがblock-ingressです。

このパラメータをSecurity Hub で指定することで、VPC BPAの設定だけでなく設定値がどちらになっているのかまで、評価対象に含められます。

忙しい方向けの検証まとめ

以降で紹介する検証の内容を、主にSecurity Hubのスケジュールタイプ観点でまとめました。

• コンソールからVPC BPAを設定した場合、設定変更後にコントロールの評価が実行される。
• カスタムパラメータの設定を変更したとき、Configルールが再作成されコントロールの評価が実行される。
• 宣言型ポリシーからの設定では、コントロールの評価は実行されない。

試してみた

ここからは実際に手を動かして挙動を確認していきます。

VPC BPAの有効化方法は「マネジメントコンソール等から直接API を利用して有効化する」「EC2の宣言型ポリシーを使ってOrganizations経由で有効化する」の2パターンあります。

これらを考慮して、以下のような様々なパターンでVPC BPA を有効化し、Security Hub がどのように検知するか試してみます。

• マネジメントコンソールを使う場合(カスタムパラメータの利用なし)
• マネジメントコンソールを使う場合(カスタムパラメータの利用あり)
• EC2の宣言型ポリシーを使う場合

Security Hub のカスタムパラメータや宣言型ポリシーについてもっと知りたい方は、以下ブログをご覧ください。

https://dev.classmethod.jp/articles/security-hub-custom-control-params/

https://dev.classmethod.jp/articles/aws-organizations-declarative-policies-available/

以降、検証の様子を紹介します。

マネジメントコンソールを使う場合(カスタムパラメータの利用なし)

Security Hub およびAFSBPが有効化されているAWS アカウントで、EC2.172コントロールの状態を確認してみました。

すると、以下のようにSecurity Hub コントロールはFAILED のステータスでした。

VPC BPAはデフォルトでは無効になっているため、これは想定通りですね。

VPC > 設定 からVPC BPA を有効化します。ブロック方向は双方向としました。

Security Hub コントロールを確認すると、PASSED に更新されていました。

検証時のCloudTrail の挙動がこちら。下から順にAPIが先に実行されています。

タイムスタンプから判断して、ModifyVpcBlockPublicAccessOptionsのAPI実行は「VPC > 設定 からVPC BPA を有効化します。」のタイミングで実行されたようです。

その直後、SecurityHub-PutEvaluations(Security Hubのサービス)によってPutEvaluationsのAPIが実行されています。

上記PutEvaluationsのJSONイベントレコードの一部を抜粋したものがこちらです。

    "requestParameters": {
        "resultToken": "HIDDEN_DUE_TO_SECURITY_REASONS",
        "testMode": false,
        "evaluations": [
            {
                "orderingTimestamp": "Jan 26, 2025 4:46:34 PM",
                "complianceResourceType": "AWS::EC2::VPCBlockPublicAccessOptions",
                "complianceResourceId": "123456789012",
                "complianceType": "COMPLIANT"
            }
        ]
    },

この結果から、

マネジメントコンソールを使う場合(カスタムパラメータの利用あり)

本コントロールではSecurity Hub のカスタムパラメータを利用して、Security Hub でチェックするパラメータをより厳密に指定できます。具体的には双方向、インバウンドのみのどちらかを指定できます。

コントロールの詳細画面、パラメータ > 設定からカスタムパラメータを設定できます。

Security Hub のステータスがFAILED になる様子を見たかったため、value にはblock-ingressを指定しました。

カスタムパラメータの設定直後はSecurity Hub のステータスが変わっていないように見えました。

このコントロールのスケジュールタイプはChange triggeredなので、VPC の設定を再度変えないと行けないのでは、と考えました。

VPC BPAの 設定を双方向→インバウンドのみ→双方向と2回変更したところ、再度評価されFAILED と判定されていました。

検証時のCloudTrail の挙動がこちら。別のイベントも含まれていたので、検証に関連するイベントのみを赤枠で記しました。

このイベント履歴から、カスタムパラメータを変更しただけでもPutEvaluationsによる再評価が実行されることがわかりました。よって、VPC BPAの再設定は不要でした。

あまり触れませんが、カスタムパラメータの変更するとConfig ルールが再作成されることをここで知りました。

EC2の宣言型ポリシーを使う場合

最後に、EC2の宣言型ポリシーを利用した場合にSecurity Hubコントロールではどのように評価されるか確認してみます。

素の状態から試してみたかったので、ここまでに設定した内容をリセットしました。

• アカウントのVPC BPA設定をオフに
• EC2.170のカスタムパラメータ設定を削除

検証用アカウントのOrganizations 管理アカウントでログインし、EC2 の宣言型ポリシーを作成します。

ポリシーにVPC ブロックパブリックアクセスの属性を追加し、インターネットゲートウェイの状態を双方向をブロックとしました。

作成したポリシーのターゲット設定を変更し、検証アカウントが含まれるように指定してください。スクショはアカウントにしていますが、OU単位でも指定できます。

設定後、検証アカウントのVPC設定を確認したところ、管理者: 宣言型のポリシーと表示されたVPC BPA が設定されていました。

再び、Security Hub コントロールの状態を確認すると、FAILED でした。

どうやら、更新済みフィールドの時間が更新されていないため、宣言型ポリシーの設定が再評価のトリガーになっていないようです。

CloudTrail のイベント履歴を確認したものがこちら。

VpcBlockPublicAccessUpdatedとVpcBlockPublicAccessOptionsUpdateがポリシー設定時に実行されているように見えます。

特に、VpcBlockPublicAccessUpdatedのJSONイベントレコードから、$.serviceEventDetails.managedByからdeclarative-policy(宣言型ポリシー)という記載が確認できたり、$.serviceEventDetails.attributeUpdatedの配下で宣言型ポリシーで指定した属性がパラメータとして表示されていました。これで間違いなさそうですね。

    "serviceEventDetails": {
        "managedBy": "declarative-policy",
        "attributeUpdated": {
            "type": "vpc-block-public-access",
            "value": "{\"internetGatewayBlock\":{\"mode\":\"block-bidirectional\",\"exclusionsAllowed\":\"disabled\"}}"
        }
    },

しかしこの変更の後、数時間Security Hubによる再評価が実行されていないため、これらのAPI は再評価のトリガーになっていないように見えます。

Security Hubによって作成・管理されたConfig マネージドルール(securityhub-ec2-vpc-bpa-internet-gateway-blocked-xxx)をConfig コンソールから確認すると、リソースタイプがEC2 VPCBlockPublicAccessOptionsと指定されていることがわかりました。

コンソールから変更した時のAPI のModifyVpcBlockPublicAccessOptionsではトリガーされるが、宣言型ポリシーによる変更時のAPIVpcBlockPublicAccessUpdatedではトリガーされない、というのがここまで確認できた事象です。

これは仕様・バグのどちらなのかは不明ですが、現状宣言型ポリシーによる設定によってコントロールの再評価が実行されない、ということだけはわかります。

宣言型ポリシーを利用している環境で、EC2.172がFAILEDになったままステータスが変わらない環境があれば、この事象を覚えておくといいかもしれません。

まとめ

検証の内容を、主にSecurity Hubのスケジュールタイプ観点でまとめました。

• コンソールからVPC BPAを設定した場合、設定変更後にコントロールの評価が実行される。
• カスタムパラメータの設定を変更したとき、Configルールが再作成されコントロールの評価が実行される。
• 宣言型ポリシーからの設定では、コントロールの評価は実行されない。

最後に

このブログでは、Security Hub に追加された新しいコントロール[EC2.172] EC2 VPC Block Public Access settings should block internet gateway trafficの紹介と、検証を行いました。

EC2.172は、FSBP に適用されているコントロールなので既に検出している環境が多くあると思います。

対応方針を検討し、AWS アカウント・組織のセキュリティレベルを向上させましょう！

本ブログが参考になれば幸いです。

以上、芦沢でした。