AWS Automated Security Response on AWS v3にアップグレードしたら自動修復設定を再度有効化しよう
はじめに
みなさん AWS Automated Security Response on AWS（ASR）を使っていますか？
先日以下の記事で v2 から v3.1.1 にアップグレードしたのですが、アップデート直後に自動修復が動作しなくなってしまいました。
調査してみると、v2 から v3 へのメジャーアップグレードでは自動修復設定は引き継がれません。
v3 では設定の保存先が CloudFormation パラメータから DynamoDB テーブルに変更されたため、旧設定は移行されないようです。
今回は DynamoDB コンソールから設定状況を確認し、コントロールを有効化して自動修復が動作するまでの手順をまとめます。
やってみる
全体像です。自動修復の設定 ON にして、対象のコントロールEC2.2の修復が行われることを確認します。
DynamoDB テーブルを確認する
Admin スタックをデプロイしたアカウントを確認しましょう。
マルチアカウントで展開している場合、管理アカウントか Security Hub CSPM の委任先にあります。
DynamoDB テーブルは{Adminスタック名}-RemediationConfigTablexxxxxという命名規則のため、RemediationConfigTableでテーブルを検索します。
テーブルをみるとautomatedRemediationEnabled が全て false になっていますね。これがアップグレード後のデフォルト状態です。
自動修復を有効化する
ASR による自動修復を有効化したい場合は、automatedRemediationEnabledをtrueに変更しましょう。
試しに今回はEC2.2のコントロールで自動修復を有効化してみます。
EC2.2はデフォルト VPC のインバウンドトラフィックとアウトバウンドトラフィックの許可があると検知されます。
自動修復の動作を確認する
実際に自動修復が動作するか確認します。
ASR がメンバーとして展開されているアカウントで、デフォルト VPC を作成しましょう。
デフォルト VPC を作成すると、自動でインバウンド・アウトバウンド許可を含んだセキュリティグループが作成されるので、修復されるか確認できます。
以下のインバウンドルールが削除されることを確認します。
アップデートで追加された Web UI をみると、すぐに自動修復が行われたことを確認できました。
インバウンドルールも削除されています。
無事自動修復の有効化ができました。
まとめ
ASR v2 から v3 へアップグレードすると自動修復設定がリセットされるので、DynamoDB テーブルで再設定が必要です。
v3 では CloudFormation スタックの更新なしで動的に設定変更できるため、運用面では便利ですね。アップグレード後に自動修復が動かないと思ったら、まず DynamoDB テーブルの設定を確認してみてください。
