In een vorige blog had ik het reeds over het uitbesteden van gemeenschappelijke zaken, nodig voor meerdere ondernemingen, applicaties & diensten, aan een derde, hierin gespecialiseerde partij. Hetgeen deze laatste partij doet, noemen we “horizontale dienstverlening”; men opereert namelijk in een horizontale markt.

Nu wil ik graag enkele voorbeelden geven van hoe de overheid hetzelfde zou kunnen doen via een data-centric eGovernment (bovenop de vele zaken die ze reeds doet, met b.v. sterke eID authenticatie, de G-Cloud, en het eHealth platform).

Een aantal voorbeelden:

1. Chipkaarten

   In diezelfde vorige blog vernoemde ik de voordelen die er zouden ontstaan indien we het beheer van chipkaarten zouden afzonderen bij één horizontale chipkaartenbeheerder, en alle gebruikers van deze kaarten dan hiervan gebruik zouden kunnen maken. In een vergevorderd stadium zou het zo in principe zelfs mogelijk worden dat we via één enkele chipkaart van allerlei diensten, aangeboden door verschillende bedrijven (overheid of privé) gebruik kunnen maken, en we dus niet met een veelheid van de plastieken ondingen in onze portefeuille zouden moeten rondlopen. Dergelijke dienstverlener zou zelfs via een SaaS platform ook aan kleine ondernemingen een paar opties kunnen geven om b.v. aan een bestaande QR code op de chipkaart van een persoon, een klantenkaart te koppelen. Kortom, “one card to rule them all“. Misschien zou de overheid dit kunnen aanbieden via de eID?

2. “Waar-woon-ik-as-a-Service”

   Een eenvoudig, maar krachtig voorbeeld van nuttige en toch min of meer private data, zijn adressen en adreswijzigingen. Wat als elke adreswijziging die iemand onderging, onmiddellijk door alle (overheids-)diensten, door de post, door koeriers, en eventueel door een resem andere belanghebbenden was geweten? Dit scenario werkt als volgt:

   1. De burger verhuist, en de nodige (fysieke) controles gebeuren.
   2. De gemeenteambtenaar voert dit gegeven in (Dit gegeven valt trouwens onder de noemer “civic moment“: een belangrijke gebeurtenis in de levensloop van een burger (of bedrijf), die een aantal administratieve gevolgen kan triggeren).
   3. Vanaf dan zijn deze gegevens (zowel het nieuwe adres als de adresverandering) automatisch beschikbaar voor alle overheidsdiensten die er sowieso recht op hebben. Dit is mogelijk via het opvragen van de gegevens (b.v. via REST APIs), maar evenzeer kunnen sommige applicaties onmiddellijk op de hoogte worden gebracht (via Events). Bijgevolg kunnen deze diensten dus automatisch eventuele veranderde rechten en plichten van de burger die van zijn adres afhangen, aanpassen, en uiteraard ook hun briefwisseling naar het nieuwe adres richten.

      

   4. Daarnaast kan de overheid, als data custodian (zo noemen we de horizontale dienst van het databeheer), ook een applicatie aanbieden aan de burger zelf, waar deze de mogelijkheid krijgt om applicaties van andere bedrijven toegang te geven tot deze gegevens. Dit zou een beetje kunnen werken zoals een Google of Facebook account: ook tot deze accounts kan men (beperkte en specifieke) toegang verlenen aan andere applicaties. De burger zou dus b.v. op die manier aan Bpost de toestemming kunnen geven om deze gegevens automatisch te ontvangen. Vanaf dan zou de post automatisch naar het nieuwe adres kunnen worden doorgestuurd. Sterker nog: men zou het zo kunnen regelen, dat men brieven kan versturen op naam (en/of eventueel een unieke identifier die een burger voor zichzelf kan genereren in de toepassing), en dat de post deze dan vanzelf aan het juiste adres levert. Op die manier zou men niet meer overal zijn échte adres moeten opgeven en verhoogt men dus zelfs de privacy van de burger.
   5. Ook andere koeriersbedrijven zouden op deze dienst kunnen intekenen en door de burger geauthenticeerd kunnen worden om gebruik te maken van diens door de service gekende adres. Ik wacht trouwens nog steeds op de mogelijkheid om een account te creëren bij een koeriersbedrijf en daarna niet meer mijn adres te moeten geven in elke aparte webshop die ik gebruik, maar gewoon te kunnen aanvinken dat mijn gekozen koerier mijn adres reeds kent!

   In het voorbeeld maakte ik abstractie van een eventueel apart correspondentie-adres, of het gebruik van meerdere adressen, maar deze zou men even goed door de burger zelf kunnen laten beheren in een centraal aangeboden toepassing.

