Sécurité cloud : par où commencer et dans quel ordre

La sécurité cloud n'est pas un sujet, elle compte neuf domaines distincts, et les traiter dans le désordre fait perdre du temps sans réduire le risque. Cette page donne la carte : ce que couvre chaque domaine, ce qu'il protège réellement, et l'ordre dans lequel les aborder selon que vous démarrez un projet ou que vous héritez d'une infrastructure déjà en production. Elle s'adresse à qui doit sécuriser sans être spécialiste sécurité.

Ce que vous allez apprendre

• Situer les domaines de la sécurité cloud les uns par rapport aux autres.
• Savoir ce que le fournisseur sécurise, et ce qui reste à votre charge.
• Prioriser quand tout semble urgent et que le temps manque.
• Protéger le service de métadonnées d'une instance contre les attaques SSRF : deux réglages AWS à vérifier par commande, puis deux réflexes valables partout.
• Reconnaître les quatre erreurs qui reviennent dans presque tous les audits.

La question qui précède toutes les autres

Avant de sécuriser quoi que ce soit, il faut savoir ce qui vous incombe. C'est le modèle de responsabilité partagée, et il n'est pas une clause juridique : c'est la liste concrète de ce que personne ne fera à votre place.

La règle tient en une phrase : le fournisseur sécurise le cloud, vous sécurisez ce que vous mettez dedans. Il garantit que le matériel, l'hyperviseur et son réseau physique tiennent. Il ne regarde pas si votre base de données est ouverte sur Internet, si vos clés d'accès traînent dans un dépôt, ou si un ancien collaborateur a encore ses droits.

Cette ligne se déplace selon le modèle de service. Sur une machine virtuelle, vous êtes responsable du système, des correctifs et des applications. Sur une base managée, le fournisseur reprend les correctifs du moteur, et vous gardez les données, les accès et le chiffrement. Ce qui ne change jamais de côté : vos données, vos identités, vos permissions.

La ligne exacte, service par service, est détaillée dans Le modèle de responsabilité partagée.

Les domaines, et ce que chacun protège

Voici la carte complète. Chaque ligne répond à une question différente, et aucune ne remplace les autres : un pare-feu parfait ne protège pas d'une clé d'accès publiée par erreur.

Domaine	La question à laquelle il répond	Traité dans
Identités et accès	Qui a le droit de faire quoi ?	IAM
Authentification forte	Comment sait-on que c'est bien cette personne ?	IAM et Zero Trust
Secrets	Où vivent les mots de passe et les clés que le code utilise ?	Gestion des secrets
Chiffrement	Que voit celui qui met la main sur le disque ou sur le câble ?	Chiffrement au repos et en transit
Sécurité réseau	Qui peut joindre quoi, sur quel port ?	Groupes de sécurité et ACL
Sécurité des charges	Le système et les dépendances sont-ils à jour ?	Analyse de code et de dépendances
Posture de configuration	Combien de réglages dangereux traînent, à cet instant ?	Prowler
Journalisation et détection	Saurait-on dire ce qui s'est passé ?	Menaces, détection et bonnes pratiques ANSSI
Souveraineté et conformité	Sous quelle juridiction, et avec quelles obligations ?	Souveraineté technologique

Glissez pour voir

Trois de ces domaines sont souvent oubliés, et ce sont rarement les plus techniques.

Les secrets. Tout le monde sait qu'il ne faut pas mettre un mot de passe dans le code. La difficulté réelle est ailleurs : il faut bien que l'application obtienne ce mot de passe au démarrage. La réponse moderne consiste à ne plus distribuer de secret du tout, mais une identité à la charge de travail, qui échange une preuve contre un jeton de courte durée. Un secret qui n'existe pas ne fuit pas.

La posture de configuration. Une infrastructure n'est pas sécurisée une fois pour toutes : elle dérive. Un port ouvert pour déboguer, un bucket rendu public le temps d'un test, une permission élargie un vendredi soir. Un outil de posture relit périodiquement la configuration réelle et signale ces écarts. C'est le seul domaine qui mesure l'état présent plutôt que l'intention.

