Comment auditer la responsabilité partagée cloud

Le fournisseur sécurise le socle qu’il exploite, pas l’usage qui en est fait. Le compromis est net : le cloud retire la charge matérielle et une part de l’exploitation, mais transfère la responsabilité de comprendre, configurer, surveiller et prouver les contrôles restants.

→ Lire l’explication complète de la marmotte

La responsabilité partagée n’est pas un transfert de risque

Le modèle de responsabilité partagée décrit une répartition des tâches de sécurité entre le fournisseur et le client. Il ne transfère pas le risque métier au fournisseur. Une donnée divulguée via un stockage public reste une donnée divulguée, même si le centre de données est mieux gardé qu’une banque suisse sous caféine.

Le fournisseur prend généralement en charge la sécurité du cloud : bâtiments, alimentation, matériel, réseau physique, hyperviseur, remplacement des disques et isolation fondamentale entre locataires. Cette isolation n’est pas absolue au sens magique du terme. Elle dépend du matériel, du microcode, de l’hyperviseur et des correctifs appliqués par le fournisseur. Les attaques par canal auxiliaire, les vulnérabilités de processeur et les défauts d’isolation existent, mais leur traitement relève principalement de son périmètre.

Le client prend en charge la sécurité dans le cloud : identités, droits, configurations réseau, chiffrement, journalisation, classification des données, règles de rétention, applications et secrets. Le fournisseur peut proposer des contrôles, parfois les activer par défaut, rarement décider à la place du propriétaire de la donnée qui doit y accéder.

La règle d’architecture est donc brutale : tout contrôle exposé dans une console, une interface de programmation ou un fichier de configuration doit avoir un propriétaire côté client, sauf engagement contractuel explicite et vérifiable du fournisseur. Une option disponible n’est pas une sécurité active. C’est un interrupteur, avec un joli logo autour.

Cette lecture doit compléter les principes décrits dans la section cloud et exploitation, notamment par un inventaire des ressources et de leurs propriétaires techniques. Sans inventaire, la matrice de responsabilité devient un exercice de peinture abstraite.

IaaS, PaaS et SaaS : la frontière se déplace, elle ne disparaît pas

En Infrastructure as a Service (IaaS), le fournisseur gère le matériel, le réseau physique, le stockage sous-jacent et la virtualisation. Le client gère le système d’exploitation invité, les correctifs, les services exposés, les pare-feu logiciels, les comptes, les clés, les données et l’application. Une machine virtuelle non corrigée n’est pas une vulnérabilité du cloud : c’est un serveur classique avec une facture plus créative.

En Platform as a Service (PaaS), le fournisseur exploite aussi le système d’exploitation, le moteur d’exécution ou le moteur de base de données. Le client reste responsable des utilisateurs, des rôles, des règles d’accès réseau, des données importées, des paramètres de chiffrement disponibles, de la journalisation applicative et du code déployé. Une base administrée peut recevoir ses correctifs sans intervention, puis être rendue publique par une règle réseau. Les deux affirmations sont simultanément vraies, ce qui fait tout le charme du sujet.

En Software as a Service (SaaS), le fournisseur gère l’application elle-même. Le client conserve la responsabilité de son paramétrage fonctionnel, des comptes, de l’authentification, des délégations, des données téléversées, des exports et de la révocation des accès. Un fournisseur peut chiffrer un document au repos tout en laissant un utilisateur invité le partager publiquement. Le chiffrement ne corrige pas une décision d’autorisation.

La frontière utile n’est pas celle des schémas à trois couleurs. Pour chaque actif, il faut poser quatre questions :

Qui peut modifier la configuration de sécurité ?
Qui applique le correctif quand une vulnérabilité apparaît ?
Qui peut lire, exporter ou supprimer les données ?
Qui détecte et traite l’événement quand le contrôle échoue ?

Si la réponse est « le fournisseur, probablement », le contrôle n’a pas de propriétaire. Il faut un nom d’équipe, une fréquence de vérification, une source de preuve et une procédure d’escalade.

Incidents typiques : le bucket public et la base sans frontière réseau

Le premier cas classique concerne un compartiment de stockage objet. Le fournisseur garantit la disponibilité du service, l’isolation des comptes clients et les mécanismes de contrôle d’accès. Le client définit la politique du compartiment, les droits de lecture, les liens de partage et le blocage des accès publics.

