Quand une fuite de données survient dans le cloud, qui est responsable ? Vous ou le fournisseur ? La réponse : ça dépend. Le cloud fonctionne sur un modèle de responsabilité partagée où chacun sécurise une partie de la pile. Ce guide clarifie exactement ce que le fournisseur gère et ce qui vous incombe, selon que vous utilisez IaaS, PaaS ou SaaS.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Ce guide couvre les fondamentaux du modèle de responsabilité partagée, de la théorie à la pratique. Vous comprendrez non seulement le principe, mais saurez l’appliquer concrètement selon votre type de déploiement.
| Compétence | Ce que vous saurez faire |
|---|---|
| Comprendre le modèle | Expliquer qui sécurise quoi dans le cloud |
| Identifier vos responsabilités | Savoir ce qui vous incombe selon IaaS/PaaS/SaaS |
| Éviter les pièges | Reconnaître les erreurs de configuration classiques |
| Dialoguer avec le fournisseur | Poser les bonnes questions sur la sécurité |
L’analogie : la location d’appartement
Section intitulée « L’analogie : la location d’appartement »Pour comprendre la responsabilité partagée, imaginez que vous louez un appartement :
Ce que le propriétaire gère
Section intitulée « Ce que le propriétaire gère »- La structure du bâtiment (murs, toit, fondations)
- Les parties communes (hall, escaliers, ascenseur)
- La sécurité de l’immeuble (porte d’entrée, interphone)
- Les réseaux (électricité, eau, gaz jusqu’au compteur)
Ce que vous gérez
Section intitulée « Ce que vous gérez »- La serrure de votre porte (et à qui vous donnez les clés)
- Le contenu de l’appartement (vos meubles, vos affaires)
- Vos installations intérieures (vous branchez un appareil défectueux, c’est votre problème)
- Vos visiteurs (vous laissez entrer un cambrioleur, c’est votre responsabilité)
Le cloud fonctionne exactement pareil : le fournisseur sécurise “l’immeuble” (l’infrastructure), vous sécurisez “votre appartement” (vos données et configurations).
Le modèle de responsabilité partagée
Section intitulée « Le modèle de responsabilité partagée »Le modèle de responsabilité partagée définit une frontière claire entre ce que le fournisseur cloud sécurise et ce qui reste sous votre contrôle. Cette frontière se déplace selon le niveau d’abstraction du service utilisé. Voici comment cela fonctionne visuellement :
Le schéma montre clairement comment la responsabilité migre progressivement vers le fournisseur au fur et à mesure qu’on monte en abstraction. En On-Premise, tout vous incombe. En IaaS, le fournisseur prend en charge l’infrastructure physique. En PaaS, il gère aussi le système et le runtime. En SaaS, il ne vous reste que la configuration et les accès.
Principe fondamental
Section intitulée « Principe fondamental »Le fournisseur cloud est responsable de la sécurité DU cloud (of the cloud). Vous êtes responsable de la sécurité DANS le cloud (in the cloud).
Cette distinction est cruciale :
| Responsabilité | Ce que ça couvre | Qui |
|---|---|---|
| Sécurité DU cloud | Infrastructure physique, hyperviseurs, réseau backbone | Fournisseur |
| Sécurité DANS le cloud | Données, configurations, accès, applications | Vous |
Ce que le fournisseur sécurise (toujours)
Section intitulée « Ce que le fournisseur sécurise (toujours) »Quel que soit le modèle (IaaS, PaaS, SaaS), le fournisseur gère :
Infrastructure physique :
- Datacenters (accès physique, vidéosurveillance, gardes)
- Alimentation électrique et refroidissement
- Protection contre les catastrophes (incendie, inondation)
Infrastructure réseau :
- Réseau backbone entre datacenters
- Protection DDoS au niveau infrastructure
- Isolation réseau entre clients (niveau hyperviseur)
Conformité de base :
- Certifications (ISO 27001, SOC 2, etc.)
- Audits réguliers de l’infrastructure
- Conformité réglementaire de leur périmètre
Ce qui vous incombe (toujours)
Section intitulée « Ce qui vous incombe (toujours) »Quel que soit le modèle, vous êtes responsable de :
Vos données :
- Classification (sensible, confidentiel, public)
- Chiffrement (au repos et en transit)
- Sauvegarde et rétention
- Suppression sécurisée
Vos accès :
- Gestion des identités (qui a accès)
- Permissions (à quoi ils ont accès)
- Authentification (MFA, SSO)
- Revue régulière des accès
Vos configurations :
- Paramètres de sécurité des services
- Règles firewall et groupes de sécurité
- Logs et monitoring
- Conformité de votre périmètre
Responsabilités par modèle de service
Section intitulée « Responsabilités par modèle de service »La frontière de responsabilité varie selon le modèle (IaaS, PaaS, SaaS). Plus vous montez dans la pile, plus le fournisseur prend en charge.
IaaS : vous gérez presque tout
Section intitulée « IaaS : vous gérez presque tout »En IaaS (EC2, Azure VMs, Compute Engine), le fournisseur gère uniquement l’infrastructure de base.
Ce que le fournisseur sécurise :
- Hyperviseur et isolation des VMs
- Réseau physique et virtuel de base
- Stockage physique
Ce que vous sécurisez :
- Système d’exploitation (patches, hardening)
- Configuration réseau (security groups, firewall)
- Middlewares et runtime
- Applications
- Données
| Couche | Responsable | Actions requises |
|---|---|---|
| Application | Vous | Tests de sécurité, WAF |
| Données | Vous | Chiffrement, backup |
| Runtime | Vous | Mise à jour, configuration |
| Middleware | Vous | Patches, hardening |
| OS | Vous | Patches mensuels, CIS benchmarks |
| Virtualisation | Fournisseur | - |
| Serveurs | Fournisseur | - |
| Stockage | Fournisseur | - |
| Réseau | Fournisseur | - |
PaaS : responsabilité réduite
Section intitulée « PaaS : responsabilité réduite »En PaaS (App Service, Cloud Run, Elastic Beanstalk), le fournisseur gère la plateforme.
Ce que le fournisseur sécurise :
- Tout ce qu’il gère en IaaS, plus :
- Système d’exploitation
- Runtime (Java, Python, Node.js…)
- Scaling et haute disponibilité
Ce que vous sécurisez :
- Votre code applicatif
- Configuration de l’application
- Données
- Authentification/autorisation applicative
| Couche | Responsable | Actions requises |
|---|---|---|
| Application | Vous | SAST, DAST, code review |
| Données | Vous | Chiffrement, backup |
| Runtime | Fournisseur | - |
| Middleware | Fournisseur | - |
| OS | Fournisseur | - |
| Virtualisation | Fournisseur | - |
Avantage sécurité : moins de surface à gérer, le fournisseur patche l’OS et le runtime.
Attention : vous restez responsable des vulnérabilités dans votre code et vos dépendances.
SaaS : responsabilité minimale (mais pas nulle)
Section intitulée « SaaS : responsabilité minimale (mais pas nulle) »En SaaS (Gmail, Salesforce, Datadog), le fournisseur gère l’application.
Ce que le fournisseur sécurise :
- Toute la pile technique
- Application et ses mises à jour
- Infrastructure de l’application
Ce que vous sécurisez :
- Configuration du service (paramètres de sécurité)
- Gestion des accès utilisateurs
- Vos données dans l’application
- Intégrations avec d’autres systèmes
| Couche | Responsable | Actions requises |
|---|---|---|
| Application | Fournisseur | - |
| Configuration | Vous | Paramètres sécurité |
| Accès | Vous | SSO, MFA, revue |
| Données | Partagé | Export, classification |
Tableau récapitulatif complet
Section intitulée « Tableau récapitulatif complet »Ce tableau synthétise les responsabilités selon le modèle de service. Utilisez-le comme référence rapide pour déterminer qui gère quoi dans votre contexte spécifique. Notez que “Partagé” signifie que les responsabilités varient selon les configurations et le contrat avec le fournisseur.
| Responsabilité | IaaS | PaaS | SaaS |
|---|---|---|---|
| Données | Vous | Vous | Partagé |
| Applications | Vous | Vous | Fournisseur |
| Runtime | Vous | Fournisseur | Fournisseur |
| Middleware | Vous | Fournisseur | Fournisseur |
| OS | Vous | Fournisseur | Fournisseur |
| Virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Serveurs | Fournisseur | Fournisseur | Fournisseur |
| Stockage | Fournisseur | Fournisseur | Fournisseur |
| Réseau | Fournisseur | Fournisseur | Fournisseur |
| Accès/IAM | Vous | Vous | Vous |
| Configuration | Vous | Vous | Vous |
Lecture : “Vous” = votre responsabilité. “Fournisseur” = sa responsabilité. “Partagé” = dépend du contexte.
Les erreurs les plus courantes
Section intitulée « Les erreurs les plus courantes »Erreur 1 : “Le cloud est sécurisé par défaut”
Section intitulée « Erreur 1 : “Le cloud est sécurisé par défaut” »Le mythe : “AWS/Azure/GCP sont certifiés, donc mes données sont en sécurité.”
La réalité : Le fournisseur sécurise son infrastructure. Vos configurations par défaut sont souvent permissives (bucket S3 public, ports ouverts, pas de chiffrement).
Exemple concret : En 2019, Capital One a subi une fuite de 100 millions de dossiers clients. AWS n’était pas en cause — c’était une mauvaise configuration du WAF côté client.
Solution : Activez les guardrails dès le départ (chiffrement par défaut, blocage de l’accès public, logs activés).
Erreur 2 : “Le fournisseur gère les backups”
Section intitulée « Erreur 2 : “Le fournisseur gère les backups” »Le mythe : “Mes données sont dans le cloud, elles sont sauvegardées.”
La réalité : Le fournisseur assure la durabilité du stockage (vos données ne disparaissent pas à cause d’un disque défaillant). Mais il ne fait pas de backup de vos données applicatives.
Exemple concret : Vous supprimez accidentellement une base de données RDS. Sans snapshot configuré par vous, les données sont perdues.
Solution : Configurez explicitement les backups (snapshots, réplication cross-région).
Erreur 3 : “Les logs sont automatiques”
Section intitulée « Erreur 3 : “Les logs sont automatiques” »Le mythe : “Le cloud trace tout, je pourrai investiguer si besoin.”
La réalité : Les logs d’audit (CloudTrail, Activity Log) sont souvent désactivés par défaut ou ont une rétention courte.
Solution : Activez les logs dès le premier jour, configurez une rétention adaptée, centralisez dans un SIEM.
Erreur 4 : “L’isolation entre clients est parfaite”
Section intitulée « Erreur 4 : “L’isolation entre clients est parfaite” »Le mythe : “Je suis dans mon propre environnement, personne ne peut accéder à mes données.”
La réalité : L’isolation est gérée par le fournisseur (et généralement excellente). Mais les erreurs de configuration peuvent exposer vos ressources à Internet ou à d’autres comptes.
Exemple concret : Un bucket S3 avec une policy trop permissive peut être accessible par n’importe qui.
Solution : Auditez régulièrement vos configurations (SCPs, policies, security groups).
Spécificités par fournisseur
Section intitulée « Spécificités par fournisseur »Documentation officielle : AWS Shared Responsibility Model
Outils pour vérifier vos responsabilités :
- AWS Config : Vérifie la conformité de vos configurations
- Security Hub : Vue centralisée de votre posture sécurité
- Trusted Advisor : Recommandations de sécurité
- IAM Access Analyzer : Détecte les accès trop permissifs
Points d’attention AWS :
- S3 : Bloquer l’accès public par défaut (account-level)
- IAM : Utiliser des rôles, pas des access keys
- VPC : Security groups en allowlist (pas de 0.0.0.0/0)
- CloudTrail : Activer dans toutes les régions
Documentation officielle : Azure Shared Responsibility
Outils pour vérifier vos responsabilités :
- Microsoft Defender for Cloud : Posture management
- Azure Policy : Conformité des ressources
- Azure Advisor : Recommandations sécurité
- Entra ID (ex-Azure AD) : Gestion des identités
Points d’attention Azure :
- Storage Account : Désactiver l’accès anonyme
- NSG : Règles explicites, pas de Any/Any
- Key Vault : Centraliser les secrets
- Activity Log : Exporter vers Log Analytics
Documentation officielle : Google Cloud Shared Responsibility
Outils pour vérifier vos responsabilités :
- Security Command Center : Vue centralisée
- Organization Policy : Contraintes au niveau org
- IAM Recommender : Optimisation des permissions
- Cloud Asset Inventory : Inventaire des ressources
Points d’attention GCP :
- GCS : Uniform bucket-level access
- IAM : Principe du moindre privilège
- VPC : Firewall rules en allowlist
- Cloud Audit Logs : Activer tous les types
Checklist de responsabilités
Section intitulée « Checklist de responsabilités »Les points essentiels à vérifier pour votre posture de sécurité cloud :
| Domaine | Points clés |
|---|---|
| Accès | MFA activé, pas de secrets dans le code, moindre privilège |
| Données | Chiffrement activé, backups configurés et testés |
| Configuration | Accès public bloqué, logs activés, Infrastructure as Code |
| Conformité | Contrat vérifié (DPA, localisation), plan d’incident |
À retenir
Section intitulée « À retenir »| Concept | Point clé |
|---|---|
| Responsabilité DU cloud | Le fournisseur sécurise l’infrastructure physique et virtuelle |
| Responsabilité DANS le cloud | Vous sécurisez vos données, configurations et accès |
| IaaS | Vous gérez presque tout (OS, middleware, apps, données) |
| PaaS | Vous gérez le code et les données |
| SaaS | Vous gérez les accès et la configuration |
| Erreur #1 | Croire que le cloud est sécurisé par défaut |
| Règle d’or | Vos données, vos accès, vos configurations = votre responsabilité |
Prochaines étapes
Section intitulée « Prochaines étapes »En cours d’écriture …