Sécurité du stockage cloud et risques d’exposition des données

Le stockage d’objets cloud — AWS S3, Azure Blob Storage et Google Cloud Storage (GCS) — stocke les fichiers sous forme d’objets dans des espaces de noms plats appelés buckets ou conteneurs. Contrairement aux systèmes de fichiers traditionnels, les permissions sont contrôlées par des policies attachées aux buckets et aux objets, plutôt que par des ACL de système de fichiers. Le stockage d’objets convient parfaitement aux données à grande échelle, mais il exige une configuration rigoureuse des permissions, car un seul bucket mal configuré peut exposer des téraoctets de données sensibles sur Internet public.

La vulnérabilité la plus courante du stockage cloud est le bucket accessible au public — un bucket de stockage dont la policy d’accès autorise la lecture anonyme (ou l’écriture). Cette mauvaise configuration a provoqué des dizaines de fuites majeures : Verizon (14 millions d’enregistrements clients), FedEx (119 000 passeports), Capital One (100 millions de demandes de cartes bancaires). Les attaquants utilisent des scanners automatisés pour découvrir les buckets publics correspondant à tous les schémas de noms de comptes AWS connus, ce qui rend leur découverte triviale dès que la mauvaise configuration existe.

Le stockage cloud utilise deux types de contrôles d’accès susceptibles d’entrer en conflit. Les policies de buckets sont des documents JSON attachés au bucket qui définissent quels principaux peuvent effectuer quelles actions. Les listes de contrôle d’accès (ACL) sont des autorisations héritées accordées objet par objet. AWS recommande de désactiver les ACL au profit des policies de buckets afin d’assurer la cohérence. Lorsque les deux existent, la policy la plus permissive l’emporte — ce qui signifie qu’une ACL trop permissive peut accorder un accès public même si la policy du bucket le restreint.

Les fournisseurs de stockage cloud proposent un chiffrement côté serveur pour les objets au repos. SSE-S3 (AWS) utilise automatiquement des clés gérées par AWS. SSE-KMS utilise des clés gérées par le client dans AWS Key Management Service, ce qui fournit de meilleures pistes d’audit (chaque déchiffrement est enregistré dans CloudTrail) et un contrôle de la rotation des clés. SSE-C utilise des clés fournies par le client, que celui-ci gère entièrement en dehors d’AWS. Pour les données sensibles, SSE-KMS avec des clés gérées par le client offre le contrôle le plus strict et les meilleurs éléments de preuve de conformité.

Même des données correctement chiffrées au repos peuvent être exposées si elles sont transmises par des canaux non chiffrés. Toutes les APIs de stockage cloud doivent être utilisées exclusivement via HTTPS/TLS. Pour S3, les policies de buckets peuvent imposer HTTPS en refusant les requêtes contenant aws:SecureTransport: false. Les URL pré-signées — des URL authentifiées temporaires qui accordent un accès limité dans le temps aux objets — doivent toujours utiliser HTTPS et être configurées avec des durées d’expiration courtes afin de réduire la fenêtre d’exposition en cas d’interception.

Toutes les données n’exigent pas le même niveau de protection. Les données sensibles (PII, PHI, dossiers financiers) doivent être stockées dans des buckets chiffrés, dont l’accès est restreint et le logging d’audit activé. Les données moins sensibles peuvent bénéficier d’un accès plus large. Des étiquettes de classification des données doivent être appliquées lors de la création des objets et utilisées pour acheminer automatiquement les données vers un stockage correctement configuré. Les policies qui déplacent automatiquement les données vers un stockage plus sécurisé en fonction des balises de classification réduisent le risque que des données sensibles se retrouvent dans des buckets faiblement sécurisés.

Le logging des accès est essentiel pour détecter après coup les accès non autorisés et réaliser les audits de conformité. Les journaux d’accès AWS S3 et le logging des événements de données CloudTrail enregistrent chaque appel d’API au niveau de l’objet — qui a demandé un objet, depuis quelle IP et à quel moment. Le logging de diagnostic d’Azure Blob et les journaux d’audit GCS offrent des fonctionnalités similaires. Sans ces journaux, aucune preuve forensique n’est disponible lorsqu’une violation de données est découverte, ce qui rend impossible la détermination de l’étendue de l’exposition.

Le stockage cloud est souvent partagé entre plusieurs comptes (développement, préproduction, production, partenaires tiers). Un accès inter-comptes configuré sans précaution peut accorder des permissions excessives. Les bonnes pratiques comprennent : utiliser des identifiants de compte explicites dans les policies de buckets plutôt que des principaux génériques, utiliser les SCP AWS Organizations pour limiter les comptes externes auxquels un accès peut être accordé, auditer régulièrement les autorisations inter-comptes et privilégier AWS PrivateLink à l’accès par Internet public pour les transferts de données entre comptes.

Le versionnage des objets conserve toutes les versions d’un objet, y compris les versions supprimées. Il protège contre les suppressions accidentelles, le chiffrement des objets par un rançongiciel et les menaces internes. Pour les données critiques, combinez le versionnage avec Object Lock (équivalent de S3 Glacier Vault Lock) — une policy WORM (Write Once, Read Many) qui empêche toute suppression ou modification pendant une période de conservation définie. Object Lock peut satisfaire les exigences réglementaires relatives aux enregistrements immuables dans les secteurs financier et de la santé.

Les outils de Cloud Security Posture Management (CSPM) analysent automatiquement les configurations du stockage cloud par rapport aux référentiels de sécurité. Les vérifications CSPM comprennent : certains buckets sont-ils accessibles au public ? Le chiffrement au repos est-il activé ? Le logging est-il activé ? Le versionnage est-il activé sur les buckets critiques ? Les policies de buckets sont-elles trop permissives ? Les outils CSPM tels que Prisma Cloud, Wiz et AWS Security Hub assurent une surveillance continue de la conformité et signalent les dérives de configuration avant que les attaquants ne les découvrent.

Les URL pré-signées accordent un accès limité dans le temps à des objets précis sans exiger que le destinataire possède des identifiants AWS. Elles sont utiles pour partager des fichiers avec des tiers. Les risques de sécurité comprennent : des URL dont la durée d’expiration est excessivement longue et qui persistent au-delà de la période de partage prévue, des URL transférées par les destinataires à des personnes ne faisant pas partie du public prévu, et des jetons intégrés aux URL qui apparaissent dans les journaux des serveurs. Définissez toujours la durée d’expiration viable la plus courte et évitez d’enregistrer les URL pré-signées dans les journaux.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les mauvaises configurations des buckets publics sont la cause la plus courante des violations de données dans le stockage cloud, que SSE-KMS offre le contrôle de chiffrement le plus strict avec un logging d’audit via CloudTrail, et que le versionnage des objets combiné à Object Lock protège contre les rançongiciels et la suppression interne de données critiques. Nous allons maintenant étudier l’identité cloud avec les rôles IAM et les comptes de service.