View a markdown version of this page

ソリューションを更新する - AWS での自動化されたセキュリティ対応
v1.4 以前のバージョンからのアップグレードv1.4 以降からのアップグレードv2.0.x からのアップグレードv2.1.4 以前からのアップグレードv2.x から v4.0.0 以降へのアップグレード

ソリューションを更新する

重要

  • 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 以降へのアップグレード」を参照してください。

  • v2.x から v3.x へのアップグレード: スタックの更新後、管理者アカウントで自動修復ルールを手動で再度有効にします。「完全に自動化された修復を有効にする」を参照してください。

  • Reuse Orchestrator Log Group パラメータを使用してログを保持する場合は、スタックの更新時に適切に設定されていることを確認し、ロググループの再作成やログ保持設定の喪失を回避してください。「ソリューションをデプロイする」を参照してください。以前のバージョンから v2.3.0+ へのスタックの更新を実行する場合は、[no] を選択します。

v1.4 以前のバージョンからのアップグレード

v1.4.x 以前のソリューションをデプロイしている場合は、アンインストールしてから最新バージョンをインストールしてください。

  1. 以前にデプロイしたソリューションをアンインストールします。「ソリューションのアンインストール」を参照してください。

  2. 最新のテンプレートを起動します。「ソリューションをデプロイする」を参照してください。

    注記

    v1.2.1 以前から v1.3.0 以降にアップグレードする場合は、Reuse Orchestrator Log Group を No に設定してください。v1.3.0 以降を再インストールする場合は、このオプションで Yes を選択できます。このオプションを使用すると、オーケストレーターステップ関数と同じロググループに引き続きログを記録できます。

v1.4 以降からのアップグレード

v1.4.x からアップグレードする場合は、すべてのスタックまたは StackSets を次のように更新します。

  1. 最新のテンプレートを使用して、Security Hub の管理者アカウントのスタックを更新します。

  2. 各メンバーアカウントで、最新のテンプレートからアクセス許可を更新します。

  3. 現在デプロイされているすべてのリージョンの各メンバーアカウントで、最新のテンプレートのメンバースタックを更新します。

  4. ウェブ UI が有効になっていて、TicketGenFunctionName などのパラメータを更新した場合は、CloudFront キャッシュを無効にして変更をすぐに反映します。

    aws cloudfront create-invalidation \
  --distribution-id <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 テーブルでコントロールを手動で有効にします。「完全に自動化された修復を有効にする」を参照してください。