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. La sécurité est une responsabilité partagée entre plusieurs acteurs. Comprendre cette répartition est essentiel pour éviter les angles morts où personne ne se sent responsable.
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 »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.
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 »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 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 »-
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, 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é).
| 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 :
| 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” : Google s’engage à aider les clients à réussir leur sécurité, pas seulement à délimiter les responsabilités.
| 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 »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, PodSecurityPolicy/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
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 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.
Ce qu’il faut retenir
Section intitulée « Ce qu’il faut retenir »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.
Documenter et tester
Les hypothèses implicites sont la source des incidents les plus graves. Formaliser les frontières.