新しいAWSリージョンを使い始める初期のSecurity Hub CSPM検出結果に対応したい

こんにちは。コーポレート本部 サイバーセキュリティ推進部の耿です。
本記事は電通総研 Advent Calendar 2025 4日目の記事です。

AWSではSecurity Hub CSPMのセキュリティ基準を有効にすると、何もリソースを作成していなくても非準拠の検出結果が複数発生します。この記事では新しいリージョンを使い始める初期に、どのような設定を行うとSecurity Hub CSPMの検出結果になるべく対応できるかをまとめます。対象とするセキュリティ標準は一般的によく使われるAWS Foundational Security Best Practices（以下「FSBP基準」）です。

初期のSecurity Hub CSPMの検出結果に対応する理由

新しいAWSアカウント・リージョンが使えるようになるといきなりシステム開発を始めたくなりますが、その前にまずはConfigとSecurity Hub CSPMのFSBP基準を有効にし、検出結果に対応していきましょう。理由は2つあります。

1. 設定が推奨される項目がある
   GuardDutyの有効化など、リージョン単位で設定すべき/しておいた方が良い項目を見逃さないようにしておきたいです。

2. 今後作成するインフラリソースに対する検出結果に気づきやすくする
   何もリソースを作成していない状態でも、FSBP基準は20個前後の非準拠の検出結果を生成します。これをキレイにし、初期のセキュリティスコアを100に近づけると、今後作成するリソースに対する非準拠の検出結果に気づきやすくなります。非準拠の検出結果に気づきやすいと、検出結果の対応が進みやすくなり、結果としてセキュリティリスクが低減され、システム開発に好循環を生み出すことが期待できます。

AWSアカウントレベルですべき設定

新しいAWSアカウントについては、以下の設定をしておきましょう。この記事は以下の対応はされている前提で割愛します。

• CloudTrailのマルチリージョンで有効化（CloudTrail.1）
• S3のアカウントレベルのブロックパブリックアクセスを設定（S3.1）

それでは新しいリージョンでConfigとSecurity Hub CSPMのFSBP基準を有効にしたときに、検出されるセキュリティコントロールと対応の考え方を見ていきましょう。
（組織やAWSアカウントの設定により、非準拠となる項目が異なる場合があります。また、2025/11の執筆時点の情報です。今後Security Hub CSPMのアップデートにより非準拠となるコントロールが増える可能性があります。）

GuardDutyを有効にする

対応推奨度：必須レベル

対応できるコントロール：

• GuardDuty.1 GuardDuty を有効にする必要があります
• GuardDuty.7 GuardDuty EKS ランタイムモニタリングを有効にする必要があります
• GuardDuty.11 GuardDuty Runtime Monitoring を有効にする必要があります
• GuardDuty.12 GuardDuty ECS Runtime Monitoring を有効にする必要があります
• GuardDuty.13 GuardDuty EC2 Runtime Monitoring を有効にする必要があります

AWSアカウントへの脅威を検出するために必須のサービスです。全てのリージョンで必ず有効にしましょう。
GuardDutyには標準機能の他に、任意に有効化・無効化できる保護プランがあります。該当するリソースがある場合は追加で利用料金がかかりますが、許容できる限り利用をお勧めします。現在はGuardDutyを有効にすると、デフォルトでRuntime Monitoring以外の保護プランも同時に有効になります。

GuardDuty標準機能および、Runtime Monitoringも含めた全ての保護プランを有効にするAWS CLIコマンドです：（CloudShellから実行可）

aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES --features '[{"Name" : "RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration": [{"Name" : "ECS_FARGATE_AGENT_MANAGEMENT", "Status" : "ENABLED"}, {"Name" : "EC2_AGENT_MANAGEMENT", "Status" : "ENABLED"}, {"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}]}]'

検出結果をS3やEventBridgeに送信する間隔もデフォルトの6時間から15分に変更しています。

Runtime Monitoringを有効にしない場合のAWS CLIコマンドは以下です：

aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES

EBS のデフォルト暗号化を有効にする

対応推奨度：やった方が良い

対応できるコントロール：

• EC2.7 EBS のデフォルト暗号化を有効にすることをお勧めします

そのリージョンで作成されるEBSボリュームをデフォルトで暗号化することができます。EBSボリュームを使うかどうかはシステムに依存しますが、とりあえず設定だけしておくと良いでしょう。
AWS CLIコマンドは以下です：

