SlideShare une entreprise Scribd logo
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
   
27
Confidentiel
 
28
Confidentiel
 
 
29
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;
Query OK, 1 row affected (0,00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE employees SET first_name = 'JOE' WHERE emp_no = 1000000;
Query OK, 1 row affected (0,00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE employees SET last_name = 'DOE' WHERE emp_no = 1000000;
Query OK, 1 row affected (0,00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
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');
Query OK, 1 row affected (0,01 sec)
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 `employees_encrypt` (
-> `emp_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 (`emp_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;
Query OK, 1000000 rows affected (9,87 sec)
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;
Query OK, 0 rows affected (0,00 sec)
mysql> SELECT KEY_ID FROM performance_schema.keyring_keys;
+--------------------------------------------------+
| KEY_ID |
+--------------------------------------------------+
| INNODBKey-a23a5098-4d73-11ea-8914-005056ae4270-1 |
| INNODBKey-a23a5098-4d73-11ea-8914-005056ae4270-2 |
+--------------------------------------------------+
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
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD
Mise en conformité des bases de données MySQL avec le RGPD

Contenu connexe

Tendances

Distributed computing ).ppt him
Distributed computing ).ppt himDistributed computing ).ppt him
Distributed computing ).ppt him
Himanshu Saini
 
Cloud robotics
Cloud roboticsCloud robotics
Cloud robotics
Ank Khandelwal
 
Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2
Jean David Olekhnovitch
 
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
Edureka!
 
Microsoft Hyper-V
Microsoft Hyper-VMicrosoft Hyper-V
Microsoft Hyper-V
Davoud Teimouri
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
Heithem Abbes
 
Microsoft Azure Networking Basics
Microsoft Azure Networking BasicsMicrosoft Azure Networking Basics
Microsoft Azure Networking Basics
Sai Kishore Naidu
 
Introduction to Google Cloud Platform
Introduction to Google Cloud PlatformIntroduction to Google Cloud Platform
Introduction to Google Cloud Platform
dhruv_chaudhari
 
4.cloud Deployment models
4.cloud Deployment models4.cloud Deployment models
4.cloud Deployment models
DrRajapraveen
 
Virtualization & cloud computing
Virtualization & cloud computingVirtualization & cloud computing
Virtualization & cloud computing
Soumyajit Basu
 
PowerHA for i
PowerHA for iPowerHA for i
PowerHA for i
cindyvermeulen
 
Architecture of a Modern Web App
Architecture of a Modern Web AppArchitecture of a Modern Web App
Architecture of a Modern Web App
scothis
 
Etude de la virtualisation
Etude de la virtualisationEtude de la virtualisation
Etude de la virtualisation
Antoine Benkemoun
 
Présentation des services AWS
Présentation des services AWSPrésentation des services AWS
Présentation des services AWS
Julien SIMON
 
Azure backup Disaster Recovery Business Continuity
Azure backup Disaster Recovery Business ContinuityAzure backup Disaster Recovery Business Continuity
Azure backup Disaster Recovery Business Continuity
Mike Resseler
 
Get started With Microsoft Azure Virtual Machine
Get started With Microsoft Azure Virtual MachineGet started With Microsoft Azure Virtual Machine
Get started With Microsoft Azure Virtual Machine
Lai Yoong Seng
 
VMware Presentation
VMware PresentationVMware Presentation
VMware Presentation
Emirates Computers
 
Introduction To Cloud Computing
Introduction To  Cloud ComputingIntroduction To  Cloud Computing
Introduction To Cloud Computing
acemindia
 
Cloud Computing & Distributed Computing
Cloud Computing & Distributed ComputingCloud Computing & Distributed Computing
VMware vSphere technical presentation
VMware vSphere technical presentationVMware vSphere technical presentation
VMware vSphere technical presentation
aleyeldean
 

Tendances (20)

Distributed computing ).ppt him
Distributed computing ).ppt himDistributed computing ).ppt him
Distributed computing ).ppt him
 
Cloud robotics
Cloud roboticsCloud robotics
Cloud robotics
 
Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2Développement web mobile avec IONIC 2
Développement web mobile avec IONIC 2
 
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
VMware Tutorial For Beginners | VMware Workstation | VMware Virtualization | ...
 
Microsoft Hyper-V
Microsoft Hyper-VMicrosoft Hyper-V
Microsoft Hyper-V
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
Microsoft Azure Networking Basics
Microsoft Azure Networking BasicsMicrosoft Azure Networking Basics
Microsoft Azure Networking Basics
 
Introduction to Google Cloud Platform
Introduction to Google Cloud PlatformIntroduction to Google Cloud Platform
Introduction to Google Cloud Platform
 
4.cloud Deployment models
4.cloud Deployment models4.cloud Deployment models
4.cloud Deployment models
 
Virtualization & cloud computing
Virtualization & cloud computingVirtualization & cloud computing
Virtualization & cloud computing
 
PowerHA for i
PowerHA for iPowerHA for i
PowerHA for i
 
