View a markdown version of this page

Sélection des correctifs de sécurité - AWS Systems Manager

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sélection des correctifs de sécurité

L'objectif principal de Patch Manager concerne l'installation de mises à jour relatives à la sécurité des systèmes d'exploitation sur les nœuds gérés. Par défaut, Patch Manager n'installe pas tous les correctifs disponibles, mais plutôt un plus petit ensemble de correctifs axé sur la sécurité.

Par défaut, Patch Manager ne remplace pas un package marqué comme obsolète dans un référentiel de packages par des packages de remplacement portant un nom différent, sauf si ce remplacement est requis par l’installation d’une autre mise à jour de package. À la place, pour les commandes qui mettent à jour un package, Patch Manager signale et installe seulement les mises à jour manquantes pour le package installé, mais obsolète. Cela est dû au fait que le remplacement d’un package obsolète nécessite généralement la désinstallation d’un package existant et l’installation de son remplacement. Le remplacement du package obsolète peut introduire des modifications majeures ou des fonctionnalités supplémentaires que vous n’aviez pas prévues.

Ce comportement est conforme à la commande update-minimal de YUM et DNF, qui met l’accent sur les mises à jour de sécurité plutôt que sur les mises à niveau des fonctionnalités. Pour plus d’informations, consultez Installation des correctifs.

Note

Lorsque vous utilisez ApproveUntilDate paramètre ou ApproveAfterDays paramètre dans une règle de base de correctif, Patch Manager évalue les dates de publication des correctifs en utilisant le temps universel coordonné (UTC).

Par exemple, pour ApproveUntilDate, si vous spécifiez une date telle que 2025-11-16, patchs publiés entre 2025-11-16T00:00:00Z et 2025-11-16T23:59:59Z sera approuvé.

Sachez que les dates de publication des correctifs affichées par les gestionnaires de packages natifs sur vos nœuds gérés peuvent être différentes en fonction du fuseau horaire local de votre système, mais Patch Manager utilise toujours la date/heure UTC pour les calculs d'approbation. Cela garantit la cohérence avec les dates de sortie des correctifs publiées sur les sites Web officiels d'avis de sécurité.

Pour Linux-based les types de systèmes d'exploitation qui indiquent un niveau de gravité pour les correctifs, Patch Manager utilise le niveau de gravité indiqué par l'éditeur du logiciel pour l'avis de mise à jour ou le correctif individuel. Patch Manager ne calcule pas de niveaux de gravité à partir de sources tierces, telles que le Système commun de notation des vulnérabilités (CVSS), ou à partir de métriques publiées par le Base de données nationale sur les vulnérabilités (NVD.).

Note

Sur tous Linux-based systèmes pris en charge par Patch Manager, vous pouvez choisir un référentiel source différent configuré pour le nœud géré, généralement pour installer des mises à jour non liées à la sécurité. Pour plus d’informations, consultez Spécification d'un autre référentiel source de correctifs (Linux).

Sélectionnez parmi les onglets suivants pour en savoir plus sur la manière dont Patch Manager sélectionne les correctifs de sécurité pour votre système d'exploitation.

Amazon Linux 2 and Amazon Linux 2023

La gestion des référentiels préconfigurés sur Amazon Linux 2 est différente de celle d’Amazon Linux 2023.

Sur Amazon Linux 2, le service de référentiel de correctifs Systems Manager utilise des référentiels préconfigurés sur le nœud géré. Un nœud comporte généralement deux référentiels préconfigurés :

Sur Amazon Linux 2

  • ID de référentiel : amzn2-core/2/architecture

    Nom de référentiel : Amazon Linux 2 core repository

  • ID de référentiel : amzn2extra-docker/2/architecture

    Nom de référentiel : Amazon Extras repo for docker

Note

architecture peut être x86_64 ou (pour les processeurs Graviton) aarch64.

Lorsque vous créez une instance Amazon Linux 2023 (AL2023), celle-ci contient les mises à jour disponibles dans la version d’AL2023 et les AMI spécifiques sélectionnées. Votre instance AL2023 ne reçoit pas automatiquement de mises à jour de sécurité critiques et importantes supplémentaires au moment du lancement. Au lieu de cela, grâce à la fonctionnalité de mises à niveau déterministes via des référentiels versionnés prise en charge pour AL2023, qui est activée par défaut, vous pouvez appliquer des mises à jour selon un calendrier qui répond à vos besoins spécifiques. Pour plus d'informations, veuillez consulter la rubrique Mises à niveau déterministes via des référentiels versionnés dans le Guide de l'utilisateur Amazon Linux 2023.

