Comment les propriétaires de données mettent leurs locataires en danger

Microsoft est un leader mondial du stockage en nuage et de la protection des données. Ils prouvent que même les bases de données cloud les plus respectées offrent une sécurité faible.

L’architecture de microservices d’aujourd’hui dépend fortement du transfert de données fluide et interconnecté. SQL est un langage de codage parfait pour stocker des données dans des bases de données relationnelles, fournissant rapidement et en toute sécurité des données sur demande. C’est également un langage de codage très fiable, capable de maintenir l’intégrité des bases de données à travers le monde.

Malheureusement, la pression constante pour itérer et produire a obligé de nombreux développeurs à s’appuyer sur des plateformes tierces ; les fournisseurs de cloud ont également commencé à sur-optimiser, en regroupant plusieurs clients sur une seule instance cloud. Cela a ouvert de toutes nouvelles surfaces d’attaque au sein de la protection des données dans le cloud, car les entreprises inconnues et non fiables ne doivent compter que sur de minces murs de protection.

L’importance de PostgreSQL

PostgreSQL est la bibliothèque open source la plus avancée au monde pour SQL, avec un accent particulier sur la stabilité, la haute disponibilité et l’évolutivité. Développée il y a plus de 30 ans, la base de données a pour objectif de rationaliser et de nettoyer le code développé par la communauté. Celui-ci est ensuite publié et réutilisable avec ou sans licence commerciale.

Ce code SQL utilise des données stockées dans le cloud ; il est logique de stocker le code lui-même également sur un cloud. C’est là que la plate-forme Microsoft Azure est une aubaine pour de nombreuses entreprises de développement ; cette plate-forme est une base de données (principalement) sécurisée et gérée.

Les offres de plate-forme cloud sont des bases simples pour les applications et les services. À partir de cette base fiable, les développeurs d’applications peuvent rapidement concevoir et créer des applications sans avoir à se concentrer sur la gestion de la plate-forme. Microsoft propose le service Azure Database pour PostgreSQL dans trois variantes de déploiement : serveur unique, serveur flexible et hyperscale.

Le stockage en nuage est avantageux à plusieurs égards ; l’évolutivité est une force inhérente au cloud, car les entreprises n’auront qu’à payer suffisamment pour leur propre stockage. Tout stockage nécessitera une quantité définie de puissance de calcul ; cependant, d’un point de vue commercial, la flexibilité va à l’encontre de la fiabilité.

Microsoft résout ce problème grâce à une méthode ingénieuse : étant donné une quantité d’espace serveur définie, plusieurs clients peuvent “habiter” ce cloud, optimisant à la fois la demande des clients et la puissance de calcul.

Comment fonctionne l’architecture multi-locataires

Cette disposition multi-locataire voit différents clients partager des ressources système telles que le stockage, la mémoire et les systèmes d’exploitation. Regroupés, ils sont tous alimentés par un seul ensemble de matériel physique.

Les instances client sont séparées par la virtualisation. La deuxième couche de logiciels englobe l’environnement cloud, simulant les fonctionnalités matérielles pour créer un système informatique virtuel unique. Il y a une instance par client permettant une séparation logique et aidant en outre à séparer et à suivre l’utilisation des ressources.

L’attaque PostgreSQL

En 2022, des chercheurs ont découvert une vulnérabilité critique au sein de la plateforme PostgreSQL Microsoft Azure.

Lors de la validation de l’autorisation d’un serveur et de la validation d’une connexion, le code source d’Azure vérifie le certificat du client. Il recherche un nom commun prédéfini. Cependant, un oubli dans le processus de validation signifiait que le fait de glisser des caractères supplémentaires entre le début et la fin du faux certificat permettait de toute façon l’accès.

L’étape suivante dans la liste des tâches de l’attaquant consiste à établir quels éléments de la base de données d’un utilisateur contiennent des informations précieuses.

Externes à l’environnement virtuel de chaque client, les clients partagent tous un cache mémoire de niveau 3. En termes simples, cela reflète la mémoire système sur toutes les instances client. Un attaquant pourrait manipuler ce cache dans un état connu. Lorsqu’un utilisateur se connecte et utilise la plate-forme, l’attaquant peut alors consulter les modifications présentes dans le cache, l’identifier sur l’activité d’une victime et remonter jusqu’à l’endroit où l’utilisateur stocke ses données sensibles.

Avec une chaîne d’attaque convenablement établie, la dernière étape consiste à trouver une victime.

Les chercheurs ont précisé que cette attaque ne fonctionne que contre les bases de données de la même région. Cependant, trouver la région d’une base de données préexistante est une tâche relativement facile ; cela ressort de l’adresse IP de son serveur d’hébergement. Une fois que cela est connu, il est relativement simple de créer un compte et de commencer à exploiter d’autres utilisateurs sur le même cloud.

Alors, comment se protéger des voisins malveillants ?

Sécuriser votre cloud

Alors que de nombreuses bibliothèques de codage sont partagées publiquement et open source, les entreprises de plusieurs millions de dollars n’ont aucune obligation de publier leur propre code et architectures. Bien que cela soit tout à fait logique du point de vue des brevets, cela se fait au détriment de vos propres choix en matière de sécurité.

De plus en plus de chercheurs commencent à demander aux fournisseurs de cloud de donner un meilleur aperçu de leurs architectures d’isolation ; demandez toujours la documentation pertinente avant de choisir un fournisseur.

CVE fournit un processus de documentation global pour les vulnérabilités et les erreurs de configuration. Lorsque le code est mal géré et exploité, un identifiant CVE lui est attribué. Cela aide à rechercher, suivre et finalement prévenir ces vulnérabilités.

Cependant, le problème avec les fournisseurs de cloud est que les failles de sécurité logicielle et les erreurs de configuration ne reçoivent pas d’ID CVE. Il est donc beaucoup plus difficile d’établir les antécédents d’un fournisseur de cloud. Il y a cependant de bonnes nouvelles sur ce front – une équipe de professionnels de la sécurité qui travaille dur crée une base de données Github des incidents de sécurité dans le cloud.

Si vous êtes déjà dans un contrat pluriannuel avec un fournisseur de cloud, vos options sont légèrement plus limitées. Il est important de se rappeler que s’appuyer sur les propriétés d’un seul programme ou d’une machine virtuelle n’est pas suffisant ; la vulnérabilité de n’importe quel composant du service peut compromettre la sécurité de l’ensemble du service. En fin de compte, si les données sont exposées à Internet, elles sont vulnérables.

La gestion de ce risque est une partie importante de l’exploitation d’une entreprise sécurisée.

Toutes les données critiques – c’est-à-dire les données qui pourraient causer des dommages irréparables si elles étaient volées à votre organisation – ne doivent pas être stockées dans un environnement cloud tiers ; multi-locataire ou non. Au lieu de s’appuyer sur l’architecture d’un tiers non transparent, les données critiques doivent être stockées sur un serveur local ultra-sécurisé. Cela ne devrait pas avoir d’accès direct à l’Internet public.

Pour vos données non critiques, le stockage dans le cloud est une solution pratique et évolutive, tant que vous mettez des barrières supplémentaires entre les éventuels attaquants et vos données. Chiffrer vos données une fois qu’elles se trouvent dans le cloud signifie que, même si un attaquant y accède, les données sont fonctionnellement inutiles pour lui.

Leave a Comment

Your email address will not be published.