RGPD : Po­ser les bases de la mise en confor­mi­té

Dé­si­gner un res­pon­sable de pro­jet puis car­to­gra­phier les trai­te­ments de don­nées per­son­nelles. Telles sont les pre­mières étapes d’une bonne préparation à la mise en confor­mi­té avec le RGPD. Par­mi les en­jeux : dé­ni­cher les ap­pli­ca­tions de Sha­dow IT qui ne p

L'Informaticien - - SOMMAIRE - CHRISTOPHE GUILLEMIN

L’ échéance ap­proche à grand pas. Le 25 mai 2018, le Rè­gle­ment gé­né­ral sur la pro­tec­tion des don­nées ( RGPD) en­tre­ra en vi­gueur. À cette date, les en­tre­prises et ad­mi­nis­tra­tions de l’Union Eu­ro­péenne de­vront s’être mises en confor­mi­té avec ce nou­veau texte, des­ti­né à ren­for­cer et uni­for­mi­ser la pro­tec­tion des don­nées à ca­rac­tère per­son­nel sur le Vieux Conti­nent. Mais par où com­men­cer ? Avant même de se lan­cer dans les opé­ra­tions de mise en confor­mi­té, d’im­por­tants pré­pa­ra­tifs s’avèrent né­ces­saires. Dé­si­gner le pi­lote du pro­jet La pre­mière étape est sans conteste de dé­si­gner un « pi­lote » du pro­jet. « Vous au­rez be­soin d’un vé­ri­table chef d’or­chestre qui exerce une mis­sion

Il faut dé­si­gner une per­sonne ex­pé­ri­men­tée car elle de­vra tra­vailler avec de hauts ni­veaux de res­pon­sa­bi­li­té Patrick Blum, CIL de l’École su­pé­rieure des sciences éco­no­miques et com­mer­ciales (Es­sec)

d’in­for­ma­tion, de conseil et de contrôle en in­terne » , sou­ligne ain­si la Com­mis­sion na­tio­nale de l’in­for­ma­tique et des li­ber­tés (Cnil). Dans cer­tains cas, la dé­si­gna­tion de ce res­pon­sable de­vien­dra de toute fa­çon in­con­tour­nable avec le RGPD. Le nou­veau texte rend en ef­fet obli­ga­toire la no­mi­na­tion d’un « dé­lé­gué à la pro­tec­tion des

don­nées » ou Da­ta Pro­tec­tion Of­fi­cer (DPO) pour les en­ti­tés pu­bliques et cer­taines en­tre­prises. Il s’agit plus pré­ci­sé­ment des so­cié­tés dont l’ac­ti­vi­té prin­ci­pale les amène à réa­li­ser à grande échelle un sui­vi ré­gu­lier et sys­té­ma­tique des per­sonnes (pro­fi­ling), ou à trai­ter des don­nées « sen­sibles » ou en­core à ex­ploi­ter des don­nées re­la­tives à des condam­na­tions et in­frac­tions pé­nales. Par­mi ces en­tre­prises fi­gurent par exemple des so­cié­tés d’e- com­merce, de mar­ke­ting di­gi­tal, des banques et as­su­rances, des éta­blis­se­ments de soins ou en­core des en­tre­prises du sec­teur des te­le­coms. Et même si elles ne tombent pas sous le coup de cette obli­ga­tion, la ma­jo­ri­té des en­tre­prises ont tout in­té­rêt à dé­si­gner un res­pon­sable des don­nées per­son­nelles. « Sur une base vo­lon­taire, il est for­te­ment re­com­man­dé de dé­si­gner une per­sonne, dis­po­sant de re­lais in­ternes, char­gée de s’as­su­rer de la mise en confor­mi­té au rè­gle­ment eu­ro­péen » , pour­suit ain­si la Cnil.