3. Civiele “Half-Open” Data

   Naast het adres heeft de overheid nog een schat van andere informatie over haar burgers en bedrijven. We moeten uiteraard rekening houden met de privacy van dergelijke data, maar desalniettemin kan deze functie van Data Custodian worden uitgebreid met heel wat interessante mogelijkheden. (Ik verwees in de chipkaartenblog reeds naar het gescheiden beheer van gegevensnetwerken versus de applicaties die ervan gebruik maken. De vortex van enablers maakt dit reeds perfect mogelijk.)

   Men zou bijvoorbeeld automatisch rechten kunnen afleiden uit bepaalde situaties die burgers ondergaan (verlies van werk, fysiek letsel, …) indien deze gebeurtenissen (dit zijn Civic Moments en Events!) en hun corresponderende nieuwe gegevens snel en automatisch door alle nodige diensten werden opgevangen.

   In het voorbeeld van het fysiek letsel zou de burger aan een dokter de toestemming kunnen geven om gegevens i.v.m. langdurige werkonbekwaamheid automatisch door te sturen naar instanties die hiervoor uitkeringen betalen. Een gelijktijdig gevolg, met communicatie naar de Fod SZ, zou kunnen zijn dat de burger automatisch een parkeerkaart voor personen met een handicap zou krijgen toegestuurd.

   Deze, en nog vele andere mogelijkheden die ontstaan door de juiste data op het juiste moment op de juiste plaats te krijgen, tonen nogmaals aan dat data-centric IT meer dan ooit van belang is (en – niet te vergeten – data-centric security).

Digitale transformatie

Het eGovernment heeft onlangs reeds een fenomenale stap vooruit gezet als horizontale dienstverlener via de G-Cloud, die ervoor zorgt dat men op infrastructuur- en middlewarevlak synergieën kon creëren. Nu is stilaan het moment aangebroken om verder te beginnen denken: ook bovenop de infrastructuur, binnen en tussen applicaties en vooral door hergebruik van gegevens, ligt er nog een goudmijn van mogelijkheden op ons te wachten. In dergelijke context praat men momenteel dan ook graag over “Digital Transformation” (een evolutie die eigenlijk al heel lang gaande is).

Tot nu toe focuste deze trend zich binnen de overheid daarbij vooral op kostenbesparingen: hoe hetzelfde doen, maar dan op een efficiëntere manier? Dit is uiteraard nuttig, maar Digitale Transformatie gaat veel verder dan dat (ook volgens de blogosphere, en ook wanneer het specifiek over Cloud gaat). De ware kracht van deze trend mag niet verloren gaan in oeverloze discussies over hoe alles goedkoper kan, of hoe de bestaande zaken met de nieuwe technologie efficiënter kunnen worden gemaakt.

Ik durf hierbij zelfs Bob Lewis bij te treden: IT plannen moeten niet gedreven worden door de noden van de business, maar de business strategie moet gedreven worden door de nieuw beschikbare technologische mogelijkheden!

Welnu: de technologieën die een grote evolutie mogelijk maken, zijn gearriveerd. Laten we onze inspiratie de vrije teugels geven, en bedenken wat voor interessante diensten we nog kunnen bieden, aan zowel de ambtenaren van ons land, als aan zijn burgers en bedrijven.

