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 My SQL

La sécurité d'Amazon Aurora My SQL est gérée à trois niveaux :

Dans les sections suivantes, consultez les informations sur les autorisations utilisateur pour Aurora My SQL et TLS les connexions avec les clusters Aurora My SQL DB.

Maîtrisez les privilèges des utilisateurs avec Amazon Aurora My SQL

Lorsque vous créez une instance Amazon Aurora My SQL DB, l'utilisateur principal dispose des privilèges par défaut répertoriés dansPrivilè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 base de données Aurora My SQL version 2, les rdsadmin utilisateurs admin et sont créés lors de la création du cluster de base de données. Dans les clusters de base de données Aurora My SQL version 3 adminrdsadmin, les rds_superuser_role utilisateurs, et sont créés.

Pour la gestion du cluster Aurora My SQL DB, la norme kill et kill_query les commandes ont été restreintes. Utilisez plutôt les RDS commandes Amazon rds_kill_query pour mettre fin rds_kill aux sessions utilisateur ou aux requêtes sur les instances Aurora My SQL DB.

TLSconnexions aux clusters Aurora My SQL DB

Les clusters Amazon Aurora My SQL DB prennent en charge les connexions Transport Layer Security (TLS) provenant d'applications en utilisant le même processus et la même clé publique que RDS pour les instances My SQL DB.

Amazon RDS crée un TLS certificat et l'installe sur l'instance de base de données lorsqu'Amazon RDS approvisionne l'instance. Ces certificats sont signés par une autorité de certification. Le TLS certificat inclut le point de terminaison de l'instance de base de données comme nom commun (CN) du TLS certificat afin de se prémunir contre les attaques par usurpation d'identité. Par conséquent, vous ne pouvez utiliser le point de terminaison du cluster de base de données pour vous connecter à un cluster de base de données que TLS si votre client prend en charge les noms alternatifs de sujet (SAN). 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 TLS deSSL/pour chiffrer une connexion à une de clusters.

Nous recommandons le AWS JDBCLe conducteur en tant que client qui soutient SAN avecTLS. Pour plus d'informations sur le AWS JDBCPilote et instructions complètes pour son utilisation, consultez le site Amazon Web Services (AWS) GitHub Référentiel de JDBC pilotes.

Exiger une TLS connexion à un cluster Aurora My SQL DB

Vous pouvez exiger que toutes les connexions utilisateur à votre cluster Aurora My SQL DB soient utilisées TLS en utilisant le paramètre de cluster de require_secure_transport base de données. Par défaut, le paramètre require_secure_transport est défini sur OFF. Vous pouvez définir le require_secure_transport paramètre comme requis ON 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 Groupes de paramètres pour Amazon Aurora.

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.

TLSversions pour Aurora My SQL

Aurora My SQL prend en charge les versions 1.0, 1.1, 1.2 et 1.3 de Transport Layer Security (TLS). À partir de SQL la version 3.04.0 et supérieure d'Aurora My, vous pouvez utiliser le protocole TLS 1.3 pour sécuriser vos connexions. Le tableau suivant indique la TLS prise en charge des SQL versions d'Aurora My.

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 TLS les nouvelles versions. Par défaut, le cluster de base de données tente d'utiliser la version de TLS protocole 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 :

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 tls_version paramètre doit inclure tous les protocoles, du 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 des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora. Si vous utilisez le plugin AWS CLI pour modifier le paramètre du tls_version cluster de base de données, le ApplyMethod 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 Aurora My SQL DB

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 sécuriser les TLS connexions 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 My SQL version 3 et Aurora My SQL version 2. Pour spécifier la liste des chiffrements TLS 1.2, TLS 1.1, TLS 1.0 autorisés pour le chiffrement des connexions, modifiez le paramètre du ssl_cipher cluster. Définissez le ssl_cipher paramètre dans un groupe de paramètres de cluster à l'aide du AWS Management Console, le AWS CLI, ou le RDSAPI.

Définissez le ssl_cipher paramètre sur une chaîne de valeurs chiffrées 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 Amazon Aurora My SQL DB.

À partir de la SQL version 3.04.0 et supérieure d'Aurora My, 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 tls_ciphersuites paramètre dans votre groupe de paramètres. TLSLa version 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 sur tls_ciphersuites une chaîne de valeurs de chiffrement séparées par des virgules pour 1.3. TLS

Le tableau suivant indique les chiffrements pris en charge ainsi que le protocole de TLS chiffrement et les versions valides SQL du moteur Aurora My pour chaque chiffrement.

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 des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora. Si vous utilisez le CLI pour modifier le paramètre du ssl_cipher cluster de base de données, assurez-vous de ApplyMethod définir le 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.

Vous pouvez également utiliser la CLI commande 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 ssl_cipher cluster pour Aurora My SQL 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 plus d'informations sur les chiffrements, consultez la variable ssl_cipher dans Ma documentation. SQL Pour plus d'informations sur les formats des suites de chiffrement, consultez la documentation sur le format de liste openssl-ciphers et le format de chaîne openssl-ciphers sur le site Web Open. SSL

Chiffrement des connexions à un cluster Aurora My SQL DB

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 My SQL 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 My SQL 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 avec le chemin complet vers votre certificat d'autorité de certification (CA). Pour plus d'informations sur le téléchargement de certificats, veuillez consulter Utilisation TLS deSSL/pour chiffrer une connexion à une de clusters.

Vous pouvez exiger des TLS connexions pour des comptes d'utilisateurs spécifiques. Par exemple, vous pouvez utiliser l'une des instructions suivantes, en fonction de votre SQL version My, pour exiger TLS des connexions sur le compte utilisateurencrypted_user.

Pour My SQL 5.7 et 8.0 :

ALTER USER 'encrypted_user'@'%' REQUIRE SSL;            

Pour My SQL 5.6 :

GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL;

Lorsque vous utilisez un RDS proxy, vous vous connectez au point de terminaison du proxy au lieu du point de terminaison du cluster habituel. Vous pouvez rendreSSL/TLSobligatoire ou facultatif pour les connexions au proxy, de la même manière que pour les connexions directes au cluster de base de données Aurora. Pour plus d'informations sur l'utilisation RDS du proxy, consultezUtilisation d'Amazon RDS Proxy pour Aurora.