コンテンツにスキップ

サービス独自の公開設定

各サービスが持つ独自のパブリックアクセス制御機能をチェックするコントロール群。アカウントレベルの Block Public Access(以下、BPA と呼ぶ)設定や、サービス固有のリソース公開設定(クラスターのエンドポイント公開、セキュリティグループの ingress、ドキュメントの共有設定など)が対象である。

他カテゴリのコントロールが「リソースポリシー」「サブネット配置」「PubliclyAccessible フラグ」のような共通パターンで分類できるのに対し、本カテゴリはサービスごとに固有の公開制御機構を持つコントロールの集まりである。たとえば SSM ドキュメントは IAM ベースのリソースポリシーを持たず、ssm:ModifyDocumentPermission でアカウント ID のリストを指定して共有する独自の仕組みを持つ(SSM.4)。なお、本記事では SSM の Block Public Sharing も含めて、アカウント単位のパブリック化防止機構を総称して BPA と呼ぶ。

対象コントロール(6 件)

デフォルト保護は API のデフォルト値(CLI でオプションを省略した場合の値)に基づく。マネジメントコンソールではより安全な値がプリセットされている場合がある。6 件のうち、デフォルトで保護されているのは SSM.4 / EMR.2 / MSK.4 / Redshift.15 の 4 件で、SSM.7 / EKS.1 の 2 件はデフォルトで未保護である。

コントロール重大度タイトルデフォルト保護IAM Access Analyzer記事
SSM.4CRITICALSSM ドキュメントがパブリックでないこと保護済み: 本コントロールは個別の SSM ドキュメントがパブリック共有されているかをチェックする。SSM ドキュメントは IAM ベースのリソースポリシーを持たず、ssm:ModifyDocumentPermission でアカウント ID のリスト(個別 ID または all)を指定して共有する。作成時のデフォルトは非共有のため、--account-ids all を明示的に実行しない限り FAILED にならない対象外検証済み
SSM.7CRITICALSSM ドキュメントのパブリック共有ブロック設定が有効であること未保護: 本コントロールはアカウントレベルの BPA(SSM ドキュメントのパブリック共有を禁止する設定)が有効になっているかをチェックする。BPA はデフォルトで無効のため FAILED。明示的に BPA を有効化しない限り FAILED のまま対象外検証済み
EMR.2CRITICALEMR の BPA 設定が有効であること保護済み: 本コントロールはアカウントレベルの BPA(パブリックな ingress ルールを持つセキュリティグループに関連付けられた EMR クラスターの起動をブロックする機能)が有効になっているかをチェックする。新規アカウントの BPA はデフォルトで有効(例外ポート 22 のみ許可)。明示的に BPA を無効化しない限り PASSED対象外検証済み
MSK.4CRITICALMSK クラスターのパブリックアクセスが無効であること保護済み: クラスター作成時のデフォルトはパブリックアクセス不可。パブリック化には「SASL/IAM 等の強認証の有効化」「パブリックサブネット配置」「公開設定の明示的な変更」の 3 ステップが必要で、意図性が強く要求される対象外検証済み
EKS.1HIGHEKS クラスターエンドポイントがパブリックにアクセス可能でないこと未保護: クラスター作成時の API デフォルトは endpointPublicAccess=truepublicAccessCidrs=["0.0.0.0/0"] のため、CLI でオプションを省略するとパブリック公開状態のクラスターが作成される対象外検証済み
Redshift.15HIGHRedshift セキュリティグループがクラスターポートへのアクセスを制限していること保護済み: 本コントロールは「Redshift クラスターに関連付けられたセキュリティグループが 0.0.0.0/0 または ::/0 から Redshift クラスターポート(デフォルト 5439)への ingress を許可している」場合に FAILED となる(AWS 公式ドキュメント)。VPC のデフォルトセキュリティグループは 0.0.0.0/0 / ::/0 からの ingress を持たない(同一セキュリティグループ内通信のルールのみ)ため、Redshift クラスター作成時にデフォルトセキュリティグループを使用する限り PASSED対象外検証済み

コントロールの性質による分類

6 件はチェック対象の階層によって 2 つに分類できる。

Type 1: アカウントレベル BPA の有効性チェック(2 件)

アカウント単位の BPA 設定が有効になっているかを評価する。BPA 自体が「リソースをパブリック化させない」予防機構として動作するため、これらのコントロールは予防機構そのものが稼働しているかをチェックする位置付けとなる(コントロール自体は検出だが、検出対象が予防機構の有効性である)。

該当コントロール: SSM.7, EMR.2

Type 2: リソース単位の公開設定チェック(4 件)

個別リソースのパブリックアクセス可否を評価する。リソース作成・更新時のパラメータ、ドキュメントの共有設定、関連付けられたセキュリティグループの内容を直接チェックする。

該当コントロール: SSM.4, MSK.4, EKS.1, Redshift.15

関連コントロールとの対応関係

本カテゴリの Type 1 コントロールは、他カテゴリの個別リソース系コントロールとペアで多層防御を構成する。アカウント単位 BPA が有効ならば、リソース単位の違反操作(個別リソースのパブリック化)を API レベルで拒否でき、新規違反の発生を防げる。

アカウント単位 BPA(本カテゴリ)リソース単位アカウント BPA のデフォルトリソース単位への保護効果
SSM.7SSM.4無効(SSM.7 は FAILED)BPA が無効のため、SSM.4 違反(個別ドキュメントのパブリック共有)を API レベルでは防げず、個別ドキュメントの公開操作に注意する必要がある
EMR.2EMR.1有効(EMR.2 は PASSED)BPA が有効のため、EMR.1 違反(パブリックなセキュリティグループ付きクラスターの起動)は AWS によって API レベルで拒否される

