Security Hub CSPM

Security Hub CSPM とは

AWS Security Hub の CSPM（Cloud Security Posture Management）機能は、AWS リソースの設定がセキュリティベストプラクティスに準拠しているかを継続的にチェックするサービスである。AWS アカウント内のリソース設定を自動でスキャンし、ベストプラクティスから外れた設定を「セキュリティ上の問題」として可視化することが主な役割になる。

コントロールと AWS Config の関係

Security Hub CSPM のチェック項目は「コントロール」と呼ばれる。各コントロールは内部的に AWS Config ルールによって評価されており、Security Hub を有効化すると、対応する Config ルールが自動でアカウントにデプロイされる。

Security Hub の finding（検出結果）は、内部で動作する Config ルールの評価結果から生成される。Config ルールが NON_COMPLIANT を返した場合、Security Hub では FAILED の finding が生成され、COMPLIANT を返した場合は PASSED の finding になる。

finding のステータス

Security Hub の各 finding は以下のステータスを持つ。

本記事では PASSED / FAILED の挙動を中心に扱う。

セキュリティ基準

Security Hub CSPM はあらかじめ定義された複数の「セキュリティ基準」（standards）を提供しており、各基準は数十〜数百のコントロールで構成される。AWS Foundational Security Best Practices（FSBP）、CIS AWS Foundations Benchmark、PCI DSS などが代表的である。本記事では後述の理由により FSBP を対象とする。

セキュリティ基準と重大度

FSBP を対象とする理由

Security Hub には複数のセキュリティ基準（CIS AWS Foundations Benchmark、PCI DSS 等）があるが、本記事では AWS Foundational Security Best Practices（FSBP） を対象とする。FSBP は AWS 自身が定義したベストプラクティス集であり、AWS サービス固有の設定チェックが最も網羅的に含まれている。他の基準（CIS 等）は業界標準の観点からのチェックであり、FSBP と重複するコントロールも多い。

重大度 CRITICAL / HIGH にフォーカスする理由

Security Hub コントロールの重大度は、悪用の難易度と侵害の可能性に基づいて AWS が割り当てている（AWS Prescriptive Guidance）。

MEDIUM / LOW のコントロールも対処すべきものであり、無視してよいわけではない。ただし、AWS は「CRITICAL と HIGH の finding を優先的に調査することを推奨」していることから、本記事では対処の優先順位に従い、まず CRITICAL / HIGH のコントロールを対象とする。

CRITICAL / HIGH コントロールの全体像

FSBP の CRITICAL / HIGH コントロールは合計 82 件（CRITICAL 27 件、HIGH 55 件）ある。セキュリティ上の懸念パターンで分類すると以下の通り。

CRITICAL 27 件中 21 件（78%）がパブリックアクセスの防止に分類される。

選定の考え方

本記事では、パブリックアクセスの防止（35 件）を検証対象とする。

パブリックアクセスにフォーカスする理由：

• CRITICAL 27 件中 21 件（78%）がパブリックアクセス関連であり、最もリスクが高いパターン
• 全 82 件の 43% を占める最大のカテゴリ

残り 47 件は、テーマが異なるため今回は扱わない。セキュリティサービスの有効化（GuardDuty / Inspector 等）は組織設計、パッチ管理やネットワーク分離はワークロード固有の運用設計に依存するテーマであり、パブリックアクセスの防止とは検証の観点が異なる。

パブリックアクセスの分類

35 件のコントロールを「何がパブリックになるか」の観点で 5 つに分類した。

各分類の個別コントロール・検証結果は上記リンク先のページを参照。

デフォルト保護

Security Hub CSPM のコントロールには、「何もしなくてもデフォルトで PASSED になるもの」と「デフォルトでは FAILED になるもの」がある。これを本記事ではデフォルト保護と呼ぶ。

定義と意味

「保護済み」とは、対象リソースを CLI のオプション省略（API のデフォルト値）で作成した場合に、当該コントロールが PASSED となる状態を指す。具体的には以下のいずれかが該当する。

• リソース作成時のデフォルト設定が、パブリックアクセスを許可しない方向に設定されている（例: S3 バケットの BPA がデフォルト有効）
• リソースのリソースポリシーがデフォルトでは存在せず、パブリック許可の経路自体がない（例: Lambda 関数の関数ポリシー）
• リソースの初期状態がそもそも非公開である（例: スナップショットの restore 属性が空）

逆に「未保護」のコントロールは、リソースを CLI のデフォルト値で作成した瞬間に FAILED の finding が発生するか、リソース作成とは別のアカウントレベル設定を有効化しないと FAILED のままになるものを指す（例: EBS Snapshot BPA は明示的に block-all-sharing に変更しない限り無効）。

API デフォルトとマネジメントコンソール

本記事における「デフォルト保護」は API のデフォルト値（CLI でオプションを省略した場合の値）に基づく。マネジメントコンソールの作成ウィザードでは、API のデフォルトとは異なる、より安全な値がプリセットされている場合がある。コンソール経由の操作だけを見ていると気付かない設定ギャップが、Terraform / CloudFormation / SDK 経由の自動化では露呈する、ということが起こり得る。