Méthodes de tokenization

Il existe essentiellement deux méthodes de tokenization.

1. Vault-based tokenization

Avec cette méthode, il n’y a aucune relation mathématique, ni aucune logique entre la donnée originale et le token correspondant. C’est donc un mapping aléatoire unique “donnée-token”.

Pour chaque type de données, un mapping est généralement stocké dans une table, nommée lookup table (p.ex. figure 1 ci-dessous). Toutes les lookup tables sont alors stockées sur un serveur de tokens, comme représenté dans la figure 2 ci-dessous.

Cette méthode peut être problématique quand la quantité de données à tokeniser augmente perpétuellement. En effet, si les lookup tables ne font que grossir, alors (1) la taille du serveur de tokens doit sans cesse être augmentée, et (2) il est difficile de répliquer un serveur de tokens de taille trop grande ailleurs.

La vault-based tokenization est donc la méthode la plus basique, à utiliser de préférence pour un ensemble de données assez petit, qui ne varie pas ou n’augmente pas beaucoup.

2. Vaultless tokenization

L’autre méthode de tokenization consiste en créer une ou plusieurs lookup tables génériques par type de données, comme illustré dans la figure 3 ci-dessous. Pour une base de données simple, on peut ainsi seulement créer une lookup table pour les nombres, et une pour les mots. Ces lookup tables sont pré-calculées à l’avance et bien sûr randomisées. Elles sont donc d’une taille fixe, préférablement plus petite que les tables de la méthode vault-based.

Avec ces tables pré-calculées, il est alors possible de tokeniser les données correspondantes. Par exemple, la figure 4 ci-dessus illustre une tokenization d’un numéro de carte de crédit. Notons que cet exemple de tokenization très simple est montré ici pour son aspect didactique. Il est tout à fait possible d’imaginer une tokenization plus élaborée, plus complexe, par exemple qui se servirait de 2 lookup tables de nombres (au lieu d’une), et/ou qui mélangerait davantage les nombres (au lieu d’un simple bloc-par-bloc).

La vaultless tokenization est donc la méthode la plus adéquate lorsqu’on souhaite tokeniser des ensembles de données grands et dynamiques.

Pourquoi la tokenization est-elle une méthode intéressante?

Tout d’abord, le critère unique et aléatoire d’une tokenization est très intéressant : il empêche tout attaquant de détokeniser et de retrouver la donnée originale à partir du token sans avoir les lookup tables correspondantes. Ces dernières sont en fait l’équivalent d’une clé cryptographique “super-puissante” dans un système standard de chiffrement. Donc le niveau de sécurité d’une tokenization est très élevé. Bien sûr, ceci est valable que lorsque les lookup tables sont stockées de manière protégée. Aussi, les données, même tokenisées, sont utilisables “as-is”. il est donc possible de faire des SEARCH et des SORT dans une base de données tokenisées. Un des seuls points négatifs est la taille des lookup tables, qui peut s’avérer très grande si l’on utilise la mauvaise méthode de tokenization. Donc le lieu de stockage des tables doit être pensé en fonction de cela.

La tokenization est déjà utilisée dans plusieurs domaines où la sécurité est primordiale. Le plus courant est le milieu bancaire. Par exemple, la tokenization est souvent utilisée pour protéger les données stockées, comme demandé par le standard PCI DSS (Payment Card Industry Data Security Standard). Autre exemple : en mars 2014, EMVCo (consortium des grandes firmes bancaires telles que Europay Mastercard Visa) a publié une méthode de tokenization pour les paiements EMV. On peut aussi retrouver la tokenization dans les systèmes de données médicales, ou encore pour les casiers judiciaires.

En fin de compte, c’est une technologie très intéressante, qui n’est qu’à ses balbutiements en terme de déploiement pratique, mais qui s’annonce être une petite révolution dans la protection des données.

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.

]]>