Louer un local aux Arcades : nu, aménagé ou clé en main

Aux Arcades, le centre commercial qui sert de fil rouge à cette série, un nouveau commerçant a trois façons de s'installer. Il peut louer un local entièrement nu : quatre murs, un compteur, et à lui de poser le sol, le rideau de fer, l'éclairage, les rayonnages. Il peut louer un local déjà aménagé, avec vitrine, comptoir et électricité prêts à l'emploi, où il n'a qu'à installer sa marchandise. Ou il peut reprendre un comptoir clé en main, personnel fourni, où il se contente de vendre.

Dans les trois cas, le bailleur reste responsable d'une chose : la structure du bâtiment, les entrées communes, les portiques à l'entrée, les vigiles. Mais aucun de ces trois commerçants n'est dispensé de fermer son rideau le soir et de gérer ses clés. Le bailleur sécurise le bâtiment. Le commerçant sécurise sa boutique. Personne ne peut faire l'autre moitié à sa place.

Le cloud déplace la frontière de ce que tu gères toi-même, mais il ne supprime jamais ta part de responsabilité. Il la déplace, parfois de façon contre-intuitive.

C'est exactement ce que décrivent les modèles cloud (IaaS, PaaS, SaaS) et le concept qui les sous-tend : le modèle de responsabilité partagée. Cet article suit la même logique que le local des Arcades, du local nu jusqu'au comptoir clé en main, puis montre où se situent les erreurs qui finissent en fuite de données.

Vue d'ensemble : trois modèles, une seule frontière mobile

Avant le détail, la carte du territoire. Quand tu héberges une application, il faut empiler plusieurs couches : le réseau et le datacenter, les serveurs physiques, la virtualisation, le système d'exploitation, le runtime, l'application, et enfin les données. Sur une machine que tu possèdes, tu gères tout. Dans le cloud, le fournisseur en prend une partie à sa charge.

Les trois grands modèles se distinguent par l'endroit où passe cette frontière.

  • IaaS (Infrastructure as a Service). Le fournisseur te livre l'infrastructure brute : du calcul, du stockage, du réseau. Tu gères tout ce qui est au-dessus, à partir du système d'exploitation. C'est le local nu.
  • PaaS (Platform as a Service). Le fournisseur gère aussi le système, le runtime et la plateforme d'exécution. Tu n'apportes que ton code et ta configuration. C'est le local aménagé.
  • SaaS (Software as a Service). Le fournisseur gère l'application complète. Tu te contentes de l'utiliser et de gérer tes comptes et tes données. C'est le comptoir clé en main.

Une constante traverse les trois : les données et les identités restent toujours de ton côté. Le fournisseur ne sait pas qui doit accéder à quoi dans ton organisation, ni quelles données sont sensibles. Cette partie ne se délègue pas.

C'est cette frontière mobile, et la zone grise juste autour, que le reste de l'article détaille.

IaaS, PaaS, SaaS : qui garde quoi à sa charge

Reviens aux Arcades. Le commerçant du local nu doit tout sécuriser sauf le bâtiment. Celui du local aménagé hérite déjà d'une vitrine et d'une serrure posées par le bailleur, mais c'est encore lui qui décide à qui il confie ses clés. Celui du comptoir clé en main n'a plus à se soucier du matériel, mais il reste seul responsable de sa caisse et de son fichier clients.

La transposition IT est directe. Plus tu montes vers le SaaS, plus le fournisseur absorbe de couches, et plus ta part se concentre sur le haut de la pile : la configuration, les accès, les données.

Le tableau suivant lit chaque couche de bas en haut et indique qui en a la charge selon le modèle. « Fournisseur » signifie que le cloud s'en occupe, « Client » que la responsabilité reste chez toi.

Couche On-premise IaaS PaaS SaaS
Datacenter et réseau physique Client Fournisseur Fournisseur Fournisseur
Serveurs et virtualisation Client Fournisseur Fournisseur Fournisseur
Système d'exploitation Client Client Fournisseur Fournisseur
Runtime et middleware Client Client Fournisseur Fournisseur
Application Client Client Client Fournisseur
Configuration et réseau logique Client Client Client Client
Identités et accès (IAM) Client Client Client Client
Données Client Client Client Client

