Cloud : d'où viennent les menaces complexes qui ciblent les entreprises ?

Le cloud figure parmi les technologies les plus exposées en matière de cyber-risque. Dans ces conditions, quels sont les points de vigilance et les différents recours permettant de sécuriser cet environnement.

Avec un marché évalué à près de 300 milliards de dollars cette année[1], le cloud s'affirme désormais comme une norme dans le secteur informatique. Cependant, la sécurité reste l'un des principaux défis à relever pour la grande majorité des entreprises (65%) s'apprêtant à migrer vers le cloud. Et c'est sans compter la complexité de gestion induite par le développement du cloud hybride et du multi-cloud.

Aujourd’hui, la question sous-jacente à laquelle tout RSSI est confronté est de savoir à qui incombe la responsabilité de sa sécurité. Un questionnement d’autant plus légitime que le cloud figure parmi les technologies les plus exposées en matière de cyber-risque[2]. Dans ces conditions, quels sont les points de vigilance et les différents recours en matière de sécurisation du cloud ?

La responsabilité partagée

Les entreprises migrent leurs données et leurs services vers le cloud au profit de leur performance : pour accroître leur efficacité, réduire les coûts, améliorer leur souplesse et révolutionner l'expérience client. Pourtant, certaines idées reçues persistent, notamment concernant les fournisseurs d'IaaS. S’ils disposent de capacités et de ressources de sécurité plus performantes que l’entreprise elle-même, ils ne mettront à disposition de celle-ci que des outils permettant de sécuriser son infrastructure cloud, et ce sera donc à elle de se charger de leur mise en œuvre. Les plateformes AWS, Azure et Google Cloud Platform (GCP) sécurisent aujourd’hui l'infrastructure de la plateforme, mais les clients demeurent quant à eux responsables de la protection des données qui y transitent.

Cette fausse idée reçue constitue actuellement l'une des plus grandes menaces pour la sécurité des entreprises dans le cloud. Elle est à l’origine de 230 millions d’erreurs de configuration quotidiennes[3]. Certains systèmes, comme AWS, sécurisent les paramètres par défaut – paramètres souvent modifiés par des équipes informatiques sous pression qui cherchent à rationaliser les flux de travail et les processus internes.

Les erreurs de configuration

Les buckets S3 d'AWS sont l'un des points d'entrée les plus courants d’activités malveillantes et d’erreurs d’utilisateurs. Si les administrateurs système les rendent publiquement accessibles en écriture, ils ouvrent alors la porte au piratage lorsqu’ils tombent entre des mains malveillantes. C'est ce qui est arrivé au LA Times lorsque son équipe informatique a malencontreusement mal configuré les listes de contrôle d'accès (ACL), permettant une écriture à l'ensemble du bucket dans lequel était hébergé un sous-site du journal. Un cybercriminel a découvert l'erreur et exploité le système en téléchargeant un mineur de crypto-monnaie Monero dans le code JavaScript du bucket. Dans la même lignée, la campagne Magecart aurait infecté des dizaines de milliers de sites de e-commerce à travers le monde, dont notamment celui de British Airways. Une infraction qui, en marge du RGPD, pourrait coûter 183 millions de livres sterling d’amendes à la compagnie aérienne.

Même lorsque les organisations n'hébergent pas de sites web dans leurs buckets S3, le risque est latent. S'ils sont accessibles au public, les buckets AWS pourraient être utilisés abusivement par des cybercriminels pour héberger des serveurs de commande et de contrôle (C&C), servir de point d'entrée pour dérober des informations d'entreprise sensibles, etc. Mais ils ne sont toutefois pas les seuls à comporter des risques…

Les conteneurs sur le front

Ces environnements légers et isolés sont de plus en plus privilégiés par les équipes DevOps, qui y voient un moyen plus facile de tester et de déployer rapidement de nouvelles applications et d'intégrer le cloud hybride. Mais là encore, les erreurs des utilisateurs exposent les entreprises.

Si Docker est aujourd’hui l'un des outils les plus utilisés pour créer et déployer des conteneurs, il constitue également un terrain exploité par les hackers. Par exemple, certaines images ont été identifiées comme source d’exécution de mineurs de crypto-monnaie. Plusieurs techniques peuvent être utilisées pour arriver à ce résultat : l’installation du malware via une image qui contient le code malicieux, hébergé sur un repository comme docker.io, ou encore en utilisant une image de base telle qu’Alpine ou Ubuntu et en installant le logiciel de minage au moment du démarrage. Tout conteneur d’un système Docker ainsi exposé constitue l’occasion pour les hackers d’installer des malwares qui pourraient mener in fine au vol de données, voire à la prise en otage de l’infrastructure informatique.

Des expositions au risque involontaires

Si l’informatique moderne et le cloud ont été pensés pour que les entreprises gagnent en agilité et en performances, la partie sécurité est parfois relativement négligée. Nous avons ainsi découvert des faiblesses de sécurité assez communes dans les fonction Lambda, un composant de l’infrastructure serverless d’AWS.  Certains développeurs ont tendance à penser que les noms des fonctions Lambda ne sont pas connus des hackers, qu’ils sont donc sûrs et ne nécessitent donc pas d'authentification. En réalité, ils peuvent être trouvés assez facilement en inspectant les journaux des serveurs proxy, en examinant le code source des pages web qui utilisent Lambda avec une passerelle API en arrière-plan, ou en ‘écoutant’ le trafic réseau avec un sniffer. De même, laisser des serveurs Kubernetes ouverts permet aux hackers de sonder l’infrastructure IT à la recherche de vulnérabilités exploitables à distance.

En matière de sécurité du cloud, la tendance à l'erreur humaine ne fera qu'augmenter à mesure que les entreprises adopteront une approche DevOps, utiliseront des conteneurs et passeront à l'IaaS pour stimuler leur croissance et asseoir leur transformation numérique. Pour éviter d'exposer involontairement les données et les systèmes des entreprises aux risques, les responsables informatiques doivent avant tout comprendre et maîtriser leur infrastructure Cloud. Ils doivent donc envisager les scripts de déploiement du cloud comme AWS CloudFormation pour voir comment cela s'articule, répertorier les contrôles qui sont en place par défaut et identifier où il peut y avoir des lacunes. Il leur faut ensuite appliquer des best practices, telles les politiques d'accès avec le moins de privilèges possible (politique de least privilege), et adopter un outil de gestion de la posture de sécurité du cloud (CSPM) pour surveiller de près et en permanence les potentielles mauvaises configurations, etc.

La sécurité doit constituer une part intégrante de la culture DevOps. Les équipes de développeurs qui choisiront de s’appuyer sur des services innovants de sécurité basés sur les API n'auront plus à sacrifier la vitesse et l'agilité au profit de la protection. Les avantages du cloud sont nombreux, c’est vrai. Ils peuvent toutefois rapidement être remis en cause, si une sécurité multicouche n'est pas mise en place dès l’origine du projet. En matière de sécurité du cloud, la vigilance est doublement de mise !

[1] Source

[2] Source

[3] Source : Trend Micro