Sur AL2023, le référentiel préconfiguré est le suivant :

  • ID de référentiel : amazonlinux

    Nom du référentiel : référentiel Amazon Linux 2023

Sur Amazon Linux 2023 (version préliminaire), les référentiels préconfigurés sont liés à versions verrouillées des mises à jour des packages. Lorsque de nouvelles Amazon Machine Images (AMIs) pour AL2023 sont publiées, elles sont verrouillées pour une version spécifique. Pour les mises à jour des correctifs, Patch Manager récupère la dernière version verrouillée du référentiel de mises à jour des correctifs, puis met à jour les packages sur le nœud géré en fonction du contenu de cette version verrouillée.

Gestionnaires de package.

Les nœuds gérés Amazon Linux 2 utilisent Yum comme gestionnaire de packages. Amazon Linux 2023 utilise DNF comme gestionnaire de packages.

Les deux gestionnaires de packages utilisent le concept d'un avis de mise à jour comme fichier nommé updateinfo.xml. Une notice de mise à jour est simplement un ensemble de packages qui corrigent des problèmes spécifiques. Tous les packages qui sont inclus dans une notice de mise à jour sont considérés comme des correctifs de sécurité par Patch Manager. Les packages ne se voient pas attribuer des classifications ou des niveaux de sévérité. Pour cette raison, Patch Manager affecte les attributs d'une notice de mise à jour aux packages associés.

Note

Si vous cochez la case Inclusion de mises à jour non liées à la sécurité sur la page Créer une référence de correctif, les packages qui ne sont pas classifiées dans un fichier updateinfo.xml (ou un package contenant un fichier sans valeurs Classification, Gravité et Date correctement formatées) peuvent être inclus dans la liste des correctifs préfiltrée. Toutefois, pour qu'un correctif soit appliqué, il doit toujours respecter les règles de base des correctifs spécifiées par l'utilisateur.

Pour plus d’informations sur l’option Inclusion de mises à jour non liées à la sécurité, consultez Installation des correctifs et Comment fonctionnent les règles de base relatives aux correctifs Linux-based systèmes.

CentOS Stream

Sous CentOS Stream, le service de référentiel de correctifs Systems Manager utilise des référentiels préconfigurés sur le nœud géré. La liste suivante fournit des exemples d'un CentOS 9.2 fictif Amazon Machine Image (AMI) :

  • ID de référentiel : example-centos-9.2-base

    Nom de référentiel : Example CentOS-9.2 - Base

  • ID de référentiel : example-centos-9.2-extras

    Nom de référentiel : Example CentOS-9.2 - Extras

  • ID de référentiel : example-centos-9.2-updates

    Nom de référentiel : Example CentOS-9.2 - Updates

  • ID de référentiel : example-centos-9.x-examplerepo

    Nom de référentiel : Example CentOS-9.x – Example Repo Packages

Note

Toutes les mises à jour sont téléchargées à partir des référentiels distants configurés sur le nœud géré. Par conséquent, le nœud doit disposer d'un accès sortant à Internet pour se connecter aux dépôts afin que le correctif puisse être effectué.

Les nœuds CentOS Stream, quant à eux, utilisent DNF comme gestionnaire de package. Le gestionnaire de package utilise le concept d’un avis de mise à jour. Une notice de mise à jour est simplement un ensemble de packages qui corrigent des problèmes spécifiques.

Toutefois, les référentiels CentOS Stream par défaut ne sont pas configurés avec une notice de mise à jour. Cela signifie que Patch Manager ne détecte pas les packages sur les référentiels CentOS Stream par défaut. Pour permettre au Patch Manager de traiter des packages qui ne sont pas contenus dans une notice de mise à jour, vous devez activer l'indicateur EnableNonSecurity dans les règles de référentiel de correctifs.

Note

Les avis de mise à jour CentOS Stream sont pris en charge. Les référentiels avec des notices de mise à jour peuvent être téléchargés après le lancement.

