Plan

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

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

3. 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 • ...

4. 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é

5. 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

6. 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

7. 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 • ...

8. 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 »

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

10. 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 ?

11. 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

12. 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

13. 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

14. 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