Cadre générique pour l’uniformisation des algorithmes de localisation des données 

Télécharger le fichier pdf d’un mémoire de fin d’études

La localisation des données : une clause de QoS

La zone géographique de stockage des données, ou localisation des données, dans le Cloud est un critère de QoS. En effet, ce critère peut se retrouver au sein des SLA sous deux formes :
— La duplication des lieux de stockage, afin de réaliser une redondance des données, pour des raisons de sécurité et de tolérance aux fautes ou bien pour des raisons de performances avec de la géo-réplication.
— La précision d’une zone géographique pour le ou les lieux de stockage, afin de garantir leur présence et leur accès au sein d’une limite administrative. Et ce, principalement pour des raisons légales et de respect de la vie privée.
Les deux formes ne sont cependant pas exhaustives. En effet un utilisateur peut vouloir une duplication des lieux de stockage, mais tous limités à une certaine zone géographique, par exemple à l’intérieur d’un pays.
De plus, il faut noter que contrairement aux autres critères de QoS habituel-lement présents dans les SLA, la localisation des données n’est pas facilement vérifiable par un utilisateur, dans le contexte Cloud actuel. En effet, il est fa-cile de vérifier le pourcentage de disponibilité du service, le temps d’accès ou la fiabilité. Pour chacun de ces trois critères, la mesure est à la portée des utilisateurs. Il s’agit respectivement de littéralement compter la durée d’indis-ponibilité, le temps que met une requête à être exécutée et le nombre d’erreurs sur une période donnée. Ensuite l’utilisateur concerné n’a plus qu’à comparer ces mesures avec celles fournies dans le contrat. Pour la localisation des don-nées, il est impossible de « simplement » la mesurer et il faut mettre en place des mécanismes un peu plus complexes afin de s’en assurer.
Même si un utilisateur grand public, consommateur de logiciels en tant que service (SaaS ou Software-as-a-Service), ne voit pas toujours d’intérêt à pouvoir spécifier et connaître la localisation de ses données, différentes raisons peuvent pousser un utilisateur à limiter les zones géographiques dans lesquelles seront stockées ses données, et ainsi d’avoir besoin de s’assurer du respect de la clause de QoS correspondante. Ces raisons sont d’autant plus importantes si l’utilisateur est une entreprise ou une entité publique. D’une part ces rai-sons sont plutôt techniques, comme assurer la sécurité des données ainsi qu’un certain niveau de performance sur l’accès aux données. D’autre part, ce sont des raisons de respect de la législation et de la vie privée.

Sécurité et performances

Dupliquer les données ou préciser une zone géographique sur les lieux de stockage permet de garantir un certain niveau de sécurité et de performances pour l’utilisateur. Dans cette section, il sera montré comment le respect des clauses de QoS concernant la localisation des données permet d’assurer ce niveau.

Sécurité

En termes de sécurité, trois raisons ont été identifiées pour justifier le besoin de connaitre la localisation des données.
Protéger les données en cas d’accident
Les données étant stockées sur des supports physiques à l’intérieur de centres de données, elles ne sont pas à l’abri de catastrophes naturelles, telles que les tornades, tsunamis et éruptions volcaniques, ni d’accidents moins « ex-traordinaires » comme les incendies ou inondations. Ces accidents peuvent avoir pour conséquence la perte des données.
En effet, les supports de stockages peuvent être directement endomma-gés par l’accident, comme en juin 2011 où une tornade a détruit l’hôpital
« St. John’s Regional Medical Center » dans le Missouri ainsi que le centre de données adjacent qui contenait des données médicales de patients, issues de l’hôpital [6].
Savoir où sont stockées les données permet donc d’estimer et limiter les risques de les perdre suite à un accident naturel, même si tout n’est pas pré-visible [7].
Empêcher l’accès aux données à une entité extérieure
Connaître et choisir le lieu de stockage de ses données permet de s’assurer qu’une entité extérieure à l’utilisateur et au fournisseur de service, par exemple un organisme gouvernemental du pays dans lequel se trouvent les données, n’accède ni n’intercepte les données. En effet, prenons l’exemple de données françaises qui se retrouvent stockées en Russie parce qu’un utilisateur a voulu externaliser le stockage de ses données. D’après le principe de souveraineté des données le gouvernement russe a potentiellement le droit d’accéder à ces données (figure 1.1) car elles sont soumises aux lois du territoire sur lesquelles elles sont stockées, dans ce cas la Russie.
Si les données stockées ne sont que des données personnelles d’utilisateurs grand public le problème peut être considéré comme négligeable, mais il est d’autant plus important quand les données le sont aussi. Il ne serait pas sou-haitable que des données sensible du gouvernement français ou de grandes industries soient accessibles à des gouvernements étrangers.
Il est possible d’observer ce genre d’accès par une entité extérieure. En effet, aux États-Unis, grâce aux révélations d’Edward Snowden sur la surveillance de la NSA, l’accès à des données internes à Google et Yahoo ! par l’agence de sécurité grâce au projet MUSCULAR a été exposé [8].

