Un développeur a frôlé une facture de 1 300 dollars à cause d'un espace de stockage AWS S3 portant un nom inapproprié, choisi par inadvertance par un outil open-source populaire. Maciej Pocwierz, ingénieur génie logiciel, confronté à des millions de tentatives non autorisées de création de fichiers sur son espace en une journée, a découvert l'ampleur du problème lorsqu'il a consulté sa facture. Malgré ses assurances à son client sur les coûts négligeables des services AWS, il s'est retrouvé avec une facture exorbitante. Heureusement, AWS a annulé la facture de Pocwierz après qu'il l'ait contacté, toutefois, l'incident souligne les risques associés à des noms d'espace génériques et les dangers des configurations par défaut malheureuses. En réponse, AWS envisage des mesures pour prévenir de tels incidents à l'avenir. Amazon Simple Storage Service (Amazon S3) est un service de stockage d'objets qui offre une évolutivité, une disponibilité des données, une sécurité et des performances de premier plan. Les clients de toutes tailles et de tous secteurs peuvent utiliser Amazon S3 pour stocker et protéger n'importe quelle quantité de données pour une série de cas d'utilisation, tels que les lacs de données, les sites web, les applications mobiles, la sauvegarde et la restauration, l'archivage, les applications d'entreprise, les appareils IoT et l'analyse de données massives.
Amazon S3 offre des fonctions de gestion qui permettent d'optimiser, d'organiser et de configurer l'accès aux données afin de répondre à vos besoins spécifiques en matière d'entreprise, d'organisation et de conformité. Il s'agit essentiellement d'un service de stockage d'objets qui stocke les données sous forme d'objets à l'intérieur de godets, où un objet est un fichier et toutes les métadonnées qui décrivent le fichier, et un godet est un conteneur pour les objets.
Si vous utilisez les services Web d'Amazon et que votre espace de stockage S3 est accessible depuis le web, vous feriez bien de ne pas choisir un nom générique pour cet espace. Maciej Pocwierz, en a fait les frais en choisissant par hasard un nom S3 que « l'un des outils open-source les plus populaires » utilisait pour sa configuration de sauvegarde par défaut. Après avoir configuré le panier pour un projet client, il a consulté sa page de facturation et a découvert près de 100 millions de tentatives non autorisées de création de nouveaux fichiers sur son panier (requêtes PUT) en l'espace d'une journée. La facture s'élevait à plus de 1 300 dollars.
« Il y a quelques semaines, j'ai commencé à travailler sur le PoC d'un système d'indexation de documents pour mon client. J'ai créé un bucket S3 unique dans la région eu-west-1 et j'y ai téléchargé quelques fichiers à des fins de test. Deux jours plus tard, j'ai consulté ma page de facturation AWS, principalement pour m'assurer que ce que je faisais était bien dans les limites du niveau gratuit. Apparemment, ce n'était pas le cas. Ma facture s'élevait à plus de 1 300 dollars, la console de facturation affichant près de 100 000 000 de requêtes S3 PUT exécutées en l'espace d'une seule journée », déclare Maciej Pocwierz.
En réponse à l'article de Pocwierz, Jeff Barr, évangéliste en chef pour AWS chez Amazon, a tweeté : « Nous sommes d'accord sur le fait que les clients ne devraient pas avoir à payer pour des requêtes non autorisées qu'ils n'ont pas initiées ». Barr a ajouté qu'Amazon aurait bientôt plus d'informations à partager sur la manière dont l'entreprise pourrait les empêcher. AWS propose une brève explication et une page de contact sur les frais AWS inattendus.
En ce qui concerne les comptes de Pocwierz, tant S3 que bancaires, tout s'est bien terminé. Un représentant d'AWS l'a contacté sur LinkedIn et a annulé sa facture, a-t-il déclaré, et on lui a dit que tout le monde pouvait demander des remboursements pour des demandes excessives non autorisées. « Mais ils n'ont pas explicitement dit qu'ils l'approuveraient nécessairement », a-t-il écrit. Il a noté dans son billet de blog qu'AWS « a insisté sur le fait qu'il s'agissait d'une exception ».
Thank you to everyone who brought this article to our attention. We agree that customers should not have to pay for unauthorized requests that they did not initiate. We’ll have more to share on exactly how we’ll help prevent these charges shortly.#AWS #S3
— Jeff Barr ☁️ (@jeffbarr) April 30, 2024
How an empty S3…
Par défaut, AWS ne consigne pas les requêtes exécutées sur les buckets S3. Toutefois, ces journaux peuvent être activés à l'aide d'AWS CloudTrail ou de S3 Server Access Logging (journalisation de l'accès au serveur S3). Après avoir activé les journaux CloudTrail, Pocwierz a immédiatement observé des milliers de demandes d'écriture provenant de plusieurs comptes ou entièrement en dehors d'AWS.
Conséquences désastreuses d'une simple erreur dans la configuration d'un service cloud
Amazon S3 est intégré à AWS CloudTrail, un service qui fournit un enregistrement des actions effectuées par un utilisateur, un rôle ou un service AWS dans Amazon S3. CloudTrail capture un sous-ensemble d'appels API pour Amazon S3 en tant qu'événements, y compris les appels de la console Amazon S3 et les appels de code aux opérations API Amazon S3.
Si un utilisateur crée une piste, il peut activer la livraison continue des événements CloudTrail vers un seau Amazon S3, y compris les événements pour Amazon S3. S’il ne configure pas de piste, il peut toujours consulter les événements les plus récents dans la console CloudTrail dans Historique des événements. En utilisant les informations collectées par CloudTrail, il est possible de déterminer la requête qui a été faite à Amazon S3, l'adresse IP à partir de laquelle la requête a été faite, qui a fait la requête, quand elle a été faite, et d'autres détails.
La journalisation des accès au serveur fournit des enregistrements détaillés des requêtes effectuées sur un godet. Les journaux d'accès au serveur sont utiles pour de nombreuses applications. Par exemple, les informations du journal des accès peuvent être utiles pour les audits de sécurité et d'accès. Ces informations peuvent également aider à connaître la clientèle et à comprendre la facture Amazon S3. Toutefois, cet incident souligne de manière frappante les conséquences potentiellement désastreuses d'une simple erreur dans la configuration d'un service cloud. La mésaventure du développeur met en lumière plusieurs problèmes majeurs dans la gestion des infrastructures cloud et la sécurité des données.
Tout d'abord, il met en évidence le besoin urgent d'une meilleure sensibilisation et formation des développeurs sur les bonnes pratiques de sécurité en matière de gestion des services cloud. Il est crucial que les développeurs comprennent pleinement les risques associés à des configurations par défaut malheureuses, ainsi que l'importance de choisir des noms de seau et de fichiers appropriés pour éviter les fuites de données et les coûts imprévus.
En outre, cet incident souligne la nécessité pour les entreprises de mettre en place des processus de supervision et de surveillance rigoureux pour détecter rapidement les anomalies de trafic et les activités suspectes sur leurs infrastructures cloud. Dans le cas présent, il est alarmant de constater que des millions de tentatives non autorisées de création de fichiers ont pu passer inaperçues pendant une période prolongée, mettant ainsi en péril la sécurité des données sensibles de plusieurs entreprises.
Enfin, la réaction d'AWS, bien qu'appréciée, soulève des questions sur la manière dont les fournisseurs de services cloud traitent les incidents de ce type. Bien que la décision d'annuler la facture soit louable, elle soulève également des préoccupations quant à la transparence des politiques de tarification et à la manière dont les entreprises peuvent se protéger contre de telles erreurs à l'avenir.
Sources : Maciej Pocwierz's blog post, AWS(1, 2)
Et vous ?
Quel est votre avis sur le sujet ? Quelles sont selon vous, les mesures de sécurité que le développeur aurait pu prendre pour éviter une telle situation ? Quelles autres mesures de prévention et de réponse les fournisseurs de services cloud comme AWS pourraient-ils mettre en place pour minimiser les risques associés à des incidents similaires à l'avenir ?Voir aussi :
AWS : les adresses IPv4 coûtent trop cher, donc vous allez payer. Comment AWS encourage la migration vers l'IPv6 en facturant les adresses IPv4 publiques AWS facture les adresses IPv4 publiques à ses clients et devrait gagner entre 400 Mns et 1 Md $. Stratégie pour encourager la transition vers l'IPv6 ou mesure abusive pour profiter de la pénurie ? Amazon Web Services acquiert Fig, une petite entreprise de San Francisco qui aide les développeurs à être plus efficaces et à collaborer tout en utilisant la ligne de commande