Cloud : un protocole de sécurité veut protéger les données pendant les calculs

Les données stockées dans le cloud sont généralement chiffrées. Celles qui circulent entre un poste de travail et un serveur le sont souvent aussi. La phase la plus sensible reste parfois celle où une application doit les lire et les traiter pour exécuter un calcul. C’est sur ce point qu’entend agir le protocole de sécurité présenté le 26 septembre 2024 : rendre les informations aussi difficiles que possible à exploiter pour un attaquant durant leur traitement dans le cloud.

L’idée répond à une préoccupation très concrète des organisations. Le cloud permet de louer rapidement de la puissance de calcul, d’héberger des applications et de partager des ressources à grande échelle. Mais il concentre aussi des données clients, financières, industrielles ou administratives dans des environnements connectés en permanence. Une exfiltration de données, une erreur de configuration ou l’exploitation d’une vulnérabilité peuvent alors avoir des conséquences importantes.

Le protocole décrit s’appuie sur deux axes, le chiffrement dynamique et la segmentation des environnements. Il n’est pas présenté comme un remplacement intégral des protections déjà déployées. Il doit au contraire s’intégrer à une architecture plus large, avec des pare-feu cloud, des pare-feu applicatifs, des équilibreurs de charge et des dispositifs de protection contre les attaques par déni de service distribué, ou DDoS.

Pourquoi les calculs dans le cloud posent-ils un défi de sécurité ?

On distingue habituellement trois moments dans la vie d’une donnée numérique : lorsqu’elle est stockée, lorsqu’elle circule sur un réseau et lorsqu’elle est utilisée par un logiciel. Les deux premiers sont bien connus du grand public. Un disque chiffré protège les données au repos. Une connexion sécurisée protège les données en transit.

La troisième situation est plus complexe. Pour traiter un dossier, calculer un score, générer un rapport ou répondre à une requête, une application doit manipuler l’information. Celle-ci peut alors être exposée dans la mémoire de la machine ou au sein des composants chargés du traitement. Dans une infrastructure cloud, cette question prend une dimension particulière, puisque les ressources sont administrées à distance et peuvent être mutualisées entre plusieurs clients.

Le protocole annoncé cherche précisément à réduire cette fenêtre d’exposition. Son objectif est que les données restent inaccessibles ou inutilisables pour un acteur malveillant, y compris lorsqu’un calcul est en cours.

Cette distinction est essentielle. Déplacer une application vers le cloud ne transfère pas automatiquement toutes les responsabilités de sécurité au fournisseur. Les identités des utilisateurs, les droits d’accès, les données déposées dans les services et les réglages des applications restent des sujets de vigilance majeurs pour l’entreprise cliente.

Chiffrement dynamique et segmentation : les deux mécanismes mis en avant

Le premier pilier du protocole est le chiffrement dynamique. L’expression renvoie ici à une protection appliquée au fil du traitement afin que les informations ne soient pas facilement lisibles ou réutilisables par un attaquant. À la différence d’un chiffrement limité au stockage d’un fichier ou à son transport sur un réseau, l’ambition est de renforcer la confidentialité au moment où l’application effectue ses opérations.

Dans la pratique, une telle protection suppose aussi une gestion très rigoureuse des clés de chiffrement. Une donnée chiffrée n’est réellement protégée que si les clés permettant de la déchiffrer sont elles-mêmes séparées, accessibles aux seules personnes ou applications autorisées et renouvelées selon une politique adaptée. Le chiffrement constitue donc une couche technique importante, mais pas une garantie isolée.

Le second pilier est la segmentation des environnements. Plutôt que de laisser les différents systèmes communiquer librement entre eux, cette méthode les sépare en zones. Une application web, une base de données, un environnement d’administration et un outil d’analyse peuvent ainsi être isolés les uns des autres.

L’objectif est de limiter les déplacements d’un intrus. Si un serveur exposé à Internet est compromis, il ne doit pas pouvoir atteindre directement les données les plus sensibles. Cette logique réduit ce que les spécialistes appellent la surface d’attaque et le rayon d’impact d’un incident.

Comment ce protocole s’intègre aux défenses cloud existantes

La sécurité cloud ne se résume pas à un outil unique. C’est pourquoi le protocole est conçu pour fonctionner avec les technologies déjà utilisées pour sécuriser les applications et les infrastructures.

Les pare-feu cloud contrôlent les flux réseau autorisés entre les différentes ressources. Ils contribuent, par exemple, à empêcher qu’une base de données accepte des connexions directes depuis Internet lorsqu’elle n’a besoin de communiquer qu’avec une application précise.

Les WAF, pour Web Application Firewalls, sont des pare-feu spécialisés dans le trafic web. Ils inspectent les requêtes adressées à une application et peuvent bloquer certains comportements malveillants avant qu’ils atteignent le serveur. Ils sont particulièrement utiles face aux tentatives d’exploitation qui passent par les formulaires, les paramètres d’URL ou les interfaces accessibles depuis un navigateur.

Les équilibreurs de charge, aussi appelés load balancers, répartissent le trafic entre plusieurs serveurs ou instances de calcul. Leur fonction première est la disponibilité et la performance, mais ils peuvent contribuer à la résilience globale lorsqu’ils sont associés à des contrôles de sécurité.

