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 dans Amazon Aurora DSQL
Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) s’applique à la protection des données dans AWS. Comme décrit dans ce modèle, AWS est responsable de la protection de l’infrastructure globale sur laquelle l’ensemble du AWS Cloud s’exécute. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des services que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’ et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécurité *.
À des fins de protection des données, nous vous recommandons de protéger les informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS. Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d’informations sur l’utilisation des sentiers pour capturer des activités, consultez [Utilisation des sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *Guide de l’utilisateur*.
+ Utilisez des solutions de chiffrement, ainsi que tous les contrôles de sécurité par défaut au sein des Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec ou d'autres utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
## Chiffrement des données
Amazon Aurora DSQL offre une infrastructure de stockage hautement durable, pensée pour le stockage de données primaires et stratégiques. Les données sont stockées de façon redondante sur plusieurs appareils situés dans plusieurs installations au sein d’une même région Aurora DSQL.
### Chiffrement en transit
Par défaut, le chiffrement en transit est configuré pour vous. Aurora DSQL utilise le protocole TLS pour chiffrer tout le trafic entre votre client SQL et Aurora DSQL.
Chiffrement et signature des données en transit entre les AWS CLI clients du SDK ou de l'API et les points de terminaison SQL Aurora :
+ Aurora DSQL fournit des points de terminaison HTTPS pour le chiffrement des données en transit.
+ Pour protéger l’intégrité des demandes d’API adressées à Aurora DSQL, les appels d’API doivent être signés par l’appelant. Les appels sont signés par un certificat X.509 ou par la clé d'accès AWS secrète du client conformément au processus de signature Signature version 4 (Sigv4). Pour plus d’informations, consultez [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans le *Références générales AWS*.
+ Utilisez le AWS CLI ou l'un des AWS SDKs pour envoyer des demandes à AWS. Ces outils signent automatiquement les demandes avec la clé d’accès que vous spécifiez lors de leur configuration.
#### Conformité FIPS
Les points de terminaison du plan de données Aurora DSQL (points de terminaison de cluster utilisés pour les connexions aux bases de données) utilisent par défaut des modules cryptographiques validés par la norme FIPS 140-2. Aucun point de terminaison FIPS distinct n'est requis pour les connexions au cluster.
Pour les opérations du plan de contrôle, Aurora DSQL fournit des points de terminaison FIPS dédiés dans les régions prises en charge. Pour plus d'informations sur les points de terminaison FIPS du plan de contrôle, consultez la section Points de [terminaison et quotas Aurora DSQL](https://docs.aws.amazon.com/general/latest/gr/dsql.html) dans le. *Références générales AWS*
Pour le chiffrement au repos, consultez [Chiffrement au repos dans Aurora DSQL](data-encryption.md#encryption-at-rest).
### Confidentialité du trafic inter-réseaux
Les connexions sont protégées à la fois entre Aurora DSQL et les applications sur site et entre Aurora DSQL et les autres AWS ressources de ces applications. Région AWS
Vous disposez de deux options de connectivité entre votre réseau privé et AWS :
+ Une connexion AWS Site-to-Site VPN. Pour plus d’informations, consultez [Qu’est-ce qu’ AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Une Direct Connect connexion. Pour plus d'informations, voir [Qu'est-ce que c'est Direct Connect ?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
Vous accédez à Aurora DSQL via le réseau en utilisant les opérations d’API publiées par AWS. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
## Protection des données dans les régions témoins
Lorsque vous créez un cluster multi-régions, une région témoin permet la reprise automatique en cas de défaillance en participant à la réplication synchrone des transactions chiffrées. Si un cluster associé devient indisponible, la région témoin reste disponible pour valider et traiter les écritures de base de données, sans perte de disponibilité.
Les régions témoins protègent et sécurisent vos données grâce à ces caractéristiques de conception :
+ La région témoin reçoit et stocke uniquement les journaux de transactions chiffrés. Elle n’héberge, ne stocke ni ne transmet jamais vos clés de chiffrement.
+ La région témoin se concentre uniquement sur les fonctions d’écriture, d’enregistrement des transactions et de quorum. Elle ne peut pas lire vos données de par sa conception.
+ La région témoin fonctionne sans points de terminaison de connexion au cluster ni processeurs de requêtes. Cela empêche l’accès à la base de données utilisateur.
Pour plus d’informations sur les régions témoins, consultez [Configuration de clusters multi-régions](configuring-multi-region-clusters.md).
# Configuration des SSL/TLS certificats pour les connexions Aurora DSQL
Aurora DSQL exige que toutes les connexions utilisent le chiffrement par protocole TLS (Transport Layer Security). Pour établir des connexions sécurisées, votre système client doit faire confiance à Amazon Root CA 1 (Root Certificate Authority). Ce certificat est préinstallé sur de nombreux systèmes d’exploitation. Cette section fournit des instructions pour vérifier le certificat Amazon Root CA 1 préinstallé sur différents systèmes d’exploitation et vous guide tout au long du processus d’installation manuelle du certificat s’il n’est pas déjà présent.
Nous vous recommandons d’utiliser la version 17 de PostgreSQL.
**Important**
Pour les environnements de production, nous recommandons d’utiliser le mode SSL `verify-full` pour garantir le plus haut niveau de sécurité de connexion. Ce mode vérifie que le certificat du serveur est signé par une autorité de certification fiable et que le nom d’hôte du serveur correspond au certificat.
## Vérification des certificats préinstallés
Dans la plupart des systèmes d’exploitation, **Amazon Root CA 1** est déjà préinstallé. Pour le valider, suivez les étapes indiquées ci-dessous.
### Linux (RedHat/CentOS/Fedora)
Exécutez la commande suivante dans votre terminal :
```
trust list | grep "Amazon Root CA 1"
```
Si le certificat est installé, vous obtenez la sortie suivante :
```
label: Amazon Root CA 1
```
### macOS
1. Ouvrez Spotlight Search (**Command** \$1 **Espace**)
1. Recherchez **Keychain Access**
1. Sélectionnez **System Roots** sous **System Keychains**
1. Recherchez **Amazon Root CA 1** dans la liste des certificats
### Windows
**Note**
En raison d’un problème connu avec le client Windows PSQL, l’utilisation de certificats racine du système (`sslrootcert=system`) peut renvoyer l’erreur suivante : `SSL error: unregistered scheme`. Vous pouvez suivre la méthode [Connexion depuis Windows](#connect-windows) comme méthode alternative pour vous connecter à votre cluster à l’aide du protocole SSL.
Si **Amazon Root CA 1** n’est pas installé sur votre système d’exploitation, suivez les étapes ci-dessous.
## Installation de certificats
Si le certificat `Amazon Root CA 1` n’est pas préinstallé sur votre système d’exploitation, vous devrez l’installer manuellement afin d’établir des connexions sécurisées avec votre cluster Aurora DSQL.
### Installation du certificat Linux
Suivez ces étapes pour installer le certificat Amazon Root CA sur les systèmes Linux.
1. Téléchargez le certificat racine :
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Ajoutez le certificat au Trust Store :
```
sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/
```
1. Mettez à jour le CA Trust Store :
```
sudo update-ca-trust
```
1. Vérifier l’installation :
```
trust list | grep "Amazon Root CA 1"
```
### Installation du certificat macOS
Ces étapes d’installation du certificat sont facultatives. L’[Installation du certificat Linux](#install-linux) fonctionne également pour un macOS.
1. Téléchargez le certificat racine :
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Ajoutez le certificat au trousseau du système :
```
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem
```
1. Vérifier l’installation :
```
security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain
```
## Connexion avec SSL/TLS vérification
Avant de configurer SSL/TLS des certificats pour des connexions sécurisées à votre cluster Aurora DSQL, assurez-vous de remplir les conditions préalables suivantes.
+ PostgreSQL version 17 installée
+ AWS CLI configuré avec les informations d'identification appropriées
+ Informations sur les points de terminaison du cluster Aurora DSQL
### Connexion depuis Linux
1. Générez et définissez le jeton d’authentification :
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connectez-vous à l’aide de certificats système (s’ils sont préinstallés) :
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Ou connectez-vous à l’aide d’un certificat téléchargé :
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
**Note**
Pour en savoir plus sur les paramètres PGSSLMODE, consultez [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) dans la documentation [Fonctions de contrôle de connexion à la base de données](https://www.postgresql.org/docs/current/libpq-connect.html) PostgreSQL 17.
### Connexion depuis macOS
1. Générez et définissez le jeton d’authentification :
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connectez-vous à l’aide de certificats système (s’ils sont préinstallés) :
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Vous pouvez également télécharger le certificat racine et l’enregistrer sous `root.pem` (si le certificat n’est pas préinstallé)
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
1. Connexion à l’aide de psql :
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
### Connexion depuis Windows
#### Utilisation d’une invite de commande
1. Générez le jeton d’authentification :
```
aws dsql generate-db-connect-admin-auth-token ^
--region=your-cluster-region ^
--expires-in=3600 ^
--hostname=your-cluster-endpoint
```
1. Définissez la variable d’environnement mot de passe :
```
set "PGPASSWORD=token-from-above"
```
1. Définissez la configuration SSL :
```
set PGSSLROOTCERT=C:\full\path\to\root.pem
set PGSSLMODE=verify-full
```
1. Établissez une connexion à la base de données :
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^
--username admin ^
--host your-cluster-endpoint
```
#### En utilisant PowerShell
1. Générez et définissez le jeton d’authentification :
```
$env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint)
```
1. Définissez la configuration SSL :
```
$env:PGSSLROOTCERT='C:\full\path\to\root.pem'
$env:PGSSLMODE='verify-full'
```
1. Établissez une connexion à la base de données :
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres `
--username admin `
--host your-cluster-endpoint
```
## Ressources supplémentaires
+ [Documentation PostgreSQL SSL](https://www.postgresql.org/docs/current/libpq-ssl.html)
+ [Amazon Trust Services](https://www.amazontrust.com/repository/)