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
Vous pouvez activer le chiffrement pour vos ressources de base de données. Vous pouvez également chiffrer les connexions aux instances de base de données.
**Topics**
+ [Chiffrement des ressources Amazon RDS](Overview.Encryption.md)
+ [AWS KMS key gestion](Overview.Encryption.Keys.md)
+ [](UsingWithRDS.SSL.md)
+ [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md)
# Chiffrement des ressources Amazon RDS
Amazon RDS peut chiffrer vos instances de base de données Amazon RDS. Les données chiffrées au repos incluent le stockage sous-jacent pour les instances de base de données, ses journaux, ses sauvegardes automatisées, ses répliques de lecture et ses instantanés.
Les instances de base de données chiffrées Amazon RDS utilisent l'algorithme de chiffrement standard AES-256 pour chiffrer vos données sur le serveur qui héberge vos instances de base de données Amazon RDS.
Une fois vos données chiffrées, Amazon RDS 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 d'instances 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 des ressources Amazon RDS](#Overview.Encryption.Overview)
+ [Chiffrement d’une instance de base de données](#Overview.Encryption.Enabling)
+ [Détermination si le chiffrement est activé pour une instance de base de données](#Overview.Encryption.Determining)
+ [Disponibilité du chiffrement Amazon RDS](#Overview.Encryption.Availability)
+ [Chiffrement en transit](#Overview.Encryption.InTransit)
+ [Limitations des instances données chiffrées Amazon RDS](#Overview.Encryption.Limitations)
## Présentation du chiffrement des ressources Amazon RDS
Les instances de base de données chiffrée Amazon RDS 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. Vous pouvez utiliser le chiffrement Amazon RDS for renforcer la protection des données de vos applications déployées dans le cloud et pour satisfaire aux exigences de conformité pour le chiffrement au repos. Pour une instance de base de données chiffrée Amazon RDS, l’ensemble des journaux, sauvegardes et instantanés sont chiffrés. Pour plus d’informations sur la disponibilité et les limites du chiffrement, consultez [Disponibilité du chiffrement Amazon RDS](#Overview.Encryption.Availability) et [Limitations des instances données chiffrées Amazon RDS](#Overview.Encryption.Limitations).
Amazon RDS 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. Vous pouvez utiliser un Clé gérée par AWS, ou vous pouvez créer des clés gérées par le client.
Lorsque vous créez une instance de base de données chiffrée, vous pouvez choisir une clé gérée par le client ou la Clé gérée par AWS pour Amazon RDS pour chiffrer votre instance de base de données. Si vous ne spécifiez pas l'identifiant de clé pour une clé gérée par le client, Amazon RDS l'utilise Clé gérée par AWS pour votre nouvelle instance de base de données. Amazon RDS crée un Clé gérée par AWS pour Amazon RDS pour votre AWS compte. Votre AWS compte possède un identifiant Amazon RDS 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 RDS, 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 qui contrôlent 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 de base de données. Vous devez donc prendre soin de déterminer vos besoins en termes de clés KMS avant de créer votre instance de base de données chiffrée.
Si vous devez modifier la clé de chiffrement de votre instance de base de données, créez un instantané manuel de votre instance et activez le chiffrement lors de la copie de l’instantané. Pour plus d’informations, consultez cet [article re:Post Knowledge](https://repost.aws/knowledge-center/update-encryption-key-rds).
+ Si vous copiez un instantané chiffré, vous pouvez utiliser une clé KMS différente pour chiffrer l’instantané cible que celle utilisée pour chiffrer l’instantané source.
+ Une réplique en lecture d'une instance cryptée Amazon RDS doit être chiffrée à l'aide de la même clé KMS que l'instance de base de données principale lorsque les deux se trouvent dans la même AWS région.
+ Si l'instance de base de données principale et la réplique en lecture se trouvent dans des AWS régions différentes, vous chiffrez la réplique en lecture à l'aide de la clé KMS de cette AWS région.
+ Vous ne pouvez pas partager un instantané chiffré à l'aide Clé gérée par AWS du AWS compte qui l'a partagé.
+ Amazon RDS prend également en charge le chiffrement d’une instance de base de données Oracle ou SQL Server à l’aide du chiffrement TDE (Transparent Data Encryption). Le chiffrement TDE peut être utilisé avec le chiffrement RDS au repos, bien que l’utilisation simultanée de ces deux chiffrements puisse affecter quelque peu les performances de votre base de données. Vous devez gérer des clés différentes pour chaque méthode de chiffrement. Pour plus d’informations sur TDE, consultez [Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md) ou [Prise en charge de Transparent Data Encryption dans SQL Server](Appendix.SQLServer.Options.TDE.md).
**Important**
Amazon RDS perd l’accès à la clé KMS pour une instance de base de données lorsque vous désactivez la clé KMS. Si vous perdez l’accès à une clé KMS, l’instance de base de données cryptée passe à l’état `inaccessible-encryption-credentials-recoverable` 2 heures après la détection dans les instances où les sauvegardes sont activées. L’instance de base de données reste dans cet état pendant sept jours, pendant lesquels elle est arrêtée. Les appels d’API effectués vers l’instance de base de données pendant cette période risquent d’échouer. Pour restaurer l’instance de base de données, activez la clé KMS, puis redémarrez l’instance. Activez la clé KMS depuis l'API AWS Management Console AWS CLI, ou RDS. Redémarrez l'instance de base de données à l'aide de la AWS CLI commande [start-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-instance.html)ou AWS Management Console.
L’état `inaccessible-encryption-credentials-recoverable` s’applique uniquement aux instances de base de données qui peuvent être interrompues. Cet état récupérable ne s’applique pas aux instances qui ne peuvent pas s’arrêter, telles que les réplicas en lecture et les instances contenant des réplicas en lecture. Pour plus d’informations, consultez [Limites liées à l'arrêt de votre instance de base de données](USER_StopInstance.md#USER_StopInstance.Limitations).
Si l’instance de base de données n’est pas récupérée dans un délai de sept jours, elle passe à l’état `inaccessible-encryption-credentials` terminal. Dans cet état, l’instance de base de données n’est plus utilisable et vous ne pouvez la restaurer qu’à partir d’une sauvegarde. Nous vous recommandons vivement de toujours activer les sauvegardes pour les instances de base de données chiffrées afin de vous prémunir contre la perte de données chiffrées dans vos bases de données.
Lors de la création d’une instance de base de données, Amazon RDS 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 de l’instance de base 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 une instance de base de données à partir de l’instantané sans spécifier de clé KMS différente, la nouvelle instance utilise la clé KMS du compte source. Le fait de révoquer l’accès à la clé après la création de l’instance de base de données n’a aucun impact sur cette instance. Toutefois, la désactivation de la clé affecte toutes les instances de base de données chiffrées avec cette clé. Afin d’éviter cette situation, indiquez une clé différente au moment de la copie de l’instantané.
Les instances de base de données dont les sauvegardes sont désactivées restent disponibles jusqu’à ce que les volumes soient détachés de l’hôte lors de la modification d’une instance ou d’une restauration. RDS place les instances dans l’état `inaccessible-encryption-credentials-recoverable` ou `inaccessible-encryption-credentials`, selon le cas.
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’une instance de base de données
Pour chiffrer une nouvelle instance de base de données, sélectionnez **Enable encryption** (Activer le chiffrement) dans la console Amazon RDS. Pour plus d’informations sur la création d’une instance de base de données, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
Si vous utilisez la [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI commande pour créer une instance de base de données cryptée, définissez le `--storage-encrypted` paramètre. Si vous utilisez l'opération [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API, définissez le `StorageEncrypted` paramètre sur true.
Si vous utilisez la AWS CLI `create-db-instance` commande pour créer une instance de base de données cryptée 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 une instance de base 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 une instance de base de données.
### Console
**Pour déterminer si le chiffrement au repos est activé pour une instance de base 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 de l’instance de base de données que vous souhaitez vérifier pour afficher ses détails.
1. Cliquez sur l’onglet **Configuration** et cochez la case **Encryption** (Chiffrement) sous **Storage** (Stockage).
Il indique **Enabled** (Activé) ou **Not enabled** (Non activé).
![\[Vérification du chiffrement au repos pour une instance de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/encryption-check-db-instance.png)
### AWS CLI
Pour déterminer si le chiffrement au repos est activé pour une instance de base de données à l'aide de AWS CLI, appelez la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande avec l'option suivante :
+ `--db-instance-identifier` : nom de l’instance de base de données.
L’exemple suivant utilise une requête pour renvoyer `TRUE` ou `FALSE` concernant le chiffrement au repos pour l’instance de base de données `mydb`.
**Example**
```
1. aws rds describe-db-instances --db-instance-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text
```
### API RDS
Pour déterminer si le chiffrement au repos est activé pour une instance de base de données à l'aide de l'API Amazon RDS, appelez l'DBInstancesopération [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) avec le paramètre suivant :
+ `DBInstanceIdentifier` : nom de l’instance de base de données.
## Disponibilité du chiffrement Amazon RDS
Le chiffrement Amazon RDS est actuellement disponible pour tous les moteurs de base de données et types de stockage.
Le chiffrement Amazon RDS est disponible pour la plupart des classes d’instance de base de données. Le tableau suivant répertorie les classes d’instance de base de données qui *ne prennent pas en charge* le chiffrement Amazon RDS :
| Type d’instance | Classe d’instance |
| --- | --- |
| Polyvalent (M1) | db.m1.small db.m1.medium db.m1.large db.m1.xlarge |
| Mémoire optimisée (M2) | db.m2.xlarge db.m2.2xlarge db.m2.4xlarge |
| Capacité extensible (T2) | 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 instances données chiffrées Amazon RDS
Les limitations suivantes existent pour les instances de base de données chiffrées Amazon RDS :
+ Vous ne pouvez chiffrer une instance de base de données Amazon RDS que lorsque vous la créez, et non après sa création.
Cependant, parce que vous pouvez chiffrer une copie d’un instantané non chiffré, vous pouvez ajouter le chiffrement efficacement à une instance de base de données non chiffrée. Autrement dit, vous pouvez créer un instantané de votre instance de base de données et ensuite créer une copie chiffrée de l’instantané. Vous pouvez ensuite restaurer une instance de base de données à partir de l’instantané chiffré et vous aurez une copie chiffrée de votre instance de base de données d’origine. Pour plus d’informations, consultez [Copie d’un instantané de base de données pour Amazon RDS](USER_CopySnapshot.md).
+ Vous ne pouvez pas désactiver le chiffrement d’une instance de base de données chiffrée.
+ Vous ne pouvez pas créer un instantané chiffré d'une instance de base de données non chiffrée.
+ Un instantané d’instance de bases de données chiffrées doit être chiffré à l’aide de la même clé KMS que l’instance de bases de données.
+ Vous ne pouvez pas avoir un réplica en lecture chiffré d’une instance de base de données non chiffrée ni un réplica en lecture non chiffré d’une instance de base de données chiffrée.
+ Les réplicas en lecture chiffrés doivent être chiffrés avec la même clé KMS que l’instance de base de données source lorsque tous deux se trouvent dans la même région AWS .
+ Vous ne pouvez pas restaurer un instantané non chiffré ou une sauvegarde non chiffrée vers une instance de base de données chiffrée.
+ 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 RDS 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 cluster chiffrées. Vous pouvez cependant exporter des données à partir d’un cluster et importer les données dans un cluster non chiffrées.
# AWS KMS key gestion
Amazon RDS 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 RDS 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 d'instances 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 d'instances de base de données chiffrées Amazon RDS , 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 RDS 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 RDS .
Pour créer une ressource RDS à 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 RDS , 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 RDS utilise votre clé KMS ou quand Amazon EBS utilise la clé KMS pour le compte de RDS , 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, Amazon RDS utilise toujours l’ID d’instance de bases de données pour le contexte de chiffrement, comme dans l’exemple au format JSON suivant :
```
{ "aws:rds:db-id": "db-CQYSMDPBRZ7BPMH7Y3RTDG5QY" }
```
Ce contexte de chiffrement peut vous aider à identifier l’instance de bases de données pour lequel votre clé KMS a été utilisée.
Quand votre clé KMS est utilisée pour une instance de bases de données spécifique et un volume Amazon EBS spécifique, l’ID de l’instance 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:db-id": "db-BRG7VYS3SVIFQW7234EJQOM5RQ",
"aws:ebs:id": "vol-ad8c6542"
}
```
#
Vous pouvez utiliser le protocole SSL (Secure Socket Layer) ou le protocole TLS (Transport Layer Security) à partir de votre application pour chiffrer une connexion à une base de données exécutant Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle ou PostgreSQL.
Les connexions SSL/TLS fournissent une couche de sécurité en chiffrant les données en transit entre votre client et l’instance de base de données ou 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 :
+ [Utilisation SSL/TLS avec une instance de base de données Amazon RDS pour DB2](Db2.Concepts.SSL.md)
+ [Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS](MariaDB.Concepts.SSLSupport.md)
+ [Utilisation de SSL avec une instance DB Microsoft SQL Server](SQLServer.Concepts.General.SSL.Using.md)
+ [Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS](MySQL.Concepts.SSLSupport.md)
+ [Utilisation de SSL avec une instance de base de données RDS for Oracle](Oracle.Concepts.SSL.md)
+ [Utilisation de SSL avec une instance de base de données PostgreSQL](PostgreSQL.Concepts.General.SSL.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/UserGuide/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éation d’une instance de base de données ou d’un cluster de bases de données multi-AZ : vous pouvez configurer la CA lorsque vous créez une instance de base de données ou un cluster de bases de données multi-AZ. Pour obtenir des instructions, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md) ou [Création d’un cluster de bases de données Multi-AZ pour Amazon RDS](create-multi-az-db-cluster.md).
+ Modification d’une instance de base de données ou d’un cluster de bases de données multi-AZ : vous pouvez définir la CA 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 Amazon RDS](Overview.DBInstance.Modifying.md) ou [Modification d’un cluster de bases de données multi-AZ pour Amazon RDS](modify-multi-az-db-cluster.md).
**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/UserGuide/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. Vous pouvez définir l'autorité de certification pour un cluster de base de données multi-AZ à l'aide de la [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)commande [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.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/UserGuide/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. Vous pouvez afficher les détails de l'autorité de certification pour un cluster de base de données multi-AZ à l'aide de la [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)commande.
##
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 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).
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 ou à vos clusters de base de données multi-AZ, 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[](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 ou votre cluster](#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 ou vos clusters de basses de données multi-AZ 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 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 une application Go version 1.15 avec une instance de base de données ou un cluster de bases de données multi-AZ 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` pour une instance de base de données ou la commande `modify-db-cluster` pour un cluster de bases de données multi-AZ, 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 ou votre cluster
*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 ou votre cluster**
1. Téléchargez le nouveau SSL/TLS certificat comme décrit dans[](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 instances MariaDB à l'aide de nouveaux certificats SSL/TLS](ssl-certificate-rotation-mariadb.md)
+ [Mise à jour des applications pour se connecter aux instances de bases de données Microsoft SQL Server à l'aide des nouveaux certificats SSL/TLS](ssl-certificate-rotation-sqlserver.md)
+ [Mise à jour des applications pour se connecter aux instances de base de données MySQL à l'aide de nouveaux SSL/TLS certificats](ssl-certificate-rotation-mysql.md)
+ [Mise à jour des applications pour se connecter aux instances de base de données Oracle à l'aide de nouveaux SSL/TLS certificats](ssl-certificate-rotation-oracle.md)
+ [Mise à jour des applications pour se connecter aux instances de base de données PostgreSQL à l'aide de nouveaux certificats SSL/TLS](ssl-certificate-rotation-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 instance de base de données ou un cluster , 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 ou le cluster de base de données multi-AZ pour faire passer 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.
**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 les instances de base de données Oracle, nous vous recommandons de redémarrer votre base de données Oracle pour éviter toute erreur de connexion.
Pour les instances RDS for SQL Server Multi-AZ dont l'option de mise en miroir est activée AlwaysOn ou dont l'option de mise en miroir est activée, un basculement est attendu lorsque l'instance est redémarrée après la rotation des certificats.
Pour définir un remplacement pour votre CA d’instance 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).
Vous pouvez utiliser le AWS Management Console ou AWS CLI pour modifier le certificat CA de **rds-ca-2019** à **rds-ca-rsa2048-g1** pour une instance de base de données ou un cluster de base de données multi-AZ.
------
#### [ 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 ou le cluster de bases de données multi-AZ que vous souhaitez modifier.
1. Sélectionnez **Modifier**.
![\[Modification d’une instance de base de données ou d’un cluster de bases de données Multi-AZ\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-modify.png)
1. Dans la section **Connectivité**, choisissez **rds-ca-rsa2048-g1**.
![\[Choisissez un certificat CA\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/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** ou **Modifier le cluster** 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 multi-AZ, appelez la commande or. [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 ou du cluster 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**
**Instance DB**
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.
**Example**
**Cluster de bases de données multi-AZ**
L’exemple suivant modifie `mydbcluster` en définissant le certificat CA sur `rds-ca-rsa2048-g1`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster \
--db-cluster-identifier mydbcluster \
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Pour Windows :
```
aws rds modify-db-cluster ^
--db-cluster-identifier mydbcluster ^
--ca-certificate-identifier rds-ca-rsa2048-g1
```
------
## 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/UserGuide/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/UserGuide/images/ssl-rotate-cert-update-multiple.png)
**Note**
Cette page affiche uniquement les instances de base de données et les clusters 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 ou le cluster de bases de données multi-AZ 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/UserGuide/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/UserGuide/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 et cluster de bases 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
```
------