Application RGPD dans les petites structures
Bonjour la liste. Tout le monde semble avoir la tête dans la RGPD en ce moment. On voit les CGV et CGU des gros sites changer, les applications se mettre à jour. La marmite a fait un article assez complet pour les bloggeurs : https://wpmarmite.com/rgpd-wordpress/ mais pour le reste ? Concrètement ? Dans le principe je trouve ça bien mais au final, j'ai l'impression d'être de plus en plus déconnecté de notre métier. - Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups. - Si on prend une petite structure, un serveur AD avec SQL Serveur, 10 personnes, un truc classique. Pas d'accueil de public. * Est-ce que l'applicatif métier uniquement conforme suffit pour leur base métier ou bien faut-il crypter la partition D qui héberge la base SQL-server ? * Si on doit crypter aussi la partition C, cela veut dire qu'il faut obligatoirement un KVM IP ou une console HP iLO / Intel RMM... pour pouvoir saisir la clé de décryptage du disque dur lors d'un reboot à distance du serveur ? - Office 365 a mis à jour son portail mais c'est une usine à gaz. Quelqu'un aurait des informations claires et simples adaptées aux petites structures par hasard ? Merci pour vos retours. Vincent
Bonjour Je vois, Vincent, que tu as aussi commenté le post du blog :-) Ce que je pense c'est que oui, il faudrait supprimer tous les données perso, donc supprimer les données des backups ou s'assurer que les sauvegardes sont chiffrées (ce qui rentre JE CROIS dans le cadre d'une "bonne" protection des données utilisateurs). Et oui de toute manière, je pense qu'il faut conserver un registre des demandes d'effacement. Je n'ai pas d'info sur l'application aux petites structures. Le 14 mai 2018 à 10:37, Vincent Duvernet <vincent.duvernet@nolme.com> a écrit :
Bonjour la liste.
Tout le monde semble avoir la tête dans la RGPD en ce moment. On voit les CGV et CGU des gros sites changer, les applications se mettre à jour. La marmite a fait un article assez complet pour les bloggeurs : https://wpmarmite.com/rgpd-wordpress/
mais pour le reste ? Concrètement ? Dans le principe je trouve ça bien mais au final, j'ai l'impression d'être de plus en plus déconnecté de notre métier.
- Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups.
- Si on prend une petite structure, un serveur AD avec SQL Serveur, 10 personnes, un truc classique. Pas d'accueil de public. * Est-ce que l'applicatif métier uniquement conforme suffit pour leur base métier ou bien faut-il crypter la partition D qui héberge la base SQL-server ? * Si on doit crypter aussi la partition C, cela veut dire qu'il faut obligatoirement un KVM IP ou une console HP iLO / Intel RMM... pour pouvoir saisir la clé de décryptage du disque dur lors d'un reboot à distance du serveur ?
- Office 365 a mis à jour son portail mais c'est une usine à gaz.
Quelqu'un aurait des informations claires et simples adaptées aux petites structures par hasard ?
Merci pour vos retours.
Vincent _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Emmanuel Jacquet manu@formidable-inc.net
(je ne suis pas juriste ..) On 05/14/2018 10:37 AM, Vincent Duvernet wrote:
- Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups.
Absolument pas ! Mme Michu de demande de supprimer ses données, tu dois supprimer ses données, c'est à dire être dans l'impossibilité de les récupérer Autrement dit, tu dois supprimer les données "live" mais également les données contenu dans les backup La procédure pour mettre ceci en application n'est pas précisée .. Par rapport au chiffrement, l'encryption at rest (!!) est plutôt obligatoire : ici (gros groupe, avec plein de juristes etc), nous avons l'obligation de chiffrer les backups "at rest", et il est fortement conseillé de chiffrer les data live également (ils sont plus compréhensifs du fait de l'aspect performance que cela peut impliquer, m'enfin) M'enfin
J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir : En hard HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives" En soft Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm Avez-vous des retours au niveau performance utilisation de ces différents cas ? ou d'autres cas qui se seraient éventuellement présentés a vous ? Il me semble que pour couvrir le cas de fuite des données " par la fenetre sous le bras " en cas de vol d'infra, ce cas est a envisager, Dans le cas d'un datacenter, peut être moins, Merci, Kévin -----Message d'origine----- De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de frsag@jack.fr.eu.org Envoyé : lundi 14 mai 2018 11:05 À : frsag@frsag.org Objet : Re: [FRsAG] Application RGPD dans les petites structures (je ne suis pas juriste ..) On 05/14/2018 10:37 AM, Vincent Duvernet wrote:
- Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups.
Absolument pas ! Mme Michu de demande de supprimer ses données, tu dois supprimer ses données, c'est à dire être dans l'impossibilité de les récupérer Autrement dit, tu dois supprimer les données "live" mais également les données contenu dans les backup La procédure pour mettre ceci en application n'est pas précisée .. Par rapport au chiffrement, l'encryption at rest (!!) est plutôt obligatoire : ici (gros groupe, avec plein de juristes etc), nous avons l'obligation de chiffrer les backups "at rest", et il est fortement conseillé de chiffrer les data live également (ils sont plus compréhensifs du fait de l'aspect performance que cela peut impliquer, m'enfin) M'enfin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Le 14/05/2018 à 11:47, Kevin CHAILLY | Service Technique a écrit :
J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir :
En hard
HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives"
En soft
Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm
Note que dans le cas d'un système matériel, tu as vivement intérêt à disposer de matériel de secours, avec la même carte, et les mêmes puces sur les cartes, parce que sinon, tu ne récupères pas tes données en cas de panne. C'est d'ailleurs amusant, car une garantie de disponibilité des données est également demandée par le RGPD. En crypto logicielle, tu as intérêt à bien t'assurer de la cohérence des systèmes de stockage et de fichiers, parce qu'un volume chiffré corrompu par une brutale panne de courant te fera mal au crâne. Bien cordialement, -- Maxime DERCHE
Je voudrais pas troller mais encore une fois, des petites structures vont devoir déployer des moyens techniques peu ou pas à leur portée, parce que ces dernières années quelques (très) grosses structures se sont fait trouer le cul, parfois sans l’admettre à leurs clients ou aux autorités, et probabement sans rien changer ensuite. On se moque de qui…. Ca va par contre probablement enrichir plein d’acteurs du secteur. On 14 mai 2018 12:14 +0200, Maxime DERCHE <maxime@mouet-mouet.net>, wrote:
Bonjour,
Le 14/05/2018 à 11:47, Kevin CHAILLY | Service Technique a écrit :
J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir :
En hard
HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives"
En soft
Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm
Note que dans le cas d'un système matériel, tu as vivement intérêt à disposer de matériel de secours, avec la même carte, et les mêmes puces sur les cartes, parce que sinon, tu ne récupères pas tes données en cas de panne.
C'est d'ailleurs amusant, car une garantie de disponibilité des données est également demandée par le RGPD.
En crypto logicielle, tu as intérêt à bien t'assurer de la cohérence des systèmes de stockage et de fichiers, parce qu'un volume chiffré corrompu par une brutale panne de courant te fera mal au crâne.
Bien cordialement, -- Maxime DERCHE
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Sans troller non plus, mettre une couche de device-mapper, c'est à la portée de n'importe quel sysadmin; On 05/14/2018 12:38 PM, David Ponzone wrote:
Je voudrais pas troller mais encore une fois, des petites structures vont devoir déployer des moyens techniques peu ou pas à leur portée, parce que ces dernières années quelques (très) grosses structures se sont fait trouer le cul, parfois sans l’admettre à leurs clients ou aux autorités, et probabement sans rien changer ensuite. On se moque de qui…. Ca va par contre probablement enrichir plein d’acteurs du secteur.
On 14 mai 2018 12:14 +0200, Maxime DERCHE <maxime@mouet-mouet.net>, wrote:
Bonjour,
Le 14/05/2018 à 11:47, Kevin CHAILLY | Service Technique a écrit :
J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir :
En hard
HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives"
En soft
Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm
Note que dans le cas d'un système matériel, tu as vivement intérêt à disposer de matériel de secours, avec la même carte, et les mêmes puces sur les cartes, parce que sinon, tu ne récupères pas tes données en cas de panne.
C'est d'ailleurs amusant, car une garantie de disponibilité des données est également demandée par le RGPD.
En crypto logicielle, tu as intérêt à bien t'assurer de la cohérence des systèmes de stockage et de fichiers, parce qu'un volume chiffré corrompu par une brutale panne de courant te fera mal au crâne.
Bien cordialement, -- Maxime DERCHE
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
re, Le 14/05/2018 à 12:38, David Ponzone a écrit :
Je voudrais pas troller mais encore une fois, des petites structures vont devoir déployer des moyens techniques peu ou pas à leur portée, parce que ces dernières années quelques (très) grosses structures se sont fait trouer le cul, parfois sans l’admettre à leurs clients ou aux autorités, et probabement sans rien changer ensuite. On se moque de qui…. Ca va par contre probablement enrichir plein d’acteurs du secteur.
Sans troll : * le RGPD vise à établir la liberté de circulation des données personnelles au sein de l'UE, c'est donc un texte /largement/ destiné à favoriser l'activité commerciale, y compris au détriment des droits légitimes des personnes ; * petite structure ne signifie pas mauvaise structure (traite les données d'autrui comme tu voudrais qu'autrui traite les tiennes) ; * les "autres acteurs" ne s'enrichiront qu'auprès des structures qui choisissent de considérer la sécurité des données personnelles que comme une contrainte qu'il convient d'externaliser ; * la référence à une pratique sexuelle me semble choquante et hors de propos. Bien cordialement, -- Maxime DERCHE
Mais non c’est pas choquant, c’est juste une expression imagée, certes du registre vulgaire, qui est là pour faire remarquer que les gros, avec leurs discours rassurants, sont toujours les premiers à se faire avoir. Mes excuses si je t’ai choqué. On 14 mai 2018 12:59 +0200, Maxime DERCHE <maxime@mouet-mouet.net>, wrote:
re,
Le 14/05/2018 à 12:38, David Ponzone a écrit :
Je voudrais pas troller mais encore une fois, des petites structures vont devoir déployer des moyens techniques peu ou pas à leur portée, parce que ces dernières années quelques (très) grosses structures se sont fait trouer le cul, parfois sans l’admettre à leurs clients ou aux autorités, et probabement sans rien changer ensuite. On se moque de qui…. Ca va par contre probablement enrichir plein d’acteurs du secteur.
Sans troll : * le RGPD vise à établir la liberté de circulation des données personnelles au sein de l'UE, c'est donc un texte /largement/ destiné à favoriser l'activité commerciale, y compris au détriment des droits légitimes des personnes ; * petite structure ne signifie pas mauvaise structure (traite les données d'autrui comme tu voudrais qu'autrui traite les tiennes) ; * les "autres acteurs" ne s'enrichiront qu'auprès des structures qui choisissent de considérer la sécurité des données personnelles que comme une contrainte qu'il convient d'externaliser ; * la référence à une pratique sexuelle me semble choquante et hors de propos.
Bien cordialement, -- Maxime DERCHE
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 14/05/2018 11:47, Kevin CHAILLY | Service Technique wrote:
J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir :
En hard
HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives"
En soft
Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm
Avez-vous des retours au niveau performance utilisation de ces différents cas ? ou d'autres cas qui se seraient éventuellement présentés a vous ? Je dm-crypte ( linux/LVM) pas mal de chose depuis plusieurs années ( Perso & pro):
C'est assez facile à mettre en oeuvre ( 10s quand on sait) et à gérer, les performance sont la. Par exemple sur un serveur "moyen" de 2013: time cryptsetup benchmark ... # Algorithm | Key | Encryption | Decryption aes-cbc 128b 454.0 MiB/s 1135.0 MiB/s ... aes-cbc 256b 400.6 MiB/s 990.1 MiB/s aes-xts 256b 793.2 MiB/s 802.9 MiB/s aes-xts 512b 749.1 MiB/s 739.2 MiB/s ... # ElapsedRealTime=28.514 KernelCPUSecond=23.534 UserCPUSecond=4.455 ( 100%cpu) Soit plus que le débit de mes RAID, sachant que en pratique je suis surtout limité par les IO/s (comme presque tous ?) ou le cryptage n'a pas d'impact et que les serveurs on un usage CPU très modéré. Le cache SSD n'est pas crypté, à voir. J'imagine des performances comparable sous MSWindows puisque le cryptage est matériel par le cpu. Par contre je n'ai aucun avis sur la facilité de mise en oeuvre sur cet OS. Ca me parait très correcte. Mesuré au doigt mouillé ( et au monitoring) en comparent avant/après et avec/sans, pour un usage "moyen", c'est complètement transparent. La seul contrainte (qui peut être assez importante selon votre cas): un homme doit taper le passwd au boot/démarrage du(s) service(s). Avec de la redondance et quelques reboot par an par un admin, c'est gerable sans effort. C'était la minute témoignage moyen qui se croit représentatif :-) Cordialement.
Pour rappel, les données peuvent être chiffrées par différent moyen, à choisir en fonction du risque. Par exemple, vol de matériel, alors les SEP avec KMS. Quand il s’agit de vol de données, le fait d’avoir la données stockée avec chiffrement sur les HDD ne sert à pas grand-chose. Lors d’une intrusion, le pirate peut tout à fait, par exemple, utiliser du Sql Injection, et la, données chiffrés ou pas, ça ne changera rien. L’application doit pouvoir utiliser un chiffrement à l’écriture / lecture avec une clé (de préférence pas sur le même serveur). De sorte qu’un dump de la DB ne soit pas facilement lisible. De : FRsAG <frsag-bounces@frsag.org> De la part de un+FRsAG@pontesprit.net Envoyé : mardi, 15 mai 2018 14:42 À : frsag@frsag.org Objet : Re: [FRsAG] Application RGPD dans les petites structures On 14/05/2018 11:47, Kevin CHAILLY | Service Technique wrote: J'en profite pour rebondir sur le sujet du "Crypt live", qui effectivement devrait être de plus en plus demandé a l'avenir : En hard HP propose Smart Array SR Secure Encryption, Les "Self Encrypting Drives" En soft Microsoft propose BitLocker, sur les versions récentes de windows. ZFS propose la crypto, très bon pour du *BSD, un peu jeune pour du ZFS-On-Linux. LVM propose aussi de crypter l'ensemble du système. Mac OS X propose FileVault VMware propose de crypter les vm Avez-vous des retours au niveau performance utilisation de ces différents cas ? ou d'autres cas qui se seraient éventuellement présentés a vous ? Je dm-crypte ( linux/LVM) pas mal de chose depuis plusieurs années ( Perso & pro): C'est assez facile à mettre en oeuvre ( 10s quand on sait) et à gérer, les performance sont la. Par exemple sur un serveur "moyen" de 2013: time cryptsetup benchmark ... # Algorithm | Key | Encryption | Decryption aes-cbc 128b 454.0 MiB/s 1135.0 MiB/s ... aes-cbc 256b 400.6 MiB/s 990.1 MiB/s aes-xts 256b 793.2 MiB/s 802.9 MiB/s aes-xts 512b 749.1 MiB/s 739.2 MiB/s ... # ElapsedRealTime=28.514 KernelCPUSecond=23.534 UserCPUSecond=4.455 ( 100%cpu) Soit plus que le débit de mes RAID, sachant que en pratique je suis surtout limité par les IO/s (comme presque tous ?) ou le cryptage n'a pas d'impact et que les serveurs on un usage CPU très modéré. Le cache SSD n'est pas crypté, à voir. J'imagine des performances comparable sous MSWindows puisque le cryptage est matériel par le cpu. Par contre je n'ai aucun avis sur la facilité de mise en oeuvre sur cet OS. Ca me parait très correcte. Mesuré au doigt mouillé ( et au monitoring) en comparent avant/après et avec/sans, pour un usage "moyen", c'est complètement transparent. La seul contrainte (qui peut être assez importante selon votre cas): un homme doit taper le passwd au boot/démarrage du(s) service(s). Avec de la redondance et quelques reboot par an par un admin, c'est gerable sans effort. C'était la minute témoignage moyen qui se croit représentatif :-) Cordialement.
On 15/05/2018 14:54, Duchet Rémy wrote:
Pour rappel, les données peuvent être chiffrées par différent moyen, à choisir en fonction du risque.
Par exemple, vol de matériel, alors les SEP avec KMS.
Quand il s’agit de vol de données, le fait d’avoir la données stockée avec chiffrement sur les HDD ne sert à pas grand-chose.
Lors d’une intrusion, le pirate peut tout à fait, par exemple, utiliser du Sql Injection, et la, données chiffrés ou pas, ça ne changera rien.
L’application doit pouvoir utiliser un chiffrement à l’écriture / lecture avec une clé (de préférence pas sur le même serveur).
De sorte qu’un dump de la DB ne soit pas facilement lisible.
Tout a fait, c'est pour cela que cette technique n'est pas généralise dans le service. ( certain serveurs sont difficiles à atteindre physiquement, même pour l'admin, mais c'est une autre histoire :-/ ) L'application elle même peut être piraté et utilisé pour récupérer les informations sensible, la mémoire du serveur scanné pour rechercher le passwd: si le serveur est hacké, on est mal et ni dm-crypte, ni cryptage "applicatif" ne protégera du vol. D'ou l'usage pragmatique et essentiellement limité à contrer un vol physique des HD ( ainsi que un peu de politique interne :-(, il faut bien le constater ) Si vous avez des idées pour gérer ce point intelligemment, ça m'intéresse. Je répondais surtout à la question, que je trouve néanmoins pertinente, des performances.
Le 14 mai 2018 11:04:42 GMT+02:00, frsag@jack.fr.eu.org a écrit :
(je ne suis pas juriste ..)
On 05/14/2018 10:37 AM, Vincent Duvernet wrote:
- Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups.
Absolument pas ! Mme Michu de demande de supprimer ses données, tu dois supprimer ses données, c'est à dire être dans l'impossibilité de les récupérer Autrement dit, tu dois supprimer les données "live" mais également les données contenu dans les backup La procédure pour mettre ceci en application n'est pas précisée ..
La solution chez Google a priori, c’est que les backups sont chiffrés avec une clé différente pour chaque utilisateur, sur une demande de suppression des données ils détruisent la clé (une partie des backups étant offline, ce serait trop contraignant d’aller chercher partout). Je n’ai aucune idée de comment c’est implémenté en pratique, mais ça doit pas être trivial. Notez que c’est pas parfait non plus, dans 20 ans quand la crypto utilisée sera cassée d’une manière ou d’une autre, les données seront à nouveau lisible dans l’absolu. Mais je suppose qu’au moins ça montre que des efforts sont faits.
Bonjour, Le coup de la sauvegarde bien vu, je n'avais pas encore vu ce sujet abordé. Je te répondrais que les CGV (avant RGPD j’irais rafraichir dans quelques semaines / mois) des gros Amazon AWS, Dropbox, Google Drive et Office 365 disent clairement : nous ne vous garantissons pas la correcte suppression de vos données lorsque vous les supprimez. Un adminsys pense aux sauvegardes ou aux disques dur retirés à chaud car présentant des défaillances hardware qui en offline ne reçoit pas l'ordre de suppression. La personne qui lit mieux va mettre en rapport cette phrase avec celle sur la propriété des données : vous nous cédez un droit d'usage non limité dans le temps et non limité géographiques pour toute exploitation de vos données. Et là on en comprend la finalité qui est d'éplucher les données et de les revendre. On va donc voir comment ils évoluent sur ces sujets. Mais dans la problématique petite entreprise, je pense que les demandes de suppression vont pas être légion et une simple liste dans un tableur devrait faire l'affaire. A l'inverse la clause de portabilité me fait plus peur car si tu fournis un export de ta base, Mme Michu aidée de son petit fil informaticien dira c'est pas un format standardisé et donc faut me fournir les données dans tel ou tel format. Et là c'est le coup de développement pour convertir les données qui risque d'affoler tout le monde. Pour la partie serveur, désolé mais on ne dit pas crypter (ça n'existe pas en français) mais chiffrer, ça pique les yeux sinon. Chiffrer le disque D c'est un bon début, chiffrer le C c'est encore mieux. Mais il faut se poser la question autrement. Le RGPD est là pour prévenir et sanctionner les fuites de données personnelles. Un simple fichier excel avec les prospects ou clients d'une entreprise sont des données personnelles, si la clef usb sur laquelle se trouve le fichier est perdu et que cela fuite l'entreprise est attaquable. C'est clairement plus ce risque que tu trouveras dans les TPE / PME voir grand compte, l'humain est la faille. J'ai vu deux comportements pour l'approche RGPD dans les TPE / PME : - le premier le pire, on s'en fout on va pas tout changer pour une loi, si ça fuite et qu'on se fait pénaliser par la CNIL on fermera boutique pour renaître ailleurs ... - le deuxième est de dire on sait qu'on est pas carré donc on fait le maximum possible pour prévenir les fuites au niveau technique et au niveau humain. Le but c'est de documenter toutes les sécurités et prouver les investissements qui ont été fait : audit du code des développeurs, confier l'admin des serveurs à des adminsys et pas aux dev, chiffrer partout où c'est possible sans refaire du dev (le serveur plutôt que la base de donnée), sensibiliser sur l'échange d'informations pour les humains en proposant d'autres solutions d'échanges, ... Mais même dans ce deuxième cas, les entreprises savent qu'elles pourront avoir des fuites de données car chiffrer les disques des ordis portables ou des smartphones c'est contraignants et donc ils sont pas à l'abris d'un vol dans les transports ou de la perte d'une clef usb non chiffrée par exemple. Mais comme ils auront fait la documentation nécessaires et pris des tiers pour l'audit de code / sécu, l'infogérance pour les serveurs ils pourront démontrer qu'ils ont fait le nécessaire mais que la faille reste possible et humaine et seront donc moins sanctionné que les premiers. Voilà l'état des lieux que j'en ai. Le 14/05/2018 à 10:37, Vincent Duvernet a écrit :
Bonjour la liste.
Tout le monde semble avoir la tête dans la RGPD en ce moment. On voit les CGV et CGU des gros sites changer, les applications se mettre à jour. La marmite a fait un article assez complet pour les bloggeurs : https://wpmarmite.com/rgpd-wordpress/
mais pour le reste ? Concrètement ? Dans le principe je trouve ça bien mais au final, j'ai l'impression d'être de plus en plus déconnecté de notre métier.
- Pour les backups par exemple : * Mme Michu (encore et toujours elle) te demande de lui envoyer ses données et de les supprimer. Ce que tu fais * Mer... tu dois restaurer un ancien backup suite à un travail de stagiaire restaurant par la même occasion les datas de Mme Michu. * Wtf ? Il faut refaire la procédure me direz-vous. Donc, il faut garder un fichier contenant la liste des personnes à re-virer en cas de restauration de backup. Et donc ce fichier contient une donnée personnelle. Et on ne peut pas forcément détruire rétroactivement dans tous les backups.
- Si on prend une petite structure, un serveur AD avec SQL Serveur, 10 personnes, un truc classique. Pas d'accueil de public. * Est-ce que l'applicatif métier uniquement conforme suffit pour leur base métier ou bien faut-il crypter la partition D qui héberge la base SQL-server ? * Si on doit crypter aussi la partition C, cela veut dire qu'il faut obligatoirement un KVM IP ou une console HP iLO / Intel RMM... pour pouvoir saisir la clé de décryptage du disque dur lors d'un reboot à distance du serveur ?
- Office 365 a mis à jour son portail mais c'est une usine à gaz.
Quelqu'un aurait des informations claires et simples adaptées aux petites structures par hasard ?
Merci pour vos retours.
Vincent _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Question pour les sysadmin aussi. On a des UTM Sophos (mais c'est pareil avec la concurrence). On a des adresses IP dans les logs. Certaines fonctions permettent de mettre cela en corrélation avec un utilisateur de l'AD. Tout ceci à but de sécurité c'est bien. Mais c'est aussi des données personnelles. Quelqu'un a une corde et un tabouret ? Vincent
Si ces données servent à établir une responsabilité en cas de malveillance ou à des fins légales vis à vis de la justice, la loi Français impose 1 an de logs à garder et c'est du coup plus fort que la RGPD car si un référé de tribunal vient te demander les logs d'accès et que tu as moins d'un an alors c'est le responsable de cette purge précoce qui sera sanctionner. D'après nos conseils, les logs n'entrent pas dans le spectre RGPD pendant les 1 an de rétention, par contre si tu les gardes au delà pour que ton client en fasse des études statistiques, des traitements divers sur qui est venu et revenu sur un site ecommerce par exemple, là tu dois anonymiser au delà des 1 an. Bref vivement que la Quadrature et FDN arrivent à faire tomber la loi FR sur les 1 an de log pour qu'on revienne sur le droit EU qui parle de 3 mois il me semble. Le 15/05/2018 à 10:11, Vincent Duvernet a écrit :
Bonjour,
Question pour les sysadmin aussi.
On a des UTM Sophos (mais c'est pareil avec la concurrence). On a des adresses IP dans les logs. Certaines fonctions permettent de mettre cela en corrélation avec un utilisateur de l'AD. Tout ceci à but de sécurité c'est bien. Mais c'est aussi des données personnelles.
Quelqu'un a une corde et un tabouret ?
Vincent _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (10)
-
Bruno Pagani -
David Ponzone -
Duchet Rémy -
Emmanuel Jacquet -
frsag＠jack.fr.eu.org -
Kevin CHAILLY | Service Technique -
Maxime DERCHE -
un+FRsAG＠pontesprit.net -
Vincent Duvernet -
Wallace