検証アプローチへの影響

デフォルト保護されているかどうかは、コントロールの検証アプローチに影響する。

• 保護済みのコントロール: デフォルトのままでは finding が発生しないため、検証は「どんな操作をすると FAILED になるか」「FAILED 状態から PASSED に戻すには何が必要か」を確認する流れになる
• 未保護のコントロール: デフォルトで FAILED になっていることをまず確認し、そこから「PASSED にするには何を設定すればよいか」を検証する流れになる

詳細は各カテゴリの個別ページを参照。

コントロール間の連動

組織レベルの宣言型ポリシーや一部のアカウント単位 BPA 設定を有効化すると、複数のコントロールが連動して PASSED に変化したり、違反操作が API レベルで拒否される。これらのペア関係を理解しておくと、予防手段の選択時に効率的に複数コントロールをカバーできる。

このため、組織単位で宣言型ポリシーを適用すれば、ペアの個別コントロールも自動的に PASSED 化または予防できる場合がある。ただし S3.6 / S3.8 / S3.19 のように評価対象が異なるコントロールは別途個別に対応が必要。表内で「SSM.7 連動」と表記されているのは、SSM Block Public Sharing 有効化により SSM.4 が予防される関係を指す。

SCP / 宣言型ポリシーの違い（既存違反の扱い）

予防手段にもいくつか種類があり、適用時点で既に違反状態のリソースが存在する場合の挙動が異なる。

「宣言型ポリシー（設定値強制型）」が成り立つのは、対象がアカウント単位の設定（EBS Snapshot BPA、S3 アカウントレベル BPA、SSM Block Public Sharing 等）の場合に限られる。リソース作成時の API パラメータ（例: RDS の PubliclyAccessible、EKS の endpointPublicAccess）を宣言的に強制する仕組みは AWS Organizations の宣言型ポリシーには存在せず、これらは SCP の Condition で API 呼び出しを Deny する以外に予防手段がない（CloudFormation Hook によるプロアクティブ予防は IaC 経由のデプロイにしか効かないため、本記事ではスコープ外）。

このため、SCP / 予防コントロールでデフォルト保護 × のコントロールに対応する場合は、SCP 適用前に既存リソースの初期化が必要となる。例えば SSM.7 はデフォルトで未保護のため、カスタム SCP で BPA 設定変更を Deny する前に、まず BPA を有効化しておく必要がある（さもないと SCP によって BPA が無効のまま固定されてしまう）。

アカウント発行時のベースラインで対応できるか

35 件のうち、SCP / カスタム SCP で予防するコントロールについて、アカウント発行時のベースラインだけで対応できるか整理する。

これら以外の SCP / 予防コントロール / 宣言型ポリシー / RCP で予防する 27 件は、デフォルト保護 〇 か、宣言型ポリシー（設定値強制型）/ RCP のように「ポリシー適用と同時に保護される」性質のため、ベースライン施策における順序問題は発生しない。

なお、上記は新規アカウント発行時の話で、既存アカウントに後から SCP を適用する場合は別途、既存違反リソースの修正計画が必要になる。RDS.2 の場合は既存パブリック DB の PubliclyAccessible=false 化（接続エンドポイント DNS 解決先が変わるためアプリケーション影響あり）が必要で、これはワークロード所有者との調整が必要となる。

他のツールとの位置づけ

Security Hub CSPM で検出された問題に対して、「予防」と「検出の深掘り」の両面で補完するツールがある。Security Hub CSPM は「リソースの設定」を継続的にチェックするのが基本だが、別の角度から問題を見るツールや、そもそも問題が起きないように事前に防ぐツールを組み合わせることで、より強固な防御層になる。

検出の深掘り

Security Hub CSPM 自体は「設定がベストプラクティスに沿っているか」をチェックするが、最終的に「どこから誰がアクセスできるか」までは踏み込まない。この観点を補完するのが IAM Access Analyzer である。

Security Hub CSPM は「設定がどうなっているか」をチェックする。IAM Access Analyzer は「最終的に誰がアクセスできるか」を分析する。Security Hub CSPM がパブリックアクセスの設定チェックを中心とするのに対し、IAM Access Analyzer はパブリックアクセスに加えてクロスアカウントアクセス（組織内・組織外の別アカウントからのアクセス）も検出する。

そのため、IAM Access Analyzer の対象リソース（S3 バケット、IAM ロール、KMS キー、Lambda 関数、SQS キュー、Secrets Manager、SNS トピック、EBS スナップショット、RDS スナップショット、ECR リポジトリ、EFS ファイルシステム、DynamoDB）については、CSPM がパブリックアクセスのみを検出するコントロールであっても、IAM Access Analyzer でクロスアカウントアクセスを補完的に検出できる。一方、IAM Access Analyzer の対象外リソース（VPC リソース、DocumentDB / Neptune クラスタースナップショット、SSM ドキュメント、EKS、MSK 等）については、CSPM の検出が主な手段となる。

