Installation des correctifs - 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.

Installation des correctifs

Patch Manager, un outil dans AWS Systems Manager, utilise le mécanisme intégré approprié à un type de système d'exploitation pour installer les mises à jour sur un nœud géré. Par exemple, sous Windows Server, l’API Windows Update est utilisée, et sous Amazon Linux 2, le gestionnaire de package yum est utilisé.

Patch Managern'installe pas de nouveau package qui remplace un package obsolète actuellement installé. (Exceptions : le nouveau package dépend d'une autre mise à jour de package en cours d'installation, ou le nouveau package porte le même nom que le package obsolète.) Au lieu de cela, Patch Manager signale et installe les mises à jour disponibles pour les packages installés. Cette approche permet d'éviter des modifications inattendues des fonctionnalités de votre système susceptibles de se produire lorsqu'un package en remplace un autre.

Si vous devez désinstaller un package devenu obsolète et installer son remplacement, vous devrez peut-être utiliser un script personnalisé ou utiliser les commandes du gestionnaire de packages en dehors des Patch Manager opérations standard.

Sélectionnez parmi les onglets suivants pour en savoir plus sur la manière dont Patch Manager installe les correctifs sur un système d'exploitation.

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

Sur les nœuds gérés Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 et Amazon Linux 2023, le flux d’installation des correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de type chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  3. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

  4. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  5. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  6. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  7. L’API de mise à jour YUM (Amazon Linux 1, Amazon Linux 2) ou l’API de mise à jour DNF (Amazon Linux 2022, Amazon Linux 2023) est appliquée aux correctifs approuvés comme suit :

    • Pour les référentiels de correctifs par défaut prédéfinis fournis par AWS, seuls les correctifs spécifiés dans updateinfo.xml sont appliqués (mises à jour de sécurité uniquement). Cela est dû au fait que la case Inclusion de mises à jour non liées à la sécurité n’est pas cochée. Les références prédéfinies sont équivalentes à une référence personnalisée avec les éléments suivants :

      • La case Inclusion de mises à jour non liées à la sécurité n’est pas cochée.

      • Une liste de GRAVITÉ [Critical, Important]

      • Une liste de CLASSIFICATION [Security, Bugfix]

      Pour Amazon Linux 1 et Amazon Linux 2, la commande yum équivalente pour ce flux de travail est :

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      Pour Amazon Linux 2022 et Amazon Linux 2023, la commande dnf équivalente pour ce flux de travail est :

      sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

      Si la case Inclusion de mises à jour non liées à la sécurité est cochée, les correctifs figurant dans updateinfo.xml et ceux ne figurant pas dans updateinfo.xml sont appliqués (mises à jour de sécurité et non liées à la sécurité).

      Pour Amazon Linux 1 et Amazon Linux 2, si une référence avec Inclusion de mises à jour non liées à la sécurité est sélectionnée, comportant une liste de GRAVITÉ [Critical, Important] et une liste de CLASSIFICATION [Security, Bugfix], la commande yum équivalente est la suivante :

      sudo yum update --security --sec-severity=Critical,Important --bugfix -y

      Pour Amazon Linux 2022 et Amazon Linux 2023, la commande dnf équivalente est :

      sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
      Note

      Les nouveaux packages qui remplacent les packages désormais obsolètes portant des noms différents sont installés si vous les exécutez yum ou si vous exécutez des dnf commandes en dehors de. Patch Manager Cependant, ils ne sont pas installés par des Patch Manager opérations équivalentes.

      Informations supplémentaires sur les correctifs pour Amazon Linux 2022 et Amazon Linux 2023
      Support pour le niveau de gravité « Aucun »

      Amazon Linux 2022 et Amazon Linux 2023 prennent également en charge le niveau de sévérité des correctifs None, qui est reconnu par le gestionnaire de packages DNF.

      Support pour le niveau de gravité « moyen »

      Pour Amazon Linux 2022 et Amazon Linux 2023, un niveau de sévérité des correctifs Medium équivaut à un niveau de sévérité Moderate pouvant être défini dans certains référentiels externes. Si vous incluez des correctifs de gravité Medium dans le référentiel de correctifs, des correctifs de gravité Moderate provenant de correctifs externes sont également installés sur les instances.

      Lorsque vous recherchez des données de conformité à l'aide de l'action d'API DescribeInstancePatches, le filtrage selon le niveau de gravité Medium signale les correctifs dont les niveaux de gravité sont à la fois Medium et Moderate.

      Gestion des dépendances transitives pour Amazon Linux 2022 et Amazon Linux 2023

      Pour Amazon Linux 2022 et Amazon Linux 2023, Patch Manager vous pouvez installer des versions de dépendances transitives différentes de celles installées par les dnf commandes équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences des autres packages (dépendances des dépendances).

      Par exemple, dnf upgrade-minimal --security installe les versions minimales des dépendances transitives nécessaires pour résoudre les problèmes de sécurité connus, tout en Patch Manager installant les dernières versions disponibles des mêmes dépendances transitives.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