La journalisation. Elle ne protège de rien, et sans elle vous ne pouvez ni comprendre un incident, ni prouver qu'il n'y en a pas eu. La question à se poser n'est pas « est-ce que je journalise », mais « saurais-je répondre à : qui a supprimé cette ressource, et quand ? ».

Par où commencer, concrètement

Si vous héritez d'une infrastructure existante, l'ordre ci-dessous va du plus rentable au moins urgent. Il est bâti sur une idée simple : commencer par ce qui est exploitable depuis l'extérieur, sans authentification.

1. Ce qui est exposé sans authentification

   Stockage objet accessible publiquement, base de données joignable depuis Internet, interface d'administration ouverte. Ces défauts ne demandent aucune compétence pour être exploités : ils sont trouvés par balayage automatisé, en quelques minutes. C'est la seule catégorie où le délai de correction se compte en heures.

2. Les accès trop larges et les comptes dormants

   Les droits d'administration distribués « en attendant », les clés d'accès de personnes parties, les identifiants de longue durée dans les chaînes d'intégration. Voir la page IAM pour les pièges classiques, et la leçon Le moindre privilège appliqué pour dimensionner les droits.

3. La journalisation, avant d'en avoir besoin

   Activez-la maintenant, pas après l'incident. Un journal qui commence le jour de la panne ne sert à rien : ce qu'on cherche s'est produit avant.

4. Le filtrage réseau

   Une fois l'exposition évidente traitée, restreignez les flux internes. La segmentation limite la portée d'une compromission, elle ne l'empêche pas, et c'est déjà beaucoup.

5. Le chiffrement et les secrets

   Souvent activables sans interruption de service sur les stockages managés. Le chantier des secrets est plus long parce qu'il touche au code.

6. La posture en continu

   Une fois le terrain assaini, mettez en place la mesure régulière qui vous dira quand il dérive à nouveau.

Ce que cet ordre suppose, et qu'il faut vérifier

Il suppose que vous savez ce que vous avez. Beaucoup d'équipes découvrent en auditant qu'un compte oublié héberge encore des ressources actives, ou qu'une région inutilisée porte des machines allumées depuis des mois.

Avant de commencer l'étape 1, faites l'inventaire : ressources par région, comptes et projets existants, identités actives. C'est fastidieux et cela révèle presque toujours quelque chose. Le même inventaire sert ensuite à la maîtrise des coûts, ce qui rend l'effort doublement rentable.

Comment protéger le service de métadonnées d'une instance ?

Le service de métadonnées d'une instance est la cible numéro un des attaques SSRF, et deux réglages AWS puis deux réflexes réduisent fortement l'exposition. Ce service, souvent appelé IMDS (Instance Metadata Service), répond à l'intérieur de chaque instance sur l'adresse locale 169.254.169.254. Chez les fournisseurs qui attachent une identité à une instance, il lui remet des identifiants temporaires. Le mécanisme qui les délivre est enseigné par la section Comment une machine obtient-elle ses droits sans clé ? ; ici, on ne retient que ce qu'il faut pour le défendre.

Cette protection existe à cause d'une attaque bien réelle. Une faille de type SSRF (Server-Side Request Forgery), où une application est amenée à émettre une requête vers une adresse choisie par l'attaquant, permet d'atteindre ce service depuis l'extérieur et d'en extraire les identifiants de la machine. C'est le scénario de la compromission de Capital One en 2019, qui a exposé les données de plus de cent millions de clients : une requête forgée, un service de métadonnées joignable, et les droits de l'instance dans les mains d'un tiers.

Quatre garde-fous ferment cette porte. Le jeton de la version 2 et la limite de sauts sont deux réglages propres à AWS ; l'en-tête exigé par Azure et Google Cloud n'est pas configurable, on s'assure seulement que le code le fournit ; le rôle minimal vaut partout :