L’incident naît lorsqu’un compartiment reçoit une politique autorisant la lecture anonyme, ou lorsqu’un mécanisme de blocage global des accès publics reste désactivé. Le fournisseur n’a pas à deviner si un export contient des images publiques, des sauvegardes ou des pièces d’identité. Une détection peut être proposée, mais une alerte non lue reste une décoration de tableau de bord.

Le second cas concerne une base de données administrée. L’équipe applicative suppose que le fournisseur filtre les accès Internet parce que le moteur est géré. L’équipe plateforme suppose que l’application n’ouvrira pas de règle réseau large. Une règle autorisant 0.0.0.0/0 sur le port de la base rend le service joignable depuis Internet. L’authentification de la base réduit alors l’exposition, mais ne remplace ni le filtrage réseau ni la détection de tentatives par force brute.

La contre-mesure doit être structurelle : interdire les chemins réseau publics par politique d’organisation, exiger un point d’accès privé, journaliser les flux refusés et vérifier les règles à chaque changement. Laisser la sécurité dépendre d’une convention orale entre deux équipes revient à déléguer le pare-feu à un pigeon voyageur.

Ces incidents recoupent la gestion des identités : une politique réseau restrictive ne protège pas contre un rôle trop puissant, et un rôle minimal ne protège pas une base laissée sur Internet. La page IAM et accès cloud complète cette partie sur les identités et les autorisations.

Lire une matrice fournisseur sans avaler la légende

Une matrice de responsabilité doit être lue ligne par ligne, service par service, et non comme une promesse générale. Les expressions « sécurisé par défaut », « géré », « chiffré » et « conforme » exigent une question supplémentaire : par qui, avec quelle configuration, et quelle preuve reste accessible ?

Pour chaque ligne, distinguer quatre états :

Exploité par le fournisseur : le fournisseur exécute le contrôle et corrige son composant.
Configuré par le client : le mécanisme existe, mais son activation, son paramétrage ou son usage restent côté client.
Partagé : le fournisseur protège la plate-forme, le client choisit les règles appliquées aux ressources.
Hors périmètre : ni le service ni son contrat ne couvrent le besoin, par exemple la sauvegarde métier d’un export supprimé par un compte légitime.

Le chiffrement illustre très bien le piège. Un fournisseur peut chiffrer les volumes avec des clés qu’il gère. Cela ne garantit ni la séparation des administrateurs métier, ni la rotation d’une clé contrôlée par le client, ni la récupération après suppression de la clé, ni la confidentialité face à un compte client compromis. Pour les données à forte sensibilité, choisir une clé gérée par le client impose d’exploiter ses autorisations, sa rotation, ses journaux et ses procédures de restauration. Une clé non sauvegardée n’est pas une stratégie de souveraineté, c’est un bouton d’autodestruction avec conformité en police huit.

La matrice doit aussi préciser les dépendances : région activée, journalisation du plan de contrôle, export des journaux vers un stockage distinct, service de gestion des identités, réseau privé, résolution de noms et compte de secours. Un contrôle sans dépendances recensées casse précisément pendant l’incident, quand tout le monde découvre qu’il dépendait de l’accès administratif habituel.

Exemple reproductible : vérifier et bloquer l’accès public à un bucket

L’exemple suivant utilise l’interface en ligne de commande d’Amazon Web Services (AWS). Il vérifie les protections contre l’accès public d’un bucket de stockage objet, puis les active. Le compte exécutant doit disposer des autorisations de lecture et modification sur ce bucket. La commande ne remplace pas l’examen des politiques existantes : elle réduit la surface d’attaque, elle ne lit pas dans les intentions humaines.

# Définir le bucket à auditer.
BUCKET="exemple-donnees-confidentielles"

# Lire le blocage des accès publics actuellement appliqué au bucket.
aws s3api get-public-access-block \
  --bucket "$BUCKET"

# Activer les quatre protections contre les politiques et listes publiques.
aws s3api put-public-access-block \
  --bucket "$BUCKET" \
  --public-access-block-configuration \
    BlockPublicAcls=true,\
IgnorePublicAcls=true,\
BlockPublicPolicy=true,\
RestrictPublicBuckets=true

# Vérifier aussi qu'aucune politique de bucket n'autorise un principal universel.
aws s3api get-bucket-policy \
  --bucket "$BUCKET" \
  --query 'Policy' \
  --output text

Cette vérification doit être exécutée par l’automatisation d’Infrastructure as Code (IaC), puis contrôlée hors bande par une règle de conformité. L’IaC évite la dérive intentionnelle ou accidentelle ; le contrôle indépendant détecte qu’un rôle d’administration a contourné l’IaC. Croire qu’un dépôt Git est un contrôle de sécurité parce qu’il contient du YAML reste un rite très populaire dans les temples du DevOps.

