Sécuriser votre environnement cloud : stratégies essentielles et tests d’intrusion

Avec l’adoption croissante des services du cloud ainsi que l’augmentation globale de la sensibilité à la cybersécurité, la sécurisation des données et des infrastructures est devenue une préoccupation majeure pour les entreprises de toutes tailles. Les environnements cloud, bien qu’offrant une grande flexibilité et évolutivité, présentent également des défis uniques en matière de sécurité.

Responsabilités partagées

Le principe même du cloud est de permettre l’accès à des services ou des technologies sans avoir à gérer l’infrastructure physique sous-jacente.

Un concept clé de la sécurité dans le cloud est donc celui du partage des responsabilités entre le fournisseur de services cloud et le client. Cette notion est essentielle pour comprendre jusqu’où vont les obligations des deux parties en matière de sécurité. Nous pouvons résumer les grandes lignes de cette responsabilité avec le modèle suivant :

• Sécurité du cloud (responsabilité du fournisseur) : Les fournisseurs de cloud comme AWS, Azure et GCP sont responsables de la sécurité de l’infrastructure globale qui comprend le matériel, les logiciels de base, les réseaux et les installations physiques qui hébergent les services cloud. Ces derniers fournissent notamment des infographies (ici pour Google Cloud, par exemple) détaillant leurs responsabilités ainsi que celles de leurs clients en fonction du type de services (IaaS, PaaS, SaaS).
• Sécurité dans le cloud (responsabilité du client) : Les clients, en revanche, sont responsables de la sécurité de tout ce qu’ils déploient dans le cloud. Cela inclut la gestion des accès utilisateurs, la configuration des services, le chiffrement des données, et la surveillance des activités suspectes.

On comprend donc vite que dans le modèle Infrastructure as a Service (IaaS), c’est le client qui a le plus de responsabilités. Le fournisseur cloud n’ayant pour responsabilités que le support physique des serveurs, réseaux et datacenters.

Cas concrets

• Gestion des accès : Par exemple, la sécurisation des accès via IAM dans AWS est une responsabilité du client. L’absence de mécanisme MFA ou la mauvaise configuration des droits ne peut donc pas être imputée aux fournisseurs.
• Chiffrement des données : Le fournisseur de cloud propose des outils de chiffrement, mais c’est au client de s’assurer que ses données sont correctement chiffrées, tant au repos que lors des transferts. L’option de chiffrement des données, bien qu’accessible, n’est pas toujours activée par défaut dans ces environnements cloud.

Pour aller plus loin, des audits réguliers peuvent aider à vérifier que ce qui est sous notre responsabilité est correct. Par exemple, un audit pourrait examiner si les pratiques de gestion des accès et de chiffrement des données respectent les standards de sécurité.

Méthodologie d’intrusion

Tests d’Intrusion dans le cloud : simuler l’attaque pour renforcer la défense

Les tests d’intrusion sont des méthodes couramment utilisées pour évaluer la sécurité des systèmes informatiques. Dans un environnement cloud, ces tests revêtent une importance particulière en raison de la nature distribuée et partagée des ressources. Les méthodes d’intrusion en environnement cloud sont similaires à celles des intrusions internes ou sur des applicatifs externes.

Méthodes d’intrusion : Les étapes clés

Les tests dans le cloud peuvent varier en complexité, allant des tests d’intrusion plus basique à des opérations de type Red Team simulant des attaques complexes et persistantes. Voici les principales étapes couramment suivies :

