Lors des sessions d’information “Data Protection 2.0” du 21 et 28 juin 2016, j’ai eu l’occasion de présenter un nouveau concept très intéressant de la sécurité de l’information : le Data-Centric Security Model. Ce modèle est en réalité une nouvelle façon de protéger les données d’une organisation. Il diffère des habituelles défenses périphériques composées tant de murs physiques que de murs virtuels (p.ex. contrôle d’accès, firewall). Contrairement aux protections périphériques, le modèle de sécurité Data-Centric se focalise sur la protection des données elles-mêmes. Il a pour but de protéger toute donnée dite “sensible” partout et à tout moment, dès qu’elle est introduite dans le système informatique d’une organisation, que la donnée soit utilisée, en transit ou stockée. Ce modèle permet donc de déployer une sécurité globale et homogène dans une organisation.

Bien que le modèle de sécurité Data-Centric amène un nouvel espoir pour l’avenir de la sécurité des données, je souhaite tempérer nos aspirations vis-à-vis du modèle en nuançant quelque peu ses bienfaits. C’est pourquoi je souhaite récapituler dans ce blog les points d’attentions et conclusions émises à la fin des deux présentations au sujet du modèle de sécurité Data-Centric.

1. La mise en place du modèle peut s’avérer délicate

Pour mettre en place une telle sécurité, un minimum de re-engineering est nécessaire au niveau des applications par où transitent les données. Pour des applications qui (de base) sont bien conçues, cet effort va être généralement minimal (quelques lignes de code à rajouter). Dans les autres cas, cela peut malheureusement vite devenir un casse-tête. Dans tous les cas, l’utilisation d’un tel modèle de sécurité au niveau des applications est une méthode légèrement intrusive.

2. La classification des données est une opération pesante

Comme je l’ai expliqué durant les présentations, la première étape pour mettre en place un tel modèle de sécurité est la classification des données : quelles sont les données sensibles? où sont-elles stockées? qui y a accès? etc. Toutes ces questions doivent être posées pour ensuite déterminer quelles données doivent être absolument protégées. Cette classification est un travail lourd et obligatoire. Notons néanmoins que, sauf grand changement dans une organisation, la classification des données ne doit finalement être effectuée qu’une et une seule fois (au début de la mise en place du modèle), et elle doit seulement être maintenue à jour par la suite. Donc ce lourd travail n’est finalement qu’exceptionnel.

3. Les opérations sur les DB peuvent se compliquer

Lors des présentations, j’ai expliqué qu’une protection des données Data-Centric nécessite que cette protection se fasse au niveau applicatif, dès que la donnée rentre dans un système informatique. Ceci a des implications au niveau des opérations faites sur les bases de données. Tout d’abord, l’accès direct aux bases de données n’est plus compatible avec la protection Data-Centric : par exemple, il n’est plus possible de modifier directement une donnée dans une base de données ; il faut passer par la couche applicative pour le faire. Par contre, les opérations en batch sur les bases de données peuvent toujours s’effectuer (la nuit par exemple), mais elles devront aussi nécessairement passer par l’application correspondante.

4. Les DBA sont toujours capables de faire leur job

Le point précédent n’empêche pas les DBA de faire leur travail. Avec un modèle de sécurité Data-Centric, les DBA ont toujours la possibilité de modéliser et d’optimiser les bases de données, de changer leur structure, de dimensionner les espaces de stockage, de gérer les désastres, etc. Comme les données ne sont plus stockées en clair dans les bases de données, le seul changement est que les DBA n’ont donc plus accès aux données en clair.

5. La problématique de la qualité des données est toujours là

Lors des présentations, j’ai expliqué que les meilleures méthodes de protection Data-Centric sont le format preserving encryption et la tokenization. Dans ces deux méthodes, une donnée protégée va être “transformée” (c’est-à-dire chiffrée ou tokenisée) de façon unique. Si les données ne sont pas de bonne qualité, alors la transformation ne sera pas de bonne qualité non plus. Par exemple, la donnée “tania” (sans majuscule) peut être transformée en “cYjzL” et la donnée “Tania” (avec majuscule) peut être transformée en “OWpzN“. Ceci peut donc être problématique dans un système informatique où la qualité des données n’est pas primordiale, comme par exemple ne pas tenir compte de la casse des mots.

6. Il faut protéger un système, pas seulement une DB, ni toutes les données

Comme je l’ai expliqué durant les présentations, le but d’un modèle de sécurité Data-Centric n’est pas de se focaliser sur la protection d’une base de données, mais de voir plus large et de protéger un système informatique dans sa globalité. En effet, cela ne sert à rien de protéger une base de données si, à côté, on retrouve les mêmes données non protégées. Pour ce faire, il est aussi important de se rendre compte que protéger toutes les données n’a pas de sens. Il suffit de protéger les données sensibles (telles que définies dans la classification) et les données qui donnent malgré tout de l’information sensible sans s’en rendre compte. Par exemple, même si elle n’est reliée à aucune personne, la taille donne beaucoup d’information personnelle : généralement si elle est inférieure à une certaine borne (p.ex. 1,20 mètre), on pourra considérer que c’est un enfant, sinon on pourra s’imaginer un adulte ou adolescent. Il faut donc protéger ces données partout dans le système informatique cible.

7. Le partage inter-institutionnel de données est difficile

A l’heure actuelle, il est très difficile d’imaginer la mise en place d’un modèle de sécurité Data-Centric dans plusieurs organisations collaboratrices. Ceci est principalement dû au fait qu’il faudrait désigner un unique security officer capable de gérer la politique de sécurité centralisée pour toutes les organisations. Néanmoins, si chaque organisation fait l’effort de mettre en place un même modèle de sécurité Data-Centric, avec les mêmes paramètres de protection des données, alors le partage inter-institutionnel de données serait clairement faisable.

8. Le prix d’un tel déploiement est élevé

Aujourd’hui, tenter l’aventure Data-Centric a un coût non négligeable. Tout d’abord, il faut investir dans différents produits commerciaux pour classifier, surveiller, auditer, alerter, protéger, etc. les données. Ensuite, il faut former les employés d’une organisation à utiliser les produits achetés, car les employés vont devoir changer leur manière de travailler et utiliser ces nouveaux produits. Enfin, il faut adapter les applications déjà déployées pour y intégrer la protection Data-Centric offerte par les produits choisis. Bref, tout cela a un prix.

9. Le modèle de sécurité data-centric augmente la protection de la vie privée

Finalement, la mise en place d’un tel modèle ne se résume pas juste à l’achat d’outil(s) supplémentaire(s). La protection Data-Centric est clairement complémentaire aux défenses périphériques déjà en place autour d’un système informatique. Elle met la donnée au centre de la protection, ce qui favorise la protection des données à caractère personnel, donc de la vie privée. Il y a fort à parier qu’un tel modèle soit d’une grande aide pour une organisation qui souhaite être compatible avec la GDPR.

Pour moi, le modèle de sécurité Data-Centric améliore grandement les systèmes informatiques, en se protégeant d’une manière tout à fait originale et innovante. C’est au final le futur de la protection des données vers lequel les organisations devraient se tourner petit à petit.

Notons que le modèle de sécurité Data-Centric peut être vu dans un contexte plus large qu’on appelle le Data-Centric IT. Pour les lecteurs intéressés, mon collègue Koen Vanderkimpen explique dans son blog d’avril 2016 comment mettre en place une telle technologie avec REST.