Responsabilités partagées et implications contractuelles
Appliquer le modèle de responsabilité partagée pour clarifier les obligations contractuelles entre client et fournisseur cloud.
À retenir
- Le modèle de responsabilité partagée répartit la sécurité entre fournisseur (« du cloud ») et client (« dans le cloud »).
- La classification des données et la gestion des identités restent toujours du ressort du client.
- La majorité des incidents cloud proviennent de mauvaises configurations côté client, pas de failles du fournisseur.
- Un contrat cloud doit détailler la répartition des responsabilités poste par poste, au-delà d'une mention générique.
Le modèle de responsabilité partagée
Dans le cloud, la sécurité et la conformité ne reposent jamais entièrement sur une seule partie. Le modèle de responsabilité partagée répartit les obligations entre le fournisseur (« sécurité du cloud ») et le client (« sécurité dans le cloud »). Cette répartition varie selon le modèle de service choisi.
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Données et classification | Client | Client | Client |
| Gestion des identités et accès | Client | Client (partagé) | Client (partagé) |
| Applications | Client | Client | Fournisseur |
| Runtime / middleware | Client | Fournisseur | Fournisseur |
| Système d'exploitation | Client | Fournisseur | Fournisseur |
| Virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Infrastructure physique et réseau | Fournisseur | Fournisseur | Fournisseur |
Point clé
quel que soit le modèle de service, la classification des données et la gestion des accès (IAM) restent toujours de la responsabilité du client. Aucun fournisseur ne peut deviner quelles données sont sensibles chez vous.
Une source d'incidents fréquente : les buckets mal configurés
La majorité des fuites de données « cloud » médiatisées ces dernières années ne proviennent pas d'une faille du fournisseur, mais d'une mauvaise configuration côté client (bucket de stockage public, groupe de sécurité trop permissif, clé d'API exposée). C'est la conséquence directe d'une mauvaise compréhension du modèle de responsabilité partagée.
Attention
signer un contrat cloud ne transfère pas la responsabilité légale de la protection des données personnelles. Le client reste responsable du traitement (au sens RGPD ou des lois nationales équivalentes), même si le traitement technique est sous-traité à un fournisseur cloud.
Traduire le modèle en clauses contractuelles
Un contrat cloud sérieux doit préciser, poste par poste, qui fait quoi :
- Qui applique les correctifs de sécurité du système d'exploitation (en IaaS) ?
- Qui gère la rotation des clés de chiffrement ?
- Qui est notifié en cas d'incident de sécurité, et sous quel délai (souvent 72h pour les obligations réglementaires) ?
- Qui garantit la localisation géographique des données (souveraineté) ?
# Exemple : vérifier l'exposition d'un bucket S3-compatible
aws s3api get-bucket-policy-status --bucket mon-bucket
aws s3api get-public-access-block --bucket mon-bucket
Ces commandes illustrent une vérification côté client : le fournisseur propose l'outillage, mais c'est au client de vérifier et de corriger sa configuration.
Le rôle de la Cloud Security Alliance
Le référentiel CSA Cloud Controls Matrix (CCM) formalise ce partage de responsabilité domaine par domaine (gouvernance, gestion des identités, chiffrement, continuité d'activité) et sert de base à de nombreux audits de fournisseurs cloud.
Sur le terrain
lors d'un appel d'offres pour un opérateur télécom régional, exigez systématiquement une matrice de responsabilité annexée au contrat, poste par poste, plutôt qu'une simple mention générique « la sécurité est une responsabilité partagée ». Cette matrice évite les zones grises lors d'un incident.
Astuce
faites relire la matrice de responsabilité par l'équipe technique ET par l'équipe juridique ensemble ; les deux lisent souvent le même paragraphe avec des attentes différentes, notamment sur la notion de « disponibilité garantie ».