CentOS and CentOS Stream

Sur CentOS et CentOS Stream les noeuds gérés, le flux d'installation des correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de type chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

    Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  2. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

  3. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  4. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  5. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  6. L'API de mise à jour YUM (sur les versions CentOS 6.x and 7.x) ou la mise à jour DNF (sur CentOS 8 et CentOS Stream) applicable aux correctifs approuvés.

    Note

    Pour CentOS, Patch Manager vous pouvez installer des versions de dépendances transitives différentes de celles installées par les commandes équivalentesdnf. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences des autres packages (dépendances des dépendances).

    Par exemple, dnf upgrade-minimal --security installe les versions minimales des dépendances transitives nécessaires pour résoudre les problèmes de sécurité connus, tout en Patch Manager installant les dernières versions disponibles des mêmes dépendances transitives.

  7. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

Debian Server and Raspberry Pi OS

Sur les instances Debian Server et Raspberry Pi OS (anciennement Raspbian), le flux d'installation de correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de style chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Si une mise à jour est disponible pour python3-apt (une interface de bibliothèque Python pour libapt), la mise à niveau est faite à la dernière version. (Ce package non lié à la sécurité est mis à niveau même si vous n'avez pas sélectionné l'option Inclure les mises à jour non liées à la sécurité.)

    Important

    Sous Debian Server 8 uniquement : dans la mesure où certains nœuds gérés de Debian Server 8.* font référence à un référentiel de packages obsolète (jessie-backports), Patch Manager applique des étapes supplémentaires suivantes pour s'assurer du succès des opérations d'application de correctifs :

    1. Sur votre nœud géré, la référence au référentiel jessie-backports est commentée à partir de la liste des emplacements sources (/etc/apt/sources.list.d/jessie-backports). Par conséquent, aucune tentative n'est effectuée pour télécharger des correctifs à partir de cet emplacement.

    2. Une clé de signature de mise à jour de sécurité Stretch est importée. Cette clé fournit les autorisations nécessaires pour les opérations de mise à jour et d'installation sur les distributions Debian Server 8.*.

    3. L'opération apt-get est exécutée à ce moment précis pour s'assurer que la dernière version de python3-apt est installée avant le début du processus d'application des correctifs.

    4. Une fois le processus d'installation terminé, la référence au référentiel jessie-backports est restaurée et la clé de signature est supprimée du porte-clés source apt. Ainsi, la configuration du système demeure telle qu'elle était avant l'opération d'application de correctifs.

    Lorsque Patch Manager met à jour à nouveau le système, le même processus est répété.

  3. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  4. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Note

    Dans la mesure où il n'est pas possible de déterminer de manière fiable les dates de publication des packages de mise à jour pour Debian Server, les options d'approbation automatique ne sont pas prises en charge pour ce système d'exploitation.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

    Note

    Pour Debian Server et Raspberry Pi OS, les versions de correctifs candidates se limitent aux correctifs inclus dans debian-security.

  5. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  6. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  7. La bibliothèque APT permet de mettre à niveau les packages.

    Note

    Patch Manager ne prend pas en charge l’utilisation de l’option APT Pin-Priority pour attribuer des priorités aux packages. La commande Patch Manager regroupe les mises à jour disponibles à partir de tous les dépôts activés et sélectionne la mise à jour la plus récente qui correspond à la référence pour chaque package installé.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

macOS

