Sécurité du Cloud : vulnérabilités courantes et bonnes pratiques

Introduction

Le cloud est aujourd’hui un pilier essentiel de l’innovation. Son adoption massive témoigne des avantages qu’il offre en termes de flexibilité d’accès aux données et de capacité de stockage.

La popularité du cloud s’explique également en partie par la complexité croissante des systèmes modernes, soutenus par des technologies comme l’IA ou l’IoT. Ces dernières nécessitent une infrastructure dynamique et évolutive ; besoins que les infrastructures cloud savent combler.

Cependant, la sécurité du cloud soulève des questions critiques. En effet l’augmentation du volume de données stockées et la multiplication des services vont de pair avec la hausse du risque de failles de sécurité.

Cet article explore les différents aspects de la sécurité du cloud. Nous présenterons d’abord les spécificités des divers modèles de services cloud, avant de détailler les enjeux et les risques sécurité associés. Nous aborderons ensuite, cas concrets à l’appui, les failles les plus courantes ainsi que les bonnes pratiques pour sécuriser son infrastructure Cloud.

Guide complet sur la sécurité du Cloud

Pourquoi la sécurité du cloud est importante ?

L’adoption du cloud expose les organisations à des risques uniques en termes de sécurité qui, s’ils ne sont pas maîtrisés, peuvent avoir des conséquences graves sur leurs données, leurs opérations, et leur réputation.

Sécurité des données dans le cloud

La sécurité des données stockées dans le cloud est critique. Ces informations sont très souvent sensibles : données personnelles, informations clients, données financières, etc.

Une faille de sécurité peut exposer ces données à des accès non autorisés, des fuites ou des altérations ; avec des conséquences potentielles lourdes : pertes financières, atteintes à la réputation et perte de confiance des clients, non conformité aux règlementations, etc.

Par ailleurs, les environnements cloud sont souvent partagés entre plusieurs clients, ce qui introduit des risques liés au cloisonnement des données.

Une mauvaise configuration, une vulnérabilité exploitée ou une erreur humaine peut permettre à un attaquant de compromettre des données sensibles hébergées sur le même serveur ou dans le même réseau virtuel.

Une surface d’attaque étendue

Le cloud repose sur des technologies complexes et interconnectées, comprenant des APIs, des conteneurs, et des environnements multi-clouds.

Ces composants multiplient les points d’entrée potentiels pour les attaquants et font du cloud une cible de choix.

Par exemple, des vulnérabilités dans les APIs exposées par les fournisseurs de services cloud ou une mauvaise gestion des identités et des accès peuvent permettre un accès non autorisé à des ressources critiques.

Une responsabilité partagée qui peut mener à des lacunes

Les fournisseurs de services cloud fonctionnent selon un modèle de responsabilité partagée, où l’infrastructure sous-jacente est sécurisée par le fournisseur, mais où la sécurisation des applications, des configurations et des données reste à la charge du client.

Cette répartition entraîne souvent des zones grises et des lacunes, en particulier lorsque les entreprises ne disposent pas de l’expertise nécessaire pour assumer leur part de responsabilité.

La sécurisation des environnements cloud n’est pas un luxe mais une nécessité. Alors que les entreprises continuent de migrer vers le cloud, la mise en place de mesures proactives de sécurité est essentielle pour garantir la résilience face à des menaces de plus en plus sophistiquées.

Une configuration qui peut être difficile à appréhender

La sécurité du cloud peut se résumer peu ou prou à une question de configurations. Et elles sont nombreuses et les documentations fournisseurs sont verbeuses et difficiles à appréhender pour des publics non sensibilisés à la sécurité.

Néanmoins, une configuration adéquate est vitale car les incidents de sécurité liés à une mauvaise configuration sont les plus nombreux. Il s’agit généralement de situations où des ressources sont laissées accessibles publiquement ou d’une mauvaise gestion de composants et processus clés.  

Vous l’aurez compris, cet article ne vise pas l’exhaustivité. L’objectif ici est de vous présenter les bonnes pratiques permettant de sécuriser vos infrastructures cloud et d’expliciter les vulnérabilités courantes exploitées par les attaquants.

