View a markdown version of this page

Consideraciones de seguridad para actualizar de la versión 3 a la versión 8.4 de Aurora MySQL - Amazon Aurora

Consideraciones de seguridad para actualizar de la versión 3 a la versión 8.4 de Aurora MySQL

Al migrar de la versión 3 de Aurora MySQL (compatible con MySQL 8.0) a la versión 8.4 de Aurora MySQL, hay que tener en cuenta varios cambios importantes relacionados con la seguridad que requieren una planificación minuciosa. En esta guía se describen los principales cambios de seguridad y se proporcionan recomendaciones para una migración fluida.

Política de autenticación (novedades en la versión 8.4)

La versión 3 de Aurora MySQL (compatible con MySQL 8.0) usa el parámetro default_authentication_plugin para configurar el complemento de autenticación predeterminado utilizado al crear los usuarios de bases de datos. En la versión 8.4 de Aurora MySQL, este parámetro se sustituye por el parámetro authentication_policy, establecido en *:caching_sha2_password de forma predeterminada.

Valores admitidos en Aurora MySQL:

  • *:caching_sha2_password (valor predeterminado: permite utilizar cualquier complemento de autenticación de un solo factor mediante el uso de caching_sha2_password si no se especifica ningún otro valor).

  • *:mysql_native_password (permite cualquier complemento de autenticación de un solo factor mediante el uso de mysql_native_password si no se especifica ningún otro valor).

nota

La versión 8.4 de Aurora MySQL no admite configuraciones de autenticación multifactor.

La comprobación previa de actualización deprecatedDefaultAuth advierte si el clúster de origen tiene la opción default_authentication_plugin establecida en mysql_native_password. Revise esta advertencia y configure el parámetro authentication_policy en el grupo de parámetros del clúster de destino al realizar la actualización.

Comportamiento del usuario maestro

Nuevos clústeres

El usuario maestro se crea con el complemento de autenticación establecido por el parámetro authentication_policy en el momento de la creación del clúster. Si utiliza el grupo de parámetros predeterminado, el usuario maestro se crea con el complemento de autenticación caching_sha2_password. Si utiliza el grupo de parámetros personalizado con el parámetro authentication_policy establecido en *:mysql_native_password, el usuario maestro se crea con el complemento de autenticación mysql_native_password.

Restablecimiento de la contraseña del usuario maestro

Al restablecer la contraseña del usuario maestro, mediante la Consola de administración de AWS, la CLI (modify-db-cluster --master-user-password) o la API, Aurora utilizará el complemento predeterminado actual definido por el parámetro authentication_policy en el momento del restablecimiento.

Secrets Manager y rotación de contraseñas

Al utilizar AWS Secrets Manager para administrar la contraseña del usuario maestro, si se actualiza el valor del parámetro authentication_policy, la siguiente rotación de contraseña configurará el complemento de autenticación del usuario maestro para que coincida con el nuevo valor del parámetro authentication_policy.

Usuarios de la base de datos creados después de la actualización

Los usuarios de bases de datos existentes que utilizan el complemento de autenticación mysql_native_password seguirán funcionando después de la actualización. Los usuarios de bases de datos que cree después de la actualización sin especificar una cláusula IDENTIFIED WITH utilizan el complemento de autenticación definido por el parámetro authentication_policy. Cuando el parámetro tenga un valor predeterminado de *:caching_sha2_password, se crean nuevos usuarios con el complemento de autenticación caching_sha2_password.

Para cambiar el complemento de autenticación predeterminado para todos los usuarios nuevos, actualice el valor de authentication_policy. Para obtener más información sobre los valores admitidos, consulte Política de autenticación (novedades en la versión 8.4).

Para crear un usuario con un complemento de autenticación diferente al predeterminado, especifíquelo de forma explícita en la instrucción CREATE USER:

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

Cambios en el cifrado y en TLS

Para establecer que todas las conexiones de usuario al clúster de base de datos de Aurora MySQL utilicen TLS, use el parámetro del clúster de la base de datos require_secure_transport. De forma predeterminada, este parámetro se encuentra establecido en ON en la versión 8.4 de Aurora MySQL.

La versión 8.4 de Aurora MySQL aplica estándares criptográficos más estrictos en consonancia con los requisitos de seguridad más recientes de los parámetros de clústeres de bases de datos ssl_ciphers (TLS 1.2) y tls_ciphersuites (TLS 1.3). Para obtener más información, consulte Seguridad con Amazon Aurora MySQL.

