Comment faire face aux incidents « logiciels » Comment faire face aux incidents « logiciels » ? ADIRA / Clusir le 5 mars 2002 Benoit Champouillon : Responsable Technique Informatique Groupe SEB

Plan 1. La problématique Les vulnérabilités Quelques exemples Les difficultés 2. Les solutions

1. L ’indisponibilité du système d ’information Les causes d’indisponibilité non planifiée défaillance matérielle (panne ou sinistre) malveillance (ex déni de service) l’erreur de manipulation le bug logiciel l ’erreur de paramétrage qui conduit à un arrêt la pollution de données provoquée par un programme erroné les virus ...

1. Les causes les plus fréquentes ? Quelle est la cause de notre dernière interruption de service ? Probablement pas la malveillance Probablement pas une défaillance matérielle Peut-être une infection virus Certainement une défaillance « logicielle » … bug logiciel erreur paramétrage erreur de manipulation pollution de données due à un programme erroné

1. Pourquoi ces vulnérabilités Le logiciel zéro défaut n’existe pas encore les méthodes de conception/programmation ne permettent pas de garantir le fonctionnement le coût de la qualité dans les développements est souvent contradictoire avec les contraintes de rentabilité ou de délai les moyens de test permettent rarement de simuler les vraies conditions de production et ne sont pas exhaustifs les moyens pour éviter l ’erreur de manipulation sont encore limités ou complexes à mettre en œuvre

1. Quelques exemples Groupe Seb bug logiciel août 1999 : corruption de block BD Oracle/SAP suite à un bug AIX (36 heures) nov 2000 : gel serveur puis corruption BD Oracle/SAP suite à un bug AIX+bug microcode (96 heures) fév 2002 : accès impossible à un data center depuis le réseau WAN suite à un incident logiciel sur un switch Nortel Networks (45 min) erreur paramétrage fév 2002 : interruption de processes Oracle suite à paramétrage mémoire incorrect (1 heure) erreur de manipulation fév 2002 : e-mails entrants interrompus pendant 36 heures suite à erreur de manipulation d ’un opérateur Oleane sur domaine moulinex.fr pollution de données due à un programme erroné sept 2000 : une erreur de sélection dans un programme entraîne la relance de transactions déjà exécutées

1. … malgré de nombreuses précautions Séparation des environnements développement, test, production Environnement de test très proche de la production (matériel, versions logiciels, données) Limitation volontaire des modifications pendant les périodes critiques du business Applications des correctifs ou nouvelles versions avec un décalage dans le temps pour éviter « d ’essuyer les plâtres » Test des solutions de restauration Eviter de modifier les solutions qui fonctionnent ...

1. Les difficultés Le logiciel zéro défaut n’existe pas encore les méthodes de conception/programmation ne permettent pas de garantir le fonctionnement le coût de la qualité dans les développements est souvent contradictoire avec les contraintes de rentabilité ou les délais Nous sommes souvent contraints de mettre en production de nouvelles version logicielles pour bénéficier d’évolutions fonctionnelles ou techniques (performances, nouveaux matériels) les moyens de test permettent rarement de simuler les vraies conditions de production et ne sont pas exhaustifs les moyens pour éviter l ’erreur de manipulation sont encore limités ou complexes à mettre en œuvre Même si la redondance des serveurs d ’application est souvent possible, le serveur de données reste un « single point of failure »

Plan 1. La problématique Les vulnérabilités Quelques exemples Les difficultés 2. Les solutions Les solutions à mettre en oeuvre Exemples

2. Les solutions Pour faire face aux défaillances matérielles, les solutions sont nombreuses : redondances (disques, cpu, mémoire, alim, …) hot swap (disques, mémoire, alim, …) clustering même si parfois difficile à mettre en œuvre site de secours pour faire face à un sinistre majeur Contre la malveillance, les solutions existent également : anti-virus, firewall, gestion des accès, détection d ’intrusion, …  il reste encore souvent à mettre en œuvre et à gérer Mais face à l ’incident « logiciel », quelles parades ?

2. Les solutions préventives Le renforcement des tests et des procédures de mise en production oui pour les développements spécifiques mais nous n’avons pas la maîtrise du plan de test des éditeurs. Quand aurons-nous une mesure de la qualité des logiciels ? Stratégie pour appliquer les nouvelles versions Le dilemme : Attendre un certain temps pour éviter de créer de l ’instabilité ou appliquer dès que possible pour bénéficier des corrections ?  Les correctifs doivent sans doute être appliqués rapidement, les versions majeures peuvent attendre Une documentation très précise des consignes d ’exploitation et de reprise souvent bénéfique, permet d ’éviter certaines erreurs de manipulation et diminue les temps d ’indisponibilité Intégrer la sécurité dans la conception des applications

2. Les solutions au cas où ... Les procédures de gestion manuelles de l ’activité de l ’entreprise Parfois complexes ou impossibles à mettre en œuvre, la dépendance par rapport au SI augmente sans cesse C’est une étape souvent négligée dans la mise en œuvre d ’une nouvelle solution informatique Les moyens de restauration rapides Ils permettent de réduire l ’indisponibilité en cas de nécessité de rechargement des données La robotisation totale des sauvegardes est bénéfique Attention à suivre l ’augmentation des volumes et la conséquence sur les temps de restauration

2. Les solutions au cas où ... La réplication des données Les données sont répliquées sur un système de secours Cela permet de gérer les problèmes de corruption bas niveau Les solutions existent pour les bases de données ou les fichiers Faut-il répliquer en temps réel pour ne rien perdre ou conserver un délai pour faire face à un incident du type corruption ou pollution de données ? Faut-il laisser le système de secours en version N-1 du logiciel ? La procédure et les conditions de bascule/retour doivent être définies précisément Les solutions de contournement ou « bypass » Elles consistent à mettre à disposition des utilisateurs un système en mode dégradé Ces solutions sont rarement prévues lors de la conception L ’activation en mode forcé doit être prévue car le système ne détecte pas toujours une panne « logicielle » qui n ’est pas toujours franche

2. Exemples de solutions pour le Groupe Seb Robotisation totale des sauvegardes et utilisation de la technologie LTO pour maintenir des temps de sauvegarde restauration acceptables (LTO IBM) Mise en œuvre de solution « Flash copy » sur baie IBM ESS pour réduire les temps de restauration à quelques minutes sur les bases critiques La technologie baie de disques permettra ultérieurement de mettre en œuvre la réplication de base de données Oracle en temps réel sur un système de secours distant Démarche engagée pour lister les cas de défaillance logicielle redoutés et les procédures de reprise associées Application plus rapide des correctifs système d ’exploitation (Maintenance level AIX, ou services pack MS) Révision de la politique d ’affectation des autorisations administrateur pour limiter les erreurs de manipulation