MySQLパスワードローテーション：1人のユーザーを使用して他のユーザーパスワードを変更する
現在、AWS Aurora / MySQLベースのアプリケーションのパスワードローテーション戦略の設定に取り組んでいます。
私の計画はこのような戦略を使うことでした...
- AWSSSM暗号化パラメーターに保存されているアプリケーションのユーザー名/パスワード。
- アプリケーションサーバーは、SSMから資格情報のみを取得するためのアクセス権を持っています。環境（ステージング、本番など）による制限
- Lambdaは、MySQLのパスワードを変更し、新しい値をSSMに保存するために定期的に実行するように構成されています。Lambdaは、パスワードを使用するのではなく、AWSIAMロールを使用してデータベースで認証します。
最後のビットは私がよくわからないビットです。この構成では、ラムダロール/ユーザーが他のすべてのアプリケーションユーザーのパスワードを変更する権限を持っている必要があります。
これは、セキュリティの観点から、それを行うための合理的な方法ですか？lambda mysqlユーザーはパスワードではなくIAMロールを使用するため、これにより、許可されたロールのみに使用を制限する必要があります。
別の方法は、ラムダがログインするための特別なdbユーザーを持たないことですが、ラムダ関数がSSMから各ユーザーの資格情報を取得し、各ユーザーとしてログインしてパスワードを変更することです。
いずれにせよ、ラムダは各ユーザーにアクセスできる必要があります。
MySQLの「lambda_user」へのアクセスを注意深く取得できると仮定すると、ユーザーに他のユーザーのパスワードを変更する権限を持たせることに他の明白な問題はありますか？
また、明確にするために、これらはアプリケーションユーザーであり、これらの資格情報を使用する通常の人間タイプのユーザーではありません。
回答
これは、あなたが概説したまさにその理由から、それを行うためのベストプラクティスの方法です。Lambdaに資格情報の代わりに認証の役割を使用させることで、保持する秘密の数を最小限に抑えることができます。これは間違いなく良いことです。指摘する価値のあるものは2つだけです。
これで、CloudFormationを使用して、このための特別な目的のLambdaのプロビジョニングとデプロイを自動化できます。その結果、これを比較的簡単に行うことができます。私は個人的にCloudFormationの大ファンではありませんが、とにかくここで使用します。
メタデータV2エンドポイントに切り替えると、インフラストラクチャで見つかったSSRFからの追加のセキュリティや、他の形式の侵入を提供できますが、このユースケースではあまり関係ありません。