Nous partirons du cloud AWS pour illustrer les risques principaux via des cas concrets rencontrés lors de nos tests d’intrusion.

Mais avant d’entrer dans le vif du sujet, quelques précisions sur les différences et spécificités des principaux types de services cloud.

IaaS, PaaS et SaaS : quelles sont les spécificités de ces services Cloud ?

Les services Cloud se déclinent en trois modèles principaux : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service).

Ces modèles se distinguent par le niveau d’abstraction et de responsabilité pris en charge par le fournisseur. Et, chaque type de service répond à des besoins divers en matière de ressources, de développement et de services.

IaaS (Infrastructure as a Service)

L’IaaS est un modèle où le fournisseur Cloud offre une infrastructure informatique complète. L’infrastructure inclut notamment des ressources matérielles telles que des serveurs virtuels, du stockage, et des équipements réseau.

Ce modèle constitue une alternative à la gestion d’un Datacenter physique. Il permet aux entreprises d’accéder à des ressources qui peuvent être provisionnées ou libérées à la demande, et facturées selon l’utilisation réelle. Amazon EC2, par exemple, permet aux entreprises de louer la capacité de calcul et de stockage en fonction de leurs besoins, sans avoir à gérer les infrastructures matérielles sous-jacentes.

Cependant, cette approche nécessite que l’entreprise conserve certaines compétences techniques internes pour gérer les environnements systèmes, configurer les machines virtuelles, et s’assurer du bon fonctionnement de leurs applications dans le Cloud. En d’autres termes, le fournisseur prend en charge l’infrastructure physique, mais l’utilisateur est responsable de la gestion de l’OS, des applications et de la sécurité des données.

PaaS (Platform as a Service)

Le PaaS va un niveau plus loin dans la simplification en offrant non seulement une infrastructure sous-jacente mais aussi une plateforme d’exécution complète pour le développement et le déploiement d’applications.

En fournissant une couche d’abstraction au-dessus de l’IaaS, le PaaS permet aux développeurs de se concentrer uniquement sur le développement de leurs applications, sans se soucier des serveurs, des systèmes d’exploitation ou de la gestion des bases de données.

Ainsi, les développeurs bénéficient d’outils, de frameworks, et de services de bases de données, ainsi que d’un hébergement flexible, optimisant le processus de développement.

Cependant, ce modèle présente des limitations. La dépendance envers les technologies proposées par le fournisseur de PaaS crée une certaine rigidité, car migrer vers un autre fournisseur peut nécessiter une réécriture des applications.

De plus, les entreprises n’ont pas de contrôle total sur l’infrastructure sous-jacente, ce qui peut poser problème en cas de changement d’offre ou d’abandon de certains services par le fournisseur. Ce manque de contrôle et cette dépendance peuvent aussi représenter des risques potentiels pour la sécurité et la disponibilité des services.

SaaS (Software as a Service)

Le SaaS est sans aucun doute le modèle le plus avancé en termes de dématérialisation et de gestion par le fournisseur.

Ici, le matériel, l’infrastructure logicielle, les applications et les données sont entièrement pris en charge par le fournisseur, et le client accède au logiciel directement depuis un navigateur ou via une application.

Dans ce modèle, les entreprises accèdent aux outils nécessaires sans devoir se préoccuper de l’infrastructure sous-jacente, des mises à jour ou de la gestion des serveurs.

Le SaaS offre un accès simplifié aux applications et une évolutivité rapide, avec une facturation souvent basée sur l’usage ou sur un abonnement.

Cependant, l’absence de contrôle total sur les données stockées dans le datacenter du fournisseur, ainsi que sur la sécurité et les politiques de gestion des données, constitue un défi pour de nombreuses entreprises.

Les enjeux de confidentialité et de protection des données sensibles demeurent donc une préoccupation, d’autant plus que l’utilisateur dépend entièrement du fournisseur pour la gestion des pannes, la sécurité et les mises à jour.

Quelles sont les vulnérabilités courantes du Cloud et comment se protéger ?

Comme indiqué plus haut, les erreurs de configuration sont clairement la cause principale des incidents de sécurité dans le cloud.

