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