Quand un incident de sécurité survient, la première question est souvent : « C'est la faute de qui ? » Dans les architectures modernes, cloud, conteneurs, services managés, la réponse n'est jamais simple. Cette page explique le principe de responsabilité partagée : la règle qui délimite ce que le fournisseur sécurise et ce qui reste, toujours, à la charge du client. Destinée aux équipes dev, ops et sécurité qui utilisent du cloud, des conteneurs ou des prestataires externes, elle couvre les modèles IaaS/PaaS/SaaS, Kubernetes, le serverless, l'open source et la matrice RACI pour clarifier qui fait quoi.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Cette page vous donne une grille de lecture concrète pour trancher, face à un incident ou une architecture donnée, qui doit agir. Vous repartirez avec des repères directement applicables sur vos propres systèmes cloud, conteneurs ou prestataires.
- Distinguer les responsabilités du fournisseur et celles du client selon IaaS, PaaS et SaaS
- Identifier les zones grises qui provoquent le plus d'incidents
- Appliquer le modèle aux conteneurs, à Kubernetes et au serverless
- Construire une matrice RACI pour clarifier qui fait quoi entre équipes
- Anticiper les nouvelles obligations réglementaires (Cyber Resilience Act) qui pèsent sur les logiciels open source
Le mythe de la délégation totale
Section intitulée « Le mythe de la délégation totale »Une erreur fréquente consiste à croire que l'utilisation d'un service externe transfère la responsabilité de sécurité. C'est l'un des mythes les plus dangereux du cloud et des services managés.
On entend souvent : « On est dans le cloud, c'est le fournisseur qui gère la sécurité. » Ou encore : « On utilise un service managé, on n'a plus à s'en occuper. » Certains pensent même : « Le prestataire est certifié ISO 27001, on est couverts » ou « C'est un logiciel open source maintenu par une grande communauté, c'est sûr. »
Ces croyances créent des zones grises où personne ne protège réellement les actifs critiques. Le fournisseur sécurise son périmètre, pas le vôtre.
Le principe de responsabilité partagée
Section intitulée « Le principe de responsabilité partagée »La responsabilité partagée (shared responsibility) définit une frontière claire entre ce que le fournisseur sécurise et ce que le client doit sécuriser.
La métaphore de l'immeuble
Section intitulée « La métaphore de l'immeuble »Imaginez un immeuble en location. Le propriétaire (le fournisseur) est responsable de la structure : murs porteurs, toiture, parties communes, ascenseurs. Le locataire (le client) est responsable de son appartement : serrures, alarme, ce qu'il stocke à l'intérieur.
Si quelqu'un entre par une fenêtre que le locataire a laissée ouverte, ce n'est pas la faute du propriétaire, même si l'immeuble est « sécurisé ».
Application au numérique
Section intitulée « Application au numérique »Le fournisseur gère l'infrastructure physique (datacenters, serveurs, réseau) et la virtualisation (hyperviseur, isolation). Pour le système d'exploitation, cela dépend du service : en IaaS c'est le client, en PaaS c'est partagé. Les applications (code, dépendances, configuration) et les données (classification, chiffrement, accès) sont toujours de la responsabilité du client. Pour les identités, le fournisseur propose le service d'authentification, mais la gestion des comptes, le MFA et les mots de passe restent côté client.
Les niveaux de service et leurs frontières
Section intitulée « Les niveaux de service et leurs frontières »Le partage exact des responsabilités dépend directement du modèle de service choisi. Plus le fournisseur automatise (SaaS), moins vous gardez de leviers techniques, mais votre responsabilité sur les données et les accès ne disparaît jamais. Les trois onglets suivants détaillent, modèle par modèle, ce qui reste précisément à votre charge.
Infrastructure as a Service
Section intitulée « Infrastructure as a Service »Le fournisseur gère le matériel et la virtualisation. Le client gère tout le reste : système d'exploitation, middleware, applications, données. C'est le modèle qui laisse le plus de contrôle au client, mais aussi le plus de responsabilités.
Ce que le client doit faire : Patcher le système d'exploitation. Configurer les pare-feux et groupes de sécurité. Durcir les services exposés. Gérer les accès et les identités. Chiffrer les données sensibles. Sauvegarder et restaurer.
Ce que le fournisseur NE fait PAS : Mettre à jour vos serveurs. Fermer les ports que vous avez ouverts. Supprimer les comptes que vous avez créés. Détecter les intrusions dans vos applications.
Platform as a Service
Section intitulée « Platform as a Service »Le fournisseur gère également le système d'exploitation et le runtime. Le client gère les applications et les données. Ce modèle accélère le développement en éliminant la gestion de l'infrastructure, mais exige une vigilance accrue sur le code et ses dépendances.
Ce que le client doit faire : Sécuriser le code applicatif. Gérer les dépendances et leurs vulnérabilités. Configurer l'authentification et les autorisations. Protéger les données stockées. Définir les politiques de réseau applicatives.
Software as a Service
Section intitulée « Software as a Service »Le fournisseur gère presque tout. Le client gère les données, les accès et la configuration. C'est le modèle le plus simple en apparence, mais les risques se concentrent sur deux aspects critiques : la gestion des identités et la classification des données.
Ce que le client doit faire : Gérer les comptes utilisateurs et leurs droits. Activer les options de sécurité disponibles (MFA, SSO). Classifier et protéger les données uploadées. Surveiller l'utilisation et les accès. Respecter les politiques de conformité.
Au-delà du cloud : autres contextes de partage
Section intitulée « Au-delà du cloud : autres contextes de partage »Conteneurs et orchestration
Section intitulée « Conteneurs et orchestration »Avec les conteneurs, les responsabilités se fragmentent davantage sur plusieurs couches. L'image de base est de la responsabilité de l'éditeur (par exemple la distribution Linux). L'image applicative est construite par l'équipe de développement. Le runtime conteneur est géré par l'équipe plateforme ou ops. L'orchestrateur (Kubernetes) est configuré par l'équipe plateforme. La configuration du workload revient à l'équipe applicative.
Une vulnérabilité dans l'image de base n'est pas de la responsabilité de l'équipe applicative, mais c'est son problème si elle n'est pas corrigée.
Logiciels open source
Section intitulée « Logiciels open source »L'utilisation de composants open source crée une responsabilité implicite souvent mal comprise. La communauté développe et maintient le code. L'utilisateur choisit de l'intégrer et assume les conséquences. Personne n'est contractuellement responsable des failles.
Si une vulnérabilité est découverte dans une bibliothèque que vous utilisez, c'est votre responsabilité de la mettre à jour ou de l'atténuer, pas celle du mainteneur bénévole.
Cette responsabilité implicite devient progressivement explicite sur le plan réglementaire. Le Cyber Resilience Act (CRA), le règlement européen sur la cyber-résilience, entre en application par étapes : les obligations de signalement des vulnérabilités exploitées s'appliquent à partir du 11 septembre 2026, et l'essentiel des obligations de conformité à partir du 11 décembre 2027. Les éditeurs qui intègrent des composants open source dans un produit commercial (les « fabricants » au sens du texte) devront documenter et corriger les vulnérabilités tout au long du cycle de vie, même quand le code provient d'un projet communautaire. Les mainteneurs bénévoles et fondations qui publient du logiciel libre sans le commercialiser restent, eux, hors du périmètre des sanctions du CRA : la responsabilité légale reste bien du côté de celui qui intègre et distribue, pas de celui qui code gratuitement.
Prestataires et sous-traitants
Section intitulée « Prestataires et sous-traitants »Externaliser une fonction ne supprime pas la responsabilité, c'est un principe fondamental souvent ignoré. Le prestataire est responsable de l'exécution du service. Le client reste responsable du choix du prestataire et de la supervision. En cas d'incident, les deux peuvent être impliqués.
Un hébergeur compromis peut être fautif techniquement, mais le client qui n'a pas vérifié les pratiques de sécurité ou qui n'avait pas de plan B partage la responsabilité du résultat.
Scénarios concrets
Section intitulée « Scénarios concrets »Les principes théoriques prennent tout leur sens face à des incidents réels. Les deux scénarios suivants, une fuite de données en configuration cloud mal gérée et un incident chez un prestataire externe, montrent comment appliquer la grille de lecture « responsabilité partagée » pour trancher qui doit répondre de quoi.
La fuite de données « dans le cloud »
Section intitulée « La fuite de données « dans le cloud » »Une entreprise stocke des données clients dans un service de stockage cloud. Un jour, ces données sont accessibles publiquement sur Internet.
Investigation : Le bucket de stockage était configuré en accès public. Aucune alerte n'était configurée sur les changements de permissions. Le fournisseur cloud avait averti de la configuration risquée (notification ignorée).
Qui est responsable ? Le fournisseur a fourni un service sécurisable et a alerté. Le client a mal configuré et ignoré l'avertissement. Verdict : responsabilité client.
Le fournisseur n'a pas à empêcher ses clients de faire des choix (légitimes dans certains cas, comme l'hébergement public).
L'incident chez le prestataire
Section intitulée « L'incident chez le prestataire »Une entreprise utilise un prestataire SaaS pour sa gestion RH. Le prestataire subit une attaque et les données des employés fuitent.
Situation : Le prestataire avait des failles connues non corrigées. L'entreprise n'avait pas audité la sécurité du prestataire. Le contrat ne prévoyait pas de clause de sécurité ni de notification d'incident.
Qui est responsable ? Le prestataire est fautif techniquement. L'entreprise n'a pas fait sa due diligence (la vérification préalable des pratiques de sécurité d'un partenaire, avant de lui confier des données) et reste responsable des données de ses employés vis-à-vis d'eux et du régulateur. Verdict : responsabilité partagée.
L'entreprise ne peut pas se défausser sur le prestataire, surtout si elle n'a pas vérifié ses pratiques.
Clarifier les responsabilités en pratique
Section intitulée « Clarifier les responsabilités en pratique »Comprendre le principe ne suffit pas : il faut l'appliquer systématiquement, système par système. La démarche suivante en quatre étapes transforme un principe abstrait en pratique opérationnelle vérifiable, et empêche les zones grises de s'installer silencieusement.
-
Cartographier les acteurs
Pour chaque système, identifier : Qui développe le code ? Qui opère l'infrastructure ? Qui configure les accès ? Qui supervise la sécurité ? Qui répond aux incidents ?
-
Documenter les frontières
Formaliser explicitement : ce que le fournisseur garantit (SLA, l'engagement contractuel de niveau de service, et certifications). Ce que le client doit faire (configuration, surveillance). Les zones grises à clarifier.
-
Éviter les hypothèses
Ne jamais supposer que « quelqu'un d'autre s'en occupe ». Si ce n'est pas écrit et validé, c'est probablement une zone grise non couverte.
-
Tester les frontières
Valider régulièrement que chaque partie assume ses responsabilités : audit des configurations client, revue des SLA et engagements fournisseur, exercices de réponse à incident impliquant tous les acteurs.
Responsabilités par fournisseur cloud
Section intitulée « Responsabilités par fournisseur cloud »Les trois grands fournisseurs cloud (AWS, Azure, GCP) partagent le même principe de responsabilité partagée, mais avec des nuances importantes.
AWS, Shared Responsibility Model
Section intitulée « AWS, Shared Responsibility Model »AWS utilise le terme "Security OF the cloud" (leur responsabilité) vs "Security IN the cloud" (votre responsabilité) pour distinguer, service par service, ce qui relève de son infrastructure de ce qui reste sous votre configuration.
| Couche | AWS | Client |
|---|---|---|
| Datacenters physiques | Sécurité physique, alimentation, refroidissement | - |
| Réseau global | Backbone, edge locations, DDoS L3/L4 | - |
| Hyperviseur | Isolation des instances | - |
| EC2 (IaaS) | Infrastructure matérielle | OS, patching, firewall, données |
| RDS (PaaS) | Patching DB, backups (si activés) | Configuration, utilisateurs, données |
| S3 (Stockage) | Durabilité, disponibilité | Bucket policies, ACLs, chiffrement |
| Lambda (Serverless) | Runtime, scaling, infra | Code, dépendances, permissions IAM |
| IAM | Service disponible et sécurisé | Politiques, utilisateurs, MFA |
Azure, Shared Responsibility Model
Section intitulée « Azure, Shared Responsibility Model »Azure distingue les responsabilités selon le modèle de service, du SaaS au on-premise, avec une gradation progressive du périmètre client : plus on descend vers l'infrastructure gérée en interne, plus la part du client augmente.
| Responsabilité | SaaS | PaaS | IaaS | On-prem |
|---|---|---|---|---|
| Information et données | Client | Client | Client | Client |
| Appareils (mobile/PC) | Client | Client | Client | Client |
| Comptes et identités | Client | Client | Client | Client |
| Infrastructure d'identité | Partagé | Partagé | Client | Client |
| Applications | Microsoft | Client | Client | Client |
| Contrôles réseau | Microsoft | Partagé | Client | Client |
| Système d'exploitation | Microsoft | Microsoft | Client | Client |
| Hôtes physiques | Microsoft | Microsoft | Microsoft | Client |
| Réseau physique | Microsoft | Microsoft | Microsoft | Client |
| Datacenter physique | Microsoft | Microsoft | Microsoft | Client |
GCP, Shared Fate Model
Section intitulée « GCP, Shared Fate Model »Google Cloud va plus loin avec le concept de "Shared Fate" (le destin partagé) : Google s'engage à aider activement les clients à réussir leur sécurité, pas seulement à délimiter des responsabilités et à s'en tenir là.
| Service | Google Cloud | Client |
|---|---|---|
| Compute Engine | Infra, hyperviseur | OS, applications, données |
| GKE (Kubernetes) | Control plane, upgrades | Workloads, RBAC, network policies |
| Cloud Run | Runtime, scaling | Code, dépendances, secrets |
| Cloud Storage | Durabilité, chiffrement au repos | IAM, ACLs, classification données |
| BigQuery | Infrastructure, chiffrement | Accès, requêtes, données |
Modèle Kubernetes, 5 couches de responsabilité
Section intitulée « Modèle Kubernetes, 5 couches de responsabilité »Avec Kubernetes, les responsabilités se fragmentent sur 5 couches distinctes. La répartition dépend de si vous utilisez un service managé ou un cluster auto-géré.
| Couche | Managed K8s (EKS/GKE/AKS) | Self-managed |
|---|---|---|
| 1. Cluster (control plane) | Provider | Client |
| 2. Nodes (workers) | Partagé (AMI/images) | Client |
| 3. Réseau (CNI, policies) | Partagé | Client |
| 4. Workloads (pods, deployments) | Client | Client |
| 5. Images conteneurs | Client | Client |
Détail par couche
Section intitulée « Détail par couche »Chaque couche mérite un examen séparé, car le niveau de délégation au fournisseur varie fortement de l'une à l'autre. Voici, couche par couche, ce qui bascule côté provider et ce qui reste, dans tous les cas, de votre ressort.
Couche 1, Control Plane :
- En managé : le provider gère etcd, API server, scheduler, controller-manager
- Vous gardez la responsabilité de la configuration RBAC
Couche 2, Nodes :
- En managé : le provider fournit des AMI/images sécurisées
- Vous devez activer les mises à jour automatiques et surveiller les CVE
Couche 3, Réseau :
- Network Policies sont de VOTRE responsabilité (désactivées par défaut !)
- Le provider gère le CNI sous-jacent mais pas vos règles
Couche 4, Workloads :
- SecurityContext, Pod Security Standards : votre responsabilité
- Secrets : votre responsabilité (même si stockés dans etcd managé)
Couche 5, Images :
- Scanner les images : votre responsabilité
- Corriger les CVE dans vos images : votre responsabilité
- Le runtime est sécurisé par le provider, pas le contenu
Les modes tout-géré : EKS Auto Mode, GKE Autopilot, AKS Automatic
Section intitulée « Les modes tout-géré : EKS Auto Mode, GKE Autopilot, AKS Automatic »Les trois fournisseurs proposent désormais des modes qui automatisent une part croissante des couches 2 et 3. EKS Auto Mode délègue à AWS le cycle de vie complet des instances (patching, scaling, santé), GKE Autopilot va plus loin en gérant intégralement le plan de données, et AKS Automatic prend en charge les composants coeur de la plateforme. Ces modes réduisent le travail opérationnel quotidien mais ne suppriment jamais votre responsabilité sur les couches 4 et 5 : configuration des workloads, RBAC applicatif, secrets et contenu des images restent, dans tous les cas, de votre ressort. Ils redistribuent la charge, ils ne l'éliminent pas.
Serverless, Moins de responsabilités, pas zéro
Section intitulée « Serverless, Moins de responsabilités, pas zéro »Le Serverless (Lambda, Cloud Functions, Azure Functions) réduit drastiquement le périmètre client, mais ne l'élimine pas. C'est le modèle où le fournisseur prend en charge le plus de responsabilités, mais attention, « moins de responsabilités » ne signifie pas « zéro responsabilité ». Le tableau ci-dessous détaille précisément ce qui reste à votre charge.
| Aspect | Provider | Client |
|---|---|---|
| Infrastructure | Serveurs, scaling, disponibilité | - |
| Runtime | Patching, sécurité du runtime | - |
| Code | - | Logique, vulnérabilités |
| Dépendances | - | Librairies, CVE |
| Permissions | - | IAM roles (souvent trop permissifs) |
| Secrets | Service disponible | Gestion, rotation |
| Données | - | Chiffrement, classification |
Anti-pattern Serverless : donner *:* (toutes permissions) à une Lambda "parce que c'est plus simple". Le moindre privilège s'applique encore plus en Serverless car les fonctions sont souvent exposées publiquement.
La matrice RACI pour clarifier les responsabilités
Section intitulée « La matrice RACI pour clarifier les responsabilités »Quand plusieurs équipes interviennent sur un même système, les responsabilités deviennent floues. La matrice RACI est un outil simple mais puissant pour formaliser qui fait quoi et éviter que des tâches critiques tombent entre les mailles du filet.
| Lettre | Signification | Description |
|---|---|---|
| R | Responsible | Fait le travail |
| A | Accountable | Responsable final (1 seul par tâche) |
| C | Consulted | Donne un avis avant |
| I | Informed | Informé après |
Exemple : Gestion d'une vulnérabilité dans une image conteneur
Section intitulée « Exemple : Gestion d'une vulnérabilité dans une image conteneur »Prenons un cas concret : une CVE critique (Common Vulnerabilities and Exposures, l'identifiant public d'une faille de sécurité connue) est découverte dans une image conteneur utilisée en production. Qui doit faire quoi ? Sans matrice RACI, chaque équipe attend que « l'autre » s'en occupe, et la faille reste ouverte pendant des semaines.
| Action | Dev | Ops | Sécurité | Management |
|---|---|---|---|---|
| Détecter la CVE | I | R | A | I |
| Évaluer l'impact | C | R | A | I |
| Corriger l'image | R | C | I | I |
| Valider le correctif | C | R | A | I |
| Décider du déploiement | I | C | C | A |
| Déployer | R | A | I | I |
Sans cette clarification, la CVE reste dans les limbes pendant que chaque équipe attend que « l'autre » s'en occupe.
À retenir
Section intitulée « À retenir »Retenez ces points essentiels : ils résument le raisonnement à appliquer face à n'importe quel fournisseur, service managé ou prestataire externe.
Toujours partagée
Aucun fournisseur ne prend en charge 100% de la sécurité. Il reste toujours une part client.
Pas de transfert automatique
Utiliser un service externe ne transfère pas la responsabilité. Le client reste responsable de ses données, accès et configurations.
Frontières variables
IaaS laisse plus de responsabilités au client que PaaS, qui en laisse plus que SaaS.
Zones grises = vulnérabilités
Si personne ne sait qui est responsable d'un aspect, personne ne s'en occupe.
Les modes tout-géré redistribuent, n'éliminent pas
EKS Auto Mode, GKE Autopilot, AKS Automatic réduisent le travail opérationnel mais laissent workloads, secrets et images à votre charge.
La réglementation formalise l'implicite
Le Cyber Resilience Act impose aux éditeurs qui intègrent de l'open source de documenter et corriger les vulnérabilités, dès 2026.
Documenter et tester
Les hypothèses implicites sont la source des incidents les plus graves. Formaliser les frontières avec une matrice RACI.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Pour aller plus loin
Section intitulée « Pour aller plus loin »Pour approfondir la mise en oeuvre de ces principes, ces guides connexes du parcours fondamentaux détaillent la gestion des vulnérabilités, les causes organisationnelles des angles morts et les arbitrages de sécurité au quotidien.