Automated Security Response on AWS が v4.0.0 にアップデートされたので何が変わったか確認してみた

Automated Security Response on AWS が v4.0.0 にアップデートされたので何が変わったか確認してみた

AWS Automated Security Response v4.0.0がリリースされ、AI Toolkitだけでなく、Inspector・GuardDuty・Macieの検出への自動修復拡大、Web UIの刷新、M2M認証によるAPI アクセスなど、大きな変更が加わりました。アップグレードで確認すべき点と、実際のデプロイ・動作確認をまとめます。
2026.09.02

はじめに

みなさん Automated Security Response on AWS(以下 ASR)を使われているでしょうか。アップデート情報を眺めていたところ、ASR にアップデートがありました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/automated-security-response-adds-AI-toolkit/

タイトルだけでは「AI Toolkit が追加された」というアップデートに見えます。GitHub の CHANGELOG を確認したところ、実際は v4.0.0 として多数の変更がまとめてリリースされていました。今回は v4.0.0 全体で何が変わったのかを整理します。

https://github.com/aws-solutions/automated-security-response-on-aws

何が変わったのか

v4.0.0(2026-08-26 リリース)の主な追加項目を整理しました。

Inspector・GuardDuty・Macie の検出への自動修復拡大

これまで ASR は主に Security Hub CSPM の標準(CIS、AFSBP、PCI DSS、NIST 800-53 など)のコントロールに対する修復が中心でした。今回、Amazon Inspector、Amazon GuardDuty、Amazon Macie が検出した Finding に対しても修復が用意されています。

  • Inspector.InstanceVulnerability: EC2 インスタンスのパッケージ脆弱性への自動パッチ適用
  • GuardDuty.IAMUser: IAM の認証情報侵害が疑われる Finding への対応。AWSSupport-ContainIAMPrincipal でアクセスキー無効化・コンソールアクセス禁止を実行
  • Macie.SensitiveDataS3Object: 機密データを検出した S3 バケットの Block Public Access 有効化

GuardDuty.IAMUserMacie.SensitiveDataS3Objectは、根本対応の前段としてまず封じ込めを行う位置づけです。GitHub の説明を見ると、実行後の Finding はIN_PROGRESSになり根本対応は手動での確認が必要と明記されています。一方Inspector.InstanceVulnerabilityは Systems Manager Patch Manager でパッチを直接適用する修復で、封じ込めではなく修正そのものです。

Web UI と Findings 通知の強化

Web UI が刷新され、コントロールの一元管理がしやすくなりました。あわせて、Email、Slack、Jira、ServiceNow への通知にも対応しています。実際の画面については後述します。

AI Toolkit for Custom Remediations

ガイド付きプロンプトと組み込みガードレールで、ASR 用のカスタム修復を書く際に AI アシスタントを支援する機能です。Claude Code や Amazon Q Developer などに読み込ませて使う想定で、Bedrock などのランタイムを呼び出すものではありません。

GitHub リポジトリを見ると、実体はai-assets/prompts/remediation-generator-system-prompt.mdというファイルです。ASR が要求する命名規則や IAM ロールの最小権限の作法、「修復の最後には必ず検証ステップを入れる」といったガードレールが細かく書かれています。デプロイやランタイムの修復動作自体を変えるものではなく、あくまで開発支援のプロンプトという位置づけです。

M2M 認証による API アクセス

これまで ASR の API を操作するには、Web UI にログインした人間の Cognito ユーザーとしての認証が必要でした。GitHub のソースコード(cognito-construct.ts)を見ると、v4.0.0 では Cognito に機密クライアントを登録する方式が追加されています。OAuth2 のclient_credentialsグラントでアクセストークンを取得でき、このトークンにはasr-api/full-accessという管理者相当のスコープが付与されます。

つまり、人がログインしなくてもプログラムから ASR の API を叩けるようになりました。CI/CD パイプラインからデプロイ前にコンプライアンス状況を確認できます。社内の自動化基盤や ChatOps ボットから Finding の取得・修復の実行・コントロールの有効化を行うこともできそうです。