Enfin, les protections anti-DDoS répondent à un scénario différent : celui d’un afflux massif de requêtes destiné à saturer un site ou un service. L’attaque vise surtout la disponibilité. Un chiffrement efficace protège le contenu des données, mais n’empêche pas à lui seul un service d’être submergé par du trafic. La défense contre une attaque DDoS repose sur le filtrage, l’absorption et la répartition des flux suspects.

Ce que cette approche protège, et ce qu’elle ne peut pas promettre

L’intérêt principal du protocole est de mieux protéger les données à une étape souvent moins visible que le stockage ou le transport : leur exploitation par les applications cloud. En associant chiffrement et isolation, il cherche à limiter les possibilités de récupération d’informations utiles par un attaquant.

Cette approche peut également aider les entreprises à répondre à leurs obligations de protection des données. La conformité ne consiste toutefois pas à installer une technologie puis à considérer le sujet comme réglé. Elle suppose de savoir quelles données sont collectées, où elles sont hébergées, qui peut y accéder, combien de temps elles sont conservées et comment les incidents sont détectés et traités.

Il faut surtout éviter de confondre les menaces. Une attaque DDoS, une fuite de données, un mot de passe volé et une faille dans un logiciel ne se combattent pas de la même manière. Une architecture solide associe plusieurs protections complémentaires : contrôle des accès, segmentation, chiffrement, surveillance, mises à jour, sauvegardes et procédure de réponse aux incidents.

Le protocole ne dispense donc pas les organisations de corriger les vulnérabilités de leurs applications. Il ne remplace pas non plus l’authentification multifacteur pour les comptes sensibles, ni les sauvegardes nécessaires pour retrouver un service après un incident. Son apport se situe dans une stratégie de défense en profondeur.

Quelles bonnes pratiques pour les entreprises qui utilisent le cloud ?

La mise en œuvre d’une protection de ce type demande d’abord de connaître les flux de données. Une entreprise ne peut pas isoler efficacement ce qu’elle ne sait pas identifier. Il est utile de distinguer les données publiques, internes, confidentielles et particulièrement sensibles, puis d’appliquer des règles d’accès cohérentes avec ces catégories.

Plusieurs pratiques sont particulièrement importantes :

• appliquer le principe du moindre privilège, afin que chaque utilisateur et chaque application ne disposent que des accès indispensables ;
• vérifier régulièrement les configurations des services cloud, car des permissions trop larges ou un stockage exposé peuvent suffire à provoquer une fuite ;
• maintenir les systèmes, bibliothèques et applications à jour pour réduire l’exploitation de vulnérabilités connues ;
• centraliser les journaux d’activité et surveiller les comportements inhabituels, notamment les accès ou transferts de données anormaux ;
• tester les procédures de réaction à un incident, y compris la restauration depuis des sauvegardes ;
• former les équipes, car un message d’hameçonnage ou un mot de passe réutilisé peut contourner des protections techniques pourtant solides.

Les audits de sécurité et les tests de pénétration complètent cette démarche. Ils permettent de vérifier, dans un cadre autorisé, ce qu’un attaquant pourrait réellement atteindre. L’objectif n’est pas seulement de cocher une exigence de conformité, mais de découvrir les failles avant qu’elles ne soient exploitées.

Une sécurité à intégrer dès la conception des applications

Les experts cités dans la présentation insistent sur une évolution de méthode : installer des outils de sécurité après le déploiement d’un service ne suffit plus. La protection doit être pensée dès la conception de l’architecture.

Cette approche implique notamment de prévoir l’isolation des composants, la gestion des secrets, les règles de journalisation et les mécanismes de récupération avant que l’application ne soit ouverte aux utilisateurs. Dans un environnement cloud, où une ressource peut être créée ou modifiée très rapidement, l’automatisation des contrôles prend également une importance particulière.

L’enjeu est autant organisationnel que technique. Les équipes chargées du développement, de l’exploitation et de la sécurité doivent partager une vision commune des risques. Sans cette coordination, un protocole de chiffrement ou un pare-feu performant peut être affaibli par une règle de configuration inadaptée, une clé mal protégée ou un compte administrateur trop largement ouvert.

Ce qu’il faut surveiller

À mesure que les attaques se diversifient, la demande pour des protections capables de sécuriser les données pendant toute leur durée de vie devrait continuer à progresser. Le protocole présenté s’inscrit dans cette tendance : renforcer la confidentialité au cours des calculs, tout en s’intégrant aux défenses classiques du cloud.

Son efficacité dépendra toutefois de conditions concrètes : la qualité de l’intégration avec les services existants, la gestion des clés, la bonne segmentation des environnements, la capacité à surveiller les incidents et l’impact réel sur les performances des applications. Ajouter une couche de sécurité peut demander des ressources supplémentaires ou modifier les temps de traitement selon l’architecture retenue. Il est donc nécessaire de l’évaluer dans des conditions proches des usages réels.

Pour les organisations, le cap est clair en septembre 2024 : la sécurité cloud doit devenir une démarche continue. Protéger les données au repos et en transit reste indispensable. Les protéger pendant leur traitement, limiter les accès et préparer la réponse aux attaques constituent désormais les autres volets d’une même exigence de confiance numérique.