Cloud public et protection des données

Published by Anne ANDRIANARIMANANA on

Cloud public et protection des données

Depuis une décennie, on constate une augmentation drastique de la valorisation des données : nous avons accès à de la donnée en quantité et de qualité croissante, et surtout avec une puissance de calcul toujours plus accessible.

Outre les développements technologiques sur les puces toujours plus denses – cf la célèbre Loi de Moore, la transition vers les GPU et le développement des supercalculateurs – ce sont surtout le développement du calcul distribué et du cloud public qui permettent de réellement démocratiser la puissance de calcul. Une bonne illustration est celle du « CloudSort Benchmark », compétition dont le but est de trier – une des opérations les plus lourdes sur des données – 100To de données, dans un environnement de cloud public, pour le coût le plus faible possible :

Source : DataBricks

Hormis ce coût extrêmement faible ($1.44 par To) pour des vitesses de traitement très élevées (1.39To / minute), la flexibilité du cloud public, sa scalabilité (394 machines tournant en parallèle pour ce record), et les services managés innovants proposés sur ces plateformes nous amènent au constat suivant : l’avenir de l’exploitation des données, qu’il s’agisse de données massives, d’intelligence artificielle ou d’open data passera forcément en très grande partie par le cloud public.

Cela étant dit, l’augmentation des possibilités technologiques ne doit pas aller de pair avec une diminution des responsabilités – bien au contraire. 

Le modèle de responsabilité partagée

Dans le contexte du cloud public, le modèle en vigueur est celui de la responsabilité partagée. 

Le schéma suivant reprend le modèle proposé par Amazon Web Services :

En résumé, AWS est responsable de la sécurité du cloud (équipements physiques, périmètre du datacenter, sécurité des couches basses) tandis que le client est responsable de la sécurité dans le cloud. Autrement  dit, si un datacenter brûle, Amazon est responsable. Si vous mettez des données personnelles dans le cloud et qu’elles sont volées, vous êtes responsable.

La sécurité du cloud

Pour faire face à cette responsabilité, les fournisseurs de cloud public prennent des mesures : contrôles d’accès physiques, emplacements exacts des datacenters tenus secret, chiffrement des données au repos, patching de sécurité des équipements réseaux, etc… 

En outre, ils se soumettent à un grand nombre de normes, certifications et standards – dont leurs clients peuvent bénéficier par rebond : ISOx, SOC, PCI-DSS, RGPD, etc… Vous pouvez trouver un exemple ici sur le site d’Alibaba Cloud : https://www.alibabacloud.com/trust-center

La sécurité des données

Le sujet de la sécurité dans le cloud étant bien trop large pour être couvert dans un article, nous nous concentrerons sur la protection des données, objet de cet article. C’est là que le concept de data responsabilité est très largement en jeu : il ne s’agit pas de « protéger toutes ses données en gardant tout chez soi » ni de « prendre un risque en mettant toutes ses données dans le cloud public », mais bien de classifier ses données par sensibilité / criticité et de différencier les traitements en fonction de cette classification.

Chez EVA Group, une partie de notre travail d’accompagnement est de construire avec nos clients un arbre de décision pour identifier les points suivants :

  • Quelles catégories de données sont parfaitement compatibles avec du cloud public ?
  • Quelles sont celles qui peuvent l’être si les mesures de sécurité et certifications mises en place sont d’un niveau satisfaisant ?
  • Quelles sont celles qui sont vouées à rester sur des infrastructures hébergées en interne ?

La difficulté derrière cette approche est double : savoir classifier ses données, et savoir évaluer les mesures de sécurité à disposition. C’est justement sur ces questions que BSSI, notre pôle Cybersécurité, accompagne ses clients.

La sécurité dans le cloud

La sécurité des données dans le cloud public couvre un éventail très large de mesures, et nous insisterons ici sur deux d’entre elles, les deux principales, sans lesquelles les autres n’ont aucune valeur : le chiffrement des données – au repos et en transit – et la gestion des identités & accès.