Debian Server

Sur Debian Server, le service de référentiel de correctifs Systems Manager utilise des référentiels (repos) préconfigurés sur l'instance. Ces référentiels préconfigurés sont utilisés pour extraire une liste mise à jour des mises à niveau de package disponibles. Pour cela, Systems Manager exécute l'équivalent d'une commande sudo apt-get update.

Les packages sont ensuite filtrés à partir du référentiel debian-security codename. Cela signifie que sur chaque version de Debian Server, Patch Manager identifie uniquement les mises à niveau qui font partie du repo associé pour cette version, comme suit :

  • Debian Server 11 : debian-security bullseye

  • Debian Server 12 : debian-security bookworm

Oracle Linux

Sous Oracle Linux, le service de référentiel de correctifs Systems Manager utilise des référentiels préconfigurés sur le nœud géré. Un nœud comporte généralement deux référentiels préconfigurés :

Oracle Linux 7 :

  • ID de référentiel : ol7_UEKR5/x86_64

    Nom de référentiel : Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)

  • ID de référentiel : ol7_latest/x86_64

    Nom de référentiel : Oracle Linux 7Server Latest (x86_64)

Oracle Linux 8 :

  • ID de référentiel : ol8_baseos_latest

    Nom de référentiel : Oracle Linux 8 BaseOS Latest (x86_64)

  • ID de référentiel : ol8_appstream

    Nom de référentiel : Oracle Linux 8 Application Stream (x86_64)

  • ID de référentiel : ol8_UEKR6

    Nom de référentiel : Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)

Oracle Linux 9 :

  • ID de référentiel : ol9_baseos_latest

    Nom de référentiel : Oracle Linux 9 BaseOS Latest (x86_64)

  • ID de référentiel : ol9_appstream

    Nom de référentiel : Oracle Linux 9 Application Stream Packages(x86_64)

  • ID de référentiel : ol9_UEKR7

    Nom de référentiel : Oracle Linux UEK Release 7 (x86_64)

Note

Toutes les mises à jour sont téléchargées à partir des référentiels distants configurés sur le nœud géré. Par conséquent, le nœud doit disposer d'un accès sortant à Internet pour se connecter aux dépôts afin que le correctif puisse être effectué.

Les nœuds gérés Oracle Linux utilisent Yum comme gestionnaire de package, tandis que Yum utilise le concept d'avis de mise à jour sous la forme d'un fichier nommé updateinfo.xml. Une notice de mise à jour est simplement un ensemble de packages qui corrigent des problèmes spécifiques. Les packages ne se voient pas attribuer des classifications ou des niveaux de sévérité. C'est la raison pour laquelle Patch Manager affecte les attributs d'une notice de mise à jour aux packages associés et installe les packages en fonction des filtres de classification spécifiés dans le référentiel de correctif.

Note

Si vous cochez la case Inclusion de mises à jour non liées à la sécurité sur la page Créer une référence de correctif, les packages qui ne sont pas classifiées dans un fichier updateinfo.xml (ou un package contenant un fichier sans valeurs Classification, Gravité et Date correctement formatées) peuvent être inclus dans la liste des correctifs préfiltrée. Toutefois, pour qu'un correctif soit appliqué, il doit toujours respecter les règles de base des correctifs spécifiées par l'utilisateur.

AlmaLinux, RHEL, and Rocky Linux

Sur AlmaLinux, Red Hat Enterprise Linux, et Rocky Linux le service de base des correctifs de Systems Manager utilise des référentiels préconfigurés (dépôts) sur le nœud géré. Un nœud comporte généralement trois référentiels préconfigurés :

Toutes les mises à jour sont téléchargées à partir des référentiels distants configurés sur le nœud géré. Par conséquent, le nœud doit disposer d'un accès sortant à Internet pour se connecter aux dépôts afin que le correctif puisse être effectué.

Note

Si vous cochez la case Inclusion de mises à jour non liées à la sécurité sur la page Créer une référence de correctif, les packages qui ne sont pas classifiées dans un fichier updateinfo.xml (ou un package contenant un fichier sans valeurs Classification, Gravité et Date correctement formatées) peuvent être inclus dans la liste des correctifs préfiltrée. Toutefois, pour qu'un correctif soit appliqué, il doit toujours respecter les règles de base des correctifs spécifiées par l'utilisateur.