なお、Control Tower にも独自の検出コントロール（Strongly recommended / Elective）があり、パブリックアクセス関連のものも含まれる。ただし、FSBP の方がコントロール数が多く網羅性が高いため、本記事では FSBP を基準として整理する（Control Tower のコントロール種別ごとの本サイトでの扱いは本サイトでのコントロール種別の扱いを参照）。

予防

Security Hub CSPM はあくまで「事後検出」のツールであり、問題のある設定が作成されること自体は止められない。問題のある設定を作成段階でブロックするのが「予防」のツール群である。

予防コントロールおよび宣言型ポリシーが存在するサービスについては、これらを優先的に活用すべきである。予防コントロールは AWS がポリシーの内容を管理しており、サービスの仕様変更に追従する。宣言型ポリシーはサービスのコントロールプレーンで直接強制されるため、新しい API が追加されてもポリシーの更新なしに設定を維持できる。一方、カスタム SCP / RCP は自分でメンテナンスが必要であり、サービスの API 変更や新機能追加に対して追従漏れのリスクがある。

予防コントロールが存在しないサービスについては、カスタム SCP / RCP 等で補完する必要がある。

予防手段が finding に与える影響

予防手段を有効化した場合、Security Hub の finding 状態は予防手段の種類によって挙動が異なる点に注意が必要である。

「予防手段を有効化したのに FAILED が残っている」というケースは多くあり、それは必ずしも予防が機能していないことを意味しない。実害の有無を判断するには、予防手段の種類と、各コントロールの評価ロジックの両方を理解する必要がある。詳細は各カテゴリの個別ページに記載した。

全コントロール一覧

35 件のパブリックアクセス防止コントロールについて、デフォルト保護・IAM Access Analyzer 対応・予防手段を一覧にまとめる。

凡例

• デフォルト保護: 〇 = リソースを CLI のデフォルト値で作成すると PASSED になる / × = デフォルトでは FAILED になる
• IAA: IAM Access Analyzer の対象リソースか。〇 = 対象（クロスアカウントアクセスも検出可能） / × = 対象外
• 予防手段: 各手段の機構を以下の 3 種類で示す。
  • [予] 予防: 違反状態の発生を防ぐ。API 操作の Deny（SCP / Control Tower 予防コントロール）と、設定値そのものを強制する宣言型ポリシーがこれに該当
  • [実] 実害ブロック（finding は残る）: リソース側の設定値は変えないが、実際のネットワークアクセスを遮断する。VPC BPA / RCP がこれに該当
  • [検] 検知 + 修復: API 操作はブロックできないため、Config マネージドルールで検知し、自動修復ランブックで復旧する

予防手段に * が付いているものは、実装方針は判明している（条件キーが提供されている、対応するマネージドルールが存在する等）が本サイトでは未検証のもの。

S3 パブリックアクセス（5 件）

スナップショット公開（5 件）

インターネット到達性（15 件）

VPC BPA は IGW / EIGW 経由のインターネット通信を組織全体でブロックする統制であり、本カテゴリの 15 件すべてに対する予防手段として機能する。ただし、リソース側の設定値（パブリック IP の付与設定、PubliclyAccessible フラグ等）は変更しないため、finding は FAILED のまま残る。実害（実際のインターネットアクセス）はブロックされる。

VPC BPA はリージョン単位かつアカウント全体に及ぶため、インターネット接続が必要な VPC は Exclusion で明示する運用となる。組織横断で Exclusion をどう管理するか（誰が Exclusion を作成できるか、SCP で制御するか）は別途運用検証が必要である。詳細はインターネット到達性を参照。

VPC BPA の運用負荷（多数の VPC、Exclusion 管理）が組織として許容できない場合のフォールバック策として、データストア系の CRITICAL 5 件（RDS.2 / DMS.1 / Redshift.1 / ES.2 / Opensearch.2）については個別予防の選択肢があるが、サービスごとに対応手段が異なる。CRITICAL 5 件に絞った理由は、これらが情報漏洩時の影響が甚大なデータストア系であり、二重防御の投資対効果が高いため。HIGH 10 件は VPC BPA に寄せる方針とする（リスクの段階差を踏まえた絞り込み）。

DMS.1 / ES.2 / Opensearch.2 については、VPC BPA で実害（外部からのアクセス）はブロックされるが、リソース側設定の変更は API 上不可能なため、新規作成時に予防する手段（カスタム SCP）が望ましい。ただしこれらサービスにはパブリックアクセスを制御する条件キーが存在しない（条件キー調査結果）。

リソースポリシー系（5 件）

サービス独自の公開設定（5 件）

Redshift.15 は VPC BPA で実害（外部からのクラスターポートへのアクセス）はブロックされるが、セキュリティグループの ingress ルール自体は変わらないため finding は FAILED のまま残る。

注釈

• * 実装方針は判明している（条件キーが提供されている、Config マネージドルールが存在する等）が、本サイトでは未検証