La plupart des grandes entreprises affirmeraient disposer d’une stratégie de cyber-résilience.
Elles sauvegardent leurs données avec des plateformes comme Veeam, Rubrik ou Cohesity. La gestion des identités passe par Okta ou Microsoft Entra ID.
Les infrastructures cloud sont réparties entre AWS, Azure et Google Cloud. Les configurations réseau et edge peuvent se trouver dans Cloudflare, Akamai, F5 ou Fastly. L’observabilité repose sur Datadog, Splunk, Dynatrace ou Grafana.
Chaque couche possède ses propres contrôles, sa propre équipe et, de plus en plus, son propre scénario de reprise.
Sur le papier, cela ressemble à une couverture complète. En pratique, c’est de la fragmentation.
- La reprise est un problème de dépendances
- La couche manquante est la configuration
- On peut tout restaurer individuellement et quand même échouer collectivement
- La lacune de récupérabilité se situe entre les outils
- La cyber-résilience exige une reprise coordonnée
- Une protection fragmentée n’est pas de la cyber-résilience
La reprise est un problème de dépendances
La cyber-résilience est en définitive mesurée à l’aune de la rapidité avec laquelle l’entreprise peut reprendre ses activités. Ce n’est pas la même chose que de se demander si une plateforme donnée peut être restaurée.
Une application de production peut s’exécuter dans AWS, utiliser Okta pour l’authentification, Cloudflare pour le DNS et le routage edge, Datadog pour la supervision, GitHub pour les workflows de déploiement et ServiceNow pour les processus opérationnels. Ses données peuvent être protégées par une plateforme de sauvegarde complètement différente.
Chacun de ces systèmes peut être considéré comme « protégé » individuellement. Mais l’application ne fonctionne que lorsque ses dépendances fonctionnent ensemble.
C’est là la faiblesse structurelle du marché actuel de la cyber-résilience. La reprise est cloisonnée par catégorie de fournisseurs, alors que l’entreprise fonctionne comme un système connecté unique.
La couche manquante est la configuration
La fragmentation devient particulièrement évidente au niveau de la configuration.
Récupérer Okta ou Entra ID signifie restaurer bien plus que les enregistrements utilisateurs. Les groupes, les rôles, les politiques d’accès conditionnel, les intégrations applicatives, les règles d’authentification et les autorisations doivent tous retrouver un état de confiance.
Il en va de même pour le réseau. Restaurer les workloads AWS ne sert pas à grand-chose si les enregistrements DNS Cloudflare, les règles de routage Akamai, les politiques F5 ou les configurations de sécurité ne correspondent plus à l’environnement qu’ils prennent en charge.
L’observabilité crée une autre dépendance. Une application peut être opérationnelle, mais l’absence de moniteurs Datadog, d’alertes Splunk, de paramètres Dynatrace ou de tableaux de bord Grafana peut priver les équipes d’intervention de la visibilité dont elles ont besoin.
Ces systèmes ne sont pas des éléments distincts du processus de reprise. La reprise de l’activité dépend de leur restauration conjointe.
On peut tout restaurer individuellement et quand même échouer collectivement
Imaginons un incident cyber majeur. Rubrik restaure les données. Les workloads AWS reviennent en ligne. Okta, Cloudflare et Datadog fonctionnent à nouveau. Chaque équipe indique que ses systèmes ont été récupérés.
Mais l’environnement ne s’articule plus correctement.
Les politiques Okta sont incorrectes. Cloudflare est restauré à un mauvais point dans le temps. Les groupes de sécurité AWS ont été modifiés pendant l’incident. Des moniteurs Datadog critiques ont disparu. Les autorisations de déploiement GitHub ne correspondent plus à l’environnement de production.
Toutes les plateformes peuvent être disponibles, mais l’entreprise peut toujours être incapable de fonctionner.
C’est la différence entre la reprise des plateformes et la reprise de l’activité.
La restauration des systèmes individuels ne crée pas de cyber-résilience si les dépendances entre eux ne sont pas également restaurées.
La lacune de récupérabilité se situe entre les outils
Les stratégies de résilience traditionnelles tendent à se demander si chaque technologie est protégée.
- Les données sont-elles sauvegardées ?
- Pouvons-nous récupérer les identités ?
- Avons-nous un plan de reprise après sinistre pour AWS ?
- Quelle est notre stratégie de sauvegarde SaaS ?
Toutes ces questions sont importantes, mais une autre question se pose entre elles :
Pouvons-nous récupérer la configuration qui permet à tous ces systèmes de fonctionner ensemble ?
Cela inclut le dernier état connu comme fiable des politiques d’identité, des paramètres réseau, des ressources cloud, des règles d’observabilité, des intégrations SaaS, des contrôles d’accès et des dépendances tierces.
Aujourd’hui, ces points de récupération sont souvent répartis entre différents outils, les historiques natifs des fournisseurs, les dépôts IaC, les scripts, les tickets, la documentation et la mémoire des personnes qui ont conçu l’environnement.
C’est la lacune de récupérabilité.
La cyber-résilience exige une reprise coordonnée
La cyber-résilience n’exige pas de remplacer les plateformes que les entreprises utilisent déjà pour la sauvegarde, les identités, l’infrastructure cloud, le réseau et l’observabilité. L’enjeu consiste à garantir que ces systèmes puissent être récupérés ensemble.
Cela nécessite une visibilité sur les configurations et les dépendances dans l’ensemble de l’environnement, ainsi que des points de récupération versionnés indiquant ce qui a changé et quand. Les entreprises doivent également identifier les états de confiance et comprendre quelles configurations peuvent réellement être restaurées après un incident.
C’est particulièrement important pour les configurations cloud, où l’infrastructure, les politiques d’identité, les règles réseau et les dépendances applicatives peuvent changer en permanence.
L’objectif n’est pas simplement de récupérer les plateformes individuelles. Il s’agit de restaurer les configurations et les dépendances qui permettent à ces plateformes de fonctionner ensemble.
Une protection fragmentée n’est pas de la cyber-résilience
Les entreprises n’achètent plus une seule pile technologique. Elles exploitent des centaines de plateformes interconnectées.
AWS remplit une fonction. Okta en remplit une autre. Cloudflare, Datadog et GitHub détiennent chacun une autre pièce critique de l’environnement opérationnel.
Cette architecture n’est pas près de disparaître.
Mais les stratégies de reprise construites autour de ces mêmes frontières sont de plus en plus difficiles à défendre.
Lors d’un incident, le conseil d’administration ne se soucie pas de savoir si la sauvegarde des données a réussi, si les identités ont été restaurées et si l’équipe réseau est « presque au bout ».
La seule question qui compte vraiment est de savoir si l’entreprise peut fonctionner. Une série de reprises réussies peut malgré tout aboutir à un échec de la reprise.
Découvrez pourquoi la prévention seule ne suffit plus et pourquoi les organisations doivent renforcer leur résilience opérationnelle