Architecture of a Modern Web App
Architecture of a Modern Web AppArchitecture of a Modern Web App
Architecture of a Modern Web App
 
Etude de la virtualisation
Etude de la virtualisationEtude de la virtualisation
Etude de la virtualisation
 
Présentation des services AWS
Présentation des services AWSPrésentation des services AWS
Présentation des services AWS
 
Azure backup Disaster Recovery Business Continuity
Azure backup Disaster Recovery Business ContinuityAzure backup Disaster Recovery Business Continuity
Azure backup Disaster Recovery Business Continuity
 
Get started With Microsoft Azure Virtual Machine
Get started With Microsoft Azure Virtual MachineGet started With Microsoft Azure Virtual Machine
Get started With Microsoft Azure Virtual Machine
 
VMware Presentation
VMware PresentationVMware Presentation
VMware Presentation
 
Introduction To Cloud Computing
Introduction To  Cloud ComputingIntroduction To  Cloud Computing
Introduction To Cloud Computing
 
Cloud Computing & Distributed Computing
Cloud Computing & Distributed ComputingCloud Computing & Distributed Computing
Cloud Computing & Distributed Computing
 
VMware vSphere technical presentation
VMware vSphere technical presentationVMware vSphere technical presentation
VMware vSphere technical presentation
 

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

Livre blanc sauvegarde en ligne enjeux et atouts
Livre blanc sauvegarde en ligne   enjeux et atoutsLivre blanc sauvegarde en ligne   enjeux et atouts
Livre blanc sauvegarde en ligne enjeux et atouts
Ozitem
 
Workshop CNIL - RGPD & Objets connectés
Workshop CNIL - RGPD & Objets connectésWorkshop CNIL - RGPD & Objets connectés
Workshop CNIL - RGPD & Objets connectés
Stéphanie Roger
 
Protéger ses données: mission impossible?
Protéger ses données: mission impossible?Protéger ses données: mission impossible?
Protéger ses données: mission impossible?
Antoine Vigneron
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
Tidiane Sylla
 
Des données au savoir : big data et data mining
Des données au savoir : big data et data miningDes données au savoir : big data et data mining
Des données au savoir : big data et data mining
Pierre-Alain Four
 
MEMOIRE TIEMOKO BATHILY.docx
MEMOIRE TIEMOKO BATHILY.docxMEMOIRE TIEMOKO BATHILY.docx
MEMOIRE TIEMOKO BATHILY.docx
TiemokoBoubouBathily
 
Keynote 5th Swiss Data Protection day, 2012
Keynote 5th Swiss Data Protection day, 2012Keynote 5th Swiss Data Protection day, 2012
Keynote 5th Swiss Data Protection day, 2012
University of Geneva
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
christedy keihouad
 
Internet des objets : quels défis pour la protection des données personnelles ?
Internet des objets : quels défis pour la protection des données personnelles ?Internet des objets : quels défis pour la protection des données personnelles ?
Internet des objets : quels défis pour la protection des données personnelles ?
Radouane Mrabet
 
Analyse spatiale en Big data
Analyse spatiale en Big dataAnalyse spatiale en Big data
Analyse spatiale en Big data
Soufiane ElATEF✔️
 
Whitepaper security Lenovo
Whitepaper security LenovoWhitepaper security Lenovo
Whitepaper security Lenovo
SOUKARIEH Mayass
 
Bluemix Paris Meetup : Big data et Analytics - 15 avril 2015
Bluemix Paris Meetup :  Big data et Analytics - 15 avril 2015Bluemix Paris Meetup :  Big data et Analytics - 15 avril 2015
Bluemix Paris Meetup : Big data et Analytics - 15 avril 2015IBM France Lab
 
Meetup Cybersécurité RGPD Conséquences dans l'Embarqué
Meetup Cybersécurité RGPD Conséquences dans l'EmbarquéMeetup Cybersécurité RGPD Conséquences dans l'Embarqué
Meetup Cybersécurité RGPD Conséquences dans l'Embarqué
Christian Charreyre
 
Competitic securite données - numerique en entreprise
Competitic   securite données - numerique en entrepriseCompetitic   securite données - numerique en entreprise
Competitic securite données - numerique en entreprise
COMPETITIC
 
Gdpr acerta
Gdpr acertaGdpr acerta
Synthèse des Solutions Software
Synthèse des Solutions Software   Synthèse des Solutions Software
Synthèse des Solutions Software
Solutions IT et Business
 
Pour_une_politique_publique_de_la_donnée
Pour_une_politique_publique_de_la_donnéePour_une_politique_publique_de_la_donnée
Pour_une_politique_publique_de_la_donnée
CHARLES Frédéric
 
Research Paper on Digital Forensic
Research Paper on Digital ForensicResearch Paper on Digital Forensic
Research Paper on Digital Forensic
Thomas Roccia
 
