Plan

Comment faire face aux incidents « logiciels » ?

ADIRA / Clusir le 5 mars 2002

Benoit Champouillon : Responsable Technique Informatique Groupe SEB

BCH / Adira le 05/03/2002 Ref adira mars2002.ppt /

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

Plan

Documents

Transcript of Plan