Quand une application métier tourne en partie sur un serveur local et en partie chez un fournisseur cloud, la surface d’attaque ne se limite plus à un seul périmètre. La notion de Critical System Protection prend alors tout son sens : il s’agit de protéger les workloads les plus sensibles, ceux dont l’arrêt ou la compromission aurait des conséquences directes sur l’activité. En cloud hybride, cette protection exige des mécanismes adaptés à chaque couche de l’infrastructure.
Workloads critiques en cloud hybride : ce qui est réellement exposé
Avant de parler de solutions, il faut identifier ce qu’on protège. Dans un environnement hybride, les workloads sensibles ne sont pas uniquement les bases de données clients ou les applications de paiement.
Vous avez déjà remarqué qu’un ERP hébergé sur site peut dépendre d’un service d’authentification dans le cloud public ? Ce type d’interdépendance crée des chemins d’attaque que les architectures classiques ne couvrent pas. Un attaquant qui compromet la couche de virtualisation (l’hyperviseur, par exemple) peut paralyser des dizaines de machines virtuelles d’un coup, sans jamais toucher directement l’application cible.
Les analyses récentes du secteur industriel montrent que le ransomware cible désormais les couches IT et virtualisation qui supportent l’OT, plutôt que les contrôleurs industriels eux-mêmes. Autrement dit, il suffit de bloquer la plateforme de gestion pour arrêter une chaîne de production entière. Ce constat change la hiérarchie des priorités en matière de protection.
Critical System Protection : segmenter les contrôles selon la criticité
Le principe de Critical System Protection repose sur une idée simple : tous les workloads ne méritent pas le même niveau de contrôle. Appliquer une politique de sécurité uniforme à l’ensemble de l’infrastructure revient à gaspiller des ressources sur des systèmes à faible risque tout en sous-protégeant les systèmes stratégiques.
Classer les workloads par niveau d’impact
La première étape consiste à cartographier les applications et les données en fonction de leur impact métier. Un workload est critique si son indisponibilité provoque l’un de ces effets :
- Arrêt d’un processus de production ou d’un service client direct, avec perte de revenus mesurable en quelques heures.
- Violation d’une obligation réglementaire (conformité NIS 2, RGPD, réglementations sectorielles) entraînant des sanctions ou des notifications obligatoires.
- Compromission de données sensibles (données de santé, données financières, propriété intellectuelle) dont la fuite causerait un préjudice durable.
Cette classification détermine ensuite le type de contrôles appliqués. Un workload classé « critique » recevra des politiques de restriction strictes, tandis qu’un environnement de développement pourra fonctionner avec des règles plus souples.
Politiques de verrouillage applicatif
Sur les systèmes critiques, l’approche la plus efficace est le verrouillage par liste d’autorisation. Seuls les processus explicitement approuvés peuvent s’exécuter. Toute tentative de lancement d’un binaire inconnu est bloquée par défaut.
Ce modèle, parfois appelé « default deny », est particulièrement adapté aux serveurs qui exécutent des charges de travail stables et prévisibles. Un serveur de base de données, par exemple, n’a aucune raison de lancer un interpréteur PowerShell ou un client BitTorrent. Le blocage de ces processus réduit la surface d’attaque sans perturber le fonctionnement normal.
Gestion des risques entre cloud public et infrastructure on-premise
En cloud hybride, la difficulté principale tient au modèle de responsabilité partagée. Le fournisseur cloud sécurise l’infrastructure physique et la couche réseau de base. Vous restez responsable de la configuration, du contrôle d’accès et de la protection des données.
Ce partage crée une zone grise que beaucoup d’entreprises sous-estiment. Quand un workload critique migre vers le cloud public, les contrôles de sécurité qui fonctionnaient sur site (pare-feu physique, segmentation réseau matérielle) ne s’appliquent plus de la même façon. Il faut les remplacer par des équivalents logiciels, souvent fournis par le fournisseur cloud, mais configurés par vos équipes.
Chiffrement et gestion des clés
Pour les données sensibles en transit entre l’infrastructure locale et le cloud, le chiffrement de bout en bout est le minimum. La question réelle porte sur la gestion des clés : qui contrôle les clés de chiffrement détermine qui a réellement accès aux données.
Si les clés sont gérées uniquement par le fournisseur cloud, vous perdez une partie du contrôle sur vos données critiques. Les organisations soumises à des exigences de conformité strictes optent souvent pour un système de gestion de clés externe, hébergé sur leur propre infrastructure ou chez un tiers de confiance indépendant du fournisseur cloud.
Authentification et contrôle d’accès
Un système de protection des workloads critiques ne peut pas reposer sur de simples identifiants et mots de passe. L’authentification multifacteur est un prérequis, mais elle ne suffit pas seule. Le principe du moindre privilège appliqué à chaque couche (réseau, application, données) limite les dégâts en cas de compromission d’un compte.
Concrètement, un administrateur réseau n’a pas besoin d’accéder aux bases de données de production. Un développeur n’a pas besoin de droits d’écriture sur l’environnement de production. Chaque rôle reçoit uniquement les permissions nécessaires à sa fonction, et ces permissions sont revues régulièrement.
Conformité NIS 2 et cadre NIST : articuler protection et obligations réglementaires
La directive NIS 2, entrée en application dans l’Union européenne, élargit le périmètre des organisations soumises à des obligations de cybersécurité. Les entreprises opérant en cloud hybride avec des workloads stratégiques sont directement concernées.
Le cadre NIST (notamment le Cybersecurity Framework) fournit une grille de lecture complémentaire, organisée autour de cinq fonctions : identifier, protéger, détecter, répondre, récupérer. Pour les systèmes critiques en cloud hybride, la fonction « protéger » passe précisément par les contrôles décrits plus haut (verrouillage applicatif, chiffrement, moindre privilège).
L’articulation entre ces deux référentiels est un point pratique souvent négligé. NIS 2 impose des résultats, le NIST propose un chemin pour les atteindre. Utiliser le cadre NIST comme base de mise en conformité NIS 2 évite de réinventer une méthodologie interne à partir de zéro. Les contrôles documentés dans le NIST se mappent directement sur les exigences de notification, de gestion des risques et de gouvernance de NIS 2.
La protection des workloads critiques en cloud hybride ne se résume pas à empiler des solutions de sécurité. Elle repose sur une classification rigoureuse de ce qui est réellement sensible, des contrôles calibrés selon le niveau de criticité, et une maîtrise du partage de responsabilités avec les fournisseurs cloud. Les organisations qui traitent ces trois points en amont réduisent considérablement leur exposition aux attaques qui paralysent aujourd’hui des chaînes entières d’activité.
