Résilience du SI assurance : comment concevoir une architecture qui résiste aux pannes et aux attaques ?

Pour un architecte infrastructure dans le secteur de l’assurance, la pression est constante. La moindre interruption de service peut paralyser les courtiers, retarder l’indemnisation d’un sinistre et éroder la confiance des clients. Face à cette exigence du 24/7, la réponse habituelle consiste à empiler les technologies : des pare-feux plus puissants, des serveurs plus rapides, des logiciels de surveillance omniprésents. Ces éléments sont nécessaires, mais ils traitent les symptômes, pas la cause profonde de la fragilité. Ils opèrent sous l’hypothèse qu’il est possible d’empêcher toutes les pannes et toutes les attaques.

Cette approche est un combat perdu d’avance. La véritable question n’est pas « si » une panne surviendra, mais « quand ». Dans un contexte où, selon l’assurtech Stoïk, la fréquence des sinistres cyber a atteint 11,38% en France, l’obsession de l’invulnérabilité doit laisser place à une ingénierie de la résilience. Mais si la clé n’était pas de construire une forteresse imprenable, mais plutôt un système conçu pour absorber l’échec ? Un système où la défaillance d’un composant est un non-événement, une péripétie prévue et gérée automatiquement, rendue totalement invisible pour l’utilisateur final.

Cet article propose un changement de paradigme. Nous n’allons pas lister des outils, mais déconstruire les piliers d’une architecture de résilience. De la protection de la donnée elle-même à la duplication des services, en passant par le confinement des menaces et la validation par le chaos, nous allons bâtir une feuille de route pour concevoir un SI non pas « sans pannes », mais dont la continuité est garantie *malgré* les pannes.

Cet article explore les stratégies techniques et organisationnelles indispensables pour bâtir un système d’information résilient dans le secteur exigeant de l’assurance. Découvrez ci-dessous le détail de chaque pilier de cette architecture robuste.

Chiffrement au repos : pourquoi chiffrer la base de données rend le vol inutile pour les hackers ?

La première couche de la résilience n’est pas le pare-feu ou l’antivirus, mais la protection de l’actif le plus précieux : la donnée. Dans le secteur de l’assurance, les bases de données regorgent d’informations personnelles et sensibles. L’approche classique consiste à multiplier les murailles pour empêcher les attaquants d’y accéder. L’approche résiliente part du principe que l’attaquant finira par entrer. La question est : que pourra-t-il faire avec son butin ?

Le chiffrement des données au repos (encryption at rest) répond à cette question de manière radicale. Il consiste à chiffrer les données directement sur leur support de stockage, qu’il s’agisse de disques durs de serveurs, de bases de données ou de sauvegardes. Si un pirate parvient à exfiltrer un fichier de base de données, il ne se retrouvera qu’avec une masse d’informations illisibles et inexploitables. Le vol a bien eu lieu, mais son impact est nul. C’est le principe même de l’absorption de l’échec : la violation de périmètre est absorbée sans causer de dommage métier.

Cette technique neutralise une large part des attaques par exfiltration de données, qui visent souvent à revendre les informations ou à faire du chantage. Pour l’architecte, cela signifie intégrer des solutions comme TDE (Transparent Data Encryption) pour les bases de données SQL ou des mécanismes de chiffrement au niveau du système de fichiers ou du volume de stockage. La gestion des clés de chiffrement devient alors un point critique de l’architecture, car leur compromission annulerait toute la protection.

Sauvegarde 3-2-1 : quelle stratégie de backup pour être sûr de pouvoir restaurer ?

La sauvegarde est la police d’assurance fondamentale de tout système d’information. Pourtant, trop d’entreprises découvrent, au moment d’une crise, que leurs sauvegardes sont corrompues, incomplètes ou tout simplement inaccessibles. Une stratégie de sauvegarde résiliente ne se contente pas de copier des données ; elle repose sur une redondance intentionnelle et diversifiée. La règle d’or en la matière est la stratégie « 3-2-1 », qui a récemment évolué pour répondre aux menaces modernes comme les ransomwares.

La règle 3-2-1-1-0 est un framework robuste qui impose une discipline rigoureuse :

