• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

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.

# Fonctionnement des opérations Patch Manager
<a name="patch-manager-patching-operations"></a>

Cette section fournit des détails techniques sur la manière dont Patch Manager, un des outils d’AWS Systems Manager, détermine quels correctifs installer et dont il les installe sur chaque système d’exploitation pris en charge. Pour les systèmes d'exploitation Linux, elle fournit également des informations sur la spécification d'un référentiel source, au sein d'un référentiel de correctifs personnalisé, pour les correctifs autres que ceux configurés par défaut sur un nœud géré. Cette section fournit également des détails sur le fonctionnement des règles de référentiel de correctifs sur différentes distributions du système d'exploitation Linux.

**Note**  
Les informations des rubriques suivantes s'appliquent, quels que soient la méthode ou le type de configuration que vous utilisez pour vos opérations d'application de correctifs :  
Une politique de correctifs configurée dans Quick Setup
Une option de gestion des hôtes configurée dans Quick Setup
Une fenêtre de maintenance pour exécuter un correctif `Scan` ou une tâche `Install`
Une opération **Patch now** (Appliquer les correctifs maintenant) à la demande

**Topics**
+ [Calcul des dates de sortie et des mises à jour des packages](patch-manager-release-dates.md)
+ [Sélection des correctifs de sécurité](patch-manager-selecting-patches.md)
+ [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md)
+ [Installation des correctifs](patch-manager-installing-patches.md)
+ [Fonctionnement des règles de référence de correctif sur les systèmes basés sur Linux](patch-manager-linux-rules.md)
+ [Différences d’opérations de correctifs entre Linux et Windows Server.](patch-manager-windows-and-linux-differences.md)

# Calcul des dates de sortie et des mises à jour des packages
<a name="patch-manager-release-dates"></a>

**Important**  
Les informations de cette page concernent les systèmes d’exploitation (OS) Amazon Linux 2 et Amazon Linux 2023 pour les instances Amazon Elastic Compute Cloud (Amazon EC2). Amazon Web Services crée et gère les packages pour ces types de systèmes d'exploitation. La gestion des packages et des référentiels par les fabricants d'autres systèmes d'exploitation influe sur le calcul de leurs dates de sortie et de mise à jour. OSs Outre Amazon Linux 2 et Amazon Linux 2023, par exempleRed Hat Enterprise Linux, reportez-vous à la documentation du fabricant pour obtenir des informations sur la mise à jour et la maintenance de leurs packages.

Dans les paramètres des [lignes de base de correctifs personnalisées](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) que vous créez, pour la plupart des types de systèmes d'exploitation, vous pouvez spécifier que l'installation des correctifs est approuvée automatiquement après un certain nombre de jours. AWS fournit plusieurs lignes de base de correctifs prédéfinies qui incluent des dates d'approbation automatique de 7 jours.

Un délai *d'auto-approbation* correspond au nombre de jours à attendre après la publication du correctif et avant son approbation. Par exemple, vous créez une règle à l'aide de la classification `CriticalUpdates` et la configurez pour un délai d'approbation automatique de 7 jours. Par conséquent, pour un nouveau correctif critique dont la date de sortie ou de la dernière mise à jour est le 7 juillet, l'approbation automatique aura lieu le 14 juillet.

Afin d’éviter des résultats inattendus liés à des retards d’approbation automatique sur Amazon Linux 2 et Amazon Linux 2023, il est important de comprendre le calcul de leurs dates de sortie ainsi que leurs mises à jour.

**Note**  
Si un référentiel Amazon Linux 2 ou Amazon Linux 2023 ne fournit pas les informations relatives à la date de publication des packages, Patch Manager utilise le temps de génération du package comme date pour les spécifications relatives à la date d’approbation automatique. Si l’heure de génération du package ne peut pas être déterminée, Patch Manager utilise la date par défaut du 1er janvier 1970. Cela entraîne le contournement de toute spécification de date d’approbation automatique par Patch Manager dans les référentiels de correctifs configurés pour approuver les correctifs pour toute date postérieure au 1er janvier 1970.

Dans la plupart des cas, le temps d'attente de l'approbation automatique avant l'installation des correctifs est calculé à partir d'une valeur `Updated Date` dans `updateinfo.xml`, et non pas d'une valeur `Release Date`. Voici des détails importants relatifs à ces calculs de date : 
+ La `Release Date` est la date à laquelle *un avis* est publié. Cette publication ne signifie pas forcément que le package est disponible dans les référentiels associés. 
+ La `Update Date` est la dernière date de la mise à jour de l'avis. La mise à jour d'un avis peut être aussi petite que la mise à jour d'un texte ou d'une description. Cette mise à jour ne signifie pas que le package est publié à partir de cette date ni qu'il est forcément disponible dans les référentiels associés. 

  Cela signifie qu'un package peut avoir une valeur `Update Date` du 7 juillet mais être indisponible pour l'installation avant (par exemple) le 13 juillet. Supposons dans ce cas qu'un référentiel de correctifs spécifiant un délai d'approbation automatique de 7 jours s'exécute dans une opération `Install` le 14 juillet. Étant donné que la valeur `Update Date` est de 7 jours avant la date d'exécution, les correctifs et les mises à jour du package sont installés le 14 juillet. L'installation a lieu même si un seul jour s'est écoulé depuis que le package est disponible pour une installation réelle.
+ Après sa publication initiale, un package contenant des correctifs de système d'exploitation ou d'application peut être mis à jour plusieurs fois.
+ Un package peut être publié dans les référentiels AWS gérés, puis annulé si des problèmes sont découverts ultérieurement.

Dans certaines opérations d'application de correctifs, ces facteurs peuvent être insignifiants. Par exemple, si la configuration d'un référentiel de correctifs permet l'installation d'un correctif dont les valeurs de gravité sont de `Low` et `Medium`, et une classification de `Recommended`, tout retard de l'approbation automatique aura peu d'impact sur vos opérations.