• Exiger la version protégée du protocole (réglage AWS, --http-tokens required), et refuser l'ancienne. La version 2 demande un jeton obtenu par une requête PUT avant toute lecture, et cela se règle instance par instance : la valeur par défaut d'une image ancienne n'est pas toujours la bonne.
• Limiter le nombre de sauts réseau à un (réglage AWS, http-put-response-hop-limit). La réponse à la requête de jeton n'aboutit alors que si elle vient de la machine elle-même, ce qui coupe l'accès depuis un conteneur qui s'y trouve. Si vos conteneurs ont besoin d'une identité, donnez-leur la leur plutôt que de relever cette limite.
• Savoir qu'Azure et Google Cloud exigent un en-tête dédié (Metadata: true, Metadata-Flavor: Google), sans réglage possible : il bloque un simple relais de requête, pas une faille qui peut forger l'en-tête.
• Garder le rôle de l'instance minimal. Un attaquant qui atteint quand même le service n'obtient que ce que le rôle contient : c'est le dernier filet, et le seul qui tienne quand les deux précédents ont cédé.

Chez AWS, les deux réglages s'appliquent par une commande, que l'on vérifie ensuite en relisant les options de l'instance :

aws ec2 modify-instance-metadata-options --instance-id <id-instance> \
  --http-tokens required --http-put-response-hop-limit 1
aws ec2 describe-instances --instance-ids <id-instance> \
  --query 'Reservations[].Instances[].MetadataOptions'

La seconde commande doit afficher "HttpTokens": "required" et "HttpPutResponseHopLimit": 1. Tant que HttpTokens vaut optional, la version ancienne du protocole répond encore, et c'est elle que la faille exploite.

Ces réglages sont ceux des fournisseurs qui documentent une identité attachée aux instances. Pour Scaleway et Outscale, ce mécanisme n'est pas documenté : la section Pourquoi un repli, et pourquoi pas la clé de longue durée ? montre comment s'en passer.

Corriger tôt coûte moins cher, et voici pourquoi

Ce n'est pas une question de multiplicateur, c'est une question de travaux qui s'accumulent. Un défaut trouvé à la conception se répare en changeant un schéma. Le même défaut trouvé en production se répare en changeant le schéma, plus le code déjà écrit, plus les données déjà produites au mauvais format, plus leur migration, le tout sans interrompre le service.

Méfiez-vous des chiffres précis qui circulent sur ce sujet, du type « dix fois plus cher en production ». Les plus cités remontent aux années 1980 et leur publication d'origine est introuvable. Le raisonnement, lui, se vérifie sur n'importe quel projet.

Les quatre erreurs qui reviennent partout

Ces quatre-là ressortent dans presque tous les audits, et aucune ne demande un attaquant sophistiqué.

• Le port d'administration ouvert au monde. 0.0.0.0/0 sur le port 22, posé « le temps de déboguer ». Les balayages le trouvent en minutes.
• Les identifiants de longue durée. Une clé créée aujourd'hui sera encore valide dans trois ans, sur un poste que vous ne contrôlez plus. Préférez des jetons courts obtenus par un rôle.
• Le stockage objet rendu public. Presque toujours pour partager un fichier rapidement, presque jamais remis en privé ensuite.
• Les accès des personnes parties. Le départ est traité côté ressources humaines et oublié côté cloud. Une revue trimestrielle des identités suffit à fermer cette porte.

À retenir

• Le fournisseur sécurise le cloud, vous sécurisez ce que vous y mettez. Vos données, vos identités et vos permissions ne changent jamais de côté.
• La sécurité cloud compte neuf domaines distincts, et aucun ne compense l'absence d'un autre.
• Commencez par ce qui est exploitable sans authentification. C'est la seule urgence qui se compte en heures.
• Activez la journalisation avant d'en avoir besoin : un journal qui démarre le jour de l'incident ne dit rien de ce qui l'a précédé.
• Un secret qui n'existe pas ne fuit pas : préférez une identité de charge de travail à une clé distribuée.
• Le service de métadonnées de l'instance est ce qu'une faille SSRF vise en premier. Version protégée du protocole, un seul saut réseau, rôle minimal.
• Une infrastructure dérive. La mesure régulière de la configuration est le seul domaine qui constate l'état présent.
• Faites l'inventaire d'abord. Il révèle presque toujours des ressources oubliées, et il sert aussi à la facture.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →