セキュリティ上の問題を検出し、調査対象を整理できても、実際のAWSリソースが危険な状態のままでは改善は完了しません。

例えば、

セキュリティグループが
許可してはいけない通信を許可

↓

AWS Config Rule
NON_COMPLIANT

↓

担当者が手作業で修正

という運用では、同じ問題が多数のリソースで発生したときに対応が遅れます。

一方で、検出したものを無条件に変更する自動化も危険です。

ここでは、

AWS Config Rule
↓
NON_COMPLIANT
↓
Remediation Configuration
↓
Systems Manager Automation

または、

セキュリティ検出結果
↓
Amazon EventBridge
↓
必要な情報をAutomation入力へ対応付け
↓
Systems Manager Automation

という接続を中心に、

検出した問題を、安全に修復処理へつなげる実装判断

を扱います。

Automationの実行ロールや、人による承認、一般的なエスカレーション設計そのものは既習です。ここでは、それらを再説明せず、AWS Config Ruleまたはセキュリティ検出結果から修復ワークフローへ接続する部分に集中します。

ゴール

既存環境について、

• AWS Config Ruleの非準拠判定をSystems Manager Automationによる修復へ接続する
• 自動修復と手動修復を使い分ける
• 対象リソースの識別子をAutomationへ正しく渡す
• 同じリソースで修復が繰り返し失敗した場合の動作を理解する
• 大量の非準拠リソースを一度に修復するときの実行量を制御する
• 保存されたコンプライアンス評価と、実行時の現在状態を混同しない
• セキュリティ検出結果からAutomationを起動するときに必要な入力を対応付ける
• 修復後にAWS Config Ruleのコンプライアンス状態を確認する

ことを目指します。

1. 検出と修復を分けて考える

最初に区別するのは、

問題を見つける

ことと、

AWSリソースへ変更を加える

ことです。

例えばAWS Config Ruleが、

セキュリティグループ
↓
0.0.0.0/0 から
管理ポートを許可
↓
NON_COMPLIANT

と判定したとしても、その判定だけでセキュリティグループが変更されるわけではありません。

AWS Config Rule
= 設定を評価

Systems Manager Automation
= 修復処理を実行

という責任分離で考えます。

したがって、自動修復では、

検出
↓
修復対象の特定
↓
修復処理

を接続する必要があります。

2. AWS Config Ruleから修復へ接続する

AWS Configでは、Ruleで非準拠と判定されたリソースに対して修復アクションを設定できます。

基本構成は、

AWS Config Rule
↓
NON_COMPLIANT
↓
Remediation Configuration
↓
Systems Manager Automation
↓
対象リソースを修復

です。

ここで重要なのは、

Config Ruleそのものが
リソースを書き換える

のではないことです。

AWS Config側では、

どのRuleに対して

どのAutomationドキュメントを使い

対象リソースを
どのパラメータへ渡すか

をRemediation Configurationとして対応付けます。

3. 対象リソースをAutomationへ渡す

Systems Manager Automationのランブックは、修復する対象を識別できなければなりません。

例えばAutomationが、

ResourceId

という入力を要求している場合、

AWS Config Rule
↓
NON_COMPLIANTとなったリソース
↓
リソースID
↓
Automation
ResourceId

という対応付けを行います。

つまり、

どのリソースが非準拠か

というAWS Config側の情報を、

どのリソースを変更するか

というAutomation側の入力へ渡します。

ここが曖昧だと、正しい修復ランブックを用意していても対象を特定できません。

4. 自動修復と手動修復を分ける

AWS Configの修復では、

自動修復
手動修復

を選択できます。

自動修復

NON_COMPLIANT
↓
条件に従って
Automation開始

と進みます。

多数のリソースに同じ修復を継続的に適用したい場合に利用できます。

手動修復

NON_COMPLIANT
↓
対象を確認
↓
修復実行

と、人が実行タイミングを選びます。

重要なのは、

Automationがある
=
必ず自動修復

ではないことです。

修復方法をAutomationへ標準化しながら、実行開始だけを手動にする構成も可能です。

5. 自動修復が失敗した場合は無限に繰り返さない

自動修復では、一時的な失敗が発生する可能性があります。

例えば、

NON_COMPLIANT
↓
Automation
↓
一時的な失敗

だけで永久に修復不能と判断する必要はありません。

AWS Configの自動修復では、

MaximumAutomaticAttempts
RetryAttemptSeconds

に相当する条件によって、

一定期間内に
何回まで自動修復を試行するか

を制御できます。

流れは、

修復開始
↓
失敗
↓
再試行条件内？
│
├─ はい → 再試行
│
└─ いいえ → 自動修復を継続しない

です。

ポイントは、

再試行回数だけでなく、再試行を数える期間も組み合わせる

