* avoir un backup de vos datas/systèmes qui MARCHE (ie: testé et validé)
* garder vos clés privés sur plusieurs media amovibles avec vos bandes de sauvegardes, dans deux coffres de deux banques différentes situées dans deux villes différentes séparées de 800 km. Chiffrer des backups qu'on ne peut pas relire...
* garder vos bandes de backups dans un coffre fermé (pas posées sur le bureau)
* attacher physiquement vos serveurs aux racks/armoires/sol/votre belle-mère
* fermer a clé l'armoire des baies de disques extractibles a chaud (deux disques d'un même RAID 5 arrachés a la baie provoquent une perte immédiate de TOUTES vos données du RAID)
* lacher un (et rien qu'un) pitbull affamé dans la salle serveurs
* utilisez des sondes/switch/anti-sniffers et surtout, jettez un coup d'oeil a vos logs en prenant votre café le matin (et rediriger les logs et vos backups sur /dev/null n'est généralement pas une bonne idée, sauf si vous êtes le BoFH)
# Re: Cryptage de volume sous kernel 2.4.22/2.6.x
Posté par Matho (site web personnel) . En réponse au journal Cryptage de volume sous kernel 2.4.22/2.6.x. Évalué à 1.
* garder vos clés privés sur plusieurs media amovibles avec vos bandes de sauvegardes, dans deux coffres de deux banques différentes situées dans deux villes différentes séparées de 800 km. Chiffrer des backups qu'on ne peut pas relire...
* garder vos bandes de backups dans un coffre fermé (pas posées sur le bureau)
* attacher physiquement vos serveurs aux racks/armoires/sol/votre belle-mère
* fermer a clé l'armoire des baies de disques extractibles a chaud (deux disques d'un même RAID 5 arrachés a la baie provoquent une perte immédiate de TOUTES vos données du RAID)
* lacher un (et rien qu'un) pitbull affamé dans la salle serveurs
* utilisez des sondes/switch/anti-sniffers et surtout, jettez un coup d'oeil a vos logs en prenant votre café le matin (et rediriger les logs et vos backups sur /dev/null n'est généralement pas une bonne idée, sauf si vous êtes le BoFH)