Mise en conformité des bases de données MySQL avec le RGPD

CONSERVATOIRE NATIONAL DES ARTS ET METIERS
CENTRE REGIONAL ASSOCIE DE LIMOGES
_______
MEMOIRE
présenté en vue d'obtenir
le DIPLOME d'INGENIEUR CNAM
SPECIALITE : Informatique et Systèmes d’informations
par
TRAËN Valentin
______
Mise en conformité des bases de données MySQL avec le Règlement
Général sur la Protection des Données
Soutenu le 24 Septembre 2020
_______
Devant le jury composé de :
Mme. Elisabeth METAIS, Présidente du jury
M. Jimmy JOUANNAUD, Responsable du centre de développement informatique de
Limoges à la CARSAT Centre Ouest
M. Jonathan GOURDON, Responsable adjoint de la production informatique chez Tessi

Je tiens à exprimer toute ma reconnaissance à Madame Sophie Pourtau et Monsieur
Jonathan Gourdon, responsable et responsable adjoint de la production informatique chez Tessi, qui
m’ont permis de réaliser cette étude dans le cadre de mon travail. Je remercie Monsieur Amine
Talbi, Data Protection Officer chez Tessi et Monsieur Rodolphe Baca, auditeur risques et
conformité RGPD chez Tessi qui ont accepté de répondre à mes questions durant mes recherches. Je
tiens aussi à remercier Monsieur Julien Brunot, chef de produit chez Tessi, pour ses conseils et
réflexions partagées tout au long de la réalisation de ce mémoire. Merci à Pierre Delage, chef de
projets chez Tessi pour sa relecture attentive.
J’adresse mes sincères remerciements à Monsieur Michael Coburn, architecte technique chez
Percona, Monsieur Peter Zaitsev, fondateur de Percona et Madame Lorraine Pocklington,
community manager chez Percona pour s’être intéressé à mon travail et m’avoir mis en relation
avec les équipes de Percona afin de mener à bien mon étude. C’est pourquoi la suite de mes
remerciements iront vers Messieurs Stephen Hoffman, chef de produit Percona Monitoring and
Management et Peter Schwaller, chef de produit Percona Server, qui ont su se rendre disponibles
afin d’éclaircir certains sujets et d’apporter des détails techniques relatifs à leurs solutions.
Je tiens enfin à remercier Monsieur Sunny Bains, leader du développement du moteur de stockage
innodb chez Oracle ainsi que Monsieur Georgi Kodinov, directeur du développement chez Oracle
qui m’ont accordé leur confiance et m’ont permis de valider mes recherches.
Remerciements

ACID : Atomicité Cohérence Isolation Durabilité
CIL : Correspondant Informatique et Liberté
CNIL : Commission Nationale de l’Informatique et des Libertés
DPO : Data Protection Officer
GNU : GNU’s Not Unix
GNU GPL : GNU General Public License
PAM : Pluggable Authentification modules
PDO : Php data Objects
RAM : Random Access Memory
RPGD : Règlement Général sur la Protection des données
SGBDR : Système de Gestion de Bases de Données Relationnelles
TDE : Transparent Data Encryption
TLS : Transport Layer Security
Liste des abréviations

Table des matières
Introduction............................................................................................................................7
I RGPD : Genèse et but du règlement....................................................................................9
I.1 La protection des données personnelles à l’ère numérique..........................................9
I.1.A Historique de la protection des données en Europe et en France........................9
I.1.B Enjeux de la protection des données..................................................................11
I.2 Le Règlement Général sur la Protection des Données...............................................15
I.2.A Explication du texte de loi.................................................................................15
I.2.B Application du RGPD aux bases de données relationnelles..............................24
I.3 Le RGPD chez Tessi...................................................................................................26
I.3.A Le groupe Tessi..................................................................................................26
I.3.B Conformité des bases de données MySQL avec le RGPD chez Tessi...............27
II Présentation de l’environnement d’étude.........................................................................30
II.1 Serveur utilisé pour l’étude.......................................................................................30
II.2 Base de données utilisée pour l’étude.......................................................................30
II.3 Configuration de l’instance Percona Server réalisée pour l’étude............................30
III Mise en place du chiffrement des données......................................................................32
III.1 Intérêt du chiffrement des bases de données...........................................................32
III.2 Emplacement des données et nécessité du chiffrement...........................................33
III.2.A Emplacement des données sur disque dur.......................................................34
III.2.B Maintien des données en Ram........................................................................39
III.2.C Échange de données à travers le réseau.........................................................41
III.3 Mise en place du chiffrement des données innodb avec Percona Server for MySQL
.........................................................................................................................................44
III.4 Analyse des performances de Percona Server for MySQL après chiffrement des
données innodb................................................................................................................51
III.4.A Insertion des données......................................................................................52
III.4.B Projection de données non optimisée.............................................................53
III.4.C Projection de données optimisée.....................................................................55
III.4.D Génération d’une table temporaire..................................................................56
III.5 Mise en place du chiffrement des redo logs, undo tablespaces et logs binaires avec
Percona Server for MySQL.............................................................................................57
III.6 Supervision de la solution de chiffrement mise en place........................................59
IV Mise en place du module d’audit des actions menées en bases de données...................62
IV.1 Présentation du module d’audit de Percona Server for MySQL..............................62
IV.2 Authentification des utilisateurs dans Percona Server for MySQL et adéquation
avec le module d’audit.....................................................................................................68
5

IV.2.A Configuration des comptes nominatifs............................................................70
IV.2.B Configuration de groupes d’utilisateurs..........................................................70
IV.3 Adéquation du module d’audit avec la sécurisation des données............................74
V Anonymisation et pseudonymisation des données à caractère personnel.........................76
V.1 Pseudonymisation des données à caractère personnel..............................................76
V.2 Anonymisation des données à caractère personnel...................................................77
V.2.A Le module d’anonymisation fourni avec Percona Server for MySQL 8.0.......78
V.2.B Mise en place de l’anonymisation grâce à ProxySQL......................................81
Conclusion............................................................................................................................93
Annexes................................................................................................................................95
Bibliographie......................................................................................................................108
Index des figures :...............................................................................................................111
Index des tableaux..............................................................................................................113
6

Introduction
La protection des données personnelles est depuis plusieurs années mise en avant
par différentes entreprises comme étant un élément de différenciation et de confiance pour
leurs clients. C'est ainsi que fin 2019, Apple diffuse une publicité ne ventant aucune
caractéristique technique de son smartphone; on ne trouve en effet dans ce spot télévisé
qu'un seul argument de vente : "Respect de la vie privée. C'est ça l'iPhone.". On est dès lors
en droit de se poser plusieurs questions : Ma vie privée est-elle réellement respectée
lorsque j'utilise un iPhone ? Ne l'était-elle pas auparavant ? L'est-elle plus avec un iPhone
qu'avec un autre smartphone ? Qu'est-ce qui est mis en œuvre afin de garantir la
sécurisation de mes données ? Les différents scandales autour des fuites de données qui ont
été médiatisés ont renforcé la méfiance des utilisateurs quant à la sécurisation de leurs
informations personnelles. Les grosses sociétés misent désormais leurs campagnes
marketing sur le fait que ,chez elles, nos
données sont parfaitement cloisonnées
et ne sont utilisées qu’aux fins
nécessaires à la réalisation des services
qu’on leur demande. Il ne s’agit
cependant pas d’une prise de conscience
collective et désintéressée : la loi
européenne, par l’intermédiaire du
Règlement Général sur la Protection des
Données, leur impose différentes règles
à appliquer en ce sens. Dans un système
d’information et même dans un
processus complet de vente ou d’embauche, les données relatives aux individus sont
omniprésentes et leur sécurisation doit être assurée tout au long de la chaîne de traitement.
La gestion des données personnelles en entreprise est bien souvent confiée à des bases de
données qu’il est alors nécessaire de protéger. Si les éditeurs de solutions de gestion de
bases de données ont su adapter leurs logiciels aux exigences du RGPD, il n’est pas
toujours aisé d’identifier les actions qui doivent être menées afin de rendre conformes des
bases de données historiques avec ce règlement. Les choix faits ne sont alors pas toujours
7
Figure 1: Campagne publicitaire pour le moteur
de recherche DuckDuckGo, affichée en France en
Juin 2020

les bons et il peut subsister des problèmes de cohérence et/ou de coût des solutions
choisies. C’est pourquoi nous étudierons dans ce mémoire, à travers le prisme des bases de
données MySQL, une solution de mise en adéquation de celles-ci avec le RGPD. Cette
solution, centralisée autour d’un système de gestion de bases de données unique et gratuit
et d’un applicatif complémentaire a pour but de rendre n’importe quelle base de données
MySQL compatible avec le règlement européen.
Dans ce document, nous allons tout d’abord nous intéresser au RGPD et à ce qu’il impose
aux entreprises. Différents aspects de son application aux bases de données relationnelles
MySQL seront ensuite abordés, comme le chiffrement des tables, l’audit des actions
menées sur les données ainsi que l’anonymisation et la pseudonymisation des données à
caractère personnel.
8

I RGPD : Genèse et but du règlement
Le Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril
2016, relatif à la protection des personnes physiques à l'égard du traitement des données à
caractère personnel et à la libre circulation de ces données, aussi appelé Règlement sur la
Protection des Données (RGPD) encadre le traitement des données à caractère personnel
sur l'ensemble du territoire de l'Union Européenne. Il permet la définition de plusieurs
notions essentielles à la protection des données dans un monde résolument numérique qui a
vu le nombre d'informations stockées s’accroître considérablement en quelques années.
I.1 La protection des données personnelles à l’ère numérique
I.1.A Historique de la protection des données en Europe et en France
Il n'a pas fallu attendre la mise en place du RGPD pour que la société se rende
compte de l'importance du besoin de protéger les données personnelles.
9
Figure 2: Image montrant l'évolution prévisionnelle des données numériques entre
les années 2010 et 2035

En 1974, le projet SAFARI (Système Automatisé pour les Fichiers Administratifs et le
Répertoire des Individus) inquiète déjà les Français. Mis en lumière par le quotidien Le
Monde qui titre à l'époque "SAFARI ou la chasse aux Français", ce projet a pour but
l'interconnexion des fichiers de l'administration française grâce à l'utilisation d'un
identifiant unique : le numéro de sécurité sociale. Ainsi, grâce à un seul et même
identifiant, toutes les informations connues par l’État sur un individu sont récupérables.
Face au tollé provoqué par cette révélation, le gouvernement de l'époque décide
d'abandonner ce projet. C'est dans ce contexte qu'est rédigée et votée la première version
de la loi "Informatique et Libertés", entrée en application le 06 janvier 1978. En parallèle,
la première Autorité Administrative française naît : la Commission Nationale de
l'Informatique et des Libertés (CNIL). Cette commission veille au respect de la loi
"Informatique et Libertés" qui garantit que l'informatique doit rester une technologie au
service des citoyens et ne doit aucunement mettre en péril les différentes libertés
intrinsèques à ce statut. La CNIL vérifie alors que tous les traitements effectués sur les
données par les administrations respectent les pré-requis exposés par le texte de loi.
En 1995, la directive européenne 95/46/CE, relative à "la protection des personnes
physiques à l'égard du traitement des données à caractère personnel et à la libre circulation
de ces données" est adoptée. Elle reprend les bases de la loi "Informatique et Libertés" en
généralisant à l'ensemble des pays de l'Union Européenne la mise en place d'une
commission similaire à la CNIL et en uniformisant le régime juridique relatif aux données
sensibles.
C'est en 2004 que la loi "Informatique et Libertés" est mise à jour pour la première fois.
Elle souffre de lacunes concernant les nouvelles technologies qui ont totalement modifié la
façon dont les données sont traitées à cette époque; en effet, l'explosion de nouvelles
façons de communiquer et d’interagir avec l’environnement (nanotechnologies,
smartphones...) ainsi que la démocratisation d'Internet ont rendu la loi de 1978 obsolète et
incomplète. C'est aussi l'occasion pour la France d'aligner son texte national avec la
directive européenne 95/46/CE publiée 9 ans plus tôt. Des apports de cette mise à jour
modifient en profondeur le champ d'application de cette loi, avec notamment la double
obligation pour le secteur privé :
- celle de demander l’'autorisation préalable à la CNIL pour la mise en place de certains
traitements
10