この API アクセスは Web UI を有効化すると利用できます。AWS WAF のレートベースルールと API Gateway のスロットリングの追加も合わせて実装されていました。

新規コントロール修復

新しく 3 件のコントロール修復が追加されています。

  • S3.14: S3 バケットのバージョニング有効化
  • S3.11: S3 バケットのイベント通知設定
  • CloudFormation.3: CloudFormation スタックの終了保護を有効化

ここまでの機能追加によって、アーキテクチャは以下のようになりました。

Automated Security Response on AWSのアーキテクチャ図

Architecture overview - Automated Security Response on AWSより引用。

検出結果のソースや通知周りのリソースが大幅に増えた印象です。

既存ユーザーが気をつけたい変更

すでに ASR を運用している場合、v4.0.0 へのアップグレードでいくつか確認しておきたい点があります。

自動修復設定の移行

v2.x までは、コントロールごとの EventBridge ルールで自動修復の有効/無効を管理していました。v3 以降は DynamoDB テーブルで管理する方式に変わっており、v4.0.0 へのアップグレード時には v2 の設定を自動移行するカスタムリソースが動作します。

移行できなかったコントロールはSO0111-ASR-MigrationAutoRemediationという Lambda 関数の CloudWatch Logs に一覧が出力されます。移行が失敗した場合はSO0111-ASR_Topicという SNS トピックにも通知されます。この ARN は SSM パラメータ/Solutions/SO0111/SNS_Topic_ARNから取得でき、アップグレード前にこのトピックへの確認済みサブスクリプションが必要です。未購読のままアップグレードすると、失敗に気づく手段が CloudWatch Logs だけになってしまいます。

v3.x 以降からのアップグレードでは、この移行は不要でそのまま設定が引き継がれます。

バージョンによっては直接アップグレードできない

v2.1.4 以前からアップグレードする場合、直接 v4.0.0 へは進めません。一度 v2.3.0 を経由する必要があり、それ以外の経路だとスタック更新が失敗します。v2.0.x からも、まず v2.3.0 へのアップグレードが必要です。

v1.4 未満からのアップグレードはスタック更新の対象外で、アンインストールしてから最新版を新規インストールする形になります。

IAM パスワードポリシーのデフォルト値バグ修正

ASR-SetIAMPasswordPolicyという修復ランブックのバグ修正もありました。MaxPasswordAgeのデフォルト値が、IAM のUpdateAccountPasswordPolicyAPI が受け付けない0になっていた問題です。IAM.7 や IAM.11〜IAM.17 のコントロールに影響していたとのことです。これらのコントロールで自動修復を有効にしている場合は、挙動の変化を確認しておくとよさそうです。

非推奨コントロールの整理

CloudFormation.1CodeBuild.5S3.4SNS.2の 4 コントロールが、AWS 側で廃止されたことに伴いアクティブな修復対象から除外されています。

デプロイして動作を確認してみる

実際に検証用の単一 AWS アカウントに ASR v4.0.0 をデプロイして確認してみました。Security Hub CSPM を有効化してさえいれば、Organizations を使わない単一アカウントでも動作します。

デプロイ手順

公式のテンプレートをそのまま使い、Admin→Member-Roles→Member の順に AWS CLI でデプロイしました。前のスタックの完了を待ってから次を実行する必要があります。

aws cloudformation create-stack \
  --stack-name automated-security-response-on-aws-admin \
  --template-url "https://s3.amazonaws.com/solutions-reference/automated-security-response-on-aws/latest/automated-security-response-admin.template" \
  --parameters \
    ParameterKey=AdminUserEmail,ParameterValue=xxx@example.com \
    ParameterKey=Namespace,ParameterValue=devioasr \
  --capabilities CAPABILITY_NAMED_IAM CAPABILITY_IAM

Admin の完了後に Member-Roles、続けて Member をデプロイします。テンプレート URL とスタック名以外のパラメータはほぼ共通です。