• 3 copies des données : L’original et au moins deux sauvegardes. Si un support tombe en panne, il en reste deux.
• 2 types de supports différents : Ne pas mettre tous ses œufs dans le même panier technologique. Utiliser par exemple un NAS et une bande magnétique.
• 1 copie hors site : Essentiel pour se protéger d’un sinistre physique (incendie, inondation) qui détruirait le site principal.
• 1 copie « air-gapped » ou immuable : C’est l’ajout crucial contre les ransomwares. Cette copie est déconnectée du réseau ou rendue techniquement impossible à modifier, même par un administrateur dont les identifiants seraient compromis.
• 0 erreur de restauration : La sauvegarde ne vaut rien si la restauration échoue. Des tests de restauration réguliers et automatisés sont la seule garantie de pouvoir réellement récupérer les données.

Ce dernier point est souvent le plus négligé et pourtant le plus critique. Une architecture de sauvegarde moderne doit inclure des mécanismes de vérification de l’intégrité et des scénarios de test qui vont au-delà de la simple restauration d’un fichier, en simulant la reconstruction d’un service complet.

Comme on peut le voir, l’intégrité des données est au cœur du processus. La vérification après restauration n’est pas une option, mais la validation que la stratégie de sauvegarde est fonctionnelle. C’est la seule façon de s’assurer que le « 0 » de la règle 3-2-1-1-0 est bien respecté.

Haute disponibilité (HA) : comment dupliquer les serveurs pour qu’une panne soit invisible ?

La haute disponibilité est l’incarnation même du concept d’insignifiance de la panne. Elle vise à garantir qu’un service reste opérationnel sans interruption perceptible pour l’utilisateur, même en cas de défaillance matérielle ou logicielle d’un de ses composants. Pour un architecte, il ne s’agit plus de chercher à atteindre un MTBF (Mean Time Between Failures) infini pour chaque serveur, mais de concevoir une architecture où la panne d’un serveur est un événement normal et géré automatiquement.

La disponibilité correspond au pourcentage de temps pendant lequel une charge de travail est disponible à l’utilisation. Dans son interprétation la plus stricte, la disponibilité est réduite chaque fois que l’application ne fonctionne pas normalement, y compris pendant les interruptions planifiées et non planifiées.

– Amazon Web Services, Documentation AWS – Pilier Fiabilité

Le principe de base de la HA est la redondance. Au lieu d’un unique serveur pour une application critique (ex: le portail de gestion des sinistres), on en déploie au moins deux. Un mécanisme de « load balancing » répartit le trafic entre eux. Si l’un des serveurs tombe en panne, le load balancer le détecte et redirige 100% du trafic vers le serveur restant. L’utilisateur ne subit, au pire, qu’un bref ralentissement. Le coût de l’indisponibilité justifie amplement cet investissement, car comme le démontre l’exemple d’EDF où chaque point de disponibilité peut représenter des millions, l’inaction est souvent plus coûteuse. Dans certains secteurs, on estime la perte à 200 millions d’euros par point de disponibilité perdu.

Cette redondance doit être pensée à tous les niveaux de l’architecture : serveurs d’application, bases de données (via des clusters), équipements réseau, et même liens internet. L’objectif est d’éliminer tout « Single Point of Failure » (SPOF), ce composant unique dont la défaillance entraînerait la chute de l’ensemble du service. La haute disponibilité transforme l’architecture d’une chaîne fragile en un filet robuste, où la rupture d’un fil n’affecte pas la solidité de l’ensemble.

Segmentation réseau : comment empêcher un virus de passer de la RH à la gestion sinistre ?

Imaginez un navire. S’il n’était qu’une coque vide, le moindre trou sous la ligne de flottaison le ferait couler. Les navires modernes sont divisés en compartiments étanches : une brèche inonde un seul compartiment, mais le navire reste à flot. La segmentation réseau applique exactement ce principe à un système d’information. Elle part du constat qu’une intrusion est inévitable et vise à limiter radicalement la capacité de l’attaquant à se déplacer une fois à l’intérieur du réseau.

Sans segmentation, un virus qui infecte l’ordinateur d’un employé des RH via une pièce jointe malveillante peut potentiellement se propager à l’ensemble du réseau de l’entreprise et atteindre les serveurs critiques de gestion des sinistres. Avec une segmentation efficace, le réseau est divisé en zones logiques (VLANs) isolées les unes des autres : un réseau pour les postes de travail, un pour les serveurs de production, un pour les invités, etc. La communication entre ces zones est interdite par défaut et n’est autorisée que par des règles de pare-feu très strictes et spécifiques. L’ordinateur du service RH est ainsi dans un compartiment, les serveurs de sinistres dans un autre. Le virus reste confiné.

