Que sont les images durcies ?
Les images durcies sont des images de VM ou de conteneurs OCI qui sont conçues sur mesure ou préconfigurées pour respecter des normes de sécurité spécifiques. Le processus de durcissement d'une image comprend la suppression des utilitaires et bibliothèques inutiles, la mise en œuvre de bases de référence de configuration, l'analyse des vulnérabilités et l'application de correctifs.
Les images durcies vous apportent la tranquillité d'esprit en garantissant que votre charge de travail respecte les meilleures pratiques de sécurité dès le départ. Vous avez l'assurance qu'une image durcie minimise votre surface d'attaque et vos vulnérabilités connues au moment de sa sortie. Les images durcies font l'objet d'analyses approfondies par rapport aux bases de données de CVE avant leur distribution, bien que de nouvelles vulnérabilités puissent apparaître au fil du temps, ce qui explique l'importance d'une analyse et d'une correction continues. Certains fournisseurs, dont Wiz, s'engagent sur des accords de niveau de service (SLA) concernant la correction des vulnérabilités dans leurs offres d'images durcies, prenant en charge la charge des correctifs afin que les clients puissent maintenir leur niveau de sécurité.
N'oubliez pas : il est plus facile de prévenir les problèmes dès le départ que de corriger les vulnérabilités une fois que les conteneurs et les machines virtuelles sont exécutés en production. C'est pourquoi les images durcies apportent des avantages tangibles : la suppression des vulnérabilités en amont réduit le bruit lié aux failles, l'exposition et le risque de violation.
Images sécurisées 101
Sécurisez votre écosystème de conteneurs grâce à cette affiche numérique facile à lire qui détaille tout ce que vous devez savoir sur la sécurité des images de conteneurs.
Types d'images durcies et où les trouver
Il existe deux types distincts d'images durcies, classés selon leur architecture et la manière dont elles interagissent avec votre environnement hôte.
Images de machines virtuelles durcies
Les images de machines virtuelles durcies sont des artefacts autonomes qui incluent l'ensemble du système d'exploitation, un noyau dédié et tous les pilotes nécessaires. Le durcissement de ces images implique de dépouiller le système d'exploitation de ses services essentiels et d'appliquer des repères de configuration stricts, tels que les CIS Benchmarks ou les STIG. Elles sont conçues pour s'exécuter sur un hyperviseur (tel que Hyper-V ou KVM) afin de fournir une isolation matérielle puissante.
Images de conteneurs durcies
Les images de conteneurs durcies sont des artefacts légers contenant uniquement l'application et ses dépendances de l'espace utilisateur ; elles partagent le noyau de l'hôte au moment de l'exécution. Le durcissement consiste ici à réduire la taille de l'image, en utilisant des images de base minimales pour éliminer les binaires inutiles. En réduisant l'image au minimum fonctionnel requis, vous réduisez la surface d'attaque. Le durcissement des images de conteneurs se concentre également sur la suppression des vulnérabilités. Les images « sécurisées » vont plus loin dans le durcissement en offrant des garanties concernant la résolution des CVE. Ces images sécurisées sont maintenues en continu à un niveau proche de zéro CVE dans le cadre de SLA garantis par un fournisseur.
Une fois que vous avez déterminé votre architecture, vous pouvez vous procurer des images auprès de plusieurs canaux :
Marchés des fournisseurs de services cloud : Toutes les plateformes cloud populaires hébergent des marchés où vous pouvez obtenir des images pré-durcies et maintenues en continu. Gardez à l'esprit que leur utilisation peut entraîner des coûts supplémentaires, facturés par heure d'utilisation de la VM ou par instance et par mois.
Mainteneurs d'images durcies privées : Des fournisseurs tels que le Center for Internet Security (images conformes aux normes CIS Benchmark) proposent des images pré-durcies provenant de registres publics ou privés.
Fournisseurs d'images sécurisées / d'images durcies gérées : Des fournisseurs tels que Wiz créent et maintiennent des images durcies avec des SLA stricts garantis par le fournisseur pour la correction des CVE. Cela va un peu plus loin que les images durcies traditionnelles en déchargeant les clients des tâches de correction et de maintenance, ce qui les aide à maintenir leur niveau de sécurité au fil du temps.
Créez la vôtre : Si vous souhaitez avoir un contrôle total sur l'ensemble du processus de durcissement, vous pouvez créer vous-même une image durcie. C'est l'option qui demande le plus de travail. Outre le processus de création, vous devrez également investir des efforts dans la maintenance de votre image durcie pour faire face à l'évolution du paysage des menaces.
Créer un pipeline d'images sécurisé de la source au déplreoiement
Voyons maintenant un flux général pour créer un pipeline d'images sécurisé. Même si vos étapes exactes dépendent du type d'image que vous créez et de l'usage auquel elle est destinée, ces conseils étape par étape vous mettront sur la voie du succès :
Développer
Rédigez vos exigences et objectifs.
Choisissez une bonne image de base—soit minimale (pour les machines virtuelles et les conteneurs), soit Distroless (conteneurs uniquement)—provenant de sources fiables et sûres. Les images Distroless ne contiennent pas de shell, de gestionnaire de paquets ou d'utilitaires courants, mais elles ne sont pas renforcées automatiquement : elles nécessitent toujours une configuration de sécurité et une analyse.
Configurez les mécanismes et outils de sécurité internes qui correspondent au framework de votre choix (par exemple, CIS Benchmarks ou DISA STIG).
Réduisez davantage la surface d'attaque à l'aide de contrôles spécifiques à l'architecture :
Pour les machines virtuelles : Configurez les pare-feu de l'hôte (
iptables, nftables) pour appliquer une politique de refus par défaut, garantissant que seuls les ports strictement nécessaires sont ouverts.Pour les conteneurs : Évitez d'alourdir les images avec des pare-feu intégrés aux conteneurs. À la place, configurez le conteneur pour qu'il s'exécute avec un système de fichiers racine en lecture seule. Il s'agit de l'un des moyens les plus efficaces pour empêcher un attaquant de télécharger des logiciels malveillants ou d'obtenir une persistance s'il obtient un accès initial.
Pour les deux : Basculer l'utilisateur par défaut vers un utilisateur non-root, supprimer les fonctionnalités Linux superflues (telles que
CAP_NET_RAW ou CAP_SYS_ADMIN), et veiller à ce que les profils de sécurité (comme AppArmor ou Seccomp) soient utilisés pour restreindre la surface d'attaque du noyau.
Gardez vos secrets en sécurité pendant cette étape ! Les coder en dur dans l'image compromet tous les efforts que vous avez investis dans le processus de durcissement jusqu'à présent.
Créer
Utiliser l'intégration et le déploiement continus (CI/CD) pour la création d'images : le durcissement automatisé réduira considérablement l'effort requis, fera gagner beaucoup de temps et fournira une source fraîche d'images bien testées.
Pour les conteneurs, utiliser des outils de création modernes et axés sur la sécurité (par exemple, BuildKit ou Buildpacks).
Pour les machines virtuelles, coder le processus de création à l'aide de Packer ou d'outils natifs du cloud (tels qu'Azure Image Builder).
S'assurer que le pipeline de création lui-même est sécurisé !
Analyser
Analyser l'image et l'ensemble de son contenu à la recherche de vulnérabilités, et remplacer les packages et bibliothèques défectueux par des versions (ou des alternatives) fiables et sûres.
Des outils tels que Trivy, Grype ou Wiz peuvent s'avérer utiles à cette étape.
De nouvelles vulnérabilités sont découvertes chaque jour — n'oubliez pas de réanalyser périodiquement les images que vous avez déjà créées pour vous assurer qu'elles restent robustes.
Ajouter la provenance
Établir l'origine de l'image, son historique de modifications et les normes qui lui sont appliquées permet de faciliter ultérieurement les contrôles de sécurité et de conformité, tout en prévenant les falsifications.
Générer un SBOM pour suivre le contenu exact de votre image de base. Les SBOM existent en différents formats — SPDX (de la Linux Foundation) et CycloneDX (d'OWASP) sont les deux normes de l'industrie. Veillez à choisir un format compatible avec le reste de votre écosystème de sécurité, de conformité et de protection de la chaîne d'approvisionnement.
Signer l'image pour permettre des contrôles d'intégrité ultérieurs. Vous pouvez signer des images avec des solutions telles que Sigstore Cosign, Notary ou Docker Content Trust. Des services natifs du cloud tels qu'AWS Signer peuvent également s'avérer utiles. Voici un exemple : à l'aide de Cosign, vous pouvez signer une image de conteneur avec une seule commande :
cosign sign --key <private key> <image>. Cette signature pourra être vérifiée ultérieurement aveccosign verify --key <clé publique> <image>.Attester l'image en produisant des déclarations signées cryptographiquement (à l'aide de la provenance SLSA ou d'attestations in-toto) concernant l'origine du build, le contenu de la SBOM et les résultats des analyses de sécurité. Ces attestations signées permettent aux consommateurs en aval de vérifier que l'image n'a pas été altérée et qu'elle respecte les politiques de sécurité.
Vérifier
Dans cette étape, vous allez faire le point sur tout le travail accompli.
Valider l'image par rapport aux benchmarks de votre choix. Analysez vos scans, justifiez les éventuelles exemptions et rendez compte du résultat final.
Tester si l'image fonctionne comme prévu. Certaines mesures de sécurité, en particulier les plus strictes, peuvent causer des dysfonctionnements. Par exemple, une minoration très poussée pourrait supprimer des bibliothèques dont vous avez réellement besoin. L'étape de vérification est votre dernière chance de vous assurer que tout est en ordre de marche avant le déploiement de votre image.
Promouvoir et déployer
L'image est prête. Elle peut désormais intégrer vos environnements, après avoir passé les vérifications finales, bien entendu.
Configurer les portes de promotion (« promotion gates ») pour n'autoriser que les images qui atteignent les seuils de politique requis — par exemple, l'absence de CVE critiques ou de sévérité élevée disposant de correctifs, l'obligation de signatures et d'attestations d'images, et la conformité aux benchmarks CIS. Définir des flux de travail d'acceptation des risques pour les vulnérabilités sans correctif.
Mettre en place un contrôle d'admission à l'aide d'OPA Gatekeeper, Kyverno ou de la fonctionnalité Pod Security Admission (PSA) de Kubernetes pour n'accepter comme candidats au déploiement que les images de conteneurs signées, attestées, testées et conformes. Par exemple, une politique Kyverno peut vérifier les signatures Cosign et bloquer les images non signées au moment du déploiement.
Les équipes de sécurité ont souvent du mal à gérer des outils fragmentés — un scanner pour la CI, un autre pour les registres, un troisième pour l'exécution — chacun ayant ses propres politiques et seuils. Envisagez plutôt de déployer un moteur de politique unique. Visez une politique unique tout au long du flux de travail : du développement, en passant par la CI et la promotion dans les environnements, jusqu'à l'admission. Ainsi, vous maintenez une posture de sécurité uniforme, cohérente et robuste, sans la fragmentation inutile des outils et la surcharge qu'elle entraîne.
Regarder la démo de 12 min
Wiz identifie les conteneurs exposés, visualise l'ensemble du chemin d'attaque et corrige le problème directement dans le code.
Pièges courants de durcissement qui perturbent les opérations cloud
Configurations non sécurisées
L'un des aspects les plus importants du durcissement ? Une configuration sécurisée. Les problèmes d'images proviennent fréquemment d'erreurs simples. Nous parlons de configurations de pare-feu trop permissives laissées en l'état, d'outils de sécurité intégrés qui sont désactivés et de mauvaises configurations SELinux/AppArmor/seccomp sur l'hôte de la machine virtuelle ou du conteneur. Malheureusement, ces erreurs affectent gravement la fiabilité de l'image obtenue.
Dépendances et ajouts
Les images durcies sont conçues pour être sûres dès leur obtention, mais cela ne signifie pas qu'elles le resteront toujours. Si vous utilisez une image durcie comme image de base pour votre application, ses dépendances et son processus de construction peuvent introduire (ou réintroduire) des vulnérabilités. Lorsque vous ajoutez quoi que ce soit à une image durcie, quelle qu'en soit la forme ou la manière, vous devez la scanner à nouveau.
Erreurs de configuration à l'exécution
Des erreurs de configuration à l'exécution, telles qu'un accès surprivilégié ou l'omission de mises à jour logicielles et de correctifs critiques, rendront vulnérable même une image pourtant bien durcie. C'est particulièrement vrai pour les conteneurs ; les exécuter en mode privilégié, utiliser l'utilisateur root à l'intérieur du conteneur, leur attribuer des capacités du noyau excessives ou des droits d'écriture sur le système de fichiers racine peut constituer exactement le levier dont un acteur malveillant a besoin pour une évasion de conteneur.
Tenter d'éliminer tous ces pièges sans un contexte approfondi et spécifique (par exemple, exposition à Internet + conteneur privilégié + données sensibles), ne fera qu'amener votre équipe à courir après de faux signaux. Privilégiez plutôt une approche par graphe de risques pour prioriser ce qui compte vraiment et déployer des correctifs ciblés et précis.
Feuille de route étape par étape pour la mise en œuvre d'images durcies
Si vous souhaitez anticiper la sécurité (et croyez-nous, c'est le cas), mettez en place des images durcies dès le tout début de votre projet. Voici comment :
Sélectionnez les normes et politiques qui conviennent le mieux à votre organisation. Si vous avez un doute, les CIS Benchmarks constituent un excellent point de départ.
Identifiez les charges de travail qui nécessitent un durcissement et attribuez des priorités. Certaines charges de travail sont plus importantes que d'autres, choisissez donc soigneusement celles qui méritent le plus votre attention. Vous pourrez vous occuper du reste plus tard.
Déterminez l'approche de correction appropriée. Souhaitez-vous créer vous-même une image, utiliser une image de base et y ajouter l'application, ou opter pour une solution entièrement pré-construite ?
Intégrez les images de votre choix dans vos flux de travail. Ajustez vos pipelines CI/CD pour qu'ils jouent un rôle clé dans le processus : par exemple, configurez des analyses périodiques ou des builds automatiques lorsqu'un correctif est publié.
Surveillez votre environnement et maintenez le standard de référence — examinez périodiquement votre posture de sécurité, surveillez en continu l'apparition de nouvelles vulnérabilités et réévaluez la qualité de vos images pour les garder propres et sûres.
Visez une traçabilité bidirectionnelle : lorsqu'un problème est détecté dans le cloud, vous devez être capable de remonter sans effort à l'image de base et au pipeline qui l'ont produit ; lors de la correction de failles dans le code/le build, validez la dérive dans le cloud concerné. La collecte automatique de contexte supplémentaire réduit le délai moyen de correction (MTTR) de plusieurs jours à quelques heures en éliminant les investigations manuelles et les transferts de tickets. Voici le contexte que vous souhaiterez collecter :
Ressource cloud : tâche ECS, pod Kubernetes, instance de VM
Image de conteneur : registre, tag, condensé (digest), horodatage de build
Pipeline CI/CD : tâche Jenkins, workflow GitHub Actions, pipeline GitLab
Code source : dépôt, Dockerfile, SHA du commit, auteur
Propriétaire : canal Slack de l'équipe, rotation d'astreinte, projet JIRA
Comment Wiz identifie et priorise les opportunités d'images durcies
Obtenir des images durcies n'est que le début d'un long parcours pour protéger votre organisation. Heureusement, vous n'êtes pas obligé de traverser toutes les étapes, les obstacles et la lutte constante pour la sécurité tout seul. Il existe une méthode meilleure et plus simple : Wiz.
Les images WizOS fournissent une base sécurisée et prête pour la production pour les applications conteneurisées, offrant des images renforcées et minimales avec un profil CVE presque nul. Chaque version est signée et inclut un SBOM pour garantir la provenance. Les images sont gérées en continu par Wiz dans le cadre d'un SLA, ce qui décharge vos développeurs de la charge de remédiation.
Le graphe de sécurité Wiz met en corrélation les CVE des images avec l'exposition réseau, les identités et la sensibilité des données, vous aidant à repérer les images non sécurisées en un coup d'œil et à prioriser les corrections les plus urgentes. La traçabilité bidirectionnelle du code au cloud fournit tout ce dont votre équipe a besoin pour déterminer quel service construit l'image, qui en est propriétaire et comment les politiques sont appliquées avant son déploiement.
L'inventaire des images de conteneurs de Wiz garantit que chaque image de l'ensemble de votre code, de votre cloud et de vos registres sera prise en compte. Les équipes peuvent identifier rapidement les images les plus vulnérables et les prioriser pour la migration vers une alternative renforcée comme WizOS.
Prêt à en savoir plus ? Inscrivez-vous à une démo pour voir par vous-même comment Wiz peut protéger tout ce que vous construisez et exécutez dans le cloud !
Obtenir une démonstration de la sécurité des conteneurs
Découvrez comment Wiz analyse vos conteneurs à la recherche de vulnérabilités et comment les images de base WizOS peuvent réduire votre nombre de CVE à presque zéro.