- la déclaration de tout document - même non informatisé - permettant la collecte et le
classement de données à caractère personnel.
Des sanctions peuvent désormais être prises par la CNIL. Enfin, un Correspondant
Informatique et Libertés (CIL) peut être désigné au sein des administrations et entreprises
afin de veiller à la bonne application de la loi.
2016 est une année charnière concernant la protection des données individuelles sur les
territoires français et européens.
En France, la promulgation de la loi n° 2016-1321 du 7 octobre 2016 pour une République
numérique vient considérablement enrichir la loi "Informatique et Libertés" révisée en
incluant par exemple la possibilité pour un citoyen d'avoir un droit de regard sur les
données collectées le concernant : il peut à tout moment décider et contrôler l'usage qui est
fait de ses données. Le citoyen dispose désormais d'un accès complet et privé aux données
personnelles le concernant, comme celles échangées dans le cadre d'une messagerie
électronique; la mise à disposition de ces données pour tout autre traitement doit faire
l'objet d'un accord préalable qui devra régulièrement être renouvelé. On peut aussi citer la
portabilité des données qui permet à un citoyen le transfert de ses données d'un service à un
autre, la pénalisation des revanches pornographiques ainsi que la mise en place du concept
de mort numérique.
La directive européenne "police-justice" 1
permet quant à elle d'encadrer les traitements mis
en place sur les données dans le cadre d'infractions pénales commises par un citoyen.
Enfin, le RGPD est aussi adopté en 2016 pour une entrée en application le 25 mai 2018. Ce
règlement sera détaillé dans la suite de ce mémoire.
I.1.B Enjeux de la protection des données
Même si l'idée de respect de la vie privée et de risques liés à la collecte des données
existe depuis 1974 - et même depuis la deuxième guerre mondiale du fait des registres mis
en place à cette époque - les enjeux liés à la protection des données privées ont
considérablement évolué.
1 DIRECTIVE (UE) 2016/680 DU PARLEMENT EUROPÉEN ET DU CONSEIL du 27 avril 2016
relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel
par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d'enquêtes
et de poursuites en la matière ou d'exécution de sanctions pénales, et à la libre circulation de ces données,
et abrogeant la décision-cadre 2008/977/JAI du Conseil
11

La crainte de main mise de l'information relative à un citoyen par un gouvernement est tout
de même belle et bien toujours présente, notamment du fait des révélations d'Edward
Snowden en 2013; cet informaticien, ancien employé des services de renseignements
américains (Central Intelligence Agency et National Security Agency), a rendu publique les
pratiques d'écoutes téléphoniques et d'écoutes
sur internet mises en place par les
gouvernements américain et britannique.
L'étude "Chilling Effects : Online
Surveillance and Wikipedia Use" menée par
Jonathon W.Penney (2016) révèle que le
trafic vers les pages Wikipédia traitant de
sujets sensibles au vue d'un gouvernement
(« attaque suicide », « bombe radiologique »,
« terrorisme » etc...) s'est vu
considérablement réduit. Il est alors
nécessaire de rassurer la population par la mise en place de mesures assurant la protection
des données et leur anonymisation. En effet, cette peur de représailles d'un gouvernement
qui serait à l'écoute de toutes les recherches faites sur Internet (ou sur tout autre média) va
à l'encontre des libertés individuelles et notamment de la liberté d'expression et de la
liberté de s'informer. Le haut-commissaire aux droits humains de l'Organisation des
Nations Unies indique d'ailleurs dans le rapport A/HRC/28/29 que de telles pratiques de
surveillance ont un impact sur les droits humains tels que "les droits à la vie privée, à la
liberté d'expression et d'opinion, de liberté de rassemblement, de vie familiale et de santé".
Il indique qu’Internet a permis la mise en place de moyens de communication à une échelle
jamais connue auparavant et qu’il permet d'élever le débat en matière de droits de l'Homme
d'une manière "inimaginable" il y a quelques années encore. Le haut-commissaire relève
que des lacunes en matière de droit national dans certains pays entraînent des dérives mais
que le droit international des droits de l'Homme doit tout de même être respecté, quelles
que soient les raisons invoquées pour la mise en place d'une telle surveillance. Enfin, il est
rappelé que les entreprises du secteur privé sont soumises aux mêmes règles, même si les
demandes proviennent d'un état.
Dans ce même rapport de l'ONU, il est indiqué que l’agrégation d'informations est aussi
dangereuse pour la vie privée. A une époque où Internet s'est démocratisé, que les
12
Figure 3: Image montrant la logique de
rapprochement des données utilisée par
Latanya Sweeney

smartphones ont pris place dans tous les foyers et que l'Internet des objets est en constante
croissance (enceintes connectées, caméras de surveillance domestiques ...), le nombre de
données collectées par les différents services auxquels on est abonné, par les constructeurs
de nos appareils et leurs partenaires est colossal. Il devient très difficile de maîtriser les
données transmises et d'imaginer l'impact que la mise en relation de données collectées par
différents services peut avoir. Dans son étude "k-Anonymity : A Model For protecting
Privacy" (2002), Latanya Sweeney a montré que le croisement de données pouvait révéler
l'identité de quelqu'un et ainsi compromettre sa vie privée. En croisant les bases de données
anonymisées d'un organisme d'assurance avec la base de données des personnes ayant voté
dans la ville de Cambridge, il a été possible de remonter très facilement jusqu'au
gouverneur de l'époque de l'état du Massachusetts aux Etats-Unis et ainsi de révéler son
dossier médical. Dans un autre rapport scientifique, "Unique in the Crowd : The privacy
bounds of human mobility", Yves-Alexandre de Montjoye et al. (2013) ont montré qu'ils
étaient capables de retrouver l'identité d'une personne dans 95% des cas avec seulement
quatre points spatio-temporels spécifiés toutes les heures. Ils démontrent dans cette étude
que l'unicité des déplacements humains est réelle et qu'il est facile de retrouver l'identité
d'une personne grâce, par exemple, à la mise en lumière de son trajet domicile-travail. Ils
rappellent d'ailleurs que l'unicité d'un individu avait été prouvée en 1930 par Edmond
Locard grâce aux empreintes digitales mais que 12 points de lecture étaient alors requis.
De telles données spatio-temporelles, du fait de l’évolution de notre mode de vie et de
notre utilisation de la technologie, ne sont plus seulement détenues par les opérateurs
téléphoniques mais par de nombreuses entreprises. La récupération de telles données par
un individu malintentionné s’en trouve facilitée. Le monde entier prend maintenant
conscience de l'importance que peuvent avoir les données tant certaines fuites et attaques
médiatisées ces dernières années ont pu choquer l'opinion publique. L'affaire des Panama
Papers est sans doute celle qui a le plus marqué les esprits et montré de façon concrète
qu'une fuite de données associée aux bonnes informations peut révéler l'identité de
personnes qui ont pourtant pris la peine de "se cacher" de façon très sophistiquée.
Les attaques par le biais de logiciels bloquant les données et demandant une somme
d'argent afin de les débloquer (ransomware) ont aussi explosé et ont été rendues publiques.
Tout le monde peut être touché, quelle que soit la plateforme utilisée pour conserver ses
données. De plus, la médiatisation de telles attaques sur des administrations comme des
hôpitaux ou des écoles inquiète davantage les citoyens. Le scandale Facebook-Cambridge
13

Analytica a aussi indigné les peuples américain et britannique. En fournissant les données
personnelles de 87 millions d'utilisateurs à une société d'analyse de données, Facebook a
permis d'influencer certaines élections aux États-Unis. En 2018, Facebook a même reconnu
recueillir des données d'internautes inscrits ou non sur sa plateforme. Il s'agit là d'une tout
autre problématique concernant la conservation des données personnelles : peut-on faire
confiance aux entreprises qui nous fournissent des services sur Internet ?
La ruée vers l'or numérique a commencé. Les entreprises ont compris l'importance des
données et le bénéfice qu'elles peuvent en tirer. On constate d'ailleurs que le nombre
d'offres d’emplois de data-scientists (informaticiens et mathématiciens qui exploitent et
donnent de la valeur aux données) a explosé ces dernières années.
La société a aussi sa part à jouer dans la sécurisation des données. Si les risques sont
désormais si élevés, c'est en partie dû à la façon dont on consomme et dont on utilise les
réseaux sociaux. Dans un monde où l'image publique est devenue essentielle, où le culte de
la personnalité est omniprésent, il en va de la responsabilité de chacun de maîtriser les
informations partagées sur Internet. La conscience numérique est une notion qui doit
prendre une place centrale dans la vie d'un citoyen du 21ème siècle, qui doit se poser les
bonnes questions avant d'alimenter la base de données d'un service numérique et être
pleinement au fait des possibles répercussions que ces actions entraînent.
14
Figure 4: Graphique montrant l'évolution du nombre de postes de data scientist ouverts
entre 2016 et 2019 dans les plus gros groupes mondiaux

I.2 Le Règlement Général sur la Protection des Données
C’est dans ce contexte d’omniprésence et d’abondance de données à caractère
personnel, abondamment stockées dans des bases de données, que le RGPD a vu le jour. Le
but de ce règlement est de protéger les utilisateurs de services, salariés ou citoyens d’un
pays de l’Union Européenne et de limiter la possibilité pour les entreprises ou
administrations de diffuser librement les données recueillies. Ce règlement a aussi servi de
base au « California Consumer Privacy Act », législation en place depuis le 1er
Janvier
2020 dans l’état de Californie aux États-Unis.
I.2.A Explication du texte de loi
Le RGPD permet de fixer un cadre concernant la mise en œuvre des traitements de
données à caractère personnel, qu’ils soient informatisés ou non.
Les différents concepts clés liés à la protection des données personnelles
Avant de détailler ce règlement européen, il est nécessaire de définir différentes
notions clé. Commençons par les « données à caractère personnel ». Voici comment le
RGPD définit une donnée à caractère personnel (Article 4) :
« Toute information se rapportant à une personne physique identifiée ou identifiable [...];
est réputée être une «personne physique identifiable» une personne physique qui peut être
identifiée, directement ou indirectement, notamment par référence à un identifiant, tel
qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne,
ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique,
génétique, psychique, économique, culturelle ou sociale ».
Cette définition est assez claire pour ne pas être explicitée. Il est cependant utile de préciser
que le champ d’application de cette définition ne se limite pas seulement aux données
informatisées ; en effet, tout document « physique » comme une photographie ou un
document papier manuscrit est aussi concerné. Une donnée peut être à caractère personnel
même si elle est publique : ce n’est pas la confidentialité de celle-ci qui indique son
caractère mais son lien possible avec l’identification d’un individu. Une donnée à caractère
personnel peut permettre d’identifier directement une personne en ne laissant pas
d’ambiguïté quant à son identité (nom de famille, photographie de la personne, etc.) ou
15