ことです。

6. 繰り返し失敗したリソースはRemediationExceptionになる

同じリソースに対して修復処理を繰り返しても失敗し続ける場合、AWS ConfigはそのリソースにRemediationExceptionを設定できます。

NON_COMPLIANT
↓
自動修復
↓
失敗
↓
再試行
↓
再び失敗
↓
設定した試行条件を超える
↓
RemediationException

これは、

失敗している対象へ
自動修復を永久に繰り返す

ことを防ぐための状態です。

したがって、

RemediationException
↓
そのまま自動修復ループへ戻し続ける

とは考えません。

繰り返し失敗している対象として切り分け、原因を確認する対象にします。

例えば、

対象リソースの状態が
想定と異なる

必要な依存関係がない

修復ランブックが
そのリソース条件に対応していない

などを確認します。

7. 大量修復では同時実行量を制御する

1件のリソースを修復できても、同じAutomationを数千リソースへ同時実行して安全とは限りません。

例えば、

2,000リソース
NON_COMPLIANT

↓

2,000件を
一斉修復

すると、

• APIの集中
• 対象システムへの急激な変更
• 同じ原因による大量失敗

などにつながる可能性があります。

AWS Configの修復では、

ConcurrentExecutionRatePercentage

を使って、同時に修復する対象の割合を制御できます。

大量のNON_COMPLIANT
↓
一部ずつAutomation実行
↓
次の対象へ

という実行にできます。

重要なのは、

修復できる

ことと、

全対象を同時に修復してよい

ことを分けることです。

8. 許容エラー率で大量失敗を抑える

大量修復では、少数の失敗と大規模な失敗を区別する必要があります。

そのため、

ErrorPercentage

によって、許容するエラー割合を制御できます。

考え方は、

自動修復開始
↓
複数対象で実行
↓
失敗率を確認
↓
許容範囲を超える
↓
追加実行を抑制

です。

したがって、大量リソースへの自動修復では、

ConcurrentExecutionRatePercentage

と、

ErrorPercentage

を組み合わせて考えます。

9. コンプライアンス評価は「現在状態」とは限らない

AWS Configの自動修復で特に注意するのが、

評価された状態

と、

Automation実行時の状態

に時間差が存在し得ることです。

例えば、

10:00
AWS Config
NON_COMPLIANT

↓

10:01
管理者が手動修正

↓

10:02
保存されていた評価を基に
自動修復開始

というケースです。

この時点では、

10:00
NON_COMPLIANT

という評価結果は存在しますが、

10:02
実際のリソース

は既に正常化している可能性があります。

したがって、

NON_COMPLIANTだった
=
Automation開始時も
同じ状態

とは限りません。

10. 影響の大きい修復では実行時の現在状態を再確認する

古いコンプライアンス評価に基づいて、不要になった変更を実行したくない場合があります。

その場合は、Automation内で、

Automation開始
↓
現在状態を取得
↓
まだ修復が必要？
│
├─ はい → 修復
│
└─ いいえ → 変更せず終了

という確認を入れます。

例えば、

AWS Config評価時
セキュリティグループが非準拠

↓

その後
管理者が正しいルールへ修正

↓

Automation開始

↓

現在のセキュリティグループを確認

↓

既に正常
→ 追加変更しない

という形です。

ここでの決定打は、

保存されたコンプライアンス評価だけを、実行時の現在状態として扱わない

ことです。

11. セキュリティ検出結果から修復へつなぐ場合

AWS Config Ruleによる設定準拠とは別に、セキュリティ検出結果を入口として修復したい場合があります。

この場合、Amazon EventBridgeを利用して対象イベントを修復処理へ接続できます。

セキュリティ検出結果
↓
Amazon EventBridge
↓
Systems Manager Automation

ただし、この接続自体の基本は既習です。

ここで重要なのは、

検出結果のどの情報を、Automationのどの入力へ渡すか

です。

12. EventBridgeでAutomation入力へ必要な情報を対応付ける

例えば、セキュリティ検出結果に、

リソースID
AWSアカウント
リージョン
検出結果タイプ

が含まれており、Automationランブックが、

ResourceId
AccountId
Region
RemediationType

を要求するとします。

この場合、

セキュリティ検出結果
│
├─ リソースID
│      ↓
│   ResourceId
│
├─ AWSアカウント
│      ↓
│   AccountId
│
├─ リージョン
│      ↓
│   Region
│
└─ 検出結果タイプ
       ↓
    RemediationType

となるように入力を構成します。

単に、

EventBridgeのルールが一致した

だけでは不十分です。

Automationが、

どのリソースを

どのアカウント・リージョンで

どの修復方式により

処理するか判断できる入力へ変換する必要があります。

13. Config Ruleとセキュリティ検出結果では入口が異なる

