Licence CC BY

Sécurité et confidentialité des données

Voilà une partie qui s’annonce très dense, étant donné les exigences du RGPD à ce sujet ; nous traiterons de la nouvelle obligation incombant aux structures qui est celle d’assurer la confidentialité des données personnelles. Aussi, en matière de sécurité, nous survolerons – car ces notions pourraient faire l’objet d’un cours complet – les politiques de sécurité des systèmes d’information, maintenant obligatoires, ainsi qu’un concept nommé Privacy Impact Assessment, et consistant à étudier les impacts d’un projet sur la vie privée avant même de le concevoir. Du point de vue des utilisateurs, cette partie consiste à étudier quelles mesures de protections seront appliquées à leurs données, et à comprendre leurs droits à ce sujet.

Présentation générale

Commençons tout d’abord par définir les deux termes qui seront objets de toute cette partie, à savoir :

  • la confidentialité est, selon les termes de l’ISO « le fait de s’assurer que l’information n’est accessible qu’à ceux dont l’accès est autorisé », il s’agit donc d’un contrôle d’accès indirect, qui s’applique à la fois au niveau physique (contrôler les portes qui mènent aux terminaux) et numérique (contrôler les terminaux eux-mêmes) ;
  • la sécurité, quant à elle, est une situation dans laquelle le risque est minimal par rapport à la donnée, il faut pour cela prendre à la fois des éléments de risque, mais aussi évaluer l’importance des données traitées.

Le RGPD regroupe plus ou moins ces deux concepts dans celui de sécurité, pour la raison simple que la sécurité est seule garante de la confidentialité des données, elle est à ce titre la clef de voûte à la fois de la confidentialité et de l’intégrité des données, puisqu’elle empêche leur modification ou leur accès par une personne malveillante.

Pour commencer à parler réellement des dispositions du RGPD, il faut noter que la sécurité et la confidentialité des données sont à prendre de manière globale ; chaque traitement doit faire l’objet d’analyses permettant de prendre en compte la meilleure manière de sécuriser la donnée, en en considérant tous les éléments environnants, qui sont d’ailleurs parfois d’autres données personnelles.

Le principe général est le suivant : nécessité de mettre en œuvre toutes les mesures de protection possibles en fonction de l’état de l’art afin d’assurer la confidentialité, l’intégrité (c’est-à-dire l’exactitude par rapport aux données originales) et la sécurité des données personnelles1. Pour cela, le Règlement propose quatre moyens, non-exhaustifs :

  • la pseudonymisation des données (une forme d’anonymisation dont nous parlions avant, qui n’en est pas réellement) ;
  • la mise en place de chiffrement, c’est-à-dire de mesures techniques permettant que des données éventuellement volées ne puissent être lues ;
  • des moyens permettant de rétablir les données en cas d’incident physique ou technique ;
  • une procédure visant à tester l’efficacité des mesures mises en place.

Le dernier point est très important et rappelle la liberté laissée à l’entreprise en termes de sécurité : tout est possible en termes de forme, mais il faut en tous cas documenter et tester. Aussi, le RGPD rappelle que la sécurité est forcément basée sur l’équilibre, entre « l’état des connaissances, [l]es coûts de mise en œuvre et la nature, la portée, [le] contexte et [l]es finalités » d’un part, et de l’autre, « [l]es risques, dont le degré de probabilité et de gravité varie, pour les droits et libertés des personnes physiques ».

Enfin, notons qu’il y a des précautions à prendre pour les sous-traitants : toute personne physique agissant sous l’autorité d’un responsable de traitement ne peut traiter les données que sur ordre direct de celui-ci ; le sous-traitant doit garantir de bonnes conditions de sécurité par contrat, et ne peut faire sous-traiter par quelqu’un d’autre sans y avoir été explicitement autorisé.

  1. RGPD, art. 32 ↩

Mise en œuvre interne

Beaucoup de formalités internes ici (c’est le but) ; si l’idée vous répugne, fuyez à la partie suivante.

La loi Informatique et Liberté précise1 qu’il faut mettre en place en interne des précautions utiles, au regard de la nature des données et des risques présentés par le traitement ; cette disposition est reprise par le RGPD2 et synthétise ce qui a été vu dans la partie précédente. Dans cette partie, le terme « en interne » va nous intéresser particulièrement, car une grande et stricte organisation sera requise pour sécuriser la donnée, et surtout être en mesure de la prouver à la CNIL.