indirectement ; un numéro de client ou de téléphone, par exemple, peuvent permettre
l’identification d’une personne par croisement avec une autre base de données (un annuaire
téléphonique par exemple). Enfin, la combinaison de données peut permettre
l’identification d’une personne même si, prises séparément, ces données ne semblent pas
significatives. Par exemple, Latanya Sweeney a réussi à identifier dans son étude citée plus
haut le gouverneur du Massachusetts seulement grâce à son sexe, sa date de naissance et
son code postal. De telles données relèvent donc aussi de la notion de données à caractère
personnel puisqu’elles peuvent permettre l’identification d’un individu lorsqu’elles sont
associées entre elles.
Il est nécessaire de distinguer les données à caractère personnel et les données à caractère
personnel dites sensibles dont la collecte, par défaut, n’est pas autorisée par le RGPD. Les
données sensibles concernent une liste définie de données identifiantes et personnelles
comme par exemple les origines raciales, l’orientation sexuelle, l’appartenance à un
syndicat, les données biométriques. Il en va de même pour le numéro de sécurité sociale et
pour les données concernant les condamnations pénales. Des exceptions sont cependant
prévues afin de pouvoir assurer le traitement de ces données par les organismes de santé
par exemple. Un consentement explicite de la personne concernée peut aussi permettre le
traitement de telles données, ainsi que le fait que cette personne les a elle-même rendues
publiques.
On comprend déjà la complexité liée à la détermination des données à caractère personnel
dans un traitement de données. Mais qu’est-ce qu’un traitement de données ? Dans quelle
mesure peut-on considérer que l’on traite des données à caractère personnel ? Voici
comment le RGPD définit cette notion (Article 4):
« Toute opération ou tout ensemble d'opérations effectuées ou non à l'aide de procédés
automatisés et appliquées à des données ou des ensembles de données à caractère
personnel, telles que la collecte, l'enregistrement, l'organisation, la structuration, la
conservation, l'adaptation ou la modification, l'extraction, la consultation, l'utilisation, la
communication par transmission, la diffusion ou toute autre forme de mise à disposition, le
rapprochement ou l'interconnexion, la limitation, l'effacement ou la destruction ». Ainsi,
dès lors que des données sont recueillies même pour simple consultation ou transfert,
même si aucun stockage de ces données n’est engagé, on parle de traitement de données.
16

On reconnaît bien ici dans cette liste d’opérations les actions liées à la gestion de données
dans une base de données comme MySQL.
Désormais, les notions de responsable de traitement et de sous-traitant peuvent être
définies. Un organisme est responsable du traitement des données s’il est à l’origine de la
définition de sa finalité : c’est cet organisme qui a défini quelles données sont nécessaires
au traitement, leur cycle de vie et leur adéquation avec le besoin défini.
Un sous-traitant quant à lui traite des données à caractère personnel pour le compte d’un
responsable de traitement ; le sous-traitant a un domaine d’action restreint qui peut être vu
comme une brique nécessaire à l’érection du mur nécessaire au traitement des données. Un
même organisme peut tout à fait à la fois être responsable d’un traitement et sous-traitant
pour un autre. Les entreprises fournissant des appareils ou des logiciels ne contenant pas de
données au moment de la livraison ne sont pas considérés comme sous-traitant.
Champ d’application et grands principes du RGPD
Le RGPD concerne toute organisation publique ou privée traitant des données de
citoyen de l’Union Européenne, qu’elle se trouve dans ou hors de l’Union Européenne. Le
RGPD est aussi applicable à l’ensemble des organisations dont le siège social se trouve
dans l’Union Européenne.
Le transfert des données hors UE est tout de même prévu et réglementé : les données
d’individus européens transitant dans ou en dehors de l’Union Européenne doivent être
protégées de la même façon à chaque étape du processus. Certains pays comme la
Nouvelle Zélande et le Japon fournissent un protection suffisante des données du fait de
leur législation locale et le transfert de données vers ces pays ne requiert donc pas
d’autorisation spéciale. Pour d’autres pays, une autorisation de la CNIL sera nécessaire. La
personne concernée par les données en transit devra alors être avertie et avoir donné son
consentement sauf si le transfert se fait dans le cas d’un contrat ou d’un motif d’intérêt
public ou nécessaire à la sauvegarde des intérêts vitaux de cette personne.
Ce règlement s’appuie sur les grands principes détaillés ci-dessous :
• La finalité du traitement des données doit être explicite. On parle de finalité afin
de désigner le but du traitement : pourquoi recueille-t-on ces données ? La finalité
17

est essentielle à la définition du besoin et donc à la justification du choix des
données collectées : ne peuvent être collectées que les données personnelles utiles
au traitement. Afin d’éviter toute ambiguïté concernant les données à caractère
personnel nécessaires au traitement, l’énonciation de la finalité du traitement doit
être claire et intelligible pour tous et doit faire référence à un traitement spécifique
afin de ne pas mélanger les différentes données et leur utilité. Énoncer une finalité
ne suffit pas à définir les données dont on a besoin : il faut que cette finalité soit
légitime. En effet, il convient de ne pas définir une finalité qui ne serait pas en
accord avec le service fourni afin de récupérer des données supplémentaires à celles
réellement utiles. Il n’est ainsi pas possible de définir une finalité « géolocalisation
des utilisateurs d’un site de recettes de cuisine ». Toute utilisation des données
recueillies pour une finalité autre que celle définie et validée par l’utilisateur
(comme un transfert des données à un site partenaire afin qu’il envoie de la
publicité ciblée à l’utilisateur alors que la finalité initiale n’était qu’un achat sur le
site marchand) relève du détournement de finalité qui peut conduire à une sanction
administrative (20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial)
selon l’article 83-5 du RGPD et pénale (300 000€ d’amende et 5 ans de prison)
selon l’article 226-21 du code pénal. Il est tout de même possible d’utiliser les
données recueillies à toute autre fin compatible tel que défini dans l’article 5 du
RGPD : « le traitement ultérieur à des fins archivistiques dans l'intérêt public, à des
fins de recherche scientifique ou historique ou à des fins statistiques ».
• La minimisation des données à caractère personnel doit être mise en place.
Autrement dit, les données collectées doivent être nécessaires au regard de la
finalité du traitement mis en place et ne doivent pas être exhaustives : ne doivent
être collectées que les données requises pour la mise en place de ce traitement. On
va ici au-delà de la notion de pertinence d’une donnée à caractère personnel : si
cette donnée est pertinente avec la finalité définie pour le traitement mais n’est pas
nécessaire à sa mise en place, elle ne doit pas être collectée. Dans le cas d’un site
marchand par exemple, dans le cadre du traitement des commandes d’un utilisateur,
il peut paraître pertinent de demander le sexe de l’individu afin de préfixer son nom
au moment de l’envoi de la commande mais cette information n’est pas nécessaire
au bon fonctionnement du processus : elle ne doit donc pas être demandée. Les
données collectées doivent aussi être maintenues à jour afin de répondre au besoin
18

de minimisation. Si l’on a par exemple récupéré l’adresse mail d’un client d’une
enseigne de grande distribution dans le cadre d’une opération de communication, il
faut s’assurer de la suppression de cette adresse mail si le client ne souhaite plus
recevoir d’informations par mail. Aucune donnée ne peut être recueillie à titre
préventif afin de palier à une mise à jour prévue du traitement. Dès lors que les
données collectées ne sont plus utiles au traitement défini avec la personne
concernée et qu’aucun autre traitement n’a été consenti, celles-ci peuvent être
anonymisées, c’est à dire transformées afin d’empêcher de manière irréversible
l’identification de la personne. Ces données sortiront alors du cadre du RGPD.
• Le traitement doit respecter la législation, être licite. Selon l’article 6-1 du
RGPD, le traitement ne peut être licite que s’il remplit au moins une des conditions
suivantes :
- « la personne concernée a consenti au traitement de ses données à caractère
personnel pour une ou plusieurs finalités spécifiques ». Le consentement est défini
dans le RGPD (article 4-11) comme « toute manifestation de volonté, libre,
spécifique, éclairée et univoque par laquelle la personne concernée accepte, par une
déclaration ou par un acte positif clair, que des données à caractère personnel la
concernant fassent l'objet d'un traitement ». Le consentement ne doit donc pas être
forcé et doit être recueilli pour un seul traitement de données et non pour
l’ensemble couvert par la prestation ou par l’organisme. Il doit aussi être donné
dans un contexte clair à partir d’un texte concis par exemple mettant en avant les
éléments essentiels mais renvoyant tout de même vers une page ou un document
exhaustif. L’acte de consentement ne doit en effet pas laisser place au doute : le
consentement ne peut être donné « par défaut » en l’absence de réponse ou à travers
de cases pré-cochées dans un formulaire. Le responsable de traitement doit être en
mesure de fournir la preuve du recueil de consentement.
- « le traitement est nécessaire à l'exécution d'un contrat auquel la personne
concernée est partie ou à l'exécution de mesures précontractuelles prises à la
demande de celle-ci ». Dans le cas d’un contrat entre un client et un fournisseur de
matériel informatique par exemple, sera reconnu licite le traitement concernant la
collecte d’informations personnelles telles que l’adresse du client, son nom et un
numéro de téléphone dans le cadre du besoin de livraison des commandes.
19

