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 AWS Backup AWS Backup est conforme au [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/), qui inclut des réglementations et des directives pour la protection des données. AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS services. AWS conserve le contrôle des données hébergées sur cette infrastructure, y compris les contrôles de configuration de sécurité pour le traitement du contenu client et des données personnelles. AWS les clients et les AWS partenaires du réseau de partenaires (APN), agissant en tant que responsables du traitement des données ou en tant que sous-traitants, sont responsables de toutes les données personnelles qu'ils saisissent dans le AWS Cloud. Pour des raisons de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer des comptes utilisateur individuels avec Gestion des identités et des accès AWS (IAM). Cela permet de garantir que chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour les besoins de 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. + Utilisez le protocole SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) pour communiquer avec les ressources AWS . + Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut au sein AWS des services. Nous vous recommandons vivement de ne jamais placer d’informations identifiables sensibles, telles que les numéros de compte de vos clients, dans des champs de formulaire comme **Nom**. Cela inclut lorsque vous travaillez avec AWS Backup ou avec d'autres AWS services à l'aide de la console AWS CLI, de l'API ou AWS SDKs. Toutes les données que vous entrez dans AWS Backup ou d'autres services peuvent être récupérées pour être insérées dans des journaux de diagnostic. Lorsque vous fournissez une URL à un serveur externe, n’incluez pas les informations d’identification non chiffrées dans l’URL pour valider votre demande adressée au serveur. Pour en savoir plus sur la protection des données, consultez le billet de blog [Modèle de responsabilité partagée AWS et RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog sur la sécurité d’AWS *. # Chiffrement pour les sauvegardes dans AWS Backup ## Chiffrement indépendant AWS Backup propose un chiffrement indépendant pour les [types de ressources qui prennent en charge AWS Backup la gestion complète](backup-feature-availability.md#features-by-resource). Le chiffrement indépendant signifie que les points de restauration (sauvegardes) que vous créez AWS Backup peuvent avoir une méthode de chiffrement autre que celle déterminée par le chiffrement de la ressource source. Par exemple, votre sauvegarde d'un compartiment Amazon S3 peut utiliser une méthode de chiffrement différente de celle du compartiment source que vous avez chiffré avec le chiffrement Amazon S3. Ce chiffrement est contrôlé par le biais de la configuration des AWS KMS clés dans le coffre de sauvegarde dans lequel votre sauvegarde est stockée. Les sauvegardes de types de ressources qui ne sont pas entièrement gérés par héritent AWS Backup généralement des paramètres de chiffrement de leur ressource source. Vous pouvez configurer ces paramètres de chiffrement conformément aux instructions de ce service, telles que le [chiffrement Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) dans le guide de l'*utilisateur Amazon EBS*. Votre rôle IAM doit avoir accès à la clé KMS utilisée pour sauvegarder et restaurer l'objet. Dans le cas contraire, la tâche est réussie mais les objets ne sont ni sauvegardés ni restaurés. Les autorisations de la politique IAM et de la politique des clés KMS doivent être cohérentes. Pour plus d'informations, consultez la section [Spécification des clés KMS dans les déclarations de politique IAM](https://docs.aws.amazon.com/kms/latest/developerguide/cmks-in-iam-policies.html) du *Guide du AWS Key Management Service développeur*. Le tableau suivant répertorie chaque type de ressource pris en charge. Il indique également la façon dont le chiffrement est configuré pour les sauvegardes et si un chiffrement indépendant est pris en charge pour les sauvegardes. Lorsqu' AWS Backup chiffre une sauvegarde de manière indépendante, il utilise l'algorithme de chiffrement AES-256 standard. Pour plus d'informations sur le chiffrement dans AWS Backup, consultez [la section Sauvegarde entre régions](cross-region-backup.md) et [entre comptes](create-cross-account-backup.md). | Type de ressource | Configuration du chiffrement | AWS Backup Chiffrement indépendant | | --- | --- | --- | | Amazon Simple Storage Service (Amazon S3) | Les sauvegardes Amazon S3 sont chiffrées à l'aide d'une clé AWS KMS (AWS Key Management Service) associée au coffre de sauvegarde. La clé AWS KMS peut être une clé gérée par le client ou une clé AWS gérée associée au service. AWS Backup AWS Backup chiffre toutes les sauvegardes même si les compartiments Amazon S3 source ne sont pas chiffrés. | Pris en charge | | VMware machines virtuelles | Les sauvegardes de machines virtuelles sont toujours chiffrées. La clé de AWS KMS chiffrement pour les sauvegardes de machines virtuelles est configurée dans le AWS Backup coffre dans lequel les sauvegardes de machines virtuelles sont stockées. | Pris en charge | | Amazon DynamoDB après avoir activé [Sauvegarde DynamoDB avancée](advanced-ddb-backup.md) | Les sauvegardes DynamoDB sont toujours chiffrées. La clé de AWS KMS chiffrement pour les sauvegardes DynamoDB est configurée dans AWS Backup le coffre dans lequel les sauvegardes DynamoDB sont stockées. | Pris en charge | | Amazon DynamoDB sans avoir activé [Sauvegarde DynamoDB avancée](advanced-ddb-backup.md) | Les sauvegardes DynamoDB sont automatiquement chiffrées avec la même clé de chiffrement que celle utilisée pour chiffrer la table DynamoDB source. Les instantanés de tables DynamoDB non chiffrés ne sont pas chiffrés non plus. AWS Backup Pour créer une sauvegarde d'une table DynamoDB chiffrée, vous devez ajouter les `kms:Decrypt` autorisations `kms:GenerateDataKey` et le rôle IAM utilisé pour la sauvegarde. Vous pouvez également utiliser le rôle de service AWS Backup par défaut. | Non pris en charge | | Amazon Elastic File System (Amazon EFS) | Les sauvegardes Amazon EFS sont toujours chiffrées. La clé de AWS KMS chiffrement pour les sauvegardes Amazon EFS est configurée dans le AWS Backup coffre dans lequel les sauvegardes Amazon EFS sont stockées. | Pris en charge | | Amazon Elastic Block Store (Amazon EBS) | Par défaut, les sauvegardes Amazon EBS sont soit chiffrées à l'aide de la clé utilisée pour chiffrer le volume source, soit elles ne sont pas chiffrées. Pendant la restauration, vous pouvez choisir de remplacer la méthode de chiffrement par défaut en spécifiant une clé KMS. | Non pris en charge | | Amazon Elastic Compute Cloud (Amazon EC2) AMIs | AMIs ne sont pas chiffrés. Les instantanés EBS sont chiffrés selon les règles de chiffrement par défaut pour les sauvegardes EBS (voir l'entrée relative à EBS). Les instantanés EBS des données et des volumes racines peuvent être chiffrés et attachés à une AMI. | Non pris en charge | | Amazon Relational Database Service (Amazon RDS) | Les instantanés Amazon RDS sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer la base de données Amazon RDS source. Les instantanés de bases de données Amazon RDS non chiffrés ne sont pas chiffrés non plus. | Non pris en charge | | Amazon Aurora | Les instantanés de cluster Aurora sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer le cluster Amazon Aurora source. Les instantanés de clusters Aurora non chiffrés ne sont pas chiffrés. | Non pris en charge | | AWS Storage Gateway | Les instantanés Storage Gateway sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer le volume Storage Gateway source. Les instantanés de volumes Storage Gateway non chiffrés ne sont pas chiffrés non plus. Vous n'avez pas besoin d'utiliser une clé gérée par le client pour tous les services pour activer Storage Gateway. Il vous suffit de copier la sauvegarde Storage Gateway dans un coffre-fort qui a configuré une clé KMS. Cela est dû au fait que Storage Gateway ne possède pas de clé AWS KMS gérée spécifique au service. | Non pris en charge | | Amazon FSx | Les fonctionnalités de chiffrement des systèmes de FSx fichiers Amazon varient en fonction du système de fichiers sous-jacent. Pour en savoir plus sur votre système de FSx fichiers Amazon en particulier, consultez le [guide de FSx l'utilisateur](https://docs.aws.amazon.com/fsx/) approprié. | Non pris en charge | | Amazon DocumentDB | Les instantanés de cluster Amazon DocumentDB sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer le cluster Amazon DocumentDB source. Les instantanés de clusters Amazon DocumentDB non chiffrés ne sont pas chiffrés. | Non pris en charge | | Amazon Neptune | Les instantanés de cluster Neptune sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer le cluster Neptune source. Les instantanés de clusters Neptune non chiffrés ne sont pas chiffrés. | Non pris en charge | | Amazon Timestream | Les sauvegardes d'instantanés de la table Timestream sont toujours chiffrées. La clé de AWS KMS chiffrement pour les sauvegardes Timestream est configurée dans le coffre de sauvegarde dans lequel les sauvegardes Timestream sont stockées. | Pris en charge | | Amazon Redshift | Les clusters Amazon Redshift sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer le cluster Amazon Redshift source. Les instantanés de clusters Amazon Redshift non chiffrés ne sont pas chiffrés. | Non pris en charge | | Amazon Redshift sans serveur | Les instantanés Redshift Serverless sont automatiquement chiffrés avec la même clé de chiffrement que celle utilisée pour chiffrer la source. | Non pris en charge | | CloudFormation | CloudFormation les sauvegardes sont toujours cryptées. La clé de CloudFormation chiffrement pour les CloudFormation sauvegardes est configurée dans le CloudFormation coffre dans lequel les CloudFormation sauvegardes sont stockées. | Pris en charge | | Bases de données SAP HANA sur des instances Amazon EC2 | Les sauvegardes de base de données SAP HANA sont toujours chiffrées. La clé de AWS KMS chiffrement pour les sauvegardes de base de données SAP HANA est configurée dans le AWS Backup coffre dans lequel les sauvegardes de base de données sont stockées. | Pris en charge | **Astuce** [AWS Backup Audit Manager](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-audit-manager.html) vous aide à détecter automatiquement les sauvegardes non chiffrées. ## Chiffrement des copies d'une sauvegarde sur un autre compte ou Région AWS Lorsque vous copiez vos sauvegardes entre comptes ou régions, les copies sont AWS Backup automatiquement chiffrées pour la plupart des types de ressources, même si la sauvegarde d'origine n'est pas chiffrée. AWS Backup chiffre la copie à l'aide de la clé KMS du coffre cible. Avant de copier une sauvegarde d'un compte vers un autre (tâche de copie entre comptes) ou de copier une sauvegarde d'une région à une autre (tâche de copie interrégionale), tenez compte des conditions suivantes, dont la plupart dépendent du fait que le type de ressource de la sauvegarde (point de restauration) est [entièrement géré par AWS Backup ou non entièrement](backup-feature-availability.md#features-by-resource) géré. + Une copie d'une sauvegarde vers une autre Région AWS est chiffrée à l'aide de la clé du coffre de destination. + Pour obtenir une copie d'un point de restauration (sauvegarde) d'une ressource **entièrement gérée par AWS Backup**, vous pouvez choisir de la chiffrer avec une [clé gérée par le client (CMK)](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) ou une clé AWS Backup gérée (`aws/backup`). Pour une copie d'un point de restauration d'une ressource qui **n'est pas entièrement gérée** par AWS Backup, la clé associée au coffre de destination doit être une clé CMK ou la clé gérée du service propriétaire de la ressource sous-jacente. Par exemple, si vous copiez une instance EC2, une clé gérée Backup ne peut pas être utilisée. Il faut plutôt utiliser une clé CMK ou Amazon EBS KMS (`aws/ebs`) pour éviter l'échec de la tâche de copie. + La copie entre comptes avec clés AWS gérées n'est pas prise en charge pour les ressources qui ne sont pas entièrement gérées par AWS Backup. La [politique clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) d'une clé AWS gérée est immuable, ce qui empêche de copier la clé d'un compte à un autre. Si vos ressources sont chiffrées à l'aide de clés AWS gérées et que vous souhaitez effectuer une copie entre comptes, vous pouvez [remplacer les clés de chiffrement](https://repost.aws/knowledge-center/update-encryption-key-rds) par une clé gérée par le client, qui peut être utilisée pour la copie entre comptes. Vous pouvez également suivre les instructions de la [section Protection des instances Amazon RDS chiffrées avec des sauvegardes entre comptes et entre régions](https://aws.amazon.com/blogs/storage/protecting-encrypted-amazon-rds-instances-with-cross-account-and-cross-region-backups/) pour continuer à utiliser AWS des clés gérées. + Les copies des clusters Amazon Aurora, Amazon DocumentDB et Amazon Neptune non chiffrés sont également déchiffrées. ## AWS Backup autorisations, autorisations et déclarations de refus Pour éviter l'échec des tâches, vous pouvez examiner la politique AWS KMS clé pour vous assurer qu'elle dispose des autorisations requises et qu'elle ne contient aucune déclaration de refus empêchant le succès des opérations. Les tâches échouées peuvent se produire en raison d'une ou de plusieurs instructions Deny appliquées à la clé KMS ou en raison d'une [autorisation](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) révoquée pour la clé. Dans une politique d'accès AWS géré telle que [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html), certaines actions Autoriser permettent de créer une interface AWS Backup AWS KMS pour créer une autorisation sur une clé KMS au nom d'un client dans le cadre des opérations de sauvegarde, de copie et de stockage. La politique clé nécessite au minimum les autorisations suivantes : + `kms:createGrant` + `kms:generateDataKey` + `kms:decrypt` Si des politiques de refus sont nécessaires, vous devrez autoriser la liste des rôles requis pour les opérations de sauvegarde et de restauration. Ces éléments peuvent ressembler à : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "KmsPermissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": [ "kms:ListKeys", "kms:DescribeKey", "kms:GenerateDataKey", "kms:ListAliases" ], "Resource": "*" }, { "Sid": "KmsCreateGrantPermissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": [ "kms:CreateGrant" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:backup:backup-vault" }, "Bool": { "kms:GrantIsForAWSResource": true }, "StringLike": { "kms:ViaService": "backup.*.amazonaws.com" } } } ] } ``` ------ Ces autorisations doivent faire partie de la clé, qu'elles soient AWS gérées ou gérées par le client. 1. Assurez-vous que les autorisations requises font partie de la politique clé de KMS 1. Exécutez KMS CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) pour afficher la politique de clé attachée à la clé KMS spécifiée. 1. Vérifiez les autorisations renvoyées. 1. Assurez-vous qu'aucune instruction Deny n'affecte les opérations 1. Exécutez (ou réexécutez) CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) pour afficher la politique de clé attachée à la clé KMS spécifiée. 1. Passez en revue la politique. 1. Supprimez les instructions Deny pertinentes de la politique de clé KMS. 1. Si nécessaire, exécutez [https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html)pour remplacer ou mettre à jour la politique clé avec des autorisations révisées et des instructions Deny supprimées. En outre, la clé associée au rôle à l'origine d'une tâche de copie interrégionale doit figurer `"kms:ResourcesAliases": "alias/aws/backup"` dans l'`DescribeKey`autorisation. # Chiffrement des informations d'identification de l'hyperviseur de machine virtuelle Les machines virtuelles [gérées par un hyperviseur](https://docs.aws.amazon.com//aws-backup/latest/devguide/working-with-hypervisors.html) utilisent [AWS Backup Gateway](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html) pour connecter les systèmes sur site à AWS Backup. Il est important que les hyperviseurs disposent de la même sécurité robuste et fiable. Cette sécurité peut être atteinte en chiffrant l'hyperviseur, soit à l'aide de clés AWS détenues, soit à l'aide de clés gérées par le client. ## AWS clés détenues et gérées par le client AWS Backup fournit le chiffrement des informations d'identification de l'hyperviseur afin de protéger les informations de connexion sensibles des clients à l'aide de clés de **chiffrement AWS détenues**. Vous avez la possibilité d'utiliser des **clés gérées par le client** à la place. Par défaut, les clés utilisées pour chiffrer les informations d'identification dans votre hyperviseur sont des clés **AWS détenues**. AWS Backup utilise ces clés pour chiffrer automatiquement les informations d'identification de l'hyperviseur. Vous ne pouvez ni consulter, ni gérer, ni utiliser AWS les clés que vous possédez, ni auditer leur utilisation. Toutefois, vous n’avez pas besoin de prendre de mesure ou de modifier les programmes pour protéger les clés qui chiffrent vos données. Pour plus d'informations, consultez la section sur les clés AWS détenues dans le [https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt). Les informations d'identification peuvent également être chiffrées à l'aide de *clés gérées par le client*. AWS Backup prend en charge l'utilisation de clés symétriques gérées par le client que vous créez, possédez et gérez pour effectuer votre chiffrement. Étant donné que vous avez le contrôle total de ce chiffrement, vous pouvez effectuer les tâches suivantes : + Établissement et gestion des stratégies de clé + Établissement et gestion des politiques IAM et des octrois + Activation et désactivation des stratégies de clé + Rotation des matériaux de chiffrement de clé + Ajout de balises + Création d’alias de clé + Planification des clés pour la suppression Lorsque vous utilisez une clé gérée par le client, AWS Backup vérifie si votre rôle est autorisé à déchiffrer à l'aide de cette clé (avant l'exécution d'une tâche de sauvegarde ou de restauration). Vous devez ajouter l'action `kms:Decrypt` au rôle utilisé pour démarrer une tâche de sauvegarde ou de restauration. Comme l'action `kms:Decrypt` ne peut pas être ajoutée au rôle de sauvegarde par défaut, vous devez utiliser un rôle autre que le rôle de sauvegarde par défaut pour utiliser les clés gérées par le client. Pour plus d'informations, consultez [Clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) dans le *Manuel du développeur AWS Key Management Service *. ## Octroi requis lors de l'utilisation des clés gérées par le client AWS KMS nécessite une [autorisation](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) pour utiliser votre clé gérée par le client. Lorsque vous importez une [configuration d'hyperviseur](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_ImportHypervisorConfiguration.html) chiffrée à l'aide d'une clé gérée par le client, AWS Backup vous créez une autorisation en votre nom en envoyant une [https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)demande à AWS KMS. AWS Backup utilise des autorisations pour accéder à une clé KMS dans un compte client. Vous pouvez révoquer l'accès à l'autorisation ou supprimer AWS Backup l'accès à la clé gérée par le client à tout moment. Dans ce cas, toutes les passerelles associées à votre hyperviseur ne pourront plus accéder au nom d'utilisateur et au mot de passe de l'hyperviseur chiffrés par la clé gérée par le client, ce qui affectera vos tâches de sauvegarde et de restauration. Plus précisément, les tâches de sauvegarde et de restauration que vous effectuez sur les machines virtuelles de cet hyperviseur échoueront. Backup gateway utilise cette opération `RetireGrant` pour supprimer un octroi lorsque vous supprimez un hyperviseur. ## Surveillance des clés de chiffrement Lorsque vous utilisez une clé gérée par le AWS KMS client avec vos AWS Backup ressources, vous pouvez utiliser [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) pour suivre les demandes AWS Backup envoyées à AWS KMS. Recherchez les AWS CloudTrail événements contenant les `"eventName"` champs suivants pour surveiller les AWS KMS opérations appelées pour accéder AWS Backup aux données chiffrées par votre clé gérée par le client : + `"eventName": "CreateGrant"` + `"eventName": "Decrypt"` + `"eventName": "Encrypt"` + `"eventName": "DescribeKey"`