Configルールによる自動修復

非準拠のリソースを見つけるだけでは作業の半分にすぎません。自動修復によって、自動的に問題を解消できます。AWS Configではルールに修復アクションを関連付けられるため、リソースがNON_COMPLIANTになると、人の対応を待たずに修正を実行できます。これにより、安全でない設定が公開されている時間を短縮できます。

Configの修復は、ランブックとも呼ばれるAWS Systems Manager (SSM) Automationドキュメントによって実行されます。AWSには、S3バケットへのパブリックアクセスを無効にしたり、ボリュームを暗号化したりするための定義済みドキュメントが多数用意されています。ドキュメントには、リソースを再び準拠状態に戻すために実行する具体的な手順が定義されています。

修復アクションをConfigルールに関連付け、リソースIDなどのルールの出力をランブックの入力パラメータに対応付けます。ルールが非準拠を報告すると、Configはその特定のリソースに対してSSMドキュメントを実行し、検出から修正までの一連の流れを完了させます。

修復は、非準拠が検出されるとすぐに実行する自動修復にも、オペレーターが確認してから修正を開始する手動修復にもできます。自動修復は、明確で安全な修正に適しています。一方、ワークロードに影響を与える可能性があり、実行前に人の判断が必要な変更には手動修復が適しています。

SSMドキュメントは、指定したIAMロールで実行されます。このロールには、セキュリティグループの変更や暗号化の有効化など、修正を実行する権限が必要です。最小権限の原則に従い、ランブックが必要とするアクションだけをこのロールに許可してください。このロールは、実質的にリソースを変更できる権限を持つためです。

修復を何回再試行するか、またどの時間枠で再試行するかを設定できます。修正が繰り返し失敗すると、リソースは非準拠のままになり、人による対応が必要なものとして通知されます。この動作を理解しておくと、予期しない結果を防げます。修復はベストエフォート型の自動化であり、成功を保証するものではないため、結果の監視も重要です。

典型的なパターンでは、s3-bucket-public-read-prohibitedルールと、パブリックとして検出されたバケットにBlock Public Accessを適用する修復ランブックを組み合わせます。誰かがバケットを公開した瞬間にConfigが検出し、ランブックが再び安全な状態に戻します。多くの場合、オペレーターの対応なしで数分以内に完了します。

修復は、悪い状態が発生した後に対応します。一方、SCPやアクセス許可境界などの予防的なガードレールは、悪い状態そのものが発生するのを防ぎます。最も強力な設計では、両方を組み合わせます。防げるものは防ぎ、それでも発生した問題は自動修復します。試験では、予防的なコントロールと、検出と是正を組み合わせたコントロールが対比されることがよくあります。

自動修正には副作用が生じる可能性があります。リソースの再暗号化や再保護によって、サービスが一時的に中断したり、正当な変更と競合したりすることがあります。まず非本番環境でランブックをテストし、ルールの対象範囲を慎重に設定してください。また、機密性の高いリソースには手動修復を検討し、自動化によって修正対象の設定ミス以上の被害が生じないようにします。

コンフォーマンスパックを使用すると、ルールと修復アクションを組織内のすべてのアカウントに一度にデプロイできます。これにより、どのアカウントでも同じ自動化された標準によって設定ミスを検出し、修正できる、一貫した自己修復体制を実現できます。

自動修復によってConfigの仕組みが完成します。状態を記録し、ルールで評価し、最小権限のロールで実行するSSMランブックによって自動的に修正します。予防的なガードレールと慎重に組み合わせることで、環境を継続的に準拠させ、安全でない設定が残り続ける時間を大幅に短縮できます。

自動修復に関する知識を確認しましょう。

自動修復では、SSM AutomationドキュメントをConfigルールに関連付け、非準拠のリソースを自動的に、または手動で確認した後に修正します。ランブックは最小権限のIAMロールで実行され、再試行回数を設定できます。予防的なガードレールと組み合わせ、まずランブックをテストしたうえで、コンフォーマンスパックを使用して組織全体にデプロイすると、自己修復型で継続的に準拠した環境を実現できます。