2つの経路を混同しないようにします。

AWS Config Ruleでは、

NON_COMPLIANTとなったリソース
↓
Remediation Configuration
↓
Automation

が中心です。

セキュリティ検出結果では、

検出イベント
↓
EventBridge
↓
必要な情報を入力へ対応付け
↓
Automation

が中心です。

どちらも最終的にSystems Manager Automationを利用できても、

Automationまでの接続方法が同じではありません。

14. 修復後はAWS Config Ruleを再評価する

AWS Config Ruleを基準として修復した場合、修復処理を実行しただけでは、

コンプライアンス上
正常になった

ことを示しません。

例えば、

AWS Config Rule
NON_COMPLIANT
↓
Automation
↓
設定変更

の後に、

AWS Config Rule
再評価
↓
COMPLIANT

となることで、設定がRuleの要求状態へ戻ったことを確認できます。

したがって、AWS Configを基準とした修復では、

Automation実行

だけを見るのではなく、

Ruleの再評価結果

まで確認します。

これは一般的なAutomationの成否判定を再説明するものではなく、

AWS Config Ruleを基準にした修復では、コンプライアンス状態へ戻ったことをAWS Config側で確認する

という判断です。

15. 修復経路を整理する

AWS Config Ruleを入口にする場合

AWS Config Rule
↓
NON_COMPLIANT
↓
Remediation Configuration
↓
対象リソースIDを対応付け
↓
Systems Manager Automation
↓
必要なら現在状態を再確認
↓
修復
↓
AWS Config Rule再評価
↓
COMPLIANT

自動修復を利用する場合は、さらに、

MaximumAutomaticAttempts
RetryAttemptSeconds

ConcurrentExecutionRatePercentage
ErrorPercentage

RemediationException

を使って実行を制御します。

セキュリティ検出結果を入口にする場合

セキュリティ検出結果
↓
Amazon EventBridge
↓
必要なイベントを選択
↓
検出結果の情報を
Automation入力へ対応付け
↓
Systems Manager Automation
↓
対象を修復

この2つの違いを押さえることが重要です。

16. 混同しやすいポイント

17. SAP-C02での判断手順

問題文で、

AWS Config Ruleが
多数のNON_COMPLIANTを検出

手動修正に時間がかかる

同じ修復方法を
繰り返し実施している

とあれば、

AWS Config Rule
↓
Remediation Configuration
↓
Systems Manager Automation

を候補にします。

次に、

自動実行する？
手動で開始する？

を判断します。

自動修復なら、

再試行は何回まで？
↓
失敗し続ける対象は？
↓
大量対象の同時実行量は？
↓
許容エラー率は？

まで確認します。

さらに、

AWS Configの評価から
Automation開始までに
状態が変わり得る？

なら、

Automation開始
↓
現在状態を再確認
↓
必要な場合だけ変更

とします。

一方、

Security Hubなどの
セキュリティ検出結果

↓

条件に合うものを
自動修復したい

なら、

Amazon EventBridge
↓
検出結果の必要フィールドを抽出
↓
Automation入力へ対応付け
↓
Systems Manager Automation

と判断します。

決定打は、

検出サービスを増やすことではなく、検出した対象・現在状態・修復方法を正しくAutomationへ接続し、過剰実行や修復ループを制御できること

です。

まとめ

セキュリティ上の問題を自動修復するときは、

検出

という一般概念ではなく、

検出
↓
対象特定
↓
修復処理へ接続
↓
実行制御
↓
現在状態確認
↓
修復
↓
コンプライアンス確認

という実装で考えます。

AWS Config Ruleを入口にする場合は、

NON_COMPLIANT
↓
Remediation Configuration
↓
Systems Manager Automation

が中心です。

自動修復では、

MaximumAutomaticAttempts
RetryAttemptSeconds
RemediationException
ConcurrentExecutionRatePercentage
ErrorPercentage

を使って、失敗時の再試行や大量実行を制御します。

また、

保存されたコンプライアンス評価
≠
Automation開始時の現在状態

なので、必要に応じて実行時に状態を再確認します。

セキュリティ検出結果を入口にする場合は、

セキュリティ検出結果
↓
Amazon EventBridge
↓
検出結果の情報を
Automation入力へ対応付け
↓
Systems Manager Automation

と接続します。

最後に、AWS Config Ruleを基準とする修復では、Ruleを再評価し、対象がCOMPLIANTへ戻ったことまで確認します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Config — Remediating noncompliant AWS resources
• AWS Config API — RemediationConfiguration
• AWS Config API — PutRemediationExceptions
• AWS Config — Automatic remediation
• Amazon EventBridge — AWS service events
• AWS Security Hub — Amazon EventBridge integration
• AWS Systems Manager — Automation