Protection des données dans Amazon Aurora DSQL - Amazon Aurora DSQL
Chiffrement des donnéesProtection des données dans les régions témoins

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 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. 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) 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 AWS Identity and Access Management. 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 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 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 dans le. Références générales AWS

Pour le chiffrement au repos, consultez Chiffrement au repos dans Aurora DSQL.

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 :

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.