Le cloud a besoin de portes opérationnelles, notamment pour des raisons de sécurité

En janvier 2017, le très populaire MongoDB a subi ce qui semble devenir une tactique assez prévisible pour les attaquants : prendre des données en otage. Une enquête ultérieure sur la compromission a révélé que, dans la plupart des cas, les attaquants n’avaient exploité… rien. Le problème ne venait pas du logiciel, mais de la configuration. La configuration par défaut , fonctionnant principalement sur AWS, laissait les bases de données largement ouvertes à toute personne disposant d'une connexion Internet.

Cela incluait le désormais tristement célèbre drame de CloudPets dans lequel les messages vocaux (supposés privés) entre les enfants et leurs parents étaient accessibles au public à toute personne suffisamment avertie pour récupérer la base de données (une instance non sécurisée de MongoDB) ou comprendre l'architecture de l'application et son utilisation d'Amazon S3. Cloud Pets a utilisé S3 pour stocker des photos de profil et des enregistrements vocaux et a apparemment ignoré tout type de sécurité, les laissant accessibles à toute personne disposant de la référence appropriée.

Maintenant, de peur que vous ne pensiez que je m'en prends à CloudPets, permettez-moi de souligner que l'équipe RedLock CSI a récemment découvert que « 82 % des bases de données dans les environnements de cloud computing publics tels qu'Amazon Relational Database Service et Amazon RedShift ne sont pas chiffrées ».

[pause dramatique]

De plus, « 31 % de ces bases de données acceptaient les demandes de connexion entrantes provenant d’Internet ».

Permettez-moi de noter également que plus de 27 000 serveurs MongoDB ont été compromis au cours des premières semaines de janvier 2017. Bien plus que CloudPets a été touché par ses propres mauvaises pratiques de sécurité concernant cet incident. Comme l' a noté un blog de MongoDB lorsque les premières attaques ont été rendues publiques, « Ces attaques sont évitables grâce aux protections de sécurité étendues intégrées à MongoDB. Vous devez utiliser ces fonctionnalités correctement , et notre documentation de sécurité vous aidera à le faire. [c'est moi qui souligne]”

MongoDB n’était pas non plus dangereux, il n’était tout simplement pas sécurisé du tout. Le problème ne vient pas vraiment du produit, mais des mauvaises pratiques de ceux qui se précipitent pour mettre l’IoT et les applications mobiles entre les mains des consommateurs via le cloud. 

Le cloud comme catalyseur de pratiques peu sûres

Dans le centre de données (sur site), il existe des portes, à la fois physiques (pare-feu et autres) et opérationnelles (processus et approbations), qui doivent être franchies avant que le logiciel ne soit diffusé dans le monde et utilisé pour fournir des données. Le cloud, de par sa conception, comporte moins de portes physiques et – comme cela apparaît malheureusement souvent – moins de portes opérationnelles que les applications doivent franchir avant d’être proposées au monde entier. La réduction des portes opérationnelles est en réalité à l’origine du concept de « Rogue IT » ou de « Shadow IT ». Les acteurs du secteur d’activité, frustrés par les longs délais d’exécution et les échéanciers de projets s’étalant sur des années au lieu de plusieurs mois, ont commencé à se tourner vers le cloud pour « contourner » l’informatique. Mais cela signifiait également qu’ils contournaient les portes opérationnelles mises en place pour garantir la sécurité et les performances de ces applications.

Ce n’est pas un problème avec le cloud, c’est un problème avec ceux qui l’adoptent. Car ce n’est pas seulement la phrase « il faut trop de temps pour provisionner le matériel physique » qu’on nous sert depuis dix ans ; c’est aussi la phrase « il faut trop de temps pour passer par les processus d’approbation informatique » qui fait vraiment mal aux acteurs commerciaux qui veulent simplement arriver sur le marché maintenant, avant la concurrence.

Les personnes interrogées dans le cadre d'une enquête sponsorisée par Arxan/IBM en 2017 sur la sécurité mobile et IoT le confirment. Les personnes interrogées ont cité la pression exercée sur les équipes de développement d'applications comme étant responsable du manque de sécurité de l'IoT et des applications mobiles, 69 % d'entre elles pointant du doigt le développement précipité des applications mobiles comme source de code vulnérable, et 75 % affirmant la même chose pour les applications IoT.

Cette même pression s’étend à la mise en place et à la sécurisation des bases de données et du stockage cloud qui rendent les choses utiles en premier lieu. Le principe de base de Cloud Pets ne repose pas sur le jouet, mais sur sa capacité à envoyer et à recevoir des données via Internet. Cela signifie que son succès réside dans le fait qu'une de ces applications IoT est développée et déployée à toute vitesse dans le cloud pour atteindre la date de sortie du jour de Noël.

Les développeurs ne sont pas les seuls responsables de la sécurisation des applications qu’ils sont chargés de fournir. Quiconque est responsable de la fourniture de services cloud prenant en charge cette application (qu’il s’agisse de bases de données, de partage de fichiers ou de services d’application en général) doit assumer une partie de la responsabilité de sa sécurisation. Il en va de même pour les acteurs commerciaux qui imposent des délais irréalistes et encouragent le strict minimum de portes opérationnelles pour la livraison finale.

Oui, l’informatique doit adopter la transformation numérique et rationaliser les portes opérationnelles qui conduisent à une livraison réussie et sûre des produits aux consommateurs. Mais les entreprises et les développeurs ne peuvent pas continuer à simplement éviter ces portes opérationnelles dans le cloud et à laisser non seulement les consommateurs mais aussi les parties prenantes de l’entreprise en danger avec des pratiques de sécurité de mauvaise qualité qui reposent sur des configurations « par défaut ». Il ne s’agit pas tant de produits que de processus ; il s’agit de garantir que les politiques sont déployées et que les configurations sont correctes avant d’exposer les applications – et leurs utilisateurs – à des compromis évitables.

Si vous voulez éviter un incident embarrassant, vous devez commencer par fixer des objectifs de sécurité de base en définissant (et en appliquant) au moins quelques barrières opérationnelles de base qui doivent être franchies avant de lancer votre produit sur le marché.

Les organisations ont plus que jamais besoin de ces portes opérationnelles, car le rythme de migration vers le cloud public pour les applications prenant en charge à la fois la productivité et les bénéfices s’accélère. Et avec ce rythme de migration accru, les opportunités pour les attaquants de les exploiter se multiplient.