Sécurité avec Amazon Aurora MySQL - Amazon Aurora

Sécurité avec Amazon Aurora MySQL

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

  • Pour contrôler les personnes autorisées à exécuter des opérations de gestion Amazon RDS sur des clusters et des instances de base de données Aurora MySQL, vous utilisez AWS Identity and Access Management (IAM). Lorsque vous vous connectez à AWS à l'aide des informations d'identification IAM, votre compte AWS doit disposer des politiques IAM qui accordent les autorisations requises pour exécuter 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, connectez-vous d'abord à l'AWS Management Console avec vos informations d'identification 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. Ces connexions au point de terminaison et au port peuvent être effectuées à l'aide du protocole SSL (Secure Socket Layer). 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.

    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. L'authentification de base de données IAM vous permet d'utiliser les mêmes informations d'identification pour contrôler l'accès à vos ressources AWS 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 Amazon Aurora MySQL, l'utilisateur principal a les privilèges par défaut suivants :

  • ALTER

  • ALTER ROUTINE

  • CREATE

  • CREATE ROUTINE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • EVENT

  • EXECUTE

  • GRANT OPTION

  • INDEX

  • INSERT

  • LOAD FROM S3

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • SELECT

  • SHOW DATABASES

  • SHOW VIEW

  • TRIGGER

  • UPDATE

Pour fournir des services de gestion à chaque cluster de bases de données, l'utilisateur rdsadmin est créé 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.

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 SSL/TLS avec des clusters de base de données Aurora MySQL

Les clusters de bases de données Amazon Aurora MySQL prennent en charge les connexions SSL (Secure Sockets Layer) et TLS (Transport Layer Security) à partir des applications utilisant le même processus et la même clé publique que les instances de bases de données RDS pour MySQL.

Amazon RDS crée un certificat SSL/TLS et l'installe sur l'instance de base de données quand Amazon RDS alloue l'instance. Ces certificats sont signés par une autorité de certification. Le certificat SSL/TLS inclut le point de terminaison de l'instance de base de données en tant que nom commun du certificat SSL/TLS pour assurer une protection contre les attaques par usurpation. Ainsi, 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 SSL/TLS, si votre client prend en charge 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 de SSL/TLS pour chiffrer une connexion à un cluster de base de données.

Nous recommandons d'utiliser AWS JDBC Driver for MySQL comme client prenant en charge SAN avec SSL/TLS. Pour obtenir plus d'informations sur le pilote JDBC AWS pour MySQL et des instructions d'utilisation complètes, consultez le AWS JDBC Driver for MySQL GitHub repository (Référentiel GitHub du pilote JDBC AWS pour MySQL).

Exiger une connexion SSL/TLS à un cluster de base de données Aurora MySQL

Vous pouvez exiger que toutes les connexions utilisateur à votre cluster de base de données Aurora MySQL utilisent SSL/TLS à l'aide du paramètre de cluster de base 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 SSL/TLS pour les connexions à votre cluster de base 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 uniquement pour Aurora MySQL version 5.7. 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 et 1.2. 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

Aurora MySQL version 3

Pris en charge

Pris en charge

Pris en charge

Aurora MySQL version 2

Pris en charge

Pris en charge

Pris en charge

Aurora MySQL version 1

Pris en charge

Pris en charge pour Aurora MySQL 1.23.1 et versions ultérieures

Pris en charge pour Aurora MySQL 1.23.1 et versions ultérieures

Bien que MySQL Community Edition 8.0 prenne en charge TLS1.3, la version 3 d'Aurora MySQL compatible MySQL 8.0 ne prend pas en charge TLS 1.3.

Pour un cluster de base de données Aurora MySQL 5.7, vous pouvez utiliser le paramètre de cluster de base 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.2 – Seul le protocole TLS version 1.2 est autorisé pour les connexions chiffrées.

  • TLSv1.1 – Les protocoles TLS versions 1.1 et 1.2 sont autorisés pour les connexions chiffrées.

  • TLSv1 – Les protocoles TLS versions 1.0, 1.1 et 1.2 sont autorisés pour les connexions chiffrées.

Si le paramètre n'est pas défini, les protocoles TLS versions 1.0, 1.1 et 1.2 sont autorisés pour les connexions chiffrées.

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'AWS CLI pour modifier le tls_version groupe de paramètres de cluster de base de données, ApplyMethod doit avoir la valeur 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.

Note

Le paramètre de cluster de base de données tls_version n'est pas disponible pour Aurora MySQL 5.6.

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 Utilisation de SSL/TLS pour chiffrer une connexion à un cluster de base de données.

Vous pouvez exiger des connexions SSL/TLS pour des comptes utilisateur spécifiques. Par exemple, vous pouvez utiliser l'une des instructions suivantes, selon votre version MySQL, pour exiger des connexions SSL/TLS sur le compte 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 en savoir plus sur l'utilisation du proxy RDS, reportez-vous à la section Utilisation d'Amazon RDS Proxy.

Note

Pour de plus amples informations sur les connexions SSL/TLS avec MySQL, veuillez consulter la documentation MySQL.

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 SSL/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 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.

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.

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.

Définissez le paramètre ssl_cipher comme une chaîne de valeurs de chiffrement séparées par des virgules. 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.

ChiffrementProtocole de chiffrementVersions Aurora MySQL prises en charge

DHE-RSA-AES128-SHA

TLS 1.03.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

DHE-RSA-AES128-SHA256

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

DHE-RSA-AES128-GCM-SHA256

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

DHE-RSA-AES256-SHA

TLS 1.03.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

DHE-RSA-AES256-SHA256

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

DHE-RSA-AES256-GCM-SHA384

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.10.1, 2.09.3, 2.08.4, 2.07.7, 2.04.9

ECDHE-RSA-AES128-SHA

TLS 1.03.01.0 et versions ultérieures, 2.10.2, 2.09.3

ECDHE-RSA-AES128-SHA256

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.09.3

ECDHE-RSA-AES128-GCM-SHA256

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.09.3

ECDHE-RSA-AES256-SHA

TLS 1.03.01.0 et versions ultérieures, 2.10.2, 2.09.3

ECDHE-RSA-AES256-SHA384

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.09.3

ECDHE-RSA-AES256-GCM-SHA384

TLS 1.23.01.0 et versions ultérieures, 2.10.2, 2.09.3

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 5.7.

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.