- « le traitement est nécessaire au respect d'une obligation légale à laquelle le
responsable du traitement est soumis ». Une société peut par exemple avoir à
demander des informations personnelles à ses clients ou à ses usagers si son secteur
d’activité relève de la défense nationale.
- « le traitement est nécessaire à la sauvegarde des intérêts vitaux de la personne
concernée ou d'une autre personne physique ». Il est assez évident ici que la
collecte d’informations relatives à une personne peut être faite auprès de proches
par un organisme de santé si la vie de cette personne est en jeu et qu’elle ne peut
consentir et fournir elle-même les informations requises par le traitement.
- « le traitement est nécessaire à l'exécution d'une mission d'intérêt public ou
relevant de l'exercice de l'autorité publique dont est investi le responsable du
traitement ». Ainsi, un commissariat de police pourra traiter les informations
personnelles d’une personne dans le cadre d’une enquête.
- « le traitement est nécessaire aux fins des intérêts légitimes poursuivis par le
responsable du traitement ou par un tiers, à moins que ne prévalent les intérêts ou
les libertés et droits fondamentaux de la personne concernée qui exigent une
protection des données à caractère personnel, notamment lorsque la personne
concernée est un enfant. » Le traitement des données collectées par le responsable
de traitement doit correspondre à un traitement « logique » pour la personne au
regard de la relation qu’il entretient avec l’organisme et des missions de cet
organisme.
• Les données ne peuvent être conservées indéfiniment par l’organisme. Ce
principe existe en France depuis la première version de la loi Informatique et
Libertés. La durée de conservation des données peut soit être réglée par une valeur
fixe, soit par une valeur relative à un élément objectif tel qu’un contrat par
exemple. Les données à caractère personnel doivent alors être supprimées du
système, archivées (dans un souci de respect des obligations légales, dans le cas
d’éventuel contentieux, pour des besoins statistiques) ou bien anonymisées.
Attention, pour rappel l’anonymisation est bien différente de la pseudonymisation.
L’anonymisation modifie les données de telle sorte qu’il n’est pas possible par
quelque moyen que ce soit de réidentifier la personne, ce qui n’est pas le cas de la
20

pseudonymisation. Les bases de données sont concernées par l’anonymisation et la
pseudonymisation ; la dernière partie de ce mémoire sera dédiée à ces notions.
• Les données à caractère personnel doivent être sécurisées. Le niveau de
sécurisation demandé sera à évaluer en fonction des données possédées et de la
sensibilité des informations qui y sont liées. La sécurité étant un processus continu
en constant changement, ce principe de sécurisation des données doit être inclus
dans ce même processus afin de réévaluer le risque régulièrement. Le RGPD
propose certaines mesures de sécurité qui doivent être appliquées dès lors que
l’évaluation du risque nécessite de mettre en place des mesures de sécurité,
notamment (article 32-1) :
« - la pseudonymisation et le chiffrement des données à caractère personnel.
- des moyens permettant de garantir la confidentialité, l'intégrité, la disponibilité et
la résilience constantes des systèmes et des services de traitement.
- des moyens permettant de rétablir la disponibilité des données à caractère
personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique
ou technique.
- une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des
mesures techniques et organisationnelles pour assurer la sécurité du traitement. »
Les données doivent rester intègres, c’est à dire ne doivent pas pouvoir être
modifiées par un élément externe au traitement des données défini. Elles doivent
constamment être disponibles et consultables et ne peuvent être lues que par les
personnes qui en ont l’habilitation. Des mesures physiques doivent donc être prises
afin de limiter l’accès aux locaux d’une organisation aux seules personnes
autorisées ainsi que des mesures logiques comme la mise en place d’outils d’audit
des actions menées sur les données, le chiffrement des données, leur
pseudonymisation, leur sauvegarde régulière. Ces mesures logiques concernent la
gestion des données en base de données. Des mesures organisationnelles peuvent
être couplées aux mesures physiques et logiques en permettant aux employés
devant travailler sur une base de données comportant des données à caractère
personnel de consulter une version anonymisée de cette base ou bien en obtenant
des certifications telles que ISO 27001 ou « Hébergeur de données de santé ». La
21

sensibilisation des employés à la sécurité informatique est aussi une composante
essentielle de la sécurisation des données.
• Les droits à l’information, d’accès, de rectification, d’effacement, d’opposition,
de portabilité, à la limitation du traitement et le droit de ne pas faire l’objet
d’une décision fondée sur un traitement automatisé doivent être respectés.
Le droit à l’information permet à toute personne de connaître l’ensemble des droits
cités précédemment ainsi que d’être informé de la façon dont ses données sont
exploitées, stockées et de la raison justifiant la récupération de ses données. Ces
informations doivent être explicitées par le responsable de traitement en des termes
intelligibles et concis. Il peut être dérogé à ce droit si des efforts disproportionnés
sont nécessaires à sa communication ou que la récupération des données se fait
dans le cadre d’un loi nationale ou européenne.
Le droit d’accès permet à un individu de lire, contrôler et donc faire rectifier si
besoin les données le concernant en en faisant la demande au responsable de
traitement. Une copie des données doit lui être fourni ainsi que d’autres
informations comme par exemple la durée de conservation de ces données,
l’existence des différents droits, la finalité du traitement des données.
Le droit de rectification correspond au droit de pouvoir modifier ou compléter les
données collectées après y avoir accédé.
Le droit d’opposition peut être exercé à tout moment, en fournissant ou non un
motif de refus en fonction du traitement, afin d’empêcher le traitement des données
à caractère personnel.
Le droit d’effacement, aussi appelé droit à l’oubli, permet à un individu de
demander la suppression des données le concernant si celles-ci ne sont plus
nécessaires à la finalité du traitement, s’il retire son consentement ou si le
traitement des données mis en place n’est pas licite. A l’inverse, ce droit ne peut
être exercé s’il va à l’encontre de la liberté d’information, d’un objectif d’utilité
public ou d’une obligation légale.
Le droit de portabilité permet à un individu de récupérer les données le concernant
sous un format exploitable et structuré afin de les traiter ou de les transférer à un
autre organisme. On trouve donc les données directement transmises par l’individu
22

au moment du consentement au traitement des données mais aussi toutes les
données automatiquement générées lors du traitement.
Le droit à la limitation du traitement permet à un individu d’indiquer à l’organisme
auprès duquel il a exercé un des droits précédents de ne plus utiliser les données le
concernant durant le mois légal dont l’organisme dispose pour appliquer la
demande antérieure de l’individu.
Enfin, le droit de ne pas faire l’objet d’une décision fondée sur un traitement
automatisé permet à un individu de s’opposer à ce que ses données soient utilisées
dans un traitement entièrement automatisé. Ainsi, si par exemple l’activité d’un
salarié est analysée à travers un logiciel de saisie et que ce même logiciel décide de
refuser la prime de fin d’année à ce salarié au regard des données collectées, le
salarié peut exercer ce droit.
Pénalités prévues en cas de non respect du RGPD
Le RGPD est donc résolument tourné vers la protection des individus, de leur vie
privée. Le nom-respect des règles imposées par ce règlement peut entraîner une amende
allant jusqu’à 20 000 000 d’euros ou de 4 % du chiffre d’affaires si celui-ci dépasse la
somme précédemment citée. Le risque financier n’est cependant pas élevé seulement au
regard des sanctions pénales ; en effet, la prolifération des logiciels de type
« ransomware » à l’ère du RGPD n’est pas un hasard. Les individus malveillants à
l’origine de ces virus informatiques ont bien compris que les rançons demandées pour
débloquer des données cryptées par leur soin pouvaient exploser étant donné les amendes
mises en place par le règlement européen. Le 20 novembre 2019, le centre hospitalier de
Rouen a subi une attaque par ransomware lui réclamant près de 300 000€. Les délais de
prise en charge des patients ont été allongés mais l’affaire a été réglée. Il est cependant
essentiel de se rendre compte des possibles conséquences financières et humaines d’une
telle attaque : d’un côté, cette absence de données peut stopper l’activité d’un ou de
plusieurs services entraînant alors une importante perte de capital, de l’autre, les patients
ne reçoivent pas le service qui leur est dû. Le risque commercial et d’image est alors aussi
engagé, surtout lorsqu’il s’agit d’une entreprise du secteur privé qui subit une telle attaque.
23

Le risque d’une deuxième attaque imminente par une autre équipe est aussi important étant
donné la publication dans la presse de ce genre d’affaires.
Il ne faut pas non plus limiter l’application du RGPD aux clients de son organisme : il
concerne l’intégralité des personnes pour lesquelles on collecte des données, c’est à dire
dans tous les cas, les employés de l’entreprise ou de l’administration.
Enfin, il ne faut pas non plus seulement penser que l’essentiel des attaques vient de
l’extérieur. L’étude « A Study on Global Data Leaks in 2018 » menée par le centre
analytique d’InfoWatch estime à 63,5 % la proportion d’attaques internes à l’entreprise
menant à la fuite de données. Parmi ces données, 69,5 % sont des données à caractère
personnel. 83,9 % des fuites de données sont dues à un manque de connaissances de la part
du personnel des entreprises, conséquence directe d’un problème de sensibilisation à la
protection des données. On constate cependant un nette chute des fuites de données entre
2017 et 2018 qui semble indiquer que les personnes bien formées comprennent
l’importance de protéger les données.
I.2.B Application du RGPD aux bases de données relationnelles
La complexité et la complétude du RGPD font que chaque service d’une
organisation est concerné de près ou de loin par sa mise en place ou son respect. Ce
mémoire a pour but d’aborder le RGPD sous l’angle de la base de données relationnelle
MySQL. Ce travail étant réalisé dans le cadre d’un projet d’étude commun avec mon
employeur Tessi, seuls les aspects relevant de mon métier - l’exploitation des bases de
données et leur déploiement - seront abordés. Les raisons du choix de cette étude ainsi que
de son périmètre sont détaillés dans la partie suivante, traitant de l’application du RGPD
chez Tessi.
Un système de gestion de bases de données relationnelles (SGBDR) permet la gestion de
bases de données et donc le stockage de données à caractère personnel. C’est le cas chez
Tessi où divers SGBDR sont utilisés mais où MySQL est le plus représenté. MySQL, dans
sa version communautaire, n’est pas conforme au RGPD puisque les modules de
chiffrement, d’authentification ou d’audit par exemple ne sont pas présents ou complets.
Ces modules sont en effet seulement présents dans la version Enterprise de MySQL,
payante et soumise à une licence propriétaire. Dans un souci de cohérence avec l’outil de
supervision Percona mis en place chez Tessi mais aussi de coûts, le SGBDR étudié dans ce
24

mémoire en remplacement de MySQL sera Percona Server for MySQL. Percona Server for
MySQL est un SGBDR développé par la société Percona, basé sur MySQL, open source
(les sources du code sont disponibles), gratuit, soumis à la licence GNU GPL 2
et
regroupant l’ensemble des fonctionnalités présentes dans la version Enterprise de MySQL.
Percona Server for MySQL est totalement compatible avec MySQL : il suffit de modifier
le SGBDR en conservant les bases de données MySQL en place afin de le déployer. Il
s’agit en fait d’une copie conforme de MySQL Community Edition à laquelle différents
modules ont été ajoutés. Le choix de Percona Server for MySQL, au-delà de l’aspect
économique, est surtout pratique. En effet, le système de supervision des bases de données
MySQL mis en place chez Tessi est le logiciel développé par Percona : Percona Monitoring
and Management. J’ai déjà été amené à apporter des évolutions à ce logiciel de supervision
et c’est à ce titre que j’ai été pu animer une conférence au côté d’un ingénieur de chez
Percona en 2019, durant le Percona Live Europe à Amsterdam. Durant cette conférence,
j’ai présenté les modification que j’ai apportées à leur logiciel de supervision afin de
répondre aux besoins de maintien en condition opérationelle des bases de données de
production chez Tessi. De plus, je suis déjà en relation avec plusieurs développeurs de
Percona Server for MySQL, ce qui représente un gain de temps et une sécurité
supplémentaire pour le déploiement de ce SGBDR chez Tessi.
Certains aspects liés aux RGPD comme l’anonymisation et la pseudonymisation des bases
de données ne sont pas pris en charge (ou de façon peu efficace) par Percona Server for
MySQL. Il ne s’agit en effet pas de fonctionnalités propres à ce type de logiciel mais plutôt
de fonctions qui doivent être développées en interne dans les entreprises tant les besoins
peuvent être spécifiques aux données recueillies ainsi qu’à l’architecture des bases de
données mises en place. Il est cependant possible d’utiliser des outils en amont du SGBDR,
des proxys, afin de réaliser ces opérations : ProxySQL sera étudié dans ce mémoire. Grâce
à mes relations chez Percona, j’ai aussi obtenu le contact de développeurs chez ProxySQL
afin de garantir l’exactitude de cette étude.
Enfin, la problématique de la purge des données ne sera pas abordée dans ce mémoire
puisqu’il s’agit tout d’abord d’une opération techniquement simple à effectuer mais aussi
parce qu’elle s’inscrit selon moi dans le développement d’un produit et pas dans le
2 La licence GPL (GNU General Public License) permet d’utiliser un logiciel pour un usage domestique
ou commercial et donne accès au code source de celui-ci. Cette licence permet de modifier le logiciel si
besoin mais oblige la publication des apports ajoutés afin de respecter la politique« open source »
appliquée à celui-ci.
25

