Dans la fréquence des mises a jour ? comment vérifier si une mise à jour va faire cracher votre serveur en production ...
La fréquence est moins importante que la qualité de la mise à jour, et chaque fois que c'est possible on prend tjrs la mise à jour connue stable mais jamais la dernière chronologique, au cas où des problèmes non-découverts existeraient...
Accessoirement lorsque c'est possible, on maquette une copie ISO-prod et on test dessus d'abord, plusieurs jours, et on teste en particulier la possibilité de retour arrière.
Fréquence d'analyse d'état de santé des disques durs ?
Chaque down-time programmé, on doit en profiter pour le faire, et si on en a pas de down-time prévu, on en fait 1 au minimum lors d'un reboot programmé, pour mise à jour ou pour le reboot annuel minimal nécessaire (même si en général on ne le fait jamais on devrait ).
La config minimal en sécurité ?
Bha là ça dépend de la structure, mais de façon général aucun accès possible hors ssh par clef, aucune connections par password hormis localement. Chaque machine à son démon de blacklist, de surveillance rootkits etc... toute salle informatique doit avoir son firewall hardware, avec jumper qui interdit électriquement la mise à jour du firmware. et bien sur en entrée on a 4 firewall redondés 2 à 2, à la suite. Une fois par an au moins, une campagne de type nessus ou tiger d'analyse des risques et d'estimation des mises à jours de sécurités à faire doit être pratiqué (_là pareil on le fait plus quand on a le temps que de façon planifié, genre l'été _)
# bha dison pour faire simple
Posté par kuroineko . En réponse au message Bonne pratique administration système. Évalué à 1.
La fréquence est moins importante que la qualité de la mise à jour, et chaque fois que c'est possible on prend tjrs la mise à jour connue stable mais jamais la dernière chronologique, au cas où des problèmes non-découverts existeraient...
Accessoirement lorsque c'est possible, on maquette une copie ISO-prod et on test dessus d'abord, plusieurs jours, et on teste en particulier la possibilité de retour arrière.
Chaque down-time programmé, on doit en profiter pour le faire, et si on en a pas de down-time prévu, on en fait 1 au minimum lors d'un reboot programmé, pour mise à jour ou pour le reboot annuel minimal nécessaire (même si en général on ne le fait jamais on devrait ).
Bha là ça dépend de la structure, mais de façon général aucun accès possible hors ssh par clef, aucune connections par password hormis localement. Chaque machine à son démon de blacklist, de surveillance rootkits etc... toute salle informatique doit avoir son firewall hardware, avec jumper qui interdit électriquement la mise à jour du firmware. et bien sur en entrée on a 4 firewall redondés 2 à 2, à la suite. Une fois par an au moins, une campagne de type nessus ou tiger d'analyse des risques et d'estimation des mises à jours de sécurités à faire doit être pratiqué (_là pareil on le fait plus quand on a le temps que de façon planifié, genre l'été _)