はじめに
Security Hub CSPM の Critical / High パブリックアクセス系コントロール 35 件について、それぞれを AWS の機能でどこまで防げるかを実 AWS アカウントで検証した。
結論として、finding を PASSED にできる「予防」は 10 件にとどまった。残りは、実害は止まるが finding は残る「実害ブロック」が 18 件、検知して自動で修復する「自動修復」が 4 件、強制手段がない「運用ルール依存」が 3 件である。「防ぐ」と一口に言っても効果はこれだけ分かれる。本記事はその検証結果と、採用判断の論点を整理したものである。
1. 背景
Security Hub を運用していると、過剰な予防統制を敷かない方針の組織であっても、「Critical や High のパブリックアクセス系コントロールは、検出されたら結局修正を依頼するのだから、最初から予防してしまえばいいのではないか」という問いが立つことがある。
確かに、原則修正を求めるなら、最初から API レベルで止めた方が運用負荷は低い。そこで、予防手段の検討を行った。当初は Control Tower の予防機能で一通り塞げるだろうと踏んでいたが、調べ始めると、Control Tower の予防機能ではカバーできない Security Hub コントロールがいくつもあることが分かってきた。AWS のパブリックアクセスを止める仕組みは Control Tower 予防コントロール以外にも、カスタム SCP、宣言型ポリシー、サービス固有の BPA 機能など複数の層に散らばっており、どの手段がどのコントロールを塞げるかはサービスごとに違う。これらの関係を一度、体系的に整理しておきたかった。
業務では限られた時間で優先度を付けたため、現組織の運用方針に合わない手段までは検証が回らなかった。VPC BPA や Config 自動修復などがそれにあたる。そこで、業務で扱えなかった範囲も含めて「思いつく予防手段を全部試したらどこまで塞げるのか」をプライベートで検証し、コントロール単位で体系的に整理した。本記事はその結果である。
なお、そもそも「予防に倒すべきか、検出のまま運用するか」自体が組織のリスク許容度や運用体制によって変わる判断である。本記事は「パブリックアクセス系については、予防できるものは予防したい」という立場を取るが、その前提でどこまで技術的に防げるかを検証するのが目的で、予防すべきか否かの判断そのものには踏み込まない。判断材料として「予防・実害ブロック・自動修復のどれがどこまで効くか」を示すので、各組織のスタンスに応じて取捨選択してほしい。
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 件） を検証対象とする。理由は 2 つある。全 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 の finding と実害への効き方が分かれることを見ていく。優先順位（どれから使うか）と効き方（どこまで止まるか）は別の話で、両者を分けて捉えることが本章の要点になる。
3.1 優先順位：AWS マネージド → カスタム → 自動修復
防ぐ手段は、その管理主体で次の順に検討する。メンテナンスコストが低く、サービス変更に強い手段から使うという基準だ。
第 1 優先：AWS マネージドの手段（Control Tower 予防コントロール / 宣言型ポリシー / VPC BPA）
AWS が枠組みを提供する手段。Control Tower 予防コントロールは事前定義された SCP / RCP / 宣言型ポリシーで、ポリシーの中身を AWS が管理し、サービスの仕様変更にも追従してくれる。宣言型ポリシーはサービスのコントロールプレーンで直接強制されるため、新しい API が追加されても、その API による設定変更を個別に禁止する必要がなく、目的の設定値が保たれる。
なお、宣言型ポリシーは Control Tower の予防コントロールとしてだけでなく、Organizations のポリシーとしても直接設定できる。Control Tower 予防コントロールの宣言型ポリシーは、その実体が Organizations ポリシーである。予防コントロールとして用意されているものはそれを使うのが簡単だが、より柔軟な設定をしたい場合は Organizations ポリシーを直接定義する選択肢もある。Control Tower 予防コントロールは中身を AWS が管理するためメンテナンス負荷が小さいが、Organizations ポリシーを自分で定義する場合は、その内容は自前で管理することになる。
いずれにせよ、AWS が枠組みを提供する手段はカスタム SCP より管理負荷が小さく、サービス変更にも強いため、これを最優先で検討する。
第 2 優先：カスタム SCP / RCP（AWS マネージドの手段がないサービスを補完）
AWS マネージドの手段が用意されていないサービスは、AWS が条件キーを提供していれば独自の SCP / RCP で補える。ただし自前メンテナンスが必要で、サービスの API 変更や新機能追加に追従漏れのリスクがある。第 1 優先が存在しないサービスに限って使う。
第 3 優先：Config + 自動修復（第 1・第 2 優先のいずれでも対処できないものの受け皿）
第 1・第 2 優先のいずれでも対処できないコントロールは、Config マネージドルールで検知し、自動修復ランブックで事後的に修復する。最後に検討する手段だ。
この優先順位はあくまで「どの手段から検討するか」の順序であって、各手段がどこまで防げるか（finding を消せるか、実害だけ止まるか）とは別の話だ。その効き方の違いは次節で扱う。
3.2 同じ手段でも finding への効き方は分かれる
優先順位とは別に、各手段が Security Hub の finding と実害にどう作用するかで、効き方は 3 つに分かれる。同じ「防ぐ」でも結果は異なる。
- 予防: 違反状態の発生そのものを防ぐ。リソース側の設定値が変わる（または最初から作らせない）ため、Security Hub の finding も PASSED になる
- 実害ブロック: 実際のアクセスは遮断するが、リソース側の設定値は変えない。実害は止まるが finding は FAILED のまま残る
- 検知 + 自動修復: 作成自体は止められないため、Config で検知し、自動修復ランブックで事後的に修復する
重要なのは、この効き方の 3 区分は優先順位ではないことだ。前節の優先順位は「AWS マネージドか自前か」という管理主体で決まり、効き方は「finding と実害のどちらをどこまで止めるか」という別の軸で決まる。だから、優先順位が同じ第 1 優先（AWS マネージド）の中にも、予防になるものと実害ブロックに留まるものが混在する。たとえば宣言型ポリシーでも、設定値そのものを強制する S3 ポリシーや EBS Snapshot BPA は予防（PASSED）になるが、ネットワーク層で通信を遮断する VPC BPA はリソース設定を変えないため実害ブロックに留まる。Control Tower 予防コントロールでも、SCP 型で API を止めるもの（Lambda.1 の CT.LAMBDA.PV.2 等）は予防になり、RCP 型で実行時に遮断するもの（S3.6 / KMS.5 / SQS.3 の CT.S3.PV.4 等）は実害ブロックに留まる。
「予防手段を有効化したのに FAILED が残る」というのは、実害ブロックでは正常な挙動だ。finding を消すことと実害を止めることは別の目標であり、この区別を念頭に置くと次章の分類が理解しやすくなる。
なお、優先順位は機械的に適用されるものではなく、組織の価値判断で前後しうる。たとえば 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 を制限する。呼び出し元プリンシパルの所属を問わず適用されるため、組織外プリンシパルや匿名（パブリック）リクエストを拒否できる
ここで重要なのは、SCP は finding が FAILED になる設定操作そのものを防げるが、RCP は防げないという非対称性だ。SCP は「リソースをパブリック化する操作」（バケットポリシーを Principal: "*" に書き換える、RDS を PubliclyAccessible: true で作る等）を組織内プリンシパルが行う API ごと止めるため、そもそも違反状態が作られず、結果として finding は PASSED のまま保たれる。一方 RCP はリソースポリシーを書き換えず、組織外からの実アクセスを実行時に遮断するだけなので、リソース設定は違反のまま finding は FAILED が残る。RCP は前節の「実害ブロック」に分類される。なお、SCP も既存の違反リソースを PASSED に変えるわけではなく、新たに違反を作らせないことで PASSED を保つ（既存違反への扱いは次節で述べる）。
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 の作成自体がブロックされ、順序問題は起きない。
既存アカウントへ後から適用する場合は、既存違反リソースの修正計画が別途必要になる。この既存環境への適用ハードルは第 6.3 章で扱う。
3.5 IaC ガードレールと CloudFormation Hooks は本記事の対象外
予防の発想を IaC 側で実現するアプローチもある。1 つは IaC ツール（CloudFormation、Service Catalog、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 マネージドで守れる」とは限らない。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 は 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 にならない。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）と実態（アクセス遮断済み）に乖離が生じる。
なお、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 値の条件キーが未提供 |
これら 4 件は、いずれも infra.jp の自動修復シリーズで検証済みである。条件キーが提供されておらず、カスタム SCP では予防できない。加えて対応する実害ブロックも存在しない。そのため、検知 + 自動修復が現実的な選択肢として残った。
なお、今回検証対象としたのは、予防（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 結果とともに一覧化したものである。
凡例:
- 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 で明示する必要がある。リージョン単位かつアカウント全体に及ぶため、影響範囲も広い。VPC BPA を見送る選択肢もあり、CRITICAL のデータストア系については個別手段（RDS.2 はカスタム SCP、Redshift.1 は Config 自動修復）に切り替える判断ができる（詳細な検証は infra.jp を参照）。HIGH のコントロールについては個別の代替手段は本記事では扱っていない。
自動修復は、予防とは別種のハードルを持つ。「設定したものが勝手に変わる」体験は、予防統制で「設定そのものができない」体験とは別物だ。導入には組織内で「こういう自動修復を仕掛けている」と十分発信し、理解を得るプロセスが要る。このコミュニケーション設計が整っていないうちは、自動修復は慎重に扱う方が安全だ。
とはいえ、こうした採用ハードルは「予防に倒す」という方針そのものを否定するものではない。AWS マネージドの手段が使えるものを優先し、finding ごと消せるものは予防で塞ぐ。finding は消せなくても実害をブロックできるものは実害ブロックで止め、それも効かないものは自動修復で戻す——この多層的なアプローチを採れば、Critical / High パブリックアクセス系のリスクは十分に下げられる。当初の問いが想定したより話は複雑だったが、「重大度の高いパブリックアクセスを防ぐ投資対効果は高く、多くの組織で検討する価値がある」という基本線は変わらない。重要なのは、各コントロールがどのカテゴリに属し、finding と実害のどちらをどこまで止められるのかを正確に把握した上で、組織のスタンスに応じて手段を選ぶことだ。
7. おわりに
Control Tower 予防コントロール、宣言型ポリシー、VPC BPA、EBS Snapshot BPA、S3 BPA、カスタム SCP——選択肢は揃いつつある。しかし「組織がそれらを採用できるか」「既存環境に適用したときに何が影響を受けるか」を見極める運用設計は、各組織で個別に検討するしかない。本記事がその判断材料になれば幸いだ。
個別の検証ログは infra.jp に蓄積している。各コントロールの検証手順や finding の挙動を確認したい場合は、自組織で検討する際の根拠資料として活用してほしい。
本記事はプライベートで実施した検証の整理であり、所属組織を代表する見解ではありません。
また、本記事は 2026 年 4 月時点の検証結果をまとめたものです。AWS のアップデートにより記載内容が古くなる可能性があるため、実際の運用にあたっては最新の公式ドキュメントも併せてご確認ください。