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.

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 :

Le précontrôle de mise à niveau obsolète 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 deauthentication_policy. Pour plus d'informations sur les valeurs prises en charge, consultezPolitique d'authentification (nouvelle version de la version 8.4).

Pour créer un utilisateur avec un plugin d'authentification différent de celui par défaut, spécifiez-le explicitement dans l'CREATE USERinstruction :

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.

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 deINSTALL 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 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 :

Ces privilèges sont automatiquement accordés à vos comptes d'utilisateur principaux lors de la mise à niveau. Privilèges du compte utilisateur principal

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 rejetteCREATE,DROP,RENAME, GRANTREVOKE, et fonctionne SET PASSWORD contre n'rdsproxyadminimporte quel hôte. Pour obtenir la liste complète des opérations rejetées et des exemples d'erreurs, consultezUtilisateurs réservés dans Aurora MySQL.

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 pourrdsproxyadmin, 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 . AWS Support peut supprimer un rdsproxyadmin utilisateur préexistant reporté depuis la version 3.