Red Hat Enterprise Linux 7 nœuds gérés utilisent Yum comme gestionnaire de packages. AlmaLinux, Red Hat Enterprise Linux 8, et Rocky Linux les nœuds gérés utilisent DNF comme gestionnaire de packages. Les deux gestionnaires de packages utilisent le concept d'un avis de mise à jour comme fichier nommé updateinfo.xml. Une notice de mise à jour est simplement un ensemble de packages qui corrigent des problèmes spécifiques. Les packages ne se voient pas attribuer des classifications ou des niveaux de sévérité. C'est la raison pour laquelle Patch Manager affecte les attributs d'une notice de mise à jour aux packages associés et installe les packages en fonction des filtres de classification spécifiés dans le référentiel de correctif.

Note

Sur AlmaLinux et Rocky Linux, les dépôts peuvent ne pas conserver les anciennes versions d'un package une fois qu'une nouvelle version portant le même nom de package est publiée. Si un avis de mise à jour fait référence à une version qui n'est plus disponible dans le référentiel, Patch Manager évalue l'installation de la nouvelle version à l'aide des métadonnées consultatives publiées pour la version qui n'est plus disponible. Cela garantit que les correctifs en attente sont appliqués lorsque la version non disponible ne se trouve plus dans le référentiel.

Cela peut conduire Patch Manager pour installer les nouvelles versions du package même si l'avis associé a été publié après la configuration ApproveUntilDate ou ApproveAfterDays.

RHEL 7
Note

Les ID de référentiels suivants sont associés à RHUI 2. RHUI 3 a été lancé en décembre 2019 et a introduit un schéma de d'attribution de noms différent pour les ID de référentiel Yum. En fonction de RHEL-7 AMI à partir de laquelle vous créez vos nœuds gérés, vous devrez peut-être mettre à jour vos commandes. Pour plus d'informations, voir ID de référentiel pour RHEL 7 pouces AWS Ont changé sur le Portail client Red Hat.

  • ID de référentiel : rhui-REGION-client-config-server-7/x86_64

    Nom de référentiel : Red Hat Update Infrastructure 2.0 Client Configuration Server 7

  • ID de référentiel : rhui-REGION-rhel-server-releases/7Server/x86_64

    Nom de référentiel : Red Hat Enterprise Linux Server 7 (RPMs)

  • ID de référentiel : rhui-REGION-rhel-server-rh-common/7Server/x86_64

    Nom de référentiel : Red Hat Enterprise Linux Server 7 RH Common (RPMs)

AlmaLinux, 8 RHEL 8, et Rocky Linux 8

  • ID de référentiel : rhel-8-appstream-rhui-rpms

    Nom de référentiel : Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)

  • ID de référentiel : rhel-8-baseos-rhui-rpms

    Nom de référentiel : Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)

  • ID de référentiel : rhui-client-config-server-8

    Nom de référentiel : Red Hat Update Infrastructure 3 Client Configuration Server 8

AlmaLinux 9, RHEL 9, et Rocky Linux 9

  • ID de référentiel : rhel-9-appstream-rhui-rpms

    Nom de référentiel : Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)

  • ID de référentiel : rhel-9-baseos-rhui-rpms

    Nom de référentiel : Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)

  • ID de référentiel : rhui-client-config-server-9

    Nom de référentiel : Red Hat Enterprise Linux 9 Client Configuration

SLES

