CASBs épisode 4 : chiffrement et tokenisation des données
Dans les épisodes précédents consacrés aux CASBs, j’avais traité des aspects découverte du Shadow IT, de la protection et du contrôle des données « at rest » et « on fly » selon le type de données à protéger et contrôler. Voici la suite.
Dans une étude récemment publiée par Gemalto et Ponemon, portant sur presque 3500 réponses, la capacité de chiffrer ou tokeniser les données dans le cloud est considérée comme importante pour 72 % des entreprises et le sera encore plus dans les deux années suivantes pour 86 % des participants. Cette capacité de chiffrement et de tokenisation est justement proposée par de nombreux éditeurs de CASB avec la promesse d’une sécurisation accrue des services cloud. C’est donc par un article consacré à cette problématique que je vais clore cette série sur le CASB.
Comme dans les épisodes précédents, je décrirai les cas d’usages ainsi que les pour et les contre de chaque solution.
Chiffrer ou tokeniser : comment et pour quels cas d’usage
Dans cet article, Jean François Audenard nous expliquait la différence entre les deux techniques, je n’y reviens donc pas, focalisons nous plutôt sur les cas d’usage. Dans les deux cas, l’objectif de ces solutions est de renforcer la sécurité des données stockées dans un espace extérieur à l’entreprise, qu’il s’agisse de fichiers ou de données structurées.
Soyons clair : pour l’utilisateur la différence n’est pas flagrante. Il n’est même pas censé être au courant que les données qu’il envoie dans le cloud sont chiffrées ou tokenisées. La différence sera en revanche importante pour l’entreprise.
En effet, il faut se poser tout d’abord la question des données à chiffrer ou tokeniser. Pour des raisons de performance, il est évident que toutes les données ne peuvent être sécurisées. Seules les plus sensibles doivent l’être. On estime que moins d’un tiers des données ont un intérêt à être sécurisées et en général le pourcentage oscille entre 15 et 25 % dans les projets de chiffrement ou tokenisation avec les CASBs.
On peut également se poser la question de sécuriser les intitulés des champs. Par exemple un chiffre dont on ne sait pas à quoi il se rapporte n’a que peu d’intérêt. Tout projet de sécurisation des données d’une application cloud se doit d’adresser ces points. Il est donc, de facto, très adhérent au type de données à sécuriser, à la façon dont l’application sera utilisée c’est à dire au métier des utilisateurs de l’application. Cette implication des utilisateurs et la bonne compréhension de leur activité est clef pour la réussite de tout projet de chiffrement / tokenisation.
En termes d’architecture
Dans les deux cas il faudra mettre en place une passerelle assurant la fonction de transformation de la donnée. Dans le cas de la tokenisation il faudra gérer, séparément ou au sein de la passerelle, la base de donnée des tokens (faisant le lien entre la donnée et le token qui la remplace) qui sera stockée dans l’entreprise ou chez un tiers de confiance alors que les tokens seront enregistrés dans le cloud.
Dans le cas d’une plateforme de chiffrement, il n’y a pas de base de données à gérer mais il faut être vigilant quant à la gestion des clefs de chiffrement. Dans ces architectures, c’est souvent un HSM tiers, là encore hébergé localement ou chez un tiers de confiance, qui sera le garant de la sécurité des clefs. Certains éditeurs de CASB proposent ces passerelles de chiffrement / tokenisation dans le cloud. Cela me semble peu adapté au contexte européen. Si vous souhaitez en savoir plus ce document de Forrester détaille l’ensemble des cas possibles.
Les architectures techniques étant assez semblables, ce sont surtout les aspects légaux qui sont à prendre en compte. En effet, dans certains pays pour certains types de données, le chiffrement est exigé alors que dans d’autres cas la tokenisation s’impose. En particulier la norme PCI / DSS impose la tokenisation des numéros des cartes bancaires si ces données doivent être stockées.
Il faut aussi prendre en compte ce qu’il advient de la donnée
Là les deux solutions sont assez différentes. Dans le cas du chiffrement c’est une donnée, certes transformée, qui est stockée dans le cloud ce qui peut être contraire à la législation. Dans le cas de la tokenisation c’est un jeton, sans possibilité d’accès à la donnée d’origine qui est envoyé dans le cloud. Ce qui peut être conforme à des législations plus restrictives.
Autre point sensible : puisque vous stockez dans le cloud des données chiffrées ou tokenisées il est indispensable que le CASB se substitue à certaines fonctions de l’application cloud. En effet le CASB va devoir assurer les fonctions d’indexation, de recherche etc à la place de la solution cloud.
Enfin dans les deux cas il faut être vigilant sur le traitement des add-ons des services cloud traités par les deux solutions. Par exemple si le service cloud propose un chat intégré ou un MTA, sera-t-il possible de chiffrer / tokeniser les échanges ou les mails ?
Le chiffrement
Pour rappel dans le cas du chiffrement la donnée est chiffrée à la volée
Pour : A priori une architecture de chiffrement est plus légère à mettre en œuvre qu’une solution de tokenisation.
Ce qui donne la possibilité de gérer les clefs en interne avec un HSM tiers indépendant (éditeur différent, zone d’hébergement différente) de la solution de chiffrement. Les performances sont a priori meilleures et l’impact sur l’expérience utilisateur sera plus faible.
Contre : la donnée, même chiffrée, quitte l’entreprise et souvent le territoire national si elle est stocké dans un cloud non souverain.
Le processus est réversible, en cas de vol des données il est possible d’accéder aux données, avec difficulté certes mais c’est possible. La sécurité réside en grande partie sur le stockage et l’échange sécurisé des clefs entre le CASB et le HSM.
La tokenisation
Popularisée dans le cadre de la norme PCI DSS, la tokenisation remplace la donnée par un jeton aléatoire qui interdit toute réversibilité : chaque jeton étant généré indépendamment de son voisin.
Pour : le gain en sécurité est indéniable : la donnée ne quitte pas l’entreprise ou le territoire national.
En cas d’attaque et de vols des tokens, il est quasi impossible de reconstituer les données d’origine. La tokenisation répond aux exigences de certaines normes comme PCI DSS.
Contre : l’architecture est plus complexe à mettre en œuvre et à maintenir.
La gestion de la base des tokens nécessite les compétences d’un DBA.
Vous l’avez compris, les projets de chiffrement et de tokenisation des données stockées dans le cloud sont dans tous les cas des projets complexes. En accord avec Gartner il est recommandé de traiter avec soin tout projet de cet ordre. Au-delà des aspects architecturaux non négligeables, les considérations vis-à -vis des métiers sont importantes pour ne pas dégrader l’expérience utilisateur, le choix des données à sécuriser est fondamental et enfin la capacité à suivre les évolutions de la solution cloud est un facteur clef de succès sur la durée.
Je synthétiserai prochainement ces 4 épisodes sous forme de tableau reprenant les cas d’usage ainsi que le pour et le contre de chaque architecture.
Philippe
Pour aller plus loin
CASBs épisode 3 : protection et contrôle des données «on fly»
CASBs Episode 2 : Shadow Data – protection et contrôle des données «at rest»
Cloud Access Security Brokers (CASB) : le nouvel eldorado de la sécurité ?
Pour tout savoir sur les tendances 2016 de la cyberdéfense en 120 secondes
Orange Cyberdefense protège vos essentiels
CASBs épisode 4 : chiffrement et tokenisation des données was originally published on JDCHASTA SAS
