Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Sécurité avec Amazon Aurora PostgreSQL
Pour obtenir une présentation générale de la sécurité Aurora, consultez [Sécurité dans )](UsingWithRDS.md). Vous pouvez gérer la sécurité d’Amazon Aurora PostgreSQL à différents niveaux :
+ Pour contrôler qui peut effectuer des actions de gestion Amazon RDS sur les clusters de bases de données et les instances de base de données Aurora PostgreSQL, Gestion des identités et des accès AWS utilisez (IAM). IAM gère l’authentification de l’identité de l’utilisateur avant que l’utilisateur puisse accéder au service. Il gère également l’autorisation, c’est-à-dire si l’utilisateur est autorisé à faire ce qu’il essaie de faire. L’authentification de base de données IAM est une méthode d’authentification supplémentaire que vous pouvez choisir lorsque vous créez votre cluster de bases de données Aurora PostgreSQL. Pour de plus amples informations, veuillez consulter [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md).
Si vous utilisez IAM avec votre cluster de base de données Aurora PostgreSQL, connectez-vous d'abord à l'aide de vos informations d'identification IAM, avant d'ouvrir AWS Management Console la console Amazon RDS à l'adresse. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)
+ Les clusters de bases de données Aurora doivent être créés dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Pour contrôler les appareils et les instances Amazon EC2 qui peuvent ouvrir des connexions au point de terminaison et au port de l’instance de base de données pour les clusters de bases de données Aurora d’un VPC, vous utilisez un groupe de sécurité VPC. Ces connexions au point de terminaison et au port peuvent être effectuées à l’aide du protocole SSL (Secure Socket Layer). En outre, les règles de pare-feu de votre entreprise peuvent contrôler si les appareils en cours d’exécution dans votre entreprise peuvent ouvrir des connexions à une instance de base de données. Pour plus d’informations sur les VPC, consultez [Amazon VPC et Amazon Aurora](USER_VPC.md).
La location de VPC prise en charge dépend de la classe d’instance de base de données utilisée par vos clusters de bases de données Aurora PostgreSQL. Avec la location de VPC `default`, le cluster de bases de données s’exécute sur du matériel partagé. Avec la location de VPC `dedicated`, le cluster de bases de données s’exécute sur une instance matérielle dédiée. Les classes d’instance de base de données à performances extensibles prennent uniquement en charge la location de VPC par défaut. Les classes d’instance de base de données à performances extensibles incluent les classes d’instance de base de données db.t3 et db.t4g. Toutes les autres classes d’instance de base de données Aurora PostgreSQL prennent en charge à la fois la location de VPC par défaut et dédiée.
Pour plus d’informations sur les classes d’instance, consultez [Amazon AuroraClasses d'instances de base de données](Concepts.DBInstanceClass.md). Pour plus d’informations sur la location de VPC `default` et `dedicated`, consultez [Instances dédiées](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
+ Pour accorder des autorisations aux bases de données PostgreSQL exécutées sur votre cluster de bases de données Amazon Aurora, vous pouvez adopter la même approche générale que pour les instances autonomes de PostgreSQL. Les commandes telles que `CREATE ROLE`, `ALTER ROLE`, `GRANT` et `REVOKE` fonctionnent de la même façon que dans les bases de données sur site, comme le fait la modification directe des bases de données, schémas et tables.
PostgreSQL gère les privilèges en utilisant des *rôles*. Le rôle `rds_superuser` est le rôle disposant du plus haut niveau de privilèges sur un cluster de bases de données Aurora PostgreSQL. Ce rôle est créé automatiquement et il est accordé à l’utilisateur qui crée le cluster de bases de données (le compte utilisateur principal, `postgres` par défaut). Pour en savoir plus, consultez [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Toutes les versions Aurora PostgreSQL disponibles, y compris les versions 10, 11, 12, 13, 14 et les versions ultérieures, prennent en charge le mécanisme d’authentification SCRAM (Salted Challenge Response Authentication Mechanism) pour les mots de passe comme alternative à l’algorithme MD5. Nous vous recommandons d’utiliser SCRAM qui est plus sécurisé que MD5. Pour savoir comment migrer les mots de passe utilisateur de base de données de MD5 vers SCRAM, consultez [Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL](PostgreSQL_Password_Encryption_configuration.md).
## Sécurisation des données Aurora PostgreSQL avec SSL/TLS
Amazon RDS prend en charge le chiffrement SSL (Secure Socket Layer) et TLS (Transport Layer Security) pour les clusters de bases de données Aurora PostgreSQL. À l'aide de SSL/TLS, vous pouvez chiffrer une connexion entre vos applications et vos clusters de bases de données Aurora PostgreSQL. Vous pouvez également forcer l'utilisation de toutes les connexions à votre cluster de base de données Aurora PostgreSQL. SSL/TLS Amazon Aurora PostgreSQL prend en charge le protocole TLS (Transport Layer Security) versions 1.1 et 1.2. Nous vous recommandons d’utiliser TLS 1.2 pour les connexions chiffrées. Nous avons ajouté la prise en charge TLSv1.3 des versions suivantes d'Aurora PostgreSQL :
+ Version 15.3 et toutes les versions ultérieures
+ 14.8 et versions 14 ultérieures
+ 13.11 et versions 13 ultérieures
+ 12.15 et versions 12 ultérieures
+ 11.20 et versions 11 ultérieures
Pour des informations générales sur le SSL/TLS support et les bases de données PostgreSQL, [consultez la section Support SSL](https://www.postgresql.org/docs/current/libpq-ssl.html) dans la documentation PostgreSQL. Pour plus d'informations sur l'utilisation d'une SSL/TLS connexion via JDBC, consultez [la section Configuration du client dans la documentation](https://jdbc.postgresql.org/documentation/head/ssl-client.html) de PostgreSQL.
**Topics**
+ [Exiger une SSL/TLS connexion à un cluster de base de données Aurora PostgreSQL](#AuroraPostgreSQL.Security.SSL.Requiring)
+ [Déterminer l'état de la SSL/TLS connexion](#AuroraPostgreSQL.Security.SSL.Status)
+ [Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora PostgreSQL](#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites)
SSL/TLS le support est disponible dans toutes les AWS régions pour Aurora PostgreSQL. Amazon RDS crée un SSL/TLS certificat pour votre cluster de base de données Aurora PostgreSQL lors de sa création. Si vous activez la vérification du SSL/TLS certificat, le SSL/TLS certificat inclut le point de terminaison du cluster de base de données comme nom commun (CN) du SSL/TLS certificat afin de se protéger contre les attaques par usurpation d'identité.
**Pour vous connecter à un cluster de base de données Aurora PostgreSQL via SSL/TLS**
1. Téléchargez le certificat.
Pour plus d’informations sur le téléchargement de certificats, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une base de données cluster](UsingWithRDS.SSL.md).
1. Importez le certificat dans votre système d’exploitation.
1. Connectez-vous à votre cluster de base de données Aurora PostgreSQL via. SSL/TLS
Lorsque vous vous connectez en utilisant SSL/TLS, votre client peut choisir de vérifier ou non la chaîne de certificats. Si vos paramètres de connexion spécifient `sslmode=verify-ca` ou `sslmode=verify-full`, votre client nécessite que les certificats de l’autorité de certification RDS soient dans leur magasin d’approbations ou référencés dans l’URL de connexion. L’exigence nécessite de vérifier la chaîne du certificat qui signe le certificat de votre base de données.
Lorsqu'un client, tel que psql ou JDBC, est configuré avec le SSL/TLS support, le client essaie d'abord de se connecter à la base de données par SSL/TLS défaut. Si le client ne parvient pas à se connecter avec SSL/TLS, il revient à se connecter sans SSL/TLS. Par défaut, l’option `sslmode` est définie sur `prefer` pour les clients JDBC et libpq.
Utilisez le paramètre `sslrootcert` pour référencer le certificat, par exemple, `sslrootcert=rds-ssl-ca-cert.pem`.
Voici un exemple d’utilisation de psql pour se connecter à un cluster de bases de données Aurora PostgreSQL :
```
$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
"dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"
```
### Exiger une SSL/TLS connexion à un cluster de base de données Aurora PostgreSQL
Pour exiger des SSL/TLS connexions à votre cluster de base de données Aurora PostgreSQL, utilisez le paramètre. `rds.force_ssl`
+ Pour exiger SSL/TLS des connexions, définissez la valeur du `rds.force_ssl` paramètre sur 1 (activé).
+ Pour désactiver SSL/TLS les connexions requises, définissez la valeur du `rds.force_ssl` paramètre sur 0 (désactivé).
La valeur par défaut de ce paramètre dépend de la version d’Aurora PostgreSQL :
+ Pour Aurora PostgreSQL 17 et les versions ultérieures : la valeur par défaut est 1 (activé).
+ Pour Aurora PostgreSQL 16 et les versions antérieures : la valeur par défaut est 0 (désactivé).
**Note**
Lorsque vous effectuez une mise à niveau de version majeure d’Aurora PostgreSQL 16 ou version antérieure vers la version 17 ou une version ultérieure, la valeur par défaut du paramètre passe de 0 (désactivé) à 1 (activé). Ce changement peut entraîner des défaillances de connectivité pour les applications qui ne sont pas configurées pour le protocole SSL. Pour revenir au comportement par défaut précédent, définissez ce paramètre sur 0 (désactivé).
Pour plus d’informations sur la gestion des paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md).
La mise à jour du `rds.force_ssl` paramètre définit également le paramètre `ssl` PostgreSQL sur 1 (activé) et modifie le fichier de votre cluster de bases de données pour prendre en charge `pg_hba.conf` la nouvelle configuration. SSL/TLS
Lorsque le `rds.force_ssl` paramètre est défini sur 1 pour un cluster de base de données, vous obtenez une sortie similaire à la suivante lorsque vous vous connectez, ce qui indique que SSL/TLS c'est désormais obligatoire :
```
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
### Déterminer l'état de la SSL/TLS connexion
Le statut chiffré de votre connexion est affiché dans la page d’accueil d’ouverture de session lorsque vous vous connectez au cluster de bases de données.
```
Password for user master:
psql (9.3.12)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Vous pouvez également charger l'`sslinfo`extension, puis appeler la `ssl_is_used()` fonction pour déterminer si elle SSL/TLS est utilisée. La fonction renvoie `t` si la connexion est utilisée SSL/TLS, sinon elle revient`f`.
```
postgres=> create extension sslinfo;
CREATE EXTENSION
postgres=> select ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Vous pouvez utiliser la `select ssl_cipher()` commande pour déterminer le SSL/TLS code :
```
postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Si vous activez `set rds.force_ssl` et redémarrez le cluster de bases de données, les connexions non-SSL sont refusées avec le message suivant :
```
$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$
```
Pour plus d’informations sur l’option `sslmode`, consultez [Database Connection Control Functions](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) dans la documentation PostgreSQL.
### Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora PostgreSQL
L’utilisation de suites de chiffrement configurables vous permet d’avoir plus de contrôle sur la sécurité des connexions de vos bases de données. Vous pouvez spécifier une liste de suites de chiffrement que vous souhaitez autoriser pour sécuriser les SSL/TLS connexions client à votre base de données. Avec les suites de chiffrement configurables, vous pouvez contrôler le chiffrement de connexion accepté par votre serveur de base de données. Cela permet d’éviter l’utilisation de chiffrements non sécurisés ou obsolètes.
Les suites de chiffrement configurables sont prises en charge dans Aurora PostgreSQL 11.8 et versions ultérieures.
Pour spécifier la liste des chiffrements autorisés pour le chiffrement des connexions, modifiez le paramètre de cluster `ssl_ciphers`. Définissez le `ssl_ciphers` paramètre sur une chaîne de valeurs chiffrées séparées par des virgules dans un groupe de paramètres de cluster à l'aide de l'API AWS Management Console, de ou de l' AWS CLI API RDS. Pour définir des paramètres de cluster, consultez [Modification des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
Le tableau suivant indique les chiffrements autorisés pour chaque version majeure d'Aurora PostgreSQL.
| Version majeure d'APG | Liste des chiffrements autorisés |
| --- | --- |
| 18 | TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_ECDHE\_AES\_RSA\_WITH\_\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_ECD\_D\_SHA HE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_AES\_128\_GCM\_SHA256, TLS\_AES\_256\_GCM\_SHA384 |
| 17 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 16 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 15 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 14 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 13 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 12 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
| 11 | DHE-RSA-AES128-SHA,,,,,,,,, DHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA ECDHE-RSA-AES256-GCM-SHA384, TLS\_ECDHE\_RSA\_WITH\_CHACHA20\_POLY1305\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_RSA\_\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_AES\_128\_GCM\_SHA256, TLS\_ AES\_256\_GCM\_SHA384, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384, ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 |
Vous pouvez également utiliser la commande CLI [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) pour déterminer quelles suites de chiffrement sont actuellement prises en charge pour une famille de groupes de paramètres spécifique. L’exemple suivant montre comment obtenir les valeurs autorisées pour le paramètre de cluster `ssl_cipher` pour Aurora PostgreSQL 11.
```
aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
...some output truncated...
{
"ParameterName": "ssl_ciphers",
"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "list",
"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"IsModifiable": true,
"MinimumEngineVersion": "11.8",
"SupportedEngineModes": [
"provisioned"
]
},
...some output truncated...
```
Le `ssl_ciphers` paramètre utilise par défaut toutes les suites de chiffrement TLS 1.2 autorisées. Pour plus d’informations sur les chiffrements, consultez la variable [ssl\_ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-SSL-CIPHERS) dans la documentation PostgreSQL.
À partir d'Aurora PostgreSQL 18.3, deux paramètres contrôlent les suites de chiffrement proposées par le serveur lors de la prise de contact TLS. Les deux paramètres sont indépendants et complémentaires : ils `ssl_ciphers` contrôlent les chiffrements de version TLS 1.2 et `ssl_tls13_ciphers` les chiffrements de version TLS 1.3.
| Paramètre | Champ d'application du protocole TLS | Adaptabilité | Disponible en | Valeurs autorisées | Valeurs par défaut |
| --- | --- | --- | --- | --- | --- |
| `ssl_ciphers` | TLS 1.2 | Oui | Toutes les versions actuelles d'Aurora PostgreSQL | TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_ECDHE\_AES\_RSA\_WITH\_\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA, TLS\_ECD\_D\_SHA HE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 | TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_RSA\_WITH\_AES\_128\_AES\_128\_GCM\_SHA256, TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384, TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_RSA\_RSA\_WITH\_AES\_128\_GCM\_SHA256, TLS\_RSA\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256, TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 |
| `ssl_tls13_ciphers` | TLS 1.3 | Oui | Aurora PostgreSQL 18.3 et versions ultérieures | TLS\_AES\_128\_GCM\_SHA256, TLS\_AES\_256\_GCM\_SHA384 | TLS\_AES\_128\_GCM\_SHA256, TLS\_AES\_256\_GCM\_SHA384 |
#### Mise à niveau à partir de versions antérieures d'Aurora PostgreSQL
À partir d'Aurora PostgreSQL 18.3, les chiffrements TLS 1.3 ne sont plus contrôlés par le paramètre. `ssl_ciphers` Si vous effectuez une mise à niveau à partir d'une version antérieure et que votre groupe de paramètres de cluster de base de données personnalisé est défini `ssl_ciphers` dans le but de restreindre les chiffrements TLS 1.3, ces entrées ne s'appliquent plus aux connexions TLS 1.3 après la mise à niveau. Pour contrôler la liste de chiffrement TLS 1.3, définissez votre groupe de paramètres `ssl_tls13_ciphers` de cluster de base de données personnalisé.