Deux lignes ne changent jamais de colonne, quel que soit le modèle : les identités et les données. C'est le cœur du message. Aucun fournisseur, aussi sérieux soit-il, ne configure tes droits d'accès ni ne classe tes données à ta place.

Plus le modèle est managé, plus ta surface de responsabilité se réduit en quantité, mais se concentre sur ce qui compte le plus : qui accède à quoi, et ce qui est exposé.

Cette concentration est un piège discret. En SaaS, tu n'as presque rien à gérer, donc on a tendance à croire qu'il n'y a rien à sécuriser. Or les quelques boutons qui restent (partages publics, droits d'administration, jetons d'API) sont précisément ceux qui causent les fuites.

Le modèle de responsabilité partagée

Aux Arcades, personne ne signe un bail en imaginant que le bailleur viendra fermer chaque boutique le soir. La répartition est implicite mais comprise : le bailleur tient le bâtiment, le commerçant tient son local. Dans le cloud, cette répartition porte un nom, le modèle de responsabilité partagée, et elle est écrite noir sur blanc par chaque fournisseur.

L'idée tient en une phrase. Le fournisseur est responsable de la sécurité du cloud (l'infrastructure qu'il opère). Le client est responsable de la sécurité dans le cloud (ce qu'il y met et comment il le configure). C'est la formulation qu'emploient les pages officielles d'AWS et d'Azure.

Le schéma ci-dessous montre comment la ligne de partage glisse vers le haut à mesure qu'on passe de l'IaaS au SaaS.

flowchart TB subgraph IaaS["IaaS (local nu)"] direction TB i_p["Fournisseur : datacenter, réseau, hyperviseur"] i_c["Client : OS, runtime, appli, config, IAM, données"] end subgraph PaaS["PaaS (local aménagé)"] direction TB p_p["Fournisseur : + OS, runtime, plateforme"] p_c["Client : appli, config, IAM, données"] end subgraph SaaS["SaaS (comptoir clé en main)"] direction TB s_p["Fournisseur : + application complète"] s_c["Client : config, IAM, données"] end IaaS --> PaaS --> SaaS classDef prov fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef cli fill:#ede9e1,stroke:#b5651d,color:#1a1a1a classDef grp fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a class i_p,p_p,s_p prov class i_c,p_c,s_c cli class IaaS,PaaS,SaaS grp
La sécurité du cloud relève du fournisseur ; la sécurité dans le cloud relève de toi. Confondre les deux, c'est croire qu'on est protégé alors que la moitié du travail n'a pas été faite.

Le danger n'est pas tant dans les cas clairs (chacun sait que le fournisseur gère le matériel) que dans la zone grise. Qui patche l'image système d'une base de données managée ? Qui chiffre les sauvegardes ? Qui restreint un partage public ? La réponse dépend du service exact, et c'est précisément pour cela que ces matrices de responsabilité sont publiées et qu'il faut les lire avant de déployer.

Les erreurs fréquentes côté client

Aux Arcades, le bailleur a beau aligner vigiles et caméras, rien ne protège un commerçant qui laisse son rideau à moitié relevé, distribue un double de ses clés à tout le monde, ou colle le code de son coffre sur la caisse. Les incidents cloud suivent le même schéma : ce ne sont presque jamais des failles de l'infrastructure du fournisseur, mais des erreurs de configuration côté client.

Quatre familles reviennent sans cesse.

Le stockage exposé publiquement

Un bucket de stockage objet (S3 chez AWS, équivalents ailleurs) configuré en accès public est la fuite la plus banale et la plus médiatisée. Le service fonctionne, l'application tourne, et personne ne remarque que n'importe qui sur Internet peut lister et télécharger le contenu. La bonne pratique est le « secure by default » : bloquer l'accès public au niveau du compte, n'ouvrir que ce qui doit l'être, et auditer régulièrement.

L'IAM trop permissif

Donner à un rôle ou à un compte des droits * (« tout, partout ») est l'équivalent du double de clés distribué sans réfléchir. C'est le contraire du moindre privilège, le principe développé dans le billet Zero Trust, moindre privilège et surface d'attaque. Chaque permission de trop élargit la surface d'attaque et transforme une compromission mineure en compromission totale. La gestion fine de ces droits est l'objet du billet IAM et PAM : gérer identités et accès à privilèges.

Les secrets en clair