Toutefois, dans les cas où la synchronisation des correctifs critiques ou de gravité élevée est plus importante, vous pouvez exercer un plus grand contrôle lors de l'installation des correctifs. La méthode recommandée pour ce faire consiste à utiliser des référentiels sources de correctifs alternatifs au lieu des référentiels par défaut pour les opérations d'application de correctifs sur un nœud géré. 

Vous pouvez spécifier d'autres référentiels source de correctifs lors de la création d'un référentiel de correctifs personnalisée. Dans chaque référentiel de correctifs personnalisée, vous pouvez spécifier des configurations source de correctifs pour un maximum de 20 versions d'un système d'exploitation Linux pris en charge. Pour de plus amples informations, veuillez consulter [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md).

# Sélection des correctifs de sécurité
<a name="patch-manager-selecting-patches"></a>

L'objectif principal d'Patch Managerun outil est d'installer des mises à AWS Systems Manager jour liées à 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 de plus amples informations, veuillez consulter [Installation des correctifs](patch-manager-installing-patches.md).

**Note**  
Lorsque vous utilisez le `ApproveUntilDate` paramètre ou le `ApproveAfterDays` paramètre dans une règle de référence des correctifs, 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`, les correctifs publiés entre `2025-11-16T00:00:00Z` et `2025-11-16T23:59:59Z` seront approuvés.   
Sachez que les dates de publication des correctifs affichées par les gestionnaires de packages natifs sur vos nœuds gérés peuvent indiquer des heures différentes en fonction du fuseau horaire local de votre système, mais qu'elles utilisent Patch Manager toujours la date UTC pour les calculs d'approbation. Cela garantit la cohérence avec les dates de publication des correctifs publiées sur les sites Web officiels d'avis de sécurité.

Pour les types de système d'exploitation basés sur Linux qui signalent un niveau de sévérité pour les correctifs, Patch Manager utilise le niveau de sévérité signalé par l'éditeur du logiciel pour l'avis de mise à jour ou le correctif individuel. Patch Manager ne dérive pas les niveaux de sévérité de sources tierces, telles que le [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS), ou des métriques publiées par la [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD).

**Note**  
Sur tous les systèmes Linux pris en charge par Patch Manager, vous pouvez choisir un autre référentiel source 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)](patch-manager-alternative-source-repository.md).

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\$164 ou (pour les processeurs Graviton) aarch64.

Lorsque vous créez une instance Amazon Linux 2023 (AL2023), elle contient les mises à jour disponibles dans la version de AL2023 et celles spécifiques que AMI vous avez sélectionnées. Votre AL2023 instance ne reçoit pas automatiquement d'autres mises à jour de sécurité critiques et importantes au moment du lancement. Au lieu de cela, grâce à la fonctionnalité de *mise à niveau déterministe via des référentiels versionnés* prise en charge AL2023, qui est activée par défaut, vous pouvez appliquer les 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](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) dans le *Guide de l'utilisateur Amazon Linux 2023*. 

Activé 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 aux *versions verrouillées* des mises à jour des packages. Lorsque de nouveaux Amazon Machine Images (AMIs) pour AL2023 sont publiés, ils sont verrouillés dans 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 satisfaire aux règles de référence de correctif 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](patch-manager-installing-patches.md) et [Fonctionnement des règles de référence de correctif sur les systèmes basés sur Linux](patch-manager-linux-rules.md).

------
#### [  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 de 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 à l'internet afin de se connecter aux référentiels pour que le correctif puisse être exécuté.

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 Server11 : `debian-security bullseye`
+ Debian Server12 : `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 à l'internet afin de se connecter aux référentiels pour que le correctif puisse être exécuté.

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 satisfaire aux règles de référence de correctif spécifiées par l'utilisateur.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

Activé AlmaLinuxRed Hat Enterprise Linux, et Rocky Linux le service de base de correctifs de Systems Manager utilise des référentiels préconfigurés (repos) 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 à l'internet afin de se connecter aux référentiels pour que le correctif puisse être exécuté.

**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 satisfaire aux règles de référence de correctif spécifiées par l'utilisateur.

Red Hat Enterprise Linux7 nœuds gérés utilisent Yum comme gestionnaire de packages. AlmaLinux, Red Hat Enterprise Linux 8, et les nœuds Rocky Linux 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.