Sur les nœuds gérés macOS, le flux d'installation des correctifs est le suivant :

  1. La liste de propriétés /Library/Receipts/InstallHistory.plist est un registre des logiciels qui ont été installés et mis à niveau à l'aide des gestionnaires de package softwareupdate et installer. La liste est analysée avec l'outil de ligne de commande pkgutil (pourinstaller) et les commandes CLI du gestionnaire de packages softwareupdate.

    Pour installer, la réponse aux commandes CLI comprend les détails package name, version, volume, location et install-time, mais Patch Manager utilise seulement le package name et la version.

    Pour softwareupdate, la réponse aux commandes CLI comprend le nom du package (display name), la version et la date, mais Patch Manager utilise seulement le nom du package et la version.

    Pour Brew et Brew Cask, Homebrew ne prend pas en charge les commandes qui s'exécutent sous l'utilisateur racine. Par conséquent, Patch Manager interroge et exécute les commandes Homebrew en tant que le propriétaire du répertoire Homebrew ou l'utilisateur valide appartenant au groupe de propriétaires du répertoire Homebrew. Les commandes sont similaires à softwareupdate et installer, et sont exécutées via un sous-processus Python pour collecter les données de package, la sortie étant analysée pour identifier les noms et les versions des packages.

  2. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  3. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

  4. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  5. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  6. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  7. Appelle la CLI du package sur le nœud géré pour traiter les correctifs approuvés comme suit :

    Note

    installer ne dispose pas de la fonctionnalité nécessaire pour rechercher et installer des mises à jour. Par conséquent, pour installer, Patch Manager signale uniquement les packages qui sont installés. Il s'ensuit que les packages installer ne sont jamais signalés comme Missing.

    • Pour les référentiels de correctifs par défaut prédéfinis fournis par AWS et pour les référentiels de correctifs personnalisés pour lesquels la case Inclusion de mises à jour non liées à la sécurité n’est pas cochée, seules les mises à jour de sécurité sont appliquées.

    • Pour les référentiels de correctifs personnalisés pour lesquels la case Inclusion de mises à jour non liées à la sécurité est cochée, les mises à jour de sécurité et non liées à la sécurité sont appliquées.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

Oracle Linux

Sur les nœuds gérés Oracle Linux, le flux d'installation des correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de type chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  3. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

  4. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  5. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  6. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  7. Sur les nœuds gérés de version 7, l'API de mise à jour YUM est appliquée aux correctifs approuvés comme suit :

    • Pour les référentiels de correctifs par défaut prédéfinis fournis par AWS et pour les référentiels de correctifs personnalisés pour lesquels la case Inclusion de mises à jour non liées à la sécurité n’est pas cochée, seuls les correctifs spécifiés dans updateinfo.xml sont appliqués (mises à jour de sécurité uniquement).

      La commande yum équivalente pour ce flux de travail est :

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    • Pour les référentiels de correctifs personnalisés pour lesquels la case Inclusion de mises à jour non liées à la sécurité est cochée, les correctifs figurant dans updateinfo.xml et ceux ne figurant pas dans updateinfo.xml sont appliqués (mises à jour de sécurité et non liées à la sécurité).

      La commande yum équivalente pour ce flux de travail est :

      sudo yum update --security --bugfix -y

      Sur les nœuds gérés de version 8 et 9, l'API de mise à jour DNF est appliquée aux correctifs approuvés comme suit :

      • Pour les lignes de base de correctifs par défaut prédéfinies fournies par AWS, et pour les lignes de base de correctifs personnalisées pour lesquelles la case Inclure les mises à jour non liées à la sécurité n'est pas cochée, seuls les correctifs spécifiés dans updateinfo.xml sont appliqués (mises à jour de sécurité uniquement).

        La commande yum équivalente pour ce flux de travail est :

        sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
        Note

        Pour Oracle Linux, Patch Manager vous pouvez installer des versions de dépendances transitives différentes de celles installées par les dnf commandes équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences des autres packages (dépendances des dépendances).

        Par exemple, dnf upgrade-minimal --security installe les versions minimales des dépendances transitives nécessaires pour résoudre les problèmes de sécurité connus, tout en Patch Manager installant les dernières versions disponibles des mêmes dépendances transitives.

      • Pour les référentiels de correctifs personnalisés pour lesquels la case Inclusion de mises à jour non liées à la sécurité est cochée, les correctifs figurant dans updateinfo.xml et ceux ne figurant pas dans updateinfo.xml sont appliqués (mises à jour de sécurité et non liées à la sécurité).

        La commande yum équivalente pour ce flux de travail est :

        sudo dnf upgrade --security --bugfix
    Note

    Les nouveaux packages qui remplacent les packages désormais obsolètes portant des noms différents sont installés si vous les exécutez yum ou si vous exécutez des dnf commandes en dehors de. Patch Manager Cependant, ils ne sont pas installés par des Patch Manager opérations équivalentes.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

AlmaLinux, RHEL, and Rocky Linux