Sur les nœuds gérés SUSE Linux Enterprise Server (SLES), la bibliothèque ZYPP obtient la liste des correctifs disponibles (un ensemble de packages) à partir des emplacements suivants :

  • Liste de référentiels : etc/zypp/repos.d/*

  • Informations sur les packages : /var/cache/zypp/raw/*

Les nœuds gérés SLES utilisent Zypper comme gestionnaire de package, tandis que Zypper utilise le concept de correctif. Un correctif est tout simplement un ensemble de packages qui corrigent un problème spécifique. Patch Manager gère tous les packages référencés dans un correctif comme étant liés à la sécurité. Étant donné que les différents packages ne sont associés à aucune classification ou sévérité, Patch Manager leur affecte les attributs du correctif auquel ils appartiennent.

Ubuntu Server

Sous Ubuntu Server, le service de référentiel de correctifs Systems Manager utilise des référentiels préconfigurés sur le nœud géré. Ces référentiels préconfigurés sont utilisés pour extraire une liste mise à jour des mises à niveau de package disponibles. Pour cela, Systems Manager exécute l'équivalent d'une commande sudo apt-get update.

Les packages sont ensuite filtrés à partir de codename-security dépôts, où le nom de code est unique à la version finale, tel que plucky pour Ubuntu Server 25,04. Patch Manager identifie uniquement les mises à niveau qui font partie de ces dépôts :

  • Ubuntu Server 18.04 LTS : bionic-security

  • Ubuntu Server 20.04 LTS : focal-security

  • Ubuntu Server 22.04 LTS : jammy-security

  • Ubuntu Server 24,04 LITRES : noble-security

  • Ubuntu Server 25,04 : plucky-security

  • Ubuntu Server 26,04 LITRES : resolute-security

Windows Server

Sur les systèmes d'exploitation Microsoft Windows, Patch Manager récupère une liste des mises à jour disponibles que Microsoft publie dans Microsoft Update et sont automatiquement disponibles pour Windows Server Update Services (WSUS).

Note

Patch Manager ne met à disposition que les correctifs destinés aux versions du système d'exploitation Windows Server prises en charge par Patch Manager. Par exemple, Patch Manager ne peut pas être utilisé pour appliquer un correctif à Windows RT.

Patch Manager surveille en permanence les nouvelles mises à jour dans chaque Région AWS. La liste des mises à jour disponibles est actualisée dans chaque région au moins une fois par jour. Lorsque les informations de correctif provenant de Microsoft sont traitées, Patch Manager supprime de la liste des correctifs les mises à jour qui ont été remplacés par des mises à jour ultérieures. Par conséquent, seule la mise à jour la plus récente est affichée et disponible pour être installée. Par exemple, si KB4012214 remplace KB3135456, seule KB4012214 est disponible en tant que mise à jour dans Patch Manager.

De même, Patch Manager ne peut installer que les correctifs disponibles sur le nœud géré au moment de l’application de correctifs. Par défaut, Windows Server 2019 et Windows Server 2022 suppriment les mises à jour qui sont remplacées par des mises à jour ultérieures. Par conséquent, si vous utilisez le paramètre ApproveUntilDate dans un référentiel de correctifs Windows Server, mais que la date sélectionnée dans le paramètre ApproveUntilDate est antérieure à la date du dernier correctif, le scénario suivant se produit :

  • Le correctif remplacé est supprimé du nœud et ne peut donc pas être installé à l’aide de Patch Manager.

  • Le dernier correctif de remplacement est présent sur le nœud, mais son installation n’a pas encore été approuvée à la date spécifiée dans le paramètre ApproveUntilDate.

Les correctifs remplacés peuvent créer une lacune en matière de conformité

Votre nœud géré peut être déclaré conforme aux opérations de Systems Manager même si aucun correctif critique du mois précédent n'est installé. Ce scénario peut également se produire avec ApproveAfterDays paramètre.

En raison du comportement des correctifs remplacés de Microsoft, vous pouvez définir ApproveAfterDays à une valeur (généralement supérieure à 30) afin que les patchs pour Windows Server ne sont jamais installés si Microsoft publie le dernier correctif avant que ce nombre de jours ne soit écoulé. Dans ce cas, votre nœud géré peut être déclaré conforme même si aucun correctif de sécurité critique n'est installé.

Par exemple, définissez ApproveAfterDays jusqu'à 45 ans. Si Microsoft publie un correctif de remplacement le 30e jour, le système supprime le correctif d'origine. Le nouveau correctif n'est approuvé qu'au 45e jour, laissant une fenêtre de 15 jours pendant laquelle aucun correctif n'est installé.

Ce comportement ne s'applique pas si vous avez modifié les paramètres de votre objet de stratégie de groupe (GPO) Windows pour rendre le correctif remplacé disponible sur vos nœuds gérés.

Note

Dans certains cas, Microsoft publie des correctifs pour des applications qui ne précisent pas de date et d’heure de mise à jour. La date et l'heure 01/01/1970 sont alors fournies par défaut.