RHEL 7  
Les dépôts suivants IDs sont associés à RHUI 2. RHUI 3 a été lancé en décembre 2019 et a introduit un schéma de dénomination différent pour le référentiel Yum. IDs En fonction de l'AMI RHEL-7 à partir de laquelle vous créez vos nœuds gérés, une mise à jour de vos commandes peut être nécessaire. Pour plus d'informations, consultez [Repository IDs for RHEL 7 dans AWS Have Changed](https://access.redhat.com/articles/4599971) 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 référentiels `codename-security`, le nom de code étant unique à la version, `trusty` pour Ubuntu Server 14 par exemple. Patch Manager identifie uniquement les mises à niveau qui font partie de ces référentiels : 
+ Ubuntu Server 16.04 LTS : `xenial-security`
+ Ubuntu Server 18.04 LTS : `bionic-security`
+ Ubuntu Server 20.04 LTS : `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server24,04 LTS () `noble-security`
+ Ubuntu Server 25.04 (`plucky-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`. 

Cela signifie que le nœud géré est conforme en termes d’opérations Systems Manager, même si un correctif critique du mois précédent peut ne pas être installé. Le même scénario peut se produire lorsque vous utilisez le paramètre `ApproveAfterDays`. En raison du comportement de Microsoft en matière de correctifs remplacés, il est possible de définir un nombre (généralement supérieur à 30 jours) de sorte que les correctifs pour Windows Server ne soient jamais installés si le dernier correctif disponible de Microsoft est publié avant que le nombre de jours indiqué dans `ApproveAfterDays` ne se soit écoulé. Notez que ce comportement du système ne s’applique pas si vous avez modifié vos paramètres d’objets de politique 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.

------

# Spécification d'un autre référentiel source de correctifs (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Lorsque vous utilisez les référentiels par défaut configurés sur un nœud géré pour les opérations d'application de correctifs, un outil introduit Patch Manager AWS Systems Manager, recherche ou installe les correctifs liés à la sécurité. Il s'agit du comportement par défaut pour Patch Manager. Pour des informations détaillées sur la façon dont Patch Manager sélectionne et installe les correctifs de sécurité, consultez [Sélection des correctifs de sécurité](patch-manager-selecting-patches.md).

Toutefois, sur les systèmes Linux, vous pouvez également utiliser Patch Manager pour installer des correctifs non liés à la sécurité ou provenant d'un référentiel source autre de celui configuré par défaut sur le nœud géré. Vous pouvez spécifier d'autres référentiels source de correctifs lors de la création d'un référentiel de correctifs personnalisée. Dans chaque référentiel de correctifs personnalisée, vous pouvez spécifier des configurations source de correctifs pour un maximum de 20 versions d'un système d'exploitation Linux pris en charge. 

Par exemple, supposons que votre parc Ubuntu Server contienne les deux nœuds gérés Ubuntu Server 25.04. Dans ce cas, vous pouvez spécifier d'autres référentiels pour chaque version dans la même référentiel de correctifs personnalisée. Pour chaque version, vous fournissez un nom, spécifiez le type de version du système d'exploitation (produit) et indiquez une configuration de référentiel. Vous pouvez également spécifier un autre référentiel source unique, qui s'applique à toutes les versions d'un système d'exploitation pris en charge.

**Note**  
L'exécution d'un référentiel de correctifs personnalisé spécifiant des référentiels alternatifs pour un nœud géré ne fait pas de ceux-ci les nouveaux référentiels par défaut sur le système d'exploitation. Une fois les correctifs appliqués, les référentiels précédemment configurés par défaut pour le système d'exploitation du nœud restent les référentiels par défaut.

Pour obtenir la liste des exemples de scénarios pour l'utilisation de cette option, consultez [Exemples d'utilisations pour d'autres référentiels source de correctifs](#patch-manager-alternative-source-repository-examples) plus loin dans cette rubrique.

Pour plus d'informations sur les références de correctifs par défaut et personnalisées, consultez [Référentiels de correctifs prédéfinis et personnalisés](patch-manager-predefined-and-custom-patch-baselines.md).

**Exemple : utilisation de la console**  
Pour spécifier d'autres référentiels source de correctifs lorsque vous travaillez dans la console Systems Manager, utilisez la section **Sources des correctifs** de la page **Créer un référentiel de correctifs**. Pour de plus amples informations sur l'utilisation des options **Sources des correctifs**, veuillez consulter [Création d’un référentiel de correctifs personnalisé pour Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**Exemple : utilisation du AWS CLI**  
Pour un exemple d'utilisation de l'option `--sources` à l'aide de l' AWS Command Line Interface (AWS CLI), consultez [Création d'un référentiel de correctifs avec des référentiels personnalisés pour les différentes versions du système d'exploitation](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Points importants à prendre en compte pour d'autres référentiels](#alt-source-repository-important)
+ [Exemples d'utilisations pour d'autres référentiels source de correctifs](#patch-manager-alternative-source-repository-examples)

## Points importants à prendre en compte pour d'autres référentiels
<a name="alt-source-repository-important"></a>

Gardez les points suivants à l'esprit lorsque vous planifiez votre stratégie d'application de correctifs en utilisant d'autres référentiels de correctifs.

**Appliquer les vérifications de mise à jour des dépôts (YUM et DNF)**  
La configuration par défaut d'un gestionnaire de packages sur une distribution Linux peut être définie pour ignorer un dépôt de packages inaccessible si la connexion au référentiel ne peut pas être établie. Pour appliquer la vérification des mises à jour du référentiel, ajoutez `skip_if_unavailable=False` à la configuration du référentiel.

Pour plus d’informations sur l’option `skip_if_available`, consultez [Connectivité à la source de correctifs](patch-manager-prerequisites.md#source-connectivity).

**Seuls les référentiels spécifiés sont utilisés pour l'application de correctifs**  
Spécifier d'autres référentiels ne signifie pas spécifier des référentiels *supplémentaires*. Vous pouvez choisir de spécifier des référentiels autres que ceux configurés par défaut sur un nœud géré. Toutefois, vous devez également spécifier les référentiels par défaut dans le cadre de la configuration d'autres sources de correctifs si vous voulez que leurs mises à jour soient appliquées.

Par exemple, sur les nœuds gérés Amazon Linux 2, les référentiels par défaut sont `amzn2-core` et `amzn2extra-docker`. Si vous souhaitez inclure le référentiel EPEL (Extra Packages for Enterprise Linux) dans vos opérations d'application de correctifs, vous devez spécifier ces trois référentiels en tant que référentiels alternatifs.

**Note**  
L'exécution d'un référentiel de correctifs personnalisé spécifiant des référentiels alternatifs pour un nœud géré ne fait pas de ceux-ci les nouveaux référentiels par défaut sur le système d'exploitation. Une fois les correctifs appliqués, les référentiels précédemment configurés par défaut pour le système d'exploitation du nœud restent les référentiels par défaut.

**Le comportement d'application de correctifs pour les distributions basées sur YUM dépend du manifeste updateinfo.xml**  
Lorsque vous spécifiez d’autres référentiels de correctifs pour les distributions basées sur YUM, tels qu’Amazon Linux 2 ou Red Hat Enterprise Linux, le comportement d’application des correctifs varie selon que le référentiel inclut ou non un manifeste de mise à jour sous la forme d’un fichier `updateinfo.xml` complet et correctement formaté. Ce fichier spécifie la date de parution, la classification et la sévérité des différents packages. Les éléments suivants ont un impact sur le comportement d'application des correctifs :
+ Si vous filtrez selon **Classification** et **Severity (Sévérité)**, mais qu'elles ne sont pas spécifiées dans `updateinfo.xml`, le package ne sera pas inclus par le filtre. Cela signifie également que les packages sans fichier `updateinfo.xml` ne seront pas inclus dans l'application des correctifs.
+ Si vous filtrez **ApprovalAfterDays**, mais que la date de sortie du package n'est pas au format Unix Epoch (ou qu'aucune date de sortie n'est spécifiée), le package ne sera pas inclus dans le filtre.
+ Il existe une exception 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**. Dans ce cas, les packages sans fichier `updateinfo.xml` (ou contenant ce fichier sans que les valeurs de **Classification**, **Severity** (Sévérité) et **Date** soient correctement formatées) *seront* inclus dans la liste préfiltrée des correctifs. (Ils doivent encore satisfaire aux autres conditions préalables relatives aux règles de référentiel de correctifs pour pouvoir être installés.)

## Exemples d'utilisations pour d'autres référentiels source de correctifs
<a name="patch-manager-alternative-source-repository-examples"></a>

**Exemple 1 - Mises à jour non liées à la sécurité pour Ubuntu Server**  
Vous avez déjà l'habitude d'Patch Managerinstaller des correctifs de sécurité sur un parc de nœuds Ubuntu Server gérés à l'aide de la base `AWS-UbuntuDefaultPatchBaseline` de correctifs prédéfinie AWS fournie. Vous pouvez créer un référentiel de correctifs basée sur cette valeur par défaut, mais spécifiez dans les règles d'approbation que vous ne voulez pas que les mises à jour non liées à la sécurité qui font partie de la distribution par défaut soient également installées. Lorsque ce référentiel de correctifs est exécuté sur vos nœuds, tous les correctifs, qu'ils soient liés ou non à la sécurité, sont appliqués. Vous pouvez également choisir d'approuver les correctifs non liés à la sécurité dans les exceptions de correctif que vous spécifiez pour une référence.

**Exemple 2 - Dépôts PPA (Personal Package Archive) pour Ubuntu Server**  
Vos nœuds gérés Ubuntu Server exécutent des logiciels distribués par le biais de [référentiels PPA (Personal Package Archive) pour Ubuntu](https://launchpad.net/ubuntu/+ppas). Dans ce cas, vous créez un référentiel de correctifs spécifiant un référentiel PPA que vous avez configuré sur le nœud géré en tant que référentiel source pour l'application des correctifs. Utilisez ensuite la fonctionnalité Run Command pour exécuter le document de référentiel de correctifs sur les nœuds.

**Exemple 3 – Versions des applications d’entreprise internes prises en charge sur Amazon Linux**  
Certaines applications doivent être exécutées sur vos nœuds gérés Amazon Linux pour mettre ceux-ci en conformité avec les réglementations du secteur. Vous pouvez configurer un référentiel dédié à ces applications sur les nœuds, utiliser YUM pour installer les applications, puis mettre à jour ou créer un référentiel de correctifs pour inclure ce nouveau référentiel d'entreprise. Vous pouvez ensuite utiliser la fonctionnalité Run Command pour exécuter le document `AWS-RunPatchBaseline` avec l'option `Scan` afin de déterminer si le package d'entreprise est répertorié parmi les packages installés et à jour sur le nœud géré. S'il n'est pas à jour, vous pouvez exécuter à nouveau le document à l'aide de l'option `Install` pour mettre à jour les applications. 

# Installation des correctifs
<a name="patch-manager-installing-patches"></a>

Patch Manager, un outil de AWS Systems Manager, utilise le gestionnaire de packages intégré au système d'exploitation pour installer les mises à jour sur les nœuds gérés. Par exemple, il utilise l'API Windows Update sur Windows Server et `DNF` sur Amazon Linux 2023. Patch Manager respecte les configurations existantes du gestionnaire de packages et des référentiels sur les nœuds, y compris les paramètres tels que l'état du référentiel, le miroir URLs, la vérification GPG et les options telles que`skip_if_unavailable`.

Patch Manager n’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 opérations standard de Patch Manager.

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 2 and Amazon Linux 2023 ]

Sur les nœuds gérés Amazon Linux 2 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.

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

1. L’API de mise à jour YUM (Amazon Linux 2) ou l’API de mise à jour DNF (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 2, la commande yum équivalente pour ce flux de travail est

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

     Pour 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 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 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 exécutez ces commandes `yum` ou `dnf` en dehors de Patch Manager. Cependant, ils ne sont *pas* installés par les opérations Patch Manager équivalentes.

**Informations supplémentaires sur l’application de correctifs pour Amazon Linux 2023**  
Prise en charge du niveau de gravité « Aucun »  
Amazon Linux 2023 prend également en charge le niveau de gravité des correctifs`None`, reconnu par le gestionnaire de packages DNF.   
Prise en charge du niveau de gravité « Moyen »  
Pour Amazon Linux 2023, le niveau de gravité des correctifs `Medium` est équivalent à celui `Moderate` qui peut ê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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html), 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 2023  
Pour Amazon Linux 2023, Patch Manager peut installer des versions de dépendances transitives différentes de celles installées par les commandes `dnf` équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences d’autres packages (dépendances de 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, tandis que Patch Manager installe les **dernières versions disponibles des mêmes dépendances transitives.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**Note**  
La configuration par défaut d'un gestionnaire de packages sur une distribution Linux peut être définie pour ignorer un référentiel de packages inaccessible sans erreur. Dans de tels cas, l'opération de correction correspondante se poursuit sans installer de mises à jour depuis le référentiel et se termine par un succès. Pour appliquer les mises à jour du référentiel, ajoutez-les `skip_if_unavailable=False` à la configuration du référentiel.  
Pour plus d’informations sur l’option `skip_if_available`, consultez [Connectivité à la source de correctifs](patch-manager-prerequisites.md#source-connectivity).

------
#### [ CentOS Stream ]

Sur les nœuds gérés CentOS Stream, 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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

1. La mise à jour DNF sur CentOS Stream est appliquée aux correctifs approuvés.
**Note**  
Pour CentOS Stream, Patch Manager peut installer des versions de dépendances transitives différentes de celles installées par les commandes `dnf` équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences d’autres packages (dépendances de 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, tandis que Patch Manager installe les *dernières versions disponibles* des mêmes dépendances transitives.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Debian Server ]

Sur les instances Debian Server, 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.

1. 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é**.)

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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, les versions de correctifs candidates se limitent aux correctifs inclus dans `debian-security`.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. 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é.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ 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` (pour`installer`) 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.

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) comme indiqué dans la référence de correctif. Chaque règle d'approbation peut définir un package comme approuvé.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