cyberedu_module_1_notions_de_base_02_2017.pptx
cyberedu_module_1_notions_de_base_02_2017.pptxcyberedu_module_1_notions_de_base_02_2017.pptx
cyberedu_module_1_notions_de_base_02_2017.pptx
HbJlm
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
Borel NZOGANG
 

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

Livre blanc sauvegarde en ligne enjeux et atouts
Livre blanc sauvegarde en ligne   enjeux et atoutsLivre blanc sauvegarde en ligne   enjeux et atouts
Livre blanc sauvegarde en ligne enjeux et atouts
 
Workshop CNIL - RGPD & Objets connectés
Workshop CNIL - RGPD & Objets connectésWorkshop CNIL - RGPD & Objets connectés
Workshop CNIL - RGPD & Objets connectés
 
Protéger ses données: mission impossible?
Protéger ses données: mission impossible?Protéger ses données: mission impossible?
Protéger ses données: mission impossible?
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
 
Des données au savoir : big data et data mining
Des données au savoir : big data et data miningDes données au savoir : big data et data mining
Des données au savoir : big data et data mining
 
MEMOIRE TIEMOKO BATHILY.docx
MEMOIRE TIEMOKO BATHILY.docxMEMOIRE TIEMOKO BATHILY.docx
MEMOIRE TIEMOKO BATHILY.docx
 
Keynote 5th Swiss Data Protection day, 2012
Keynote 5th Swiss Data Protection day, 2012Keynote 5th Swiss Data Protection day, 2012
Keynote 5th Swiss Data Protection day, 2012
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
 
Internet des objets : quels défis pour la protection des données personnelles ?
Internet des objets : quels défis pour la protection des données personnelles ?Internet des objets : quels défis pour la protection des données personnelles ?
Internet des objets : quels défis pour la protection des données personnelles ?
 
Analyse spatiale en Big data
Analyse spatiale en Big dataAnalyse spatiale en Big data
Analyse spatiale en Big data
 
Whitepaper security Lenovo
Whitepaper security LenovoWhitepaper security Lenovo
Whitepaper security Lenovo
 
Bluemix Paris Meetup : Big data et Analytics - 15 avril 2015
Bluemix Paris Meetup :  Big data et Analytics - 15 avril 2015Bluemix Paris Meetup :  Big data et Analytics - 15 avril 2015
Bluemix Paris Meetup : Big data et Analytics - 15 avril 2015
 
Meetup Cybersécurité RGPD Conséquences dans l'Embarqué
Meetup Cybersécurité RGPD Conséquences dans l'EmbarquéMeetup Cybersécurité RGPD Conséquences dans l'Embarqué
Meetup Cybersécurité RGPD Conséquences dans l'Embarqué
 
Competitic securite données - numerique en entreprise
Competitic   securite données - numerique en entrepriseCompetitic   securite données - numerique en entreprise
Competitic securite données - numerique en entreprise
 
Gdpr acerta
Gdpr acertaGdpr acerta
Gdpr acerta
 
Synthèse des Solutions Software
Synthèse des Solutions Software   Synthèse des Solutions Software
Synthèse des Solutions Software
 
Pour_une_politique_publique_de_la_donnée
Pour_une_politique_publique_de_la_donnéePour_une_politique_publique_de_la_donnée
Pour_une_politique_publique_de_la_donnée
 
Research Paper on Digital Forensic
Research Paper on Digital ForensicResearch Paper on Digital Forensic
Research Paper on Digital Forensic
 
cyberedu_module_1_notions_de_base_02_2017.pptx
cyberedu_module_1_notions_de_base_02_2017.pptxcyberedu_module_1_notions_de_base_02_2017.pptx
cyberedu_module_1_notions_de_base_02_2017.pptx
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
 

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

  • 1. 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
  • 2.
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. - 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. - « 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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.
  • 36. 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; Query OK, 1 row affected (0,00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> UPDATE employees SET first_name = 'JOE' WHERE emp_no = 1000000; Query OK, 1 row affected (0,00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> UPDATE employees SET last_name = 'DOE' WHERE emp_no = 1000000; Query OK, 1 row affected (0,00 sec) Rows matched: 1 Changed: 1 Warnings: 0
  • 37. 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'); Query OK, 1 row affected (0,01 sec)
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. (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
  • 42. 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
  • 43. 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
  • 44. 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); ?>
  • 45. 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
  • 46. 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';
  • 47. 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 `employees_encrypt` ( -> `emp_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 (`emp_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; Query OK, 1000000 rows affected (9,87 sec) Records: 1000000 Duplicates: 0 Warnings: 0
  • 48. 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 | +--------------------------------------------------+
  • 49. 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; Query OK, 0 rows affected (0,00 sec) mysql> SELECT KEY_ID FROM performance_schema.keyring_keys; +--------------------------------------------------+ | KEY_ID | +--------------------------------------------------+ | INNODBKey-a23a5098-4d73-11ea-8914-005056ae4270-1 | | INNODBKey-a23a5098-4d73-11ea-8914-005056ae4270-2 | +--------------------------------------------------+ 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
  • 50. 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.
  • 51. 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
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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