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. # Sécurité avec Amazon Aurora MySQL La sécurité d’Amazon Aurora MySQL est gérée à trois niveaux : + Pour contrôler qui peut effectuer des actions de gestion Amazon RDS sur les clusters de base de données et les instances de base de données Aurora MySQL, vous utilisez Gestion des identités et des accès AWS (IAM). Lorsque vous vous connectez à AWS l'aide d'informations d'identification IAM, votre AWS compte doit disposer de politiques IAM qui accordent les autorisations requises pour effectuer les opérations de gestion Amazon RDS. Pour de plus amples informations, consultez [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md). Si vous utilisez IAM pour accéder à la console Amazon RDS, assurez-vous d'abord de vous connecter à l'aide de vos informations AWS Management Console d'identification utilisateur IAM. Accédez ensuite à la console Amazon RDS à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. + Les clusters de base de données Aurora MySQL doivent être créés dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Pour contrôler les appareils et les instances Amazon EC2 qui peuvent ouvrir des connexions au point de terminaison et au port de l’instance de base de données pour les clusters de bases de données Aurora MySQL d’un VPC, utilisez un groupe de sécurité VPC. Vous pouvez établir ces connexions entre les points de terminaison et les ports en utilisant le protocole TLS (Transport Layer Security). En outre, les règles de pare-feu de votre entreprise peuvent contrôler si les appareils en cours d’exécution dans votre entreprise peuvent ouvrir des connexions à une instance de base de données. Pour plus d'informations sur VPCs, voir[Amazon VPC et Amazon Aurora](USER_VPC.md). La location de VPC prise en charge dépend de la classe d’instance de base de données utilisée par vos clusters de bases de données Aurora MySQL. Avec la location de VPC `default`, le VPC s’exécute sur du matériel partagé. Avec la location de VPC `dedicated`, le VPC s’exécute sur une instance de matériel dédiée. Les classes d’instance de base de données à performances extensibles prennent uniquement en charge la location de VPC par défaut. Les classes d’instance de base de données à performances extensibles incluent les classes d’instance de base de données db.t2, db.t3 et db.t4g. Toutes les autres classes d’instance de base de données MySQL Aurora prennent en charge à la fois la location de VPC par défaut et dédiée. **Note** Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez [Utilisation de classes d’instance T pour le développement et les tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium). Pour plus d’informations sur les classes d’instance, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). Pour plus d’informations sur la location de VPC `default` et `dedicated`, consultez [Instances dédiées](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*. + Pour authentifier la connexion et les autorisations d’un cluster de bases de données Amazon Aurora MySQL, vous pouvez adopter l’une des approches suivantes, ou les combiner : + Vous pouvez adopter la même approche qu’avec une instance autonome de MySQL. Les commandes telles que `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` et `SET PASSWORD` fonctionnent de la même façon que dans les bases de données sur site, comme le fait la modification directe des tables du schéma de base de données. Pour plus d’informations, consultez [Contrôle d’accès et gestion des comptes](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) dans la documentation MySQL. + Vous pouvez également utiliser l’authentification de base de données IAM. L’authentification de base de données IAM vous permet de vous authentifier sur votre cluster de bases de données à l’aide d’un utilisateur IAM ou d’un rôle IAM et d’un jeton d’authentification. Un *jeton d’authentification* est une valeur unique qui est générée à l’aide du processus de signature Signature Version 4. En utilisant l'authentification de base de données IAM, vous pouvez utiliser les mêmes informations d'identification pour contrôler l'accès à vos AWS ressources et à vos bases de données. Pour de plus amples informations, veuillez consulter [Authentification de base de données IAM](UsingWithRDS.IAMDBAuth.md). **Note** Pour plus d’informations, consultez [Sécurité dans )](UsingWithRDS.md). Dans les sections suivantes, consultez les informations sur les autorisations utilisateur pour les connexions Aurora MySQL et TLS avec les clusters de bases de données Aurora MySQL. **Topics** + [Privilèges d’utilisateur principal avec Amazon Aurora MySQL.](#AuroraMySQL.Security.MasterUser) + [Connexions TLS aux clusters de bases de données Aurora MySQL](#AuroraMySQL.Security.SSL) ## Privilèges d’utilisateur principal avec Amazon Aurora MySQL. Lorsque vous créez une instance de base de données MySQL Amazon Aurora, l’utilisateur principal dispose des privilèges par défaut répertoriés dans [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md). Pour fournir des services de gestion pour chaque cluster de bases de données, les utilisateurs `admin` et `rdsadmin` sont créés lors de la création du cluster de bases de données. Les tentatives de supprimer, renommer et modifier le mot de passe du compte `rdsadmin`, ou d’en modifier les privilèges, génèrent une erreur. Dans les clusters de bases de données Aurora MySQL version 2, les utilisateurs `admin` et `rdsadmin` sont créés lors de la création du cluster de bases de données. Dans les clusters de bases de données Aurora MySQL version 3, les utilisateurs `admin`, `rdsadmin` et `rds_superuser_role` sont créés. **Important** Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application. Pour la gestion du cluster de bases de données Aurora MySQL, les commandes standard `kill` et `kill_query` ont fait l’objet de restrictions. Utilisez à la place les commandes Amazon RDS `rds_kill` et `rds_kill_query` pour arrêter les sessions utilisateur ou les requêtes sur les instances de base de données Aurora MySQL. **Note** Le chiffrement d’une instance de base de données et des instantanés n’est pas pris en charge pour la région Chine (Ningxia). ## Connexions TLS aux clusters de bases de données Aurora MySQL Les clusters de bases de données Amazon Aurora MySQL prennent en charge les connexions TLS (Transport Layer Security) à partir des applications utilisant le même processus et la même clé publique que les instances de base de données RDS for MySQL. Amazon RDS crée un certificat TLS et l’installe sur l’instance de base de données quand Amazon RDS met en service l’instance. Ces certificats sont signés par une autorité de certification. Le certificat TLS inclut le point de terminaison de l’instance de base de données en tant que nom commun (CN) du certificat TLS pour assurer une protection contre les attaques par usurpation. Par conséquent, vous pouvez utiliser uniquement le point de terminaison de cluster de bases de données pour vous connecter à un cluster de bases de données à l’aide de TLS, si votre client prend en charge les noms SAN (Subject Alternative Names). Sinon, vous devez utilisez le point de terminaison d’instance d’une instance de dispositif d’écriture. Pour de plus amples informations sur le téléchargement de certificats, veuillez consulter [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md). Nous recommandons le pilote AWS JDBC en tant que client prenant en charge le SAN avec TLS. Pour plus d'informations sur le pilote AWS JDBC et des instructions complètes pour son utilisation, consultez le référentiel de pilotes [JDBC Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-jdbc-wrapper). GitHub **Topics** + [Exiger une connexion TLS à un cluster de bases de données Aurora MySQL](#AuroraMySQL.Security.SSL.RequireSSL) + [Versions TLS pour Aurora MySQL](#AuroraMySQL.Security.SSL.TLS_Version) + [Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora MySQL](#AuroraMySQL.Security.SSL.ConfiguringCipherSuites) + [Chiffrement des connexions à un cluster de bases de données Aurora MySQL](#AuroraMySQL.Security.SSL.EncryptingConnections) ### Exiger une connexion TLS à un cluster de bases de données Aurora MySQL Vous pouvez exiger que toutes les connexions utilisateur à votre cluster de bases de données Aurora MySQL utilisent TLS à l’aide du paramètre de cluster de bases de données `require_secure_transport`. Par défaut, le paramètre `require_secure_transport` est défini sur `OFF`. Vous pouvez définir le paramètre `require_secure_transport` sur `ON` pour exiger TLS pour les connexions à votre cluster de bases de données. Vous pouvez définir la valeur du paramètre `require_secure_transport` en mettant à jour le groupe de paramètres pour votre cluster de bases de données. Vous n’avez pas besoin de redémarrer votre cluster de bases de données pour que la modification prenne effet. Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). **Note** Le paramètre `require_secure_transport` est disponible pour Aurora MySQL versions 2 et 3. Vous pouvez définir ce paramètre dans un groupe de paramètres de cluster de bases de données personnalisé. Le paramètre n’est pas disponible dans les groupes de paramètres d’instance de base de données. Lorsque le paramètre `require_secure_transport` est défini sur `ON` pour un cluster de bases de données, un client de base de données peut s’y connecter s’il peut établir une connexion chiffrée. Sinon, un message d’erreur similaire au suivant est renvoyé au client : ``` MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` ### Versions TLS pour Aurora MySQL Aurora MySQL prend en charge le protocole TLS (Transport Layer Security) versions 1.0, 1.1, 1.2 et 1.3. À partir d’Aurora MySQL version 3.04.0, vous pouvez utiliser le protocole TLS 1.3 pour sécuriser vos connexions. Le tableau suivant affiche la prise en charge du protocole TLS pour les versions Aurora MySQL. **** | Aurora MySQL Version | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Par défaut | | --- | --- | --- | --- | --- | --- | | Aurora MySQL version 2 | Obsolète | Obsolète | Pris en charge | Non pris en charge | Toutes les versions TLS prises en charge | | Aurora MySQL version 3 (antérieure à 3.04.0) | Obsolète | Obsolète | Pris en charge | Non pris en charge | Toutes les versions TLS prises en charge | | Aurora MySQL version 3 (3.04.0 et versions ultérieures) | Non pris en charge | Non pris en charge | Pris en charge | Pris en charge | Toutes les versions TLS prises en charge | **Important** Si vous utilisez des groupes de paramètres personnalisés pour vos clusters Aurora MySQL de version 2 ou de version antérieure à 3.04.0, nous vous recommandons d’utiliser TLS 1.2, car les protocoles TLS 1.0 et 1.1 sont moins sécurisés. L’édition communautaire de MySQL 8.0.26 et Aurora MySQL 3.03 et ses versions mineures ont rendu obsolète la prise en charge de TLS versions 1.1 et 1.0. L’édition communautaire de MySQL 8.0.28 et les versions 3.04.0 et ultérieures compatibles d’Aurora MySQL ne prennent pas en charge TLS 1.1 ni TLS 1.0. Si vous utilisez Aurora MySQL 3.04.0 ou version ultérieure, ne définissez pas le protocole TLS sur 1.0 ni 1.1 dans votre groupe de paramètres personnalisés. Pour Aurora MySQL version 3.04.0 ou ultérieure, les paramètres par défaut sont TLS 1.3 et TLS 1.2. Vous pouvez utiliser le paramètre de cluster de bases de données `tls_version` pour indiquer les versions de protocole autorisées. Des paramètres client similaires existent pour la plupart des outils client ou des pilotes de base de données. Certains clients plus anciens peuvent ne pas prendre en charge les versions TLS plus récentes. Par défaut, le cluster de bases de données tente d’utiliser la version de protocole TLS la plus élevée autorisée par la configuration du serveur et du client. Définissez le paramètre de cluster de bases de données `tls_version` sur l’une des valeurs suivantes : + `TLSv1.3` + `TLSv1.2` + `TLSv1.1` + `TLSv1` Vous pouvez également définir le paramètre `tls_version` sous forme de chaîne de liste séparée par des virgules. Si vous souhaitez utiliser à la fois les protocoles TLS 1.2 et TLS 1.3, le paramètre `tls_version` doit inclure tous les protocoles, du plus bas au plus élevé. Dans ce cas, `tls_version` est défini comme suit : ``` tls_version=TLSv1.2,TLSv1.3 ``` Pour plus d’informations sur la modification de paramètres dans un groupe de paramètres de cluster de bases de données, consultez [Modification des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). Si vous utilisez le AWS CLI pour modifier le paramètre du `tls_version` cluster de base de données, `ApplyMethod` il doit être défini sur`pending-reboot`. Lorsque la méthode d’application est`pending-reboot`, les modifications des paramètres sont appliquées après l’arrêt et le redémarrage des clusters de bases de données associés au groupe de paramètres. ### Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora MySQL L’utilisation de suites de chiffrement configurables vous permet d’avoir plus de contrôle sur la sécurité des connexions de vos bases de données. Vous pouvez spécifier une liste de suites de chiffrement que vous souhaitez autoriser pour la sécurisation des connexions TLS client à votre base de données. Avec les suites de chiffrement configurables, vous pouvez contrôler le chiffrement de connexion accepté par votre serveur de base de données. Cela permet d’éviter l’utilisation de codes de chiffrement non sécurisés ou rendus obsolètes. Les suites de chiffrement configurables sont prises en charge dans Aurora MySQL version 3 et Aurora MySQL version 2. Pour spécifier la liste des chiffrements TLS 1.2, TLS 1.1 et TLS 1.0 autorisés pour le chiffrement des connexions, modifiez le paramètre de cluster `ssl_cipher`. Définissez le paramètre `ssl_cipher` dans un groupe de paramètres de cluster utilisant l’ AWS Management Console, l’ AWS CLI, ou l’API RDS. Définissez le paramètre `ssl_cipher` comme une chaîne de valeurs de chiffrement séparées par des virgules pour votre version TLS. Pour l’application client, vous pouvez spécifier les chiffrements à utiliser pour les connexions chiffrées en utilisant l’option `--ssl-cipher` lors de la connexion à la base de données. Pour obtenir plus d’informations sur la connexion à votre base de données, consultez [Connexion à un cluster de bases de données Amazon Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.AuroraMySQL). À partir d’Aurora MySQL version 3.04.0, vous pouvez spécifier des suites de chiffrement TLS 1.3. Pour spécifier les suites de chiffrement TLS 1.3 autorisées, modifiez le paramètre `tls_ciphersuites` de votre groupe de paramètres. TLS 1.3 a réduit le nombre de suites de chiffrement disponibles en raison de modifications apportées à la convention de dénomination qui supprime le mécanisme d’échange de clés et le certificat utilisés. Définissez le paramètre `tls_ciphersuites` comme une chaîne de valeurs de chiffrement séparées par des virgules pour TLS 1.3. Le tableau suivant présente les chiffrements pris en charge ainsi que le protocole de chiffrement TLS et les versions valides du moteur Aurora MySQL pour chaque chiffrement. | Chiffrement | Protocole de chiffrement | Versions Aurora MySQL prises en charge | | --- | --- | --- | | `ECDHE-RSA-AES128-SHA` | TLS 1.0 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-RSA-AES128-SHA256` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-RSA-AES128-GCM-SHA256` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-RSA-AES256-SHA` | TLS 1.0 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-RSA-AES256-GCM-SHA384` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-RSA-CHACHA20-POLY1305` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-ECDSA-AES128-SHA` | TLS 1.0 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-ECDSA-AES256-SHA` | TLS 1.0 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-ECDSA-AES128-GCM-SHA256` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-ECDSA-AES256-GCM-SHA384` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `ECDHE-ECDSA-CHACHA20-POLY1305` | TLS 1.2 | 3.04.0 et versions ultérieures, 2.11.0 et versions ultérieures | | `TLS_AES_128_GCM_SHA256` | TLS 1.3 | Versions 3.04.0 et ultérieures | | `TLS_AES_256_GCM_SHA384` | TLS 1.3 | Versions 3.04.0 et ultérieures | | `TLS_CHACHA20_POLY1305_SHA256` | TLS 1.3 | Versions 3.04.0 et ultérieures | Pour plus d’informations sur la modification de paramètres dans un groupe de paramètres de cluster de bases de données, consultez [Modification des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). Si vous utilisez l’interface CLI pour modifier le paramètre `ssl_cipher` du cluster de bases de données, veillez à définir le paramètre `ApplyMethod` sur `pending-reboot`. Lorsque la méthode d’application est`pending-reboot`, les modifications des paramètres sont appliquées après l’arrêt et le redémarrage des clusters de bases de données associés au groupe de paramètres. Vous pouvez également utiliser la commande CLI [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) pour déterminer quelles suites de chiffrement sont actuellement prises en charge pour une famille de groupes de paramètres spécifique. L’exemple suivant montre comment obtenir les valeurs autorisées pour le paramètre de cluster `ssl_cipher` pour Aurora MySQL version 2. ``` aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-mysql5.7 ...some output truncated... { "ParameterName": "ssl_cipher", "ParameterValue": "ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-SHA,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES128-SHA", "Description": "The list of permissible ciphers for connection encryption.", "Source": "system", "ApplyType": "static", "DataType": "list", "AllowedValues": "ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-SHA,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES128-SHA", "IsModifiable": true, "SupportedEngineModes": [ "provisioned" ] }, ...some output truncated... ``` Pour obtenir plus d’informations sur les chiffrements, consultez la variable [ssl\$1cipher](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_ssl_cipher) dans la documentation MySQL. Pour plus d’informations sur les formats de suite de chiffrement, consultez les documentations relatives aux [format de liste openssl-ciphers](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-LIST-FORMAT) et [format de chaîne openssl-ciphers](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS) sur le site Web d’OpenSSL. ### Chiffrement des connexions à un cluster de bases de données Aurora MySQL Pour chiffrer les connexions à l’aide du client `mysql` par défaut, lancez le client mysql à l’aide du paramètre `--ssl-ca` pour référencer la clé publique. Par exemple : Pour MySQL 5.7 et 8.0 : ``` mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=full_path_to_CA_certificate --ssl-mode=VERIFY_IDENTITY ``` Pour MySQL 5.6 : ``` mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=full_path_to_CA_certificate --ssl-verify-server-cert ``` *full\$1path\$1to\$1CA\$1certificate*Remplacez-le par le chemin complet de votre certificat d'autorité de certification (CA). Pour plus d’informations sur le téléchargement d’un certificat, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md). Vous pouvez exiger des connexions TLS pour des comptes d’utilisateur spécifiques. Par exemple, vous pouvez utiliser l’une des instructions suivantes, selon votre version de MySQL, pour exiger des connexions TLS sur le compte d’utilisateur `encrypted_user`. Pour MySQL 5.7 et 8.0 : ``` ALTER USER 'encrypted_user'@'%' REQUIRE SSL; ``` Pour MySQL 5.6 : ``` GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL; ``` Lorsque vous utilisez un proxy RDS, vous vous connectez au point de terminaison du proxy et non au point de terminaison de cluster habituel. Vous pouvez rendre SSL/TLS obligatoires ou facultatives les connexions au proxy, de la même manière que pour les connexions directes au cluster de base de données Aurora. Pour obtenir des informations sur l’utilisation du proxy RDS, consultez [Proxy Amazon RDS pour Aurora](rds-proxy.md). **Note** Pour plus d’informations sur les connexions TLS avec MySQL, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html).