Responsabilités partagées : comprendre qui fait quoi en sécurité

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.

En résumé : La sécurité est une responsabilité partagée entre fournisseurs et clients. Chaque partie sécurise son périmètre. Les zones grises — où personne ne sait qui est responsable — sont la première cause d’incidents.

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é.

Exemples de raisonnements dangereux :

• “On est dans le cloud, c’est le fournisseur qui gère la sécurité”
• “On utilise un service managé, on n’a plus à s’en occuper”
• “Le prestataire est certifié ISO 27001, on est couverts”
• “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.

Erreur fréquente

Penser qu’une certification (ISO 27001, SOC 2) du fournisseur couvre automatiquement vos données. Ces certifications attestent des pratiques du fournisseur, pas de votre configuration ni de vos usages.

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

Imaginez un immeuble en location :

• Le propriétaire (fournisseur) est responsable de la structure : murs porteurs, toiture, parties communes, ascenseurs
• Le locataire (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

Responsabilité	Fournisseur	Client
Infrastructure physique	Datacenters, serveurs, réseau	—
Virtualisation	Hyperviseur, isolation	—
Système d’exploitation	Selon le service (IaaS: client / PaaS: partagé)	Configuration, durcissement
Applications	—	Code, dépendances, configuration
Données	—	Classification, chiffrement, accès
Identités	Service d’authentification	Gestion des comptes, MFA, mots de passe

Les niveaux de service et leurs frontières

Infrastructure as a Service (IaaS)

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.

Responsabilités client :

• 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 (PaaS)

Le fournisseur gère également le système d’exploitation et le runtime. Le client gère les applications et les données.

Responsabilités client :

• 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 (SaaS)

Le fournisseur gère presque tout. Le client gère les données, les accès et la configuration.

Responsabilités client :

• 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

Conteneurs et orchestration

Avec les conteneurs, les responsabilités se fragmentent davantage :

Couche	Responsable
Image de base	Éditeur de l’image (ex: distribution Linux)
Image applicative	Équipe de développement
Runtime conteneur	Équipe plateforme / ops
Orchestrateur	Équipe plateforme
Configuration du workload	É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

L’utilisation de composants open source crée une responsabilité implicite :

• 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

Externaliser une fonction ne supprime pas la responsabilité :

• 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énario 1 : 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

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).

Leçon : “être dans le cloud” ne signifie pas “être sécurisé”. La configuration reste de la responsabilité du client.

Scénario 2 : 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

Responsabilité : partagée. L’entreprise ne peut pas se défausser sur le prestataire, surtout si elle n’a pas vérifié ses pratiques.

Leçon : externaliser un service ne transfère pas la responsabilité légale et éthique envers les personnes concernées.

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

À retenir

1. La sécurité est toujours partagée — aucun fournisseur ne prend en charge 100% de la sécurité, il reste toujours une part client.

2. Utiliser un service externe ne transfère pas la responsabilité — le client reste responsable de ses données, de ses accès et de ses configurations.

3. Les frontières varient selon le niveau de service — IaaS laisse plus de responsabilités au client que PaaS, qui en laisse plus que SaaS.

4. Les zones grises créent des vulnérabilités — si personne ne sait qui est responsable d’un aspect, personne ne s’en occupe.

5. Documenter et tester les responsabilités — les hypothèses implicites sont la source des incidents les plus graves.

Liens utiles

• Menace, risque, vulnérabilité, attaque — Comprendre les concepts pour identifier les responsables
• Pourquoi la sécurité échoue — Les silos organisationnels qui brouillent les responsabilités
• Sécurité : une question de compromis — Arbitrer qui fait quoi selon les contraintes
• Vue d’ensemble de la sécurité — Point d’entrée vers les guides de sécurisation