はじめに
Security Hub CSPM の Critical / High パブリックアクセス系コントロール 35 件を対象に、AWS の予防機能でどこまで公開状態を防げるかを実 AWS アカウントで検証してみました。具体的には、Control Tower の予防コントロール、カスタム SCP、Config + 自動修復などです。
結論として、明確に防ぐことができたのは 10 件にとどまりました。残りは、実際のアクセスは防げたものの、Security Hub CSPM 上では FAILED 状態のままとどまってしまった「実害ブロック」が 18 件、検知してから自動で修復する「自動修復」が 4 件、強制手段がない「運用ルール依存」が 3 件となりました。本記事は、検証結果と、予防機能の採用判断の論点を整理したものです。
パブリックアクセス系のコントロールにどう向き合うか悩んでいる方の判断材料になれば幸いです。
1. 背景
セキュリティ担当として Security Hub CSPM を運用していると、過剰な予防統制を敷かない方針の組織であっても、「Critical や High のパブリックアクセス系コントロールは、検出されたら結局アカウント担当者に修正を依頼するのだから、最初から予防してしまえばいいのではないか」という話になることがあります。
確かに、原則修正を求めるなら、最初から API レベルで止めた方が運用負荷は低いので、予防手段の検討を行うことにしました。当初は Control Tower の予防機能で一通り塞げるだろうと踏んでいたのですが、調べ始めると、AWS のパブリックアクセスを止める仕組みは Control Tower 予防コントロール以外にも、カスタム SCP、宣言型ポリシー、サービス固有の Block Public Access 機能(以下、BPA)など複数の層に散らばっていることが分かりました。そこで、これらの関係を一度、体系的に整理してみることにしました。
業務では限られた時間で優先度を付けたため、現組織の運用方針に合わない手段までは検証できませんでした。そこで、業務で扱えなかった範囲も含めて「思いつく予防手段を全部試したらどこまで塞げるのか」をプライベートで検証し、コントロール単位で体系的に整理してみました。本記事はその結果です。
なお、そもそも「予防すべきか、検出のまま運用するべきか」は、組織のリスク許容度や運用体制によって変わる判断です。本記事は「パブリックアクセス系については、予防できるものは予防したい」という方針で、どこまで技術的に防げるかを検証するのが目的のため、予防すべきか否かの判断そのものには踏み込んでいません。判断材料として「予防・実害ブロック・自動修復のどれがどこまで効くか」を示すので、各組織のスタンスに応じて取捨選択して頂ければと思います。
2. 検証対象を絞る
2.1 全体像と検証対象の選定
検証対象は、AWS Security Hub の AWS Foundational Security Best Practices（以下、FSBP）v1.0.0 に含まれるコントロールのうち、重大度が CRITICAL または HIGH で、対象がパブリックアクセスを防ぐものに絞りました。検証は AWS Organizations / Control Tower のマルチアカウント環境、主たるリージョンは ap-northeast-1 で行いました。
このうち FSBP の CRITICAL / HIGH コントロールは、本記事の検証時点（2026 年 4 月）で合計 82 件（CRITICAL 27 件、HIGH 55 件）ありました。セキュリティ上の懸念パターンで分類すると以下の通りです。
| パターン | 件数 | 割合 | CRITICAL | HIGH | 概要 |
|---|---|---|---|---|---|
| パブリックアクセスの防止 | 35 | 43% | 21 | 14 | リソースがインターネットに公開されていないことを確認 |
| セキュリティサービスの有効化 | 14 | 17% | 1 | 13 | GuardDuty、Inspector、Config 等の有効化 |
| パッチ / バージョン管理 | 7 | 9% | 0 | 7 | IMDSv2 強制、マイナーバージョン自動アップグレード等 |
| 最小権限 / アクセス制御 | 6 | 7% | 0 | 6 | ワイルドカード権限の禁止、SG の制限等 |
| 認証情報の保護 | 6 | 7% | 4 | 2 | クリアテキスト認証情報の排除、ルートアクセスキー排除 |
| ネットワーク分離 / VPC 設計 | 6 | 7% | 0 | 6 | カスタム VPC 配置、拡張 VPC ルーティング |
| ログ・監視の確保 | 4 | 5% | 0 | 4 | CloudTrail マルチリージョン証跡、ログ設定 |
| 暗号鍵の保護 | 2 | 2% | 1 | 1 | KMS キーの削除防止 |
| その他 | 2 | 2% | 0 | 2 | 上記に含まれないもの |
本記事は以下の理由から、パブリックアクセスの防止（35 件）を検証対象としています。
- 全 82 件の 43% を占める最大のカテゴリであること
- CRITICAL 27 件中 21 件（78%）がこのパターンに集中しており、重大度の観点でも最優先と考えられること
残る 47 件は本記事では扱いません。セキュリティサービスの有効化（GuardDuty / Inspector 等）は組織設計、パッチ管理やネットワーク分離はワークロード固有の運用設計に依存するテーマで、パブリックアクセスの防止とは検証の観点が異なるためです。
なお、AWS は FSBP に随時コントロールを追加・更新しています。本記事の分類は検証時点のスナップショットであり、執筆時点ではすでに数件追加されていました。最新は公式コントロール一覧を参照してください。また、この表は重大度（CRITICAL / HIGH）で分類したものですが、第 4 章では同じ 35 件を「どこまで防げるか」の軸で改めて分類します。
2.2 対象コントロール一覧（35 件）
パブリックアクセスの防止に関するコントロールは、以下の 5 つのカテゴリに分類できました。各コントロールの個別検証ログは infra.jp の Security Hub CSPM ページ に集約しています。
| カテゴリ | 件数 | 内容 |
|---|---|---|
| インターネット到達性 | 15 | リソースがインターネットから到達可能になる |
| S3 パブリックアクセス | 5 | S3 バケット・アクセスポイントが公開される |
| スナップショット公開 | 5 | スナップショットが他アカウントから復元可能になる |
| リソースポリシー系 | 5 | リソースポリシーでパブリックアクセスが許可される |
| サービス独自の公開設定 | 5 | サービス固有の BPA・パブリックアクセス設定 |
| 計 | 35 |
3. 予防手段の優先順位
AWS がパブリックアクセスを防ぐ仕組みは複数の層に散らばっていて、どれでも同じように効くわけではありません。本章ではまず、どの手段から検討すべきかという優先順位を整理します。優先順位は、手段の管理主体（AWS マネージドか自前のカスタムか）を基準に決めました。その上で、同じ手段でも Security Hub CSPM の finding と実害への効き方が分かれることを見ていきました。優先順位と実害への効き方は別の話で、両者を分けて捉えることが本章の要点になります。
3.1 優先順位：AWS マネージド → カスタム → 自動修復
防ぐ手段は、その管理主体で次の順に検討しました。メンテナンスコストが低く、サービス変更に強い手段から使うという基準です。
第 1 優先：AWS マネージドの手段（Control Tower 予防コントロール / 宣言型ポリシー / VPC BPA）
AWS が枠組みを提供する手段です。Control Tower 予防コントロールは事前定義された SCP / RCP / 宣言型ポリシーで、ポリシーの中身を AWS が管理し、サービスの仕様変更にも追従してくれます。宣言型ポリシーはサービスのコントロールプレーンで直接強制されるので、新しい API が追加されても、その API による設定変更を個別に禁止する必要がなく、目的の設定値が保たれます。
なお、宣言型ポリシーは Control Tower の予防コントロールとしてだけでなく、Organizations のポリシーとしても直接設定できます。Control Tower 予防コントロールの宣言型ポリシーは、その実体が Organizations ポリシーです。Control Tower 予防コントロールとして用意されているのであれば、それを使うのが簡単ですが、より柔軟な設定をしたい場合は Organizations ポリシーを直接定義する選択肢もあります。Control Tower 予防コントロールは中身を AWS が管理するため、メンテナンス負荷が小さいですが、Organizations ポリシーを自分で定義する場合は、その内容は自前で管理することになります。
いずれにしても、AWS が枠組みを提供する手段はカスタム SCP より管理負荷が小さく、サービス変更にも強いため、これを最優先で検討します。
第 2 優先：カスタム SCP / RCP（AWS マネージドの手段がないサービスを補完）
AWS マネージドの手段が用意されていないサービスは、AWS が条件キーを提供していれば独自の SCP / RCP で補えます。ただし、自前メンテナンスが必要で、サービスの API 変更や新機能追加に追従漏れのリスクがあります。第 1 優先が存在しないサービスに限って使うこととします。
第 3 優先：Config + 自動修復（第 1・第 2 優先のいずれでも対処できない場合の最終手段）
第 1・第 2 優先のいずれでも対処できないコントロールは、Config マネージドルールで検知し、自動修復ランブックで事後的に修復します。最後に検討する手段です。
自動修復ランブックは自前で用意するほか、AWS 公式のソリューション Automated Security Response on AWS（ASR） を使う選択肢もあります。Security Hub の finding をトリガーに、事前定義の SSM オートメーションランブックで修復するもので、2026 年 6 月時点で FSBP の 63 コントロールに対応しています（対応コントロールの一覧は Playbooks ページ を参照）。ただし用意されているランブックはコントロール単位のため、本記事で自動修復に分類した 4 件のうち ASR が標準対応するのは RDS.1 のみで、残りは自前ランブックでの対応になります。本記事の検証では ASR は使わず、いずれも自前のランブックで修復を確認しています。
3.2 finding への効き方
優先順位とは別に、各手段が Security Hub CSPM の finding と実害にどう効くかで 3 区分に分かれます。
- 予防: 違反状態の発生そのものを防ぐ。リソース側の設定値が変わる（または最初から作らせない）ため、Security Hub CSPM の finding も PASSED になる
- 実害ブロック: 実際のアクセスは遮断するが、リソース側の設定値は変えない。実害は止まるが finding は FAILED のまま残る
- 検知 + 自動修復: 作成自体は止められないため、Config で検知し、自動修復ランブックで事後的に修復する
たとえば同じ宣言型ポリシーでも、設定値を強制する S3 ポリシーや EBS Snapshot BPA は finding ごと PASSED になりますが、通信を遮断する VPC BPA はリソース設定を変えないため FAILED が残ります。Control Tower 予防コントロールも同様で、API を止める SCP 型（Lambda.1 の CT.LAMBDA.PV.2 等）は予防、実行時に遮断する RCP 型（S3.6 の CT.S3.PV.4、KMS.5 の CT.KMS.PV.7、SQS.3 の CT.SQS.PV.1 等）は実害ブロックです。
予防手段を有効化したのに FAILED が残るというのは、実害ブロックでは正常な挙動です。
なお、優先順位は機械的に適用されるものではなく、組織の価値判断で変わってきます。たとえば RDS.2 は、第 1 優先の VPC BPA（実害ブロック）でも防げますし、第 2 優先のカスタム SCP（予防）でも防げます。VPC BPA は AWS マネージドで運用が楽な一方、影響範囲が広く finding は FAILED が残ります。カスタム SCP は自前メンテナンスが必要ですが、finding を PASSED にでき、対象をピンポイントに絞れます。「finding も消したい」「VPC BPA の広い影響を避けたい」組織は、優先順位を一段下げてでもカスタム SCP を選ぶことになります。後述する 35 件の分類は、この優先順位を基本線として各コントロールに当てはめた結果です。
3.3 SCP と RCP の違い
第 1・第 2 優先の中で使われる SCP と RCP は、適用対象が異なります。
- SCP（Service Control Policy）: 組織内アカウントのプリンシパル（IAM ユーザー / ロール）が実行する API を制限する。AWS 公式も「組織のメンバーアカウント内の IAM プリンシパルの権限を制限するときに使う」と明記しており、評価されるのは組織内プリンシパルのリクエストに限られる。組織外プリンシパルや認証情報を持たない匿名（パブリック）リクエストには SCP の評価がそもそも及ばない
- RCP（Resource Control Policy）: 組織内アカウントのリソースに対する API を制限する。リソース側でアクセスを評価するため呼び出し元プリンシパルの所属を問わず適用され、
aws:PrincipalOrgID（リクエスト元が自組織か）やaws:PrincipalIsAWSService（AWS サービスからの呼び出しか）といった条件で、組織外プリンシパルや匿名リクエストを拒否できる
この評価対象の違いが、コントロールごとに「予防になるか実害ブロックにとどまるか」を分けます。SCP は「リソースをパブリック化する操作」（バケットポリシーを Principal: "*" に書き換える、RDS を PubliclyAccessible: true で作る等）を組織内プリンシパルが行う API ごと止めるので、そもそも違反状態が作られず、finding は PASSED のまま保たれます。一方、SCP は組織外プリンシパルや匿名リクエストには評価が及ばないため、すでにパブリック化されたリソースへの組織外からのアクセスは止められません。
RCP はこの逆で、リソース側でアクセスを評価するため、組織外プリンシパルや匿名リクエストを実行時に遮断できます。ただしリソースポリシー自体は書き換えないため、リソース設定は違反のまま、つまり finding は FAILED が残ります。これが RCP だけが組織外アクセスを遮断できる理由であり、RCP が前節の「実害ブロック」に分類される理由です。
3.4 既存違反への影響と適用順序
予防手段は、適用時点で既に違反状態のリソースがある場合の挙動が異なります。
- 宣言型ポリシー（設定値強制型）: EBS Snapshot BPA、S3 ポリシー、SSM Block Public Sharing など、アカウント単位の設定値を強制するもの。適用と同時に初期化が完了し、既存違反も解消される
- SCP / 予防コントロール（API ブロック型）: API 操作を Deny するだけで既存リソースの設定は変えない。デフォルトで違反状態のコントロール（例: SSM.7）は、SCP 適用前に手動で初期化が必要。さもないと違反状態のまま固定されてしまう
特に SSM.7 は注意が必要です。デフォルトで BPA が無効なので、先に「BPA 有効化 → SCP 適用」の順を踏まないと、SCP（BPA 設定変更を Deny）が BPA 無効のまま固定してしまいます。一方 RDS.2 は、アカウント発行直後は DB が存在せず finding は PASSED なので、SCP を最初から適用しておけば違反 DB の作成自体がブロックされ、順序問題は起きません。
既存アカウントへ後から適用する場合は、既存違反リソースの修正計画が別途必要になります。
3.5 IaC ガードレールと CloudFormation Hooks について
予防の発想を IaC 側で実現するアプローチもあります。1 つは IaC ツール（CloudFormation、Terraform 等）のテンプレートにパブリック化の余地がない設計を組み込む方法です。これは AWS の機能というより運用設計の話で、組織のスタンス次第なので本記事では扱いません。
もう 1 つは AWS 側の仕組みである CloudFormation Hooks を使った予防です。Control Tower の プロアクティブコントロール（CT.*.PR.*）はこの CloudFormation Hooks を使って実装されていて、CloudFormation スタック作成時にコンプライアンス違反のリソースを事前にブロックできます。ただし、CloudFormation 経由のリソース作成にしか効かない という制約があります。CLI や SDK、Terraform 経由で作成されるリソースは検査対象外で、組織内のリソース作成経路を CloudFormation に統一していない限り抜け道になります。本記事は CLI / SDK / コンソールも含めて経路を問わず効く予防手段（SCP / RCP / 宣言型ポリシー）を中心に扱うため、CloudFormation Hooks ベースのプロアクティブコントロールは対象外としています。
4. 35 件を 4 カテゴリに分類する
第 3 章で見た 2 つの軸——管理主体の優先順位と効き方——を 35 件すべてに当てはめると、各コントロールは 4 つに分類できました。finding ごと消せる「予防」、実害は止まるが finding が残る「実害ブロックのみ」、予防も実害ブロックもできず事後修復に頼る「自動修復のみ」、いずれの技術的強制もできない「運用ルール依存」です。ここで効いた手段が AWS マネージド（第 1 優先）かカスタム SCP（第 2 優先）かは、各カテゴリの中で示します。
| カテゴリ | 件数 | finding | 実害 |
|---|---|---|---|
| 予防 | 10 | PASSED になる | 止まる |
| 実害ブロックのみ | 18 | FAILED 残存 | 止まる |
| 自動修復のみ | 4 | 一時 FAILED → 修復で PASSED | 修復後に止まる |
| 運用ルール依存 | 3 | 組織強制手段なし | 作成時の選択次第 |
4.1 予防（10 件）
finding が PASSED になる、最も望ましい群です。第 3 章の第 1・第 2 優先（AWS マネージドの手段 / カスタム SCP）で、違反状態の発生自体を防げます。
この 10 件には第 1 優先と第 2 優先が混在している点に注意が必要です。AWS マネージドの手段（宣言型ポリシー / 予防コントロール）で守れるのは 5 件（EC2.1 / EC2.182 / S3.2 / S3.3 / Lambda.1）で、残る 5 件（SSM.7 / SSM.4 / EMR.2 / MSK.4 / EKS.1）は AWS マネージドの予防コントロールが存在せず、自前メンテナンスが必要なカスタム SCP に頼る必要があります。予防という結果は同じでも、メンテナンス負荷とサービス変更への追従リスクは第 1 優先と第 2 優先で異なります。
第 1 優先（AWS マネージドの手段 — 宣言型ポリシー / Control Tower 予防コントロール）:
| ID | 重大度 | 予防手段 |
|---|---|---|
| EC2.1 | CRITICAL | EBS Snapshot BPA（宣言型）/ CT.EC2.PV.7（宣言型） |
| EC2.182 | HIGH | EBS Snapshot BPA（宣言型） |
| S3.2 | CRITICAL | S3 ポリシー（宣言型） |
| S3.3 | CRITICAL | S3 ポリシー（宣言型） |
| Lambda.1 | CRITICAL | CT.LAMBDA.PV.2（SCP 型の予防コントロール） |
第 2 優先（カスタム SCP — AWS マネージドの予防コントロールが存在しないサービス）:
| ID | 重大度 | 予防手段 |
|---|---|---|
| SSM.7 | CRITICAL | カスタム SCP（SSM BPA 強制） |
| SSM.4 | CRITICAL | SSM.7 連動（SSM BPA 有効化で予防） |
| EMR.2 | CRITICAL | カスタム SCP（EMR BPA 強制） |
| MSK.4 | CRITICAL | カスタム SCP（MSK パブリックアクセスブロック） |
| EKS.1 | HIGH | カスタム SCP（eks:endpointPublicAccess、2026/4 追加） |
S3.2 / S3.3 は Control Tower の予防コントロール CT.S3.PV.4（RCP）でも実害ブロックできますが、S3 ポリシー（宣言型）で finding ごと PASSED にできるため、予防に分類します。SSM.4 は SSM.7 の予防（SSM BPA 有効化）が成立すれば、ドキュメントをパブリック共有する API 自体が拒否されるため、連動して防げます（このため第 2 優先のカスタム SCP に依存する側に置いています）。
EC2.1 の予防手段には注意が必要です。同じ Control Tower 予防コントロールでも、CT.EC2.PV.3（新規のパブリック共有 API を Deny する SCP 型）では既存の FAILED が残ってしまいます。PASSED になるのは EBS Snapshot BPA を強制する宣言型の CT.EC2.PV.7 です。設定値そのものを強制する宣言型なので、既存スナップショットも含めて finding が PASSED に変わります。
4.2 実害ブロックのみ（18 件）
実際のアクセスは遮断されるが、リソース側の設定値は変わらないため finding は FAILED が残る群です。VPC BPA（ネットワーク層遮断）、RCP（実行時遮断）、S3 ポリシー（アカウントレベル BPA 強制）に頼るコントロールが該当します。いずれも第 3 章でいう「実害ブロック」の効き方をする手段で、その多くは AWS マネージド（第 1 優先）で実現できます。FAILED が残るのは、設定値を変えず実害だけを止めるタイプだからです。CSPM の判定（FAILED）と実態（アクセス遮断済み）に乖離が生じることになります。
この乖離は運用上の注意点になります。実害ブロックを使うと、「FAILED があれば未対応、なければ対応済み」という単純な見方が通用しなくなります。FAILED の中に「実害は止まっているが finding だけ残っているもの」と「本当に手つかずのもの」が混在するからです。
この2つを区別するために、Security Hub には finding の抑制（ワークフローステータスを SUPPRESSED にする）やコントロールの無効化といった手段があります。ただしそれぞれ運用設計上の考慮が必要なため、本記事では詳細は割愛します。
なお、VPC BPA の対象となるコントロールのうち、データストア系かつ CRITICAL に該当するサービスは、情報漏洩時の影響が甚大であると考えられるため、VPC BPA とは別に finding を PASSED にできる個別手段が存在するかを別途検証し、RDS.2 はカスタム SCP、Redshift.1 は Config 自動修復が利用可能であることを確認しました。VPC BPA の影響範囲が組織として許容できない場合や、finding まで消したい場合の選択肢となりますが、本記事ではこれらをまとめて VPC BPA による実害ブロックとして扱います（個別手段の検証詳細は infra.jp を参照）。
VPC BPA で実害ブロック（13 件）
VPC BPA は IGW / EIGW 経由のインターネット通信を組織全体で遮断する宣言型ポリシーです（Control Tower では CT.EC2.PV.8 として提供される）。リソース側の設定値（パブリック IP の付与、PubliclyAccessible フラグ、SG ルール等）は変えないため finding は残るものの、実際のインターネット到達はブロックされます。
| ID | 重大度 | 評価対象 |
|---|---|---|
| EC2.9 | HIGH | パブリック IP の有無 |
| EC2.25 | HIGH | 起動テンプレートの設定値 |
| Autoscaling.5 | HIGH | 起動設定の設定値 |
| ECS.2 | HIGH | サービスの assignPublicIp |
| ECS.16 | HIGH | TaskSet の assignPublicIp |
| EMR.1 | HIGH | プライマリノードのパブリック IP |
| RDS.46 | HIGH | サブネットのルートテーブル |
| RDS.2 | CRITICAL | PubliclyAccessible フラグ（カスタム SCP で予防も可） |
| DMS.1 | CRITICAL | PubliclyAccessible フラグ |
| RedshiftServerless.3 | HIGH | PubliclyAccessible フラグ |
| EC2.19 | CRITICAL | SG のインバウンドルール |
| Redshift.15 | HIGH | SG のインバウンドルール |
| Redshift.1 | CRITICAL | PubliclyAccessible フラグ（Config 自動修復で finding 復旧も可） |
なお VPC BPA の実通信ブロックは EC2 を代表として検証しており、RDS / DMS / ECS / EMR / Redshift など個別サービスでの実通信影響は未検証です。いずれも IGW / EIGW 経由の通信を遮断するしくみは共通のため、同様にブロックされると見込んでいます。また、実通信の確認は NAT Gateway 経由で行っており、Egress-only IGW 経由のブロックは公式ドキュメントの記述に基づきます（実検証は対象外）。
RCP で実害ブロック（3 件）
RCP は組織外からの実アクセスを実行時に遮断するものの、リソースポリシーは書き換えないため finding は残ります。
| ID | 重大度 | 予防手段 |
|---|---|---|
| S3.6 | HIGH | CT.S3.PV.4（RCP） |
| KMS.5 | CRITICAL | CT.KMS.PV.7（RCP） |
| SQS.3 | CRITICAL | CT.SQS.PV.1（RCP） |
S3 ポリシー（宣言型）で実害ブロック（2 件）
S3 ポリシーはアカウントレベル BPA を強制するものの、バケットレベル BPA（S3.8）/ アクセスポイント BPA（S3.19）の設定値は変えません。実害（パブリック公開）はアカウントレベル BPA が最も制限的として優先されるため遮断されますが、finding は FAILED が残ります。
| ID | 重大度 | 予防手段 |
|---|---|---|
| S3.8 | HIGH | S3 ポリシー（宣言型） |
| S3.19 | CRITICAL | S3 ポリシー（宣言型） |
4.3 自動修復のみ（4 件）
第 1・第 2 優先の手段では予防できず、VPC BPA / RCP による実害ブロックも効かない群です。AWS マネージドの予防手段がなく、API を止めるための条件キーも提供されていないため、カスタム SCP でも塞げません。実害ブロックも効かないため、Config マネージドルールで検知し、自動修復ランブックで事後的に修復するしかありません。
| ID | 重大度 | 理由 |
|---|---|---|
| RDS.1 | CRITICAL | スナップショット restore 属性の条件キーが未提供 |
| DocumentDB.3 | CRITICAL | 同上（RDS API を共有） |
| Neptune.3 | CRITICAL | 同上（Neptune は RDS API を共有） |
| SNS.4 | CRITICAL |
SetTopicAttributes / AddPermission の Policy 値の条件キーが未提供 |
なお、今回検証対象としたのは、予防（SCP / 宣言型ポリシー / 予防コントロール / カスタム SCP）が不可能と確定したコントロールで、内訳は自動修復で finding を PASSED に戻せる 4 件（RDS.1 / DocumentDB.3 / Neptune.3 / SNS.4）と、自動修復すら不可能な 3 件（ES.2 / Opensearch.2 / SageMaker.1）に分かれました。後者の 3 件はパブリックアクセス設定を作成後に変更できず、リソースの再作成が必須のため、Config で検知はできても自動修復は実質的に成立しません。これらは VPC BPA でも実害を止められないため、本記事では運用ルール依存（4.4）に分類しています。
4.4 運用ルール依存（3 件）
予防・実害ブロック・自動修復のいずれの技術的な組織強制手段もない群です。作成時に正しいアクセス方式を選ぶ運用に依存するしかありません。
| ID | 重大度 | 理由 |
|---|---|---|
| ES.2 | CRITICAL | パブリックエンドポイント方式が AWS 管理ネットワークに配置され、ユーザー VPC の IGW を経由しないため VPC BPA で遮断不可 |
| Opensearch.2 | CRITICAL | 同上 |
| SageMaker.1 | HIGH | Direct Internet Access が SageMaker 管理 VPC 経由で提供され、ユーザー VPC の IGW を経由しないため VPC BPA で遮断不可 |
ES / OpenSearch は作成時に VPC アクセス方式を、SageMaker は DirectInternetAccess=Disabled を選ぶ運用に頼ることになります。いずれも作成後の API による変更ができないため、初期作成時の選択が唯一の対処手段になります。
5. 機能横断マトリクス
35 件を、コントロール × 効き方の表に展開します。第 4 章のカテゴリを finding 結果とともに一覧化したものです。各コントロール ID は infra.jp の個別検証ページにリンクしています。
凡例:
- finding 結果: PASSED = 予防で finding が消える / FAILED 残存 = 実害は止まるが finding は残る / 修復後 PASSED = 自動修復で復旧する / 強制手段なし = 運用ルール依存
- [予] 予防（finding PASSED）: API 操作の Deny（SCP / 予防コントロール）または設定値を強制する宣言型ポリシー
- [実] 実害ブロック（finding は FAILED 残存）: VPC BPA / RCP / S3 ポリシー（バケット/AP 単位評価分）
- [修] 検知 + 自動修復: Config マネージドルールで検知し自動修復ランブックで復旧
| ID | 重大度 | カテゴリ | finding 結果 | 主たる手段 |
|---|---|---|---|---|
| S3.2 | CRITICAL | 予防 | PASSED | [予] S3 ポリシー（宣言型） |
| S3.3 | CRITICAL | 予防 | PASSED | [予] S3 ポリシー（宣言型） |
| EC2.1 | CRITICAL | 予防 | PASSED | [予] EBS Snapshot BPA / CT.EC2.PV.7 |
| EC2.182 | HIGH | 予防 | PASSED | [予] EBS Snapshot BPA |
| Lambda.1 | CRITICAL | 予防 | PASSED | [予] CT.LAMBDA.PV.2（SCP） |
| SSM.7 | CRITICAL | 予防 | PASSED | [予] カスタム SCP |
| SSM.4 | CRITICAL | 予防 | PASSED | [予] SSM.7 連動 |
| EMR.2 | CRITICAL | 予防 | PASSED | [予] カスタム SCP |
| MSK.4 | CRITICAL | 予防 | PASSED | [予] カスタム SCP |
| EKS.1 | HIGH | 予防 | PASSED | [予] カスタム SCP |
| EC2.9 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| EC2.25 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| Autoscaling.5 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| ECS.2 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| ECS.16 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| EMR.1 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| RDS.46 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| RDS.2 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA（カスタム SCP で予防も可） |
| DMS.1 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| RedshiftServerless.3 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| EC2.19 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| Redshift.15 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA |
| Redshift.1 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] VPC BPA（Config 自動修復で finding 復旧も可） |
| S3.6 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] CT.S3.PV.4（RCP） |
| KMS.5 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] CT.KMS.PV.7（RCP） |
| SQS.3 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] CT.SQS.PV.1（RCP） |
| S3.8 | HIGH | 実害ブロックのみ | FAILED 残存 | [実] S3 ポリシー（宣言型） |
| S3.19 | CRITICAL | 実害ブロックのみ | FAILED 残存 | [実] S3 ポリシー（宣言型） |
| RDS.1 | CRITICAL | 自動修復のみ | 修復後 PASSED | [修] Config 自動修復 |
| DocumentDB.3 | CRITICAL | 自動修復のみ | 修復後 PASSED | [修] Config 自動修復 |
| Neptune.3 | CRITICAL | 自動修復のみ | 修復後 PASSED | [修] Config 自動修復 |
| SNS.4 | CRITICAL | 自動修復のみ | 修復後 PASSED | [修] Config 自動修復 |
| ES.2 | CRITICAL | 運用ルール依存 | 強制手段なし | 作成時に VPC アクセス方式を選択 |
| Opensearch.2 | CRITICAL | 運用ルール依存 | 強制手段なし | 作成時に VPC アクセス方式を選択 |
| SageMaker.1 | HIGH | 運用ルール依存 | 強制手段なし | 作成時に DirectInternetAccess=Disabled |
6. 結論
冒頭の「Critical / High のパブリックアクセス系コントロールは、検出されたら結局修正を依頼するのだから、最初から予防してしまえばいいのではないか」に対する答えを整理します。
結論として、「検出を全部予防に置き換える」は単純には成り立たないことが分かりました。35 件のうち、finding ごと消せる純粋な予防は 10 件にとどまりました。残りは実害ブロック（finding は残る、18 件）・自動修復（合意形成が前提、4 件）・運用ルール（強制手段なし、3 件）を使い分けるしかありません。
ここで重要なのは、それぞれの手段に固有の採用ハードルがあることです。
実害ブロックの中心となる VPC BPA は、IGW / EIGW 経由の通信を組織全体で遮断する強力な仕組みですが、採用には運用設計が必要です。既存環境で IGW 経由の通信を行っているプロダクトを事前に把握しきるのは難しく、インターネット接続が必要な VPC は Exclusion で明示する必要があります。効果はリージョン単位かつアカウント全体に及ぶので、影響範囲も広いです。
自動修復は、予防とは別種のハードルを持ちます。設定したものが勝手に変わるため、導入には組織内で発信し、理解を得るプロセスが必要と考えます。
また、ハードルは技術面だけではありません。予防統制を強めると開発スピードが落ちるという理由で、予防に慎重な組織もあるでしょう。
とはいえ、これまで見てきた多層的なアプローチを採れば、Critical / High パブリックアクセス系のリスクは十分に下げられます。重大度の高いパブリックアクセスを防ぐ投資対効果は高く、多くの組織で検討する価値があると考えます。
7. おわりに
個別の検証ログは infra.jp に蓄積しています。各コントロールの検証手順や finding の挙動を確認したい場合は、自組織で検討する際の根拠資料として活用してください。
本記事はプライベートで実施した検証の整理であり、所属組織を代表する見解ではありません。
また、本記事は 2026 年 4 月時点の検証結果をまとめたものです。AWS のアップデートにより記載内容が古くなる可能性があるため、実際の運用にあたっては最新の公式ドキュメントも併せてご確認ください。