aws ec2 enable-ebs-encryption-by-default

EBSスナップショットのパブリック共有をブロックする

（2025/12/8に追加されたコントロールです）

対応推奨度：やった方が良い

対応できるコントロール：

• EC2.182 Amazon EBS Snapshots should not be publicly accessible

リージョンレベルの設定であり、そのリージョンのEBSスナップショットの意図しないパブリック公開を全てブロックできます。 AWS CLIコマンドは以下です：

aws ec2 enable-snapshot-block-public-access --state block-all-sharing

SSM Automationのログ記録を有効にする

対応推奨度：やった方が良い

対応できるコントロール：

• SSM.6 SSM Automation では CloudWatch ログ記録が有効になっている必要があります

SSM Automationを利用するかどうかはシステムに依存しますが、とりあえず設定だけしておくと良いでしょう。
AWS CLIコマンドは以下です：

aws ssm update-service-setting --setting-id /ssm/automation/customer-script-log-destination --setting-value CloudWatch

SSMドキュメントのパブリック共有ブロックを有効にする

対応推奨度：やった方が良い

対応できるコントロール：

• SSM.7 SSM ドキュメントでは、パブリック共有ブロック設定を有効にする必要があります

これもとりあえず設定しておいて損はありません。
AWS CLIコマンドは以下です：

aws ssm update-service-setting --setting-id /ssm/documents/console/public-sharing-permission --setting-value Disable

Inspectorの各種機能を有効にする

対応推奨度：やった方が良い

対応できるコントロール：

• Inspector.1 Amazon Inspector EC2 スキャンを有効にする必要があります
• Inspector.2 Amazon Inspector ECR スキャンを有効にする必要があります
• Inspector.3 Amazon Inspector Lambda コードスキャンを有効にする必要があります
• Inspector.4 Amazon Inspector Lambda 標準スキャンを有効にする必要があります

利用しているソフトウェアパッケージや開発したコード上の脆弱性を検出するサービスです。特にLambda関数については数が多いと利用料金が高くなる可能性があるため、アカウントの使い方に応じて各種機能を利用するか検討してください。
EC2スキャン、ECRスキャン、Lambda標準・コードスキャンを全て有効にするAWS CLIコマンドは以下です：

aws inspector2 enable --resource-types EC2 ECR LAMBDA LAMBDA_CODE

※Lambdaコードスキャンは利用可能なリージョンがまだ少ないため、利用不可のリージョンでは LAMBDA_CODE 以外の機能を有効にします。

Macieを有効にする

対応推奨度：やった方が良い

対応できるコントロール：

• Macie.1 Amazon Macie を有効にする必要があります

S3バケットやS3オブジェクトの数が多いと利用料金が高くなる可能性があるため、アカウントの使い方に応じて利用するか検討してください。
Macieを有効化するAWS CLIコマンドは以下です：

aws macie2 enable-macie

デフォルトVPCを削除する

対応推奨度：やった方が良い

対応できるコントロール：

• EC2.2 VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックまたはアウトバウンドトラフィックを許可しないようにすることをお勧めします
• EC2.6 すべての VPC で VPC フローログ記録を有効にすることをお勧めします
• EC2.10 Amazon EC2 サービス用に作成された VPC エンドポイントを使用するようにAmazon EC2 を設定することをお勧めします
• EC2.15 Amazon EC2 サブネットは、パブリック IP アドレスを自動的に割り当てないことをお勧めします
• EC2.55 VPCs は ECR API のインターフェイスエンドポイントで設定する必要があります
• EC2.56 VPCsは Docker Registry のインターフェイスエンドポイントで設定する必要があります
• EC2.57 VPCsは Systems Manager のインターフェイスエンドポイントで設定する必要があります

デフォルトVPCにまつわる様々なコントロールが非準拠になっているはずです。最近はVPCを使わないシステム構成もよくありますし、必要になったらVPCを作成すれば良いので、各リージョンのデフォルトVPCは削除しておくことをお勧めします。そうすることでこれらの非準拠の検出結果は全て消えてなくなります。

CLIでVPCを削除するにはIGWの削除、サブネットの削除と段階を踏んで行う必要があります。（https://dev.classmethod.jp/articles/delete-default-vpcs-by-cloudshell/ を参考にさせていただきました）AWS CLIコマンドは以下です：