Ce « chef d’or­chestre » est peu­têtre dé­jà en place dans l’en­tre­prise. La Cnil re­cense ain­si près de 5 000 Cor­res­pon­dants in­for­ma­tique et li­ber­tés (CIL), dé­ployés de­puis 2005 dans des en­tre­prises et en­ti­tés pu­bliques fran­çaises. Ce CIL est tout à fait en me­sure de po­ser les ja­lons pour la fu­ture mise en confor­mi­té avec le RGPD. Et il pour­ra évo­luer en­suite vers le poste de DPO (lire L’In­for­ma­ti­cien n°157, sur le mé­tier du DPO). S’il n’y a pas de CIL dans l’en­tre­prise, il est donc vi­ve­ment re­com­man­dé d’en dé­si­gner un. Il peut être nom­mé en in­terne ou re­cru­té. « Une no­mi­na­tion en in­terne offre l’avan­tage d’avoir un col­la­bo­ra­teur qui connaît bien l’en­tre­prise. Mais un re­cru­te­ment ex­terne per­met aus­si de li­mi­ter les pres­sions qui pour­raient pe­ser sur ses épaules du fait de son an­cien poste » , sou­ligne Patrick Blum, CIL de L’École su­pé­rieure des sciences éco­no­miques et com­mer­ciales (Es­sec). Comment choi­sir son CIL ? Il ne s’agit pas d’un poste pour un « ju­nior ». « Il faut une per­sonne ex­pé­ri­men­tée et qui fait au­to­ri­té sur le trai­te­ment des don­nées car elle de­vra être en me­sure de tra­vailler avec de hauts ni­veaux de res­pon­sa­bi­li­té » , pour­suit Patrick Blum. L’une des pre­mières mis­sions du CIL se­ra en ef­fet de ren­con­trer toutes les di­rec­tions de l’en­tre­prise pour leur de­man­der de lui four­nir les in­for­ma­tions né­ces­saires sur les lo­gi­ciels qu’ils uti­lisent ( lire ci- après). Il faut donc pou­voir « s’im­po­ser ». « Il faut dis­po­ser d’un tiers de com­pé­tences ju­ri­diques, d’un tiers de com­pé­tences IT et d’un tiers de com­pé­tences en re­la­tions hu­maines » , ré­sume pour sa part For­tu­na­to Gua­ri­no, CIL de l’édi­teur amé­ri­cain Gui­dance Soft­ware. No­tons que cer­tains postes sont in­com­pa­tibles avec une no­mi­na­tion au sta­tut de CIL ou de fu­tur DPO, car il y au­rait alors un risque de conflits d’in­té­rêts. C’est le cas du DG, du DSI, de la DRH ou en­core de la di­rec­tion mé­tier. « Il ne faut pas une per­sonne ayant au­to­ri­té sur le trai­te­ment des don­nées, si­non elle se­ra juge et par­tie » , in­dique Patrick Blum. Pour les pe­tites et moyennes struc­tures, ou les so­cié­tés n’ar­ri­vant pas à trou­ver de CIL, il est pos­sible de se tour­ner vers un pres­ta­taire ex­terne qui as­su­re­ra la mis­sion. Avec l’échéance du RGPD, de plus

Il faut dis­po­ser d’un tiers de com­pé­tences ju­ri­diques, d’un tiers de com­pé­tences IT et d’un tiers de com­pé­tences en re­la­tions hu­maines For­tu­na­to Gua­ri­no, CIL de l’édi­teur amé­ri­cain Gui­dance Soft­ware

en plus de ca­bi­nets d’avo­cats, de consul­tants et autres so­cié­tés de conseil, pro­posent au­jourd’hui ce type de pres­ta­tions. Pour choi­sir ce pres­ta­taire : « Il faut lui de­man­der ses ré­fé­rences clients. Si elles sont nom­breuses et an­ciennes c’est plu­tôt bon signe. En­suite, il faut prendre contact avec cer­taines de ces ré­fé­rences pour éva­luer les com­pé­tences et le sé­rieux du pres­ta­taire » , ex­plique Bru­no Rasle dé­lé­gué gé­né­ral de l’AFCDP, as­so­cia­tion fran­çaise

