Tirer les leçons d’un crash de serveur informatique - Dmoz.fr | Actualité insolite
Aller au contenu

Tirer les leçons d’un crash de serveur informatique

1.La sécurité du RIS repose sur 3 types éléments fondamentaux: « la mémoire » ; la disponibilité du serveur et la sécurité du système d’information support du RIS : « la continuité de service ».

La plupart des éditeurs de logiciel RIS ne sont pas experts en fourniture de matériel et réseau et proposent un matériel de bonne facture, souvent sur-dimensionné. Ils l’installent dans la seule préoccupation d’un fonctionnement fluide à l’installation initiale.

Ces architectures basiques sont le plus souvent composées :

D’un seul serveur, doté d’un seul disque dur : en cas de panne sévère, il n’y a aucune possibilité de bascule et le RIS est indisponible jusqu’au remontage sur un autre serveur avec réinjection des données de la dernière bonne sauvegarde. Cela pose le problème des données non sauvegardées, de la procédure de sauvegarde et de vérification de la présence effective et exhaustive des éléments listés par l’éditeur, de la liste réactualisée par l’éditeur voire des tests annuels de remontée par l’éditeur. Le stockage des médias de sauvegarde à proximité du serveur en cas de sinistre physique est aussi un risque non mesuré (incendie, vol, dégâts des eaux).

D’un ensemble de PC, sans mise à jour du logiciel opérateur (OS) en ce qui concerne les failles, trop souvent capables de naviguer librement sur Internet,d’échanger des e-mails et sans antivirus de réseau, voire sans antivirus tout court.

Enfin, souvent, il n’existe pas de contrat de maintenance dédié au matériel, sécurité et réseau, seulement une maintenance de l’éditeur qui ne définit pas forcément de prise en charge de la sécurité du système d’information en terme de stratégie pro active, d’entretien préventif ou de la mise en place d’une organisation palliative en cas de problème majeur, « désastre informatique », dans des délais acceptables…

2. Notre organisation tenait compte des ces contraintes

Avant le premier accident majeur, nous avions mis en place un système d’information du RIS bien plus évolué, intégrant la plupart des mesures de sécurité en vigueur à l’époque pour notre niveau d’information : u n serveur composé de plusieurs disques durs redondants, capables d’alerter en cas de panne de l’un des disques sans arrêter l’activité jusqu’à l’échange à chaud RAID 5.

RAID désigne les techniques permettant de répartir des données sur plusieurs disques durs afin d'améliorer soit la tolérance aux pannes. Redundant Array of Independent Disks, ce qui signifie « chaîne redondante de disques indépendants ».

Un serveur composé d’une alimentation double redondante capable d’alerter en cas de panne de l’une

des deux sans arrêter l’activité jusqu’à l’échange, l’une connectée sur un onduleur interactif (protection contre les micro coupures, contre les coupures longues avec système d’alerte pour fermeture préventive de la base avant chute définitive de l’alimentation électrique, contre les surtensions), l’autre connectée sur une autre prise au travers d’un para-surtenseur (permet de fonctionner si l’onduleur est en panne tout en restant protégé des surtensions).

Une sauvegarde nocturne externalisée avec vérification quotidienne par une opératrice et réalisée conformément aux préconisations écrites et mises à jour de l’éditeur du RIS.

Le réseau RIS périphérique isolé et réputé «propre», dit réseau propre, confiné dans un domaine sécurisé et avec un accès Internet limité à la liste blanche exhaustive des sites minimum utiles pour la réalisation du travail demandé, les lecteurs CD et disquettes verrouillés, et un réseau dit « sale », isolé du reste du réseau pour la navigation libre Internet, sans aucun lien avec le réseau propre dédié au RIS (mesures de sécurité minimum, stratégie du contact souillant le plus restreint possible : techniques de soin appliquées à l’informatique).

L’accès Internet filtré par un routeur pare feu.

Nous avions installé un antivirus basique qui, à l’époque (avant les catastrophes virales mondiales de 2009), était utilisé par le plus grand nombre d’utilisateurs dans le monde. Nous avions choisi de ne pas verrouiller les accès USBpour des raisons pratiques de connexion des périphériques de dictée par exemple. Nous avions choisi de ne pas réaliser régulièrement les mises à jour de Windows® car nous avions eu des déboires par le passé avec des incompatibilités majeures avec certains pilotes de périphériques très spécifiques à notre métier, cartes vitale etc…

