# ソリューションを更新する
**重要**
**v4.0.0 以降へのアップグレード:** ソリューションは、アップグレード後も既存の自動修復設定を保持します。**v2.x** からアップグレードすると、ソリューションはスタックの更新中に、自動修復設定を v2 EventBridge ルールから新しい DynamoDB ベースの設定へと自動的に移行します。v2 で自動修復を有効にしたコントロールは v4 でも有効のままになります。v3 以降に対応するものがないコントロールはスキップされ、移行 AWS Lambda 関数の Amazon CloudWatch ログに一覧表示されます。**v3.x** からアップグレードする場合、自動修復設定は既に DynamoDB ベースの設定内に存在し、変更されずに引き継がれるため、移行は不要です。移行中にコントロール単位の障害が発生した場合、またはコントロールが書き込まれる前に移行が中断した場合、`SO0111-ASR-MigrationAutoRemediation` Lambda 関数は既存の `SO0111-ASR_Topic` に Amazon SNS 通知を発行します。**この通知を受け取るには、v4 スタックの更新を開始する前に、`SO0111-ASR_Topic` のサブスクリプションを確定している必要があります。**「[v2.x から v4.0.0 以降へのアップグレード](#upgrading-from-v2-to-v4)」を参照してください。
**v2.x から v3.x へのアップグレード:** スタックの更新後、管理者アカウントで自動修復ルールを手動で再度有効にします。「[完全に自動化された修復を有効にする](enable-fully-automated-remediations.md)」を参照してください。
`Reuse Orchestrator Log Group` パラメータを使用してログを保持する場合は、スタックの更新時に適切に設定されていることを確認し、ロググループの再作成やログ保持設定の喪失を回避してください。「[ソリューションをデプロイする](deployment.md)」を参照してください。以前のバージョンから v2.3.0\+ へのスタックの更新を実行する場合は、[no] を選択します。
## v1.4 以前のバージョンからのアップグレード
v1.4.x 以前のソリューションをデプロイしている場合は、アンインストールしてから最新バージョンをインストールしてください。
1. 以前にデプロイしたソリューションをアンインストールします。「[ソリューションのアンインストール](uninstall-the-solution.md)」を参照してください。
1. 最新のテンプレートを起動します。「[ソリューションをデプロイする](deploy-the-solution.md)」を参照してください。
**注記**
v1.2.1 以前から v1.3.0 以降にアップグレードする場合は、`Reuse Orchestrator Log Group` を `No` に設定してください。v1.3.0 以降を再インストールする場合は、このオプションで `Yes` を選択できます。このオプションを使用すると、オーケストレーターステップ関数と同じロググループに引き続きログを記録できます。
## v1.4 以降からのアップグレード
v1.4.x からアップグレードする場合は、すべてのスタックまたは StackSets を次のように更新します。
1. [最新のテンプレート](https://solutions-reference.s3.amazonaws.com/automated-security-response-on-aws/latest/automated-security-response-admin.template)を使用して、Security Hub の管理者アカウントのスタックを更新します。
1. 各メンバーアカウントで、最新のテンプレートからアクセス許可を更新します。
1. 現在デプロイされているすべてのリージョンの各メンバーアカウントで、最新のテンプレートのメンバースタックを更新します。
1. ウェブ UI が有効になっていて、`TicketGenFunctionName` などのパラメータを更新した場合は、CloudFront キャッシュを無効にして変更をすぐに反映します。
```
aws cloudfront create-invalidation \
--distribution-id \
--paths "/aws-exports.json"
```
## v2.0.x からのアップグレード
v2.0.x からアップグレードする場合は、まず v2.3.0 にアップグレードしてください。CloudFormation で v2.1.0～2.1.1 への更新は失敗します。
## v2.1.4 以前からのアップグレード
v2.1.4 以前からアップグレードする場合は、**v2.3.0 より上位のバージョンにアップグレードする前に、v2.3.0 にアップグレードする必要があります。**そうでなければ、スタックの更新オペレーションは失敗します。あるいは、スタックの更新を実行するのではなく、ソリューションのスタックを削除して再デプロイすることもできます。
## v2.x から v4.0.0 以降へのアップグレード
v4.0.0 以降、ソリューションは v2 から v4 へのアップグレード時にも自動修復設定を保持します。v2 では、コントロールごとの Amazon EventBridge ルールに自動修復状態が保存されていました。v3 以降では、自動修復状態が管理者アカウントの修復設定 Amazon DynamoDB テーブルに保存されます。v4 スタックの更新中、カスタムリソースは既存の v2 `_AutoTrigger` ルールをスキャンし、各ルールの標準固有のコントロール ID を対応するセキュリティコントロール ID に変換します。また、以前に有効化されたコントロールを DynamoDB テーブルに書き込みます。
移行は 5 つの v2 プレイブックすべてを対象としています。
+ `SC` (AWS Security Hub サービスマネージドセキュリティコントロール) — コントロール ID は変更されずに DynamoDB に書き込まれます。
+ `AFSBP` (AWS 基礎セキュリティのベストプラクティス) — コントロール ID は変更されずに DynamoDB に書き込まれます。
+ `NIST80053R5` (NIST 800-53 リビジョン 5) — コントロール ID は変更されずに DynamoDB に書き込まれます。
+ `PCI` (PCI DSS v3.2.1) — 先頭の `PCI.` プレフィックスが削除されます (例: `PCI.S3.5` は `S3.5` になります)。
+ `CIS` (CIS AWS Foundations Benchmark v1.2.0、v1.4.0、v3.0.0) — 各 CIS コントロール ID は、その v2 SSM 修復ドキュメントが対象としていたセキュリティコントロールにマッピングされます。
移行の結果:
+ 正常に移行されたコントロールにはアクションが不要です。自動修復は v2 と同じように v4 でも有効になります。
+ 移行でスキップされるコントロールは、v2 で ASR 修復対象外の CIS ルールと、v3\+ に含まれないコントロールの 2 つのカテゴリに分類されます。スキップされたコントロールは、`SO0111-ASR-MigrationAutoRemediation` AWS Lambda 関数の Amazon CloudWatch ログに一覧表示されます。
+ 移行中にコントロール単位の障害 (DynamoDB 更新中の一時的なスロットリングエラーなど) が発生した場合、またはコントロールが書き込まれる前に移行が中断された場合、`SO0111-ASR-MigrationAutoRemediation` は Amazon SNS 通知を既存の `SO0111-ASR_Topic` トピックに発行します。通知本文には。影響を受けたコントロール ID が一覧表示され、`[ASR v2 → v3/v4 migration]` というプレフィックスが付けられます。
+ カスタムリソースは、最初の v3/v4 スタックの更新時にのみ実行されます。以降のスタック更新では、移行は再実行されません。
**注記**
**アップグレードする前に SNS トピックをサブスクライブしてください。**移行失敗通知は、ソリューションの既存の `SO0111-ASR_Topic` Amazon SNS トピックに発行されます。アップグレード前にそのトピックのサブスクリプションを確定していないと、障害通知は届きません。この場合、障害は `SO0111-ASR-MigrationAutoRemediation` AWS Lambda 関数 の Amazon CloudWatch ログにのみ表示されます。エンドポイントをサブスクライブするには、`/Solutions/SO0111/SNS_Topic_ARN` で AWS Systems Manager Parameter Store からトピック ARN を取得し、v4 スタックの更新を開始する前に SNS サブスクリプション (E メール、SQS、AWS Lambda 関数、またはその他のサポートされているプロトコル) を追加します。AWS 確認 E メールで E メールサブスクリプションを確定し、移行の実行前にトピックを配信できる状態にしておきます。
v4 で自動修復するコントロールを移行で書き込めない場合は、修復設定 DynamoDB テーブルでコントロールを手動で有効にします。「[完全に自動化された修復を有効にする](enable-fully-automated-remediations.md)」を参照してください。