re­pré­sen­tant les CIL. « Nous four­nis­sons sur notre site in­ter­net une liste de ca­bi­nets d’avo­cats et de so­cié­tés de conseil. Il ne s’agit pas d’ac­teurs que nous avons au­di­té et que nous re­com­man­dons, mais sim­ple­ment d’une liste de contacts pos­sibles. À chaque en­tre­prise de vé­ri­fier si le pres­ta­taire cor­res­pond à ses be­soins » , pré­cise le res­pon­sable.

Car­to­gra­phier les trai­te­ments de don­nées per­son­nelles

Une fois le « pi­lote » dé­si­gné, la deuxième étape des pré­pa­ra­tifs au RGPD est d’éta­blir une carte des trai­te­ments de don­nées per­son­nelles uti­li­sées par l’en­tre­prise. Pour réa­li­ser cette car­to­gra­phie, le plus simple est de com­men­cer par iden­ti­fier les lo­gi­ciels et services en ligne uti­li­sés par les col­la­bo­ra­teurs et ain­si d’éta­blir un « pa­tri­moine ap­pli­ca­tif ». Le res­pon­sable des don­nées per­son­nelles va com­men­cer par ren­con­trer toutes les di­rec­tions de l’en­tre­prise pour leur de­man­der quels lo­gi­ciels et services en ligne elles ex­ploitent. Il s’agit no­tam­ment de la di­rec­tion mé­tier, du com­merce, des RH, etc. « Mais le plus ef­fi­cace est de com­men­cer par la DSI qui nor­ma­le­ment doit connaître les lo­gi­ciels uti­li­sés dans l’en­tre­prise, du moins

celles of­fi­cielles » , ex­plique Ar­naud Cas­sagne, di­rec­teur des opé­ra­tions chez l’in­té­gra­teur et pres­ta­taire IT New­lode. Il fau­dra en­suite iden­ti­fier par­mi toutes ces ap­pli­ca­tions, celles qui ex­ploitent des don­nées per­son­nelles. Par « don­nées per­son­nelles », le RGPD en­tend : « Toute in­for­ma­tion se rap­por­tant à une per­sonne phy­sique iden­ti­fiée ou iden­ti­fiable […], no­tam­ment par ré­fé­rence à un iden­ti­fiant, tel qu’un nom, un nu­mé­ro d’iden­ti­fi­ca­tion, des don­nées de lo­ca­li­sa­tion, un iden­ti­fiant en ligne, ou à un ou plu­sieurs élé­ments spé­ci­fiques propres à son iden­ti­té phy­sique, phy­sio­lo­gique, gé­né­tique, psy­chique, éco­no­mique, cultu­relle ou so­ciale. » Cette phase de re­cherche d’in­for­ma­tions se concré­tise par un grand nombre d’en­tre­tiens, qui peuvent, si né­ces­saire, être en par­tie confiés à des consul­tants ex­ternes. Au- de­là du dé­cla­ra­tif, le fu­tur DPO et la DSI peuvent éga­le­ment s’ap­puyer sur des ou­tils tech­niques per­met­tant de lis­ter les ap­pli­ca­tions uti­li­sées dans l’en­tre­prise. Les so­lu­tions com­mer­ciales de sé­cu­ri­té ré­seau et de ges­tion de don­nées in­tègrent ain­si de plus en plus des fonc­tions de ce type. Leur prin­cipe gé­né­ral est de suivre les flux de don­nées échan­gées sur le SI pour iden­ti­fier les lo­gi­ciels ou services qui les ex­ploitent. « Nos ou­tils de sé­cu­ri­té per­mettent de vi­sua­li­ser tous les flux qui passent entre les dif­fé­rentes zones du ré­seau et avec les connexions ex­ternes – In­ter­net, MPLS, etc. Il per­met donc de re­pé­rer toute connexion ap­pli­ca­tive et ai­de­ra à com­plé­ter un in­ven­taire ap­pli­ca­tif » , ex­plique Pas­cal Le Di­gol, Coun­try Ma­na­ger France de Watch­guard, spé­cia­liste amé­ri­cain des so­lu­tions sé­cu­ri­té ré­seau (lire en page 46). Même son de cloche chez Va­ro­nis, spé­cia­liste amé­ri­cain de la gou­ver­nance de don­nées.