déploiement d’un SGBDR. Il s’agit en effet de jouer des instructions SQL « DELETE »
tout en appliquant les filtres « WHERE » correspondant au besoin de suppression des
données. Imaginons par exemple qu’il est nécessaire pour une entreprise de vente en ligne
de supprimer tous les utilisateurs n’ayant passé aucune commande sur la plateforme depuis
un an. En base de données, une table « utilisateurs » est présente et comporte différentes
champs identifiant la personne (nom, prénom, date de naissance, adresse) ainsi que la date
de la dernière commande effectuée. La requête permettant la suppression de ces utilisateurs
sera alors :

Il faudra ensuite automatiser l’exécution quotidienne de cette requête en alimentant
parexemple la table de planification du système d’exploitation ou le gestionnaire d
’évènementMySQL prévu à cet effet.
Le but de ce mémoire est de pouvoir fournir à l’ensemble des équipes utilisant MySQL
chez Tessi une solution « clé en main » permettant la mise en adéquation des bases de
données avec le RGPD. Il ne m’est pas possible de généraliser la notion de purge tant elle
peut différer d’un produit à l’autre mais aussi d’un client à l’autre. Il est aussi essentiel de
permettre au service développant les logiciels de rester impliqué dans l’application du
RGPD au niveau des bases de données.
I.3 Le RGPD chez Tessi
Confidentiel

II Présentation de l’environnement d’étude
Percona Server for MySQL, aussi appelé Percona Server dans la suite de ce
mémoire, est un SGBDR basé sur la branche open source de MySQL et apportant des
modifications fonctionnelles à MySQL Community Edition. Le terme MySQL désignera
désormais dans ce mémoire la technologie interne au SGBDR et non le SGBDR lui même.
Afin d’éviter toute confusion, dès lors que l’on évoquera une spécificité d’un SGBDR, son
nom complet sera renseigné.
II.1 Serveur utilisé pour l’étude
Durant toute cette étude, un serveur hébergé dans un des centres informatiques de
Tessi sera utilisé. Il s’agit d’une machine virtuelle comportant deux vCPU3
et 4 Go de
Ram. Le système d’exploitation installé est un système Linux, Ubuntu Server 16.04.
II.2 Base de données utilisée pour l’étude
Afin de réaliser différents tests dans ce mémoire, une base de données mise à
disposition publiquement sera utilisée. Il s’agit d’une base de données bien connue des
utilisateurs de MySQL : la base « employees ». Cette base de données, décrite dans la
documentation MySQL, comporte six tables dont une contient des informations à caractère
personnel : la table « employees ». Il s’agit évidemment de données fictives. Le détail de la
structure de cette base de données se trouve en Annexe 1. Cette base de données modélise
une organisation dans laquelle des employés ont un rôle, un salaire et appartiennent à un
département de l’entreprise dirigé par un manager. Pour des besoins liés aux tests de
performances réalisés plus loin dans ce mémoire, des entrées ont été ajoutées à cette base
de données, notamment à la table « employees » qui comporte désormais un million
d’individus.
II.3 Configuration de l’instance Percona Server réalisée pour l’étude
La base de données « employees » a été déployée sur une instance MySQL
Community Edition 8.0.18 (avant-dernière version sortie au moment de la rédaction de ce
3 Virtual Central Processing Unit : portion définie d’un processeur physique apparaissant comme étant un
processeur à part entière du point de vue du système d’exploitation de la machine virtuelle
30

mémoire) afin de valider la facilité d’installation et la compatibilité de Percona Server avec
cette base de données déjà présente. La version 8.0.18-94
de Percona Server a alors été
déployée en lieu et place de MySQL en conservant le même chemin (datadir) pointant vers
le dossier contenant la base de données. Il n’y a eu aucun problème d’incompatibilité et
aucune particularité d’installation, c’est pourquoi ce déploiement ne sera pas détaillé dans
ce mémoire.
La configuration de l’instance variera en fonction des besoins et des éléments à mettre en
avant dans cette étude. Ainsi par exemple, il sera indiqué à Percona Server de n’utiliser
qu’une quantité infime de Ram pour maintenir les données lorsque le but du test consistera
à observer le comportement du disque dur.
4 Dernière version de Percona Server for MySQL lors de la rédaction de ce mémoire. 8.0.18 indique la
version de MySQL sur laquelle s’est basé Percona et 9 renseigne le numéro de version de Percona Server
for MySQL basé sur une version 8.0 de MySQL
31

III Mise en place du chiffrement des données
III.1 Intérêt du chiffrement des bases de données
Le chiffrement est un procédé cryptographique permettant de rendre illisibles les
données à toute personne ne possédant pas la clé de déchiffrement. Les SGBDR MySQL
Community Edition ou Percona Server ne chiffrent pas par défaut les données. Il faut ici
bien distinguer les chiffrements logiques et physiques :
- le chiffrement logique consiste à appliquer un algorithme de chiffrement au moment de
l’insertion des données ou de leur modification. Ainsi, l’affichage des données lors d’une
requête en base de données renverra des données chiffrées qui nécessiteront l’appel à la
fonction de déchiffrement pour être lues. Ce chiffrement n’est donc pas transparent pour
les utilisateurs qui devront appliquer une modification aux données pour pouvoir les lire.
- le chiffrement physique des bases de données consiste à appliquer un algorithme de
chiffrement afin de chiffrer les fichiers contenant les bases de données stockées sur disque.
Le but est donc d’empêcher toute personne ayant accès au serveur sur lequel l’instance est
installée de pouvoir lire directement les fichiers stockés sur les disques durs. Ce
chiffrement est transparent pour les utilisateurs de la base de données.
- le chiffrement physique des disques durs consiste à chiffrer entièrement un disque dur et
ainsi permettre de sécuriser les données y étant stockées en cas de vol de ce disque.
Le chiffrement permet donc de ne pas pouvoir lire une donnée sans posséder la clé de
déchiffrement adéquate. Les différences entre chiffrement physique et logique sont très
importantes : le chiffrement physique des disques durs ne permettra de se protéger que
contre un individu qui aurait accès au centre informatique et volerait les disques durs : il
s’agit donc de la méthode la moins efficace en cas d’attaque à distance. Au contraire, le
chiffrement logique permet d’assurer la sécurité des données, que l’attaque soit orchestrée
sur le matériel physique ou sur les données qu’il contient. Cependant, il n’est pas toujours
simple et performant de modifier le code d’une application afin de lui permettre de
déchiffrer l’ensemble des données stockées dans une table. Le chiffrement physique des
bases de données constitue quant à lui une alternative intéressante se situant entre les deux
méthodes citées précédemment : un attaquant ayant accès au serveur que ce soit en
personne dans la salle informatique ou à distance ne pourra lire les données stockées.
32

Cependant, si cet attaquant possède un compte lui permettant d’accéder à la base de
données, il pourra lire les données sans difficulté. Cette approche doit donc forcément être
couplée à des mesures d’authentification fortes et des modules permettant la traçabilité des
actions entreprises en bases de données ; ces points seront abordés plus tard dans ce
mémoire. C’est cette dernière méthode de chiffrement qui sera étudiée dans ce mémoire.
Les données ne sont cependant pas seulement présentes sur les disques durs des serveurs
mais transitent sur la machine par l’intermédiaire de la RAM ou bien d’une application
vers le SGBDR et vice versa par l’intermédiaire du réseau. Cette deuxième partie de
mémoire va donc se pencher sur le chiffrement des données et leur sécurisation tout au
long de leur cycle de vie.
III.2 Emplacement des données et nécessité du chiffrement
Dans ce mémoire, le moteur de stockage innodb sera étudié. Il s’agit en effet du
seul moteur de stockage fourni par MySQL étant ACID. Les propriétés d’un système ACID
sont les suivantes :
- Atomicité : la donnée est soit entièrement insérée en base de données, soit ne l’est pas du
tout. On ne peut pas trouver dans une table utilisant le moteur de stockage innodb une
donnée incomplète du fait d’une panne de réseau ou d’un composant de la machine
hébergeant le SGBDR.
- Cohérence : toute modification de la base de données conservera l’intégrité de cette base
et ne pourra entraîner de panne empêchant le bon déroulement des prochaines actions.
- Isolation : chaque interrogation de la base de données doit pouvoir fournir un résultat
indépendamment des autres transactions exécutées en parallèle.
- Durabilité : la durabilité assure le stockage permanent des données.
L’ensemble de ces propriétés est nécessaire au stockage des données à caractère personnel
puisqu’il permet par son mécanisme d’assurer l’exactitude des données au regard des
insertions, modifications et suppressions qui sont faites par les applications ou utilisateurs.
33

Le moteur de stockage innodb est de plus le moteur de stockage privilégié pour les bases
de données MySQL puisqu’il s’agit du moteur défini par défaut lors de la création d’une
table. C’est le moteur de stockage utilisé dans les bases de données Tessi.
Le moteur de stockage innodb nécessite différents fichiers présents à différents
emplacement du système pour fonctionner. Ainsi, on retrouvera aussi bien des données en
Ram (« In-Memory Structures » sur la Figure 4) que sur disque dur (« On-Disk
Structures » sur la figure 4), dans des fichiers de stockage que dans des fichiers de
fonctionnement interne au moteur.
III.2.AEmplacement des données sur disque dur
Dans une base de données MySQL, on retrouve les données stockées dans le
dossier défini par la variable datadir du fichier de configuration. Si la variable
innodb_file_per_table est initialisée à 1, chaque table possédera un fichier physique
contenant ses données à l’intérieur d’un dossier portant le nom de la base de données. Si la
variable innodb_file_per_table est initialisée à 0, toutes les données seront placées dans un
seul fichier physique, placé directement à la racine du datadir, et mêlant les données de
l’ensemble des tables de toutes les bases de données. Tessi, suivant les conseils d’Oracle et
34
Figure 6: Schéma montrant la structure interne nécessaire au fonctionnement
du moteur de stockage innodb

