# 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.
**Topics**
+ [Política de autenticación (novedades en la versión 8.4)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy)
+ [Comportamiento del usuario maestro](#AuroraMySQL.Upgrade-v3-v84-security.master-user)
+ [Cambios en el cifrado y en TLS](#AuroraMySQL.Upgrade-v3-v84-security.tls)
+ [Migración de componentes de validación de contraseñas](#AuroraMySQL.Upgrade-v3-v84-security.validate-password)
+ [Nuevos privilegios dinámicos](#AuroraMySQL.Upgrade-v3-v84-security.new-privileges)
+ [Aplicación de usuarios protegidos para `rdsproxyadmin`](#AuroraMySQL.Upgrade-v3-v84-security.rdsproxyadmin)
## 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](AuroraMySQL.upgrade-prechecks.descriptions.md#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)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy).
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](AuroraMySQL.Security.md).
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](AuroraMySQL.upgrade-prechecks.descriptions.md#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](UsingWithRDS.MasterAccounts.md) 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](AuroraMySQL.Security.md#AuroraMySQL.Security.ReservedUsers).
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](https://aws.amazon.com/premiumsupport/). AWS Support puede eliminar un usuario de `rdsproxyadmin` que ya existía transferido de la versión 3.