Nous col­lec­tons des mé­ta-da­tas qui vont per­mettre de sa­voir où sont les don­nées, qui les uti­lisent et qui en est le pro­prié­taire Christophe Ba­dot, DG de Va­ro­nis France

La maî­trise du Sha­dow IT de­vient un en­jeu ma­jeur pour la sé­cu­ri­té des don­nées Laurent Ma­ré­chal, ex­pert en cybersécurité chez McA­fee Notre so­lu­tion va scan­ner le ré­seau, trou­ver les lo­gi­ciels uti­li­sés par les col­la­bo­ra­teurs et les com­pa­rer avec une base de si­gna­tures Ja­mal La­bed, co-fon­da­teur d’Ea­sy­vis­ta, spé­cia­liste des so­lu­tions de ges­tion de ser­vice IT (ITSM)

Ces ou­tils sur­veillent le SI en ana­ly­sant le com­por­te­ment des per­sonnes et des ma­chines qui ac­cèdent aux don­nées, et en si­gna­lant tout com­por­te­ment anor­mal. « Nous col­lec­tons des mé­ta- da­tas qui vont per­mettre de sa­voir où sont les don­nées, qui les uti­lisent, qui en est le pro­prié­taire et si leur trai­te­ment cor­res­pond à une ac­ti­vi­té nor­male » , ré­sume Christophe Ba­dot, DG France. L’édi­teur fran­çais Ea­sy­vis­ta, spé­cia­liste des so­lu­tions de ges­tion de ser­vice IT (ITSM), pro­pose éga­le­ment ce type de

fonc­tion­na­li­tés. « Notre so­lu­tion est un peu comme l’ERP de la di­rec­tion in­for­ma­tique. Il in­tègre des fonc­tions de Soft­ware As­set Ma­na­ge­ment per­met­tant de dres­ser l’in­ven­taire des lo­gi­ciels uti­li­sés dans l’en­tre­prise. La so­lu­tion va scan­ner le ré­seau, trou­ver les lo­gi­ciels uti­li­sés par les col­la­bo­ra­teurs et les com­pa­rer avec une base de si­gna­tures afin d’iden­ti­fier les dif­fé­rents pro­grammes » , ex­plique Ja­mal La­bed, co-fon­da­teur de l’en­tre­prise. Au- de­là des don­nées tran­si­tant sur le ré­seau, le fu­tur DPO et la DSI doivent éga­le­ment prendre en compte les don­nées sé­den­taires, sto­ckées sur les dif­fé­rentes es­paces de sto­ckage. « En fait, il faut trai­ter les trois dif­fé­rentes ty­po­lo­gies de don­nées dans leur en­semble : les don­nées sto­ckées – par scan de sup­port de sto­ckage comme les BDD par exemple –, les don­nées en cours d’uti­li­sa­tion – maî­trise du co­pier- col­ler et de l’im­pres­sion d’un do­cu­ment sen­sible par exemple – et les don­nées en tran­sit – don­nées sen­sibles en­voyées en WebPost sur un en­vi­ron­ne­ment cloud pu­blic par exemple » , ré­sume ain­si Laurent Ma­ré­chal, ex­pert en cybersécurité chez McA­fee. Dé­bus­quer le « Sha­dow IT » L’in­ven­taire ap­pli­ca­tif doit bien en­ten­du prendre en compte les services cloud. À ce ni­veau, l’un