de Percona, a choisi de conserver l’initialisation de cette variable à 1, qui est le paramètre
par défaut configuré pour les SGBDR MySQL (Community et Enterprise) et Percona
Server. Cette configuration des instances MySQL permet aussi le maintien des
performances dans le temps grâce à la possibilité de mise en place d’opérations de
maintenance régulières et peu coûteuses en temps. Ces opérations de maintenance
permettent, entre autres, de récupérer l’espace disque libéré par les processus de purge des
données demandées par le RGPD. C’est pour ces raisons que dans la suite de ce mémoire,
chaque table se verra affectée à un fichier physique distinct.
Ainsi, voici la structure physique de la base de données employees :
Ici, « /mnt/db/mysql » correspond au datadir, « employees » au dossier de la base de
données.
Ces fichiers ne sont pas chiffrés par défaut et, même s’ils ne sont pas dans un format
exploitable facilement (format binaire), ils laissent apparaître certaines données à toute
personne se connectant au serveur et disposant des droits suffisants pour les lire.
Ce qui est encore plus problématique avec cette méthode de fonctionnement est qu’il est
possible de récupérer l’intégralité du contenu du datadir afin de le copier sur un autre
serveur et d’indiquer à un nouveau SGBDR du même type (MySQL Server, Percona
Server) d’utiliser ce dossier comme datadir. Les données seront alors accessibles depuis un
35
> ls /mnt/db/mysql/employees
titles.ibd
salaries.ibd
employees.ibd
dept_manager.ibd
dept_emp.ibd
departments.ibd
Figure 7: Image montrant une partie du contenu du fichier employees.ibd et laissant apparaître
quelques prénoms présents dans cette table.

autre serveur et pourront être analysées en détail physiquement et même accédées en
totalité de façon efficace puisqu’il sera possible de créer son propre utilisateur ayant les
habilitions nécessaires pour s’authentifier dans ce nouveau SGBDR.
Des données peuvent aussi être présentes au niveau des « undo tablespaces » qui sont des
espaces dédiés permettant le retour en arrière sur les modifications effectuées en base de
données par une transaction. A la fin d’une transaction SQL, il est en effet possible
d’effectuer un « ROLLBACK » afin d’annuler les actions entreprises. Il est facile de se
rendre compte de ce fonctionnement en exécutant une transaction sans la conclure par la
commande ‘COMMIT’, indiquant à MySQL de réaliser les écritures demandées :
Ici, dans l’ordre nous demandons :
1) une mise à jour des nom et prénom de l’employé numéro 1 000 000. Il s’appellera
désormais Valentin TRAEN. Sur cette instance, la variable autocommit a été laissée à 1.
Cela signifie que sans indication explicite de début de transaction (START
TRANSACTION), l’instruction COMMIT est automatiquement envoyée au SGBDR qui
applique la modification en l’écrivant sur le disque dur.
2) le démarrage d’une nouvelle transaction qui nécessitera d’être validée par l’instruction
COMMIT ou annulée par l’instruction ROLLBACK.
3) une mise à jour du prénom de l’employé 1 000 000 : il s’appellera désormais Jon
TRAEN.
36
mysql> UPDATE employees SET first_name = 'Valentin', last_name = 'TRAEN' WHERE
emp_no = 1000000;
Query OK, 1 row affected (0,00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)
mysql> UPDATE employees SET first_name = 'JON' WHERE emp_no = 1000000;
mysql> UPDATE employees SET first_name = 'JOE' WHERE emp_no = 1000000;
mysql> UPDATE employees SET last_name = 'DOE' WHERE emp_no = 1000000;