Ils peuvent prendre plusieurs formes : absence de chiffrement, ports ouverts par défaut, une mauvaise configuration des politiques d’accès, une gestion inadéquate des identités et des accès (IAM), etc.

Par ailleurs, quel que soit le type d’infrastructure cloud, Azure, AWS ou GCP, les problématiques sont les mêmes. Ici, nous nous appuierons sur le cloud AWS pour illustrer les exemples de mauvaises configurations et les bonnes pratiques associées.

Mauvaises configurations des politiques d’accès et exposition de buckets S3

L’exposition de buckets S3 est une problématique que nous rencontrons très souvent lors de nos pentests AWS.

Ce problème est critique pour la sécurité des environnements AWS et peut mener la compromission des données ; et dans certaines situations permettre l’exécution de services tiers.

Voyons cela étape par étape.

Qu’est-ce qu’un bucket S3 ?

Un bucket S3 (Simple Storage Service) est une unité de stockage cloud proposée par AWS. Il est souvent utilisé pour stocker des fichiers, des bases de données, ou tout type d’objet.

Par défaut, les buckets S3 sont privés, mais des erreurs dans leur configuration peuvent les rendre accessibles publiquement. Et dans la plupart des cas, cela arrive lorsque les politiques d’accès (Bucket Policies) ou les ACL (Access Control Lists) sont mal configurées.

Bucket Policies et ACL : fonctionnement et exemples de mauvaises configurations

Dans AWS S3, Bucket Policies et ACL (Access Control Lists) sont des mécanismes utilisés pour gérer l’accès aux buckets et aux objets.

Bien qu’ils aient des fonctionnalités intriquées, ils diffèrent dans leur approche et leurs cas d’utilisation. Une mauvaise configuration de ces mécanismes peut entraîner des vulnérabilités importantes.

Buckets Policies

Les buckets policies sont des documents JSON qui définissent les permissions au niveau du bucket (et parfois des objets qu’il contient). Ces buckets policies :

• S’appliquent à tout le bucket ou à une sélection d’objets.
• Utilisent une syntaxe basée sur IAM (Identity and Access Management).
• Peuvent inclure des conditions (comme l’exigence de TLS ou des plages IP).
• Prennent en charge des principaux (principals) spécifiques (utilisateurs IAM, rôles, comptes AWS externes, etc.).

Ci-dessous un exemple d’une bucket policy interdisant l’accès public si le transport n’est pas sécurisé :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Ici, un exemple de politique autorisant l’accès à une plage d’adresse IP :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSharedIPRange",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

Dans ce cas de figure, la politique permet l’accès à tous les utilisateurs (Principal: "*"), mais restreint cet accès à la plage d’IP spécifiée (aws:SourceIp: "203.0.113.0/24").

Ce type de configuration est bien évidemment à proscrire car toute personne opérant dans la plage IP autorisée pourra accéder aux objets sans authentification ; et ce sachant qu’il est particulièrement facile dans un environnement cloud de se placer dans certaines plages d’IP.

Et un autre exemple d’une policy permettant un accès public total au bucket :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}

Le problème ici est le suivant : cette politique autorise tous les utilisateurs (Principal: "*") à effectuer n’importe quelle action (s3:*) sur le bucket et ses objets. Cela expose totalement les données.

ACL (Access Controls Lists)

Les ACL définissent les permissions sur un bucket ou un objet au niveau des utilisateurs ou groupes AWS, mais elles sont moins flexibles que les Bucket Policies.

Elles sont généralement utilisées pour gérer des accès simples. Les spécificités des ACL sont les suivantes :

• Les ACLs fonctionnent au niveau de l’objet ou du bucket.
• Elles permettent de donner des permissions précises (lecture, écriture) à des groupes prédéfinis (comme AllUsers ou AuthenticatedUsers).
• Elles ne prennent pas en charge les conditions ou la granularité des Bucket Policies.

Ci-dessous un exemple d’une ACL autorisant l’accès en lecture à un utilisateur IAM spécifique :

aws s3api put-bucket-acl --bucket example-bucket --grant-read id="USER_IAM_CANONICAL_ID"