Respect de la législation

Cas des données de santés en France

D’après un rapport de Dell EMC, un acteur important dans les systèmes de stockage, et de l’International Data Corporation (IDC) [12], la quantité de données de santé en 2013 était de 153 exaoctets. Leurs prévisions s’accordent à dire qu’en 2020, la quantité de données de santé atteindra 2 314 exaoctets. Les données de santé représentent donc une quantité considérable de données à stocker, ce qui explique que les acteurs produisant ces données, comme les hôpitaux ou les centres de santé, sous-traitent le stockage.
Cependant, les données de santé peuvent contenir des informations confi-dentielles, telles que les dossiers médicaux des patients, avec l’ensemble des images médicales réalisées, les opérations subies, les traitements suivis et les pathologies ou affections dont souffre le patient. Il n’est donc pas souhaitable qu’elles soient stockées n’importe où, pour des raisons de sécurité et de vie privée, et que les acteurs produisant ces données aient le choix du lieu de stockage.
C’est pour cela qu’en France l’article L.1111-8 [13] du code de la santé pu-blique ainsi que le décret no 2018-137 du 26 février 2018 relatif à l’hébergement de données de santé à caractère personnel [14] définissent et encadrent l’hé-bergement des données de santé. Ce décret encadre le stockage des données de santé en demandant à ce qu’un centre de données soit certifié (anciennement agréé) « Hébergeur de Données de Santé » (HDS). Pour effectuer une demande d’agrément, les prérequis sont listés dans le référentiel HDS et plusieurs normes et exigences sont à respecter :
— ISO 27001 « système de gestion de la sécurité des systèmes d’informa-tion ».
— ISO 20000 « système de gestion de la qualité des services » (partielle-ment).
— ISO 27018 « protection des données à caractère personnel » (partielle-ment).
— Exigences complémentaires aux normes ISO 27001, ISO 20000.
— Exigences relatives à la protection des données de santé à caractère per-sonnel.
— Exigences spécifiques au domaine de la santé.
Les prérequis explicitent aussi que la localisation des données est une exi-gence à respecter. L’hébergeur doit lister l’ensemble des pays dans lequel les données peuvent être stockés, c’est-à-dire l’ensemble des pays pour lesquels un centre de données est certifié (ou agrée) HDS. De plus l’hébergeur doit per-mettre à l’utilisateur de choisir le ou les lieux de stockage de ses données, tout en s’assurant que le choix de l’utilisateur pour la localisation est bien respecté.
Le respect des normes et exigences, et donc le respect de celles qui concernent la localisation, est vérifié par un audit avant l’obtention de la certification, va-lable 3 ans. De plus un audit de contrôle annuel a aussi lieu.

Le RGPD au sein de l’Union Européenne

Le règlement no 2016/679 aussi connu comme le Règlement Général sur la Protection des Données (RGPD) [15] est un règlement issu de l’Union Euro-péenne (UE) et s’appliquant au sein des 28 États membres. Le RGPD remplace la directive 95/46/CE sur la protection des données personnelles pour les 28 États membres.
Ce règlement a pour but d’apporter un cadre harmonisé relatif à la pro-tection des données personnelles concernant les résidents de l’UE. Les données personnelles, sont définies d’après le RGPD comme celles permettant l’identi-fication d’une personne physique, c’est-à-dire une référence à :
— Un nom.
— Un numéro d’identification.
— Des données de localisation.
— Un identifiant en ligne.
De plus le RGPD applique aussi des dispositions particulières aux données sensibles d’une personne, telles que :
— La prétendue origine raciale ou ethnique.
— Les opinions politiques.
— Les convictions religieuses ou philosophiques.
— L’appartenance syndicale.
— Les données génétiques.
— Les données biométriques servant à l’identification unique.
— Les données de santé.
— la vie sexuelle ou l’orientation sexuelle.
Il s’applique lorsqu’une organisation, de n’importe quel type, traite des données personnelles concernant un résident de l’UE, et ce quelque même si l’organisation est hors de l’UE. Le RGPD a donc une application extraterrito-riale et il touche un grand nombre d’acteurs du fait de sa définition large des données personnelles et de son application à n’importe quel type d’acteur les traitant. Imposer des contraintes sur la position des données, comme imposer aux acteurs de stocker leurs données dans l’UE, n’est pas le but du RGPD. Si des contraintes fortes sur la localisation des données sont nécessaires c’est à la législation des États membres de le prendre en compte. Cependant, la locali-sation reste quand même importante, car les données personnelles stockées au sein de l’UE et celles stockées hors de l’UE sont soumises à des règles diffé-rentes. En effet, les données stockées au sein de l’UE sont considérées comme respectant par défaut le RGPD. Pour pouvoir les transférer en dehors de l’UE il faut qu’une des trois conditions suivante soit respectée :
— Le pays est reconnu par l’UE comme assurant un niveau de protection adéquat : Andorre, Argentine, Guernesey, Israël, Île de Man, Îles Féroé, Japon, Jersey, Nouvelle-Zélande, Suisse, Uruguay, Canada (organisations commerciales) et États-Unis d’Amérique (organisations appartenant au Privacy Shield).
— Des règles d’entreprise contraignantes (BCR) qui assurent un niveau de protection adéquat et qui sont juridiquement contraignantes internatio-nalement.
— Par exception grâce à une autorisation, sous conditions, de la Commis-sion Nationale de l’Informatique et des Libertés (CNIL) en France et organisme équivalent dans les autres pays de l’UE.
L’aide à la conformité et le contrôle du respect du RGPD en France est effectué par la CNIL qui agit principalement en fonction des plaintes reçues par les utilisateurs. Les organismes équivalent des autres États membres effectuent les même missions.