いずれのケースでも、アカウント単位 BPA を有効に保つことが、リソース単位の違反を構造的に減らす鍵となる。SSM.7 はデフォルトでは無効なため、アカウントベースラインで明示的に有効化する運用が必要となる。

なお、Redshift.15 は EC2.19(高リスクポートへのセキュリティグループの無制限アクセスを禁止するコントロール)と一見類似するが、対象ポートが異なる。EC2.19 が使用する Config ルール vpc-sg-restricted-common-ports の対象ポートは 22 / 3389 等 24 ポートに固定されており、Redshift クラスターポートの 5439 は含まれない(参照: restricted-common-ports - AWS ConfigSecurity Hub CSPM EC2 controls - EC2.19)。Redshift クラスターポートのパブリック公開は Redshift.15 が独自にカバーする関係となっている。

予防手段との対応

6 件のコントロールはいずれも、Control Tower の予防コントロールおよび Organizations の宣言型ポリシーに直接対応するものが用意されていない(本記事執筆時点)。Type 1(BPA 系)と Type 2(リソース単位)でアプローチが大きく異なるため、それぞれに分けて整理する。

Type 1(SSM.7 / EMR.2): BPA 自体が予防手段、その維持にカスタム SCP が必要

これらは BPA 設定が有効であること自体が予防レイヤーである。BPA が有効ならば、配下のリソースの違反操作(SSM ドキュメントのパブリック共有、EMR クラスターのパブリックセキュリティグループ起動など)が API レベルで拒否される。

ただし、運用上は以下の 2 点に対処する必要がある:

  • BPA の初期有効化: デフォルトで BPA が無効のコントロール(SSM.7)については、アカウント作成時のベースライン整備で明示的に有効化する必要がある
  • BPA 無効化操作の防止: 一度有効化した BPA を運用中に誤って無効化されないようにする予防が必要。本記事執筆時点では Control Tower や宣言型ポリシーに該当機能がないため、カスタム SCP による無効化 API の拒否が必要となる(カスタム SCP の具体的な実装は今後の検証論点)

Type 2(SSM.4 / MSK.4 / EKS.1 / Redshift.15): リソース作成・更新時の予防が必要

これらは個別リソースの公開設定をチェックするため、リソース作成・更新 API の呼び出しを違反パラメータでブロックする必要がある。Control Tower の予防コントロールおよび宣言型ポリシーに該当機能が存在しないため、以下のいずれかの対応が必要となる:

  • カスタム SCP: 該当 API 呼び出しを違反パラメータでブロックする(リアクティブ予防)。ただし、SCP の Condition キーが該当パラメータをサポートしている必要があり、サポートされない場合は API 自体を拒否するしかなく、サービスが使えなくなる
  • プロアクティブ予防コントロール: CloudFormation Hook 等を用いてリソース作成前にパラメータを検証してブロックする方式

ただし SSM.4 は例外的な性質を持つ。SSM ドキュメントはリソースポリシーを持たず、ssm:ModifyDocumentPermission でパブリック化(--account-ids-to-add 'all')するため、アカウント単位の SSM Block Public Sharing(Type 1 の SSM.7 が評価する設定)を有効化すれば、パブリック化操作が API レベルで拒否され、SSM.4 違反を予防できる。ただしこれは「パブリック化のみ」のブロックであり、特定の外部アカウント ID へのクロスアカウント共有は防げない(クロスアカウント共有は IAM Access Analyzer の対象外でもあり、検出も予防も別途カスタム SCP が必要)。

特に EKS.1 のようにデフォルトで未保護かつ作成時のパラメータが問題となるケースでは、SCP Condition がサポートされない場合は検出コントロール(Security Hub finding)でのカバーが必要となる。なお、別の解決策としてプロアクティブ予防コントロール(CloudFormation Hook 等)も選択肢として考えられるが、IaC によるデプロイを前提とする方式のため、本記事では対象外としている。

影響まとめ

コントロール対応する予防手段主な検討事項
SSM.7専用なし(アカウント作成時の BPA 有効化 + 維持にカスタム SCP)デフォルトで BPA 無効のため、アカウントベースライン整備での初期有効化が必要
EMR.2専用なし(BPA 維持にカスタム SCP)デフォルトで BPA 有効のため、無効化操作の防止が中心
SSM.4SSM Block Public Sharing(SSM.7 有効化)でパブリック化を予防デフォルトで保護されている(非共有)。SSM.7 有効化でパブリック化を API レベルで防げるが、特定アカウントへのクロスアカウント共有は防げない
MSK.4専用なし(カスタムSCP または プロアクティブ予防)デフォルトで保護されているが、公開設定への変更を防ぐ手段が別途必要
EKS.1専用なし(カスタムSCP または プロアクティブ予防)デフォルトで未保護のため、新規クラスター作成時のパラメータ制御が必要。SCP の Condition 対応がない場合はプロアクティブ予防が必要
Redshift.15専用なし(カスタムSCP または プロアクティブ予防)デフォルトで保護されているが、セキュリティグループへの公開的 ingress 追加を防ぐ手段が別途必要

補足: SSM.7 の設定名による混乱

SSM.7 が参照するアカウントレベルの設定は、設定値の意味が直感的でない:

  • 設定値が「パブリック共有を許可する状態」(デフォルト) → SSM.7 は FAILED
  • 設定値が「パブリック共有をブロックする状態」 → SSM.7 は PASSED

設定値の表現と「ブロックが有効か」の関係が逆になっており、設定変更時に意図と逆の操作をしてしまいやすい。詳細は SSM.7 の記事を参照。

また、Config ルール名は ssm-automation-block-public-sharing と “automation” を含むが、実際は SSM ドキュメント全般(Automation だけでなく Command、Session、Package など)が評価対象である。これは実装の名残と考えられる。