1. 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.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ 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.

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

1. 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 où 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 peut installer des versions de dépendances transitives différentes de celles installées par les commandes `dnf` équivalentes. Les dépendances transitives sont des packages qui sont automatiquement installés pour répondre aux exigences d’autres packages (dépendances de 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, tandis que Patch Manager installe 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 exécutez ces commandes `yum` ou `dnf` en dehors de Patch Manager. Cependant, ils ne sont *pas* installés par les opérations Patch Manager équivalentes.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**Note**  
La configuration par défaut d'un gestionnaire de packages sur une distribution Linux peut être définie pour ignorer un référentiel de packages inaccessible sans erreur. Dans de tels cas, l'opération de correction correspondante se poursuit sans installer de mises à jour depuis le référentiel et se termine par un succès. Pour appliquer les mises à jour du référentiel, ajoutez-les `skip_if_unavailable=False` à la configuration du référentiel.  
Pour plus d’informations sur l’option `skip_if_available`, consultez [Connectivité à la source de correctifs](patch-manager-prerequisites.md#source-connectivity).

------
#### [ 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.

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

1. 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 **Inclusion de mises à jour non liées à la sécurité** : *non* coché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 du référentiel de correctifs et s’ils se trouvent dans les référentiels configurés.

     Dans certains cas, un correctif spécifié dans `updateinfo.xml` peut ne plus être disponible dans un référentiel configuré. Les référentiels 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 du référentiel de correctifs et est omise de l’opération d’application de correctifs.
   + **Commandes** : pour RHEL 7, la commande yum équivalente pour ce flux de travail est : 

     ```
     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 AlmaLinuxRHEL, 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 d’autres packages (dépendances de 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, tandis que Patch Manager installe 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 à** : référentiels de correctifs personnalisés.
   + Case **Inclusion de mises à jour non liées à la sécurité** : cochée.
   + **Correctifs appliqués** : les correctifs dans `updateinfo.xml` *et* non présents dans `updateinfo.xml` sont appliqués (mises à jour liées ou non à la sécurité).
   + **Commandes** : pour RHEL 7, la commande yum équivalente pour ce flux de travail est :

     ```
     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 exécutez ces commandes `yum` ou `dnf` en dehors de Patch Manager. Cependant, ils ne sont *pas* installés par les opérations Patch Manager équivalentes.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**Note**  
La configuration par défaut d'un gestionnaire de packages sur une distribution Linux peut être définie pour ignorer un référentiel de packages inaccessible sans erreur. Dans de tels cas, l'opération de correction correspondante se poursuit sans installer de mises à jour depuis le référentiel et se termine par un succès. Pour appliquer les mises à jour du référentiel, ajoutez-les `skip_if_unavailable=False` à la configuration du référentiel.  
Pour plus d’informations sur l’option `skip_if_available`, consultez [Connectivité à la source de correctifs](patch-manager-prerequisites.md#source-connectivity).

------
#### [ 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.

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

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

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

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ 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.

1. 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é**.)

1. Appliquez des filtres [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) comme indiqué dans la référence de correctif en conservant uniquement les packages qualifiés à des fins de traitement ultérieur. 

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 16.04 LTS : `xenial-security`
Ubuntu Server 18.04 LTS : `bionic-security`
Ubuntu Server 20.04 LTS) : `focal-security`
Ubuntu Server 22.04 LTS : `jammy-security`
Ubuntu Server24,04 LTS () `noble-security`
Ubuntu Server 25.04 (`plucky-security`)

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) ou si aucune règle d'approbation spécifiée dans [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) ne leur accorde d'approbation.