Et un autre exemple d’une ACL permettant un accès public complet :

aws s3api put-bucket-acl --bucket example-bucket --grant-full-control uri=http://acs.amazonaws.com/groups/global/AllUsers

Le problème ici est que cette configuration donne à tout le monde (AllUsers) un contrôle total (FullControl) sur le bucket.

Cela signifie que n’importe qui peut ajouter, modifier ou supprimer des fichiers.

Caractéristique	Bucket Policies	ACL
Portée	Bucket (et parfois objets spécifiques)	Buckets ou objets individuels
Granularité	Très fine, avec support des conditions	Simples, permissions limitées
Compatibilité IAM	Compatible avec IAM	Moins intégrée à IAM
Cas d’usage principal	Accès externe ou gestion conditionnelle	Scénarios simples ou anciens systèmes

Bonnes pratiques pour éviter les erreurs de configuration au niveau des Buckets Policies et des ACL

La bonne configuration des Buckets Policies et des ACLs est primordiale pour garantir la sécurité et le contrôle d’accès des données stockées dans Amazon S3.

Pour ce faire, il est nécessaire d’utiliser les Bucket Policies comme méthode principale. En effet, mélanger les deux méthodes peut générer des permissions conflictuelles. Imaginons une configuration suivante :

• Une Bucket Policy qui interdit l’accès public.
• Et une ACL qui autorise l’accès public.

De fait, il peut arriver dans ce cas de figure que les ACL annule l’intention sécuritaire de la Bucket Policy, et autorise involontairement un accès public.

Pour éviter cette problématique, il est essentiel de configurer les Bucket Policies pour contrôler l’accès de manière centralisée pour ne pas trop dépendre des ACL.

Et si les ACL sont nécessaires, il est judicieux de les limiter aux utilisateurs authentifiés ou à des comptes AWS spécifiques. On peut imaginer cette configuration :

• AllUsers pour lecture publique uniquement dans des cas contrôlés.
• AuthenticatedUsers pour des environnements partagés et restreints.

Enfin, l’option S3 Block Public Access peut être utilisée pour tout simplement bloquer l’accès public au niveau global :

aws s3api put-public-access-block --bucket example-bucket --public-access-block-configuration '{
    "BlockPublicAcls": true,
    "IgnorePublicAcls": true,
    "BlockPublicPolicy": true,
    "RestrictPublicBuckets": true
}'

Gestion inadéquate des identités et des accès (IAM)

La mauvaise gestion des identités et des accès (IAM) est une source fréquente de vulnérabilités dans les environnements cloud.

Une mauvaise configuration IAM peut permettre à un attaquant d’accéder à des ressources sensibles ou de compromettre l’ensemble de l’environnement cloud.

Restons dans l’environnement cloud AWS pour expliciter cette problématique.

Fonctionnement du système IAM dans AWS

IAM (Identity and Access Management) est le service AWS permettant de gérer qui peut faire quoi et sur quelles ressources.

Il fournit des outils pour contrôler les permissions des utilisateurs, groupes, rôles, et applications via des politiques (policies).

Ci-dessous les composants clés d’IAM :

• Utilisateurs IAM : représentent des individus ou des services nécessitant un accès à AWS.
• Groupes IAM : permettent de gérer des permissions collectives en regroupant plusieurs utilisateurs.
• Rôles IAM : fournissent des permissions temporaires pour des entités comme des instances EC2, des fonctions Lambda, ou des comptes externes.
• Politiques IAM : documents JSON définissant les permissions (actions, ressources, et conditions).
• Identifiants d’accès : comprennent des clés d’accès API (Access Key ID et Secret Access Key) et des mots de passe pour la Console AWS.

Mauvaises configurations IAM et bonnes pratiques associées

Principe du moindre privilège non respecté

Donner des permissions trop larges à un utilisateur ou une entité est l’une des erreurs les plus courantes. Cela inclut :

• Assigner des politiques de type AdministratorAccess à des utilisateurs qui n’en ont pas besoin.
• Permettre des actions wildcard (Action: "s3:*") sur des ressources wildcard (Resource: "*").

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Avec une telle configuration, un utilisateur ou un service compromis pourrait supprimer toutes les ressources (buckets s3, base de données, etc.) et modifier des configurations de sécurité.

