• 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.
# AWS Systems Manager Patch Manager
Patch Manager, un outil de AWS Systems Manager, automatise le processus d'application des correctifs aux nœuds gérés à la fois avec des mises à jour liées à la sécurité et d'autres types de mises à jour.
**Note**
Systems Manager prend en charge les *politiques de correctifs* dans Quick Setup, un outil d’ AWS Systems Manager. Nous recommandons d’utiliser des politiques de correctifs pour configurer vos opérations de correctifs. À l’aide d’une configuration de politique de correctifs unique, vous pouvez définir l’application de correctifs pour tous les comptes de toutes les régions de votre organisation ; uniquement pour les comptes et les régions de votre choix ; ou pour une seule paire compte-région. Pour de plus amples informations, veuillez consulter [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
Vous pouvez utiliser Patch Manager pour appliquer des correctifs pour les systèmes d'exploitation et les applications. (Sur Windows Server, la prise en charge des applications est limitée à des mises à jour pour les applications publiées par Microsoft.) Vous pouvez utiliser Patch Manager pour installer des Service Packs sur les nœuds Windows et procéder à des mises à niveau mineures sur les nœuds Linux. Vous pouvez appliquer des correctifs à des flottes d'instances Amazon Elastic Compute Cloud (Amazon EC2), d'appareils périphériques, de serveurs sur site et de machines virtuelles (VMs) par type de système d'exploitation. Cela inclut les versions prises en charge de plusieurs systèmes d'exploitation, comme indiqué dans [conditions préalables requises de l’Patch Manager](patch-manager-prerequisites.md). Vous pouvez scanner les instances pour afficher uniquement le rapport des correctifs manquants, ou scanner et installer automatiquement les correctifs manquants. Pour vos premiers pas dans Patch Manager, ouvrez [Systems Manager console](https://console.aws.amazon.com//systems-manager/patch-manager). Dans le panneau de navigation, sélectionnez **Patch Manager**.
AWS ne teste pas les correctifs avant de les rendre disponibles dansPatch Manager. Ne Patch Manager prend pas non plus en charge la mise à niveau des versions majeures des systèmes d'exploitation, telles que Windows Server 2016 à Windows Server 2019 ou Red Hat Enterprise Linux (RHEL) 7.0 vers RHEL 8.0.
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).
## Comment mon organisation peut-elle tirer parti de Patch Manager ?
Patch Manager automatise le processus d’application de correctifs aux nœuds gérés, aussi bien pour les mises à jour liées à la sécurité que pour les autres types de mises à jour. Il offre plusieurs avantages clés :
+ **Contrôle centralisé des correctifs** : avec les politiques de correctif, vous pouvez configurer des opérations d’application de correctifs récurrentes pour tous les comptes de toutes les régions de votre organisation, des comptes et des régions spécifiques, ou une seule paire compte-région.
+ **Opérations d’application de correctifs flexibles** : vous pouvez scanner les instances pour afficher uniquement le rapport des correctifs manquants, ou scanner et installer automatiquement les correctifs manquants.
+ **Rapports de conformité complets** : après les opérations d’analyse, vous pouvez consulter des informations détaillées sur les nœuds gérés qui ne sont pas en conformité pour les correctifs et sur les correctifs manquants.
+ **Prise en charge multiplateforme** : Patch Manager prend en charge plusieurs systèmes d’exploitation, y compris diverses distributions Linux, macOS et Windows Server.
+ **Référentiels de correctifs personnalisés** : vous pouvez définir ce qui constitue la conformité des correctifs pour votre entreprise grâce à des référentiels de correctifs personnalisés qui spécifient les correctifs dont l’installation est approuvée.
+ **Intégration avec d'autres AWS services** : Patch Manager s'intègre à AWS Organizations AWS Security Hub CSPM AWS CloudTrail, et AWS Config pour une gestion et une sécurité améliorées.
+ **Mises à niveau déterministes** : prise en charge des mises à niveau déterministes via des référentiels avec gestion des versions pour des systèmes d’exploitation comme Amazon Linux 2023.
## À qui est destiné Patch Manager ?
Patch Manager est conçu pour :
+ Administrateurs informatiques devant garantir la conformité des correctifs sur l’ensemble de leur parc de nœuds gérés
+ Responsables des opérations qui ont besoin d’une visibilité sur l’état de conformité des correctifs à travers l’ensemble de leur infrastructure
+ Architectes cloud qui souhaitent mettre en œuvre des solutions d’application de correctifs automatisées à grande échelle
+ DevOps ingénieurs qui ont besoin d'intégrer les correctifs dans leurs flux de travail opérationnels
+ Organisations ayant des déploiements multicomptes/multirégions et besoin d’une gestion centralisée des correctifs
+ Toute personne chargée de maintenir le niveau de sécurité et la santé opérationnelle des nœuds AWS gérés, des appareils périphériques, des serveurs sur site et des machines virtuelles
## Quelles sont les principales fonctionnalités Patch Manager ?
Patch Manager propose plusieurs fonctionnalités clés :
+ **Politiques de correctifs** — Configurez les opérations d'application de correctifs sur plusieurs Comptes AWS régions à l'aide d'une politique unique grâce à l'intégration avec AWS Organizations.
+ **Référentiels de correctifs personnalisés** : définissez les règles d’approbation automatique des correctifs quelques jours après leur publication, ainsi que les listes des correctifs approuvés et refusés.
+ **Plusieurs méthodes d’application de correctifs** : choisissez entre les politiques de correctif, les fenêtres de maintenance et les opérations « Appliquer le correctif maintenant » à la demande pour répondre à vos besoins spécifiques.
+ **Rapports de conformité** : générez des rapports détaillés sur le statut de conformité des correctifs, qui peuvent être envoyés à un compartiment Amazon S3 au format CSV.
+ **Prise en charge multiplateforme** : appliquez des correctifs aux systèmes d’exploitation et aux applications sur Windows Server, diverses distributions Linux et macOS.
+ **Flexibilité de planification** : définissez différents calendriers pour l’analyse et l’installation des correctifs à l’aide d’expressions CRON et de valeurs de déclenchement personnalisées.
+ **Hooks de cycle de vie** : exécutez des scripts personnalisés avant et après les opérations d’application de correctifs à l’aide des documents Systems Manager.
+ **Focalisation sur la sécurité** : par défaut, Patch Manager se concentre sur les mises à jour liées à la sécurité plutôt que sur l’installation de tous les correctifs disponibles.
+ **Contrôle du débit** : configurez la simultanéité et les seuils d’erreur pour les opérations d’application de correctifs afin de minimiser l’impact opérationnel.
## Qu’est-ce que la conformité dans Patch Manager ?
Le point de référence pour déterminer ce qui constitue la *conformité des correctifs* pour les nœuds gérés de vos flottes de Systems Manager n'est pas défini par AWS les fournisseurs de systèmes d'exploitation (OS) ou par des tiers tels que les sociétés de conseil en sécurité.
Vous définissez vous-même ce que signifie la conformité aux correctifs pour les nœuds gérés de votre organisation ou de votre compte dans un *référentiel de correctifs*. Un référentiel de correctifs est une configuration qui spécifie les règles selon lesquelles les correctifs doivent être installés sur un nœud géré. Un nœud géré est conforme en matière de correctifs lorsqu’il est à jour avec tous les correctifs qui répondent aux critères d’approbation que vous spécifiez dans la référentiel de correctifs.
Notez que la *conformité* à un référentiel de correctifs ne signifie pas nécessairement qu’un nœud géré est *sécurisé*. Conforme signifie que les correctifs définis par la référentiel de correctifs qui sont à la fois *disponibles* et *approuvés* ont été installés sur le nœud. La sécurité globale d’un nœud géré est déterminée par de nombreux facteurs extérieurs au-delà de la portée de Patch Manager. Pour de plus amples informations, veuillez consulter [Sécurité dans AWS Systems Manager](security.md).
Chaque référentiel de correctifs est une configuration pour un type de système d’exploitation (OS) pris en charge spécifique, comme Red Hat Enterprise Linux (RHEL), macOS ou Windows Server. Un référentiel de correctifs peut définir des règles d’application de correctifs pour toutes les versions prises en charge d’un système d’exploitation ou être limité à celles que vous spécifiez, comme RHEL 7.8. et RHEL 9.3.
Dans un référentiel de correctifs, vous pouvez spécifier que tous les correctifs de certaines classifications et de certains niveaux de gravité sont approuvés pour l’installation. Par exemple, vous pouvez inclure tous les correctifs classés comme `Security`, mais exclure d’autres classifications, comme `Bugfix` ou `Enhancement`. Et vous pouvez inclure tous les correctifs dont la gravité est `Critical` et en exclure d’autres, comme `Important` et `Moderate`.
Vous pouvez également définir des correctifs de manière explicite dans une base de correctifs en les ajoutant IDs à des listes de correctifs spécifiques à approuver ou à rejeter, par exemple `KB2736693` `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` pour Windows Server ou pour Amazon Linux 2023 (AL2023). Vous pouvez éventuellement spécifier un certain nombre de jours d’attente pour l’application d’un correctif une fois qu’un correctif est disponible. Pour Linux et macOS, vous avez la possibilité de spécifier une liste externe de correctifs à des fins de conformité (une liste de remplacement d’installation) au lieu de ceux définis par les règles du référentiel de correctifs.
Lorsqu’une opération d’application de correctifs est exécutée, Patch Manager compare les correctifs actuellement appliqués à un nœud géré à ceux qui doivent être appliqués conformément aux règles définies dans le référentiel de correctifs ou une liste de remplacement d’installation. Vous pouvez faire en sorte que Patch Manager n'affiche qu'un rapport sur les correctifs manquants (une opération `Scan`), ou que Patch Manager installe automatiquement tous les correctifs manquants sur un nœud géré (une opération `Scan and install`).
**Note**
Les données de conformité des correctifs représentent un point-in-time instantané de la dernière opération de correction réussie. Chaque rapport de conformité contient une heure de capture qui indique le moment où le statut de conformité a été calculé. Lorsque vous examinez les données de conformité, tenez compte du temps de capture pour déterminer si l'opération a été exécutée comme prévu.
Patch Manager fournit des référentiels de correctifs prédéfinis que vous pouvez utiliser pour vos opérations d’application de correctifs ; toutefois, ces configurations prédéfinies sont fournies à titre d’exemple et non en tant que meilleures pratiques recommandées. Nous vous recommandons de créer vos propres référentiels de correctifs personnalisés afin de mieux contrôler ce qui constitue la conformité des correctifs pour votre flotte.
Pour plus d’informations sur les référentiels de correctifs, consultez les rubriques suivantes :
+ [Référentiels de correctifs prédéfinis et personnalisés](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md)
+ [Affichage des lignes de base de correctifs AWS prédéfinies](patch-manager-view-predefined-patch-baselines.md)
+ [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md)
+ [Utilisation des rapports de conformité des correctifs](patch-manager-compliance-reports.md)
## Composants principaux
Avant de commencer à utiliser l’outil Patch Manager, vous devez vous familiariser avec certains des composants et fonctionnalités principaux des opérations d’application de correctifs de l’outil.
**Références de correctifs**
Patch Manager utilise des *référentiels de correctifs* qui incluent les règles d'approbation automatique des correctifs quelques jours après leur publication, ainsi que des listes facultatives des correctifs approuvés et refusés. Lorsqu'une opération d'application de correctifs est exécutée, Patch Manager compare les correctifs actuellement appliqués à un nœud géré à ceux qui doivent être appliqués conformément aux règles définies dans le référentiel de correctifs. Vous pouvez faire en sorte que Patch Manager n'affiche qu'un rapport sur les correctifs manquants (une opération `Scan`), ou que Patch Manager installe automatiquement tous les correctifs manquants sur un nœud géré (une opération `Scan and install`).
**Méthodes de fonctionnement d'application de correctifs**
Patch Manager propose actuellement quatre méthodes d'exécution des opérations `Scan` et `Scan and install` :
+ **(Recommandé) Une politique de correctifs configurée dans Quick Setup** — Sur la base de l'intégration avec AWS Organizations, une politique de correctifs unique peut définir des calendriers d'application des correctifs et des lignes de base de correctifs pour l'ensemble de l'organisation, y compris plusieurs comptes Comptes AWS et tous Régions AWS ceux sur lesquels ces comptes opèrent. Une politique de correctifs peut également cibler uniquement certaines unités organisationnelles (OUs) d'une organisation. Vous pouvez utiliser une seule politique de correctifs pour effectuer des analyses et des installations selon des planifications différentes. Pour plus d’informations, consultez [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md) et [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
+ **Une option de gestion des hôtes configurée dans Quick Setup** — Les configurations de gestion des hôtes sont également prises en charge par l'intégration avec AWS Organizations, ce qui permet d'exécuter une opération d'application de correctifs pour une organisation entière au maximum. Toutefois, cette option se limite à rechercher les correctifs manquants à l'aide du référentiel de correctifs par défaut actuel et à fournir des résultats dans des rapports de conformité. Cette méthode de fonctionnement ne permet pas d'installer de correctifs. Pour de plus amples informations, veuillez consulter [Configurer la gestion des hôtes Amazon EC2 à l’aide d’Quick Setup](quick-setup-host-management.md).
+ **Fenêtre de maintenance pour exécuter une tâche de correctif `Scan` ou `Install`** : une fenêtre de maintenance, que vous configurez dans l’outil Systems Manager appelé Maintenance Windows, peut être configurée pour exécuter différents types de tâches selon une planification que vous définissez. Une tâche de type Run Command peut être utilisée pour exécuter des tâches `Scan` ou `Scan and install` sur un ensemble de nœuds gérés de votre choix. Chaque tâche de la fenêtre de maintenance peut cibler les nœuds gérés en une seule Compte AWSRégion AWS paire. Pour de plus amples informations, veuillez consulter [Tutoriel : créer une fenêtre de maintenance pour l’application de correctifs à l’aide de la console](maintenance-window-tutorial-patching.md).
+ **Opération **Corriger maintenant** à la demande dans Patch Manager** : l’option **Corriger maintenant** vous permet de contourner les configurations de planification lorsque vous devez appliquer des correctifs à des nœuds gérés le plus rapidement possible. À l'aide de **Patch now**, vous pouvez spécifier s'il faut exécuter l'opération `Scan` ou `Scan and install` et sur quels nœuds gérés l'exécuter. Vous pouvez également choisir d’exécuter les documents Systems Manager (documents SSM) en tant que hooks de cycle de vie lors de l’application de correctifs. Chaque opération **Patch now** peut cibler les nœuds gérés en une seule Compte AWSRégion AWS paire. Pour de plus amples informations, veuillez consulter [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md).
**Rapports de conformité**
Après une opération `Scan`, vous pouvez utiliser la console Systems Manager pour afficher des informations sur les nœuds gérés qui ne sont pas conformes aux correctifs et sur les correctifs manquants sur chacun de ces nœuds. Vous pouvez également générer des rapports de conformité des correctifs au format .csv, qui sont envoyés à un compartiment Amazon Simple Storage Service (Amazon S3) de votre choix. Vous pouvez générer des rapports ponctuels ou selon un calendrier régulier. Pour un nœud géré individuel, les rapports contiennent les détails de tous les correctifs relatifs à ce nœud. Pour un ensemble de nœuds gérés, le rapport contient seulement un résumé indiquant le nombre de correctifs manquants. Une fois le rapport généré, vous pouvez utiliser un outil tel qu'Amazon Quick pour importer et analyser les données. Pour de plus amples informations, veuillez consulter [Utilisation des rapports de conformité des correctifs](patch-manager-compliance-reports.md).
**Note**
Un élément de conformité généré par l'utilisation d'une politique de correctifs a le type d'exécution `PatchPolicy`. Un élément de conformité qui n'est pas généré lors d'une opération de politique de correctifs a le type d'exécution `Command`.
**Intégrations**
Patch Managers'intègre aux autres éléments suivants Services AWS :
+ **Gestion des identités et des accès AWS (IAM)** — Utilisez IAM pour contrôler quels utilisateurs, groupes et rôles ont accès aux Patch Manager opérations. Pour plus d’informations, consultez [Fonctionnement d’AWS Systems Manager avec IAM](security_iam_service-with-iam.md) et [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
+ **AWS CloudTrail**— CloudTrail À utiliser pour enregistrer un historique vérifiable des événements liés aux opérations d'application de correctifs initiés par des utilisateurs, des rôles ou des groupes. Pour de plus amples informations, veuillez consulter [Journalisation des appels d' AWS Systems Manager API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**— Les données de conformité des correctifs Patch Manager peuvent être envoyées à AWS Security Hub CSPM. Security Hub CSPM vous donne une vue complète de vos alertes de sécurité prioritaires et de l'état de conformité. Il surveille également le statut d'application des correctifs de votre flotte. Pour de plus amples informations, veuillez consulter [Intégration Patch Manager avec AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
+ **AWS Config**— Configurez l'enregistrement AWS Config pour afficher les données de gestion des instances Amazon EC2 dans le Patch Manager tableau de bord. Pour de plus amples informations, veuillez consulter [Affichage des résumés du tableau de bord des correctifs](patch-manager-view-dashboard-summaries.md).
**Topics**
+ [Comment mon organisation peut-elle tirer parti de Patch Manager ?](#how-can-patch-manager-benefit-my-organization)
+ [À qui est destiné Patch Manager ?](#who-should-use-patch-manager)
+ [Quelles sont les principales fonctionnalités Patch Manager ?](#what-are-the-main-features-of-patch-manager)
+ [Qu’est-ce que la conformité dans Patch Manager ?](#patch-manager-definition-of-compliance)
+ [Composants principaux](#primary-components)
+ [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md)
+ [conditions préalables requises de l’Patch Manager](patch-manager-prerequisites.md)
+ [Fonctionnement des opérations Patch Manager](patch-manager-patching-operations.md)
+ [Documents de commande SSM pour l’application de correctifs sur les nœuds gérés](patch-manager-ssm-documents.md)
+ [Références de correctifs](patch-manager-patch-baselines.md)
+ [Utilisation de Kernel Live Patching sur des nœuds gérés Amazon Linux 2](patch-manager-kernel-live-patching.md)
+ [Utilisation des ressources Patch Manager et de la conformité en utilisant la console](patch-manager-console.md)
+ [Travailler avec des ressources Patch Manager à l’aide de l’AWS CLI](patch-manager-cli-commands.md)
+ [Tutoriels AWS Systems Manager Patch Manager](patch-manager-tutorials.md)
+ [Résolution des problèmes de Patch Manager](patch-manager-troubleshooting.md)
# Configurations de la politique de correctifs dans Quick Setup
AWS recommande l'utilisation de *politiques de correctifs* pour configurer les correctifs pour votre organisation et Comptes AWS. Les politiques de correctifs ont été introduites dans Patch Manager en décembre 2022.
Une politique de correctifs est une configuration que vous définissez à l’aide de Quick Setup, un outil d’ AWS Systems Manager. Les politiques de correctif fournissent un contrôle plus étendu et plus centralisé de vos opérations d'application de correctifs qu'avec les méthodes précédentes. Les politiques de correctif peuvent être utilisées avec [tous les systèmes d'exploitation pris en charge par Patch Manager](patch-manager-prerequisites.md#pm-prereqs), y compris les versions prises en charge de Linux, macOS et Windows Server. Pour obtenir des instructions sur la création d’une politique de correctifs, consultez [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md).
## Principales fonctionnalités des politiques de correctif
Au lieu d'utiliser d'autres méthodes pour appliquer des correctifs à vos nœuds, utilisez une politique de correctifs pour tirer parti des principales fonctionnalités suivantes :
+ **Configuration unique** : la configuration des opérations d'application de correctifs à l'aide d'une fenêtre de maintenance ou d'une association State Manager peut requérir plusieurs tâches dans différentes parties de la console Systems Manager. À l'aide d'une politique de correctifs, toutes vos opérations d'application de correctifs peuvent être configurées dans un seul assistant.
+ **Support multicompte/multirégion** : en utilisant une fenêtre de maintenance, une State Manager association ou la fonctionnalité **Patch now** dansPatch Manager, vous êtes limité à cibler les nœuds gérés en une seule paire. Compte AWSRégion AWS Si vous utilisez plusieurs comptes et régions, vos tâches de configuration et de maintenance peuvent prendre beaucoup de temps, car vous devez effectuer des tâches de configuration dans chaque paire compte-région. Toutefois, si vous en utilisez AWS Organizations, vous pouvez configurer une politique de correctif qui s'applique à tous vos nœuds gérés dans l'ensemble de votre Comptes AWS. Régions AWS Ou, si vous le souhaitez, une politique de correctifs ne peut s'appliquer qu'à certaines unités organisationnelles (OUs) des comptes et des régions de votre choix. Une politique de correctifs peut également s'appliquer à un seul compte local, si vous le souhaitez.
+ **Assistance à l'installation au niveau de l'organisation** : l'option de configuration de gestion des hôtes existante dans Quick Setup permet d'effectuer une analyse quotidienne de la conformité aux correctifs de vos nœuds gérés. Toutefois, cette analyse est effectuée à une heure prédéterminée et n'aboutit qu'à des informations de conformité aux correctifs. Aucune installation de correctif n'est effectuée. À l'aide d'une politique de correctifs, vous pouvez spécifier différentes planifications d'analyse et d'installation. Vous pouvez également choisir la fréquence et l'heure de ces opérations à l'aide d'expressions CRON ou Rate personnalisées. Par exemple, vous pouvez rechercher les correctifs manquants chaque jour afin de bénéficier d'informations de conformité régulièrement mises à jour. Toutefois, votre planification d'installation peut se limiter à une fois par semaine afin d'éviter des temps d'arrêt indésirables.
+ **Sélection simplifiée des référentiels de correctifs** : les politiques de correctif intègrent toujours des référentiels de correctifs, et aucune modification n'a été apportée à la façon dont les référentiels de correctifs sont configurés. Toutefois, lorsque vous créez ou mettez à jour une politique de correctif, vous pouvez sélectionner la ligne de base AWS gérée ou personnalisée que vous souhaitez utiliser pour chaque type de système d'exploitation (OS) dans une liste unique. Il n'est pas nécessaire de spécifier le référentiel par défaut pour chaque type de système d'exploitation dans des tâches distinctes.
**Note**
Lors de l'exécution d'opérations d'application des correctifs basées sur une politique de correctifs, celles-ci utilisent le document SSM `AWS-RunPatchBaseline`. Pour de plus amples informations, veuillez consulter [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
**Informations connexes**
[Déployez de manière centralisée les opérations de correction au sein de votre AWS organisation à l'aide de Systems Manager Quick Setup](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) (blog sur les opérations et les migrations dans le AWS cloud)
## Autres différences avec les politiques de correctif
Voici d'autres différences à noter lorsque vous utilisez des politiques de correctif au lieu des méthodes précédentes de configuration de l'application des correctifs :
+ **Aucun groupe de correctifs requis** : lors des opérations d'application des correctifs précédentes, vous pouviez baliser plusieurs nœuds pour qu'ils appartiennent à un groupe de correctifs, puis spécifier le référentiel de correctifs à utiliser pour ce groupe de correctifs. Si aucun groupe de correctifs n'a été défini, Patch Manager a corrigé les instances avec le référentiel de correctifs par défaut actuel pour le type de système d'exploitation. Grâce aux politiques de correctif, il n'est plus nécessaire de configurer et de gérer des groupes de correctifs.
**Note**
La fonctionnalité de groupes de correctifs n’est pas prise en charge dans la console pour les paires compte-région qui n’utilisaient pas encore de groupes de correctifs avant le lancement de la prise en charge des politiques de correctifs le 22 décembre 2022. La fonctionnalité de groupes de correctifs est toujours disponible dans les paires compte-région qui ont commencé à utiliser les groupes de correctifs avant cette date.
+ **Page « Configurer l'application de correctifs » supprimée** : avant la publication des politiques de correctif, vous pouviez spécifier des valeurs par défaut pour les nœuds à corriger, une planification d'application des correctifs et une opération d'application des correctifs sur la page **Configure patching** (Configurer l'application des correctifs). Cette page a été supprimée de Patch Manager. Ces options sont désormais spécifiées dans les politiques de correctif.
+ **Pas de support « Patch now »** : la possibilité de patcher les nœuds à la demande est toujours limitée à une seule Compte AWSRégion AWS paire à la fois. Pour plus d'informations, consultez [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md).
+ **Politiques de correctif et informations de conformité** : lorsque vos nœuds gérés sont analysés à des fins de conformité, conformément à une configuration de politique d'application de correctifs, les données de conformité sont mises à votre disposition. Vous pouvez consulter et utiliser les données de la même manière qu'avec les autres méthodes d'analyse de conformité. Bien que vous puissiez configurer une politique de correctifs pour l'ensemble d'une organisation ou pour plusieurs unités organisationnelles, les informations de conformité sont signalées individuellement pour chaque Compte AWSRégion AWS paire. Pour de plus amples informations, veuillez consulter [Utilisation des rapports de conformité des correctifs](patch-manager-compliance-reports.md).
+ **Statut de conformité de l’association et politiques de correctifs** : le statut de l’application des correctifs pour un nœud géré soumis à une politique de correctifs Quick Setup correspond au statut de l’exécution de l’association State Manager pour ce nœud. Si le statut d’exécution de l’association est `Compliant`, le statut d’application des correctifs pour le nœud géré est également marqué `Compliant`. Si le statut d’exécution de l’association est `Non-Compliant`, le statut d’application des correctifs pour le nœud géré est également marqué `Non-Compliant`.
## Régions AWS pris en charge pour les politiques de correctifs
Actuellement, les configurations d'application de correctifs de Quick Setup sont prises en charge dans les régions suivantes :
+ USA Est (Ohio) (us-east-2)
+ USA Est (Virginie du Nord) (us-east-1)
+ USA Ouest (Californie du Nord) (us-west-1)
+ USA Ouest (Oregon) (us-west-2)
+ Asie-Pacifique (Mumbai) (ap-south-1)
+ Asie-Pacifique (Séoul) (ap-northeast-2)
+ Asie-Pacifique (Singapour) (ap-southeast-1)
+ Asie-Pacifique (Sydney) (ap-southeast-2)
+ Asie-Pacifique (Tokyo) (ap-northeast-1)
+ Canada (Centre) (ca-central-1)
+ Europe (Francfort) (eu-central-1)
+ Europe (Irlande) (eu-west-1)
+ Europe (Londres) (eu-west-2)
+ Europe (Paris) (eu-west-3)
+ Europe (Stockholm) (eu-north-1)
+ Amérique du Sud (São Paulo) (sa-east-1)
# conditions préalables requises de l’Patch Manager
Assurez-vous que vous avez rempli les conditions requises avant d'utiliser Patch Manager un outil dans AWS Systems Manager.
**Topics**
+ [Version de l’SSM Agent](#agent-versions)
+ [Version de Python](#python-version)
+ [Exigences d'emballage supplémentaires](#additional-package-requirements)
+ [Connectivité à la source de correctifs](#source-connectivity)
+ [Accès aux points de terminaison S3](#s3-endpoint-access)
+ [Autorisations d’installer les correctifs localement](#local-installation-permissions)
+ [Systèmes d'exploitation pris en charge pour Patch Manager](#supported-os)
## Version de l’SSM Agent
La version 2.0.834.0 (ou version ultérieure) de SSM Agent doit être exécutée sur les nœuds gérés que vous souhaitez gérer avec Patch Manager.
**Note**
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.
## Version de Python
Pour macOS et la plupart des systèmes d'exploitation Linux (OSs), prend Patch Manager actuellement en charge les versions 2.6 à 3.12 de Python. Les AlmaLinuxDebian Server, et Ubuntu Server OSs nécessitent une version prise en charge de Python 3 (3.0 - 3.12).
## Exigences d'emballage supplémentaires
Pour les systèmes d'exploitation basés sur DNF, les `unzip` utilitaires`zstd`,`xz`, et peuvent être nécessaires pour décompresser les informations du référentiel et les fichiers correctifs. Les systèmes d'exploitation basés sur DNF incluent Amazon Linux 2023, les versions Red Hat Enterprise Linux 8 et ultérieures, les versions Oracle Linux 8 et ultérieures Rocky Linux AlmaLinux, et CentOS 8 et les versions ultérieures. Si vous constatez une erreur similaire à `No such file or directory: b'zstd'` ou des échecs de correction dus à une absence`unzip`, vous devez installer ces utilitaires. `No such file or directory: b'unxz'` `zstd``xz`, et `unzip` peut être installé en exécutant ce qui suit :
```
dnf install zstd xz unzip
```
## Connectivité à la source de correctifs
Si vos nœuds gérés ne sont pas directement connectés à Internet et que vous utilisez une instance d'Amazon Virtual Private Cloud (Amazon VPC) avec un point de terminaison d’un VPC, vous devez vous assurer que les nœuds ont accès aux référentiels de correctifs sources. Sur les nœuds Linux, les correctifs sont généralement téléchargés à partir des référentiels distants configurés sur le nœud. Par conséquent, le nœud doit être en mesure de se connecter aux référentiels afin que les correctifs puissent être appliqués. Pour de plus amples informations, veuillez consulter [Sélection des correctifs de sécurité](patch-manager-selecting-patches.md).
Lorsque vous appliquez des correctifs à un nœud qui s'exécute dans un environnement IPv6 réservé, assurez-vous que le nœud est connecté à la source du correctif. Vous pouvez vérifier le Run Command résultat de l'exécution du correctif pour vérifier la présence d'avertissements concernant des référentiels inaccessibles. Pour les systèmes d'exploitation basés sur DNF, il est possible de configurer les référentiels indisponibles pour qu'ils soient ignorés lors de l'application des correctifs si l'`skip_if_unavailable`option est définie sur moins. `True` `/etc/dnf/dnf.conf` Les systèmes d'exploitation basés sur DNF incluent Amazon Linux 2023, les versions Red Hat Enterprise Linux 8 et ultérieures, les versions Oracle Linux 8 et ultérieures Rocky Linux AlmaLinux, et CentOS 8 et les versions ultérieures. Sur Amazon Linux 2023, l'`skip_if_unavailable`option est définie sur `True` par défaut.
**CentOS Stream : activez l’indicateur `EnableNonSecurity`**
Les nœuds CentOS Stream utilisent DNF comme gestionnaire de package, qui 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.
**Windows Server : assurez la connectivité à Windows Update Catalog ou à Windows Server Update Services (WSUS)**
Les nœuds gérés Windows Server doivent être en mesure de se connecter au catalogue Windows Update ou à Windows Server Update Services (WSUS). Vérifiez que vos nœuds sont connectés au [catalogue Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) via une passerelle Internet, une instance NAT ou une passerelle NAT. Si vous utilisez WSUS, vérifiez que le nœud est connecté au serveur WSUS de votre environnement. Pour de plus amples informations, veuillez consulter [Problème : le nœud géré n'a pas accès au catalogue Windows Update ou à WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).
## Accès aux points de terminaison S3
Que vos nœuds gérés fonctionnent sur un réseau privé ou public, sans accès aux compartiments Amazon Simple Storage Service (Amazon S3) AWS gérés requis, les opérations de correction échouent. Pour obtenir des informations sur les compartiments S3 auxquels vos nœuds gérés doivent avoir accès, consultez [SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) et [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md).
## Autorisations d’installer les correctifs localement
Sur les systèmes d’exploitation Windows Server et Linux, Patch Manager assume les comptes d’utilisateur Administrateur et racine, respectivement, pour installer les correctifs.
Sur macOS, cependant, pour Brew et Brew Cask, Homebrew ne prend pas en charge l’exécution de ses commandes sous le compte d’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. Par conséquent, pour pouvoir installer des correctifs, le propriétaire du répertoire `homebrew` doit également disposer des autorisations de propriétaire récursives pour le répertoire `/usr/local`.
**Astuce**
La commande suivante fournit cette autorisation à l’utilisateur spécifié :
```
sudo chown -R $USER:admin /usr/local
```
## Systèmes d'exploitation pris en charge pour Patch Manager
L’outil Patch Manager peut ne pas prendre pas en charge les mêmes versions des systèmes d’exploitation que les autres outils de Systems Manager. (Pour obtenir la liste complète des systèmes d'exploitation pris en charge par Systems Manager, consultez [Systèmes d'exploitation pris en charge pour Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Par conséquent, assurez-vous que les nœuds gérés que vous souhaitez utiliser avec Patch Manager exécutent l'un des systèmes d'exploitation répertoriés dans le tableau suivant.
**Note**
Patch Manager s’appuie sur les référentiels de correctifs configurés sur un nœud géré, tels que Windows Update Catalog et Windows Server Update Services for Windows, pour récupérer les correctifs disponibles à installer. Par conséquent, pour les versions de systèmes d’exploitation en fin de vie (EOL), si aucune nouvelle mise à jour n’est disponible, Patch Manager peut ne pas être en mesure de signaler les nouvelles mises à jour. Cela peut être dû au fait qu’aucune nouvelle mise à jour n’est publiée par le gestionnaire de la distribution Linux, Microsoft ou Apple, ou au fait que le nœud géré ne dispose pas de la licence appropriée pour accéder aux nouvelles mises à jour.
Nous vous recommandons vivement d'éviter d'utiliser des versions de système d'exploitation ayant atteint End-of-Life (EOL). Les fournisseurs de systèmes d'exploitation, y compris, ne fournissent AWS généralement pas de correctifs de sécurité ou d'autres mises à jour pour les versions qui ont atteint la fin de vie. Le fait de continuer à utiliser un système EOL augmente considérablement le risque de ne pas pouvoir appliquer les mises à niveau, y compris les correctifs de sécurité, et d'autres problèmes opérationnels. AWS ne teste pas les fonctionnalités de Systems Manager sur les versions du système d'exploitation ayant atteint la fin de vie.
Patch Manager rapporte le statut de conformité par rapport aux correctifs disponibles sur le nœud géré. Par conséquent, si une instance exécute un système d’exploitation EOL et qu’aucune mise à jour n’est disponible, Patch Manager peut indiquer que le nœud est conforme, en fonction des référentiels de correctifs configurés pour l’opération de correctifs.
| Système d’exploitation | Détails |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS est pris en charge uniquement pour les instances Amazon EC2.* 13,0—13,7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) mises à jour du système d'exploitation macOS Patch Manager ne prend pas en charge les mises à jour ou les mises à niveau du système d’exploitation (SE) pour macOS, par exemple, de la version 13.1 à la version 13.2. Pour effectuer des mises à jour de la version du système d'exploitation sur macOS, nous vous recommandons d'utiliser les mécanismes intégrés de mise à niveau du système d'exploitation d'Apple. Pour plus d'informations, consultez [Gestion des appareils](https://developer.apple.com/documentation/devicemanagement) (français non garanti) sur le site web de la documentation du développeur Apple. Prise en charge de Homebrew Patch Manager nécessite que Homebrew, le système de gestion de packages logiciels open source, soit installé à l’un des emplacements d’installation par défaut suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-prerequisites.html) Les opérations d’application de correctifs utilisant Patch Manager ne fonctionnent pas correctement lorsque Homebrew n’est pas installé. Prise en charge de la région macOSn'est pas pris en charge dans tous les cas Régions AWS. Pour plus d’informations sur la prise en charge d’Amazon EC2 pour macOS, consultez [Instances Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) dans le *Guide de l’utilisateur Amazon EC2*. Des appareils macOS Edge SSM Agentpour les appareils AWS IoT Greengrass principaux n'est pas pris en charge surmacOS. Vous ne pouvez pas utiliser Patch Manager pour appliquer des correctifs aux appareils de périphérie macOS. |
| Windows | Windows Server2012 à Windows Server 2025, y compris les versions R2. SSM Agentpour les appareils AWS IoT Greengrass principaux n'est pas pris en charge sous Windows 10. Vous ne pouvez pas utiliser Patch Manager pour appliquer des correctifs aux appareils de périphérie Windows 10. Prise en charge de Windows Server 2012 et 2012 R2 Windows Server 2012 et 2012 R2 ont atteint la fin du support le 10 octobre 2023. Pour utiliser Patch Manager ces versions, nous vous recommandons également d'utiliser les mises à jour de sécurité étendues (ESUs) de Microsoft. Pour plus d’informations, consultez [Windows Server 2012 et 2012 R2 atteignant la fin du support](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support) sur le site Web de Microsoft. |
# Fonctionnement des opérations Patch Manager
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
**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é
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)
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
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
**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
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
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
**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
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
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
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
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
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
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
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.
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
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`
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
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
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
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.
# Documents de commande SSM pour l’application de correctifs sur les nœuds gérés
Cette rubrique décrit les neuf documents Systems Manager (documents SSM) actuellement disponibles pour vous aider à appliquer les dernières mises à jour de sécurité à vos nœuds gérés.
Nous vous recommandons d'utiliser cinq de ces documents seulement pour vos opérations d'application de correctifs. Conjointement, ces cinq documents SSM vous fournissent une gamme complète d'options de correctifs à l'aide d' AWS Systems Manager. Quatre de ces documents ont été publiés plus tard que les quatre documents SSM existants qu'ils remplacent et représentent les développements ou consolidations de fonctionnalités.
**Documents SSM recommandés pour l’application de correctifs**
Nous vous recommandons d’utiliser les cinq documents SSM suivants pour vos opérations de correctifs.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documents SSM hérités pour l’application de correctifs**
Les quatre documents SSM hérités suivants restent disponibles dans certaines Régions AWS , mais ne sont plus mis à jour ni pris en charge. Il n'est pas garanti que ces documents fonctionnent uniquement dans IPv6 les environnements et le support IPv4. Il n’est pas garanti qu’ils fonctionnent dans tous les scénarios et risquent de perdre leur support à l’avenir. Nous vous recommandons de ne pas activer ces documents pour les opérations d’application de correctifs.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Pour connaître les étapes à suivre pour configurer les opérations d'application de correctifs dans un environnement uniquement compatible, consultez IPv6. [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md)
Consultez les sections suivantes pour plus d'informations sur l'utilisation de ces documents SSM lors de vos opérations d'application de correctifs.
**Topics**
+ [Documents SSM recommandés pour l'application de correctifs aux nœuds gérés](#patch-manager-ssm-documents-recommended)
+ [Documents SSM hérités pour l'application de correctifs aux nœuds gérés](#patch-manager-ssm-documents-legacy)
+ [Limitations connues des documents SSM pour l'application de correctifs aux nœuds gérés](#patch-manager-ssm-documents-known-limitations)
+ [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Exemple de scénario d'utilisation du InstallOverrideList paramètre dans `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Utilisation du BaselineOverride paramètre](patch-manager-baselineoverride-parameter.md)
## Documents SSM recommandés pour l'application de correctifs aux nœuds gérés
L'utilisation des cinq documents SSM suivants est recommandée pour l'application de correctifs aux nœuds gérés.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Prend en charge la configuration des fonctions de base de Windows Update et leur utilisation pour installer les mises à jour automatiquement (ou pour désactiver les mises à jour automatiques). Disponible dans toutes les Régions AWS.
Ce document SSM invite Windows Update à télécharger et installer les mises à jour spécifiées et à redémarrer les nœuds gérés, selon les besoins. Utilisez ce document avec State Manager un outil pour vous assurer que Windows Update conserve sa configuration. AWS Systems Manager Vous pouvez également l'exécuter manuellement à l'aide Run Command d'un outil intégré AWS Systems Manager pour modifier la configuration de Windows Update.
Les paramètres disponibles dans ce document prennent en charge la spécification d'une catégorie de mises à jour à installer (ou si les mises à jour automatiques doivent être désactivées), ainsi que la spécification du jour de la semaine et l'heure de la journée pour exécuter les opérations d'application des correctifs. Ce document SSM est particulièrement utile si vous n'avez pas besoin de contrôler strictement les mises à jour Windows et si vous n'avez pas besoin de collecter des informations de conformité.
**Remplace les documents SSM existants :**
+ *Aucun*
### `AWS-InstallWindowsUpdates`
Installe les mises à jour sur un nœud géré Windows Server. Disponible dans toutes les Régions AWS.
Ce document SSM fournit des fonctionnalités de correctifs de base pour les cas suivants : lorsque vous souhaitez installer une mise à jour spécifique (à l'aide du paramètre `Include Kbs`) ou installer des correctifs avec les classifications ou catégories spécifiques, mais si vous n'avez pas besoin des informations de conformité des correctifs.
**Remplace les documents SSM existants :**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Les trois documents existants réalisent différentes fonctions, mais vous pouvez obtenir les mêmes résultats en utilisant différents paramètres avec le nouveau document SSM `AWS-InstallWindowsUpdates`. La configuration des paramètres est décrite dans [Documents SSM hérités pour l'application de correctifs aux nœuds gérés](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Installe des correctifs sur vos nœuds gérés ou analyse les nœuds pour déterminer s'il manque des correctifs qualifiés. Disponible dans toutes les Régions AWS.
`AWS-RunPatchBaseline` vous permet de contrôler les approbations de correctifs à l'aide du référentiel de correctifs spécifié « par défaut » pour un type de système d'exploitation. informations de conformité des correctifs que vous pouvez consulter à l'aide des outils de conformité Systems Manager. Ces outils vous fournissent des informations sur l'état de conformité de vos nœuds gérés en matière de correctifs, comme les nœuds auxquels il manque des correctifs et la nature de ces correctifs. Lorsque vous utilisez `AWS-RunPatchBaseline`, les informations de conformité des correctifs sont enregistrées à l'aide de la commande d'API `PutInventory`. Pour les systèmes d'exploitation Linux, des informations de conformité sont fournies sur les correctifs provenant à la fois du référentiel source par défaut configuré sur un nœud géré et de tout autre référentiel source spécifié par vos soins dans un référentiel de correctifs personnalisé. Pour en savoir plus sur les autres référentiels source, consultez [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md). Pour plus d'informations sur les outils de conformité Systems Manager, consultez [Conformité d'AWS Systems Manager](systems-manager-compliance.md).
**Remplace les documents existants :**
+ `AWS-ApplyPatchBaseline`
Le document hérité `AWS-ApplyPatchBaseline` s'applique uniquement aux nœuds gérés Windows Server et ne prévoit pas de prise en charge des correctifs d'application. Le nouveau document `AWS-RunPatchBaseline` fournit le même support pour les systèmes Windows et Linux. La version 2.0.834.0 ou une version ultérieure de SSM Agent pour pouvoir utiliser le document `AWS-RunPatchBaseline`.
Pour plus d'informations sur le document SSM `AWS-RunPatchBaseline`, consultez [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Installe les correctifs sur les instances ou analyse les instances afin de déterminer s'il manque des correctifs qualifiés. Disponible dans toutes les Régions AWS commerciales.
Des différences importantes distinguent `AWS-RunPatchBaselineAssociation` de `AWS-RunPatchBaseline` :
+ `AWS-RunPatchBaselineAssociation` est principalement destinée à une utilisation avec les associations State Manager créées avec Quick Setup, un outil d’ AWS Systems Manager. Précisément, lorsque vous utilisez le type de configuration de gestion des hôtes Quick Setup, si vous sélectionnez l'option **Scan instances for missing patches daily** (Analyser quotidiennement les instances pour les correctifs manquants), le système utilise `AWS-RunPatchBaselineAssociation` pour l'opération.
Dans la plupart des cas, cependant, lors de la configuration de vos propres opérations d'application de correctifs, sélectionnez [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) de préférence à `AWS-RunPatchBaselineAssociation`.
Pour plus d'informations, consultez les rubriques suivantes :
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` prend en charge l'utilisation de balises pour identifier le référentiel de correctifs à utiliser avec un ensemble de cibles lors de son exécution.
+ Pour les opérations d'application de correctifs qui utilisent `AWS-RunPatchBaselineAssociation`, les données sur la conformité des correctifs sont compilées en fonction d'une association State Manager particulière. Les données sur la conformité des correctifs collectées lorsque `AWS-RunPatchBaselineAssociation`s'exécute sont enregistrées avec la commande d'API `PutComplianceItems` plutôt qu'avec `PutInventory`. De cette façon, les données de conformité qui ne sont pas associées à cette association particulière ne sont pas écrasées.
Pour les systèmes d'exploitation Linux, des informations de conformité sont fournies pour les correctifs à la fois par le référentiel source par défaut configuré sur une instance et par les autres référentiels source que vous spécifiez dans un référentiel de correctifs personnalisée. Pour en savoir plus sur les autres référentiels source, consultez [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md). Pour plus d'informations sur les outils de conformité Systems Manager, consultez [Conformité d'AWS Systems Manager](systems-manager-compliance.md).
**Remplace les documents existants :**
+ **Aucun**
Pour plus d'informations sur le document SSM `AWS-RunPatchBaselineAssociation`, consultez [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Installe les correctifs sur vos nœuds gérés, ou analyse les nœuds afin de déterminer s'il manque des correctifs qualifiés, avec des hooks facultatifs que vous pouvez utiliser pour exécuter des documents SSM à trois stades du cycle d'application des correctifs. Disponible dans toutes les Régions AWS commerciales. Non pris en charge sur macOS.
`AWS-RunPatchBaselineWithHooks` diffère de `AWS-RunPatchBaseline` par son opération `Install`.
`AWS-RunPatchBaselineWithHooks` prend en charge les hooks de cycle de vie qui s'exécutent aux stades désignés lors de l'application de correctifs sur des nœuds gérés. Comme l'installation des correctifs exige parfois le redémarrage des nœuds gérés, l'opération d'application des correctifs se décompose en deux événements, pour un total de trois hooks qui prennent en charge la fonctionnalité personnalisée. Le premier hook précède l'opération `Install with NoReboot`. Le deuxième hook suit l'opération `Install with NoReboot`. Le troisième hook est disponible après le redémarrage du nœud.
**Remplace les documents existants :**
+ **Aucun**
Pour plus d'informations sur le document SSM `AWS-RunPatchBaselineWithHooks`, consultez [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documents SSM hérités pour l'application de correctifs aux nœuds gérés
Les quatre documents SSM suivants sont encore disponibles dans certaines Régions AWS. Cependant, ils ne sont plus mis à jour et pourraient ne plus être pris en charge à l’avenir, c’est pourquoi nous ne recommandons pas leur utilisation. Utilisez plutôt les documents décrits dans [Documents SSM recommandés pour l'application de correctifs aux nœuds gérés](#patch-manager-ssm-documents-recommended).
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Prend uniquement en charge les nœuds gérés Windows Server, mais n'inclut pas la prise en charge des correctifs d'application figurant dans le référentiel de remplacement, `AWS-RunPatchBaseline`. Non disponible en cas de Régions AWS lancement après août 2017.
**Note**
Le document de remplacement de ce document SSM, `AWS-RunPatchBaseline` nécessite une version 2.0.834.0 ou une version ultérieure de SSM Agent. Vous pouvez utiliser le document `AWS-UpdateSSMAgent` pour procéder à la mise à jour des nœuds gérés vers la dernière version de l'agent.
### `AWS-FindWindowsUpdates`
Remplacé par `AWS-InstallWindowsUpdates`, qui peut effectuer toutes les mêmes actions. Non disponible en cas de Régions AWS lancement après avril 2017.
Pour obtenir le même résultat qu'avec le document SSM existant, utilisez la configuration de paramètres suivante avec le document de remplacement recommandé, `AWS-InstallWindowsUpdates` :
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Remplacé par `AWS-InstallWindowsUpdates`, qui peut effectuer toutes les mêmes actions. Non disponible dans les versions Régions AWS lancées après avril 2017.
Pour obtenir le même résultat qu'avec le document SSM existant, utilisez la configuration de paramètres suivante avec le document de remplacement recommandé, `AWS-InstallWindowsUpdates` :
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Remplacé par `AWS-InstallWindowsUpdates`, qui peut effectuer toutes les mêmes actions. Non disponible dans les versions Régions AWS lancées après avril 2017.
Pour obtenir le même résultat qu'avec le document SSM existant, utilisez la configuration de paramètres suivante avec le document de remplacement recommandé, `AWS-InstallWindowsUpdates` :
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*
## Limitations connues des documents SSM pour l'application de correctifs aux nœuds gérés
### Interruptions de redémarrage externes
Si un redémarrage est lancé par le système sur le nœud pendant l'installation du correctif (par exemple, pour appliquer des mises à jour au microprogramme ou à des fonctionnalités similaires SecureBoot), l'exécution du document de correction peut être interrompue et marquée comme ayant échoué même si les correctifs ont été correctement installés. Cela se produit parce que l'agent SSM ne peut pas conserver et reprendre l'état d'exécution du document lors de redémarrages externes.
Pour vérifier l'état de l'installation des correctifs après un échec d'exécution, exécutez une `Scan` opération de correction, puis vérifiez les données de conformité des correctifs dans le Gestionnaire de correctifs afin d'évaluer l'état de conformité actuel.
# Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`
AWS Systems Manager supports`AWS-RunPatchBaseline`, un document Systems Manager (document SSM) pourPatch Manager, un outil dans AWS Systems Manager. Ce document SSM permet d'appliquer des correctifs sur les nœuds gérés, tant pour les mises à jour liées à la sécurité que pour les autres types de mises à jour. Si aucun groupe de correctifs n'est spécifié, lorsque le document est exécuté, il utilise le référentiel de correctifs spécifié « par défaut » pour un type de système d'exploitation. Sinon, il utilise le référentiel de correctifs associé au groupe de correctifs. Pour de plus amples informations sur les groupes de correctifs, veuillez consulter [Groupes de correctifs](patch-manager-patch-groups.md).
Vous pouvez utiliser le document `AWS-RunPatchBaseline` pour appliquer des correctifs pour les systèmes d'exploitation et les applications. (Sur Windows Server, la prise en charge des applications est limitée à des mises à jour pour les applications publiées par Microsoft.)
Ce document prend en charge les nœuds gérés Linux, macOS et Windows Server. Ce document effectue les actions correspondant à chaque plateforme.
**Note**
Patch Manager prend également en charge le document SSM `AWS-ApplyPatchBaseline` hérité. Toutefois, seule l'application de correctifs sur les nœuds gérés Windows est prise en charge par ce document. Nous vous recommandons vivement de privilégier l'utilisation d'`AWS-RunPatchBaseline` dans la mesure où celui-ci prend en charge l'application de correctifs sur les nœuds gérés Linux, macOS et Windows Server. La version 2.0.834.0 ou une version ultérieure de SSM Agent pour pouvoir utiliser le document `AWS-RunPatchBaseline`.
------
#### [ Windows Server ]
Sur les nœuds Windows Server gérés, le `AWS-RunPatchBaseline` document télécharge et invoque un PowerShell module, qui télécharge à son tour un instantané de la ligne de base des correctifs qui s'applique au nœud géré. Cet instantané de référentiel de correctifs contient une liste des correctifs approuvés qui sont compilés en interrogeant le référentiel de correctifs sur un serveur Windows Server Update Services (WSUS). Cet instantané du référentiel de correctifs est transmis à l'API Windows Update qui contrôle le téléchargement et l'installation des correctifs approuvés selon les besoins.
------
#### [ Linux ]
Sur les nœuds gérés Linux, le document `AWS-RunPatchBaseline` appelle un module Python qui, à son tour, télécharge un instantané du référentiel de correctifs qui s'applique au nœud géré. Cet instantané du référentiel de correctifs utilise les règles définies et les listes de correctifs approuvés et bloqués afin de piloter le gestionnaire de package approprié pour chaque type de nœud :
+ Les nœuds gérés Amazon Linux 2, Oracle Linux et RHEL 7 utilisent YUM. Pour les opérations YUM, Patch Manager nécessite `Python 2.6` ou une version ultérieure prise en charge (2.6 à 3.12). Amazon Linux 2023 utilise DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12).
+ Les nœuds gérés RHEL 8 utilisent DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12). (Aucune des versions n'est installée par défaut sur RHEL 8. Vous devez les installer manuellement.)
+ Les instances Debian Server et Ubuntu Server utilisent APT. Pour les opérations APT, Patch Manager nécessite une version prise en charge de `Python 3` (3.0 à 3.12).
------
#### [ macOS ]
Sur les nœuds gérés macOS, le document `AWS-RunPatchBaseline` appelle un module Python qui, à son tour, télécharge un instantané du référentiel de correctifs qui s'applique au nœud. Ensuite, un sous-processus Python invoque le AWS Command Line Interface (AWS CLI) sur le nœud pour récupérer les informations d'installation et de mise à jour pour les gestionnaires de packages spécifiés et pour piloter le gestionnaire de packages approprié pour chaque package de mise à jour.
------
Chaque instantané est spécifique à un groupe de correctifs Compte AWS, à un système d'exploitation et à un identifiant de capture d'écran. L'instantané est délivré via une URL Amazon Simple Storage Service (Amazon S3) présignée, qui expire 24 heures après la création de l'instantané. Toutefois, après l'expiration de l'URL, si vous souhaitez appliquer le même contenu d'instantané à d'autres nœuds gérés, générez une nouvelle URL Amazon S3 présignée jusqu'à trois jours après la création de l'instantané. Pour ce faire, utilisez la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Une fois que toutes les mises à jour approuvées et applicables ont été installées, et que les redémarrages nécessaires ont été effectués, des informations relatives à la conformité des correctifs sont générées sur un nœud géré et transmises à Patch Manager.
**Note**
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 de plus amples informations, veuillez consulter [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Pour plus d'informations sur l'affichage des données de conformité des correctifs, consultez [A propos de la conformité des correctifs](compliance-about.md#compliance-monitor-patch).
## Paramètres dans l’`AWS-RunPatchBaseline`
`AWS-RunPatchBaseline` prend en charge six paramètres. Le paramètre `Operation` est obligatoire. Les paramètres `InstallOverrideList`, `BaselineOverride` et `RebootOption` sont facultatifs. `Snapshot-ID` est techniquement facultatif, mais nous vous recommandons de lui attribuer une valeur personnalisée lorsque vous exécutez `AWS-RunPatchBaseline`en dehors d'une fenêtre de maintenance, et de laisser Patch Manager fournir automatiquement la valeur personnalisée lorsque le document est exécuté dans le cadre d'une opération de fenêtre de maintenance.
**Topics**
+ [Nom du paramètre: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nom du paramètre: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nom du paramètre: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nom du paramètre: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nom du paramètre: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nom du paramètre: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Nom du paramètre: `Operation`
**Utilisation** : Obligatoire.
**Options** : `Scan` \$1 `Install`.
Analyser
Lorsque vous sélectionnez l'option `Scan`, `AWS-RunPatchBaseline` détermine l'état de conformité du nœud géré en matière de correctifs et transmet cette information à Patch Manager. `Scan` n'invite pas à installer les mises à jour ou à redémarrer les nœuds gérés. Mais l'opération identifie les mises à jour manquantes qui sont approuvées et applicables au nœud.
Installation
Lorsque vous sélectionnez l'option `Install`, `AWS-RunPatchBaseline` tente d'installer les mises à jour approuvées et applicables qu'il manque sur le nœud géré. Les informations de conformité des correctifs générées dans le cadre d'une opération `Install` ne répertorient pas les mises à jour manquantes, mais peuvent signaler les mises à jour avec un état d'échec si l'installation de la mise à jour a échoué pour une raison ou pour une autre. Chaque fois qu'une mise à jour est installée sur un nœud géré, ce dernier est redémarré pour s'assurer que la mise à jour est non seulement installée, mais également active. (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-parameters-norebootoption)).
Si un correctif spécifié par les règles de référentiel est installé *avant* la mise à jour du nœud géré par Patch Manager, le système peut ne pas redémarrer comme prévu. Cela peut se produire lorsqu'un correctif est installé manuellement par un utilisateur ou installé automatiquement par un autre programme, tel que le package `unattended-upgrades` sur Ubuntu Server.
### Nom du paramètre: `AssociationId`
**Utilisation** : Facultatif.
`AssociationId` est l’ID d’une association existante dans State Manager, un outil d’ AWS Systems Manager. Il est utilisé par Patch Manager pour ajouter des données de conformité à une association spécifiée. Cette association est liée à une opération d'application de correctifs [définie dans une politique de correctifs dans Quick Setup](quick-setup-patch-manager.md).
**Note**
Avec le `AWS-RunPatchBaseline`, si une valeur `AssociationId` est fournie avec un remplacement du référentiel de la politique de correctifs, l'application des correctifs est effectuée en tant qu'opération `PatchPolicy` et la valeur `ExecutionType` indiquée dans `AWS:ComplianceItem` est également `PatchPolicy`. Si aucune valeur `AssociationId` n'est fournie, l'application des correctifs est effectuée en tant qu'opération `Command` et le rapport de valeur `ExecutionType` sur l'`AWS:ComplianceItem` soumis est également `Command`.
Si vous n'avez pas encore d'association à utiliser, vous pouvez en créer une en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html).
### Nom du paramètre: `Snapshot ID`
**Utilisation** : Facultatif.
`Snapshot ID` est un ID unique (GUID) utilisé par Patch Manager pour s'assurer que les nœuds gérés d'un groupe auquel des correctifs ont été appliqués dans le cadre d'une opération individuelle disposent tous du même ensemble de correctifs approuvés. Bien que le paramètre soit défini comme facultatif, nous recommandons deux bonnes pratiques différentes : l'une si vous exécutez `AWS-RunPatchBaseline` dans une fenêtre de maintenance, l'autre si l'exécution a lieu hors d'une fenêtre de maintenance, comme décrit dans le tableau ci-dessous.
**Bonnes pratiques `AWS-RunPatchBaseline`**
| Mode | Bonne pratique | Détails |
| --- | --- | --- |
| Exécution de AWS-RunPatchBaseline à l'intérieur d'une fenêtre de maintenance | Ne fournissez pas d'ID d'instantané. Patch Manager le fournira pour vous. | Si vous utilisez une fenêtre de maintenance pour exécuter `AWS-RunPatchBaseline`, vous ne devriez pas fournir votre propre ID d'instantané généré. Dans ce scénario, Systems Manager fournit une valeur de GUID en fonction de l'ID d'exécution de la fenêtre de maintenance. Cela permet de garantir que l'ID correct est utilisé pour tous les appels de `AWS-RunPatchBaseline` dans cette fenêtre de maintenance. Si vous spécifiez une valeur dans ce scénario, notez que pendant plus de trois jours, l'instantané du référentiel de correctifs peut changer. Par la suite, un nouvel instantané est généré même si vous spécifiez le même ID après l'expiration de l'instantané. |
| Exécution de AWS-RunPatchBaseline à l'extérieur d'une fenêtre de maintenance | Générez et spécifiez une valeur de GUID personnalisée pour l'ID d'instantané.¹ | Si vous n'avez pas recours à une fenêtre de maintenance pour exécuter `AWS-RunPatchBaseline`, nous vous recommandons de générer et de spécifier un ID d'instantané unique pour chaque référentiel de correctifs, en particulier si vous exécutez le document `AWS-RunPatchBaseline` sur plusieurs nœuds gérés au cours de la même opération. Dans ce cas de figure, si vous ne spécifiez pas d'ID, Systems Manager génère un ID d'instantané différent pour chacun des nœuds gérés auxquels la commande est envoyée. Cela peut entraîner la spécification de différents ensembles de correctifs parmi les nœuds gérés. Par exemple, si vous exécutez le document `AWS-RunPatchBaseline` directement via Run Command, un outil d’ AWS Systems Manager et que vous ciblez un groupe de 50 nœuds gérés. La spécification d'un ID d'instantané personnalisé entraîne la génération d'un instantané de référentiel unique qui permet d'évaluer et de corriger tous les nœuds, garantissant ainsi un état final cohérent. |
| ¹ Vous pouvez utiliser n'importe quel outil capable de générer un GUID afin de générer une valeur pour le paramètre d'ID d'instantané. Par exemple, dans PowerShell, vous pouvez utiliser l'`New-Guid`applet de commande pour générer un GUID au format de. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Nom du paramètre: `InstallOverrideList`
**Utilisation** : Facultatif.
`InstallOverrideList` vous permet de spécifier une URL https ou une URL de type chemin Amazon S3 vers une liste de correctifs à installer. Cette liste d'installation de correctifs que vous conservez au format YAML remplace les correctifs spécifiés par le référentiel de correctifs par défaut actuelle. Cela vous confère un contrôle plus précis sur les correctifs installés sur vos nœuds gérés.
**Important**
Le nom de fichier `InstallOverrideList` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1).
Le comportement de l’application des correctifs lors de l’utilisation du paramètre `InstallOverrideList` diffère entre les nœuds gérés Linux et macOS et les nœuds gérés par Windows Server. Sur les nœuds Linux et macOS, Patch Manager tente d’appliquer les correctifs inclus dans la liste de correctifs `InstallOverrideList` et présents dans tout référentiel activé sur le nœud, que les correctifs correspondent ou non aux règles de référentiel de correctifs. Sur les nœuds Windows Server, cependant, les correctifs de la liste de correctifs `InstallOverrideList` ne sont appliqués *que* s’ils correspondent également aux règles de référentiel de correctifs.
Sachez que les rapports de conformité reflètent les états de correctif en fonction de ce qui est spécifié dans le référentiel de correctifs et non pas de ce que vous spécifiez dans une liste `InstallOverrideList` de correctifs. En d'autres termes, les opérations d'analyse ignorent le paramètre `InstallOverrideList`. Cela permet de garantir que les rapports de conformité reflètent constamment les états de correctif en fonction de la politique plutôt que de ce qui a été approuvé pour une opération spécifique d'application de correctifs.
**Note**
Lorsque vous appliquez des correctifs à un nœud qui utilise uniquement IPv6, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie. Consultez [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md) pour plus d'informations sur la configuration de l'agent pour utiliser Dualstack.
Pour obtenir une description de la façon dont vous pouvez utiliser le paramètre `InstallOverrideList` pour appliquer différents types de correctifs à un groupe cible, selon des calendriers de fenêtre de maintenance différents, tout en utilisant une ligne de base de correctifs unique, veuillez consulter [Exemple de scénario d'utilisation du InstallOverrideList paramètre dans `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Formats d'URL valides**
**Note**
Si votre fichier est stocké dans un compartiment accessible au public, vous pouvez spécifier un format d'URL https ou une URL de style chemin Amazon S3. Si votre fichier est stocké dans un compartiment privé, vous devez spécifier une URL de style chemin Amazon S3.
+ **Format des URL https** :
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL de style chemin Amazon S3** :
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formats de contenu YAML valides**
Les formats que vous utilisez pour spécifier les correctifs dans votre liste dépendent du système d'exploitation de votre nœud géré. Le format général, toutefois, est le suivant :
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Vous pouvez fournir des champs supplémentaires dans votre fichier YAML, mais ils sont ignorés pendant les opérations d'application de correctifs.
De plus, nous vous recommandons de vérifier que le format de votre fichier YAML est valide avant d'ajouter ou de mettre à jour la liste dans votre compartiment S3. Pour plus d'informations sur le format YAML, consultez [yaml.org](http://www.yaml.org). Pour les options de l'outil de validation, recherchez « validateurs de format yaml » sur le web.
------
#### [ Linux ]
**id**
Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide du nom du package et de l'architecture. Par exemple : `'dhclient.x86_64'`. Vous pouvez utiliser des caractères génériques dans l'ID pour indiquer plusieurs packages. Par exemple : `'dhcp*'` et `'dhcp*1.*'`.
**Titre**
Le champ **title (titre)** est facultatif mais, sur les systèmes Linux, il fournit des fonctionnalités de filtrage supplémentaires. Si vous utilisez le champ **title (titre)**, il doit contenir les informations de version de package dans l'un des formats suivants :
YUM/SUSE Linux Enterprise Server (SLES) :
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Pour les titres de correctifs Linux, vous pouvez utiliser un ou plusieurs caractères génériques dans n'importe quelle position pour étendre le nombre de correspondances de package. Par exemple : `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Par exemple :
+ La version du package apt qui est actuellement installée sur votre nœud géré est la version 1.2.25, mais la version 1.2.27 est désormais disponible.
+ Vous ajoutez apt.amd64 version 1.2.27 à la liste des correctifs. Elle dépend de apt utils.amd64 version 1.2.27, mais apt-utils.amd64 version 1.2.25 est spécifié dans la liste.
Dans ce cas, l'installation de la version 1.2.27 d'apt sera bloquée et signalée comme « Failed- NonCompliant ».
------
#### [ Windows Server ]
**id**
Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide de la base de connaissances Microsoft IDs (par exemple KB2736693) et du bulletin de sécurité Microsoft IDs (par exemple, MS17 -023).
Tous les autres champs que vous voulez fournir dans une liste de correctifs pour Windows sont facultatifs et fournis à titre d'information uniquement. Vous pouvez utiliser des champs supplémentaires, tels que **title**, **classification**, **severity** ou autre, pour fournir des informations plus détaillées sur les correctifs spécifiés.
------
#### [ macOS ]
**id**
Le champ **id** est obligatoire. La valeur du champ **id** peut être fournie sous un format `{package-name}.{package-version}` ou un format \$1package\$1name\$1.
------
**Exemples de listes de correctifs**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nom du paramètre: `RebootOption`
**Utilisation** : Facultatif.
**Options** : `RebootIfNeeded` \$1 `NoReboot`
**Par défaut** : `RebootIfNeeded`
**Avertissement**
L'option par défaut est `RebootIfNeeded`. Veillez à sélectionner l'option qui correspond à votre cas d'utilisation. Par exemple, si vos nœuds gérés doivent redémarrer immédiatement pour finaliser un processus de configuration, sélectionnez `RebootIfNeeded`. Ou, si des nœuds gérés doivent rester disponibles jusqu'à une heure de redémarrage planifiée, sélectionnez `NoReboot`.
**Important**
Nous vous déconseillons de Patch Manager les utiliser pour appliquer des correctifs à des instances de cluster dans Amazon EMR (précédemment appelé Amazon MapReduce Elastic). Ne sélectionnez pas l'option `RebootIfNeeded` pour le paramètre `RebootOption`. (Cette option est disponible dans les documents SSM Command pour l'application de correctifs sur `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` et `AWS-RunPatchBaselineWithHooks`.)
Les commandes sous-jacentes pour l'application de correctifs à l'aide de Patch Manager utilisent les commandes `yum` et `dnf`. Par conséquent, les opérations entraînent des incompatibilités en raison de la manière dont les packages sont installés. Pour plus d'informations sur les méthodes préférées de mise à jour logicielle sur les clusters Amazon EMR, veuillez consulter la rubrique [Utilisation de l'AMI par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) dans le *Guide de gestion Amazon EMR*.
RebootIfNeeded
Lorsque vous sélectionnez l'option `RebootIfNeeded`, le nœud géré est redémarré dans l'un des cas suivants :
+ Patch Manager a installé un ou plusieurs correctifs.
Patch Manager n'évalue pas si un redémarrage est *requis* par le correctif. Le système est redémarré même si le correctif ne nécessite pas de redémarrage.
+ Patch Manager détecte un ou plusieurs correctifs à l'état `INSTALLED_PENDING_REBOOT` durant l'opération `Install`.
Le statut `INSTALLED_PENDING_REBOOT` peut signifier que l’option `NoReboot` a été sélectionnée lors de la dernière exécution de l’opération `Install`, ou qu’un correctif a été installé en dehors de Patch Manager depuis le dernier redémarrage du nœud géré.
Dans ces deux cas, le redémarrage des nœuds gérés permet de supprimer les packages mis à jour de la mémoire, et assure la cohérence du comportement d'application des correctifs et de redémarrage sur tous les systèmes d'exploitation.
NoReboot
Lorsque vous sélectionnez l'option `NoReboot`, Patch Manager ne redémarre pas le nœud géré même s'il y a installé des correctifs pendant l'opération `Install`. Cette option est utile si vous savez qu'il n'est pas nécessaire de redémarrer vos nœuds gérés après l'application de correctifs, ou si des applications ou des processus en cours d'exécution sur un nœud ne doivent pas être perturbés par un redémarrage suite à l'application de correctifs. Elle est également utile lorsque vous souhaitez bénéficier de plus de contrôle sur le timing des redémarrages des nœuds gérés, par exemple en utilisant une fenêtre de maintenance.
Si vous sélectionnez l'option `NoReboot` et qu'un correctif est installé, l'état du correctif est attribué au correctif `InstalledPendingReboot`. Le nœud géré, quant à lui, est marqué comme `Non-Compliant`. Après un redémarrage et l'exécution d'une opération `Scan`, l'état du nœud géré est mis à jour et devient `Compliant`.
L’option `NoReboot` empêche uniquement les redémarrages au niveau du système d’exploitation. Les redémarrages au niveau du service peuvent toujours avoir lieu dans le cadre du processus d’application des correctifs. Par exemple, lorsque Docker est mis à jour, les services dépendants, comme Amazon Elastic Container Service, peuvent redémarrer automatiquement même avec `NoReboot` activé. Si vos services essentiels ne doivent pas être interrompus, envisagez des mesures supplémentaires, comme la suppression temporaire des instances du service ou la planification de l’application de correctifs pendant des fenêtres de maintenance.
**Fichier de suivi de l'installation des correctifs** : pour suivre l'installation des correctifs, en particulier ceux installés depuis le dernier redémarrage du système, Systems Manager gère un fichier sur le nœud géré.
**Important**
Ne supprimez pas ou ne modifiez pas le fichier de suivi. Si ce fichier est supprimé ou endommagé, le rapport de conformité des correctifs correspondant au nœud géré est inexact. Dans ce cas, redémarrez le nœud et lancez une opération d'analyse des correctifs pour restaurer le fichier.
Ce fichier de suivi est stocké aux emplacements suivants sur vos nœuds gérés :
+ Systèmes d'exploitation Linux :
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Système d'exploitation Windows Server :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nom du paramètre: `BaselineOverride`
**Utilisation** : Facultatif.
Vous pouvez définir des préférences d'application de correctifs au moment de l'exécution en utilisant le paramètre `BaselineOverride`. Ce remplacement de référentiel est conservé en tant qu'objet JSON dans un compartiment S3. Il garantit que les opérations d'application de correctifs utilisent les référentiels correspondant au système d'exploitation hôte au lieu d'appliquer les règles du référentiel de correctifs par défaut
**Important**
Le nom de fichier `BaselineOverride` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1).
Pour de plus amples informations sur l'utilisation du paramètre `BaselineOverride`, veuillez consulter [Utilisation du BaselineOverride paramètre](patch-manager-baselineoverride-parameter.md).
### Nom du paramètre: `StepTimeoutSeconds`
**Utilisation** : Obligatoire.
Nombre de secondes de 1 à 36000 (10 heures) accordées à l’exécution d’une commande avant qu’elle soit considérée comme ayant échoué.
# Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineAssociation`
Comme le document `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` effectue des opérations d'application de correctifs, pour les mises à jour liées à la sécurité et pour d'autres types de mises à jour. Vous pouvez également utiliser le document `AWS-RunPatchBaselineAssociation` pour appliquer des correctifs pour les systèmes d'exploitation et les applications. (Sur Windows Server, la prise en charge des applications est limitée à des mises à jour pour les applications publiées par Microsoft.)
Ce document prend en charge les instances Amazon Elastic Compute Cloud (Amazon EC2) pour Linux, macOS et Windows Server. Il ne prend pas en charge les nœuds non EC2 d'un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Le document exécutera les actions appropriées pour chaque plate-forme, en invoquant un module Python sur Linux et les macOS instances, et un PowerShell module sur les instances Windows.
`AWS-RunPatchBaselineAssociation` diffère cependant de `AWS-RunPatchBaseline` par les aspects suivants :
+ `AWS-RunPatchBaselineAssociation` est principalement destinée à une utilisation avec les associations State Manager créées avec [Quick Setup](systems-manager-quick-setup.md), un outil d’ AWS Systems Manager. Précisément, lorsque vous utilisez le type de configuration de gestion des hôtes Quick Setup, si vous sélectionnez l'option **Scan instances for missing patches daily** (Analyser quotidiennement les instances pour les correctifs manquants), le système utilise `AWS-RunPatchBaselineAssociation` pour l'opération.
Dans la plupart des cas, cependant, lors de la configuration de vos propres opérations d'application de correctifs, sélectionnez [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) ou [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) de préférence à `AWS-RunPatchBaselineAssociation`.
+ Lorsque vous utilisez le document `AWS-RunPatchBaselineAssociation`, vous pouvez spécifier une paire clé-balise dans le champ de paramètre `BaselineTags` du document. Si une ligne de base de correctifs personnalisée Compte AWS partage ces balisesPatch Manager, un outil utilise cette ligne de base balisée lorsqu'il s'exécute sur les instances cibles au lieu de la ligne de base de correctifs « par défaut » actuellement spécifiée pour le type de système d'exploitation. AWS Systems Manager
**Note**
Si vous choisissez d'utiliser `AWS-RunPatchBaselineAssociation` dans des opérations d'application de correctifs autres que celles configurées avec Quick Setup, et que vous voulez utiliser son paramètre facultatif `BaselineTags`, vous devez ajouter des autorisations supplémentaires au [profil d'instance](setup-instance-permissions.md) pour les instances Amazon Elastic Compute Cloud (Amazon EC2). Pour de plus amples informations, veuillez consulter [Nom du paramètre: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Les deux formats suivants sont valides pour votre paramètre `BaselineTags` :
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Important**
Les clés et les valeurs ne peuvent pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double (") et signe du dollar (\$1).
+ Lors de l'exécution de `AWS-RunPatchBaselineAssociation`, les données de conformité des correctifs qu'il collecte sont enregistrées à l'aide de la commande d'API `PutComplianceItems` au lieu de la commande `PutInventory`, qui est utilisée par `AWS-RunPatchBaseline`. Cette différence signifie que les informations de conformité des correctifs sont stockées et signalées pour une *association* particulière. Les données sur la conformité des correctifs générées hors de cette association ne sont pas remplacées.
+ Les informations de conformité des correctifs signalées après l'exécution de `AWS-RunPatchBaselineAssociation` indiquent si une instance est conforme ou non. Il n'inclut pas les détails au niveau du correctif, comme le montre le résultat de la commande suivante AWS Command Line Interface (AWS CLI). La commande exécute un filtrage sur `Association` comme type de conformité :
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
Le système retourne des informations telles que les suivantes.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
Si une valeur de paire clé-balise a été spécifiée comme paramètre pour le document `AWS-RunPatchBaselineAssociation`, Patch Manager recherche un référentiel de correctifs personnalisé correspondant au type de système d'exploitation et qui a été balisé avec la même paire clé-balise. Cette recherche ne se limite pas au référentiel de correctifs par défaut actuellement spécifié ou au référentiel affecté à un groupe de correctifs. Si aucun référentiel n'est trouvé avec les balises spécifiées, Patch Managerrecherche ensuite un groupe de correctifs, si un groupe a été spécifié dans la commande qui exécute `AWS-RunPatchBaselineAssociation`. Si aucun groupe de correctifs ne correspond, Patch Manager revient au référentiel de correctifs par défaut actuel pour le compte de système d'exploitation.
Si plusieurs référentiels de correctifs sont trouvés avec les balises spécifiées dans le document `AWS-RunPatchBaselineAssociation`, Patch Manager renvoie un message d'erreur indiquant qu'un seul référentiel de correctifs peut être balisé avec cette paire clé-valeur pour que l'opération continue.
**Note**
Sur les nœuds Linux, le gestionnaire de packages approprié pour chaque type de nœud est utilisé pour installer les packages :
Les instances Amazon Linux 2, Oracle Linux et RHEL utilisent YUM. Pour les opérations YUM, Patch Manager nécessite `Python 2.6` ou une version ultérieure prise en charge (2.6 à 3.12). Amazon Linux 2023 utilise DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12).
Les instances Debian Server et Ubuntu Server utilisent APT. Pour les opérations APT, Patch Manager nécessite une version prise en charge de `Python 3` (3.0 à 3.12).
Une fois l'analyse terminée ou toutes les mises à jour approuvées et applicables installées, et les redémarrages exécutés au besoin, les informations de conformité des correctifs sont générées sur une instance et rapportées au service Patch Compliance.
**Note**
Si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaselineAssociation`, l'instance n'est pas redémarrée après l'exécution du Patch Manager. Pour de plus amples informations, veuillez consulter [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Pour plus d'informations sur l'affichage des données de conformité des correctifs, consultez [A propos de la conformité des correctifs](compliance-about.md#compliance-monitor-patch).
## Paramètres dans l’`AWS-RunPatchBaselineAssociation`
`AWS-RunPatchBaselineAssociation` prend en charge cinq paramètres. Les paramètres `Operation` et `AssociationId` sont obligatoires. Les paramètres `InstallOverrideList`, `RebootOption` et `BaselineTags` sont facultatifs.
**Topics**
+ [Nom du paramètre: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nom du paramètre: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nom du paramètre: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nom du paramètre: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nom du paramètre: `Operation`
**Utilisation** : Obligatoire.
**Options** : `Scan` \$1 `Install`.
Analyser
Lorsque vous sélectionnez l'option `Scan`, `AWS-RunPatchBaselineAssociation` détermine l'état de conformité de correctif de l'instance et rapporte cette information au Patch Manager. `Scan` n'invite pas à installer des mises à jour ou à redémarrer des instances. Cet opération identifie plutôt à quel emplacement il manque des mises à jour approuvées et applicables à l'instance.
Installation
Lorsque vous sélectionnez l'option `Install`, `AWS-RunPatchBaselineAssociation` tente d'installer les mises à jour approuvées et applicables qui sont manquantes dans l'instance. Les informations de conformité des correctifs générées dans le cadre d'une opération `Install` ne répertorient pas les mises à jour manquantes, mais peuvent signaler les mises à jour avec un état d'échec si l'installation de la mise à jour a échoué pour une raison ou pour une autre. À chaque installation d'une mise à jour sur une instance, cette dernière est redémarrée pour s'assurer que la mise à jour est non seulement installée, mais également active. (Exception : si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaselineAssociation`, l'instance n'est pas redémarrée après l'exécution de Patch Manager. Pour de plus amples informations, consultez [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)
Si un correctif spécifié par les règles de ligne de base est installé *avant* que Patch Manager ne mette à jour l'instance, le système peut ne pas redémarrer comme prévu. Cela peut se produire lorsqu'un correctif est installé manuellement par un utilisateur ou installé automatiquement par un autre programme, tel que le package `unattended-upgrades` sur Ubuntu Server.
### Nom du paramètre: `BaselineTags`
**Utilisation** : Facultatif.
`BaselineTags` est une paire clé-valeur de balise unique que vous sélectionnez et affectez à un référentiel de correctifs personnalisé. Vous pouvez spécifier une ou plusieurs valeurs pour ce paramètre. Les deux formats sont valides :
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Important**
Les clés et les valeurs ne peuvent pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double (") et signe du dollar (\$1).
La valeur `BaselineTags` est utilisée par Patch Manager pour s'assurer qu'un ensemble d'instances corrigées lors d'une opération unique dispose du même ensemble de correctifs identiques approuvés. Lorsque l'opération d'application de correctifs s'exécute, Patch Manager vérifie si un référentiel de correctifs pour le type de système d'exploitation est balisé avec la même paire clé-valeur que celle spécifiée pour `BaselineTags`. En cas de correspondance, ce référentiel de correctifs personnalisé est utilisé. En l'absence de correspondance, un référentiel de correctifs est identifié en fonction de n'importe quel groupe de correctifs spécifié pour l'application de correctifs. S'il n'y en a pas, la ligne de base de correctifs prédéfinie AWS gérée pour ce système d'exploitation est utilisée.
**Exigences d'autorisations supplémentaires**
Si vous utilisez `AWS-RunPatchBaselineAssociation` dans des opérations d'application de correctifs autres que celles configurées avec Quick Setup, et que vous voulez utiliser son paramètre facultatif `BaselineTags`, vous devez ajouter les autorisations suivantes au [profil d'instance](setup-instance-permissions.md) pour les instances Amazon Elastic Compute Cloud (Amazon EC2).
**Note**
Quick Setupet `AWS-RunPatchBaselineAssociation` ne prennent pas en charge les serveurs locaux et les machines virtuelles (VMs).
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Remplacez-le *patch-baseline-arn* par le Amazon Resource Name (ARN) de la ligne de base de correctif à laquelle vous souhaitez donner accès, au format`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.
### Nom du paramètre: `AssociationId`
**Utilisation** : Obligatoire.
`AssociationId` est l’ID d’une association existante dans State Manager, un outil d’ AWS Systems Manager. Il est utilisé par Patch Manager pour ajouter des données de conformité à une association spécifiée. Cette association est liée à une opération de correctif `Scan` activée dans une [configuration de gestion des hôtes créée dans Quick Setup](quick-setup-host-management.md). En envoyant les résultats des correctifs sous forme de données de conformité d'association plutôt que de données de conformité d'inventaire, les informations de conformité d'inventaire existantes pour vos instances ne sont pas remplacées après une opération de correction, ni pour toute autre association. IDs Si vous n'avez pas encore d'association à utiliser, vous pouvez en créer une en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Par exemple :
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### Nom du paramètre: `InstallOverrideList`
**Utilisation** : Facultatif.
En utilisant `InstallOverrideList`, vous spécifiez une URL https ou une URL de style chemin Amazon Simple Storage Service (Amazon S3) à une liste de correctifs à installer. Cette liste d'installation de correctifs que vous conservez au format YAML remplace les correctifs spécifiés par le référentiel de correctifs par défaut actuelle. Cela vous offre un contrôle plus précis sur les correctifs installés sur vos instances.
**Important**
Le nom de fichier `InstallOverrideList` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1).
Le comportement de l’application des correctifs lors de l’utilisation du paramètre `InstallOverrideList` diffère entre les nœuds gérés Linux et macOS et les nœuds gérés par Windows Server. Sur les nœuds Linux et macOS, Patch Manager tente d’appliquer les correctifs inclus dans la liste de correctifs `InstallOverrideList` et présents dans tout référentiel activé sur le nœud, que les correctifs correspondent ou non aux règles de référentiel de correctifs. Sur les nœuds Windows Server, cependant, les correctifs de la liste de correctifs `InstallOverrideList` ne sont appliqués *que* s’ils correspondent également aux règles de référentiel de correctifs.
Sachez que les rapports de conformité reflètent les états de correctif en fonction de ce qui est spécifié dans le référentiel de correctifs et non pas de ce que vous spécifiez dans une liste `InstallOverrideList` de correctifs. En d'autres termes, les opérations d'analyse ignorent le paramètre `InstallOverrideList`. Cela permet de garantir que les rapports de conformité reflètent constamment les états de correctif en fonction de la politique plutôt que de ce qui a été approuvé pour une opération spécifique d'application de correctifs.
**Formats d'URL valides**
**Note**
Si votre fichier est stocké dans un compartiment accessible au public, vous pouvez spécifier un format d'URL https ou une URL de style chemin Amazon S3. Si votre fichier est stocké dans un compartiment privé, vous devez spécifier une URL de style chemin Amazon S3.
+ **Exemple de format d'URL https** :
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Exemple d'URL de type chemin d'accès Amazon S3** :
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formats de contenu YAML valides**
Les formats que vous utilisez pour spécifier des correctifs dans votre liste dépendent du système d'exploitation de votre instance. Le format général, toutefois, est le suivant :
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Vous pouvez fournir des champs supplémentaires dans votre fichier YAML, mais ils sont ignorés pendant les opérations d'application de correctifs.
De plus, nous vous recommandons de vérifier que le format de votre fichier YAML est valide avant d'ajouter ou de mettre à jour la liste dans votre compartiment S3. Pour plus d'informations sur le format YAML, consultez [yaml.org](http://www.yaml.org). Pour les options de l'outil de validation, recherchez « validateurs de format yaml » sur le web.
+ Microsoft Windows
**id**
Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide de la base de connaissances Microsoft IDs (par exemple KB2736693) et du bulletin de sécurité Microsoft IDs (par exemple, MS17 -023).
Tous les autres champs que vous voulez fournir dans une liste de correctifs pour Windows sont facultatifs et fournis à titre d'information uniquement. Vous pouvez utiliser des champs supplémentaires, tels que **title**, **classification**, **severity** ou autre, pour fournir des informations plus détaillées sur les correctifs spécifiés.
+ Linux
**id**
Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide du nom du package et de l'architecture. Par exemple : `'dhclient.x86_64'`. Vous pouvez utiliser des caractères génériques dans l'ID pour indiquer plusieurs packages. Par exemple : `'dhcp*'` et `'dhcp*1.*'`.
**title**
Le champ **title (titre)** est facultatif mais, sur les systèmes Linux, il fournit des fonctionnalités de filtrage supplémentaires. Si vous utilisez le champ **title (titre)**, il doit contenir les informations de version de package dans l'un des formats suivants :
YUM/Red Hat Enterprise Linux (RHEL) :
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Pour les titres de correctifs Linux, vous pouvez utiliser un ou plusieurs caractères génériques dans n'importe quelle position pour étendre le nombre de correspondances de package. Par exemple : `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Par exemple :
+ La version 1.2.25 du package apt est actuellement installée sur votre instance, mais la version 1.2.27 est désormais disponible.
+ Vous ajoutez apt.amd64 version 1.2.27 à la liste des correctifs. Elle dépend de apt utils.amd64 version 1.2.27, mais apt-utils.amd64 version 1.2.25 est spécifié dans la liste.
Dans ce cas, l'installation de la version 1.2.27 d'apt sera bloquée et signalée comme « Failed- NonCompliant ».
**Autres champs**
Tous les autres champs que vous voulez fournir dans une liste de correctifs pour Linux sont facultatifs et fournis à titre d'information uniquement. Vous pouvez utiliser des champs supplémentaires, tels que **classification**, **severity** ou autre, pour fournir des informations plus détaillées sur les correctifs spécifiés.
**Exemples de listes de correctifs**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nom du paramètre: `RebootOption`
**Utilisation** : Facultatif.
**Options** : `RebootIfNeeded` \$1 `NoReboot`
**Par défaut** : `RebootIfNeeded`
**Avertissement**
L'option par défaut est `RebootIfNeeded`. Veillez à sélectionner l'option qui correspond à votre cas d'utilisation. Par exemple, si un redémarrage immédiat de vos instances est nécessaire pour finaliser un processus de configuration, sélectionnez `RebootIfNeeded`. Ou, si des instances doivent rester disponibles jusqu'à une heure de redémarrage planifiée, sélectionnez `NoReboot`.
**Important**
L’option `NoReboot` empêche uniquement les redémarrages au niveau du système d’exploitation. Les redémarrages au niveau du service peuvent toujours avoir lieu dans le cadre du processus d’application des correctifs. Par exemple, lorsque Docker est mis à jour, les services dépendants, comme Amazon Elastic Container Service, peuvent redémarrer automatiquement même avec `NoReboot` activé. Si vos services essentiels ne doivent pas être interrompus, envisagez des mesures supplémentaires, comme la suppression temporaire des instances du service ou la planification de l’application de correctifs pendant des fenêtres de maintenance.
**Important**
Nous vous déconseillons de Patch Manager les utiliser pour appliquer des correctifs à des instances de cluster dans Amazon EMR (précédemment appelé Amazon MapReduce Elastic). Ne sélectionnez pas l'option `RebootIfNeeded` pour le paramètre `RebootOption`. (Cette option est disponible dans les documents SSM Command pour l'application de correctifs sur `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` et `AWS-RunPatchBaselineWithHooks`.)
Les commandes sous-jacentes pour l'application de correctifs à l'aide de Patch Manager utilisent les commandes `yum` et `dnf`. Par conséquent, les opérations entraînent des incompatibilités en raison de la manière dont les packages sont installés. Pour plus d'informations sur les méthodes préférées de mise à jour logicielle sur les clusters Amazon EMR, veuillez consulter la rubrique [Utilisation de l'AMI par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) dans le *Guide de gestion Amazon EMR*.
RebootIfNeeded
Lorsque vous sélectionnez l'option `RebootIfNeeded`, l'instance est redémarrée dans l'un des cas suivants :
+ Patch Manager a installé un ou plusieurs correctifs.
Patch Manager n'évalue pas si un redémarrage est *requis* par le correctif. Le système est redémarré même si le correctif ne nécessite pas de redémarrage.
+ Patch Manager détecte un ou plusieurs correctifs à l'état `INSTALLED_PENDING_REBOOT` durant l'opération `Install`.
Le statut `INSTALLED_PENDING_REBOOT` peut signifier que l’option `NoReboot` a été sélectionnée lors de la dernière exécution de l’opération `Install`, ou qu’un correctif a été installé en dehors de Patch Manager depuis le dernier redémarrage du nœud géré.
Dans ces deux cas, le redémarrage des instances garantit que les packages mis à jour sont supprimés de la mémoire et assure la cohérence du comportement d'application de correctifs et de redémarrage sur tous les systèmes d'exploitation.
NoReboot
Lorsque vous sélectionnez l'option `NoReboot`, Patch Manager ne redémarre pas une instance même s'il a installé des correctifs pendant l'opération `Install`. Cette option est utile si vous savez que vos instances ne nécessitent pas de redémarrage après l'application des correctifs, ou si vous avez des applications ou des processus en cours d'exécution sur une instance qui ne doivent pas être perturbés par un redémarrage suite à une opération d'application de correctifs. Elle est également utile lorsque vous voulez plus de contrôle sur le timing des redémarrages d'instance, par exemple en utilisant une fenêtre de maintenance.
**Fichier de suivi de l'installation des correctifs** : pour suivre l'installation des correctifs, en particulier les correctifs installés depuis le dernier redémarrage du système, Systems Manager gère un fichier sur l'instance gérée.
**Important**
Ne supprimez pas ou ne modifiez pas le fichier de suivi. Si ce fichier est supprimé ou endommagé, le rapport de conformité des correctifs pour l'instance est inexact. Si cela se produit, redémarrez l'instance et exécutez une opération d'analyse des correctifs pour restaurer le fichier.
Ce fichier de suivi est stocké dans les emplacements suivants sur vos instances gérées :
+ Systèmes d'exploitation Linux :
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Système d'exploitation Windows Server :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager supports`AWS-RunPatchBaselineWithHooks`, un document Systems Manager (document SSM) pourPatch Manager, un outil dans AWS Systems Manager. Ce document SSM permet d'appliquer des correctifs sur les nœuds gérés, tant pour les mises à jour liées à la sécurité que pour les autres types de mises à jour.
`AWS-RunPatchBaselineWithHooks` diffère de `AWS-RunPatchBaseline` par les aspects suivants :
+ **Un document wrapper** : `AWS-RunPatchBaselineWithHooks` est un wrapper pour `AWS-RunPatchBaseline` et s'appuie sur `AWS-RunPatchBaseline` pour certaines de ses opérations.
+ **L'opération `Install` ** : `AWS-RunPatchBaselineWithHooks` prend en charge les hooks de cycle de vie qui s'exécutent aux stades désignés lors de l'application de correctifs sur des nœuds gérés. Comme l'installation des correctifs exige parfois le redémarrage des nœuds gérés, l'opération d'application des correctifs se décompose en deux événements, pour un total de trois hooks qui prennent en charge la fonctionnalité personnalisée. Le premier hook précède l'opération `Install with NoReboot`. Le deuxième hook suit l'opération `Install with NoReboot`. Le troisième hook est disponible après le redémarrage du nœud géré.
+ **Aucune prise en charge de liste de correctifs personnalisée** : `AWS-RunPatchBaselineWithHooks` ne prend pas en charge le paramètre `InstallOverrideList`.
+ **Prise en charge de SSM Agent** : `AWS-RunPatchBaselineWithHooks` exige que SSM Agent 3.0.502 (ou version ultérieure) soit installé sur le nœud géré auquel les correctifs doivent être appliqués.
Si aucun groupe de correctifs n'est spécifié, lorsque le document est exécuté, il utilise le référentiel de correctifs « par défaut » actuellement spécifié pour un type de système d'exploitation. Sinon, il utilise les référentiels de correctifs associés au groupe de correctifs. Pour de plus amples informations sur les groupes de correctifs, veuillez consulter [Groupes de correctifs](patch-manager-patch-groups.md).
Vous pouvez utiliser le document `AWS-RunPatchBaselineWithHooks` pour appliquer des correctifs pour les systèmes d'exploitation et les applications. (Sur Windows Server, la prise en charge des applications est limitée à des mises à jour pour les applications publiées par Microsoft.)
Ce document prend en charge les nœuds gérés Linux et Windows Server. Ce document effectue les actions correspondant à chaque plateforme.
**Note**
`AWS-RunPatchBaselineWithHooks` n’est pas pris en charge par macOS.
------
#### [ Linux ]
Sur les nœuds gérés Linux, le document `AWS-RunPatchBaselineWithHooks` appelle un module Python qui, à son tour, télécharge un instantané du référentiel de correctifs qui s'applique au nœud géré. Cet instantané du référentiel de correctifs utilise les règles définies et les listes de correctifs approuvés et bloqués afin de piloter le gestionnaire de package approprié pour chaque type de nœud :
+ Les nœuds gérés Amazon Linux 2, Oracle Linux et RHEL 7 utilisent YUM. Pour les opérations YUM, Patch Manager nécessite `Python 2.6` ou une version ultérieure prise en charge (2.6 à 3.12). Amazon Linux 2023 utilise DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12).
+ Les nœuds gérés RHEL 8 utilisent DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12). (Aucune des versions n'est installée par défaut sur RHEL 8. Vous devez les installer manuellement.)
+ Les instances Debian Server et Ubuntu Server utilisent APT. Pour les opérations APT, Patch Manager nécessite une version prise en charge de `Python 3` (3.0 à 3.12).
------
#### [ Windows Server ]
Sur les nœuds Windows Server gérés, le `AWS-RunPatchBaselineWithHooks` document télécharge et invoque un PowerShell module, qui télécharge à son tour un instantané de la ligne de base des correctifs qui s'applique au nœud géré. Cet instantané de référentiel de correctifs contient une liste des correctifs approuvés qui sont compilés en interrogeant le référentiel de correctifs sur un serveur Windows Server Update Services (WSUS). Cet instantané du référentiel de correctifs est transmis à l'API Windows Update qui contrôle le téléchargement et l'installation des correctifs approuvés selon les besoins.
------
Chaque instantané est spécifique à un groupe de correctifs Compte AWS, à un système d'exploitation et à un identifiant de capture d'écran. L'instantané est délivré via une URL Amazon Simple Storage Service (Amazon S3) présignée, qui expire 24 heures après la création de l'instantané. Toutefois, une fois l'URL expirée, si vous souhaitez appliquer le contenu du même instantané à d'autres nœuds gérés, vous pouvez générer une nouvelle URL Amazon S3 présignée jusqu'à trois jours après la création de l'instantané. Pour ce faire, utilisez la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Une fois que toutes les mises à jour approuvées et applicables ont été installées, et que les redémarrages nécessaires ont été effectués, des informations relatives à la conformité des correctifs sont générées sur un nœud géré et transmises à Patch Manager.
Si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaselineWithHooks`, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour de plus amples informations, veuillez consulter [Nom du paramètre: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**Important**
Bien que l’option `NoReboot` empêche les redémarrages du système d’exploitation, elle n’empêche pas les redémarrages au niveau du service susceptibles de se produire lors de la mise à jour de certains packages. Par exemple, la mise à jour de packages comme Docker peut déclencher le redémarrage automatique de services dépendants (comme les services d’orchestration de conteneurs) même lorsque `NoReboot` est spécifié.
Pour plus d'informations sur l'affichage des données de conformité des correctifs, consultez [A propos de la conformité des correctifs](compliance-about.md#compliance-monitor-patch).
## Étapes opérationnelles d'`AWS-RunPatchBaselineWithHooks`
Lorsque `AWS-RunPatchBaselineWithHooks` s'exécute, les étapes suivantes sont effectuées :
1. **Analyser** : une opération `Scan` utilisant `AWS-RunPatchBaseline` est exécutée sur le nœud géré, et un rapport de conformité est généré et chargé.
1. **Vérifier les états des correctifs locaux** : un script est exécuté pour déterminer quelles étapes seront effectuées en fonction de l'opération sélectionnée et du résultat de `Scan` à l'étape 1.
1. Si l'opération sélectionnée est `Scan`, l'opération est marquée comme terminée. L'opération se termine.
1. Si l'opération sélectionnée est `Install`, Patch Manager évalue le résultat de `Scan` à l'étape 1 afin de déterminer ce qu'il faut exécuter ensuite :
1. Si aucun correctif manquant n'est détecté et qu'aucun redémarrage en attente n'est requis, l'opération passe directement à l'étape finale (étape 8), qui comprend un hook fourni par vos soins. Toutes les étapes intermédiaires sont ignorées.
1. Si aucun correctif manquant n'est détecté, mais qu'aucun redémarrage en attente n'est requis et que l'option de redémarrage sélectionnée est `NoReboot`, l'opération passe directement à l'étape finale (étape 8), qui comprend un hook fourni par vos soins. Toutes les étapes intermédiaires sont ignorées.
1. Autrement, l'opération passe à l'étape suivante.
1. **Opération hook avant l'application de correctifs** : le document SSM que vous avez fourni pour le premier hook de cycle de vie, `PreInstallHookDocName`, est exécuté sur le nœud géré.
1. **Installer avec NoReboot** : une `Install` opération avec l'option de redémarrage `NoReboot` `AWS-RunPatchBaseline` est exécutée sur le nœud géré, et un rapport de conformité est généré et téléchargé.
1. **Opération hook après l'application de correctifs** : le document SSM que vous avez fourni pour le premier hook de cycle de vie, `PostInstallHookDocName`, est exécuté sur le nœud géré.
1. **Vérification du redémarrage** : un script est exécuté afin de déterminer si un redémarrage est nécessaire pour le nœud géré et quelles sont les étapes à suivre :
1. Si l'option de redémarrage sélectionnée est `NoReboot`, l'opération passe directement à l'étape finale (étape 8), qui comprend un hook fourni par vos soins. Toutes les étapes intermédiaires sont ignorées.
1. Si l'option de redémarrage sélectionnée est `RebootIfNeeded`, Patch Manager vérifie si des redémarrages en attente sont requis, à partir de l'inventaire collecté à l'étape 4. Cela signifie que l'opération continue jusqu'à l'étape 7 et que le nœud géré est redémarré dans l'un des cas suivants :
1. Patch Manager a installé un ou plusieurs correctifs. (Patch Manager n'évalue pas si un redémarrage est requis par le correctif. Le système est redémarré même si le correctif ne nécessite pas de redémarrage.)
1. Patch Manager détecte un ou plusieurs correctifs à l'état `INSTALLED_PENDING_REBOOT` durant l'opération Install (Installer). Le statut `INSTALLED_PENDING_REBOOT` peut signifier que l’option `NoReboot` a été sélectionnée lors de la dernière exécution de l’opération Install, ou qu’un correctif a été installé en dehors de Patch Manager depuis le dernier redémarrage du nœud géré.
Si aucun correctif correspondant à ces critères n'est trouvé, l'opération d'application de correctifs sur un nœud géré prend fin et passe directement à l'étape finale (étape 8), qui comprend un hook fourni par vos soins. Toutes les étapes intermédiaires sont ignorées.
1. **Redémarrage et rapport** : une opération d'installation avec l'option de redémarrage `RebootIfNeeded` est exécutée sur le nœud géré via `AWS-RunPatchBaseline`, et un rapport de conformité est généré et chargé.
1. **Opération hook après redémarrage** : le document SSM que vous avez fourni pour le troisième hook de cycle de vie, `OnExitHookDocName`, est exécuté sur le nœud géré.
Pour une opération `Scan`, si l'étape 1 échoue, le processus d'exécution du document s'arrête et l'étape est signalée comme ayant échoué, bien que les étapes suivantes soient signalées comme ayant réussi.
Pour une opération `Install`, si l'une des étapes `aws:runDocument` échoue pendant l'opération, ces étapes sont signalées comme ayant échoué et l'opération passe directement à l'étape finale (étape 8), qui comprend un hook fourni par vos soins. Toutes les étapes intermédiaires sont ignorées. Cette étape est signalée comme ayant échoué, la dernière étape indique le statut du résultat de son opération et toutes les étapes intermédiaires sont signalées comme ayant réussi.
## Paramètres dans l’`AWS-RunPatchBaselineWithHooks`
`AWS-RunPatchBaselineWithHooks` prend en charge six paramètres.
Le paramètre `Operation` est obligatoire.
Les paramètres `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` et `OnExitHookDocName` sont facultatifs.
Du point de vue technique, `Snapshot-ID` est facultatif, mais nous vous recommandons de lui donner une valeur personnalisée lorsque vous exécutez `AWS-RunPatchBaselineWithHooks` à l'extérieur d'une fenêtre de maintenance. Laissez Patch Manager fournir la valeur automatiquement lorsque le document est exécuté dans le cadre d'une opération de fenêtre de maintenance.
**Topics**
+ [Nom du paramètre: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nom du paramètre: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nom du paramètre: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nom du paramètre: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nom du paramètre: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nom du paramètre: `Operation`
**Utilisation** : Obligatoire.
**Options** : `Scan` \$1 `Install`.
Analyser
Lorsque vous sélectionnez l'option `Scan`, le système utilise le document `AWS-RunPatchBaseline` afin de déterminer l'état de conformité du nœud géré en matière de correctifs et transmet cette information à Patch Manager. `Scan` n'invite pas à installer les mises à jour ou à redémarrer les nœuds gérés. Mais l'opération identifie les mises à jour manquantes qui sont approuvées et applicables au nœud.
Installation
Lorsque vous sélectionnez l'option `Install`, `AWS-RunPatchBaselineWithHooks` tente d'installer les mises à jour approuvées et applicables qu'il manque sur le nœud géré. Les informations de conformité des correctifs générées dans le cadre d'une opération `Install` ne répertorient pas les mises à jour manquantes, mais peuvent signaler les mises à jour avec un état d'échec si l'installation de la mise à jour a échoué pour une raison ou pour une autre. Chaque fois qu'une mise à jour est installée sur un nœud géré, ce dernier est redémarré pour s'assurer que la mise à jour est non seulement installée, mais également active. (Exception : si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaselineWithHooks`, 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-runpatchbaselinewithhooks-parameters-norebootoption)).
Si un correctif spécifié par les règles de référentiel est installé *avant* la mise à jour du nœud géré par Patch Manager, le système peut ne pas redémarrer comme prévu. Cela peut se produire lorsqu'un correctif est installé manuellement par un utilisateur ou installé automatiquement par un autre programme, tel que le package `unattended-upgrades` sur Ubuntu Server.
### Nom du paramètre: `Snapshot ID`
**Utilisation** : Facultatif.
`Snapshot ID` est un ID unique (GUID) utilisé par Patch Manager pour s'assurer que les nœuds gérés d'un groupe auquel des correctifs ont été appliqués dans le cadre d'une opération individuelle disposent tous du même ensemble de correctifs approuvés. Bien que le paramètre soit défini comme facultatif, nous recommandons deux bonnes pratiques différentes : l'une si vous exécutez `AWS-RunPatchBaselineWithHooks` dans une fenêtre de maintenance, l'autre si l'exécution a lieu hors d'une fenêtre de maintenance, comme décrit dans le tableau ci-dessous.
**Bonnes pratiques `AWS-RunPatchBaselineWithHooks`**
| Mode | Bonne pratique | Détails |
| --- | --- | --- |
| Exécution de AWS-RunPatchBaselineWithHooks à l'intérieur d'une fenêtre de maintenance | Ne fournissez pas d'ID d'instantané. Patch Manager le fournira pour vous. | Si vous utilisez une fenêtre de maintenance pour exécuter `AWS-RunPatchBaselineWithHooks`, vous ne devriez pas fournir votre propre ID d'instantané généré. Dans ce scénario, Systems Manager fournit une valeur de GUID en fonction de l'ID d'exécution de la fenêtre de maintenance. Cela permet de garantir que l'ID correct est utilisé pour tous les appels de `AWS-RunPatchBaselineWithHooks` dans cette fenêtre de maintenance. Si vous spécifiez une valeur dans ce scénario, notez que pendant plus de trois jours, l'instantané du référentiel de correctifs peut changer. Par la suite, un nouvel instantané est généré même si vous spécifiez le même ID après l'expiration de l'instantané. |
| Exécution de AWS-RunPatchBaselineWithHooks à l'extérieur d'une fenêtre de maintenance | Générez et spécifiez une valeur de GUID personnalisée pour l'ID d'instantané.¹ | Si vous n'avez pas recours à une fenêtre de maintenance pour exécuter `AWS-RunPatchBaselineWithHooks`, nous vous recommandons de générer et de spécifier un ID d'instantané unique pour chaque référentiel de correctifs, en particulier si vous exécutez le document `AWS-RunPatchBaselineWithHooks` sur plusieurs nœuds gérés au cours de la même opération. Dans ce cas de figure, si vous ne spécifiez pas d'ID, Systems Manager génère un ID d'instantané différent pour chacun des nœuds gérés auxquels la commande est envoyée. Cela peut entraîner la spécification d'ensembles de correctifs différents parmi les nœuds. Par exemple, si vous exécutez le document `AWS-RunPatchBaselineWithHooks` directement via Run Command, un outil d’AWS Systems Manager et que vous ciblez un groupe de 50 nœuds gérés. La spécification d'un ID d'instantané personnalisé entraîne la génération d'un instantané de référentiel unique qui permet d'évaluer et de corriger tous les nœuds gérés, garantissant ainsi un état final cohérent. |
| ¹ Vous pouvez utiliser n'importe quel outil capable de générer un GUID afin de générer une valeur pour le paramètre d'ID d'instantané. Par exemple, dans PowerShell, vous pouvez utiliser l'`New-Guid`applet de commande pour générer un GUID au format de. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Nom du paramètre: `RebootOption`
**Utilisation** : Facultatif.
**Options** : `RebootIfNeeded` \$1 `NoReboot`
**Par défaut** : `RebootIfNeeded`
**Avertissement**
L'option par défaut est `RebootIfNeeded`. Veillez à sélectionner l'option qui correspond à votre cas d'utilisation. Par exemple, si vos nœuds gérés doivent redémarrer immédiatement pour finaliser un processus de configuration, sélectionnez `RebootIfNeeded`. Ou, si des nœuds gérés doivent rester disponibles jusqu'à une heure de redémarrage planifiée, sélectionnez `NoReboot`.
**Important**
Nous vous déconseillons de Patch Manager les utiliser pour appliquer des correctifs à des instances de cluster dans Amazon EMR (précédemment appelé Amazon MapReduce Elastic). Ne sélectionnez pas l'option `RebootIfNeeded` pour le paramètre `RebootOption`. (Cette option est disponible dans les documents SSM Command pour l'application de correctifs sur `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` et `AWS-RunPatchBaselineWithHooks`.)
Les commandes sous-jacentes pour l'application de correctifs à l'aide de Patch Manager utilisent les commandes `yum` et `dnf`. Par conséquent, les opérations entraînent des incompatibilités en raison de la manière dont les packages sont installés. Pour plus d'informations sur les méthodes préférées de mise à jour logicielle sur les clusters Amazon EMR, veuillez consulter la rubrique [Utilisation de l'AMI par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) dans le *Guide de gestion Amazon EMR*.
RebootIfNeeded
Lorsque vous sélectionnez l'option `RebootIfNeeded`, le nœud géré est redémarré dans l'un des cas suivants :
+ Patch Manager a installé un ou plusieurs correctifs.
Patch Manager n'évalue pas si un redémarrage est *requis* par le correctif. Le système est redémarré même si le correctif ne nécessite pas de redémarrage.
+ Patch Manager détecte un ou plusieurs correctifs à l'état `INSTALLED_PENDING_REBOOT` durant l'opération `Install`.
Le statut `INSTALLED_PENDING_REBOOT` peut signifier que l’option `NoReboot` a été sélectionnée lors de la dernière exécution de l’opération `Install`, ou qu’un correctif a été installé en dehors de Patch Manager depuis le dernier redémarrage du nœud géré.
Dans ces deux cas, le redémarrage des nœuds gérés permet de supprimer les packages mis à jour de la mémoire, et assure la cohérence du comportement d'application des correctifs et de redémarrage sur tous les systèmes d'exploitation.
NoReboot
Lorsque vous sélectionnez l'option `NoReboot`, Patch Manager ne redémarre pas le nœud géré même s'il y a installé des correctifs pendant l'opération `Install`. Cette option est utile si vous savez qu'il n'est pas nécessaire de redémarrer vos nœuds gérés après l'application de correctifs, ou si des applications ou des processus en cours d'exécution sur un nœud ne doivent pas être perturbés par un redémarrage suite à l'application de correctifs. Elle est également utile lorsque vous souhaitez bénéficier de plus de contrôle sur le timing des redémarrages des nœuds gérés, par exemple en utilisant une fenêtre de maintenance.
Si vous sélectionnez l'option `NoReboot` et qu'un correctif est installé, l'état du correctif est attribué au correctif `InstalledPendingReboot`. Le nœud géré, quant à lui, est marqué comme `Non-Compliant`. Après un redémarrage et l'exécution d'une opération `Scan`, l'état du nœud est mis à jour et devient `Compliant`.
**Fichier de suivi de l'installation des correctifs** : pour suivre l'installation des correctifs, en particulier ceux installés depuis le dernier redémarrage du système, Systems Manager gère un fichier sur le nœud géré.
**Important**
Ne supprimez pas ou ne modifiez pas le fichier de suivi. Si ce fichier est supprimé ou endommagé, le rapport de conformité des correctifs correspondant au nœud géré est inexact. Dans ce cas, redémarrez le nœud et lancez une opération d'analyse des correctifs pour restaurer le fichier.
Ce fichier de suivi est stocké aux emplacements suivants sur vos nœuds gérés :
+ Systèmes d'exploitation Linux :
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Système d'exploitation Windows Server :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nom du paramètre: `PreInstallHookDocName`
**Utilisation** : Facultatif.
**Par défaut** : `AWS-Noop`.
La valeur à fournir pour le paramètre `PreInstallHookDocName` est le nom ou l'Amazon Resource Name (ARN) d'un document SSM de votre choix. Vous pouvez fournir le nom d'un document AWS géré ou le nom ou l'ARN d'un document SSM personnalisé que vous avez créé ou qui a été partagé avec vous. (Pour un document SSM qui a été partagé avec vous à partir d'un autre document Compte AWS, vous devez spécifier l'ARN complet de la ressource, par exemple`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Le document SSM spécifié par vos soins est exécuté avant l'opération `Install` et effectue toutes les actions prises en charge par SSM Agent, comme l'exécution d'un script shell pour assurer la surveillance de l'état des applications avant l'installation des correctifs sur le nœud géré. (Pour obtenir la liste des actions, consultez [Référence de plug-in de document Command](documents-command-ssm-plugin-reference.md)). Par défaut, le document SSM porte le nom `AWS-Noop`. Celui-ci n'effectue aucune opération sur le nœud géré.
Pour de plus amples informations sur la création d'un document SSM personnalisé, veuillez consulter [Création du contenu du document SSM](documents-creating-content.md).
### Nom du paramètre: `PostInstallHookDocName`
**Utilisation** : Facultatif.
**Par défaut** : `AWS-Noop`.
La valeur à fournir pour le paramètre `PostInstallHookDocName` est le nom ou l'Amazon Resource Name (ARN) d'un document SSM de votre choix. Vous pouvez fournir le nom d'un document AWS géré ou le nom ou l'ARN d'un document SSM personnalisé que vous avez créé ou qui a été partagé avec vous. (Pour un document SSM qui a été partagé avec vous à partir d'un autre document Compte AWS, vous devez spécifier l'ARN complet de la ressource, par exemple`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Le document SSM que vous spécifiez est exécuté après l'opération `Install with NoReboot` et effectue toutes les actions prises en charge par SSM Agent, par exemple un script shell pour installer des mises à jour tierces avant le redémarrage. (Pour obtenir la liste des actions, consultez [Référence de plug-in de document Command](documents-command-ssm-plugin-reference.md)). Par défaut, le document SSM porte le nom `AWS-Noop`. Celui-ci n'effectue aucune opération sur le nœud géré.
Pour de plus amples informations sur la création d'un document SSM personnalisé, veuillez consulter [Création du contenu du document SSM](documents-creating-content.md).
### Nom du paramètre: `OnExitHookDocName`
**Utilisation** : Facultatif.
**Par défaut** : `AWS-Noop`.
La valeur à fournir pour le paramètre `OnExitHookDocName` est le nom ou l'Amazon Resource Name (ARN) d'un document SSM de votre choix. Vous pouvez fournir le nom d'un document AWS géré ou le nom ou l'ARN d'un document SSM personnalisé que vous avez créé ou qui a été partagé avec vous. (Pour un document SSM partagé avec vous à partir d'un Compte AWS différent, vous devez spécifier l'ARN complet de la ressource, `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` par exemple.)
Le document SSM spécifié par vos soins est exécuté après l'opération de redémarrage du nœud géré et effectue toutes les actions prises en charge par SSM Agent, comme l'exécution d'un script shell pour vérifier l'état du nœud une fois l'opération d'application des correctifs terminée. (Pour obtenir la liste des actions, consultez [Référence de plug-in de document Command](documents-command-ssm-plugin-reference.md)). Par défaut, le document SSM porte le nom `AWS-Noop`. Celui-ci n'effectue aucune opération sur le nœud géré.
Pour de plus amples informations sur la création d'un document SSM personnalisé, veuillez consulter [Création du contenu du document SSM](documents-creating-content.md).
# Exemple de scénario d'utilisation du InstallOverrideList paramètre dans `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`
Vous pouvez utiliser le paramètre `InstallOverrideList` lorsque vous souhaitez remplacer les correctifs spécifiés par le référentiel de correctifs par défaut actuel dans Patch Manager, un outil d’ AWS Systems Manager. Cette rubrique fournit des exemples sur l'utilisation de ce paramètre pour atteindre les objectifs suivants :
+ Appliquez différents ensembles de correctifs à un groupe cible de nœuds gérés.
+ Appliquez ces ensembles de correctifs sur différentes fréquences.
+ Utilisez la même ligne de base de correctifs pour les deux opérations.
Supposons que vous souhaitez installer deux catégories différentes de correctifs sur vos nœuds gérés Amazon Linux 2. Vous souhaitez installer ces correctifs sur différents calendriers à l'aide de fenêtres de maintenance. Vous voulez qu'une fenêtre de maintenance s'exécute chaque semaine et installe tous les correctifs `Security`. Vous souhaitez qu'une autre fenêtre de maintenance s'exécute une fois par mois et installe tous les correctifs disponibles ou catégories de correctifs autres que `Security`.
Toutefois, une seule ligne de base de correctifs à la fois peut être définie comme valeur par défaut pour un système d'exploitation. Cette exigence permet d'éviter les situations où une ligne de base de correctifs approuve un correctif alors qu'une autre le bloque, ce qui peut entraîner des problèmes entre les versions conflictuelles.
La stratégie suivante vous permet d'utiliser le paramètre `InstallOverrideList` pour appliquer différents types de correctifs à un groupe cible, selon des calendriers différents, tout en utilisant le même référentiel de correctifs :
1. Dans la ligne de base du correctif par défaut, assurez-vous que seules les mises à jour `Security` sont spécifiées.
1. Créez une fenêtre de maintenance qui exécute `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation` chaque semaine. Ne spécifiez pas de liste de remplacement.
1. Créez une liste de remplacement des correctifs de tous les types que vous souhaitez appliquer chaque mois et stockez-la dans un compartiment Amazon Simple Storage Service (Amazon S3).
1. Créez une deuxième fenêtre de maintenance qui s'exécute une fois par mois. Toutefois, pour la tâche Run Command que vous inscrivez pour cette fenêtre de maintenance, spécifiez l'emplacement de votre liste de remplacement.
Résultat : seuls les correctifs `Security`, tels que définis dans votre ligne de base de correctifs par défaut, sont installés chaque semaine. Tous les correctifs disponibles, ou le sous-ensemble de correctifs que vous définissez, sont installés chaque mois.
**Note**
Lorsque vous appliquez des correctifs à un nœud qui utilise uniquement IPv6, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie. [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md)Pour plus d'informations sur la configuration de l'agent pour utiliser DualStack, reportez-vous à la section.
Pour plus d'informations et de listes d'exemples, veuillez consulter [Nom du paramètre: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Utilisation du BaselineOverride paramètre
Vous pouvez définir les préférences d’application de correctifs au moment de l’exécution en utilisant la fonction de remplacement de référentiel dans Patch Manager, un outil d’ AWS Systems Manager. Pour cela, spécifiez un compartiment Amazon Simple Storage Service (Amazon S3) contenant un objet JSON avec une liste de référentiels de correctifs. L'opération d'application de correctifs utilise les référentiels fournis dans l'objet JSON et correspondant au système d'exploitation hôte au lieu d'appliquer les règles du référentiel de correctifs par défaut.
**Important**
Le nom de fichier `BaselineOverride` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1).
Sauf lorsqu’une opération de correctif utilise une politique de correctifs, l’utilisation du paramètre `BaselineOverride` n’écrase pas la conformité du correctif du référentiel fourni dans le paramètre. Les résultats délivrés en sortie sont enregistrés dans les journaux Stdout de Run Command, un outil d’ AWS Systems Manager. Les résultats n'impriment que les packages marqués comme `NON_COMPLIANT`. Cela signifie que le package est marqué comme `Missing`, `Failed`, `InstalledRejected` ou `InstalledPendingReboot`.
Toutefois, lorsqu’une opération de correctif utilise une politique de correctifs, le système transmet le paramètre d’écrasement à partir du compartiment S3 associé, et la valeur de conformité est mise à jour pour le nœud géré. Pour plus d’informations sur les comportements des politiques de correctifs, consultez [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
**Note**
Lorsque vous appliquez des correctifs à un nœud qui utilise uniquement IPv6, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie. Consultez [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md) pour plus d'informations sur la configuration de l'agent pour utiliser Dualstack.
## Utilisation du remplacement du référentiel de correctifs par les paramètres d'ID d'instantané ou de liste de remplacement d'installation
Dans deux cas précis, le remplacement du référentiel de correctifs a un comportement remarquable.
**Utilisation simultanée du remplacement du référentiel et de l'ID d'instantané**
Les ID d'instantané permettent d'appliquer les mêmes correctifs sur tous les nœuds gérés associés à une commande particulière. Par exemple, si vous appliquez des correctifs sur 1 000 nœuds à la fois, il s'agit des mêmes correctifs.
Lorsque vous utilisez à la fois un ID d'instantané et un remplacement du référentiel de correctifs, l'ID d'instantané a priorité sur le remplacement du référentiel de correctifs. Les règles de remplacement du référentiel seront utilisées, mais elles ne seront évaluées qu'une seule fois. Dans l'exemple précédent, les correctifs appliqués à vos 1 000 nœuds gérés seront toujours les mêmes. Si, à mi-parcours de l'opération d'application de correctifs, vous avez modifié le fichier JSON dans le compartiment S3 référencé pour en faire quelque chose de différent, les correctifs appliqués ne changeront pas. Cela vient du fait que l'ID d'instantané a été fourni.
**Utilisation simultanée du remplacement du référentiel et de la liste de remplacement d'installation**
Vous ne pouvez pas utiliser ces deux paramètres en même temps. Le document d'application de correctifs échoue si les deux paramètres sont fournis, et il ne procède alors à aucune analyse ou installation sur le nœud géré.
## Exemples de code
L'exemple de code suivant pour Python montre la génération du remplacement du référentiel de correctifs.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
Voici comment se produit un remplacement du référentiel de correctifs :
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# Références de correctifs
Les rubriques de cette section fournissent des informations sur le fonctionnement des référentiels de correctifs dans l’outil Patch Manager d’AWS Systems Manager lorsque vous exécutez une opération `Scan` ou `Install` sur vos nœuds gérés.
**Topics**
+ [Référentiels de correctifs prédéfinis et personnalisés](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formats de noms de package pour les listes de correctifs approuvés et rejetés](patch-manager-approved-rejected-package-name-formats.md)
+ [Groupes de correctifs](patch-manager-patch-groups.md)
+ [Correction d’applications publiées par Microsoft sur Windows Server](patch-manager-patching-windows-applications.md)
# Référentiels de correctifs prédéfinis et personnalisés
Patch Manager, un outil dans AWS Systems Manager, fournit des lignes de base de correctifs prédéfinies pour chacun des systèmes d'exploitation pris en charge parPatch Manager. Vous pouvez utiliser ces lignes de base telles qu'elles sont actuellement configurées (vous ne pouvez pas les personnaliser) ou vous pouvez créer vos propres lignes de base de correctifs personnalisées. Les lignes de base de correctifs personnalisées vous permettent de mieux contrôler les correctifs approuvés ou rejetés pour votre environnement. En outre, les lignes de base prédéfinies attribuent un niveau de conformité `Unspecified` à tous les correctifs installés à l'aide de ces lignes de base. Pour que les valeurs de conformité soient affectées, vous pouvez créer une copie d'une ligne de base prédéfinie et spécifier les valeurs de conformité que vous souhaitez affecter aux correctifs. Pour plus d'informations, consultez [Références personnalisées](#patch-manager-baselines-custom) et [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).
**Note**
Les informations de cette rubrique 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**
+ [Référentiels prédéfinis](#patch-manager-baselines-pre-defined)
+ [Références personnalisées](#patch-manager-baselines-custom)
## Référentiels prédéfinis
Le tableau ci-dessous décrit les références de correctifs prédéfinies fournies avec Patch Manager.
Pour plus d'informations sur les versions de chaque système d'exploitation que Patch Manager prend en charge, consultez [conditions préalables requises de l’Patch Manager](patch-manager-prerequisites.md).
****
| Nom | Système d'exploitation pris en charge | Détails |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». Approuve également tous les correctifs classés comme « Bugfix » (Correctif de bogue). L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». Avec une classification « Bugfix », l'approbation automatique de tous les correctifs est possible. L'approbation automatique des correctifs se fait 7 jours après leur publication.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». Les correctifs sont approuvés automatiquement sept jours après leur publication. Approuve également tous les correctifs avec une classification « Bugfix (correctif de bogue) » sept jours après leur publication. |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Approuvez toutes les mises à jour 7 jours après leur disponibilité, notamment les mises à jour non liées à la sécurité. |
| AWS-DebianDefaultPatchBaseline | Debian Server | Approuve immédiatement tous les correctifs de système d'exploitation relatifs à la sécurité qui ont une priorité « Required (Obligatoire) », « Important (Importante) », « Standard », « Optional (Facultative) » ou « Extra ». L'approbation est immédiate, car les dates de publication fiables sont indisponibles dans le référentiel. |
| AWS-MacOSDefaultPatchBaseline | macOS | Approuve tous les correctifs de système d'exploitation classifiés comme « liés à la sécurité » Approuve également tous les packages faisant l'objet d'une mise à jour. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Important » ou « Moderate (Modéré) ». Approuve également tous les correctifs classés comme « Bugfix » (Correctif de bogue) 7 jours après leur publication. L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». Approuve également tous les correctifs classés comme « Bugfix » (Correctif de bogue). L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Approuve tous les correctifs de système d'exploitation qui sont classés dans la section « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». Approuve également tous les correctifs classés comme « Bugfix » (Correctif de bogue). L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Approuve tous les correctifs de système d'exploitation qui sont classés en tant que « Security (Sécurité) » et qui ont un niveau de sévérité « Critical (Critique) » ou « Important ». L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Approuve immédiatement tous les correctifs de système d'exploitation relatifs à la sécurité qui ont une priorité « Required (Obligatoire) », « Important (Importante) », « Standard », « Optional (Facultative) » ou « Extra ». L'approbation est immédiate, car les dates de publication fiables sont indisponibles dans le référentiel. |
| AWS-DefaultPatchBaseline | Windows Server | Approuve tous les correctifs du système Windows Server d'exploitation classés comme « CriticalUpdates » ou « SecurityUpdates » et dont le niveau de gravité MSRC est « Critique » ou « Important ». L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Approuve tous les correctifs du système Windows Server d'exploitation classés comme « CriticalUpdates » ou « SecurityUpdates » et dont le niveau de gravité MSRC est « Critique » ou « Important ». L'approbation automatique des correctifs se fait 7 jours après leur publication ou leur mise à jour.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Pour le système Windows Server d'exploitation, approuve tous les correctifs classés comme « » ou CriticalUpdates « SecurityUpdates » et dont le niveau de gravité MSRC est « Critique » ou « Important ». Pour les applications publiées par Microsoft, approuve tous les correctifs. Les correctifs de système d'exploitation et d'applications sont automatiquement approuvés 7 jours après leur publication.² |
¹ Pour Amazon Linux 2, l’attente de 7 jours avant l’approbation automatique des correctifs est calculée à partir d’une valeur `Updated Date` dans `updateinfo.xml`, pas une valeur `Release Date`. Divers facteurs peuvent affecter la valeur `Updated Date`. Les autres systèmes d'exploitation gèrent les dates de sortie ainsi que de mise à jour de façon différente. Pour des informations vous permettant d'éviter des résultats inattendus avec les délais d'approbation automatique, consultez [Calcul des dates de sortie et des mises à jour des packages](patch-manager-release-dates.md).
² Pour Windows Server, les références par défaut incluent un délai d'approbation automatique de 7 jours. Pour installer un correctif dans les 7 jours suivant sa publication, vous devez créer une base de référence personnalisée.
## Références personnalisées
Utilisez les informations suivantes pour vous aider à créer des référentiels de correctifs personnalisés afin d’atteindre vos objectifs en matière d’application de correctifs.
**Topics**
+ [Utilisation des approbations automatiques dans les référentiels personnalisés](#baselines-auto-approvals)
+ [Informations complémentaires pour la création de référentiels de correctifs](#baseline-additional-info)
### Utilisation des approbations automatiques dans les référentiels personnalisés
Si vous créez votre propre référentiel de correctifs, vous pouvez choisir les correctifs à approuver automatiquement en utilisant les catégories suivantes.
+ **Système d’exploitation** : versions prises en charge de Windows Server, Amazon Linux, Ubuntu Server, etc.
+ **Nom du produit** (pour les systèmes d'exploitation) : par exemple, RHEL 7.5, Amazon Linux 2023, 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2, etc.
+ **Nom du produit** (pour les applications publiées par Microsoft Windows Server uniquement) : par exemple, Word 2016, BizTalk Server, etc.
+ **Classification** : par exemple, mises à jour critiques, mises à jour de sécurité, etc.
+ **Sévérité** : par exemple, critique, important, etc.
Pour chaque règle d'approbation que vous créez, vous pouvez choisir de spécifier un délai d'approbation automatique ou une date limite d'approbation des correctifs.
**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.
Le délai d'approbation automatique correspond au nombre de jours à attendre après la publication ou la dernière mise à jour du correctif, ceci avant que ce dernier ne soit automatiquement approuvé pour application. Par exemple, si vous créez une règle à l'aide de la classification `CriticalUpdates` et que vous la configurez pour un délai d'approbation automatique de 7 jours, un nouveau correctif critique publié le 7 juillet sera automatiquement approuvé le 14 juillet.
Si un référentiel Linux 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 de date d’approbation automatique pour Amazon Linux 2, Amazon Linux 2023 et Red Hat Enterprise Linux (RHEL). 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.
Lorsque vous indiquez une date limite d'auto-approbation, Patch Manager tous les correctifs publiés ou mis à jour à cette date ou avant sont automatiquement appliqués. Par exemple, si vous indiquez le 7 juillet 2023 comme date limite, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
Lorsque vous créez un référentiel de correctifs personnalisé, vous pouvez spécifier un niveau de sévérité de conformité pour les correctifs approuvés par ce référentiel de correctifs, tel que `Critical` ou `High`. Si l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
### Informations complémentaires pour la création de référentiels de correctifs
Gardez les points suivants à l'esprit lorsque vous créez un référentiel de correctifs :
+ Patch Manager fournit un référentiel de correctifs prédéfini pour chaque système d'exploitation pris en charge. Ces références de correctifs prédéfinies sont utilisées en tant que références de correctifs par défaut pour chaque type de système d'exploitation, sauf si vous créez votre propre référentiel de correctifs et que vous la définissez comme le référentiel par défaut pour le type de système d'exploitation correspondant.
**Note**
Pour Windows Server, trois référentiels de correctifs prédéfinis sont fournis. Les référentiels de correctifs `AWS-DefaultPatchBaseline` et `AWS-WindowsPredefinedPatchBaseline-OS` prennent uniquement en charge les mises à jour du système d'exploitation Windows. `AWS-DefaultPatchBaseline` est utilisé comme référentiel de correctifs par défaut pour les nœuds gérés Windows Server, sauf si vous en spécifiez un autre. Ces deux référentiels de correctifs ont des paramètres de configuration identiques. Le plus récent des deux, `AWS-WindowsPredefinedPatchBaseline-OS`, a été créé pour le différencier du troisième référentiel de correctifs prédéfini pour Windows Server. Ce référentiel de correctifs, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, peut être utilisé pour appliquer des correctifs à la fois au système d'exploitation Windows Server et aux applications prises en charge publiées par Microsoft.
+ 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 nouveau correctif n’est pas installé lors de l’exécution de l’application de correctifs. Pour plus d’informations sur les règles d’application de correctifs Windows Server, consultez l’onglet Windows Server dans [Sélection des correctifs de sécurité](patch-manager-selecting-patches.md).
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é.
+ Pour Windows Server uniquement, un correctif de mise à jour de sécurité disponible qui n’est pas approuvé par le référentiel de correctifs peut avoir une valeur de conformité de `Compliant` ou `Non-Compliant`, comme défini dans un référentiel de correctifs personnalisé.
Lorsque vous créez ou mettez à jour un référentiel de correctifs, vous choisissez le statut que vous souhaitez attribuer aux correctifs de sécurité disponibles mais non approuvés car ils ne répondent pas aux critères d’installation spécifiés dans le référentiel de correctifs. Par exemple, les correctifs de sécurité que vous souhaitez installer peuvent être ignorés si vous avez spécifié une longue période d’attente après la publication d’un correctif avant l’installation. Si une mise à jour du correctif est publiée pendant la période d’attente que vous avez spécifiée, la période d’attente pour l’installation du correctif recommence. Si le délai d’attente est trop long, plusieurs versions du correctif peuvent être publiées mais ne jamais être installées.
En utilisant la console pour créer ou mettre à jour un référentiel de correctifs, vous spécifiez cette option dans le champ **Statut de conformité des mises à jour de sécurité disponibles**. AWS CLI À l'aide de la [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)commande pour exécuter [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)ou, vous spécifiez cette option dans le `available-security-updates-compliance-status` paramètre.
+ Pour les serveurs locaux et les machines virtuelles (VMs), Patch Manager tente d'utiliser votre ligne de base de correctifs par défaut personnalisée. S'il n'existe aucun référentiel de correctifs personnalisée par défaut, le système utilise le référentiel de correctifs prédéfinie pour le système d'exploitation correspondant.
+ Si un correctif est répertorié comme approuvé et refusé dans la même référentiel de correctifs, le correctif est refusé.
+ Vous ne pouvez définir qu'un seul référentiel de correctifs par nœud géré.
+ Les formats de noms de package que vous pouvez ajouter à la liste des correctifs approuvés et rejetés pour un référentiel de correctifs dépendent du type de système d'exploitation auquel vous appliquez des correctifs.
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).
+ Si vous utilisez une [configuration de politique de correctifs](patch-manager-policies.md) dans Quick Setup, les mises à jour que vous apportez aux référentiels de correctifs personnalisés sont synchronisées avec Quick Setup une fois par heure.
Si un référentiel de correctifs personnalisé référencé dans une politique de correctifs est supprimé, une bannière s'affiche sur la page Quick Setup **Configuration details** (Détails de configuration) de votre politique de correctifs. La bannière vous informe que la politique de correctifs fait référence à un référentiel de correctifs qui n'existe plus et que les opérations d'application de correctifs suivantes échoueront. Dans ce cas, revenez à la page Quick Setup **Configurations**, sélectionnez la configuration Patch Manager, puis choisissez **Actions**, **Edit configuration** (Modifier la configuration). Le nom du référentiel de correctifs supprimé est surligné et vous devez sélectionner un nouveau référentiel de correctifs pour le système d'exploitation concerné.
+ Lorsque vous créez une règle d’approbation comportant plusieurs valeurs `Classification` et `Severity`, les correctifs sont approuvés en fonction de leurs attributs disponibles. Les packages comportant à la fois les attributs `Classification` et `Severity` correspondront aux valeurs de référence sélectionnées pour les deux champs. Les packages contenant uniquement des attributs `Classification` ne sont comparés qu’aux valeurs de référence `Classification` sélectionnées. Les exigences de sévérité de la même règle sont ignorées pour les packages dépourvus d’attributs `Severity`.
Pour plus d'informations sur la création d'un référentiel de correctifs, consultez [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md) et [Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
# Formats de noms de package pour les listes de correctifs approuvés et rejetés
Les formats de noms de package que vous pouvez ajouter à la liste des correctifs approuvés et rejetés dépendent du type de système d'exploitation auquel vous appliquez des correctifs.
## Formats de noms de package pour les systèmes d'exploitation Linux
Les formats que vous pouvez spécifier pour les correctifs approuvés et rejetés dans votre référentiel de correctifs varient selon le type de système Linux. Plus précisément, les formats qui sont pris en charge dépendent du gestionnaire de package utilisé par le type de système d'exploitation Linux.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux et Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server et Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2, Amazon Linux 2023, Oracle Linux et Red Hat Enterprise Linux (RHEL)
**Gestionnaire de packages **: YUM, à l’exception d’Amazon Linux 2023 et de RHEL 8, qui utilisent DNF comme gestionnaire de packages
**Correctifs approuvés** : pour les correctifs approuvés, vous pouvez spécifier l'un des éléments suivants :
+ Bugzilla IDs, au format `1234567` (Le système traite les chaînes contenant uniquement des nombres comme Bugzilla.) IDs
+ CVE IDs, au format `CVE-2018-1234567`
+ Avis IDs, dans des formats tels que `RHSA-2017:0864` et `ALAS-2018-123`
+ Noms de packages construits à l’aide d’un ou plusieurs des composants disponibles pour le nommage des packages. Par exemple, pour le package nommé `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, les composants sont les suivants :
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Les noms de package avec les constructions suivantes sont pris en charge :
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Voici quelques exemples :
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Nous prenons également en charge les composants de nom de package avec un seul caractère générique dans les formats ci-dessus, tels que les suivants :
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**Correctifs rejetés** : pour les correctifs rejetés, vous pouvez spécifier l'un des éléments suivants :
+ Noms de packages construits à l’aide d’un ou plusieurs des composants disponibles pour le nommage des packages. Par exemple, pour le package nommé `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, les composants sont les suivants :
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Les noms de package avec les constructions suivantes sont pris en charge :
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Voici quelques exemples :
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ Nous prenons également en charge les composants de nom de package avec un seul caractère générique dans les formats ci-dessus, tels que les suivants :
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server et Ubuntu Server
**Gestionnaire de package** : APT
**Correctifs approuvés** et **correctifs rejetés** : pour les correctifs approuvés comme rejetés, spécifiez l'un des éléments suivants :
+ Noms de package, au format `ExamplePkg33`
**Note**
Pour les listes Debian Server et les listes Ubuntu Server, n’incluez pas d’éléments tels que l’architecture ou les versions. Par exemple, vous spécifiez le nom de package `ExamplePkg33` pour inclure tous les éléments suivants dans une liste de correctifs :
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**Gestionnaire de package** : Zypper
**Correctifs approuvés** et **correctifs rejetés** : pour les listes de correctifs approuvés comme rejetés, vous pouvez spécifier l'un des éléments suivants :
+ Noms de package complets, dans des formats tels que :
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Noms de package avec un seul caractère générique, tels que :
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## Formats de noms de package pour macOS
**Gestionnaires de packages pris en charge** : softwareupdate, programme d'installation, Brew, Brew Cask
**Correctifs approuvés** et **correctifs rejetés** : pour les listes de correctifs approuvés et de correctifs rejetés, vous pouvez spécifier des noms de packages complets, dans l'un des formats suivants :
+ `XProtectPlistConfigData`
+ `MRTConfigData`
Les caractères génériques ne sont pas pris en charge dans les listes de correctifs approuvés et rejetés pour macOS.
## Formats de noms de package pour les systèmes d'exploitation Windows
Pour les systèmes d'exploitation Windows, spécifiez les correctifs à l'aide de la base de connaissances Microsoft IDs et du bulletin de sécurité Microsoft IDs ; par exemple :
```
KB2032276,KB2124261,MS10-048
```
# Groupes de correctifs
**Note**
Les groupes de correctifs ne sont pas utilisés dans les opérations d'application de correctifs basées sur des *politiques de correctifs*. Pour obtenir des informations sur l'utilisation des politiques de correctifs, consultez la rubrique [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
La fonctionnalité de groupes de correctifs n’est pas prise en charge dans la console pour les paires compte-région qui n’utilisaient pas encore de groupes de correctifs avant le lancement de la prise en charge des politiques de correctifs le 22 décembre 2022. La fonctionnalité de groupes de correctifs est toujours disponible dans les paires compte-région qui ont commencé à utiliser les groupes de correctifs avant cette date.
Vous pouvez utiliser un *groupe de correctifs* pour associer des nœuds gérés à un référentiel de correctifs spécifique dans l’outil Patch Manager d’AWS Systems Manager. Les groupes de correctifs vous permettent de vous assurer que vous déployez les correctifs appropriés, conformément aux règles de référentiel de correctifs associées, pour le groupe de nœuds adéquat. Les groupes de correctifs peuvent également vous aider à éviter le déploiement de correctifs avant qu'ils aient été testés correctement. Par exemple, vous pouvez créer des groupes de correctifs pour différents environnements (par exemple, développement, test ou production) et enregistrer chaque groupe de correctifs dans un référentiel de correctifs appropriée.
Lorsque vous exécutez `AWS-RunPatchBaseline` ou d’autres documents de commande SSM pour l’application de correctifs, vous pouvez cibler les nœuds gérés à l’aide de leur ID ou de leurs balises. SSM Agent et Patch Manager déterminent alors quel est le référentiel de correctifs à utiliser en fonction de la valeur de groupe de correctifs que vous avez ajoutée au nœud géré.
## Utiliser des balises pour définir des groupes de correctifs
Vous pouvez créer un groupe de correctifs en utilisant des balises appliquées à vos instances Amazon Elastic Compute Cloud (Amazon EC2) et aux nœuds non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Notez les détails suivants sur l’utilisation des balises pour les groupes de correctifs :
+
Un groupe de correctifs doit être défini à l’aide de la clé de balise `Patch Group` ou `PatchGroup` appliquée à vos nœuds gérés. Lors de l’enregistrement d’un groupe de correctifs pour un référentiel de correctifs, toutes les *valeurs* identiques spécifiées pour ces deux clés sont interprétées comme faisant partie du même groupe. Supposons, par exemple, que vous ayez balisé cinq nœuds avec la première des paires clé-valeur suivantes, et cinq avec la seconde :
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
La commande Patch Manager de création d’un référentiel combine ces 10 nœuds gérés en un seul groupe en fonction de la valeur `DEV`. L’équivalent AWS CLI permettant de créer un référentiel de correctifs pour les groupes de correctifs est la commande suivante :
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
La combinaison de valeurs provenant de différentes clés en une seule cible est propre à cette commande Patch Manager pour créer un nouveau groupe de correctifs et n’est pas prise en charge par d’autres actions d’API. Par exemple, si vous exécutez des actions [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) avec des clés `PatchGroup` et `Patch Group` ayant les mêmes valeurs, vous ciblez deux ensembles de nœuds complètement différents :
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ Le ciblage basé sur les balises est soumis à des limites. Chaque tableau de cibles pour `SendCommand` peut contenir un maximum de cinq paires clé-valeur.
+ Nous vous recommandons de ne choisir qu’une seule de ces conventions de clés de balise, soit `PatchGroup` (sans espace), soit `Patch Group` (avec espace). Cependant, si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), vous devez utiliser `PatchGroup`.
+ La clé est sensible à la casse. Vous pouvez spécifier n’importe quelle *valeur* pour vous aider à identifier et à cibler les ressources de ce groupe, par exemple « serveurs web » ou « US-EAST-PROD », cependant la clé doit être `Patch Group` ou `PatchGroup`.
Après avoir créé un groupe de correctifs et attribué des balises aux nœuds gérés, vous pouvez enregistrer le groupe de correctifs auprès d'un référentiel de correctifs. L'enregistrement du groupe de correctifs auprès d'un référentiel de correctifs garantit que les nœuds du groupe de correctifs utiliseront les règles définies dans le référentiel de correctifs associé.
Pour de plus amples informations sur la création d'un groupe de correctifs et son association à un référentiel de correctifs, consultez [Création et gestion de groupes de correctifs](patch-manager-tag-a-patch-group.md) et [Ajout d'un groupe de correctifs à un référentiel de correctifs](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).
Pour voir un exemple de création d'un référentiel de correctifs et de groupes de correctifs à l'aide de l'AWS Command Line Interface (AWS CLI), consultez [Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Pour de plus amples informations sur les balises Amazon EC2, veuillez consulter [Baliser vos ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) dans le *Guide de l’utilisateur Amazon EC2*.
## Fonctionnement
Lorsque le système applique un référentiel de correctifs à un nœud géré, SSM Agent vérifie si une valeur de groupe de correctifs est définie pour le nœud. Si le nœud est attribué à un groupe de correctifs, Patch Manager vérifie alors quel référentiel de correctifs est enregistré pour ce groupe. S'il existe un référentiel de correctifs pour ce groupe, Patch Manager demande à l'SSM Agent de l'utiliser. Si un nœud n'est attribué à aucun groupe de correctifs, Patch Manager demande automatiquement à SSM Agent d'utiliser le référentiel de correctifs par défaut.
**Important**
Un nœud géré ne peut appartenir qu'à un seul groupe de correctifs.
Un groupe de correctifs peut être enregistré avec un seule référentiel de correctifs pour chaque type de système d'exploitation.
Vous ne pouvez pas appliquer la `Patch Group` balise (avec un espace) à une instance Amazon EC2 si l'option ** Autoriser les balises dans les métadonnées d'instance ** est activée sur celle-ci. L'autorisation des identifications dans les métadonnées d'instance empêche les noms de clés d'identification de contenir des espaces. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), vous devez utiliser la clé de la balise `PatchGroup` (sans espace).
**Diagramme 1 : Exemple général de flux de processus d'opérations d'application de correctifs**
L’illustration suivante présente un exemple général des processus exécutés par Systems Manager lors de l’envoi à votre flotte de serveurs d’une tâche Run Command d’application de correctifs à l’aide du Patch Manager. Ces processus déterminent les référentiels de correctifs à utiliser dans les opérations de correctifs. (Un processus similaire est utilisé lorsqu’une fenêtre de maintenance est configurée pour envoyer une commande d’application de correctifs à l’aide du Patch Manager.)
Le processus complet est expliqué sous l’illustration.
![\[Flux de travail de Patch Manager pour déterminer les référentiels de correctifs à utiliser lors des opérations de correctifs.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
Cet exemple illustre trois groupes d'instances EC2 pour Windows Server avec les balises suivantes appliquées :
****
| Groupe d'instances EC2 | Balises |
| --- | --- |
| Groupe 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| Groupe 2 | `key=OS,value=Windows` |
| Groupe 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
Dans cet exemple, nous avons également ces deux référentiels de correctifs Windows Server :
****
| ID de référence de correctif | Par défaut | Groupe de correctifs associé |
| --- | --- | --- |
| `pb-0123456789abcdef0` | Oui | `Default` |
| `pb-9876543210abcdef0` | Non | `DEV` |
La procédure générale d’analyse ou d’installation des correctifs à l’aide de Run Command, un des outils d’AWS Systems Manager et de Patch Manager se présente comme suit :
1. **Envoi d'une commande de correctif** : utilisez la console Systems Manager, le kit SDK, l'AWS Command Line Interface (AWS CLI) ou AWS Tools for Windows PowerShell pour envoyer une tâche Run Command à l'aide du document `AWS-RunPatchBaseline`. Le diagramme illustre une tâche Run Command d'application de correctifs aux instances gérées en ciblant la balise `key=OS,value=Windows`.
1. **Détermination du référentiel de correctifs** : SSM Agent vérifie les balises de groupe de correctifs appliquées à l'instance EC2 et interroge Patch Manager concernant le référentiel de correctifs correspondante.
+ **Mise en correspondance de la valeur du groupe de correctifs associée avec le référentiel de correctifs:**
1. L'SSM Agent, qui est installé sur les instances EC2 dans un groupe, reçoit la commande émise à l'étape 1 lui indiquant de lancer une opération d'application de correctifs. L'SSM Agent vérifie que la valeur-balise de groupe de correctifs appliquée aux instances EC2 est `DEV` et interroge Patch Manager concernant le référentiel de correctifs associée.
1. Patch Manager vérifie que le référentiel de correctifs `pb-9876543210abcdef0` est associée au groupe de correctifs `DEV` et informe l'SSM Agent.
1. L'SSM Agent récupère un instantané de référentiel de correctifs depuis Patch Manager en fonction des règles d'approbation et des exceptions configurées dans `pb-9876543210abcdef0`, puis passe à l'étape suivante.
+ **Aucune balise de groupe de correctifs n'est ajoutée à l'instance :**
1. SSM Agent, qui est installé sur les instances EC2 du groupe deux, reçoit la commande émise à l'étape 1 pour commencer une opération de correction. SSM Agent valide que les instances EC2 n'ont pas de balise `Patch Group` ou `PatchGroup` appliquée et, par conséquent, SSM Agent demande Patch Manager la ligne de base de correction Windows par défaut.
1. Patch Manager vérifie que le référentiel de correctifs Windows Server par défaut est `pb-0123456789abcdef0` et en avertit l'SSM Agent.
1. L'SSM Agent récupère un instantané de référentiel de correctifs depuis Patch Manager en fonction des règles d'approbation et des exceptions configurées dans le référentiel de correctifs par défaut `pb-0123456789abcdef0`, puis passe à l'étape suivante.
+ **Aucune valeur de groupe de correctifs correspondante n'est associée à un référentiel de correctifs:**
1. L'SSM Agent, qui est installé sur les instances EC2 du groupe trois, reçoit la commande émise à l'étape 1 lui indiquant de lancer une opération d'application de correctifs. L'SSM Agent vérifie que la valeur-balise de groupe de correctifs appliquée aux instances EC2 est `QA` et interroge Patch Manager concernant le référentiel de correctifs associée.
1. Patch Manager ne trouve aucun référentiel de correctifs associée au groupe `QA`.
1. Patch Manager demande à l'SSM Agent d'utiliser le référentiel de correctifs Windows par défaut `pb-0123456789abcdef0`.
1. L'SSM Agent récupère un instantané de référentiel de correctifs depuis Patch Manager en fonction des règles d'approbation et des exceptions configurées dans le référentiel de correctifs par défaut `pb-0123456789abcdef0`, puis passe à l'étape suivante.
1. **Recherche ou installation des correctifs** : Après avoir déterminé le référentiel de correctifs appropriée à utiliser, l'SSM Agent commence à rechercher ou à installer les correctifs en fonction de la valeur d'opération spécifiée à l'étape 1. Les correctifs qui sont recherchés ou installés sont déterminés par les règles d'approbation et les exceptions de correctifs définies dans l'instantané de référentiel de correctifs fourni par Patch Manager.
**Plus d'informations**
+ [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md)
# Correction d’applications publiées par Microsoft sur Windows Server
Utilisez les informations de cette rubrique pour vous préparer à corriger des applications sur Windows Server en utilisant Patch Manager, un outil d’ AWS Systems Manager.
**Correction d'applications Microsoft**
La prise en charge de l'installation de correctifs destinés aux applications sur les nœuds gérés par Windows Server s'applique uniquement aux applications publiées par Microsoft.
**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.
**Référentiels de correctifs pour corriger des applications publiées par Microsoft**
Pour Windows Server, trois référentiels de correctifs prédéfinis sont fournis. Les référentiels de correctifs `AWS-DefaultPatchBaseline` et `AWS-WindowsPredefinedPatchBaseline-OS` prennent uniquement en charge les mises à jour du système d'exploitation Windows. `AWS-DefaultPatchBaseline` est utilisé comme référentiel de correctifs par défaut pour les nœuds gérés Windows Server, sauf si vous en spécifiez un autre. Ces deux référentiels de correctifs ont des paramètres de configuration identiques. Le plus récent des deux, `AWS-WindowsPredefinedPatchBaseline-OS`, a été créé pour le différencier du troisième référentiel de correctifs prédéfini pour Windows Server. Ce référentiel de correctifs, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, peut être utilisé pour appliquer des correctifs à la fois au système d'exploitation Windows Server et aux applications prises en charge publiées par Microsoft.
Vous pouvez également créer un référentiel de correctifs personnalisé pour mettre à jour les applications publiées par Microsoft sur les machines Windows Server.
**Prise en charge de l'application des correctifs publiés par Microsoft sur les serveurs sur site, les périphériques, les machines virtuelles et d'autres nœuds non EC2**
Pour appliquer des correctifs aux applications publiées par Microsoft sur les machines virtuelles (VM) et les autres nœuds gérés non EC2, vous devez activer le niveau des instances avancées. L'utilisation du niveau d'instance avancé est facturée. **La correction d'applications publiées par Microsoft sur des instances Amazon Elastic Compute Cloud (Amazon EC2) n'induit aucuns frais supplémentaires.** Pour de plus amples informations, veuillez consulter [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md).
**Option de mise à jour Windows pour d'« autres produits Microsoft »**
Pour permettre à Patch Manager d'installer des correctifs destinés aux applications publiées par Microsoft sur vos nœuds gérés Windows Server, l'option Windows Update **Me communiquer les mises à jour d'autres produits Microsoft lorsque je mets à jour Windows** doit être activée sur le nœud géré.
Pour savoir comment autoriser cette option sur un nœud géré individuel, consultez [Mise à jour d'Office avec Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) sur le site web du support technique Microsoft.
Pour une flotte de nœuds gérés exécutant Windows Server 2016 ou version ultérieure, vous pouvez activer le paramètre à l'aide d'un objet de politique de groupe (GPO). Dans l'éditeur de gestion des politiques de groupe, accédez à **Configuration de l'ordinateur**, **Modèles administratifs**, **Composants Windows**, **Mises à jour Windows**, puis sélectionnez **Installer des mises à jour pour d'autres produits Microsoft**. Nous recommandons également de configurer l'objet de politique de groupe avec des paramètres supplémentaires qui empêchent les mises à jour automatiques imprévues et les redémarrages en dehors de Patch Manager. Pour de plus amples informations, veuillez vous reporter à [Configuration des mises à jour automatiques dans un environnement non Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) sur le site web de documentation technique de Microsoft.
Pour une flotte de nœuds gérés exécutant Windows Server 2012 ou 2012 R2, vous pouvez activer l'option à l'aide d'un script, comme décrit dans [Enabling and Disabling Microsoft Update in Windows 7 via Script (Activation et désactivation de Microsoft Update dans Windows 7 via un script)](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) sur le site web Microsoft Docs Blog. Par exemple, vous pouvez effectuer les opérations suivantes :
1. Enregistrez le script à partir de l'article de blog dans un fichier.
1. Chargez le fichier dans un compartiment Amazon Simple Storage Service (Amazon S3) ou un autre emplacement accessible.
1. Utilisez Run Command un outil pour exécuter le script sur vos nœuds gérés à l'aide du document Systems Manager (document SSM) `AWS-RunPowerShellScript` avec une commande similaire à la suivante. AWS Systems Manager
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**Exigences de paramètres minimales**
Pour inclure des applications publiées par Microsoft dans votre référentiel de correctifs personnalisé, vous devez, au minimum, spécifier le produit auquel vous souhaitez appliquer un correctif. La commande suivante AWS Command Line Interface (AWS CLI) décrit la configuration minimale requise pour appliquer un correctif à un produit, tel que Microsoft Office 2016.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Si vous spécifiez la famille de produits des applications Microsoft, chaque produit que vous spécifiez doit être un membre pris en charge de la famille de produits sélectionnée. Par exemple, pour appliquer un correctif au produit « Active Directory Rights Management Services Client 2.0 », vous devez spécifier sa famille de produits sous la forme « Active Directory » et non pas, par exemple, sous la forme « Office » ou « SQL Server ». La AWS CLI commande suivante illustre une association correspondante entre la famille de produits et le produit.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**Note**
Si vous recevez un message d'erreur sur un défaut d'appariement de produits et de familles, veuillez consulter [Problème : paires de produits family/product incompatibles](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) pour obtenir de l'aide afin de résoudre le problème.
# Utilisation de Kernel Live Patching sur des nœuds gérés Amazon Linux 2
Kernel Live Patching pour Amazon Linux 2 vous permet d'appliquer des correctifs de vulnérabilité de sécurité et de bogues critiques à un noyau Linux en cours d'exécution, sans redémarrer ni interrompre les applications en cours d'exécution. Cela vous permet de bénéficier d'une meilleure disponibilité des services et des applications, tout en profitant d'une infrastructure sécurisée et à jour. Kernel Live Patching est pris en charge sur les instances Amazon EC2, sur les appareils Core AWS IoT Greengrass et sur les [machines virtuelles sur site](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) qui exécutent Amazon Linux 2.
[Pour obtenir des informations générales à ce sujetKernel Live Patching, consultez Kernel Live Patching le *guide de l'utilisateur Amazon Linux 2*. AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)
Après avoir activé Kernel Live Patching sur un nœud géré Amazon Linux 2, vous pouvez utiliser Patch Manager, un outil d’ AWS Systems Manager pour appliquer des correctifs à chaud du noyau au nœud géré. L'utilisation de Patch Manager est une alternative à l'utilisation de flux de travail yum existants sur le nœud pour appliquer les mises à jour.
**Avant de commencer**
Pour utiliser Patch Manager afin d'appliquer des correctifs à chaud du noyau sur vos nœuds gérés Amazon Linux 2, assurez-vous que vos nœuds sont basés sur la bonne architecture et la bonne version du noyau. Pour obtenir des informations, veuillez consulter [Configurations et conditions préalables prises en charge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) dans le* Guide de l’utilisateur Amazon EC2*.
**Topics**
+ [Kernel Live Patching utilisant Patch Manager](#about-klp)
+ [Fonctionnement de Kernel Live Patching en utilisant Patch Manager](#how-klp-works)
+ [Activez Kernel Live Patching en utilisant Run Command](enable-klp.md)
+ [Application des correctifs à chaud du noyau à l'aide de Run Command](install-klp.md)
+ [Désactiver Kernel Live Patching en utilisant Run Command](disable-klp.md)
## Kernel Live Patching utilisant Patch Manager
Mise à jour de la version du noyau
Il n'est pas nécessaire de redémarrer un nœud géré après avoir appliqué un correctif à chaud du noyau. Cependant, AWS fournit des correctifs dynamiques du noyau pour une version du noyau Amazon Linux 2 jusqu'à trois mois après sa sortie. Après la période de 3 mois, vous devez effectuer une mise à jour vers une version ultérieure du noyau pour continuer à recevoir les correctifs à chaud du noyau. Nous vous recommandons d'utiliser une fenêtre de maintenance pour planifier un redémarrage de votre nœud au moins une fois tous les trois mois afin de demander la mise à jour de la version du noyau.
Désinstallation des correctifs live du noyau
Les correctifs live du noyau ne peuvent pas être désinstallés à l'aide de Patch Manager. Au lieu de cela, vous pouvez désactiver Kernel Live Patching, ce qui supprime les packages RPM pour les correctifs live du noyau appliqués. Pour de plus amples informations, veuillez consulter [Désactiver Kernel Live Patching en utilisant Run Command](disable-klp.md).
Conformité du noyau
Dans certains cas, l'installation de tous les correctifs CVE à partir de correctifs live pour la version actuelle du noyau peut amener ce noyau dans le même état de conformité qu'une version plus récente du noyau. La version la plus récente est alors signalée comme `Installed`, tandis que le nœud géré est signalé comme `Compliant`. Cependant, aucune heure d'installation n'est signalée pour la version plus récente du noyau.
Un correctif dynamique pour le noyau, plusieurs CVEs
Si un correctif actif du noyau en adresse plusieurs CVEs et CVEs que celles-ci ont des valeurs de classification et de gravité différentes, seules les catégories et les niveaux de gravité les plus élevés CVEs sont signalées pour le correctif.
Le reste de cette section explique comment utiliser Patch Manager pour appliquer les correctifs à chaud du noyau aux nœuds gérés qui répondent à ces exigences.
## Fonctionnement de Kernel Live Patching en utilisant Patch Manager
AWS publie deux types de correctifs dynamiques du noyau pour Amazon Linux 2 : des mises à jour de sécurité et des corrections de bogues. Pour appliquer ces types de correctifs, vous utilisez un document de référentiel de correctifs qui cible uniquement les classifications et les sévérités répertoriées dans le tableau suivant.
| Classification | Sévérité |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
Vous pouvez créer une ligne de base de correctifs personnalisée qui cible uniquement ces correctifs, ou utiliser la ligne de base de correctifs `AWS-AmazonLinux2DefaultPatchBaseline` prédéfinie. En d'autres termes, vous pouvez utiliser `AWS-AmazonLinux2DefaultPatchBaseline` avec les nœuds gérés Amazon Linux 2 sur lesquels Kernel Live Patching est activé. Les mises à jour à chaud du noyau seront alors appliquées.
**Note**
La `AWS-AmazonLinux2DefaultPatchBaseline` configuration indique une période d'attente de 7 jours après la publication ou la dernière mise à jour d'un correctif avant son installation automatique. Si vous ne voulez pas attendre 7 jours pour que les correctifs en direct du noyau soient automatiquement approuvés, vous pouvez créer et utiliser une base de correctifs personnalisée. Dans votre référentiel de correctifs, vous pouvez spécifier une période d'attente d'approbation automatique nulle ou plus courte ou plus longue. Pour de plus amples informations, veuillez consulter [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).
Nous vous recommandons la stratégie suivante pour appliquer les mises à jour à chaud du noyau sur vos nœuds gérés :
1. Activez Kernel Live Patching sur vos nœuds gérés Amazon Linux 2.
1. Utilisez Run Command un outil pour exécuter une `Scan` opération sur vos nœuds gérés à l'aide de la ligne de base de correctifs prédéfinie `AWS-AmazonLinux2DefaultPatchBaseline` ou personnalisée qui cible également uniquement les `Security` mises à jour dont le niveau de gravité est classé comme `Critical` et`Important`, et le niveau de `Bugfix` gravité de`All`. AWS Systems Manager
1. Utilisez Compliance, un outil intégré AWS Systems Manager, pour vérifier si une non-conformité en matière de correctifs est signalée pour l'un des nœuds gérés qui ont été scannés. Si tel est le cas, consultez les détails de conformité du nœud pour déterminer s'il manque des correctifs à chaud du noyau dans le nœud géré.
1. Pour installer les correctifs live du noyau manquants, utilisez Run Command avec la même ligne de base que celle spécifiée précédemment, mais cette fois exécutez une opération `Install` au lieu d'une opération `Scan`.
Comme les correctifs live du noyau sont installés sans avoir à redémarrer, vous pouvez choisir l'option de redémarrage `NoReboot` pour cette opération.
**Note**
Vous pouvez toujours redémarrer le nœud géré si d'autres types de correctifs installés sur celui-ci l'exigent, ou si vous souhaitez procéder à une mise à jour vers un noyau plus récent. Dans ces cas, sélectionnez plutôt l'option de redémarrage `RebootIfNeeded`.
1. Revenez à Conformité pour vérifier que les correctifs live du noyau ont été installés.
# Activez Kernel Live Patching en utilisant Run Command
Pour activer Kernel Live Patching, vous pouvez exécuter des commandes `yum` sur vos nœuds gérés, ou utiliser Run Command et un document Systems Manager (document SSM) créé par vos soins.
Pour obtenir des informations sur l’activation de Kernel Live Patching en exécutant des commandes `yum` directement sur le nœud géré, consultez [Activation de Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) dans le *Guide de l’utilisateur Amazon EC2*.
**Note**
Lorsque vous activez Kernel Live Patching, si le noyau exécuté sur le nœud géré est *antérieur* à `kernel-4.14.165-131.185.amzn2.x86_64` (version minimale prise en charge), le processus installe la dernière version disponible du noyau et redémarre le nœud géré. Si le nœud exécute déjà `kernel-4.14.165-131.185.amzn2.x86_64` ou une version ultérieure, le processus n'installe pas de version plus récente et ne redémarre pas le nœud.
**Pour activer Kernel Live Patching en utilisant Run Command (console)**
1. Ouvrez la console AWS Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste **Documents de commande**, sélectionnez le document SSM personnalisé `AWS-ConfigureKernelLivePatching`.
1. Dans la section **Command parameters (Paramètres de commande)**, indiquez si vous souhaitez redémarrer les nœuds gérés dans le cadre de cette opération.
1. Pour de plus amples informations sur l'utilisation des contrôles restants de cette page, veuillez consulter [Exécution des commande à partir de la console](running-commands-console.md).
1. Cliquez sur **Exécuter**.
**Pour activer Kernel Live Patching (AWS CLI)**
+ Exécutez la commande suivante sur votre machine locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
Remplacez *instance-id* par l'ID du nœud géré Amazon Linux 2 sur lequel vous souhaitez activer la fonction, par exemple, i-02573cafcfEXAMPLE. Pour activer la fonction sur plusieurs nœuds gérés, vous pouvez utiliser l'un des formats suivants.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Pour obtenir des informations sur les autres options possibles avec la commande, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) dans la *Référence des commandes AWS CLI*.
# Application des correctifs à chaud du noyau à l'aide de Run Command
Pour appliquer des correctifs à chaud du noyau, vous pouvez exécuter des commandes `yum` sur vos nœuds gérés, ou utiliser Run Command et le document SSM `AWS-RunPatchBaseline`.
Pour obtenir des informations sur l’application des correctifs à chaud du noyau en exécutant des commandes `yum` directement sur le nœud géré, consultez [Application des correctifs à chaud du noyau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) dans le *Guide de l’utilisateur Amazon EC2*.
**Pour appliquer des correctifs live du noyau à l'aide de Run Command (console)**
1. Ouvrez la console AWS Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste **Command document (Document Command)**, sélectionnez un document `AWS-RunPatchBaseline`.
1. Dans la section **Paramètres de commande** effectuez l'une des opérations suivantes :
+ Si vous vérifiez si de nouveaux correctifs live du noyau sont disponibles, pour **Opération (Opération)**, sélectionnez `Scan`. Dans **Reboot Option (Option de redémarrage)**, sélectionnez `NoReboot` si vous ne souhaitez pas redémarrer vos nœuds gérés à l'issue de cette opération. Une fois l'opération terminée, vous pouvez vérifier les nouveaux correctifs et l'état de conformité dans Compliance.
+ Si vous avez déjà vérifié la conformité des correctifs et que vous êtes prêt à appliquer les correctifs live du noyau disponibles, pour **Opération**, sélectionnez `Install`. Dans **Reboot Option (Option de redémarrage)**, sélectionnez `NoReboot` si vous ne souhaitez pas redémarrer vos nœuds gérés à l'issue de cette opération.
1. Pour de plus amples informations sur l'utilisation des contrôles restants de cette page, veuillez consulter [Exécution des commande à partir de la console](running-commands-console.md).
1. Cliquez sur **Exécuter**.
**Pour appliquer des correctifs live du noyau à l'aide de Run Command (AWS CLI)**
1. Pour effectuer une opération `Scan` avant de vérifier vos résultats dans Compliance, exécutez la commande suivante à partir de votre machine locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
Pour obtenir des informations sur les autres options possibles avec la commande, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) dans la *Référence des commandes AWS CLI*.
1. Pour effectuer une opération `Install` après avoir vérifié vos résultats dans Compliance, exécutez la commande suivante à partir de votre machine locale.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
Dans les deux commandes précédentes, remplacez *instance-id* par l'ID du nœud géré Amazon Linux 2 sur lequel vous souhaitez appliquer des correctifs à chaud du noyau, par exemple i-02573cafcfEXAMPLE. Pour activer la fonction sur plusieurs nœuds gérés, vous pouvez utiliser l'un des formats suivants.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Pour obtenir des informations sur les autres options possibles avec ces commandes, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) dans la *Référence des commandes AWS CLI*.
# Désactiver Kernel Live Patching en utilisant Run Command
Pour désactiver Kernel Live Patching, vous pouvez exécuter des commandes `yum` sur vos nœuds gérés, ou utiliser Run Command et un document SSM `AWS-ConfigureKernelLivePatching` personnalisé.
**Note**
Si vous n'avez plus besoin d'utiliser Kernel Live Patching, vous pouvez le désactiver à tout moment. Dans la plupart des cas, la désactivation de la fonction n'est pas nécessaire.
Pour obtenir des informations sur la désactivation de Kernel Live Patching en exécutant des commandes `yum` directement sur le nœud géré, consultez [Activation de Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) dans le *Guide de l’utilisateur Amazon EC2*.
**Note**
Lorsque vous désactivez Kernel Live Patching, le processus désinstalle le plugin Kernel Live Patching, puis redémarre le nœud géré.
**Pour désactiver Kernel Live Patching en utilisant Run Command (console)**
1. Ouvrez la console AWS Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez **Run Command (Exécuter la commande)**.
1. Dans la liste **Command document (Document Command)**, sélectionnez un document `AWS-ConfigureKernelLivePatching`.
1. Dans la section **Command parameters (Paramètres de la commande)**, indiquez des valeurs pour les paramètres requis.
1. Pour de plus amples informations sur l'utilisation des contrôles restants de cette page, veuillez consulter [Exécution des commande à partir de la console](running-commands-console.md).
1. Cliquez sur **Exécuter**.
**Pour désactiver Kernel Live Patching (AWS CLI)**
+ Exécutez une commande similaire à la suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
Remplacez *instance-id* par l'ID du nœud géré Amazon Linux 2 sur lequel vous souhaitez désactiver la fonction, par exemple i-02573cafcfEXAMPLE. Pour désactiver la fonction sur plusieurs nœuds gérés, vous pouvez utiliser l'un des formats suivants.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Pour obtenir des informations sur les autres options possibles avec la commande, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) dans la *Référence des commandes AWS CLI*.
# Utilisation des ressources Patch Manager et de la conformité en utilisant la console
Pour utiliser Patch Manager un outil AWS Systems Manager, effectuez les tâches suivantes. Ces tâches sont décrites plus en détail dans cette section.
1. Vérifiez que la ligne de base de correctifs AWS prédéfinie pour chaque type de système d'exploitation que vous utilisez répond à vos besoins. Si ce n'est pas le cas, créez un référentiel de correctifs qui définit un ensemble de correctifs standard pour ce type de nœud géré, et définissez-le comme référentiel par défaut.
1. Organisez les nœuds gérés en groupes de correctifs à l'aide de balises Amazon Elastic Compute Cloud (Amazon EC2) (facultatif, mais recommandé).
1. Effectuez l’une des actions suivantes :
+ (Recommandé) Configurez une politique de correctifs dans Quick Setup, un outil de Systems Manager qui vous permet d’installer les correctifs manquants selon une planification pour l’ensemble d’une organisation, un sous-ensemble d’unités organisationnelles ou un seul Compte AWS. Pour de plus amples informations, veuillez consulter [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md).
+ Créez une fenêtre de maintenance qui utilise le document Systems Manager (document SSM) `AWS-RunPatchBaseline` dans un type de tâche Run Command. Pour de plus amples informations, veuillez consulter [Tutoriel : créer une fenêtre de maintenance pour l’application de correctifs à l’aide de la console](maintenance-window-tutorial-patching.md).
+ Exécutez `AWS-RunPatchBaseline` manuellement dans une opération Run Command. Pour de plus amples informations, veuillez consulter [Exécution des commande à partir de la console](running-commands-console.md).
+ Appliquez manuellement des correctifs aux nœuds à la demande à l'aide de la fonctionnalité **Patch now** (Appliquer les correctifs maintenant). Pour de plus amples informations, veuillez consulter [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md).
1. Surveillez l'application des correctifs pour vérifier la conformité et enquêter sur les défaillances.
**Topics**
+ [Création d'une politique de correctif](patch-manager-create-a-patch-policy.md)
+ [Affichage des résumés du tableau de bord des correctifs](patch-manager-view-dashboard-summaries.md)
+ [Utilisation des rapports de conformité des correctifs](patch-manager-compliance-reports.md)
+ [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md)
+ [Utilisation des référentiels de correctifs](patch-manager-create-a-patch-baseline.md)
+ [Affichage des correctifs disponibles](patch-manager-view-available-patches.md)
+ [Création et gestion de groupes de correctifs](patch-manager-tag-a-patch-group.md)
+ [Intégration Patch Manager avec AWS Security Hub CSPM](patch-manager-security-hub-integration.md)
# Création d'une politique de correctif
Une politique de correctifs est une configuration que vous définissez à l’aide de Quick Setup, un outil d’ AWS Systems Manager. Les politiques de correctif fournissent un contrôle plus étendu et plus centralisé de vos opérations d'application de correctifs qu'avec les autres méthodes. Une politique de correctifs définit la planification et le référentiel à utiliser lors de l'application automatique de correctifs à vos nœuds et applications.
Pour plus d’informations, consultez les rubriques suivantes :
+ [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md)
+ [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md)
# Affichage des résumés du tableau de bord des correctifs
L’onglet **Tableau de bord** dans Patch Manager affiche une vue récapitulative consolidée de vos opérations d’application de correctifs, dans la console. Patch Manager est un outil d’ AWS Systems Manager. L'onglet **Dashboard (Tableau de bord)** vous permet de visualiser les éléments suivants :
+ Un instantané du nombre de nœuds gérés qui sont conformes et non conformes aux règles d'application de correctifs.
+ Un instantané de l'ancienneté des résultats de conformité de vos nœuds gérés en matière de correctifs.
+ Un décompte lié du nombre de nœuds gérés non conformes pour chacun des motifs courants de non-conformité.
+ Une liste liée des opérations d'application de correctifs les plus récentes.
+ Une liste liée des tâches récurrentes d'application de correctifs qui ont été configurées.
**Pour afficher les résumés du tableau de bord des correctifs**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Dashboard (Tableau de bord)**.
1. Faites défiler jusqu'à la section contenant les données récapitulatives à afficher :
+ **Gestion des instances Amazon EC2**
+ **Résumé de conformité**
+ **Nombre de cas de non-conformité**
+ **Rapports de conformité**
+ **Opérations non basées sur des politiques de correctif**
+ **Tâches récurrentes non basées sur des politiques de correctif**
# Utilisation des rapports de conformité des correctifs
Les informations contenues dans les rubriques suivantes vous aideront à générer et à utiliser les rapports de conformité des correctifs dans Patch Manager, un outil d’ AWS Systems Manager.
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
**Important**
Les rapports de conformité des correctifs sont des point-in-time instantanés générés uniquement par des opérations de correction réussies. Chaque rapport contient une heure de capture qui indique le moment où le statut de conformité a été calculé.
Si vous avez mis en place plusieurs types d'opérations pour analyser la conformité de vos instances aux correctifs, veuillez noter que chaque analyse remplace les données de conformité aux correctifs des analyses précédentes. Par conséquent, vous pourriez obtenir des résultats inattendus en ce qui concerne vos données de conformité aux correctifs. Pour de plus amples informations, veuillez consulter [Identification de l'exécution qui a créé les données de conformité des correctifs](patch-manager-compliance-data-overwrites.md).
Pour vérifier quel référentiel de correctifs a été utilisé pour générer les dernières informations de conformité, accédez à l'onglet **Rapports de conformité** dans Patch Manager, localisez la ligne correspondant au nœud géré qui vous intéresse, puis choisissez l'ID de référentiel dans la colonne **ID de référentiel utilisé**.
**Topics**
+ [Affichage des résultats de la conformité des correctifs](patch-manager-view-compliance-results.md)
+ [Génération de rapports de conformité des correctifs .csv](patch-manager-store-compliance-results-in-s3.md)
+ [Correction des nœuds gérés non conformes avec Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identification de l'exécution qui a créé les données de conformité des correctifs](patch-manager-compliance-data-overwrites.md)
# Affichage des résultats de la conformité des correctifs
Utilisez ces procédures pour afficher les informations de conformité des correctifs sur vos nœuds gérés.
Cette procédure s'applique aux opérations d'application de correctifs qui utilisent le document `AWS-RunPatchBaseline`. Pour obtenir des informations sur l'affichage des informations de conformité des correctifs pour les opérations d'application de correctifs qui utilisent le document `AWS-RunPatchBaselineAssociation`, veuillez consulter [Identification des nœuds gérés non conformes](patch-manager-find-noncompliant-nodes.md).
**Note**
Les opérations de numérisation des correctifs pour le `AWS-RunPatchBaselineAssociation` document Quick Setup et son Explorer utilisation. Quick Setupet Explorer sont tous deux des outils AWS Systems Manager.
**Identification de la solution de correctif pour un problème CVE spécifique (Linux)**
Pour de nombreux systèmes d'exploitation Linux, les résultats de conformité des correctifs indiquent quels problèmes signalés sur un bulletin Common Vulnerabilities and Exposure (CVE) sont résolus par quels correctifs. Ces informations peuvent vous aider à déterminer à quel point il est urgent d'installer un correctif manquant ou défaillant.
Les détails CVE sont inclus pour les versions prises en charge des types de système d'exploitation suivants :
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**Note**
Par défaut, CentOS Stream ne fournit pas d’informations CVE sur les mises à jour. Vous pouvez toutefois autoriser cette prise en charge en utilisant des référentiels tiers tels que le référentiel EPEL (Extra Packages for Enterprise Linux) publié par Fedora. Pour obtenir des informations, veuillez consulter [EPEL](https://fedoraproject.org/wiki/EPEL) sur le Wiki Fedora.
Actuellement, les valeurs d’ID CVE ne sont signalées que pour les correctifs dont le statut est `Missing` ou `Failed`.
Vous pouvez également ajouter CVE IDs à vos listes de correctifs approuvés ou rejetés dans vos lignes de base de correctifs, selon la situation et vos objectifs en matière de correctifs.
Pour obtenir des informations sur l'utilisation des listes de correctifs approuvés et de correctifs rejetés, veuillez consulter les rubriques suivantes :
+ [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md)
+ [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 les systèmes basés sur Linux](patch-manager-linux-rules.md)
+ [Installation des correctifs](patch-manager-installing-patches.md)
**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.
## Affichage des résultats de conformité de l’application de correctifs
Utilisez les procédures suivantes pour afficher les données de conformité dans la console AWS Systems Manager .
**Note**
Pour obtenir des informations sur la génération de rapports de conformité des correctifs qui sont téléchargés dans un compartiment Amazon Simple Storage Service (Amazon S3), veuillez consulter [Génération de rapports de conformité des correctifs .csv](patch-manager-store-compliance-results-in-s3.md).
**Pour afficher les résultats de conformité des correctifs**
1. Effectuez l'une des actions suivantes :
**Option 1** (recommandée) : naviguez à partir de Patch Manager, un outil d’ AWS Systems Manager :
+ Dans le panneau de navigation, sélectionnez **Patch Manager**.
+ Sélectionnez l'onglet **Compliance reporting (Rapports de conformité)**.
+ Dans la zone **Détails de l’application de correctifs sur le nœud**, sélectionnez l’ID du nœud géré pour lequel vous voulez examiner les résultats de conformité des correctifs. Nœuds qui sont `stopped` ou ne `terminated` seront pas affichés ici.
+ Dans la zone **Détails**, dans la liste **Propriétés**, sélectionnez **Correctifs**.
**Option 2** : naviguez à partir de Compliance, un outil d’ AWS Systems Manager :
+ Dans le panneau de navigation, sélectionnez **Compliance (Conformité)**.
+ Pour **Récapitulatif des ressources de conformité**, sélectionnez un nombre dans la colonne réservée aux types de ressources d'application de correctifs à consulter, tels que **Ressources non conformes**.
+ Ci-dessous, dans la liste **Ressources**, sélectionnez l’ID du nœud géré pour lequel vous voulez examiner les résultats de la conformité des correctifs.
+ Dans la zone **Détails**, dans la liste **Propriétés**, sélectionnez **Correctifs**.
**Option 3** : naviguez à partir de Fleet Manager, un outil d’ AWS Systems Manager :
+ Dans le panneau de navigation, sélectionnez **Fleet Manager**.
+ Dans la zone **Instances gérées**, sélectionnez l’ID du nœud géré pour lequel vous voulez examiner les résultats de conformité des correctifs.
+ Dans la zone **Détails**, dans la liste **Propriétés**, sélectionnez **Correctifs**.
1. (Facultatif) Dans la zone Rechercher (![\[The Search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), sélectionnez parmi les filtres disponibles.
Par exemple, pour Red Hat Enterprise Linux (RHEL), sélectionnez l'un des éléments suivants :
+ Nom
+ Classification
+ State
+ Sévérité
Pour Windows Server, sélectionnez parmi les options suivantes :
+ Ko
+ Classification
+ State
+ Sévérité
1. Sélectionnez l'une des valeurs disponibles pour le type de filtre choisi. Par exemple, si vous avez choisi **État**, choisissez désormais un état de conformité tel que **InstalledPendingReboot****Échec** ou **Manquant**.
**Note**
Actuellement, les valeurs d’ID CVE ne sont signalées que pour les correctifs dont le statut est `Missing` ou `Failed`.
1. En fonction de l'état de conformité du nœud géré, vous pouvez choisir l'action à entreprendre pour remédier aux nœuds non conformes.
Par exemple, vous pouvez choisir d'appliquer immédiatement des correctifs à vos nœuds gérés non conformes. Pour obtenir des informations sur l'application de correctifs sur les nœuds gérés à la demande, consultez [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md).
Pour plus d'informations sur les états de conformité des correctifs, consultez [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md).
# Génération de rapports de conformité des correctifs .csv
Vous pouvez utiliser la AWS Systems Manager console pour générer des rapports de conformité des correctifs qui sont enregistrés sous forme de fichier .csv dans un bucket Amazon Simple Storage Service (Amazon S3) de votre choix. Vous pouvez générer un rapport à la demande unique ou planifier la génération automatique des rapports.
Les rapports peuvent être générés pour un seul nœud géré ou pour tous les nœuds gérés de votre choix Compte AWS et Région AWS. Pour un seul nœud, un rapport contient des informations complètes, notamment les correctifs liés à IDs la non-conformité d'un nœud. Un rapport portant sur tous les nœuds gérés, quant à lui, ne contient que des informations sommaires ainsi que le nombre de correctifs liés aux nœuds non conformes.
Une fois le rapport généré, vous pouvez utiliser un outil tel qu'Amazon Quick pour importer et analyser les données. Quick est un service de business intelligence (BI) que vous pouvez utiliser pour explorer et interpréter des informations dans un environnement visuel interactif. Pour plus d'informations, consultez le [guide d'utilisation rapide d'Amazon](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).
**Note**
Lorsque vous créez un référentiel de correctifs personnalisé, vous pouvez spécifier un niveau de sévérité de conformité pour les correctifs approuvés par ce référentiel de correctifs, tel que `Critical` ou `High`. Si l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
Vous pouvez aussi spécifier une rubrique Amazon Simple Notification Service (Amazon SNS) à utiliser pour envoyer des notifications lorsqu'un rapport est généré.
**Rôles de service pour la génération de rapports de conformité des correctifs**
La première fois que vous générez un rapport, Systems Manager crée un rôle responsable Automation nommé `AWS-SystemsManager-PatchSummaryExportRole` à utiliser pour le processus d'exportation vers S3.
**Note**
Si vous exportez des données de conformité vers un compartiment S3 chiffré, vous devez mettre à jour la politique de AWS KMS clé associée afin de fournir les autorisations nécessaires pour`AWS-SystemsManager-PatchSummaryExportRole`. Par exemple, ajoutez une autorisation similaire à celle-ci à la AWS KMS politique de votre compartiment S3 :
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
*role-arn*Remplacez-le par le Amazon Resource Name (ARN) du fichier créé dans votre compte, au format`arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.
Pour plus d’informations, consultez [Politiques de clé dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *Guide du développeur AWS Key Management Service *.
La première fois que vous générez un rapport selon un calendrier, Systems Manager crée un autre rôle de service nommé`AWS-EventBridge-Start-SSMAutomationRole`, ainsi que le rôle de service `AWS-SystemsManager-PatchSummaryExportRole` (s'il n'est pas déjà créé) à utiliser pour le processus d'exportation. `AWS-EventBridge-Start-SSMAutomationRole`permet EventBridge à Amazon de démarrer une automatisation à l'aide du runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Nous vous déconseillons de tenter de modifier ces politiques et ces rôles. Cela pourrait entraîner l'échec de la génération de rapports de conformité des correctifs. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés à la génération de rapports de conformité des correctifs](#patch-compliance-reports-troubleshooting).
**Topics**
+ [Qu'est-ce qu'un rapport de conformité des correctifs généré ?](#patch-compliance-reports-to-s3-examples)
+ [Génération de rapports de conformité des correctifs pour un nœud géré individuel](#patch-compliance-reports-to-s3-one-instance)
+ [Génération de rapports de conformité des correctifs pour tous les nœuds gérés](#patch-compliance-reports-to-s3-all-instances)
+ [Affichage de l'historique de génération de rapports de conformité des correctifs](#patch-compliance-reporting-history)
+ [Affichage des calendriers de rapports de conformité des correctifs](#patch-compliance-reporting-schedules)
+ [Résolution des problèmes liés à la génération de rapports de conformité des correctifs](#patch-compliance-reports-troubleshooting)
## Qu'est-ce qu'un rapport de conformité des correctifs généré ?
Cette rubrique fournit des informations sur les types de contenu inclus dans les rapports de conformité des correctifs qui sont générés et téléchargés dans un compartiment S3 spécifié.
### Format de rapport pour un nœud géré individuel
Un rapport généré pour un nœud géré individuel fournit à la fois des informations sommaires et détaillées.
[Télécharger un exemple de rapport (pour un nœud individuel)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
Les informations sommaires fournies pour un nœud géré individuel sont les suivantes :
+ Index
+ ID d’instance
+ Instance name
+ Adresse IP d'instance
+ Nom de la plateforme
+ Version de la plateforme
+ Version de l’SSM Agent
+ Référentiel de correctifs
+ Groupe de correctifs
+ Statut de conformité
+ Sévérité de conformité
+ Nombre de correctifs de sévérité critique non conformes
+ Nombre de correctifs de sévérité élevée non conformes
+ Nombre de correctifs de sévérité moyenne non conformes
+ Nombre de correctifs de sévérité faible non conformes
+ Nombre de correctifs de sévérité informationnelle non conformes
+ Nombre de correctifs de sévérité non spécifiée non conformes
Les informations détaillées fournies pour un nœud géré individuel sont les suivantes :
+ Index
+ ID d’instance
+ Instance name
+ Nom du correctif
+ ID/Patch ID KB
+ État du correctif
+ Heure du dernier rapport
+ Niveau de conformité
+ Sévérité du correctif
+ Classification des correctifs
+ ID CVE
+ Référentiel de correctifs
+ URL des journaux
+ Adresse IP d'instance
+ Nom de la plateforme
+ Version de la plateforme
+ Version de l’SSM Agent
**Note**
Lorsque vous créez un référentiel de correctifs personnalisé, vous pouvez spécifier un niveau de sévérité de conformité pour les correctifs approuvés par ce référentiel de correctifs, tel que `Critical` ou `High`. Si l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
### Format de rapport pour tous les nœuds gérés
Un rapport généré pour tous les nœuds gérés ne fournit que des informations sommaires.
[Télécharger un exemple de rapport (pour tous les nœuds gérés)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
Les informations sommaires fournies pour tous les nœuds gérés sont les suivantes :
+ Index
+ ID d’instance
+ Instance name
+ Adresse IP d'instance
+ Nom de la plateforme
+ Version de la plateforme
+ Version de l’SSM Agent
+ Référentiel de correctifs
+ Groupe de correctifs
+ Statut de conformité
+ Sévérité de conformité
+ Nombre de correctifs de sévérité critique non conformes
+ Nombre de correctifs de sévérité élevée non conformes
+ Nombre de correctifs de sévérité moyenne non conformes
+ Nombre de correctifs de sévérité faible non conformes
+ Nombre de correctifs de sévérité informationnelle non conformes
+ Nombre de correctifs de sévérité non spécifiée non conformes
## Génération de rapports de conformité des correctifs pour un nœud géré individuel
Procédez comme suit pour générer un rapport sommaire sur les correctifs relatifs à un nœud géré individuel dans votre Compte AWS. Le rapport relatif à un seul nœud géré fournit des informations détaillées sur chaque correctif non conforme, notamment les noms des correctifs et IDs.
**Pour générer des rapports de conformité des correctifs pour un nœud géré individuel**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Compliance reporting (Rapports de conformité)**.
1. Cliquez sur le bouton correspondant à la ligne du nœud géré pour lequel vous souhaitez générer un rapport, puis sélectionnez **View detail (Afficher les détails)**.
1. Dans la section **Patch summary (Récapitulatif des correctifs)**, sélectionnez **Export to S3 (Exporter vers S3)**.
1. Pour **Nom du rapport**, saisissez un nom qui vous aidera à identifier le rapport ultérieurement.
1. Pour **Fréquence de génération de rapports**, sélectionnez l'une des options suivantes :
+ **À la demande** : pour créer un rapport unique. Passez à l'étape 9.
+ **Planifiée** : spécifie une planification récurrente pour la génération automatique de rapports. Passez à l'étape 8.
1. Pour **Type de programme**, spécifiez une expression rate, par exemple tous les 3 jours, ou fournissez une expression cron pour définir la fréquence du rapport.
Pour plus d'informations sur les expressions cron, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
1. Pour **Nom du compartiment**, sélectionnez le nom du compartiment S3 dans lequel vous voulez stocker les fichiers de rapport .csv.
**Important**
Si vous travaillez dans un Région AWS compartiment lancé après le 20 mars 2019, vous devez sélectionner un compartiment S3 dans cette même région. Les régions lancées après cette date ont été désactivées par défaut. Pour plus d'informations et une liste de ces régions, veuillez consulter la rubrique [Activation d'une région](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) dans la *Référence générale d'Amazon Web Services*.
1. (Facultatif) Pour envoyer des notifications lorsque le rapport est généré, développez la section **SNS topic (Rubrique SNS)**, puis sélectionnez une rubrique Amazon SNS existante dans **SNS topic Amazon Resource Name (ARN) (Amazon Resource Name (ARN) de rubrique SNS)**.
1. Sélectionnez **Submit (Envoyer)**.
Pour obtenir des informations sur l'affichage d'un historique des rapports générés, veuillez consulter [Affichage de l'historique de génération de rapports de conformité des correctifs](#patch-compliance-reporting-history).
Pour obtenir des informations sur l'affichage des détails relatifs aux calendriers de génération de rapports que vous avez créés, veuillez consulter [Affichage des calendriers de rapports de conformité des correctifs](#patch-compliance-reporting-schedules).
## Génération de rapports de conformité des correctifs pour tous les nœuds gérés
Procédez comme suit pour générer un rapport sommaire sur les correctifs relatifs à tous les nœuds gérés de votre Compte AWS. Le rapport portant sur tous les nœuds gérés désigne les nœuds qui ne sont pas conformes et le nombre de correctifs non conformes. Il ne fournit pas les noms ou autres identifiants des correctifs. Pour plus de détails, vous pouvez générer un rapport de conformité des correctifs portant sur un nœud géré individuel. Pour plus d'informations, consultez [Génération de rapports de conformité des correctifs pour un nœud géré individuel](#patch-compliance-reports-to-s3-one-instance) plus haut dans cette rubrique.
**Pour générer des rapports de conformité des correctifs pour tous les nœuds gérés**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Compliance reporting (Rapports de conformité)**.
1. Sélectionnez **Exporter vers S3**. (Évitez de sélectionner un ID de nœud en premier).
1. Pour **Nom du rapport**, saisissez un nom qui vous aidera à identifier le rapport ultérieurement.
1. Pour **Fréquence de génération de rapports**, sélectionnez l'une des options suivantes :
+ **À la demande** : pour créer un rapport unique. Passez à l'étape 8.
+ **Planifiée** : spécifie une planification récurrente pour la génération automatique de rapports. Passez à l'étape 7.
1. Pour **Type de programme**, spécifiez une expression rate, par exemple tous les 3 jours, ou fournissez une expression cron pour définir la fréquence du rapport.
Pour plus d'informations sur les expressions cron, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
1. Pour **Nom du compartiment**, sélectionnez le nom du compartiment S3 dans lequel vous voulez stocker les fichiers de rapport .csv.
**Important**
Si vous travaillez dans un Région AWS compartiment lancé après le 20 mars 2019, vous devez sélectionner un compartiment S3 dans cette même région. Les régions lancées après cette date ont été désactivées par défaut. Pour plus d'informations et une liste de ces régions, veuillez consulter la rubrique [Activation d'une région](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) dans la *Référence générale d'Amazon Web Services*.
1. (Facultatif) Pour envoyer des notifications lorsque le rapport est généré, développez la section **SNS topic (Rubrique SNS)**, puis sélectionnez une rubrique Amazon SNS existante dans **SNS topic Amazon Resource Name (ARN) (Amazon Resource Name (ARN) de rubrique SNS)**.
1. Sélectionnez **Submit (Envoyer)**.
Pour obtenir des informations sur l'affichage d'un historique des rapports générés, veuillez consulter [Affichage de l'historique de génération de rapports de conformité des correctifs](#patch-compliance-reporting-history).
Pour obtenir des informations sur l'affichage des détails relatifs aux calendriers de génération de rapports que vous avez créés, veuillez consulter [Affichage des calendriers de rapports de conformité des correctifs](#patch-compliance-reporting-schedules).
## Affichage de l'historique de génération de rapports de conformité des correctifs
Utilisez les informations de cette rubrique pour vous aider à consulter les détails des rapports de conformité des correctifs générés dans votre Compte AWS.
**Pour afficher l'historique de génération de rapports de conformité des correctifs**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Compliance reporting (Rapports de conformité)**.
1. Sélectionnez **Afficher toutes les exportations vers S3**, puis sélectionnez l'onglet **Historique des exportations**.
## Affichage des calendriers de rapports de conformité des correctifs
Utilisez les informations de cette rubrique pour vous aider à consulter les détails des calendriers de rapports de conformité des correctifs créés dans votre Compte AWS.
**Pour afficher l'historique de génération de rapports de conformité des correctifs**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Compliance reporting (Rapports de conformité)**.
1. Sélectionnez **View all S3 exports (Afficher toutes les exportations S3)**, puis l'onglet **Report schedule rules (Règles de planification de rapport)**.
## Résolution des problèmes liés à la génération de rapports de conformité des correctifs
Utilisez les informations suivantes pour résoudre les problèmes liés à la génération de rapports de conformité des correctifs dans Patch Manager, un outil d’ AWS Systems Manager.
**Topics**
+ [Un message signale que la politique `AWS-SystemsManager-PatchManagerExportRolePolicy` est corrompue](#patch-compliance-reports-troubleshooting-1)
+ [La suppression des politiques ou des rôles de conformité des correctifs empêche la génération correcte des rapports planifiés.](#patch-compliance-reports-troubleshooting-2)
### Un message signale que la politique `AWS-SystemsManager-PatchManagerExportRolePolicy` est corrompue
**Problème** : vous recevez un message d'erreur semblable au suivant, indiquant que la valeur `AWS-SystemsManager-PatchManagerExportRolePolicy` est corrompue :
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **Solution** : utilisez la Patch Manager console ou supprimez AWS CLI les rôles et politiques concernés avant de générer un nouveau rapport de conformité des correctifs.
**Pour supprimer la politique corrompue à l'aide de la console**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Effectuez l’une des actions suivantes :
**Rapports à la demande** : si le problème s'est produit lors de la génération d'un rapport à la demande ponctuel, dans le panneau de navigation de gauche, sélectionnez **Politiques**, recherchez `AWS-SystemsManager-PatchManagerExportRolePolicy`, puis supprimez la politique. Ensuite, sélectionnez **Rôles**, recherchez `AWS-SystemsManager-PatchSummaryExportRole`, puis supprimez le rôle.
**Rapports planifiés** : si le problème s'est produit lors de la génération d'un rapport planifié, dans le panneau de navigation de gauche, sélectionnez **Politiques**, recherchez `AWS-EventBridge-Start-SSMAutomationRolePolicy` et `AWS-SystemsManager-PatchManagerExportRolePolicy` une par une, et supprimez chaque politique. Ensuite, sélectionnez **Rôles**, recherchez `AWS-EventBridge-Start-SSMAutomationRole` et `AWS-SystemsManager-PatchSummaryExportRole` un par un, et supprimez chaque rôle.
**Pour supprimer la politique corrompue à l'aide du AWS CLI**
Remplacez le *placeholder values* par votre identifiant de compte.
+ Si le problème s'est produit lors de la génération d'un rapport unique à la demande, exécutez les commandes suivantes :
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Si le problème s'est produit lors de la génération d'un rapport selon une planification, exécutez les commandes suivantes :
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Après avoir effectué l'une des deux procédures, suivez les étapes pour générer ou planifier un nouveau rapport de conformité des correctifs.
### La suppression des politiques ou des rôles de conformité des correctifs empêche la génération correcte des rapports planifiés.
**Problème** : la première fois que vous générez un rapport, Systems Manager crée un rôle de service et une politique à utiliser pour le processus d'exportation (`AWS-SystemsManager-PatchSummaryExportRole` et `AWS-SystemsManager-PatchManagerExportRolePolicy`). La première fois que vous générez un rapport planifié, Systems Manager crée un autre rôle de service et une autre politique (`AWS-EventBridge-Start-SSMAutomationRole` et `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Ils permettent EventBridge à Amazon de démarrer une automatisation à l'aide du runbook [AWS- ExportPatchReportTo S3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Si vous supprimez l'une de ces politiques ou l'un de ces rôles, les connexions entre votre calendrier et votre compartiment S3 spécifié et la rubrique Amazon SNS peuvent être perdues.
+ **Solution** : pour contourner ce problème, nous vous recommandons de supprimer le calendrier précédent et de créer un calendrier pour remplacer celui qui présentait des problèmes.
# Correction des nœuds gérés non conformes avec Patch Manager
Les rubriques de cette section expliquent comment identifier les nœuds gérés qui ne sont pas conformes en matière de correctifs, et comment les mettre en conformité.
**Topics**
+ [Identification des nœuds gérés non conformes](patch-manager-find-noncompliant-nodes.md)
+ [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md)
+ [Application de correctifs sur des nœuds gérés non conformes](patch-manager-compliance-remediation.md)
# Identification des nœuds gérés non conformes
Out-of-compliance les nœuds gérés sont identifiés lorsque l'un des deux AWS Systems Manager documents (documents SSM) est exécuté. Ces documents SSM font référence au référentiel de correctifs correspondant à chaque nœud géré dans l’outil Patch Manager d’ AWS Systems Manager. Ils évaluent ensuite l'état des correctifs du nœud géré, puis mettent les résultats de conformité à votre disposition.
Deux documents SSM sont utilisés pour identifier ou mettre à jour les nœuds gérés non conformes : `AWS-RunPatchBaseline` et `AWS-RunPatchBaselineAssociation`. Chacun d'entre eux est utilisé par différents processus, et leurs résultats de conformité sont disponibles via différents canaux. Le tableau suivant décrit les différences entre ces documents.
**Note**
Les données de conformité des correctifs Patch Manager peuvent être envoyées à AWS Security Hub CSPM. Security Hub CSPM vous donne une vue complète de vos alertes de sécurité prioritaires et de l'état de conformité. Il surveille également le statut d'application des correctifs de votre flotte. Pour de plus amples informations, veuillez consulter [Intégration Patch Manager avec AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| Processus qui utilisent le document | **Correctifs à la demande** : vous pouvez analyser les nœuds gérés ou y appliquer des correctifs à la demande à l'aide de l'option **Patch now (Appliquer les correctifs maintenant)**. Pour plus d'informations, consultez [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md). **Politiques de correctif Quick Setup de Systems Manager** : vous pouvez créer une configuration d’application de correctifs dans Quick Setup, un outil d’ AWS Systems Manager, capable de rechercher ou d’installer les correctifs manquants selon des planifications distinctes pour l’ensemble d’une organisation, un sous-ensemble d’unités organisationnelles ou un seul Compte AWS. Pour plus d'informations, consultez [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md). **Exécution d’une commande** : vous pouvez exécuter `AWS-RunPatchBaseline` manuellement dans une opération dans Run Command, un outil d’ AWS Systems Manager. Pour plus d'informations, consultez [Exécution des commande à partir de la console](running-commands-console.md). **Fenêtre de maintenance** : vous pouvez créer une fenêtre de maintenance qui utilise le document SSM `AWS-RunPatchBaseline` dans un type de tâche Run Command. Pour plus d'informations, consultez [Tutoriel : créer une fenêtre de maintenance pour l’application de correctifs à l’aide de la console](maintenance-window-tutorial-patching.md). | **Gestion des hôtes Quick Setup de Systems Manager** : vous pouvez activer une option de configuration de gestion des hôtes dans Quick Setup de sorte à analyser quotidiennement la conformité aux correctifs de vos instances gérées. Pour plus d'informations, consultez [Configurer la gestion des hôtes Amazon EC2 à l’aide d’Quick Setup](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**: lorsque vous l'autorisezExplorer, un outil analyse régulièrement vos instances gérées pour vérifier la conformité des correctifs et affiche les résultats dans le Explorer tableau de bord. AWS Systems Manager |
| Format des données de résultat de l'analyse des correctifs | Une fois que `AWS-RunPatchBaseline` s’exécute, Patch Manager envoie un objet `AWS:PatchSummary` à Inventory, un outil d’ AWS Systems Manager. Ce rapport est généré uniquement par des opérations de correction réussies et inclut une heure de capture identifiant le moment où le statut de conformité a été calculé. | Une fois que `AWS-RunPatchBaselineAssociation` s'exécute, Patch Manager envoie un objet `AWS:ComplianceItem` à Systems Manager Inventory. |
| Affichage des rapports de conformité actuelle dans la console | Vous pouvez afficher des informations de conformité des correctifs pour les processus qui utilisent `AWS-RunPatchBaseline` dans [Conformité de la configuration Systems Manager](systems-manager-compliance.md) et [Utilisation des nœuds gérés](fleet-manager-managed-nodes.md). Pour de plus amples informations, veuillez consulter [Affichage des résultats de la conformité des correctifs](patch-manager-view-compliance-results.md). | Si vous utilisez Quick Setup pour analyser vos instances gérées pour la conformité des correctifs, vous pouvez voir le rapport de conformité dans [Systems Manager Fleet Manager](fleet-manager.md). Dans la console Fleet Manager, sélectionnez l’ID de nœud de votre nœud géré. Dans le menu **Général**, sélectionnez **Conformité de la configuration**. Si vous utilisez Explorer pour analyser vos instances gérées pour la conformité des correctifs, vous pouvez voir le rapport de conformité dans Explorer et [Systems Manager OpsCenter](OpsCenter.md). |
| AWS CLI commandes pour afficher les résultats de conformité des correctifs | Pour les processus qui l'utilisent`AWS-RunPatchBaseline`, vous pouvez utiliser les AWS CLI commandes suivantes pour afficher des informations récapitulatives sur les correctifs sur un nœud géré. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | Pour les processus qui l'utilisent`AWS-RunPatchBaselineAssociation`, vous pouvez utiliser la AWS CLI commande suivante pour afficher des informations récapitulatives sur les correctifs d'une instance. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| Opérations d'application de correctifs | Pour les processus qui utilisent `AWS-RunPatchBaseline`, vous spécifiez si l'opération doit exécuter une opération `Scan` uniquement ou une opération `Scan and install`. Si votre objectif est d'identifier les nœuds gérés non conformes, et non de les corriger, contentez-vous d'exécuter une opération `Scan`. | Les processus Quick Setup et Explorer, qui utilisent AWS-RunPatchBaselineAssociation, exécutent uniquement une opération Scan. |
| Plus d’informations | [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
Pour obtenir des informations sur les différents états de conformité des correctifs qui peuvent être signalés, veuillez consulter [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md)
Pour obtenir des informations sur la résolution des problèmes de non-conformité des nœuds gérés, consultez [Application de correctifs sur des nœuds gérés non conformes](patch-manager-compliance-remediation.md).
# Valeurs de l’état de conformité des correctifs
Les informations relatives aux correctifs d'un nœud géré incluent un rapport sur l'état ou le statut de chaque correctif.
**Astuce**
Si vous souhaitez attribuer un état de conformité des correctifs spécifique à un nœud géré, vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) ou l'opération [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API. L'attribution d'un état de conformité n'est pas prise en charge dans la console.
Utilisez les informations figurant dans les tableaux suivants pour identifier les raisons pour lesquelles une nœud géré peut ne pas être conforme en matière de correctifs.
## Valeurs de conformité des correctifs pour Debian Server et Ubuntu Server
Pour Debian Server et Ubuntu Server, les règles de classification des packages dans les différents états de conformité sont décrites dans le tableau suivant.
**Note**
Gardez les points suivants à l’esprit lorsque vous évaluez les valeurs de statut `INSTALLED`, `INSTALLED_OTHER`, et `MISSING` : si vous ne cochez pas la case **Inclusion de mises à jour non liées à la sécurité** lors de la création ou de la mise à jour d’un référentiel de correctifs, les versions des correctifs candidats sont limitées aux correctifs des 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`)
`debian-security` (Debian Server)
Si vous cochez la case **Inclure les mises à jour non liées à la sécurité**, les correctifs provenant d'autres référentiels sont également pris en compte.
| État du correctif | Description | Statut de conformité |
| --- | --- | --- |
| **`INSTALLED`** | Le correctif est répertorié dans le référentiel de correctifs et est installé sur le nœud géré. Il a pu être installé manuellement par une personne ou automatiquement par Patch Manager lors de l'exécution du document `AWS-RunPatchBaseline` sur le nœud géré. | Conforme |
| **`INSTALLED_OTHER`** | Le correctif n'est pas inclus dans le référentiel ou n'est pas approuvé par le référentiel, mais il est installé sur le nœud géré. Le correctif a peut-être été installé manuellement, le package peut être une dépendance obligatoire d'un autre correctif approuvé ou le correctif peut avoir été inclus dans une InstallOverrideList opération. Si vous ne spécifiez pas `Block` comme l'action **Correctifs rejetés**, `INSTALLED_OTHER`inclut également les correctifs installés mais rejetés. | Conforme |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` peut signifier une des deux choses suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-compliance-states.html) Dans les deux cas, cela ne signifie pas qu’un correctif ayant ce statut *nécessite* un redémarrage, mais seulement que le nœud n’a pas été redémarré depuis l’installation du correctif. | Non-Compliant (Non conforme) |
| **`INSTALLED_REJECTED`** | Le correctif est installé sur le nœud géré, mais il figure dans une liste **Rejected patches (Correctifs rejetés)**. Cela signifie généralement que le correctif a été installé avant d'être ajouté à la liste des correctifs rejetés. | Non-Compliant (Non conforme) |
| **`MISSING`** | Le correctif est approuvé dans le référentiel, mais il n'est pas installé sur le nœud géré. Si vous configurez la tâche de document `AWS-RunPatchBaseline` pour l'analyse (au lieu de l'installation), le système signale ce statut pour les correctifs qui ont été détectés lors de l'analyse, mais qui n'ont pas été installés. | Non-Compliant (Non conforme) |
| **`FAILED`** | Le correctif est approuvé dans la référence, mais il n'a pas pu être installé. Pour résoudre ce problème, passez en revue la sortie de commande afin d'accéder à des informations supplémentaires susceptibles de vous aider à comprendre ce qui se passe. | Non-Compliant (Non conforme) |
## Valeurs de conformité des correctifs pour les autres systèmes d'exploitation
Pour tous les systèmes d'exploitation autres que Debian Server et Ubuntu Server, les règles de classification des packages dans les différents états de conformité sont décrites dans le tableau suivant.
| État du correctif | Description | Valeur de conformité |
| --- | --- | --- |
| **`INSTALLED`** | Le correctif est répertorié dans le référentiel de correctifs et est installé sur le nœud géré. Il a pu être installé manuellement par une personne ou automatiquement par Patch Manager lors de l'exécution du document `AWS-RunPatchBaseline` sur le nœud. | Conforme |
| **`INSTALLED_OTHER`**¹ | Le correctif ne figure pas dans le référentiel, mais il est installé sur le nœud géré. Il y a deux raisons possibles à cela : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-compliance-states.html) | Conforme |
| **`INSTALLED_REJECTED`** | Le correctif est installé sur le nœud géré, mais il figure dans une liste Rejected patches (Correctifs rejetés). Cela signifie généralement que le correctif a été installé avant d'être ajouté à la liste des correctifs rejetés. | Non-Compliant (Non conforme) |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` peut signifier une des deux choses suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/patch-manager-compliance-states.html) Dans les deux cas, cela ne signifie pas qu’un correctif ayant ce statut *nécessite* un redémarrage, mais seulement que le nœud n’a pas été redémarré depuis l’installation du correctif. | Non-Compliant (Non conforme) |
| **`MISSING`** | Le correctif est approuvé dans le référentiel, mais il n'est pas installé sur le nœud géré. Si vous configurez la tâche de document `AWS-RunPatchBaseline` pour l'analyse (au lieu de l'installation), le système signale ce statut pour les correctifs qui ont été détectés lors de l'analyse, mais qui n'ont pas été installés. | Non-Compliant (Non conforme) |
| **`FAILED`** | Le correctif est approuvé dans la référence, mais il n'a pas pu être installé. Pour résoudre ce problème, passez en revue la sortie de commande afin d'accéder à des informations supplémentaires susceptibles de vous aider à comprendre ce qui se passe. | Non-Compliant (Non conforme) |
| **`NOT_APPLICABLE`**¹ | *Ce statut de conformité est uniquement signalé sur les systèmes d’exploitation Windows Server.* Le correctif est approuvé dans le référentiel, mais le service ou la fonction qui l'utilise n'est pas installé sur le nœud géré. Par exemple, un correctif relatif à un service de serveur web tel qu'Internet Information Services (IIS) indique `NOT_APPLICABLE` s'il a été approuvé dans le référentiel, alors que le service web n'est pas installé sur le nœud géré. Un patch peut également être marqué `NOT_APPLICABLE` s'il a été remplacé par une mise à jour ultérieure. Cela signifie que la mise à jour ultérieure est installée et que la `NOT_APPLICABLE` mise à jour n'est plus requise. | Non applicable |
| AVAILABLE\$1SECURITY\$1UPDATES | *Ce statut de conformité est uniquement signalé sur les systèmes d’exploitation Windows Server.* Un correctif de mise à jour de sécurité disponible qui n’est pas approuvé par le référentiel de correctifs peut avoir une valeur de conformité de `Compliant` ou `Non-Compliant`, comme défini dans un référentiel de correctifs personnalisé. Lorsque vous créez ou mettez à jour un référentiel de correctifs, vous choisissez le statut que vous souhaitez attribuer aux correctifs de sécurité disponibles mais non approuvés car ils ne répondent pas aux critères d’installation spécifiés dans le référentiel de correctifs. Par exemple, les correctifs de sécurité que vous souhaitez installer peuvent être ignorés si vous avez spécifié une longue période d’attente après la publication d’un correctif avant l’installation. Si une mise à jour du correctif est publiée pendant la période d’attente que vous avez spécifiée, la période d’attente pour l’installation du correctif recommence. Si le délai d’attente est trop long, plusieurs versions du correctif peuvent être publiées mais ne jamais être installées. Pour le décompte récapitulatif des correctifs, lorsqu’un correctif est signalé comme `AvailableSecurityUpdate`, il est toujours inclus dans `AvailableSecurityUpdateCount`. Si le référentiel est configuré pour signaler ces correctifs comme `NonCompliant`, il est également inclus dans `SecurityNonCompliantCount`. Si le référentiel est configuré pour signaler ces correctifs comme `Compliant`, il n’est pas inclus dans `SecurityNonCompliantCount`. Ces correctifs sont toujours signalés avec une gravité non spécifiée et ne sont jamais inclus dans `CriticalNonCompliantCount`. | Conforme ou Non conforme, selon l’option sélectionnée pour les mises à jour de sécurité disponibles. En utilisant la console pour créer ou mettre à jour un référentiel de correctifs, vous spécifiez cette option dans le champ **Statut de conformité des mises à jour de sécurité disponibles**. AWS CLI À l'aide de la [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)commande pour exécuter [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)ou, vous spécifiez cette option dans le `available-security-updates-compliance-status` paramètre. |
¹ Pour les correctifs avec l’état `INSTALLED_OTHER` et `NOT_APPLICABLE`, Patch Manager omet certaines données dans les résultats des requêtes basées sur la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html), comme les valeurs pour `Classification` et `Severity`. Cela permet d’éviter de dépasser la limite de données pour les nœuds individuels dans l’iventaire, un outil d’ AWS Systems Manager. Pour voir tous les détails des correctifs, vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html).
# Application de correctifs sur des nœuds gérés non conformes
La plupart des AWS Systems Manager outils et processus que vous pouvez utiliser pour vérifier la conformité des nœuds gérés peuvent être utilisés pour mettre les nœuds en conformité avec les règles de correctifs qui leur sont actuellement applicables. Pour que les nœuds gérés soient conformes aux correctifsPatch Manager, un outil doit exécuter une `Scan and install` opération. AWS Systems Manager(Si votre objectif est uniquement d'identifier les nœuds gérés non conformes, et non de les corriger, contentez-vous d'exécuter une opération `Scan`. Pour plus d'informations, veuillez consulter la rubrique [Identification des nœuds gérés non conformes](patch-manager-find-noncompliant-nodes.md).)
**Installer des correctifs en utilisant Systems Manager**
Vous pouvez choisir parmi plusieurs outils pour exécuter une opération `Scan and install`.
+ (Recommandé) Configurez une politique de correctifs dans Quick Setup, un outil de Systems Manager qui vous permet d’installer les correctifs manquants selon une planification pour l’ensemble d’une organisation, un sous-ensemble d’unités organisationnelles ou un seul Compte AWS. Pour de plus amples informations, veuillez consulter [Configurer les applications de correctifs pour les instances d’une organisation à l’aide d’une politique de correctif Quick Setup](quick-setup-patch-manager.md).
+ Créez une fenêtre de maintenance qui utilise le document Systems Manager (document SSM) `AWS-RunPatchBaseline` dans un type de tâche Run Command. Pour plus d'informations, consultez [Tutoriel : créer une fenêtre de maintenance pour l’application de correctifs à l’aide de la console](maintenance-window-tutorial-patching.md).
+ Exécutez `AWS-RunPatchBaseline` manuellement dans une opération Run Command. Pour plus d'informations, consultez [Exécution des commande à partir de la console](running-commands-console.md).
+ Installez des correctifs à la demande en utilisant l'option **Corriger maintenant**. Pour plus d'informations, consultez [Application de correctifs sur les nœuds gérés à la demande](patch-manager-patch-now-on-demand.md).
# Identification de l'exécution qui a créé les données de conformité des correctifs
Les données de conformité des correctifs représentent un point-in-time instantané de la dernière opération de correction réussie. Chaque rapport de conformité inclut à la fois un identifiant d'exécution et une heure de capture qui vous aident à identifier l'opération qui a créé les données de conformité et à quel moment elles ont été générées.
Si vous avez mis en place plusieurs types d'opérations pour analyser la conformité de vos instances aux correctifs, chaque analyse remplace les données de conformité aux correctifs des analyses précédentes. Par conséquent, vous pourriez obtenir des résultats inattendus en ce qui concerne vos données de conformité aux correctifs.
Supposons, par exemple, que vous créiez une politique de correctifs qui analyse la conformité aux correctifs chaque jour à 2 h 00, heure locale. Cette politique de correctifs utilise un référentiel de correctifs qui cible les correctifs dont la sévérité est définie sur `Critical`, `Important` et `Moderate`. Ce référentiel de correctifs indique également quelques correctifs spécifiquement rejetés.
Supposons également qu'une fenêtre de maintenance ait déjà été configurée pour analyser le même ensemble de nœuds gérés chaque jour à 4 h 00, heure locale, que vous ne supprimez ni ne désactivez. La tâche de cette fenêtre de maintenance utilise un référentiel de correctifs différent, qui cible uniquement les correctifs dont la sévérité est `Critical` et n'exclut aucun correctif spécifique.
Lorsque cette seconde analyse est effectuée par la fenêtre de maintenance, les données de conformité aux correctifs de la première analyse sont supprimées et remplacées par les données de conformité aux correctifs issues de la seconde analyse.
Par conséquent, nous vous recommandons vivement de n'utiliser qu'une seule méthode automatisée pour analyser et installer vos opérations d'application de correctifs. Si vous configurez des politiques de correctif, vous devez supprimer ou désactiver les autres méthodes d'analyse de la conformité aux correctifs. Pour plus d'informations, consultez les rubriques suivantes :
+ Pour supprimer une tâche d'application de correctifs d'une fenêtre de maintenance : [Mise à jour ou désenregistrement de tâches de fenêtre de maintenance à l’aide de la console](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ Pour supprimer une association State Manager : [Suppression d'associations](systems-manager-state-manager-delete-association.md).
Pour désactiver les analyses quotidiennes de conformité aux correctifs dans une configuration de gestion des hôtes, procédez comme suit dans Quick Setup :
1. Dans le panneau de navigation, sélectionnez **Quick Setup**.
1. Sélectionnez la configuration de gestion des hôtes à mettre à jour.
1. Choisissez **Actions, Edit configuration** (Actions, Modifier la configuration).
1. Décochez la case **Scan instances for missing patches daily** (Analyser quotidiennement les instances pour les correctifs manquants).
1. Choisissez **Mettre à jour**.
**Note**
L'utilisation de l'option **Patch now** (Appliquer les correctifs maintenant) pour analyser la conformité d'un nœud géré entraîne également le remplacement des données de conformité aux correctifs.
# Application de correctifs sur les nœuds gérés à la demande
L’utilisation de l’option **Corriger maintenant** dans Patch Manager, un outil d’ AWS Systems Manager, vous permet d’exécuter des opérations d’application de correctifs à la demande depuis la console Systems Manager. Cela signifie que vous n'avez pas à créer de calendrier pour mettre à jour le statut de conformité de vos nœuds gérés ou pour installer des correctifs sur les nœuds non conformes. Vous n'avez pas non plus besoin de basculer la console Systems Manager entre Patch Manager etMaintenance Windows, un outil AWS Systems Manager, pour configurer ou modifier une fenêtre d'application de correctifs planifiée.
L'option **Patch now (Appliquer les correctifs maintenant)** est particulièrement utile lorsque vous devez appliquer des mises à jour « zéro jour » ou installer d'autres correctifs critiques sur vos nœuds gérés dans les plus brefs délais.
**Note**
L'application de correctifs à la demande est prise en charge pour une seule Compte AWSRégion AWS paire à la fois. Elle ne peut pas être utilisée avec des opérations d'application de correctifs basées sur des *politiques de correctif*. Nous vous recommandons d'utiliser des politiques de correctif pour garantir la conformité de tous vos nœuds gérés. Pour plus d'informations sur l'utilisation des politiques de correctifs, consultez la rubrique [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
**Topics**
+ [Fonctionnement de l'option « Corriger maintenant »](#patch-on-demand-how-it-works)
+ [Exécution de l'option « Corriger maintenant »](#run-patch-now)
## Fonctionnement de l'option « Corriger maintenant »
Pour exécuter l'option **Corriger maintenant**, vous devez spécifier deux paramètres obligatoires seulement :
+ La simple recherche des correctifs manquants, ou l'analyse *et* l'installation des correctifs sur vos nœuds gérés
+ Les nœuds gérés sur lesquels exécuter l'opération
Lorsque l'opération **Patch now (Appliquer les correctifs maintenant)** s'exécute, elle détermine le référentiel de correctifs à utiliser, comme pour les autres opérations d'application de correctifs. Si un nœud géré est associé à un groupe de correctifs, le référentiel de correctifs spécifié pour ce groupe est utilisé. Si le nœud géré n'est associé à aucun groupe de correctifs, l'opération utilise le référentiel de correctifs défini par défaut pour le type de système d'exploitation du nœud géré. Il peut s'agir d'un référentiel prédéfini ou du référentiel personnalisé que vous avez défini par défaut. Pour plus d'informations sur la sélection du référentiel de correctifs, consultez [Groupes de correctifs](patch-manager-patch-groups.md).
Parmi les options que vous pouvez spécifier pour l'opération **Patch now (Appliquer les correctifs maintenant)** figurent le choix du moment, ou de l'opportunité, de redémarrer les nœuds gérés après l'application de correctifs, la spécification d'un compartiment Amazon Simple Storage Service (Amazon S3) pour stocker les données de journal de l'opération d'application de correctifs, et l'exécution de documents Systems Manager (documents SSM) en tant que hooks de cycle de vie pendant l'application des correctifs.
### Seuils de simultanéité et d'erreur pour l'option « Corriger maintenant »
Pour les opérations **Corriger maintenant**, les options de simultanéité et de seuil d'erreur sont gérées par Patch Manager. Il n'est pas nécessaire de spécifier le nombre de nœuds gérés à corriger simultanément, ni le nombre d'erreurs autorisées avant que l'opération échoue. Patch Manager applique les paramètres de simultanéité et de seuil d'erreur décrits dans les tableaux suivants lorsque vous appliquez des correctifs à la demande.
**Important**
Les seuils suivants s'appliquent aux opérations `Scan and install` uniquement. Pour les opérations `Scan`, Patch Manager tente d'analyser jusqu'à 1 000 nœuds simultanément et de poursuivre l'analyse jusqu'à ce qu'il ait rencontré jusqu'à 1 000 erreurs.
**Concurrences : opérations d'installation**
| Nombre total de nœuds gérés associés à l'opération **Patch now (Appliquer les correctifs maintenant)** | Nombre de nœuds gérés analysés ou corrigés simultanément |
| --- | --- |
| Moins de 25 | 1 |
| 25-100 | 5 % |
| 101 à 1 000 | 8 % |
| Plus de 1 000 | 10 % |
**Seuil d'erreur : opérations d'installation**
| Nombre total de nœuds gérés associés à l'opération **Patch now (Appliquer les correctifs maintenant)** | Nombre d'erreurs autorisées avant que l'opération échoue |
| --- | --- |
| Moins de 25 | 1 |
| 25-100 | 5 |
| 101 à 1 000 | 10 |
| Plus de 1 000 | 10 |
### Utilisation des hooks de cycle de vie « Corriger maintenant »
L'opération **Corriger maintenant** vous permet d'exécuter des documents SSM Command en tant que hooks de cycle de vie durant une opération d'application de correctifs `Install`. Vous pouvez utiliser ces hooks pour des tâches telles que l'arrêt des applications avant l'application de correctifs ou l'exécution de surveillances de l'état de vos applications après l'application de correctifs ou après un redémarrage.
Pour plus d'informations sur l'utilisation des hooks de cycle de vie, consultez [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
Le tableau suivant répertorie les hooks de cycle de vie disponibles pour chacun des trois options **Corriger maintenant**, ainsi que des exemples d'utilisation pour chaque hook.
**Hooks de cycle de vie et exemples d'utilisation**
| Option de redémarrage | Hook : avant l'installation | Hook : après l'installation | Hook : à la sortie | Hook : après le redémarrage planifié |
| --- | --- | --- | --- | --- |
| Redémarrer si nécessaire | Exécutez un document SSM avant le début de l'application des correctifs. Exemple d'utilisation : arrêtez les applications en toute sécurité avant le début du processus d'application des correctifs. | Exécutez un document SSM à la fin de l'opération d'application des correctifs et avant le redémarrage du nœud géré. Exemple d'utilisation : exécutez des opérations telles que l'installation d'applications tierces avant un redémarrage potentiel. | Exécutez un document SSM une fois l'opération de correctif terminée et les instances redémarrées. Exemple d'utilisation : vérifiez que les applications s'exécutent comme prévu après l'application des correctifs. | Non disponible |
| Ne pas redémarrer mes instances | Idem ci-dessus. | Exécutez un document SSM à la fin de l'opération d'application des correctifs. Exemple d'utilisation : vérifiez que les applications s'exécutent comme prévu après l'application des correctifs. | *Non disponible* | *Non disponible* |
| Planifier une heure de redémarrage | Idem ci-dessus. | Identique à Ne pas redémarrer mes instances. | Non disponible | Exécutez un document SSM immédiatement après la fin d'un redémarrage planifié. Exemple d'utilisation : vérifiez que les applications s'exécutent comme prévu après le redémarrage. |
## Exécution de l'option « Corriger maintenant »
Procédez comme suit pour appliquer des correctifs à la demande à vos nœuds gérés.
**Pour exécuter l'option « Corriger maintenant »**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez **Corriger maintenant**.
1. Pour **Opération d'application des correctifs**, sélectionnez l'une des options suivantes :
+ **Scan (Analyser)** : Patch Manager recherche les correctifs manquants sur vos nœuds gérés, mais ne les installe pas. Vous pouvez afficher les résultats dans le tableau de bord **Compliance** ou dans les autres outils que vous utilisez pour afficher la conformité des correctifs.
+ **Scan and install (Analyser et installer)** : Patch Manager recherche les correctifs manquants sur vos nœuds gérés et les installe.
1. Effectuez cette étape uniquement si vous avez choisi **Analyser et installer** à l'étape précédente. Pour **Reboot option (Option de redémarrage)**, sélectionnez l'une des options suivantes :
+ **Reboot if needed (Redémarrer si nécessaire)** : après l'installation, Patch Manager ne redémarre les nœuds gérés que si cela est nécessaire pour finaliser l'installation des correctifs.
+ **Don't reboot my instances (Ne pas redémarrer mes instances)** : après l'installation, Patch Manager ne redémarre pas les nœuds gérés. Vous pouvez redémarrer les nœuds manuellement lorsque vous sélectionnez ou gérez les redémarrages en dehors de Patch Manager.
+ **Schedule a reboot time (Planifier une heure de redémarrage)** : spécifiez la date, l'heure et le fuseau horaire UTC auxquels vous souhaitez que Patch Manager redémarre vos nœuds gérés. Après avoir exécuté l'option **Corriger maintenant**, le redémarrage planifié est répertorié comme une association dans State Manager sous le nom `AWS-PatchRebootAssociation`.
**Important**
Si vous annulez l'opération de correction principale après son démarrage, l'`AWS-PatchRebootAssociation`association n'State Managerest PAS automatiquement annulée. Pour éviter les redémarrages inattendus, vous devez supprimer manuellement `AWS-PatchRebootAssociation` de State Manager si vous ne souhaitez plus que le redémarrage planifié ait lieu. Le non-respect de cette consigne peut entraîner des redémarrages imprévus du système susceptibles d'avoir un impact sur les charges de travail de production. Vous trouverez cette association dans la console Systems Manager sous **State Manager**> **Associations**.
1. Pour **Instances to patch (Instances à corriger)**, sélectionnez l'une des options suivantes :
+ **Corrigez toutes les instances** : Patch Manager exécute actuellement l'opération spécifiée sur tous les nœuds gérés Compte AWS de votre instance Région AWS.
+ **Patch only the target instances I specify (N'appliquer les correctifs que sur les instances cibles que je spécifie)** : vous spécifiez les nœuds gérés à cibler à l'étape suivante.
1. Utilisez cette étape uniquement si vous avez choisi **Corriger seulement les instances cibles que je spécifie** à l'étape précédente. Dans la section **Target selection (Sélection de la cible)**, identifiez les nœuds sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant les nœuds manuellement ou en spécifiant un groupe de ressources.
**Note**
Si, contrairement à vos attentes, un nœud géré ne figure pas dans la liste, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) pour obtenir des conseils de dépannage.
Si vous choisissez de cibler un groupe de ressources, notez que les groupes de ressources basés sur une AWS CloudFormation pile doivent toujours être étiquetés avec la `aws:cloudformation:stack-id` balise par défaut. Si elle a été supprimée, cela peut empêcher Patch Manager de déterminer quels nœuds gérés appartiennent au groupe de ressources.
1. (Facultatif) Pour **Stockage des journaux d'application des correctifs**, si vous voulez créer et enregistrer des journaux à partir de cette opération d'application de correctifs, sélectionnez le compartiment S3 dans lequel les journaux seront stockés.
**Note**
Les autorisations S3 qui accordent la possibilité d'écrire les données dans un compartiment S3 sont celles du profil d'instance (pour les instances EC2) ou de la fonction du service IAM (pour les machines activées par un système hybride) attribués à l'instance, et non celles de l'utilisateur IAM qui effectue cette tâche. Pour plus d’informations, veuillez consulter les rubriques [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md) ou [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md). En outre, si le compartiment S3 spécifié se trouve dans un autre compartiment Compte AWS, assurez-vous que le profil d'instance ou le rôle de service IAM associé au nœud géré dispose des autorisations nécessaires pour écrire dans ce compartiment.
1. (Facultatif) Pour exécuter des documents SSM en tant que hooks de cycle de vie au niveau de points spécifiques de l'opération d'application de correctifs, procédez comme suit :
+ Sélectionnez **Utiliser des hooks de cycle de vie**.
+ Pour chaque hook disponible, sélectionnez le document SSM à exécuter au point spécifié de l'opération :
+ Avant l'installation
+ Après l'installation
+ À la sortie
+ Après le redémarrage planifié
**Note**
Le document par défaut, `AWS-Noop`, n'exécute aucune opération.
1. Sélectionnez **Corriger maintenant**.
La page **Association execution summary (Résumé d'exécution de l'association)** s'ouvre. (L’option Corriger maintenant utilise alors des associations dans State Manager, un outil d’ AWS Systems Manager, pour ses opérations.) Dans la zone **Operation summary (Résumé de l'opération)**, vous pouvez surveiller le statut de l'analyse ou de l'application des correctifs sur les nœuds gérés que vous avez spécifiés.
# Utilisation des référentiels de correctifs
Un référentiel de correctifs de l’outil Patch Manager d’ AWS Systems Manager définit les correctifs qui peuvent être installés sur vos nœuds gérés. Vous pouvez spécifier un par un les correctifs approuvés ou rejetés. Vous pouvez également utiliser les règles d'approbation automatique pour spécifier que certains types de mises à jour (par exemple, les mises à jour critiques) doivent être approuvés automatiquement. La liste des mises à jour rejetées remplace à la fois les règles et la liste des mises à jour approuvées. Pour utiliser une liste de correctifs approuvés pour installer des packages spécifiques, commencez par supprimer toutes les règles d'approbation automatique. Si vous avez identifié explicitement un correctif en tant que rejeté, il ne sera ni approuvé, ni installé, même s'il correspond à tous les critères d'une règle d'approbation automatique. De la même façon, un correctif n'est installé sur un nœud géré qu'à condition qu'il soit compatible avec le logiciel du nœud, même si le correctif a par ailleurs été approuvé pour le nœud géré.
**Topics**
+ [Affichage des lignes de base de correctifs AWS prédéfinies](patch-manager-view-predefined-patch-baselines.md)
+ [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md)
+ [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md)
**Plus d'informations**
+ [Références de correctifs](patch-manager-patch-baselines.md)
# Affichage des lignes de base de correctifs AWS prédéfinies
Patch Manager, un outil dans AWS Systems Manager, inclut une ligne de base de correctifs prédéfinie pour chaque système d'exploitation pris en charge parPatch Manager. Vous pouvez soit utiliser ces références de correctifs (impossibles à personnaliser), soit en créer. La procédure suivante décrit comment afficher un référentiel de correctifs prédéfinie afin de voir si elle répond à vos besoins. Pour en savoir plus sur les références de correctifs, consultez [Référentiels de correctifs prédéfinis et personnalisés](patch-manager-predefined-and-custom-patch-baselines.md).
**Pour afficher les lignes de base de correctifs AWS prédéfinies**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Dans la liste des références de correctifs, sélectionnez l'ID de l'une des références de correctifs prédéfinies.
-ou-
Si vous accédez à Patch Manager pour la première fois dans l' Région AWS actuelle, choisissez **Commencer par une présentation**, sélectionnez l'onglet **Référentiels de correctifs**, puis choisissez l'ID de référentiel de l'un des référentiels de correctifs prédéfinis.
**Note**
Pour Windows Server, trois référentiels de correctifs prédéfinis sont fournis. Les référentiels de correctifs `AWS-DefaultPatchBaseline` et `AWS-WindowsPredefinedPatchBaseline-OS` prennent uniquement en charge les mises à jour du système d'exploitation Windows. `AWS-DefaultPatchBaseline` est utilisé comme référentiel de correctifs par défaut pour les nœuds gérés Windows Server, sauf si vous en spécifiez un autre. Ces deux référentiels de correctifs ont des paramètres de configuration identiques. Le plus récent des deux, `AWS-WindowsPredefinedPatchBaseline-OS`, a été créé pour le différencier du troisième référentiel de correctifs prédéfini pour Windows Server. Ce référentiel de correctifs, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, peut être utilisé pour appliquer des correctifs à la fois au système d'exploitation Windows Server et aux applications prises en charge publiées par Microsoft.
Pour de plus amples informations, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation**, consultez la configuration des référentiels de correctifs.
1. Si la configuration est acceptable pour vos nœud gérés, vous pouvez passer à la procédure [Création et gestion de groupes de correctifs](patch-manager-tag-a-patch-group.md).
-ou-
Pour créer votre propre référentiel de correctifs par défaut, passez à la rubrique [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).
# Utilisation des référentiels de correctifs personnalisés
Patch Manager, un outil dans AWS Systems Manager, inclut une ligne de base de correctifs prédéfinie pour chaque système d'exploitation pris en charge parPatch Manager. Vous pouvez soit utiliser ces références de correctifs (impossibles à personnaliser), soit en créer.
Les procédures suivantes décrivent comment créer, mettre à jour et supprimer votre propre référentiel de correctifs personnalisé. Pour en savoir plus sur les références de correctifs, consultez [Référentiels de correctifs prédéfinis et personnalisés](patch-manager-predefined-and-custom-patch-baselines.md).
**Topics**
+ [Création d’un référentiel de correctifs personnalisé pour Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Création d’un référentiel de correctifs personnalisé pour macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Création d’un référentiel de correctifs personnalisé pour Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Mise à jour ou suppression d’un référentiel de correctifs personnalisé](patch-manager-update-or-delete-a-patch-baseline.md)
# Création d’un référentiel de correctifs personnalisé pour Linux
Suivez la procédure ci-dessous afin de créer un référentiel de correctifs personnalisé pour les nœuds gérés Linux dans l’outil Patch Manager d’ AWS Systems Manager.
Pour plus d'informations sur la création d'un référentiel de correctifs pour les nœuds gérés macOS, consultez [Création d’un référentiel de correctifs personnalisé pour macOS](patch-manager-create-a-patch-baseline-for-macos.md). Pour plus d'informations sur la création d'un référentiel de correctifs pour les nœuds gérés Windows, consultez [Création d’un référentiel de correctifs personnalisé pour Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).
**Pour créer un référentiel de correctifs personnalisé pour les nœuds gérés Linux**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
-ou-
Si vous accédez à Patch Manager pour la première fois dans la Région AWS actuelle, choisissez **Commencer par une présentation**, sélectionnez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
1. Pour **Nom**, entrez un nom pour votre nouvelle référentiel de correctifs, par exemple : `MyRHELPatchBaseline`.
1. (Facultatif) Pour **Description**, saisissez une description pour cette référence de correctif.
1. Pour **Operating system (Système d'exploitation)**, sélectionnez un système d'exploitation, par exemple, `Red Hat Enterprise Linux`.
1. Si vous souhaitez commencer à utiliser cette ligne de base de correctifs par défaut pour le système d'exploitation sélectionné dès sa création, cochez la case à côté de **Définir cette ligne de base de correctifs comme ligne de base de correctifs par défaut pour les *operating system name* instances**.
**Note**
Cette option n'est disponible que si vous avez accédé à Patch Manager pour la première fois avant la publication des [politiques de correctifs](patch-manager-policies.md) le 22 décembre 2022.
Pour de plus amples informations, sur la définition d'un référentiel de correctifs existante en tant que référence par défaut, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation pour les systèmes d'exploitation)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
+ **Produits** : version des systèmes d'exploitation à laquelle s'applique la règle d'approbation, par exemple `RedhatEnterpriseLinux7.4`. La sélection par défaut est `All`.
+ **Classification** : type de correctifs auquel s'applique la règle d'approbation, par exemple `Security` ou `Enhancement`. La sélection par défaut est `All`.
**Astuce**
Vous pouvez configurer un référentiel de correctifs pour contrôler si des mises à niveau mineures pour Linux sont installées, par exemple RHEL 7.8. Les mises à niveau mineures de version peuvent être installées automatiquement par Patch Manager, à condition que la mise à jour soit disponible dans le référentiel approprié.
Pour les systèmes d'exploitation Linux, les mises à niveau de versions mineures ne sont pas classées de manière cohérente. Elles peuvent être classées comme correctifs de bogues ou mises à jour de sécurité, ou non classés, même dans la même version du noyau. Voici quelques options pour vérifier si un référentiel de correctifs les installe.
**Option 1** : La règle d'approbation la plus large pour s'assurer que des mises à niveau mineures sont installées lorsqu'elles sont disponibles consiste à définir la valeur de **Classification** sur `All` (\$1) et à choisir l'option **Inclusion de mises à jour non liées à la sécurité**.
**Option 2** : Pour vous assurer que les correctifs d'une version d'un système d'exploitation sont installés, vous pouvez utiliser un caractère générique (\$1) pour spécifier son format de noyau dans la section des **Exceptions de correctif** de la référence. Par exemple, le format du noyau pour RHEL 7.\$1 est `kernel-3.10.0-*.el7.x86_64`.
Saisissez `kernel-3.10.0-*.el7.x86_64` dans la liste **Approved patches (Correctifs approuvés)** de votre référentiel de correctifs pour vous assurer que tous les correctifs, y compris les mises à niveau de versions mineures, sont appliqués à vos nœuds gérés RHEL 7.\$1. (Si vous connaissez le nom exact du package d'un correctif de version mineur, saisissez-le à la place de cette valeur.)
**Option 3** : vous pouvez avoir le plus de contrôle sur les correctifs appliqués à vos nœuds gérés, y compris les mises à niveau de versions mineures, en utilisant le [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)paramètre indiqué dans le `AWS-RunPatchBaseline` document. Pour de plus amples informations, veuillez consulter [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
+ **Severity (Sévérité)** : valeur de sévérité des correctifs à laquelle la règle va s'appliquer, par exemple `Critical`. La sélection par défaut est `All`.
+ **Approbation automatique** : méthode de sélection des patchs pour approbation automatique.
**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.
+ **Approuvez les correctifs après un nombre de jours spécifié** : pendant lesquels Patch Manager doit attendre la publication ou la dernière mise à jour d'un correctif avant son approbation automatique. Vous pouvez entrer tout nombre entier situé entre zéro (0) et 360. Nous vous recommandons, en règle générale, de ne pas attendre plus de 100 jours.
+ **L'approbation des correctifs publiés jusqu'à une date spécifique**: date de publication des correctifs pour laquelle Patch Manager applique automatiquement tous les correctifs publiés à cette date ou avant cette date. Par exemple, si vous spécifiez le 7 juillet 2023, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
+ (Facultatif) **Rapport de conformité** : niveau de sévérité que vous voulez affecter aux correctifs approuvés par la référence, tel que `Critical` ou `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
+ **Include non-security updates (Inclure les mises à jour non liées à la sécurité)** : cochez cette case pour installer les correctifs non liés à la sécurité pour le système d'exploitation Linux disponibles dans le référentiel source, en plus des correctifs de sécurité.
Pour en savoir plus sur l'utilisation des règles d'approbation dans un référentiel de correctifs personnalisée, consultez [Références personnalisées](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Si vous souhaitez explicitement approuver des correctifs en plus de ceux conformes à vos règles d'approbation, procédez comme suit dans la section **Patch exceptions (Exceptions de correctifs)** :
+ Pour **Approved patches (Correctifs approuvés)**, entrez une liste séparée par des virgules des correctifs à approuver.
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).
+ (Facultatif) Pour **Approved patches compliance level (Niveau de conformité des correctifs approuvés)**, affectez un niveau de conformité aux correctifs figurant dans la liste.
+ Si des correctifs approuvés que vous spécifiez ne sont pas liés à la sécurité, cochez la case **Inclusion de mises à jour non liées à la sécurité** pour que ces correctifs soient également installés sur votre système d’exploitation Linux.
1. Si vous souhaitez rejeter explicitement des correctifs conformes par ailleurs à vos règles d'approbation, procédez comme suit dans la section **Patch exceptions (Exceptions de correctifs)** :
+ Pour **Rejected patches (Correctifs rejetés)**, entrez une liste séparée par des virgules des correctifs à rejeter.
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 **Rejected patches action (Action pour les correctifs rejetés)**, sélectionnez l'action que Patch Manager doit effectuer sur les correctifs inclus dans la liste **Rejected patches (Correctifs rejetés)**.
+ **Allow as dependency (Autoriser en tant que dépendance)** : un package de la liste **Rejected patches (Correctifs rejetés)** est installé uniquement s'il constitue une dépendance d'un autre package. Il est considéré comme conforme à la ligne de base du correctif et son état est indiqué sous la forme *InstalledOther*. Il s'agit de l'action par défaut si aucune option n'est spécifiée.
+ **Bloquer** : les packages de la liste **Correctifs rejetés**, ainsi que les packages qui les incluent en tant que dépendances, ne sont pas installés par Patch Manager, quelles que soient les circonstances. Si un package a été installé avant d’être ajouté à la liste des **correctifs rejetés**, ou s’il est installé en dehors de Patch Manager par la suite, il est considéré comme non conforme au référentiel de correctifs et son statut est signalé comme *InstalledRejected*.
**Note**
Patch Manager recherche les dépendances des correctifs de manière récursive.
1. **(Facultatif) Si vous souhaitez spécifier des référentiels de correctifs alternatifs pour différentes versions d'un système d'exploitation, telles que *AmazonLinux2016.03 et *AmazonLinux2017.09**, procédez comme suit pour chaque produit dans la section Sources des correctifs :**
+ Dans **Name (Nom)**, entrez un nom qui vous aidera à identifier la configuration de la source.
+ Dans **Product (Produit)**, sélectionnez la version des systèmes d'exploitation à laquelle est destiné le référentiel source de correctifs, comme `RedhatEnterpriseLinux7.4`.
+ Dans **Configuration**, saisissez la valeur de la configuration du référentiel à utiliser dans le format approprié :
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**Astuce**
Pour plus d'informations sur les autres options disponibles pour la configuration de votre référentiel yum, reportez-vous à la section [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).
------
#### [ Examples for Ubuntu Server and Debian Server ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Les informations de référentiel pour les référentiels Ubuntu Server doivent être spécifiées sur une seule ligne. Pour plus d’exemples et d’informations, consultez [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) sur le site Web des *manuels du serveur Ubuntu* et [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format) sur le *Wiki Debian*.
------
Sélectionnez **Add another source** (Ajouter une autre source) pour spécifier un référentiel source pour chaque version supplémentaire du système d'exploitation, jusqu'à un maximum de 20.
Pour en savoir plus sur les autres référentiels source de correctifs, consultez [Spécification d'un autre référentiel source de correctifs (Linux)](patch-manager-alternative-source-repository.md).
1. (Facultatif) Pour **Gérer les balises**, appliquez une ou plusieurs name/value paires de clés de balise à la ligne de base du correctif.
Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Par exemple, vous pouvez baliser un référentiel de correctifs pour identifier le niveau de sévérité de correctifs qu'elle spécifie, la famille de systèmes d'exploitation à laquelle elle s'applique et le type d'environnement. Dans ce cas, vous pouvez spécifier des balises similaires aux name/value paires de clés suivantes :
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Sélectionnez **Créer un référentiel de correctif**.
# Création d’un référentiel de correctifs personnalisé pour macOS
Suivez la procédure ci-dessous afin de créer un référentiel de correctifs personnalisé pour les nœuds gérés macOS dans Patch Manager, un outil d’ AWS Systems Manager.
Pour plus d'informations sur la création d'un référentiel de correctifs pour les nœuds gérés Windows Server, consultez [Création d’un référentiel de correctifs personnalisé pour Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Pour plus d'informations sur la création d'un référentiel de correctifs pour les nœuds gérés Linux, consultez [Création d’un référentiel de correctifs personnalisé pour Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**Note**
macOSn'est pas pris en charge dans tous les cas Régions AWS. Pour plus d’informations sur la prise en charge d’Amazon EC2 pour macOS, consultez [Instances Amazon EC2 Mac](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) dans le *Guide de l’utilisateur Amazon EC2*.
**Pour créer un référentiel de correctifs personnalisé pour les nœuds gérés macOS**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
-ou-
Si vous accédez à Patch Manager pour la première fois dans la Région AWS actuelle, choisissez **Commencer par une présentation**, sélectionnez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
1. Pour **Nom**, entrez un nom pour votre nouvelle référentiel de correctifs, par exemple : `MymacOSPatchBaseline`.
1. (Facultatif) Pour **Description**, saisissez une description pour cette référence de correctif.
1. Pour **Système d'exploitation**, sélectionnez macOS.
1. Si vous souhaitez commencer à utiliser ce référentiel de correctifs comme référence par défaut pour macOS dès sa création, cochez la case **Set this patch baseline as the default patch baseline for macOS instances (Définir cette référence comme référentiel de correctifs par défaut pour les instances du nom du système d'exploitation)**.
**Note**
Cette option n'est disponible que si vous avez accédé à Patch Manager pour la première fois avant la publication des [politiques de correctifs](patch-manager-policies.md) le 22 décembre 2022.
Pour de plus amples informations, sur la définition d'un référentiel de correctifs existante en tant que référence par défaut, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation pour les systèmes d'exploitation)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
+ **Produits** : version des systèmes d'exploitation à laquelle s'applique la règle d'approbation, par exemple `BigSur11.3.1` ou `Ventura13.7`. La sélection par défaut est `All`.
+ **Classification** : le ou les gestionnaires de packages dont vous voulez qu'ils appliquent des packages durant le processus d'application de correctifs. Sélectionnez parmi les éléments suivants :
+ softwareupdate
+ installer (programme d'installation)
+ brew
+ brew cask
La sélection par défaut est `All`.
+ (Facultatif) **Rapport de conformité** : niveau de sévérité que vous voulez affecter aux correctifs approuvés par la référence, tel que `Critical` ou `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
Pour en savoir plus sur l'utilisation des règles d'approbation dans un référentiel de correctifs personnalisée, consultez [Références personnalisées](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Si vous souhaitez explicitement approuver des correctifs en plus de ceux conformes à vos règles d'approbation, procédez comme suit dans la section **Patch exceptions (Exceptions de correctifs)** :
+ Pour **Approved patches (Correctifs approuvés)**, entrez une liste séparée par des virgules des correctifs à approuver.
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).
+ (Facultatif) Pour **Approved patches compliance level (Niveau de conformité des correctifs approuvés)**, affectez un niveau de conformité aux correctifs figurant dans la liste.
1. Si vous souhaitez rejeter explicitement des correctifs conformes par ailleurs à vos règles d'approbation, procédez comme suit dans la section **Patch exceptions (Exceptions de correctifs)** :
+ Pour **Rejected patches (Correctifs rejetés)**, entrez une liste séparée par des virgules des correctifs à rejeter.
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 **Rejected patches action (Action pour les correctifs rejetés)**, sélectionnez l'action que Patch Manager doit effectuer sur les correctifs inclus dans la liste **Rejected patches (Correctifs rejetés)**.
+ **Allow as dependency (Autoriser en tant que dépendance)** : un package de la liste **Rejected patches (Correctifs rejetés)** est installé uniquement s'il constitue une dépendance d'un autre package. Il est considéré comme conforme à la ligne de base du correctif et son état est indiqué sous la forme *InstalledOther*. Il s'agit de l'action par défaut si aucune option n'est spécifiée.
+ **Bloquer** : les packages de la liste **Correctifs rejetés**, ainsi que les packages qui les incluent en tant que dépendances, ne sont pas installés par Patch Manager, quelles que soient les circonstances. Si un package a été installé avant d’être ajouté à la liste des **correctifs rejetés**, ou s’il est installé en dehors de Patch Manager par la suite, il est considéré comme non conforme au référentiel de correctifs et son statut est signalé comme *InstalledRejected*.
1. (Facultatif) Pour **Gérer les balises**, appliquez une ou plusieurs name/value paires de clés de balise à la ligne de base du correctif.
Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Par exemple, vous pouvez baliser un référentiel de correctifs pour identifier le niveau de sévérité de correctifs qu'elle spécifie, le gestionnaire de packages auquel elle s'applique et le type d'environnement. Dans ce cas, vous pouvez spécifier des balises similaires aux name/value paires de clés suivantes :
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. Sélectionnez **Créer un référentiel de correctif**.
# Création d’un référentiel de correctifs personnalisé pour Windows Server
Suivez la procédure ci-dessous afin de créer un référentiel de correctifs personnalisé pour les nœuds gérés dans Patch Manager, un outil d’ AWS Systems Manager.
Pour plus d'informations sur la création d'un référentiel de correctifs pour les nœuds gérés Linux, consultez [Création d’un référentiel de correctifs personnalisé pour Linux](patch-manager-create-a-patch-baseline-for-linux.md). Pour plus d’informations sur la création d’un référentiel de correctifs pour les nœuds gérés macOS, consultez [Création d’un référentiel de correctifs personnalisé pour macOS](patch-manager-create-a-patch-baseline-for-macos.md).
Pour obtenir un exemple de création d'un référentiel de correctifs limitée à l'installation des Service Packs Windows uniquement, veuillez consulter [Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
**Pour créer un référentiel de correctifs personnalisée (Windows)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
-ou-
Si vous accédez à Patch Manager pour la première fois dans la Région AWS actuelle, choisissez **Commencer par une présentation**, sélectionnez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
1. Pour **Nom**, entrez un nom pour votre nouvelle référentiel de correctifs, par exemple : `MyWindowsPatchBaseline`.
1. (Facultatif) Pour **Description**, saisissez une description pour cette référence de correctif.
1. Pour **Système d'exploitation**, sélectionnez `Windows`.
1. Pour **Statut de conformité des mises à jour de sécurité disponibles**, choisissez le statut que vous souhaitez attribuer aux correctifs de sécurité disponibles mais non approuvés car ils ne répondent pas aux critères d’installation spécifiés dans le référentiel de correctifs, **Non conforme** ou **Conforme**.
Exemple de scénario : les correctifs de sécurité que vous souhaitez installer peuvent être ignorés si vous avez spécifié une longue période d’attente après la publication d’un correctif avant l’installation. Si une mise à jour du correctif est publiée pendant la période d’attente que vous avez spécifiée, la période d’attente pour l’installation du correctif recommence. Si le délai d’attente est trop long, plusieurs versions du correctif peuvent être publiées mais ne jamais être installées.
1. Si vous souhaitez commencer à utiliser cette référence de correctif comme valeur par défaut pour Windows dès sa création, sélectionnez **Définir cette référence de correctif comme référence par défaut pour les instances Windows Server**.
**Note**
Cette option n'est disponible que si vous avez accédé à Patch Manager pour la première fois avant la publication des [politiques de correctifs](patch-manager-policies.md) le 22 décembre 2022.
Pour de plus amples informations, sur la définition d'un référentiel de correctifs existante en tant que référence par défaut, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation pour les systèmes d'exploitation)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
+ **Produits** : version des systèmes d'exploitation à laquelle s'applique la règle d'approbation, par exemple `WindowsServer2012`. La sélection par défaut est `All`.
+ **Classification** : type de correctifs auquel s'applique la règle d'approbation, par exemple `CriticalUpdates`, `Drivers` et `Tools`. La sélection par défaut est `All`.
**Astuce**
Vous pouvez inclure des installations de Service Packs Windows dans vos règles d'approbation en incluant `ServicePacks` ou en choisissant `All` dans votre liste **Classification**. Pour obtenir un exemple, consultez [Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
+ **Severity (Sévérité)** : valeur de sévérité des correctifs à laquelle la règle va s'appliquer, par exemple `Critical`. La sélection par défaut est `All`.
+ **Approbation automatique** : méthode de sélection des patchs pour approbation automatique.
+ **Approuver les correctifs après un nombre de jours spécifié** : pendant lesquels Patch Manager doit attendre après la publication ou la mise à jour d'un correctif avant son approbation automatique. Vous pouvez entrer tout nombre entier situé entre zéro (0) et 360. Nous vous recommandons, en règle générale, de ne pas attendre plus de 100 jours.
+ **L'approbation des correctifs publiés jusqu'à une date spécifique**: date de publication des correctifs pour laquelle Patch Manager applique automatiquement tous les correctifs publiés à cette date ou avant cette date. Par exemple, si vous spécifiez le 7 juillet 2023, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
+ (Facultatif) **Compliance reporting (Rapport de conformité)** : niveau de sévérité que vous voulez affecter aux correctifs approuvés par la référence, tel que `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
1. (Facultatif) Dans la section **Approval rules for applications (Règles d'approbation pour les applications Microsoft)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
**Note**
Au lieu de spécifier des règles d'approbation, vous pouvez spécifier des listes de correctifs approuvés et de correctifs rejetés en tant qu'exceptions de correctifs. Voir les étapes 10 et 11.
+ **Product family (Famille de produits)** : famille de produits Microsoft générale pour laquelle vous souhaitez spécifier une règle, par exemple `Office` ou `Exchange Server`.
+ **Produits** : version de l'application à laquelle s'applique la règle d'approbation, par exemple `Office 2016` ou `Active Directory Rights Management Services Client 2.0 2016`. La sélection par défaut est `All`.
+ **Classification** : type de correctifs auquel s'applique la règle d'approbation, par exemple `CriticalUpdates`. La sélection par défaut est `All`.
+ **Severity (Sévérité)** : valeur de sévérité des correctifs à laquelle la règle s'applique, par exemple `Critical`. La sélection par défaut est `All`.
+ **Approbation automatique** : méthode de sélection des patchs pour approbation automatique.
+ **Approuver les correctifs après un nombre de jours spécifié** : pendant lesquels Patch Manager doit attendre après la publication ou la mise à jour d'un correctif avant son approbation automatique. Vous pouvez entrer tout nombre entier situé entre zéro (0) et 360. Nous vous recommandons, en règle générale, de ne pas attendre plus de 100 jours.
+ **L'approbation des correctifs publiés jusqu'à une date spécifique**: date de publication des correctifs pour laquelle Patch Manager applique automatiquement tous les correctifs publiés à cette date ou avant cette date. Par exemple, si vous spécifiez le 7 juillet 2023, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
+ (Facultatif) **Rapport de conformité** : niveau de sévérité que vous voulez affecter aux correctifs approuvés par la référence, tel que `Critical` ou `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un correctif approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
1. (Facultatif) Si, au lieu que des correctifs soient sélectionnés selon les règles d'approbation, vous voulez les approuver explicitement, procédez comme suit dans la section **Exceptions de correctifs** :
+ Pour **Approved patches (Correctifs approuvés)**, entrez une liste séparée par des virgules des correctifs à approuver.
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).
+ (Facultatif) Pour **Approved patches compliance level (Niveau de conformité des correctifs approuvés)**, affectez un niveau de conformité aux correctifs figurant dans la liste.
1. Si vous souhaitez rejeter explicitement des correctifs conformes par ailleurs à vos règles d'approbation, procédez comme suit dans la section **Patch exceptions (Exceptions de correctifs)** :
+ Pour **Rejected patches (Correctifs rejetés)**, entrez une liste séparée par des virgules des correctifs à rejeter.
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 **Rejected patches action (Action pour les correctifs rejetés)**, sélectionnez l'action que Patch Manager doit effectuer sur les correctifs inclus dans la liste **Rejected patches (Correctifs rejetés)**.
+ **Autoriser en tant que dépendance** : Windows Server ne prend pas en charge le concept de dépendances de package. Si un package figurant dans la liste des **correctifs rejetés** et déjà installé sur le nœud, son statut est signalé comme `INSTALLED_OTHER`. Tout package qui n’est pas déjà installé sur le nœud est ignoré.
+ **Bloquer** : les packages de la liste des **correctifs rejetés** ne sont en aucun cas installés par Patch Manager. Si un package a été installé avant d’être ajouté à la liste des **correctifs rejetés**, ou s’il est installé en dehors de Patch Manager par la suite, il est considéré comme non conforme au référentiel de correctifs et son statut est signalé comme `INSTALLED_REJECTED`.
Pour plus d’informations sur les actions relatives aux packages rejetés, consultez [Options de la liste des correctifs rejetés dans les référentiels de correctifs personnalisés](patch-manager-windows-and-linux-differences.md#rejected-patches-diff).
1. (Facultatif) Pour **Gérer les balises**, appliquez une ou plusieurs name/value paires de clés de balise à la ligne de base du correctif.
Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Par exemple, vous pouvez baliser un référentiel de correctifs pour identifier le niveau de sévérité de correctifs qu'elle spécifie, la famille de systèmes d'exploitation à laquelle elle s'applique et le type d'environnement. Dans ce cas, vous pouvez spécifier des balises similaires aux name/value paires de clés suivantes :
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Sélectionnez **Créer un référentiel de correctif**.
# Mise à jour ou suppression d’un référentiel de correctifs personnalisé
Vous pouvez mettre à jour ou supprimer une référence de correctifs personnalisée que vous avez créée dans Patch Manager, un outil d’ AWS Systems Manager. Lorsque vous mettez à jour un référentiel de correctifs, vous pouvez modifier son nom, sa description, ses règles d'approbation et ses exceptions pour les correctifs approuvés et rejetés. Vous pouvez également mettre à jour les balises qui sont appliquées au référentiel de correctifs. Vous ne pouvez pas modifier le type de système d'exploitation pour lequel une ligne de base de correctifs a été créée, ni apporter de modifications à une ligne de base de correctifs prédéfinie fournie par AWS.
## Mise à jour ou suppression d’un référentiel de correctifs
Suivez les étapes ci-dessous pour mettre à jour ou supprimer un référentiel de correctifs.
**Important**
Faites preuve de vigilance lorsque vous supprimez un référentiel de correctifs personnalisé susceptible d'être utilisé par la configuration d'une politique de correctifs dans Quick Setup.
Si vous utilisez une [configuration de politique de correctifs](patch-manager-policies.md) dans Quick Setup, les mises à jour que vous apportez aux référentiels de correctifs personnalisés sont synchronisées avec Quick Setup une fois par heure.
Si un référentiel de correctifs personnalisé référencé dans une politique de correctifs est supprimé, une bannière s'affiche sur la page Quick Setup **Configuration details** (Détails de configuration) de votre politique de correctifs. La bannière vous informe que la politique de correctifs fait référence à un référentiel de correctifs qui n'existe plus et que les opérations d'application de correctifs suivantes échoueront. Dans ce cas, revenez à la page Quick Setup **Configurations**, sélectionnez la configuration Patch Manager, puis choisissez **Actions**, **Edit configuration** (Modifier la configuration). Le nom du référentiel de correctifs supprimé est surligné et vous devez sélectionner un nouveau référentiel de correctifs pour le système d'exploitation concerné.
**Pour mettre à jour ou supprimer un référentiel de correctifs**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez le référentiel de correctifs à mettre à jour ou supprimer, puis exécutez l'une des tâches suivantes :
+ Pour supprimer la ligne de base des correctifs de votre Compte AWS ordinateur, choisissez **Supprimer**. Le système vous invite à confirmer vos actions.
+ Pour modifier le nom ou la description d'un référentiel de correctifs, les règles d'approbation ou les exceptions de correctifs, sélectionnez **Modifier**. Sur la page **Modifier le référentiel de correctif**, modifiez les valeurs et options souhaitées, puis sélectionnez **Enregistrer les modifications**.
+ Pour ajouter, modifier ou supprimer des balises appliquées au référentiel de correctifs, sélectionnez l'onglet **Balises**, puis **Modifier les balises**. Sur la page **Edit patch baseline tags (Modifier les balises de référentiel de correctif)**, mettez à jour les balises du référentiel de correctifs, puis sélectionnez **Enregistrer les modifications**.
Pour de plus amples informations sur les choix de configuration que vous pouvez effectuer, veuillez consulter [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).
# Définition d'un référentiel de correctifs existante en tant que valeur par défaut
**Important**
Les sélections de référentiel de correctifs par défaut que vous effectuez ici ne s'appliquent pas aux opérations d'application de correctifs basées sur une politique de correctifs. Les politiques de correctifs utilisent leurs propres spécifications de référentiel de correctifs. Pour plus d'informations sur les politiques de correctifs, veuillez consulter la rubrique [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
Lorsque vous créez un référentiel de correctifs personnalisée dans Patch Manager, un outil d’ AWS Systems Manager, vous pouvez la définir comme référence par défaut pour le type de système d’exploitation associé dès sa création. Pour plus d'informations, consultez [Utilisation des référentiels de correctifs personnalisés](patch-manager-manage-patch-baselines.md).
Vous pouvez également définir un référentiel de correctifs existante en tant que référence par défaut pour un type de système d'exploitation.
**Note**
Les étapes à suivre varient selon si vous avez accédé pour la première fois à Patch Manager avant ou après la publication des politiques de correctifs le 22 décembre 2022. Si vous avez utilisé Patch Manager avant cette date, vous pouvez utiliser la procédure de la console. Dans le cas contraire, suivez la AWS CLI procédure. Le menu **Actions** référencé dans la procédure de la console ne s'affiche pas dans les régions où Patch Manager n'a pas été utilisé avant la publication des politiques de correctifs.
**Pour définir un référentiel de correctifs comme référence par défaut**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Patch baselines (Référentiels de correctifs)**.
1. Dans la liste des références de correctifs, sélectionnez le bouton correspondant à un référentiel de correctifs qui n'est pas actuellement définie comme référence par défaut pour un type de système d'exploitation.
La colonne **Référence par défaut** indique les références qui sont actuellement définies comme références par défaut.
1. Dans le menu **Actions**, sélectionnez **Définir un référentiel de correctif par défaut**.
**Important**
Le menu **Actions** n'est pas disponible si vous n'avez pas travaillé avec Patch Manager la version actuelle Compte AWS et la région avant le 22 décembre 2022. Pour plus d'informations, reportez-vous à la **note** figurant plus haut dans cette rubrique.
1. Dans la boîte de dialogue de confirmation, sélectionnez **Set default (Définir par défaut)**.
**Pour définir un référentiel de correctifs comme référence par défaut (AWS CLI)**
1. Exécutez la [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html)commande pour afficher la liste des lignes de base de correctifs disponibles ainsi que leurs noms IDs et ceux d'Amazon Resource (ARNs).
```
aws ssm describe-patch-baselines
```
1. Exécutez la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) pour définir un référentiel par défaut pour le système d'exploitation auquel il est associé. *baseline-id-or-ARN*Remplacez-le par l'ID de la ligne de base de correctif personnalisée ou de la ligne de base prédéfinie à utiliser.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
Vous trouverez ci-dessous un exemple de définition d'un référentiel personnalisé comme référentiel par défaut.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
Voici un exemple de définition d'une ligne de base prédéfinie gérée par AWS défaut.
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
Vous trouverez ci-dessous un exemple de définition d'un référentiel personnalisé comme référentiel par défaut.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
Voici un exemple de définition d'une ligne de base prédéfinie gérée par AWS défaut.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# Affichage des correctifs disponibles
À l'aide Patch Manager d'un outil AWS Systems Manager, vous pouvez afficher tous les correctifs disponibles pour un système d'exploitation spécifique et, éventuellement, une version spécifique du système d'exploitation.
**Astuce**
Pour générer une liste des correctifs disponibles et les enregistrer dans un fichier, vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) et spécifier votre [sortie](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html).
**Pour afficher les correctifs disponibles**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l'onglet **Patches (Correctifs)**.
-ou-
Si vous accédez à Patch Manager pour la première fois dans la Région AWS actuelle, choisissez **Commencer par une présentation**, puis sélectionnez l'onglet **Correctifs**.
**Note**
Pour Windows Server, l'onglet **Correctifs** affiche les mises à jour disponibles auprès de Windows Server Update Service (WSUS).
1. Pour **Système d'exploitation**, sélectionnez le système d'exploitation pour lequel vous voulez afficher les correctifs disponibles, `Windows` ou `Amazon Linux` par exemple.
1. (Facultatif) Pour **Produit**, sélectionnez une version du système d'exploitation, `WindowsServer2019` ou `AmazonLinux2018.03` par exemple.
1. (Facultatif) Pour ajouter ou supprimer des colonnes d'informations pour vos résultats, sélectionnez le bouton (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/configure-button.png)) en haut à droite de la liste **Correctifs**. (Par défaut, l'onglet **Correctifs** affiche des colonnes pour quelques-unes des métadonnées de correctif disponibles seulement.)
Pour obtenir des informations sur les types de métadonnées qui peuvent être ajoutées à votre affichage, veuillez consulter [Correctif](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) dans la *Référence des API AWS Systems Manager *.
# Création et gestion de groupes de correctifs
Si vous n'utilisez *pas* de stratégies de correction dans vos opérations, vous pouvez organiser vos efforts de correction en ajoutant des nœuds gérés à des groupes de correctifs à l'aide de balises.
**Note**
Les groupes de correctifs ne sont pas utilisés dans les opérations d'application de correctifs basées sur des *politiques de correctifs*. Pour obtenir des informations sur l'utilisation des politiques de correctifs, consultez la rubrique [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
La fonctionnalité de groupes de correctifs n’est pas prise en charge dans la console pour les paires compte-région qui n’utilisaient pas encore de groupes de correctifs avant le lancement de la prise en charge des politiques de correctifs le 22 décembre 2022. La fonctionnalité de groupes de correctifs est toujours disponible dans les paires compte-région qui ont commencé à utiliser les groupes de correctifs avant cette date.
Pour utiliser les balises dans les opérations de correctif, vous devez appliquer la clé de balise `Patch Group` ou `PatchGroup` à vos nœuds gérés. Vous devez également spécifier le nom que vous voulez donner au groupe de correctifs comme valeur de la balise. Vous pouvez spécifier n'importe quelle valeur de balise, mais la clé de balise doit être `Patch Group` ou `PatchGroup`.
`PatchGroup` (sans espace) est nécessaire si vous avez [autorisé les balises dans les métadonnées d'instance EC2.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS).
Après avoir regroupé vos nœuds gérés à l'aide de balises, vous devez ajouter la valeur du groupe de correctifs à un référentiel de correctifs. En enregistrant le groupe de correctifs auprès d'un référentiel de correctifs, vous veillez à ce que les correctifs appropriés soient installés lors de l'opération d'application des correctifs. Pour de plus amples informations sur les groupes de correctifs, consultez [Groupes de correctifs](patch-manager-patch-groups.md).
Effectuez les tâches de cette rubrique pour préparer vos nœuds gérés à l'application de correctifs à l'aide de balises avec vos nœuds et votre référentiel de correctifs. La tâche 1 n'est requise que si vous corrigez des instances Amazon EC2. La tâche 2 est requise uniquement si vous corrigez des instances non-EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). La tâche 3 est requise pour tous les nœuds gérés.
**Astuce**
Vous pouvez également ajouter des balises aux nœuds gérés à l'aide de la AWS CLI commande `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` ou de l'opération ssm-agent-minimum-s `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` 3-permissions-required de l'API Systems Manager.
**Topics**
+ [Tâche 1 : Ajout d'instances EC2 à un groupe de correctifs à l'aide de balises](#sysman-patch-group-tagging-ec2)
+ [Tâche 2 : Ajout de nœuds gérés à un groupe de correctifs à l'aide de balises](#sysman-patch-group-tagging-managed)
+ [Tâche 3 : Ajout d'un groupe de correctifs à un référentiel de correctifs](#sysman-patch-group-patchbaseline)
## Tâche 1 : Ajout d'instances EC2 à un groupe de correctifs à l'aide de balises
Vous pouvez ajouter des balises aux instances EC2 à l'aide de la console Systems Manager ou de la console Amazon EC2. Cette tâche n'est requise que si vous corrigez des instances Amazon EC2.
**Important**
Vous ne pouvez pas appliquer la `Patch Group` balise (avec un espace) à une instance Amazon EC2 si l'option ** Autoriser les balises dans les métadonnées d'instance ** est activée sur celle-ci. L'autorisation des identifications dans les métadonnées d'instance empêche les noms de clés d'identification de contenir des espaces. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), vous devez utiliser la clé de la balise `PatchGroup` (sans espace).
**Option 1 : pour ajouter des instances EC2 à un groupe de correctifs (console Systems Manager)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Fleet Manager**.
1. Dans la liste **Nœuds gérés**, sélectionnez l'ID d'une instance EC2 gérée que vous souhaitez configurer pour l'application de correctifs. Les ID de nœud pour les instances EC2 commencent par `i-`.
**Note**
Lorsque vous utilisez la console Amazon EC2 AWS CLI, il est possible d'appliquer des `Key = PatchGroup` balises à `Key = Patch Group` des instances qui ne sont pas encore configurées pour être utilisées avec Systems Manager.
Si, contrairement à vos attentes, un nœud géré ne figure pas dans la liste, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) pour obtenir des conseils de dépannage.
1. Choisissez l'onglet **Balises**, puis **Modifier**.
1. Dans la colonne de gauche, saisissez **Patch Group** ou **PatchGroup**. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), il est impératif d'utiliser `PatchGroup` (sans espace).
1. Dans la colonne de droite, saisissez une valeur de balise qui servira de nom au groupe de correctifs.
1. Choisissez **Enregistrer**.
1. Répétez cette procédure pour ajouter d'autres instances EC2 au même groupe de correctifs.
**Option 2 : pour ajouter des instances EC2 à un groupe de correctifs (console Amazon EC2)**
1. Ouvrez la [console Amazon EC2](https://console.aws.amazon.com/ec2/), puis sélectionnez **Instances** dans le panneau de navigation.
1. Dans la liste d'instances, sélectionnez une instance que vous souhaitez configurer pour l'application de correctifs.
1. Dans le menu **Actions**, sélectionnez **Paramètres de l'instance**, **Gérer les balises**.
1. Sélectionnez **Ajouter une nouvelle balise**.
1. Pour **Key** (Clé), saisissez **Patch Group** ou **PatchGroup**. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), il est impératif d'utiliser `PatchGroup` (sans espace).
1. Pour **Valeur**, entrez une valeur qui servira de nom au groupe de correctifs.
1. Sélectionnez **Enregistrer**.
1. Répétez cette procédure pour ajouter d'autres instances au même groupe de correctifs.
## Tâche 2 : Ajout de nœuds gérés à un groupe de correctifs à l'aide de balises
Suivez les étapes décrites dans cette rubrique pour ajouter des balises aux appareils AWS IoT Greengrass principaux et aux nœuds gérés non activés par un système hybride EC2 (mi-\$1). Cette tâche n'est requise que si vous corrigez des instances non-EC2 dans un environnement hybride et multicloud.
**Note**
Vous ne pouvez pas ajouter de balises sur des nœuds gérés non EC2 via la console Amazon EC2.
**Pour ajouter des nœuds gérés non EC2 à un groupe de correctifs (console Systems Manager)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Fleet Manager**.
1. Dans la liste **Nœuds gérés**, sélectionnez le nom du nœud géré que vous souhaitez configurer pour l'application de correctifs.
**Note**
Si, contrairement à vos attentes, un nœud géré ne figure pas dans la liste, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) pour obtenir des conseils de dépannage.
1. Choisissez l'onglet **Balises**, puis **Modifier**.
1. Dans la colonne de gauche, saisissez **Patch Group** ou **PatchGroup**. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), il est impératif d'utiliser `PatchGroup` (sans espace).
1. Dans la colonne de droite, saisissez une valeur de balise qui servira de nom au groupe de correctifs.
1. Sélectionnez **Enregistrer**.
1. Répétez cette procédure pour ajouter d'autres nœuds gérés dans le même groupe de correctifs.
## Tâche 3 : Ajout d'un groupe de correctifs à un référentiel de correctifs
Pour associer un référentiel de correctifs spécifique à vos nœuds gérés, vous devez ajouter la valeur du groupe de correctifs à ce référentiel. En enregistrant le groupe de correctifs auprès d'un référentiel de correctifs, vous veillez à ce que les correctifs appropriés soient installés lors de l'exécution de l'application des correctifs. Cette tâche est requise, que vous corrigiez des instances EC2, des nœuds gérés non EC2 ou les deux.
Pour de plus amples informations sur les groupes de correctifs, consultez [Groupes de correctifs](patch-manager-patch-groups.md).
**Note**
Les étapes à suivre varient selon si vous avez accédé pour la première fois à Patch Manager avant ou après la publication des [stratégies de correctifs](patch-manager-policies.md) le 22 décembre 2022.
**Pour ajouter un groupe de correctifs à un référentiel de correctifs (console Systems Manager)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Si vous accédez à Patch Manager pour la première fois dans l' Région AWS actuelle et que la page de démarrage de Patch Manager s'ouvre, choisissez **Commencer par une présentation**.
1. Sélectionnez l'onglet **Référentiel de correctifs**, puis dans la liste **Référentiel de correctifs**, sélectionnez le nom du référentiel de correctifs que vous souhaitez configurer pour votre groupe de correctifs.
Si vous n'avez accédé pour la première fois à Patch Manager qu'après la publication des stratégies de correctifs, vous devez choisir un référentiel personnalisé que vous avez créé.
1. Si la page de détails **ID de référence** comprend un menu **Actions** procédez comme suit :
+ Sélectionnez **Actions**, puis **Modifier les groupes de correctifs**.
+ Saisissez la *valeur* de balise que vous avez ajoutée à vos nœuds gérés dans [Tâche 2 : Ajout de nœuds gérés à un groupe de correctifs à l'aide de balises](#sysman-patch-group-tagging-managed), puis sélectionnez **Ajouter**.
Si la page de détails **ID de référence** ne comporte *pas* un menu **Actions** les groupes de correctifs ne peuvent pas être configurés dans la console. Au lieu de cela, vous pouvez effectuer l'une des actions suivantes :
+ (Recommandé) Configurez une politique de correctifs dans Quick Setup, un outil d’ AWS Systems Manager, pour mapper un référentiel de correctifs à une ou plusieurs instances EC2.
Pour en savoir plus, consultez les rubriques [Utilisation des politiques de correctifs de Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) et [Automatiser les correctifs à l'échelle de l'organisation à l'aide d'une politique de correctifs de Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
+ Utilisez la [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)commande du AWS Command Line Interface (AWS CLI) pour configurer un groupe de correctifs.
# Intégration Patch Manager avec AWS Security Hub CSPM
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)vous fournit une vue complète de votre état de sécurité dans AWS. Security Hub CSPM collecte des données de sécurité provenant de l'ensemble Comptes AWS des produits partenaires et pris en charge par des tiers. Services AWS Avec Security Hub CSPM, vous pouvez vérifier que votre environnement est conforme aux normes du secteur de la sécurité et aux meilleures pratiques. Security Hub CSPM vous aide à analyser vos tendances en matière de sécurité et à identifier les problèmes de sécurité les plus prioritaires.
En utilisant l'intégration entre Patch Manager Security Hub CSPM et un outil intégré à AWS Systems Manager Security Hub, vous pouvez envoyer des informations concernant des nœuds non conformes à Security Patch Manager Hub CSPM. Vous pouvez observer parmi les résultats l'enregistrement d'une vérification de sécurité ou d'une détection liée à la sécurité. Security Hub CSPM peut ensuite inclure les résultats relatifs aux correctifs dans son analyse de votre posture de sécurité.
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
**Contents**
+ [Comment Patch Manager envoie des résultats à Security Hub CSPM](#securityhub-integration-sending-findings)
+ [Types de résultats que Patch Manager envoie](#securityhub-integration-finding-types)
+ [Latence pour l'envoi des résultats](#securityhub-integration-finding-latency)
+ [Réessayer lorsque Security Hub CSPM n’est pas disponible](#securityhub-integration-retry-send)
+ [Afficher les résultats dans Security Hub CSPM](#securityhub-integration-view-findings)
+ [Résultats types de Patch Manager](#securityhub-integration-finding-example)
+ [Activation et configuration de l'intégration](#securityhub-integration-enable)
+ [Comment arrêter l'envoi des résultats](#securityhub-integration-disable)
## Comment Patch Manager envoie des résultats à Security Hub CSPM
Dans Security Hub CSPM, les problèmes de sécurité sont suivis en tant que findings (résultats). Certains résultats proviennent de problèmes détectés par d'autres partenaires Services AWS ou par des partenaires tiers. Security Hub CSPM dispose également d'un ensemble de règles qu'il utilise pour détecter les problèmes de sécurité et générer des résultats.
Patch Managerest l'un des outils de Systems Manager qui envoie les résultats au Security Hub CSPM. Après avoir effectué une opération de correction en exécutant un document SSM (`AWS-RunPatchBaseline`,, ou`AWS-RunPatchBaselineWithHooks`)`AWS-RunPatchBaselineAssociation`, les informations d'application des correctifs sont envoyées à Inventory ou Compliance, aux outils, ou aux deux AWS Systems Manager. Après qu'Inventory, Compliance, ou les deux, ont reçu les données, Patch Manager reçoit une notification. Ensuite, Patch Manager évalue l'exactitude, le formatage et la conformité des données. Si toutes les conditions sont remplies, Patch Manager transmet les données à Security Hub CSPM.
Security Hub CSPM fournit des outils permettant de gérer les résultats provenant de toutes ces sources. Vous pouvez afficher et filtrer les listes de résultats et afficher les informations sur un résultat. Pour de plus amples informations, consultez la section [Viewing findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) (Affichage des résultats) dans le *Guide de l'utilisateur AWS Security Hub *. Vous pouvez également suivre le statut d'une analyse dans un résultat. Pour de plus amples informations, veuillez consulter [Prendre des mesure en fonction des résultats](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) dans le *Guide de l'utilisateur AWS Security Hub *.
Tous les résultats du Security Hub CSPM utilisent un format JSON standard appelé AWS Security Finding Format (ASFF). Le format ASFF comprend des informations sur la source du problème, les ressources affectées et le statut actuel du résultat. Pour de plus amples informations, veuillez consulter [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) dans le *Guide de l'utilisateur AWS Security Hub *.
### Types de résultats que Patch Manager envoie
Patch Managerenvoie les résultats à Security Hub CSPM en utilisant le format [ASFF (AWS Security Finding Format)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). Dans le format ASFF, le champ `Types` fournit le type de résultat. Les résultats de Patch Manager peuvent avoir la valeur suivante pour `Types` :
+ Checks/Patch Gestion des logiciels et des configurations
Patch Manager envoie un résultat par nœud géré non conforme. La découverte est signalée avec le type de ressource [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)afin que les résultats puissent être corrélés avec d'autres intégrations Security Hub CSPM qui signalent des types de ressources. `AwsEc2Instance` Patch Managerne transmet une constatation à Security Hub CSPM que si l'opération a découvert que le nœud géré n'était pas conforme. Le résultat contient les résultats du Résumé des correctifs.
**Note**
Après avoir signalé un nœud non conforme à Security Hub CSPM. Patch Managern'envoie pas de mise à jour au Security Hub CSPM une fois que le nœud est devenu conforme. Vous pouvez résoudre manuellement les résultats dans Security Hub CSPM une fois que les correctifs requis ont été appliqués au nœud géré.
Pour plus d'informations sur les définitions de conformité, consultez [Valeurs de l’état de conformité des correctifs](patch-manager-compliance-states.md). Pour plus d'informations à ce sujet`PatchSummary`, consultez [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)la *référence de AWS Security Hub l'API*.
### Latence pour l'envoi des résultats
Lors de Patch Manager la création d'un nouveau résultat, il est généralement envoyé au Security Hub CSPM dans un délai de quelques secondes à 2 heures. La vitesse dépend du trafic en cours de traitement dans la Région AWS à ce moment-là.
### Réessayer lorsque Security Hub CSPM n’est pas disponible
En cas de panne de service, une AWS Lambda fonction est exécutée pour remettre les messages dans la file d'attente principale après la réexécution du service. Une fois les messages dans la file d'attente principale, la nouvelle tentative est automatique.
Si Security Hub CSPM n'est pas disponible, Patch Manager réessaie d'envoyer les résultats jusqu'à ce qu'ils soient reçus.
### Afficher les résultats dans Security Hub CSPM
Cette procédure explique comment consulter dans Security Hub CSPM les résultats concernant les nœuds gérés de votre parc qui ne sont pas conformes aux correctifs.
**Pour consulter les résultats du Security Hub CSPM relatifs à la conformité des correctifs**
1. Connectez-vous à la AWS Security Hub CSPM console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/).
1. Dans le volet de navigation, choisissez **Conclusions**.
1. Choisissez la case **Ajouter des filtres** (![\[The Search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)).
1. Dans le menu, sous **Filtres**, choisissez **Nom du produit**.
1. Dans la boîte de dialogue qui s'ouvre, sélectionnez **est** dans le premier champ, puis saisissez **Systems Manager Patch Manager** dans le deuxième champ.
1. Cliquez sur **Appliquer**.
1. Ajoutez les filtres supplémentaires que vous souhaitez pour affiner vos résultats.
1. Dans la liste des résultats, choisissez le titre d'un résultat sur lequel vous souhaitez obtenir plus d'informations.
Un volet s'ouvre sur le côté droit de l'écran. Il contient plus de détails sur la ressource, le problème découvert et les solutions recommandées.
**Important**
À l'heure actuelle, Security Hub CSPM indique le type de ressource de tous les nœuds gérés sous la forme. `EC2 Instance` Cela inclut les serveurs locaux et les machines virtuelles (VMs) que vous avez enregistrés pour être utilisés avec Systems Manager.
**Classifications de sévérité**
La liste des résultats de **Systems Manager Patch Manager** comprend un rapport sur la sévérité du résultat. Les niveaux de **sévérité** sont les suivants, du plus faible au plus élevé :
+ **INFORMATIF** : aucun problème n'a été détecté.
+ **FAIBLE** : le problème ne nécessite aucune correction.
+ **MOYEN** : le problème doit être traité, mais n'est pas urgent.
+ **ÉLEVÉ** : le problème doit être traité en priorité.
+ **CRITIQUE** : le problème doit être résolu immédiatement pour éviter qu'il ne s'aggrave.
La sévérité est déterminée par le package non conforme le plus sévère d'une instance. Comme vous pouvez disposer de plusieurs référentiels de correctifs avec différents niveaux de sévérité, le niveau de sévérité le plus élevé est indiqué parmi tous les packages non conformes. Supposons, par exemple, que vous ayez deux packages non conformes. Le niveau de sévérité du package A est « critique » et celui du package B est « faible ». La sévérité sera signalée comme étant « critique ».
Veuillez noter que le champ de sévérité est directement corrélé au champ `Compliance` de Patch Manager. Il s'agit d'un champ que vous attribuez aux correctifs individuels qui correspondent à la règle. Ce champ `Compliance` étant affecté à des correctifs individuels, il n'est pas reflété au niveau du résumé des correctifs.
**Contenu connexe**
+ [Résultats](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) du *Guide de l'utilisateur AWS Security Hub *
+ [Conformité aux correctifs multicomptes avec Patch Manager et Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) sur le *Blog AWS de gestion et gouvernance* (en anglais)
## Résultats types de Patch Manager
Patch Managerenvoie les résultats au Security Hub CSPM en utilisant le format [ASFF (AWS Security Finding Format)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).
Voici un exemple de résultat type de Patch Manager.
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## Activation et configuration de l'intégration
Pour utiliser l'Patch Managerintégration avec Security Hub CSPM, vous devez activer Security Hub CSPM. *Pour plus d'informations sur la façon d'activer Security Hub CSPM, consultez la section [Configuration de Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) dans le guide de l'utilisateur.AWS Security Hub *
La procédure suivante décrit comment intégrer Patch Manager Security Hub CSPM lorsque Security Hub CSPM est déjà actif mais que Patch Manager l'intégration est désactivée. Cette procédure doit être effectuée uniquement si l'intégration a été désactivée manuellement.
**À ajouter Patch Manager à l'intégration de Security Hub CSPM**
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Sélectionnez l’onglet **Paramètres**.
-ou-
Si vous accédez à Patch Manager pour la première fois dans la Région AWS actuelle, choisissez **Commencer par une présentation**, puis sélectionnez l'onglet **Paramètres**.
1. **Dans la section **Exporter vers Security Hub CSPM**, à droite de « Les **résultats de conformité des correctifs ne sont pas exportés vers Security Hub** », choisissez Enable.**
## Comment arrêter l'envoi des résultats
Pour arrêter l’envoi des résultats à Security Hub CSPM, vous pouvez utiliser la console Security Hub CSPM ou l’API.
Pour plus d'informations, consultez les rubriques suivantes dans le *AWS Security Hub Guide de l'utilisateur* :
+ [Désactivation et activation du flux de résultats d'une intégration (console)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Désactivation du flux de résultats d'une intégration (API Security Hub CSPM,) AWS CLI](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# Travailler avec des ressources Patch Manager à l’aide de l’AWS CLI
La section inclut des exemples de commandes AWS Command Line Interface (AWS CLI) que vous pouvez utiliser pour effectuer des tâches de configuration pour Patch Manager un outil dans AWS Systems Manager.
Pour une illustration de l'utilisation du correctif pour appliquer des correctifs AWS CLI à un environnement de serveur à l'aide d'une ligne de base de correctifs personnalisée, consultez[Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
Pour plus d'informations sur l'utilisation AWS Systems Manager des tâches AWS CLI for, consultez la [AWS Systems Manager section du manuel de référence des AWS CLI commandes](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).
**Topics**
+ [AWS CLI commandes pour les lignes de base des correctifs](#patch-baseline-cli-commands)
+ [AWS CLI commandes pour les groupes de correctifs](#patch-group-cli-commands)
+ [AWS CLI commandes pour afficher les résumés et les détails des correctifs](#patch-details-cli-commands)
+ [AWS CLI commandes pour scanner et appliquer des correctifs aux nœuds gérés](#patch-operations-cli-commands)
## AWS CLI commandes pour les lignes de base des correctifs
**Topics**
+ [Créer un référentiel de correctifs](#patch-manager-cli-commands-create-patch-baseline)
+ [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-create-patch-baseline-mult-sources)
+ [Mettre à jour un référentiel de correctifs](#patch-manager-cli-commands-update-patch-baseline)
+ [Renommer un référentiel de correctifs](#patch-manager-cli-commands-rename-patch-baseline)
+ [Supprimer un référentiel de correctifs](#patch-manager-cli-commands-delete-patch-baseline)
+ [Afficher toutes les références de correctifs](#patch-manager-cli-commands-describe-patch-baselines)
+ [Répertorier toutes les AWS lignes de base de correctifs fournies](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Répertorier mes références de correctifs](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Afficher un référentiel de correctifs](#patch-manager-cli-commands-get-patch-baseline)
+ [Obtenir le référentiel de correctifs par défaut](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Définir un référentiel de correctifs personnalisée comme valeur par défaut](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Réinitialisation d'une ligne de base de AWS correctifs par défaut](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Baliser un référentiel de correctifs](#patch-manager-cli-commands-add-tags-to-resource)
+ [Répertorier les balises d'un référentiel de correctifs](#patch-manager-cli-commands-list-tags-for-resource)
+ [Supprimer une balise d'un référentiel de correctifs](#patch-manager-cli-commands-remove-tags-from-resource)
### Créer un référentiel de correctifs
La commande suivante crée un référentiel de correctifs approuvant toutes les mises à jour de sécurité critiques et importantes pour Windows Server 2012 R2 cinq jours après leur publication. Des correctifs ont également été spécifiés pour les listes de correctifs approuvés et rejetés. En outre, le référentiel de correctifs a été balisée pour indiquer qu'elle est destinée à un environnement de production.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 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
S'applique uniquement aux nœuds gérés Linux. La commande suivante montre comment spécifier le référentiel de correctifs à utiliser pour une version spécifique du système d'exploitation Amazon Linux. Cet exemple utilise un référentiel source autorisé par défaut sur Amazon Linux 2017.09, mais peut être adapté à un autre référentiel source configuré pour un nœud géré.
**Note**
Pour mieux illustrer cette commande plus complexe, nous utilisons l'option `--cli-input-json` avec des options supplémentaires stockées dans un fichier JSON externe.
1. Créez un fichier JSON avec un nom tel que `my-patch-repository.json` et ajoutez-lui le contenu suivant.
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. Dans le répertoire où vous avez enregistré le fichier, exécutez la commande suivante.
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Mettre à jour un référentiel de correctifs
La commande suivante ajoute deux correctifs comme refusés et un correctif comme approuvé à un référentiel de correctifs existante.
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).
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Renommer un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Supprimer un référentiel de correctifs
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Afficher toutes les références de correctifs
```
aws ssm describe-patch-baselines
```
Le système retourne des informations telles que les suivantes.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
Voici une autre commande qui répertorie toutes les référentiels de correctifs dans une Région AWS.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Répertorier toutes les AWS lignes de base de correctifs fournies
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### Répertorier mes références de correctifs
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Afficher un référentiel de correctifs
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**Note**
Pour les référentiels de correctifs personnalisés, vous pouvez spécifier l'ID de référentiel de correctifs ou l'Amazon Resource Name (ARN) complet. Pour une ligne de base de correctif AWS fournie, vous devez spécifier l'ARN complet. Par exemple, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Obtenir le référentiel de correctifs par défaut
```
aws ssm get-default-patch-baseline --region us-east-2
```
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Définir un référentiel de correctifs personnalisée comme valeur par défaut
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Réinitialisation d'une ligne de base de AWS correctifs par défaut
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Baliser un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### Répertorier les balises d'un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### Supprimer une balise d'un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## AWS CLI commandes pour les groupes de correctifs
**Topics**
+ [Créer un groupe de correctifs](#patch-manager-cli-commands-create-patch-group)
+ [Enregistrer un groupe de correctifs « Serveurs web » avec un référentiel de correctifs](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Enregistrez un groupe de correctifs « Backend » avec la ligne de base de correctifs AWS fournie](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Afficher les enregistrements du groupe de correctifs](#patch-manager-cli-commands-describe-patch-groups)
+ [Annuler l'enregistrement d'un groupe de correctifs à partir d'un référentiel de correctifs](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### Créer un groupe de correctifs
**Note**
Les groupes de correctifs ne sont pas utilisés dans les opérations d'application de correctifs basées sur des *politiques de correctifs*. Pour obtenir des informations sur l'utilisation des politiques de correctifs, consultez la rubrique [Configurations de la politique de correctifs dans Quick Setup](patch-manager-policies.md).
Pour faciliter l'organisation des opérations d'application de correctifs, nous vous recommandons d'ajouter des nœuds gérés à des groupes de correctifs à l'aide de balises. Les groupes de correctifs nécessitent l'utilisation de la clé de balise `Patch Group` ou `PatchGroup`. Si vous avez [autorisé les balises dans les métadonnées des instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), vous devez utiliser `PatchGroup` (sans espace). Toutefois, peu importe le choix de la valeur d'une balise, la clé de balise doit être `Patch Group` ou `PatchGroup`. Pour de plus amples informations sur les groupes de correctifs, consultez [Groupes de correctifs](patch-manager-patch-groups.md).
Après avoir regroupé vos nœuds gérés à l'aide de balises, vous devez ajouter la valeur du groupe de correctifs à un référentiel de correctifs. En enregistrant le groupe de correctifs auprès d'un référentiel de correctifs, vous veillez à ce que les correctifs appropriés soient installés lors de l'opération d'application des correctifs.
#### Tâche 1 : Ajout d'instances EC2 à un groupe de correctifs à l'aide de balises
**Note**
Lorsque vous utilisez la console Amazon Elastic Compute Cloud (Amazon EC2), il est possible AWS CLI d'`Key = Patch Group`appliquer `Key = PatchGroup` ou de baliser des instances qui ne sont pas encore configurées pour être utilisées avec Systems Manager. Si une instance EC2 que vous prévoyez de voir dans Patch Manager n'est pas répertoriée après l'application de `Patch Group` ou `Key = PatchGroup` balise, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md) afin d'obtenir des conseils de dépannage.
Exécutez la commande suivante pour ajouter la balise `PatchGroup` à une instance EC2.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### Tâche 2 : Ajout de nœuds gérés à un groupe de correctifs à l'aide de balises
Exécutez la commande suivante pour ajouter la balise `PatchGroup` à un nœud géré.
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### Tâche 3 : Ajout d'un groupe de correctifs à un référentiel de correctifs
Exécutez la commande suivante pour associer une valeur de balise `PatchGroup` au référentiel de correctifs spécifiée.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Enregistrer un groupe de correctifs « Serveurs web » avec un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Enregistrez un groupe de correctifs « Backend » avec la ligne de base de correctifs AWS fournie
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Afficher les enregistrements du groupe de correctifs
```
aws ssm describe-patch-groups --region us-east-2
```
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### Annuler l'enregistrement d'un groupe de correctifs à partir d'un référentiel de correctifs
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLI commandes pour afficher les résumés et les détails des correctifs
**Topics**
+ [Obtenir tous les correctifs définis par un référentiel de correctifs](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Obtenez tous les correctifs pour AmazonLinux 2018.03 dont la classification `SECURITY` et le niveau de gravité sont `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Obtenir tous les correctifs pour Windows Server 2012 dont la sévérité MSRC est `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Obtenir tous les correctifs disponibles](#patch-manager-cli-commands-describe-available-patches)
+ [Obtenir le résumé de l'état des correctifs par nœud géré](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Obtenir les informations de conformité des correctifs pour un nœud géré](#patch-manager-cli-commands-describe-instance-patches)
+ [Afficher les résultats de conformité de l'application de correctifs (AWS CLI)](#viewing-patch-compliance-results-cli)
### Obtenir tous les correctifs définis par un référentiel de correctifs
**Note**
Cette commande est seulement prise en charge pour les référentiels de correctifs de Windows Server.
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### Obtenez tous les correctifs pour AmazonLinux 2018.03 dont la classification `SECURITY` et le niveau de gravité sont `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### Obtenir tous les correctifs pour Windows Server 2012 dont la sévérité MSRC est `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### Obtenir tous les correctifs disponibles
```
aws ssm describe-available-patches --region us-east-2
```
Le système retourne des informations telles que les suivantes.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### Obtenir le résumé de l'état des correctifs par nœud géré
Le résumé par nœud géré indique le nombre de correctifs dans les états suivants par nœud : « », NotApplicable « Manquant », « Échec », « » et InstalledOther « Installé ».
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
Le système retourne des informations telles que les suivantes.
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### Obtenir les informations de conformité des correctifs pour un nœud géré
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
Le système retourne des informations telles que les suivantes.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### Afficher les résultats de conformité de l'application de correctifs (AWS CLI)
**Pour afficher les résultats de conformité des correctifs pour un nœud géré individuel**
Exécutez la commande suivante dans le AWS Command Line Interface (AWS CLI) pour afficher les résultats de conformité des correctifs pour un seul nœud géré.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
Remplacez *instance-id* par l'ID du nœud géré pour lequel vous souhaitez afficher les résultats, au format `i-02573cafcfEXAMPLE` ou`mi-0282f7c436EXAMPLE`.
Les systèmes renvoient des informations telles que les suivantes.
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**Pour afficher un résumé du nombre de correctifs pour toutes les instances EC2 dans une région**
La commande `describe-instance-patch-states` prend en charge la récupération des résultats pour une seule instance gérée à la fois. Cependant, l'utilisation d'un script personnalisé avec la commande `describe-instance-patch-states` vous permet de générer un rapport plus granulaire.
Par exemple, si l'[outil de filtrage jq](https://stedolan.github.io/jq/download/) est installé sur votre machine locale, vous pouvez exécuter la commande suivante pour identifier celle de vos instances EC2 qui a un statut de `InstalledPendingReboot` dans une Région AWS particulière.
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*region*représente l'identifiant d'une région Région AWS prise en charge par AWS Systems Manager, par exemple `us-east-2` pour la région USA Est (Ohio). Pour obtenir la liste des *region* valeurs prises en charge, consultez la colonne **Région** dans les [points de terminaison du service Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) dans le *Référence générale d'Amazon Web Services*.
Par exemple :
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
Le système retourne des informations telles que les suivantes.
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
Outre `InstalledPendingRebootCount`, la liste des types de nombres interrogeables comprend les éléments suivants :
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## AWS CLI commandes pour scanner et appliquer des correctifs aux nœuds gérés
Après avoir exécuté les commandes suivantes pour analyser la conformité des correctifs ou installer des correctifs, vous pouvez utiliser les commandes de la section [AWS CLI commandes pour afficher les résumés et les détails des correctifs](#patch-details-cli-commands) pour afficher des informations sur le statut et la conformité des correctifs.
**Topics**
+ [Analyser les nœuds gérés pour vérifier la conformité des correctifs (AWS CLI)](#patch-operations-scan)
+ [Installer des correctifs sur les nœuds gérés (AWS CLI)](#patch-operations-install-cli)
### Analyser les nœuds gérés pour vérifier la conformité des correctifs (AWS CLI)
**Pour analyser les nœuds gérés afin de vérifier la conformité des correctifs**
Exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Pour analyser les nœuds gérés et vérifier la conformité des correctifs par balise de groupe de correctifs**
Exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### Installer des correctifs sur les nœuds gérés (AWS CLI)
**Pour installer des correctifs sur des nœuds gérés spécifiques**
Exécutez la commande suivante.
**Note**
Si nécessaire, les nœuds gérés cibles redémarrent pour finaliser l'installation des correctifs. Pour de plus amples informations, veuillez consulter [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Pour installer des correctifs sur des nœuds gérés appartenant à un groupe de correctifs spécifique**
Exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# Tutoriels AWS Systems Manager Patch Manager
Les didacticiels de cette section montrent comment utiliser Patch Manager un outil dans AWS Systems Manager plusieurs scénarios d'application de correctifs.
**Topics**
+ [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutoriel : mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l’état spécifique à l’application en utilisant la console](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement
Patch Managerprend en charge l'application de correctifs aux nœuds dans les environnements qui en ont IPv6 uniquement. En mettant à jour la SSM Agent configuration, les opérations de correction peuvent être configurées pour effectuer des appels uniquement aux points de terminaison IPv6 du service.
**Pour appliquer un correctif à un serveur dans un environnement IPv6 uniquement**
1. Assurez-vous que SSM Agent la version 3.3270.0 ou ultérieure est installée sur le nœud géré.
1. Sur le nœud géré, accédez au fichier SSM Agent de configuration. Le `amazon-ssm-agent.json` fichier se trouve dans les répertoires suivants :
+ Linux : `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
S'il `amazon-ssm-agent.json` n'existe pas encore, copiez le contenu de `amazon-ssm-agent.json.template` dans le même répertoire dans`amazon-ssm-agent.json`.
1. Mettez à jour l'entrée suivante pour définir la bonne région et définissez-la `UseDualStackEndpoint` sur `true` :
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Redémarrez le SSM Agent service à l'aide de la commande adaptée à votre système d'exploitation :
+ Linux : `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Serverà l'aide de Snap : `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` suivi par `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` suivi par `Start-Service AmazonSSMAgent`
Pour obtenir la liste complète des commandes par système d'exploitation, consultez[Vérification du statut de l'SSM Agent et démarrage de l'agent](ssm-agent-status-and-restart.md).
1. Exécutez n'importe quelle opération de correction pour vérifier que les opérations de correction réussissent dans votre environnement réservé à votre environnement IPv6. Assurez-vous que les nœuds auxquels le correctif est appliqué sont connectés à la source du correctif. Vous pouvez vérifier le Run Command résultat de l'exécution du correctif pour vérifier la présence d'avertissements concernant des référentiels inaccessibles. Lorsque vous appliquez des correctifs à un nœud qui s'exécute dans un environnement IPv6 réservé, assurez-vous que le nœud est connecté à la source du correctif. Vous pouvez vérifier le Run Command résultat de l'exécution du correctif pour vérifier la présence d'avertissements concernant des référentiels inaccessibles. Pour les systèmes d'exploitation basés sur DNF, il est possible de configurer les référentiels indisponibles pour qu'ils soient ignorés lors de l'application des correctifs si l'`skip_if_unavailable`option est définie sur moins. `True` `/etc/dnf/dnf.conf` Les systèmes d'exploitation basés sur DNF incluent Amazon Linux 2023, les versions Red Hat Enterprise Linux 8 et ultérieures, les versions Oracle Linux 8 et ultérieures Rocky Linux AlmaLinux, et CentOS 8 et les versions ultérieures. Sur Amazon Linux 2023, l'`skip_if_unavailable`option est définie sur `True` par défaut.
**Note**
Lorsque vous utilisez les fonctionnalités Install Override List ou Baseline Override, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie.
# Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console
Lorsque vous créez un référentiel de correctifs personnalisée, vous pouvez spécifier que tous, certains ou un seul type de correctif pris en charge sont installés.
Dans les références de correctifs pour Windows, vous pouvez sélectionner `ServicePacks` comme seule option de **Classification** afin de limiter les mises à jour des correctifs aux Service Packs uniquement. Les Service Packs peuvent être installés automatiquement à l'aide d'un outil AWS Systems Manager, à condition que la mise à jour soit disponible dans Windows Update ou Windows Server Update Services (WSUS). Patch Manager
Vous pouvez configurer un référentiel de correctifs pour contrôler si les Service Packs pour toutes les versions de Windows sont installés, ou uniquement ceux pour des versions spécifiques, comme Windows 7 ou Windows Server 2016.
Suivez la procédure ci-dessous afin de créer un référentiel de correctifs personnalisé à utiliser exclusivement pour installer tous les Service Packs sur vos nœuds gérés Windows.
**Créer un référentiel de correctifs pour l'installation des Service Packs Windows (console)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
1. Pour **Nom**, entrez un nom pour votre nouvelle référentiel de correctifs, par exemple : `MyWindowsServicePackPatchBaseline`.
1. (Facultatif) Pour **Description**, saisissez une description pour cette référence de correctif.
1. Pour **Système d'exploitation**, sélectionnez `Windows`.
1. Si vous souhaitez commencer à utiliser cette référence de correctif comme valeur par défaut pour Windows dès sa création, sélectionnez **Définir cette référence de correctif comme référence par défaut pour les instances Windows Server**.
**Note**
Cette option n'est disponible que si vous avez accédé à Patch Manager pour la première fois avant la publication des [politiques de correctifs](patch-manager-policies.md) le 22 décembre 2022.
Pour de plus amples informations, sur la définition d'un référentiel de correctifs existante en tant que référence par défaut, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation pour les systèmes d'exploitation)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
+ **Produits** : versions des systèmes d'exploitation auxquelles s'applique la règle d'approbation, par exemple `WindowsServer2012`. Vous pouvez choisir une, plusieurs ou toutes les versions prises en charge de Windows. La sélection par défaut est `All`.
+ **Classification** : sélectionnez `ServicePacks`.
+ **Importance** : valeur d'importance des correctifs à laquelle la règle va s'appliquer. Pour vous assurer que tous les Service Packs sont inclus dans la règle, sélectionnez `All`.
+ **Approbation automatique** : méthode de sélection des patchs pour approbation automatique.
+ **Approuver les correctifs après un nombre de jours spécifié** : pendant lesquels Patch Manager doit attendre après la publication ou la mise à jour d'un correctif avant son approbation automatique. Vous pouvez entrer tout nombre entier situé entre zéro (0) et 360. Nous vous recommandons, en règle générale, de ne pas attendre plus de 100 jours.
+ **L'approbation des correctifs publiés jusqu'à une date spécifique**: date de publication des correctifs pour laquelle Patch Manager applique automatiquement tous les correctifs publiés à cette date ou avant cette date. Par exemple, si vous spécifiez le 7 juillet 2023, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
+ (Facultatif) **Rapport de conformité** : niveau d'importance que vous voulez affecter aux Service Packs approuvés par la référence, par exemple `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un Service Pack approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
1. (Facultatif) Pour **Gérer les balises**, appliquez une ou plusieurs name/value paires de clés de balise à la ligne de base du correctif.
Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Pour ce référentiel de correctifs dédiée à la mise à jour des Service Packs, vous pouvez spécifier des paires clé-valeur telles que les suivantes :
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Sélectionnez **Créer un référentiel de correctif**.
# Tutoriel : mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l’état spécifique à l’application en utilisant la console
Dans bien des cas, un nœud géré doit être redémarré après l'installation de la dernière mise à jour logicielle. Toutefois, le redémarrage d'un nœud en production sans mesures de protection peut occasionner différents problèmes, comme le déclenchement d'alarmes, l'enregistrement de données métriques incorrectes et l'interruption des synchronisations de données.
Ce didacticiel illustre la façon d'éviter les problèmes de ce genre en utilisant le document AWS Systems Manager (document SSM) `AWS-RunPatchBaselineWithHooks` pour réaliser une opération complexe d'application de correctifs en plusieurs étapes qui effectue les opérations suivantes :
1. Empêcher de nouvelles connexions à l'application
1. Installer les mises à jour du système d'exploitation
1. Mettre à jour les dépendances de package de l'application
1. Redémarrer le système
1. Effectuer une surveillance de l'état spécifique à l'application
Pour cet exemple, nous avons configuré notre infrastructure de la façon suivante :
+ Les machines virtuelles ciblées sont enregistrées en tant que nœuds gérés auprès de Systems Manager.
+ `Iptables` est utilisé comme pare-feu local.
+ L'application hébergée sur les nœuds gérés s'exécute sur le port 443.
+ L'application hébergée sur les nœuds gérés est une application `nodeJS`.
+ L'application hébergée sur les nœuds gérés est gérée par le gestionnaire de processus pm2.
+ L'application dispose déjà d'un point de terminaison de surveillance de l'état spécifié.
+ Le point de terminaison de surveillance de l'état de l'application n'exige aucune authentification de l'utilisateur final. Le point de terminaison autorise une surveillance de l'état qui répond aux exigences de l'organisation en matière d'établissement de la disponibilité. (Dans vos environnements, il pourrait suffire de vérifier simplement que l'application `nodeJS` est en cours d'exécution et peut écouter les demandes. Dans d'autres cas, vous pouvez également vouloir vérifier qu'une connexion à la couche de mise en cache ou à la couche de base de données est déjà établie.)
Les exemples de ce didacticiel sont fournis à titre indicatif uniquement. Ils ne sont pas destinés à être mis en œuvre en l'état dans les environnements de production. N’oubliez pas non plus que la fonction de hooks de cycle de vie de Patch Manager, un outil de Systems Manager, avec le document `AWS-RunPatchBaselineWithHooks` peut prendre en charge de nombreux autres scénarios. Voici quelques exemples.
+ Arrêtez l'agent de génération de rapport de métriques avant d'appliquer les correctifs, et relancez-le après le redémarrage du nœud géré.
+ Détachez le nœud géré du cluster CRM ou PCS avant d'appliquer les correctifs, et attachez-le de nouveau après le redémarrage du nœud.
+ Mettez à jour les logiciels tiers (comme les applications Adobe, Java, Tomcat, etc.) sur les machines Windows Server après l'application des mises à jour du système d'exploitation, mais avant le redémarrage du nœud géré.
**Pour mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l'état spécifique à l'application**
1. Créez un document SSM avec le contenu suivant pour votre script de préinstallation et nommez-le `NodeJSAppPrePatch`. Remplacez *your\$1application* par le nom de votre application.
Ce script bloque immédiatement les nouvelles demandes entrantes et fournit aux demandes déjà actives un délai de cinq secondes avant de commencer l'opération d'application de correctifs. Pour l'option `sleep`, spécifiez un nombre de secondes supérieur à ce qu'il faut habituellement aux requêtes entrantes pour s'effectuer.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
Pour de plus amples informations sur la création de documents SSM, consultez [Création du contenu du document SSM](documents-creating-content.md).
1. Créez un autre document SSM avec le contenu suivant pour votre script postinstallation, pour mettre à jour vos dépendances d'application, et nommez-le `NodeJSAppPostPatch`. Remplacez */your/application/path* par le chemin d'accès à votre application.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Créez un autre document SSM avec le contenu suivant pour votre script `onExit`, pour rétablir votre application et effectuer une surveillance de l'état. Nommez ce document SSM `NodeJSAppOnExitPatch`. Remplacez *your\$1application* par le nom de votre application.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. Créez une association dans State Manager, un outil d’ AWS Systems Manager, pour émettre l’opération en procédant comme suit :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **State Manager**, puis **Créer une association**.
1. Pour **Nom**, fournissez un nom permettant d'identifier le but de l'association.
1. Dans la liste **Document**, sélectionnez `AWS-RunPatchBaselineWithHooks`.
1. Pour **Operation (Opération)**, sélectionnez **Install (Installer)**.
1. (Facultatif) Pour **ID d'instantané**, fournissez un GUID que vous générez pour accélérer l'opération et garantir la cohérence. La valeur du GUID peut être aussi simple que `00000000-0000-0000-0000-111122223333`.
1. Pour **Nom de document du hook de préinstallation**, saisissez `NodeJSAppPrePatch`.
1. Pour **Nom de document du hook de postinstallation**, saisissez `NodeJSAppPostPatch`.
1. Pour **On ExitHook Doc Name**, entrez`NodeJSAppOnExitPatch`.
1. Dans **Targets (Cibles)**, identifiez vos nœuds gérés en spécifiant des balises, en choisissant manuellement les nœuds, en choisissant un groupe de ressources ou en choisissant tous les nœuds gérés.
1. Pour **Spécifier le calendrier**, spécifiez la fréquence d'exécution de l'association. La fréquence d'application des correctifs sur les nœuds gérés est couramment définie sur une fois par semaine.
1. Dans la section **Rate control (Contrôle du débit)**, sélectionnez les options permettant de contrôler la façon dont l'association s'exécute sur plusieurs nœuds gérés. Assurez-vous que seule une partie des nœuds gérés est mise à jour à la fois. Autrement, la totalité ou la majeure partie de votre flotte pourrait être déconnectée en même temps. Pour de plus amples informations sur l'utilisation des contrôles de débit, consultez [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Facultatif) Dans **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, sélectionnez **Enable writing to an S3 bucket (Autoriser l'écriture dans un compartiment S3)** Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**Note**
Les autorisations S3 qui donnent la possibilité d'écrire les données dans un compartiment S3 sont celles du profil d'instance attribué au nœud géré, et non celles de l'utilisateur IAM qui effectue cette tâche. Pour plus d’informations, consultez les sections [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md) et [Créer un rôle de service IAM pour un environnement hybride](hybrid-multicloud-service-role.md). En outre, si le compartiment S3 spécifié se trouve sur un autre Compte AWS, vérifiez que le profil d'instance ou la fonction de service IAM associé au nœud géré dispose des autorisations nécessaires pour écrire dans ce compartiment.
1. Sélectionnez **Create Association (Créer une association)**.
# Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI
La procédure suivante décrit l'application de correctifs à un environnement de serveur à l'aide d'un référentiel de correctifs personnalisée, de groupes de correctifs et d'une fenêtre de maintenance.
**Avant de commencer**
+ Installez ou mettez à jour SSM Agent sur vos nœuds gérés. 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. Pour de plus amples informations, veuillez consulter [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configurez les rôles et les autorisations pourMaintenance Windows, un outil dans AWS Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de Maintenance Windows](setting-up-maintenance-windows.md).
+ Installez et configurez le AWS Command Line Interface (AWS CLI), si ce n'est pas déjà fait.
Pour de plus amples informations, consultez [Installation ou mise à jour de la version la plus récente de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Pour configurer Patch Manager et appliquer des correctifs aux nœuds gérés (ligne de commande)**
1. Exécutez la commande suivante pour créer un référentiel de correctifs pour Windows nommée `Production-Baseline`. Ce référentiel de correctifs approuve les correctifs pour un environnement de production 7 jours après leur publication ou leur dernière mise à jour. Cela signifie que le référentiel de correctifs a été balisée pour indiquer qu'elle est destinée à un environnement de production.
**Note**
Le paramètre `OperatingSystem` et `PatchFilters` varient en fonction du système d'exploitation des nœuds gérés cibles auxquels s'applique le référentiel de correctifs. Pour plus d’informations, consultez [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) et [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer le référentiel de correctifs « Production-Baseline » pour deux groupes de correctifs. Les groupes sont nommés « serveurs de base de données » et « serveurs front-end ».
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Exécutez les commandes suivantes pour créer deux fenêtres de maintenance pour les serveurs de production. La première fenêtre est exécutée tous les mardis à 22:00. La seconde fenêtre est exécutée tous les samedis à 22:00. En outre, la fenêtre de maintenance a été balisée pour indiquer qu'elle est destinée à un environnement de production.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer les groupes de correctifs des serveurs `Database` et `Front-End` avec leurs fenêtres de maintenance respectives.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer une tâche de correctif qui installe les mises à jour manquantes sur les serveurs `Database` et `Front-End` pendant leurs fenêtres de maintenance respectives.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Exécutez la commande suivante pour obtenir le résumé de haut niveau de la conformité des correctifs d'un groupe de correctifs. Le récapitulatif détaillé de conformité des correctifs comprend le nombre de nœuds gérés et présente les correctifs en indiquant leurs états respectifs.
**Note**
Ce récapitulatif doit théoriquement afficher des zéros pour le nombre de nœuds gérés jusqu'à ce que la tâche d'application des correctifs soit exécutée lors de la première fenêtre de maintenance.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Exécutez la commande suivante pour obtenir le récapitulatif des états des correctifs par nœud géré pour un groupe de correctifs. Le récapitulatif par nœud géré présente un certain nombre de correctifs en indiquant leurs états respectifs par nœud géré pour un groupe de correctifs.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Pour des exemples d'autres AWS CLI commandes que vous pouvez utiliser pour vos tâches Patch Manager de configuration, consultez[Travailler avec des ressources Patch Manager à l’aide de l’AWS CLI](patch-manager-cli-commands.md).
# Résolution des problèmes de Patch Manager
Utilisez les informations suivantes pour résoudre les problèmes liés à Patch Manager, un outil de AWS Systems Manager.
**Topics**
+ [Problème : erreur « Invoke- PatchBaselineOperation : accès refusé » ou erreur « Impossible de télécharger le fichier depuis S3 » pour `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problème : le correctif échoue sans cause apparente ni message d'erreur](#race-condition-conflict)
+ [Problème : résultats de conformité aux correctifs inattendus](#patch-manager-troubleshooting-compliance)
+ [Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Linux](#patch-manager-troubleshooting-linux)
+ [Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Windows Server](#patch-manager-troubleshooting-windows)
+ [Erreurs lors de l'exécution `AWS-RunPatchBaseline` sur macOS](#patch-manager-troubleshooting-macos)
+ [Utilisation des AWS Support runbooks d'automatisation](#patch-manager-troubleshooting-using-support-runbooks)
+ [En contactant AWS Support](#patch-manager-troubleshooting-contact-support)
## Problème : erreur « Invoke- PatchBaselineOperation : accès refusé » ou erreur « Impossible de télécharger le fichier depuis S3 » pour `baseline_overrides.json`
**Problème** : lorsque les opérations de correction spécifiées par votre politique de correction s'exécutent, vous recevez une erreur similaire à l'exemple suivant.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**Cause** : vous avez créé une politique de correctifs dans Quick Setup, et certains de vos nœuds gérés avaient déjà un profil d'instance attaché (pour les instances EC2) ou à une fonction du service (pour les machines non EC2).
Cependant, comme le montre l’image suivante, vous n’avez pas coché la case **Ajouter les politiques IAM requises aux profils d’instance existants attachés à vos instances**.
![\[\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Lorsque vous créez une politique de correctifs, un compartiment Amazon S3 est également créé pour stocker le fichier `baseline_overrides.json` de configuration de la politique. Si vous ne cochez pas la case **Ajouter les politiques IAM requises aux profils d'instance existants attachés à vos instances** lors de la création de la politique, les politiques IAM et les balises de ressources nécessaires pour accéder à `baseline_overrides.json` dans le compartiment S3 ne sont pas automatiquement ajoutées à vos profils d'instance et fonction du service IAM existants.
**Solution 1** : supprimez la configuration de la politique de correctifs existante, puis créez-en une nouvelle, en veillant à cocher la case **Ajouter les politiques IAM requises aux profils d'instance existants attachés à vos instances**. Cette sélection applique les politiques IAM créées par cette configuration Quick Setup aux nœuds auxquels un profil d'instance ou une fonction du service est déjà attaché. (Par défaut, Quick Setup ajoute les politiques requises aux instances et aux nœuds qui n'ont *pas* encore de profils d'instance ou de fonction du service.) Pour plus d'informations, consultez [Automatiser l'application de correctifs à l'échelle de l'organisation à l'aide d'une politique de correctifs Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Solution 2** : ajoutez manuellement les autorisations et les balises requises à chaque profil d'instance IAM et à chaque fonction du service IAM que vous utilisez avec Quick Setup. Pour obtenir des instructions, veuillez consulter [Autorisations pour le compartiment S3 de la politique de correctifs](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problème : le correctif échoue sans cause apparente ni message d'erreur
**Problème** : une opération de correctif échoue sans renvoyer de message d'erreur.
**Cause possible** : lors de l'application de correctifs à des nœuds gérés, l'exécution du document peut être interrompue et marquée comme ayant échoué même si les correctifs ont été correctement installés. Cela peut se produire si le système lance un redémarrage inattendu pendant l'opération de correction (par exemple, pour appliquer des mises à jour au microprogramme ou à des fonctionnalités similaires SecureBoot). L'agent SSM ne peut pas conserver et reprendre l'état d'exécution du document lors de redémarrages externes, ce qui entraîne le signalement de l'échec de l'exécution.
**Solution** : pour vérifier l'état de l'installation des correctifs après un échec d'exécution, exécutez une `Scan` opération de correction, puis vérifiez les données de conformité des correctifs dans le Gestionnaire de correctifs afin d'évaluer l'état de conformité actuel.
Si vous déterminez que les redémarrages externes ne sont pas à l'origine de l'échec dans ce scénario, nous vous recommandons de contacter [AWS Support](#patch-manager-troubleshooting-contact-support).
## Problème : résultats de conformité aux correctifs inattendus
**Problème** : lorsque vous examinez les informations de conformité aux correctifs générées après une opération `Scan`, les résultats incluent des informations qui ne reflètent pas les règles définies dans votre référentiel de correctifs. Par exemple, une exception que vous avez ajoutée à la liste **Rejected patches** (Correctifs rejetés) dans un référentiel de correctifs est répertoriée comme `Missing`. Ou les correctifs considérés comme `Important` sont répertoriés comme manquants alors que votre référentiel de correctifs ne spécifie que des correctifs `Critical`.
**Cause** : Patch Manager prend actuellement en charge plusieurs méthodes d'exécution des opérations `Scan` :
+ 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
Lorsqu'une opération `Scan` s'exécute, elle remplace les informations de conformité issues de l'analyse la plus récente. Si plusieurs méthodes sont configurées pour exécuter une opération `Scan` et qu'elles utilisent des référentiels de correctifs différents avec des règles différentes, elles se traduiront par des résultats de conformité aux correctifs différents.
**Solution** : pour éviter des résultats inattendus de conformité aux correctifs, nous vous recommandons de n'utiliser qu'une seule méthode à la fois pour exécuter l'opération `Scan` de Patch Manager. Pour de plus amples informations, veuillez consulter [Identification de l'exécution qui a créé les données de conformité des correctifs](patch-manager-compliance-data-overwrites.md).
## Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Linux
**Topics**
+ [Problème : erreur indiquant « Pas de fichier ou de répertoire »](#patch-manager-troubleshooting-linux-1)
+ [Problème : erreur indiquant « un autre processus a acquis yum lock »](#patch-manager-troubleshooting-linux-2)
+ [Problème : erreur indiquant « Autorisation refusée /échec d'exécution des commandes »](#patch-manager-troubleshooting-linux-3)
+ [Problème : erreur indiquant « Impossible de télécharger la charge utile »](#patch-manager-troubleshooting-linux-4)
+ [Problème : erreur indiquant « gestionnaire de packages et combinaison de versions python non pris en charge »](#patch-manager-troubleshooting-linux-5)
+ [Problème : Patch Manager n'applique pas les règles spécifiées pour exclure certains packages](#patch-manager-troubleshooting-linux-6)
+ [Problème : l'application des correctifs échoue et Patch Manager signale que l'extension Indication de nom de serveur pour TLS n'est pas disponible](#patch-manager-troubleshooting-linux-7)
+ [Problème : Patch Manager signale « Plus de miroirs à essayer »](#patch-manager-troubleshooting-linux-8)
+ [Problème : le correctif échoue avec « Code d'erreur 23 renvoyé par curl »](#patch-manager-troubleshooting-linux-9)
+ [Problème : le correctif échoue avec le message « Error unpacking rpm package… » (Erreur de décompactage du package rpm…)](#error-unpacking-rpm)
+ [Problème : le correctif échoue avec le message « Erreur côté service lors du chargement de l’inventaire »](#inventory-upload-error)
+ [Problème : le correctif échoue avec le message « Errors were encountered while downloading packages » (Des erreurs ont été rencontrées lors du téléchargement des packages)](#errors-while-downloading)
+ [Problème : l'application des correctifs échoue en raison d'une erreur de mémoire insuffisante (OOM)](#patch-manager-troubleshooting-linux-oom)
+ [Problème : le correctif échoue avec le message suivant : « The following signatures couldn't be verified because the public key is not available » (Les signatures suivantes n'ont pas pu être vérifiées, car la clé publique n'est pas disponible)](#public-key-unavailable)
+ [Problème : l'application de correctifs échoue avec un message « NoMoreMirrorsRepoError »](#no-more-mirrors-repo-error)
+ [Problème : le correctif échoue avec un message « Unable to download payload » (Impossible de télécharger la charge utile)](#payload-download-error)
+ [Problème : le correctif échoue avec un message « install errors: dpkg: error: dpkg frontend is locked by another process » (erreurs d'installation : dpkg : erreur : dpkg frontend est bloqué par un autre processus)](#dpkg-frontend-locked)
+ [Problème : le correctif sur Ubuntu Server échoue avec une erreur « dpkg was interrupted » (dpkg a été interrompu)](#dpkg-interrupted)
+ [Problème : l'utilitaire du gestionnaire de packages ne peut pas résoudre la dépendance d'un package](#unresolved-dependency)
+ [Problème : échecs liés aux dépendances de verrouillage du package Zypper sur les nœuds gérés SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Problème : erreur indiquant « Pas de fichier ou de répertoire »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'une des erreurs suivantes.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**Cause 1** : deux commandes servant à exécuter `AWS-RunPatchBaseline` s'exécutaient en même temps sur le même nœud géré. Cela crée une condition de concurrence qui empêche la création des `file patch-baseline-operations*` temporaires, ou l'accès normal à celles-ci.
**Cause 2** : l'espace de stockage restant dans le répertoire `/var` est insuffisant.
**Solution 1** : assurez-vous qu'aucune fenêtre de maintenance ne comporte au moins deux Run Command tâches exécutées `AWS-RunPatchBaseline` avec le même niveau de priorité et exécutées sur la même cible IDs. Dans ce cas, réorganisez la priorité. Run Commandest un outil dans AWS Systems Manager.
**Solution 2** : vérifiez qu'une seule fenêtre de maintenance à la fois exécute des tâches Run Command qui utilisent `AWS-RunPatchBaseline` sur les mêmes cibles et selon le même calendrier. Si tel est le cas, modifiez le calendrier.
**Solution 3** : vérifiez qu’une seule association State Manager exécute `AWS-RunPatchBaseline` selon le même calendrier et cible les mêmes nœuds gérés. State Manager est un outil d’ AWS Systems Manager.
**Solution 4** : libérez suffisamment d'espace de stockage dans le répertoire `/var` pour les packages de mise à jour.
### Problème : erreur indiquant « un autre processus a acquis yum lock »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Cause** : le document `AWS-RunPatchBaseline` a commencé à s'exécuter sur un nœud géré alors qu'il est déjà en cours d'exécution dans une autre opération. Il a acquis le processus `yum` du gestionnaire de packages.
**Solution** : vérifiez qu'aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration qui exécute `AWS-RunPatchBaseline` selon une planification ne cible le même nœud géré en même temps.
### Problème : erreur indiquant « Autorisation refusée /échec d'exécution des commandes »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Cause** : `/var/lib/amazon/` peut être monté avec des autorisations `noexec`. Cela pose un problème car SSM Agent télécharge des scripts de charge utile dans `/var/lib/amazon/ssm` et les exécute depuis cet emplacement.
**Solution** : la vérification de la configuration des partitions exclusives est nécessaire pour `/var/log/amazon` et `/var/lib/amazon`, ainsi que leur montée avec des autorisations `exec`.
### Problème : erreur indiquant « Impossible de télécharger la charge utile »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**Cause** : le nœud géré ne dispose pas des autorisations requises pour accéder au compartiment Amazon Simple Storage Service (Amazon S3) spécifié.
**Solution** : mettez à jour votre configuration réseau pour que les points de terminaison S3 soient accessibles. Pour plus de détails, consultez les informations relatives à l'accès requis aux compartiments S3 pour Patch Manager dans [SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Problème : erreur indiquant « gestionnaire de packages et combinaison de versions python non pris en charge »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Cause** : aucune version prise en charge de python3 n’est pas installée sur l’instance Debian Server ou Ubuntu Server.
**Solution** : installez une version prise en charge de python3 (3.0 à 3.12) sur le serveur, comme l’exigent les nœuds gérés Debian Server et Ubuntu Server.
### Problème : Patch Manager n'applique pas les règles spécifiées pour exclure certains packages
**Problème** : vous avez tenté d'exclure certains packages en les spécifiant dans le fichier `/etc/yum.conf`, au format `exclude=package-name`, mais lors de l'opération `Install` de Patch Manager il s'avère qu'ils ne sont pas exclus.
**Cause** : Patch Manager n'incorpore pas les exclusions spécifiées dans le fichier `/etc/yum.conf`.
**Solution** : pour exclure des packages spécifiques, créez un référentiel de correctifs personnalisé et créez une règle pour exclure les packages que vous ne voulez pas installer.
### Problème : l'application des correctifs échoue et Patch Manager signale que l'extension Indication de nom de serveur pour TLS n'est pas disponible
**Problème** : l'opération d'application de correctifs émet le message suivant.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**Cause** : ce message n'indique pas une erreur. Il s'agit plutôt d'un avertissement selon lequel l'ancienne version de Python distribuée avec le système d'exploitation ne prend pas en charge l'indication de nom de serveur TLS. Le script de charge utile du correctif Systems Manager émet cet avertissement lors de la connexion à AWS APIs ce support SNI.
**Solution** : pour résoudre les échecs d'application de correctifs lorsque ce message est signalé, consultez le contenu des fichiers `stdout` et `stderr`. Si vous n'avez pas configuré la ligne de base de correctifs pour stocker ces fichiers dans un compartiment S3 ou dans Amazon CloudWatch Logs, vous pouvez les localiser à l'emplacement suivant sur votre nœud géré Linux.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Problème : Patch Manager signale « Plus de miroirs à essayer »
**Problème** : l'opération d'application de correctifs émet le message suivant.
```
[Errno 256] No more mirrors to try.
```
**Cause** : les référentiels configurés sur le nœud géré ne fonctionnent pas correctement. Les causes possibles incluent :
+ Le cache `yum` est corrompu.
+ Des problèmes liés au réseau empêchent d'atteindre une URL de référentiel.
**Solution** : Patch Manager utilise le gestionnaire de packages par défaut du nœud géré pour appliquer les correctifs. Vérifiez que les référentiels sont configurés et fonctionnent correctement.
### Problème : le correctif échoue avec « Code d'erreur 23 renvoyé par curl »
**Problème** : une opération d'application de correctifs qui utilise `AWS-RunPatchBaseline` échoue avec une erreur semblable à celle-ci :
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Cause** : l'outil curl utilisé sur vos systèmes ne dispose pas des autorisations nécessaires pour écrire sur le système de fichiers. Cela peut se produire lorsque l'outil curl par défaut du gestionnaire de packages a été remplacé par une version différente, telle que celle installée avec snap.
**Solution** : si la version curl fournie par le gestionnaire de packages a été désinstallée lors de l'installation d'une autre version, réinstallez-la.
Si vous devez conserver plusieurs versions de curl installées, assurez-vous que la version associée au gestionnaire de packages se trouve dans le premier répertoire répertorié dans la variable `PATH`. Vous pouvez le vérifier en exécutant la commande `echo $PATH` pour voir l'ordre actuel des répertoires dans lesquels les fichiers exécutables sont vérifiés sur votre système.
### Problème : le correctif échoue avec le message « Error unpacking rpm package… » (Erreur de décompactage du package rpm…)
**Problème** : une opération de correctif échoue avec un message d'erreur similaire au suivant :
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**Cause 1** : lorsqu'un package particulier est présent dans plusieurs installateurs de packages, comme `pip` et `yum` ou `dnf`, des conflits peuvent survenir lors de l'utilisation du gestionnaire de packages par défaut.
Un exemple courant est celui du package `urllib3`, qui se trouve dans `pip`, `yum` et `dnf`.
**Cause 2** : le package `python-urllib3` est endommagé. Cela peut se produire si les fichiers du package ont été installés ou mis à jour par `pip` après que le package `rpm` ait été précédemment installé par `yum` ou `dnf`.
**Solution** : supprimez le package `python-urllib3` de pip en exécutant la commande `sudo pip uninstall urllib3`, en conservant le package uniquement dans le gestionnaire de package par défaut (`yum` ou `dnf`).
### Problème : le correctif échoue avec le message « Erreur côté service lors du chargement de l’inventaire »
**Problème** : lorsque vous exécutez le document `AWS-RunPatchBaseline`, vous recevez le message d’erreur suivant :
```
Encounter service side error when uploading the inventory
```
**Cause** : deux commandes servant à exécuter `AWS-RunPatchBaseline` s’exécutaient en même temps sur le même nœud géré. Cela crée une condition de concurrence lors de l’initialisation du client boto3 lors des opérations d’application de correctifs.
**Solution** : vérifiez qu'aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration qui exécute `AWS-RunPatchBaseline` selon une planification ne cible le même nœud géré en même temps.
### Problème : le correctif échoue avec le message « Errors were encountered while downloading packages » (Des erreurs ont été rencontrées lors du téléchargement des packages)
**Problème** : pendant le correctif, vous recevez un message d'erreur similaire au suivant :
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**Cause** : cette erreur peut se produire lorsque la mémoire disponible sur un nœud géré est insuffisante.
**Solution** : configurez la mémoire d'échange ou mettez à niveau l'instance vers un type différent pour augmenter la prise en charge de la mémoire. Lancez ensuite une nouvelle opération de correctif.
### Problème : l'application des correctifs échoue en raison d'une erreur de mémoire insuffisante (OOM)
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, l'opération de correction échoue en raison d'une mémoire insuffisante sur le nœud géré. Des erreurs telles que`Cannot allocate memory`, `Killed` (provenant du logiciel Linux OOM Killer) peuvent s'afficher, ou l'opération peut échouer de façon inattendue. Cette erreur est plus susceptible de se produire sur les instances disposant de moins de 1 Go de RAM, mais elle peut également affecter les instances disposant de plus de mémoire lorsqu'un grand nombre de mises à jour sont disponibles.
**Cause** : Patch Manager exécute des opérations de correction à l'aide du gestionnaire de packages natif sur le nœud géré. La mémoire requise lors d'une opération d'application de correctifs dépend de plusieurs facteurs, notamment :
+ Le nombre de packages installés et de mises à jour disponibles sur le nœud géré.
+ Le gestionnaire de packages utilisé et ses caractéristiques de mémoire.
+ Autres processus exécutés sur le nœud géré au moment de l'opération d'application des correctifs.
Les nœuds gérés dotés d'un grand nombre de packages installés ou d'un grand nombre de mises à jour disponibles nécessitent davantage de mémoire lors des opérations d'application de correctifs. Lorsque la mémoire disponible est insuffisante, le processus d'application des correctifs échoue et se termine avec un message d'erreur. Le système d'exploitation peut également mettre fin au processus d'application des correctifs.
**Solution** : essayez une ou plusieurs des solutions suivantes :
+ Planifiez les opérations d'application de correctifs pendant les périodes de faible charge de travail sur le nœud géré, par exemple en utilisant des fenêtres de maintenance.
+ Mettez à niveau l'instance vers un type avec plus de mémoire.
+ Configurez la mémoire d'échange sur le nœud géré. Notez que sur les instances dont le débit EBS est limité, une utilisation intensive du swap peut entraîner une dégradation des performances.
+ Vérifiez et réduisez le nombre de processus exécutés sur le nœud géré pendant les opérations d'application de correctifs.
### Problème : le correctif échoue avec le message suivant : « The following signatures couldn't be verified because the public key is not available » (Les signatures suivantes n'ont pas pu être vérifiées, car la clé publique n'est pas disponible)
**Problème** : le correctif échoue sur Ubuntu Server avec une erreur similaire à la suivante :
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**Cause** : la clé GNU Privacy Guard (GPG) a expiré ou est manquante.
**Solution** : actualisez la clé GPG ou ajoutez-la de nouveau.
Par exemple, en utilisant l'erreur montrée précédemment, nous voyons que la clé `467B942D3A79BD29` est manquante et doit être ajoutée. Pour ce faire, exécutez l'une des commandes suivantes :
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
Ou, pour actualiser toutes les clés, exécutez la commande suivante :
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Si l'erreur se reproduit, nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce qu'un correctif soit disponible, vous pouvez modifier le fichier `/etc/apt/sources.list` afin d'omettre le référentiel pendant le processus de correctif.
Pour ce faire, ouvrez le fichier `sources.list` pour le modifier, localisez la ligne relative au référentiel et insérez un caractère `#` au début de la ligne pour la mettre en commentaire. Ensuite, enregistrez et fermez le fichier.
### Problème : l'application de correctifs échoue avec un message « NoMoreMirrorsRepoError »
**Problème** : vous recevez une erreur similaire à la suivante :
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Cause** : il y a une erreur dans le référentiel source.
**Solution** : nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce que l'erreur soit corrigée, vous pouvez désactiver le référentiel au niveau du système d'exploitation. Pour ce faire, exécutez la commande suivante en remplaçant la valeur pour *repo-name* par le nom de votre dépôt :
```
yum-config-manager --disable repo-name
```
Voici un exemple.
```
yum-config-manager --disable pgdg94
```
Après avoir exécuté cette commande, lancez une autre opération de correctif.
### Problème : le correctif échoue avec un message « Unable to download payload » (Impossible de télécharger la charge utile)
**Problème** : vous recevez une erreur similaire à la suivante :
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**Cause** : la configuration du nœud géré contient des erreurs ou est incomplète.
**Solution** : assurez-vous que le nœud géré est configuré avec les éléments suivants :
+ Règle TCP 443 sortante dans le groupe de sécurité.
+ Règle TCP 443 de sortie dans NACL.
+ Règle TCP 1024-65535 d'entrée dans NACL.
+ NAT/IGW dans la table de routage pour fournir une connectivité à un point de terminaison S3. Si l'instance n'a pas d'accès internet, fournissez-lui une connectivité avec le point de terminaison S3. Pour ce faire, ajoutez un point de terminaison de passerelle S3 dans le VPC et intégrez-le à la table de routage du nœud géré.
### Problème : le correctif échoue avec un message « install errors: dpkg: error: dpkg frontend is locked by another process » (erreurs d'installation : dpkg : erreur : dpkg frontend est bloqué par un autre processus)
**Problème** : le correctif échoue avec une erreur similaire à la suivante :
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**Cause** : le gestionnaire de packages exécute déjà un autre processus sur un nœud géré au niveau du système d'exploitation. Si cet autre processus prend beaucoup de temps à se terminer, l'opération de correctif Patch Manager peut prendre du temps et échouer.
**Solution** : une fois que l'autre processus utilisant le gestionnaire de packages est terminé, exécutez une nouvelle opération de correctif.
### Problème : le correctif sur Ubuntu Server échoue avec une erreur « dpkg was interrupted » (dpkg a été interrompu)
**Problème** : sur Ubuntu Server, le correctif échoue avec une erreur similaire à la suivante :
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Cause** : un ou plusieurs packages sont mal configurés.
**Solution** : procédez comme suit :
1. Vérifiez quels sont les packages concernés et quels sont les problèmes liés à chaque package en exécutant les commandes suivantes, une à la fois :
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Corrigez les packages concernés en exécutant la commande suivante :
```
sudo dpkg --configure -a
```
1. Si la commande précédente n'a pas permis de résoudre complètement le problème, exécutez la commande suivante :
```
sudo apt --fix-broken install
```
### Problème : l'utilitaire du gestionnaire de packages ne peut pas résoudre la dépendance d'un package
**Problème** : le gestionnaire de packages natif du nœud géré ne parvient pas à résoudre une dépendance de package et le correctif échoue. L'exemple de message d'erreur suivant indique ce type d'échec sur un système d'exploitation qui utilise `yum` comme gestionnaire de packages.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**Cause** : sur les systèmes d'exploitation Linux, Patch Manager utilise le gestionnaire de packages natif de l'ordinateur pour exécuter les opérations de correctif. telles que `yum`, `dnf`, `apt` et `zypper`. Les applications détectent, installent, mettent à jour ou suppriment automatiquement les packages dépendants selon les besoins. Cependant, dans certaines conditions, le gestionnaire de packages peut être dans l'incapacité de mener à bien une opération de dépendance, comme par exemple :
+ Plusieurs référentiels contradictoires sont configurés sur le système d'exploitation.
+ L'URL d'un référentiel distant est inaccessible en raison de problèmes liés au réseau.
+ Un package pour la mauvaise architecture est trouvé dans le référentiel.
**Solution** : le correctif peut échouer en raison d'un problème de dépendance pour une grande variété de raisons. Par conséquent, nous vous recommandons de nous contacter AWS Support pour obtenir de l'aide pour le dépannage.
### Problème : échecs liés aux dépendances de verrouillage du package Zypper sur les nœuds gérés SLES
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline` avec l’opération `Install` sur des instances SUSE Linux Enterprise Server, l’application de correctifs échoue en raison d’erreurs de vérification des dépendances liées au verrouillage des packages. Vous pourriez recevoir des messages d’erreur similaires au suivant :
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
Dans cet exemple, le package `mock-pkg-standalone` est verrouillé, ce que vous pouvez vérifier en exécutant `sudo zypper locks` et en recherchant ce nom de package dans la sortie.
Vous pourriez également voir des entrées de journal indiquant des échecs de vérification des dépendances :
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**Note**
Ce problème se produit uniquement pendant les opérations `Install`. Les opérations `Scan` n’appliquent pas de verrous de package et ne sont pas affectées par les verrous existants. »
**Cause** : cette erreur se produit lorsque les verrous de package zypper empêchent l’installation ou la mise à jour de packages en raison de conflits de dépendances. Les verrous de package peuvent être présents pour plusieurs raisons :
+ **Verrous appliqués par le client** : vous ou votre administrateur système avez verrouillé manuellement les packages à l’aide de commandes zypper comme `zypper addlock`.
+ **Correctifs rejetés par Patch Manager** : Patch Manager applique automatiquement le verrouillage des packages lorsque vous spécifiez des packages dans la liste des **correctifs rejetés** de votre référentiel de correctifs afin d’empêcher leur installation.
+ **Verrouillages résiduels dus à des opérations interrompues** : dans de rares cas, si une opération d’application de correctif a été interrompue (par exemple à la suite d’un redémarrage du système) avant que Patch Manager puisse nettoyer les verrous temporaires, des verrous de package résiduels peuvent rester sur votre nœud géré.
**Solution** : pour résoudre les problèmes de verrouillage de package zypper, suivez ces étapes en fonction de la cause :
**Étape 1 : identifier les packages verrouillés**
Connectez-vous à votre nœud géré SLES et exécutez la commande suivante pour répertorier tous les packages actuellement verrouillés :
```
sudo zypper locks
```
**Étape 2 : déterminer la source des verrous**
+ Si les packages verrouillés sont ceux que vous avez intentionnellement verrouillés pour la stabilité du système, déterminez s’ils doivent rester verrouillés ou s’ils peuvent être temporairement déverrouillés pour l’application de correctifs.
+ Si les packages verrouillés correspondent aux entrées de la liste des **correctifs rejetés** de votre référentiel de correctifs, il s’agit probablement de verrouillages résiduels résultant d’une interruption d’opération d’application de correctif. Au cours des opérations normales, Patch Manager applique ces verrous temporairement et les supprime automatiquement une fois l’opération terminée. Vous pouvez soit supprimer les packages de la liste des packages rejetés, soit modifier les règles de votre référentiel de correctifs.
+ Si vous ne reconnaissez pas les packages verrouillés et qu’ils n’ont pas été verrouillés intentionnellement, il se peut qu’il s’agisse de verrous résiduels résultant d’une interruption d’une opération d’application de correctif précédente.
**Étape 3 : supprimer les verrous le cas échéant**
Pour supprimer des verrous de package spécifiques, utilisez la commande suivante :
```
sudo zypper removelock package-name
```
Pour supprimer tous les verrous de package (à utiliser avec prudence), exécutez :
```
sudo zypper cleanlocks
```
**Étape 4 : mettez à jour votre référentiel de correctifs (le cas échéant)**
Si les verrouillages ont été provoqués par le rejet de correctifs dans votre référentiel de correctifs :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l’onglet **Référentiels de correctifs**, puis choisissez votre référentiel de correctifs personnalisé.
1. Choisissez **Actions**, puis **Modifier le référentiel de correctifs**.
1. Dans la section **Correctifs rejetés**, passez en revue les packages répertoriés et supprimez ceux dont l’installation devrait être autorisée.
1. Sélectionnez **Enregistrer les modifications**.
**Étape 5 : réessayer l’opération d’application de correctif**
Après avoir supprimé les verrous problématiques et mis à jour votre référentiel de correctifs si nécessaire, réexécutez le document `AWS-RunPatchBaseline`.
**Note**
Lorsque Patch Manager applique des verrous aux correctifs rejetés pendant les opérations `Install`, il est conçu pour nettoyer ces verrous automatiquement une fois l’opération d’application de correctif terminée. Si ces verrous apparaissent lors de l’exécution de `sudo zypper locks`, cela indique qu’une opération d’application de correctif précédente a été interrompue avant que le nettoyage puisse avoir lieu. Toutefois, si une opération d’application de correctif est interrompue, un nettoyage manuel peut être nécessaire, comme décrit dans cette procédure.
**Prévention** : pour éviter de futurs conflits de verrouillage zypper :
+ Examinez attentivement la liste des correctifs rejetés de votre référentiel de correctifs pour vous assurer qu’elle inclut uniquement les packages que vous souhaitez réellement exclure.
+ Évitez de verrouiller manuellement les packages qui peuvent être nécessaires comme dépendances pour les mises à jour de sécurité.
+ Si vous devez verrouiller des packages manuellement, documentez les raisons de ce choix et vérifiez régulièrement les verrous.
+ Assurez-vous que les opérations d’application de correctifs se terminent correctement et ne sont pas interrompues par des redémarrages du système ou d’autres facteurs.
+ Surveillez les opérations d’application de correctifs jusqu’à leur fin et évitez de les interrompre en redémarrant le système ou en effectuant d’autres actions susceptibles d’empêcher le bon nettoyage des verrous temporaires.
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Windows Server
**Topics**
+ [Problème : paires de produits family/product incompatibles](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problème: `AWS-RunPatchBaseline` renvoie un `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Problème : le nœud géré n'a pas accès au catalogue Windows Update ou à WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problème : le PatchBaselineOperations PowerShell module n'est pas téléchargeable](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problème : correctifs manquants](#patch-manager-troubleshooting-missing-patches)
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Problème : paires de produits family/product incompatibles
**Problèmes :** lorsque vous créez un référentiel de correctifs dans la console Systems Manager, vous spécifiez une famille de produits et un produit. Par exemple, vous pouvez choisir ce qui suit :
+ **Famille de produits** : `Office`
**Produit** : `Office 2016`
**Cause** : Si vous tentez de créer une ligne de base de correctifs avec une family/product paire de produits qui ne correspond pas, un message d'erreur s'affiche. Voici les cas où cette situation peut se présenter :
+ Vous avez sélectionné une paire famille de produits et produit valide, puis supprimé la sélection de la famille de produits.
+ Vous avez choisi un produit dans la sous-liste **Obsolete or mismatched options (Options obsolètes ou non assorties)** au lieu de la sous-liste **Available and matching options (Options disponibles et assorties)**.
Les éléments de la sous-liste des **options obsolètes ou incompatibles** du produit peuvent avoir été saisis par erreur via un SDK ou une commande AWS Command Line Interface ()AWS CLI. `create-patch-baseline` Cela peut signifier qu'une faute de frappe a été introduite ou qu'un produit a été attribué à la mauvaise famille de produits. Un produit apparaît également dans la sous-liste **Obsolete or mismatched options (Options obsolètes ou non assorties)** s'il a été spécifié pour un référentiel de correctifs précédente mais qu'aucun correctif n'est disponible à partir de Microsoft.
**Solution** : pour éviter ce problème dans la console, sélectionnez toujours des options des sous-listes **Currently available options (Options actuellement disponibles)**.
Vous pouvez également consulter les produits pour lesquels des correctifs sont disponibles à l'aide de la 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)` dans l' AWS CLI ou de la commande d'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)`.
### Problème: `AWS-RunPatchBaseline` renvoie un `HRESULT` (Windows Server)
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**Cause** : ce résultat indique que le Windows Update natif n'a pas APIs pu exécuter les opérations de correction.
**Solution** : vérifiez le code `HResult` dans les rubriques suivantes sur microsoft.com afin d'identifier les étapes de résolution de cette erreur :
+ [Codes d'erreur Windows Update par composant](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Erreurs courantes et mesures d'atténuation pour Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Problème : le nœud géré n'a pas accès au catalogue Windows Update ou à WSUS
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**Cause** : cette erreur peut être liée aux composants Windows Update ou à un manque de connectivité au catalogue Windows Update ou aux WSUS (Windows Server Update Services).
**Solution** : vérifiez que le nœud géré est connecté au [catalogue Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) via une passerelle Internet, une passerelle NAT ou une instance NAT. Si vous utilisez WSUS, vérifiez que le nœud géré est connecté au serveur WSUS de votre environnement. Si la connectivité est disponible pour la destination prévue, vérifiez la documentation Microsoft pour trouver d'autres causes potentielles à `HResult 0x80072EE2`. Cela peut indiquer un problème au niveau du système d'exploitation.
### Problème : le PatchBaselineOperations PowerShell module n'est pas téléchargeable
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**Solution** : vérifiez la connectivité du nœud géré et les autorisations d'accès à Amazon Simple Storage Service (Amazon S3). Le rôle du nœud géré Gestion des identités et des accès AWS (IAM) doit utiliser les autorisations minimales citées dans[SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). Le nœud doit communiquer avec le point de terminaison Amazon S3 via le point de terminaison de la passerelle Amazon S3, la passerelle NAT ou la passerelle Internet. Pour plus d'informations sur les exigences du point de terminaison VPC pour AWS Systems Manager SSM Agent (SSM Agent), consultez. [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md)
### Problème : correctifs manquants
**Problème** : `AWS-RunPatchbaseline` s'est terminé avec succès, mais il manque certains correctifs.
Voici quelques causes courantes et leurs solutions.
**Cause 1** : le référentiel n'est pas en vigueur.
**Solution 1** : pour vérifier si la cause est bien liée à ce problème, procédez comme suit :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez l'onglet **Historique des commandes**, puis sélectionnez la commande dont vous souhaitez vérifier le référentiel.
1. Sélectionnez le nœud géré auquel il manque des correctifs.
1. Sélectionnez **Étape 1 - Sortie**, et recherchez la valeur `BaselineId`.
1. Vérifiez la [Configuration de référentiel de correctifs](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) affectée, c'est-à-dire le système d'exploitation, le nom du produit, la classification et la sévérité associés au référentiel de correctifs.
1. Accédez au [Catalogue des mises à jour Microsoft](https://www.catalog.update.microsoft.com/home.aspx).
1. Recherchez dans l'article de la base de connaissances Microsoft (KB) IDs (par exemple, KB3216916).
1. Vérifiez que la valeur indiquée sous **Product (Produit)** correspond à celle de votre nœud géré, et sélectionnez le **Title (Titre)** correspondant. Une nouvelle fenêtre **Actualiser les détails** s'ouvre.
1. Sous l'onglet **Présentation**, la **classification** et la **sévérité du MSRC** doivent correspondre à la configuration du référentiel de correctifs que vous avez trouvée précédemment.
**Cause 2** : le correctif a été remplacé.
**Solution 2** : pour vérifier si cela est vrai, procédez comme suit.
1. Accédez au [Catalogue des mises à jour Microsoft](https://www.catalog.update.microsoft.com/home.aspx).
1. Recherchez dans l'article de la base de connaissances Microsoft (KB) IDs (par exemple, KB3216916).
1. Vérifiez que la valeur indiquée sous **Product (Produit)** correspond à celle de votre nœud géré, et sélectionnez le **Title (Titre)** correspondant. Une nouvelle fenêtre **Actualiser les détails** s'ouvre.
1. Accédez à l'onglet **Détails du package**. Recherchez une entrée sous l'en-tête **Cette mise à jour a été remplacée par les mises à jour suivantes : **.
**Cause 3** : le même correctif peut avoir différents numéros de KB car les mises à jour en ligne des WSUS et de Window sont gérées comme des canaux de publication indépendants par Microsoft.
**Solution 3** : vérifiez l'éligibilité du correctif. Si le package n'est pas disponible sous les WSUS, installez la [version 14393.3115 du système d'exploitation](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Si le package est disponible pour toutes les versions du système d'exploitation, installez les [versions de système d'exploitation 18362.1256 et 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Erreurs lors de l'exécution `AWS-RunPatchBaseline` sur macOS
**Topics**
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Utilisation des AWS Support runbooks d'automatisation
AWS Support fournit deux runbooks d'automatisation que vous pouvez utiliser pour résoudre certains problèmes liés à l'application de correctifs.
+ `AWSSupport-TroubleshootWindowsUpdate` : le dossier d’exploitation [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) est utilisé pour identifier les problèmes susceptibles de faire échouer les mises à jour Windows Server des instances Amazon Elastic Compute Cloud (Amazon EC2) Windows Server.
+ `AWSSupport-TroubleshootPatchManagerLinux` : le dossier d’exploitation [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) résout les problèmes courants susceptibles de provoquer l’échec d’un correctif sur les nœuds gérés basés sur Linux avec Patch Manager. L’objectif principal de ce dossier d’exploitation est d’identifier la cause première de l’échec de la commande de correctif et de suggérer un plan de correction.
**Note**
L’utilisation des dossiers d’exploitation Automation est payante. Pour plus d’informations, consultez la section [Tarification AWS Systems Manager pour Automation](https://aws.amazon.com/systems-manager/pricing/#Automation).
## En contactant AWS Support
Si vous ne trouvez pas de solutions de dépannage dans cette section ou dans les problèmes Systems Manager de [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), et que vous disposez d'une [formule Support Développeur, Business ou Entreprise](https://aws.amazon.com/premiumsupport/plans), vous pouvez formuler une demande de prise en charge technique à l'adresse [AWS Support](https://aws.amazon.com/premiumsupport/).
Avant de nous contacter Support, collectez les objets suivants :
+ [Journaux SSM Agent](ssm-agent-logs.md)
+ Run CommandID de commande, ID de fenêtre de maintenance ou ID d'exécution d'Automation
+ Pour les nœuds gérés Windows Server, munissez-vous également les éléments suivants :
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` tels qu'ils figurent sous l'onglet **Windows** de [Installation des correctifs](patch-manager-installing-patches.md)
+ Journaux de mise à jour Windows : pour Windows Server 2012 R2 et versions antérieures, utilisez `%windir%/WindowsUpdate.log`. Pour Windows Server 2016 et les versions ultérieures, exécutez d'abord la PowerShell commande [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)avant d'utiliser `%windir%/WindowsUpdate.log`
+ Pour les nœuds gérés Linux, munissez-vous également les éléments suivants :
+ Le contenu du répertoire `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`.