Sécurité dans le nuage : le modèle de responsabilité partagée expliqué
Le fournisseur sécurise le nuage, vous sécurisez ce que vous y mettez. Où passe la frontière selon le type de service, et comment s'en assurer avant la mise en production.
Un classique des incidents : un stockage de fichiers laissé en accès public, des données exposées, et une phrase qui revient dans la réunion de crise : « Mais c’est le fournisseur qui gère la sécurité ». Il en gère une partie. L’autre partie, souvent la plus exposée, reste à vous. C’est tout l’objet de la sécurité du cloud et de son principe fondateur, la responsabilité partagée.
Le principe en une phrase
Le fournisseur est responsable de la sécurité du nuage : bâtiments, serveurs, réseau, couche de virtualisation. Le client est responsable de la sécurité dans le nuage : ses données, ses accès, sa configuration. Les grands fournisseurs publient tous un schéma de ce partage ; leur formulation diffère, le principe est le même.
Le fournisseur garantit le terrain. Ce que vous construisez dessus, et qui en a les clés, reste de votre ressort.
La frontière se déplace selon le modèle de service
Plus le service est « géré », plus le fournisseur en porte. Mais deux responsabilités ne se délèguent jamais : les données et la gestion des identités et des accès.
| Élément | Infrastructure (IaaS) | Plateforme (PaaS) | Logiciel (SaaS) |
|---|---|---|---|
| Bâtiments, matériel, réseau physique | Fournisseur | Fournisseur | Fournisseur |
| Virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Système d’exploitation et correctifs | Client | Fournisseur | Fournisseur |
| Applications et code | Client | Client | Fournisseur |
| Configuration du service | Client | Client | Client |
| Identités, droits, authentification forte | Client | Client | Client |
| Données, classification, chiffrement des clés | Client | Client | Client |
Ce tableau est un modèle simplifié ; le contrat et la documentation du fournisseur font foi. Retenez surtout les trois dernières lignes : quel que soit le service, elles vous reviennent.
Les erreurs qui reviennent
- Supposer que « dans le nuage » veut dire « sauvegardé » : la sauvegarde et la restauration sont à définir et à tester par le client, sauf engagement explicite du contrat.
- Laisser des droits d’administration trop larges, sans authentification forte, sur les comptes de gestion.
- Oublier la configuration par défaut : un stockage, une base de données ou un journal peuvent être ouverts plus largement que prévu.
- Ne pas relire les journaux : les traces existent, mais personne n’est chargé de les exploiter.
- Ignorer la localisation et la juridiction des données, qui relèvent aussi du partage de responsabilité, au sens juridique.
Comment s’en assurer, pas à pas
- Cartographier. Pour chaque service utilisé, noter le modèle (IaaS, PaaS, SaaS) et dessiner la frontière avec la documentation du fournisseur.
- Désigner un responsable pour chaque ligne côté client. Une responsabilité sans nom reste une responsabilité oubliée.
- Exiger les preuves. Demander les rapports d’audit et les certifications qui couvrent la part du fournisseur : la norme ISO/IEC 27001, son extension ISO/IEC 27017 pour le nuage, ou, pour les besoins de confiance les plus élevés en France, la qualification SecNumCloud de l’ANSSI.
- Verrouiller les accès. Authentification forte, moindre privilège, comptes d’administration séparés, revue périodique des droits.
- Contrôler la configuration en continu. Des outils de contrôle de posture signalent les écarts (stockage public, port ouvert, chiffrement absent) avant qu’un tiers ne les trouve.
- Prévoir la sortie. Format des données, délai de restitution, suppression vérifiée : à écrire au contrat, pas à découvrir en fin de relation.
Les certifications du fournisseur prouvent la solidité de son périmètre, pas celle de votre configuration. Un nuage parfaitement sécurisé peut héberger une application mal configurée.
Ce que cela change pour les décideurs
Pour un décideur, trois questions suffisent à ouvrir la discussion : qui détient les clés de chiffrement, qui peut accéder aux données en cas de réquisition étrangère, et qui est responsable en cas d’incident sur chaque couche. Elles relèvent de la gouvernance autant que de la technique, et se posent avant la signature, pas après. Pour structurer cette démarche, consultez notre approche de cybersécurité et conformité ou demandez un diagnostic de votre exposition.
Pour approfondir : Gouvernance & traçabilité
Questions fréquentes
La responsabilité partagée est-elle une obligation juridique ?
C'est d'abord un principe contractuel et opérationnel, publié par les fournisseurs. Le règlement général sur la protection des données répartit en outre les rôles entre responsable de traitement et sous-traitant, ce qui précise qui répond de quoi pour les données personnelles.
Le SaaS dispense-t-il de s'occuper de sécurité ?
Non. Même en SaaS, le client gère ses comptes, ses droits, ses paramètres de partage et ses données. Une erreur de configuration suffit à exposer des informations.
Qu'est-ce que SecNumCloud ?
Un référentiel de l'ANSSI, l'agence française de cybersécurité, qui qualifie des offres de nuage selon des exigences de sécurité et de protection contre les lois extra-européennes. Il vise les données les plus sensibles.
Qui doit tester la restauration des sauvegardes ?
Le client, sauf si le contrat prévoit explicitement un service de restauration testée. Un test régulier est la seule preuve qu'une sauvegarde est utilisable.