Cloud : le modèle de responsabilité partagée que presque personne ne lit

« C’est dans le cloud, donc c’est sécurisé. » Cette phrase, entendue en réunion de direction, résume le malentendu le plus coûteux du sujet.

Le fournisseur sécurise son périmètre. Le vôtre reste le vôtre. Et la frontière entre les deux se déplace selon le type de service.

Le principe

Tous les grands fournisseurs publient un modèle de responsabilité partagée. Les formulations diffèrent, la logique est identique : la responsabilité de l’infrastructure appartient au fournisseur, la responsabilité dans l’infrastructure vous appartient.

Ce qui varie, c’est où passe la ligne.

En infrastructure à la demande (IaaS)

Le fournisseur répond du matériel, de la virtualisation, des centres de données, du réseau physique.

Vous répondez du système d’exploitation, des correctifs, de la configuration, du réseau virtuel, des pare-feux applicatifs, des identités, du chiffrement et des sauvegardes. C’est-à-dire de l’essentiel.

En plateforme à la demande (PaaS)

Le fournisseur reprend le système d’exploitation et l’exécution. Vous gardez l’application, les données, les identités et les configurations d’accès.

En logiciel à la demande (SaaS)

Le fournisseur gère presque tout. Il vous reste trois choses, qui sont précisément celles qui posent problème : vos données, vos identités et habilitations, et vos paramètres de partage.

La plupart des fuites de données en SaaS ne viennent pas d’une faille du fournisseur. Elles viennent d’un partage public laissé ouvert et d’un droit d’accès mal attribué.

Les quatre zones grises qui produisent les incidents

1. Les configurations par défaut

Un espace de stockage créé en trois clics est fonctionnel immédiatement. Sécurisé, c’est autre chose. Les paramètres par défaut privilégient la mise en service, pas la restriction.

La règle : tout service nouvellement créé doit passer une revue de configuration avant d’accueillir des données réelles. Sans ce point de contrôle, la dérive est mécanique.

2. Les sauvegardes

C’est le malentendu le plus fréquent en SaaS. La réplication assurée par le fournisseur protège contre la panne matérielle, pas contre la suppression par un utilisateur, un chiffrement par rançongiciel, ou une erreur de synchronisation.

Beaucoup de contrats prévoient une corbeille de trente jours et rien au-delà. Si votre besoin de rétention est supérieur, c’est à vous de l’organiser. Rappelons que le RGPD impose la capacité de rétablir la disponibilité des données.

3. La journalisation

Les journaux détaillés sont souvent une option payante, avec une rétention par défaut courte. Le jour de l’incident, vous découvrez que les traces des trois semaines précédentes n’ont jamais été conservées.

À vérifier avant la mise en production : quels journaux sont disponibles, sur quelle durée, exportables vers votre propre système de collecte ou non.

4. Les identités

Le cloisonnement entre l’annuaire d’entreprise et les rôles du fournisseur est rarement pensé. Résultat courant : des comptes disposant de privilèges d’administration sur l’environnement entier, sans authentification renforcée et sans revue. Voir les erreurs récurrentes sur les comptes à privilèges.

Ce que la réglementation en dit

ISO/IEC 27002:2022 a introduit une mesure dédiée, 5.23 — sécurité de l’information dans l’utilisation de services en nuage — qui impose de définir les exigences, les responsabilités et les modalités de sortie.

ISO/IEC 27017 fournit des lignes directrices spécifiques au cloud, avec une répartition explicite entre client et fournisseur.

En France, le référentiel SecNumCloud de l’ANSSI qualifie des offres selon des exigences de sécurité et de protection contre les législations extraterritoriales. Pour certains traitements sensibles, c’est un critère de sélection déterminant.

Côté DORA, les fournisseurs cloud entrent pleinement dans le périmètre des prestataires tiers de services TIC, avec obligation d’inscription au registre d’information.

Les questions à poser avant de signer

1. Où sont hébergées et traitées les données, et sous quelle juridiction ?
2. Quelle est la politique de sauvegarde du fournisseur, et que couvre-t-elle exactement ?
3. Quels journaux sont accessibles, sur quelle durée, exportables comment ?
4. Quelles sont les modalités de réversibilité : formats, délais, coût d’extraction ?
5. Qui détient les clés de chiffrement, et pouvez-vous les gérer vous-même ?
6. Quelles notifications d’incident sont contractuellement prévues, dans quel délai ?

Ces six questions relèvent de la même logique que la maîtrise de la chaîne d’approvisionnement : un fournisseur cloud est un prestataire tiers comme un autre, avec un niveau de dépendance simplement plus élevé.

Sources

• ISO/IEC 27002:2022, mesure 5.23 — sécurité dans l’utilisation de services en nuage
• ISO/IEC 27017 — lignes directrices pour la sécurité des services en nuage
• ANSSI — référentiel SecNumCloud
• Cloud Security Alliance — matrices de contrôles

Aller plus loin

Nous auditons les configurations cloud dans le cadre de l’audit 360, et l’encadrement contractuel relève de la gouvernance, risques et conformité. La formation Lead Cloud Security Manager traite ces sujets en profondeur.