Premièrement, le Règlement mentionne un principe appelé « Privacy by Design », qui constitue à penser à la protection des données dès l’étape de conception, c’est-à-dire dès l’origine du traitement. C’est une démarche à laquelle votre esprit devrait être habitué depuis le début du cours, car l’organisation de celui-ci vous mène à poser des questions de nécessité de traitement. Cette conception avec l’idée de protection des données n’implique pas que le problème s’arrête ici, il faut ensuite interpréter et adapter les règles tout au long des différents traitements, c’est pourquoi il faut pour les structures établir une politique des systèmes d’informations3, qui soit globale et s’applique dans toute la structure, ou toute le département informatique.

Cette PSSI n’est en réalité pas un unique document, mais est en général constituée 4, d’abord, d’une politique générale, qui se constitue elle-même d’un ensemble de documents précisant le périmètre d’application, les acteurs et leurs missions et les risques concernés ainsi que les modalités de mise en œuvre de la politique, de reporting et de contrôle des procédures. Concernant les acteurs, le responsable de traitement est garant ad-hoc de la sécurité des données en tous cas, mais le responsable pratique est en réalité plutôt une personne spécifiquement nommée à cet effet dans les grandes entreprises, ou un ingénieur en sécurité informatique ; quant au DPD, il n’est comme toujours pas responsable, mais doit conseiller correctement une entreprise lors du processus de mise en sécurité des données.

Peuvent être adjoints à ce document de politique générale diverses politiques spécifiques qui peuvent être présentes dès le départ, ou ajoutées par la suite. On pourrait citer, non-exhaustivement4 :

  • une politique sur la sécurité physique qui définit les procédures à mettre en œuvre pour empêcher un accès physique non autorisé, ou tout dommage ou intrusion dans les locaux hébergeant les données ;
  • une politique sur les modalités de traitement de l’information qui précise où sont stockées les données, les modalités de leur destruction, ainsi que les mesures de sécurités logicielles (pseudonymisation, chiffrement, …) ;
  • une politique de sauvegarde et d’archivage qui assure l’intégrité et la disponibilité des éléments amenés à être restaurés, et explique le choix des solutions d’archivage (le système en trois archives dont nous parlions).

  1. L. n° 78-17, 6 janvier 1978, relative à l’informatique, aux fichiers et aux libertés, art. 34 ↩

  2. RGPD, art. 5 ↩

  3. ANSSI (ex-DCSSI), 2004, guide pour l’élaboration d’une politique de sécurité de système d’information ↩

  4. Par exemple le PSSI de l’État ↩

Notification des failles de sécurité

Le RGPD introduit une notion qui n’existait avant que dans peu de pays européens : l’obligation de notifier les failles de sécurité1. L’exigence envers les responsables de traitement est grandissante, et afin d’éviter la propagation des données, où un scandale grave lié aux données personnelles – alors que l’affaire Cambridge Analytica, concernant aussi Facebook retentit en ce moment dans les médias2. L’avertissement doit être transmis à la CNIL, ou tout autre autorité compétente dans le pays en question, « dans les meilleurs délais », soit si possible 3 jours après en avoir pris connaissance, précise le Règlement ; si elle est effectuée plus de 3 jours après, il sera nécessaire de préciser les motifs de retard.

Une violation de données – synonyme de faille de sécurité – est une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d’une autre manière, ou l’accès non autorisé à de telles données. Notons qu’une faille de sécurité découverte sur un environnement précisément destiné à cela n’a pas à être signalée, ni celles qui n’ont révélé aucune donnée personnelle, il faut en effet une violation de données à caractère personnel, même si elle est minime, et surtout si vous n’êtes pas sûr de son ampleur.

La CNIL est là pour vous aider dans ce cas et jouera en premier lieu le rôle du pompier : éteindre le feu avant qu’il ne prenne trop. Au niveau pénal3, la non-communication à la CNIL sera suivie de 5 ans d’emprisonnement et de 300 000 €, un paradoxe, quand on sait que la connaissance de cette faille par la CNIL peut mener à des amendes disciplinaires…

En cas de communication à la CNIL (c’est à ne pas souhaiter), il vous faudra fournir les éléments suivants, que la CNIL gardera bien évidemment privés4 :

  • une description de la nature des données (quelles données?) ainsi que, s’ils sont connus, les types de personnes touchés par la faille, et leur nombre ; s’il est approximatif, ou estimé en interne, fournissez-le tout de même (quel quantité?), enfin, quelle quantité d’enregistrements a été effectuée ?
  • le nom et les coordonnées du délégué à la protection des données ou d’un autre point de contact auprès duquel des informations supplémentaires peuvent être obtenues ;
  • expliquer les conséquences possibles et probables de la violation de données ; pas besoin d’en faire des tonnes, mais soyez clairs et allez droit au but ;
  • décrire les mesures proposées pour remédier à la violation de données, et les mesures pour en atténuer les effets négatifs.

