完全自動修復を有効にする
このソリューションのもう 1 つの運用方法は、検出結果が Security Hub に到着したら自動的に修復することです。
重要
完全自動修復を有効にする前に、ソリューションで自動変更を行うアカウントとリージョンで、ソリューションが設定されていることを確認してください。ソリューションの自動修復の範囲を絞り込む場合は、「完全自動修復のフィルタリング」を参照してください。
注記
AWS Security Hub で抑制されている検出結果は、対応するコントロールに対して完全自動修復が有効になっていても、自動的に修復されません。検出結果は、そのワークフローステータスが SUPPRESSED の場合に抑制されます。ソリューションは抑制された検出結果を自動開始時にスキップするため、Security Hub で検出結果を抑制することは、コントロールを有効にしたままで自動修復から特定の検出結果を除外する効果的な方法です。抑制された検出結果であっても、ウェブ UI または AWS Security Hub CSPM カスタムアクションからオンデマンドで修復できます。
自動修復の再試行制限
完全自動修復が失敗すると、AWS Security Hub は失敗し続けている検出結果を再インポートします。これにより、ソリューションが修復を無期限にトリガーし続ける可能性があります。これを防ぐために、ソリューションは失敗した検出結果を最大 3 回再試行し、試行から次の試行までに少なくとも 15 分間空けます。3 回目の試行後、ソリューションは検出結果の自動再試行を停止し、Amazon CloudWatch メトリクス RemediationRetryCapReached を出力します。検出結果はソリューションに引き続き表示され、ウェブ UI または AWS Security Hub CSPM カスタムアクションからオンデマンドでいつでも修復できます。この制限は検出結果別に適用され、他の検出結果やコントロールには影響しません。
例: Lambda.1 の完全自動修復を有効にする
自動修復を有効にすると、有効にしたコントロール (Lambda.1) と一致するすべてのリソースで修復が開始されます。
重要
ソリューションの範囲内のすべてのパブリック Lambda 関数に対してこのアクセス許可を取り消せることを確認してください。完全自動修復は、作成した関数に適用範囲が限定されるわけではありません。このコントロールがインストールされているアカウントとリージョンのいずれかで検出された場合、ソリューションはこのコントロールを修正します。
| アカウント | 目的 | us-east-1 でのアクション | us-west-2 でのアクション |
|---|---|---|---|
|
|
管理者 |
必要なパブリック関数がないことを確認する |
必要なパブリック関数がないことを確認する |
|
|
メンバー |
必要なパブリック関数がないことを確認する |
必要なパブリック関数がないことを確認する |
修復設定 DynamoDB テーブルを見つける
管理者アカウントで、CloudFormation コンソールOutputs を確認します。「RemediationConfigurationDynamoDBTable」というタイトルの出力が表示されます。
これは、ソリューションの自動修復設定を制御する修復設定 DynamoDB テーブルの名前です。この出力の値をコピーし、対応する DynamoDB テーブルを DynamoDB コンソール
v2 から v4 への移行
v2.x から v4.0.0 以降にアップグレードした場合、ソリューションは v2 で自動修復が有効になっていたコントロールをこのテーブルに自動的に入力します。移行によって書き込まれた項目は modifiedBy が v2-migration に設定されているため、移行されたエントリを手動編集から区別できます。期待していたコントロールの移行が成功したことを検証するには、automatedRemediationEnabled = true を使用してテーブルをクエリし、結果を確認します。移行でスキップされたコントロール (v2 で ASR 修復対象外の CIS ルールや v3+ に含まれていないコントロール) は、以下の手順を使用して手動で有効にする必要があります。移行結果の詳細については、「ソリューションを更新する」を参照してください。
| アカウント | 目的 | us-east-1 でのアクション | us-west-2 でのアクション |
|---|---|---|---|
|
|
管理者 |
修復設定 DynamoDB テーブルを見つけます。 |
なし |
|
|
メンバー |
なし |
なし |
修復設定テーブルを変更する
修復設定テーブルを見つけた DynamoDB コンソール
テーブルの各項目は、ソリューションでサポートされている Security Hub コントロールに対応しています。各項目には automatedRemediationEnabled 属性があり、これを変更することで、関連するコントロールに対する完全自動修復を有効にすることができます。
Lambda.1 を有効にするには、[項目のスキャンまたはクエリ] で [クエリ] を選択します。[パーティションキー: controlId] で「Lambda.1」と入力し、[実行] を選択します。Lambda.1 コントロールに対応する単一の項目が返されます。
次に、Lambda.1 項目を選択し、[アクション] > [項目の編集] を選択します。
![DynamoDB の修復設定用の [項目の編集] ダイアログ](images/remediation-config-edit-item.png)
最後に、automatedRemediationEnabled 属性値を [True] に変更します。[保存して閉じる] を選択します。
| アカウント | 目的 | us-east-1 でのアクション | us-west-2 でのアクション |
|---|---|---|---|
|
|
管理者 |
修復設定 DynamoDB テーブルを変更します。 |
なし |
|
|
メンバー |
なし |
なし |
リソースを設定する
メンバーアカウントで、パブリックアクセスを許可するように Lambda 関数を再設定します。
| アカウント | 目的 | us-east-1 でのアクション | us-west-2 でのアクション |
|---|---|---|---|
|
|
管理者 |
なし |
なし |
|
|
メンバー |
なし |
Lambda 関数がパブリックアクセスを許可できるように設定する |
修復によって検出結果が解決したことを確認する
安全ではない設定を Config で再度検出するまで、しばらく時間がかかる場合があります。2 つの SNS 通知を受け取るはずです。1 つ目は、修復が開始されたことを示します。2 つ目は、修復が成功したことを示します。2 回目の通知を受け取ったら、メンバーアカウントで Lambda コンソール
| アカウント | 目的 | us-east-1 でのアクション | us-west-2 でのアクション |
|---|---|---|---|
|
|
管理者 |
なし |
なし |
|
|
メンバー |
なし |
修復が成功したことを確認する |
(オプション) 完全自動修復をフィルタリングする
ソリューションによる完全自動修復の実行範囲を制限するには、リソースフィルターを適用します。フィルターは完全自動修復にのみ適用され、手動で開始した修復には影響しません。
リソースフィルターは、どの検出結果を自動修復の対象範囲にするかを決める再利用可能な定義です。フィルターごとに、アカウント ID、AWS Organizations 組織単位 (OU)、リソース ARN パターン、リソースタグを組み合わせることができます。フィルターは、ウェブ UI の [フィルター] ページで作成し、[含める] モードまたは [除外する] モードを使用して、[コントロール] ページの 1 つのコントロール (または一度にすべてのコントロール) に適用します。
完全なチュートリアル (フィルターの作成、コントロールへの適用、ソリューションによる [含める] モードと [除外する] モードの評価方法など) については、管理者ガイドの「リソースフィルターを作成して適用する」を参照してください。