aws cloudformation create-stack \
  --stack-name automated-security-response-on-aws-member-roles \
  --template-url "https://s3.amazonaws.com/solutions-reference/automated-security-response-on-aws/latest/automated-security-response-member-roles.template" \
  --parameters \
    ParameterKey=SecHubAdminAccount,ParameterValue=<account-id> \
    ParameterKey=Namespace,ParameterValue=devioasr \
  --capabilities CAPABILITY_NAMED_IAM CAPABILITY_IAM

aws cloudformation create-stack \
  --stack-name automated-security-response-on-aws-member \
  --template-url "https://s3.amazonaws.com/solutions-reference/automated-security-response-on-aws/latest/automated-security-response-member.template" \
  --parameters \
    ParameterKey=SecHubAdminAccount,ParameterValue=<account-id> \
    ParameterKey=Namespace,ParameterValue=devioasr \
    ParameterKey=LogGroupName,ParameterValue=<multi-region-cloudtrail-log-group> \
    ParameterKey=LoadSCMemberStack,ParameterValue=yes \
  --capabilities CAPABILITY_NAMED_IAM CAPABILITY_IAM

新規追加された修復ドキュメントの確認

aws ssm list-documentsで確認したところ、ASR 用の SSM Automation ドキュメントが 164 個作成されていました。このうち GuardDuty 連携の実体であるASR-GuardDuty.IAMUserと、新規コントロール修復 3 件も実際に存在することを確認できました。

> aws ssm list-documents --filters Key=Name,Values=ASR- \
    --query "DocumentIdentifiers[?contains(Name, 'S3.14') || contains(Name, 'S3.11') || contains(Name, 'CloudFormation.3') || contains(Name, 'GuardDuty.IAMUser')].Name" \
    --output text

ASR-GuardDuty.IAMUser  ASR-SC_2.0.0_CloudFormation.3  ASR-SC_2.0.0_S3.11  ASR-SC_2.0.0_S3.14

Web UIの確認

Web UI を確認してみると、左ナビにControl Panelが追加されており、ControlsResource FiltersNotificationsの 3 項目が並んでいます。

ASR Web UIのFindings画面とControl Panelナビゲーション

Controlsではコントロール単位で自動修復の有効化・無効化を設定できます。以前は DynamoDB の値を直接書き換える必要があったので、地味にありがたい変更です。

ASR Web UIのControls管理画面

Resource Filtersでは自動修復のスコープ設定ができます。v3 ではASR/Filters/配下の Systems Manager パラメータで設定する方式でしたが、v4 からは UI から設定できるようになっています。アカウント ID・OU・タグに加えて ARN パターンでも絞り込めます。

ASR Web UIのResource Filters一覧画面

ASR Web UIのResource Filter作成ダイアログ

Notificationsでは Email/Slack/Jira/ServiceNow/SNS と連携して通知できます。設定画面を進めると、通知のトリガーを「Finding 検出時」と「Remediation 実行時」のどちらにするか選べるようになっていました。

ASR Web UIの通知設定画面(Basic information)

試しに Slack 連携を設定してみました。Secrets Manager に Webhook の URL を登録し、シークレット名をasr/notifications/で始める命名規則になっているので注意が必要です。

ASR Web UIの通知設定画面(Slack連携)

このほか、複数の Finding を 1 通にまとめる Notification batching もありました。IaC 修復コードを添付できる Notification content、重大度・修復ステータス・リソース・コントロール単位でフィルタできる Notification filters もあります。ここでは特に設定せずに進めます。

ASR Web UIの通知設定画面(Notification filters、重大度フィルタリング)

手動で修復してみると、Slack に通知が届きました。

Slackに届いた修復通知

まとめ

Automated Security Response on AWS の v4.0.0 で何が変わったのかを、CHANGELOG と GitHub のソースコードで確認しました。AI Toolkit 以外にも、Web UI の刷新、セキュリティサービス連携の拡大、M2M 認証、新規コントロールと、変更点の多いアップデートでした。

Web UI については特にこれまで画面上で操作したかった部分ができるようになっているので、ぜひ試してみてください。

以上、鈴木純がお送りしました。

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事