Comme vous pouvez le voir, cela représente beaucoup d’informations en 72 heures, c’est pourquoi il est recommandé d’ajouter à votre PSSI une politique de gestion des incidents, qui formalise le processus à effectuer en cas de problème sur un serveur ou de faille de sécurité, qui inclus notamment l’obligation légale de déclaration à la CNIL des failles de sécurité dont nous venons de parler ; en cas de problème, vous serez ravis d’avoir ce protocole sous la main.

Enfin, dans certains cas très précis, il est nécessaire d’avertir l’utilisateur que ses données personnelles ont été volées. Cela concerne les cas où la communication de ces données présente un risque élevé pour les droits et libertés ; pour vous aider là-dessus, la CNIL a mis sur son site Internet des guides à destination des professionnels de différents secteurs pour faciliter la compréhension.

  1. RGPD, art. 33 et suivants ↩

  2. Rappel succin des événements ↩

  3. C. pén., art. 226-17-1 ↩

  4. RGPD, art. 33, alinéa 3 ↩

Le PIA : une analyse d’impact

Le Privacy Impact Assessement est un processus qui assure que tout nouveau traitement mis en en œuvre ou toute modification d’un traitement existant sera réalisé conformément aux obligations légales diverses, particulièrement relativement à la sécurité, la confidentialité et la fin de vie des données (après les cycles d’archivage)1.

Ce PIA est toujours recommandé, mais obligatoire uniquement dans les cas « susceptible[s] d’engendrer un risque élevé pour les droits et libertés des personnes ». Pour déterminer cela, il faut utiliser le Règlement, qui définit des obligations de manière formelle, la CNIL, et sa bibliothèque d’avis, et d’avis à venir, mais aussi une liste, mise en place par le G29 (deux éléments de la liste devraient vous alerter et vous inciter à réaliser un PIA) qui vous indique de vous inquiéter dans les cas2 :

  • d’évaluation et de notation, y compris le profilage (d’un salarié, par exemple) ;
  • de prise de décision automatisée, dans un cadre juridique (c’est pourquoi la nouvelle loi de conciliation de justice impose un humain dans le processus, notamment) ;
  • de surveillance systématique, sans que soit entendu par surveillance l’idée de caméra ;
  • données particulières visées à l’article 9 (de santé, pénale, …) ;
  • de big-data, important par sa volumétrie, le nombre de personnes concernées, la durée de conservation et l’étendue géographique du traitement ;
  • de croisement d’informations entre elles ;
  • de traitement de données de personnes vulnérables (pour rappel, mineur de 16 ans et majeurs protégés) ;
  • de l’emploi de solutions technologiques particulièrement technologiques (entendre innovantes et dangereuses, comme la biométrie) ;
  • enfin, d’exclusion du bénéfice d’un droit du RGPD (si l’utilisateur est privé de droit d’accès par exemple).

Comme je le disait plus haut, il faut deux points pour commencer à s’inquiéter suffisamment pour réaliser un PIA, mais si vous ne répondez qu’à un critère, soyez toutefois vigilant : vous traitez une donnée sensible, soumise à des règles parfois spécifiques. Prenons un exemple : le traitement de données de patients ; par un hôpital, un PIA devra être réalisé, car les conditions « personnes vulnérables », « données sensibles » et « big-data » – oui, pas au sens commun, on parle de big-data quand un bon nombre de personnes sont concernées. Par un médecin, toutefois, pas besoin de PIA, car les médecins bénéficient d’une exception au sens du considérant 91 du RGPD.

Pour bien rédiger un PIA, je vous redirige vers les très bons conseils de la CNIL à ce sujet, car sa documentation est plus complète que n’importe quel cours.

Terminons enfin par préciser qu’il faut transmettre le PIA à la CNIL s’il réside un risque élevé malgré la mise en place de protocoles pour l’éviter, sur obligation légale ou en cas de contrôle de la CNIL dans l’entreprise ; il est en tous cas conseillé de refaire un PIA au moins tout les 3 ans, ou au moins de le revoir, cela permets de se rendre compte des données devenues inutiles, et des informations devenues inexactes.

  1. RGPD, art. 35 ↩

  2. G29, avis WP 248, lignes directrices concernant l’analyse d’impact relative à la protection des données, 4 avril 2017 ↩

J’espère que ces concepts de confidentialité et de sécurité sans bien ancrés dans vos têtes, et que vous y penserez lors de la réalisation d’un quelconque projet informatique. Pour rappel la question importante à se poser est la suivante : « La sécurité des données que je traite est-elle proportionnée à leur contenu ? ».