Ailleurs dans le monde

Le problème de la localisation des données est un problème qui concerne tous les pays, chacun essayant de protéger les données personnelles de ses citoyens. Il n’est donc pas étonnant de voir des législations similaires voire plus forte à celles applicables en France dans d’autres pays au sujet de la localisation des données.
On peut notamment citer les trois pays suivants, hors UE, qui se distinguent par leurs législations plus contraignantes qu’en France.
Australie
En Australie, les données de santé des citoyens ne peuvent être stockés ni traitées en dehors de l’Australie, d’après le My Health Records Act [16]. L’Toutefois, si les données ne contiennent pas d’information permettant l’iden-tification des personnes, elles peuvent être transférées, stockées et manipulées à l’extérieur du territoire australien.
Russie
En Russie, d’après la Loi Fédérale no 242 [17] sur les procédures de traite-ment des données personnelles, les données personnelles des citoyens Russes doivent être stockés et manipulées en Russie. Il n’y a aucune exception, les données personnelles ne peuvent pas, d’après la loi, quitter la Russie. De plus le lieu de stockage des données doit être précisé à l’utilisateur dont les données ont été recueillies.
Chine
En Chine, des contraintes de localisation existent sur plusieurs types de données :
— Données financières : d’après une annonce de la Banque Populaire de Chine [18], devant être suivie par les banques en Chine, la collecte, le traitement et le stockage des données financières personnelles doit se faire sur le territoire chinois. La définition des données financières personnelles étant très large, on peut considérer que l’ensemble des données financières doit être stocké en Chine.
— Données personnelles : en accord avec les lignes directrices du gouver-nement chinois [19], les données personnelles doivent être stockées en Chine, sauf consentement explicite de l’utilisateur.
— Données commerciales : conformément à la loi sur les secrets d’États [20], les données commerciales qui constituent des secrets d’État ne peuvent pas être transférées hors de Chine.

Utilisation de matériel sécurisé

Certaines méthodes utilisent du matériel sécurisé. Ce matériel repose le plus souvent sur un module de plateforme sécurisée (TPM ou Trusted Platform Mo-dule) qui permet de construire un environnement pour assurer la localisation.

Description d’un TPM

