[FRsAG] Application RGPD dans les petites structures

Duchet Rémy remy at duchet.eu
Mar 15 Mai 14:54:28 CEST 2018


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 at frsag.org> De la part de un+FRsAG at pontesprit.net
Envoyé : mardi, 15 mai 2018 14:42
À : frsag at 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.






-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20180515/8d1bc4fb/attachment.html>


Plus d'informations sur la liste de diffusion FRsAG