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.