Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Estrategias de rotación de la función de Lambda

Para Rotación con función de Lambda, en el caso de los secretos de base de datos, Secrets Manager ofrece dos estrategias de rotación.

Estrategia de rotación: un solo usuario

Esta estrategia actualiza las credenciales de un usuario en un secreto. En el caso de las instancias Db2 de Amazon RDS, dado que los usuarios no pueden cambiar sus propias contraseñas, debe proporcionar las credenciales de administrador en un secreto independiente. Esta es la estrategia de rotación más sencilla y es adecuada para la mayoría de los casos de uso. En particular, recomendamos que utilice esta estrategia para las credenciales de los usuarios interactivos o únicos (ad hoc).

Cuando el secreto rota, las conexiones de bases de datos abiertas no se eliminan. Mientras se produce la rotación, hay un breve periodo de tiempo entre el momento en que cambia la contraseña de la base de datos y el momento en que se actualiza el secreto. Durante este tiempo, existe un riesgo bajo de que la base de datos deniegue las llamadas que utilizan las credenciales rotadas. Puede mitigar este riesgo con una estrategia de reintentos apropiada. Tras la rotación, las nuevas conexiones utilizan las nuevas credenciales.

Estrategia de rotación: usuarios alternativos

Esta estrategia actualiza las credenciales de dos usuarios en un secreto. Se crea el primer usuario y, durante la primera rotación, la función de rotación lo clona para crear el segundo usuario. Cada vez que el secreto rota, la función de rotación alterna la contraseña de usuario que actualiza. Dado que la mayoría de los usuarios no tienen permiso para clonarse a sí mismos, debe proporcionar las credenciales de un usuario de tipo superuser en otro secreto. Recomendamos que utilice la estrategia de rotación de un solo usuario cuando los usuarios clonados en su base de datos no tienen los mismos permisos que el usuario original y para las credenciales de los usuarios interactivos o únicos (ad hoc).

Esa estrategia es adecuada para bases de datos con modelos de permisos en los que un rol es propietario de las tablas de base de datos y un segundo rol tiene permiso para acceder a las tablas de base de datos. También es adecuada para aplicaciones que requieren alta disponibilidad. Si una aplicación recupera el secreto durante la rotación, seguirá obteniendo un conjunto de credenciales válido. Tras la rotación, las credenciales de user y user_clone son válidas. Incluso hay menos posibilidades de que las aplicaciones sufran denegaciones durante este tipo de rotación que con la rotación de un solo usuario. Si la base de datos está alojada en una granja de servidores donde el cambio de contraseña tarda tiempo en propagarse a todos los servidores, existe el riesgo de que la base de datos deniegue las llamadas que utilicen las nuevas credenciales. Puede mitigar este riesgo con una estrategia de reintentos apropiada.

Secrets Manager crea el usuario clonado con los mismos permisos que el usuario original. Si cambia los permisos del usuario original después de crear el clon, también debe cambiar los permisos del usuario clonado.

Por ejemplo, si crea un secreto con las credenciales de un usuario de base de datos, el secreto contiene una versión con esas credenciales.

Primera rotación: la función de rotación crea un clon del usuario con una contraseña generada y esas credenciales se convierten en la versión del secreto actual.

Segunda rotación: la función de rotación actualiza la contraseña del usuario original.

Segunda rotación: la función de rotación actualiza la contraseña del usuario clonado.