La plupart des organisations abordent la mise à jour des correctifs dans le cloud de la même manière qu'elles l'ont toujours fait : rechercher les vulnérabilités, planifier une fenêtre de maintenance, déployer les mises à jour, vérifier les résultats. Le problème, c'est que l'infrastructure cloud ne reste pas stable assez longtemps pour que ce processus puisse fonctionner. Lorsque la mise à jour des correctifs prend du retard dans les environnements cloud, la fenêtre d'exposition s'élargit rapidement et passe souvent inaperçue.
Les groupes à dimensionnement automatique lancent des instances qui disparaissent avant l'exécution de votre analyse hebdomadaire. Les conteneurs sont remplacés, et non corrigés. Le modèle de responsabilité partagée signifie que votre fournisseur de services cloud prend en charge certaines couches tandis que vous vous chargez d'autres, et que les limites ne sont pas toujours évidentes. Ces différences structurelles remettent en cause les hypothèses sur lesquelles repose la gestion traditionnelle des correctifs.
Cet article identifie les cas où ces hypothèses ne tiennent pas la route et explique comment y remédier, qu'il s'agisse des limites de responsabilité, de la correction des conteneurs, de la vérifiabilité de la conformité ou des indicateurs de performance du programme.
Pourquoi les environnements cloud remettent en cause les principes traditionnels de gestion des correctifs
Dans les environnements cloud, les ressources sont dynamiques, leur propriété est partagée avec les fournisseurs, et les workflows d’analyse et de correction conçus pour les infrastructures sur site passent souvent complètement à côté de certaines charges de travail.
L' traditionnelle de gestion des correctifs repose sur certaines hypothèses qui ne s'appliquent pas aux environnements cloud. Ce modèle part du principe que les ressources sont permanentes, que vous maîtrisez l'ensemble de la pile et qu'un cycle de correctifs hebdomadaire ou mensuel permet de couvrir l'ensemble du système.
La mise à jour des infrastructures cloud remet en cause chacune de ces hypothèses, et en l’absence d’un programme structuré de gestion des vulnérabilités , les failles qui en résultent peuvent exposer les organisations à des cyberattaques pendant des semaines, voire des mois.
Dans un centre de données classique, un serveur reste en service jusqu'à ce que quelqu'un le mette hors service. Vous pouvez effectuer une analyse, planifier une fenêtre de maintenance, déployer un correctif et vérifier le résultat. L'actif reste en place.
Les charges de travail dans le cloud se comportent différemment. Un groupe à dimensionnement automatique peut lancer 50 instances pendant les pics de trafic et les arrêter une heure plus tard. Un microservice conteneurisé peut fonctionner pendant quelques secondes avant d'être remplacé.
Ce caractère éphémère pose un problème de synchronisation.
Si votre processus de gestion des correctifs s'effectue à une fréquence hebdomadaire, il ne prendra pas en compte les charges de travail qui n'existent pas pendant une semaine entière. Si votre inventaire des actifs est mis à jour quotidiennement, il ne prendra pas en compte les instances qui ont été créées puis supprimées entre deux analyses.
Le modèle de propriété ajoute également une couche supplémentaire de complexité. Dans les environnements sur site, votre équipe contrôle tout, du matériel physique au code des applications. Dans le cloud, cette pile est répartie entre vous et votre fournisseur. Ces limites varient selon le type de service et ne sont pas toujours évidentes.
Ces différences structurelles ne signifient pas pour autant que l'application de correctifs dans le cloud soit impossible. Ils veulent dire que les hypothèses, les outils et les processus qui fonctionnaient en environnement sur site ne sont souvent pas directement transposables. Les sections suivantes expliquent en détail dans quels cas ces hypothèses ne tiennent pas la route et comment y remédier.
Le modèle de responsabilité partagée et ce dont votre organisation est réellement responsable
Tous les principaux fournisseurs de services cloud fonctionnent selon un modèle de responsabilité partagée. Le fournisseur assure la sécurité de l'infrastructure, et le client assure la sécurité des applications qui y sont exécutées. La répartition exacte dépend du type de service, et pour les organisations qui font appel à des prestataires de services gérés, il est tout aussi essentiel de bien comprendre où s'arrêtent les obligations du prestataire et où commencent les vôtres.
Dans le cadre d' de type « Infrastructure as a Service » (IaaS), telles que les instances AWS EC2 ou les machines virtuelles Microsoft Azure, le fournisseur gère le centre de données physique, l'hyperviseur et l'infrastructure réseau.
Votre organisation gère le système d'exploitation, les intergiciels, les applications et les données. Cela signifie que les correctifs du système d'exploitation, les mises à jour des applications tierces et le renforcement de la sécurité des configurations relèvent de votre responsabilité.
Dans le cas des services « Platform as a Service » (PaaS)s, tels qu’Azure App Service ou AWS Elastic Beanstalk, le fournisseur prend en charge davantage de tâches. Ils gèrent généralement le système d'exploitation et l'environnement d'exécution. Vous restez responsable du code de votre application et de toutes les dépendances que vous déployez.
Dans le cadre des services PaaS gérés, les fournisseurs peuvent appliquer des correctifs au système d'exploitation ou à l'environnement d'exécution sous-jacents selon leur propre calendrier, ce qui laisse parfois aux clients un contrôle limité sur le moment de ces interventions. Les organisations restent responsables de la compatibilité des applications, de la gestion des dépendances et de la vérification que les correctifs fournis par les éditeurs n'entraînent pas de régressions.
Dans le cadre d'une offre « Software as a Service » (SaaS), le prestataire se charge de presque tout. Votre responsabilité se limite aux données, aux contrôles d'accès et aux paramètres de configuration.
| Modèle de service | Responsabilité du prestataire | Responsabilité du client |
|---|---|---|
| IaaS | Infrastructure physique, hyperviseur, réseau | Système d'exploitation, intergiciel, applications, données |
| PaaS | Infrastructure, système d'exploitation et environnement d'exécution | Code de l'application, dépendances, données |
| SaaS | Full stack | Données, contrôles d'accès, configuration |
La difficulté réside dans le fait que de nombreuses organisations combinent ces trois approches. Une même application peut utiliser des machines virtuelles IaaS pour les composants hérités, des services PaaS pour les API et des outils SaaS pour la surveillance. Chaque couche est soumise à des obligations de correction différentes, et aucun outil proposé par le fournisseur de services cloud ne permet de toutes les couvrir.
C'est là que des lacunes apparaissent. Les équipes partent du principe que le fournisseur applique les correctifs, alors que ce n'est pas le cas. Ou bien ils appliquent un correctif au système d'exploitation, mais négligent une bibliothèque vulnérable au niveau de la couche applicative. Le modèle de responsabilité partagée n'est pas un problème ponctuel qu'il suffit de résoudre une fois pour toutes. Il s'agit d'une limite que vous redéfinissez en permanence à mesure que votre empreinte cloud évolue. Une mauvaise interprétation de cette limite figure parmi les causes les plus fréquentes de défaillances en matière de sécurité dans le cloud.
Une fois que vous savez ce que vous possédez, la question suivante est de savoir comment vous allez concrètement y apporter des correctifs. Cela dépend si vous utilisez des instances traditionnelles ou des charges de travail conteneurisées d' .
Deux approches en matière de correctifs : mises à jour sur place ou correction par image
Les environnements cloud prennent en charge deux approches fondamentalement différentes en matière d'application de correctifs. Le choix approprié dépend de l'architecture de votre charge de travail.
Application de correctifs à chaud pour les instances persistantes
Pour les machines virtuelles et les instances en fonctionnement depuis longtemps, l'application de correctifs sur place fonctionne de la même manière que sur site. Vous identifiez les systèmes vulnérables, déployez les correctifs pendant une fenêtre de maintenance, redémarrez si nécessaire et vérifiez la mise à jour de sécurité. L'instance persiste avant et après l'application du correctif.
Cette approche convient aux charges de travail qui s'exécutent en continu : serveurs de bases de données, hôtes d'applications ou systèmes existants qui n'ont pas encore été conteneurisés. L'outillage vous est familier. Le défi réside dans l'évolutivité et la coordination. Lorsque des instances s'étendent sur plusieurs comptes cloud ou plusieurs régions, il est essentiel de planifier soigneusement les fenêtres de maintenance, car le moindre décalage dans le calendrier entraîne un risque d'interruption de service pour les services stratégiques de l'entreprise.
Correction basée sur des images pour les conteneurs et l'infrastructure immuable
Les conteneurs ne sont pas mis à jour sur place. Un conteneur en cours d'exécution est considéré comme immuable. Si une vulnérabilité est détectée dans l'image du conteneur, vous la corrigez en recompilant l'image avec les dépendances mises à jour, puis en la redéployant.
Cela permet d'intégrer l'application des correctifs en amont dans le pipeline CI/CD. Votre équipe de sécurité identifie une image de base ou une bibliothèque vulnérable. Votre équipe de développement met à jour le fichier Dockerfile ou la configuration de compilation. Le pipeline crée une nouvelle image, la transfère vers le registre, puis des outils d'orchestration tels que Kubernetes déploient les conteneurs mis à jour.
L'avantage réside dans la cohérence : chaque instance exécute la même image mise à jour.
Le compromis réside dans la coordination : l'application des correctifs « » implique désormais les développeurs, et non plus uniquement les équipes d'exploitation, et nécessite une intégration avec vos outils de compilation et de déploiement, et non plus uniquement avec votre plateforme de gestion des correctifs.
Dans la pratique, il arrive que les équipes modifient occasionnellement un conteneur en cours d'exécution à des fins de débogage d'urgence ou d'atténuation à court terme ; toutefois, cette pratique n'est pas considérée comme une stratégie de correction durable ou vérifiable et doit être réintégrée dans le pipeline d'images.
Conseil : Effectuez une analyse des images de conteneurs dans votre registre avant leur déploiement, et pas seulement en production. Tester les correctifs et les mises à jour d'images dans un environnement de préproduction avant de les déployer en production permet de réduire l'urgence des interventions, de minimiser le risque de régressions et de simplifier la restauration en cas de problèmes.
Les services PaaS nécessitent souvent une planification des mesures à prendre plutôt qu'une application directe des correctifs, car les clients peuvent avoir besoin de vérifier le comportement de leurs applications après les mises à jour effectuées par le fournisseur, plutôt que de déployer eux-mêmes les correctifs.
De nombreuses organisations appliquent ces deux modèles simultanément. Les machines virtuelles hébergent des charges de travail avec état, tandis que les conteneurs prennent en charge les microservices sans état. Votre approche de gestion des correctifs variera selon chaque cas, avec des processus, des responsables et des méthodes de vérification différents.
Assurer la visibilité des correctifs sur l'ensemble des charges de travail éphémères et à dimensionnement automatique
Les inventaires traditionnels des ressources d' , , partent du principe que les terminaux restent en service suffisamment longtemps pour pouvoir être détectés, analysés et suivis. Les charges de travail dans le cloud ne fonctionnent souvent pas comme prévu.
Un groupe à dimensionnement automatique peut lancer des instances en réponse à des pics de trafic et les arrêter lorsque la demande diminue. Dans le cadre de son fonctionnement normal, un déploiement Kubernetes peut remplacer des pods toutes les quelques heures. Une fonction sans serveur peut s'exécuter en quelques millisecondes. Aucun de ces éléments ne s'inscrit parfaitement dans le cadre d'un bilan hebdomadaire des actifs.
Cela soulève deux problèmes liés. Vous ne pouvez pas appliquer de correctif à ce que vous ne voyez pas, et l'absence de correctifs sur les charges de travail éphémères est particulièrement dangereuse, car ces failles risquent de ne jamais être détectées avant que l'instance ne soit arrêtée et remplacée par une autre copie vulnérable. Et vous ne pouvez pas prouver la conformité pour des actifs qui n'existent plus lorsque l'auditeur vous le demande.
Plusieurs approches permettent de remédier au problème de la visibilité éphémère :
- Marquage au lancement : Utilisez le marquage et les métadonnées « cloud-native » pour collecter les informations pertinentes pour les correctifs lors du démarrage des instances. Les balises peuvent indiquer la version de l'image de base, la date du dernier correctif ou le statut de conformité au moment de la création.
- Déplacer la vérification vers la gauche : Pour les charges de travail conteneurisées, vérifiez l'état des correctifs dans l'image avant le déploiement plutôt que dans le conteneur en cours d'exécution. Si l'image est intacte, les conteneurs lancés à partir de celle-ci héritent généralement de cet état lors du déploiement.
- Utilisez la gestion des stocks en temps réel : Les inventaires périodiques ne permettent pas de recenser les actifs à courte durée de vie. L' e de découverte en temps réel permet de réduire les angles morts en recensant les ressources actuellement en cours d'exécution, même si celles-ci n'existent plus lors de la prochaine analyse programmée.
- Enregistrer les événements liés au cycle de vie : Les fournisseurs de services cloud génèrent des événements lors du démarrage et de l'arrêt des instances. La consignation de ces événements permet de constituer une piste d'audit, même pour les actifs qui n'existent plus.
L'objectif n'est pas d'appliquer un correctif à chaque instance éphémère individuellement. Cela permet de s'assurer que les images, les modèles et les configurations à partir desquels ces instances sont lancées ont déjà reçu les correctifs nécessaires. Si votre image AMI « golden » ou votre image de conteneur de base est à jour, les instances créées à partir de celle-ci héritent de ce niveau de sécurité. Votre niveau de conformité reflète donc l'état de ces artefacts sources, et non celui des instances éphémères en cours d'exécution à un moment donné.
La visibilité est un problème technique, mais c'est aussi un problème d'organisation. Qui est chargé d'appliquer les correctifs aux charges de travail dans le cloud lorsque trois équipes différentes interviennent sur la même application ?
Gouvernance et responsabilité : harmoniser la sécurité, les opérations informatiques et le DevOps
L'application de correctifs dans le cloud met en évidence des lacunes de coordination que les environnements sur site ont tendance à masquer. Dans un centre de données traditionnel, le service informatique est entièrement responsable de la gestion des correctifs. Dans le cloud, cette responsabilité est répartie entre les équipes chargées de la sécurité, des opérations informatiques et du DevOps. Les équipes informatiques, qui contrôlaient autrefois l'intégralité du cycle de vie des correctifs, se partagent désormais cette responsabilité, et c'est au niveau des points de transfert entre elles que la mise en œuvre des mesures correctives s'enlise.
Les équipes de sécurité identifient les vulnérabilités en suivant les CVE pertinents et fixent des délais de correction. Le service des opérations informatiques gère l'infrastructure et les créneaux de maintenance. Les équipes DevOps gèrent le pipeline CI/CD et les images de conteneurs. Il se peut que l'équipe d'ingénierie de la plateforme soit responsable des clusters Kubernetes. Chaque groupe dispose d'outils différents, a des priorités différentes et a sa propre définition de ce qu'est un travail « terminé ». En l'absence de coordination, les efforts de correction s'enlisent aux points de relais entre ces équipes, au lieu de se dérouler sans heurts, de l'identification à la correction.
Cette fragmentation est source de tensions. Le service de sécurité a signalé une vulnérabilité critique. Le service informatique affirme qu'il s'agit d'un problème lié aux conteneurs et que cela ne relève pas de sa responsabilité. L'équipe DevOps indique qu'elle s'en occupera lors du prochain sprint. En attendant, cette faille de sécurité n'a toujours pas fait l'objet d'un correctif.
«» Il y a dix ans, les failles dues à une mauvaise configuration du cloud n'étaient même pas considérées comme une menace à part entière. Aujourd’hui, le cloud et les données qu’il contient constituent une cible de choix. »Rapport IBM sur le coût d'une fuite de données 2025
Définir clairement les limites des responsabilités
Commencez par recenser qui est propriétaire de quoi. Pour chaque type de charge de travail, précisez qui identifie les failles de sécurité, qui approuve les mesures correctives, qui applique le correctif ou la mise à jour de l'image, et qui vérifie que le problème a bien été résolu.
Cette correspondance variera selon qu'il s'agit de machines virtuelles, de conteneurs ou de services PaaS. C'est tout à fait normal. L'objectif est la clarté, et non l'uniformité. Une fois la responsabilité établie, consignez-la officiellement dans vos politiques de gestion des correctifs afin que les attentes soient harmonisées entre les équipes et puissent servir de référence lors des audits ou des analyses d'incidents.
Intégration au processus de gestion du changement existant
La mise à jour des correctifs dans le cloud continue de bénéficier d'une gouvernance. Les correctifs qui contournent la procédure de gestion des changements présentent un risque, même s'ils corrigent des vulnérabilités. L'intégration des processus de correction dans le cloud aux processus existants de gestion des services informatiques (ITSM) permet de maintenir une bonne maîtrise de la situation.
Les équipes ne sont pas obligées d'utiliser les mêmes outils, mais elles ont tout à gagner à partager les mêmes données. Une vue unifiée de l'état des actifs, du statut des vulnérabilités et de l'historique des correctifs permet d'éviter les accusations mutuelles et d'accélérer la mise en œuvre des mesures correctives.
Garantie de la traçabilité en matière de conformité lorsque votre infrastructure évolue quotidiennement
Les auditeurs attendent des preuves : ce qui a été corrigé, à quel moment et sur quels systèmes. Dans des environnements statiques, c'est déjà assez difficile. Les environnements cloud compliquent les choses. L'instance qui présentait une vulnérabilité mardi dernier n'existe peut-être plus aujourd'hui.
L'instance qui présentait une vulnérabilité la semaine dernière n'existe peut-être plus aujourd'hui. Le conteneur qui a fonctionné pendant la période d'audit a été remplacé à trois reprises. Le groupe à dimensionnement automatique qui gérait les pics de trafic est revenu à zéro.
Mise en place d'une piste d'audit pour une infrastructure dynamique
Plusieurs pratiques permettent de garantir la traçabilité dans des environnements dynamiques :
- Enregistrement de l'état au moment du déploiement : Enregistrez le niveau de correctif, la version de l'image et l'état de conformité lors du lancement des charges de travail. Cela permet de créer un enregistrement à un instant donné, même si la charge de travail est ensuite interrompue.
- Conservation des journaux de cycle de vie : Les fournisseurs de services cloud enregistrent la création et la suppression des instances, ainsi que les modifications de configuration. Conservez ces journaux pendant toute la durée de conservation requise aux fins de conformité.
- Utilisez des artefacts immuables : Les images de conteneurs stockées dans un registre sont immuables. Si vous pouvez prouver que l'image a été analysée et corrigée avant son déploiement, vous pouvez démontrer la conformité de chaque conteneur lancé à partir de celle-ci.
- Intégration avec les systèmes SIEM et CMDB : Importez les données relatives aux actifs cloud dans votre système de gestion des informations et des événements de sécurité (SIEM) et dans votre base de données de gestion des configurations (CMDB). Cela permet de créer un registre centralisé qui perdure au-delà de la durée de vie de chaque actif.
| Exigence d'audit | Approche de l'environnement statique | Approche de l'environnement cloud |
|---|---|---|
| Inventaire des actifs | Analyse périodique | Détection en temps réel grâce à la journalisation du cycle de vie |
| Historique des mises à jour | Enregistrements par point d'accès | Enregistrements au niveau des images et journaux de déploiement |
| Preuves de conformité | Rapports ponctuels | Enregistrement continu de l'état au démarrage |
| Fidélisation | Basé sur les terminaux | Basé sur les artefacts et les journaux |
On passe désormais du suivi des points de terminaison individuels au suivi des artefacts et des configurations qui les définissent. De nombreux cadres d'audit ont été conçus pour des infrastructures statiques et peuvent encore exiger des éléments probants axés sur les terminaux. Les organisations doivent souvent traduire les contrôles au niveau des artefacts et des pipelines en descriptions et rapports compréhensibles par les auditeurs, même lorsque l'infrastructure sous-jacente est entièrement dynamique.
Si vos images de base, vos modèles de lancement et vos pipelines de déploiement sont conformes à vos exigences de conformité en matière d' , les charges de travail qu'ils génèrent sont généralement mieux à même de soutenir ces efforts. Cela ne dispense pas de la nécessité de se préparer en permanence à l'audit, mais cela réduit le volume de rapprochements manuels à effectuer.
Évaluation de la maturité d'un programme de gestion des instances cloud
Les indicateurs vous permettent de savoir si votre programme est efficace. Sans elles, vous n'avez d'autre choix que de deviner. Commencez par établir une base de référence — un instantané à un moment donné de votre niveau actuel de conformité en matière de correctifs, de votre couverture et de votre délai moyen d'application des correctifs — afin de disposer d'un point de référence pour mesurer les progrès réalisés. Les indicateurs pertinents pour la gestion des correctifs dans le cloud diffèrent légèrement de ceux des environnements traditionnels, car le parc d'actifs est dynamique.
Si les environnements cloud peuvent permettre une correction plus rapide, la vitesse réelle d'application des correctifs dépend davantage de la maturité des processus, de la clarté des responsabilités et de la rigueur en matière de gestion des images que de l'infrastructure seule. Les indicateurs permettent de faire la distinction entre la vitesse perçue et les performances constantes et reproductibles.
Indicateurs clés relatifs à l'application des correctifs dans le cloud
- Délai moyen de correction (MTTP) par niveau de gravité : Délai entre la divulgation de la vulnérabilité et la confirmation de la correction. Suivez séparément les résultats critiques, élevés et moyens afin de déterminer si vos délais de réponse respectent les SLA internes ou les exigences du cadre réglementaire de l' .
- Taux de conformité des correctifs par catégorie d'actifs : Quel pourcentage de vos machines virtuelles, conteneurs et services PaaS est à jour ? Veuillez ventiler ces données par type de charge de travail. Un taux de conformité de 95 % pour les machines virtuelles n'a guère d'importance si celui de vos conteneurs s'élève à 60 %. Le suivi de la conformité par classe d'actifs vous aide également à évaluer si vos processus de mise à jour s'adaptent à mesure que votre environnement cloud s'étend ou se diversifie.
- Source de l'image : Pour les charges de travail conteneurisées, suivez le nombre de conteneurs en cours d'exécution qui utilisent des images plus anciennes qu'un seuil défini. Les images obsolètes contiennent souvent des vulnérabilités non corrigées.
- Respect du SLA concernant les vulnérabilités critiques : Respectez-vous vos délais internes ou réglementaires pour l'application des correctifs critiques ? Suivre les exceptions et leurs causes profondes.
- Taux de couverture : Quel pourcentage de vos ressources cloud est réellement géré par votre processus de gestion des correctifs ? Les actifs non gérés constituent des angles morts.
Ces indicateurs s'adressent à différents publics.
Le respect du MTTP et du SLA revêt une importance capitale pour les responsables de la sécurité. Les taux de conformité revêtent une grande importance pour les auditeurs. Les taux de couverture revêtent une grande importance pour les équipes opérationnelles qui s'efforcent de combler les lacunes.
Examinez régulièrement les indicateurs. Un simple aperçu vous permet de savoir où vous en êtes. Les tendances vous permettent de savoir si vous vous améliorez.
Le rôle de l'automatisation dans la gestion des correctifs dans le cloud
À mesure que les organisations perfectionnent leurs pratiques en matière d'application de correctifs dans le cloud, des workflows automatisés et sélectifs peuvent contribuer à étendre la mise en œuvre des correctifs sans pour autant compromettre le contrôle.
L'automatisation permet de rationaliser des tâches telles que la création de tickets, le suivi des validations et la documentation des résultats, en particulier dans les environnements où le parc d'actifs et le volume de correctifs évoluent rapidement.
Cependant, l'automatisation n'est pas une caractéristique inhérente à la mise à jour des correctifs dans le cloud. Utilisée sans cadre de gouvernance, elle peut réduire le délai moyen de correction tout en augmentant le risque opérationnel, ce qui renforce la nécessité de définir clairement les responsabilités, les processus de validation et les procédures de validation avant d'étendre l'automatisation.
Comment Tanium facilite la gestion des correctifs dans le cloud d'entreprise
Une gestion efficace des correctifs dans le cloud commence par savoir ce qui est réellement en cours d'exécution, et non par se fier aux résultats de votre dernier scan. Dans les environnements cloud et hybrides, les machines virtuelles sont fréquemment créées, modifiées et mises hors service. Dans ce contexte, se fier à des données de stock obsolètes signifie qu' des systèmes vulnérables passent inaperçus ou ne sont pas corrigés.
Tanium facilite la gestion des charges de travail dans le cloud en offrant une visibilité en temps réel sur l'applicabilité, l'état et le déploiement des correctifs sur les terminaux hébergés dans le cloud et les terminaux hybrides, y compris les systèmes Windows, Linux et macOS. Cela permet aux équipes d'évaluer l'état de préparation actuel des correctifs, de suivre l'avancement du déploiement et de vérifier les résultats de l'installation, y compris les besoins de redémarrage, en se basant sur l'état en temps réel des terminaux plutôt que sur des cycles de reporting périodiques.
Au-delà du déploiement, Tanium étend les processus de mise à jour pour y inclure la validation et la collecte de preuves. En associant l'identification des vulnérabilités aux mesures correctives et à la validation post-déploiement au sein d'un même flux de travail opérationnel, les équipes peuvent mieux gérer l'application des correctifs dans des environnements cloud dynamiques, réduire les frictions liées aux transferts de responsabilité entre les équipes de sécurité et d'exploitation, et maintenir une supervision cohérente à mesure que l'infrastructure s'étend à travers les régions et les plateformes.
Tanium prend en charge l'ensemble du cycle de mise à jour en le centralisant au sein d'un flux de travail opérationnel unique, depuis l'évaluation jusqu'au déploiement, en passant par la vérification post-déploiement :
- Informations en temps réel sur les terminaux : Des informations actualisées sur l'état des correctifs sous Windows, Linux et macOS, sans dépendre uniquement d'analyses périodiques ou de données d'inventaire obsolètes.
- Déploiement progressif par anneaux : Déploiements par étapes qui commencent à petite échelle, permettent de valider les résultats et s'étendent lorsque les critères de réussite sont remplis, les terminaux critiques pour l'activité étant mis à jour ultérieurement afin de réduire le risque opérationnel.
- Guides d'automatisation régis : Une automatisation « low-code » et « no-code » qui maintient les opérateurs informés, avec une autorisation étape par étape et un suivi en temps réel de l'exécution des guides.
- Validation en boucle fermée : Vérification post-déploiement de l'état des correctifs, détection des exceptions et mises à jour en temps réel du tableau de bord sur l'ensemble des terminaux gérés.
- Hiérarchisation des correctifs en fonction des menaces : Capacité à prendre en compte les informations externes sur les menaces lors de la hiérarchisation des correctifs, afin de concentrer les mesures de correction sur les vulnérabilités activement exploitées dans la nature.
- Évaluation intégrée des vulnérabilités : Tanium Comply relie l'identification des vulnérabilités aux mesures correctives au sein d'une même plateforme, avec des mises à jour quotidiennes de la bibliothèque de contenus.
- Rapports de conformité : Évaluations conformes à la norme SCAP, conçues pour accompagner les programmes de conformité PCI, HIPAA et SOX, dans le cadre d'un dispositif de conformité plus large.
- Planification des fenêtres de maintenance : Planification des correctifs et processus de validation s'alignant sur les processus existants de gestion des changements afin de minimiser l'impact sur l'activité.
- Intégration de l'ITSM et de la CMDB : Les données sur les actifs sont transmises en temps réel à ServiceNow et à d'autres outils, et les workflows de correctifs sont reliés aux systèmes de tickets et d'approbation existants.
Ensemble, ces fonctionnalités ont pour objectif d'aider les organisations à réduire les lacunes en matière d'application des correctifs, à coordonner les mesures correctives entre les différentes équipes et à conserver des preuves prêtes à être présentées en cas d'audit, à mesure que les environnements évoluent et s'étendent.
Comment Tanium Cloud Workloads associe la visibilité de l'état de conformité au niveau des images au contexte d'exécution des conteneurs
Cette brève vidéo de présentation offre un aperçu général de la manière dont Tanium Cloud Workloads met en évidence les vulnérabilités du registre d'images, analyse les conteneurs en cours d'exécution et applique des politiques d'exécution Kubernetes afin d'aider les équipes à mieux comprendre les risques d'exposition dans les environnements conteneurisés dynamiques.
FAQ sur la gestion des correctifs dans le cloud
La mise à jour des correctifs dans le cloud soulève des questions opérationnelles auxquelles il n'existe pas toujours de réponse évidente.
Vous trouverez ci-dessous les questions les plus fréquemment posées par les équipes des entreprises lorsqu'elles étendent leurs programmes de gestion des correctifs aux environnements cloud.
Comment puis-je appliquer des correctifs à des charges de travail qui s'adaptent automatiquement tout au long de la journée ?
Vous n'appliquez pas de correctifs aux instances individuelles au sein des groupes à dimensionnement automatique. Il vous suffit plutôt d'apporter des modifications au modèle de lancement ou à l'AMI utilisé par le groupe. Lorsque de nouvelles instances sont créées, elles sont lancées à partir de l'image mise à jour. Les instances existantes peuvent être retirées progressivement dans le cadre d'un remplacement progressif.
Quelle est la différence entre l'application d'un correctif à une machine virtuelle et celle à un conteneur ?
Les machines virtuelles reçoivent des correctifs « in-place » au même titre que les serveurs traditionnels. Les conteneurs sont immuables. Vous recompilez l'image du conteneur avec les dépendances mises à jour, puis vous la redéployez. Le conteneur en cours d'exécution est remplacé, et non modifié.
À qui incombe la gestion des correctifs dans le cloud lorsque plusieurs équipes interviennent sur la même charge de travail ?
La responsabilité varie d'une organisation à l'autre, mais la clarté prime sur l'uniformité. Attribuez chaque type de charge de travail à des responsables spécifiques pour l'identification des vulnérabilités, l'approbation des mesures correctives, leur mise en œuvre et leur vérification. Consignez ces limites par écrit et réexaminez-les à mesure que votre utilisation du cloud évolue.
Comment puis-je prouver la conformité des correctifs pour les actifs qui n'existent plus ?
Enregistrez l'état de conformité au moment du déploiement. Utilisez le balisage, la journalisation du cycle de vie et des artefacts immuables, tels que les images de conteneurs, pour créer des enregistrements qui perdurent au-delà de la durée de vie des actifs individuels. Intégrez ces données à votre SIEM et à votre CMDB afin d'assurer une conservation centralisée.
Puis-je utiliser mes outils de gestion des correctifs existants dans le cloud ?
Les logiciels traditionnels de gestion des correctifs d' , tels que , ont été conçus pour les environnements sur site ; leur compatibilité avec les charges de travail dans le cloud varie donc considérablement. Cela dépend de l'outil utilisé et du type de charge de travail. De nombreux outils traditionnels prennent en charge les machines virtuelles hébergées dans le cloud. Peu d'entre eux prennent en charge nativement les conteneurs ou les services PaaS. Vérifiez si votre solution actuelle de gestion des correctifs offre une visibilité en temps réel, prend en charge vos fournisseurs de services cloud et s'intègre à votre pipeline CI/CD.
Ressources supplémentaires sur les correctifs
Découvrez les recommandations en matière de correctifs, classées par plateforme, type de charge de travail ou domaine d'activité :
- Gestion des correctifs Windows pour les postes de travail et les serveurs d'entreprise
- Gestion des correctifs Linux pour l'ensemble des distributions et des instances hébergées dans le cloud
- Gestion des correctifs tiers pour les navigateurs, les outils et les applications d'entreprise
- Les correctifs de sécurité et leur rôle dans la réduction des vecteurs d'attaque connus
- Tout savoir sur les correctifs logiciels : mises à jour, corrections et gestion des versions
- Gestion des correctifs Mac dans les environnements informatiques d'entreprise
- Gestion des correctifs des serveurs pour les infrastructures sur site et dans le cloud
- Conception et gouvernance de la politique de gestion des correctifs
- Meilleures pratiques en matière de gestion des correctifs pour une évolutivité sécurisée
La gestion des correctifs dans le cloud n'est pas un simple prolongement de ce que vous faites déjà. Il s'agit d'un modèle de fonctionnement différent, reposant sur des hypothèses différentes, avec des limites de responsabilité différentes et des méthodes de vérification différentes. Les organisations qui réussissent abordent cela comme une refonte de leur programme : elles partent de ce qu’elles peuvent réellement observer, de l’identité des responsables de chaque charge de travail et des justificatifs dont elles auront besoin en cas de demande d’un auditeur.
Prenez rendez-vous dès aujourd’hui pour une démonstration gratuite et personnalisée afin de découvrir comment Tanium aide les équipes à gérer les correctifs dans les environnements cloud, sur site et hybrides grâce à une visibilité et un contrôle en temps réel.
