Sécurisation des données au repos avec le chiffrement...Le JCE sous-jacent dans votre application...

Amazon Web Services - Chiffrement de données au repos dans AWS novembre 2013

sur 17

Sécurisation des données au repos avec le chiffrement

Ken Beer Ryan Holland

Novembre 2013

(Consultez http://aws.amazon.com/whitepapers pour obtenir la version la plus récente de ce livre blanc)

Résumé Les politiques organisationnelles ou les réglementations sectorielles ou gouvernementales peuvent nécessiter l'utilisation du chiffrement au repos pour protéger vos données. Avec sa nature flexible, Amazon Web Services (AWS) vous permet de choisir entre de nombreuses options qui répondent à vos besoins. Ce livre blanc présente les différentes méthodes de chiffrement de vos données au repos disponibles à l'heure actuelle.

Introduction Amazon Web Services (AWS) propose une plateforme de cloud computing évolutive et sécurisée, à la disponibilité élevée, qui vous offre la flexibilité pour créer une large gamme d'applications. Si vous avez besoin d'une couche supplémentaire de sécurité pour les données que vous stockez dans le cloud, il existe de nombreuses options pour le chiffrement de données au repos, des solutions de chiffrement d'AWS totalement automatisées aux options manuelles côté client. Le choix des bonnes solutions dépend du service AWS que vous utilisez et de vos exigences pour la gestion


sur 17

des clés. Ce livre blanc présente de nombreuses méthodes de chiffrement de données au repos dans AWS. Des liens vers des ressources supplémentaires sont proposés pour une meilleure compréhension de la façon de mettre en place concrètement les méthodes de chiffrement.

La clé du chiffrement : Qui contrôle les clés ?

Le chiffrement d'un système nécessite trois composants : (i) des données à chiffrer ; (ii) une méthode de chiffrement des données à l'aide d'un algorithme cryptographique ; et (iii) des clés de chiffrement à utiliser avec les données et l'algorithme. La plupart des langages de programmation modernes fournissent des bibliothèques avec de nombreux algorithmes cryptographiques disponibles, comme AES (Advanced Encryption Standard). Le choix du bon algorithme implique l'évaluation des exigences en matière de sécurité, de performances et de conformité spécifiques à votre application. Si le choix d'un algorithme de chiffrement est important, la protection des clés contre les accès non autorisés est essentielle. La gestion de la sécurité des clés de chiffrement se fait souvent à l'aide d'une infrastructure de gestion des clés (KMI). Une KMI est elle-même composée de deux sous-composants : la couche de stockage qui protège les clés en texte brut et la couche de gestion qui autorise l'utilisation de la clé. Pour protéger les clés dans une KMI il existe une manière courante qui consiste à utiliser un module de sécurité matérielle (HSM). Un HSM est un appareil de stockage et de traitement des données dédié qui réalise des opérations cryptographiques à l'aide des clés sur l'appareil. Un HSM fournit généralement des témoins antiviolation pour protéger les clés contre une utilisation non autorisée. Une couche d'autorisation basée sur le logiciel contrôle les personnes pouvant administrer le HSM et précise quels utilisateurs ou quelles applications peuvent utiliser des clés précises dans le HSM.

Lorsque vous déployez le chiffrement pour de nombreuses classifications de données dans AWS, il est important de comprendre exactement qui a accès à vos clés ou données de chiffrement et dans quelles conditions. Il existe trois modèles différents de fournir la méthode de chiffrement et la KMI.

A. Vous contrôlez la méthode de chiffrement et l’ensemble de la KMI.

B. Vous contrôlez la méthode de chiffrement, AWS fournit le composant de stockage pour la KMI pendant que vous vous chargez de la couche de gestion de la KMI.

C. AWS contrôle la méthode de chiffrement et l'ensemble de la KMI.

Modèle A : Vous contrôlez la méthode de chiffrement et l'ensemble de la KMI Dans ce modèle, vous utilisez votre propre KMI pour générer, stocker et gérer l'accès aux clés, ainsi que pour contrôler toutes les méthodes de chiffrement dans vos applications. Cet emplacement physique de la KMI et la méthode de chiffrement peuvent être extérieurs à AWS ou se trouver dans l'instance Amazon EC2 (Amazon Elastic Compute Cloud) que vous possédez. La méthode de chiffrement peut être une combinaison des outils à code source libre, les kits de développement logiciel (SDK) AWS ou les logiciels tiers et/ou de matériel. Ce modèle présente une propriété de sécurité importante en ce que vous avez le contrôle complet des clés de chiffrement et de l'environnement d'exécution qui


sur 17

utilise ces clés dans le code de chiffrement. AWS n'a pas accès à vos clés et ne parvient pas à effectuer le chiffrement ou le déchiffrement en votre nom. Vous êtes chargé du stockage, de la gestion et de l'utilisation corrects des clés, pour garantir la confidentialité, l'intégrité et la disponibilité de vos données. Les données peuvent être chiffrées dans des services AWS de la manière décrite dans les sections suivantes.

Amazon S3

Vous pouvez chiffrer des données à l'aide d'une méthode de chiffrement souhaitée, puis téléchargez les données chiffrées à l'aide des API d'Amazon Simple Storage Service (Amazon S3). Les principaux langages d'application comprennent des bibliothèques cryptographiques qui vous permettent de réaliser le chiffrement dans vos applications. Les deux outils en code source libre suivants sont couramment disponibles : Bouncy Castle et OpenSSL. Après avoir chiffré un objet et stocké en toute sécurité la clé dans votre KMI, l'objet chiffré peut être téléchargé sur Amazon S3 directement avec une demande PUT. Pour déchiffrer ces données, vous émettez la demande GET dans l'API Amazon S3, puis vous transférez les données chiffrées vers votre application locale pour qu'elle les déchiffre.

AWS propose une solution de remplacement à ces outils de déchiffrement en code source libre avec le client de chiffrement Amazon S3 ; il s'agit d’un ensemble d'API en code source libre intégrées aux SDK AWS. Ce client vous fournit une clé depuis votre KMI pouvant être utilisée pour chiffrer ou déchiffrer vos données dans le cadre de l'appel vers Amazon S3. Le SDK tire parti de vos JCE (Java Cryptography Extension) dans votre application pour utiliser votre clé symétrique ou asymétrique comme entrée et chiffrer l'objet avant de le télécharger dans Amazon S3. Le processus est inversé lorsque le SDK est utilisé pour récupérer un objet ; l'objet chiffré téléchargé depuis Amazon S3 est transféré au client avec la clé de votre KMI. Le JCE sous-jacent dans votre application déchiffre l'objet. Le client de chiffrement Amazon S3 est intégré aux SDK AWS pour Java, Ruby et .NET et fournit un substitut transparent pour le code cryptographique que vous avez peut-être utilisé précédemment avec votre application en interaction avec Amazon S3. Certes Amazon fournit la méthode de chiffrement, mais c’est vous qui contrôlez la sécurité de vos données car vous contrôlez les clés à utiliser pour ce moteur. Si vous utilisez le client de chiffrement d'Amazon S3 sur site, AWS n'a jamais accès à vos clés ou données non chiffrées. Si vous utilisez le client dans une application exécutée sur Amazon EC2, il est judicieux de transférer des clés vers le client à l'aide d'un transport sécurisé (p. ex., SSL ou SSH) depuis votre KMI pour garantir la confidentialité. Pour plus d'informations, consultez la http://aws.amazon.com/sdkforjava/ documentation du SDK AWS pour Java et la section Utilisationdu chiffrementcôté client dans le Manuel du développeur d'Amazon S3. La figure 1 montre comment ces deux méthodes de chiffrement côté client fonctionnent pour les données Amazon S3.

http://www.bouncycastle.org/




http://www.openssl.org/


http://aws.amazon.com/sdkforjava/



http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html





sur 17

Figure 1 : Chiffrement côté client Amazon S3 depuis le système sur site ou votre application Amazon EC2

Des solutions tierces sont disponibles, elles permettent de simplifier le processus de gestion de clé lors du chiffrement des données dans Amazon S3. CloudBerry Explorer PRO pour Amazon S3 et CloudBerry Backup proposent tous les deux une option de chiffrement côté client qui utilise un mot de passe défini par l'utilisateur sur le schéma de chiffrement, afin de protéger les fichiers stockés dans Amazon S3. Pour les besoins de chiffrement par programmation, SafeNet ProtectApp for Java s’intègre à la KMI SafeNet KeySecure pour proposer un chiffrement côté client dans votre application. La KMI KeySecure fournit un stockage de clé sécurisé et l'application des politiques pour des clés transmises au client Java ProtectApp compatible avec le SDK AWS. La KMI KeySecure peut être exécutée comme une appliance sur site ou une appliance virtuelle dans Amazon EC2. La figure 2 montre comment la solution SafeNet peut être utilisée pour chiffrer des données stockées sur Amazon S3.

Figure 2 : Chiffrement côté client Amazon S3 depuis le système sur site ou votre application dans Amazon EC2 à l'aide de la

KMI SafeNet ProtectApp et SafeNet KeySecure

http://www.cloudberrylab.com/amazon-s3-explorer-pro-cloudfront-IAM.aspx


http://www.cloudberrylab.com/amazon-s3-cloud-desktop-backup.aspx

http://www.cloudberrylab.com/amazon-s3-cloud-desktop-backup.aspx

http://www.safenet-inc.com/Products_V2/tier4.aspx?id=8589935277&terms=protectapp


sur 17

Amazon EBS

Amazon Elastic Block Store (Amazon EBS) fournit des volumes de stockage de niveau bloc à utiliser avec les instances Amazon EC2. Les volumes Amazon EBS sont connectés au réseau et persistent indépendamment de la durée de vie de l'instance. Étant donné que les volumes Amazon EBS sont présentés sur une instance comme un périphérique de stockage en mode bloc, vous pouvez tirer parti de la plupart des outils de chiffrement standard pour un chiffrement au niveau du système de fichiers ou du bloc. Parmi les solutions fréquentes de chiffrement en code source libre au niveau du bloc pour Linux figurent LoopAES, dm-crypt (avec ou sans) LUKS et TrueCrypt. Chaque solution fonctionne sous la couche du système de fichiers à l'aide de pilotes d'espace noyau pour procéder au chiffrement et au déchiffrement des données. Ces outils sont utiles lorsque vous voulez que toutes les données écrites sur un volume soient chiffrées, quel que soit le répertoire dans lequel les données sont stockées. Une autre option consiste à utiliser le chiffrement au niveau du système de fichiers, qui fonctionne en empilant un système de fichiers chiffré au-dessus d'un système de fichiers existant. Cette méthode est généralement utilisée pour le chiffrement d'un répertoire spécifique. eCryptfs et EncFs sont deux exemples d'outils de chiffrement en code source libre basés sur Linux au niveau du système de fichiers. Ces solutions exigent que vous fournissiez des clés, manuellement ou depuis votre KMI. Concernant les outils de chiffrement au niveau du bloc et du système de fichiers, il convient d’avoir à l’esprit qu'ils ne peuvent être utilisés que pour chiffrer des volumes de données qui ne sont pas des volumes de démarrage Amazon EBS. Cela est dû au fait que ces outils ne vous permettent pas de faire en sorte qu’une clé approuvée soit automatiquement disponible sur le volume de démarrage au démarrage.

Le chiffrement de volumes Amazon EBS liés à des instances Windows peut être réalisé à l'aide de BitLocker ou de Encrypted File System (EFS), ainsi que d'applications en code source libre open source comme TrueCrypt. Dans tous les cas, vous devez toujours fournir ces clés pour ces méthodes de chiffrement et vous pouvez uniquement chiffrer des volumes de données.

Il existe des solutions partenaires d'AWS qui permettent d'automatiser le processus de chiffrement des volumes Amazon EBS, ainsi que pour la fourniture et la protection des clés nécessaires. Trend Micro SecureCloud et SafeNet ProtectV sont tous les deux des produits partenaires qui chiffrent des volumes Amazon EBS et comprennent une KMI. Les deux produits peuvent chiffrer des volumes de démarrage en plus des volumes de données. Ces solutions prennent également en charge des cas d'utilisation dans lesquels les volumes Amazon EBS sont fixés à des instances Amazon EC2 d'un groupe Auto Scaling. La figure 3 montre comment les solutions SafeNet et Trend Micro peuvent être utilisées pour chiffrer des données stockées sur Amazon EBS à l'aide de clés gérées sur site, via SaaS ou via un logiciel exécuté sur EC2.

http://www.trendmicro.com/us/enterprise/cloud-solutions/secure-cloud/index.html


http://www.safenet-inc.com/public-cloud-security/protectv-data-protection-for-the-cloud/




sur 17

Figure 3 : Chiffrement dans Amazon EBS à l'aide de SafeNet ProtectV ou de Trend Micro SecureCloud

AWS Storage Gateway

AWS Storage Gateway est un service connectant une appliance logicielle sur site à Amazon S3. Il peut être exposé à votre réseau comme un disque iSCSI pour faciliter la copie de données depuis d'autres sources. Les données sur les volumes de disque liés à AWS Storage Gateway seront automatiquement téléchargées sur Amazon S3 en fonction de la politique appliquée. Vous pouvez chiffrer des données source sur les volumes de disque à l'aide de n'importe quelle méthode de chiffrement de fichier décrite précédemment (p. ex., Bouncy Castle ou OpenSSL) avant qu'elles n'atteignent le disque. Vous pouvez également utiliser un outil de chiffrement au niveau du bloc (p. ex., BitLocker ou dm-crypt/LUKS) dans le point de terminaison iSCSI exposé par AWS Storage Gateway pour chiffrer toutes les données sur le volume de disque. En outre, deux solutions partenaires AWS, Trend Micro SecureCloud et SafeNet StorageSecure, peuvent assurer le chiffrement et la gestion des clés pour le volume de disque iSCSI exposé par AWS Storage Gateway. Ces partenaires fournissent une solution facile à base de cases à cocher pour le chiffrement de données et la gestion des clés nécessaires, semblable par la conception au fonctionnement de leurs solutions de chiffrement Amazon EBS. Amazon RDS

Le chiffrement des données dans Amazon RDS (Amazon Relational Database Service) à l'aide de la technologie côté client exige que vous réfléchissiez à la manière dont vous voulez que les requêtes de données fonctionnent. Étant donné qu'Amazon RDS n'expose pas le disque lié qu'il utilise pour le stockage des données, le chiffrement transparent du disque à l'aide de techniques décrites dans la section précédente sur Amazon EBS ne vous est pas disponible. Toutefois, un chiffrement sélectif des champs de base de données dans votre application peut être réalisé à l'aide de l'une des bibliothèques de chiffrement standard mentionnées précédemment (p. ex., Bouncy Castle, OpenSSL) dans votre application avant que les données ne soient transférées à votre instance Amazon RDS. Alors que ces données de champ spécifiques ne prennent pas facilement en charge des requêtes de plage dans la base de données, les requêtes basées sur les champs qui ne sont pas chiffrés peuvent toujours renvoyer des résultats utiles. Les champs chiffrés des résultats





http://www.safenet-inc.com/WorkArea/DownloadAsset.aspx?id=8589948281

http://www.safenet-inc.com/WorkArea/DownloadAsset.aspx?id=8589948281


sur 17

renvoyés peuvent être déchiffrés par votre application locale pour une présentation. Pour prendre en charge des requêtes plus efficaces des données chiffrées, vous pouvez conserver un code HMAC d'un champ chiffré dans votre schéma, et fournir une clé pour la fonction de hachage. Les requêtes suivantes des champs protégés qui contiennent le code HMAC des données recherchées ne divulgueront pas les valeurs en texte brut dans la requête. Cela permet à la base de données d'effectuer une requête sur base des données chiffrées dans votre base de données sans divulguer les valeurs en texte brut dans la requête. Toute méthode de chiffrement que vous choisissez doit être réalisée sur votre propre instance d'application avant que les données ne soient envoyées à l'instance d'Amazon RDS.

CipherCloud et Voltage Secure sont deux partenaires d'AWS proposant des solutions qui simplifient la protection de la confidentialité des données dans Amazon RDS. Les deux fournisseurs peuvent chiffrer les données à l'aide du chiffrement qui conserve le format (FPE) et permet d'insérer du texte chiffré dans la base de données sans interrompre le schéma. Ils prennent également en charge des options de tokenisation avec des tables de recherche intégrées. Dans tous les cas, vos données sont chiffrées ou tokenisées dans votre application avant d'être inscrites dans l'instance Amazon RDS. Ces partenaires proposent des options pour l'indexation et la recherche dans les bases de données avec des champs chiffrés ou tokenisés. Les données non chiffrées ou non tokenisées peuvent être lues depuis la base de données par d'autres applications sans devoir distribuer de clés ou de tables de mapping à ces applications pour déverrouiller les champs chiffrés ou tokenisés. Par exemple, vous pouvez déplacer des données d'Amazon RDS vers la solution d'entreposage des données Amazon Redshift et exécuter des requêtes sur des champs non sensibles, tout en conservant les champs sensibles chiffrés ou tokenisés. La figure 4 montre comment la solution Voltage peut être utilisée avec Amazon EC2 pour chiffrer des données avant qu'elles ne soient écrites sur l'instance Amazon RDS. Les clés de chiffrement sont extraites de la KMI Voltage située dans votre centre de données par le client Voltage est exécuté sur vos applications sur Amazon EC2.

Figure 4 : Chiffrement de données dans vos applications Amazon EC2 avant leur écriture sur Amazon RDS à l'aide de Voltage SecureData

http://www.ciphercloud.com/


http://www.voltage.com/products/securedata-enterprise/



sur 17

CipherCloud for Amazon Web Services est une solution qui fonctionne de manière semblable au client Voltage pour des applications exécutées sur Amazon EC2 qui doivent envoyer des données chiffrées vers et depuis Amazon RDS. CipherCloud fournit un pilote JDBC qui peut être installé sur l'application, qu'il soit exécuté sur EC2 ou dans votre centre de données. En outre, la solution CipherCloud for Any App peut être déployée comme une passerelle en ligne pour intercepter des données lorsqu'elles sont envoyées vers et depuis votre instance Amazon RDS. La figure 5 montre comment la solution CipherCloud peut être déployée de cette manière pour chiffrer ou tokeniser les données provenant de votre centre de données avant qu'elles ne soient écrites sur l'instance Amazon RDS.

Figure 5 : chiffrement des données dans votre centre de données avant leur écriture sur Amazon RDS à l'aide du chiffrement

CipherCloud Gateway

Amazon EMR

Amazon EMR (Amazon Elastic MapReduce) propose une mise en œuvre facile à utiliser de Hadoop sur Amazon EC2. La réalisation du chiffrement pendant l'opération MapReduce implique le chiffrement et la gestion des clés à quatre points distincts :

1. La source de données ;

2. Le système de fichiers distribué Hadoop (HDFS) ;

3. La phase de remaniement ;

4. Les données de sortie.

Si les données source ne sont pas chiffrées, cette étape peut être ignorée et SSL peut être utilisé pour protéger les données qui transitent vers le cluster Amazon EMR. Si les données source sont chiffrées, votre tâche MapReduce devra pouvoir déchiffrer les données lorsqu'elles sont assimilées. Si votre flux de travail utilise Java et si les données source se trouvent sur Amazon S3, vous pouvez utiliser l'une des méthodes de déchiffrement du client décrites dans les sections précédentes sur Amazon S3.

http://www.ciphercloud.com/aws-encryption-ciphercloud.aspx

http://www.ciphercloud.com/aws-encryption-ciphercloud.aspx

http://www.ciphercloud.com/ciphercloud-connect-anyapp.aspx

http://www.ciphercloud.com/ciphercloud-connect-anyapp.aspx


sur 17

Le stockage utilisé pour le point de montage HDFS est le stockage éphémère des nœuds de cluster. En fonction du type d'instance, il peut y avoir plusieurs montages. Le chiffrement de ces points de montage implique l'utilisation d'un script d'amorçage Amazon EMR qui :

• arrête le service Hadoop ;

• installe un outil de chiffrement du système de fichiers sur l'instance ;

• crée un répertoire chiffré pour monter le système de fichiers chiffré par dessus les points de montage existants ;

redémarre le service Hadoop.

Vous pouvez, par exemple, effectuer ces étapes à l'aide du package eCryptfs à code source libre et d’une clé éphémère générée dans votre code sur chacun des montages HDFS. Vous ne devez pas vous inquiéter du stockage permanent de cette clé de chiffrement car les données qu'elle chiffre ne subsistent pas après la durée de vie de l'instance HDFS.

La phase de remaniement implique le transfert de données entre les nœuds de cluster avant l'étape de réduction. Pour chiffrer ces données en transit, vous pouvez activer SSL avec une option de configuration d'amorçage Hadoop lorsque vous créez votre cluster.

Enfin, pour permettre le chiffrement des données de sortie, votre tâche MapReduce doit chiffrer la sortie à l'aide d'une clé provenant de votre KMI. Ces données peuvent être envoyées vers Amazon S3 pour être stockées sous forme chiffrée.

Le partenaire AWS Gazzang simplifie la gestion du chiffrement et la KMI pour fournir un chiffrement de bout en bout de données via une tâche Amazon EMR. Leur Gazzang™ CloudEncrypt solution vous permet de charger des données dans Amazon S3 à l'aide de leur chiffrement côté client est intégré, puis ajouter un script d'amorçage à votre cluster Amazon EMR. CloudEncrypt permettra de chiffrer des données utilisées par tous les points de montage HDFS, et de gérer la gestion des clés tant pour les données d'entrée récupérées d’Amazon S3 que pour les données de sortie écrites sur Amazon S3. La figure 6 montre comment la solution Gazzang peut être utilisée pour effectuer le chiffrement de bout en bout des données utilisées dans Amazon EMR.

http://www.gazzang.com/products/cloudencrypt



sur 17

Figure 6 : chiffrement de bout en bout des données dans Amazon EMR à l'aide de Gazzang CloudEncrypt™

Modèle B : Vous contrôlez la méthode de chiffrement, AWS fournit le composant de stockage pour la KMI pendant que vous vous chargez de la couche de gestion de la KMI Ce modèle est semblable au Modèle A en ce que vous gérez la méthode de chiffrement, mais diffère par ce que les clés sont stockées dans une https://aws.amazon.com/cloudhsm/ appliance AWS CloudHSM et pas dans un système de stockage de clé que vous gérez sur site. Tandis que les clés sont stockées dans l'environnement AWS, elles ne sont pas accessibles pour les employés d'AWS. Cela est dû au fait que vous seul avez accès aux partitions cryptographiques dans le HSM dédié pour utiliser les clés. L'appliance AWS CloudHSM possède des mécanismes physiques et logiques de réponse et de détection d'effraction qui déclenchent une remise à zéro de l'appliance. La remise à zéro efface la mémoire volatile du HSM dans laquelle les clés en cours de déchiffrement sont stockées et détruit la clé qui chiffre les objets stockés, ce qui a pour conséquence de rendre toutes les clés du HSM inaccessibles et irrécupérables. Lorsque vous déterminez si l'utilisation d'AWS CloudHSM convient à votre déploiement, il est important de comprendre le rôle joué par un HSM dans le chiffrement de données. Un HSM peut être utilisé pour générer et stocker des clés et effectuer des opérations de chiffrement et de déchiffrement, mais il n'exécute aucune fonction de gestion du cycle de vie de clé (p. ex., politique de contrôle d'accès, rotation des clés). Cela signifie qu'une KMI compatible peut être nécessaire en plus de l'appliance AWS CloudHSM avant le déploiement de votre application. La KMI fournie peut être déployée sur site ou sur Amazon EC2 et communiquer de manière sécurisée avec l'instance AWS CloudHSM via SSL pour protéger les données et les clés de chiffrement. Le service AWS CloudHSM utilisant des appliances SafeNet Luna, tout serveur de gestion de clés qui prend en charge la plateforme SafeNet Luna peut également être utilisé avec AWS CloudHSM. Toutes les options de chiffrement décrites pour les services AWS dans le Modèle A peuvent fonctionner avec AWS CloudHSM tant que la solution prend en charge la plateforme SafeNet Luna. Cela vous permet d'exécuter votre

https://aws.amazon.com/cloudhsm/



sur 17

KMI dans l'environnement de calcul AWS en conservant une racine fiable dans une appliance matérielle à laquelle vous êtes le seul à pouvoir accéder.

Les applications doivent pouvoir accéder à votre appliance AWS CloudHSM dans un Amazon Virtual Private Cloud (Amazon VPC). Le client AWS CloudHSM, fourni par SafeNet, interagit avec l'appliance AWS CloudHSM pour chiffrer les données de votre application. Ensuite, les données chiffrées peuvent être envoyées à un service AWS à des fins de stockage. Les applications de base de données, de volume de disque et de chiffrement de fichier peuvent toutes être prises en charge par AWS CloudHSM et votre application personnalisée. La figure 7 montre comment la solution AWS CloudHSM fonctionne avec vos applications dans un VPC Amazon, l'instance Amazon EC2.

Figure 7 : AWS CloudHSM déployé sur Amazon VPC

Afin d’obtenir une disponibilité et une durabilité maximales des clés dans votre appliance AWS CloudHSM, nous recommandons le déploiement de plusieurs applications AWS CloudHSM sur des zones de disponibilité ou avec une applicance SafeNet Luna sur site que vous gérez. La solution SafeNet Luna prend en charge la réplication sécurisée des clés sur les appliances. Pour plus d'informations, consultez AWS CloudHSM sur le site web AWS.

Modèle C : AWS contrôle la méthode de chiffrement et l'ensemble de la KMI Dans ce modèle, AWS propose un chiffrement côté serveur de vos données, en gérant en toute transparence la méthode de chiffrement et les clés. Le chiffrement de l'enveloppe est utilisé dans AWS pour le chiffrement côté serveur. La figure 8 décrit le chiffrement d'enveloppe.




sur 17

1. Une clé de données est générée par le service AWS au moment où vous demandez le chiffrement de vos données.

2. La clé de données est utilisée pour chiffrer vos données.

3. La clé de données est ensuite chiffrée avec une clé de chiffrement de clé unique pour le service qui stocke vos données.

4. La clé des données chiffrées et les données chiffrées sont ensuite stockées par le service de stockage AWS en votre nom.

Figure 8 : Chiffrement d'enveloppe

Les clés de chiffrement de clé utilisées pour chiffrer les clés de données sont stockées et gérées séparément des données et des clés de données. Des contrôles d'accès stricts sont placés sur les clés de chiffrement conçues pour empêcher une utilisation non autorisée par les employés d'AWS. Lorsque vous devez accéder à vos données en texte brut, ce processus est inversé. La clé des données chiffrées est déchiffrée à l'aide de la clé de chiffrement de clé. Ensuite, la clé de données est utilisée pour déchiffrer vos données.

Les services AWS suivants proposent le chiffrement côté serveur :

Amazon S3

Vous pouvez définir un indicateur d'API ou activer la case à cocher dans AWS Management Console, pour que les données soient chiffrées avant leur écriture sur le disque dans Amazon S3. Chaque objet est chiffré à l'aide d'une clé unique. Comme protection supplémentaire, cette clé est chiffrée avec une clé principale à rotation périodique unique pour Amazon S3 qui est stockée dans des systèmes distincts sous contrôle d'AWS. Le chiffrement côté serveur Amazon


sur 17

S3 utilise des clés AES (Advanced Encryption Standard) à 256 bits pour les clés d'objet et principales. Cette fonction n'entraîne pas de supplément au tarif que vous payez pour utiliser Amazon S3.

Amazon Glacier

Les données sont toujours automatiquement chiffrées avant leur écriture sur le disque à l'aide de clés AES à 256 bits uniques pour le service Amazon Glacier stockées dans des systèmes distincts sous contrôle d'AWS. Cette fonction n'entraîne pas de supplément au tarif que vous payez pour Amazon Glacier.

AWS Storage Gateway

AWS Storage Gateway transfère de manière sécurisée vos données vers AWS via SSL et stocke vos données chiffrées au repos dans Amazon S3 ou Amazon Glacier à l'aide de leur propre schéma de chiffrement côté serveur.

Amazon EMR

S3DistCp est une fonction d'Amazon EMR qui déplace de grandes quantités de données d'Amazon S3 vers HDFS, de HDFS vers Amazon S3 et entre des compartiments Amazon S3. S3DistCp prend offre la possibilité de demander à Amazon S3 d'utiliser un chiffrement côté serveur lorsqu'il écrit des données EMR dans un compartiment Amazon S3 que vous gérez. Cette fonction n'entraîne pas de supplément au tarif que vous payez pour Amazon S3 pour stocker vos données Amazon EMR.

Oracle sur Amazon RDS

Vous pouvez choisir d'établir une licence pour l'option Oracle Advanced Security pour Oracle sur Amazon RDS afin de bénéficier des fonctionnalités natives TDE (Transparent Data Encryption) et NNE (Native Network Encryption). Le module de chiffrement Oracle crée des clés de chiffrement de données ou de clé pour chiffrer la base de données. Les clés de chiffrement de clé spécifiques à votre instance Oracle sur Amazon RDS sont chiffrées par une clé principale AES à 256 bits à rotation périodique. Cette clé principale est unique pour le service Amazon RDS et est stockée dans des systèmes distincts sous contrôle d'AWS.

Microsoft SQL Server sur Amazon RDS

Vous pouvez choisir de prévoir un chiffrement TDE (Transparent Data Encryption) pour Microsoft SQL Server sur Amazon RDS. Le module de chiffrement SQL Server crée des clés de chiffrement de données ou de clé pour chiffrer la base de données. Les clés de chiffrement de clé spécifiques à votre instance SQL Server sur Amazon RDS sont chiffrées par une clé principale régionale AES à 256 bits à rotation périodique. Cette clé principale est unique pour le service Amazon RDS et est stockée dans des systèmes distincts sous contrôle d'AWS. . Cette fonction n'entraîne pas de supplément au tarif que vous payez pour utiliser Microsoft SQL Server sur Amazon RDS.


sur 17

Amazon Redshift

Lorsque vous créez un cluster Amazon Redshift, vous pouvez choisir de chiffrer toutes les données dans des tables créées par l'utilisateur. Il existe deux options pour le chiffrement côté serveur d'un cluster Amazon Redshift.

1. Dans la première option, des blocs de données (et sauvegardes) sont chiffrés à l'aide de clés AES 256 à bits aléatoires. Ces clés sont elles-mêmes chiffrées à l'aide d'une clé de base de données AES à 256 bits aléatoire. Cette clé de base de données est chiffrée par une clé principale de cluster AES à 256 bits unique pour votre cluster. La clé principale de cluster est chiffrée à l'aide d'une clé principale régionale à rotation périodique unique pour le service Amazon Redshift et stockée de manière sécurisée dans des systèmes distincts sous contrôle d'AWS. Cette fonction n'entraîne pas de supplément au tarif que vous payez pour utiliser Amazon Redshift.

2. Dans la deuxième option, la clé principale de cluster AES à 256 bits utilisée pour le chiffrement de vos clés de base de données est générée dans votre AWS CloudHSM ou à l'aide d'une appliance SafeNet Luna HSM sur site. Cette clé principale de cluster est ensuite chiffrée par une clé principale qui ne quitte jamais votre HSM. Au démarrage du cluster Amazon Redshift, la clé principale de cluster est déchiffrée dans votre HSM et utilisée pour déchiffrer la clé de base de données, qui est envoyée de manière sécurisée aux hôtes Amazon Redshift de sorte qu’elle ne se trouve dans la mémoire pendant la durée de vie du cluster. Si le cluster redémarre, la clé principale de cluster est à nouveau récupérée en toute sécurité depuis votre HSM, elle n'est jamais stockée sur le disque en texte brut. Cette option vous permet de mieux contrôler la hiérarchie et le cycle de vie des clés utilisées pour chiffrer vos données. Cette fonction n'entraîne pas de supplément au tarif que vous payez pour Amazon Redshift (et AWS CloudHSM si vous choisissez cette option pour le stockage de clés).

Outre le chiffrement de données générées dans votre cluster Amazon Redshift, vous pouvez également charger des données chiffrées sur Amazon Redshift depuis Amazon S3, qui ont déjà été chiffrées à l'aide d'Amazon S3 Encryption Client et des clés que vous fournissez. Amazon Redshift prend en charge le déchiffrement et le rechiffrement de données entre Amazon S3 et Amazon Redshift pour protéger le cycle de vie complet de vos données.

Ces fonctions de chiffrement côté serveur sur plusieurs services d'AWS vous permettent de chiffrer vos données facilement et simplement en définissant une configuration dans AWS Management Console, l'interface de ligne de commande ou une demande d'API pour le service AWS donné. L'utilisation autorisée des clés de chiffrement est gérée de manière automatique et sécurisée par AWS. Étant donné que l'accès non autorisé à ces clés pourrait entraîner la divulgation de vos données, nous avons créé des systèmes et des processus qui limitent le risque d'accès non autorisé.

Conclusion Nous avons présenté trois modèles différents pour la gestion des clés de chiffrement et l'endroit où elles sont utilisées. Si vous prenez en charge la méthode de chiffrement et la KMI, vous pouvez bénéficier d'un contrôle granulaire sur la manière dont vos applications chiffrent les données. Toutefois, ce contrôle granulaire a un coût, aussi bien au niveau de l'effort de déploiement que de l'incapacité à intégrer des services AWS aux méthodes de chiffrement de vos applications. Par ailleurs, AWS propose un chiffrement à base de case à cocher entièrement intégré pour de nombreux services qui stockent vos données.


sur 17

Le tableau 1 ci-dessous récapitule les options disponibles pour le chiffrement de données au repos sur AWS. Nous vous recommandons de déterminer le modèle de chiffrement et de gestion de clé le plus approprié pour vos classifications de données dans le cadre du service AWS que vous utilisez.

Méthode de chiffrement et KMI Modèle A Modèle B Modèle C

AWS Service Solutions côté client à

l'aide de clés gérées par le client

Solutions partenaires côté client avec KMI pour des clés gérées par le client

Solutions côté client pour des clés gérées par le client

dans AWS CloudHSM

Chiffrement côté serveur à l'aide de clés gérées par

AWS Amazon S3 Bouncy Castle, OpenSSL,

Amazon S3 Encryption Client dans le SDK AWS pour Java

SafeNet ProtectApp for Java

Application personnalisée Amazon VPC-EC2 intégrée au client AWS CloudHSM

Chiffrement côté client Amazon S3

Amazon Glacier N/A N/A Application personnalisée Amazon VPC-EC2 intégrée au client AWS CloudHSM

Toutes les données sont automatiquement chiffrées à l'aide du chiffrement côté serveur

AWS Storage Gateway Niveau bloc Linux : - Loop-AES, dm-crypt (avec ou sans LUKS) et le système de fichiers Linux TrueCrypt : - eCryptfs et EncFs Niveau bloc Windows : -TrueCrypt Système de fichiers Windows : - BitLocker

Trend Micro SecureCloud, SafeNet StorageSecure

N/A Chiffrement côté client Amazon S3

Amazon EBS Niveau bloc Linux : - Loop-AES, dmcrypt+LUKS et système de fichiers Linux TrueCrypt : - eCryptfs et EncFs Niveau Bloc Windows : Système de fichiers Windows : -TrueCrypt - BitLocker, EFS

Trend Micro SecureCloud, SafeNet ProtectV


N/A

Oracle sur Amazon RDS Bouncy Castle, OpenSSL CipherCloud Database Gateway et Voltage SecureData


Transparent Data Encryption (TDE) et Native Network Encryption (NNE) avec licence Oracle Advanced Security facultative TDE pour Microsoft SQL Server

Microsoft SQL Server sur Amazon RDS

Bouncy Castle, OpenSSL CipherCloud Database Gateway et Voltage SecureData


N/A


sur 17

Amazon Redshift N/A N/A Clusters chiffrés Amazon Redshift avec votre clé principale gérée dans AWS CloudHSM ou Safenet Luna HSM sur site

Clusters chiffrés Amazon Redshift avec clé principale AWSmanaged

Amazon EMR eCryptfs CloudEncrypt Gazzang Application personnalisée Amazon VPC-EC2 intégrée au client AWS CloudHSM

S3DistCp à l'aide du chiffrement côté serveur Amazon S3 pour protéger les données stockées de manière permanente

Tableau 1 : Récapitulatif des options de chiffrement de données au repos

Références et suggestions de lecture Ressources AWS

• Chiffrement de données côté client avec le kit AWS SDK pour Java et Amazon S3 :

http://aws.amazon.com/articles/2850096021478074

• AWS CloudHSM https://aws.amazon.com/cloudhsm/

• Amazon EMR S3DistCp pour le chiffrement de données dans Amazon S3 http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/UsingEMR_s3distcp.html

• Chiffrement TDE (Transparent Data Encryption) pour Oracle sur Amazon RDS http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.html#Appendix.Oracle.O ptions.AdvSecurity

• Chiffrement TDE (Transparent Data Encryption) pour Microsoft SQL Server sur Amazon RDS http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.Gener al.Options

• Chiffrement Amazon Redshift http://aws.amazon.com/redshift/faqs/#0210

• Blog sur la sécurité AWS http://blogs.aws.amazon.com/security

Ressources partenaires

• Bibliothèque cryptographique http://www.bouncycastle.org/ Java Bouncy http://www.bouncycastle.org/ Castle http://www.bouncycastle.org/

• Bibliothèque cryptographique OpenSSL http://www.openssl.org/

• CloudBerry Explorer PRO pour le chiffrement d'Amazon S3 http://www.cloudberrylab.com/amazon-s3-explorer-pro-cloudfront-IAM.aspx

http://aws.amazon.com/articles/2850096021478074


http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/UsingEMR_s3distcp.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.html#Appendix.Oracle.Options.AdvSecurity



http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.Options



http://aws.amazon.com/redshift/faqs/#0210

http://blogs.aws.amazon.com/security





















sur 17

• Produits de chiffrement SafeNet pour Amazon S3, Amazon EBS et AWS CloudHSM http://www.safenet-inc.com/

• Trend Micro SecureCloud http://www.trendmicro.com/us/enterprise/cloud-solutions/secure-cloud/index.html

• CipherCloud for AWS et CipherCloud for Any App http://www.ciphercloud.com/

• Voltage Security SecureData Enterprise http://www.voltage.com/products/securedata-enterprise/

• Gazzang CloudEncrypt http://www.gazzang.com/products/cloudencrypt

http://www.safenet-inc.com/













Sécurisation des données au repos avec le chiffrement...Le JCE sous-jacent dans votre application...

Documents

Transcript of Sécurisation des données au repos avec le chiffrement...Le JCE sous-jacent dans votre application...