Clés d'API, mots de passe de base de données et jetons stockés dans un fichier de configuration, une variable d'environnement non protégée ou, pire, dans un dépôt Git public. Une fois un secret exposé, il ne suffit pas de le supprimer : il faut le révoquer et le faire tourner, car il a peut-être déjà été copié. Les fournisseurs proposent tous un coffre dédié (gestionnaire de secrets) qu'il faut utiliser à la place.

# Mauvais : le secret est en clair dans le code et finira dans l'historique Git
DB_PASSWORD="S3cret!2024"

# Mieux : la valeur est lue depuis un gestionnaire de secrets au démarrage
DB_PASSWORD="$(read-secret prod/db/password)"

Le service de métadonnées d'instance

C'est l'erreur la moins connue et l'une des plus dangereuses. Chaque instance de calcul cloud expose un service de métadonnées sur une adresse interne fixe (169.254.169.254), accessible depuis la machine elle-même. Ce service peut délivrer les identifiants temporaires du rôle attaché à l'instance. Si une application sur cette machine peut être détournée pour interroger cette adresse à la place de l'attaquant, par exemple via une faille de type SSRF (Server-Side Request Forgery), elle peut récupérer ces identifiants et les utiliser pour accéder à d'autres ressources.

La quasi-totalité des fuites cloud médiatisées tient à une configuration côté client : stockage ouvert, droits trop larges, secret exposé ou métadonnées accessibles. L'infrastructure du fournisseur n'est presque jamais en cause.

Ces quatre points partagent une racine commune : ils relèvent tous de la partie qui ne se délègue pas, en haut de la pile, là où ta responsabilité se concentre quel que soit le modèle.

Scénario B : Capital One, 2019

Le cas qui illustre le mieux la responsabilité partagée est la compromission de Capital One en 2019. Il combine plusieurs des erreurs ci-dessus en une seule chaîne, et il a été documenté en détail par la justice américaine.

D'après l'acte d'accusation du Department of Justice, l'attaquante a exploité une faille de type SSRF rendue possible par un pare-feu applicatif (WAF) mal configuré. Cette SSRF lui a permis d'atteindre le service de métadonnées d'instance depuis le serveur, puis d'en extraire les identifiants temporaires du rôle attaché à la machine. Ce rôle disposait de droits suffisamment larges pour lister et lire le contenu de buckets de stockage S3, où se trouvaient des données concernant environ 100 millions de clients aux États-Unis.

La chaîne est limpide : WAF mal configuré, donc SSRF, donc accès aux métadonnées, donc identifiants d'un rôle trop permissif, donc lecture des données. À chaque maillon, on retrouve une responsabilité côté client, pas côté fournisseur.

L'infrastructure cloud sous-jacente n'a pas été percée. Ce sont la configuration du WAF, l'étendue du rôle IAM et l'exposition du service de métadonnées (tous du ressort du client) qui ont rendu l'attaque possible.

C'est la démonstration grandeur nature du modèle de responsabilité partagée. Le fournisseur tenait son côté du bail : le bâtiment était sûr. Mais le rideau côté client était relevé, et les clés traînaient. À la suite de cet incident, l'usage du service de métadonnées dans sa version plus protégée (qui exige une étape supplémentaire et bloque les détournements de type SSRF) est devenu une recommandation standard. La leçon ne dépend pas d'un fournisseur en particulier : elle vaut pour tout déploiement cloud.

Points clés

  • IaaS, PaaS, SaaS se distinguent par l'endroit où passe la frontière entre ce que gère le fournisseur et ce qui reste à ta charge : du local nu au comptoir clé en main.
  • Le modèle de responsabilité partagée sépare la sécurité du cloud (fournisseur) de la sécurité dans le cloud (client). La zone grise, propre à chaque service, se lit dans la matrice officielle du fournisseur.
  • Identités et données restent de ton côté quel que soit le modèle. Plus le service est managé, plus ta responsabilité se concentre sur la configuration et les accès.
  • Les fuites cloud viennent presque toujours du client : stockage exposé, IAM trop permissif, secrets en clair, métadonnées accessibles, à relier au moindre privilège et à l'IAM.
  • Le cas Capital One (2019) enchaîne ces erreurs : un WAF mal configuré ouvre une SSRF, qui atteint les métadonnées et un rôle trop large, jusqu'aux données. Tout côté configuration client.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Cloud & applications.

Pour aller plus loin