カスタム SCP
AWS Organizations のサービスコントロールポリシー（SCP）のうち、Control Tower の予防コントロールでカバーされていないチェック項目を補完するために独自に作成するポリシーをカスタム SCP と呼ぶ。本セクションでは、Security Hub CSPM のコントロールに対応する予防手段として、各サービスごとのカスタム SCP の実装と検証結果をまとめる。
カスタム SCP で予防できるコントロール
Security Hub CSPM のページで本サイトのスコープとして整理している 35 件（FSBP の CRITICAL / HIGH のうちパブリックアクセス防止に関わるコントロール）のうち、サービス独自の条件キーまたは特定 API の Deny でカスタム SCP による予防が可能なものを以下に整理する。
| コントロール | 該当 API | Deny の方式 | 検証記事 |
|---|---|---|---|
| SSM.7 | ssm:UpdateServiceSetting | API + リソース ARN 単位の Deny（/ssm/documents/console/public-sharing-permission 設定の変更を拒否） | SSM Block Public Sharing |
| EMR.2 | elasticmapreduce:PutBlockPublicAccessConfiguration | API 単位の Deny（BPA 設定変更操作そのものを拒否） | EMR Block Public Access |
| MSK.4 | kafka:UpdateConnectivity | API + 条件キー kafka:publicAccessEnabled で Deny | MSK Public Access |
| RDS.2 | rds:CreateDBInstance / rds:ModifyDBInstance | API + 条件キー rds:PubliclyAccessible で Deny | RDS Publicly Accessible |
| EKS.1 | eks:CreateCluster / eks:UpdateClusterConfig | API + 条件キー eks:endpointPublicAccess で Deny | EKS Public Endpoint |
カスタム SCP で予防できないコントロール
本サイトのスコープ 35 件のうち、対応するサービスの API に必要な条件キーが提供されていないため、カスタム SCP では予防できないコントロールを以下に整理する。これらは Config 検知 + 自動修復で対応する。
| コントロール | 該当 API | カスタム SCP で予防できない理由 |
|---|---|---|
| RDS.1 | rds:ModifyDBSnapshotAttribute | パブリック共有を判定する条件キーが提供されていない |
| DocumentDB.3 | rds:ModifyDBClusterSnapshotAttribute（DocumentDB の IAM アクションは rds: プレフィックスを使用） | パブリック共有を判定する条件キーが提供されていない |
| Neptune.3 | rds:ModifyDBClusterSnapshotAttribute（Neptune の IAM アクションは rds: プレフィックスを使用） | パブリック共有を判定する条件キーが提供されていない |
| SNS.4 | sns:SetTopicAttributes | アクセスポリシー内容を評価する条件キーが提供されていない |
| Redshift.1 | redshift:CreateCluster / redshift:ModifyCluster | パブリックアクセスを制御する条件キーが提供されていない |
| RedshiftServerless.3 | redshift-serverless:UpdateWorkgroup | パブリックアクセスを制御する条件キーが提供されていない |
| ES.2 | es:CreateElasticsearchDomain | VPC アクセスを制御する条件キーが提供されていない |
| Opensearch.2 | opensearch:CreateDomain | VPC アクセスを制御する条件キーが提供されていない |
| DMS.1 | dms:CreateReplicationInstance | パブリックアクセスを制御する条件キーが提供されていない |
これらのコントロールの対応方針は以下の通り:
- インターネット到達性カテゴリ（Redshift.1 / RedshiftServerless.3 / ES.2 / Opensearch.2 / DMS.1）: VPC BPA（宣言型ポリシー） を主軸とし、VPC BPA が組織として採用できない場合のフォールバック策として Config 検知 + 自動修復を採用する
- それ以外（RDS.1 / DocumentDB.3 / Neptune.3 / SNS.4）: Config マネージドルールによる検知と SSM Automation による自動修復が主軸となる