Le modèle de responsabilité partagée

Qui a laissé le bucket ouvert

Une équipe crée un bucket de stockage pour recevoir les fichiers envoyés par les utilisateurs de son application. Pour aller vite pendant les tests, elle active l'accès public, en se disant qu'elle le refermera avant le lancement. Elle oublie. Six mois plus tard, un chercheur en sécurité tombe sur ce bucket entier, accessible en un clic depuis un moteur de recherche, chaque fichier envoyé lisible par n'importe qui possède le lien. Qui a échoué : le fournisseur cloud, ou l'équipe ?

L'équipe. Pas parce qu'elle a mal tapé une commande, mais parce qu'elle a traité comme acquise une décision qui lui appartenait entièrement. Cet écart entre ce que le fournisseur sécurise et ce que le client configure est exactement ce que le modèle de responsabilité partagée existe pour clarifier.

La sécurité du cloud, la sécurité dans le cloud

AWS nomme sa part du partage « la sécurité du cloud » : les centres de données physiques, les baies qu'ils contiennent, l'hyperviseur qui découpe un serveur physique en plusieurs machines virtuelles, et le réseau mondial qui relie les régions AWS entre elles. Vous ne voyez rien de tout cela, et vous ne corrigez rien de tout cela. Azure et Google Cloud décrivent le même partage pour leurs propres plateformes, avec d'autres mots, mais la même forme.

Votre part s'appelle « la sécurité dans le cloud » : tout ce que vous construisez, configurez et stockez avec les services que le fournisseur met à votre disposition. Cela inclut toujours vos données et vos politiques d'accès. Selon le service choisi, cela peut aussi inclure votre système d'exploitation invité et le code de votre application.

La frontière se déplace selon le modèle de service

Ce partage n'est pas fixe. Il glisse le long de la pile technique selon la quantité de travail que vous confiez au fournisseur.

Lisez ce tableau de haut en bas plutôt que colonne par colonne : les deux premières lignes ne passent presque jamais au fournisseur, et les deux dernières ne passent presque jamais au client. Les lignes du milieu sont là où se jouent les vraies décisions, et où se produisent la plupart des questions d'examen et des erreurs de configuration réelles.

Exemple concret : la même fonctionnalité, deux modèles de service

Une équipe fait tourner une API sur une machine virtuelle Ubuntu. AWS gère le serveur physique, l'hyperviseur, et le réseau entre les zones de disponibilité. L'équipe gère, elle, l'installation des correctifs d'Ubuntu quand une faille du kernel est publiée, la configuration du security group pour que seul le port 443 soit accessible, et la rotation de la clé SSH utilisée pour se connecter. C'est de l'IaaS : la part du client y est lourde.

La même équipe reconstruit ensuite sa fonctionnalité d'envoi d'images sous forme d'un bucket S3 et d'une fonction Lambda qui redimensionne les fichiers à leur arrivée. AWS gère maintenant entièrement le système d'exploitation et le runtime dans lequel Lambda s'exécute : il n'y a plus aucun serveur à corriger. Ce qui reste à l'équipe : la politique d'accès du bucket S3, ce que le rôle IAM assumé par la fonction a le droit de toucher, et si les fichiers stockés sont chiffrés. Passer de l'IaaS à un service serverless de type PaaS a retiré une ligne entière du côté du client. Cela n'a pas retiré la première ligne du tableau.

Ce qui ne traverse jamais la frontière

Quel que soit le modèle, IaaS, PaaS ou SaaS, deux choses restent toujours du côté du client : les données elles-mêmes, y compris leur classification et leurs choix de chiffrement, et la gestion des identités et des accès, c'est-à-dire qui peut se connecter et ce qu'il a le droit de faire une fois connecté. Un fournisseur peut chiffrer un disque par défaut, mais seul le client décide quels fichiers méritent une restriction supplémentaire, et seul le client décide qui, dans son équipe, y a accès. Les deux prochaines leçons de ce sujet couvrent exactement ces deux lignes en détail : d'abord l'identité, puis le chiffrement.

Idée reçue : un certificat que vous n'avez pas gagné

Il est tentant de penser que, votre fournisseur cloud étant certifié SOC 2 ou ISO 27001, votre propre application hérite de cette certification. Ce n'est pas le cas. Le certificat du fournisseur couvre l'infrastructure qu'il exploite : les centres de données, l'hyperviseur, l'intérieur de ses services gérés. Que les contrôles d'accès, les paramètres de chiffrement et les pratiques de traitement des données de votre application respectent tel ou tel cadre, c'est un audit distinct, et vous seul pouvez en produire les preuves. La dernière leçon de ce sujet revient exactement sur cet écart et détaille comment les équipes le comblent.

Repères d'examen : lire un scénario de responsabilité partagée

Le piège à repérer : un énoncé qui mentionne un service géré ou serverless et vous pousse à croire que le fournisseur possède désormais tout. Il en possède plus qu'en IaaS, mais les données et l'identité ne changent jamais de camp.

Où cela vous mène

À mesure que vous montez de l'IaaS vers le SaaS, la part du fournisseur grandit et celle du client rétrécit, mais les deux premières lignes du tableau, les données et l'identité, ne traversent jamais la frontière dans un sens ni dans l'autre. Savoir lire un scénario et le placer correctement sur ce tableau est la compétence la plus testée en sécurité cloud. La prochaine leçon ouvre pleinement le volet identité : comment le cloud vérifie réellement qui vous êtes et décide ce que vous avez le droit de faire une fois qu'il le sait.