Modèle de responsabilité partagée : IaaS, PaaS et SaaS

Les services Cloud sont fournis selon trois modèles principaux, chacun offrant un niveau d’abstraction différent. Infrastructure as a Service (IaaS) fournit des ressources brutes de calcul, de stockage et de réseau. Platform as a Service (PaaS) ajoute l’OS, les intergiciels et les environnements d’exécution. Software as a Service (SaaS) fournit des applications pleinement fonctionnelles sur Internet. Il est essentiel de comprendre ces modèles, car les responsabilités en matière de sécurité diffèrent considérablement entre eux.

Le modèle de responsabilité partagée définit les tâches de sécurité qui incombent au fournisseur Cloud et celles qui relèvent du client. Ce modèle est souvent résumé ainsi : le fournisseur est responsable de la sécurité du Cloud (centres de données physiques, hyperviseurs, infrastructure réseau), tandis que le client est responsable de la sécurité dans le Cloud (données, gestion des accès, sécurité des applications et configuration). Une mauvaise compréhension de cette limite est l’une des principales causes des incidents de sécurité dans le Cloud.

Avec IaaS, le client assume la plus grande part des responsabilités de sécurité. Le fournisseur Cloud sécurise l’infrastructure physique, l’hyperviseur et l’architecture réseau. Le client est responsable de : l’installation, de l’application des correctifs et du renforcement de l’OS ; de la configuration de l’environnement d’exécution et des intergiciels ; de la sécurité des applications ; des règles des groupes de sécurité réseau ; des règles IAM et de la gestion des utilisateurs ; du chiffrement des données au repos et en transit ; ainsi que de la configuration de conformité. IaaS offre un contrôle maximal, mais exige aussi un effort de sécurité maximal.

Avec PaaS, le fournisseur prend en charge la gestion de l’OS et de l’environnement d’exécution. Le client n’applique plus les correctifs du système d’exploitation et ne gère plus les intergiciels : le fournisseur s’en charge. Cependant, le client reste responsable de : la sécurité du code des applications (absence de SQLi, XSS, etc.), la classification et le chiffrement des données, la gestion des identités et des accès, la configuration des applications (variables d’environnement, gestion des secrets) et la sécurité des API. PaaS transfère une partie de la charge au fournisseur, tandis que les clients se concentrent sur la logique applicative.

Avec SaaS, le fournisseur gère presque tout. Les principales responsabilités du client en matière de sécurité sont : la gestion des accès (déterminer qui possède des comptes, imposer MFA et examiner les autorisations), la gouvernance des données (déterminer quelles données sont téléversées et combien de temps elles sont conservées), la sécurité de la configuration (paramètres de confidentialité, autorisations de partage, intégrations tierces) et la conformité aux règles d’utilisation acceptable. De nombreuses compromissions de SaaS proviennent de paramètres de partage mal configurés ou d’autorisations excessives accordées à des applications tierces, plutôt que de défaillances du fournisseur.

Certains contrôles sont partagés entre le fournisseur et le client. Prenons le chiffrement : le fournisseur cloud peut proposer des services de chiffrement (KMS, chiffrement par défaut), mais le client doit les activer, configurer la gestion des clés et choisir des algorithmes appropriés. De même pour l’identité : le fournisseur fournit des outils IAM, mais le client doit configurer des policies selon le principe du moindre privilège et imposer la MFA. Supposer que le fournisseur gère un contrôle partagé et ne pas le configurer est une erreur courante et dangereuse.

Le modèle de responsabilité partagée échoue le plus souvent à cause d’une mauvaise configuration du client, et non d’une défaillance du fournisseur. Exemples classiques : des buckets S3 laissés accessibles au public (fuite de Capital One en 2019, 100 millions d’enregistrements exposés), des rôles IAM trop permissifs permettant une élévation de privilèges, des groupes de sécurité contenant des règles entrantes 0.0.0.0/0 sur des ports sensibles, et des identifiants par défaut restés inchangés sur des bases de données déployées dans le cloud. L’infrastructure sous-jacente du fournisseur était sécurisée ; la configuration du client ne l’était pas.

La visibilité constitue un défi majeur du modèle partagé. Dans les environnements sur site, les équipes de sécurité contrôlent tout le logging. Dans le cloud, les journaux de l’infrastructure du fournisseur peuvent ne pas être accessibles. Les clients doivent activer les services de logging natifs du cloud : AWS CloudTrail, Azure Monitor et GCP Cloud Audit Logs enregistrent les appels d’API et les modifications de configuration. Sans activer ces services, une organisation ne dispose d’aucune piste d’audit indiquant qui a fait quoi dans son environnement cloud — ce qui représente une importante lacune en matière de conformité et d’investigation forensique.

Lorsque les organisations font appel à des fournisseurs de services managés pour exploiter leurs environnements cloud, la responsabilité se répartit entre trois parties. Le client doit s’assurer que les contrats (SLA et accords de traitement des données) définissent clairement les obligations de sécurité. Les applications cloud de tiers accessibles par l’intermédiaire du SaaS ajoutent une complexité supplémentaire : un consentement OAuth accordé à une application trop permissive donne à celle-ci accès à vos données. L’examen et l’audit régulier des consentements OAuth accordés à des tiers font partie des bonnes pratiques d’hygiène de sécurité du SaaS.

Les exigences de conformité ne disparaissent pas parce que les charges de travail ont été déplacées vers le cloud. HIPAA exige un accord de partenaire commercial (BAA) avec les fournisseurs cloud qui traitent des PHI — AWS, Azure et GCP proposent tous des BAA. PCI-DSS exige que l’environnement cloud soit inclus dans le périmètre d’évaluation ; les matrices de responsabilité partagée des fournisseurs indiquent quels contrôles PCI sont satisfaits. Les organisations doivent comprendre ce que couvre leur fournisseur et ce qu’elles doivent mettre en œuvre elles-mêmes pour réussir les audits.

Le modèle de responsabilité partagée a une portée juridique. Les conditions générales d’utilisation du fournisseur cloud et les accords de niveau de service (SLA) précisent les garanties de disponibilité et les exclusions. Les accords de traitement des données (DPA) prévus par le GDPR définissent les obligations du sous-traitant. Si une violation se produit en raison d’une défaillance du fournisseur, le client peut demander réparation au titre du SLA. Si la violation est due à une mauvaise configuration du client, le fournisseur n’est pas responsable. Comprendre les contrats est aussi important que comprendre les contrôles techniques.

Dans cette leçon, vous avez appris que : le modèle de responsabilité partagée définit les obligations de sécurité du fournisseur et du client dans les environnements IaaS, PaaS et SaaS, que les clients assument la plus grande part de la responsabilité de sécurité dans l’IaaS et la plus faible dans le SaaS, tout en restant toujours responsables de la gestion des accès et de la gouvernance des données, et que la mauvaise configuration du client — et non une défaillance du fournisseur — est la principale cause des violations de données dans le cloud. Nous allons maintenant étudier la sécurité du stockage cloud et les risques d’exposition des données.