• Reconnaissance : La première étape consiste à collecter des informations sur l’infrastructure de la cible. Cela peut inclure l’analyse des services exposés, l’identification du fournisseur Cloud, l’exploration des métadonnées, et l’identification des technologies utilisées. Cette phase permet de dresser une carte des actifs disponibles et des points d’entrée potentiels. Par exemple, la découverte d’un service de stockage type bucket s3 accessible publiquement.
• Accès initial : Une fois les informations collectées, l’étape suivante est de tenter d’obtenir un accès initial à l’environnement cible. Cela peut se faire via de l’ingénierie sociale comme du phishing, l’exploitation de défauts de configuration, ou l’utilisation d’identifiants compromis. En explorant le bucket S3, on peut ainsi découvrir des clés RSA pour SSH sur une instance ec2.
• Mouvement latéral : Après avoir obtenu un accès initial, l’attaquant peut essayer de se déplacer latéralement au sein de l’infrastructure cloud pour découvrir et compromettre d’autres ressources. Cela peut impliquer l’exploitation de défauts de configuration réseau, ou l’abus des permissions pour accéder à des services plus ou moins critiques. L’accès à l’instance ec2 récupéré donne accès au réseau privé virtuelle de notre cible.
• Élévation de privilèges : L’étape suivante consiste à élever les privilèges afin d’obtenir un accès à des ressources plus sensibles. Dans le cloud, cela peut inclure l’exploitation des rôles IAM mal configurés, ou l’utilisation de privilèges excessifs pour accéder à des services ou des données protégés. Par exemple, la compromission de l’instance ec2 précédemment identifiée pourrait permettre d’augmenter nos privilèges en usurpant le rôle de l’instance.
• Persistance : Enfin, pour maintenir l’accès à l’environnement cible, les attaquants mettent en place des mécanismes de persistance. Cela peut inclure la création de comptes backdoor, la modification des configurations de sécurité, ou l’installation de logiciels malveillants pour surveiller et contrôler l’environnement de manière continue. La création d’une seconde clé d’accès CLI pour un compte AWS peut être un moyen de persistance.

À noter qu’après la compromission d’un accès, une phrase de découverte est toujours effectuée afin de connaitre les droits du compte ou rôle. Ces méthodes permettent de comprendre comment un attaquant pourrait exploiter des faiblesses dans votre environnement cloud.

Démonstration pratique : Intrusion dans un environnement AWS

Lors d’une phase de reconnaissance quelconque nous avons découvert le bucket s3 suivant appartenant à notre cible : https://bucket-article.s3.eu-west-3.amazonaws.com

Comme on peut voir ce bucket n’est pas dans une configuration sécurisée car accessible en public et contient des données comme un fichier Excel faisant penser à un Excel de mot de passe.

Il est protégé par un mot de passe. Beaucoup de personnes utilisent des fichiers Excel chiffrés en pensant être aussi protégées que s’ils utilisaient des coffres-forts à mots de passe.

L’utilitaire office2john, fourni avec l’outil de cassage de mots de passe John The Ripper, permet de récupérer le condensat cryptographique du mot de passe de l’Excel.

On peut donc ensuite mettre ce condensat dans un fichier pour tenter de découvrir le fameux mot de passe.

On peut donc accéder à la précieuse donnée contenue dans le fichier Excel protégé.

On remarque deux chaînes de caractères ressemblant à des clés d’accès à l’interface en ligne de commande d’AWS.

On configure les identifiants, et on teste la connexion.

Avec cet outil, on peut tenter d’énumérer les droits d’un utilisateur ou d’un rôle sur AWS :

On remarque que l’outil nous remonte plusieurs droits notamment ec2.describe_snapshots

Cela veut dire que l’utilisateur michel dispose du droit permettant l’affichage du détail des snapshots ou instantanés au sein du module ec2 d’AWS.

Nous avons effectivement bien ce droit dans la région eu-west-3 (Paris).

Nous pouvons voir un instantané non chiffré nous appartenant.

Bien que l’outil enumerate-iam ne nous ait pas remonté de droits autres liés au service ec2, nous pouvons quand même tester le droit de télécharger les snapshots.

L’outil dsnap de l’entreprise RhinoSecurityLabs permet notamment le téléchargement et la manipulation de ces éléments.

Le téléchargement commence, nous en avions donc bien le droit. On peut ensuite simplement monter l’image sur notre machine.

On remarque que deux utilisateurs sont présents : le root et l’utilisateur par défaut ec2-user.

Dans le dossier root, on trouve un dossier « .aws ».

Ce dossier sert notamment à enregistrer la configuration du CLI AWS d’un utilisateur.

On configure cette nouvelle clé d’accès.

On remarque que cette nouvelle paire de clés appartient à l’utilisateur « backup ».

On modifie le nom du profil pour coller au nom de l’utilisateur et on essaye de lister les politiques associées à l’utilisateur.

Nous disposons donc d’un compte ayant des droits d’administration complets. Ce compte est certainement utilisé uniquement en cas de problème, comme compte de secours.

Conseils pour sécuriser votre environnement cloud

