Le modèle de responsabilité partagée

Quand un fichier est « dans le cloud », il se trouve sur un serveur appartenant à une entreprise que vous n’avez jamais rencontrée et ne visiterez jamais. Cet arrangement répartit la responsabilité de sécurité entre deux parties, et la plupart des gens n’apprennent jamais où se situe cette limite avant que quelque chose ne tourne mal. Chaque grand fournisseur cloud documente explicitement cette répartition, car se tromper dans un sens comme dans l’autre — supposer que le fournisseur couvre tout, ou essayer de sécuriser des éléments déjà pris en charge par le fournisseur — provoque de vrais incidents.

Deux côtés d’une même ligne

Amazon Web Services appelle sa version de cette répartition le modèle de responsabilité partagée, la divisant en « sécurité du cloud » et « sécurité dans le cloud ». AWS est responsable du premier : « le matériel, les logiciels, le réseau et les installations qui font fonctionner les services AWS Cloud » — les centres de données physiques, les correctifs de l’infrastructure, les éléments que vous ne pourriez jamais inspecter ni configurer vous-même même si vous le vouliez. Le client est responsable du second, et AWS précise ce que cela inclut pour les services de stockage cloud : « gérer ses données (y compris les options de chiffrement), classer ses actifs, et utiliser les outils IAM » — c’est-à-dire qui est autorisé à y accéder.

La répartition se déplace selon ce que vous utilisez

La documentation de Microsoft souligne un point important pour quiconque choisit entre différents types de services cloud : la ligne de partage n’est pas fixe, elle se déplace selon le modèle de service. Son tableau de responsabilités liste les données du client, les identités de compte et la gestion des accès comme étant toujours la tâche du client, dans chaque modèle, sur site ou dans le cloud. Mais à mesure que l’on passe de l’infrastructure en tant que service (louer une machine virtuelle que vous configurez vous-même) vers le logiciel en tant que service (utiliser une application toute prête comme un service de messagerie ou de partage de fichiers), Microsoft en prend davantage à sa charge : les systèmes d’exploitation, le code applicatif et la configuration réseau deviennent de plus en plus la tâche de Microsoft plutôt que la vôtre. Ce qui ne se déplace jamais, selon les propres mots de Microsoft, c’est que « vous conservez toujours » la responsabilité de vos données, de vos comptes, de vos appareils clients et de vos contrôles d’accès.

Pourquoi le côté client compte plus qu’il n’y paraît

Pour une ONG utilisant un service de partage de fichiers ou de messagerie tout prêt — le logiciel en tant que service, le modèle où le fournisseur gère le plus — il est tentant de supposer que la sécurité du fournisseur constitue désormais toute l’histoire. Ce n’est pas le cas. Le côté du fournisseur (ses serveurs, son réseau, ses correctifs) est généralement excellent pour les grands services ; c’est précisément pourquoi les attaquants s’en prennent rarement directement à lui. Ils ciblent plutôt le côté du client : un mot de passe faible ou réutilisé, un lien partagé plus largement que prévu, un compte sans second facteur. Chaque catégorie de la liste « toujours la tâche du client » ci-dessus fait aussi, non par hasard, l’objet de la leçon suivante de ce cours.

Une question à se poser pour tout service cloud que vous utilisez

Avant de confier du contenu sensible à un service cloud, il vaut la peine de trouver sa propre documentation sur la responsabilité partagée (tous les grands fournisseurs en publient une) et de se poser deux questions : que sécurise réellement le fournisseur par défaut, et qu’est-ce qui m’est explicitement laissé ? La réponse clarifie généralement précisément desquelles de vos propres habitudes — traitées dans le reste de ce cours — dépend réellement la sécurité de ces données.