Sur AlmaLinux et sur les nœuds Rocky Linux gérés, le flux de travail d'installation des correctifs est le suivant : Red Hat Enterprise Linux

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de type chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  3. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

  4. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  5. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  6. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  7. L'API de mise à jour YUM (sur RHEL 7) ou l'API de mise à jour DNF (sur AlmaLinux RHEL 8 et 9, 8, 9 et 10, et Rocky Linux 8 et 9) est appliquée aux correctifs approuvés conformément aux règles suivantes :

     

    Scénario 1 : mises à jour non liées à la sécurité exclues

    • S'applique à : les lignes de base de correctifs par défaut prédéfinies fournies par AWS et les lignes de base de correctifs personnalisées.

    • Case à cocher Inclure les mises à jour non liées à la sécurité : Non sélectionnée.

    • Correctifs appliqués : les correctifs spécifiés dans updateinfo.xml (mises à jour de sécurité uniquement) ne sont appliqués que s'ils correspondent à la configuration de base des correctifs et s'ils se trouvent dans les dépôts configurés.

      Dans certains cas, un correctif spécifié dans updateinfo.xml peut ne plus être disponible dans un dépôt configuré. Les dépôts configurés ne disposent généralement que de la dernière version d'un correctif, qui est un cumul de toutes les mises à jour précédentes, mais la dernière version peut ne pas correspondre aux règles de base du correctif et est omise de l'opération de correction.

    • Commandes : pour RHEL 7, la commande yum équivalente pour ce flux de travail est la suivante : 

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      Pour AlmaLinux, RHEL 8 etRocky Linux, les commandes dnf équivalentes pour ce flux de travail sont les suivantes :

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
      Note

      For AlmaLinux,RHEL, et Rocky Linux Rocky Linux Patch Manager peuvent installer des versions de dépendances transitives différentes de celles installées par les dnf commandes équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences des autres packages (dépendances des dépendances).

      Par exemple, dnf upgrade-minimal --security installe les versions minimales des dépendances transitives nécessaires pour résoudre les problèmes de sécurité connus, tout en Patch Manager installant les dernières versions disponibles des mêmes dépendances transitives.

    Scénario 2 : Mises à jour non liées à la sécurité incluses

    • S'applique à : lignes de base de correctifs personnalisées.

    • Case à cocher Inclure les mises à jour non liées à la sécurité : sélectionnée.

    • Correctifs appliqués : les correctifs intégrés updateinfo.xml et non intégrés updateinfo.xml sont appliqués (mises à jour de sécurité et non liées à la sécurité).

    • Commandes : pour RHEL 7, la commande yum équivalente pour ce flux de travail est la suivante :

      sudo yum update --security --bugfix -y

      Pour AlmaLinux 8 et 9, RHEL 8 et 9, et Rocky Linux 8 et 9, la commande dnf équivalente pour ce flux de travail est la suivante :

      sudo dnf update --security --bugfix -y
    Note

    Les nouveaux packages qui remplacent les packages désormais obsolètes portant des noms différents sont installés si vous les exécutez yum ou si vous exécutez des dnf commandes en dehors de. Patch Manager Cependant, ils ne sont pas installés par des Patch Manager opérations équivalentes.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

SLES

Sur les nœuds gérés SUSE Linux Enterprise Server (SLES), le flux d'installation des correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de type chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  3. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

  4. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  5. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  6. Si plusieurs versions d'un correctif sont approuvées, la version la plus récente sera appliquée.

  7. L'API de mise à jour Zypper est appliquée aux correctifs approuvés.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

Ubuntu Server

