Chiffrement des ressources Amazon Aurora - Amazon Aurora

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.

Chiffrement des ressources Amazon Aurora

Amazon Aurora protège vos données à la fois au repos et en transit, qu'elles soient transférées entre des clients sur site et Amazon Aurora, ou entre Amazon Aurora et d'autres ressources. AWS Amazon Aurora chiffre toutes les données utilisateur de vos clusters de base de données Amazon Aurora, y compris les journaux, les sauvegardes automatisées et les instantanés.

Une fois vos données chiffrées, Amazon Aurora gère l'authentification de l'accès et le déchiffrement de vos données de manière transparente avec un impact minimal sur les performances. Vous n’avez pas besoin de modifier vos applications clientes de base de données pour utiliser le chiffrement.

Note

Pour les clusters d' de base de données chiffrés et non chiffrés, les données en transit entre la source et les répliques lues sont chiffrées, même lors de la réplication entre régions. AWS

Présentation du chiffrement dans les ressources Amazon Aurora

Les clusters de base de données chiffrée Amazon Aurora fournissent une couche supplémentaire de protection des données en sécurisant vos données contre tout accès non autorisé au stockage sous-jacent. Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après 2026 dans Amazon Aurora sont chiffrés au repos à l'aide du chiffrement AES-256 conforme aux normes du secteur. Ce chiffrement s'effectue automatiquement en arrière-plan, sécurisant ainsi vos données sans aucune action de votre part. Cela permet également de réduire la charge opérationnelle et la complexité liées à la protection des données sensibles. Avec le chiffrement au repos, vous pouvez protéger les applications sensibles en termes de conformité et de sécurité contre les menaces accidentelles et malveillantes, tout en respectant les exigences réglementaires.