4) une mise à jour du prénom de l’employé 1 000 000 : il s’appellera désormais Joe
TRAEN.
5) une mise à jour du nom de l’employé 1 000 000 : il s’appellera désormais Joe DOE.
Aucune validation ou annulation de opérations n’a été demandée. L’ensemble de ces
modifications sont donc visibles dans l’ « undo tablespace » :
On constate dans l’ordre que MySQL sauvegarde le prénom de l’employé, puis sa
deuxième version et enfin le nom. Le SGBDR conserve en fait la dernière version de la
valeur de la donnée modifiée juste avant chaque requête de modification. Il sera alors
possible pour le SGBDR de rejouer les modifications « à l’envers » si jamais la transaction
« ROLLBACK » est demandée. On peut aussi notifier la présence plus haut dans le fichier
(non visible sur la Figure 6) du nom d’utilisateur MySQL utilisé pour réaliser ces
opérations.
Il en va de même pour les « redo logs » permettant d’assurer l’exécution des transactions
SQL qui n’ont pas pu aboutir du fait d’un crash serveur lors du redémarrage de l’instance.
Ainsi, si une requête d’insertion est jouée sur le serveur :
37
Figure 8: Fragment de l'"undo tablespace" après exécution d'une transaction non
validée ou annulée
mysql> INSERT INTO employees VALUES (20000010,'1990-01-
01','TEST_PRENOM','TEST_NOM','M','2010-01-01');

On retrouve ces informations dans les « redo logs » :
Les logs binaires comportent l’ensemble des opérations modifiant les données (INSERT,
UPDATE ou DELETE) effectuées sur la base de données. Ils permettent le retour arrière de
l’ensemble des transactions et aussi l’analyse des opérations ayant entraîné la modification
d’une donnée. Les logs binaires peuvent aussi être utilisés dans le cas d’instances MySQL
répliquées afin de transmettre les changements appliqués sur l’instance maître, « master »
aux instances esclaves, « slaves ». La possibilité de chiffrer les logs binaires est offerte par
Percona Server for MySQL mais pas par MySQL Community Edition ou Enterprise.
On retrouve les informations de la précédente insertion dans le log binaire :
38
Figure 10: Extrait des logs binaires montrant les nom et prénom de l'employé inséré en
base de données
Figure 9: Extrait des "redo logs" montrant les nom et prénom de l'employé inséré en
base de données

Lors de l’exécution de transactions nécessitant une étape intermédiaire de tri ou
d’association de données, une table temporaire est automatiquement créée dans le dossier
dédié #innodb_temp. Comme leur nom l’indique, ces tables temporaires sont aussi créées
en utilisant le moteur de stockage innodb et leur sécurisation est donc nécessaire si elles
permettent le traitement de données à caractère personnel. La possibilité de chiffrer les
tables temporaires est offerte par Percona Server for MySQL mais pas par MySQL
Community Edition ou Enterprise.
L’exécution d’une requête d’union, par exemple, requiert l’utilisation d’une table
temporaire. Après l’exécution de cette requête,
nous retrouvons bien les informations contenues dans la table employees au sein d’un
fichier permettant le stockage des tables temporaires :
III.2.B Maintien des données en Ram
Un SGBDR tire toute son efficacité de l’utilisation qu’il fait de la RAM dont il
dispose. En effet, un des buts premiers de ce type de logiciel, au-delà des possibilités qu’il
39
mysql> (SELECT * FROM employees) UNION (SELECT * FROM employees);
Figure 11: Extrait d'une table temporaire laissant apparaître des données personnelles
en clair

apporte en termes de stockage, est de permettre la lecture des données de manière très
rapide, presque instantanée. Pour ce faire, la RAM est essentielle puisqu’il s’agit
aujourd’hui du composant informatique le plus rapide permettant de stocker une quantité
importante de données. Sa volatilité l’empêche cependant d’être un concurrent sérieux
concernant le stockage permanent des données. Le SGBDR doit donc savoir « jongler »
intelligemment entre les disques durs et la Ram afin de répondre aux besoins de stockage
et d’accessibilité des données. Le moteur de stockage innodb utilise une mémoire tampon
en Ram afin de répondre à ce besoin de récupération rapide des données : l’« innodb buffer
pool ».
Il est courant de dire que l’« innodb buffer
pool » permet le maintien en Ram des
données utiles à l’application, c’est à dire les
données les plus souvent interrogées. On
imagine donc que certaines parties de
certaines tables apparaissent en clair si on lit
ce que contient la Ram et qu’il est alors
nécessaire de protéger son accès. Le
mécanisme est en fait un peu différent.
L’« innodb buffer pool » ne maintient en
réalité que des index qui pointent vers
certaines pages disque servant au stockage
des données sur disque dur. On y retrouve aussi bien les index B-tree5
créés manuellement
pour optimiser les requêtes que les « clustered index », utilisés pour trier physiquement les
données en se basant sur la clé primaire de la table. Ces index ne sont cependant pas
exploitables puisqu’ils ne renseignent pas directement sur les données et sont uniquement
interprétables par le SGBDR. Ce buffer ne requiert donc pas d’attention particulière quant
à son chiffrement dans le cadre du traitement de données à caractère personnel.
Enfin, il est utile de préciser que l’on peut aussi retrouver les tables temporaires
précédemment évoquées en Ram en fonction de la configuration appliquée à l’instance
MySQL. Celles-ci utilisent cependant le moteur de stockage MEMORY ou TEMPTABLE
5 Un arbre B (B-tree) est une structure d’index permettant le stockage de liens vers les données sous forme
triée afin de faciliter les opérations de recherche en base de données. Cette structure se présente sous
forme d’arbre où chaque feuille indique la plage de données présentes dans les feuilles du niveau
inférieur.
40
Figure 12: Image montrant un fragment
d'innodb buffer pool

(et non le moteur de stockage innodb comme les tables temporaires stockées sur disque)
qui ne font pas partie de l’objet d’étude de ce mémoire. Il s’agit cependant du
fonctionnement « normal » d’une instance MySQL qui utilisera la Ram qui lui est allouée
pour réaliser ce genre d’opérations et n’aura besoin du disque dur que dans le cas où la
taille de la table temporaire dépassera cette allocation mémoire.
III.2.C Échange de données à travers le réseau
Les SGBDR basés sur MySQL utilisent la typologie client-serveur. La base de
données est présente sur un serveur et sera interrogée ou alimentée par un logiciel client,
présent ou non sur la même machine. Un échange de données se fait donc et il est
nécessaire de s’assurer que celles-ci ne circulent pas en clair entre les applications afin que
toute interception de ces données ne soit pas problématique. Par défaut, Percona Server
chiffre les transferts de données.
41
Figure 13: Capture d'écran montrant le chiffrement utilisé par défaut par Percona
Server for MySQL

Le protocole utilisé pour les échanges de données est TLS et on constate que la suite de
chiffrement6
utilisée par défaut est ECDHE-RSA-AES128-GCM-SHA256. Les clients
MySQL développés par Oracle et par Percona sont tous deux compatibles avec l’utilisation
de ce chiffrement. Ainsi, toute trame réseau échangée entre le client et le serveur est
chiffrée :
Attention cependant : le serveur autorisera tout de même les échanges non chiffrés si le
client ne permet pas ce chiffrement. En effet, la variable require_secure_transport
indiquant l’obligation ou non de communiquer à travers un canal chiffré est initialisée à
« faux » par défaut.
6 Une suite de chiffrement permet au client et au serveur de s’entendre sur une méthode d’échange
sécurisée. On y retrouve dans l’ordre : le protocole d’échange de clés de chiffrement entre le client et le
serveur, la méthode d’authentification utilisée par le serveur et le client afin de se reconnaître,
l’algorithme de chiffrement par bloc utile au chiffrement des flux et l’algorithme de code
d’authentification utilisé pour créer une empreinte de chaque bloc afin d’en vérifier l’intégrité.
42
Figure 14: Fragment de trame réseau chiffrées d'échange entre un client MySQL et le serveur
Percona Server for MySQL

Il est donc tout à fait possible d’utiliser une connexion non chiffrée qui laissera apparaître
les données dans les trames :
Il n’est pas nécessaire d’aller plus loin concernant le chiffrement réseau des données dans
ce mémoire. Il est évident qu’afin d’assurer la sécurité des échanges de données, la
variable require_secure_transport doit être initialisée à 1 lors du déploiement de l’instance
Percona Server. La difficulté réside ensuite au niveau du service développant les logiciels
interrogeant les bases de données qui doit s’assurer que les connecteurs utilisés chiffrent
bien les trames réseau.
43
Figure 15: Fragment de trame réseau non chiffrées d'échange entre un client MySQL et le serveur
Percona Server for MySQL

Ainsi, voici par exemple comment forcer la sécurisation des échanges avec le connecteur
PHP Data Objects (PDO) :
III.3 Mise en place du chiffrement des données innodb avec Percona
Server for MySQL
Le chiffrement transparent des données, appelé TDE pour Transparent Data
Encryption, est un mécanisme permettant la sécurisation des données sur disque. Il s’agit
en fait d’un chiffrement physique de certains fichiers générés et utilisés par un SGBDR. Ce
type de chiffrement protège donc les données de toute attaque physique au niveau du
serveur ou au niveau du système d’exploitation. Il reste cependant transparent pour les
utilisateurs de la base de données et devra donc être couplé avec une politique de sécurité
efficace afin de limiter le risque concernant les fuites de données. MySQL et Percona
Server utilisent la technologie TDE afin de chiffrer les fichiers innodb. Pour ce faire, une
architecture à deux niveaux est utilisée :
- Une clé de chiffrement principale, appelée « master key » permet le chiffrement d’une
deuxième clé de chiffrement propre à chaque fichier du SGBDR.
- C’est cette deuxième clé qui sert au chiffrement des fichiers du SGBDR.
Nous parlerons désormais de clé maîtresse pour désigner la « master key » et de clés
secondaires pour désigner les clés propres aux différents éléments du SGBDR. Lorsque
l’on chiffre des données, la sécurisation de la méthode de chiffrement est aussi importante
44
<?php
$servername = "hostname_mysql";
$username = "utilisateur_mysql";
$password = "motdepasse_mysql";
$options = array(
// clé client
PDO::MYSQL_ATTR_SSL_KEY =>'/certificats_mysql/client-key.pem',
// certificat client
PDO::MYSQL_ATTR_SSL_CERT=>'/certificats_mysql/client-cert.pem',
// certificat autorité de certification
PDO::MYSQL_ATTR_SSL_CA =>'/certificats_mysql/ca-cert.pem',
// suite de chiffrement préférée
PDO::MYSQL_ATTR_SSL_CIPHER => 'ECDHE-RSA-AES128-GCM-SHA256’
);
$conn = new PDO("mysql:host=$servername;port=3306;dbname=db_name", $username,
$password, $options);
?>

que les données elles-mêmes. En effet, s’il est aisé pour un attaquant de récupérer la
méthode lui permettant de déchiffrer des données, l’intérêt de ce chiffrement est nul.
En ce qui concerne la clé maîtresse, celle-ci peut être gérée de deux façons différentes :
- elle peut être stockée sur disque grâce au plugin MySQL « keyring_file ». Attention
cependant : il ne s’agit pas d’une méthode de stockage de la clé viable en production
puisqu’elle pourra facilement être récupérée par un attaquant. Il s’agit de la seule option
disponible dans MySQL Community Edition
- elle peut être stockée et gérée par un coffre de clés, un key-vault. Percona Server permet
l’utilisation du key-vault développé par la société HashiCorp, gratuit, open source, publié
sous licence Mozilla Public License 2.07
. Ce coffre fonctionne selon la typologie client-
serveur. Le serveur permet le stockage et le verrouillage des clés qui y sont stockées grâce
à des procédés de sécurisation avancés. Le client, ici le plugin MySQL « keyring_vault »,
obtient le droit de déverrouillage du coffre et communique avec lui grâce à un flux sécurisé
https. Hashicorp Vault peut aussi bien être installé localement sur la machine hébergeant
l’instance MySQL que sur un serveur distant. Il s’agit de la méthode à privilégier dans un
environnement de production.
Quel que soit le mode de gestion de la clé maîtresse utilisé, MySQL ne l’écrira jamais sur
disque lorsqu’il la récupérera au démarrage de l’instance : la clé sera maintenue en Ram
afin de déchiffrer les différentes clés secondaires.
Les clés de chiffrement secondaires sont les clés permettant le chiffrement des fichiers sur
disque. Chaque fichier relatif à une table configurée comme devant être chiffrée obtient sa
propre clé secondaire unique qui permettra son déchiffrement. Ces clés sont stockées sous
forme chiffrée par la clé maîtresse au niveau de la première page disque attribuée à chaque
fichier. Ainsi, même si cette première page est lisible par un attaquant, il ne verra qu’une
forme chiffrée de la clé secondaire.
7 La licence Mozilla Public License (MPL) 2.0 permet les mêmes droits que la licence GNU GPL. Elle
n’oblige cependant pas à la publication complète des sources du logiciel utilisant des parties modifiées
d’un code source soumis à cette licence mais seulement les modifications apportées. C’est cette licence
qui permet l’obtention de logiciels « hybrides » dont certaines parties du code sources sont publiées
puisque modifiées ou tirées de sources soumises à licence MPL et d’autres sont propriétaires.
45

Ce type d’architecture a plusieurs avantages. Il est possible de mettre en place une rotation
de la clé maîtresse afin de limiter le risque de compromission de celle-ci. Cette rotation
sera alors quasiment transparente pour tous les fichiers du SGBDR puisque seules les
premières pages disques de chacun seront mises à jour afin d’y stocker la nouvelle version
chiffrée de la clé secondaire. Il n’est alors pas nécessaire pour le SGBDR de relancer
l’opération de chiffrement des données, risquée et coûteuse en temps. Cette rotation d’une
clé unique permet aussi la mise en place d’une politique de sécurité efficace et simple à
mettre en œuvre.
Voyons maintenant comment mettre en place ce chiffrement des fichiers innodb. Au niveau
de l’instance, il est nécessaire d’installer le module permettant la gestion de la master key :
« keyring_file » ou « keyring_vault » :
46
Figure 16: Schéma montrant l'échange de clé opéré par Percona Server lors
de l'utilisation de la technologie TDE
mysql> INSTALL PLUGIN keyring_vault SONAME 'keyring_vault.so';
mysql> INSTALL PLUGIN keyring_file SONAME 'keyring_file.so';

Il faut ensuite indiquer à l’instance d’utiliser le module choisi à son démarrage.
Si on utilise « keyring_file » :
Si on utilise « keyring_vault » :
Une fois cette configuration faite, quel que soit le module choisi, les manipulations au sein
du SGBDR restent les mêmes. Créons une nouvelle table « employees_encrypt », chiffrée,
et chargeons-y les mêmes utilisateurs que dans la table « employees » :
47
#module à charger au démarrage
early-plugin-load=keyring_file.so
#emplacement de la clé
keyring_file_data=/usr/local/mysql/mysql-keyring/keyring
#module à charger au démarrage
early-plugin-load=keyring_vault.so
#fichier de configuration du vault renseignant son adresse, le token utilisé pour s’identifier et
l’emplacement de stockage de la clé
loose-keyring_vault_config=/etc/mysql/mysql.conf.d/keyring_vault.conf
mysql> CREATE TABLE èmployees_encrypt` (
-> èmp_no` int(11) NOT NULL,
-> `birth_date` date NOT NULL,
-> `first_name` varchar(32) DEFAULT NULL,
-> `last_name` varchar(32) DEFAULT NULL,
-> `gender` enum('M','F') NOT NULL,
-> `hire_date` date NOT NULL,
-> PRIMARY KEY (èmp_no`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
ENCRYPTION='Y';
Query OK, 0 rows affected, 1 warning (0,02 sec)
mysql> INSERT INTO
employees_encrypt(emp_no,birth_date,first_name,last_name,gender,hire_date) SELECT
emp_no,birth_date,first_name,last_name,gender,hire_date FROM employees;
Records: 1000000 Duplicates: 0 Warnings: 0

Ici, c’est l’ajout de la commande « ENCRYPTION=’Y’ » qui indique que les données de
cette table devront être chiffrées. La lecture du fichier .ibd sur disque ne laisse désormais
plus apparaître les données :
Il convient maintenant de s’interroger sur le type de clés utilisé pour mettre en place cette
architecture. Il est possible de récupérer l’identifiant de la master key générée au moment
de la mise en place du chiffrement de la première table innodb dans la base de données
« performance_schema » :
Il s’agit évidemment d’un identifiant de clé et pas de la clé elle-même. Cet identifiant est
composé ainsi : INNODBKey–[Identifiant du serveur]–[Numéro de clé Innodb générée].
On apprend donc qu’il s’agit de la première master key générée afin de protéger les
données des tables innodb du serveur a23a5098-4d73-11ea-8914-005056ae4270.
48
Figure 17: Image montrant une partie du contenu du fichier employees_encrypt.ibd
mysql> SELECT KEY_ID FROM performance_schema.keyring_keys;
+--------------------------------------------------+
| KEY_ID |
+--------------------------------------------------+
| INNODBKey-a23a5098-4d73-11ea-8914-005056ae4270-1 |
+--------------------------------------------------+

Si une rotation de clé maîtresse est engagée afin de limiter les possibilités de corruption de
la master key précédente, voici l’id de clé généré :
Le dernier identifiant de clé est alors utilisé par innodb.
Différentes informations comme cet identifiant, l’algorithme de chiffrement utilisé, la taille
de la clé et la clé elle-même sont conservées par le plugin de gestion des clés et sont
chargées en mémoire au démarrage de l’instance. Une analyse approfondie de la Ram a été
menée durant cette étude afin de vérifier qu’il n’était pas possible de récupérer la clé
maîtresse par ce moyen, cela semble bien être le cas. En effet, cette donnée est maintenue
dans un segment mémoire privé (réservé au processus) qui ne peut être lu :
Ici, ces informations sont présentes dans le segment numéroté 7f423b201000-
7f423b400000. Le fait de maintenir ces informations en Ram, volatile, présente cependant
des limites. En effet, en cas d’utilisation d’un coffre de clés situé sur un autre serveur, il est
essentiel de s’assurer de la présence de ce coffre au moment du démarrage de l’instance :
en effet, celle-ci ne pouvant récupérer la master key, toutes les tables chiffrées ne pourront
être lues ou modifiées. Il en va de même en cas de suppression du fichier contenant la clé
si le plugin « keyring_file » est utilisé. La méthode de vérification de la présence de la
master key est décrite plus loin.
49
mysql> ALTER INSTANCE ROTATE INNODB MASTER KEY;
mysql> SELECT KEY_ID FROM performance_schema.keyring_keys;
+--------------------------------------------------+
| KEY_ID |
+--------------------------------------------------+
+--------------------------------------------------+
7f423b1de000-7f423b201000 r-xp 00000000 fc:00 138830 /usr/lib/mysql/plugin/keyring_file.so
7f423b201000-7f423b400000 ---p 00023000 fc:00 138830 /usr/lib/mysql/plugin/keyring_file.so
7f423b400000-7f423b401000 r--p 00022000 fc:00 138830 /usr/lib/mysql/plugin/keyring_file.so
7f423b401000-7f423b402000 rw-p 00023000 fc:00 138830 /usr/lib/mysql/plugin/keyring_file.so

La clé secondaire chiffrée est quant à elle présente dans l’entête chiffrée du fichier innodb
qui est organisé ainsi :
Numéro de master key utilisé
Identifiant du serveur
Chiffrement de la clé secondaire
Somme de contrôle CRC32 de la clé secondaire
Le seul algorithme de chiffrement supporté par MySQL pour la mise en place de la TDE
est AES : c’est donc celui-ci qui permet le chiffrement et déchiffrement des fichiers et clés
secondaires déjà évoqués. Les modes d’opération de chiffrement diffèrent cependant entre
celui des fichiers et celui des clés secondaires :
- ECB est utilisé pour chiffrer les clés secondaires
- CBC pour les données.
L’ensemble de ces notions cryptographiques sont détaillées en Annexe 2.
Les clés ont une taille de 256 bits. Le stockage de la somme de contrôle permet au
SGBDR, au moment du déchiffrement de la clé secondaire, de vérifier qu’elle est bien
conforme et donc que la bonne master key a été utilisée. Cette vérification de la cohérence
de la master key est nécessaire lors du démarrage de l’instance MySQL. Grâce aux
numéros de master key et à l’identifiant du serveur, l’identifiant de la master key est
reconstitué ; celle-ci peut alors être récupérée depuis le plugin utilisé et permet le
déchiffrement de la clé secondaire. Si les sommes de contrôle calculées lors du
déchiffrement de la clé et stockées dans l’entête correspondent, la table est marquée
comme saine et accessible ; si ce n’est pas le cas, la table n’est pas accessible. Ainsi, si on
simule une rupture réseau entre Hashicorp Vault et Percona Server lors d’un démarrage,
voici ce qui apparaît dans les journaux de démarrage :
50
[ERROR] [MY-012226] [InnoDB] Encryption information in datafile:
./employees/employees_encrypt.ibd can't be decrypted, please confirm the keyfile is match and
keyring plugin is loaded.

Et on ne peut évidemment plus lire les données de la table :
En cas de ralentissement réseau, il est possible d’indiquer à Percona Server for MySQL
une valeur de temps d’attente de réponse plus importante du coffre fort de clés grâce à la
variable « keyring_vault_timeout ».
III.4 Analyse des performances de Percona Server for MySQL après
chiffrement des données innodb.
Dans cette partie, des tests comparatifs de performance vont être présentés entre
une instance Percona Server for MySQL dans laquelle la table employees est chiffrée et
une autre instance dans laquelle la table employees n’est pas chiffrée. Ces deux instances
ont été configurées comme suit afin de limiter au maximum le maintien en mémoire des
données :
Ainsi, l’exécution des requêtes nécessitera l’ouverture des fichiers innodb et donc le
déchiffrement ou non des données. Il a aussi été indiqué à ces instances de limiter au
maximum la taille des tables temporaires en mémoire afin de comparer les temps de
réponse des requêtes nécessitant l’écriture de tables temporaires innodb sur disque :
51
mysql> select * from employees.employees_encrypt;
ERROR 3185 (HY000): Can't find master key from keyring, please check in the server log if a
keyring plugin is loaded and initialized successfully.
#Taille minimum configurable du buffer pool
innodb_buffer_pool_size=5242880
#Définition du moteur de stockage temporaire à utiliser en Ram
internal_tmp_mem_storage_engine=TempTable
#Taille maximale configurable des données en Ram
temptable_max_ram=2097152
#Utilisation d’innodb quand la valeur de temptable_max_ram est dépassée
temptable_use_mmap=0

Le chiffrement des tables temporaires a d’ailleurs été demandé sur l’instance concernée :
L’outil utilisé afin de mesurer le temps d’exécution des requêtes est « mysqlslap ». Ce
logiciel de diagnostic fourni avec MySQL permet de simuler des clients MySQL, de les
faire interroger une instance MySQL et d’enregistrer les temps d’exécution de requêtes.
Voici le scénario de tests joué :
III.4.AInsertion des données
5000, 10000, 20000, 30000, 40000, 500000, 60000, 70000, 80000, 90000, 100000,
200000 et 300000 requêtes d’insertion dans la table employees (préalablement vidée)
seront respectivement exécutées. Le but de ce test est de mesurer le temps d’écriture des
52
#Chiffrement des tables temporaires innodb
innodb_temp_tablespace_encrypt=1
Figure 18: Schéma montrant les différents tests effectués afin de
comparer les performances du SGBDR avant et après chiffrement
de la table employees

données dans un fichier chiffré ou non. La parallélisation des requêtes d’insertion n’est pas
nécessaire du fait du fonctionnement ACID d’innodb qui assure qu’une écriture sera faite à
chaque insertion en base de données. Qu’il y ait une ou cinq connexions simultanées à la
base n’influe donc pas sur ces performances.
On constate ici que les temps d’insertion sont comparables dans une table chiffrée et dans
une table non chiffrée pour un nombre d’insertions allant jusqu’à 100000. On remarque
cependant ensuite des écarts de performances significatifs avec 16 % de temps d’exécution
supplémentaires pour 200000 et 300000 enregistrements insérés dans une table chiffrée par
rapport à une table non chiffrée.
III.4.B Projection de données non optimisée
1000 requêtes de projection aléatoires sur la table employees ont été jouées et
réparties entre 1, 5, 10, 50 et 100 clients se connectant simultanément à la base de données.
Cette opération a été exécutée dès lors qu’une phase d’insertion en masse s’est terminée.
Ces requêtes utilisent comme filtre une clé non indexée de la table employees et ne sont
donc pas optimisées
53
Figure 19: Graphe comparant les temps d'exécution des insertions sur une table
chiffrée et sur une table non chiffrée

Le temps d’exécution de requêtes aléatoires de projection basées sur une colonne non
indexée de la table sont tout à fait comparables, que cette table soit chiffrée ou non.
54
Figure 20: Graphe montrant les temps d'exécution d'une requête de projection non
optimisée sur une table non chiffrée
Figure 21: Graphe montrant les temps d'exécution d'une requête de projection non
optimisée sur une table chiffrée

III.4.CProjection de données optimisée
1000 requêtes de projection aléatoires sur la table employees ont été jouées et
réparties entre 1, 5, 10, 50 et 100 clients se connectant simultanément à la base de données.
Cette opération a été exécutée dès lors qu’une phase d’insertion en masse s’est terminée.
Ces requêtes utilisent comme filtre la clé primaire et sont donc optimisées.
55
Figure 22: Graphe montrant les temps d'exécution d'une requête de projection
optimisée sur une table non chiffrée
Figure 23: Graphe montrant les temps d'exécution d'une requête de projection
optimisée sur une table chiffrée

Le temps d’exécution de requêtes aléatoires de projection basées sur la clé primaire de la
table sont tout à fait comparables, que cette table soit chiffrée ou non.
III.4.DGénération d’une table temporaire
La requête présentée précédemment dans ce mémoire permettant la génération de
table temporaires a été exécutée dès lors qu’une phase d’insertion en masse s’est terminée.
Ici le nombre de clients n’a pas été modifié (toujours 1) puisque le test consiste à mesurer
l’impact de l’écriture sur disque de données temporaires chiffrées ou non.
Aucune différence de performances notable n’est constatable.
Il s’agit ici de tests « extrêmes » visant à mesurer l’impact du chiffrement innodb sur les
performances de ce moteur. Les temps présentés ne sont en aucun cas représentatifs de la
réalité puisque les configurations ne seraient pas les mêmes en production. Ils permettent
cependant de comparer les performances d’un SGBDR exécutant les mêmes requêtes sur
un même environnement, avant et après chiffrement d’une table. Les résultats sont présents
sous forme de données brutes en Annexe 3.
Tous ces tests de performances ne mettent donc pas en évidence de différences
fondamentales entre les deux instances déployées, si ce n’est pour l’insertion massive de
données. Le chiffrement innodb mis en place par Percona Server semble donc efficace
56
Figure 24: Graphe montrant les temps d'exécution d'une requête générant des
tables temporaires innodb chiffrées ou non

puisque simple à mettre en place et très peu impactant pour les produits utilisant la base de
données.
III.5 Mise en place du chiffrement des redo logs, undo tablespaces et logs
binaires avec Percona Server for MySQL
Les méthodologies de chiffrement mises en place afin de protéger les autres fichiers
pouvant contenir des données diffèrent pour certaines de celle mise en place pour chiffrer
les fichiers innodb.
Commençons par étudier le chiffrement des redo logs. Ici, le chiffrement utilisé requiert
seulement la master key générée lors du chiffrement des fichiers innodb (ou créera une clé
maîtresse si elle n’existe pas). Voici comment la configuration doit être modifiée afin
d’activer le chiffrement des redo logs :
La même méthode de chiffrement que celle utilisée pour chiffrer les clés secondaires des
fichiers innodb est utilisée (ECB), mais elle sert cette fois à chiffrer les données insérées
dans ce fichier : il n’y aura en effet jamais besoin de déchiffrer ou chiffrer l’intégralité du
fichier, donc les problèmes de performances évoqués précédemment ne se posent pas. Les
redo logs étant des fichiers séquentiels dont l’historique n’est plus utile s’il n’y a pas eu de
problème au niveau de l’instance, il a été choisi de n’activer le chiffrement que sur les
pages disques subissant des écritures postérieures à l’activation du paramètre. Il s’agit d’un
choix discutable puisque les données telles que celles montrées précédemment dans ce
mémoire sont toujours visibles et exploitables. La taille de ces fichiers de logs étant fixe,
ces anciennes pages disques subissent cependant rapidement de nouvelles écritures et
l’intégralité des pages disques composant ce fichier se retrouvent chiffrées. Afin de
maintenir la cohérence de la volonté de chiffrement, il semble plus prudent de supprimer
les anciens redo logs lors de l’application du paramètre si l’instance a été correctement
éteinte afin de repartir sur des fichiers vierges de toute donnée non chiffrée.
57
innodb_redo_log_encrypt=ON

Mise en conformité des bases de données MySQL avec le RGPD

Mise en conformité des bases de données MySQL avec le RGPD

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Mise en conformité des bases de données MySQL avec le RGPD

Similaire à Mise en conformité des bases de données MySQL avec le RGPD (20)

Dernier

Dernier (20)

Mise en conformité des bases de données MySQL avec le RGPD