Qu’est-ce que l’analyse d’impact version RGPD (PIA, DPIA, EIVP) ?

L’application du nouveau règlement européen relatif aux données personnelles appelé RGPD impose, en partie, la réalisation d’une analyse d’impact relative à la protection des données ou DPIA pour Data Protection Impact Assessment. Cette démarche, repose sur une analyse de risques sécurité orientée uniquement sur les risques visant les données personnelles et leurs impacts sur les droits et libertés des personnes concernées par ces données.

L’Étude d’Impact sur la Vie Privée (EIVP), traduction utilisée par la Commission Nationale de l’Informatique et des Libertés (CNIL) pour le Privacy Impact Assessment (PIA), sont les termes précédemment utilisés. Le Règlement Général pour la Protection des Données (RGPD) les remplace par DPIA (en français : analyse d’impact sur la protection des données). Si les termes évoluent, ils désignent sensiblement la même chose : une démarche d’analyse des risques impactant la protection des données, évoqué par l’article 35 du RGPD.

Nous le disions en introduction, le DPIA s’impose, mais en fait pas pour tous les traitements. En effet, il n’est pas obligatoire pour l’ensemble des traitements, mais uniquement pour les traitements présentant « un risque élevé pour les droits et libertés des personnes physiques » (RGPD article 35 – 1.). Si cette description est un peu vague, le règlement nous donne tout de même quelques exemples (en préambule et sur l’article 35), sur lesquels la réalisation d’une analyse d’impact est obligatoire :

  • les traitements à grande échelle
  • la surveillance systématique à grande échelle d’une zone accessible au public (notamment la vidéosurveillance)
  • les décisions automatiques produisant des effets juridiques (pour des offres de prestations, ou le choix de contractualisation)
  • le traitement de données sensibles (données de santé, opinions politiques, orientation sexuelle)
  • l’évaluation ou la notation basée sur des données personnelles, y compris le profilage et la prédiction
  • le traitement de données biométriques, de données relatives à des condamnations pénales et à des infractions

Il est également précisé que la liste n’est pas exhaustive. Ce sont les autorités de contrôle nationaux (la CNIL pour la France) qui seront en charge d’éditer la liste des traitements nécessitant une DPIA (RGPD, article 35 – 4) et la liste des traitements ne nécessitant pas une DPIA (RGPD, article 35 – 5).

Le G29 (groupe des autorités de contrôle dont la CNIL), quant à eux, recommande qu’une DPIA soit effectuée pour aider les responsables du traitement à se conformer à la réglementation.

Comment réaliser une DPIA ?

Le RGPD définit les responsabilités impliquées dans la réalisation d’une DPIA (RGPD article 35 – 1 et 2). Ainsi, c’est le Responsable du Traitement qui réalise la DPIA, avant la mise en place du traitement. Si un DPO (Data Protection Officer) ou DPD en français (Délégué à la Protection des Données), est nommé, le DPO aura un rôle de conseil auprès du Responsable de Traitement pour l’accompagner sur l’exécution de l’analyse.

Pour la mise en œuvre d’une telle démarche, la CNIL a publié en 2012 un guide pour la réalisation d’une PIA. La recette proposée se résume par le schéma ci-dessous extrait du guide PIA-1 – Méthode :

Demarche d'analyse de risques de cybersecurite basee sur la methodologie ebios

C’est une démarche d’analyse de risques sécurité (au sens cybersécurité), basé sur la méthodologie EBIOS publiée par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information). Pour résumer la démarche :

1. Contexte

Décrire le ou les traitement(s) considéré(s) (finalités, enjeux, durées de conservation) ainsi que les responsabilités liées aux traitements. Décrire les moyens supports des traitements (matériels, logiciels, réseaux, personnes, papiers). Cette étape doit permettre également d’évaluer « la nécessité et de la proportionnalité des opérations de traitement au regard des finalités » (RGPD article 35 – 7).

2. Mesures

Identifier les mesures existantes ou prévues. Ces mesures sont les mesures juridiques imposées par la réglementation (droits des personnes et information à leur fournir) et les mesures de sécurité pour les protéger (mesures organisationnelles et techniques).

3. Risques

La définition proposée du risque le décompose en deux parties pour faciliter son identification et son analyse. D’un côté, on évalue ce que l’on craint sur les traitements (perte, divulgation, corruption des données avec les impacts sur la vie privée) et le niveau de gravité de ces événements redoutés. De l’autre, les menaces et leur source ciblant les supports des traitements et pouvant mener aux événements redoutés. La vraisemblance de réalisation de ces scénarios est évaluée en considérant les vulnérabilités identifiées ou potentielles et sur les mesures de sécurité. La combinaison des événements redoutés et des scénarios de menaces donne des risques, et les niveaux de risques s’évaluent en considérant la vraisemblance du scénario et la gravité des impacts identifiés.

4. Décision

La prise de décision consiste à valider le choix des mesures existantes et prévues permettant de traiter les risques. Ainsi, si les mesures ne sont pas suffisantes, un plan d’actions est défini pour en proposer de nouvelles. L’analyse est alors révisée pour prendre en compte ces nouveaux paramètres, et ce jusqu’à ce que les niveaux de risques permettent de prendre la décision de les accepter.

Comme le précise la CNIL dans son guide, c’est un processus d’amélioration continue, qui peut nécessiter plusieurs itérations pour la détermination des mesures adéquates. Il est aussi à mettre à jour régulièrement pour étudier les évolutions probables (évolution des traitements, du contexte, des supports du traitement, de nouvelles menaces, etc.).

Un point important à noter, la mise en place de cette méthode impose d’identifier les mesures de sécurité, mais aussi de conformité au règlement, avec notamment (RGPD article 35 – 7) :

  • « la preuve du respect du présent règlement »
  • « le respect, par les responsables du traitement ou sous-traitants concernés, de codes de conduite approuvés »

De plus, pour une identification efficace des mesures de sécurité, il est conseillé de prendre en compte tout le cycle de vie de la donnée (création ou réception, transfert, stockage, manipulation, destruction, mais aussi ses sauvegardes et son archivage). La donnée sera traitée et échangée entre différents supports (matériels, logiciel, réseaux, personnes et papiers) sur son cycle, qu’il est nécessaire de protéger pour garantir sa sécurité.

Conclusion

L’incorporation d’une démarche méthodique dans le RGPD va permettre de se poser les bonnes questions sur les traitements de données personnelles.

Le fait de limiter l’étude aux traitements les plus à risques, malgré la difficulté à établir une liste précise, obligera les organismes à se confronter aux problématiques sécurité de gestion de ces traitements et les responsabilisera quant au respect du droits des personnes.

C’est une avancée pour les libertés individuelles, mais cette démarche va poser des difficultés aux organismes devant l’appliquer. La réalisation d’une analyse de risques demande des compétences en sécurité pour se montrer efficace sous peine d’être superficiel ou au contraire trop lourde si on se perd dans les détails techniques.

Sources CNIL

Je partage

Derniers articles

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article