![【Security Hub修復手順】[SSM.6] SSM Automation では CloudWatch ログ記録が有効になっている必要があります](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/f_auto,q_auto/v1790871196/eyecatch/wr309ednrjrbdx9mtsnl.png)
【Security Hub修復手順】[SSM.6] SSM Automation では CloudWatch ログ記録が有効になっている必要があります
こんにちは！コンサルティング部のみゃんです。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[SSM.6] SSM Automation では CloudWatch ログ記録が有効になっている必要があります
[SSM.6] SSM Automation should have CloudWatch logging enabled
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、Systems Manager Automation（以下、Automation）で、aws:executeScriptアクションの出力をCloudWatch Logsへ送信する設定が有効になっているかをチェックします。設定が無効の場合、このコントロールは失敗します。
Automationは、Runbook（ランブック）と呼ばれる手順書に沿って、AWSリソースの設定変更や運用作業を自動実行するSystems Managerの機能です。Runbookの中ではaws:executeScriptアクションを使ってPythonやPowerShellのスクリプトを実行できます。本コントロールの設定を有効にすると、このスクリプトの出力が指定したCloudWatch Logsのロググループに記録されます。
この設定はAWSアカウント・リージョン単位で、既定では無効です。そのため、Automationを一度も使っていない環境でも、Security Hubを有効にしているリージョンではこのコントロールが失敗します。
設定が無効のままだと、Runbookのスクリプトがリソースに対して何を実行し、どのような結果になったかが記録に残りません。Automationの実行が原因でリソースが意図せず変更された場合や、第三者に権限を悪用されて不正なRunbookが実行された場合に、実行内容を後から追跡できず、原因調査や影響範囲の特定ができません。
本番環境では、監査とトラブルシューティングのために対応は必須です。
本番以外の環境では、Automationの実行記録を残す必要がなく、CloudWatch Logsのログ保存料金を抑えたい場合は対応しなくても問題ありません。本番環境と同じ構成で運用したい場合は、本番以外の環境でも有効化をご検討ください。
修復手順
コントロールの確認方法
- Security Hubコンソールを開く
- 左メニューから「検出結果」を選択
- フィルターで対象のコンプライアンスセキュリティコントロール ID「SSM.6」を検索
- 検出結果の詳細から、対象のAWSアカウントIDとリージョンを確認する
本コントロールはアカウント・リージョン単位で評価されるため、検出結果はリージョンごとに1件ずつ出ます。複数リージョンで失敗している場合は、リージョンごとに修復手順を実施してください。
ステークホルダーに確認
修復を行う前に、以下の点をステークホルダーに確認してください。
- 出力先のロググループ：既定のロググループ（
/aws/ssm/automation/executeScript）を使うか、既存のロググループを指定するか - ログの保持期間：組織のログ保管ルールに合わせた保持期間（既定のロググループを自動作成させる場合は、作成後に保持期間を設定する）
- ログの暗号化：ロググループにKMSキーを設定して暗号化するか
- Automationの実行権限：自社で作成したRunbookを実行するIAMロール（AssumeRole）に、CloudWatch Logsへの書き込み権限を追加できるか（後述）
修復手順
まず、現在の設定を確認します。
- Systems Managerコンソールを開き、対象のリージョンに切り替える
- 左メニューから「変更管理ツール」>「自動化」を選択する
- 「設定を構成する」を選択する
-
「出力を CloudWatch Logs に送信する」が無効になっていることを確認し、チェックボックスを押下する
-
「CloudWatch Logs ロググループ」で出力先を選択する
- デフォルトのロググループに出力を送信する：
/aws/ssm/automation/executeScriptが存在しない場合は自動で作成されます - ロググループ一覧から選択する／ロググループ名を入力：事前に作成したロググループを指定します
- デフォルトのロググループに出力を送信する：
※ 今回はデフォルトのロググループを選択
- 「保存」を選択する
AWS CLIで設定する場合は、以下のコマンドを実行します。
REGION="ap-northeast-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
# 出力先をCloudWatch Logsに設定
aws ssm update-service-setting \
--setting-id "arn:aws:ssm:${REGION}:${ACCOUNT_ID}:servicesetting/ssm/automation/customer-script-log-destination" \
--setting-value CloudWatch \
--region "$REGION"
# 出力先のロググループを指定（既存のロググループを使う場合）
aws ssm update-service-setting \
--setting-id "arn:aws:ssm:${REGION}:${ACCOUNT_ID}:servicesetting/ssm/automation/customer-script-log-group-name" \
--setting-value "{ロググループ名}" \
--region "$REGION"
Automationの実行権限について
AWSが提供するRunbookの出力をCloudWatch Logsへ送信するには、Automationを実行するユーザーまたはロールに以下の権限が必要です。自社で作成したRunbookでは、Runbookの実行に使うIAMロール（AssumeRole）に同じ権限を追加します。
logs:CreateLogGrouplogs:CreateLogStreamlogs:DescribeLogGroupslogs:DescribeLogStreamslogs:PutLogEvents
この権限がない場合、設定を有効にしてもスクリプトの出力はロググループに記録されません。Security Hubの検出結果はサービス設定だけを見て判定するため、PASSEDになっても実際にログが出ているとは限りません。設定後にaws:executeScriptを含むRunbookを実行する機会があれば、ロググループにログが出ていることを確認してください。
修復確認
修復後、Systems Managerコンソールの「オートメーション」>「設定」タブで、「CloudWatch Logs への出力の送信」が有効になり、指定したロググループが表示されていることを確認します。
Security Hubで検出結果が「PASSED」になることを確認します。
今回の検証では、修復手順の実施から約3時間後に「PASSED」になりました。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
以上、みゃんでした！
