【Security Hub修復手順】[SecretsManager.2] 自動ローテーションを設定した Secrets Manager のシークレットは正常にローテーションする必要があります

AWS SecurityHub 基礎セキュリティのベストプラクティスコントロール修復手順をご紹介します。

AWS Security Hub 基礎セキュリティのベストプラクティスコントロール修復手順

2026.09.05

こんにちは！コンサルティング部のみゃんです。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
 本記事の対象コントロール[SecretsManager.2] 自動ローテーションを設定した Secrets Manager のシークレットは正常にローテーションする必要があります。
[SecretsManager.2] Secrets Manager secrets configured with automatic rotation should rotate successfully
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/secretsmanager-controls.html#secretsmanager-2
 前提条件本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。

AWS Security Hubの詳細についてはこちらのブログをご覧ください。
https://dev.classmethod.jp/articles/lets-learn-aws-security-hub/
https://dev.classmethod.jp/articles/aws-security-operation-with-securityhub-2021/
 対象コントロールの説明このコントロールは、自動ローテーションを設定したSecrets Managerのシークレットが、ローテーションスケジュール通りに正常にローテーションされているかチェックします。シークレットのRotationOccurringAsScheduledがfalseの場合、つまりローテーション予定日を過ぎても正常なローテーションが完了していない場合に、このコントロールは失敗します。
なお、本コントロールはローテーションが有効化されているシークレットのみを評価対象とします。そもそもローテーションを有効化していないシークレットは評価対象外となり、その場合は[SecretsManager.1]のコントロールで検知されます。
シークレットのローテーションは、Secrets ManagerがLambda関数を呼び出して、シークレット値の生成、対象サービス（データベース等）への反映、新しい値の検証、確定という4つのステップを実行することで実現されます。このいずれかのステップで失敗すると、ローテーションは完了せず、RotationOccurringAsScheduledがfalseのままになります。
ローテーション失敗の主な原因は以下の通りです。
ローテーション用Lambda関数がVPC内にあり、Secrets Managerのエンドポイントやデータベースに到達できないネットワーク構成になっている
ローテーション用Lambda関数に、シークレットを復号するためのKMSキーへのアクセス権限がない
ローテーション対象のデータベースやサービス側の認証情報変更に失敗している（パスワードポリシー違反、権限不足など）
Lambda関数のタイムアウトや同時実行数の制限に達している
ローテーションが「有効」に設定されていても、実際には上記のような理由で失敗し続けているケースは珍しくありません。ローテーション設定を有効にしただけで安心し、その後の実行結果を確認していないと、シークレットが実質的に何年も更新されていない状態に気付けません。
侵害された認証情報が長期間使われ続けるリスクや、有効期限切れ・失効した認証情報が原因でアプリケーションが突然接続エラーを起こすリスクにつながるため、対応は必須です。
 修復手順 コントロールの確認方法Security Hubコンソールを開く
左メニューから「検出結果」を選択
フィルターで対象のコンプライアンスセキュリティコントロール ID「SecretsManager.2」を検索
検出結果の詳細から、対象のシークレット名（リソースID）を確認する
 ステークホルダーに確認ローテーション用Lambda関数や対象サービス側の設定変更を伴う可能性があるため、修復を行う前に以下の点を確認してください。
対象シークレットを利用しているシステム・アプリケーションの範囲と、メンテナンスウィンドウの有無
ローテーション用Lambda関数がVPC内で動作している場合、ネットワーク構成（サブネット、セキュリティグループ、VPCエンドポイント）の変更権限を持つ担当者
ローテーション対象のデータベース・サービス側のパスワードポリシーや権限設定を変更できる担当者
 修復手順まず、Secrets Managerコンソールでローテーションの失敗状況を確認します。
Secrets Managerコンソールを開く
対象のシークレットを選択する
「ローテーション設定」セクションで、「ローテーションのステータス」が「有効」になっていること、および「次のローテーション日」が過去の日付のまま更新されていないことを確認する

※今回は検証用にローテーション用のLambdaは必ず失敗するようにしているので、最終ローテーション実行日が空欄になっています。

「ローテーション設定」セクションの「ローテーション関数」に表示されているLambda関数名を確認する
次に、CloudWatch Logsでローテーション関数のエラー内容を確認します。
CloudWatch Logsコンソールを開き、対象のLambda関数に対応するロググループ（/aws/lambda/{ローテーション関数名}）を開く

※以下のように対象のLambdaのモニタリングからロググループに飛ぶこともできます。

直近の実行ログを確認し、createSecret・setSecret・testSecret・finishSecretのどのステップでエラーが発生しているかを確認する


※今回の検証では、意図的にLambda側で必ず例外エラーでローテーションに失敗するようにしてあります。
エラー内容に応じて、以下のように対処します。
ネットワークエラー（「createSecret」以降でログが止まっている等）の場合: Lambda関数のVPC設定を確認し、Secrets Managerエンドポイントおよび対象データベースへの経路（セキュリティグループ、VPCエンドポイントポリシー）を見直す
KMSアクセスエラー（Access to KMS is not allowed等）の場合: ローテーション用Lambda関数の実行ロールに、シークレットの暗号化に使用しているKMSキーへの復号権限（kms:Decrypt等）を付与する
対象サービス側の認証エラー（setSecret: Unable to log into database等）の場合: 対象データベース・サービス側のユーザー権限やパスワードポリシーを確認し、ローテーション用ユーザーが新しいパスワードを設定できる状態にする
ローテーションが中途半端な状態で止まっている場合: AWSPENDINGのステージングラベルが残っていないか確認し、残っている場合は取り除いたうえで再度ローテーションを実行する
原因を修正したら、Secrets Managerコンソールから手動でローテーションを再実行し、正常に完了することを確認します。
Secrets Managerコンソールで対象のシークレットを開く
「ローテーション設定」セクションで「今すぐシークレットをローテーション」を選択する

確認ダイアログで「ローテーション」を選択する

 修復確認ローテーションが正常に完了すると、シークレット詳細画面の「最終ローテーション日」が更新されます。



修復後、Security Hubで検出結果が「PASSED」になることを確認します。

 最後に今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
以上、みゃんでした！