aws ec2 describe-vpcs --output text --query "Vpcs[?IsDefault].[VpcId]"
  | while read vpc; do
    aws ec2 describe-internet-gateways --output text --filters Name=attachment.vpc-id,Values=${vpc} \
      --query "InternetGateways[].[InternetGatewayId]" \
    | while read igw; do
      echo "# deleting igw: ${igw} in ${vpc}"
      aws ec2 detach-internet-gateway --internet-gateway-id ${igw} --vpc-id ${vpc}
      aws ec2 delete-internet-gateway --internet-gateway-id ${igw}
  done
   
  aws ec2 describe-subnets --output text --filters Name=vpc-id,Values=${vpc} \
    --query "Subnets[].[SubnetId]" \
  | while read subnet; do
    echo "# deleting subnet: ${subnet} in ${vpc}"
    aws ec2 delete-subnet --subnet-id ${subnet}
  done
   
  echo "# deleting vpc: ${vpc}"
  aws ec2 delete-vpc --vpc-id ${vpc}  
done

VPCブロックパブリックアクセスを設定する

対応推奨度：使い方による

対応できるコントロール：

• EC2.172 EC2 VPC ブロックパブリックアクセス設定はインターネットゲートウェイトラフィックをブロックする必要があります

VPCブロックパブリックアクセスはややこしい機能です。設定する場合は仕組みをよく理解したうえで設定しましょう（このドキュメントなどを参考に）。
VPC利用の有無、利用有の場合の通信方向に応じて設定の可否を判断してください。

双方向モードのブロックを設定する場合のAWS CLIコマンドは以下です：

aws ec2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional

Ingress-Onlyモードのブロックを設定する場合のAWS CLIコマンドは以下です：

aws ec2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-ingress

CloudTrail.5を抑制する

対応推奨度：使い方による

対応できるコントロール：

• CloudTrail.5 CloudTrail 証跡は Amazon CloudWatch Logs と統合する必要があります

特定のオペレーションを監視する場合などは、CloudTrail証跡をCloudWatch Logsに連携すると設定しやすいです。
特にそのような要件がない場合は検出結果を抑制しておきましょう。

CloudTrail.5 を抑制するAWS CLIコマンドは以下です：

aws securityhub get-findings --output json --filters '{"ComplianceSecurityControlId":[{"Value":"CloudTrail.5","Comparison":"EQUALS"}]}' \
| jq -c '.Findings[]' \
| while read -r finding; do
  id=$(echo ${finding} | jq -r '.Id')
  productArn=$(echo ${finding} | jq -r '.ProductArn')
  aws securityhub batch-update-findings --finding-identifiers Id=$id,ProductArn=$productArn --workflow '{"Status": "SUPPRESSED"}'
done

IAM.6を抑制する

対応推奨度：使い方による

対応できるコントロール：

• IAM.6 ルートユーザーに対してハードウェア MFA を有効にする必要があります

ルートユーザにMFAを設定するのは必須ですが、ハードウェア MFAを使っていない場合はこのコントロールが非準拠になります。
ハードウェア MFAでなくても良い場合は検出結果を抑制しましょう。

IAM.6 を抑制するAWS CLIコマンドは以下です：

aws securityhub get-findings --output json --filters '{"ComplianceSecurityControlId":[{"Value":"IAM.6","Comparison":"EQUALS"}]}' \
| jq -c '.Findings[]' \
| while read -r finding; do
  id=$(echo ${finding} | jq -r '.Id')
  productArn=$(echo ${finding} | jq -r '.ProductArn')
  aws securityhub batch-update-findings --finding-identifiers Id=$id,ProductArn=$productArn --workflow '{"Status": "SUPPRESSED"}'
done

全リージョンに対してループさせる

以上のコマンドを単一リージョンではなく、AWSアカウント内で有効な全リージョンに対して一気に実行したい場合は、各AWS CLIコマンドに --region オプションを付与してループさせれば良いです。
（サービスが対応していないリージョンがあればエラーになるかもしれません）

aws ec2 describe-regions --output text --query "Regions[].[RegionName]" \
| while read region; do
  # 実行したいコマンドを --region ${region} オプションを付けて書く
done

さいごに

システム開発中にSecurity Hub CSPMの検出結果を効率的に対応していくために、AWSアカウントやリージョンを使い始める初期段階でできる限り非準拠の検出結果をなくしていきましょう！

私たちは一緒に働いてくれる仲間を募集しています！

電通総研 キャリア採用サイト

執筆：@kou.kinyo
レビュー：@miyazawa.hibiki
（Shodoで執筆されました）