Focus sur : le pentest cloud

En plus des avantages financiers et techniques qu’elles peuvent offrir, les offres cloud sont devenues matures et bien développées, offrant une panoplie de services qui peuvent répondre à tous les besoins. Ainsi, les entreprises de toutes tailles se tournent de plus en plus vers ces solutions. Qu’il s’agisse de tout ou d’une partie du SI, il y aura forcément des informations sensibles et des traitements critiques sur les services cloud. Un accès à travers le cloud implique une exposition plus importante. Il est essentiel de s’assurer que ce passage ne dégrade pas le niveau de sécurité global.

À la différence d’un pentest “classique” pour lequel l’environnement est clairement défini (web, réseau interne, etc.), un test d’intrusion en environnement cloud va très souvent combiner une intrusion web externe (services exposés sur Internet) et une intrusion interne, c’est à dire à l’intérieur même du nuage. Ceci est dû à la manière même dont les offres d’hébergement en cloud public ont été pensées : les systèmes d’information sont placés, totalement ou de manière partielle, au sein d’un nuage accessible par le biais d’une connexion Internet. Ainsi, le test consistera, en général, dans un premier temps à effectuer un test d’intrusion externe (web) durant lequel nous chercherons à nous infiltrer dans le nuage du client par le biais des différents éléments exposés sur Internet (serveurs, espaces de stockage, etc.). Si nous y parvenons, nous effectuerons un test d’intrusion interne afin d’auditer le nuage en tant que tel et y déceler les différentes vulnérabilités existantes.

En règle générale, la première partie du test d’intrusion consiste à rechercher et exploiter des vulnérabilités communes par le biais d’outils classiques. Ce n’est que lorsque nous parvenons à nous infiltrer dans le nuage du client que nous employons des outils plus spécifiques et propres à chaque CSP (Cloud Service Provider).

Si l’on traite uniquement des techniques d’attaques spécifiques aux environnements cloud, c’est à dire que l’on ne retrouve pas dans des pentests “classiques” alors oui, les approches changent du tout au tout d’un CSP à l’autre. Ceci est notamment dû au fait que le socle sur lequel reposent les solutions proposées par les CSP diffère grandement qu’il s’agisse d’Amazon, de Google ou de Microsoft pour ne citer qu’eux.

La majorité des failles exploitées durant un test d’intrusion sont en général causées par la négligence des personnes en charge de la configuration du cloud. En effet, les clients qui souscrivent à une offre en cloud public considèrent très souvent, à tort, que tout ce qu’ils configureront à l’intérieur du nuage sera protégé des attaques externes. Cela est une idée reçue. Ainsi, nous constatons une baisse de vigilance des clients par rapport à tout ce qui touche à la sécurité informatique appliquée aux environnements cloud. De ce fait, il n’est pas rare de déceler durant nos audits des erreurs de configuration créant des brèches dans le nuage du client, pouvant amener à une compromission partielle voire totale de celui-ci.

Afin de sécuriser leurs environnements cloud, les entreprises peuvent agir à plusieurs niveaux. Tout d’abord, il est important que les personnes en charge de l’infrastructure prennent du recul sur la nécessité ou non d’avoir tout ou partie du SI en cloud. En effet, nous constatons un « effet de mode » visant à adhérer à des solutions cloud pour plus d’élasticité, de disponibilité, voire, à tort, pour se décharger de la sécurité informatique. Ce choix n’est pas forcément justifié et peut même avoir l’effet inverse : rendre le SI plus vulnérable qu’auparavant. Si la migration partielle ou totale du SI a été effectuée, et que le client est désireux de sécuriser davantage son infrastructure, il est important qu’il configure l’ensemble de ses services en intégrant les bonnes pratiques de sécurité, comme par exemple le principe du moindre privilège pour tout ce qui concerne les accès et les identités.

Il est difficile de donner une réponse précise car chaque SI est différent et les configurations nécessaires d’un SI à l’autre peuvent changer du tout au tout. Néanmoins certains principes communs se doivent d’être respectés comme l’application du principe du moindre privilège (mentionné précédemment), une bonne gestion du flux entrant (whitelisting d’IP sources, fermeture des ports inutiles, surveillance du trafic en temps réel, etc.) ou encore l’installation de solutions de protection au niveau des services (WAF par exemple) ou au niveau des machines utilisateurs (HIDS/HIPS). Ces recommandations ne sont que quelques exemples parmi tant d’autres et de nombreuses solutions propres aux CSP sont disponibles aux clients par le biais des marketplaces.

Les environnements cloud mis à disposition par les CSP à leurs clients sont globalement sécurisés par défaut. Il y a bien sûr des vulnérabilités publiques qui sont régulièrement décelées par les chercheurs en sécurité informatique mais celles-ci sont très rapidement prises en charge et corrigées par les CSP. Aujourd’hui, les services cloud à disposition des clients intègrent tous des éléments de sécurité by design. Il faut cependant que les clients sachent correctement les configurer en intégrant les principes de sécurité adéquats.

Les bonnes pratiques qui s’appliquent aux utilisateurs d’un SI on-premise s’appliquent également aux utilisateurs en cloud, comme par exemple utiliser des mots de passe robustes, ne pas les stocker en clair dans des fichiers, installer les mises à jour requises, etc. Ainsi, si un attaquant parvient à compromettre le poste d’un utilisateur cloud, sa propagation se verra freinée du fait de l’application de ces mêmes bonnes pratiques.