En adoptant une architecture de confiance zéro (Zero Trust), on ne suppose plus qu’un appareil est sûr simplement parce qu’il est sur le réseau interne. Chaque connexion, chaque flux de données est inspecté et authentifié. La segmentation est la matérialisation de cette philosophie, transformant un réseau plat et vulnérable en une série de coffres-forts interconnectés de manière contrôlée.

Chaos Engineering : pourquoi provoquer des pannes volontaires pour tester la robustesse ?

Une architecture résiliente sur le papier est une chose ; sa capacité à résister à une crise réelle en est une autre. Le Chaos Engineering est une discipline qui consiste à passer de la théorie à la pratique de la manière la plus directe qui soit : en provoquant intentionnellement des pannes dans un environnement de production pour identifier les faiblesses avant qu’elles ne soient exploitées par un incident réel.

Cette approche, popularisée par Netflix, peut sembler contre-intuitive. Pourquoi casser volontairement ce qui fonctionne ? La réponse est simple : pour s’assurer que les mécanismes de redondance, de basculement automatique et les procédures de réponse humaines fonctionnent comme prévu. C’est l’équivalent d’un exercice d’incendie, mais pour l’infrastructure IT. On ne se contente pas de vérifier que des extincteurs sont présents ; on déclenche l’alarme pour voir si les gens évacuent correctement et si les portes coupe-feu se ferment.

Injecter du chaos de manière contrôlée permet de répondre à des questions cruciales : que se passe-t-il si un serveur de base de données devient soudainement inaccessible ? Le système bascule-t-il correctement sur le serveur secondaire ? Les applications le détectent-elles et se reconnectent-elles sans erreur ? L’équipe d’astreinte est-elle alertée en moins de 5 minutes ? Ces tests révèlent des faiblesses cachées non seulement dans la technologie, mais aussi dans les processus et l’organisation. C’est une forme de prophylaxie par le chaos, un vaccin qui expose le système à une version affaiblie du « virus » pour renforcer ses défenses immunitaires.

EDR et Antivirus : comment protéger les ordinateurs des gestionnaires contre les malwares ?

Même avec l’architecture serveur la plus résiliente, la chaîne de sécurité reste aussi faible que son maillon le plus exposé : le poste de travail de l’utilisateur. Les gestionnaires de sinistres, les actuaires, les commerciaux manipulent des données sensibles et sont des cibles de choix pour les attaques de phishing et les malwares. Il est statistiquement prouvé que le facteur humain est une porte d’entrée majeure pour les attaquants. D’après une analyse du rapport DBIR de Verizon, environ 60% des brèches impliquent le facteur humain, que ce soit par erreur ou par malveillance.

L’antivirus traditionnel, basé sur la détection de signatures de virus connus, est aujourd’hui insuffisant. Il est comme un gardien qui ne reconnaîtrait que les cambrioleurs dont il a déjà la photo. Face aux menaces modernes, polymorphes et souvent inconnues (zero-day), une approche plus intelligente est nécessaire. C’est le rôle des solutions EDR (Endpoint Detection and Response).

Un EDR ne se contente pas de scanner les fichiers à la recherche de signatures. Il surveille en permanence le comportement des processus sur le poste de travail. Il se pose des questions : « Pourquoi le lecteur PDF est-il en train d’essayer de contacter une adresse IP en Russie ? », « Pourquoi ce script PowerShell, lancé depuis un document Word, tente-t-il de chiffrer des fichiers ? ». En détectant ces comportements anormaux, l’EDR peut bloquer une attaque en temps réel, même si le malware utilisé est totalement nouveau. De plus, il enregistre toute l’activité, ce qui permet aux équipes de sécurité de remonter le fil de l’attaque (comment l’attaquant est entré, ce qu’il a fait) pour renforcer les défenses. Dans un pays comme la France, où l’ANSSI a traité 4 386 événements de sécurité en 2024, cette capacité de réponse est cruciale.

L’association d’un antivirus de nouvelle génération (NGAV) et d’un EDR constitue donc une protection robuste et redondante pour le poste de travail, transformant chaque ordinateur de simple point d’accès en un capteur de sécurité intelligent pour l’ensemble de l’entreprise.