Sur les nœuds gérés Ubuntu Server, le flux d'installation des correctifs est le suivant :

  1. Si une liste de correctifs est spécifiée à l'aide d'une URL https ou d'une URL de style chemin Amazon Simple Storage Service (Amazon S3) en utilisant le paramètre InstallOverrideList pour les documents AWS-RunPatchBaseline ou AWS-RunPatchBaselineAssociation, les correctifs répertoriés sont installés et les étapes 2 à 7 sont ignorées.

  2. Si une mise à jour est disponible pour python3-apt (une interface de bibliothèque Python pour libapt), la mise à niveau est faite à la dernière version. (Ce package non lié à la sécurité est mis à niveau même si vous n'avez pas sélectionné l'option Inclure les mises à jour non liées à la sécurité.)

  3. Appliquez des filtres GlobalFilters comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur.

  4. Appliquez ApprovalRules comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

    Note

    Comme il n'est pas possible de déterminer de manière fiable les dates de publication des packages de mise à jour pour Ubuntu Server, les options d'approbation automatique ne sont pas prises en charge pour ce système d'exploitation.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Si les mises à jour non liées à la sécurité sont exclues, une règle implicite est appliquée afin de sélectionner uniquement les packages avec des mises à niveau dans les référentiels de sécurité. Pour chaque package, la version du package proposée (généralement la plus récente) doit se trouver dans un référentiel de sécurité.

    Si des mises à jour non liées à la sécurité sont incluses, les correctifs provenant d'autres référentiels sont également pris en compte.

    Cependant, les règles d'approbation sont également assujetties au fait que la case Inclure les mises à jour non liées à la sécurité a été cochée ou non lors de la création ou de la dernière mise à jour d'un référentiel de correctif.

    Note

    Pour chaque version de Ubuntu Server, les versions candidates aux correctifs sont limitées aux correctifs qui font partie du repo associé à cette version, comme suit :

    • Ubuntu Server 14.04 LTS : trusty-security

    • Ubuntu Server 16.04 LTS : xenial-security

    • Ubuntu Server 18.04 LTS : bionic-security

    • Ubuntu Server 20.04 LTS) : focal-security

    • Ubuntu Server 20.10 STR : groovy-security

    • Ubuntu Server 22.04 LTS : jammy-security

    • Ubuntu Server 23.04 (lunar-security)

    • Ubuntu Server23,10 () mantic-security

    • Ubuntu Server24,04 LTS () noble-security

    • Ubuntu Server24,10 () oracular-security

    • Ubuntu Server25,04 () plucky-security

  5. Appliquez ApprovedPatches comme indiqué dans la référence de correctif. Les correctifs approuvés le sont pour une mise à jour, même s'ils sont ignorés par GlobalFilters ou si aucune règle d'approbation spécifiée dans ApprovalRules ne leur accorde d'approbation.

  6. Appliquez RejectedPatches comme indiqué dans la référence de correctif. Les correctifs rejetés sont supprimés de la liste des correctifs approuvés et ne seront pas appliqués.

  7. La bibliothèque APT permet de mettre à niveau les packages.

    Note

    Patch Manager ne prend pas en charge l’utilisation de l’option APT Pin-Priority pour attribuer des priorités aux packages. La commande Patch Manager regroupe les mises à jour disponibles à partir de tous les dépôts activés et sélectionne la mise à jour la plus récente qui correspond à la référence pour chaque package installé.

  8. Si des mises à jour ont été installées, le nœud géré est redémarré. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption).

Windows Server

Lors de l'application de correctifs sur un nœud géré Windows Server, celui-ci demande à Systems Manager un instantané du référentiel de correctifs approprié. Cet instantané contient la liste de toutes les mises à jour disponibles dans le référentiel de correctifs ayant été approuvées à des fins de déploiement. Cette liste est envoyée à l'API Windows Update, qui détermine quelles mises à jour sont applicables au nœud géré et, si nécessaire, les installe. Windows n’autorise que l’installation de la dernière version disponible d’une KB. Patch Manager installe la dernière version d’une base de données lorsque celle-ci, ou toute version antérieure de la KB, correspond au référentiel de correctifs appliqué. Si des mises à jour sont installées, le nœud géré est ensuite redémarré autant de fois que nécessaire pour appliquer les correctifs requis. (Exception : si le paramètre RebootOption est défini sur NoReboot dans le document AWS-RunPatchBaseline, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez Nom du paramètre: RebootOption). La synthèse de l'opération d'application de correctifs se situe dans la sortie de la demande Run Command. Des journaux supplémentaires sont disponibles dans le dossier %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs du nœud géré.

L'API Windows Update étant utilisée pour le téléchargement et l'installation KBs, tous les paramètres de stratégie de groupe pour Windows Update sont respectés. Aucun paramètre lié à la politique de groupe n'est requis pour utiliser Patch Manager, mais tous les paramètres que vous avez définis seront appliqués, par exemple pour diriger les nœuds gérés vers le serveur WSUS (Windows Server Update Services).

Note

Par défaut, Windows télécharge tout KBs depuis le site Windows Update de Microsoft, car il Patch Manager utilise l'API Windows Update pour piloter le téléchargement et l'installation de KBs. Par conséquent, le nœud géré doit avoir accès au site Microsoft Windows Update, faute de quoi l'application des correctifs échouera. Vous pouvez également configurer un serveur WSUS en tant que référentiel de bases de connaissances et configurer vos nœuds gérés pour qu’ils ciblent ce serveur WSUS à l’aide de politiques de groupe.

Patch Managerpeut faire référence à KB IDs lors de la création de lignes de base de correctifs personnalisées pourWindows Server, par exemple lorsqu'une liste de correctifs approuvés ou une liste de correctifs rejetés est incluse dans la configuration de référence. Seules les mises à jour auxquelles un ID KB est attribué dans Microsoft Windows Update ou sur un serveur WSUS sont installées parPatch Manager. Les mises à jour dépourvues d'un ID KB ne sont pas incluses dans les opérations de correction.

Pour plus d'informations sur la création de lignes de base de correctifs personnalisées, consultez les rubriques suivantes :