Bonjour,
Et en cas de problème, quand il faudra déclarer à la CNIL qu'il y a eu une fuite, et que lors de l'audit on découvre que tout n'a pas été mis en œuvre pour protéger les données personnelles, l'amende va piquer.
Quel enjeu pourrait bien primer sur la protection de la vie d'autrui ?
Je n'aimerais vraiment pas avoir à entendre un jour qu'un-e de mes proches s'est retrouvée exposé-e personnellement à cause d'un-e sysadmin qui a désactivé des protections pourtant critiques, tout cela pour économiser quelques cycles CPU...
Bien cordialement, -- Maxime DERCHE
Le 18/12/2019 à 18:26, frsag@jack.fr.eu.org a écrit :
Oui C'est pour ça que sur mes serveurs de stockage (par exemple), ou de databases (autre exemple), je désactive tout ça
On 12/18/19 6:12 PM, Jonathan Leroy - Inikup via FRsAG wrote:
Le mer. 18 déc. 2019 à 09:15, Greg greg-frsag@duchatelet.net a écrit :
Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs...
Question : hors environnements dans lesquels le CPU est partagé entre plusieurs utilisateurs et sur lesquels ont ne maîtrise pas forcément le code exécuté (hôte de virtualisation ou hébergement mutualisé), est-il réellement nécessaire de patcher ces failles ?
Je n'en suis pas convaincu, la plupart (totalité ?) n'étant pas exploitables sans un accès préalable à la machine.
Liste de diffusion du FRsAG http://www.frsag.org/