D’après les spécifications du Trusted Computing Group (TCG) [21], la description et le fonctionnement d’un TPM peut être expliqué de la manière suivante.
Qu’est-ce qu’un TPM ?
Un TPM est un composant matériel basé sur un processeur spécialisé, per-mettant la génération, le stockage et la manipulation de clés cryptographiques ainsi que la gestion de certificats. L’état du TPM doit être séparé du reste du système auquel il est connecté (système hôte), c’est-à-dire s’exécuter dans un environnement qui ne doit pas être accessible par le reste du système pendant l’exécution des routines du TPM.
La seule manière d’interagir entre le TPM et le système hôte est l’utilisation de l’interface définie par la spécification du TCG. Pour que ceci soit respecté il y a deux manières de mettre en place un TPM :
— Un système de type « System on a Chip » (SoC ou Système sur une puce) dans lequel tout le nécessaire pour le TPM repose dans un unique composant, c’est-à-dire que la RAM, la ROM, la mémoire Flash et le processeur nécessaire à l’exécution sécurisée des routines du TPM sont tous inclus dans la puce. Le composant échange avec le système hôte uniquement les commandes définies par l’interface et leurs résultats, et ce au travers d’un bus. La modification directe de l’état interne du TPM n’est donc pas possible.
— Une exécution en ressources partagées avec le système hôte. C’est-à-dire que le processeur et la mémoire du système hôte exécutent eux même les routines du TPM. Cependant, la mémoire dédiée au TPM n’est utilisable que quand le processeur se trouve dans un mode d’exécution particu-lier. Durant ce mode d’exécution, les zones mémoires réservées au TPM contiennent les points d’accès vers les routines et les zones inscriptibles du TPM. Grâce à cela, la modification directe de l’état interne du TPM n’est pas possible, elle ne peut se faire qu’au travers des commandes définies par la spécification.
Un TPM est composé de différents modules spécialisés, comme montré sur la figure 2.1.
En partant de ce composant comme fondation, il est donc possible de construire des applications de confiance.
Différences entre la norme TPM 1.2 et 2.0
Deux normes de TPM cohabitent, la norme 1.2 dont la dernière spécifi-cation date de mars 2011 [22] et la norme 2.0 dont la dernière spécification date de septembre 2016 [21]. Même si les deux normes répondent aux mêmes cas d’utilisation et ont des fonctionnalités similaires, des différences existent. Une partie de ces différences se trouve au niveau de l’implémentation maté-rielle des TPM et n’est donc pas visible par l’utilisateur. Les autres différences concernent :
— La possibilité d’utiliser de nouveaux algorithmes de chiffrement et de hashage. La version 1.2 était limitée à RSA et SHA1. La version 2.0 permet l’utilisation de nouveaux algorithmes asymétriques, notamment d’algorithmes de cryptographie sur les courbes elliptiques ainsi que d’al-gorithmes de chiffrements symétriques comme AES.
— L’unification et l’amélioration de méthodes d’autorisation. Elles étaient différentes selon les cas d’utilisation en version 1.2. La version 2.0 four-nit un cadre unifié. De plus, la version 2.0 permet d’utiliser des mots de passes et des Hash Message Authentication Code (HMAC) 1.2 comme nouvelles méthodes d’autorisation, en plus des politiques qui couvrent les méthodes proposées par la norme 1.2. Ces méthodes peuvent être combi-nées entre elles pour fournir une politique d’autorisation plus complexe.
— Support du TPM depuis le BIOS. En version 2.0, le support du TPM par le système d’exploitation n’est plus obligatoire pour être en mesure de l’utiliser.
— La mémoire RAM non volatile (NV-RAM) de la puce possède de nou-velles possibilités d’utilisation. En plus de stocker les clés et certificats, il est possible de s’en servir comme compteur ou tableaux de bits.
La version 2.0 permet donc d’être plus à jour en termes de sécurité, grâce
à des algorithmes de chiffrement et de hashage plus récents et sans failles connues à ce jour et de faciliter l’utilisation du TPM, tout en conservant des cas d’utilisations similaires.

Méthodes garantissant une localisation exacte

Par l’utilisation d’un TPM en association avec une autorité de cer-tification
Dans ce type de méthode [23], le principe est d’utiliser le TPM comme une « ancre de confiance pour valider la position géographique de machines virtuelles ». Une autorité tierce (TP ou Third Party), de confiance, est présente pour :
1. Certifier la bonne position géographique du TPM lors de la mise en place des machines physiques chez le fournisseur et vérifier par des audits réguliers que les TPM sont bien situés à l’endroit de départ et n’ont pas été déplacés.
2. Certifier la position géographique d’une machine virtuelle nouvellement crée.
3. Assister l’utilisateur durant la phase de vérification, en lui garantissant la validité des résultats retournés par le fournisseur.
L’architecture de la méthode est représentée sur la figure 2.2. La méthode est divisée en deux phases, durant ces phases toutes les communications entre utilisateur, TP et fournisseur sont considérées comme chiffrées. Les phases sont les suivantes :
— Une phase d’initialisation durant laquelle le fournisseur déclare à la TP la position géographique de la nouvelle machine virtuelle en accord avec le TPM. Pour cela des échanges sécurisés ont lieu, permettant à la TP d’attester de la validité de la configuration matérielle de la machine hôte et au fournisseur de déclarer la position géographique et les éléments nécessaires à la vérification de la validité de la configuration matérielle.
— Une phase de vérification durant laquelle l’utilisateur interagit avec le fournisseur et la TP, afin d’obtenir la position géographique de sa ma-chine virtuelle. Des échanges sécurisés entre ces trois entités ont lieu lorsque l’utilisateur génère une requête de localisation. D’abord, la TP identifie de qui provient la requête afin de retrouver les éléments néces-saires à la vérification. Une fois ces informations récupérées depuis le TPM chez le fournisseur, la TP atteste leur validité, et si tout est valide, la position enregistrée lors de l’initialisation est retournée à l’utilisateur. Ensuite, c’est à l’utilisateur de décider si la position géographique lui convient ou pas.

Méthodes garantissant le non-déplacement des données