des prin­ci­paux en­jeux est de dé­ni­cher les services en ligne qui ont échap­pé à la connais­sance de la DSI et qui forment le fa­meux « Sha­dow IT ». Ce phé­no­mène est loin d’être mar­gi­nal. Se­lon une ré­cente étude de McA­fee, «Buil­ding Trust in

a Clou­dy Sky » , de jan­vier 2017, 40 % des services cloud uti­li­sés en en­tre­prise sont ex­ploi­tés par des col­la­bo­ra­teurs en de­hors de tout cadre dé­fi­nit par les équipes IT. Par ailleurs, ces mêmes équipes IT es­timent qu’elles ont une vi­si­bi­li­té de l’ordre de 47 % sur ces ap­pli­ca­tions cloud, uti­li­sées au sein de leur en­tre­prise. « Ce­la si­gni­fie que 53 % des ap­pli­ca­tions cloud in­tro­duites ne bé­né­fi­cient d’au­cun contrôle ! La maî­trise du Sha­dow IT de­vient un en­jeu ma­jeur pour la sé­cu­ri­té des don­nées, et nul doute que le RGPD don­ne­ra un coup d’ac­cé­lé­ra­teur dans la vo­lon­té des en­tre­prises à sé­cu­ri­ser da­van­tage l’usage de ces services cloud » , pour­suit Laurent Ma­ré­chal. Un avis par­ta­gé par l’édi­teur ca­li­for­nien Sky­high Net­works spé­cia­li­sé dans la sé­cu­ri­té des so­lu­tions SaaS. « Chez un de nos clients, pos­sé­dant 15 000 uti­li­sa­teurs, nous avons iden­ti­fié 132 services cloud connus de l’IT et plus de 2 000 services qui avaient

échap­pé à leur connais

sance » , ex­plique Joël Mol­lo, di­rec­teur Eu­rope du Sud. Les so­lu­tions de sé­cu­ri­té et de ges­tion des don­nées peuvent là en­core être uti­li­sées pour dé­ni­cher ce « Sha­dow IT ». La pla­te­forme de Sky­high Net­works ex­ploite ain­si les logs de connexion pour re­pé­rer les services cloud uti­li­sés par les col­la­bo­ra­teurs en les com­pa­rants avec une base de don­nées d’en­vi­ron 25 000 ap­pli­ca­tions SaaS. Pour chaque ser­vice iden­ti­fié, la so­lu­tion donne un « score RGPD » me­su­rant l’adé­qua­tion avec le nou­veau rè­gle­ment eu­ro­péen (low, me­dium ou high). « Notre so­lu­tion ex­ploite l’his­to­rique des connexions et fonc­tionne en­suite au fil de l’eau. Il faut en ef­fet que la car­to­gra­phie des services cloud soit mise à jour ré­gu­liè­re­ment. Notre base compte 500 à 1 000 nou­veaux services tous les mois » , sou­ligne Joël Mol­lo. Par­mi les exemples ty­piques de Sha­dows IT, fi­gurent les so­lu­tions de sto­ckage et de par­tage de fi­chiers ( Drop­box, Box, Google Drive, iC­loud, Su­garSync, etc.). Mais l’on y trouve aus­si des ou­tils de créa­tion et de par­tage de pré­sen­ta­tions (Pre­zi) ou en­core des conver­tis­seurs ou com­pres­seurs de PDF. « Cer­tains ou­tils de com­pres­sion PDF en ligne in­diquent dans leurs condi­tions d’uti­li­sa­tion qu’ils peuvent ac­cé­der aux in­for­ma­tions conte­nues dans les fi­chiers ex­por­tés sur leur plate- forme. Ce­la peut po­ser de graves pro­blèmes avec le RGPD » , pré­cise Joël Mol­lo.

Pré­ci­ser les « fi­na­li­tés de trai­te­ment »