Nous bénéficions d’un service de maintenance de haut niveau H+2 voire H+4 avec prêt systématique en cas de panne sévère, maintenance préventive mensuelle et réunion de travail pour la mise en place de solutions proactives. Nous pensions alors que notre capacité à résister à un sinistre majeur (ou indice de résilience) était très bonne :
Perte d’activité limitée sachant que les éléments matériels du serveur réputés sensibles étaient redondants, pour un RTO 36 H maxi. Le RTO (ou Recovery Time Objective), peut se traduire par la durée maximale d'interruption admissible. Il s'agit du temps maximal acceptable pendant lequel le RIS peut ne pas être fonctionnel suite à une interruption majeure de service. Cette durée est définie à l'avance, et ce en fonction des besoins de workflow vis-à-vis de la ressource informatique. Dans un cabinet qui utilise un ERP RIS, si le RIS vient à ne plus fonctionner, la production d’examens est bloquée, mettant en danger la pérennité des soins. Le RTO du RIS devra donc être extrêmement court. En revanche, le RTO d'une application de messagerie instantanée pourra lui être beaucoup plus long, puisque ce n'est pas une application critique.

Perte de données limitée à la dernière bonne sauvegarde qui était réalisée en respectant toutes les précautions, pour un RPO 24 H maxi. RPO (ou Recovery Point Objective), désigne la durée maximum d'enregistrement des données qu'il est acceptable de perdre lors d'une panne. Le fait de quantifier le RPO définit en fait les objectifs de sauvegarde, ce qui demande de connaître la volumétrie et les fenêtres de sauvegarde. Par exemple, si le RPO est défini à 24 heures et que la volumétrie est faible, alors on peut considérer que une sauvegarde complète en fin de journée suffit. En revanche, si le RPO est très faible comme c'est le cas dans les secteurs de l’imagerie médicale alors plusieurs sauvegardes seront nécessaires par jour, et en fonction de la volumétrie, différentes techniques de sauvegarde seront utilisées comme la réplication de données.

Risque limité d’infection puisque nous étions dans le respect des normes habituelles, bien que nous ayons levé certaines restrictions de protections car trop contraignantes dans notre workflow (flux de travail).

3. Le premier crash : la carte contrôleur RAID 5 de notre serveur tombe en panne avec destruction en cascade des disques. L’impensable se produit ! (Risque accepté, mais considéré comme peu probable et trop cher à consolider)

Dès la perte du RIS sur tous les postes à 16h00, nousavons déclaré une panne en appelant la hotline de notre société de maintenance :
action en H+2 avec mise en place d’un serveur de prêt, réinjection de la sauvegarde de la veille hébergée chez eux, prise en charge immédiatement après par le support de l’éditeur, retour à l’activité complète après 32h (RTO < 36h) de remontage et seulement sur la base des données de la dernière bonne sauvegarde. Seules les données de 8h00 à 16h00 ont été perdues dans le système : (RPO < 24h). Dans un deuxième temps, pour retrouver ces quelques données, nous avons expédié les 3 disques du RAID 5 qui ont été reconstitués, presque entièrement, par une société spécialisée (5 000 € environ).

Leçons du premier crash : comment réduire à coût raisonnable RPO et RTO ?

Nous avons cherché et trouvé un système de réplication asynchrone du serveur compatible avec la base Oracle®du RIS (20 000 € environ). Nous avons doublé donc le serveur avec un serveur miroir capable de copier à la seconde toute modification d’octet effectuée sur le premier, et en cas de crash du serveur principal, le serveur de secours est capable de basculer automatiquement et servir le RIS en moins de 10 minutes sans aucune perte de données ou de fonctionnalité : RPO 1’’ et RTO < 10’.
Nous avons profité de la disposition du site en plusieurs bâtiments pour implanter le secours loin du principal afin d’augmenter encore la résilience. Nous pensions alors que notre capacité à résister à un sinistre majeur (ou indice de résilience) était très bonne :
perte d’activité limitée RTO < 10’, perte de données limitée RPO 1’’, risque limité d’infection puisque nous étions dans le respect des normes habituelles, malgré les protections que nous avions levées parce que trop contraignantes dans notre « workflow »(flux de travail).

4.Le deuxième accident : attaque mondiale par 2 virus d’un nouveau genre : confiker® et sality®

Ils paralysent les systèmes informatiques de plusieurs organismes d’état dont la marine française et…notre centre. Ce deuxième accident majeur s’est produit peu de temps après l’autre. L’effet a été dévastateur non seulement sur le personnel et les médecins, mais aussi les patients en jetant le discrédit sur l’ensemble de la structure. Cet impact sur « l’image de marque » est toujours sous-estimé.