Pour garantir le non-déplacement des données hors d’une ou plusieurs zones géographiques determinées [26], celles ci sont chiffrées et ne sont disponibles en clair que pour les centres de données situés dans les zones géographiques autorisées par l’utilisateur. Pour cela, chaque machine physique est équipée d’un TPM et d’un récepteur GPS, et un composant logiciel se charge d’enre-gistrer dans le TPM le lieu correspondant aux coordonnées géographiques de chaque machine, à intervalles réguliers. Ainsi, les informations de localisation sont stockées de manière fiable et sécurisée. Le TPM sert aussi, avec une TP, à attester de la validité logicielle des machines, c’est-à-dire si l’ensemble des lo-giciels présents sont considérés comme de confiance et ne vont pas contrecarrer le mécanisme de localisation.
La TP génère un couple de clé publique / clé privée et créé un hash pour chaque machine du fournisseur, en fonction de la position géographique ini-tiale et de la validité logicielle de la machine. L’architecture de la solution est résumée par la figure 2.4.

Politiques au sein de la pile logicielle du fournisseur

Méthodes estimant une localisation

Une façon d’estimer la localisation des données au niveau logiciel est d’en-capsuler les données dans des scripts [28]. Les données ne sont ainsi plus des éléments passifs du système, mais deviennent des éléments actifs et exécu-tables. Pour permet « l’exécution des données », un système de fichier spéci-fique est utilisé. L’accès aux données n’est donc possible qu’en communicant avec la couche extérieure, les scripts, et défini selon des politiques d’accès. Du point de vue de l’utilisateur, l’utilisation est transparente, l’encapsulation étant réalisée par le fournisseur. Les différents échanges entre l’utilisateur et les don-nées se font de manière sécurisée. Pour que cette méthode puisse fonctionner correctement, le fournisseur est considéré comme de confiance et n’altère ni l’éxecution des scripts ni le système en général. À l’initialisation, l’utilisateur et les données sont représentés par un ensemble de paramètres qui définira la manière dont ils communiqueront ensuite. L’architecture de cette méthode est représentée sur la figure 2.5.

Méthodes garantissant le non-déplacement des données

Le but de ses méthodes est d’assurer le non déplacement des données dans une zone géographique non autorisée par l’utilisateur. Elles nécessitent la mise en place de logiciels spécifiques chez le fournisseur. Elles fonctionnent grâce à des politiques sur les actions autorisées et non autorisées au niveau des données, par exemple le maintien dans une zone géographique spécifique]. Les politiques sont fournies par l’utilisateur et évaluées au sein de la pile logicielle du fournisseur. L’implémentation peut se faire au niveau du système de fichier [29] ou à plus haut niveau [30, 31].
Ces politiques sont évaluées avant de réaliser chaque opération sur les fi-chiers et l’opération n’est exécutée que si l’état du fichier après exécution de l’opération respecte les conditions définies par la politique. L’architecture de ces solutions est représentée sur la figure 2.6.
La méthode fonctionne en deux étapes :
— Une étape d’initialisation, durant laquelle l’utilisateur définit les poli-tiques qu’il souhaite associer à ses fichiers, et notamment la position géographique souhaité. Les politiques sont ainsi envoyées au fournisseur, selon une interface spécifique pour ne pas les confondre avec les données de l’utilisateur. La localisation des centres de stockage est donc connue par l’utilisateur, afin qu’il puisse choisir au moins un lieu où se trouve un centre de stockage dans ses politiques de localisation. L’utilisateur peut ensuite commencer à déposer ses fichiers.
— Une étape de vérification, s’exécute avant chaque opération sur les fi-chiers, quel que soit le type d’opération. Le déroulement de cette étape est le suivant :
1. Les politiques associées à l’utilisateur sont récupérées.
2. L’état du fichier après l’opération à réaliser (état final) est calculé, mais l’opération n’est pas réellement exécutée.
3. L’état du fichier après l’opération à réaliser est comparé aux poli-tiques.
4. Si l’état final respecte les politiques, l’opération peut être réalisée, sinon elle ne l’est pas.
Selon les méthodes, les journaux des opérations exécutées et non-exécutées sont conservés. Une TP peut aussi intervenir afin de réaliser des audits réguliers pour veiller au bon fonctionnement du système et au respect des politiques par le fournisseur.

Limites de ces méthodes

Ces méthodes fournissent la possibilité d’offrir à l’utilisateur une garantie sur la position de ses données, sous la condition qu’elles soient correctement implémentées. Cependant même dans ce cas elles présentent des limites, qui seront abordés dans la suite de cette section.

Coût élevé

La première limite de ces méthodes est le coût de mise en œuvre. En effet, dans le cas le moins couteux, mais aussi le moins fiable, il faut « imposer » au fournisseur d’utiliser un logiciel mettant en œuvre les mécanismes permet-tant l’assurance. En supposant le fournisseur de bonne foi, il doit accepter de déployer ce logiciel, ce qui peut être contraignant pour lui sur plusieurs niveaux :
— Au niveau de l’administration, car le logiciel doit être déployé et intégré au sein de la couche logicielle existante et maintenu au fil des évolutions.
— Au niveau des manipulations des données, car tout doit être tracé au niveau de la position physique.
— Au niveau de la performance car chaque opération étant tracée, il faut réussir à assurer la même QoS en utilisant plus de ressources.
Dans le cas le plus coûteux, le fournisseur doit installer du matériel sé-curisé sur l’ensemble de ses machines. En effet, même si les TPM sont des composants courant ils ne sont pas tous de la norme 2.0 qui permet d’avoir une sécuritée renforcée. Il faudrait donc installer des TPM issus de la norme 2.0 sur l’ensemble des machines. De plus il doit aussi collaborer avec une TP afin de prouver sa bonne foi.
Toutes ces contraintes sur le fournisseur se feront ressentir financièrement sur l’utilisateur. Selon le type d’utilisateur, ce n’est pas toujours acceptable.

Failles

La seconde limite de ces méthodes sont les failles qui peuvent exister à dif-férents niveaux. Il est à noter que ces failles peuvent être impossible à exploiter si un audit régulier par une TP est mis en place, à moins que le fournisseur soit malicieux et dispose de ressources quasi-infinies lui permettant de masquer les failles, c’est-à-dire déplacer les données dans à la bonne position géographique, modifier les journaux et avoir le matériel correctement configuré, avant chaque audit. Cette hypothèse peut donc être facilement exclue.
Failles au niveau logiciel
Toujours en considérant que le logiciel est correctement implémenté, s’il n’est pas utilisé en coopération avec un TPM et une TP, rien ne garantit à l’utilisateur que le logiciel qui est en train d’être exécuté chez le fournisseur est bien celui permettant d’assurer la localisation. En effet l’utilisateur n’a aucun accès physique aux hôtes et aucune autre autorité de confiance ne lui garantie la bonne exécution du logiciel de localisation. Cette absence du logicel de localisation peut être une erreur du fournisseur ou bien l’acte d’un fournisseur malveillant.
Failles au niveau GPS
Certaines méthodes utilisent des récepteurs GPS au sein des centres de données. Cependant cela pose deux problèmes majeurs :
— La localisation exacte d’un centre de données n’est pas toujours souhaible pour un fournisseur. En effet, les fournisseurs souhaitent généralement la garder secrète pour des raisons de sécurité, notamment afin d’éviter les actes de malveillance. Les fournisseurs peuvent ainsi se montrer réticent à l’utilisation d’un tel système fournissant une localisation aussi précise.
— Les signaux GPS authentiques, provenant des satellites, peuvent être usurpés par des faux signaux générés afin de faire croire à une autre position géographique [32]. Ce sont des mécanismes qui peuvent être mis en place par un fournisseur malveillant, afin de faire croire qu’une machine contenant des données devant se trouver au sein d’une zone géographique s’y trouvent encore alors qu’elles ont été déplacées.
Failles au niveau TPM
Les TPM, censés assurer la fiabilité du système grâce à leurs capacités cryptographiques, ne sont pas exempts de failles. Des attaques permettant de récupérer les secrets stockés au sein du module existent [33,34], mais leur mise en œuvre est difficile et coûteuse pour un fournisseur. Cependant une autre faille plus facile à exploiter est connue [35]. Il s’agit d’une faille de type ROCA (Return of Coppersmith’s attack) qui se situe au niveau du code permettant la génération des clés au sein du TPM. La clé privée
peut être déduite de la clé publique, permettant ainsi à l’attaquant d’utiliser les clés privées normalement non accessibles.
Un fournisseur malicieux pourrait exploiter ce type de failles afin de mas-quer la localisation réelle.

Fonctionnement général des méthodes

L’ensemble de ces méthodes fonctionne généralement de la même manière. L’idée principale est qu’en apprenant avec précision les performances du réseau autour de la zone présumée dans laquelle le fournisseur stocke ses données, dans un premier temps sans interagir avec le fournisseur, il est ensuite possible de retrouver plus précisément cette zone. En effet, les performances du réseau doivent être proches ou identiques à celles observées lors de l’apprentissage. La zone estimée sera potentiellement plus précise si elle est entourée de points de repères que si elle se trouve au sein d’une autre zone géographique, non couverte pas les points de repères. Il s’agit donc de considérer les deux étapes correspondantes aux méthodes, une étape d’apprentissage des performances du réseau à l’aide de métriques données et une étape de vérification utilisant les résultats de l’étape d’apprentissage afin d’inférer la position géographique du fournisseur. L’architecture et le fonctionnement général de ces méthodes est représentée sur la figure 3.1.