Une fois les lo­gi­ciels ou services iden­ti­fiés, le res­pon­sable des don­nées per­son­nelles doit dé­tailler leur fonc­tion­ne­ment. Ces in­for­ma­tions servent à éta­blir un « re­gistre » qui se­ra son prin­ci­pal sup­port pour l’étape sui­vante qui est la mise en

confor­mi­té. « Ce re­gistre peut se pré­sen­ter sous la forme d’un ta­bleau Ex­cel. C’est par­faite

ment suf­fi­sant » , confie Ar­naud Cas­sagne, di­rec­teur des opé­ra­tions chez l’in­té­gra­teur et pres­ta­taire IT : New­lode. La Cnil pro­pose sur son site un mo­dèle de re­gistre com­pa­tible avec le rè­gle­ment eu­ro­péen ( https:// www. cnil. fr/ fr/car­to­gra­phier-vos-trai­te­ments-de-don­nees-per­son­nelles). Il est consti­tué de deux par­ties. La pre­mière cor­res­pond à la liste des trai­te­ments, avec leur nom, leur date de créa­tion, leur der­nière mise à jour, le res­pon­sable du trai­te­ment, une in­di­ca­tion si des don­nées sont trans­fé­rées hors EU (oui ou non) et une in­di­ca­tion si le trai­te­ment concerne des don­nées sen­sibles (oui ou non). En outre, cette liste in­tègre une co­lonne « fi­na­li­té de trai­te­ment ». Celle- ci est très im­por­tante, car c’est elle qui est dé­cla­rée à la Cnil, et non le lo­gi­ciel ou le ser­vice en tant que tel. Elle cor­res­pond à l’« ob­jec­tif prin­ci­pal » de l’ap­pli­ca­tion. Par­mi les fi­na­li­tés clas­siques : ges­tion des re­cru­te­ments, ges­tion des clients, enquête de sa­tis­fac­tion, sur­veillance des lo­caux, etc. Ce re­gistre in­tègre éga­le­ment des fiches plus dé­taillées pour chaque trai­te­ment, avec des in­for­ma­tions plus pré­cises comme le lieu où les don­nées sont hé­ber­gées, les pays où elles sont éven­tuel­le­ment trans­fé­rées, leurs dé­lais de conservation et les éven­tuelles me­sures de sé­cu­ri­té mises en oeuvre pour les pro­té­ger. « Au stade des pré­pa­ra­tifs, il ne faut pas vi­ser une car­to­gra­phie ex­haus­tive mais plu­tôt la plus com­plète pos­sible » , sou­ligne Bru­no Rasle, de l’AFCDP. Ce­la peut dé­jà prendre plu­sieurs mois à réa­li­ser. « Nous re­com­man­dons en­suite une ap­proche par “passes ”, en se pré­oc­cu­pant d’abord des prin­ci­paux trai­te­ments, puis, dans un se­cond temps, en al­lant pro­gres­si­ve­ment dans un plus haut ni­veau de dé­tails » , in­dique le res­pon­sable. En­fin, l’AFCDP rap­pelle que ce re­gistre de­vra être mis à jour ré­gu­liè­re­ment. Dans l’idéal, la car­to­gra­phie des trai­te­ments de don­nées per­son­nelles de­vrait même être to­ta­le­ment re­vue chaque an­née. « Ce n’est pas un do­cu­ment à réa­li­ser une seule fois, mais bien un sup­port de tra­vail qui évo­lue­ra en per­ma­nence » , conclut Bru­no Rasle.

Il ne faut pas vi­ser une car­to­gra­phie ex­haus­tive, mais plu­tôt la plus com­plète pos­sible Bru­no Rasle dé­lé­gué gé­né­ral de l’AFCDP, as­so­cia­tion fran­çaise re­pré­sen­tant les CIL

Exemple de fiche de trai­te­ment de don­nées à in­té­grer dans le re­gistre du CIL ou du fu­tur DPO.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.