Assurer la sécurité de votre environnement cloud nécessite une approche méthodique et proactive. Voici quelques recommandations clés pour renforcer la sécurité de vos infrastructures cloud.

1. Mettre en œuvre une gestion stricte des accès

La gestion des accès est un aspect fondamental de la sécurité dans le cloud. Voici quelques pratiques essentielles à adopter :

• Principe du moindre privilège : Assurez-vous que chaque utilisateur et chaque service dispose uniquement des droits strictement nécessaires à leurs fonctions. Cela limite l’impact potentiel d’une compromission de compte.
• Authentification multi-facteur (MFA) : Activez l’authentification à plusieurs facteurs pour tous les comptes, en particulier ceux ayant des droits administratifs. Cela ajoute une couche de sécurité supplémentaire aux comptes.
• Revues régulières des accès : Effectuez des audits réguliers des permissions accordées aux utilisateurs et aux services pour vous assurer qu’elles restent conformes aux besoins actuels et aux meilleures pratiques.

2. Surveiller et journaliser les activités

La surveillance continue et la journalisation sont essentielles pour détecter et répondre rapidement aux incidents de sécurité. Cela permettra aussi de connaître le chemin de compromission d’un attaquant post-incident afin de le combler.

• Activation de la journalisation : Activez la journalisation pour tous les services cloud critiques. Par exemple, AWS CloudTrail pour suivre l’activité des API dans AWS ou Google Cloud Logging pour surveiller les ressources sur GCP.
• Remonter d’alertes : Configurez des alertes pour les activités suspectes, telles que des tentatives de connexion échouées répétées ou des modifications inattendues dans la configuration des ressources.
• Analyser les journaux : Intégrez les journaux d’activité à une solution de type SIEM pour analyser les événements en temps réel et identifier des schémas d’attaque.

3. Protéger les données sensibles

Le chiffrement des données est une mesure de sécurité incontournable pour protéger les informations sensibles.

• Activer le chiffrement des données au repos et en transfert : Assurez-vous que toutes les données sensibles sont chiffrées, aussi bien lorsqu’elles sont stockées que lors de leur transfert.
• Gestion des clés : Gérez vos clés de chiffrement via un service de gestion des clés sécurisé, tel qu’AWS KMS, Azure Key Vault, ou Google Cloud KMS. Limitez l’accès à ces clés de manière stricte.

4. Mettre en place des mesures de résilience

Préparez-vous à réagir rapidement en cas d’incident en mettant en place des stratégies de résilience.

• Mise en place de sauvegardes régulières : Effectuez des sauvegardes régulières de vos données critiques et testez vos procédures de restauration pour vous assurer qu’elles fonctionnent correctement.
• Plan de reprise d’activité : Élaborez et testez un plan de reprise après sinistre. Assurez-vous que votre infrastructure cloud est capable de se remettre rapidement d’une panne majeure ou d’une attaque.
• Redondance et haute disponibilité : Configurez vos ressources pour qu’elles soient redondantes et distribuées à travers plusieurs zones de disponibilité afin de minimiser l’impact des pannes ou des attaques ciblées.

5. Réaliser des audits de sécurité réguliers

Enfin, des audits de sécurité réguliers sont indispensables pour évaluer et améliorer continuellement la sécurité de votre environnement cloud.

• Audits de configuration : Analysez régulièrement la configuration de vos ressources cloud pour identifier et corriger les faiblesses potentielles.
• Tests d’intrusion : Effectuez des tests d’intrusion périodiques pour simuler des attaques réelles et identifier les failles de sécurité avant qu’elles ne soient exploitées par des acteurs malveillants.

N’hésitez pas à vous faire accompagner

Si vous souhaitez aller plus loin dans la sécurisation de votre environnement cloud, faites appel à l’expertise de Digitemis. Notre redoutable équipe pentest s’adapte à vos besoins (évaluation de la robustesse de vos infrastructures, identification des vulnérabilités potentielles avant qu’elles ne soient exploitées par des attaquants…). Nos experts vous accompagnent dans la mise en place de stratégies de défense efficaces et vous fournissent des recommandations concrètes pour renforcer la sécurité de vos données et de vos systèmes cloud. Contactez-nous dès aujourd’hui pour sécuriser votre infrastructure et protéger vos actifs les plus précieux.

Je partage