1. Appliquez [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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.

1. 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é.

1. 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ 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`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)). 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 base. Seules les mises à jour auxquelles un ID de base de connaissance est attribué dans Microsoft Windows Update ou sur un serveur WSUS sont installées par Patch Manager. Les mises à jour dépourvues d’un ID de base de connaissance ne sont pas incluses dans les opérations d’application de correctifs.   
Pour plus d’informations sur la création de référentiels de correctifs, consultez les rubriques suivantes :  
 [Création d’un référentiel de correctifs personnalisé pour Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 Créer un référentiel de correctifs (CLI)
[Formats de noms de package pour les systèmes d'exploitation Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Fonctionnement des règles de référence de correctif sur les systèmes basés sur Linux
<a name="patch-manager-linux-rules"></a>

Les règles d'un référentiel de correctif pour les distributions Linux fonctionnent différemment en fonction du type de distribution. Contrairement aux mises à jour de correctifs sur les nœuds Windows Server gérés, les règles sont évaluées sur chaque nœud afin de prendre en compte les dépôts configurés sur l'instance. Patch Manager, un outil dans AWS Systems Manager, utilise le gestionnaire de packages natif pour piloter l'installation des correctifs approuvés par la ligne de base des correctifs.

Pour les types de système d'exploitation basés sur Linux qui signalent un niveau de sévérité pour les correctifs, Patch Manager utilise le niveau de sévérité signalé par l'éditeur du logiciel pour l'avis de mise à jour ou le correctif individuel. Patch Manager ne dérive pas les niveaux de sévérité de sources tierces, telles que le [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS), ou des métriques publiées par la [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD).

**Topics**
+ [Fonctionnement des règles de référentiel de correctifs sur Amazon Linux 2 et Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Fonctionnement des règles de référence de correctif sur CentOS Stream](#linux-rules-centos)
+ [Fonctionnement des règles de référence de correctif sur Debian Server](#linux-rules-debian)
+ [Fonctionnement des règles de référence de correctif sur macOS](#linux-rules-macos)
+ [Fonctionnement des règles de référence de correctif sur Oracle Linux](#linux-rules-oracle)
+ [Comment fonctionnent les règles de base des correctifs sur AlmaLinuxRHEL, et Rocky Linux](#linux-rules-rhel)
+ [Fonctionnement des règles de référence de correctif sur SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Fonctionnement des règles de référence de correctif sur Ubuntu Server](#linux-rules-ubuntu)

## Fonctionnement des règles de référentiel de correctifs sur Amazon Linux 2 et Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**Note**  
Amazon Linux 2023 (AL2023) utilise des référentiels avec gestion des versions qui peuvent être verrouillés sur une version spécifique via un ou plusieurs paramètres système. Pour toutes les opérations d’application de correctifs sur les instances AL2023 EC2, Patch Manager utilise les dernières versions du référentiel, indépendamment de la configuration du système. Pour plus d'informations, veuillez consulter la rubrique [Mises à niveau déterministes via des référentiels versionnés](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) dans le *Guide de l'utilisateur Amazon Linux 2023*.

Sur Amazon Linux 2 et Amazon Linux 2023, le processus de sélection des correctifs est le suivant :

1. Sur le nœud géré, la bibliothèque YUM (Amazon Linux 2) ou la bibliothèque DNF (Amazon Linux 2023) accèdent au fichier `updateinfo.xml` de chaque référentiel configuré. 

   Si aucun fichier `updateinfo.xml` n’est trouvé, l’installation de correctifs dépend des paramètres **Inclusion de mises à jour non liées à la sécurité** et **Approbation automatique**. Par exemple, si les mises à jour non liées à la sécurité sont autorisées, elles sont installées lorsque l'heure de l'approbation automatique arrive.

1. Chaque notice de mise à jour dans le fichier `updateinfo.xml` inclut plusieurs attributs indiquant les propriétés des packages de la notice, comme décrit dans le tableau suivant.  
**Mettre à jour les attributs de la notice**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Pour obtenir des informations sur les formats acceptés de listes de correctifs approuvés et de correctifs rejetés, consultez [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

1. Le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé de produit du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctif.

1. Les packages sont sélectionnés pour la mise à jour en suivant les consignes suivantes.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Fonctionnement des règles de référence de correctif sur CentOS Stream
<a name="linux-rules-centos"></a>

Les référentiels par défaut de CentOS Stream n’incluent pas de fichier `updateinfo.xml`. Cependant, les référentiels personnalisés que vous créez ou utilisez peuvent inclure ce fichier. Dans cette rubrique, les références à `updateinfo.xml` s’appliquent uniquement à ces référentiels personnalisés.

Sur les CentOS Stream, le processus de sélection des correctifs est le suivant :

1. Sur le nœud géré, la bibliothèque DNF accède au fichier `updateinfo.xml`, s’il existe dans un référentiel personnalisé, pour chaque référentiel configuré.

   Si aucun `updateinfo.xml` n’est trouvé, ce qui inclut toujours les référentiels par défaut, l’installation des correctifs dépend des paramètres pour **Inclure les mises à jour de non-sécurité** et **Auto-approbation**. Par exemple, si les mises à jour non liées à la sécurité sont autorisées, elles sont installées lorsque l'heure de l'approbation automatique arrive.

1. Si `updateinfo.xml` est présent, chaque notice de mise à jour dans le fichier comprend plusieurs attributs qui dénotent les propriétés des packages de la notice, comme décrit dans le tableau suivant.  
**Mettre à jour les attributs de la notice**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Pour obtenir des informations sur les formats acceptés de listes de correctifs approuvés et de correctifs rejetés, consultez [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

1. Dans tous les cas, le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé de produit du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctif.

1. Les packages sont sélectionnés pour la mise à jour en suivant les consignes suivantes.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Fonctionnement des règles de référence de correctif sur Debian Server
<a name="linux-rules-debian"></a>

Sur Debian Server, le service de référence de correctifs permet un filtrage sur les champs *Priorité* et *Section*. Ces champs sont généralement présents pour tous les packages Debian Server. Pour déterminer si un correctif est sélectionné par le référentiel de correctif, Patch Manager effectue les opérations suivantes :

1. Sous les systèmes Debian Server, l'équivalent de `sudo apt-get update` est exécuté afin d'actualiser la liste des packages disponibles. Les référentiels ne sont pas configurés et les données sont extraites des référentiels configurés dans une liste de `sources`.

1. 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é**.)

1. Ensuite, les listes [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) et [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) sont appliquées.
**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é. Dans ce cas, pour Debian Server les versions de correctifs candidates se limitent aux correctifs inclus dans les référentiels suivants :

   La dénomination de ces référentiels est la suivante :
   + Debian Server11 : `debian-security bullseye`
   + Debian Server12 : `debian-security bookworm`

   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.

   Pour obtenir des informations sur les formats acceptés pour les listes de correctifs approuvés et de correctifs rejetés, veuillez consulter [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

Pour afficher le contenu des champs *Priorité* et *Section*, exécutez la commande `aptitude` suivante : 

**Note**  
Il se peut que vous deviez d'abord installer Aptitude sur les systèmes Debian Server.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Dans la réponse à cette commande, tous les packages pouvant être mis à niveau sont indiqués dans le format suivant : 

```
name, priority, section, archive, candidate version
```

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Fonctionnement des règles de référence de correctif sur macOS
<a name="linux-rules-macos"></a>

Sur les macOS, le processus de sélection des correctifs est le suivant :

1. Sur le nœud géré, Patch Manager accède au contenu analysé du fichier `InstallHistory.plist` et identifie les noms et les versions des packages. 

   Pour obtenir des détails sur le processus d'analyse, veuillez consulter l'onglet **macOS** dans [Installation des correctifs](patch-manager-installing-patches.md).

1. Le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé de produit du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctif.

1. Les packages sont sélectionnés pour la mise à jour en suivant les consignes suivantes.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Fonctionnement des règles de référence de correctif sur Oracle Linux
<a name="linux-rules-oracle"></a>

Sur les Oracle Linux, le processus de sélection des correctifs est le suivant :

1. Sur le nœud géré, la bibliothèque YUM accède au fichier `updateinfo.xml` de chaque référentiel configuré.
**Note**  
Le fichier `updateinfo.xml` peut ne pas être disponible si le référentiel n'est pas géré par Oracle. Si aucun fichier `updateinfo.xml` n’est trouvé, l’installation de correctifs dépend des paramètres **Inclusion de mises à jour non liées à la sécurité** et **Approbation automatique**. Par exemple, si les mises à jour non liées à la sécurité sont autorisées, elles sont installées lorsque l'heure de l'approbation automatique arrive.

1. Chaque notice de mise à jour dans le fichier `updateinfo.xml` inclut plusieurs attributs indiquant les propriétés des packages de la notice, comme décrit dans le tableau suivant.  
**Mettre à jour les attributs de la notice**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Pour obtenir des informations sur les formats acceptés de listes de correctifs approuvés et de correctifs rejetés, consultez [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

1. Le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé de produit du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctif.

1. Les packages sont sélectionnés pour la mise à jour en suivant les consignes suivantes.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Comment fonctionnent les règles de base des correctifs sur AlmaLinuxRHEL, et Rocky Linux
<a name="linux-rules-rhel"></a>

Sur AlmaLinux, Red Hat Enterprise Linux (RHEL) etRocky Linux, le processus de sélection des correctifs est le suivant :

1. Sur le nœud géré, la bibliothèque YUM (RHEL7) ou la bibliothèque DNF (AlmaLinux 8 et 9, RHEL 8, 9 et 10, et Rocky Linux 8 et 9) accède au `updateinfo.xml` fichier pour chaque dépôt configuré.
**Note**  
Le fichier `updateinfo.xml` peut ne pas être disponible si le référentiel n'est pas géré par Red Hat. Si aucun fichier `updateinfo.xml` n'est trouvé, aucun correctif ne sera appliqué.

1. Chaque notice de mise à jour dans le fichier `updateinfo.xml` inclut plusieurs attributs indiquant les propriétés des packages de la notice, comme décrit dans le tableau suivant.  
**Mettre à jour les attributs de la notice**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Pour obtenir des informations sur les formats acceptés de listes de correctifs approuvés et de correctifs rejetés, consultez [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

1. Le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé de produit du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctif.

1. Les packages sont sélectionnés pour la mise à jour en suivant les consignes suivantes.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

## Fonctionnement des règles de référence de correctif sur SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

Sur SLES, chaque correctif inclut les attributs suivants, qui indiquent les propriétés des packages dans le correctif :
+ **Catégorie** : Correspond à la valeur de l'attribut de la clé **Classification** du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctifs. Indique le type de correctif inclus dans la notice de mise à jour.

  Vous pouvez consulter la liste des valeurs prises en charge à l'aide de la AWS CLI commande **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** ou de l'opération API**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Vous pouvez aussi afficher la liste dans la zone **Règles d'approbation** de la page **Créer un référentiel de correctif** ou la page **Modifier le référentiel de correctif** dans la console Systems Manager.
+ **Severity** : correspond à la valeur de l'attribut de la clé **Severity** dans le type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctifs. Désigne la sévérité des correctifs.

  Vous pouvez consulter la liste des valeurs prises en charge à l'aide de la AWS CLI commande **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** ou de l'opération API**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Vous pouvez aussi afficher la liste dans la zone **Règles d'approbation** de la page **Créer un référentiel de correctif** ou la page **Modifier le référentiel de correctif** dans la console Systems Manager.

Le produit du nœud géré est déterminé par SSM Agent. Cet attribut correspond à la valeur de l'attribut de la clé **Product** du type de données [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la référence de correctifs. 

Pour chaque correctif, le référentiel de correctif est utilisée en guise de filtre, ce qui permet que seuls les packages qualifiés soient inclus dans la mise à jour. Si plusieurs packages sont applicables après l'application de la définition de référence de correctif, la version la plus récente est utilisée. 

Pour obtenir des informations sur les formats acceptés pour les listes de correctifs approuvés et de correctifs rejetés, veuillez consulter [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

## Fonctionnement des règles de référence de correctif sur Ubuntu Server
<a name="linux-rules-ubuntu"></a>

Sur Ubuntu Server, le service de référence de correctifs permet un filtrage sur les champs *Priorité* et *Section*. Ces champs sont généralement présents pour tous les packages Ubuntu Server. Pour déterminer si un correctif est sélectionné par le référentiel de correctif, Patch Manager effectue les opérations suivantes :

1. Sous les systèmes Ubuntu Server, l'équivalent de `sudo apt-get update` est exécuté afin d'actualiser la liste des packages disponibles. Les référentiels ne sont pas configurés et les données sont extraites des référentiels configurés dans une liste de `sources`.

1. 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é**.)

1. Ensuite, les listes [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) et [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) sont appliquées.
**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é. Dans ce cas, pour Ubuntu Server les versions de correctifs candidates se limitent aux correctifs inclus dans les référentiels suivants :
   + Ubuntu Server 16.04 LTS : `xenial-security`
   + Ubuntu Server 18.04 LTS : `bionic-security`
   + Ubuntu Server 20.04 LTS : `focal-security`
   + Ubuntu Server 22.04 LTS (`jammy-security`)
   + Ubuntu Server24,04 LTS () `noble-security`
   + Ubuntu Server 25.04 (`plucky-security`)

   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.

   Pour obtenir des informations sur les formats acceptés pour les listes de correctifs approuvés et de correctifs rejetés, veuillez consulter [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md).

Pour afficher le contenu des champs *Priorité* et *Section*, exécutez la commande `aptitude` suivante : 

**Note**  
Il se peut que vous deviez d'abord installer Aptitude sur les systèmes Ubuntu Server 16.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

Dans la réponse à cette commande, tous les packages pouvant être mis à niveau sont indiqués dans le format suivant : 

```
name, priority, section, archive, candidate version
```

Pour de plus amples informations sur les valeurs du statut de conformité des correctifs, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).

# Différences d’opérations de correctifs entre Linux et Windows Server.
<a name="patch-manager-windows-and-linux-differences"></a>

Cette rubrique décrit les différences importantes entre l’application de correctifs Linux et Windows Server dans Patch Manager, un des outils d’ AWS Systems Manager.

**Note**  
Pour appliquer des correctifs à des nœuds gérés Linux, ces derniers doivent exécuter SSM Agent version 2.0.834.0 ou ultérieure.  
Une nouvelle version de SSM Agent est lancée chaque fois que de nouveaux outils sont ajoutés à Systems Manager ou que des mises à jour sont apportées aux outils existants. Le fait de ne pas utiliser la dernière version de l’agent peut empêcher votre nœud géré d’utiliser divers outils et fonctionnalités de Systems Manager. C'est pourquoi nous vous recommandons d'automatiser le processus permettant de maintenir SSM Agent à jour sur vos machines. Pour plus d'informations, consultez [Automatisation des mises à jour de l'SSM Agent](ssm-agent-automatic-updates.md). Inscrivez‑vous sur la page [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) du site Web de GitHub pour recevoir des notifications sur les mises à jour de SSM Agent.

## Différence 1 : Évaluation des correctifs
<a name="patch-evaluation_diff"></a>

Patch Manager utilise des processus différents sur les nœuds gérés Windows et Linux pour déterminer quels correctifs doivent être présents. 

**Linux**  
Pour l'application de correctifs Linux, Systems Manager vérifie les règles du référentiel de correctifs ainsi que la liste des correctifs approuvés et rejetés sur *chaque* nœud géré. Systems Manager doit vérifier l'application des correctifs sur chaque nœud, car le service récupère la liste des correctifs et mises à jour connus à partir des référentiels configurés sur le nœud géré.

**Windows**  
Pour l'application de correctifs Windows, Systems Manager évalue les règles de référentiels de correctifs et la liste des correctifs approuvés et rejetés *directement dans le service*. Cette action est possible en raison du fait que les correctifs Windows sont tirés d'un même référentiel (Windows Update).

## Différence 2 : correctifs `Not Applicable`
<a name="not-applicable-diff"></a>

En raison du grand nombre de packages disponibles pour les systèmes d'exploitation Linux, Systems Manager ne signale aucun détail concernant les correctifs à l'état *Ne s'applique pas*. Par exemple, un correctif `Not Applicable` est un correctif pour le logiciel Apache lorsqu'Apache n'est pas installé sur l'instance. Systems Manager indique le nombre de `Not Applicable` correctifs dans le résumé, mais si vous appelez l'[DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API d'un nœud géré, les données renvoyées n'incluent pas les correctifs dont l'état est égal à`Not Applicable`. Depuis Windows, ce comportement est différent.

## Différence 3 : Prise en charge des documents SSM
<a name="document-support-diff"></a>

Le document Systems Manager `AWS-ApplyPatchBaseline` (document SSM) ne prend pas en charge les nœuds gérés Linux. Pour appliquer des référentiels de correctifs à des nœuds gérés Linux, macOS et Windows Server, le document SSM recommandé est `AWS-RunPatchBaseline`. Pour plus d’informations, consultez [Documents de commande SSM pour l’application de correctifs sur les nœuds gérés](patch-manager-ssm-documents.md) et [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Différence 4 : Correctifs d'applications
<a name="application-patches-diff"></a>

Le premier objectif de Patch Manager est d'appliquer des correctifs aux systèmes d'exploitation. Cependant, vous pouvez également utiliser Patch Manager pour appliquer des correctifs à certaines applications sur vos nœuds gérés.

**Linux**  
Sur les systèmes d'exploitation Linux, Patch Manager utilise les référentiels configurés pour les mises à jour et ne fait pas la différence entre les correctifs de systèmes d'exploitation et les correctifs d'applications. Vous pouvez utiliser Patch Manager pour définir les référentiels à partir desquels extraire les mises à jour. Pour de plus amples informations, veuillez consulter [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
Sur les nœuds gérés Windows Server, vous pouvez appliquer des règles d'approbation, ainsi que les exceptions de correctif *Approved (Approuvé)* et *Rejected (Rejeté)* pour les applications publiées par Microsoft, telles que Microsoft Word 2016 et Microsoft Exchange Server 2016. Pour de plus amples informations, veuillez consulter [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).

## Différence 5 : options de la liste des correctifs rejetés dans les référentiels de correctifs personnalisés
<a name="rejected-patches-diff"></a>

Lorsque vous créez un référentiel de correctifs personnalisé, vous pouvez spécifier un ou plusieurs correctifs pour une liste **Correctifs rejetés**. Pour les nœuds gérés par Linux, vous pouvez également choisir d’autoriser leur installation s’il s’agit de dépendances pour un autre correctif autorisé par le référentiel.

Cependant, Windows Server ne prend pas en charge le concept de dépendances de correctifs. Vous pouvez ajouter un correctif à la liste **Correctifs rejetés** dans un référentiel personnalisé pour Windows Server, mais le résultat dépend (1) du fait que le correctif rejeté est déjà installé ou non sur un nœud géré, et (2) de l’option que vous choisissez pour **Action sur les correctifs rejetés**.

Reportez-vous au tableau suivant pour plus de détails sur les options de correctifs rejetés sur Windows Server.


| Statut de l’installation | Option : « Autoriser en tant que dépendance » | Option : « Bloquer » | 
| --- | --- | --- | 
| Le correctif est déjà installé | Statut signalé : INSTALLED\$1OTHER | Statut signalé : INSTALLED\$1REJECTED | 
| Le correctif n’est pas encore installé | Correctif ignoré | Correctif ignoré | 

Chaque correctif pour Windows Server publié par Microsoft contient généralement toutes les informations nécessaires à la réussite de l’installation. Cependant, il peut arriver qu’un package prérequis soit nécessaire et que vous deviez l’installer manuellement. Patch Manager ne fournit pas d’informations sur ces prérequis. Pour plus d’informations, consultez [Dépannage des problèmes de Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) sur le site Web de Microsoft.