Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- La sécurité dans le cloud désigne l'ensemble des mesures de contrôle, des politiques et des outils qui protègent les données, les applications et l'infrastructure dans le cloud.
- La responsabilité partagée répartit les tâches de sécurité entre vous et le fournisseur, et cette répartition varie en fonction du modèle de service.
- Dans le cadre de l'IaaS, le système d'exploitation invité et ses mises à jour vous appartiennent, et non au fournisseur.
Les fournisseurs de services cloud exploitent les centres de données, le matériel et la couche de virtualisation sur laquelle reposent vos charges de travail. Au-delà de cela, tout dépend du modèle de service. En IaaS, le système d’exploitation invité, les comptes utilisateurs et les données stockées relèvent tous de votre responsabilité, et cette limite évolue à mesure que vous vous orientez vers des plateformes gérées et le SaaS.
C'est au niveau de cette frontière mouvante que les failles de sécurité ont tendance à apparaître. On pourrait facilement supposer que le fournisseur se charge de tâche de mise à jour ou de configuration qui vous incombe en réalité.
Qu'est-ce que la sécurité dans le cloud ?
La sécurité du cloud désigne l'ensemble des mesures de contrôle, des politiques et des outils qui protègent les données, les applications et l'infrastructure fonctionnant dans environnements cloud. Elle couvre les couches d’identité, de réseau, de charges de travail et de données, et s’applique que vous utilisiez des machines virtuelles, des plateformes gérées ou des logiciels fournis par un éditeur.
On voit parfois l'expression « sécurité dans le cloud » utilisée pour désigner des outils de sécurité qui sont eux-mêmes fournis depuis le cloud. Ici, ce terme recouvre la mission plus large consistant à protéger ce qui s'exécute dans le cloud, jusqu'aux serveurs Linux qui prennent en charge une grande partie de ces charges de travail.
C'est important car un simple paramètre mal configuré, un compte doté de droits trop étendus ou un serveur non mis à jour peut exposer des données ou entraîner la mise hors service d'un service. Certains de ces risques persistent quel que soit le modèle de service que vous choisissez, comme le montre le tableau ci-dessous.
Qu'est-ce que le modèle de responsabilité partagée en matière de sécurité dans le cloud ?
Le modèle de responsabilité partagée précise quelles tâches de sécurité incombent au fournisseur de services cloud et lesquelles vous incombent. On croit souvent à tort que le fournisseur assure la sécurité de tout ce qu’il héberge. Dans la pratique, la frontière varie en fonction du modèle de service et peut changer d’un service à l’autre.
AWS, Microsoft et Google présentent chacun cette notion sous un angle légèrement différent. Microsoft publie une matrice classée par modèle de service. AWS distingue la sécurité « du » cloud, c’est-à-dire l’infrastructure du fournisseur, de la sécurité « dans » le cloud, c’est-à-dire tout ce que vous y hébergez. Google va encore plus loin avec ce qu’il appelle le « destin partagé », dans le cadre duquel le fournisseur joue un rôle plus actif pour aider ses clients à mettre en place une configuration sécurisée. Microsoft décrit lui-même sa matrice comme un guide à titre indicatif qui ne modifie pas les termes de votre contrat ; considérez donc chacun de ces modèles comme une référence et consultez votre contrat ainsi que la documentation relative au service spécifique que vous utilisez.
Comment la responsabilité évolue entre les modèles IaaS, PaaS et SaaS
Les services cloud se répartissent en trois modèles : l'infrastructure en tant que service (IaaS), la plateforme en tant que service (PaaS) et le logiciel en tant que service (SaaS). Plus le fournisseur gère une partie importante de la pile, moins vous avez à vous en occuper directement, même si certaines responsabilités vous incombent dans les trois cas. La matrice actuelle de Microsoft, adaptée ci-dessous, illustre la répartition des tâches.
| Domaine de responsabilité | IaaS | PaaS | SaaS |
| Données clients | Toi | Toi | Toi |
| Configurations et paramètres | Toi | Toi | Toi |
| Identités et utilisateurs | Toi | Toi | Toi |
| Appareils clients | Toi | Toi | Partagé |
| Applications | Toi | Partagé | Partagé |
| Contrôles réseau | Toi | Partagé | Prestataire |
| Système d'exploitation | Toi | Prestataire | Prestataire |
| Hôtes physiques, réseau et centre de données | Prestataire | Prestataire | Prestataire |
Source : Microsoft Learn, «Responsabilité partagée dans le cloud». Adaptation : les termes « client » et « Microsoft » apparaissent sous la forme « vous » et « fournisseur », la colonne « sur site » a été supprimée, et les lignes relatives aux hôtes physiques, au réseau et au centre de données ont été regroupées en une seule.
Microsoft énumère également quatre responsabilités qui vous incombent quel que soit le modèle de service : les données, les terminaux, les comptes et la gestion des accès. Les appareils clients apparaissent comme « partagés » dans le cadre du SaaS, car Microsoft peut vous aider à les gérer dans ce contexte, mais la protection de ces terminaux reste de votre ressort.
Infrastructure en tant que service (IaaS)
Avec l'IaaS, vous louez des ressources de calcul, de stockage et de réseau, comme Amazon EC2, Azure Virtual Machines ou Google Compute Engine. Le fournisseur assure la sécurité de l'infrastructure physique et de la couche de virtualisation. Vous vous chargez du système d'exploitation invité (OS invité), des logiciels installés et de la configuration réseau.
AWS l'explique clairement. Les clients qui déploient une instance EC2 sont responsables de la « gestion du système d'exploitation invité (y compris les mises à jour et les correctifs de sécurité) », ainsi que de tout logiciel qu'ils installent et de la configuration du groupe de sécurité sur chaque instance. AWS mentionne également la gestion des correctifs comme un contrôle partagé : AWS applique les correctifs à l'infrastructure, tandis que les clients s'occupent de ceux de leur système d'exploitation invité et de leurs applications. La matrice de Microsoft va dans le même sens pour l'IaaS et attribue la responsabilité du système d'exploitation au client.
Plateforme en tant que service (PaaS)
Les plateformes gérées telles qu’Azure App Service, Azure Functions et Azure SQL Database, que Microsoft classe dans la catégorie PaaS, transfèrent une plus grande partie de la charge de travail au fournisseur. Ce dernier se charge du système d’exploitation, de l’environnement d’exécution et des intergiciels. Les applications et les contrôles réseau deviennent partagés. Vous conservez la configuration de l’application, la sécurité du code, les contrôles d’accès et les bibliothèques que vous intégrez à votre déploiement.
Les versions d'exécution sont également retirées selon un calendrier préétabli, et lorsque cela se produit, c'est à vous qu'il revient de gérer la migration.
Logiciel en tant que service (SaaS)
Les solutions SaaS, telles que Microsoft 365 ou Dynamics 365, confient au fournisseur la quasi-totalité de la pile technologique. Google l'explique ainsi : dans le cadre du SaaS, le fournisseur assume l'essentiel des responsabilités en matière de sécurité, tandis que vous restez responsable de vos contrôles d'accès et des données que vous choisissez de stocker. Microsoft considère ici les appareils clients comme un domaine partagé. Il peut proposer certaines fonctionnalités de gestion des appareils, mais la protection des terminaux et la conformité restent de votre ressort.
Quelles sont les responsabilités des fournisseurs de services cloud ?
Les fournisseurs gèrent les couches les plus proches du matériel. La documentation de Microsoft divise son domaine en plusieurs domaines, et AWS établit une distinction similaire.
Infrastructure physique
La sécurité du centre de données relève de la responsabilité du fournisseur : les installations, les contrôles d'accès physique, les contrôles environnementaux, ainsi que les serveurs physiques qui hébergent vos charges de travail.
Principes fondamentaux des réseaux
La gestion des routeurs, des commutateurs et du câblage au sein du centre de données incombe au fournisseur. Dans le cadre du modèle PaaS, Microsoft fournit un niveau de base de sécurité réseau, tandis que dans le modèle SaaS, c’est lui qui gère la sécurité du réseau. Règles de pare-feu et la segmentation de vos propres instances restent sous votre contrôle en IaaS.
Virtualisation et couches hôtes
L' hyperviseur et le système d’exploitation hôte appartiennent également au fournisseur. AWS décrit sa partie de la chaîne comme s’étendant du système d’exploitation hôte et de la couche de virtualisation jusqu’à la sécurité physique des installations, ce qui exclut votre système d’exploitation invité de ce périmètre.
Documentation relative à la conformité
AWS, Microsoft et Google Cloud publient chacun une documentation relative à la conformité. AWS indique que ses clients peuvent utiliser sa documentation sur les contrôles et la conformité pour évaluer et vérifier eux-mêmes leurs propres contrôles. L’entreprise les renvoie également vers des documents d’attestation d’audit émanant de tiers afin de déterminer quels contrôles ils ont déjà mis en place et ceux qu’ils doivent encore mettre en œuvre. Microsoft publie des rapports d’audit via son portail Service Trust, tandis que Google Cloud propose des rapports d’audit et des certifications via son Compliance Reports Manager. Certaines ressources de Microsoft et de Google nécessitent une connexion, et certains documents sont partagés sous réserve de clauses de confidentialité.
Quelles sont les responsabilités des organisations ?
Dans le cadre de l'IaaS, vous êtes responsable de la majeure partie de la pile. Cela commence par l'application des correctifs au système d'exploitation invité et au noyau sur chaque instance, y compris celles lancées à partir d'anciennes images, et s'étend aux applications que vous exécutez ainsi qu'aux bibliothèques qu'elles utilisent, même celles que vous n'avez jamais choisies directement.
Vous configurez également le réseau. Dans le cadre de l’IaaS, cela concerne les groupes de sécurité, les règles de pare-feu et la segmentation. Dans le cadre du PaaS, cela concerne les contrôles réseau au niveau des applications. La mise en place de la journalisation et de la surveillance vous incombe également. Sur Google Cloud, par exemple, les journaux d’audit relatifs à l’accès aux données sont désactivés par défaut pour tous les services, à l’exception de quelques-uns liés à BigQuery ; ainsi, pour la plupart des services, vous ne disposerez pas de ces journaux tant que vous ne les aurez pas activés.
La sauvegarde et la restauration varient selon le service. Sur Amazon EC2, vous configurez vous-même des instantanés ou des politiques de sauvegarde pour vos volumes, à l'aide d'outils tels qu'AWS Backup ou Amazon Data Lifecycle Manager. Amazon RDS active les sauvegardes automatisées par défaut, mais c'est à vous de décider de la durée de conservation de celles-ci.
Pour connaître les bonnes pratiques en matière de développement et de déploiement sécurisés, consultez notre guide sur les meilleures pratiques en matière de sécurité logicielle.
Types de mesures de sécurité dans le cloud
Les cadres de sécurité dans le cloud couvrent généralement des domaines tels que les cinq ci-dessous.
Gestion des identités et des accès
Les rôles, les politiques, les comptes de service et la fédération déterminent souvent l'étendue de l'accès dont dispose un identifiant compromis. Le principe du privilège minimal, l'authentification multifactorielle sur les comptes utilisateurs et la rotation régulière (voire la suppression pure et simple) des clés statiques permettent de restreindre ce champ d’action. Les comptes de service créés pour des tâches ponctuelles doivent faire l’objet d’un examen périodique, et tout ce qui n’est plus nécessaire doit être supprimé.
Protection des données et chiffrement
Commencez par classer les données en fonction de leur niveau de sensibilité, puis déterminez qui gère les clés. Les clés gérées par le fournisseur sont plus simples à utiliser, tandis que celles gérées par le client vous offrent davantage de contrôle sur leur rotation et leur révocation. Quel que soit votre choix, notez clairement quels ensembles de données utilisent quel type de clés.
Contrôles et segmentation du réseau
Les groupes de sécurité, les listes de contrôle d'accès réseau (ACL), les points d'extrémité privés et les périmètres de service déterminent quels systèmes peuvent communiquer entre eux. La segmentation limite la portée d'une charge de travail compromise, tandis que le filtrage du trafic sortant limite les destinations vers lesquelles cette charge de travail peut établir des connexions.
Charge de travail et application des correctifs au système d'exploitation invité
Dans le cadre de l'IaaS, l'application des correctifs est l'une des tâches récurrentes les plus importantes que vous devez effectuer. Linux est largement utilisé sur les serveurs cloud et d'hébergement, et une mise à jour du noyau a traditionnellement nécessité le redémarrage de l'instance. Lorsque l'on gère un parc important de serveurs, trouver une plage horaire de maintenance pour chaque redémarrage peut retarder l'application des correctifs.
Les fournisseurs proposent effectivement des outils à cet effet. AWS Systems Manager Patch Manager, la mise à jour automatique des systèmes d’exploitation invités sur les machines virtuelles Azure et Google Cloud VM Manager Patch permettent tous d’automatiser l’application des correctifs aux systèmes d’exploitation invités sur vos instances. Chacun de ces outils peut redémarrer l’instance dans le cadre du processus, et chacun a son propre champ d’application. La mise à jour automatique d’Azure, par exemple, ne couvre que les correctifs classés comme « critiques » ou « de sécurité ». Dans tous les cas, le système d’exploitation invité lui-même reste de votre côté de la barrière dans un environnement IaaS.
La correction en temps réel emprunte une voie différente et applique des correctifs de sécurité au noyau sur un système en cours d'exécution. Certaines distributions et certains fournisseurs proposent leur propre solution de correctifs en temps réel pour certaines plateformes ; ainsi, un parc informatique mélangeant plusieurs distributions peut se retrouver à jongler entre plusieurs outils. KernelCare propose la mise à jour en direct du noyau Linux pour plus de 70 versions de distributions Linux, ce qui vous permet de corriger les vulnérabilités du noyau sur des serveurs cloud et d’hébergement en cours d’exécution sans avoir à planifier de redémarrage.
Journalisation et surveillance
Des services tels qu’AWS CloudTrail, Azure Monitor et Google Cloud Audit Logs enregistrent l’activité au sein de votre environnement. L’envoi des journaux vers un compte ou un projet distinct rend plus difficile, en cas de compromission d’un environnement, l’effacement de sa propre piste d’audit, en particulier lorsque l’accès à la destination est strictement restreint. Des audits de sécurité permettent de vérifier que les journaux couvrent bien vos besoins.
Comment les menaces courantes liées au cloud se rapportent à vos responsabilités
Les menaces liées au cloud ont tendance à s'inscrire dans le cadre du principe de responsabilité partagée, ce qui permet de déterminer plus facilement celles sur lesquelles vous pouvez agir. Selon la matrice de Microsoft, les paramètres mal configurés et les identités compromises relèvent de votre responsabilité dans les trois modèles de service. Les vulnérabilités du système d’exploitation relèvent de votre responsabilité en IaaS et sont transférées au fournisseur en PaaS et SaaS. Si vous créez et déployez vos propres images de conteneurs et dépendances, celles-ci restent sous votre responsabilité, quelle que soit la plateforme sur laquelle elles s’exécutent. Notre article sur les menaces de sécurité dans le cloud traite chacune de ces catégories en détail.
Les systèmes non mis à jour et en fin de vie suivent la même règle dans l’IaaS, où la maintenance du système d’exploitation vous incombe. Une instance cloud peut continuer à fonctionner pendant des années à partir d’une image créée il y a longtemps. Lorsque sa distribution Linux, son environnement d’exécution ou son framework arrive en fin de vie, le fournisseur cesse de publier des mises à jour de sécurité, mais la charge de travail continue souvent à traiter le trafic pendant que la migration est planifiée. Le service Endless Lifecycle Support (ELS) de TuxCare fournit des correctifs de sécurité pour les distributions Linux, les environnements d’exécution, les frameworks et les applications en fin de vie après la fin du support standard de leurs éditeurs, ce qui vous laisse la possibilité de migrer selon votre propre calendrier.
Défis courants liés au partage des responsabilités
La file d'attente évolue à chaque service
Dans un service Kubernetes géré, le fournisseur gère le plan de contrôle, et ce qui arrive aux nœuds de travail dépend de l’option que vous choisissez. Sur Amazon EKS, AWS prend davantage en charge les opérations à mesure que vous passez de nœuds autogérés à des groupes de nœuds gérés, puis à Fargate. Même avec des groupes de nœuds gérés, vous devez toujours lancer la mise à jour vers une nouvelle version de l’AMI, et EKS se charge ensuite de la déployer sur l’ensemble de vos nœuds. Un modèle basé sur un service peut vous induire en erreur concernant le suivant ; veillez donc à consulter la documentation relative aux responsabilités de chaque service.
La gestion des correctifs peut passer entre les mailles du filet entre les équipes
Si l'ingénierie de la plateforme est responsable de la structure des comptes, que les équipes applicatives gèrent leurs propres déploiements et que la sécurité est chargée des politiques, l'application des correctifs sur les systèmes d'exploitation invités peut se situer à la croisée de ces trois domaines. Désignez un responsable. Une question utile à poser lors de votre prochaine réunion de revue est la suivante : qui a appliqué le correctif au noyau de l'instance de production la plus ancienne, et quand ?
Les cas oubliés passent facilement inaperçus
Un élément qui n'a jamais été ajouté à votre inventaire des actifs n'apparaîtra pas non plus dans vos rapports de correctifs. La comparaison de cet inventaire avec la liste de vos ressources cloud et vos données de facturation peut permettre de mettre en évidence des systèmes dont aucune équipe ne revendique la propriété.
Conseils en matière de sécurité dans le cloud pour 2026
Consultez la documentation relative aux responsabilités d'un nouveau service avant de le déployer, et non après. Apportez des modifications au système d'exploitation invité et aux correctifs du noyau . Renforcez la sécurité des identités grâce au principe du privilège minimal, à l’authentification multifactorielle et à la rotation régulière des identifiants statiques, et déterminez qui détient les clés de chiffrement pour chaque ensemble de données (puis consignez-le par écrit).
Du point de vue opérationnel, enregistrez les journaux système dans un compte ou un projet distinct et vérifiez que les alertes parviennent bien à une personne. Prévoyez des systèmes capables de fonctionner au-delà de la fin du support du fournisseur, y compris les environnements d'exécution et les images de base. Et rédigez votre procédure d’intervention en cas d’incident avant d’en avoir besoin, car le cœur d’un incident n’est pas le moment idéal pour s’y mettre.
Exploitez des environnements sécurisés avec TuxCare
Dans le cadre de l'IaaS, le fournisseur assure la sécurité de l'infrastructure, tandis que le système d'exploitation invité de chaque instance reste sous la responsabilité de votre équipe. Les dépendances open source que vous intégrez à votre propre logiciel vous appartiennent également, quel que soit l'environnement d'exécution. Assistance tout au long du cycle de vie fournit des correctifs de sécurité pour les distributions Linux, les environnements d'exécution, les frameworks et les applications en fin de vie, afin que la migration puisse s'effectuer selon votre calendrier plutôt que selon les délais imposés par un fournisseur. SecureChain vous fournit des paquets open source vérifiés, analysés contre les logiciels malveillants et mis à jour en continu pour JavaScript, Python, Java, Go, Rust et PHP. Et KernelCare applique les correctifs de sécurité du noyau aux serveurs Linux en cours d’exécution sans redémarrage, ce qui évite d’avoir à attendre une fenêtre de maintenance pour les correctifs du noyau.
Pour découvrir comment la gestion des correctifs s'intègre dans une stratégie cloud plus globale, consultez notre guide sur gestion des correctifs dans le cloud.
