La sécurité cloud n'est pas un sujet, c'est une dizaine de sujets 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
Section intitulée « 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.
- Reconnaître les quatre erreurs qui reviennent dans presque tous les audits.
La question qui précède toutes les autres
Section intitulée « 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.
Les domaines, et ce que chacun protège
Section intitulé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é ? | Surveillance et audit |
| Souveraineté et conformité | Sous quelle juridiction, et avec quelles obligations ? | Souveraineté technologique |
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
Section intitulée « 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.
-
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.
-
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, qui détaille le moindre privilège et les pièges classiques.
-
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.
-
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.
-
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.
-
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.
Comment une machine obtient-elle ses droits sans clé ?
Section intitulée « Comment une machine obtient-elle ses droits sans clé ? »Le conseil « ne distribuez pas de clé, attachez une identité » laisse toujours
la même question en suspens : par quel mécanisme concret la machine reçoit-elle
ses droits ? La réponse est un service que tous les fournisseurs exposent, à
l'intérieur de chaque instance, sur l'adresse locale 169.254.169.254. Ce
service de métadonnées répond aux requêtes venues de la machine elle-même et
lui remet des identifiants temporaires correspondant au rôle qui lui est
attaché.
Le mécanisme est simple et il change tout : les identifiants sont de courte durée, renouvelés automatiquement, jamais écrits sur disque, et ils disparaissent avec la machine. Une bibliothèque cliente du fournisseur les récupère toute seule, ce qui explique pourquoi un script fonctionne sur une instance sans qu'aucun fichier de configuration ne contienne de clé.
| Fournisseur | Point d'accès | Protection contre l'appel naïf |
|---|---|---|
| AWS | 169.254.169.254, version 2 du protocole | un jeton doit être obtenu par une requête PUT avant toute lecture |
| Azure | 169.254.169.254/metadata/instance | l'en-tête Metadata: true est obligatoire |
| Google Cloud | metadata.google.internal | l'en-tête Metadata-Flavor: Google est obligatoire |
Ces protections ne sont pas des formalités : elles existent à cause d'une attaque bien réelle. Une faille de type SSRF, 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.
Trois réflexes ferment cette porte, et ils se vérifient en quelques minutes :
- Exiger la version protégée du protocole, et refuser l'ancienne. Chez AWS, cela se règle instance par instance, et la valeur par défaut d'une image ancienne n'est pas toujours la bonne.
- Limiter le nombre de sauts réseau à un. La requête 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.
- 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é.
Le même raisonnement s'applique à vos chaînes d'intégration continue, sans machine cette fois. Un exécuteur de pipeline présente un jeton signé par sa plateforme, votre cloud vérifie cette signature et lui remet des identifiants temporaires. Aucune clé d'accès ne dort plus dans les variables du dépôt, ce qui supprime d'un coup la fuite la plus fréquente. La mise en œuvre est décrite dans OIDC pour GitHub Actions, et la question plus générale du premier secret à distribuer est traitée dans le problème du secret zéro.
Corriger tôt coûte moins cher, et voici pourquoi
Section intitulée « 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
Section intitulée « 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/0sur 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
Section intitulée « À 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 est une dizaine de 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 qui rend cette promesse concrète, et c'est aussi 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.