Un bon document avec lequel nous travaillons et que nous conseillons est le Cloud Controls Matrix, édité par la Cloud Security Alliance : https://cloudsecurityalliance.org/working-groups/cloud-controls-matrix/

Ce document regroupe les mesures de sécurité par famille (sécurité des données), sous-familles (flux de données, classification, etc…) et liste les questions à se poser pour chaque catégorie, ainsi que la correspondance avec les standards et certifications principales du marché.

Pour revenir au chiffrement et la gestion des identités & accès (IAM), ces mesures sont généralement disponibles nativement, voire mises en place par défaut par les fournisseurs. Vous retrouverez à cette adresse un cas d’usage de protection de données confidentielles (fusion & acquisition) hébergées dans Azure, et utilisant uniquement des services natifs à Azure : https://customers.microsoft.com/fr-fr/story/merrill-corporation.

L’architecture est ici très simple : des documents sont stockés et chiffrés sur Azure.

Azure Active Directory reconnaît les utilisateurs et contrôle que seul le service de stockage a le droit de demander la clé de chiffrement au service de gestion de clés. Ainsi, seul un utilisateur connu et autorisé qui demanderait un document déchiffré au service de stockage peut accéder à ce document déchiffré. On a donc ici un schéma très simple de protection de données dans le cloud public.

Une question qui revient régulièrement à ce stade est : cela me protège-t-il contre mon fournisseur de cloud public qui voudrait accéder à mes données ? Cette question pose particulièrement problème lorsque l’on parle d’acteurs américains (Azure, AWS, GCP) ou chinois (Alibaba Cloud), et non européen (OVH). En fait, il existe deux moyens assez simples de s’en prémunir :

  • Si vous disposez de données à protéger absolument de votre fournisseur américain ou chinois, ne la mettez simplement pas chez ce fournisseur. C’est là que la classification des données présentée plus haut prend davantage de valeur : elle vous permet d’identifier le strict minimum de données à ne pas mettre dans le cloud public – contrairement à l’approche « zéro cloud public ».
  • Pour les données que vous hébergez dans le cloud public, vous pouvez également décider de vous passer des solutions natives de chiffrement et d’IAM car dit native dit fournie par le fournisseur lui-même. On rentre alors dans les concepts de : 
    • Bring Your Own Identity (BYOI) avec par exemple un Active Directory managé par vous et pas par Azure.
    • Bring Your Own Key (BYOK) avec un Unbound Key Control par exemple
    • Bring Your Own Encryption (BYOE) avec un Thalès eSecurity par exemple
    • Ainsi, même si votre fournisseur accédait à vos données – suite à une demande du gouvernement américain via le PatriotAct + CloudAct par exemple – il récupèrerait des données chiffrées, et vous êtes certains qu’il ne détiendrait pas la clé de chiffrement, stockée chez vous.

Cloud public et protection des données : une question d’équilibre

En conclusion, lorsque l’on parle de cloud public et de protection des données, tout est une question d’équilibre ou d’analyse des risques. Toutes les données ne sont pas égales, et il existe une gradation réelle entre données publiques, restreintes, confidentielles ou critiques. Les mesures de sécurité nécessaires à leur protection variera en fonction de cette gradation. Il est également important de trouver un équilibre entre ces contraintes de sécurité et l’apport d’un cloud public en termes de flexibilité, scalabilité, capacité d’innovation.

Pour conclure sur un exemple, imaginons que vous vouliez produire une base de connaissances contenant l’intégralité de vos propositions commerciales pour permettre une indexation et une recherche par mots-clés, appuyé sur un moteur de similarité utilisant de l’analyse du langage naturel. Ces propositions commerciales contiennent le nom du client et le prix, informations confidentielles.

La question à laquelle vous seul pouvez répondre est la suivante : vaut-il mieux conserver toutes ces données en interne et développer des solutions maison sur des infrastructures peu scalables, ou plutôt enlever le nom du client et le prix de ces documents pour les héberger dans le cloud public et les exploiter avec des solutions « as a service » totalement scalables et sans gestion d’infrastructure ?

Marius CONJEAUD

Consultant EVA Group

Categories: EVATECH