Classification des méthodes

Les différentes méthodes existantes différent selon de multiples critères de conception. Ces critères sont présentés dans la suite et résumés dans le ta-bleau 3.1. Ils peuvent être regroupés sous cinq catégories : Corrélation entre l’adresse du point d’accès et la position du serveur (Corrélation @PA/Pos.), points de repères, recueil de mesures, apprentissage automatique et utilisation de protocoles de PDP.

Corrélation entre l’adresse du point d’accès et la position du serveur

Les utilisateurs utilisent un point d’accès particulier pour manipuler leurs données stockées dans le Cloud. Ce point d’accès peut être sous la forme d’une adresse IP ou un nom de domaine et il est fourni à l’utilisateur lors de l’éta-blissement du contrat du service. Les méthodes présentées ont deux points de vue sur la corrélation @PA/Pos. :
— Existence d’une telle corrélation [38–40] : L’adresse du point d’accès uti-lisée par l’utilisateur est celle des serveurs stockant les données ou d’un proxy mais situé dans le même centre de données que les serveurs de sto-ckage. Ainsi, en termes de vérification de la localisation, sonder l’adresse du point d’accès revient à sonder les serveurs stockant les données.
— Non-existence d’une telle corrélation [41–45] : L’adresse du point d’accès fournie n’est pas celle des serveurs stockant les données mais d’un proxy qui peut être situé loin des données. Ainsi, en termes de vérification de la localisation, l’adresse du point d’accès n’est pas utile, car elle ne servira qu’à estimer la localisation du proxy et non des données.
Il est important de noter que les fournisseurs commerciaux, dont les infra-structures reposent essentiellement sur de la virtualisation, sont plus suscep-tibles de se situer dans la seconde situation, afin de rendre opaque l’architecture interne de leur infrastructure.

Points de repères

Cette catégorie peut être divisée en trois critères de conception :
Types de points de repères
Un point de repère peut être de deux types différents selon la manière dont il est employé au sein de l’ensemble du processus de vérification.
— Les points de repères actifs [38–44] sont a l’initiative des requêtes dans le but de collecter des mesures du réseau. Ils peuvent aussi mettre en place un processus d’apprentissage et déduire des distances à partir des RTTs. Ce sont des machines dont la puissance de calcul peut être directement utilisée.
— Les points de repères passifs [45] répondent uniquement aux requêtes qui leur sont adressées et servent à collecter les RTTs, mais leur puissance de calcul n’est pas directement exploitable.
Échelle de distribution des points de repère
L’échelle de distribution des points de repère fait référence à la zone dans laquelle sont situés les points de repère. Une telle zone peut être :
— La planète entière pour une échelle mondiale comme utilisés par [39, 40, 45].
— Un ou plusieurs continents ou un très grand pays pour une échelle conti-nentale. Par exemple [38, 41–43] positionnent les points de repère aux États-Unis et [44] positionne les points de repère aux États-Unis et en Europe.
— Un petit pays ou une partie d’un pays, comme un état, une région ou un conté, pour une échelle locale.
Sélection de points de repère
Un ensemble de points de repère est défini à la mise en place de la solution et le rôle individuel des points de repère est de contribuer à déterminer la zone géographique dans laquelle se situe le fournisseur. Néanmoins, tous les points de repère de l’ensemble initial ne peuvent pas contribuer de la même manière et apporter plus de précision. Par exemple, un point de repère trop loin de tous les autres ou du fournisseur va au mieux n’avoir aucun intérêt dans l’estimation de la localisation et au pire impacter négativement la zone géographique déter-minée. La sélection des points de repère cherche donc à trouver un compromis entre la couverture géographique et la précision de l’estimation. En effet, un nombre important de points de repère et répartis mondialement permet de localiser à la même échelle, mais si tous les points de repères participent à la vérification, l’estimation risque de ne pas être précise. Sans prendre en compte les cas où des points de repère sont écartés pour des raisons techniques, il est possible de distinguer deux paradigmes de sélection :
— Pré-apprentissage [45], pour sélectionner les points de repère les plus proches de la localisation présentie, afin de minimiser les coûts, et de ne pas utiliser des points de repère qui n’apporteront rien ou très peu au modèle d’estimation. Cette sélection se justifie par le nombre élevé de points de repère dans l’ensemble initial.
— Pré-vérification [40, 41], aussi pour sélectionner les points de repère les plus proches de la localisation présentie. Cette sélection est utile lorsque le nombre de points de repère est limité dans l’ensemble initial. Leur nombre n’est donc pas un problème pour l’apprentissage, mais la sélec-tion pré-vérification est utile pour améliorer la précision de la vérification en excluant les points de repère les plus lointains, qui n’auront pas d’in-fluence positive sur le résultat.
Le reste des solutions [38,39,42–44] ne sélectionnent pas les points de repère au sein de l’ensemble initialement choisi, à part, des points de repère qui ne fonctionnent pas correctement. Cette sélection n’est pas comptabilisée, car elle ne fait pas partie de « l’esprit » de la solution mise en œuvre.

