Privilèges d'utilisateur principal avec Aurora MySQL.Utilisation de TLS avec les clusters de bases de données Aurora MySQL

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 AWS Identity and Access Management (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 plus d’informations, consultez Identity and Access Management pour Amazon Aurora.

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. Connectez-vous ensuite à la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
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 les VPC, consultez Amazon VPC et Amazon Aurora.

La location de VPC prise en charge dépend de la classe d'instances 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 à capacité extensible prennent uniquement en charge la location de VPC par défaut. Les classes d'instance de base de données à capacité extensible 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'instances T pour le développement et les tests.

Pour plus d'informations sur les classes d'instance, consultez Classes d'instances de base de données Aurora. Pour plus d'informations sur la location de VPC default et dedicated, consultez Instances dédiées 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 de plus amples informations, veuillez consulter Contrôle d'accès et gestion des comptes 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 plus d’informations, consultez Authentification de base de données IAM.

Note

Pour plus d'informations, consultez Sécurité dans Amazon Aurora.

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.

Pour fournir des services de gestion pour chaque cluster de base de données, les utilisateurs admin et rdsadmin sont créés lors de la création du cluster de base 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 base 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).

Utilisation de TLS avec les 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 .

Nous recommandons le pilote AWS JDBC pour MySQL en tant que client compatible avec le SAN avec TLS. Pour plus d'informations sur le pilote AWS JDBC pour MySQL et des instructions complètes pour son utilisation, consultez le référentiel du AWS pilote JDBC pour MySQL. GitHub

Rubriques

Exiger une connexion TLS à un cluster de bases de données Aurora MySQL
Versions TLS pour Aurora MySQL
Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora MySQL
Chiffrement des connexions à un cluster de base de données Aurora MySQL

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 base de données pour que la modification prenne effet. Pour plus d'informations sur les groupes de paramètres, consultez Utilisation des groupes de paramètres.

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 base 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 base 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	Pris en charge	Pris en charge	Pris en charge	Non pris en charge	Toutes les versions TLS prises en charge
Aurora MySQL version 3 (inférieure à la version 3.04.0)	Pris en charge	Pris en charge	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 version 3.04.0 ou 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 base 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 base 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.0, le paramètre tls_version doit inclure tous les protocoles, du protocole le plus bas au plus élevé. Dans ce cas, tls_version est défini comme suit :


tls_version=TLSv1,TLSv1.1,TLSv1.2

Pour plus d'informations sur la modification de paramètres dans un groupe de paramètres de cluster de base de données, consultez Modification de paramètres dans un groupe de paramètres de cluster de base de données. 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 surpending-reboot. Lorsque la méthode d'application estpending-reboot, les modifications des paramètres sont appliquées après l'arrêt et le redémarrage des clusters de base 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.

À 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
`DHE-RSA-AES128-SHA`	TLS 1.0	Versions 3.01.0 et ultérieures, toutes versions antérieures à 2.11.0
`DHE-RSA-AES128-SHA256`	TLS 1.2	Versions 3.01.0 et ultérieures, toutes versions antérieures à 2.11.0
`DHE-RSA-AES128-GCM-SHA256`	TLS 1.2	Versions 3.01.0 et ultérieures, toutes versions antérieures à 2.11.0
`DHE-RSA-AES256-SHA`	TLS 1.0	Versions 3.03.0 et antérieures, toutes les versions antérieures à 2.11.0
`DHE-RSA-AES256-SHA256`	TLS 1.2	Versions 3.01.0 et ultérieures, toutes versions antérieures à 2.11.0
`DHE-RSA-AES256-GCM-SHA384`	TLS 1.2	Versions 3.01.0 et ultérieures, toutes versions antérieures à 2.11.0
`ECDHE-RSA-AES128-SHA`	TLS 1.0	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 et versions ultérieures
`ECDHE-RSA-AES128-SHA256`	TLS 1.2	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 et versions ultérieures
`ECDHE-RSA-AES128-GCM-SHA256`	TLS 1.2	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 et versions ultérieures
`ECDHE-RSA-AES256-SHA`	TLS 1.0	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 et versions ultérieures
`ECDHE-RSA-AES256-SHA384`	TLS 1.2	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 et versions ultérieures
`ECDHE-RSA-AES256-GCM-SHA384`	TLS 1.2	3.01.0 et versions ultérieures, 2.09.3 et versions ultérieures, 2.10.2 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

Note

Les chiffrements DHE-RSA ne sont pris en charge que par les versions d'Aurora MySQL antérieures à 2.11.0. Les versions 2.11.0 et ultérieures ne prennent en charge que les chiffrements ECDHE.

Pour plus d'informations sur la modification de paramètres dans un groupe de paramètres de cluster de base de données, consultez Modification de paramètres dans un groupe de paramètres de cluster de base de données. Si vous utilisez l'interface CLI pour modifier le paramètre ssl_cipher du cluster de base de données, veillez à définir le paramètre ApplyMethod sur pending-reboot. Lorsque la méthode d'application estpending-reboot, les modifications des paramètres sont appliquées après l'arrêt et le redémarrage des clusters de base de données associés au groupe de paramètres.

Vous pouvez également utiliser la commande CLI describe-engine-default-cluster-parameters 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": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384",
		"Description": "The list of permissible ciphers for connection encryption.",
		"Source": "system",
		"ApplyType": "static",
		"DataType": "list",
		"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384",
		"IsModifiable": true,
		"SupportedEngineModes": [
			"provisioned"
		]
	},
       ...some output truncated...

Pour obtenir plus d'informations sur les chiffrements, consultez la variable ssl_cipher dans la documentation MySQL. Pour plus d'informations sur les formats de suite de chiffrement, veuillez consulter les documentations relatives aux format de liste openssl-ciphers et format de chaîne openssl-ciphers sur le site Web d'OpenSSL.

Chiffrement des connexions à un cluster de base 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

Remplacez full_path_to_CA_certificate par le chemin complet vers votre certificat d'une autorité de certification (CA). Pour plus d'informations sur le téléchargement de certificats, veuillez consulter .

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 le certificat SSL/TLS obligatoire ou facultatif pour les connexions au proxy, comme pour les connexions directes au cluster de base de données Aurora. Pour obtenir des informations sur l'utilisation du proxy RDS, consultez Utilisation d'Amazon RDS Proxy pour Aurora.

Note

Pour plus d'informations sur les connexions TLS avec MySQL, consultez la documentation MySQL.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Aurora MySQL version 2 compatible avec MySQL 5.7

Mise à jour des applications pour les nouveaux certificats TLS