Réplication synchrone ou asynchrone : quel coût pour quelle sécurité ?

La haute disponibilité et les plans de reprise d’activité reposent sur un principe fondamental : la donnée doit exister à plusieurs endroits. La manière dont cette donnée est copiée d’un site à un autre est l’un des choix d’architecture les plus structurants, avec un impact direct sur la performance, le coût et le niveau de protection. Le débat se cristallise autour de deux concepts clés : le RPO (Recovery Point Objective), qui définit la quantité maximale de données qu’on accepte de perdre, et le RTO (Recovery Time Objective), le temps maximal pour redémarrer le service.

Le choix entre la réplication synchrone et asynchrone est un arbitrage direct sur le RPO. La réplication synchrone garantit un RPO de zéro. Lorsqu’une transaction est effectuée (ex: validation d’un contrat), le système attend que la donnée soit écrite sur le site principal ET sur le site de secours avant de confirmer la transaction à l’utilisateur. En cas de crash du site principal, on est certain qu’aucune donnée n’a été perdue. Le prix à payer est la latence : la performance de l’application est directement impactée par le temps de communication entre les deux sites.

La réplication asynchrone, elle, confirme la transaction dès qu’elle est écrite sur le site principal. La copie vers le site de secours se fait avec un léger décalage (de quelques secondes à quelques minutes). L’impact sur la performance est minimal, mais en cas de crash, on risque de perdre les données des dernières transactions. Le RPO est donc faible, mais non nul. Le tableau suivant, basé sur les meilleures pratiques, résume les critères de choix.

Le choix n’est donc pas binaire. Une architecture résiliente utilisera souvent une combinaison des deux : une réplication synchrone pour les applications transactionnelles les plus critiques où la perte de données est inacceptable, et une réplication asynchrone pour des services moins sensibles où une perte minime est tolérable en échange d’une meilleure performance. Une analyse fine des besoins métier pour chaque application est donc un prérequis indispensable.

Plan de Reprise d’Activité (PRA) : comment garantir un RTO (temps de reprise) de moins de 4 heures ?

Le Plan de Reprise d’Activité (PRA) est le document et l’ensemble des procédures qui orchestrent la réponse à un sinistre majeur affectant le système d’information. C’est la synthèse de toutes les briques de résilience que nous avons vues. Avoir des sauvegardes, des serveurs redondants et un réseau segmenté est une chose ; les faire fonctionner de concert dans le chaos d’une crise pour respecter un RTO (Recovery Time Objective) ambitieux de moins de 4 heures en est une autre.

Garantir un RTO aussi court n’est pas seulement un défi technique, c’est avant tout un défi organisationnel et procédural. La technologie n’est qu’un facilitateur. Un PRA efficace doit être un document vivant, testé, et connu de toutes les parties prenantes. Il doit détailler précisément le « qui fait quoi, quand et comment ». Cela inclut des « runbooks » de restauration automatisés pour les équipes techniques, mais aussi des plans de communication pour les clients et des procédures métier dégradées pour les gestionnaires.

Le PRA doit inclure les processus dégradés et les plans de communication. Si le système est de retour en 1h mais que personne ne sait quelles procédures métier lancer, comment communiquer aux clients, ou qui prend les décisions, le RTO réel sera de 12h.

– Experts Wandesk, Guide de la résilience informatique

Pour être crédible, un PRA doit être testé sans complaisance. Un calendrier de tests réaliste pour une compagnie d’assurance pourrait inclure des tests techniques trimestriels pour valider les basculements, des simulations partielles bisannuelles avec les équipes métier pour roder les processus dégradés, et un exercice de crise annuel complet impliquant le top management. Chaque test, et chaque incident réel, doit être suivi d’une revue post-mortem et d’une mise à jour du PRA pour intégrer les leçons apprises. C’est ce cycle vertueux de planification, test, échec et amélioration qui transforme un document statique en une véritable capacité de résilience pour l’entreprise.

Concevoir et maintenir une architecture résiliente est un effort continu, un engagement stratégique qui va bien au-delà de la simple gestion de l’infrastructure. Pour mettre en pratique ces principes et évaluer la maturité de votre propre système, l’étape suivante consiste à réaliser un audit complet de votre infrastructure au regard de ces différents piliers.