De la même manière, nous observons également des erreurs courantes au niveau des rôles IAM, comme par exemple :

• Permettre à tout le monde (Principal: « * ») d’assumer un rôle critique.
• Ne pas limiter l’utilisation des rôles à des services ou comptes spécifiques.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123456789012:role/AdminRole"
        }
    ]
}

Ici, avec cette configuration, n’importe quel compte AWS pourrait assumer ce rôle et agir comme un administrateur.

Ainsi, il est nécessaire d’appliquer le principe du moindre privilège. Autrement dit, il faut accorder uniquement les permissions nécessaires à chaque utilisateur, rôle ou service.

Mauvaise gestion des clés d’accès

Les clés d’accès API sont souvent utilisées pour l’automatisation ou pour interagir avec AWS via des scripts. Elles ne sont pas régulièrement renouvelées ou sont stockées dans des fichiers non sécurisés ou dans du code versionné publiquement.

Il est donc important de renforcer la gestion des clés d’accès via :

• Une rotation régulière des clés.
• L’utilisation de AWS Secrets Manager pour stocker les clés de manière sécurisée.

Absence d’authentification multifacteur (MFA)

Ne pas exiger l’authentification multifacteur pour les utilisateurs privilégiés augmente les risques de compromission en cas de vol de mot de passe.

Pour contrer ce risque, il est nécessaire de :

• Configurer l’authentification multifacteur à minima pour les utilisateurs avec un accès admin.
• Activer MFA pour les rôles critiques à l’aide des conditions IAM :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

Exploitations des APIs exposées

Les APIs exposées sont devenues une cible de choix pour les attaquants, car elles jouent un rôle clé dans les échanges de données entre applications et services.

Une mauvaise sécurisation des APIs peut avoir des conséquences graves, notamment la fuite de données sensibles, la compromission de systèmes, etc.

Pour plus de détails, vous pouvez consulter notre article dédié : Comment renforcer la sécurité de vos APIs pour contrer les attaques les plus courantes ?

Concernant les APIs GraphQL, vous pouvez consulter : APIs GraphQL : fonctionnement, vulnérabilités et attaques courantes.

Exploitations des applications web hébergées

Les applications web comme les APIs peuvent également servir de point d’entrée pour compromettre votre infrastructure cloud.

Nous disposons de nombreux articles sur notre blog sur ce sujet. Notez tous simplement que la sécurité des applications web est primordiale. Et pour sortir un peu du carcan d’AWS, qui nous a servi dans cette article, nous vous invitons à consulter cet article :

Pentest Cloud Azure : objectifs, méthodologie de tests et use cases

Nous y détaillons un exemple de compromission d’une infrastructure cloud (ici Azure) suite à l’exploitation d’une application web.

Conclusion

La sécurité dans le cloud est une responsabilité partagée qui exige une attention constante aux configurations, à la gestion des accès et à la protection des interfaces critiques comme les APIs.

Les erreurs de configuration, qu’il s’agisse de buckets S3 mal sécurisés ou de politiques IAM trop permissives, exposent les organisations à des risques majeurs, allant de la fuite de données à l’interruption de service. Ces vulnérabilités sont souvent exploitées par des attaquants qui profitent de la moindre faille pour compromettre des systèmes ou exfiltrer des informations sensibles.

Dans ce contexte, il est essentiel de mettre en place des bonnes pratiques, comme le principe du moindre privilège, l’activation de l’authentification multifacteur et une surveillance active des activités dans l’environnement cloud.

Cependant, ces mesures ne suffisent pas toujours à garantir une sécurité complète face à des menaces en constante évolution.

La réalisation régulière de tests d’intrusion spécifiques au cloud permet d’identifier les failles avant qu’elles ne soient exploitées. Ces évaluations simulent des attaques réelles pour analyser la résistance de vos systèmes et offrir des recommandations concrètes pour renforcer leur sécurité.

Auteur : Amin TRAORÉ – CMO @Vaadata