Une exception d’accès public doit être documentée avec une durée, un propriétaire, un périmètre de données autorisé et une alerte dédiée. Toute exception permanente devient une configuration normale, mais avec une mauvaise réputation et sans surveillance.

Checklist d’audit de la responsabilité partagée

L’audit doit produire des éléments vérifiables, pas une case cochée dans un tableur. Pour chaque service cloud, contrôler les points suivants :

Identifier le modèle de service : IaaS, PaaS ou SaaS, et la version précise du service consommé.
Associer un propriétaire client à chaque contrôle configurable : réseau, identité, chiffrement, sauvegarde, journalisation et effacement.
Vérifier que les comptes humains utilisent une authentification multifacteur, ou Multi-Factor Authentication (MFA), et que les comptes de service disposent de droits minimaux.
Interdire les identités partagées, les clés d’accès longues durées non justifiées et les comptes administrateurs utilisés au quotidien.
Recenser les interfaces d’administration exposées, les adresses publiques et les règles réseau trop larges.
Tester l’accès effectif depuis un réseau externe et depuis un compte disposant de privilèges limités. Lire une règle ne prouve pas son effet.
Vérifier la journalisation du plan de contrôle, c’est-à-dire les appels qui créent, modifient ou suppriment les ressources.
Exporter les journaux dans un emplacement distinct, avec rétention définie et droits d’écriture séparés des droits de lecture.
Tester la restauration des données, des configurations et des clés. Une sauvegarde non restaurée est une théorie, parfois une poésie.
Examiner la rotation des secrets, les révocations et les accès d’urgence. Un accès d’urgence sans journalisation est juste un accès permanent avec un badge plus dramatique.
Vérifier que les alertes atteignent une équipe capable d’agir, y compris hors des horaires habituels.
Comparer les contrôles constatés avec la matrice contractuelle du fournisseur et documenter les écarts.

Le modèle ne garantit pas la confidentialité métier, la disponibilité applicative, l’absence d’erreur de configuration ou la récupération après suppression volontaire. Ces propriétés viennent de l’architecture : segmentation, séparation des rôles, sauvegardes testées, supervision et procédures de réponse. La responsabilité partagée cesse d’être floue quand chaque action de sécurité a un responsable, une preuve et un test d’échec.

🐝 Ce qui arrive si on s’en passe

Sans audit de la répartition des rôles, l’absence de propriétaire ne se voit qu’au moment où un contrôle échoue. Les journaux du plan de contrôle non activés ne se reconstituent pas après coup : la chronologie d’une modification de politique reste définitivement manquante, et la rétention par défaut d’un service peut effacer les traces avant même la question posée au support du fournisseur. Chaque nouveau service souscrit arrive avec ses propres réglages par défaut, jamais couverts par un examen antérieur, ce qui laisse s’accumuler des écarts invisibles entre comptes et régions. Lors d’un incident, la discussion porte alors sur la répartition des tâches plutôt que sur le confinement, et aucune preuve opposable ne permet de démontrer quel contrôle relevait du fournisseur et lequel relevait du client.

🦫 Explication de la marmotte 🍫

Un fournisseur de cloud fournit des ordinateurs, du stockage et des logiciels accessibles à distance. Il protège les bâtiments, le matériel et une partie des logiciels qu’il exploite. Cela évite au client d’acheter des serveurs et de remplacer les pièces défectueuses.

Mais le client choisit qui peut se connecter, quelles données sont déposées, quels accès sont ouverts et quelles règles protègent les services. Plus le service est géré par le fournisseur, moins le client doit maintenir de logiciels. En revanche, le client garde la responsabilité des utilisateurs, des droits accordés et des données.

Un problème apparaît quand personne ne sait qui devait fermer un accès. Un espace de stockage peut alors être accessible publiquement parce que le fournisseur attendait une règle du client. Une base de données peut être exposée parce que l’équipe qui gère l’application pensait que le fournisseur filtrait Internet, tandis que le fournisseur attendait une règle réseau.

Pour éviter cela, il faut lire les documents du fournisseur service par service. Chaque protection doit avoir un responsable identifié. Il faut vérifier régulièrement les accès publics, les comptes puissants, les copies de données et les traces des modifications. Il faut aussi tester la restauration des sauvegardes. Quand une protection échoue, les traces permettent de comprendre ce qui s’est passé et les sauvegardes permettent de reprendre l’activité.