Ces virus ont utilisé des failles de Windows® et les insuffisances des antivirus basiques. La voie d’infection chez nous n’a pas été Internet puisque nous étions bien protégés, mais la connexion d’une clef USB (par une secrétaire qui avait emporté du travail chez elle pour servir les intérêts du cabinet !), alors que des sessions de formation « sensibilisation aux bonnes pratiques de sécurité du système d’information » avaient été dispensées et avaient formellement interdit ces pratiques…

En moins d’une seconde, l’infection a gagné le serveur principal puis, la seconde suivante, le serveur redondant et tous les PC connectés :
dès la perte du RIS sur tous les postes à 10h00, nous avons déclaré une panne en appelant la ligne support de notre société de maintenance :

action en H+2 avec diagnostic puis déconnexion de tous les PC et désinfection un par un des disques dur en commençant par le serveur, deux jours et une nuit pour retrouver la totalité des PC.

Leçons du deuxième crash : comment réduire à coût raisonnable notre risque d’infection ?

Nous avons cherché et trouvé un antivirus de réseau compatible avec Oracle® et n’ayant pas un impact trop important sur la charge mémoire des postes (70 € environ/PC pour 3 ans). Cet antivirus offre une console centrale de surveillance et de mises à jour : elle est télé surveillée tous les matins par une opératrice de notre partenaire de maintenance (au passage l’opératrice vérifie l’efficience du serveur redondant). Nous avons donc décidé de réaliser toutes les mises à jour Microsoft® en acceptant le risque des perturbation éventuelles de certains périphériques et mis en place une interdiction des médias USB par la base de registre (incompatible avec les dictaphones numériques mobiles dont nous n’en avons pas l’usage). Nous avons mis en place des sauvegardes mensuelles sur média perdus, non infectables, et stockées sur un autre site.

Nous avons demandé à notre partenaire de mettre en place une veille technologique afin de bénéficier de façon pro-active des avancées en matières de protection du système d’information quand elles sont financièrement acceptables et qu’elle n’impactent pas le « workflow » ( flux de travail) de manière rédhibitoire : nous avons mis en place une réunion trimestrielle pour un consentement éclairé de notre risque.

Enfin, nous avons augmenté la fréquence des maintenances préventive (hebdomadaire).

A la suite de ces interventions :

Nous avons changé le coeur de réseau, l’ensemble des connecteurs (« switchs ») qui ne répondaient plus suffisamment à la charge d’imagerie et présentaient un risque majeur en impactaient le RTO, nous avons mis en place une passerelle filtrante de type Proxy® vers Internet et vers la clinique contiguë avec laquelle nous communiquons par la force des choses, bien qu’elle soit source potentielle de contaminations… Elle intègre un antivirus en amont, un firewall évolué et elle est capable de gérer notre « réseau sale » dédié à Internet « en zone démilitarisée (DMZ) », mais surveillée.

Elle est capable de définir des zones intermédiaires où la navigation sur les listes blanches sera encore plus surveillée, etc…

Nous avons le projet :

d’un serveur WSUS® afin de centraliser les mises à jour Microsoft® sur un serveur dédié en réduisant les accès externes désirés et la charge de chaque PC ainsi qu’une console de management des mises à jour, de systèmes biométriques d’ouverture de session, en particulier pour les postes exposés aux passages non surveillés (heures creuses).

En conclusion

Si la réaction de nos partenaires a été rapide et adaptée dans chacun des accidents majeurs, ces accidents ont provoqué des dysfonctionnements pendant des périodes trop longues pour un service médical ouvert 24h/24h. La protection contre les désastres informatiques nécessite une prise de conscience des risques et de leur impact sur le fonctionnement d’un service d’imagerie qui dépend totalement de l’informatique. L’architecture et les moyens doivent être mis en oeuvre, sans méconnaître le péril humain qui est une constante et le maillon faible dans la chaine de protection. Le recours à un prestataire interne et/ou externe, fiable et mobilisable en permanence, est indispensable. Tout prévoir n’est pas encore suffisant et il faut aussi sanctuariser les données sensibles,médicales et économiques, en les sauvegardant de façon fiable et externalisée.

Ce texte élaboré depuis une expérience de la société SGPROD, nous montre la réalité , parfois difficile , entre un monde de l'imagerie médicale qui exige un flux d'information rapide, et la nécessité de se préserver des incidents et accidents.

-