- はじめに:AWS Configで実現する継続的コンプライアンス
- 【実践】EBSデフォルト暗号化を「自動修復」でオンに保つ
- 補足:アクションの実行が失敗した場合のトラブルシューティング
- まとめ:Configで実現する低運用負荷なコンプライアンス
はじめに:AWS Configで実現する継続的コンプライアンス
こんにちは、カスタマーサクセス本部の加治屋です。
今回は、多くの組織のセキュリティポリシーで定められている「EBSのデフォルト暗号化」をテーマに、Configルールを使った監視と自動修復の具体的な手順を紹介します。
AWS環境において、セキュリティポリシーの準拠(コンプライアンス)を継続的に維持することは非常に重要です。 AWS Organizations(マルチアカウント)環境では、SCP(サービスコントロールポリシー)を使い、そもそも違反となる操作(例:暗号化なしのEBS作成)を禁止する「予防的統制(Preventive Control)」が最も強力な手段となります。
しかし、単一アカウントで運用している場合や、Organizationsの管理者権限が与えられていない環境では、SCPによる制御が困難です。
そこで有力な手段となるのが、AWS Configによる「発見的統制(Detective Control)」です。Configルールは、設定されたセキュリティポリシー(あるべき姿)から逸脱したリソースを継続的に監視・検知し、さらにSSM Automationと連携することで自動修復まで行うことができます。
早速、実践手順をご紹介していきます。
【実践】EBSデフォルト暗号化を「自動修復」でオンに保つ
特定のリージョンのEBSデフォルト暗号化設定が何らかの理由でオフにされた場合に、自動でオンに戻す仕組みを構築します。 AWS Configが違反を検知し、SSM Automationが自動で修復(設定をオンに戻す)を実行する流れです。
前提条件
本記事の手順を実践するにあたり、以下の環境が前提となります。
- AWS Config の有効化(レコーディング設定)
- 対象のリージョンにおいて、AWS Config の設定レコーダーが有効(オン)になっている必要があります。
- 未設定の場合は、AWS Config コンソールよりセットアップを事前に済ませておいてください。
手順1:自動修復(SSM)用のIAMポリシー・IAMロールの作成
Configルール自動修復アクションを実行させるためには、SystemManagerがリソースの設定を変更できるようIAMポリシーとロールを作成し、指定する必要があります。
まずは、下記の内容で IAM ロールにアタッチする IAM ポリシーを作成します。利用するアクションはSSMランブックのユーザーガイド(AWSConfigRemediation-EnableEbsEncryptionByDefault - AWS Systems Manager 自動化ランブックリファレンス )に記載されています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAutomationExecution",
"ssm:GetAutomationExecution",
"ec2:EnableEbsEncryptionByDefault",
"ec2:GetEbsEncryptionByDefault"
],
"Resource": "*"
}
]
}
作成した IAM ポリシーをアタッチした IAM ロールを作成します。IAM ロール名は任意の名前でかまいません。 その際に信頼ポリシーは Systems Manager を信頼するよう、下記のような内容を記述します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
手順2:Configルール ec2-ebs-encryption-by-default の作成
次に、EBSのデフォルト暗号化がオフになっていないかを監視するConfigルールを作成します。
- AWS Configコンソールに移動し、作業するリージョンが正しいことを確認します。
- 左メニューから「ルール」を選択し、「ルールを追加」をクリックします。
- ルールのタイプで「AWS によって管理されるルールを追加」を選択します。
- AWS マネージド型ルールの検索ボックスに「ec2-ebs-encryption-by-default」 と入力し、表示されたルールを選択します。
- (任意)名前と説明の変更が必要な場合は編集します。
- トリガーセクションで「頻度」を設定します。
- パラメータ設定は必要ないため、そのまま「次へ」進み、「保存」をクリックします。
これで、EBSのデフォルト暗号化設定が「オフ」になると、「非準拠 (NON_COMPLIANT)」として検知されるようになりました。
手順3:自動修復アクションの設定
作成したルールが「非準拠」になったときに、自動でSSMを実行するよう設定します。
- ルール一覧から、作成した ec2-ebs-encryption-by-default ルールをクリックして詳細画面を開きます。
- 右上の「アクション」メニューから「修復の管理」を選択します。
- 修復方法で「自動修復」を選択します。
- 修復アクションで「AWSConfigRemediation-EnableEbsEncryptionByDefault (※)」を検索して選択します。
※「EBSのデフォルト暗号化を有効にする」というAWS定義済みのSSMランブック(自動化ドキュメント)です。 - リソースIDパラメータは「n/a」のままでOKです(このルールはアカウント全体の設定を対象とするため、特定のリソースID指定は不要)。
- パラメーターセクションの「AutomationAssumeRole」の値として 手順1で作成したIAMロールのARNを貼り付けます。
- 「変更を保存」をクリックします。
これで、ルールが「非準拠」を検知すると指定したIAMロールの権限でSSMランブックが自動実行され、設定が「オン」に戻されるようになりました。
手順4:動作確認(テスト)
最後に、この仕組みが正しく動作するかをテストします。
4-1. 手動トリガーによる即時実行の確認
まずは、SSMオートメーションの設定やIAMロールの権限が正しいことを、手動トリガーを使って確認します。
- EC2コンソールに移動します。
- ナビゲーションペインから「設定」を選択し、「データ保護とセキュリティ」タブの「EBS 暗号化」セクションに移動します。
- 「デフォルトで暗号化」設定の「管理」をクリックし、有効化のチェックを外して、「EBS 暗号化を更新する」をクリックします(意図的に違反状態を作ります)。
- AWS Configコンソールに戻り、ec2-ebs-encryption-by-default ルールの詳細画面を開きます。
- 右上の「アクション」から「再評価」をクリックします。
- ページ下部の「対象範囲内のリソース」セクションで「ステータス:✓ アクションが正常に実行されました」「コンプライアンス:✓準拠」となっていることを確認します(反映に数分かかる場合があります)。
- 再度 EC2コンソールの「EBS 暗号化」設定画面に戻り、ページを更新します。
- 「常に新しいEBSボリュームを暗号化」の項目が「有効」に戻っていることを確認します。
これで、自動修復の仕組み自体が正しく機能していることが確認できました。
4-2. スケジュールによる自動実行の確認
次に、Configルールの「頻度」で設定したスケジュール通りに自動検知・修復が行われるかを確認します。
- 再度、EC2コンソールで「EBSデフォルト暗号化」のチェックを外し、無効化します。
- そのまま、手順2で設定したConfigルールの「頻度」(例:1時間、24時間など)の期間が経過するまで待機します。
※この間、「再評価」ボタンは押しません。 - Configルールページ下部の「対象範囲内のリソース」セクションで「ステータス:✓ アクションが正常に実行されました」「コンプライアンス:✓準拠」となっていることを確認します
- EC2コンソールを確認し、EBSデフォルト暗号化設定が「有効」になっていることを確認します。
以上で、リージョンのEBSデフォルト暗号化設定が意図せずオフにされた場合に自動でオンに戻す仕組みの構築が完了しました。
補足:アクションの実行が失敗した場合のトラブルシューティング
もし何かしらの原因で自動修復アクションが失敗してしまった場合、Configルールのコンソールからは具体的なエラーの内容や原因を見ることができません。 自動修復アクションの実行が失敗した際には AWS CLI を用いてトラブルシューティングを行うことが可能です。
AWS CLIでのトラブルシューティング
以下のようなコマンドを実行することで自動修復アクションの実行結果とエラーの内容を確認できます。
aws configservice describe-remediation-execution-status \
--config-rule-name "Configルール名"
例えば ec2-ebs-encryption-by-default ルールの自動修復アクション実行が失敗した場合以下のようなコマンドを実行します。
~ $ aws configservice describe-remediation-execution-status --config-rule-name "ec2-ebs-encryption-by-default"
{
"RemediationExecutionStatuses": [
{
"ResourceKey": {
"resourceType": "AWS::::Account",
"resourceId": "[AWS ACCOUNT ID]"
},
"State": "FAILED",
"StepDetails": [
{
"Name": "ModifyAccount",
"State": "SUCCEEDED",
"StartTime": "2025-11-06T11:59:51.966000+00:00",
"StopTime": "2025-11-06T11:59:52.415000+00:00"
},
{
"Name": "VerifyEbsEncryptionByDefault",
"State": "FAILED",
"ErrorMessage": "Step fails when it is Execute/Cancelling action. An error occurred (UnauthorizedOperation) when calling the GetEbsEncryptionByDefault operation: You are not authorized to perform this operation. User: arn:aws:sts::[AWS ACCOUNT ID]:assumed-role/Role-for-Remediation-EBS-Snapshot/[MASKED] is not authorized to perform: ec2:GetEbsEncryptionByDefault because no identity-based policy allows the ec2:GetEbsEncryptionByDefault action. Please refer to Automation Service Troubleshooting Guide for more diagnosis details.",
"StartTime": "2025-11-06T11:59:52.659000+00:00",
"StopTime": "2025-11-06T11:59:52.969000+00:00"
}
],
"InvocationTime": "2025-11-06T11:59:51.730000+00:00",
"LastUpdatedTime": "2025-11-06T11:59:53.254000+00:00"
}
]
}
すると「An error occurred (UnauthorizedOperation) when calling the GetEbsEncryptionByDefault operation: You are not authorized to perform this operation.」のようなエラーメッセージを確認でき、上記であれば権限不足により自動修復アクションが実行できなかったことがわかります。
まとめ:Configで実現する低運用負荷なコンプライアンス
今回はAWS ConfigとSSMを使い、EBSのデフォルト暗号化を自動修復する仕組みを構築しました。
Lambdaなどを使えば、リソースがルールに準拠しているかの監視や自動修復アクションを、より柔軟かつ独自に定義して運用することも可能です。しかしその場合、Lambda関数自体のコード管理や、ランタイム(Pythonなど)のバージョンアップ対応といった運用保守コストがどうしても発生してしまいます。
その点、AWSマネージドで提供されているConfigルールやSSMランブックを積極的に活用すれば、それらの運用負荷をAWSに任せつつ、効率的にコンプライアンスを維持できます。
また、組織内の複数のアカウントに対して同じセキュリティポリシーを展開したい場合には、適合パック(Conformance Packs)を使ってルールセットをYAMLでコード化し一元管理したり、アグリゲータ(Aggregator)を使って集約アカウントで一元管理することも可能です。
AWS Configを活用して、効率的なコンプライアンス体制を構築していきましょう!
加治屋 (記事一覧)
2024年度新卒入社
蕎麦が好きです