Amazon Aurora utilise une AWS Key Management Service clé pour chiffrer ces ressources. AWS KMS combine du matériel et des logiciels sécurisés et hautement disponibles pour fournir un système de gestion des clés adapté au cloud. Lors de la création d'un nouveau cluster de bases de données, Amazon Aurora utilise le chiffrement côté serveur (SSE) avec une cléAWS détenue par défaut. Toutefois, vous pouvez choisir entre trois types de chiffrement en fonction de vos besoins en matière de sécurité et de conformité :

  • AWS clé possédée (SSE-RDS) : clé de chiffrement entièrement AWS contrôlée que vous ne pouvez ni visualiser ni gérer, utilisée automatiquement par Aurora pour le chiffrement par défaut.

  • AWS clé gérée (AMK) — Cette clé est créée et gérée par AWS et est visible dans votre compte, mais elle n'est pas personnalisable. Il n'y a pas de frais mensuels, mais des frais AWS KMS d'API s'appliqueront.

  • Clé gérée par le client (CMK) — La clé est stockée dans votre compte et vous la créez, la détenez et la gérez. Vous avez le contrôle total de la clé KMS (AWS KMS des frais s'appliquent).

AWS les clés gérées constituent une ancienne option de chiffrement qui reste disponible à des fins de rétrocompatibilité. Amazon Aurora utilise des clés AWS détenues par défaut pour chiffrer vos données, offrant ainsi une protection de sécurité renforcée sans frais supplémentaires ni frais de gestion. Dans la plupart des cas d'utilisation, nous recommandons d'utiliser soit la clé AWS détenue par défaut pour des raisons de simplicité et de rentabilité, soit une clé gérée par le client (CMK) si vous avez besoin d'un contrôle total sur vos clés de chiffrement. Pour plus d'informations sur les types de clés, consultez les sections clés gérées par le client et clés AWS gérées.

Note

Important : pour les instances de base de données source ou les clusters créés avant le 18 février 2026, pour lesquels vous n'avez pas opté pour le chiffrement, les instantanés, les clones et les répliques Amazon Aurora (instance de lecture) créés à partir de ces sources ne seront pas chiffrés. Cependant, les opérations de restauration et de réplication logique en dehors du cluster Amazon Aurora produiront des instances chiffrées.

Pour un cluster de bases de données chiffrée Amazon Aurora, les instances de bases de données, journaux, sauvegardes et instantanés sont tous chiffrés. Pour plus d’informations sur la disponibilité et les limites du chiffrement, consultez Disponibilité du chiffrement Amazon Aurora et Limitations des clusters de bases de données chiffrées Amazon Aurora.

Lorsque vous créez un cluster de bases de données chiffré, vous pouvez choisir une clé gérée par le client ou une clé Clé gérée par AWS pour Amazon Aurora pour chiffrer votre cluster de bases de données. Si vous ne spécifiez pas l'identifiant de clé pour une clé gérée par le client, Amazon Aurora l'utilise Clé gérée par AWS pour votre nouveau cluster de bases de données. Amazon Aurora crée un Clé gérée par AWS pour Amazon Aurora pour votre AWS compte. Votre AWS compte est associé à un compte Amazon Aurora différent Clé gérée par AWS pour chaque AWS région.

Pour gérer les clés gérées par le client qui sont utilisées pour le chiffrement et le déchiffrement de vos ressources Amazon Aurora, vous utilisez AWS Key Management Service (AWS KMS).

À l'aide de AWS KMS, vous pouvez créer des clés gérées par le client et définir les politiques permettant de contrôler l'utilisation de ces clés gérées par le client. AWS KMS prend en charge CloudTrail, afin que vous puissiez auditer l'utilisation des clés KMS afin de vérifier que les clés gérées par le client sont utilisées de manière appropriée. Vous pouvez utiliser vos clés gérées par le client avec Amazon Aurora et les AWS services pris en charge tels qu'Amazon S3, Amazon EBS et Amazon Redshift. Pour obtenir la liste des services intégrés AWS KMS, consultez la section Intégration des AWS services. Quelques considérations relatives à l’utilisation des clés KMS :

  • Une fois que vous avez créé une instance de base de données chiffrée, vous ne pouvez pas modifier la clé KMS utilisée par cette instance. Assurez-vous de déterminer vos exigences en matière de clé KMS avant de créer votre instance de base de données chiffrée. Si vous devez modifier la clé de chiffrement de votre cluster de base de données, procédez comme suit :

    • Créez un instantané manuel de votre cluster.

    • Restaurez le snapshot et activez le chiffrement avec la clé KMS de votre choix pendant l'opération de restauration.

  • Si vous restaurez un instantané non chiffré et que vous choisissez de ne pas chiffrer, le cluster de base de données créé sera chiffré à l'aide du chiffrement par défaut au repos (cléAWS détenue par -owned).

  • Vous ne pouvez pas partager un instantané chiffré à l'aide Clé gérée par AWS du AWS compte qui l'a partagé.

  • Chaque instance de base de données du cluster de base de données partage le même stockage chiffré avec la même clé KMS.

Important

Dans certains cas, Amazon Aurora peut perdre l’accès à la clé KMS pour un cluster de bases de données lorsque vous désactivez la clé KMS. Dans ce cas, le cluster de bases de données chiffré entre dans l’état inaccessible-encryption-credentials-recoverable. Le cluster de bases de données reste dans cet état pendant sept jours, pendant lesquels l’instance est arrêtée. Les appels d’API effectués vers le cluster de bases de données pendant cette période risquent d’échouer. Pour restaurer le cluster de bases de données, activez la clé KMS, puis redémarrez le cluster. Vous pouvez activer la clé KMS depuis l'API AWS Management Console AWS CLI, ou RDS. Redémarrez le cluster de base de données à l'aide de la AWS CLI commande start-db-clusterou AWS Management Console.

L’état inaccessible-encryption-credentials-recoverable s’applique uniquement aux clusters de bases de données qui peuvent être interrompus. Cet état récupérable ne s’applique pas aux instances qui ne peuvent pas s’arrêter, telles que les clusters contenant des réplicas en lecture inter-régions. Pour plus d’informations, consultez Limites liées à l’arrêt et au démarrage des clusters de bases de données Aurora.

Si le cluster de bases de données n’est pas récupéré dans un délai de sept jours, il passe à l’état inaccessible-encryption-credentials terminal. Dans cet état, le cluster de bases de données n’est plus utilisable et vous ne pouvez le restaurer qu’à partir d’une sauvegarde. Nous vous recommandons vivement de toujours activer les sauvegardes pour éviter la perte de données dans vos bases de données.

Lors de la création d’un cluster de bases de données, Aurora vérifie si le principal appelant dispose a accès à la clé KMS, puis génère une autorisation à partir de cette clé KMS, qu’il utilisera pendant toute la durée de vie du cluster de bases de données. La révocation de l’accès du principal appelant à la clé KMS n’affecte pas la base de données en cours d’exécution. Lorsque vous utilisez des clés KMS dans des scénarios entre comptes, tels que la copie d’un instantané sur un autre compte, la clé KMS doit être partagée avec l’autre compte. Si vous créez un cluster de bases de données à partir de l’instantané sans spécifier de clé KMS différente, le nouveau cluster utilise la clé KMS du compte source. Le fait de révoquer l’accès à la clé après la création du cluster de bases de données n’a aucun impact sur ce cluster. Toutefois, la désactivation de la clé affecte tous les clusters de bases de données chiffrés avec cette clé. Afin d’éviter cette situation, indiquez une clé différente au moment de la copie de l’instantané.

Pour plus d’informations sur les clés KMS, consultez AWS KMS keys dans le Guide du développeur AWS Key Management Service et AWS KMS key gestion.

Chiffrement d’un cluster de bases de données Amazon Aurora

Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après cette date sont chiffrés par défaut à l'aide d'une clé AWS détenue.

Pour chiffrer un nouveau cluster de base de données à l'aide d'une clé gérée par le client Clé gérée par AWS ou d'une clé gérée par le client, choisissez l'option sur la console. Pour plus d’informations sur la création d’un cluster de bases de données, consultez Création d’un cluster de bases de données Amazon Aurora.

Si vous utilisez la create-db-cluster AWS CLI commande pour créer un cluster de base de données chiffré, définissez le --storage-encrypted paramètre. Si vous utilisez l'opération Create DBCluster API, définissez le StorageEncrypted paramètre sur true.

Une fois que vous avez créé un cluster de bases de données chiffrées, vous ne pouvez pas modifier la clé KMS pour ce cluster de bases de données. Vous devez donc prendre soin de déterminer vos besoins en termes de clés KMS avant de créer votre cluster de base de données chiffrées.

Si vous utilisez la AWS CLI create-db-cluster commande pour créer un cluster de base de données chiffré avec une clé gérée par le client, définissez le --kms-key-id paramètre sur n'importe quel identifiant de clé pour la clé KMS. Si vous utilisez l’opération Amazon RDS de l’API CreateDBInstance, définissez le paramètre KmsKeyId sur n’importe quel identifiant de clé pour la clé KMS. Pour utiliser une clé gérée par le client dans un autre AWS compte, spécifiez l'ARN de la clé ou l'alias ARN.

Détermination si le chiffrement est activé pour un cluster de bases de données

Vous pouvez utiliser l'API AWS Management Console AWS CLI, ou RDS pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données.

Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données
  1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à https://console.aws.amazon.com/rds/l'adresse.

  2. Dans le panneau de navigation, choisissez Databases (Bases de données).

  3. Sélectionnez le nom du cluster de base de données que vous souhaitez vérifier pour en voir les détails.

  4. Cliquez sur l’onglet Configuration et cochez la case Encryption (Chiffrement).

    Vérification du chiffrement au repos pour un cluster de base de données

Pour déterminer si le chiffrement au repos est activé pour un cluster de base de données à l'aide de AWS CLI, appelez la describe-db-clusterscommande avec l'option suivante :

  • --db-cluster-identifier : nom du cluster de bases de données.

L’exemple suivant utilise une requête pour renvoyer TRUE ou FALSE concernant le chiffrement au repos pour le cluster de bases de données mydb.

Exemple
aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text

Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données à l'aide de l'API Amazon RDS, appelez l'DBClustersopération Describe avec le paramètre suivant :

  • DBClusterIdentifier : nom du cluster de bases de données.

Disponibilité du chiffrement Amazon Aurora

Le chiffrement Amazon Aurora est actuellement disponible pour tous les moteurs de base de données et types de stockage.

Note

Le chiffrement Amazon Aurora n’est pas disponible pour la classe d’instance de base de données db.t2.micro.

Chiffrement en transit

Chiffrement au niveau de la couche physique

Toutes les données circulant Régions AWS sur le réseau AWS mondial sont automatiquement cryptées au niveau de la couche physique avant de quitter les installations AWS sécurisées. Tout le trafic entre les deux AZs est crypté. Des couches supplémentaires de chiffrement, y compris celles présentées dans cette section, peuvent fournir des protections supplémentaires.

Chiffrement fourni par le peering Amazon VPC et le peering interrégional Transit Gateway

Tout le trafic entre régions qui utilise un appairage VPC Amazon et Transit Gateway est automatiquement chiffré en bloc quand il quitte une région. Une couche de cryptage supplémentaire est automatiquement fournie au niveau de la couche physique pour tout le trafic avant qu'il ne quitte les installations AWS sécurisées.

Chiffrement entre les instances

AWS fournit une connectivité sécurisée et privée entre les instances de base de données de tous types. En outre, certains types d’instances utilisent les capacités de déchargement du matériel du système Nitro sous-jacent pour chiffrer automatiquement le trafic en transit entre instances. Ce chiffrement utilise des algorithmes de chiffrement authentifié avec données associées (AEAD), avec un chiffrement 256 bits. Il n’y a aucun impact sur les performances du réseau. Pour prendre en charge ce chiffrement supplémentaire du trafic en transit entre les instances, les exigences suivantes doivent être satisfaites :

  • Les instances utilisent les types d’instance suivants :

    • Usage général : M6i, M6id, M6in, M6idn, M7g

    • Optimisé pour la mémoire : R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn

  • Les instances se trouvent dans la même Région AWS.

  • Les instances se trouvent dans le même VPC ou peered VPCs, et le trafic ne passe pas par un périphérique ou un service réseau virtuel, tel qu'un équilibreur de charge ou une passerelle de transit.

Limitations des clusters de bases de données chiffrées Amazon Aurora

Les limitations suivantes existent pour les clusters de bases de données chiffrés Amazon Aurora :

  • Vous ne pouvez pas désactiver le chiffrement d’un cluster de bases de données chiffré.

  • Si vous disposez d'un cluster non chiffré existant, tous les instantanés créés à partir de ce cluster seront également déchiffrés. Pour créer un instantané chiffré à partir d'un cluster non chiffré, vous devez le copier et spécifier une clé gérée par le client lors de l'opération de copie. Vous ne pouvez pas créer un instantané chiffré à partir d'un instantané non chiffré sans spécifier une clé gérée par le client.

  • Vous ne pouvez pas créer un instantané chiffré d'une de base de données non chiffrée.

  • Un instantané de cluster de bases de données chiffrées doit être chiffré à l’aide de la même clé KMS que le cluster de bases de données.

  • Vous ne pouvez pas convertir un cluster de base de données non chiffrée vers un cluster chiffré. Toutefois, vous pouvez restaurer un instantané non chiffré dans un cluster de bases de données Aurora chiffré. Pour ce faire, spécifiez une clé KMS lorsque vous procédez à la restauration à partir de l’instantané non chiffré.

  • Si vous disposez d'un cluster non chiffré existant, toute réplique Amazon Aurora (instance de lecture) créée à partir de ce cluster sera également déchiffrée. Pour créer un cluster chiffré à partir d'un cluster non chiffré, vous devez restaurer le cluster de base de données. Le cluster restauré sera chiffré par défaut après l'opération de restauration.

  • Pour copier un instantané chiffré d'une AWS région à une autre, vous devez spécifier la clé KMS dans la AWS région de destination. Cela est dû au fait que les clés KMS sont spécifiques à la AWS région dans laquelle elles sont créées.

    L'instantané source reste chiffré pendant tout le processus de copie. Amazon Aurora utilise un chiffrement d’enveloppe pour protéger les données pendant le processus de copie. Pour plus d’informations sur le chiffrement d’enveloppe, consultez Chiffrement d’enveloppe dans le Guide du développeur AWS Key Management Service .

  • Vous ne pouvez pas déchiffrer un d’instances de base de données chiffrées. Vous pouvez cependant exporter des données à partir d’un d’instances de base de données et importer les données dans un d’instances de base de données non chiffrées.