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. # Protection des données à l’aide du chiffrement Amazon Aurora chiffre les ressources de base de données au niveau de la couche de stockage. Vous pouvez également chiffrer les connexions aux clusters de base de données. **Topics** + [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md) + [AWS KMS key gestion](Overview.Encryption.Keys.md) + [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md) + [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md) # Chiffrement des ressources Amazon Aurora Amazon Aurora protège vos données à la fois au repos et en transit, qu'elles soient transférées entre des clients sur site et Amazon Aurora, ou entre Amazon Aurora et d'autres ressources. AWS Amazon Aurora chiffre toutes les données utilisateur de vos clusters de base de données Amazon Aurora, y compris les journaux, les sauvegardes automatisées et les instantanés. Une fois vos données chiffrées, Amazon Aurora gère l'authentification de l'accès et le déchiffrement de vos données de manière transparente avec un impact minimal sur les performances. Vous n’avez pas besoin de modifier vos applications clientes de base de données pour utiliser le chiffrement. **Note** Pour les clusters d' de base de données chiffrés et non chiffrés, les données en transit entre la source et les répliques lues sont chiffrées, même lors de la réplication entre régions. AWS **Topics** + [Présentation du chiffrement dans les ressources Amazon Aurora](#Overview.Encryption.Overview) + [Chiffrement d’un cluster de bases de données Amazon Aurora](#Overview.Encryption.Enabling) + [Détermination si le chiffrement est activé pour un cluster de bases de données](#Overview.Encryption.Determining) + [Disponibilité du chiffrement Amazon Aurora](#Overview.Encryption.Availability) + [Chiffrement en transit](#Overview.Encryption.InTransit) + [Limitations des clusters de bases de données chiffrées Amazon Aurora](#Overview.Encryption.Limitations) ## Présentation du chiffrement dans les ressources Amazon Aurora Les clusters de base de données chiffrée Amazon Aurora fournissent une couche supplémentaire de protection des données en sécurisant vos données contre tout accès non autorisé au stockage sous-jacent. Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après 2026 dans Amazon Aurora sont chiffrés au repos à l'aide du chiffrement AES-256 conforme aux normes du secteur. Ce chiffrement s'effectue automatiquement en arrière-plan, sécurisant ainsi vos données sans aucune action de votre part. Cela permet également de réduire la charge opérationnelle et la complexité liées à la protection des données sensibles. Avec le chiffrement au repos, vous pouvez protéger les applications sensibles en termes de conformité et de sécurité contre les menaces accidentelles et malveillantes, tout en respectant les exigences réglementaires. Amazon Aurora utilise une AWS Key Management Service clé pour chiffrer ces ressources. AWS KMS combine du matériel et des logiciels sécurisés et hautement disponibles pour fournir un système de gestion des clés adapté au cloud. Lors de la création d'un nouveau cluster de bases de données, Amazon Aurora utilise le chiffrement côté serveur (SSE) avec une [cléAWS détenue par défaut](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key). Toutefois, vous pouvez choisir entre trois types de chiffrement en fonction de vos besoins en matière de sécurité et de conformité : + **AWS clé possédée (SSE-RDS)** : clé de chiffrement entièrement AWS contrôlée que vous ne pouvez ni visualiser ni gérer, utilisée automatiquement par Aurora pour le chiffrement par défaut. + **AWS clé gérée (AMK)** — Cette clé est créée et gérée par AWS et est visible dans votre compte, mais elle n'est pas personnalisable. Il n'y a pas de frais mensuels, mais des frais AWS KMS d'API s'appliqueront. + **Clé gérée par le client (CMK)** — La clé est stockée dans votre compte et vous la créez, la détenez et la gérez. Vous avez le contrôle total de la clé KMS (AWS KMS des frais s'appliquent). AWS les clés gérées constituent une ancienne option de chiffrement qui reste disponible à des fins de rétrocompatibilité. Amazon Aurora utilise des clés AWS détenues par défaut pour chiffrer vos données, offrant ainsi une protection de sécurité renforcée sans frais supplémentaires ni frais de gestion. Dans la plupart des cas d'utilisation, nous recommandons d'utiliser soit la clé AWS détenue par défaut pour des raisons de simplicité et de rentabilité, soit une clé gérée par le client (CMK) si vous avez besoin d'un contrôle total sur vos clés de chiffrement. Pour plus d'informations sur les types de clés, consultez les [sections clés gérées par le client et clés AWS gérées](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt). **Note** **Important :** pour les instances de base de données source ou les clusters créés avant le 18 février 2026, pour lesquels vous n'avez pas opté pour le chiffrement, les instantanés, les clones et les répliques Amazon Aurora (instance de lecture) créés à partir de ces sources ne seront pas chiffrés. Cependant, les opérations de restauration et de réplication logique en dehors du cluster Amazon Aurora produiront des instances chiffrées. Pour un cluster de bases de données chiffrée Amazon Aurora, les instances de bases de données, journaux, sauvegardes et instantanés sont tous chiffrés. Pour plus d’informations sur la disponibilité et les limites du chiffrement, consultez [Disponibilité du chiffrement Amazon Aurora](#Overview.Encryption.Availability) et [Limitations des clusters de bases de données chiffrées Amazon Aurora](#Overview.Encryption.Limitations). Lorsque vous créez un cluster de bases de données chiffré, vous pouvez choisir une clé gérée par le client ou une clé Clé gérée par AWS pour Amazon Aurora pour chiffrer votre cluster de bases de données. Si vous ne spécifiez pas l'identifiant de clé pour une clé gérée par le client, Amazon Aurora l'utilise Clé gérée par AWS pour votre nouveau cluster de bases de données. Amazon Aurora crée un Clé gérée par AWS pour Amazon Aurora pour votre AWS compte. Votre AWS compte est associé à un compte Amazon Aurora différent Clé gérée par AWS pour chaque AWS région. Pour gérer les clés gérées par le client qui sont utilisées pour le chiffrement et le déchiffrement de vos ressources Amazon Aurora, vous utilisez [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/). À l'aide de AWS KMS, vous pouvez créer des clés gérées par le client et définir les politiques permettant de contrôler l'utilisation de ces clés gérées par le client. AWS KMS prend en charge CloudTrail, afin que vous puissiez auditer l'utilisation des clés KMS afin de vérifier que les clés gérées par le client sont utilisées de manière appropriée. Vous pouvez utiliser vos clés gérées par le client avec Amazon Aurora et les AWS services pris en charge tels qu'Amazon S3, Amazon EBS et Amazon Redshift. Pour obtenir la liste des services intégrés AWS KMS, consultez la section [Intégration des AWS services](https://aws.amazon.com/kms/features/#AWS_Service_Integration). Quelques considérations relatives à l’utilisation des clés KMS : + Une fois que vous avez créé une instance de base de données chiffrée, vous ne pouvez pas modifier la clé KMS utilisée par cette instance. Assurez-vous de déterminer vos exigences en matière de clé KMS avant de créer votre instance de base de données chiffrée. Si vous devez modifier la clé de chiffrement de votre cluster de base de données, procédez comme suit : + Créez un instantané manuel de votre cluster. + Restaurez le snapshot et activez le chiffrement avec la clé KMS de votre choix pendant l'opération de restauration. + Si vous restaurez un instantané non chiffré et que vous choisissez de ne pas chiffrer, le cluster de base de données créé sera chiffré à l'aide du chiffrement par défaut au repos (cléAWS détenue par -owned). + Vous ne pouvez pas partager un instantané chiffré à l'aide Clé gérée par AWS du AWS compte qui l'a partagé. + Chaque instance de base de données du cluster de base de données partage le même stockage chiffré avec la même clé KMS. **Important** Dans certains cas, Amazon Aurora peut perdre l’accès à la clé KMS pour un cluster de bases de données lorsque vous désactivez la clé KMS. Dans ce cas, le cluster de bases de données chiffré entre dans l’état `inaccessible-encryption-credentials-recoverable`. Le cluster de bases de données reste dans cet état pendant sept jours, pendant lesquels l’instance est arrêtée. Les appels d’API effectués vers le cluster de bases de données pendant cette période risquent d’échouer. Pour restaurer le cluster de bases de données, activez la clé KMS, puis redémarrez le cluster. Vous pouvez activer la clé KMS depuis l'API AWS Management Console AWS CLI, ou RDS. Redémarrez le cluster de base de données à l'aide de la AWS CLI commande [start-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html)ou AWS Management Console. L’état `inaccessible-encryption-credentials-recoverable` s’applique uniquement aux clusters de bases de données qui peuvent être interrompus. Cet état récupérable ne s’applique pas aux instances qui ne peuvent pas s’arrêter, telles que les clusters contenant des réplicas en lecture inter-régions. Pour plus d’informations, consultez [Limites liées à l’arrêt et au démarrage des clusters de bases de données Aurora](aurora-cluster-stop-start.md#aurora-cluster-stop-limitations). Si le cluster de bases de données n’est pas récupéré dans un délai de sept jours, il passe à l’état `inaccessible-encryption-credentials` terminal. Dans cet état, le cluster de bases de données n’est plus utilisable et vous ne pouvez le restaurer qu’à partir d’une sauvegarde. Nous vous recommandons vivement de toujours activer les sauvegardes pour éviter la perte de données dans vos bases de données. Lors de la création d’un cluster de bases de données, Aurora vérifie si le principal appelant dispose a accès à la clé KMS, puis génère une autorisation à partir de cette clé KMS, qu’il utilisera pendant toute la durée de vie du cluster de bases de données. La révocation de l’accès du principal appelant à la clé KMS n’affecte pas la base de données en cours d’exécution. Lorsque vous utilisez des clés KMS dans des scénarios entre comptes, tels que la copie d’un instantané sur un autre compte, la clé KMS doit être partagée avec l’autre compte. Si vous créez un cluster de bases de données à partir de l’instantané sans spécifier de clé KMS différente, le nouveau cluster utilise la clé KMS du compte source. Le fait de révoquer l’accès à la clé après la création du cluster de bases de données n’a aucun impact sur ce cluster. Toutefois, la désactivation de la clé affecte tous les clusters de bases de données chiffrés avec cette clé. Afin d’éviter cette situation, indiquez une clé différente au moment de la copie de l’instantané. Pour plus d’informations sur les clés KMS, consultez [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) dans le *Guide du développeur AWS Key Management Service * et [AWS KMS key gestion](Overview.Encryption.Keys.md). ## Chiffrement d’un cluster de bases de données Amazon Aurora Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après cette date sont chiffrés par défaut à l'aide d'une clé AWS détenue. Pour chiffrer un nouveau cluster de base de données à l'aide d'une clé gérée par le client Clé gérée par AWS ou d'une clé gérée par le client, choisissez l'option sur la console. Pour plus d’informations sur la création d’un cluster de bases de données, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). Si vous utilisez la [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI commande pour créer un cluster de base de données chiffré, définissez le `--storage-encrypted` paramètre. Si vous utilisez l'opération [Create DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) API, définissez le `StorageEncrypted` paramètre sur true. Une fois que vous avez créé un cluster de bases de données chiffrées, vous ne pouvez pas modifier la clé KMS pour ce cluster de bases de données. Vous devez donc prendre soin de déterminer vos besoins en termes de clés KMS avant de créer votre cluster de base de données chiffrées. Si vous utilisez la AWS CLI `create-db-cluster` commande pour créer un cluster de base de données chiffré avec une clé gérée par le client, définissez le `--kms-key-id` paramètre sur n'importe quel identifiant de clé pour la clé KMS. Si vous utilisez l’opération Amazon RDS de l’API `CreateDBInstance`, définissez le paramètre `KmsKeyId` sur n’importe quel identifiant de clé pour la clé KMS. Pour utiliser une clé gérée par le client dans un autre AWS compte, spécifiez l'ARN de la clé ou l'alias ARN. ## Détermination si le chiffrement est activé pour un cluster de bases de données Vous pouvez utiliser l'API AWS Management Console AWS CLI, ou RDS pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données. ### Console **Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données** 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**. 1. Sélectionnez le nom du cluster de base de données que vous souhaitez vérifier pour en voir les détails. 1. Cliquez sur l’onglet **Configuration** et cochez la case **Encryption** (Chiffrement). ![\[Vérification du chiffrement au repos pour un cluster de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/encryption-aurora-instance.png) ### AWS CLI Pour déterminer si le chiffrement au repos est activé pour un cluster de base de données à l'aide de AWS CLI, appelez la [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)commande avec l'option suivante : + `--db-cluster-identifier` : nom du cluster de bases de données. L’exemple suivant utilise une requête pour renvoyer `TRUE` ou `FALSE` concernant le chiffrement au repos pour le cluster de bases de données `mydb`. **Example** ``` 1. aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text ``` ### API RDS Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données à l'aide de l'API Amazon RDS, appelez l'DBClustersopération [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) avec le paramètre suivant : + `DBClusterIdentifier` : nom du cluster de bases de données. ## Disponibilité du chiffrement Amazon Aurora Le chiffrement Amazon Aurora est actuellement disponible pour tous les moteurs de base de données et types de stockage. **Note** Le chiffrement Amazon Aurora n’est pas disponible pour la classe d’instance de base de données db.t2.micro. ## Chiffrement en transit **Chiffrement au niveau de la couche physique** Toutes les données circulant Régions AWS sur le réseau AWS mondial sont automatiquement cryptées au niveau de la couche physique avant de quitter les installations AWS sécurisées. Tout le trafic entre les deux AZs est crypté. Des couches supplémentaires de chiffrement, y compris celles présentées dans cette section, peuvent fournir des protections supplémentaires. **Chiffrement fourni par le peering Amazon VPC et le peering interrégional Transit Gateway** Tout le trafic entre régions qui utilise un appairage VPC Amazon et Transit Gateway est automatiquement chiffré en bloc quand il quitte une région. Une couche de cryptage supplémentaire est automatiquement fournie au niveau de la couche physique pour tout le trafic avant qu'il ne quitte les installations AWS sécurisées. **Chiffrement entre les instances** AWS fournit une connectivité sécurisée et privée entre les instances de base de données de tous types. En outre, certains types d’instances utilisent les capacités de déchargement du matériel du système Nitro sous-jacent pour chiffrer automatiquement le trafic en transit entre instances. Ce chiffrement utilise des algorithmes de chiffrement authentifié avec données associées (AEAD), avec un chiffrement 256 bits. Il n’y a aucun impact sur les performances du réseau. Pour prendre en charge ce chiffrement supplémentaire du trafic en transit entre les instances, les exigences suivantes doivent être satisfaites : + Les instances utilisent les types d’instance suivants : + **Usage général :** M6i, M6id, M6in, M6idn, M7g + **Optimisé pour la mémoire** : R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn + Les instances se trouvent dans la même Région AWS. + Les instances se trouvent dans le même VPC ou peered VPCs, et le trafic ne passe pas par un périphérique ou un service réseau virtuel, tel qu'un équilibreur de charge ou une passerelle de transit. ## Limitations des clusters de bases de données chiffrées Amazon Aurora Les limitations suivantes existent pour les clusters de bases de données chiffrés Amazon Aurora : + Vous ne pouvez pas désactiver le chiffrement d’un cluster de bases de données chiffré. + Si vous disposez d'un cluster non chiffré existant, tous les instantanés créés à partir de ce cluster seront également déchiffrés. Pour créer un instantané chiffré à partir d'un cluster non chiffré, vous devez le copier et spécifier une clé gérée par le client lors de l'opération de copie. Vous ne pouvez pas créer un instantané chiffré à partir d'un instantané non chiffré sans spécifier une clé gérée par le client. + Vous ne pouvez pas créer un instantané chiffré d'une de base de données non chiffrée. + Un instantané de cluster de bases de données chiffrées doit être chiffré à l’aide de la même clé KMS que le cluster de bases de données. + Vous ne pouvez pas convertir un cluster de base de données non chiffrée vers un cluster chiffré. Toutefois, vous pouvez restaurer un instantané non chiffré dans un cluster de bases de données Aurora chiffré. Pour ce faire, spécifiez une clé KMS lorsque vous procédez à la restauration à partir de l’instantané non chiffré. + Si vous disposez d'un cluster non chiffré existant, toute réplique Amazon Aurora (instance de lecture) créée à partir de ce cluster sera également déchiffrée. Pour créer un cluster chiffré à partir d'un cluster non chiffré, vous devez restaurer le cluster de base de données. Le cluster restauré sera chiffré par défaut après l'opération de restauration. + Pour copier un instantané chiffré d'une AWS région à une autre, vous devez spécifier la clé KMS dans la AWS région de destination. Cela est dû au fait que les clés KMS sont spécifiques à la AWS région dans laquelle elles sont créées. L'instantané source reste chiffré pendant tout le processus de copie. Amazon Aurora utilise un chiffrement d’enveloppe pour protéger les données pendant le processus de copie. Pour plus d’informations sur le chiffrement d’enveloppe, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) dans le *Guide du développeur AWS Key Management Service *. + Vous ne pouvez pas déchiffrer un d’instances de base de données chiffrées. Vous pouvez cependant exporter des données à partir d’un d’instances de base de données et importer les données dans un d’instances de base de données non chiffrées. # AWS KMS key gestion Amazon Aurora s’intègre automatiquement avec [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) pour la gestion des clés. Amazon Aurora utilise le chiffrement d’enveloppe. Pour plus d’informations sur le chiffrement d’enveloppe, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) dans le *Guide du développeur AWS Key Management Service *. Vous pouvez utiliser deux types de AWS KMS clés pour chiffrer vos clusters d' de base de données. + Si vous souhaitez un contrôle total sur une clé KMS, vous devez créer une *clé gérée par le client*. Pour plus d’informations sur les clés gérées par le client, consultez [Clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) dans le *Guide du développeur AWS Key Management Service *. + *Clés gérées par AWS*sont des clés KMS de votre compte créées, gérées et utilisées en votre nom par un AWS service intégré à AWS KMS. Par défaut, la Clé gérée par AWS RDS (`aws/rds`) est utilisée pour le chiffrement. Vous ne pouvez pas gérer, faire pivoter ou supprimer le RDS. Clé gérée par AWS Pour plus d'informations à ce sujet Clés gérées par AWS, consultez [Clés gérées par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)le *guide du AWS Key Management Service développeur*. Pour gérer les clés KMS utilisées pour les clusters d' de base de données chiffrées Amazon Aurora, utilisez le [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) dans la [AWS KMS console](https://console.aws.amazon.com/kms) AWS CLI, le ou l' AWS KMS API. Pour consulter les journaux d’audit de chaque action effectuée à l’aide d’une clé gérée par le client ou par AWS , utilisez [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Pour plus d’informations sur la rotation des clés, consultez [Rotation des clés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). ## Autoriser l’utilisation d’une clé gérée par le client Quand Aurora utilise une clé gérée par le client dans le cadre d’opérations de chiffrement, il agit au nom de l’utilisateur qui crée ou modifie la ressource Aurora. Pour créer une ressource Aurora à l’aide d’une clé gérée par un client, un utilisateur doit avoir les autorisations nécessaires pour appeler les opérations suivantes sur la clé gérée par le client : + `kms:CreateGrant` + `kms:DescribeKey` Vous pouvez spécifier les autorisations requises dans une politique de clé ou dans une IAM politique si la politique de clé le permet. **Important** Lorsque vous utilisez des déclarations de refus explicites pour toutes les ressources (\$1) dans les politiques AWS KMS clés des services gérés tels qu'Amazon RDS, vous devez spécifier une condition pour autoriser le compte propriétaire de la ressource. Les opérations peuvent échouer sans cette condition, même si la règle de refus inclut des exceptions pour votre utilisateur IAM. **Astuce** Pour suivre le principe du moindre privilège, n’autorisez pas l’accès complet à `kms:CreateGrant`. Utilisez plutôt la [clé de ViaService condition kms :](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) pour permettre à l'utilisateur de créer des autorisations sur la clé KMS uniquement lorsque l'autorisation est créée en son nom par un AWS service. Vous pouvez renforcer la politique IAM de différentes manières. Par exemple, si vous souhaitez autoriser l'utilisation de la clé gérée par le client uniquement pour les demandes provenant de Aurora, utilisez la [clé de kms: ViaService condition](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) avec la `rds..amazonaws.com` valeur. Vous pouvez également utiliser les clés ou les valeurs du contexte [Contexte de chiffrement Amazon RDS](#Overview.Encryption.Keys.encryptioncontext) comme condition d’utilisation de la clé gérée par le client pour le chiffrement. Pour plus d’informations, consultez [Autoriser des utilisateurs d’autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) dans le *Guide du développeur AWS Key Management Service *. ## Contexte de chiffrement Amazon RDS Quand Aurora utilise votre clé KMS ou quand Amazon EBS utilise la clé KMS pour le compte d’Aurora, le service spécifie un [contexte de chiffrement](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). Le contexte de chiffrement est constitué de [données authentifiées supplémentaires](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) AWS KMS utilisées pour garantir l'intégrité des données. Autrement dit, quand un contexte de chiffrement est spécifié pour une opération de chiffrement, le service doit spécifier le même contexte de chiffrement pour l’opération de déchiffrement. Dans le cas contraire, le déchiffrement échoue. Le contexte de chiffrement est également écrit dans vos journaux [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) pour vous aider à comprendre pourquoi une clé KMS donnée a été utilisée. Vos CloudTrail journaux peuvent contenir de nombreuses entrées décrivant l'utilisation d'une clé KMS, mais le contexte de chiffrement de chaque entrée de journal peut vous aider à déterminer la raison de cette utilisation particulière. Au minimum, Aurora utilise toujours l’ID de cluster de bases de données pour le contexte de chiffrement, comme dans l’exemple au format JSON suivant : ``` { "aws:rds:dbc-id": "cluster-CQYSMDPBRZ7BPMH7Y3RTDG5QY" } ``` Ce contexte de chiffrement peut vous aider à identifier le cluster de bases de données pour lequel votre clé KMS a été utilisée. Quand votre clé KMS est utilisée pour un cluster de bases de données spécifique et un volume Amazon EBS spécifique, l’ID du cluster de bases de données et l’ID de volume Amazon EBS sont utilisés pour le contexte de chiffrement, comme dans l’exemple au format JSON suivant : ``` { "aws:rds:dbc-id": "cluster-BRG7VYS3SVIFQW7234EJQOM5RQ", "aws:ebs:id": "vol-ad8c6542" } ``` # Utilisation SSL/TLS pour chiffrer une connexion à une de clusters Vous pouvez utiliser le protocole SSL (Secure Socket Layer) ou le protocole TLS (Transport Layer Security) à partir de votre application pour chiffrer une connexion à un cluster de bases de données exécutant Aurora MySQL ou Aurora PostgreSQL. Les connexions SSL/TLS fournissent une couche de sécurité en chiffrant les données en transit entre votre client et le cluster de bases de données. En option, votre SSL/TLS connexion peut effectuer une vérification de l'identité du serveur en validant le certificat de serveur installé sur votre base de données. Pour exiger la vérification de l’identité du serveur, suivez ce processus général : 1. Choisissez l’**autorité de certification (CA)** qui signe le **certificat de serveur de base de données** pour votre base de données. Pour plus d’informations sur les autorités de certification, consultez [Autorités de certification](#UsingWithRDS.SSL.RegionCertificateAuthorities) . 1. Téléchargez une offre groupée de certificats à utiliser lorsque vous vous connectez à la base de données. Pour télécharger une offre groupée de certificats, consultez [Forfaits de certificats par Région AWS](#UsingWithRDS.SSL.CertificatesAllRegions) . **Note** Tous les certificats sont disponibles uniquement pour le téléchargement sur des connexions SSL/TLS. 1. Connectez-vous à la base de données en utilisant le processus de votre moteur de base de données pour implémenter SSL/TLS les connexions. Chaque moteur de base de données possède son propre processus d'implémentation SSL/TLS. To learn how to implement SSL/TLS pour votre base de données. Suivez le lien correspondant à votre moteur de base de données : + [Sécurité avec Amazon Aurora MySQL](AuroraMySQL.Security.md) + [Sécurité avec Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md) ## Autorités de certification L’**autorité de certification (CA)** est le certificat qui identifie l’autorité de certification racine en haut de la chaîne de certificats. L’autorité de certification signe le **certificat de serveur de base de données**, qui est installé sur chaque instance de base de données. Le certificat de serveur de base de données identifie l’instance de base de données en tant que serveur approuvé. ![\[Présentation des autorités de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-overview.png) Amazon RDS fournit les éléments suivants CAs pour signer le certificat du serveur de base de données d'une base de données. **** | Autorité de certification (CA) | Description | Nom commun | | --- | --- | --- | | rds-ca-rsa2048-g1 | Utilise une autorité de certification avec l'algorithme de clé privée RSA 2048 et l'algorithme de SHA256 signature dans la plupart des cas. Régions AWS Dans le AWS GovCloud (US) Regions, cette autorité de certification utilise une autorité de certification avec un algorithme de clé privée et un algorithme de SHA384 signature RSA 2048. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 RSA2048 | | rds-ca-rsa4096-g1 | Utilise une autorité de certification avec l'algorithme de clé privée et l'algorithme de SHA384 signature RSA 4096. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 RSA4096 | | rds-ca-ecc384-g1 | Utilise une autorité de certification avec un algorithme de clé privée et un algorithme de SHA384 signature ECC 384. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 ECC384 | **Note** [Si vous utilisez le AWS CLI, vous pouvez vérifier la validité des autorités de certification répertoriées ci-dessus en utilisant describe-certificates.](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html) Ces certificats de CA sont inclus dans la solution groupée de certificats régionaux et mondiaux. Lorsque vous utilisez l'autorité de certification rds-ca-rsa 2048-g1, rds-ca-rsa 4096-g1 ou rds-ca-ecc 384-g1 avec une base de données, RDS gère le certificat du serveur de base de données sur la base de données. RDS effectue automatiquement la rotation du certificat de serveur de base de données avant son expiration. ### Configuration de l’autorité de certification pour votre base de données Vous pouvez définir l’autorité de certification pour une base de données lorsque vous effectuez les tâches suivantes : + Créer un cluster de base de données Aurora — Vous pouvez définir l'autorité de certification pour une instance de base de données dans un cluster Aurora lorsque vous créez la première instance de base de données dans le cluster de base de données à l'aide de l'API AWS CLI ou RDS. Actuellement, vous ne pouvez pas configurer l’autorité de certification des instances de base de données dans un cluster de bases de données lorsque vous créez le cluster de bases de données à l’aide de la console RDS. Pour obtenir des instructions, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). + Modification d’une instance de base de données : vous pouvez définir l’autorité de certification d’une instance de base de données dans un cluster de bases de données en la modifiant. Pour obtenir des instructions, consultez [Modification d’une instance de base de données dans un cluster de bases de données](Aurora.Modifying.md#Aurora.Modifying.Instance) . **Note** L'autorité de certification par défaut est définie sur rds-ca-rsa 2048-g1. Vous pouvez remplacer l'autorité de certification par défaut pour votre Compte AWS compte à l'aide de la commande [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html). La disponibilité CAs dépend du moteur de base de données et de la version du moteur de base de données. Lorsque vous utilisez le AWS Management Console, vous pouvez choisir l'autorité de **certification à l'aide du paramètre Autorité** de certification, comme indiqué dans l'image suivante. ![\[Option d’autorité de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority.png) La console affiche uniquement ceux CAs qui sont disponibles pour le moteur de base de données et la version du moteur de base de données. Si vous utilisez le AWS CLI, vous pouvez définir l'autorité de certification pour une instance de base de données à l'aide de la [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)or. Si vous utilisez le AWS CLI, vous pouvez voir ce qui est disponible CAs pour votre compte en utilisant la commande [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Cette commande indique également la date d’expiration de chaque autorité de certification dans `ValidTill`, dans la sortie. Vous pouvez trouver ceux CAs qui sont disponibles pour un moteur de base de données et une version de moteur de base de données spécifiques à l'aide de la [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande. L'exemple suivant montre la version CAs disponible pour la version par défaut du moteur de base de données RDS pour PostgreSQL. ``` aws rds describe-db-engine-versions --default-only --engine postgres ``` Votre sortie est similaire à ce qui suit. Les options disponibles CAs sont répertoriées dans`SupportedCACertificateIdentifiers`. La sortie indique également si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage dans `SupportsCertificateRotationWithoutRestart`. ``` { "DBEngineVersions": [ { "Engine": "postgres", "MajorEngineVersion": "13", "EngineVersion": "13.4", "DBParameterGroupFamily": "postgres13", "DBEngineDescription": "PostgreSQL", "DBEngineVersionDescription": "PostgreSQL 13.4-R1", "ValidUpgradeTarget": [], "SupportsLogExportsToCloudwatchLogs": false, "SupportsReadReplica": true, "SupportedFeatureNames": [ "Lambda" ], "Status": "available", "SupportsParallelQuery": false, "SupportsGlobalDatabases": false, "SupportsBabelfish": false, "SupportsCertificateRotationWithoutRestart": true, "SupportedCACertificateIdentifiers": [ "rds-ca-rsa2048-g1", "rds-ca-ecc384-g1", "rds-ca-rsa4096-g1" ] } ] } ``` ### Validité des certificats de serveur de base de données La validité du certificat de serveur de base de données dépend du moteur de base de données et de la version du moteur de base de données. Si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage, la validité du certificat de serveur de base de données est de 1 an. Dans le cas contraire, la validité est de 3 ans. Pour plus d’informations sur la rotation des certificats de serveur de base de données, consultez [Rotation automatique du certificat de serveur](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). ### Visualisation de la CA pour votre instance de base de données Vous pouvez consulter les détails concernant la CA d’une instance de base de données en affichant l’onglet **Connectivité et sécurité** de la console, comme illustré dans l’image suivante. ![\[Détails de l’autorité de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-details.png) Si vous utilisez le AWS CLI, vous pouvez afficher les détails de l'autorité de certification pour une instance de base de données à l'aide de la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande. ## Téléchargez des ensembles de certificats pour Lorsque vous vous connectez à votre base de données via SSL ou TLS, l’instance de base de données nécessite un certificat de confiance d’Amazon RDS. Sélectionnez le lien approprié dans le tableau suivant pour télécharger l’offre correspondant à la Région AWS où vous hébergez votre base de données. ### Forfaits de certificats par Région AWS Les ensembles de certificats pour toutes les régions Régions AWS et GovCloud (États-Unis) contiennent les certificats CA racine suivants : + `rds-ca-rsa2048-g1` + `rds-ca-rsa4096-g1` + `rds-ca-ecc384-g1` Les certificats `rds-ca-ecc384-g1` et `rds-ca-rsa4096-g1` ne sont pas disponibles dans les régions suivantes : + Asie-Pacifique (Mumbai) + Asie-Pacifique (Melbourne) + Canada-Ouest (Calgary) + Europe (Zurich) + Europe (Espagne) + Israël (Tel Aviv) Le magasin de confiance de votre application doit uniquement enregistrer le certificat CA racine. N'enregistrez pas les certificats CA intermédiaires dans votre magasin de confiance car cela pourrait entraîner des problèmes de connexion lorsque RDS fait automatiquement pivoter votre certificat de serveur de base de données. **Note** Le proxy et l'utilisation d'Amazon RDS Aurora Serverless v1 les certificats du AWS Certificate Manager (ACM). Si vous utilisez le proxy RDS, vous n’avez pas besoin de télécharger des certificats Amazon RDS ou de mettre à jour des applications utilisant des connexions de proxy RDS. Pour plus d’informations, consultez [Utilisation TLS/SSL avec RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls). Si vous utilisez Aurora Serverless v1, le téléchargement des certificats Amazon RDS n’est pas nécessaire. Pour plus d’informations, consultez [Utilisation TLS/SSL avec Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). Pour télécharger un bundle de certificats pour un Région AWS, sélectionnez le lien correspondant à celui Région AWS qui héberge votre base de données dans le tableau suivant. | **AWS Région** | **Solution groupée de certificats (PEM)** | **Ensemble de certificats (PKCS7)** | | --- | --- | --- | | N'importe quelle publicité Région AWS | [global-bundle.pem](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.rds.amazonaws.com/global/global-bundle.p7b) | | USA Est (Virginie du Nord) | [us-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem) | [us-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.p7b) | | US East (Ohio) | [us-east-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.pem) | [us-east-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.p7b) | | US West (N. California) | [us-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.pem) | [us-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.p7b) | | US West (Oregon) | [us-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem) | [us-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.p7b) | | Africa (Cape Town) | [af-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.pem) | [af-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.p7b) | | Asia Pacific (Hong Kong) | [ap-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.pem) | [ap-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.p7b) | | Asie-Pacifique (Hyderabad) | [ap-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.pem) | [ap-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.p7b) | | Asie-Pacifique (Jakarta) | [ap-southeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.pem) | [ap-southeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.p7b) | | Asie-Pacifique (Malaisie) | [ap-southeast-5-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.pem) | [ap-southeast-5-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.p7b) | | Asie-Pacifique (Melbourne) | [ap-southeast-4-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.pem) | [ap-southeast-4-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.p7b) | | Asia Pacific (Mumbai) | [ap-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.pem) | [ap-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.p7b) | | Asia Pacific (Osaka) | [ap-northeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.pem) | [ap-northeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.p7b) | | Asie-Pacifique (Thaïlande) | [ap-southeast-7-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.pem) | [ap-southeast-7-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.p7b) | | Asie-Pacifique (Tokyo) | [ap-northeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem) | [ap-northeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.p7b) | | Asia Pacific (Seoul) | [ap-northeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.pem) | [ap-northeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.p7b) | | Asia Pacific (Singapore) | [ap-southeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.pem) | [ap-southeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.p7b) | | Asia Pacific (Sydney) | [ap-southeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.pem) | [ap-southeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.p7b) | | Canada (Centre) | [ca-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.pem) | [ca-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.p7b) | | Canada-Ouest (Calgary) | [ca-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.pem) | [ca-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.p7b) | | Europe (Frankfurt) | [eu-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.pem) | [eu-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.p7b) | | Europe (Ireland) | [eu-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.pem) | [eu-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.p7b) | | Europe (London) | [eu-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.pem) | [eu-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.p7b) | | Europe (Milan) | [eu-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.pem) | [eu-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.p7b) | | Europe (Paris) | [eu-west-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.pem) | [eu-west-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.p7b) | | Europe (Espagne) | [eu-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.pem) | [eu-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.p7b) | | Europe (Stockholm) | [eu-north-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.pem) | [eu-north-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.p7b) | | Europe (Zurich) | [eu-central-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.pem) | [eu-central-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.p7b) | | Israël (Tel Aviv) | [il-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.pem) | [il-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.p7b) | | Mexique (Centre) | [mx-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.pem) | [mx-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.p7b) | | Middle East (Bahrain) | [me-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.pem) | [me-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.p7b) | | Moyen-Orient (EAU) | [me-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.pem) | [me-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.p7b) | | Amérique du Sud (São Paulo) | [sa-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.pem) | [sa-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.p7b) | | N'importe quel AWS GovCloud (US) Region s | [global-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.p7b) | | AWS GovCloud (USA Est) | [us-gov-east-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.pem) | [us-gov-east-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.p7b) | | AWS GovCloud (US-Ouest) | [us-gov-west-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.pem) | [us-gov-west-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.p7b) | ### Affichage du contenu de votre certificat CA Pour vérifier le contenu de votre offre groupée de certificats d’autorité de certification, utilisez la commande suivante : ``` keytool -printcert -v -file global-bundle.pem ``` # Rotation de votre SSL/TLS certificat Les certificats de l’autorité de certification Amazon RDS rds-ca-2019 sont configurés pour expirer en août 2024. Si vous utilisez ou prévoyez d'utiliser le protocole SSL (Secure Sockets Layer) ou le protocole Transport Layer Security (TLS) avec vérification des certificats pour vous connecter à vos instances de base de données RDS , pensez à utiliser l'un des nouveaux certificats CA rds-ca-rsa 2048-g1, 4096-g1 ou 384-g1. rds-ca-rsa rds-ca-ecc Si vous ne l'utilisez pas actuellement SSL/TLS avec la vérification des certificats, vous avez peut-être encore un certificat CA expiré et vous devez le mettre à jour SSL/TLS avec un nouveau certificat CA si vous prévoyez d'utiliser la vérification des certificats pour vous connecter à vos bases de données RDS. Amazon RDS fournit de nouveaux certificats CA dans le cadre des meilleures pratiques AWS de sécurité. Pour plus d'informations sur les nouveaux certificats et les AWS régions prises en charge, consultez[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md). Pour mettre à jour le certificat CA de votre base de données, appliquez les méthodes suivantes : + [Mise à jour de votre certificat CA en modifiant votre instance de base de données ](#UsingWithRDS.SSL-certificate-rotation-updating) + [Mise à jour de votre certificat CA en appliquant la maintenance](#UsingWithRDS.SSL-certificate-rotation-maintenance-update) Avant de mettre à jour vos instances de base de données pour utiliser le nouveau certificat CA, veillez à mettre à jour vos clients ou applications connectés à vos bases de données RDS. ## Considérations relatives à la rotation des certificats Tenez compte des situations suivantes avant de procéder à la rotation de votre certificat : + Le proxy et l'utilisation d'Amazon RDS Aurora Serverless v1 les certificats du AWS Certificate Manager (ACM). Si vous utilisez un proxy RDS, lorsque vous faites pivoter votre SSL/TLS certificat, vous n'avez pas besoin de mettre à jour les applications qui utilisent des connexions au proxy RDS. Pour plus d’informations, consultez [Utilisation TLS/SSL avec RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls). + Si vous utilisez Aurora Serverless v1, le téléchargement des certificats Amazon RDS n’est pas nécessaire. Pour plus d’informations, consultez [Utilisation TLS/SSL avec Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). + Si vous utilisez une application Go version 1.15 avec une instance de base de données créé(e) ou mis(e) à jour vers le certificat rds-ca-2019 avant le 28 juillet 2020, vous devez mettre à jour à nouveau le certificat. Utilisez la commande `modify-db-instance` , en utilisant le nouvel identifiant de certificat CA. Vous pouvez trouver ceux CAs qui sont disponibles pour un moteur de base de données et une version de moteur de base de données spécifiques à l'aide de la `describe-db-engine-versions` commande. Si vous avez créé votre base de données ou mis à jour son certificat après le 28 juillet 2020, aucune action n’est requise. Pour plus d'informations, consultez [Go GitHub issue \$139568](https://github.com/golang/go/issues/39568). ## Mise à jour de votre certificat CA en modifiant votre instance de base de données *L'exemple suivant met à jour votre certificat CA de *rds-ca-2019* à 2048-g1. rds-ca-rsa* Vous pouvez choisir un autre certificat. Pour plus d'informations, consultez[Autorités de certification](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). Mettez à jour le magasin de confiance de votre application afin de réduire la durée d’indisponibilité associés à la mise à jour de votre certificat CA. Pour plus d’informations sur la rotation des certificats CA, consultez [Rotation automatique du certificat de serveur](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). **Pour mettre à jour votre certificat CA en modifiant votre instance de base de données** 1. Téléchargez le nouveau SSL/TLS certificat comme décrit dans[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md). 1. Mettez à jour vos applications de sorte à utiliser le nouveau certificat SSL/TLS. Les méthodes de mise à jour des applications pour SSL/TLS les nouveaux certificats dépendent de vos applications spécifiques. Collaborez avec les développeurs de vos applications pour mettre à jour les SSL/TLS certificats de vos applications. Pour plus d'informations sur la vérification des SSL/TLS connexions et la mise à jour des applications pour chaque moteur de base de données, consultez les rubriques suivantes : + [Mise à jour des applications pour se connecter aux clusters de bases de données Aurora MySQL à l'aide des nouveaux certificats TLS](ssl-certificate-rotation-aurora-mysql.md) + [Mise à jour des applications pour se connecter aux clusters de bases de données Aurora PostgreSQL à l’aide des nouveaux certificats SSL/TLS](ssl-certificate-rotation-aurora-postgresql.md) Pour obtenir un exemple de script qui met à jour le magasin d’approbations d’un système d’exploitation Linux, consultez [Exemple de script pour importer les certificats dans votre magasin d’approbations](#UsingWithRDS.SSL-certificate-rotation-sample-script). **Note** L’ensemble de certificats contient des certificats pour le nouveau et l’ancien CA, ce qui signifie que vous pouvez mettre à niveau votre application en toute sécurité et conserver la connectivité pendant la période de transition. Si vous utilisez le AWS Database Migration Service pour migrer une base de données vers une de clusters, nous vous recommandons d'utiliser le bundle de certificats pour garantir la connectivité pendant la migration. 1. **Modifiez l'instance de base de données l'autorité de certification de **rds-ca-2019** à 2048-g1. rds-ca-rsa** Pour vérifier si votre base de données doit être redémarrée pour mettre à jour les certificats CA, utilisez la [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande et cochez l'`SupportsCertificateRotationWithoutRestart`indicateur. **Note** Redémarrez votre cluster Babelfish après l’avoir modifié pour mettre à jour le certificat CA. **Important** Si vous rencontrez des problèmes de connectivité après l’expiration du certificat, utilisez l’option **Appliquer immédiatement** en la spécifiant dans la console ou en spécifiant l’option `--apply-immediately` à l’aide d’ AWS CLI. Par défaut, il est prévu que cette opération soit exécutée pendant votre prochaine fenêtre de maintenance. Pour définir un remplacement pour votre CA de cluster différent de la CA RDS par défaut, utilisez la commande d’interface de ligne de commande [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html). ------ #### [ Console ] 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier. 1. Sélectionnez **Modifier**. ![\[Modification d’une instance de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-modify-aurora.png) 1. Dans la section **Connectivité**, choisissez **rds-ca-rsa2048-g1**. ![\[Choisissez un certificat CA\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png) 1. Choisissez **Continuer** et vérifiez le récapitulatif des modifications. 1. Pour appliquer les modifications immédiatement, choisissez **Appliquer immédiatement**. 1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modifier l’instance de base de données** pour enregistrer vos modifications. **Important** Lorsque vous planifiez cette opération, assurez-vous d’avoir mis à jour votre magasin d’approbation côté client au préalable. Ou choisissez **Retour** pour revoir vos modifications, ou choisissez **Annuler** pour les annuler. ------ #### [ AWS CLI ] Pour utiliser le pour AWS CLI faire passer l'autorité de certification de **rds-ca-2019** à **rds-ca-rsa2048-g1** pour une instance de base de données ou un cluster de base de données . [modify-db-instance[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) Spécifiez l’identifiant de l’instance de base de données et l’option `--ca-certificate-identifier`. Pour appliquer la mise à jour immédiatement, utilisez le paramètre `--apply-immediately`. Par défaut, il est prévu que cette opération soit exécutée pendant votre prochaine fenêtre de maintenance. **Important** Lorsque vous planifiez cette opération, assurez-vous d’avoir mis à jour votre magasin d’approbation côté client au préalable. **Example** L’exemple suivant modifie `mydbinstance` en définissant le certificat CA sur `rds-ca-rsa2048-g1`. Pour Linux, macOS ou Unix : ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Pour Windows : ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Si votre instance nécessite un redémarrage, vous pouvez utiliser la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI et spécifier l'`--no-certificate-rotation-restart`option. ------ ## Mise à jour de votre certificat CA en appliquant la maintenance Procédez comme suit pour mettre à jour votre certificat CA en appliquant la maintenance d’instance de base de données. ------ #### [ Console ] **Pour mettre à jour de votre certificat CA en appliquant la maintenance** 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez **Mise à jour du certificat**. ![\[Option du panneau de navigation de rotation des certificats\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-certupdate.png) La page **Bases de données nécessitant une mise à jour de certificat** apparaît. ![\[Mise à jour du certificat CA pour base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-update-multiple.png) **Note** Cette page affiche uniquement les instances de base de données actuels Région AWS. Si vous avez des bases de données dans plusieurs d'entre elles Région AWS, consultez cette page Région AWS pour voir toutes les instances de base de données dotées d'anciens SSL/TLS certificats. 1. Choisissez l’instance de base de données que vous voulez mettre à jour. Vous pouvez planifier la rotation du certificat pour votre prochaine fenêtre de maintenance en choisissant **Planification**. Appliquez la rotation immédiatement en choisissant **Appliquer maintenant**. **Important** Si vous rencontrez des problèmes de connectivité après l’expiration du certificat, utilisez l’option **Appliquer maintenant**. 1. 1. Si vous choisissez **Planification**, vous êtes invité à confirmer la rotation du certificat CA. Cette invite indique également la fenêtre planifiée pour votre mise à jour. ![\[Confirmation de la rotation du certificat\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-schedule.png) 1. Si vous choisissez **Appliquer maintenant**, vous êtes invité à confirmer la rotation du certificat CA. ![\[Confirmation de la rotation du certificat\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-now.png) **Important** Avant de planifier la rotation des certificats CA dans votre base de données, mettez à jour toutes les applications clientes qui les utilisent SSL/TLS et le certificat du serveur pour se connecter. Ces mises à jour sont spécifiques à votre moteur de base de données. Après avoir mis à jour ces applications clientes, vous pouvez confirmer la rotation du certificat CA. Pour continuer, cochez la case, puis cliquez sur **Confirmation**. 1. Répétez les étapes 3 et 4 pour chaque instance de base de données que vous souhaitez mettre à jour. ------ ## Rotation automatique du certificat de serveur Si votre CA racine prend en charge la rotation automatique du certificat de serveur, RDS gère automatiquement la rotation du certificat de serveur de base de données. RDS utilise la même autorité de certification racine pour cette rotation automatique. Vous n’avez donc pas besoin de télécharger une nouvelle offre groupée d’autorités de certification. Consultez [Autorités de certification](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). La rotation et la validité de votre certificat de serveur de base de données dépendent de votre moteur de base de données : + Si votre moteur de base de données prend en charge la rotation sans redémarrage, RDS effectue automatiquement la rotation du certificat de serveur de base de données sans que vous ayez à intervenir. RDS tente d’effectuer la rotation de votre certificat de serveur de base de données pendant la fenêtre de maintenance de votre choix, à la moitié de la durée de vie du certificat de serveur de base de données. Le nouveau certificat de serveur de base de données est valide pendant 12 mois. + Si votre moteur de base de données ne prend pas en charge la rotation sans redémarrage, Amazon RDS `server-certificate-rotation` affiche une action de maintenance en attente via l' Describe-pending-maintenance-actionsAPI, à la demi-vie du certificat ou au moins 3 mois avant son expiration. Vous pouvez appliquer la rotation à l'aide de l' apply-pending-maintenance-actionAPI. Le nouveau certificat de serveur de base de données est valide pendant 36 mois. Utilisez la [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande et inspectez l'`SupportsCertificateRotationWithoutRestart`indicateur pour déterminer si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage. Pour plus d’informations, consultez [Configuration de l’autorité de certification pour votre base de données](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection). ## Exemple de script pour importer les certificats dans votre magasin d’approbations Voici des exemples de scripts shell qui importent le lot de certificats dans un magasin d’approbations. Chaque exemple de script shell utilise keytool, qui fait partie du kit de développement Java (JDK). Pour plus d’informations sur l’installation du JDK, consultez le [Guide d’installation du JDK](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html). ------ #### [ Linux ] Voici un exemple de scripting shell qui importe le lot de certificats vers un magasin d’approbations sur un système d’exploitation Linux. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1}{print > "rds-ca-" n+1 ".pem"}' < ${mydir}/global-bundle.pem for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ #### [ macOS ] Voici un exemple de scripting shell qui importe le lot de certificats vers un magasin d’approbations sur macOS. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem split -p "-----BEGIN CERTIFICATE-----" ${mydir}/global-bundle.pem rds-ca- for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ Pour en savoir plus sur les bonnes pratiques relatives à l’utilisation du protocole SSL avec Amazon RDS, consultez [Bonnes pratiques pour des connexions SSL réussies à Amazon RDS for Oracle](https://aws.amazon.com/blogs/database/best-practices-for-successful-ssl-connections-to-amazon-rds-for-oracle/).