Table des matières

I Revue de l’état de l’art 
1 Position des données stockées dans le Cloud 
1.1 Introduction
1.2 Gestion de la QoS dans le Cloud
1.2.1 Contrats de SLA
1.2.2 La localisation des données : une clause de QoS
1.3 Sécurité et performances
1.3.1 Sécurité
1.3.2 Performances pour l’accès utilisateur
1.4 Respect de la législation
1.4.1 Cas des données de santés en France
1.4.2 Le RGPD au sein de l’Union Européenne
1.4.3 Ailleurs dans le monde
2 Garanties de localisation des données dans le Cloud par un tiers de confiance 
2.1 Introduction
2.2 Utilisation de matériel sécurisé
2.2.1 Description d’un TPM
2.2.2 Méthodes garantissant une localisation exacte
2.2.3 Méthodes garantissant le non-déplacement des données
2.3 Politiques au sein de la pile logicielle du fournisseur
2.3.1 Méthodes estimant une localisation
2.3.2 Méthodes garantissant le non-déplacement des données
2.4 Limites de ces méthodes
2.4.1 Coût élevé
2.4.2 Failles
3 Estimation de la localisation dans le Cloud à l’aide de points de repère 
3.1 Introduction
3.2 Fonctionnement général des méthodes
3.2.1 Étape d’apprentissage
3.2.2 Étape de vérification
3.3 Classification des méthodes
3.3.1 Corrélation entre l’adresse du point d’accès et la position du serveur
3.3.2 Points de repères
3.3.3 Collecte de mesures
3.3.4 Apprentissage automatique
3.3.5 Utilisation de protocoles de PDP
3.4 Synthèse des résultats expérimentaux
3.4.1 Contexte expérimental
3.4.2 Résultats
3.5 Limites et problèmes de ces méthodes
3.5.1 Aucune garantie sur la position des données
3.5.2 Compromission du processus de vérification
3.5.3 Absence de cadre unifié
II Contributions 
4 Cadre générique pour l’uniformisation des algorithmes de localisation des données 
4.1 Introduction
4.2 Définitions initiales
4.3 Apprentissage
4.3.1 Mesures entre points de repère
4.3.2 Sélection des points de repère et nettoyage de MT
4.3.3 Calcul des paramètres de la fonction d’estimation
4.4 Vérification
4.4.1 Mesures entre points de repère et fournisseur
4.4.2 Sélection des points de repère et nettoyage de MV
4.4.3 Estimation de la localisation
4.5 Évaluation
4.5.1 Score de succès de la localisation
4.5.2 Score du ratio du consensus
4.6 Cas des autres méthodes
4.6.1 Points de repères passifs
4.6.2 Méthodes reposant sur la classification
5 Collecte des données : plateforme et pré-traitements 
5.1 Introduction
5.2 Collecte au niveau national
5.2.1 Choix et répartition des points de repère
5.2.2 Métriques considérées
5.2.3 Fonctionnement de la collecte
5.3 Jeu de données national
5.3.1 Présentation du jeu de données initial
5.3.2 Nettoyage du jeu de données
5.4 Collecte au niveau mondial
5.4.1 Choix et répartition des points de repère
5.4.2 Métriques collectées
5.4.3 Fonctionnement de la collecte
5.5 Jeu de données mondial
5.5.1 Présentation du jeu de données initial
5.5.2 Nettoyage du jeu de données
6 Analyse des performances des algorithmes 
6.1 Introduction
6.2 Conditions d’évaluation au niveau national
6.2.1 Choix du consensus
6.2.2 Sélection du degré de régression polynomiale
6.2.3 Scénarios de division des mesures
6.3 Présentation des résultats au niveau national
6.3.1 Fonctions d’estimation
6.3.2 LSS
6.3.3 CRS
6.4 Conditions d’évaluation au niveau mondial
6.4.1 Division apprentissage/vérification et degré de régression polynomiale
6.4.2 Choix du consensus
6.4.3 Estimation des intersections par une méthode de type Monte-Carlo
6.5 Présentation des résultats au niveau mondial
6.5.1 Fonctions d’estimation
6.5.2 LSS
6.5.3 CRS
6.6 Aspect méthodologique pour l’utilisation des techniques
6.6.2 Effet du nombre de points de repère
6.6.3 Granularité de la cible
6.6.4 Quelle technique adopter ?
Conclusion 
1 Résumé des contributions
2 Perspectives
Publications 
Bibliographie 

Télécharger le rapport complet