Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Considérations relatives à la sécurité lors de la mise à niveau d'Aurora MySQL version 3 vers la version 8.4
Lors de la migration d'Aurora MySQL version 3 (compatible avec MySQL 8.0) vers Aurora MySQL version 8.4, plusieurs modifications importantes liées à la sécurité nécessitent une planification et une prise en compte minutieuses. Ce guide décrit les principaux changements de sécurité et fournit des recommandations pour une migration fluide.
**Topics**
+ [Politique d'authentification (nouvelle version de la version 8.4)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy)
+ [Maîtriser le comportement des utilisateurs](#AuroraMySQL.Upgrade-v3-v84-security.master-user)
+ [Chiffrement et modifications du protocole TLS](#AuroraMySQL.Upgrade-v3-v84-security.tls)
+ [Migration du composant de validation de mot de](#AuroraMySQL.Upgrade-v3-v84-security.validate-password)
+ [Nouveaux privilèges dynamiques](#AuroraMySQL.Upgrade-v3-v84-security.new-privileges)
+ [Application des droits d'utilisateur protégés pour `rdsproxyadmin`](#AuroraMySQL.Upgrade-v3-v84-security.rdsproxyadmin)
## Politique d'authentification (nouvelle version de la version 8.4)
Aurora MySQL version 3 (compatible avec MySQL 8.0) utilise le `default_authentication_plugin` paramètre pour configurer le plugin d'authentification par défaut utilisé lors de la création d'utilisateurs de base de données. Dans Aurora MySQL version 8.4, ce paramètre est remplacé par le `authentication_policy` paramètre défini `*:caching_sha2_password` par défaut.
Valeurs prises en charge dans Aurora MySQL :
+ `*:caching_sha2_password`(Valeur par défaut. Autorise n'importe quel plugin d'authentification à facteur unique, en utilisant (`caching_sha2_password`si aucun n'est spécifié)
+ `*:mysql_native_password`(Autorise n'importe quel plugin d'authentification à facteur unique, à utiliser `mysql_native_password` si aucun n'est spécifié)
**Note**
Multi-factor les configurations d'authentification ne sont pas prises en charge dans Aurora MySQL version 8.4.
Le précontrôle de mise à niveau [obsolète](AuroraMySQL.upgrade-prechecks.descriptions.md#deprecatedDefaultAuth) vous DefaultAuth avertit si votre cluster source est `default_authentication_plugin` défini sur. `mysql_native_password` Consultez cet avertissement et configurez le `authentication_policy` paramètre sur le groupe de paramètres de votre cluster cible lors de la mise à niveau.
## Maîtriser le comportement des utilisateurs
### Nouveaux clusters
L'utilisateur principal est créé avec le plug-in d'authentification défini par le `authentication_policy` paramètre au moment de la création du cluster. Si vous utilisez le groupe de paramètres par défaut, l'utilisateur principal est créé avec le plugin `caching_sha2_password` d'authentification. Si vous utilisez un groupe de paramètres personnalisé dont le `authentication_policy` paramètre est défini sur`*:mysql_native_password`, l'utilisateur principal est créé à l'aide du plug-in `mysql_native_password` d'authentification.
### Réinitialisation du mot de passe utilisateur principal
Lorsque vous réinitialisez le mot de passe de l'utilisateur principal AWS Management Console, via la CLI (`modify-db-cluster --master-user-password`) ou l'API, Aurora utilise le plug-in par défaut actuel défini par le `authentication_policy` paramètre au moment de la réinitialisation.
### Secrets Manager et rotation des mots de passe
Lorsque vous l'utilisez AWS Secrets Manager pour gérer le mot de passe de votre utilisateur principal, si vous mettez à jour la valeur du `authentication_policy` paramètre, la prochaine rotation du mot de passe définira le plug-in d'authentification de l'utilisateur principal pour qu'il corresponde à la nouvelle valeur du `authentication_policy` paramètre.
### Utilisateurs de base de données créés après la mise à niveau
Les utilisateurs de base de données existants qui utilisent le plug-in `mysql_native_password` d'authentification continuent de travailler après la mise à niveau. Les utilisateurs de base de données que vous créez après la mise à niveau sans spécifier de `IDENTIFIED WITH` clause utilisent le plug-in d'authentification défini par le `authentication_policy` paramètre. Lorsque le paramètre est à sa valeur par défaut de`*:caching_sha2_password`, de nouveaux utilisateurs sont créés avec le plugin `caching_sha2_password` d'authentification.
Pour modifier le plug-in d'authentification par défaut pour tous les nouveaux utilisateurs, mettez à jour la valeur de`authentication_policy`. Pour plus d'informations sur les valeurs prises en charge, consultez[Politique d'authentification (nouvelle version de la version 8.4)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy).
Pour créer un utilisateur avec un plugin d'authentification différent de celui par défaut, spécifiez-le explicitement dans l'`CREATE USER`instruction :
```
CREATE USER '{{username}}'@'{{host}}' IDENTIFIED WITH {{authentication-plugin}} BY '{{password}}';
```
## Chiffrement et modifications du protocole TLS
Pour exiger le protocole TLS pour toutes les connexions utilisateur à votre cluster de base de données Aurora MySQL, utilisez le paramètre de `require_secure_transport` cluster de base de données. Par défaut, ce paramètre est défini sur `ON` Aurora MySQL version 8.4.
Aurora MySQL version 8.4 applique des normes cryptographiques plus strictes conformes aux dernières exigences de sécurité relatives aux paramètres du cluster de bases de données `ssl_ciphers` (TLS 1.2) et `tls_ciphersuites` (TLS 1.3). Pour de plus amples informations, veuillez consulter [Sécurité avec Amazon Aurora MySQL](AuroraMySQL.Security.md).
Pour éviter les interruptions de connexion, vérifiez les configurations TLS de votre client MySQL et de votre cluster de base de données cible avant la migration.
## Migration du composant de validation de mot de
Aurora MySQL version 8.4 introduit le paramètre de `aurora_enable_validate_password_component` cluster pour activer ou désactiver le `validate_password` composant, éliminant ainsi le besoin de l'installer ou de le désinstaller manuellement. Si vous avez déjà installé le `validate_password` plugin et que vous avez depuis activé le composant après la mise à niveau, seul le composant est efficace ; le plugin est ignoré.
À partir de la version 8.4 d'Aurora MySQL, si vous avez déjà installé le `validate_password` plug-in par le biais de la `INSTALL PLUGIN` commande, vous pouvez migrer vers le `validate_password` composant en activant le paramètre, `aurora_enable_validate_password_component` puis en supprimant le plug-in via la `UNINSTALL PLUGIN` commande sur votre instance de rédacteur.
Si vous avez déjà installé le `validate_password` composant manuellement à l'aide de`INSTALL COMPONENT 'file://component_validate_password'`, assurez-vous de définir le `aurora_enable_validate_password_component` paramètre dans le groupe de paramètres de votre cluster de base de données cible lors de la mise à niveau. Après la mise à niveau, le composant ne sera plus répertorié dans le `mysql.component` tableau. Vous pouvez utiliser la variable `aurora_enable_validate_password_component` globale pour vérifier l'état du composant.
Au premier démarrage du moteur de base de données après la mise à niveau, vous verrez le message suivant dans votre journal des erreurs MySQL si vous avez déjà installé le composant manuellement :
```
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.
```
Le précontrôle de mise à niveau [Aurora](AuroraMySQL.upgrade-prechecks.descriptions.md#auroraValidatePasswordPluginCheck) vous ValidatePasswordPluginCheck avertit si le `validate_password` plugin est installé sur votre cluster source. Cet avertissement ne bloque pas la mise à niveau, mais vous devez prévoir de passer au composant après la mise à niveau.
## Nouveaux privilèges dynamiques
La version 8.4 d'Aurora MySQL prend en charge les nouveaux privilèges suivants :
+ `ALLOW_NONEXISTENT_DEFINER`
+ `FLUSH_PRIVILEGES`
+ `OPTIMIZE_LOCAL_TABLE`
+ `SET_ANY_DEFINER`
Ces privilèges sont automatiquement accordés à vos comptes d'utilisateur principaux lors de la mise à niveau. [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md)
## Application des droits d'utilisateur protégés pour `rdsproxyadmin`
À partir de la version 8.4.7 d'Aurora MySQL, `rdsproxyadmin` il est un utilisateur protégé. Le moteur rejette`CREATE`,`DROP`,`RENAME`, `GRANT``REVOKE`, et fonctionne `SET PASSWORD` contre n'`rdsproxyadmin`importe quel hôte. Pour obtenir la liste complète des opérations rejetées et des exemples d'erreurs, consultez[Utilisateurs réservés dans Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.ReservedUsers).
Aurora MySQL version 3 ne réserve pas le `rdsproxyadmin` nom. Si vous avez créé un utilisateur de base de données nommé `rdsproxyadmin` dans la version 3 (plutôt que de laisser le système le créer lorsque vous enregistrez une cible proxy), consultez cette section avant de passer à la version 8.4.
### Avant la mise à niveau
Si vous avez créé un `rdsproxyadmin` utilisateur dans votre cluster version 3, renommez ou supprimez le compte avant de passer à la version 8.4. Vous pouvez utiliser une connexion version 3 pour exécuter l'une des instructions suivantes :
```
-- 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}}';
```
Mettez à jour les applications ou les informations d'identification stockées qui font référence à l'ancien nom d'utilisateur avant de démarrer la mise à niveau.
### Si vous ne renommez pas ou ne supprimez pas l'utilisateur avant la mise à niveau
Si vous mettez à niveau un cluster qui possède déjà un `rdsproxyadmin` utilisateur que vous avez créé, la mise à niveau s'effectue correctement. Le compte est conservé avec son mot de passe et ses privilèges existants, et vous pouvez toujours vous connecter au cluster comme `rdsproxyadmin` si vous utilisiez le mot de passe d'origine.
Cependant, après la mise à niveau, vous ne pourrez pas modifier le compte. Si vous essayez de supprimer, de renommer, de modifier les privilèges ou de changer le mot de passe pour`rdsproxyadmin`, l'instruction renvoie une erreur.
[Si vous souhaitez supprimer le compte après la mise à niveau ou récupérer le `rdsproxyadmin` nom du proxy RDS à utiliser, contactez le Support AWS .](https://aws.amazon.com/premiumsupport/) AWS Support peut supprimer un `rdsproxyadmin` utilisateur préexistant reporté depuis la version 3.