Qui est responsable de la sécurité du cloud public ?
Cette question peut sembler étrange, mais lorsque vous travaillez avec un fournisseur de cloud tel qu’Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform, il est important de comprendre que la sécurité est une responsabilité partagée.
Les fournisseurs de cloud public offrent aux clients une grande flexibilité dans la manière avec laquelle ils peuvent construire leurs environnements cloud. Cependant, la conséquence d’une telle flexibilité est que ces fournisseurs n’offrent pas une protection complète des réseaux virtuels, des machines virtuelles ou des données stockées dans le cloud public.
Ce modèle de responsabilité partagée signifie que les fournisseurs de cloud assurent la sécurité de celui-ci, tandis que l’entreprise (le client du fournisseur de cloud, c’est-à-dire vous) est responsable de tout ce qui est exécuté dans le cloud. Aujourd’hui, les administrateurs ne savent pas toujours ce que le fournisseur de cloud prend en charge réellement, ni les contrôles de sécurité qu’ils doivent eux-mêmes mettre en œuvre. Comme vous pouvez l’imaginer, une telle situation conduit à la mise en danger de données, fichiers, bases de données et d’aperçus de disques durs.
Vous avez peut-être entendu parler des violations de compartiments S3 : en fait, il en existe beaucoup ! Mais cette série d’articles a pour objectif de présenter les autres risques majeurs en matière de sécurité et expliquer surtout comment s’en protéger, en commençant par le plus courant…
L’exposition du compartiment Amazon S3 avec accès public (avec une nouvelle variante)
Vous n’aurez pas à chercher bien longtemps pour trouver des histoires de violations de données liées à S3 et causées par une mauvaise configuration, où les paramètres de sécurité de S3 ont été laissés sur “Public“. AWS a même publié une mise à jour pour aider les clients à éviter une telle situation, qui s’avère être l’une des principales causes de violations de données dans le cloud public.
En lisant les milliers de cas existants, il se peut que vous pensiez que les attaquants ne sont à la recherche que des données sensibles d’une entreprise lors de ces attaques. Malheureusement, vous vous trompez.
Au-delà des données financières et des données de type PII (Personally Identifiable Information), l’une des principales utilisations des comptes de stockage dans le cloud public, tels que les compartiments Amazon S3, est l’hébergement de contenu statique pour des sites web, tels que des fichiers HTML, JavaScript et des feuilles de style (CSS). Les attaques ciblant ces ressources ne ciblent pas en réalité des données exposées. En effet, elles cherchent plutôt à modifier les fichiers des sites web de manière malveillante afin de voler les données financières des utilisateurs.
Des techniques d’attaque qui diffèrent
Les deux chaînes d’attaque se ressemblent au départ, les pirates analysant internet à la rechercher de compartiments S3 mal configurés à l’aide de scanneurs S3 automatisés. Mais c’est là que les techniques d’attaque diffèrent.
Dans le cas d’une violation de données S3 classique, les attaquants à priori répertorient et synchronisent le précieux contenu sur un disque local et accèdent à toutes les données mal configurées en mode “public“.
Dans le cas d’une attaque de type ‘modification de données’, une fois l’accès obtenu, les attaquants recherchent du contenu JavaScript et le modifient pour inclure du code malveillant. Ensuite, lorsqu’un utilisateur visitera le site web infecté, le code JavaScript malveillant se chargera, enregistrant toutes les données de carte de crédit saisies dans des formulaires de paiement. Ces données seront ensuite envoyées sur le serveur du cybercriminel.
Comment identifier et prévenir l’exposition du compartiment S3 (pour les deux types d’attaque) ?
Les modifications accidentelles ou malveillantes apportées aux configurations de stockage S3 qui exposent les entreprises sont trop courantes. Cloud Optix facilite l’identification rapide de tous les fichiers de données ou sites web accessibles au public et les basculent en mode privé. Il ajoute un niveau de sécurité supplémentaire à ces services critiques avec Guardrails, garantissant qu’aucune modification de configuration ne sera apportée sans autorisation.
Cloud Optix vous alerte en quelques minutes sur des compartiments S3 exposés, en affichant des alertes contextuelles qui regroupent les ressources affectées, offrant une description du problème et les étapes à suivre pour effectuer la remédiation. Ces étapes incluent la possibilité de procéder à une remédiation automatique, via une mise à jour des autorisations de lecture/écriture des ressources lorsque le stockage S3 a été rendu accessible depuis l’internet public.
En optant pour l’IA afin de détecter les événements de connexion utilisateur suspects, Cloud Optix alerte les entreprises si le contenu d’un compartiment S3 est modifié depuis un emplacement inhabituel, suggérant ainsi que des identifiants utilisateur partagés ou volés ont probablement été utilisés à distance.
Quel que soit l’objectif final d’une tentative de violation d’un service S3, ces étapes simples dans Cloud Optix permettent de garder une longueur d’avance sur les attaquants.
Billet inspiré de Exposed: The cost of errors in the public cloud, sur le Blog Sophos.
Qu’en pensez-vous ? Laissez un commentaire.