Para evitar interrupciones en la conexión, compruebe las configuraciones de TLS del cliente de MySQL y del clúster de la base de datos de destino antes de realizar la migración.

Migración de componentes de validación de contraseñas

La versión 8.4 de Aurora MySQL incluye el parámetro del clúster aurora_enable_validate_password_component para habilitar o deshabilitar el componente validate_password, lo que elimina la necesidad de instalarlo o desinstalarlo manualmente. Si ya había instalado el complemento validate_password y, desde entonces, ha habilitado el componente tras la actualización, solo tendrá validez el componente (se ignorará el complemento).

A partir de la versión 8.4 de Aurora MySQL, si ya había instalado el complemento validate_password mediante el comando INSTALL PLUGIN, puede migrar al componente validate_password habilitando el parámetro aurora_enable_validate_password_component y, a continuación, eliminar el complemento mediante el comando UNINSTALL PLUGIN en la instancia de escritor.

Si anteriormente ha instalado de forma manual el componente validate_password mediante INSTALL COMPONENT 'file://component_validate_password', asegúrese de establecer el parámetro aurora_enable_validate_password_component en el grupo de parámetros del clúster de la base de datos de destino al realizar la actualización. Tras la actualización, el componente dejará de aparecer en la tabla mysql.component. Puede utilizar la variable global aurora_enable_validate_password_component para verificar el estado del componente.

Al iniciar por primera vez el motor de base de datos tras la actualización, aparecerá el siguiente mensaje en el registro de errores de MySQL si anteriormente había instalado el componente de forma manual:

Component 'file://component_validate_password' is being removed from mysql.component table. validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

La comprobación previa de actualización auroraValidatePasswordPluginCheck advierte si el complemento validate_password se ha instalado en el clúster de origen. Esta advertencia no bloquea la actualización, pero debería planificar la transición al componente después de realizar la actualización.

Nuevos privilegios dinámicos

La versión 8.4 de Aurora MySQL admite los siguientes privilegios nuevos:

  • ALLOW_NONEXISTENT_DEFINER

  • FLUSH_PRIVILEGES

  • OPTIMIZE_LOCAL_TABLE

  • SET_ANY_DEFINER

Estos privilegios se conceden automáticamente a los Privilegios de la cuenta de usuario maestro de las cuentas de usuario maestro en el momento de la actualización.

Aplicación de usuarios protegidos para rdsproxyadmin

A partir de la versión 8.4.7 de Aurora MySQL, rdsproxyadmin es un usuario protegido. El motor rechaza las operaciones CREATE, DROP, RENAME, GRANT, REVOKE y SET PASSWORD con respecto a rdsproxyadmin en cualquier host. Para ver la lista completa de operaciones rechazadas y ejemplos de errores, consulte Usuarios reservados en Aurora MySQL.

La versión 3 de Aurora MySQL no reserva el nombre rdsproxyadmin. Si ha creado un usuario de base de datos con el nombre rdsproxyadmin en la versión 3 (en lugar de permitir que el sistema lo cree al registrar un destino del proxy), consulte esta sección antes de actualizar a la versión 8.4.

Antes de la actualización

Si ha creado un usuario de rdsproxyadmin en el clúster de la versión 3, cambie el nombre de la cuenta o elimínela antes de actualizar a la versión 8.4. Puede usar una conexión de la versión 3 para ejecutar una de las siguientes instrucciones:

-- Rename the existing account to a non-reserved name RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host'; -- Or drop the account if it is no longer needed DROP USER 'rdsproxyadmin'@'host';

Actualice todas las aplicaciones o credenciales almacenadas que hagan referencia al nombre de usuario anterior antes de iniciar la actualización.

Si no se cambia el nombre del usuario ni se elimina antes de la actualización

Si actualiza un clúster que ya tiene un usuario de rdsproxyadmin que usted ha creado, la actualización se completará correctamente. La cuenta se conserva con su contraseña y sus privilegios actuales, y puede seguir conectándose al clúster como rdsproxyadmin con la contraseña original.

Sin embargo, después de realizar la actualización, no podrá modificar la cuenta. Si intenta eliminar la cuenta, cambiar el nombre, modificar los privilegios o cambiar la contraseña de rdsproxyadmin, la instrucción devolverá un error.

Si desea eliminar la cuenta después de la actualización o recuperar el nombre rdsproxyadmin para que lo utilice RDS Proxy, póngase en contacto con AWS Support. AWS Support puede eliminar un usuario de rdsproxyadmin que ya existía transferido de la versión 3.