• 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 Outils pour nœuds
AWS Systems Manager fournit les outils suivants pour accéder à vos *nœuds gérés*, les gérer et les configurer. Un nœud géré est une machine configurée pour être utilisée avec Systems Manager dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types).
**Topics**
+ [Conformité d'AWS Systems Manager](systems-manager-compliance.md)
+ [AWS Systems Manager Distributor](distributor.md)
+ [AWS Systems Manager Fleet Manager](fleet-manager.md)
+ [AWS Systems Manager Activations hybrides](activations.md)
+ [AWS Systems Manager Inventory](systems-manager-inventory.md)
+ [AWS Systems Manager Patch Manager](patch-manager.md)
+ [AWS Systems Manager Run Command](run-command.md)
+ [AWS Systems Manager Session Manager](session-manager.md)
+ [AWS Systems Manager State Manager](systems-manager-state.md)
# Conformité d'AWS Systems Manager
Vous pouvez utiliser Compliance, un outil intégré AWS Systems Manager, pour analyser votre parc de nœuds gérés afin de détecter la conformité des correctifs et les incohérences de configuration. Vous pouvez collecter et agréger des données provenant de plusieurs Comptes AWS régions, puis explorer les ressources spécifiques qui ne sont pas conformes. Par défaut, le service Conformité affiche les données de conformité actuelles relatives à l’application de correctifs dans Patch Manager et aux associations dans State Manager. (Patch Manager et State Manager sont également des outils d’ AWS Systems Manager.) Pour vos débuts dans la section conformité, ouvrez [Systems Manager console](https://console.aws.amazon.com//systems-manager/compliance) (la console Systems Manager). Dans le panneau de navigation, sélectionnez **Compliance (Conformité)**.
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).
La conformité offre les avantages et fonctions supplémentaires suivants :
+ Affichage du suivi des modifications et de l'historique de conformité pour les données de correctifs de Patch Manager et les associations State Manager à l'aide d' AWS Config.
+ Personnalisation de la conformité pour créer vos propres types de conformité en fonction de vos exigences métier ou informatiques.
+ Résolvez les problèmes en utilisant Run Command un autre outil dans AWS Systems ManagerState Manager, ou Amazon EventBridge.
+ Transférez les données vers Amazon Athena et Amazon Quick pour générer des rapports à l'échelle de la flotte.
**EventBridge soutien**
Cet outil Systems Manager est pris en charge en tant que type d'*événement* dans les EventBridge règles d'Amazon. Pour plus d’informations, consultez [Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md) et [Référence : modèles et types d' EventBridge événements Amazon pour Systems Manager](reference-eventbridge-events.md).
**intégration d’Chef InSpec**
Systems Manager s'intègre à [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec est un framework d'exécution open source qui vous permet de créer des profils lisibles par l'homme sur GitHub Amazon Simple Storage Service (Amazon S3). Vous pouvez ensuite utiliser Systems Manager pour exécuter des analyses de conformité et afficher les nœuds gérés conformes et non conformes. Pour de plus amples informations, veuillez consulter [Utilisation des profils Chef InSpec avec la conformité de Systems Manager](integration-chef-inspec.md).
**Tarification**
Le service Compliance est fourni sans frais supplémentaires. Vous ne payez que pour les AWS ressources que vous utilisez.
**Topics**
+ [Mise en route avec le service Conformité](compliance-prerequisites.md)
+ [Configurer les autorisations pour la conformité](compliance-permissions.md)
+ [Création d'une synchronisation de données de ressources pour Compliance](compliance-datasync-create.md)
+ [En savoir plus sur la conformité](compliance-about.md)
+ [Suppression d'une synchronisation de données de ressources pour le service Conformité](systems-manager-compliance-delete-RDS.md)
+ [Résolution des problèmes de conformité avec EventBridge](compliance-fixing.md)
+ [Attribuez des métadonnées de conformité personnalisées à l'aide du AWS CLI](compliance-custom-metadata-cli.md)
# Mise en route avec le service Conformité
Pour commencer à utiliser le service Compliance, un outil d’AWS Systems Manager, effectuez les tâches suivantes.
****
| Tâche | Pour plus d'informations |
| --- | --- |
| Le service Compliance utilise des données d’application de correctifs dans Patch Manager et des associations dans State Manager. (Patch Manager et State Manager sont également des outils d’AWS Systems Manager.) Le service Conformité utilise également des types de conformité personnalisés sur les nœud gérés avec Systems Manager. Vérifiez que vous avez satisfait la configuration requise pour vos instances Amazon Elastic Compute Cloud (Amazon EC2) et vos machines non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). | [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md) |
| Mettez à jour le rôle Gestion des identités et des accès AWS (IAM) utilisé par vos nœuds gérés pour restreindre les autorisations de conformité. | [Configurer les autorisations pour la conformité](compliance-permissions.md) |
| Si vous prévoyez de surveiller la conformité des correctifs, vérifiez que vous avez configuré Patch Manager. Vous devez effectuer des opérations d'application de correctifs à l'aide de Patch Manager pour que le service Compliance puisse afficher les données de conformité des correctifs. | [AWS Systems Manager Patch Manager](patch-manager.md) |
| Si vous envisagez de surveiller la conformité des associations, vérifiez que vous avez créé des associations State Manager. Vous devez créer des associations pour que Compliance puisse afficher les données de conformité des associations. | [AWS Systems Manager State Manager](systems-manager-state.md) |
| (Facultatif) Configurez le système pour afficher le suivi des modifications et l'historique de conformité. | [Affichage du suivi des modifications et de l'historique de configuration de la conformité](compliance-about.md#compliance-history) |
| (Facultatif) Créez des types de conformité personnalisée. | [Attribuez des métadonnées de conformité personnalisées à l'aide du AWS CLI](compliance-custom-metadata-cli.md) |
| (Facultatif) Créez une synchronisation de données de ressources pour agréger toutes les données de conformité dans un compartiment Amazon Simple Storage Service (Amazon S3) cible. | [Création d'une synchronisation de données de ressources pour Compliance](compliance-datasync-create.md) |
# Configurer les autorisations pour la conformité
Pour des raisons de sécurité, nous vous recommandons de mettre à jour le rôle Gestion des identités et des accès AWS (IAM) utilisé par vos nœuds gérés avec les autorisations suivantes afin de limiter la capacité du nœud à utiliser l'action d'[PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API. Cette action d'API enregistre un type de conformité et d'autres informations de conformité sur une ressource désignée, telle qu'une EC2 instance Amazon ou un nœud géré.
Si votre nœud est une EC2 instance Amazon, vous devez mettre à jour le profil d'instance IAM utilisé par l'instance avec les autorisations suivantes. Pour plus d'informations sur les profils d' EC2 instance gérés par les instances par Systems Manager, consultez[Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md). Pour les autres types de nœuds gérés, mettez à jour le rôle IAM utilisé par le nœud avec les autorisations suivantes. Pour plus d’informations, consultez [Mettre à jour les autorisations pour un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) dans le *Guide de l’utilisateur IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:SourceInstanceARN": "${ec2:SourceInstanceARN}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ssm:SourceInstanceARN": "${ssm:SourceInstanceARN}"
}
}
}
]
}
```
------
# Création d'une synchronisation de données de ressources pour Compliance
Vous pouvez utiliser la fonctionnalité de synchronisation des données de ressources AWS Systems Manager pour envoyer les données de conformité de tous vos nœuds gérés vers un compartiment Amazon Simple Storage Service (Amazon S3) cible. Lorsque vous créez la synchronisation, vous pouvez spécifier des nœuds gérés à partir de plusieurs Comptes AWS, Régions AWS, ainsi que de votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). La synchronisation de données de ressources met alors automatiquement à jour les données centralisées lors de la collecte de nouvelles données de conformité. Toutes les données de conformité étant stockées dans un compartiment S3 cible, vous pouvez utiliser des services tels qu'Amazon Athena et Amazon Quick pour interroger et analyser les données agrégées. La configuration de la synchronisation de données de ressources pour Compliance est une opération unique.
Utilisez la procédure suivante pour créer une synchronisation de données de ressources pour Compliance en utilisant la AWS Management Console.
**Pour créer et configurer un compartiment S3 pour la synchronisation de données de ressources (console)**
1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Créez un compartiment pour stocker vos données de conformité agrégées. Pour plus d'informations, consultez [Création d'un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Guide de l'utilisateur d'Amazon Simple Storage Service*. Notez le nom du bucket et l' Région AWS endroit où vous l'avez créé.
1. Ouvrez le compartiment, sélectionnez l'onglet **Autorisations**, puis sélectionnez **Politique de compartiment**.
1. Copiez et collez la politique de compartiment suivante dans l'éditeur de politique. Remplacez amzn-s3-demo-bucket par le nom du compartiment S3 que vous avez créé et *Account-ID* un identifiant valide. Compte AWS Vous pouvez éventuellement le *Bucket-Prefix* remplacer par le nom d'un préfixe Amazon S3 (sous-répertoire). Si vous n'avez pas créé de préfixe, supprimez*Bucket-Prefix*/de l'ARN dans la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/Bucket-Prefix/*/accountid=111122223333/*"],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
```
------
**Pour créer une synchronisation de données de ressources**
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. Sélectionnez **Accoung management (Gestion du compte)**, **Resource Data Syncs (Synchronisations de données de ressources)**, puis **Create resource data sync (Créer une synchronisation de données de ressources)**.
1. Dans le champ **Sync name (Nom de la synchronisation)**, saisissez un nom pour la configuration de la synchronisation.
1. Dans le champ **Bucket name (Nom du compartiment)**, saisissez le nom du compartiment Amazon S3 créé au début de cette procédure.
1. (Facultatif) Dans le champ **Préfixe du compartiment**, saisissez le nom d'un préfixe de compartiment S3 (sous-répertoire).
1. Dans le champ **Région du compartiment**, sélectionnez **Cette région** si le compartiment S3 créé est localisé dans la Région AWS actuelle. Si le compartiment se trouve dans une **autre région Région AWS, choisissez Another region**, puis entrez le nom de la région.
**Note**
Si la synchronisation et le compartiment S3 cible sont localisés dans des régions différentes, vous pourriez être sujet à une tarification de transfert de données. Pour plus d'informations, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
1. Choisissez **Créer**.
# En savoir plus sur la conformité
Compliance, un outil de AWS Systems Manager, collecte et rapporte des données sur l'état de l'application des correctifs dans le cadre des Patch Manager correctifs et des associations dans. State Manager (Patch Manageret State Manager les deux outils sont également intégrés AWS Systems Manager.) Compliance rapporte également les types de conformité personnalisés que vous avez spécifiés pour vos nœuds gérés. Cette section inclut des détails sur chacun de ces types de conformité et la manière d'afficher les données de conformité Systems Manager. Cette section inclut également des informations sur la façon d'afficher le suivi des modifications et l'historique de conformité.
**Note**
Systems Manager s'intègre à [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec est un framework d'exécution open source qui vous permet de créer des profils lisibles par l'homme sur GitHub Amazon Simple Storage Service (Amazon S3). Ensuite, vous pouvez utiliser Systems Manager pour exécuter des analyses de conformité et afficher les instances conformes et non conformes. Pour de plus amples informations, veuillez consulter [Utilisation des profils Chef InSpec avec la conformité de Systems Manager](integration-chef-inspec.md).
## A propos de la conformité des correctifs
Une fois que vous avez utilisé Patch Manager pour installer des correctifs sur vos instances, les informations relatives au statut de conformité sont immédiatement disponibles dans la console, ou en réponse à des commandes de l' AWS Command Line Interface (AWS CLI) ou aux opérations d'API Systems Manager correspondantes.
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).
## A propos de la conformité des associations State Manager
Une fois que vous avez créé une ou plusieurs State Manager associations, les informations relatives au statut de conformité sont immédiatement disponibles dans la console ou en réponse aux AWS CLI commandes ou aux opérations d'API Systems Manager correspondantes. Pour les associations, le service Compliance affiche les statuts `Compliant` ou `Non-compliant` et le niveau de sévérité attribué à l'association, tel que `Critical` ou `Medium`.
Lorsque State Manager exécute une association sur un nœud géré, il déclenche un processus d’agrégation de conformité qui met à jour l’état de conformité de toutes les associations sur ce nœud. La valeur `ExecutionTime` figurant dans les rapports de conformité représente le moment où l’état de conformité a été capturé par Systems Manager, et non le moment où l’association a été exécutée sur le nœud géré. Cela signifie que plusieurs associations peuvent afficher des valeurs `ExecutionTime` identiques, même si elles ont été exécutées à des moments différents. Pour déterminer les temps d'exécution réels de l'association, consultez l'historique d'exécution de l'association à l'aide de la AWS CLI commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html)ou en consultant les détails de l'exécution dans la console.
## A propos de la conformité personnalisée
Vous pouvez attribuer des métadonnées de conformité à un nœud géré. Ces métadonnées peuvent ensuite être regroupées avec d'autres données de conformité à des fins de génération de rapports sur la conformité. Supposons par exemple que votre entreprise exécute les versions 2.0, 3.0 et 4.0 du logiciel X sur vos nœuds gérés. L'entreprise veut procéder à une normalisation dans la version 4.0, ce qui signifie que les instances qui exécutent les versions 2.0 et 3.0 ne sont pas conformes. Vous pouvez utiliser l'opération [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API pour indiquer explicitement quels nœuds gérés exécutent d'anciennes versions du logiciel X. Vous ne pouvez attribuer des métadonnées de conformité qu'en utilisant le AWS CLI AWS Tools for Windows PowerShell, ou le SDKs. L'exemple suivant de commande d'interface de ligne de commande attribue des métadonnées de conformité à une instance gérée et spécifie le type de conformité au format requis `Custom:`. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id i-1234567890abcdef0 \
--resource-type ManagedInstance \
--compliance-type Custom:SoftwareXCheck \
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate \
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id i-1234567890abcdef0 ^
--resource-type ManagedInstance ^
--compliance-type Custom:SoftwareXCheck ^
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate ^
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
**Note**
Le paramètre `ResourceType` prend uniquement en charge `ManagedInstance`. Si vous ajoutez une conformité personnalisée à un appareil principal AWS IoT Greengrass géré, vous devez spécifier un `ResourceType` de `ManagedInstance`.
Les gestionnaires de la conformité peuvent ensuite afficher des récapitulatifs ou créer des rapports sur les nœuds gérés conformes ou non. Vous pouvez attribuer au maximum 10 types différents de conformité personnalisée à un nœud géré.
Pour obtenir un exemple montrant comment créer un type de conformité personnalisée et afficher les données de conformité, consultez [Attribuez des métadonnées de conformité personnalisées à l'aide du AWS CLI](compliance-custom-metadata-cli.md).
## Affichage des données de conformité actuelles
Cette section explique comment afficher les données de conformité dans la console Systems Manager et à l'aide de la AWS CLI. Pour de plus amples informations sur l'affichage du suivi des modifications, ainsi que de l'historique de conformité des associations et des correctifs, veuillez consulter [Affichage du suivi des modifications et de l'historique de configuration de la conformité](#compliance-history).
**Topics**
+ [Affichage des données de conformité actuelles (console)](#compliance-view-results-console)
+ [Affichage des données de conformité actuelles (AWS CLI)](#compliance-view-data-cli)
### Affichage des données de conformité actuelles (console)
Utilisez la procédure suivante pour afficher les données de conformité dans la console Systems Manager.
**Pour afficher les rapports de conformité actuelle dans la 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 **Compliance (Conformité)**.
1. Dans la section **Compliance dashboard filtering (Filtrage du tableau de bord de conformité)**, sélectionnez une option pour filtrer les données de conformité. La section **Compliance resources summary (Synthèse des ressources de conformité)** affiche le nombre de données de conformité en fonction du filtre que vous avez choisi.
1. Pour explorer une ressource en détail, faites défiler vers le bas jusqu'à la zone **Details overview for resources (Vue d'ensemble détaillée des ressources)** et sélectionnez l'ID d'un nœud géré.
1. Sur la page **Instance ID (ID d'instance)** ou **Name (Nom)**, sélectionnez l'onglet **Configuration compliance (Conformité de la configuration)** afin d'afficher un rapport détaillé de conformité de la configuration pour le nœud géré.
**Note**
Pour de plus amples informations sur la résolution des problèmes de conformité, veuillez consulter [Résolution des problèmes de conformité avec EventBridge](compliance-fixing.md).
### Affichage des données de conformité actuelles (AWS CLI)
Vous pouvez consulter les résumés des données de conformité pour les correctifs, les associations et les types de conformité personnalisés dans le in à l'aide AWS CLI des commandes suivantes AWS CLI .
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html)
Renvoie un décompte récapitulatif des statuts d'association conformes et non conformes en fonction du filtre que vous spécifiez. (API : [ListComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListComplianceSummaries.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html)
Renvoie un récapitulatif du nombre au niveau des ressources. Ce récapitulatif inclut des informations sur les statuts Conforme et Non conforme et les nombres détaillés de sévérité de l'élément de conformité, en fonction des critères de filtre que vous spécifiez. (API : [ListResourceComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListResourceComplianceSummaries.html))
Vous pouvez afficher des données de conformité supplémentaires pour l'application de correctifs à l'aide des commandes d' AWS CLI suivantes.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html)
Renvoie l'état des informations globales de conformité des correctifs pour un groupe de correctifs. (API : [DescribePatchGroupState](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchGroupState.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html)
Renvoie l'état des correctifs de haut niveau pour les instances du groupe de correctifs spécifié. (API : [DescribeInstancePatchStatesForPatchGroup](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatchStatesForPatchGroup.html))
**Note**
Pour une illustration de la configuration des correctifs et pour consulter les détails de conformité des correctifs à l'aide du AWS CLI, voir[Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
## Affichage du suivi des modifications et de l'historique de configuration de la conformité
Le service Systems Manager Compliance affiche les données *actuelles* de conformité des associations et de l'application de correctifs pour vos nœuds gérés. Vous pouvez consulter l'historique de conformité des correctifs et des associations ainsi que le suivi des modifications en utilisant [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/). AWS Config fournit une vue détaillée de la configuration des AWS ressources de votre Compte AWS. Elle indique comment les ressources sont liées entre elles et comment elles ont été configurées dans le passé, pour que vous puissiez observer comment les configurations et les relations changent au fil du temps. Pour afficher le suivi des modifications et l'historique des associations et de l'application de correctifs, vous devez activer les ressources suivantes dans AWS Config :
+ `SSM:PatchCompliance`
+ `SSM:AssociationCompliance`
Pour de plus amples informations sur le choix et la configuration de ces ressources spécifiques dans AWS Config, veuillez consulter [Sélection des ressources enregistrées par AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) dans le *Guide du développeur AWS Config *.
**Note**
Pour plus d'informations sur la AWS Config tarification, consultez la section [Tarification](https://aws.amazon.com/config/pricing/).
# Suppression d'une synchronisation de données de ressources pour le service Conformité
Si vous ne souhaitez plus utiliser AWS Systems Manager Compliance pour consulter les données de conformité, nous vous recommandons également de supprimer les synchronisations des données de ressources utilisées pour la collecte des données de conformité.
**Pour supprimer une synchronisation de données de ressources Compliance**
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. Sélectionnez **Account management (Gestion de compte)**, **Resource data syncs (Synchronisation de données de ressources)**.
1. Dans la liste, sélectionnez une synchronisation.
**Important**
Veillez à bien choisir la synchronisation utilisée pour le service Conformité. Systems Manager prend en charge la synchronisation de données de ressources pour plusieurs outils. Si vous choisissez la mauvaise synchronisation, vous risquez de perturber l'agrégation des données pour Systems Manager Explorer ou Systems Manager Inventory.
1. Sélectionnez **Delete (Supprimer)**.
1. Supprimez le compartiment Amazon Simple Storage Service (Amazon S3) dans lequel les données ont été enregistrées. Pour obtenir des informations sur la suppression d'un compartiment Amazon S3, consultez [Deleting a bucket (Suppression d'un compartiment)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Résolution des problèmes de conformité avec EventBridge
Vous pouvez corriger rapidement les problèmes de conformité des correctifs et des associations en utilisant la fonctionnalité Run Command, un outil d’AWS Systems Manager. Vous pouvez cibler une instance ou les ID ou balises des appareils principaux AWS IoT Greengrass et exécutez le document `AWS-RunPatchBaseline` ou `AWS-RefreshAssociation`. Si actualiser l'association ou exécuter à nouveau le référentiel de correctif ne permet pas de résoudre le problème de conformité, vous devez vérifier vos associations, référentiels de correctifs ou configurations d'instance pour comprendre pourquoi les opérations Run Command n'ont pas permis de résoudre le problème.
Pour de plus amples informations sur l'application de correctifs, veuillez consulter [AWS Systems Manager Patch Manager](patch-manager.md) et [Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
Pour de plus amples informations sur les associations, veuillez consulter [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
Pour de plus amples informations sur l'exécution d'une commande, veuillez consulter [AWS Systems Manager Run Command](run-command.md).
**Spécifier Compliance comme cible d'un événement EventBridge**
Vous pouvez également configurer Amazon EventBridge pour effectuer une action en réponse à des événements Systems Manager Compliance. Par exemple, si un ou plusieurs nœuds gérés ne parviennent pas à installer des mises à jour de correctif critiques ou à exécuter une association qui installe un logiciel antivirus, vous pouvez configurer EventBridge pour exécuter le document `AWS-RunPatchBaseline` ou `AWS-RefreshAssocation` lorsque l'événement Compliance se produit.
Utilisez la procédure suivante afin de configurer Compliance comme cible d'un événement EventBridge.
**Pour configurer Compliance comme cible d'un événement EventBridge (console)**
1. Ouvrez la console Amazon EventBridge à l’adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Dans le volet de navigation, choisissez **Rules**.
1. Choisissez **Créer une règle**.
1. Saisissez un nom et une description pour la règle.
Une règle ne peut pas avoir le même nom qu'une autre règle de la même Région AWS et sur le même bus d'événement.
1. Pour **Event bus** (Bus d'événement), sélectionnez le bus d'événement que vous souhaitez associer à cette règle. Si vous souhaitez que cette règle s'applique aux événements correspondants provenant de votre propre Compte AWS, sélectionnez **défaut**. Lorsqu'un Service AWS de votre compte émet un événement, il accède toujours au bus d'événement par défaut de votre compte.
1. Pour **Rule type** (Type de règle), choisissez **Rule with an event pattern** (Règle avec un modèle d'événement).
1. Choisissez **Suivant**.
1. Pour **Event source** (Origine de l'événement), choisissez ** events or EventBridge partner events** (Événements AWS ou événements partenaires EventBridge).
1. Dans la section **Event pattern** (Modèle d'événement), choisissez **Event pattern form** (Modèle d'événement).
1. Pour **Event source** (Origine de l'événement), choisissez **AWSservices** (Services ).
1. Pour le **AWS service** choisissez **Systems Manager**.
1. Dans le champ **Event type (Type d'événement)**, sélectionnez **Configuration Compliance (Conformité de configuration)**.
1. Pour **Specific detail type(s)** (Type(s) de détails spécifiques), choisissez **Configuration Compliance State Change** (Changements d'état de la conformité de configuration).
1. Choisissez **Suivant**.
1. Pour **Types de cibles**, choisissez **service AWS**.
1. Pour **Target** (Cible), sélectionnez **Systems Manager Run Command**.
1. Dans la liste **Document**, sélectionnez un document Systems Manager (document SSM) à exécuter lorsque la cible sera invoquée. Par exemple, sélectionnez `AWS-RunPatchBaseline` pour un événement de correctif non conforme, ou `AWS-RefreshAssociation` pour un événement d'association non conforme.
1. Spécifiez les informations pour les champs et paramètres restants.
**Note**
Les champs et paramètres requis sont dotés d'une astérisque (\$1) en regard de leur nom. Pour créer une cible, vous devez spécifier une valeur pour chaque paramètre ou champ requis. Si vous ne le faites pas, le système crée la règle mais elle n'est pas exécutée.
1. Choisissez **Suivant**.
1. (Facultatif) Saisissez une ou plusieurs balises pour la règle. Pour plus d'informations, consultez [Balisage de vos ressources Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) dans le *Guide de l'utilisateur Amazon EventBridge*.
1. Choisissez **Suivant**.
1. Consultez les détails de la règle et choisissez **Create rule** (Créer une règle).
# Attribuez des métadonnées de conformité personnalisées à l'aide du AWS CLI
La procédure suivante explique comment utiliser le AWS Command Line Interface (AWS CLI) pour appeler l'opération AWS Systems Manager [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API afin d'attribuer des métadonnées de conformité personnalisées à une ressource. Vous pouvez aussi utiliser cette opération d'API pour attribuer manuellement des métadonnées de conformité des correctifs ou des associations à un nœud géré, comme indiqué dans la démonstration suivante. Pour de plus amples informations sur la conformité personnalisée, consultez [A propos de la conformité personnalisée](compliance-about.md#compliance-custom).
**Pour attribuer des métadonnées de conformité personnalisée à une instance gérée (AWS CLI)**
1. 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).
1. Exécutez la commande suivante pour attribuer des métadonnées de conformité personnalisée à un nœud géré. Remplacez chaque *example resource placeholder* par vos propres informations. Le paramètre `ResourceType` ne prend en charge qu'une valeur de `ManagedInstance`. Spécifiez cette valeur même si vous attribuez des métadonnées de conformité personnalisées à un appareil AWS IoT Greengrass principal géré.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Custom:user-defined_string \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Custom:user-defined_string ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
1. Répétez l'étape précédente pour attribuer des métadonnées supplémentaires de conformité personnalisée à un ou plusieurs nœuds. Vous pouvez aussi utiliser les commandes suivantes pour attribuer manuellement des métadonnées de conformité des correctifs ou des associations à des nœuds gérés :
Métadonnées de conformité des associations
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Association \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Association ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
Métadonnées de conformité des correctifs
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Patch \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command \
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Patch ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command ^
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
1. Exécutez la commande suivante pour afficher la liste des éléments de conformité pour un nœud géré spécifique. Utilisez des filtres pour explorer en détail des données de conformité spécifiques.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids instance_ID \
--resource-types ManagedInstance \
--filters one_or_more_filters
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids instance_ID ^
--resource-types ManagedInstance ^
--filters one_or_more_filters
```
------
Les exemples suivants vous montrent comment utiliser cette commande avec des filtres.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids i-02573cafcfEXAMPLE \
--resource-type ManagedInstance \
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids i-02573cafcfEXAMPLE ^
--resource-type ManagedInstance ^
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
1. Exécutez la commande suivante pour afficher un récapitulatif des statuts de conformité. Utilisez des filtres pour explorer en détail des données de conformité spécifiques.
```
aws ssm list-resource-compliance-summaries --filters One or more filters.
```
Les exemples suivants vous montrent comment utiliser cette commande avec des filtres.
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=ExecutionType,Values=Command
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=ExecutionType,Values=Command
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
1. Exécutez la commande suivante pour afficher un récapitulatif du nombre de ressources conformes et non conformes pour un type de conformité. Utilisez des filtres pour explorer en détail des données de conformité spécifiques.
```
aws ssm list-compliance-summaries --filters One or more filters.
```
Les exemples suivants vous montrent comment utiliser cette commande avec des filtres.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
# AWS Systems Manager Distributor
Distributor, un outil de AWS Systems Manager, vous aide à empaqueter et à publier des logiciels sur des nœuds AWS Systems Manager gérés. Vous pouvez empaqueter et publier votre propre logiciel ou l'utiliser Distributor pour rechercher et publier des packages logiciels d'agent AWS fournis **AmazonCloudWatchAgent**, tels que des packages tiers tels que **Trend Micro**.La publication d'un package annonce des versions spécifiques du document du package aux nœuds gérés que vous identifiez à l'aide d'un nœud IDs Compte AWS IDs, de balises ou d'un Région AWS. Pour vos premiers pas dans Distributor, ouvrez [Systems Manager console](https://console.aws.amazon.com//systems-manager/distributor). Dans le panneau de navigation, sélectionnez **Distributor**.
Après avoir créé un package dans Distributor, vous pouvez l'installer de l'une des manières suivantes :
+ Une seule fois en utilisant [AWS Systems Manager Run Command](run-command.md)
+ Selon une planification en utilisant [AWS Systems Manager State Manager](systems-manager-state.md)
**Important**
Les packages distribués par des vendeurs tiers ne sont pas gérés par le fournisseur du package AWS et sont publiés par celui-ci. Nous vous encourageons à faire preuve d’une diligence raisonnable supplémentaire pour garantir la conformité avec vos contrôles de sécurité internes. La sécurité est une responsabilité partagée entre vous AWS et vous. Cela est décrit comme un modèle de responsabilité partagée. Pour en savoir plus, consultez le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).
## Comment mon organisation peut-elle tirer parti de Distributor ?
Distributor offre les avantages suivants :
+ **Un package, de nombreuses plateformes**
Lorsque vous créez un package dans Distributor, le système crée un document AWS Systems Manager (document SSM). Vous pouvez joindre des fichiers .zip à ce document. Lorsque vous exécutez Distributor, le système traite les instructions du document SSM et installe le package logiciel contenu dans le fichier .zip sur les cibles spécifiées. Distributor prend en charge différents systèmes d'exploitation, comme Windows, Ubuntu Server, Debian Server et Red Hat Enterprise Linux. Pour de plus amples informations sur les plateformes prises en charge, veuillez consulter [Architectures et plateformes de package prises en charge](#what-is-a-package-platforms).
+ **Contrôle de l'accès au package à partir de groupes d'instances gérées**
Vous pouvez utiliser Run Command ou State Manager pour désigner les nœuds gérés qui doivent bénéficier d’un package ainsi que la version de ce package. Run Command et State Manager sont des outils d’ AWS Systems Manager. Les nœuds gérés peuvent être regroupés par instance ou par appareil IDs, par Compte AWS numéro, par tag ou Régions AWS. Vous pouvez utiliser des associations State Manager pour diffuser différentes versions d'un package à différents groupes d'instances.
+ **De nombreux packages d' AWS agents inclus et prêts à l'emploi**
Distributorinclut de nombreux packages d' AWS agents prêts à être déployés sur des nœuds gérés. Sur la page de la liste `Packages` Distributor, recherchez les packages publiés par `Amazon`. Exemples : `AmazonCloudWatchAgent` et `AWSPVDriver`.
+ **Automatisation du déploiement**
Pour maintenir votre environnement à jour, utilisez State Manager afin de planifier le déploiement automatique des packages sur les nœuds gérés cibles lors du premier lancement de ces derniers.
## À qui est destiné Distributor ?
+ Tout AWS client souhaitant créer de nouveaux packages logiciels ou déployer des packages logiciels existants, y compris des packages AWS publiés, sur plusieurs nœuds gérés par Systems Manager à la fois.
+ Les développeurs de logiciels qui créent des packages logiciels.
+ Administrateurs chargés de maintenir les nœuds gérés par Systems Manager à jour avec la plupart des packages up-to-date logiciels.
## Quelles sont les fonctions d'Distributor ?
+ **Déploiement de packages sur les instances Windows et Linux**
AvecDistributor, vous pouvez déployer des packages logiciels sur des instances Amazon Elastic Compute Cloud (Amazon EC2) et des appareils principaux pour AWS IoT Greengrass Linux et. Windows Server Pour obtenir une liste des types de systèmes d'exploitation d'instances pris en charge, consultez [Architectures et plateformes de package prises en charge](#what-is-a-package-platforms).
**Note**
Distributor n'est pas pris en charge sur le système d'exploitation macOS.
+ **Déploiement de packages une seule fois ou selon un calendrier automatisé**
Vous pouvez choisir de déployer les packages une seule fois, selon une planification régulière, ou chaque fois que la version de package par défaut est remplacée par une autre version.
+ **Réinstallation complète des packages ou mises à jour sur place**
Pour installer une nouvelle version de package, vous pouvez désinstaller complètement la version actuelle et en installer une nouvelle à la place. Vous pouvez également seulement mettre à jour la version actuelle avec des composants nouveaux et mis à jour, conformément à un *script de mise à jour* que vous fournissez. Votre application de package n'est pas disponible lors d'une réinstallation, mais elle peut rester disponible lors d'une mise à jour sur place. Les mises à jour sur place sont particulièrement utiles pour les applications de surveillance de la sécurité ou d'autres scénarios dans lesquels vous devez éviter les temps d'arrêt des applications.
+ **Accès aux fonctionnalités par console PowerShell, CLI et SDK Distributor**
Vous pouvez travailler avec en Distributor utilisant la console Systems Manager AWS Command Line Interface (AWS CLI) ou le AWS SDK de votre choix. Outils AWS pour PowerShell
+ **Contrôle d'accès IAM**
En utilisant des politiques Gestion des identités et des accès AWS (IAM), vous pouvez contrôler quels membres de votre organisation peuvent créer, mettre à jour, déployer ou supprimer des packages ou des versions de packages. Par exemple, vous pouvez accorder à un administrateur l'autorisation de déployer des packages, mais pas celle de modifier les packages ou de créer de nouvelles versions de package.
+ **Prise en charge de la capacité de journalisation et d'audit**
Vous pouvez auditer et enregistrer les actions des Distributor utilisateurs dans votre compte Compte AWS grâce à l'intégration avec d'autres Services AWS. Pour de plus amples informations, veuillez consulter [Audit et journalisation de l'activité de Distributor](distributor-logging-auditing.md).
## Qu’est-ce qu’un package dans Distributor ?
Un *package* est un ensemble de logiciels ou de ressources installables, qui inclut les éléments suivants :
+ Un fichier .zip de logiciels par plateforme de système d'exploitation cible. Chaque fichier .zip doit contenir les éléments suivants :
+ Un **install** et un **uninstall** script. Windows Serverles nœuds gérés basés sur la PowerShell technologie nécessitent des scripts (scripts nommés `install.ps1` et`uninstall.ps1`). Les nœuds gérés basés sur Linux nécessitent des scripts shell (scripts nommés `install.sh` et). `uninstall.sh` AWS Systems Manager SSM Agentlit et exécute les instructions contenues dans les **uninstall** scripts **install** et.
+ Un fichier exécutable. SSM Agent doit trouver ce fichier exécutable pour installer le package sur les nœuds gérés cibles.
+ Un fichier manifeste au format JSON qui décrit le contenu du package. Le manifeste n'est pas inclus dans le fichier .zip, mais il est stocké dans le même compartiment Amazon Simple Storage Service (Amazon S3) que les fichiers .zip qui constituent le package. Le manifeste identifie la version du package et mappe les fichiers .zip du package sur les attributs du nœud géré cible, tels que la version du système d'exploitation ou l'architecture. Pour de plus amples informations sur la création du manifeste, veuillez consulter [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
Lorsque vous sélectionnez le package de création **Simple** dans la console Distributor, Distributor génère les scripts d'installation et de désinstallation, les hachages de fichier, ainsi que le manifeste de package JSON pour vous, en fonction du nom du fichier exécutable de logiciel, et des plateformes et architectures cibles.
### Architectures et plateformes de package prises en charge
Vous pouvez utiliser Distributor pour publier des packages sur les plateformes de nœuds gérés Systems Manager suivantes. Une valeur de version doit correspondre à la version exacte de l'Amazon Machine Image (AMI) du système d'exploitation que vous ciblez. Pour de plus amples informations sur la détermination de cette version, veuillez consulter l'étape 4 de [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
**Note**
Systems Manager ne prend pas en charge tous les systèmes d'exploitation suivants pour les appareils AWS IoT Greengrass principaux. Pour plus d'informations, consultez la section [Configuration des appareils AWS IoT Greengrass principaux](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) dans le *Guide du AWS IoT Greengrass Version 2 développeur*.
| Plateforme | Valeur de code dans le fichier manifeste | Architectures prises en charge |
| --- | --- | --- |
| AlmaLinux | almalinux | x86\$164 ARM64 |
| Amazon Linux 2 et Amazon Linux 2023 | `amazon` | x86\$164 ou x86 ARM64(types d'instances Amazon Linux 2 et AL2023 A1) |
| Debian Server | `debian` | x86\$164 ou x86 |
| openSUSE | `opensuse` | x86\$164 |
| openSUSE Leap | `opensuseleap` | x86\$164 |
| Oracle Linux | `oracle` | x86\$164 |
| Red Hat Enterprise Linux (RHEL) | `redhat` | x86\$164 ARM64 (RHEL 7.6 et versions ultérieures, types d'instances A1) |
| Rocky Linux | rocky | x86\$164 ARM64 |
| SUSE Linux Enterprise Server (SLES) | `suse` | x86\$164 |
| Ubuntu Server | `ubuntu` | x86\$164 ou x86 ARM64 (Ubuntu Server 16 et versions ultérieures, types d'instances A1) |
| Windows Server | `windows` | x86\$164 |
**Topics**
+ [Comment mon organisation peut-elle tirer parti de Distributor ?](#distributor-benefits)
+ [À qui est destiné Distributor ?](#distributor-who)
+ [Quelles sont les fonctions d'Distributor ?](#distributor-features)
+ [Qu’est-ce qu’un package dans Distributor ?](#what-is-a-package)
+ [Configuration de Distributor](distributor-getting-started.md)
+ [Utilisation des packages Distributor](distributor-working-with.md)
+ [Audit et journalisation de l'activité de Distributor](distributor-logging-auditing.md)
+ [Résolution des problèmes AWS Systems ManagerDistributor](distributor-troubleshooting.md)
# Configuration de Distributor
Avant d'utiliser Distributor un outil pour créer AWS Systems Manager, gérer et déployer des packages logiciels, procédez comme suit.
## Exécuter les opérations Distributor prérequises
Avant d'utiliser Distributor un outil AWS Systems Manager, assurez-vous que votre environnement répond aux exigences suivantes.
**conditions préalables requises de l’Distributor**
| Exigence | Description |
| --- | --- |
| SSM Agent | AWS Systems Manager SSM Agentla version 2.3.274.0 ou ultérieure doit être installée sur les nœuds gérés sur lesquels vous souhaitez déployer ou dont vous souhaitez supprimer des packages. Pour installer ou mettre à jour SSM Agent, consultez [Utilisation de l’option SSM Agent](ssm-agent.md). |
| AWS CLI | (Facultatif) Pour utiliser le AWS Command Line Interface (AWS CLI) au lieu de la console Systems Manager pour créer et gérer des packages, installez la dernière version de AWS CLI celui-ci sur votre ordinateur local. Pour de plus amples informations sur l'installation ou la mise à niveau de la CLI, veuillez consulter [Installation de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) dans le*Guide de l'utilisateur AWS Command Line Interface *. |
| Outils AWS pour PowerShell | (Facultatif) Pour utiliser les outils PowerShell plutôt que la console Systems Manager pour créer et gérer des packages, installez la dernière version de Tools for PowerShell sur votre ordinateur local. Pour plus d'informations sur l'installation ou la mise à niveau des outils pour PowerShell, reportez-vous à la section [Configuration du AWS Tools for Windows PowerShell ou AWS Tools for PowerShell Core](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html) dans le *Guide de Outils AWS pour PowerShell l'utilisateur*. |
**Note**
Systems Manager ne prend pas en charge la distribution de packages aux nœuds gérés Oracle Linux à l'aide de Distributor.
## Vérifier ou créer un profil d’instance IAM avec des autorisations Distributor
Par défaut, AWS Systems Manager n'est pas autorisé à effectuer des actions sur vos instances. Vous devez accorder l'accès à l'aide d'un profil d'instance Gestion des identités et des accès AWS (IAM). Un profil d'instance est un conteneur qui transmet des informations sur le rôle IAM à une instance Amazon Elastic Compute Cloud (Amazon EC2) lors du lancement. Cette exigence s’applique aux autorisations relatives à tous les outils Systems Manager, et non pas uniquement Distributor.
**Note**
Lorsque vous configurez vos périphériques périphériques pour exécuter le logiciel AWS IoT Greengrass CoreSSM Agent, vous spécifiez un rôle de service IAM qui permet à Systems Manager d'effectuer des actions sur celui-ci. Il n'est pas nécessaire de configurer les appareils de périphérie gérés avec un profil d'instance.
Si vous utilisez déjà d’autres outils Systems Manager, par exemple, Run Command et State Manager, un profil d’instance avec les autorisations requises pour Distributor est déjà attaché à vos instances. Le moyen le plus simple de vous assurer que vous êtes autorisé à effectuer Distributor des tâches consiste à associer la SSMManaged InstanceCore politique **Amazon** à votre profil d'instance. Pour plus d’informations, consultez la section [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
## Contrôler l’accès des utilisateurs aux packages
À l'aide de politiques Gestion des identités et des accès AWS (IAM), vous pouvez contrôler qui peut créer, déployer et gérer des packages. Vous pouvez également contrôler les opérations d'API Run Command et State Manager que les utilisateurs sont autorisés à exécuter sur les nœuds gérés. Par exempleDistributor, les deux Run Command etState Manager, y a-t-il des outils dedans AWS Systems Manager.
**Format ARN**
Les packages définis par l'utilisateur sont associés au document Amazon Resource Names (ARNs) et ont le format suivant.
```
arn:aws:ssm:region:account-id:document/document-name
```
Voici un exemple.
```
arn:aws:ssm:us-west-1:123456789012:document/ExampleDocumentName
```
Vous pouvez utiliser deux politiques IAM par défaut AWS fournies, l'une pour les utilisateurs finaux et l'autre pour les administrateurs, afin d'accorder des autorisations pour les Distributor activités. Vous pouvez également créer des politiques IAM personnalisées appropriées, répondant à vos exigences en matière d'autorisations.
Pour de plus amples informations sur l'utilisation de variables dans les politiques IAM, consultez [Éléments de politique IAM : Variables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
Pour obtenir des informations sur la création de politiques et la façon de les attacher à des utilisateurs ou des groupes, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) et [Ajout et suppression de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.
## Créer ou choisir un compartiment Amazon S3 pour stocker les packages Distributor
Lorsque vous créez un package en utilisant le flux de travail **Simple** dans la console AWS Systems Manager , vous sélectionnez un compartiment Amazon Simple Storage Service (Amazon S3) existant dans lequel Distributor charge votre logiciel. Distributor est un outil d’ AWS Systems Manager. Dans le flux de travail **Advanced (Avancé)**, vous devez charger les fichiers .zip de vos logiciels ou ressources dans un compartiment Amazon S3 avant de commencer. Si vous créez un package à l'aide des flux de travail **Simple** ou **Advanced (Avancé)** dans la console, ou à l'aide de l'API, vous devez avoir un compartiment Amazon S3 avant de commencer à créer votre package. Dans le cadre du processus de création de package, Distributor copie vos logiciels et ressources à installer à partir de ce compartiment vers un magasin Systems Manager interne. Étant donné que les ressources sont copiées vers un magasin interne, vous pouvez supprimer ou réutiliser votre compartiment Amazon S3 lors de la création du package est terminée.
Pour plus d'informations sur la création d'un compartiment, veuillez consulter [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Guide de mise en route Amazon Simple Storage Service*. Pour plus d'informations sur la façon d'exécuter une AWS CLI commande pour créer un bucket, consultez [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)la *référence des AWS CLI commandes*.
# Utilisation des packages Distributor
Vous pouvez utiliser la console AWS Systems Manager, les outils de ligne de commande AWS (AWS CLI et Outils AWS pour PowerShell) et les kits SDK AWS pour ajouter, gérer ou déployer des packages dans Distributor. Distributor est un outil d’AWS Systems Manager. Avant d'ajouter un package à Distributor :
+ Créez et zippez les ressources à installer.
+ (Facultatif) Créez un fichier manifeste JSON pour le package. Il n'est pas obligatoire d'utiliser le processus de création de package **Simple** dans la console Distributor. La création du package Simple génère un fichier manifeste JSON pour vous.
Vous pouvez utiliser la console AWS Systems Manager, un éditeur de texte ou un éditeur JSON pour créer le fichier manifeste.
+ Prévoyez un compartiment Amazon Simple Storage Service (Amazon S3) pour stocker vos ressources ou logiciels installables. Si vous utilisez le processus de création de package **Advanced (Avancé)**, chargez vos ressources dans le compartiment Amazon S3 avant de commencer.
**Note**
Vous pouvez supprimer ou réutiliser ce compartiment après avoir créé votre package, car Distributor déplace le contenu du package vers un compartiment Systems Manager interne dans le cadre du processus de création de package.
Les packages publiés par AWS sont déjà conditionnés et prêts pour le déploiement. Pour déployer un package publié par AWS sur des nœuds gérés, consultez [Installer ou mettre à jour des packages Distributor](distributor-working-with-packages-deploy.md).
Vous pouvez partager des packages Distributor entre des Comptes AWS. Lors de l'utilisation d'un package partagé à partir d'un autre compte dans des commandes AWS CLI, utilisez l'Amazon Resource Name (ARN) du package plutôt que son nom.
**Topics**
+ [Afficher les packages dans l’application Distributor](distributor-view-packages.md)
+ [Créer un package dans Distributor](distributor-working-with-packages-create.md)
+ [Modifier les autorisations du package Distributor dans la console](distributor-working-with-packages-ep.md)
+ [Modifier les balises de package Distributor dans la console](distributor-working-with-packages-tags.md)
+ [Ajouter une version à un package Distributor](distributor-working-with-packages-version.md)
+ [Installer ou mettre à jour des packages Distributor](distributor-working-with-packages-deploy.md)
+ [Désinstaller un package Distributor](distributor-working-with-packages-uninstall.md)
+ [Supprimer un package Distributor](distributor-working-with-packages-dpkg.md)
# Afficher les packages dans l’application Distributor
Pour afficher les packages disponibles pour l'installation, vous pouvez utiliser la AWS Systems Manager console ou l'outil de ligne de AWS commande de votre choix. Distributorest un outil dans AWS Systems Manager. Pour y accéderDistributor, ouvrez la AWS Systems Manager console et choisissez **Distributor**dans le volet de navigation de gauche. Vous verrez s'afficher tous les forfaits disponibles.
La section suivante décrit l'affichage de packages Distributor en utilisant votre outil de ligne de commande préféré.
## Afficher les packages à l’aide de la ligne de commande
Cette section contient des informations sur l'utilisation de votre outil de ligne de commande préféré pour afficher des packages Distributor à l'aide des commandes fournies.
------
#### [ Linux & macOS ]
**Pour consulter les packages à AWS CLI l'aide du**
+ Pour afficher tous les packages, à l'exclusion des packages partagés, exécutez la commande suivante.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package
```
+ Pour afficher tous les packages appartenant à Amazon, exécutez la commande suivante.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Pour afficher tous les packages appartenant à des tiers, exécutez la commande suivante.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ Windows ]
**Pour consulter les packages à AWS CLI l'aide du**
+ Pour afficher tous les packages, à l'exclusion des packages partagés, exécutez la commande suivante.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package
```
+ Pour afficher tous les packages appartenant à Amazon, exécutez la commande suivante.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Pour afficher tous les packages appartenant à des tiers, exécutez la commande suivante.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ PowerShell ]
**Pour afficher les packages à l'aide des outils pour PowerShell**
+ Pour afficher tous les packages, à l'exclusion des packages partagés, exécutez la commande suivante.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "DocumentType"
$filter.Values = "Package"
Get-SSMDocumentList `
-Filters @($filter)
```
+ Pour afficher tous les packages appartenant à Amazon, exécutez la commande suivante.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "Amazon"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
+ Pour afficher tous les packages appartenant à des tiers, exécutez la commande suivante.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "ThirdParty"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
------
# Créer un package dans Distributor
Pour créer un package, préparez vos logiciels ou ressources installables, un fichier ZIP par plateforme de système d'exploitation. Vous devez disposer d'au moins un fichier pour créer un package.
Différentes plateformes peuvent parfois utiliser le même fichier, mais tous les fichiers que vous attachez à votre package doivent être répertoriés dans la section `Files` du manifeste. Si vous créez un package en utilisant le flux de travail simple dans la console, le manifeste est généré pour vous. Le nombre maximum de fichiers que vous pouvez attacher à un seul document est de 20. La taille maximale d'un fichier est de 1 Go. Pour de plus amples informations sur les plateformes prises en charge, veuillez consulter [Architectures et plateformes de package prises en charge](distributor.md#what-is-a-package-platforms).
Lorsque vous créez un package, le système crée un nouveau [document SSM](documents.md). Ce document vous permet de déployer le package sur des nœuds gérés.
À des fins de démonstration uniquement, un exemple de package, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), est disponible en téléchargement sur notre site Web. Le package d'exemple inclut un manifeste JSON complet et trois fichiers .zip contenant les programmes d'installation pour PowerShell la version 7.0.0. Les scripts d'installation et de désinstallation ne contiennent pas de commandes valides. Même si vous devez zipper chacun des fichiers installables de logiciel et des scripts dans un fichier .zip pour créer un package dans le flux de travail **Advanced (Avancé)**, vous ne zippez pas les ressources installables dans le flux de travail **Simple**.
**Topics**
+ [Créer un package à l’aide du flux de travail simple](#distributor-working-with-packages-create-simple)
+ [Créer un package à l’aide du flux de travail avancé](#distributor-working-with-packages-create-adv)
## Créer un package à l’aide du flux de travail simple
Cette section décrit comment créer un package dans Distributor en choisissant le flux de travail de création de package **Simple** dans la console Distributor. Distributor est un outil d’ AWS Systems Manager. Pour créer un package, préparez vos ressources installables, un fichier par plateforme de système d'exploitation. Vous devez disposer d'au moins un fichier pour créer un package. Le processus de création de package **Simple** génère des scripts d'installation et de désinstallation, des hachages de fichier et un manifeste au format JSON pour vous. Le flux de travail **Simple** gère le processus de chargement et de zip de vos fichiers installables, ainsi que la création d'un nouveau package et du [document SSM](documents.md) associé. Pour de plus amples informations sur les plateformes prises en charge, veuillez consulter [Architectures et plateformes de package prises en charge](distributor.md#what-is-a-package-platforms).
Lorsque vous utilisez la méthode Simple pour créer un package, Distributor crée des scripts `install` et `uninstall`. Toutefois, lorsque vous créez un package pour une mise à jour sur place, vous devez fournir votre propre contenu de script `update` dans l'onglet **Update script (Script de mise à jour)**. Lorsque vous ajoutez des commandes d'entrée pour un script `update`, Distributor inclut ce script dans le package .zip qu'il crée, avec les scripts `uninstall` et `install`.
**Note**
Utilisez l'option de mise à jour `In-place` pour ajouter des fichiers nouveaux ou mis à jour à une installation de package existante sans mettre l'application associée hors connexion.
**Pour créer un package à l’aide du flux de travail simple**
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 **Distributor**.
1. Sur la page d'accueil de Distributor, sélectionnez **Create package (Créer un package)**, puis **Simple**.
1. Sur la page **Create package (Créer un package)**, entrez un nom pour votre package. Les noms de package peuvent contenir des lettres, des chiffres, des points, des tirets et des traits de soulignement. Le nom doit être suffisamment générique pour pouvoir s'appliquer à toutes les versions des pièces jointes du package, mais suffisamment spécifique pour identifier l'objectif du package.
1. (Facultatif) Pour **Version name (Nom de version)**, entrez un nom de version. Les noms de version peuvent comporter 512 caractères au maximum et ne peuvent pas contenir de caractères spéciaux.
1. Pour **Location (Emplacement)**, sélectionnez un compartiment en utilisant le nom et le préfixe du compartiment ou en utilisant son URL.
1. Dans **Upload software** (Charger un logiciel), sélectionnez **Add software** (Ajouter un logiciel), puis recherchez les fichiers de logiciels installables qui portent l'extension `.rpm`, `.msi` ou `.deb`. Si le nom de fichier contient des espaces, le téléchargement échoue. Vous pouvez charger plusieurs fichiers de logiciel en une seule action.
1. Pour **Target platform (Plateforme cible)**, vérifiez que la plateforme de système d'exploitation cible pour chaque fichier installable est correcte. Si le système d'exploitation indiqué n'est pas correct, sélectionnez le système d'exploitation approprié dans la liste déroulante.
Dans le flux de travail de création de package **Simple**, comme vous chargez chaque fichier installable une seule fois, des étapes supplémentaires sont nécessaires pour demander à Distributor de cibler un seul fichier sur plusieurs systèmes d'exploitation. Par exemple, si vous chargez un fichier de logiciel installable nommé `Logtool_v1.1.1.rpm`, vous devez modifier certaines valeurs par défaut dans le flux de travail **Simple** pour cibler le même logiciel sur les versions prises à jour des systèmes d’exploitation Amazon Linux et Ubuntu Server. Lorsque vous ciblez plusieurs plateformes, effectuez l'une des opérations suivantes.
+ Utilisez plutôt le flux de travail **Advanced (Avancé)**, zippez chaque fichier installable en un fichier .zip avant de commencer et créez manuellement le manifeste afin qu'un fichier installable puisse cibler plusieurs plateformes ou versions de système d'exploitation. Pour de plus amples informations, veuillez consulter [Créer un package à l’aide du flux de travail avancé](#distributor-working-with-packages-create-adv).
+ Modifiez manuellement le fichier manifeste dans le flux de travail **Simple** pour que votre fichier .zip cible plusieurs plateformes ou versions de système d'exploitation. Pour plus d'informations sur la façon de procéder, consultez la fin de l'étape 4 dans [Étape 2 : Création du manifeste de package JSON](#packages-manifest).
1. Pour **Platform version (Version de plateforme)**, vérifiez que la version de plateforme de système d'exploitation est **\$1any**, une version majeure suivie d'un caractère générique (7.\$1), ou la version de système d'exploitation exacte spécifique à laquelle vous souhaitez que votre logiciel s'applique. Pour plus d'informations sur la spécification d'une version de plateforme de système d'exploitation, consultez l'étape 4 de [Étape 2 : Création du manifeste de package JSON](#packages-manifest).
1. Pour **Architecture**, sélectionnez l'architecture de processeur correcte pour chaque fichier installable dans la liste déroulante. Pour plus d'informations sur les architectures de processeur prises en charge, consultez [Architectures et plateformes de package prises en charge](distributor.md#what-is-a-package-platforms).
1. (Facultatif) Développez **Scripts** et vérifiez les scripts générés par Distributor pour votre logiciel installable.
1. (Facultatif) Pour fournir un script de mise à jour à utiliser avec les mises à jour sur place, développez **Scripts**, sélectionnez l'onglet **Update script (Script de mise à jour)** et entrez vos commandes de script de mise à jour.
Systems Manager ne génère pas de scripts de mise à jour en votre nom.
1. Pour ajouter d'autres fichiers de logiciels installables, sélectionnez **Add software (Ajouter des logiciels)**. Sinon, accédez à l'étape suivante.
1. (Facultatif) Développez **Manifest (Manifeste)** et vérifiez le manifeste de package JSON généré par Distributor pour vos logiciels installables. Si vous avez modifié des informations relatives à vos logiciels depuis que vous avez commencé cette procédure, comme la version de plateforme ou la plateforme cible, sélectionnez **Generate manifest (Générer un manifeste)** pour afficher le manifeste de package mis à jour.
Vous pouvez modifier le manifeste manuellement si vous souhaitez cibler un logiciel installable pour plusieurs systèmes d'exploitation, comme décrit à l'étape 8. Pour plus d'informations sur la modification du manifeste, consultez [Étape 2 : Création du manifeste de package JSON](#packages-manifest).
1. Sélectionnez **Create package (Créer un package)**.
Attendez que Distributor finisse de charger vos logiciels et de créer votre package. Distributor indique le statut de chargement pour chaque fichier installable. Selon le nombre et la taille des packages que vous ajoutez, cela peut prendre quelques minutes. Distributor vous redirige vers la page **Package details (Détails du package)** pour le nouveau package, mais vous pouvez choisir d'ouvrir cette page vous-même une fois les logiciels chargés. La page **Package details (Détails du package)** n'affiche pas toutes les informations sur votre package tant que Distributor n'a pas terminé le processus de création de ce package. Pour arrêter le processus de chargement et de création de package, sélectionnez **Cancel (Annuler)**.
Si Distributor ne peut pas charger les fichiers de logiciels installables, il affiche un message **Upload failed (Échec du chargement)**. Pour relancer le chargement, sélectionnez **Retry upload (Réessayer le chargement)**. Pour plus d'informations sur la façon de résoudre les échecs de création de package, consultez [Résolution des problèmes AWS Systems ManagerDistributor](distributor-troubleshooting.md).
## Créer un package à l’aide du flux de travail avancé
Dans cette section, découvrez comment les utilisateurs avancés peuvent créer un package dans Distributor après avoir chargé des ressources installables zippées avec des scripts d'installation et de désinstallation, ainsi qu'un fichier manifeste JSON dans un compartiment Amazon S3.
Pour créer un package, préparez vos fichiers .zip de ressources installables, un fichier .zip par plateforme de système d'exploitation. Vous devez disposer d'au moins un fichier .zip pour créer un package. Créez ensuite un manifeste JSON. Le manifeste inclut des pointeurs vers vos fichiers de code de package. Une fois que les fichiers de code requis ont été ajoutés à un dossier ou un répertoire et que le manifeste a été renseigné avec des valeurs correctes, chargez votre package dans un compartiment S3.
Un exemple de package, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), est disponible en téléchargement sur notre site Web. Cet exemple de package comprend un manifeste JSON complet et trois fichiers .zip.
**Topics**
+ [Étape 1 : Création des fichiers ZIP](#packages-zip)
+ [Étape 2 : Création du manifeste de package JSON](#packages-manifest)
+ [Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3](#packages-upload-s3)
+ [Étape 4 : Ajout d'un package à Distributor](#distributor-working-with-packages-add)
### Étape 1 : Création des fichiers ZIP
Votre package doit reposer sur au moins un fichier .zip de logiciels ou de ressources installables. Un package inclut un fichier .zip par système d'exploitation que vous souhaitez prendre en charge, sauf si un fichier .zip peut être installé sur plusieurs systèmes d'exploitation. Par exemple, les versions prises en charge de Red Hat Enterprise Linux et les instances Amazon Linux peuvent généralement exécuter les mêmes fichiers exécutables .RPM. Par conséquent, vous n’avez besoin d’attacher qu’un seul fichier .zip à votre package pour pouvoir prendre en charge les deux systèmes d’exploitation.
**Fichiers requis**
Les éléments suivants doivent obligatoirement être présents dans chaque fichier .zip :
+ Un **install** et un **uninstall** script. Windows Serverles nœuds gérés basés sur la PowerShell technologie nécessitent des scripts (scripts nommés `install.ps1` et`uninstall.ps1`). Les nœuds gérés basés sur Linux requièrent des scripts shell (scripts nommés `install.sh` et `uninstall.sh`). SSM Agent exécute les instructions des scripts **install** et **uninstall**.
Par exemple, vos scripts d'installation peuvent exécuter un programme d'installation (par exemple, .rpm ou .msi), ils peuvent copier des fichiers ou définir des paramètres de configuration.
+ Un fichier exécutable, des packages de programme d'installation (.rpm, .deb, .msi, etc.), d'autres scripts ou fichiers de configuration.
**Fichiers facultatifs**
L'élément suivant est facultatif dans chaque fichier .zip :
+ Un script **update**. Le fait de fournir un script de mise à jour permet d'utiliser l'option `In-place update` pour installer un package. Lorsque vous souhaitez ajouter des fichiers nouveaux ou mis à jour à une installation de package existante, l'`In-place update`option ne met pas l'application du package hors ligne pendant la mise à jour. Windows Serverles nœuds gérés basés sur la technologie nécessitent un PowerShell script (nom du script`update.ps1`). Les nœuds gérés basés sur Linux requièrent un script shell (script nommé `update.sh`). SSM Agent exécute les instructions du script **update**.
Pour de plus amples informations sur l'installation ou la mise à jour de packages, veuillez consulter [Installer ou mettre à jour des packages Distributor](distributor-working-with-packages-deploy.md).
Pour obtenir des exemples de fichiers .zip, y compris des exemples **install** et **uninstall** des scripts, téléchargez le package d'exemple, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip).
### Étape 2 : Création du manifeste de package JSON
Une fois que vous avez préparé et zippé vos fichiers installables, créez un manifeste JSON. Vous trouverez ci-après un modèle. Les parties du modèle de manifeste sont décrites dans la procédure présentée dans cette section. Vous pouvez utiliser un éditeur JSON pour créer ce manifeste dans un fichier distinct. Vous pouvez également créer le manifeste dans la AWS Systems Manager console lorsque vous créez un package.
```
{
"schemaVersion": "2.0",
"version": "your-version",
"publisher": "optional-publisher-name",
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
},
"files": {
".zip-file-name-1.zip": {
"checksums": {
"sha256": "checksum"
}
},
".zip-file-name-2.zip": {
"checksums": {
"sha256": "checksum"
}
}
}
}
```
**Pour créer un manifeste de package JSON**
1. Ajoutez la version du schéma à votre manifeste. Dans cette édition, la version du schéma est toujours `2.0`.
```
{ "schemaVersion": "2.0",
```
1. Ajoutez une version de package définie par l'utilisateur à votre fichier manifeste. Il s'agit également de la valeur de **Version name (Nom de la version)** que vous spécifiez lorsque vous ajoutez votre package à Distributor. Cette version fait partie du document AWS Systems Manager créé par Distributor lorsque vous ajoutez votre package. Vous pouvez également fournir cette valeur sous forme d'entrée dans le document `AWS-ConfigureAWSPackage` pour installer une version du package autre que la plus récente. Une valeur `version` peut contenir des lettres, des chiffres, des traits de soulignement, des tirets et des points, et peut comporter un maximum de 128 caractères. Nous vous recommandons d'utiliser une version de package lisible par l'utilisateur afin qu'il soit plus facile pour vous et pour les autres administrateurs de spécifier les versions de packages exactes lorsque vous effectuez le déploiement. Voici un exemple.
```
"version": "1.0.1",
```
1. (Facultatif) Ajoutez un nom d'éditeur. Voici un exemple.
```
"publisher": "MyOrganization",
```
1. Ajoutez des packages. La section `"packages"` décrit les plateformes, versions et architectures prises en charge par les fichiers .zip dans votre package. Pour de plus amples informations, veuillez consulter [Architectures et plateformes de package prises en charge](distributor.md#what-is-a-package-platforms).
Il *platform-version* peut s'agir de la valeur générique,`_any`. Utilisez-le pour indiquer qu'un fichier .zip prend en charge n'importe quelle version de la plateforme. Vous pouvez également spécifier une version majeure suivie d'un caractère générique pour que toutes les versions mineures soient prises en charge, par exemple 7.\$1. Si vous choisissez de spécifier une *platform-version* valeur pour une version de système d'exploitation spécifique, assurez-vous qu'elle correspond exactement à la version finale du système d'exploitation AMI que vous ciblez. Voici les ressources suggérées pour obtenir la valeur correcte du système d'exploitation.
+ Sur une nœud géré basé sur Windows Server, la version est disponible sous forme de données WMI (Windows Management Instrumentation). Vous pouvez exécuter la commande suivante à partir d'une invite de commande pour obtenir la version, puis analyser les résultats obtenus pour `version`.
```
wmic OS get /format:list
```
+ Sur un nœud géré Linux, vous pouvez obtenir la version en commençant par rechercher la version du système d'exploitation (la commande suivante). Recherchez la valeur de `VERSION_ID`.
```
cat /etc/os-release
```
Si vous n'obtenez pas les résultats dont vous avez besoin, exécutez la commande suivante pour obtenir des informations de version LSB à partir du fichier `/etc/lsb-release` et recherchez la valeur de `DISTRIB_RELEASE`.
```
lsb_release -a
```
Si ces méthodes échouent, vous pouvez généralement trouver la version en fonction de la distribution. Par exemple, sur Debian Server, vous pouvez analyser le fichier `/etc/debian_version`, ou sur Red Hat Enterprise Linux, le fichier `/etc/redhat-release`.
```
hostnamectl
```
```
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
}
```
Voici un exemple. Dans cet exemple, la plateforme du système d'exploitation est `amazon`, la version prise en charge est `2016.09`, l'architecture est `x86_64` et le fichier .zip qui prend en charge cette plateforme est `test.zip`.
```
{
"amazon": {
"2016.09": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
Vous pouvez ajouter la valeur générique `_any` pour indiquer que le package prend en charge toutes les versions de l'élément parent. Par exemple, pour indiquer que le package est pris en charge sur n'importe quelle version d'Amazon Linux, votre déclaration de package doit être similaire à ce qui suit. Vous pouvez utiliser le caractère générique `_any` aux niveaux de la version ou de l'architecture pour prendre en charge toutes les versions d'une plateforme ou toutes les architectures dans une version, ou encore toutes les versions et architectures d'une plateforme.
```
{
"amazon": {
"_any": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
L'exemple suivant ajoute `_any` pour montrer que le premier package, `data1.zip`, est pris en charge pour toutes les architectures d'Amazon Linux 2016.09. Le deuxième package, `data2.zip`, est pris en charge pour toutes les versions d'Amazon Linux, mais uniquement pour les nœuds gérés dotés de l'architecture `x86_64`. Les versions `2023.8` et `_any` sont toutes deux des entrées situées sous `amazon`. Il y a une seule plateforme (Amazon Linux), mais différentes versions et architectures, et différents fichiers .zip associés pris en charge.
```
{
"amazon": {
"2023.8": {
"_any": {
"file": "data1.zip"
}
},
"_any": {
"x86_64": {
"file": "data2.zip"
}
}
}
}
```
Vous pouvez faire référence à un fichier .zip plusieurs fois dans la section `"packages"` du manifeste, si le fichier .zip prend en charge plusieurs plateformes. Par exemple, si vous avez un fichier .zip prenant en charge à la fois les versions Red Hat Enterprise Linux 8.x et Amazon Linux, vous avez deux entrées dans la section `"packages"` pointant vers le même fichier .zip, comme illustré dans l’exemple suivant.
```
{
"amazon": {
"2023.8.20250715 ": {
"x86_64": {
"file": "test.zip"
}
}
},
"redhat": {
"8.*": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
1. Ajoutez la liste des fichiers .zip qui font partie de ce package à partir de l'étape 4. Chaque entrée de fichier requiert le nom de fichier et le total de contrôle de la valeur de hachage `sha256`. Les valeurs de total de contrôle dans le manifeste doivent correspondre à la valeur de hachage `sha256` dans les ressources zippées pour empêcher l'échec de l'installation des packages.
Pour obtenir le total de contrôle exact de vos ressources installables, vous pouvez exécuter les commandes suivantes. Sous Linux, exécutez `shasum -a 256 file-name.zip` ou `openssl dgst -sha256 file-name.zip`. Sous Windows, exécutez l'`Get-FileHash -Path path-to-.zip-file`applet de commande dans. [PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-6)
La section `"files"` du manifeste inclut une référence à chacun des fichiers .zip de votre package.
```
"files": {
"test-agent-x86.deb.zip": {
"checksums": {
"sha256": "EXAMPLE2706223c7616ca9fb28863a233b38e5a23a8c326bb4ae241dcEXAMPLE"
}
},
"test-agent-x86_64.deb.zip": {
"checksums": {
"sha256": "EXAMPLE572a745844618c491045f25ee6aae8a66307ea9bff0e9d1052EXAMPLE"
}
},
"test-agent-x86_64.nano.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.nano.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
},
"test-agent-x86.msi.zip": {
"checksums": {
"sha256": "EXAMPLE12a4abb10315aa6b8a7384cc9b5ca8ad8e9ced8ef1bf0e5478EXAMPLE"
}
},
"test-agent-x86_64.msi.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.rpm.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
}
}
```
1. Une fois que vous avez ajouté vos informations de package, enregistrez et fermez le fichier manifeste.
Voici un exemple de fichier manifeste terminé. Dans cet exemple, vous avez un fichier .zip, `NewPackage_LINUX.zip`, qui prend en charge plusieurs plateformes, mais qui n'est référencé qu'une seule fois dans la section `"files"`.
```
{
"schemaVersion": "2.0",
"version": "1.7.1",
"publisher": "Amazon Web Services",
"packages": {
"windows": {
"_any": {
"x86_64": {
"file": "NewPackage_WINDOWS.zip"
}
}
},
"amazon": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
},
"ubuntu": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
}
},
"files": {
"NewPackage_WINDOWS.zip": {
"checksums": {
"sha256": "EXAMPLEc2c706013cf8c68163459678f7f6daa9489cd3f91d52799331EXAMPLE"
}
},
"NewPackage_LINUX.zip": {
"checksums": {
"sha256": "EXAMPLE2b8b9ed71e86f39f5946e837df0d38aacdd38955b4b18ffa6fEXAMPLE"
}
}
}
}
```
#### Exemple de package
Un exemple de package, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), est disponible en téléchargement sur notre site Web. Cet exemple de package comprend un manifeste JSON complet et trois fichiers .zip.
### Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3
Préparez votre package en copiant ou en déplaçant tous les fichiers .zip dans un dossier ou un répertoire. Un package valide nécessite le manifeste que vous avez créé à l'[Étape 2 : Création du manifeste de package JSON](#packages-manifest) et tous les fichiers .zip identifiés dans la liste de fichiers du manifeste.
**Pour charger le package et le manifeste dans Amazon S3**
1. Copiez ou déplacez dans un dossier ou un répertoire tous les fichiers d'archive .zip que vous avez spécifiés dans le manifeste. Ne zippez pas le dossier ou le répertoire dans lequel vous déplacez vos fichiers d'archive .zip et votre fichier manifeste.
1. Créez un compartiment ou sélectionnez un compartiment existant. Pour plus d'informations, veuillez consulter [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Guide de mise en route Amazon Simple Storage Service*. Pour plus d'informations sur la façon d'exécuter une AWS CLI commande pour créer un bucket, consultez [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)la *référence des AWS CLI commandes*.
1. Téléchargez le dossier ou le répertoire dans le compartiment. Pour plus d'informations, veuillez consulter [Ajouter un objet à un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html) dans le *Guide de mise en route Amazon Simple Storage Service*. Si vous prévoyez de coller votre manifeste JSON dans la AWS Systems Manager console, ne le chargez pas. Pour plus d'informations sur la façon d'exécuter une AWS CLI commande pour télécharger des fichiers [https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html)dans un bucket, consultez la *référence des AWS CLI commandes*.
1. Sur la page d'accueil du compartiment, sélectionnez le dossier ou le répertoire que vous avez chargé. Si vous avez chargé vos fichiers dans un sous-dossier au sein d'un compartiment, veillez à noter le sous-dossier (également connu sous le nom de *préfixe*). Vous avez besoin du préfixe pour ajouter votre package dans Distributor.
### Étape 4 : Ajout d'un package à Distributor
Vous pouvez utiliser la AWS Systems Manager console, les outils de ligne de AWS commande (AWS CLI et Outils AWS pour PowerShell) ou AWS SDKs ajouter un nouveau package àDistributor. Lorsque vous ajoutez un package, vous ajoutez un nouveau [document SSM](documents.md). Ce document vous permet de déployer le package sur des nœuds gérés.
**Topics**
+ [Ajouter un package à l’aide de la console](#create-pkg-console)
+ [Ajoutez un package à l'aide du AWS CLI](#create-pkg-cli)
#### Ajouter un package à l’aide de la console
Vous pouvez utiliser la AWS Systems Manager console pour créer un package. Vous devez avoir à votre disposition le nom du compartiment dans lequel vous avez chargé votre package dans [Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3](#packages-upload-s3).
**Pour ajouter un package dans Distributor (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 **Distributor**.
1. Sur la page d'accueil de Distributor, sélectionnez **Create package (Créer un package)**, puis **Advanced (Avancé)**.
1. Sur la page **Create package (Créer un package)**, entrez un nom pour votre package. Les noms de package peuvent contenir des lettres, des chiffres, des points, des tirets et des traits de soulignement. Le nom doit être suffisamment générique pour pouvoir s'appliquer à toutes les versions des pièces jointes du package, mais suffisamment spécifique pour identifier l'objectif du package.
1. Pour **Version name (Nom de la version)**, saisissez la valeur exacte de l'entrée `version` dans votre fichier manifeste.
1. Pour **S3 bucket name (Nom du compartiment S3)**, sélectionnez le nom du compartiment dans lequel vous avez chargé vos fichiers .zip et le manifeste dans [Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3](#packages-upload-s3).
1. Dans **S3 key prefix (Préfixe de clé S3)**, entrez le sous-dossier du compartiment dans lequel vos fichiers .zip et le manifeste sont stockés.
1. Dans **Manifest (Manifeste)**, sélectionnez **Extract from package (Extraire depuis le package)** pour utiliser un manifeste que vous avez chargé dans le compartiment Amazon S3 avec vos fichiers .zip.
(Facultatif) Si vous n'avez pas chargé votre manifeste JSON dans le compartiment S3 où vous avez stocké vos fichiers .zip, sélectionnez **New manifest (Nouveau manifeste)**. Vous pouvez créer ou coller l'intégralité du champ de manifeste dans l'éditeur JSON. Pour de plus amples informations sur la création du manifeste JSON, veuillez consulter [Étape 2 : Création du manifeste de package JSON](#packages-manifest).
1. Lorsque vous avez fini avec le fichier manifeste, sélectionnez **Create package (Créer un package)**.
1. Attendez que Distributor crée votre package à partir de vos fichiers .zip et de votre manifeste. Selon le nombre et la taille des packages que vous ajoutez, cela peut prendre quelques minutes. Distributor vous redirige vers la page **Package details (Détails du package)** pour le nouveau package, mais vous pouvez choisir d'ouvrir cette page vous-même une fois les logiciels chargés. La page **Package details (Détails du package)** n'affiche pas toutes les informations sur votre package tant que Distributor n'a pas terminé le processus de création de ce package. Pour arrêter le processus de chargement et de création de package, sélectionnez **Cancel (Annuler)**.
#### Ajoutez un package à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour créer un package. Vous devez avoir à votre disposition l'URL du compartiment dans lequel vous avez chargé votre package à l'[Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3](#packages-upload-s3).
**Pour ajouter un package à Amazon S3 à l'aide du AWS CLI**
1. AWS CLI Pour créer un package, exécutez la commande suivante, en *package-name* remplaçant par le nom de votre package et *path-to-manifest-file* par le chemin du fichier manifeste JSON. amzn-s3-demo-bucket est l'URL du compartiment Amazon S3 dans lequel le package est stocké dans son intégralité. Lorsque vous exécutez la commande **create-document** dans Distributor, vous devez spécifier la valeur `Package` pour `--document-type`.
Si vous n'avez pas ajouté votre fichier manifeste au compartiment Amazon S3, la valeur du paramètre `--content` est le chemin d'accès au fichier manifeste JSON.
```
aws ssm create-document \
--name "package-name" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-value-from-manifest \
--document-type Package
```
Voici un exemple.
```
aws ssm create-document \
--name "ExamplePackage" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.0.1 \
--document-type Package
```
1. Vérifiez que votre package a été ajouté et affichez le manifeste du package en exécutant la commande suivante, en le *package-name* remplaçant par le nom de votre package. Pour obtenir une version spécifique du document (différente de la version d'un package), vous pouvez ajouter le paramètre `--document-version`.
```
aws ssm get-document \
--name "package-name"
```
Pour de plus amples informations sur les autres options que vous pouvez utiliser avec la commande **create-document**, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html) dans la section AWS Systems Manager de la *Référence de Command AWS CLI *. Pour de plus amples informations sur les autres options que vous pouvez utiliser avec la commande **get-document**, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html).
# Modifier les autorisations du package Distributor dans la console
Après avoir ajouté un package à Distributor un outil AWS Systems Manager, vous pouvez modifier les autorisations du package dans la console Systems Manager. Vous pouvez ajouter d'autres autorisations Comptes AWS à un package. Les packages peuvent être partagés avec d'autres comptes de la même Région AWS uniquement. Le partage inter-régions n'est pas pris en charge. Par défaut, les packages sont définis sur **Privé**, ce qui signifie que seules les personnes ayant accès aux informations du créateur du package Compte AWS peuvent consulter les informations du package et le mettre à jour ou le supprimer. Si les autorisations **Private (Privé)** sont acceptables, vous pouvez ignorer cette procédure.
**Note**
Vous pouvez mettre à jour les autorisations des packages qui sont partagés avec au maximum 20 comptes.
**Pour modifier les autorisations du package dans la 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 **Distributor**.
1. Dans la page **Packages**, sélectionnez le package dont vous souhaitez modifier les autorisations.
1. Sur l'onglet **Package details (Détails du package)**, sélectionnez **Edit permissions (Modifier les autorisations)** pour pouvoir modifier les autorisations.
1. Pour **Edit permissions (Modifier les autorisations)**, sélectionnez **Shared with specific accounts (Partagé avec des comptes spécifiques)**.
1. Sous **Shared with specific accounts (Partagé avec des comptes spécifiques)**, ajoutez les numéros de Compte AWS , l'un après l'autre. Lorsque vous avez terminé, sélectionnez **Enregistrer**.
# Modifier les balises de package Distributor dans la console
Après avoir ajouté un package à Distributor un outil AWS Systems Manager, vous pouvez modifier les balises du package dans la console Systems Manager. Ces balises sont appliquées au package, et ne sont pas liées aux balises du nœud géré sur lequel vous souhaitez déployer le package. Les balises sont des paires clé-valeur sensibles à la casse qui peuvent vous aider à regrouper et filtrer vos packages en fonction des critères pertinents pour votre organisation. Si vous ne souhaitez pas ajouter de balises, vous êtes prêt à installer votre package ou à ajouter une nouvelle version.
**Pour modifier les balises d’un package dans la 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 **Distributor**.
1. Dans la page **Packages**, sélectionnez le package dont vous souhaitez modifier les balises.
1. Sur l'onglet **Package details (Détails du package)**, dans **Tags (Balises)**, sélectionnez **Edit (Modifier)**.
1. Pour **Add tags (Ajouter des balises)**, entrez une clé de balise ou une paire clé de balise-valeur, puis sélectionnez **Add (Ajouter)**. Répétez cette opération si vous souhaitez ajouter d'autres balises. Pour supprimer des balises, sélectionnez **X** sur la balise en bas de la fenêtre.
1. Une fois que vous avez fini d'ajouter les balises au package, sélectionnez **Save (Enregistrer)**.
# Ajouter une version à un package Distributor
Pour ajouter une version de package, [créez un package](distributor-working-with-packages-create.md), puis utilisez-le Distributor pour ajouter une version de package en ajoutant une entrée au document AWS Systems Manager (SSM) qui existe déjà pour les anciennes versions. Distributorest un outil dans AWS Systems Manager. Pour gagner du temps, mettez à jour le manifeste d'une version antérieure du package, modifiez la valeur de l'entrée `version` dans le manifeste (par exemple, en remplaçant `Test_1.0` par `Test_2.0`) et enregistrez-le en tant que manifeste de la nouvelle version. Le flux de travail **Add version (Ajouter une version)** simple dans la console Distributor met à jour le fichier manifeste pour vous.
Une nouvelle version de package peut :
+ Remplacer au moins l'un des fichiers installables attachés à la version actuelle.
+ Ajouter de nouveaux fichiers installables pour prendre en charge d'autres plateformes.
+ Supprimer des fichiers afin de stopper la prise en charge de plateformes spécifiques.
Une version plus récente peut utiliser le même compartiment Amazon Simple Storage Service (Amazon S3), mais doit avoir une URL avec un autre nom de fichier affiché à la fin. Vous pouvez utiliser la console Systems Manager ou la AWS Command Line Interface (AWS CLI) pour ajouter la nouvelle version. Le chargement d'un fichier installable avec le nom exact d'un fichier installable existant dans le compartiment Amazon S3 remplace le fichier existant. Aucun fichier installable de la version antérieure n'est copié sur la nouvelle version ; vous devez charger les fichiers installables de la version antérieure pour qu'ils fassent partie d'une nouvelle version. Une fois que Distributor a fini de créer votre nouvelle version de package, vous pouvez supprimer ou réutiliser le compartiment Amazon S3, car Distributor copie vos logiciels dans un compartiment Systems Manager interne dans le cadre du processus de gestion des versions.
**Note**
Chaque package contient un maximum de 25 versions. Vous pouvez supprimer les versions qui ne sont plus requises.
**Topics**
+ [Ajout d’une version de package à l’aide de la console](#add-pkg-version)
+ [Ajouter une version de package à l'aide du AWS CLI](#add-pkg-version-cli)
## Ajout d’une version de package à l’aide de la console
Avant d'effectuer ces étapes, suivez les instructions définies dans [Créer un package dans Distributor](distributor-working-with-packages-create.md) afin de créer un nouveau package pour la version. Utilisez ensuite la console Systems Manager pour ajouter une nouvelle version de package à Distributor.
### Ajout d’une version de package à l’aide du flux de travail simple
Pour ajouter une version de package à l'aide du flux de travail **Simple**, préparez des fichiers installables mis à jour ou ajoutez des fichiers installables pour prendre en charge d'autres plateformes et architectures. Ensuite, utilisez Distributor pour charger les fichiers installables nouveaux et mis à jour, et ajouter une version de package. Le flux de travail **Add version (Ajouter une version)** simplifié dans la console Distributor met à jour le fichier manifeste et le document SSM associé pour vous.
**Pour ajouter une version de package à l’aide du flux de travail simple**
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 **Distributor**.
1. Sur la page d'accueil de Distributor, sélectionnez le package auquel vous voulez ajouter une autre version.
1. Sur la page **Add version (Ajouter une version)**, sélectionnez **Simple**.
1. Pour **Version name (Nom de version)**, saisissez un nom de version. Le nom de version de la nouvelle version doit être différent des noms des anciennes versions. Les noms de version peuvent comporter 512 caractères au maximum et ne peuvent pas contenir de caractères spéciaux.
1. Pour **S3 bucket name (Nom du compartiment S3)**, sélectionnez un compartiment S3 existant dans la liste. Il peut s'agir du même compartiment que celui que vous avez utilisé afin de stocker les fichiers installables pour les versions antérieures, mais les noms de fichier installable doivent être différents pour éviter d'écraser les fichiers installables existants dans le compartiment.
1. Pour **S3 key prefix (Préfixe de clé S3)**, entrez le sous-dossier du compartiment dans lequel vos ressources installables sont stockées.
1. Pour **Upload software (Charger des logiciels)**, recherchez les fichiers de logiciels installables que vous voulez attacher à la nouvelle version. Les fichiers installables de versions existantes ne sont pas automatiquement copiés vers une nouvelle version ; vous devez charger les fichiers installables de versions antérieures du package si vous voulez que les mêmes fichiers installables fassent partie de la nouvelle version. Vous pouvez charger plusieurs fichiers de logiciel en une seule action.
1. Pour **Target platform (Plateforme cible)**, vérifiez que la plateforme de système d'exploitation cible pour chaque fichier installable est correcte. Si le système d'exploitation indiqué n'est pas correct, sélectionnez le système d'exploitation approprié dans la liste déroulante.
Dans le flux de travail de gestion des versions **Simple**, comme vous chargez chaque fichier installable une seule fois, des étapes supplémentaires sont nécessaires pour cibler un seul fichier sur plusieurs systèmes d'exploitation. Par exemple, si vous chargez un fichier de logiciel installable nommé `Logtool_v1.1.1.rpm`, vous devez modifier certaines valeurs par défaut dans le flux de travail **Simple** pour demander à Distributor de cibler le même logiciel sur les systèmes d’exploitation Amazon Linux et Ubuntu Server. Vous pouvez effectuer l'une des actions suivantes pour contourner cette limite.
+ Utilisez plutôt le flux de travail de gestion des versions **Advanced (Avancé)**, zippez chaque fichier installable en un fichier .zip avant de commencer et créez manuellement le manifeste afin qu'un fichier installable puisse cibler plusieurs plateformes ou versions de système d'exploitation. Pour de plus amples informations, veuillez consulter [Ajout d’une version de package à l’aide du flux de travail avancé](#add-pkg-version-adv).
+ Modifiez manuellement le fichier manifeste dans le flux de travail **Simple** pour que votre fichier .zip cible plusieurs plateformes ou versions de système d'exploitation. Pour plus d'informations sur la façon de procéder, consultez la fin de l'étape 4 dans [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Pour **Platform version (Version de plateforme)**, vérifiez que la version de plateforme de système d’exploitation est **\$1any**, une version majeure suivie d’un caractère générique (8.\$1), ou la version de système d’exploitation exacte spécifique à laquelle vous souhaitez que votre logiciel s’applique. Pour plus d'informations sur la spécification d'une version de plateforme, consultez l'étape 4 de [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Pour **Architecture**, sélectionnez l'architecture de processeur correcte pour chaque fichier installable dans la liste déroulante. Pour plus d'informations sur les architectures prises en charge, consultez [Architectures et plateformes de package prises en charge](distributor.md#what-is-a-package-platforms).
1. (Facultatif) Développez **Scripts** et vérifiez les scripts d'installation et de désinstallation générés par Distributor pour vos logiciels installables.
1. Pour ajouter d'autres fichiers de logiciels installables à la nouvelle version, sélectionnez **Add software (Ajouter des logiciels)**. Sinon, accédez à l'étape suivante.
1. (Facultatif) Développez **Manifest (Manifeste)** et vérifiez le manifeste de package JSON généré par Distributor pour vos logiciels installables. Si vous avez modifié des informations relatives à vos logiciels installables depuis que vous avez commencé cette procédure, comme la version de plateforme ou la plateforme cible, sélectionnez **Generate manifest (Générer un manifeste)** pour afficher le manifeste de package mis à jour.
Vous pouvez modifier le manifeste manuellement si vous souhaitez cibler un logiciel installable pour plusieurs systèmes d'exploitation, comme décrit à l'étape 9. Pour plus d'informations sur la modification du manifeste, consultez [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Lorsque vous avez fini d'ajouter des logiciels et de vérifier les données de plateforme cible, de version et d'architecture, sélectionnez **Add version (Ajouter une version)**.
1. Attendez que Distributor finisse de charger vos logiciels et de créer la nouvelle version de package. Distributor indique le statut de chargement pour chaque fichier installable. Selon le nombre et la taille des packages que vous ajoutez, cela peut prendre quelques minutes. Distributor vous redirige vers la page **Package details (Détails du package)** pour le package, mais vous pouvez choisir d'ouvrir cette page vous-même une fois les logiciels chargés. La page **Package details (Détails du package)** n'affiche pas toutes les informations sur votre package tant que Distributor n'a pas fini de créer la nouvelle version de package. Pour arrêter le chargement et la création de la version de package, sélectionnez **Stop upload (Arrêter le chargement)**.
1. Si Distributor ne peut pas charger les fichiers de logiciels installables, il affiche un message **Upload failed (Échec du chargement)**. Pour relancer le chargement, sélectionnez **Retry upload (Réessayer le chargement)**. Pour plus d'informations sur la façon de résoudre les échecs de création de version de package, consultez [Résolution des problèmes AWS Systems ManagerDistributor](distributor-troubleshooting.md).
1. Lorsque Distributor a fini de créer la nouvelle version de package, sur la page **Details (Détails)** du package, dans l'onglet **Versions**, vous voyez s'afficher la nouvelle version dans la liste des versions de package disponibles. Définissez une version par défaut du package en choisissant une version, puis en choisissant **Set default version (Définir la version par défaut)**.
Si vous ne définissez aucune version par défaut, c'est la version la plus récente du package qui est la version par défaut.
### Ajout d’une version de package à l’aide du flux de travail avancé
Pour ajouter une version de package, [créez un package](distributor-working-with-packages-create.md), puis utilisez Distributor pour ajouter une version de package en ajoutant une entrée au document SSM qui existe déjà pour les anciennes versions. Pour gagner du temps, mettez à jour le manifeste d'une version antérieure du package, modifiez la valeur de l'entrée `version` dans le manifeste (par exemple, en remplaçant `Test_1.0` par `Test_2.0`) et enregistrez-le en tant que manifeste de la nouvelle version. Vous devez avoir un manifeste mis à jour pour ajouter une nouvelle version de package à l'aide du flux de travail **Advanced (Avancé)**.
**Pour ajouter une version de package à l’aide du flux de travail avancé**
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 **Distributor**.
1. Sur la page d'accueil de Distributor, sélectionnez le package auquel vous voulez ajouter une autre version, puis sélectionnez **Ajouter une version**.
1. Dans **Version name (Nom de la version)**, saisissez la valeur exacte de l'entrée `version` de votre fichier manifeste.
1. Pour **S3 bucket name (Nom du compartiment S3)**, sélectionnez un compartiment S3 existant dans la liste. Il peut s'agir du même compartiment que celui que vous avez utilisé afin de stocker les fichiers installables pour les versions antérieures, mais les noms de fichier installable doivent être différents pour éviter d'écraser les fichiers installables existants dans le compartiment.
1. Pour **S3 key prefix (Préfixe de clé S3)**, entrez le sous-dossier du compartiment dans lequel vos ressources installables sont stockées.
1. Pour **Manifest (Manifeste)**, sélectionnez **Extract from package (Extraire depuis le package)** pour utiliser un manifeste que vous avez chargé dans le compartiment S3 avec vos fichiers .zip.
(Facultatif) Si vous n'avez pas chargé votre manifeste JSON révisé dans le compartiment Amazon S3 où vous avez stocké vos fichiers .zip, sélectionnez **New manifest (Nouveau manifeste)**. Vous pouvez créer ou coller l'intégralité du champ de manifeste dans l'éditeur JSON. Pour de plus amples informations sur la création du manifeste JSON, veuillez consulter [Étape 2 : Création du manifeste de package JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Lorsque vous avez fini avec le fichier manifeste, sélectionnez **Add package version (Ajouter une version de package)**.
1. Sur la page **Details (Détails)** du package, dans l'onglet **Versions**, vous voyez s'afficher la nouvelle version dans la liste des versions de package disponibles. Définissez une version par défaut du package en choisissant une version, puis en choisissant **Set default version (Définir la version par défaut)**.
Si vous ne définissez aucune version par défaut, c'est la version la plus récente du package qui est la version par défaut.
## Ajouter une version de package à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour ajouter une nouvelle version de package àDistributor. Avant d'exécuter ces commandes, vous devez créer une nouvelle version de package et la charger dans S3, comme décrit au début de cette rubrique.
**Pour ajouter une version de package à l'aide du AWS CLI**
1. Exécutez la commande suivante pour modifier le AWS Systems Manager document contenant une entrée pour une nouvelle version du package. Remplacez *document-name* par le nom de votre document. *amzn-s3-demo-bucket*Remplacez-le par l'URL du manifeste JSON que vous avez copié[Étape 3 : Chargement du package et du manifeste dans un compartiment Amazon S3](distributor-working-with-packages-create.md#packages-upload-s3). *S3-bucket-URL-of-package*est l'URL du compartiment Amazon S3 dans lequel l'ensemble du package est stocké. Remplacez *version-name-from-updated-manifest* par la valeur de `version` dans le manifeste. Définissez le paramètre `--document-version` sur `$LATEST` pour que le document associé à cette version de package soit la dernière version du document.
```
aws ssm update-document \
--name "document-name" \
--content "S3-bucket-URL-to-manifest-file" \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-name-from-updated-manifest \
--document-version $LATEST
```
Voici un exemple.
```
aws ssm update-document \
--name ExamplePackage \
--content "https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage/manifest.json" \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.1.1 \
--document-version $LATEST
```
1. Exécutez la commande suivante pour vérifier que votre package a été mis à jour et afficher le manifeste du package. Remplacez-le *package-name* par le nom de votre package, et éventuellement *document-version* par le numéro de version du document (différent de la version du package) que vous avez mis à jour. Si cette version de package est associée à la dernière version du document, vous pouvez spécifier `$LATEST` pour la valeur du paramètre facultatif `--document-version`.
```
aws ssm get-document \
--name "package-name" \
--document-version "document-version"
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **update-document** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
# Installer ou mettre à jour des packages Distributor
Vous pouvez déployer des packages sur vos nœuds AWS Systems Manager gérés à l'aide Distributor d'un outil dans AWS Systems Manager. Pour déployer les packages, utilisez le AWS Management Console ou AWS Command Line Interface (AWS CLI). Vous pouvez déployer une version d'un package par commande. Vous pouvez installer de nouveaux packages ou mettre à jour les installations existantes en place. Vous pouvez choisir de déployer une version spécifique ou choisir de toujours déployer la version la plus récente d'un package. Nous vous recommandons State Manager d'utiliser un outil pour installer les packages. AWS Systems Manager L'utilisation State Manager permet de garantir que vos nœuds gérés exécutent toujours la up-to-date version la plus complète de votre package.
**Important**
Les packages que vous installez à l’aide du distributeur doivent être désinstallés uniquement à l’aide du distributeur. Sinon, Systems Manager peut toujours enregistrer l’application comme `INSTALLED` et entraîner d’autres résultats inattendus.
| Préférence | AWS Systems Manager action | Plus d'informations |
| --- | --- | --- |
| Installer ou mettre à jour un package immédiatement. | Run Command | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installer un package selon un calendrier, afin que l'installation inclue toujours la version par défaut. | State Manager | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installer automatiquement un package sur de nouveaux nœuds gérés dotés d'une balise spécifique ou d'un ensemble de balises spécifiques. Par exemple, installer l' CloudWatch agent Amazon sur de nouvelles instances. | State Manager | Pour ce faire, vous pouvez appliquer des balises à de nouveaux nœuds gérés, puis spécifier les balises en tant que cibles dans votre association State Manager. State Manager installe automatiquement le package dans une association sur les nœuds gérés dotés de balises correspondantes. Consultez [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md). |
**Topics**
+ [Installation ou mise à jour d’un package une seule fois à l’aide de la console](#distributor-deploy-pkg-console)
+ [Planification de l’installation ou de la mise à jour d’un package à l’aide de la console](#distributor-deploy-sm-pkg-console)
+ [Installation unique d'un package à l'aide du AWS CLI](#distributor-deploy-pkg-cli)
+ [Mettre à jour un package une seule fois à l'aide du AWS CLI](#distributor-update-pkg-cli)
+ [Planification de l'installation d'un package à l'aide du AWS CLI](#distributor-smdeploy-pkg-cli)
+ [Planification de la mise à jour d'un package à l'aide du AWS CLI](#distributor-smupdate-pkg-cli)
## Installation ou mise à jour d’un package une seule fois à l’aide de la console
Vous pouvez utiliser la AWS Systems Manager console pour installer ou mettre à jour un package une seule fois. Lorsque vous configurez une installation unique[AWS Systems Manager Run Command](run-command.md), un outil est Distributor utilisé pour effectuer l'installation. AWS Systems Manager
**Pour installer ou mettre à jour un package une seule fois à l’aide de la 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 **Distributor**.
1. Dans la page d'accueil de Distributor, sélectionnez le package à installer.
1. Sélectionnez **Installer une fois**.
Cette commande ouvre Run Command avec le document de commande `AWS-ConfigureAWSPackage` et votre package Distributor déjà sélectionné.
1. Pour **Document version (Version du document)**, sélectionnez la version du document `AWS-ConfigureAWSPackage` à exécuter.
1. Pour **Actions**, sélectionnez **Installer**.
1. Pour **Installation type (Type d'installation)**, sélectionnez l'une des valeurs suivantes :
+ **Uninstall and reinstall (Désinstaller et réinstaller)** : le package est complètement désinstallé, puis réinstallé. L'application n'est pas disponible tant que la réinstallation n'est pas terminée.
+ **In-place update (Mise à jour sur place)** : seuls les fichiers nouveaux ou modifiés sont ajoutés à l'installation existante, conformément aux instructions que vous fournissez dans un script `update`. L'application reste disponible tout au long du processus de mise à jour. Cette option n'est pas prise en charge pour les packages AWS publiés, à l'exception `AWSEC2Launch-Agent` du package.
1. Pour **Name (Nom)**, vérifiez que le nom du package sélectionné est entré.
1. Pour **Version**, entrez la valeur du nom de version du package. Si vous laissez ce champ vide, Run Command installe la version par défaut que vous avez sélectionnée dans Distributor.
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils manuellement, ou en spécifiant un groupe de ressources.
**Note**
Si 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).
1. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Dans **Rate Control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de cibles sur lesquelles exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises ou des groupes de ressources et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles autorisées à exécuter simultanément le document en indiquant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres cibles après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds gérés. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**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, 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, assurez-vous 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. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Lorsque vous êtes prêt à installer le package, sélectionnez **Run (Exécuter)**.
1. La zone **Command status (État de la commande)** indique la progression de l'exécution. Si la commande est toujours en cours, sélectionnez l'icône d'actualisation dans l'angle supérieur gauche de la console jusqu'à ce que la colonne **Overall status (État général)** ou **Detailed status (État détaillé)** affiche **Success (Succès)** ou **Failure (Échec)**.
1. Dans la zone **Targets and outputs (Cibles et sorties)**, cliquez sur le bouton situé en regard d'un nom de nœud géré, puis sélectionnez **View output (Afficher la sortie)**.
La page de sortie de la commande illustre les résultats de l'exécution de votre commande.
1. (Facultatif) Si vous avez choisi d'écrire la sortie de commande dans un compartiment Amazon S3, sélectionnez **Amazon S3** pour afficher les données du journal de sortie.
## Planification de l’installation ou de la mise à jour d’un package à l’aide de la console
Vous pouvez utiliser la AWS Systems Manager console pour planifier l'installation ou la mise à jour d'un package. Lorsque vous planifiez l'installation ou la mise à jour du package, Distributor utilise [AWS Systems Manager State Manager](systems-manager-state.md) pour effectuer l'installation ou la mise à jour.
**Pour planifier l’installation d’un package à l’aide de la 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 **Distributor**.
1. Dans la page d'accueil de Distributor, sélectionnez le package à installer ou mettre à jour.
1. Pour **Package**, sélectionnez **Install on a schedule (Installation planifiée)**.
Cette commande ouvre State Manager dans une nouvelle association qui est créée pour vous.
1. Pour **Name (Nom)**, saisissez un nom (par exemple, **Deploy-test-agent-package**). Cette action est facultative, mais recommandée. Les espaces ne sont pas autorisés dans le nom.
1. Dans la liste **Document**, le nom du document `AWS-ConfigureAWSPackage` est déjà sélectionné.
1. Pour **Action**, vérifiez que **Installer** est sélectionné.
1. Pour **Installation type (Type d'installation)**, sélectionnez l'une des valeurs suivantes :
+ **Uninstall and reinstall (Désinstaller et réinstaller)** : le package est complètement désinstallé, puis réinstallé. L'application n'est pas disponible tant que la réinstallation n'est pas terminée.
+ **In-place update (Mise à jour sur place)** : seuls les fichiers nouveaux ou modifiés sont ajoutés à l'installation existante, conformément aux instructions que vous fournissez dans un script `update`. L'application reste disponible tout au long du processus de mise à jour.
1. Pour **Name (Nom)**, vérifiez que le nom de votre package est entré.
1. Pour **Version**, si vous souhaitez installer une version de package autre que la dernière version publiée, entrez l'identificateur de version.
1. Pour **Targets (Cibles)**, sélectionnez **Selecting all managed instances in this account (Sélection de toutes les instances gérées dans ce compte)**, **Specifying tags (Spécification des balises)** ou **Manually Selecting Instance (Sélection manuelle des instances)**. Si vous choisissez de cibler des ressources à l'aide de balises, entrez une clé de balise et une valeur de balise dans les champs fournis.
**Note**
Vous pouvez choisir les appareils AWS IoT Greengrass principaux gérés en choisissant soit **Sélection de toutes les instances gérées dans ce compte**, soit **Sélection manuelle de l'instance**.
1. Pour **Specify schedule (Spécifier le calendrier)**, sélectionnez **On Schedule (Selon le calendrier)** pour exécuter l'association selon une planification régulière ou **No Schedule (Pas de calendrier)** pour exécuter l'association une seule fois. Pour plus d'informations sur ces options, consultez [Utilisation d'associations dans Systems Manager](state-manager-associations.md). Utilisez les contrôles pour créer un calendrier de type `cron` ou rate pour l'association.
1. Sélectionnez **Create Association (Créer une association)**.
1. Sur la page **Association** cliquez sur le bouton en regard de l'association que vous avez créée, puis sélectionnez **Apply association now (Appliquer l'association maintenant)**.
State Manager crée et exécute immédiatement l'association sur les cibles spécifiées. Pour de plus amples informations sur les résultats de l'exécution des associations, consultez [Utilisation d'associations dans Systems Manager](state-manager-associations.md) dans ce guide.
Pour de plus amples informations sur l'utilisation des options dans **Advanced options (Options avancées)**, **Rate control (Contrôle de débit)** et **Output options (Options de sortie)**, consultez [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
## Installation unique d'un package à l'aide du AWS CLI
Vous pouvez exécuter **send-command** le AWS CLI pour installer un Distributor package une seule fois. Si le package est déjà installé, l'application sera déconnectée pendant que le package est désinstallé et que la nouvelle version est installée à sa place.
**Pour installer un package une seule fois à l'aide du AWS CLI**
+ Exécutez la commande suivante dans l' AWS CLI :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**Note**
Le comportement par défaut pour `installationType` est `Uninstall and reinstall`. Vous pouvez omettre `"installationType":["Uninstall and reinstall"]` de cette commande lorsque vous installez un package complet.
Voici un exemple.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-00000000000000" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["ExamplePackage"]}'
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **send-command** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
## Mettre à jour un package une seule fois à l'aide du AWS CLI
Vous pouvez l'exécuter **send-command** AWS CLI pour mettre à jour un Distributor package sans mettre l'application associée hors ligne. Seuls les fichiers nouveaux ou mis à jour dans le package sont remplacés.
**Pour mettre à jour un package une seule fois à l'aide du AWS CLI**
+ Exécutez la commande suivante dans l' AWS CLI :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**Note**
Lorsque vous ajoutez des fichiers nouveaux ou modifiés, vous devez inclure `"installationType":["In-place update"]` dans la commande.
Voici un exemple.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["ExamplePackage"]}'
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **send-command** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
## Planification de l'installation d'un package à l'aide du AWS CLI
Vous pouvez exécuter **create-association** le AWS CLI pour installer un Distributor package selon un calendrier. La valeur de `--name`, le nom du document, est toujours `AWS-ConfigureAWSPackage`. La commande suivante utilise la clé `InstanceIds` pour spécifier des nœuds gérés cibles. Si le package est déjà installé, l'application sera déconnectée pendant que le package est désinstallé et que la nouvelle version est installée à sa place.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**Note**
Le comportement par défaut pour `installationType` est `Uninstall and reinstall`. Vous pouvez omettre `"installationType":["Uninstall and reinstall"]` de cette commande lorsque vous installez un package complet.
Voici un exemple.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **create-association** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
## Planification de la mise à jour d'un package à l'aide du AWS CLI
Vous pouvez exécuter **create-association** le AWS CLI pour mettre à jour un Distributor package selon un calendrier sans mettre l'application associée hors ligne. Seuls les fichiers nouveaux ou mis à jour dans le package sont remplacés. La valeur de `--name`, le nom du document, est toujours `AWS-ConfigureAWSPackage`. La commande suivante utilise la clé `InstanceIds` pour spécifier les instances cibles.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**Note**
Lorsque vous ajoutez des fichiers nouveaux ou modifiés, vous devez inclure `"installationType":["In-place update"]` dans la commande.
Voici un exemple.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **create-association** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
# Désinstaller un package Distributor
Vous pouvez utiliser le AWS Management Console ou le AWS Command Line Interface (AWS CLI) pour désinstaller des Distributor packages de vos nœuds AWS Systems Manager gérés en utilisantRun Command. Distributoret Run Command sont des outils dedans AWS Systems Manager. Dans cette version, vous pouvez désinstaller une version d'un package par commande. Vous pouvez désinstaller une version spécifique ou la version par défaut.
**Important**
Les packages que vous installez à l’aide du distributeur doivent être désinstallés uniquement à l’aide du distributeur. Sinon, Systems Manager peut toujours enregistrer l’application comme `INSTALLED` et entraîner d’autres résultats inattendus.
**Topics**
+ [Désinstallation d’un package à l’aide de la console](#distributor-pkg-uninstall-console)
+ [Désinstaller un package à l'aide du AWS CLI](#distributor-pkg-uninstall-cli)
## Désinstallation d’un package à l’aide de la console
Vous pouvez utiliser Run Command dans la console Systems Manager pour désinstaller un package ponctuellement. Distributor utilise [AWS Systems Manager Run Command](run-command.md) pour désinstaller les packages.
**Pour désinstaller un package à l’aide de la 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 **Run Command**.
1. Sur la page d'accueil de Run Command, sélectionnez **Run command (Exécuter la commande)**.
1. Sélectionnez le document de commande `AWS-ConfigureAWSPackage`.
1. Dans **Action**, sélectionnez **Uninstall (Désinstaller)**
1. Pour **Name (Nom)**, tapez le nom du package à désinstaller.
1. Dans **Targets (Cibles)**, sélectionnez la façon dont vous souhaitez cibler vos nœuds gérés. Vous pouvez spécifier une clé et des valeurs de balise partagées par les cibles. Vous pouvez également spécifier des cibles en choisissant des attributs, comme un ID, une plateforme et une version de SSM Agent.
1. Vous pouvez utiliser les options avancées pour ajouter des commentaires sur l'opération, modifier les valeurs **Concurrency (Simultanéité)** et **Error threshold (Seuil d'erreur)** dans **Rate control (Contrôle de débit)**, spécifier des options de sortie ou configurer les notifications Amazon Simple Notification Service (Amazon SNS). Pour plus d'informations, consultez [Exécution des commandes depuis la console](https://docs.aws.amazon.com/systems-manager/latest/userguide/rc-console.html) dans ce guide.
1. Lorsque vous êtes prêt à désinstaller le package, sélectionnez **Run (Exécuter)**, puis **View results (Afficher les résultats)**.
1. Dans la liste des commandes, sélectionnez la commande `AWS-ConfigureAWSPackage` que vous venez d'exécuter. Si la commande est toujours en cours d'exécution, sélectionnez l'icône d'actualisation dans le coin supérieur droit de la console.
1. Lorsque la colonne **Status** (Statut) affiche **Success** (Réussite) ou **Failed** (Échec), sélectionnez l'onglet **Output** (Sortie).
1. Sélectionnez **View output (Afficher la sortie)**. La page de sortie de la commande illustre les résultats de l'exécution de votre commande.
## Désinstaller un package à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour désinstaller un Distributor package des nœuds gérés en utilisantRun Command.
**Pour désinstaller un package à l'aide du AWS CLI**
+ Exécutez la commande suivante dans l' AWS CLI :
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Uninstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
Voici un exemple.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Uninstall"],"name":["Test-ConfigureAWSPackage"]}'
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **send-command** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*.
# Supprimer un package Distributor
Cette section explique comment supprimer un package. Vous ne pouvez pas supprimer une version particulière d'un package, seulement le package entier.
## Suppression d’un package à l’aide de la console
Vous pouvez utiliser la AWS Systems Manager console pour supprimer un package ou une version de Distributor package dans un outil AWS Systems Manager. La suppression d'un package supprime toutes les versions du package de Distributor.
**Pour supprimer un package à l’aide de la 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 **Distributor**.
1. Dans la page d'accueil de **Distributor**, sélectionnez le package à supprimer.
1. Sur la page des détails du package, sélectionnez **Delete package (Supprimer le package)**.
1. Lorsque vous êtes invité à confirmer la suppression, sélectionnez **Delete package (Supprimer le package)**.
## Suppression d’une version d’un package à l’aide de la console
Vous pouvez utiliser la console Systems Manager pour supprimer une version de package de Distributor.
**Pour supprimer une version d’un package à l’aide de la 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 **Distributor**.
1. Sur la page d'accueil de **Distributor**, sélectionnez le package dont vous souhaitez supprimer une version.
1. Sur la page des versions du package, sélectionnez la version à supprimer et sélectionnez **Delete version (Supprimer la version)**.
1. Lorsque vous êtes invité à confirmer la suppression, sélectionnez **Delete package version (Supprimer la version de package)**.
## Suppression d’un package à l’aide de la ligne de commande
Vous pouvez utiliser votre outil de ligne de commande préféré pour supprimer un package de Distributor.
------
#### [ Linux & macOS ]
**Pour supprimer un package à l'aide du AWS CLI**
1. Exécutez la commande suivante pour répertorier les documents de packages spécifiques. Dans les résultats de cette commande, recherchez le package que vous souhaitez supprimer.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
1. Exécutez la commande suivante pour supprimer un package. Remplacez *package-name* par le nom du package.
```
aws ssm delete-document \
--name "package-name"
```
1. Exécutez à nouveau la commande **list-documents** pour vérifier que le package a été supprimé. Le package que vous avez supprimé ne doit pas figurer dans la liste.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
------
#### [ Windows ]
**Pour supprimer un package à l'aide du AWS CLI**
1. Exécutez la commande suivante pour répertorier les documents de packages spécifiques. Dans les résultats de cette commande, recherchez le package que vous souhaitez supprimer.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
1. Exécutez la commande suivante pour supprimer un package. Remplacez *package-name* par le nom du package.
```
aws ssm delete-document ^
--name "package-name"
```
1. Exécutez à nouveau la commande **list-documents** pour vérifier que le package a été supprimé. Le package que vous avez supprimé ne doit pas figurer dans la liste.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
------
#### [ PowerShell ]
**Pour supprimer un package à l'aide des outils pour PowerShell**
1. Exécutez la commande suivante pour répertorier les documents de packages spécifiques. Dans les résultats de cette commande, recherchez le package que vous souhaitez supprimer.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
1. Exécutez la commande suivante pour supprimer un package. Remplacez *package-name* par le nom du package.
```
Remove-SSMDocument `
-Name "package-name"
```
1. Exécutez à nouveau la commande **Get-SSMDocumentList** pour vérifier que le package a été supprimé. Le package que vous avez supprimé ne doit pas figurer dans la liste.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
------
## Suppression d’une version d’un package à l’aide de la ligne de commande
Vous pouvez utiliser votre outil de ligne de commande préféré pour supprimer une version de package de Distributor.
------
#### [ Linux & macOS ]
**Pour supprimer une version de package à l'aide du AWS CLI**
1. Exécutez la commande suivante pour répertorier les versions de votre package. Dans les résultats de cette commande, recherchez la version de package que vous souhaitez supprimer.
```
aws ssm list-document-versions \
--name "package-name"
```
1. Exécutez la commande suivante pour supprimer une version de package. Remplacez *package-name* par le nom du package et *version* par le numéro de version.
```
aws ssm delete-document \
--name "package-name" \
--document-version version
```
1. Exécutez la commande **list-document-versions** pour vérifier que la version du package a été supprimée. La version de package que vous avez supprimée doit être introuvable.
```
aws ssm list-document-versions \
--name "package-name"
```
------
#### [ Windows ]
**Pour supprimer une version de package à l'aide du AWS CLI**
1. Exécutez la commande suivante pour répertorier les versions de votre package. Dans les résultats de cette commande, recherchez la version de package que vous souhaitez supprimer.
```
aws ssm list-document-versions ^
--name "package-name"
```
1. Exécutez la commande suivante pour supprimer une version de package. Remplacez *package-name* par le nom du package et *version* par le numéro de version.
```
aws ssm delete-document ^
--name "package-name" ^
--document-version version
```
1. Exécutez la commande **list-document-versions** pour vérifier que la version du package a été supprimée. La version de package que vous avez supprimée doit être introuvable.
```
aws ssm list-document-versions ^
--name "package-name"
```
------
#### [ PowerShell ]
**Pour supprimer une version de package à l'aide des outils pour PowerShell**
1. Exécutez la commande suivante pour répertorier les versions de votre package. Dans les résultats de cette commande, recherchez la version de package que vous souhaitez supprimer.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
1. Exécutez la commande suivante pour supprimer une version de package. Remplacez *package-name* par le nom du package et *version* par le numéro de version.
```
Remove-SSMDocument `
-Name "package-name" `
-DocumentVersion version
```
1. Exécutez la commande **Get-SSMDocumentVersionList** pour vérifier que la version du package a été supprimée. La version de package que vous avez supprimée doit être introuvable.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
------
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **list-documents** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html)à la AWS Systems Manager section de la *référence des AWS CLI commandes*. Pour de plus amples informations sur les autres options que vous pouvez utiliser avec la commande **delete-document**, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html).
# Audit et journalisation de l'activité de Distributor
Vous pouvez utiliser AWS CloudTrail pour auditer l'activité liée à Distributor un outil dans AWS Systems Manager. Pour de plus amples informations sur les options d'audit et de journalisation de Systems Manager, veuillez consulter [Connexion et surveillance AWS Systems Manager](monitoring.md).
## DistributorActivité d'audit à l'aide de CloudTrail
CloudTrail capture les appels d'API effectués dans la AWS Systems Manager console, le AWS Command Line Interface (AWS CLI) et le SDK Systems Manager. Les informations peuvent être consultées dans la CloudTrail console ou stockées dans un compartiment Amazon Simple Storage Service (Amazon S3). Un compartiment est utilisé pour tous les CloudTrail journaux de votre compte.
Les journaux des actions Run Command et State Manager présentent les activités de création de documents, d’installation et de désinstallation de packages. Run Command et State Manager sont des outils d’ AWS Systems Manager. Pour plus d'informations sur l'affichage et l'utilisation des CloudTrail journaux d'activité de Systems Manager, consultez[Journalisation des appels d' AWS Systems Manager API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
# Résolution des problèmes AWS Systems ManagerDistributor
Les informations suivantes peuvent vous aider à résoudre les problèmes liés à l’utilisation de Distributor, un outil d’ AWS Systems Manager.
**Topics**
+ [Un package erroné portant le même nom est installé](#distributor-tshoot-1)
+ [Erreur : impossible de récupérer le manifeste ; la dernière version du package est introuvable](#distributor-tshoot-2)
+ [Erreur : Impossible de récupérer le manifeste ; exception de validation](#distributor-tshoot-3)
+ [Le package n'est pas pris en charge (l'action d'installation du package est manquante)](#distributor-tshoot-4)
+ [Erreur : échec de téléchargement du manifeste : le document avec le nom n'existe pas](#distributor-tshoot-5)
+ [Chargement échoué.](#distributor-tshoot-6)
+ [Erreur : Impossible de trouver la plateforme : aucun manifeste n’a été trouvé pour la plateforme : Oracle, version 8.9, architecture x86\$164](#distributor-tshoot-7)
## Un package erroné portant le même nom est installé
**Problème :** vous avez installé un package, mais Distributor en a installé un autre à la place.
**Cause :** lors de l'installation, Systems Manager recherche les packages publiés par AWS avant les packages externes définis par l'utilisateur. Si le nom de package défini par l'utilisateur est identique au nom d'un package AWS publié, le AWS package est installé à la place de votre package.
**Solution :** Pour éviter ce problème, donnez à votre package un nom différent du nom d'un package AWS publié.
## Erreur : impossible de récupérer le manifeste ; la dernière version du package est introuvable
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Failed to retrieve manifest: ResourceNotFoundException: Could not find the latest version of package
arn:aws:ssm:::package/package-name status code: 400, request id: guid
```
**Cause :** vous utilisez une version de SSM Agent avec Distributor qui est antérieure à la version 2.3.274.0.
**Solution :** mettez à jour l'SSM Agent vers la version 2.3.274.0 ou ultérieure. Pour plus d’informations, consultez [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) ou [Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI](state-manager-update-ssm-agent-cli.md).
## Erreur : Impossible de récupérer le manifeste ; exception de validation
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Failed to retrieve manifest: ValidationException: 1 validation error detected: Value 'documentArn'
at 'packageName' failed to satisfy constraint: Member must satisfy regular expression pattern:
arn:aws:ssm:region-id:account-id:package/package-name
```
**Cause :** vous utilisez une version de SSM Agent avec Distributor qui est antérieure à la version 2.3.274.0.
**Solution :** mettez à jour l'SSM Agent vers la version 2.3.274.0 ou ultérieure. Pour plus d’informations, consultez [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) ou [Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI](state-manager-update-ssm-agent-cli.md).
## Le package n'est pas pris en charge (l'action d'installation du package est manquante)
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Package is not supported (package is missing install action)
```
**Cause : **la structure du répertoire du package est incorrecte.
**Solution : **ne zippez pas un répertoire parent contenant le logiciel et les scripts requis. Au lieu de cela, créez un fichier `.zip` de tous les contenus requis directement dans le chemin absolu. Pour vérifier que la création du fichier `.zip` est correcte, dézippez le répertoire de la plateforme cible et vérifiez la structure du répertoire. Par exemple, le chemin absolu du script d'installation doit être `/ExamplePackage_targetPlatform/install.sh`.
## Erreur : échec de téléchargement du manifeste : le document avec le nom n'existe pas
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Failed to download manifest - failed to retrieve package document description: InvalidDocument: Document with name filename does not exist.
```
**Cause 1 :** Distributor ne peut pas trouver le package par son nom lorsqu’un package Distributor est partagé à partir d’un autre compte.
**Solution 1 :** lors du partage d’un package à partir d’un autre compte, utilisez l’Amazon Resource Name (ARN) complet pour le package et pas seulement son nom.
**Cause 2 :** Lorsque vous utilisez un VPC, vous n'avez pas fourni à votre profil d'instance IAM l'accès au compartiment S3 AWS géré qui contient le document correspondant au que Région AWS vous `AWS-ConfigureAWSPackage` ciblez.
**Solution 2 :** assurez-vous que votre profil d'instance IAM donne accès SSM Agent au compartiment S3 AWS géré qui contient le document correspondant à l'objet `AWS-ConfigureAWSPackage` que Région AWS vous ciblez, comme expliqué dans[SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
## Chargement échoué.
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Upload failed. At least one of your files was not successfully uploaded to your S3 bucket.
```
**Cause :** le nom de votre package de logiciels inclut une espace. Par exemple, le téléchargement de `Hello World.msi` échouerait.
## Erreur : Impossible de trouver la plateforme : aucun manifeste n’a été trouvé pour la plateforme : Oracle, version 8.9, architecture x86\$164
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86_64
```
**Cause :** l’erreur signifie que le manifeste du package JSON n’a aucune définition pour cette plateforme, dans ce cas, Oracle Linux.
**Solution :** téléchargez le package que vous souhaitez distribuer depuis le site [Trend Micro Deep Security Software](https://help.deepsecurity.trendmicro.com/software.html). Créez un package logiciel `.rpm` à l’aide de : [Créer un package à l’aide du flux de travail simple](distributor-working-with-packages-create.md#distributor-working-with-packages-create-simple). Définissez les valeurs suivantes pour le package et complétez le package logiciel de chargement à l’aide du distributeur :
```
Platform version: _any
Target platform: oracle
Architecture: x86_64
```
# AWS Systems Manager Fleet Manager
L’outil Fleet Manager d’AWS Systems Manager est une interface utilisateur (IU) unifiée qui vous permet de gérer à distance les nœuds exécutés sur AWS ou sur site. Avec Fleet Manager, vous pouvez consulter l'état et le statut de performance de votre flotte de serveurs à partir d'une console unique. Vous pouvez également collecter des données provenant de nœuds individuels pour accomplir des tâches courantes de résolution des problèmes et de gestion à partir de la console. Cela inclut la connexion aux instances Windows à l'aide du protocole RDP (Remote Desktop Protocol), l'affichage du contenu des dossiers et des fichiers, la gestion du registre Windows, la gestion des utilisateurs du système d'exploitation, etc.
Pour vos premiers pas dans Fleet Manager, ouvrez [Systems Manager console](https://console.aws.amazon.com/systems-manager/fleet-manager). Dans le panneau de navigation, sélectionnez **Fleet Manager**.
## À qui est destiné Fleet Manager ?
Les clients AWS qui souhaitent gérer leur flotte de nœuds de façon centralisée doivent utiliser Fleet Manager.
## Comment mon organisation peut-elle tirer parti de Fleet Manager ?
Fleet Manager offre les avantages suivants :
+ Accomplissez différentes tâches courantes d'administration des systèmes sans avoir à vous connecter manuellement à vos nœuds gérés.
+ Gérez les nœuds exécutés sur plusieurs plateformes à partir d'une seule console unifiée.
+ Gérez les nœuds exécutant différents systèmes d'exploitation à partir d'une seule console unifiée.
+ Améliorez l'efficacité de l'administration de vos systèmes.
## Quelles sont les fonctions d'Fleet Manager ?
Les principales fonctionnalités de Fleet Manager sont décrites ci-après.
+ **Accès au portail de la base de connaissances Red Hat**
Accédez aux binaires, ainsi qu'aux forums de partage de connaissances et de discussion disponibles sur le portail de la base de connaissances Red Hat via vos instances Red Hat Enterprise Linux (RHEL).
+ **État des nœuds gérés**
Identifiez les instances gérées qui sont `running` et celles qui sont `stopped`. Pour plus d’informations sur les instances arrêtées, consultez [Arrêter et démarrer votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) dans le *Guide de l’utilisateur Amazon EC2*. Vous pouvez identifier l'état des appareils Core AWS IoT Greengrass : `online`, `offline` ou `Connection lost`.
**Note**
Si vous avez arrêté votre instance gérée avant le 12 juillet 2021, elle n'affichera pas le marqueur `stopped`. Pour afficher le marqueur, démarrez et arrêtez l'instance.
+ **Affichage des informations d'instance**
Affichez des informations sur les données de dossier et de fichier stockées sur les volumes attachés à vos instances gérées, les données de performances relatives à vos instances en temps réel et les données de journal stockées sur vos instances.
+ **Affichage des informations relatives à un appareil de périphérie**
Affichage du nom AWS IoT Greengrass Thing de l'appareil, de l'état et de la version du ping de l'SSM Agent, etc.
+ **Gestion des comptes et du registre**
Gérez les comptes utilisateurs du système d'exploitation (OS) sur vos instances et le registre sur vos instances Windows.
+ **Contrôle de l'accès aux fonctions**
Contrôlez l'accès à des fonctions Fleet Manager en utilisant des politiques Gestion des identités et des accès AWS (IAM). Grâce à ces politiques, vous pouvez désigner les utilisateurs individuels ou les groupes de votre organisation autorisés à utiliser telle ou telle fonction de Fleet Manager, et les nœuds gérés qu'ils peuvent gérer.
**Topics**
+ [À qui est destiné Fleet Manager ?](#fleet-who)
+ [Comment mon organisation peut-elle tirer parti de Fleet Manager ?](#fleet-benefits)
+ [Quelles sont les fonctions d'Fleet Manager ?](#fleet-features)
+ [Configuration de Fleet Manager](setting-up-fleet-manager.md)
+ [Utilisation des nœuds gérés](fleet-manager-managed-nodes.md)
+ [Gestion automatique des instances EC2 avec la configuration par défaut de la gestion des hôtes](fleet-manager-default-host-management-configuration.md)
+ [Connexion à une instance gérée Windows Server à l’aide d’Remote Desktop](fleet-manager-remote-desktop-connections.md)
+ [Gestion des volumes Amazon EBS sur les instances gérées](fleet-manager-manage-amazon-ebs-volumes.md)
+ [Accès au portail de la base de connaissances Red Hat](fleet-manager-red-hat-knowledge-base-access.md)
+ [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md)
# Configuration de Fleet Manager
Pour que les utilisateurs de votre Compte AWS puissent utiliser Fleet Manager, un outil d’AWS Systems Manager, afin de surveiller et de gérer vos nœuds gérés, ils doivent disposer des autorisations nécessaires. De plus, pour que les instances Amazon Elastic Compute Cloud (Amazon EC2), les appareils principaux AWS IoT Greengrass, les serveurs sur site, les appareils de périphérie et les machines virtuelles (VM) puissent être surveillés et gérés à l’aide de Fleet Manager, ceux‑ci doivent être des *nœuds gérés* Systems Manager. Un nœud géré est une machine configurée pour être utilisée avec Systems Manager dans des environnements [hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types).
Cela signifie que vos nœuds doivent remplir certaines conditions préalables et être configurés avec l’agent AWS Systems Manager (SSM Agent).
Selon le type de machine, reportez‑vous à l’une des sections suivantes pour vous assurer que vos machines répondent aux exigences relatives aux nœuds gérés.
+ Instances Amazon EC2 : [Gestion des instances EC2 avec Systems Manager](systems-manager-setting-up-ec2.md)
**Astuce**
Vous pouvez également utiliser Quick Setup, un outil d’AWS Systems Manager, pour vous aider à configurer rapidement vos instances Amazon EC2 en tant qu’instances gérées dans un compte individuel. Si votre entreprise ou organisation utilise AWS Organizations, vous pouvez également configurer des instances sur plusieurs unités organisationnelles (UO) et Régions AWS. Pour de plus amples informations sur l'utilisation de Quick Setup pour configurer les instances gérées, veuillez consulter [Configurer la gestion des hôtes Amazon EC2 à l’aide d’Quick Setup](quick-setup-host-management.md).
+ Sur site et autres types de serveurs dans le cloud : [Gestion des nœuds dans les environnements hybrides et multicloud avec Systems Manager](systems-manager-hybrid-multicloud.md)
+ Appareils (en périphérie) AWS IoT Greengrass : [Gestion des appareils de périphérie avec Systems Manager](systems-manager-setting-up-edge-devices.md)
**Topics**
+ [Contrôle de l'accès à Fleet Manager](configuring-fleet-manager-permissions.md)
# Contrôle de l'accès à Fleet Manager
Pour être utiliséFleet Manager, un outil intégré à AWS Systems Manager votre utilisateur ou rôle Gestion des identités et des accès AWS (IAM) doit disposer des autorisations requises. Vous pouvez créer une politique IAM donnant accès à toutes les fonctions Fleet Manager ou modifier votre politique afin d'octroyer l'accès aux fonctions que vous sélectionnez. Vous accordez ensuite ces autorisations aux utilisateurs, ou identités, de votre compte.
**Tâche 1 : créer des politiques IAM pour définir les autorisations d’accès**
Suivez l’une des méthodes fournies dans la rubrique suivante du *Guide de l’utilisateur IAM* pour créer une IAM afin de fournir des identités (utilisateurs, rôles ou groupes d’utilisateurs) avec un accès à Fleet Manager :
+ [Définir des autorisations IAM personnalisées à l’aide de politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
Vous pouvez utiliser l’un des exemples de politiques que nous fournissons ci-dessous, ou les modifier en fonction des autorisations que vous voulez accorder. Nous fournissons des exemples de politiques pour l’accès complet à Fleet Manager et l’accès en lecture seule.
**Tâche 2 : attacher les politiques IAM aux utilisateurs pour leur accorder des autorisations**
Après avoir créé la ou les politiques IAM qui définissent les autorisations d’accès à Fleet Manager, utilisez l’une des procédures suivantes du *Guide de l’utilisateur IAM* pour accorder ces autorisations aux identités de votre compte :
+ [Ajout des autorisations d’identité IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)
+ [Ajout d’autorisations pour les identités IAM (AWS CLI)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-cli)
+ [Ajout d’autorisations pour les identités IAM (API AWS )](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-api)
**Topics**
+ [Exemple de politique d'accès des administrateurs Fleet Manager](#admin-policy-sample)
+ [Exemple de politique d'accès Fleet Manager en lecture seule](#read-only-policy-sample)
## Exemple de politique d'accès des administrateurs Fleet Manager
La politique suivante fournit des autorisations pour toutes les fonctions Fleet Manager Cela signifie qu’un utilisateur peut créer et supprimer des utilisateurs et des groupes locaux, modifier l’appartenance à n’importe quel groupe local, et modifier des clés ou des valeurs de registre Windows Server. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource",
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations",
"ssm:RemoveTagsFromResource"
],
"Resource": "*"
},
{
"Sid": "DefaultHostManagement",
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWS-PasswordReset",
"arn:aws:ssm:*:*:document/AWSFleetManager-AddUsersToGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-CopyFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateDirectory",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUserInteractive",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-MountVolume",
"arn:aws:ssm:*:*:document/AWSFleetManager-MoveFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-RemoveUsersFromGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-RenameFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-SetWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-StartProcess",
"arn:aws:ssm:*:*:document/AWSFleetManager-TerminateProcess"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
## Exemple de politique d'accès Fleet Manager en lecture seule
La politique suivante fournit des autorisations à des fonctions Fleet Manager en lecture seule. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations"
],
"Resource": "*"
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
# Utilisation des nœuds gérés
Un *nœud géré* est une machine configurée pour AWS Systems Manager. Vous pouvez configurer les types de machines suivants en tant que nœuds gérés :
+ Instances Amazon Elastic Compute Cloud (Amazon EC2)
+ Serveurs sur votre propre site (serveurs sur site)
+ AWS IoT Greengrass appareils principaux
+ AWS IoT et appareils non AWS périphériques
+ Machines virtuelles (VMs), y compris VMs dans d'autres environnements cloud
Dans la console Systems Manager, toute machine dotée du préfixe « mi- » est configurée en tant que nœud géré à l’aide d’une [*activation hybride*](activations.md). Les appareils Edge affichent le nom de leur AWS IoT objet.
**Note**
La seule fonction prise en charge pour les instances macOS est l'affichage du système de fichiers.
**À propos des niveaux d'instances Systems Manager**
AWS Systems Manager propose un niveau d'instances standard et un niveau d'instances avancées. Les deux prennent en charge les nœuds gérés dans votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Le niveau d'instances standard vous permet d'enregistrer un maximum de 1 000 machines par machine. Compte AWS Région AWS Si vous avez besoin d'enregistrer plus de 1 000 machines dans un seul compte et une seule région, utilisez le niveau d'instances avancées. Le niveau d'instances avancées vous permet de créer autant de nœuds gérés que vous le souhaitez. Tous les nœuds gérés configurés pour Systems Manager sont facturés sur une pay-per-use base. Pour plus d'informations sur l'activation des instances avancées, consultez [Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md). Pour plus d'informations sur la tarification, consultez [Tarification AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Notez les informations supplémentaires suivantes concernant les niveaux d’instances standard et d’instances avancées :
+ Les instances avancées vous permettent également de vous connecter à vos EC2 non-nœuds dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) en utilisant AWS Systems Manager Session Manager. Session Managerfournit un accès shell interactif à vos instances. Pour de plus amples informations, veuillez consulter [AWS Systems Manager Session Manager](session-manager.md).
+ Le quota d'instances standard s'applique également aux EC2 instances qui utilisent une activation sur site de Systems Manager (ce qui n'est pas un scénario courant).
+ Pour appliquer des correctifs aux applications publiées par Microsoft sur des machines virtuelles (VMs) et des instances locales, activez le niveau d'instances avancées. L'utilisation du niveau d'instance avancé est facturée. Les applications de correctif publiées par Microsoft sur les instances Amazon Elastic Compute Cloud (Amazon EC2) sont gratuites. Pour de plus amples informations, veuillez consulter [Correction d’applications publiées par Microsoft sur Windows Server](patch-manager-patching-windows-applications.md).
**Affichage des nœuds gérés**
Si vos nœuds gérés ne sont pas répertoriés dans la console, procédez comme suit :
1. Vérifiez que la console est ouverte à l' Région AWS endroit où vous avez créé vos nœuds gérés. Vous pouvez changer de région à l'aide de la liste figurant dans la partie supérieure droite de la console.
1. Vérifiez que les étapes de configuration de vos nœuds gérés respectent les exigences de Systems Manager. Pour plus d'informations, consultez [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
1. Pour les appareils autres que EC2 des machines, vérifiez que vous avez terminé le processus d'activation hybride. Pour de plus amples informations, veuillez consulter [Gestion des nœuds dans les environnements hybrides et multicloud avec Systems Manager](systems-manager-hybrid-multicloud.md).
Notez les informations supplémentaires suivantes :
+ La Fleet Manager console n'affiche pas les EC2 nœuds Amazon qui ont été résiliés.
+ Systems Manager doit disposer de références précises en termes de date et d'heure pour pouvoir effectuer des opérations sur vos machines. Si la date et l'heure ne sont pas correctement définies sur vos nœuds gérés, les machines peuvent ne pas correspondre à la date de signature de vos demandes d'API. Pour de plus amples informations, veuillez consulter [Cas d'utilisation et bonnes pratiques](systems-manager-best-practices.md).
+ Lorsque vous créez ou modifiez des balises, une heure peut s'écouler avant que le système n’affiche les modifications dans le filtre de la table.
+ Une fois que le statut d'un nœud géré a été `Connection Lost` pendant au moins 30 jours, il est possible que le nœud ne soit plus répertorié dans la console Fleet Manager. Pour le rétablir dans la liste, le problème à l'origine de la perte de connexion doit être résolu. Pour obtenir des conseils de dépannage, veuillez consulter [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md).
**Vérification de la prise en charge de Systems Manager sur un nœud géré**
AWS Config fournit des règles AWS gérées, qui sont des règles prédéfinies et personnalisables AWS Config utilisées pour évaluer si les configurations de vos AWS ressources sont conformes aux meilleures pratiques courantes. AWS Config Les règles gérées incluent la règle [ec2- instance-managed-by-systems -manager](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html). Cette règle vérifie si les EC2 instances Amazon de votre compte sont gérées par Systems Manager. Pour en savoir plus, consultez [Règles gérées AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html).
**Renforcement de la sécurité sur les nœuds gérés**
Pour plus d'informations sur le renforcement de votre posture de sécurité vis-à-vis des commandes de niveau racine non autorisées sur vos nœuds gérés, consultez [Limitation de l'accès aux commandes de niveau racine via l'SSM Agent](ssm-agent-restrict-root-level-commands.md).
**Annulation de l'enregistrement des nœuds gérés**
Vous pouvez à tout moment annuler l'enregistrement des nœuds gérés. Par exemple, si vous gérez plusieurs nœuds dotés du même rôle Gestion des identités et des accès AWS (IAM) et que vous remarquez un quelconque comportement malveillant, vous pouvez annuler l'enregistrement d'un nombre illimité de machines à tout moment. (Pour réenregistrer la même machine, vous devez utiliser un code d’activation hybride et un ID d’activation différents de ceux utilisés précédemment pour l’enregistrer.) Pour obtenir des informations sur l'annulation de l'enregistrement des nœuds gérés, consultez [Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md)
+ [Réinitialisation des mots de passe sur les nœuds gérés](fleet-manager-reset-password.md)
+ [Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud](fleet-manager-deregister-hybrid-nodes.md)
+ [Travailler avec les systèmes de fichiers du système d’exploitation à l’aide de Fleet Manager](fleet-manager-file-system-management.md)
+ [Surveillance de la performance des nœuds gérés](fleet-manager-monitoring-node-performance.md)
+ [Utilisation des processus](fleet-manager-manage-processes.md)
+ [Affichage des journaux sur les nœuds gérés](fleet-manager-view-node-logs.md)
+ [Gestion des comptes et groupes d’utilisateurs de systèmes d’exploitation sur les nœuds gérés à l’aide d’Fleet Manager](fleet-manager-manage-os-user-accounts.md)
+ [Gestion du registre Windows sur les nœuds gérés](fleet-manager-manage-windows-registry.md)
# Configuration des niveaux d'instance
Cette rubrique décrit les scénarios dans lesquels vous devez activer le niveau d'instances avancées.
AWS Systems Manager [propose un niveau d'instances standard et un niveau d'instances avancées pour les machines non EC2 dans un environnement hybride et multicloud.](operating-systems-and-machine-types.md#supported-machine-types)
Vous pouvez enregistrer jusqu'à 1 000 [nœuds hybrides standard](activations.md) par compte et sans Région AWS frais supplémentaires. Toutefois, pour enregistrer plus de 1 000 nœuds hybrides, vous avez besoin d'activer le niveau d'instances avancées. L'utilisation du niveau d'instance avancé est facturée. Pour plus d’informations, consultez [Tarification d’AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Même avec moins de 1 000 nœuds activés par un système hybride enregistrés, deux autres scénarios requièrent le niveau d'instances avancées :
+ Vous souhaitez utiliser Session Manager pour vous connecter à des nœuds non EC2.
+ Vous souhaitez appliquer des correctifs aux applications (et non aux systèmes d'exploitation) publiées par Microsoft sur des nœuds non EC2.
**Note**
Les opérations d'application de correctifs publiées par Microsoft sur des instances Amazon EC2 sont gratuites.
## Scénarios détaillés relatifs au niveau d'instances avancées
Les informations suivantes fournissent des détails relatifs aux trois scénarios pour lesquels vous devez activer le niveau d'instances avancées.
Scénario 1 : vous souhaitez enregistrer plus de 1 000 nœuds activés par un système hybride
En utilisant le niveau d'instances standard, vous pouvez enregistrer un maximum de 1 000 nœuds non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) par compte spécifique sans Région AWS frais supplémentaires. Si vous avez besoin d'enregistrer plus de 1 000 nœuds non EC2 dans une région, vous devez utiliser le niveau d'instances avancées. Vous pouvez ensuite activer autant de machines d'un environnement hybride et multicloud que vous souhaitez. Les frais pour le niveau d'instances avancées sont basés sur, le nombre de nœuds avancés activés en tant que nœuds gérés par Systems Manager et le nombre d'heures d'exécution de ces nœuds.
Tous les nœuds gérés par Systems Manager qui utilisent le processus d’activation décrit dans [Créer une activation hybride pour enregistrer des nœuds auprès de Systems Manager](hybrid-activation-managed-nodes.md) sont alors soumis à des frais si vous dépassez 1 000 nœuds sur site dans une région pour un compte spécifique .
Vous pouvez également activer les instances Amazon Elastic Compute Cloud (Amazon EC2) existantes à l'aide des activations hybrides Systems Manager et les utiliser en tant qu'instances non EC2, comme pour les tests. Ces nœuds sont également considérés comme des nœuds hybrides. Ce scénario n'est pas courant.
Scénario 2 : application des correctifs à des applications publiées par Microsoft sur des nœuds activés par des hybrides
Le niveau d'instances avancées est également requis si vous souhaitez appliquer des correctifs à des applications publiées par Microsoft sur des nœuds non EC2 dans un environnement hybride et multicloud. L'activation du niveau d'instances avancées pour appliquer des correctifs aux applications Microsoft sur des nœuds non EC2, des frais seront alors facturés pour tous les nœuds sur site, même si vous en avez moins de 1 000.
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 [Correction d’applications publiées par Microsoft sur Windows Server](patch-manager-patching-windows-applications.md).
Scénario 3 : connexion à des nœuds activés par des hybrides à l'aide de Session Manager
Session Manager fournit un accès shell interactif à vos instances. Pour vous connecter à des nœuds gérés activés par un système hybride à l'aide de Session Manager, activez le niveau d'instances avancées. Des frais sont ensuite facturés pour tous les nœuds activés par un système hybride, même si vous en avez moins de 1 000.
**Résumé : quand ai-je besoin du niveau d'instances avancées ?**
Utilisez le tableau suivant pour savoir quand utiliser le niveau d'instances avancées et quels scénarios impliquent des frais supplémentaires.
****
| Scénario | Le niveau d'instances avancées est requis ? | Des frais supplémentaires seront facturés. |
| --- | --- | --- |
| Le nombre de nœuds activés par des hybrides dans ma région sur un compte spécifique est supérieur à 1 000. | Oui | Oui |
| Je souhaite utiliser Patch Manager pour appliquer des correctifs aux applications publiées par Microsoft sur un nombre illimité de nœuds activés par des hybrides, même moins de 1 000. | Oui | Oui |
| Je souhaite utiliser Session Manager pour vous connecter à n'importe quel nombre de nœuds activés par des hybrides, même à moins de 1 000. | Oui | Oui |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/fleet-manager-configure-instance-tiers.html) | Non | Non |
**Topics**
+ [Scénarios détaillés relatifs au niveau d'instances avancées](#systems-manager-managed-instances-tier-scenarios)
+ [Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md)
+ [Revenir du niveau des instances avancées au niveau des instances standard](fleet-manager-revert-to-standard-tier.md)
# Activation du niveau d'instances avancées
AWS Systems Manager [propose un niveau d'instances standard et un niveau d'instances avancées pour les machines non EC2 dans un environnement hybride et multicloud.](operating-systems-and-machine-types.md#supported-machine-types) Le niveau d'instances standard vous permet d'enregistrer un maximum de 1 000 machines activées par hybride par personne. Compte AWS Région AWS Le niveau d'instances avancées est également nécessaire pour utiliser Patch Manager pour appliquer des correctifs à des applications publiées par Microsoft sur des nœuds non EC2 et pour se connecter à des nœuds non EC2 à l'aide deSession Manager. Pour de plus amples informations, veuillez consulter [Activation du niveau d'instances avancées](#fleet-manager-enable-advanced-instances-tier).
Cette section décrit comment configurer votre environnement hybride et multicloud de sorte à utiliser le niveau d'instances avancées.
**Avant de commencer**
Passez en revue les informations de tarification pour les instances avancées. Les instances avancées sont disponibles sur un per-use-basis. Pour de plus amples informations, veuillez consulter [Tarification AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Configuration des autorisations pour activer le niveau des instances avancées.
Vérifiez que vous êtes autorisé Gestion des identités et des accès AWS (IAM) à modifier votre environnement du niveau des instances standard au niveau des instances avancées. La politique IAM `AdministratorAccess` doit être attachée à votre utilisateur , groupe ou rôle, ou vous devez disposer d'une autorisation pour modifier le paramètre de service de niveau d'activation Systems manager. Le paramètre de niveau d'activation utilise les opérations d'API suivantes :
+ [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)
+ [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)
+ [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)
Utilisez la procédure suivante pour ajouter une politique IAM en ligne à un compte utilisateur. Cette politique permet à un utilisateur d'afficher le paramètre actuel de niveau d'instance gérée. Cette politique permet également à l'utilisateur de modifier ou de réinitialiser le paramètre actuel dans les valeurs spécifiées Compte AWS et Région AWS.
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation, choisissez **utilisateurs**.
1. Dans la liste, sélectionnez le nom de l'utilisateur auquel intégrer une politique.
1. Choisissez l'onglet **Permissions** (Autorisations).
1. Sur le côté droit de la page, sous **Permission policies (Politiques d'autorisation)**, sélectionnez **Add inline policy (Ajouter une politique en ligne)**.
1. Sélectionnez l'onglet **JSON**.
1. Remplacez le contenu par défaut par ce qui suit :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/activation-tier"
}
]
}
```
------
1. Sélectionnez **Examiner une politique**.
1. Sur la page **Examiner une politique**, dans le champ **Nom**, saisissez un nom pour la politique en ligne. Par exemple : **Managed-Instances-Tier**.
1. Sélectionnez **Créer une politique**.
Les administrateurs peuvent spécifier une autorisation en lecture seule en affectant la politique en ligne suivante à l’utilisateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "*"
}
]
}
```
------
Pour de plus amples informations sur la création de politiques IAM, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *guide de l'utilisateur IAM*.
## Activation du niveau d'instances avancées (console)
La procédure suivante explique comment utiliser la console Systems Manager pour modifier *tous les* nœuds non EC2 ajoutés à l'aide de l'activation des instances gérées, dans le niveau spécifié Compte AWS et Région AWS pour utiliser le niveau des instances avancées.
**Avant de commencer**
Vérifiez que la console est ouverte Région AWS là où vous avez créé vos instances gérées. Vous pouvez changer de région à l'aide de la liste figurant dans la partie supérieure droite de la console.
Vérifiez que vous avez satisfait la configuration requise pour vos instances Amazon Elastic Compute Cloud (Amazon EC2) et vos machines non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Pour plus d'informations, consultez [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Important**
La procédure suivante décrit comment modifier un paramètre au niveau du compte. Cette modification entraîne des frais qui seront facturés à votre compte.
**Pour activer le niveau d'instances avancées (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 **Fleet Manager**.
1. Sélectionnez **Paramètres**, puis **Modifier les paramètres du niveau d’instance**.
1. Consultez les informations de la boîte de dialogue concernant la modification des paramètres de compte.
1. Si vous approuvez, choisissez l’option d’acceptation, puis choisissez **Modifier le paramètre**.
Le processus consistant à déplacer toutes les instances du niveau d'instances standard au niveau d'instances avancées peut prendre plusieurs minutes.
**Note**
Pour de plus amples informations sur le retour au niveau des instances standard, consultez [Revenir du niveau des instances avancées au niveau des instances standard](fleet-manager-revert-to-standard-tier.md).
## Activation du niveau d'instances avancées (AWS CLI)
La procédure suivante explique comment utiliser le pour modifier *tous les* serveurs locaux ajoutés AWS Command Line Interface à l'aide de l'activation des instances gérées, dans le niveau spécifié Compte AWS et Région AWS pour utiliser le niveau des instances avancées. VMs
**Important**
La procédure suivante décrit comment modifier un paramètre au niveau du compte. Cette modification entraîne des frais qui seront facturés à votre compte.
**Pour activer le niveau d'instances avancées à l'aide du AWS CLI**
1. Ouvrez le AWS CLI et exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value advanced
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value advanced
```
------
Il n'y a pas de sortie si la commande réussit.
1. Exécutez la commande suivante pour afficher les paramètres de service actuels pour les nœuds gérés dans les versions actuelles Compte AWS et Région AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
La commande renvoie des informations telles que les suivantes.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "advanced",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "arn:aws:sts::123456789012:assumed-role/Administrator/User_1",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "PendingUpdate"
}
}
```
## Activation du niveau d'instances avancées (PowerShell)
La procédure suivante explique comment utiliser le pour modifier *tous les* serveurs locaux ajoutés AWS Tools for Windows PowerShell à l'aide de l'activation des instances gérées, dans le niveau spécifié Compte AWS et Région AWS pour utiliser le niveau des instances avancées. VMs
**Important**
La procédure suivante décrit comment modifier un paramètre au niveau du compte. Cette modification entraîne des frais qui seront facturés à votre compte.
**Pour activer le niveau d'instances avancées à l'aide de PowerShell**
1. Ouvrez AWS Tools for Windows PowerShell et exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "advanced"
```
Il n’y a pas de sortie si la commande réussit.
1. Exécutez la commande suivante pour afficher les paramètres de service actuels pour les nœuds gérés dans les versions actuelles Compte AWS et Région AWS.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
La commande renvoie des informations telles que les suivantes.
```
ARN:arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : arn:aws:sts::123456789012:assumed-role/Administrator/User_1
SettingId : /ssm/managed-instance/activation-tier
SettingValue : advanced
Status : PendingUpdate
```
Plusieurs minutes peuvent s'écouler avant que les nœuds passent tous du niveau d'instances standard au niveau d'instances avancées.
**Note**
Pour de plus amples informations sur le retour au niveau des instances standard, consultez [Revenir du niveau des instances avancées au niveau des instances standard](fleet-manager-revert-to-standard-tier.md).
# Revenir du niveau des instances avancées au niveau des instances standard
Cette section explique comment rebasculer des nœuds activés par un système hybride du niveau d'instances avancées vers le niveau d'instances standard. Cette configuration s'applique à tous les nœuds activés de manière hybride en un Compte AWS et un. Région AWS
**Avant de commencer**
Consultez les détails importants suivants.
**Note**
Vous ne pouvez pas revenir au niveau d'instances standard si vous exécutez plus de 1 000 nœuds activés par un système hybride dans le compte et la région. Vous devez d'abord annuler l'enregistrement des nœuds jusqu'à ce que vous en ayez 1 000 ou moins. Cela concerne également les instances Amazon Elastic Compute Cloud (Amazon EC2) qui utilisent une activation hybride Systems Manager (ce qui n'est pas courant). Pour de plus amples informations, veuillez consulter [Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud](fleet-manager-deregister-hybrid-nodes.md).
Une fois que vous serez revenu en arrière, vous ne pourrez plus utiliser Session Manager, un outil d’ AWS Systems Manager, pour accéder de manière interactive à vos nœuds activés par un système hybride.
Une fois que vous serez revenu en arrière, vous ne pourrez plus utiliser Patch Manager, un outil d’ AWS Systems Manager, pour appliquer des correctifs aux applications publiées par Microsoft sur les nœuds activés par un système hybride.
Le processus de retour en arrière de tous les nœuds activés par un système hybride au niveau d'instances standard peut prendre 30 minutes ou plus.
Cette section décrit comment rétablir tous les nœuds activés par des hybrides dans un Compte AWS et Région AWS depuis le niveau d'instances avancées vers le niveau d'instances standard.
## Revenir au niveau des instances standard (console)
La procédure suivante explique comment utiliser la console Systems Manager pour modifier tous les nœuds activés en mode hybride dans votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) afin d'utiliser le niveau d'instances standard dans le niveau spécifié et. Compte AWS Région AWS
**Pour revenir au niveau des instances standard (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 **Fleet Manager**.
1. Sélectionnez le menu déroulant **Account settings (Paramètres du compte)** et sélectionnez **Instance tier settings (Paramètres du niveau d'instances)**.
1. Sélectionnez **Modifier les paramètres de compte**.
1. Vérifiez les informations contenues dans la fenêtre sur la modification des paramètres de compte puis, si vous approuvez, sélectionnez l'option pour accepter et continuer.
## Revenir au niveau des instances standard (AWS CLI)
La procédure suivante vous montre comment utiliser le AWS Command Line Interface pour modifier tous les nœuds activés par hybride dans votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) afin d'utiliser le niveau d'instances standard dans le niveau spécifié et. Compte AWS Région AWS
**Pour revenir au niveau des instances standard à l'aide du AWS CLI**
1. Ouvrez le AWS CLI et exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value standard
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value standard
```
------
Il n'y a pas de sortie si la commande réussit.
1. Exécutez la commande suivante 30 minutes plus tard pour afficher les paramètres des instances gérées dans les versions actuelles Compte AWS et Région AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
La commande renvoie des informations telles que les suivantes.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "standard",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "Default"
}
}
```
Le statut devient *Par défaut* une fois la demande approuvée.
## Revenir au niveau des instances standard (PowerShell)
La procédure suivante explique comment modifier les nœuds activés AWS Tools for Windows PowerShell en mode hybride dans votre environnement hybride et multicloud afin d'utiliser le niveau d'instances standard dans le niveau spécifié et. Compte AWS Région AWS
**Pour revenir au niveau des instances standard en utilisant PowerShell**
1. Ouvrez AWS Tools for Windows PowerShell et exécutez la commande suivante.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "standard"
```
Il n’y a pas de sortie si la commande réussit.
1. Exécutez la commande suivante 30 minutes plus tard pour afficher les paramètres des instances gérées dans les versions actuelles Compte AWS et Région AWS.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
La commande renvoie des informations telles que les suivantes.
```
ARN: arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : System
SettingId : /ssm/managed-instance/activation-tier
SettingValue : standard
Status : Default
```
Le statut devient *Par défaut* une fois la demande approuvée.
# Réinitialisation des mots de passe sur les nœuds gérés
Vous pouvez réinitialiser le mot de passe de n'importe quel utilisateur d'un nœud géré. Cela inclut les instances Amazon Elastic Compute Cloud (Amazon EC2), les appareils principaux AWS IoT Greengrass , ainsi que les serveurs sur site, les appareils périphériques et les machines virtuelles VMs () gérés par. AWS Systems Manager La fonctionnalité de réinitialisation de mot de passe est basée sur Session Manager, un outil d’ AWS Systems Manager. Vous pouvez utiliser cette fonctionnalité pour vous connecter aux nœuds gérés sans avoir à ouvrir de ports entrants, à maintenir des hôtes bastions ou à gérer des clés SSH.
La réinitialisation de mot de passe peut s'avérer utile lorsqu'un utilisateur a oublié un mot de passe, ou lorsque vous souhaitez modifier un mot de passe rapidement sans établir de connexion SSH ou RDP avec un nœud géré.
**Conditions préalables**
Avant de pouvoir réinitialiser le mot de passe d'un nœud géré, les conditions suivantes doivent être remplies :
+ Le nœud géré sur lequel vous souhaitez modifier le mot de passe doit être un nœud géré Systems Manager. De plus, SSM Agent 2.3.668.0 (ou version ultérieure) doit être installé sur le nœud géré. Pour plus d'informations sur l'installation ou la mise à jour de SSM Agent, consultez [Utilisation de l’option SSM Agent](ssm-agent.md).
+ La fonctionnalité de réinitialisation de mot de passe utilise la configuration Session Manager définie pour permettre à votre compte de se connecter au nœud géré. Par conséquent, les prérequis pour l'utilisation de Session Manager doivent avoir été satisfaits pour votre compte dans la Région AWS actuelle. Pour de plus amples informations, veuillez consulter [Configuration de Session Manager](session-manager-getting-started.md).
**Note**
La prise en charge de Session Manager pour les nœuds sur site est assurée pour le niveau d'instances avancées uniquement. Pour de plus amples informations, veuillez consulter [Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md).
+ L' AWS utilisateur qui modifie le mot de passe doit avoir l'`ssm:SendCommand`autorisation d'accéder au nœud géré. Pour de plus amples informations, veuillez consulter [Restriction de l'accès Run Command en fonction des balises](run-command-setting-up.md#tag-based-access).
**Restriction de l'accès**
La capacité d'un utilisateur à réinitialiser les mots de passe peut être limitée à des nœuds gérés spécifiques. Pour ce faire, utilisez des politiques basées sur une identité pour l'opération Session Manager `ssm:StartSession` avec le document SSM `AWS-PasswordReset`. Pour de plus amples informations, consultez [Contrôler les accès de session utilisateur aux instances](session-manager-getting-started-restrict-access.md).
**Chiffrement de données**
Activez AWS Key Management Service (AWS KMS) le chiffrement complet Session Manager des données afin d'utiliser l'option de réinitialisation du mot de passe pour les nœuds gérés. Pour de plus amples informations, veuillez consulter [Activer le chiffrement des données de session par clé KMS (console)](session-preferences-enable-encryption.md).
## Réinitialisation d'un mot de passe sur un nœud géré
Vous pouvez réinitialiser un mot de passe sur un nœud géré par Systems Manager à l'aide de la **Fleet Manager**console Systems Manager ou du AWS Command Line Interface (AWS CLI).
**Pour modifier le mot de passe sur un nœud géré (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 **Fleet Manager**.
1. Cliquez sur le bouton situé en regard du nœud qui a besoin d'un nouveau mot de passe.
1. Choisissez **Actions de l’instance, Réinitialiser le mot de passe**.
1. Pour **User name (Nom d'utilisateur)**, saisissez le nom de l'utilisateur pour lequel vous modifiez le mot de passe. Il peut s'agir de n'importe quel utilisateur qui dispose d'un compte sur le nœud.
1. Sélectionnez **Submit (Envoyer)**.
1. Suivez les instructions dans la fenêtre de commande **Enter new password (Entrer un nouveau mot)** pour spécifier le nouveau mot de passe.
**Note**
Si la version de SSM Agent disponible sur le nœud géré ne prend pas en charge la réinitialisation des mots de passe, vous êtes invité à installer une version prise en charge à l’aide de Run Command, un outil d’ AWS Systems Manager.
**Pour réinitialiser le mot de passe sur un nœud géré (AWS CLI)**
1. Pour réinitialiser le mot de passe d'un utilisateur sur un nœud géré, exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
**Note**
AWS CLI Pour réinitialiser un mot de passe, le Session Manager plugin doit être installé sur votre ordinateur local. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name "AWS-PasswordReset" \
--parameters '{"username": ["user-name"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name "AWS-PasswordReset" ^
--parameters username="user-name"
```
------
1. Suivez les instructions dans la fenêtre de commande **Enter new password (Entrer un nouveau mot)** pour spécifier le nouveau mot de passe.
## Résolution des problèmes de réinitialisation de mot de passe sur les nœuds gérés
De nombreux problèmes de réinitialisation de mot de passe peuvent être résolus en vous assurant que vous avez rempli les [Prérequis pour la réinitialisation de mot de passe](#pw-reset-prereqs). Pour les autres problèmes, utilisez les informations suivantes pour vous aider à résoudre les problèmes de réinitialisation de mot de passe.
**Topics**
+ [Nœud géré non disponible](#password-reset-troubleshooting-instances)
+ [SSM Agentpas up-to-date (console)](#password-reset-troubleshooting-ssmagent-console)
+ [Les options de réinitialisation du mot de passe ne sont pas fournies (AWS CLI)](#password-reset-troubleshooting-ssmagent-cli)
+ [Pas d'autorisation pour exécuter `ssm:SendCommand`](#password-reset-troubleshooting-sendcommand)
+ [Message d'erreur Session Manager](#password-reset-troubleshooting-session-manager)
### Nœud géré non disponible
**Problème** : vous souhaitez réinitialiser le mot de passe d'un nœud géré sur la page **Managed instances (Instances gérées)** de la console, mais le nœud ne figure pas dans la liste.
+ **Solution** : le nœud géré auquel vous souhaitez vous connecter n'est peut-être pas configuré pour Systems Manager. Pour utiliser une instance EC2 avec Systems Manager, un profil d'instance Gestion des identités et des accès AWS (IAM) autorisant Systems Manager à effectuer des actions sur vos instances doit être attaché à l'instance. Pour plus d’informations, consultez la section [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
Pour utiliser une machine non EC2 avec Systems Manager, créez une fonction du service IAM qui accorde à Systems Manager l'autorisation d'effectuer des actions sur vos nœuds gérés. Pour plus d'informations, voir [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md). (Session Managersupport pour les serveurs sur site) et VMs est fourni uniquement pour le niveau des instances avancées. Pour plus d'informations, voir[Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md).)
### SSM Agentpas up-to-date (console)
**Problème** : un message indique que la version de SSM Agent ne prend pas en charge la fonctionnalité de réinitialisation de mot de passe.
+ **Solution** : la version 2.3 668.0 ou suivante de SSM Agent est requise pour effectuer des réinitialisations de mot de passe. Dans la console, sélectionnez **Update SSM Agent (Mettre à jour l'agent SSM)** pour procéder à la mise à jour de l'agent sur le nœud géré.
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.
### Les options de réinitialisation du mot de passe ne sont pas fournies (AWS CLI)
**Problème** : vous vous connectez correctement à un nœud géré à l'aide de la AWS CLI `[https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)` commande. Vous avez spécifié le document SSM `AWS-PasswordReset` et vous avez fourni un nom utilisateur valide, mais les invites pour modifier le mot de passe n'apparaissent pas.
+ **Solution** : La version de SSM Agent sur le nœud géré ne l'est pas up-to-date. La version 2.3.668.0 ou suivante est requise pour effectuer des réinitialisations de mot de passe.
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.
### Pas d'autorisation pour exécuter `ssm:SendCommand`
**Problème** : vous essayez de vous connecter à un nœud géré pour changer le mot de passe mais vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à exécuter `ssm:SendCommand` sur le nœud géré.
+ **Solution** : Votre politique IAM doit inclure l'autorisation d'exécuter la commande `ssm:SendCommand`. Pour plus d'informations, consultez [Restriction de l'accès Run Command en fonction des balises](run-command-setting-up.md#tag-based-access).
### Message d'erreur Session Manager
**Problème** : vous recevez un message d'erreur relatif à Session Manager.
+ **Solution** : la prise en charge de la réinitialisation de mot de passe nécessite que Session Manager soit configuré correctement. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md) et [Résolution des problèmes de Session Manager](session-manager-troubleshooting.md).
# Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud
Si vous ne souhaitez plus gérer un serveur sur site, un périphérique périphérique ou une machine virtuelle (VM) en utilisant AWS Systems Manager, vous pouvez le désenregistrer. Le désenregistrement d'un nœud activé par hybride le supprime de la liste des nœuds gérés dans Systems Manager. AWS Systems Manager L'agent (SSM Agent) exécuté sur le nœud activé par un système hybride ne pourra pas actualiser son jeton d'autorisation, car il n'est plus enregistré. SSM Agent hibernera et réduira sa fréquence de ping à Systems Manager dans le cloud à une fois par heure. Systems Manager stocke l'historique des commandes d'un nœud géré dont l'enregistrement a été annulé pendant 30 jours.
**Note**
Vous pouvez réenregistrer un serveur local, un appareil de périphérie ou une machine virtuelle en utilisant le même code d’activation et le même ID, tant que vous n’avez pas atteint la limite d’instances pour le code et l’ID d’activation désignés. Vous pouvez vérifier la limite d’instances dans la console en choisissant **Outils pour nœuds**, puis en choisissant **Activations hybrides**. Si la valeur des **instances enregistrées** est inférieure à la **limite d’enregistrement**, vous pouvez réenregistrer une machine en utilisant le même code d’activation et le même ID. Si elle est supérieure, vous devez utiliser un code d’activation et un ID différents.
La procédure suivante décrit comment annuler l'enregistrement d'un nœud activé par un système hybride à l'aide de la console Systems Manager. Pour plus d'informations sur la procédure à suivre à l'aide du AWS Command Line Interface, consultez [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html).
Pour plus d'informations, consultez les rubriques connexes suivantes :
+ [Désenregistrer et réenregistrer un nœud géré (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister) (Linux)
+ [Désenregistrer et réenregistrer un nœud géré (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister) (Windows Server)
**Pour annuler l'enregistrement d'un nœud activé par un système hybride (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 **Fleet Manager**.
1. Cochez la case en regard du nœud géré que vous voulez désenregistrer.
1. Choisissez **Actions de nœud, Outils, Désenregistrer ce nœud géré**.
1. Examinez les informations de la boîte de dialogue **Désenregistrer ce nœud géré**. Si vous approuvez, cliquez sur **Désenregistrer**.
# Travailler avec les systèmes de fichiers du système d’exploitation à l’aide de Fleet Manager
Vous pouvez utiliser Fleet Manager un outil pour travailler avec le système de fichiers sur vos nœuds gérés. AWS Systems ManagerÀ l'aide de Fleet Manager, vous pouvez consulter des informations sur les données de répertoire et de fichier stockées sur les volumes attachés à vos nœuds gérés. Par exemple, vous pouvez afficher le nom, la taille, l'extension, le propriétaire et les autorisations de vos répertoires et fichiers. Vous pouvez prévisualiser jusqu'à 10 000 lignes de données de fichier sous forme de texte depuis la console Fleet Manager. Vous pouvez également utiliser cette fonction pour des fichiers `tail`. Lorsque vous utilisez `tail` pour afficher des données de fichier, les 10 dernières lignes du fichier s'affichent initialement. À mesure que de nouvelles lignes de données sont écrites dans le fichier, l'affichage se met à jour en temps réel. Vous pouvez donc consulter les données de journal depuis la console, ce qui peut accroître votre efficacité de résolution des problèmes et d'administration des systèmes. En outre, vous pouvez créer des répertoires et copier, couper, coller, renommer ou supprimer des fichiers et des répertoires.
Nous vous recommandons de créer des sauvegardes régulières ou de prendre des instantanés des volumes Amazon Elastic Block Store (Amazon EBS) attachés à vos nœuds gérés. Lorsque vous copiez ou coupez et collez des fichiers, les fichiers et répertoires existants de l'emplacement de destination qui portent le même nom que les nouveaux fichiers ou répertoires sont remplacés. De graves problèmes peuvent survenir si vous remplacez ou modifiez des fichiers et des répertoires système. AWS ne garantit pas que ces problèmes puissent être résolus. Toute modification apportée aux fichiers système se fait à vos propres risques. Vous êtes responsable de toutes les modifications que vous apportez aux fichiers et répertoires, et vous devez vous assurer que vous disposez de sauvegardes de ceux-ci. La suppression ou le remplacement de fichiers et de répertoires ne peut pas être annulée.
**Note**
Fleet Managerutilise Session Manager un outil pour afficher des AWS Systems Manager aperçus de texte et des `tail` fichiers. Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), le profil d'instance attaché à vos instances gérées doit fournir à Session Manager les autorisations nécessaires à l'utilisation de cette fonction. Pour de plus amples informations sur l'ajout d'autorisations Session Manager à un profil d'instance, veuillez consulter [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Affichage du système de fichiers du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-viewing-file-system.md)
+ [Prévisualisation des fichiers du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-preview-os-files.md)
+ [Suivi des fichiers du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-tailing-os-files.md)
+ [Copier, couper et coller des fichiers ou des répertoires du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-move-files-or-directories.md)
+ [Renommer des fichiers et des répertoires du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-renaming-files-and-directories.md)
+ [Suppression de fichiers et de répertoires du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-deleting-files-and-directories.md)
+ [Création de répertoires du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-creating-directories.md)
+ [Couper, copier et coller des répertoires du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-managing-directories.md)
# Affichage du système de fichiers du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour afficher le système de fichiers du système d’exploitation sur un nœud géré par Systems Manager.
**Pour afficher le système de fichiers du système d’exploitation à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré associé au système de fichiers que vous souhaitez afficher.
1. Choisissez **Outils, Système de fichiers**.
# Prévisualisation des fichiers du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour prévisualiser des fichiers texte sur un système d’exploitation.
**Pour afficher des aperçus de fichiers texte à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers que vous souhaitez prévisualiser.
1. Choisissez **Outils, Système de fichiers**.
1. Dans le champ **File name (Nom de fichier)**, sélectionnez le nom du répertoire qui contient le fichier que vous souhaitez prévisualiser.
1. Cliquez sur le bouton en regard du fichier dont vous voulez prévisualiser le contenu.
1. Choisissez **Actions, Aperçu sous forme de texte**.
# Suivi des fichiers du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour suivre un fichier sur un nœud géré.
**Pour suivre les fichiers du système d’exploitation avec Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers que vous souhaitez mettre en file.
1. Choisissez **Outils, Système de fichiers**.
1. Dans le champ **File name (Nom de fichier)**, sélectionnez le nom du répertoire qui contient le fichier que vous souhaitez mettre en file.
1. Cliquez sur le bouton en regard du fichier dont vous voulez mettre en file le contenu.
1. Choisissez **Actions, Fichier en queue**.
# Copier, couper et coller des fichiers ou des répertoires du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour copier, couper et coller des fichiers de système d’exploitation sur un nœud géré.
**Pour copier ou couper et coller des fichiers ou des répertoires à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers que vous souhaitez copier ou couper et coller.
1. Choisissez **Outils, Système de fichiers**.
1. Pour copier ou couper un fichier, dans le champ **File name (Nom de fichier)**, choisissez le nom du répertoire qui contient le fichier à copier ou couper. Pour copier ou couper un répertoire, choisissez le bouton situé en regard du répertoire que vous souhaitez copier ou couper, puis passez à l'étape 8.
1. Cliquez sur le bouton situé en regard du fichier que vous souhaitez copier ou couper.
1. Dans le menu **Actions**, sélectionnez **Copy (Copier)** ou **Cut (Couper)**.
1. Dans **File system** (Système de fichiers), choisissez le bouton situé en regard du répertoire dans lequel vous souhaitez coller le fichier.
1. Dans le menu **Actions**, sélectionnez **Paste (Coller)**.
# Renommer des fichiers et des répertoires du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour renommer des fichiers et des répertoires sur un nœud géré dans votre compte.
**Pour renommer des fichiers ou des répertoires avec Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers ou répertoires que vous souhaitez renommer.
1. Choisissez **Outils, Système de fichiers**.
1. Pour renommer un fichier, dans le champ **File name (Nom de fichier)**, sélectionnez le nom du répertoire qui contient le fichier que vous souhaitez renommer. Pour renommer un répertoire, cliquez sur le bouton situé en regard du répertoire que vous souhaitez renommer, puis passez à l'étape 8.
1. Cliquez sur le bouton situé en regard du fichier dont vous souhaitez renommer le contenu.
1. Choisissez **Actions, Renommer**.
1. Dans le champ **Nom du fichier**, saisissez le nouveau nom de fichier et sélectionnez **Renommer**.
# Suppression de fichiers et de répertoires du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour supprimer des fichiers et des répertoires sur un nœud géré dans votre compte.
**Pour supprimer des fichiers ou des répertoires à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers ou répertoires que vous souhaitez supprimer.
1. Choisissez **Outils, Système de fichiers**.
1. Pour supprimer un fichier, dans le champ **File name (Nom de fichier)**, sélectionnez le nom du répertoire qui contient le fichier que vous souhaitez supprimer. Pour supprimer un répertoire, cliquez sur le bouton situé en regard du répertoire que vous souhaitez supprimer, puis passez à l'étape 7.
1. Cliquez sur le bouton situé en regard du fichier dont vous souhaitez supprimer le contenu.
1. Sélectionnez **Actions, Supprimer**.
# Création de répertoires du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour créer des répertoires sur un nœud géré dans votre compte.
**Pour créer un répertoire à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré dans lequel vous souhaitez créer un répertoire.
1. Choisissez **Outils, Système de fichiers**.
1. Sélectionnez le **File name** (Nom de fichier) du répertoire où vous souhaitez créer un nouveau répertoire.
1. Sélectionnez **Create directory** (Créer un répertoire).
1. Dans le champ **Nom du répertoire**, saisissez le nom du nouveau répertoire et sélectionnez **Créer le répertoire**.
# Couper, copier et coller des répertoires du système d’exploitation à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour couper, copier et coller des répertoires sur un nœud géré dans votre compte.
**Pour copier ou copier-coller des répertoires avec Fleet 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. Sélectionnez le lien du nœud géré associé aux fichiers que vous souhaitez copier ou couper et coller.
1. Choisissez **Outils, Système de fichiers**.
1. Choisissez le bouton en regard du répertoire que vous voulez copier ou couper, puis passez à l’étape 8.
1. Dans le menu **Actions**, sélectionnez **Copy (Copier)** ou **Cut (Couper)**.
1. Dans **File system** (Système de fichiers), choisissez le bouton situé en regard du répertoire dans lequel vous souhaitez coller le fichier.
1. Dans le menu **Actions**, sélectionnez **Paste (Coller)**.
# Surveillance de la performance des nœuds gérés
Vous pouvez utiliser Fleet Manager un outil pour visualiser AWS Systems Manager les données de performance de vos nœuds gérés en temps réel. Les données de performance sont extraites des compteurs de performance.
Les compteurs de performance suivants sont disponibles dans Fleet Manager :
+ Utilisation de l’UC
+ Utilisation du disque input/output (E/S)
+ Trafic réseau
+ Utilisation de la mémoire
**Note**
Fleet Managerutilise Session Manager un outil pour récupérer AWS Systems Manager les données de performance. Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), le profil d'instance attaché à vos instances gérées doit fournir à Session Manager les autorisations nécessaires à l'utilisation de cette fonction. Pour de plus amples informations sur l'ajout d'autorisations Session Manager à un profil d'instance, veuillez consulter [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md).
**Pour consulter les données de performances avec Fleet 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. Cliquez sur le bouton situé en regard du nœud géré dont vous souhaitez surveiller la performance.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Compteurs de performance**.
# Utilisation des processus
Vous pouvez utiliser Fleet Manager, un outil d’AWS Systems Manager, pour travailler avec des processus sur vos nœuds gérés. À l'aide de Fleet Manager, vous pouvez consulter des informations sur les processus. Par exemple, vous pouvez visualiser l'utilisation du processeur et de la mémoire des processus en plus de leurs handles et threads. Avec Fleet Manager, vous pouvez démarrer et résilier des processus à partir de la console.
**Note**
Fleet Manager utilise Session Manager, un outil d’AWS Systems Manager, pour récupérer les données de processus. Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), le profil d'instance attaché à vos instances gérées doit fournir à Session Manager les autorisations nécessaires à l'utilisation de cette fonction. Pour de plus amples informations sur l'ajout d'autorisations Session Manager à un profil d'instance, veuillez consulter [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Affichage de détails sur les processus du système d’exploitation à l’aide de Fleet Manager](fleet-manager-view-process-details.md)
+ [Démarrage d’un processus de système d’exploitation sur un nœud géré à l’aide d’Fleet Manager](fleet-manager-start-process.md)
+ [Résilier un processus du système d’exploitation à l’aide d’Fleet Manager](fleet-manager-terminate-process.md)
# Affichage de détails sur les processus du système d’exploitation à l’aide de Fleet Manager
Vous pouvez utiliser Fleet Manager pour afficher les détails des processus sur vos nœuds gérés.
**Pour afficher les détails relatifs aux processus à l'aide de Fleet 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. Sélectionnez le lien du nœud dont vous voulez afficher les processus.
1. Choisissez **Outils, Processus**.
# Démarrage d’un processus de système d’exploitation sur un nœud géré à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager pour démarrer un processus sur un nœud géré.
**Pour démarrer un processus avec Fleet 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. Sélectionnez le lien du nœud géré sur lequel vous voulez démarrer un processus.
1. Choisissez **Outils, Processus**.
1. Sélectionnez **Start new process** (Démarrer un nouveau processus).
1. Dans le champ **Nom du processus ou chemin d’accès complet**, saisissez le nom du processus ou le chemin d’accès complet à l’exécutable.
1. (Facultatif) Dans le champ **Répertoire de travail**, saisissez le chemin d’accès au répertoire dans lequel vous souhaitez que le processus s’exécute.
# Résilier un processus du système d’exploitation à l’aide d’Fleet Manager
**Pour résilier un processus de système d’exploitation à l’aide d’Fleet 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. Sélectionnez le lien du nœud géré sur lequel vous voulez démarrer un processus.
1. Choisissez **Outils, Processus**.
1. Cliquez sur le bouton situé en regard du processus que vous souhaitez arrêter.
1. Sélectionnez **Actions, Terminer le processus** ou **Actions, Arrêter l’arborescence du processus**.
**Note**
L'arrêt d'une arborescence de processus met également fin à tous les processus et applications qui utilisent ce processus.
# Affichage des journaux sur les nœuds gérés
Vous pouvez utiliser l’outil Fleet Manager d’AWS Systems Manager pour visualiser les données de journal stockées sur vos nœuds gérés. Concernant les nœuds gérés Windows, vous pouvez afficher les journaux d'événements Windows et copier leurs détails depuis la console. Pour faciliter la recherche d'événements, filtrez les journaux d'événements Windows par **Niveau d'événement**, **ID d'événement**, **Source de l'événement** et **Heure de création**. Vous pouvez également afficher d'autres données du journal via la procédure d'affichage du système de fichiers. Pour de plus amples informations sur l'affichage du système de fichiers avec Fleet Manager, veuillez consulter [Travailler avec les systèmes de fichiers du système d’exploitation à l’aide de Fleet Manager](fleet-manager-file-system-management.md).
**Pour afficher les journaux d'événements Windows avec Fleet Manager**
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 **Fleet Manager**.
1. Cliquez sur le bouton situé en regard du nœud géré dont vous souhaitez visualiser les journaux d'événements.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Journaux d’événements Windows**.
1. Sélectionnez le **Nom de journal** contenant les événements que vous voulez afficher.
1. Cliquez sur le bouton en regard du **Nom de journal** que vous voulez afficher, puis sélectionnez **Afficher les événements**.
1. Cliquez sur le bouton en regard de l'événement que vous voulez afficher, puis sélectionnez **Afficher les détails de l'événement**.
1. (Facultatif) Sélectionnez **Copier en tant que JSON** pour copier les détails de l'événement dans le presse-papier.
# Gestion des comptes et groupes d’utilisateurs de systèmes d’exploitation sur les nœuds gérés à l’aide d’Fleet Manager
Vous pouvez utiliser Fleet Manager un outil dans AWS Systems Manager, pour gérer les comptes et les groupes d'utilisateurs du système d'exploitation (OS) sur vos nœuds gérés. Par exemple, vous pouvez créer et supprimer des utilisateurs et des groupes. En outre, vous pouvez afficher des détails tels que l'appartenance à un groupe, des rôles utilisateur et un statut.
**Important**
Fleet Managerutilisations Run Command et outils Session Manager intégrés à AWS Systems Manager, pour diverses opérations de gestion des utilisateurs. Par conséquent, un utilisateur peut octroyer des autorisations à un compte utilisateur du système d'exploitation, ce qui ne serait pas possible autrement. Cela est dû au fait que AWS Systems Manager Agent (SSM Agent) s'exécute sur des instances Amazon Elastic Compute Cloud (Amazon EC2) à l'aide des autorisations root (Linux) ou des autorisations SYSTEM (). Windows Server Pour de plus amples informations sur les restrictions d'accès aux commandes de niveau racine via l'SSM Agent, veuillez consulter [Limitation de l'accès aux commandes de niveau racine via l'SSM Agent](ssm-agent-restrict-root-level-commands.md). Pour restreindre l'accès à cette fonctionnalité, nous vous recommandons de créer des politiques Gestion des identités et des accès AWS (IAM) pour vos utilisateurs qui autorisent uniquement l'accès aux actions que vous définissez. Pour plus d'informations sur la création des politiques IAM pour Fleet Manager, consultez [Contrôle de l'accès à Fleet Manager](configuring-fleet-manager-permissions.md).
**Topics**
+ [Création d’un utilisateur ou d’un groupe de système d’exploitation à l’aide de Fleet Manager](manage-os-user-accounts-create.md)
+ [Mise à jour de l’appartenance à un utilisateur ou à un groupe en utilisant Fleet Manager](manage-os-user-accounts-update.md)
+ [Suppression d’un utilisateur ou d’un groupe de système d’exploitation en utilisant Fleet Manager](manage-os-user-accounts-delete.md)
# Création d’un utilisateur ou d’un groupe de système d’exploitation à l’aide de Fleet Manager
**Note**
Fleet Manager utilise Session Manager pour définir des mots de passe pour les nouveaux utilisateurs. Concernant les instances Amazon EC2, le profil d'instance attaché à vos nœuds gérés doit fournir à Session Manager les autorisations nécessaires pour utiliser cette fonction. Pour de plus amples informations sur l'ajout d'autorisations Session Manager à un profil d'instance, veuillez consulter [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md).
Au lieu de vous connecter directement à un serveur pour créer un compte d’utilisateur ou un groupe, vous pouvez utiliser la console Fleet Manager pour effectuer les mêmes tâches.
**Pour créer un compte utilisateur de système d’exploitation à l’aide de Fleet 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. Cliquez sur le bouton situé en regard du nœud géré sur lequel vous souhaitez créer un nouvel utilisateur.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Utilisateurs et groupes**.
1. Sélectionnez l'onglet **Users (Utilisateurs)**, puis **Create user (Créer un utilisateur)**.
1. Saisissez une valeur pour le **Nom** du nouvel utilisateur.
1. (Recommandé) Cochez la case en regard de **Définir mot de passe**. Au terme de la procédure, vous serez invité à fournir un mot de passe pour le nouvel utilisateur.
1. Sélectionnez **Create user (Créer un utilisateur)**. Si vous avez coché la case de création d'un mot de passe pour le nouvel utilisateur, vous serez invité à saisir une valeur pour le mot de passe et à sélectionner **Terminé**. Si le mot de passe que vous spécifiez ne répond pas aux exigences spécifiées par les politiques locales ou par les politiques de domaine de votre nœud géré, une erreur est renvoyée.
**Pour créer un groupe de système d’exploitation à l’aide de Fleet 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. Cliquez sur le bouton situé en regard du nœud géré dans lequel vous souhaitez créer un groupe.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Utilisateurs et groupes**.
1. Sélectionnez l'onglet **Groups (Groupes)**, puis **Create group (Créer un groupe)**.
1. Saisissez une valeur pour le **Nom** du nouveau groupe.
1. (Facultatif) Saisissez une valeur pour la **Description** du nouveau groupe.
1. (Facultatif) Sélectionnez les utilisateurs à ajouter aux **Membres du groupe** du nouveau groupe.
1. Sélectionnez **Create group (Créer un groupe)**.
# Mise à jour de l’appartenance à un utilisateur ou à un groupe en utilisant Fleet Manager
Au lieu de vous connecter directement à un serveur pour mettre à jour un compte d’utilisateur ou un groupe, vous pouvez utiliser la console Fleet Manager pour effectuer les mêmes tâches.
**Pour ajouter un compte utilisateur de système d’exploitation à un nouveau groupe en utilisant Fleet 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. Cliquez sur le bouton situé en regard du nœud géré contenant le compte utilisateur que vous souhaitez mettre à jour.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Utilisateurs et groupes**.
1. Sélectionnez l'onglet **Utilisateurs**.
1. Cliquez sur le bouton en regard de l'utilisateur que vous voulez mettre à jour.
1. Choisissez **Actions, Ajouter un utilisateur au groupe**.
1. Sélectionnez le groupe auquel vous voulez ajouter l'utilisateur sous **Ajouter à un groupe**.
1. Sélectionnez **Ajouter un utilisateur à un groupe**.
**Pour modifier la composition d’un groupe de système d’exploitation en utilisant Fleet 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. Cliquez sur le bouton situé en regard du nœud géré contenant le groupe que vous souhaitez mettre à jour.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Utilisateurs et groupes**.
1. Cliquez sur l'onglet **Groups (Groupes)**.
1. Cliquez sur le bouton en regard du groupe que vous voulez mettre à jour.
1. Choisissez **Actions, Modifier le groupe**.
1. Sélectionnez les utilisateurs que vous voulez ajouter ou supprimer sous **Membres du groupe**.
1. Sélectionnez **Modifier un groupe**.
# Suppression d’un utilisateur ou d’un groupe de système d’exploitation en utilisant Fleet Manager
Au lieu de vous connecter directement à un serveur pour supprimer un compte utilisateur ou un groupe, vous pouvez utiliser la console Fleet Manager pour effectuer les mêmes tâches.
**Pour supprimer un compte utilisateur de système d’exploitation en utilisant Fleet 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. Cliquez sur le bouton situé en regard du nœud géré contenant le compte utilisateur que vous souhaitez supprimer.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Utilisateurs et groupes**.
1. Sélectionnez l'onglet **Utilisateurs**.
1. Cliquez sur le bouton en regard de l'utilisateur que vous voulez supprimer.
1. Choisissez **Actions, Supprimer l’utilisateur local**.
**Pour supprimer un groupe de systèmes d’exploitation en utilisant Fleet 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. Cliquez sur le bouton situé en regard du nœud géré contenant le groupe que vous souhaitez supprimer.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Utilisateurs et groupes**.
1. Cliquez sur l'onglet **Group (Groupe)**.
1. Cliquez sur le bouton en regard du groupe que vous voulez mettre à jour.
1. Choisissez **Actions, Supprimer le groupe local**.
# Gestion du registre Windows sur les nœuds gérés
Vous pouvez utiliser Fleet Manager un outil dans AWS Systems Manager, pour gérer le registre sur vos nœuds Windows Server gérés. Depuis la Fleet Manager, vous pouvez créer, copier, mettre à jour et supprimer des entrées et des valeurs de registre.
**Important**
Avant de modifier le registre, nous vous recommandons de créer une sauvegarde de celui-ci ou de prendre un instantané du volume Amazon Elastic Block Store (Amazon EBS) racine attaché à votre nœud géré. Une modification incorrecte du registre peut entraîner de graves problèmes. Ces problèmes peuvent vous obliger à réinstaller le système d'exploitation ou à restaurer le volume racine de votre nœud à partir d'un instantané. AWS ne garantit pas que ces problèmes puissent être résolus. Vous modifiez le registre à vos propres risques. Vous êtes responsable de toutes les modifications apportées au registre et vous devez vous assurer de disposer de sauvegardes.
## Créer une clé ou une entrée de registre Windows
**Pour créer une clé de registre Windows avec Fleet 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. Cliquez sur le bouton situé en regard du nœud géré sur lequel vous souhaitez créer une clé de registre.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Registre Windows**.
1. Sélectionnez le programme Hive dans lequel vous voulez créer une nouvelle clé de registre en sélectionnant le **Nom de registre**.
1. Choisissez **Créer, Créer une clé de registre**.
1. Cliquez sur le bouton en regard de l'entrée de registre dans laquelle vous voulez créer une nouvelle clé.
1. Sélectionnez **Créer une clé de registre**.
1. Saisissez une valeur pour le paramètre **Nom** de la nouvelle clé de Registre, puis sélectionnez **Envoyer**.
**Pour créer une entrée de registre Windows avec Fleet 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. Cliquez sur le bouton en regard de l'instance sur laquelle vous voulez créer une entrée de registre.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Registre Windows**.
1. Sélectionnez le programme Hive et la clé de registre suivante dans laquelle vous voulez créer une nouvelle entrée de registre en sélectionnant le **Nom de registre**.
1. Choisissez **Créer, Créer une entrée de registre**.
1. Saisissez une valeur pour le **Name (Nom)** de la nouvelle entrée de registre.
1. Sélectionnez le **Type** de valeur que vous voulez créer pour l'entrée de registre. Pour de plus amples informations sur les types de valeur de registre, veuillez consulter [Types de valeurs de registre](https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types).
1. Saisissez une valeur pour la **Valeur** de la nouvelle entrée de registre.
## Mettre à jour une entrée de Registre Windows
**Pour mettre à jour une entrée de registre Windows avec Fleet 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. Cliquez sur le bouton situé en regard du nœud géré sur lequel vous souhaitez mettre à jour une entrée de registre.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Registre Windows**.
1. Sélectionnez le programme Hive et la clé de registre suivante que vous voulez mettre à jour en sélectionnant le **Nom de registre**.
1. Cliquez sur le bouton en regard de l'entrée de registre que vous voulez mettre à jour.
1. Choisissez **Actions, Mettre à jour l’entrée de registre**.
1. Saisissez la nouvelle valeur pour la **Value (Valeur)** de l'entrée de registre.
1. Choisissez **Mettre à jour**.
## Supprimer une entrée ou une clé de registre Windows
**Pour supprimer une clé de registre Windows avec Fleet 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. Cliquez sur le bouton situé en regard du nœud géré sur lequel vous souhaitez supprimer une clé de registre.
1. Choisissez **Outils, Registre Windows**.
1. Sélectionnez le programme Hive et la clé de registre suivante que vous voulez supprimer en sélectionnant le **Nom de registre**.
1. Cliquez sur le bouton en regard de la clé de registre que vous voulez supprimer.
1. Choisissez **Actions, Supprimer la clé de registre**.
**Pour supprimer une entrée de registre Windows avec Fleet 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. Cliquez sur le bouton situé en regard du nœud géré sur lequel vous souhaitez supprimer une entrée de registre.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Registre Windows**.
1. Sélectionnez le programme Hive et la clé de registre suivante contenant l'entrée que vous voulez supprimer en sélectionnant le **Nom du registre**.
1. Cliquez sur le bouton en regard de l'entrée de registre que vous voulez supprimer.
1. Choisissez **Actions, Supprimer l’entrée du registre**.
# Gestion automatique des instances EC2 avec la configuration par défaut de la gestion des hôtes
Le paramètre de configuration de gestion d'hôte par défaut AWS Systems Manager permet de gérer automatiquement vos instances Amazon EC2 en tant qu'instances *gérées*. Une instance gérée est une instance EC2 configurée pour une utilisation avec Systems Manager.
Les avantages de la gestion de vos instances avec Systems Manager sont les suivants :
+ Connectez-vous à vos instances EC2 en toute sécurité à l'aide de Session Manager.
+ Effectuez des analyses de correctifs automatisées à l'aide de Patch Manager.
+ Consultez les informations détaillées sur vos instances à l'aide de Systems Manager Inventory.
+ Suivez et gérez les instances à l'aide de Fleet Manager.
+ Maintenez l'SSM Agent à jour automatiquement.
*Fleet Manager, Inventory, Patch Manager et Session Manager sont des outils de Systems Manager.*
À l'aide de la configuration de gestion d'hôte par défaut, vous pouvez gérer les instances EC2 sans avoir à créer manuellement un profil d'instance Gestion des identités et des accès AWS (IAM). Au lieu de cela, la configuration de gestion d'hôte par défaut crée et applique un rôle IAM par défaut pour garantir que Systems Manager dispose des autorisations nécessaires pour gérer toutes les instances dans le Compte AWS et à l' Région AWS endroit où il est activé.
Si les autorisations fournies ne sont pas suffisantes pour votre cas d'utilisation, vous pouvez également ajouter des politiques au rôle IAM par défaut créé par la configuration de gestion des hôtes par défaut. Sinon, si vous n'avez pas besoin d'autorisations pour toutes les fonctionnalités fournies par le rôle IAM par défaut, vous pouvez créer vos propres rôles et politiques personnalisés. Toutes les modifications apportées au rôle IAM que vous choisissez pour la configuration de gestion des hôtes par défaut s'appliquent à toutes les instances Amazon EC2 gérées dans la région et le compte.
Pour plus d'informations sur la politique utilisée par la Configuration de gestion des hôtes par défaut, consultez [AWS politique gérée : Amazon SSMManaged EC2 InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy).
**Implémentation d’un accès sur la base du moindre privilège**
Les procédures de la présente rubrique sont destinées à être exécutées uniquement par les administrateurs. Par conséquent, nous recommandons d'implémenter *l'accès avec le moindre privilège* afin d'empêcher les utilisateurs non administrateurs de configurer ou de modifier la configuration de gestion des hôtes par défaut. Pour consulter des exemples de politiques qui limitent l'accès à la configuration de gestion des hôtes par défaut, voir [Exemples de politique du moindre privilège pour la configuration de gestion des hôtes par défaut](#least-privilege-examples) plus loin dans cette rubrique.
**Important**
Les informations d’enregistrement des instances enregistrées à l’aide de la configuration par défaut de la gestion des hôtes sont stockées localement dans les répertoires `var/lib/amazon/ssm` ou `C:\ProgramData\Amazon`. La suppression de ces répertoires ou de leurs fichiers empêchera l'instance d'acquérir les informations d'identification nécessaires pour se connecter à Systems Manager à l'aide de la configuration de gestion des hôtes par défaut. Dans ces cas, vous devez utiliser un profil d’instance IAM pour fournir les autorisations requises à votre instance, ou recréer l’instance.
**Topics**
+ [Conditions préalables](#dhmc-prerequisites)
+ [Activation du paramètre Configuration par défaut de la gestion des hôtes](#dhmc-activate)
+ [Désactivation du paramètre Configuration par défaut de la gestion des hôtes](#dhmc-deactivate)
+ [Exemples de politique du moindre privilège pour la configuration de gestion des hôtes par défaut](#least-privilege-examples)
## Conditions préalables
Pour utiliser la configuration de gestion d'hôte par défaut dans Région AWS et Compte AWS là où vous activez le paramètre, les conditions suivantes doivent être remplies.
+ Une instance à gérer doit utiliser le service de métadonnées d'instance version 2 (IMDSv2).
La configuration de gestion des hôtes par défaut ne prend pas en charge du Service des métadonnées d'instance Version 1. Pour plus d'informations sur la transition vers IMDSv2, consultez la section [Transition vers l'utilisation du service de métadonnées d'instance version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) dans le guide de l'*utilisateur Amazon EC2*
+ SSM Agent version 3.2.582.0 ou une version ultérieure doit être installé sur l'instance à gérer.
Pour plus d'informations sur la vérification de la version de l'SSM Agent installée sur votre instance, consultez [Vérification du numéro de version de l'SSM Agent](ssm-agent-get-version.md).
Pour plus d'informations sur la mise à jour de l'SSM Agent, veuillez consulter la rubrique [Mise à jour automatique de l'SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
+ En tant qu'administrateur effectuant les tâches décrites dans cette rubrique, vous devez disposer d'autorisations pour les opérations [GetServiceSetting[ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html), et [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)API. En outre, vous devez disposer des autorisations nécessaires pour l'autorisation `iam:PassRole` du rôle IAM `AWSSystemsManagerDefaultEC2InstanceManagementRole`. Voici un exemple de politique fournissant ces autorisations. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
+ Si un profil d'instance IAM est déjà attaché à une instance EC2 à gérer à l'aide de Systems Manager, vous devez supprimer toutes les autorisations qui permettent l'opération `ssm:UpdateInstanceInformation`. Le SSM Agent tente d'utiliser les autorisations du profil d'instance avant d'utiliser les autorisations de la Configuration de gestion des hôtes par défaut. Si vous autorisez l'opération `ssm:UpdateInstanceInformation` dans votre propre profil d'instance IAM, l'instance n'utilisera pas les autorisations de configuration de gestion des hôtes par défaut.
## Activation du paramètre Configuration par défaut de la gestion des hôtes
Vous pouvez activer la configuration de gestion d'hôte par défaut depuis la Fleet Manager console ou en utilisant le AWS Command Line Interface ou AWS Tools for Windows PowerShell.
Vous devez activer la Configuration par défaut de la gestion des hôtes une par une dans chaque région où vous voulez que vos instances Amazon EC2 soient gérées par ce paramètre.
Après avoir activé la Configuration par défaut de la gestion des hôtes, il peut s’écouler jusqu’à 30 minutes avant que vos instances utilisent les informations d’identification du rôle que vous avez choisi à l’étape 5 de la procédure suivante.
**Pour activer la configuration de gestion des hôtes par défaut (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 **Fleet Manager**.
1. Choisissez **Gestion de compte, Configuration de la gestion des hôtes par défaut**.
1. Activez l'option **Activer la configuration de gestion des hôtes par défaut**.
1. Choisissez le rôle Gestion des identités et des accès AWS (IAM) utilisé pour activer les outils Systems Manager pour vos instances. Nous vous recommandons d'utiliser le rôle par défaut dans Configuration de gestion des hôtes par défaut. Il contient l'ensemble des autorisations minimum pour gérer vos instances Amazon EC2 à l'aide de Systems Manager. Si vous préférez utiliser un rôle personnalisé, la politique de confiance du rôle doit autoriser Systems Manager en tant qu'entité de confiance.
1. Choisissez **Configurer** pour terminer la configuration.
**Pour activer la configuration de gestion des hôtes par défaut (ligne de commande)**
1. Créez un fichier JSON sur votre machine locale, contenant la politique de relation de confiance.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. Ouvrez le AWS CLI ou les outils pour Windows PowerShell et exécutez l'une des commandes suivantes, en fonction du type de système d'exploitation de votre ordinateur local, pour créer un rôle de service dans votre compte. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole \
--path /service-role/ \
--assume-role-policy-document file://trust-policy.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole ^
--path /service-role/ ^
--assume-role-policy-document file://trust-policy.json
```
------
#### [ PowerShell ]
```
New-IAMRole `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole" `
-Path "/service-role/" `
-AssumeRolePolicyDocument "file://trust-policy.json"
```
------
1. Exécutez la commande suivante pour attacher la politique gérée `AmazonSSMManagedEC2InstanceDefaultPolicy` au rôle que vous venez de créer. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Register-IAMRolePolicy `
-PolicyArn "arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy" `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
1. Ouvrez le AWS CLI ou les outils pour Windows PowerShell et exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role ^
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role" `
-SettingValue "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
Il n'y a pas de sortie si la commande réussit.
1. Exécutez la commande suivante pour afficher les paramètres de service actuels pour la configuration de gestion d'hôte par défaut dans les versions actuelles Compte AWS et Région AWS.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
La commande renvoie des informations telles que les suivantes.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/default-ec2-instance-management-role",
"SettingValue": "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"LastModifiedDate": "2022-11-28T08:21:03.576000-08:00",
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:-123456789012:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Status": "Custom"
}
}
```
## Désactivation du paramètre Configuration par défaut de la gestion des hôtes
Vous pouvez désactiver la configuration de gestion d'hôte par défaut depuis la Fleet Manager console ou en utilisant le AWS Command Line Interface ou AWS Tools for Windows PowerShell.
Vous devez désactiver le paramètre Configuration par défaut de la gestion d’hôte une par une dans chaque région où vous ne voulez plus que vos instances Amazon EC2 soient gérées par cette configuration. Le désactiver dans une région ne le désactive pas dans toutes les régions.
Si vous désactivez la configuration de gestion des hôtes par défaut et que vous n'avez pas associé de profil d'instance à vos instances Amazon EC2 autorisant l'accès à Systems Manager, celles-ci ne seront plus gérées par Systems Manager.
**Pour désactiver la configuration de gestion des hôtes par défaut (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 **Fleet Manager**.
1. Choisissez **Gestion de compte, Configuration de la gestion des hôtes par défaut**.
1. Désactivez l'option **Activer la Configuration de gestion des hôtes par défaut**.
1. Choisissez **Configurer** pour désactiver la Configuration de gestion des hôtes par défaut.
**Pour désactiver la configuration de gestion des hôtes par défaut (ligne de commande)**
+ Ouvrez le AWS CLI ou les outils pour Windows PowerShell et exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm reset-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm reset-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Reset-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
## Exemples de politique du moindre privilège pour la configuration de gestion des hôtes par défaut
Les exemples de politiques suivants montrent comment empêcher les membres de votre organisation d'apporter des modifications au paramètre de configuration de gestion des hôtes par défaut dans votre compte.
### Politique de contrôle des services pour AWS Organizations
La politique suivante explique comment empêcher les membres non administrateurs de mettre à jour votre paramètre AWS Organizations de configuration de gestion d'hôte par défaut. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:*:*:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ssm.amazonaws.com"
},
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole"
],
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
}
]
}
```
------
### Politique pour les principaux IAM
La politique suivante explique comment empêcher les groupes, les rôles ou les utilisateurs IAM de mettre à jour votre paramètre AWS Organizations de configuration de gestion d'hôte par défaut. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
}
]
}
```
------
# Connexion à une instance gérée Windows Server à l’aide d’Remote Desktop
Vous pouvez utiliser Fleet Manager un outil pour vous connecter à vos instances Windows Server Amazon Elastic Compute Cloud (Amazon EC2) à l'aide Remote Desktop Protocol du (RDP). AWS Systems ManagerFleet Manager Le bureau à distance , qui fonctionne avec [Amazon DCV](https://docs.aws.amazon.com/dcv/latest/adminguide/what-is-dcv.html), vous fournit une connectivité sécurisée à vos instances Windows Server directement depuis la console Systems Manager. Vous pouvez établir jusqu'à quatre connexions simultanées dans une seule fenêtre de navigateur.
L'API Fleet Manager Remote Desktop est nommée AWS Systems Manager GUI Connect. Pour plus d’informations sur l’utilisation de l’API Systems Manager GUI Connect, consultez la *[Référence de l’API AWS Systems Manager GUI Connect](https://docs.aws.amazon.com/ssm-guiconnect/latest/APIReference)*.
Actuellement, vous ne pouvez utiliser le Bureau à distance qu’avec des instances exécutant Windows Server 2012 RTM ou une version ultérieure. Le Bureau à distance prend uniquement en charge la langue anglaise.
Fleet Manager Remote Desktop est un service de console uniquement et ne prend pas en charge les connexions en ligne de commande à vos instances gérées. Pour vous connecter à une instance gérée Windows Server via un shell, vous pouvez utiliser Session Manager, un autre outil d’ AWS Systems Manager. Pour de plus amples informations, veuillez consulter [AWS Systems Manager Session Manager](session-manager.md).
**Note**
La durée d’une connexion RDP n’est pas déterminée par la durée de vos informations d’identification Gestion des identités et des accès AWS (IAM). Au lieu de cela, la connexion persiste jusqu’à ce que la durée maximale de connexion ou la limite de temps d’inactivité soit atteinte, selon la première éventualité. Pour de plus amples informations, veuillez consulter [Durée et simultanéité des connexions distantes](#rdp-duration-concurrency).
Pour plus d'informations sur la configuration des autorisations Gestion des identités et des accès AWS (IAM) permettant à vos instances d'interagir avec Systems Manager, consultez la section [Configurer les autorisations d'instance pour Systems Manager](setup-instance-permissions.md).
**Topics**
+ [Configuration de votre environnement](#rdp-prerequisites)
+ [Configuration des autorisations IAM pour le Bureau à distance](#rdp-iam-policy-examples)
+ [Authentification des connexions Bureau à distance](#rdp-authentication)
+ [Durée et simultanéité des connexions distantes](#rdp-duration-concurrency)
+ [Gestion des AWS IAM Identity Center attributs par Systems Manager GUI Connect](#iam-identity-center-attribute-handling)
+ [Connexion à un nœud géré à l'aide du Bureau à distance](#rdp-connect-to-node)
+ [Affichage d’informations sur les connexions en cours et terminées](#list-connections)
## Configuration de votre environnement
Avant d'utiliser le Bureau à distance, vérifiez que votre environnement respecte les conditions requises suivantes :
+ **Configuration des nœuds gérés**
Assurez-vous que vos instances Amazon EC2 sont configurées en tant que [nœuds gérés](fleet-manager-managed-nodes.md) dans Systems Manager.
+ **Version minimale de SSM Agent**
Vérifiez que les nœuds exécutent SSM Agent version 3.0.222.0 ou supérieure. Pour plus d'informations sur la vérification de la version de l'agent exécutée sur un nœud, veuillez consulter la rubrique [Vérification du numéro de version de l'SSM Agent](ssm-agent-get-version.md). Pour plus d'informations sur l'installation ou la mise à jour de SSM Agent, consultez [Utilisation de l’option SSM Agent](ssm-agent.md).
+ **Configuration du port RDP**
Pour accepter les connexions distantes, le service Remote Desktop Services sur vos nœuds Windows Server doit utiliser le port RDP 3389 par défaut. Il s'agit de la configuration par défaut sur Amazon Machine Images (AMIs) fournie par AWS. Vous n'êtes pas explicitement obligé d'ouvrir des ports entrants pour utiliser le Bureau à distance.
+ **Version du module PSReadLine pour les fonctionnalités du clavier**
Pour vous assurer que votre clavier fonctionne correctement dans PowerShell, vérifiez que la version 2.2.2 ou supérieure du module PSReadLine est installée sur les nœuds exécutant Windows Server 2022. S’ils utilisent une version antérieure, vous pouvez installer la version requise à l’aide des commandes suivantes.
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
```
Une fois le fournisseur de NuGet package installé, exécutez la commande suivante.
```
Install-Module `
-Name PSReadLine `
-Repository PSGallery `
-MinimumVersion 2.2.2 -Force
```
+ **Configuration de Session Manager**
Avant de pouvoir utiliser le Bureau à distance, vous devez remplir les conditions suivantes pour la configuration de Session Manager. Lorsque vous vous connectez à une instance à l'aide de Remote Desktop, toutes les préférences de session définies pour votre Compte AWS et Région AWS sont appliquées. Pour de plus amples informations, veuillez consulter [Configuration de Session Manager](session-manager-getting-started.md).
**Note**
Si vous journalisez l'activité de Session Manager à l'aide d'Amazon Simple Storage Service (Amazon S3), vos connexions Bureau à distance génèrent l'erreur suivante dans `bucket_name/Port/stderr`. Cette erreur est prévue et peut être ignorée sans risque.
```
Setting up data channel with id SESSION_ID failed: failed to create websocket for datachannel with error: CreateDataChannel failed with no output or error: createDataChannel request failed: unexpected response from the service
Session is already terminated
```
## Configuration des autorisations IAM pour le Bureau à distance
Outre les autorisations IAM requises pour Systems Manager et Session Manager, l’utilisateur ou le rôle que vous utilisez doit être autorisé à établir des connexions.
**Autorisations pour l’établissement de connexions**
Pour établir des connexions RDP à des instances EC2 dans la console, les autorisations suivantes sont requises :
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
**Autorisations pour répertorier les connexions**
Pour afficher des listes de connexions dans la console, l’autorisation suivante est requise :
`ssm-guiconnect:ListConnections`
Vous trouverez ci-dessous des exemples de politiques IAM que vous pouvez attacher à un utilisateur ou un rôle pour permettre différents types d'interaction avec le Bureau à distance. Remplacez chaque *example resource placeholder* par vos propres informations.
### Politique standard de connexion aux instances EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Politique de connexion à des instances EC2 avec des balises spécifiques
**Note**
Dans la politique IAM suivante, la section `SSMStartSession` requiert un Amazon Resource Name (ARN) pour l’action `ssm:StartSession`. Comme indiqué, l'ARN que vous spécifiez *ne nécessite pas* d' Compte AWS ID. Si vous spécifiez un ID de compte, Fleet Manager renvoie un `AccessDeniedException`.
La `AccessTaggedInstances` section, située plus bas dans l'exemple de politique, nécessite ARNs également`ssm:StartSession`. Pour ceux-là ARNs, vous spécifiez Compte AWS IDs.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "AccessTaggedInstances",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag key": [
"tag value"
]
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Politique permettant AWS IAM Identity Center aux utilisateurs de se connecter aux instances EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSO",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations*",
"identitystore:DescribeUser"
],
"Resource": "*"
},
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userName}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "SSMSendCommand",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWSSSO-CreateSSOUser"
]
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
## Authentification des connexions Bureau à distance
Lorsque vous établissez une connexion distante, vous pouvez vous authentifier à l’aide des informations d’identification Windows ou de la paire de clés Amazon EC2 (fichier `.pem`) associée à l’instance. Pour obtenir les informations relatives à l’utilisation des paires de clés, veuillez consulter la rubrique [Paires de clés Amazon EC2 et instances Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*.
Sinon, si vous êtes authentifié auprès de l'utilisateur AWS IAM Identity Center, AWS Management Console vous pouvez vous connecter à vos instances sans fournir d'informations d'identification supplémentaires. Pour obtenir un exemple de politique permettant l'authentification des connexions distantes à l'aide d'IAM Identity Center, veuillez consulter la rubrique [Configuration des autorisations IAM pour le Bureau à distance](#rdp-iam-policy-examples).
**Avant de commencer**
Veuillez tenir compte des conditions suivantes pour l'utilisation de l'authentification IAM Identity Center avant de commencer à vous connecter via le Bureau à distance.
+ Le Bureau à distance prend en charge l'authentification IAM Identity Center pour les nœuds dans la Région AWS dans laquelle vous avez activé IAM Identity Center.
+ Le Bureau à distance prend en charge les noms d'utilisateur IAM Identity Center comportant jusqu'à 16 caractères.
+ Le Bureau à distance prend en charge les noms d'utilisateur IAM Identity Center comportant des caractères alphanumériques et les caractères spéciaux suivants : `.` `-` `_`
**Important**
Les connexions échoueront pour les noms d’utilisateur IAM Identity Center qui contiennent les caractères suivants : `+` `=` `,`
IAM Identity Center prend en charge ces caractères dans les noms d'utilisateur, mais pas les connexions RDP Fleet Manager.
En outre, si un nom d’utilisateur IAM Identity Center contient un ou plusieurs symboles `@`, Fleet Manager ne tient pas compte du premier symbole `@` et de tous les caractères qui le suivent, que le `@` introduise ou non la partie domaine d’une adresse e-mail. Par exemple, pour le nom d’utilisateur IAM Identity Center `diego_ramirez@example.com`, la partie `@example.com` est ignorée et le nom d’utilisateur de Fleet Manager devient `diego_ramirez`. Pour `diego_r@mirez@example.com`, Fleet Manager ignore `@mirez@example.com` et le nom d’utilisateur de Fleet Manager devient `diego_r`.
+ Lorsqu'une connexion est authentifiée à l'aide d'IAM Identity Center, le Bureau à distance crée un utilisateur local Windows dans le groupe d'administrateurs locaux de l'instance. Cet utilisateur persiste après la fin de la connexion distante.
+ Le Bureau à distance n'autorise pas l'authentification IAM Identity Center pour les nœuds qui sont des contrôleurs de domaine Microsoft Active Directory.
+ Bien que le Bureau à distance vous permette d'utiliser l'authentification IAM Identity Center pour les nœuds *joints* à un domaine Active Directory, nous vous déconseillons de le faire. Cette méthode d'authentification accorde aux utilisateurs des autorisations administratives qui peuvent remplacer les autorisations plus restrictives accordées par le domaine.
**Régions prises en charge pour l'authentification IAM Identity Center**
Les connexions Remote Desktop qui utilisent l'authentification IAM Identity Center sont prises en charge dans les Régions AWS 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)
+ Afrique (Le Cap) (af-south-1)
+ Asie-Pacifique (Hong Kong) (ap-east-1)
+ Asie-Pacifique (Mumbai) (ap-south-1)
+ Asie-Pacifique (Tokyo) (ap-northeast-1)
+ Asie-Pacifique (Séoul) (ap-northeast-2)
+ Asie-Pacifique (Osaka) (ap-northeast-3)
+ Asie-Pacifique (Singapour) (ap-southeast-1)
+ Asie-Pacifique (Sydney) (ap-southeast-2)
+ Asie-Pacifique (Jakarta) (ap-southeast-3)
+ Canada (Centre) (ca-central-1)
+ Europe (Francfort) (eu-central-1)
+ Europe (Stockholm) (eu-north-1)
+ Europe (Irlande) (eu-west-1)
+ Europe (Londres) (eu-west-2)
+ Europe (Paris) (eu-west-3)
+ Israël (Tel Aviv) (il-central-1)
+ Amérique du Sud (São Paulo) (sa-east-1)
+ Europe (Milan) (eu-south-1)
+ Moyen-Orient (Bahreïn) (me-south-1)
+ AWS GovCloud (USA Est) (us-gov-east-1)
+ AWS GovCloud (US-Ouest) (us-gov-west-1)
## Durée et simultanéité des connexions distantes
Les conditions suivantes s'appliquent aux connexions Bureau à distance actives :
+ **Durée de connexion**
Par défaut, une connexion Bureau à distance est déconnectée au bout de 60 minutes. Pour empêcher la déconnexion d'une connexion, vous pouvez choisir **Renouveler la session** avant d'être déconnecté pour réinitialiser la durée.
+ **Délai de connexion**
Une connexion Bureau à distance se déconnecte après plus de 10 minutes d'inactivité.
+ **Persistance de connexion**
Une fois que vous vous connectez à Windows Server avec Bureau à distance, la connexion persiste jusqu’à ce que la durée maximale de connexion (60 minutes) ou le délai d’inactivité (10 minutes) soit atteint. La durée de la connexion n'est pas déterminée par la durée de vos informations d'identification Gestion des identités et des accès AWS (IAM). La connexion persiste après l’expiration des informations d’identification IAM si les limites de durée de connexion ne sont pas respectées. Lorsque vous utilisez Bureau à distance, vous devez mettre fin à votre connexion après l’expiration de vos informations d’identification IAM en quittant la page du navigateur.
+ **Connexions simultanées**
Par défaut, vous pouvez avoir un maximum de 5 connexions Remote Desktop actives à la fois pour le même Compte AWS et Région AWS. Pour demander une augmentation du quota de service allant jusqu'à 50 connexions simultanées, consultez la section [Demander une augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l'utilisateur des quotas de service*.
**Note**
La licence standard Windows Server permet d’établir deux connexions RDP simultanées. Pour prendre en charge un plus grand nombre de connexions, vous devez acheter des licences d'accès client supplémentaires (CALs) auprès de Microsoft ou des licences Microsoft Remote Desktop Services auprès de AWS. Pour de plus amples informations sur la gestion des licences suplémentaires, veuillez consulter les rubriques suivantes :
[Licences d’accès client et licences de gestion](https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license) sur le site Web de Microsoft
[Utiliser les abonnements utilisateur de License Manager pour les produits logiciels pris en charge](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html) dans le *Guide de l’utilisateur License Manager*
## Gestion des AWS IAM Identity Center attributs par Systems Manager GUI Connect
Systems Manager GUI Connect est l’API qui prend en charge les connexions Fleet Manager aux instances EC2 à l’aide du protocole RDP. Les données utilisateur IAM Identity Center suivantes sont conservées après la fermeture d’une connexion :
+ `username`
Systems Manager GUI Connect chiffre cet attribut d'identité au repos à l'aide d'un Clé gérée par AWS par défaut. Les clés gérées par le client ne sont pas prises en charge pour le chiffrement de cet attribut dans Systems Manager GUI Connect. Si vous supprimez un utilisateur dans votre instance IAM Identity Center, Systems Manager GUI Connect conserve l’attribut `username` associé à cet utilisateur pendant 7 ans, après quoi il est supprimé. Ces données sont conservées pour prendre en charge les événements d’audit, comme la liste de l’historique des connexions Systems Manager GUI Connect. Les données ne peuvent pas être supprimées manuellement.
## Connexion à un nœud géré à l'aide du Bureau à distance
**copy/paste Support du navigateur pour le texte**
À l’aide des navigateurs Google Chrome et Microsoft Edge, vous pouvez copier et coller du texte d’un nœud géré vers votre ordinateur local, et de votre ordinateur local vers un nœud géré auquel vous êtes connecté.
Avec le navigateur Mozilla Firefox, vous pouvez copier et coller du texte d’un nœud géré vers votre ordinateur local uniquement. La copie de votre ordinateur local vers le nœud géré n’est pas prise en charge.
**Pour vous connecter à un nœud géré à l'aide de Fleet Manager Bureau à distance**
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. Choisissez le nœud auquel vous souhaitez vous connecter. Vous pouvez sélectionner la case à cocher ou le nom du nœud.
1. Dans le menu **Actions du nœud**, sélectionnez **Se connecter au Bureau à distance**.
1. Sélectionnez votre type d'authentification préféré dans le champ **Authentication type (Type d'authentification)**. Si vous choisissez **Informations d'identification utilisateur**, saisissez le nom d'utilisateur et le mot de passe d'un compte utilisateur Windows sur le nœud auquel vous vous connectez. Si vous choisissez **Paire de clés**, vous pouvez fournir l'authentification à l'aide d'une des méthodes suivantes :
1. Choisissez **Parcourir la machine locale** si vous souhaitez sélectionner la clé PEM associée à votre instance dans votre système de fichiers local.
- ou -
1. Choisissez **Coller le contenu de la paire de clés** si vous souhaitez copier le contenu du fichier PEM et le coller dans le champ prévu à cet effet.
1. Cliquez sur **Connect (Connexion)**.
1. Pour choisir votre résolution d'affichage préférée, dans le menu **Actions**, choisissez **Resolutions** (Résolutions), puis sélectionnez l'une des options suivantes :
+ **Adaptation automatique**
+ **1920 x 1080**
+ **1400 x 900**
+ **1 366 x 768**
+ **800 x 600**
L'option **Adapt Automatically** (Adapter automatiquement) définit la résolution en fonction de la taille d'écran détectée.
## Affichage d’informations sur les connexions en cours et terminées
Vous pouvez utiliser la section Fleet Manager de la console Systems Manager pour afficher des informations sur les connexions RDP qui ont été établies dans votre compte. À l’aide d’un ensemble de filtres, vous pouvez limiter la liste des connexions affichées à une plage de temps, à une instance spécifique, à l’utilisateur qui a établi les connexions et aux connexions d’un statut spécifique. La console propose également des onglets qui affichent des informations sur toutes les connexions actuellement actives et sur toutes les connexions passées.
**Pour afficher des informations sur les connexions en cours et terminées**
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. Choisissez **Gestion des comptes, Connexion avec Remote Desktop**.
1. Choisissez l’un des onglets suivants :
+ **Connexions actives**
+ **Historique des connexions**
1. Pour réduire davantage la liste des résultats de connexion affichés, spécifiez un ou plusieurs filtres dans la zone de recherche (![\[\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)). Vous pouvez également saisir un terme de recherche en texte libre.
# Gestion des volumes Amazon EBS sur les instances gérées
[Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) (Amazon EBS) fournit des volumes de stockage par bloc à utiliser avec les instances Amazon Elastic Compute Cloud (EC2). Les volumes EBS se comportent comme des périphériques de stockage en mode bloc bruts non formatés. Vous pouvez monter ces volumes en tant qu’appareils sur vos instances.
Vous pouvez utiliser Fleet Manager un outil pour gérer les volumes Amazon EBS sur vos instances gérées. AWS Systems Manager Par exemple, vous pouvez initialiser un volume EBS, formater une partition et monter le volume pour le rendre utilisable.
**Note**
Fleet Manager ne prend actuellement en charge la gestion des volumes Amazon EBS que pour les instances Windows Server.
## Affichage des détails d’un volume
**Pour afficher les détails d’un volume EBS avec Fleet 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. Choisissez le bouton situé en regard de l’instance gérée dont vous voulez afficher les détails de volume EBS.
1. Sélectionnez **Afficher les détails**.
1. Choisissez **Outils, Volumes EBS**.
1. Pour afficher les détails d’un volume EBS, choisissez son ID dans la colonne **ID du volume**.
## Initialisation et formatage d’un volume EBS
**Pour initialiser et formater un volume EBS avec Fleet 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. Choisissez le bouton situé en regard de l’instance gérée pour laquelle vous souhaitez initialiser, formater et monter un volume EBS. Vous ne pouvez initialiser un volume EBS que si son disque est vide.
1. Sélectionnez **Afficher les détails**.
1. Dans le menu **Outils**, sélectionnez **Volumes EBS**.
1. Choisissez le bouton en regard du volume EBS que vous voulez initialiser et formater.
1. Choisissez **Initialiser et formater**.
1. Dans **Style de partition**, choisissez le style de partition que vous souhaitez utiliser pour le volume EBS.
1. (Facultatif) Choisissez une **lettre de lecteur** pour la partition.
1. (Facultatif) Saisissez un **Nom de partition** pour identifier la partition.
1. Choisissez le **Système de fichiers** à utiliser pour organiser les fichiers et les données stockés dans la partition.
1. Cliquez sur **Confirmer** pour rendre le volume EBS disponible à l’utilisation. Vous ne pouvez pas modifier la configuration de la partition AWS Management Console après confirmation, mais vous pouvez utiliser SSH ou RDP pour vous connecter à l'instance afin de modifier la configuration de la partition.
# Accès au portail de la base de connaissances Red Hat
Vous pouvez utiliser Fleet Manager un outil pour accéder au portail de la base de connaissances si vous êtes un client Red Hat. AWS Systems Manager Vous êtes considéré comme un client Red Hat si vous exécutez des instances Red Hat Enterprise Linux (RHEL) ou utilisez des services RHEL sur AWS. Le portail de la base de connaissances comprend des binaires, ainsi que des forums de partage de connaissances et de discussion destinés à assister la communauté, qui ne sont accessibles qu’aux clients sous licence Red Hat.
Outre les autorisations Gestion des identités et des accès AWS (IAM) requises pour Systems ManagerFleet Manager, l'utilisateur ou le rôle que vous utilisez pour accéder à la console doit autoriser l'`rhelkb:GetRhelURL`action à accéder au portail de la base de connaissances.
**Pour accéder au portail de la base de connaissances Red Hat**
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. Sélectionnez l'instance RHEL que vous souhaitez utiliser pour vous connecter au portail de la base de connaissances Red Hat.
1. Choisissez **Gestion de compte**, **Accéder à la base de connaissances Red Hat** pour ouvrir la page de la base de connaissances Red Hat.
Si vous utilisez RHEL on AWS pour exécuter des RHEL charges de travail entièrement prises en charge, vous pouvez également accéder à la base de connaissances Red Hat via le site Web de Red Hat en utilisant vos AWS informations d'identification.
# Résolution des problèmes de disponibilité des nœuds gérés
Pour plusieurs AWS Systems Manager outils tels que Run CommandDistributor,, etSession Manager, vous pouvez choisir de sélectionner manuellement les nœuds gérés sur lesquels vous souhaitez exécuter une opération. Après avoir spécifié que vous souhaitez choisir les nœuds manuellement, le système affiche alors une liste de nœuds gérés sur lesquels vous pouvez exécuter l'opération.
Cette rubrique fournit des informations qui vous aideront à déterminer pourquoi un nœud géré *confirmé comme en cours d'exécution* ne figure pas dans vos listes de nœuds gérés dans Systems Manager.
Pour qu'un nœud soit géré par Systems Manager et figure dans les listes de nœuds gérés, il doit remplir trois conditions :
+ SSM Agent doit être installé et exécuté sur le nœud avec un système d'exploitation pris en charge.
**Note**
Certains AWS managed Amazon Machine Images (AMIs) sont configurés pour lancer des instances [SSM Agent](ssm-agent.md)préinstallées. (Vous pouvez également configurer une AMI personnalisée pour préinstaller SSM Agent.) Pour de plus amples informations, veuillez consulter [Trouver les AMIs avec SSM Agent préinstallé](ami-preinstalled-agent.md).
+ Pour les instances Amazon Elastic Compute Cloud (Amazon EC2), vous devez associer Gestion des identités et des accès AWS un profil d'instance (IAM) à l'instance. Ce profil d'instance permet à celles-ci de communiquer avec le service Systems Manager. Si vous n'attribuez pas de profil d'instance à l'instance, vous devez l'enregistrer à l'aide d'une [activation hybride](activations.md), ce qui ne constitue pas le scénario le plus fréquent.
+ SSM Agent doit pouvoir se connecter à un point de terminaison Systems Manager afin de s'enregistrer auprès du service. Le nœud géré est ensuite disponible pour le service, comme le confirme le signal que celui-ci envoie toutes les cinq minutes afin de vérifier l'état de l'instance.
+ Une fois que le statut d'un nœud géré a été `Connection Lost` pendant au moins 30 jours, il est possible que le nœud ne soit plus répertorié dans la console Fleet Manager. Pour le rétablir dans la liste, le problème à l'origine de la perte de connexion doit être résolu.
Après avoir vérifié qu'un nœud géré est bien en cours d'exécution, vous pouvez utiliser la commande suivante pour vous assurer que SSM Agent s'est enregistré avec succès auprès du service Systems Manager. Cette commande ne renvoie pas de résultats tant que l'enregistrement n'a pas réussi.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-associations-status \
--instance-id instance-id
```
------
#### [ Windows ]
```
aws ssm describe-instance-associations-status ^
--instance-id instance-id
```
------
#### [ PowerShell ]
```
Get-SSMInstanceAssociationsStatus `
-InstanceId instance-id
```
------
Si l'enregistrement a abouti et que le nœud géré est disponible pour les opérations de Systems Manager, la commande renvoie des résultats semblables aux suivants.
```
{
"InstanceAssociationStatusInfos": [
{
"AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
"Name": "AWS-GatherSoftwareInventory",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Pending",
"DetailedStatus": "Associated"
},
{
"AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
"Name": "AWS-RunPatchBaseline",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Queued",
"AssociationName": "SystemAssociationForScanningPatches"
}
]
}
```
Si l'enregistrement n'est pas terminé ou a échoué, la commande renvoie des résultats semblables aux suivants :
```
{
"InstanceAssociationStatusInfos": []
}
```
Si la commande ne renvoie aucun résultat au bout de 5 minutes environ, utilisez les informations suivantes pour résoudre les problèmes liés à vos nœuds gérés.
**Topics**
+ [Solution 1 : vérifier que SSM Agent est installé et en cours d'exécution sur le nœud géré](#instances-missing-solution-1)
+ [Solution 2 : vérifier qu'un profil d'instance IAM a été spécifié pour l'instance (instances EC2 uniquement)](#instances-missing-solution-2)
+ [Solution 3 : vérifier la connectivité des points de terminaison de service](#instances-missing-solution-3)
+ [Solution 4 : vérifier la prise en charge du système d'exploitation cible](#instances-missing-solution-4)
+ [Solution 5 : vérifier que vous travaillez de la même manière Région AWS que l'instance Amazon EC2](#instances-missing-solution-5)
+ [Solution 6 : vérifier la configuration de proxy que vous avez appliquée à l'SSM Agent sur votre nœud géré](#instances-missing-solution-6)
+ [Solution 7 : installer un certificat TLS sur les instances gérées](#hybrid-tls-certificate)
+ [Résolution des problèmes de disponibilité des nœuds gérés en utilisant `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md)
## Solution 1 : vérifier que SSM Agent est installé et en cours d'exécution sur le nœud géré
Vérifiez que la dernière version de SSM Agent est installée et exécutée sur le nœud géré.
Pour déterminer si SSM Agent est installé et en cours d'exécution sur un nœud géré, consultez [Vérification du statut de l'SSM Agent et démarrage de l'agent](ssm-agent-status-and-restart.md).
Pour installer ou réinstaller SSM Agent sur un nœud géré, consultez les rubriques suivantes :
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Linux](manually-install-ssm-agent-linux.md)
+ [Comment installer le SSM Agent sur des nœuds Linux hybrides](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Windows Server](manually-install-ssm-agent-windows.md)
+ [Comment installer le SSM Agent sur des nœuds Windows hybrides](hybrid-multicloud-ssm-agent-install-windows.md)
## Solution 2 : vérifier qu'un profil d'instance IAM a été spécifié pour l'instance (instances EC2 uniquement)
Vérifiez que l'instance Amazon Elastic Compute Cloud (Amazon EC2) est configurée avec un profil d'instance Gestion des identités et des accès AWS (IAM) qui lui permet de communiquer avec l'API Systems Manager. Vérifiez également que votre utilisateur est associé à une politique d'approbation IAM qui permet à votre utilisateur afin de communiquer avec l'API Systems Manager.
**Note**
Les serveurs locaux, les périphériques périphériques et les machines virtuelles (VMs) utilisent un rôle de service IAM au lieu d'un profil d'instance. Pour plus d’informations, consultez la section [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md).
**Pour déterminer si un profil d'instance disposant des autorisations nécessaires est attaché à une instance EC2**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, choisissez **Instances**.
1. Sélectionnez l'instance pour laquelle rechercher un profil d'instance.
1. Sous l'onglet **Description** du panneau inférieur, recherchez **Rôle IAM** et sélectionnez le nom du rôle.
1. Sur la page **Résumé** du rôle pour le profil d'instance, sous l'onglet **Autorisations**, vérifiez que `AmazonSSMManagedInstanceCore` est bien répertorié sous **Politiques d'autorisations**.
Si vous utilisez plutôt une politique personnalisée, vérifiez qu'elle fournit les mêmes autorisations que `AmazonSSMManagedInstanceCore`.
[Ouvrir `AmazonSSMManagedInstanceCore` dans la console](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)
Pour obtenir des informations sur les autres politiques qui peuvent être attachées à un profil d’instance pour Systems Manager, consultez [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
## Solution 3 : vérifier la connectivité des points de terminaison de service
Vérifiez que l'instance est connectée aux points de terminaison de service Systems Manager. Cette connectivité est fournie en créant et en configurant des points de terminaison de VPC pour Systems Manager, ou en autorisant le trafic sortant HTTPS (port 443) vers les points de terminaison de service.
Pour les instances Amazon EC2, le point de terminaison du service Systems Manager Région AWS est utilisé pour enregistrer l'instance si votre configuration de cloud privé virtuel (VPC) autorise le trafic sortant. Toutefois, si la configuration VPC avec laquelle l'instance a été lancée n'autorise pas le trafic sortant et que vous ne pouvez pas modifier cette configuration pour permettre la connexion aux points de terminaison de service publics, vous devez configurer des points de terminaison d'interface pour votre VPC.
Pour plus d’informations, consultez [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md).
## Solution 4 : vérifier la prise en charge du système d'exploitation cible
Vérifiez que l'opération que vous avez choisie peut être exécutée sur le type de nœud géré que vous souhaitez voir figurer dans la liste. Certaines opérations Systems Manager peuvent cibler uniquement des instances Windows ou uniquement des instances Linux. Par exemple, les documents Systems Manager (SSM) `AWS-InstallPowerShellModule` et `AWS-ConfigureCloudWatch`ne peuvent être exécutés que sur des instances Windows. Sur la page **Exécuter une commande**, si vous sélectionnez l'un de ces documents et que vous sélectionnez **Choisir des instances manuellement**, seules vos instances Windows sont répertoriées et disponibles à la sélection.
## Solution 5 : vérifier que vous travaillez de la même manière Région AWS que l'instance Amazon EC2
Les instances Amazon EC2 sont créées et disponibles dans des régions spécifiques Régions AWS, telles que la région USA Est (Ohio) (us-east-2) ou Europe (Irlande) (eu-west-1). Assurez-vous que vous travaillez de la même manière Région AWS que l'instance Amazon EC2 avec laquelle vous souhaitez travailler. Pour de plus amples informations, consultez [Choisir une région](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region) dans *Mise en route avec la AWS Management Console*.
## Solution 6 : vérifier la configuration de proxy que vous avez appliquée à l'SSM Agent sur votre nœud géré
Vérifiez que la configuration de proxy que vous avez appliquée à l'SSM Agent sur votre nœud géré est correcte. Si la configuration de proxy est incorrecte, le nœud ne peut pas se connecter aux points de terminaison de service requis, ou Systems Manager risque de mal identifier le système d'exploitation du nœud géré. Pour plus d’informations, consultez [Configuration de SSM Agent pour l’utilisation d’un proxy sur les nœuds Linux](configure-proxy-ssm-agent.md) et [Configurer l'SSM Agent pour utiliser un proxy pour les instances Windows Server](configure-proxy-ssm-agent-windows.md).
## Solution 7 : installer un certificat TLS sur les instances gérées
Un certificat TLS (Transport Layer Security) doit être installé sur chaque instance gérée que vous utilisez. AWS Systems Manager Services AWS utilisez ces certificats pour chiffrer les appels vers d'autres Services AWS personnes.
Un certificat TLS est déjà installé par défaut sur chaque instance Amazon EC2 créée à partir d'une Amazon Machine Image (AMI). La plupart des systèmes d'exploitation modernes incluent le certificat TLS requis d'Amazon Trust Services CAs dans leur magasin de confiance.
Pour déterminer si le certificat requis est installé sur votre instance, exécutez la commande suivante en fonction du système d'exploitation de celle-ci. Assurez-vous de remplacer la *region* partie de l'URL par celle Région AWS où se trouve votre instance gérée.
------
#### [ Linux & macOS ]
```
curl -L https://ssm.region.amazonaws.com
```
------
#### [ Windows ]
```
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com
```
------
La commande doit renvoyer une erreur `UnknownOperationException`. Si vous recevez plutôt un message SSL/TLS d'erreur, il est possible que le certificat requis ne soit pas installé.
Si vous constatez que les certificats Amazon Trust Services CA requis ne sont pas installés sur vos systèmes d'exploitation de base, sur les instances créées à partir de celles AMIs qui ne sont pas fournies par Amazon, ou sur vos propres serveurs locaux VMs, vous devez installer et autoriser un certificat d'[Amazon Trust Services](https://www.amazontrust.com/repository/), ou utiliser AWS Certificate Manager (ACM) pour créer et gérer des certificats pour un service intégré pris en charge.
Chacune de vos instances gérées doit avoir l'un des certificats TLS (Transport Layer Security) suivants installé.
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority – G2
+ Starfield Class 2 Certificate Authority
Pour plus d'informations sur ACM, consultez le *[Guide de l'utilisateur AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*.
Si les certificats figurant dans votre environnement informatique sont gérés par un objet de politique de groupe (GPO), vous pouvez avoir besoin de configurer une politique de groupe pour inclure l'un de ces certificats.
Pour plus d'informations sur les certificats Amazon Root et Starfield, consultez le billet de blog [How to Prepare for AWS's Move to Its Own Certificate Authority](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/).
# Résolution des problèmes de disponibilité des nœuds gérés en utilisant `ssm-cli`
`ssm-cli` est un outil de ligne de commande autonome inclus dans l'installation SSM Agent. Lorsque vous installez SSM Agent 3.1.501.0 (ou une version ultérieure) sur une machine, vous pouvez exécuter des commandes `ssm-cli` sur cette machine. La sortie de ces commandes vous aide à déterminer si la machine répond aux exigences minimales requises pour être gérée par une instance Amazon EC2 ou une machine autre qu'EC2 AWS Systems Manager, et si elle est donc ajoutée aux listes de nœuds gérés dans Systems Manager. (SSM Agentla version 3.1.501.0 a été publiée en novembre 2021.)
**Configuration requise**
Pour qu'une instance Amazon EC2 ou une machine non EC2 soit gérée par AWS Systems Manager et disponible dans des listes de nœuds gérés, elle doit répondre à trois exigences principales :
+ SSM Agent doit être installé et exécuté sur une machine dotée d'un [système d'exploitation compatible](operating-systems-and-machine-types.md#prereqs-operating-systems).
Certains AWS managed Amazon Machine Images (AMIs) pour EC2 sont configurés pour lancer des instances [SSM Agent](ssm-agent.md)préinstallées. (Vous pouvez également configurer une AMI personnalisée pour préinstaller SSM Agent.) Pour de plus amples informations, veuillez consulter [Trouver les AMIs avec SSM Agent préinstallé](ami-preinstalled-agent.md).
+ Un profil d'instance Gestion des identités et des accès AWS (IAM) (pour les instances EC2) ou un rôle de service IAM (pour les machines non EC2) fournissant les autorisations requises pour communiquer avec le service Systems Manager doit être attaché à la machine.
+ SSM Agent doit pouvoir se connecter à un point de terminaison Systems Manager afin de s'enregistrer auprès du service. Le nœud géré est ensuite disponible pour le service, comme le confirme le signal que celui-ci envoie toutes les cinq minutes afin de vérifier l'état du nœud géré.
**Commandes préconfigurées dans `ssm-cli`**
Il contient des commandes préconfigurées qui rassemblent les informations requises afin de déterminer pourquoi une machine, confirmée comme en cours d'exécution, ne figure pas dans vos listes de nœuds gérées dans Systems Manager. Ces commandes sont exécutées lorsque vous spécifiez l'option `get-diagnostics`.
Sur la machine, exécutez la commande suivante afin d'utiliser `ssm-cli` pour résoudre les problèmes de disponibilité des nœuds gérés.
------
#### [ Linux & macOS ]
```
ssm-cli get-diagnostics --output table
```
------
#### [ Windows ]
Sur des machines Windows Server, vous devez accéder au répertoire `C:\Program Files\Amazon\SSM` avant d'exécuter la commande.
```
ssm-cli.exe get-diagnostics --output table
```
------
#### [ PowerShell ]
Sur des machines Windows Server, vous devez accéder au répertoire `C:\Program Files\Amazon\SSM` avant d'exécuter la commande.
```
.\ssm-cli.exe get-diagnostics --output table
```
------
La sortie générée lors de l'exécution de cette commande renvoie un tableau similaire à celui qui suit.
**Note**
Les contrôles de connectivité vers les `monitoring` points de terminaison `ssmmessages` `s3` `kms``logs`,,, et concernent des fonctionnalités facultatives supplémentaires, telles Session Manager que la possibilité de se connecter à Amazon Simple Storage Service (Amazon S3) ou CloudWatch Amazon Logs, AWS Key Management Service et d'AWS KMS utiliser le chiffrement ().
------
#### [ Linux & macOS ]
```
[root@instance]# ssm-cli get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789abcdefa in Region │
│ │ │ us-east-2 │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/Fullaccess/i-0123456789abcdefa │
│ │ │ and will expire at 2021-08-17 18:47:49 +0000 UTC │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.0.1209.0, latest available agent version is │
│ │ │ 3.1.192.0 │
└───────────────────────────────────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
```
------
#### [ Windows Server and PowerShell ]
```
PS C:\Program Files\Amazon\SSM> .\ssm-cli.exe get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬─────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789EXAMPLE in │
│ │ │ Region us-east-2 │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/SSM-Role/i-123abc45EXAMPLE │
│ │ │ and will expire at 2021-09-02 13:24:42 +0000 UTC │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Windows sysprep image state │ Success │ Windows image state value is at desired value IMAGE_STATE_COMPLETE │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.2.815.0, latest agent version in us-east-2 │
│ │ │ is 3.2.985.0 │
└───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────┘
```
------
Le tableau suivant fournit des détails supplémentaires pour chacune des vérifications effectuées par `ssm-cli`.
**Vérifications de diagnostic `ssm-cli`**
| Check | Détails |
| --- | --- |
| Service de métadonnées d'instance Amazon EC2 | Indique si le nœud géré est en mesure d'accéder au service de métadonnées. Un test qui échoue indique un problème de connectivité à http://169.254.169.254 qui peut être dû à la configuration de l'acheminement local, du proxy, ou du pare-feu et du proxy du système d'exploitation (OS). |
| Enregistrement d'une instance hybride | Indique si SSM Agent est enregistré à l'aide d'une activation hybride. |
| Connectivité au point de terminaison ssm | Indique si le nœud a accès aux points de terminaison de service de Systems Manager sur le port TCP 443. Un test raté indique des problèmes de connectivité https://ssm.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. Les problèmes de connectivité peuvent être dus à la configuration du VPC, et notamment aux groupes de sécurité, aux listes de contrôle d'accès réseau, aux tables de routage ou aux pare-feu et proxies du système d'exploitation. |
| Connectivité au point de terminaison ec2messages | Indique si le nœud a accès aux points de terminaison de service de Systems Manager sur le port TCP 443. Un test raté indique des problèmes de connectivité https://ec2messages.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. Les problèmes de connectivité peuvent être dus à la configuration du VPC, et notamment aux groupes de sécurité, aux listes de contrôle d'accès réseau, aux tables de routage ou aux pare-feu et proxies du système d'exploitation. |
| Connectivité au point de terminaison ssmmessages | Indique si le nœud a accès aux points de terminaison de service de Systems Manager sur le port TCP 443. Un test raté indique des problèmes de connectivité https://ssmmessages.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. Les problèmes de connectivité peuvent être dus à la configuration du VPC, et notamment aux groupes de sécurité, aux listes de contrôle d'accès réseau, aux tables de routage ou aux pare-feu et proxies du système d'exploitation. |
| Connectivité au point de terminaison s3 | Indique si le nœud est en mesure d’atteindre le point de terminaison d'Amazon Simple Storage Service sur le port TCP 443. Un test raté indique des problèmes de connectivité https://s3.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. La connectivité à ce point de terminaison n'est pas nécessaire pour qu'un nœud apparaisse dans votre liste de nœuds gérés. |
| Connectivité au point de terminaison kms | Indique si le nœud est capable d'atteindre le point de terminaison du service AWS Key Management Service sur le port TCP 443. Un test raté indique des problèmes de connectivité `https://kms.region.amazonaws.com` en fonction de l' Région AWS emplacement du nœud. La connectivité à ce point de terminaison n'est pas nécessaire pour qu'un nœud apparaisse dans votre liste de nœuds gérés. |
| Connectivité au point de terminaison logs | Indique si le nœud est capable d'atteindre le point de terminaison du service pour Amazon CloudWatch Logs sur le port TCP 443. Un test raté indique des problèmes de connectivité https://logs.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. La connectivité à ce point de terminaison n'est pas nécessaire pour qu'un nœud apparaisse dans votre liste de nœuds gérés. |
| Connectivité au point de terminaison monitoring | Indique si le nœud est capable d'atteindre le point de terminaison du service pour Amazon CloudWatch sur le port TCP 443. Un test raté indique des problèmes de connectivité https://monitoring.region.amazonaws.com en fonction de l' Région AWS emplacement du nœud. La connectivité à ce point de terminaison n'est pas nécessaire pour qu'un nœud apparaisse dans votre liste de nœuds gérés. |
| AWS Informations d'identification | Indique si l'SSM Agent dispose des informations d'identification requises en fonction du profil d'instance IAM (pour les instances EC2) ou de la fonction du service IAM (pour les machines non EC2) attaché à la machine. Un test qui échoue indique qu'aucun profil d'instance IAM ou fonction du service IAM n'est attaché à la machine, ou qu'il ne contient pas les autorisations requises pour Systems Manager. |
| Service d'agent | Indique si le service SSM Agent est en cours d'exécution, et s'il est exécuté en tant que racine pour Linux ou macOS, ou SYSTEM pour Windows Server. Un test qui échoue indique que le service SSM Agent n'est pas en cours d'exécution ou qu'il n'est pas exécuté en tant que root ou SYSTEM. |
| Configuration du proxy | Indique si SSM Agent est configuré pour utiliser un proxy. |
| État de l'image Sysprep (Windows uniquement) | Indique l'état de Sysprep sur le nœud. SSM Agent ne démarrera pas sur le nœud si l'état de Sysprep est une valeur autre que IMAGE\$1STATE\$1COMPLETE. |
| Version de l’SSM Agent | Indique si la dernière version disponible de l'SSM Agent est installée. |
# AWS Systems Manager Activations hybrides
Pour configurer des appareils autres que EC2 des machines à utiliser AWS Systems Manager dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types), vous devez créer une *activation hybride*. Les types autres que des EC2 machines pris en charge en tant que nœuds gérés sont les suivants :
+ Serveurs sur votre propre site (serveurs sur site)
+ AWS IoT Greengrass appareils principaux
+ AWS IoT et appareils non AWS périphériques
+ Machines virtuelles (VMs), y compris VMs dans d'autres environnements cloud
Lorsque vous exécutez la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html) pour lancer un processus d'activation hybride, vous recevez un code d'activation et un ID dans la réponse de la commande. Vous incluez ensuite le code d’activation et l’ID dans la commande d’installation de SSM Agent sur l’appareil, comme décrit à l’étape 3 de [Installer SSM Agent sur les nœuds Linux hybrides](hybrid-multicloud-ssm-agent-install-linux.md) et à l’étape 4 de [Installer SSM Agent sur les nœuds hybrides Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).
Ce processus d'activation s'applique à tous les types autres que des EC2 machines, à *l'exception* des appareils AWS IoT Greengrass principaux. Pour plus d'informations sur la configuration des appareils Core AWS IoT Greengrass pour Systems Manager, consultez [Gestion des appareils de périphérie avec Systems Manager](systems-manager-setting-up-edge-devices.md).
**Note**
Support n'est actuellement pas fourni pour les appareils autres que EC2 macOS les machines.
**À propos des niveaux d'instances Systems Manager**
AWS Systems Manager propose un niveau d'instances standard et un niveau d'instances avancées. Les deux prennent en charge les nœuds gérés dans votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Le niveau d'instances standard vous permet d'enregistrer un maximum de 1 000 machines par machine. Compte AWS Région AWS Si vous avez besoin d'enregistrer plus de 1 000 machines dans un seul compte et une seule région, utilisez le niveau d'instances avancées. Le niveau d'instances avancées vous permet de créer autant de nœuds gérés que vous le souhaitez. Tous les nœuds gérés configurés pour Systems Manager sont facturés sur une pay-per-use base. Pour plus d'informations sur l'activation des instances avancées, consultez [Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md). Pour plus d'informations sur la tarification, consultez [Tarification AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Notez les informations supplémentaires suivantes concernant les niveaux d’instances standard et d’instances avancées :
+ Les instances avancées vous permettent également de vous connecter à vos EC2 non-nœuds dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) en utilisant AWS Systems Manager Session Manager. Session Managerfournit un accès shell interactif à vos instances. Pour de plus amples informations, veuillez consulter [AWS Systems Manager Session Manager](session-manager.md).
+ Le quota d'instances standard s'applique également aux EC2 instances qui utilisent une activation sur site de Systems Manager (ce qui n'est pas un scénario courant).
+ Pour appliquer des correctifs aux applications publiées par Microsoft sur des machines virtuelles (VMs) et des instances locales, activez le niveau d'instances avancées. L'utilisation du niveau d'instance avancé est facturée. Les applications de correctif publiées par Microsoft sur les instances Amazon Elastic Compute Cloud (Amazon EC2) sont gratuites. Pour de plus amples informations, veuillez consulter [Correction d’applications publiées par Microsoft sur Windows Server](patch-manager-patching-windows-applications.md).
# AWS Systems Manager Inventory
AWS Systems Manager L'inventaire fournit une visibilité sur votre environnement AWS informatique. Vous pouvez utiliser l'inventaire pour collecter les *métadonnées* à partir de vos nœuds gérés. Vous pouvez stocker ces métadonnées dans un compartiment Amazon Simple Storage Service (Amazon S3) central, puis utiliser les outils intégrés pour interroger les données et déterminer rapidement quels nœuds exécutent les logiciels et les configurations requis par votre politique logicielle, et quels nœuds doivent être mis à jour. Vous pouvez configurer l'inventaire sur l'ensemble de vos nœuds gérés à l'aide d'une procédure en un clic. Vous pouvez également configurer et consulter les données d'inventaire à partir de plusieurs sources Régions AWS et à Comptes AWS l'aide d'Amazon Athena. Pour vos premiers pas dans l'inventaire, ouvrez la [console Systems Manager](https://console.aws.amazon.com//systems-manager/inventory). Dans le volet de navigation, sélectionnez **Inventory**.
Si les types de métadonnées préconfigurés collectés par Systems Manager Inventory ne répondent pas à vos besoins, vous pouvez créer un inventaire personnalisé. L'inventaire personnalisé est simplement un fichier JSON contenant des informations que vous fournissez et ajoutez au nœud géré dans un répertoire spécifique. Lorsque Systems Manager Inventory collecte les données, il capture les données de cet inventaire personnalisé. Par exemple, si vous exécutez un centre de données volumineux, vous pouvez spécifier l'emplacement des racks de chacun de vos serveurs en tant qu'inventaire personnalisé. Vous pouvez ensuite consulter les données de l'espace rack lorsque vous consultez les autres données d'inventaire.
**Important**
Systems Manager Inventory collecte *uniquement* les métadonnées de vos nœuds gérés. L'inventaire n'accède pas aux données ou aux informations propriétaires.
Le tableau suivant décrit les types de données que vous pouvez collecter avec Systems Manager Inventory. Le tableau décrit également les différentes offres de ciblage des nœuds et les intervalles de collecte que vous pouvez spécifier.
****
| Configuration | Détails |
| --- | --- |
| Types de métadonnées | Vous pouvez configurer l'inventaire pour collecter les types de données suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/systems-manager-inventory.html) Pour afficher la liste de toutes les métadonnées collectées par l'inventaire, consultez [Métadonnées collectées par inventaire](inventory-schema.md). |
| Nœuds à cibler | Vous pouvez choisir d'inventorier tous les nœuds gérés de vos nœuds Compte AWS, de les sélectionner individuellement ou de cibler des groupes de nœuds à l'aide de balises. Pour plus d'informations sur la collecte de données d'inventaire sur l'ensemble de vos nœuds gérés, consultez [Répertoriez tous les nœuds gérés de votre Compte AWS](inventory-collection.md#inventory-management-inventory-all). |
| Quand collecter les informations | Vous pouvez spécifier un intervalle de collecte en minutes, heures, jours et semaines. L'intervalle de collecte le plus court est toutes les 30 minutes. |
**Note**
En fonction de la quantité de données recueillies, le système peut prendre plusieurs minutes pour présenter les données à la sortie que vous avez spécifiée. Une fois les informations collectées, les données sont envoyées via un canal HTTPS sécurisé vers un AWS magasin en texte brut accessible uniquement depuis votre. Compte AWS
Vous pouvez afficher les données dans la console Systems Manager sur la page **Inventory** (Inventaire), qui comprend plusieurs cartes prédéfinies pour vous aider à interroger les données.
![\[Cartes Systems Manager Inventory dans la console Systems Manager.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-cards.png)
**Note**
Les fiches d'inventaire filtrent automatiquement les instances EC2 gérées par Amazon avec l'état *Terminé* et *Arrêté*. Pour les nœuds sur site et gérés par les appareils AWS IoT Greengrass principaux, les cartes d'inventaire filtrent automatiquement les nœuds dont l'état est *Terminé*.
Si vous créez une synchronisation de données de ressources pour synchroniser et stocker toutes vos données dans un seul compartiment Amazon S3, vous pouvez explorer en détail les données sur la page **Inventory Detailed View (Vue détaillée d'inventaire)**. Pour de plus amples informations, veuillez consulter [Interrogation des données d'inventaire à partir de plusieurs régions et comptes](systems-manager-inventory-query.md).
**EventBridge soutien**
Cet outil Systems Manager est pris en charge en tant que type d'*événement* dans les EventBridge règles d'Amazon. Pour plus d’informations, consultez [Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md) et [Référence : modèles et types d' EventBridge événements Amazon pour Systems Manager](reference-eventbridge-events.md).
**Topics**
+ [En savoir plus sur Systems Manager Inventory](inventory-about.md)
+ [Configuration de Systems Manager Inventory](systems-manager-inventory-setting-up.md)
+ [Configuration de la collecte d'inventaire](inventory-collection.md)
+ [Interrogation des données d'inventaire à partir de plusieurs régions et comptes](systems-manager-inventory-query.md)
+ [Interrogation d'une collecte d'inventaire à l'aide de filtres](inventory-query-filters.md)
+ [Agrégation des données d'inventaire](inventory-aggregate.md)
+ [Utilisation de l'inventaire personnalisé](inventory-custom.md)
+ [Affichage de l'historique d'inventaire et suivi des modifications](inventory-history.md)
+ [Arrêt de la collecte des données et suppression des données d'inventaire](systems-manager-inventory-delete.md)
+ [Attribution de métadonnées d’inventaire personnalisées à un nœud géré](inventory-custom-metadata.md)
+ [Utilisation du AWS CLI pour configurer la collecte des données d'inventaire](inventory-collection-cli.md)
+ [Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire](inventory-resource-data-sync.md)
+ [Résolution des problèmes liés à Systems Manager Inventory](syman-inventory-troubleshooting.md)
# En savoir plus sur Systems Manager Inventory
Lorsque vous configurez l'inventaire AWS Systems Manager, vous spécifiez le type de métadonnées à collecter, les nœuds à partir desquels les métadonnées doivent être collectées et un calendrier de collecte des métadonnées. Ces configurations sont enregistrées avec votre Compte AWS sous forme d'association AWS Systems Manager State Manager. Une association est simplement une configuration.
**Note**
L'inventaire collecte uniquement les métadonnées. Il ne recueille aucune donnée personnelle ou propriétaire.
**Topics**
+ [Métadonnées collectées par inventaire](inventory-schema.md)
+ [Utilisation de l'inventaire de fichiers et du registre Windows](inventory-file-and-registry.md)
# Métadonnées collectées par inventaire
L'exemple suivant affiche la liste complète des métadonnées collectées par chaque plugin Inventory AWS Systems Manager.
```
{
"typeName": "AWS:InstanceInformation",
"version": "1.0",
"attributes":[
{ "name": "AgentType", "dataType" : "STRING"},
{ "name": "AgentVersion", "dataType" : "STRING"},
{ "name": "ComputerName", "dataType" : "STRING"},
{ "name": "InstanceId", "dataType" : "STRING"},
{ "name": "IpAddress", "dataType" : "STRING"},
{ "name": "PlatformName", "dataType" : "STRING"},
{ "name": "PlatformType", "dataType" : "STRING"},
{ "name": "PlatformVersion", "dataType" : "STRING"},
{ "name": "ResourceType", "dataType" : "STRING"},
{ "name": "AgentStatus", "dataType" : "STRING"},
{ "name": "InstanceStatus", "dataType" : "STRING"}
]
},
{
"typeName" : "AWS:Application",
"version": "1.1",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "Release", "dataType": "STRING"},
{ "name": "Epoch", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"},
{ "name": "Summary", "dataType": "STRING"},
{ "name": "PackageId", "dataType": "STRING"}
]
},
{
"typeName" : "AWS:File",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Size", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "FileVersion", "dataType": "STRING"},
{ "name": "InstalledDate", "dataType": "STRING"},
{ "name": "ModificationTime", "dataType": "STRING"},
{ "name": "LastAccessTime", "dataType": "STRING"},
{ "name": "ProductName", "dataType": "STRING"},
{ "name": "InstalledDir", "dataType": "STRING"},
{ "name": "ProductLanguage", "dataType": "STRING"},
{ "name": "CompanyName", "dataType": "STRING"},
{ "name": "ProductVersion", "dataType": "STRING"}
]
},
{
"typeName": "AWS:AWSComponent",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsUpdate",
"version":"1.0",
"attributes":[
{ "name": "HotFixId", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstalledBy", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Network",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "SubnetMask", "dataType": "STRING"},
{ "name": "Gateway", "dataType": "STRING"},
{ "name": "DHCPServer", "dataType": "STRING"},
{ "name": "DNSServer", "dataType": "STRING"},
{ "name": "MacAddress", "dataType": "STRING"},
{ "name": "IPV4", "dataType": "STRING"},
{ "name": "IPV6", "dataType": "STRING"}
]
},
{
"typeName": "AWS:PatchSummary",
"version":"1.0",
"attributes":[
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "BaselineId", "dataType": "STRING"},
{ "name": "SnapshotId", "dataType": "STRING"},
{ "name": "OwnerInformation", "dataType": "STRING"},
{ "name": "InstalledCount", "dataType": "NUMBER"},
{ "name": "InstalledPendingRebootCount", "dataType": "NUMBER"},
{ "name": "InstalledOtherCount", "dataType": "NUMBER"},
{ "name": "InstalledRejectedCount", "dataType": "NUMBER"},
{ "name": "NotApplicableCount", "dataType": "NUMBER"},
{ "name": "UnreportedNotApplicableCount", "dataType": "NUMBER"},
{ "name": "MissingCount", "dataType": "NUMBER"},
{ "name": "FailedCount", "dataType": "NUMBER"},
{ "name": "OperationType", "dataType": "STRING"},
{ "name": "OperationStartTime", "dataType": "STRING"},
{ "name": "OperationEndTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING"},
{ "name": "RebootOption", "dataType": "STRING"},
{ "name": "LastNoRebootInstallOperationTime", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING", "isOptional": "true"},
{ "name": "NonCompliantSeverity", "dataType": "STRING", "isOptional": "true"},
{ "name": "SecurityNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "CriticalNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "OtherNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"}
]
},
{
"typeName": "AWS:PatchCompliance",
"version":"1.0",
"attributes":[
{ "name": "Title", "dataType": "STRING"},
{ "name": "KBId", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "State", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ComplianceItem",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionId", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionTime", "dataType": "STRING", "isContext": "true"},
{ "name": "Id", "dataType": "STRING"},
{ "name": "Title", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "DocumentName", "dataType": "STRING"},
{ "name": "DocumentVersion", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "PatchSeverity", "dataType": "STRING"},
{ "name": "PatchState", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedText", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedLink", "dataType": "STRING", "isOptional": "true"},
{ "name": "CVEIds", "dataType": "STRING", "isOptional": "true"}
]
},
{
"typeName": "AWS:ComplianceSummary",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "OverallSeverity", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING"},
{ "name": "ExecutionType", "dataType": "STRING"},
{ "name": "ExecutionTime", "dataType": "STRING"},
{ "name": "CompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "CompliantHighCount", "dataType": "NUMBER"},
{ "name": "CompliantMediumCount", "dataType": "NUMBER"},
{ "name": "CompliantLowCount", "dataType": "NUMBER"},
{ "name": "CompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "CompliantUnspecifiedCount", "dataType": "NUMBER"},
{ "name": "NonCompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantHighCount", "dataType": "NUMBER"},
{ "name": "NonCompliantMediumCount", "dataType": "NUMBER"},
{ "name": "NonCompliantLowCount", "dataType": "NUMBER"},
{ "name": "NonCompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantUnspecifiedCount", "dataType": "NUMBER"}
]
},
{
"typeName": "AWS:InstanceDetailedInformation",
"version":"1.0",
"attributes":[
{ "name": "CPUModel", "dataType": "STRING"},
{ "name": "CPUCores", "dataType": "NUMBER"},
{ "name": "CPUs", "dataType": "NUMBER"},
{ "name": "CPUSpeedMHz", "dataType": "NUMBER"},
{ "name": "CPUSockets", "dataType": "NUMBER"},
{ "name": "CPUHyperThreadEnabled", "dataType": "STRING"},
{ "name": "OSServicePack", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Service",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "ServiceType", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "DependentServices", "dataType": "STRING"},
{ "name": "ServicesDependedOn", "dataType": "STRING"},
{ "name": "StartType", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRegistry",
"version":"1.0",
"attributes":[
{ "name": "KeyPath", "dataType": "STRING"},
{ "name": "ValueName", "dataType": "STRING"},
{ "name": "ValueType", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRole",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "Path", "dataType": "STRING"},
{ "name": "FeatureType", "dataType": "STRING"},
{ "name": "DependsOn", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "Installed", "dataType": "STRING"},
{ "name": "InstalledState", "dataType": "STRING"},
{ "name": "SubFeatures", "dataType": "STRING"},
{ "name": "ServerComponentDescriptor", "dataType": "STRING"},
{ "name": "Parent", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Tag",
"version":"1.0",
"attributes":[
{ "name": "Key", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ResourceGroup",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Arn", "dataType": "STRING"}
]
},
{
"typeName": "AWS:BillingInfo",
"version": "1.0",
"attributes": [
{ "name": "BillingProductId", "dataType": "STRING"}
]
}
```
**Note**
Pour `"typeName": "AWS:InstanceInformation"`, `InstanceStatus` peut être l'une des options suivantes : Actif, ConnectionLost (connexion perdue), Arrêté, Terminé.
Avec le lancement de la version 2.5, le gestionnaire de package RPM a remplacé l'attribut Serial par Epoch. L'attribut Epoch est un entier qui augmente de façon monotone, comme Serial. Lorsque vous procédez à l'inventaire à l'aide du type `AWS:Application`, une valeur supérieure pour Epoch désigne une version plus récente. Si les valeurs Epoch sont les mêmes ou sont vides, utilisez la valeur de l'attribut Version ou Release (publication) pour déterminer la version plus récente.
Certaines métadonnées ne sont pas disponibles à partir des instances Linux. Plus précisément, pour « typeName » : « AWS:Network », les types de métadonnées suivants ne sont pas encore pris en charge pour les instances Linux. Ils SONT pris en charge pour Windows.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DNSServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# Utilisation de l'inventaire de fichiers et du registre Windows
AWS Systems Manager L'inventaire vous permet de rechercher et d'inventorier des fichiers sous Linux et sur Windows Server des systèmes macOS d'exploitation. Vous pouvez également rechercher et inventorier le registre Windows.
**Fichiers** : Vous pouvez collecter des informations de métadonnées sur les fichiers, notamment leurs noms, leur heure de création, l'heure de leur dernière modification et de leur dernier accès, leur taille, etc. Pour commencer la collecte d'un inventaire de fichiers, indiquez le chemin d'accès où effectuer l'inventaire, un ou plusieurs modèles définissant les types de fichiers à inventorier, et si le chemin doit être parcouru de manière récursive. Systems Manager inventorie toutes les métadonnées de fichier des fichiers qui, dans le chemin spécifié, correspondent au modèle. L'inventaire de fichiers utilise l'entrée de paramètre suivante.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Chemin** : chemin d'accès au répertoire où vous souhaitez inventorier les fichiers. Sous Windows, vous pouvez utiliser des variables d’environnement telles que `%PROGRAMFILES% ` dès lors que la variable est mappée à un seul chemin d’accès au répertoire. Par exemple, si vous utilisez la variable %PATH% qui est mappée sur plusieurs chemins de répertoire, l'inventaire renvoie une erreur.
+ **Modèle** : tableau de modèles pour identifier des fichiers.
+ **Récursif** : valeur booléenne indiquant si l'inventaire doit parcourir les répertoires de manière récursive.
+ **DirScanLimit**: valeur facultative spécifiant le nombre de répertoires à analyser. Utilisez ce paramètre pour minimiser l'impact sur les performances de vos nœuds gérés. L’inventaire analyse 5 000 répertoires au maximum.
**Note**
L'inventaire collecte des métadonnées pour 500 fichiers au maximum sur tous les chemins indiqués.
Voici des exemples de spécification de paramètres lors de l'exécution d'un inventaire de fichiers.
+ Sous Linux et macOS, collectez les métadonnées des fichiers .sh dans le répertoire `/home/ec2-user`, en excluant tous les sous-répertoires.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ Sous Windows, collectez les métadonnées de tous les fichiers .exe du dossier Program Files, en incluant les sous-répertoires de manière récursive.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ Sous Windows, collectez les métadonnées de modèles de journaux spécifiques.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ Limitez le nombre de répertoires lors de l'exécution d'une collection récursive.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Registre Windows** : Vous pouvez collecter des valeurs et clés de registre Windows. Vous pouvez choisir un chemin de clé et collecter toutes les clés et valeurs de manière récursive. Vous pouvez également collecter une clé de registre spécifique et sa valeur pour un chemin donné. Inventory collecte le chemin de clé, le nom, le type et la valeur.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Chemin** : chemin d'accès à la clé de registre.
+ **Récursif** : valeur booléenne indiquant si l'inventaire doit parcourir les répertoires du registre de manière récursive.
+ **ValueNames**: tableau de noms de valeurs pour effectuer l'inventaire des clés de registre. Si vous utilisez ce paramètre, Systems Manager n'inventorie que les noms de valeurs spécifiés pour le chemin indiqué.
**Note**
L'inventaire collecte 250 valeurs de clé de registre au maximum sur tous les chemins indiqués.
Voici des exemples de spécification de paramètres lors de l'exécution d'un inventaire du registre Windows.
+ Collectez toutes les clés et valeurs de manière récursive pour un chemin spécifique.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ Collectez toutes les clés et valeurs pour un chemin spécifique (recherche récursive désactivée).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ Collectez une clé spécifique à l'aide de l'option `ValueNames`.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Configuration de Systems Manager Inventory
Avant d'utiliser AWS Systems Manager Inventory pour collecter des métadonnées relatives aux applications, services, AWS composants, etc., exécutés sur vos nœuds gérés, nous vous recommandons de configurer la synchronisation des données de ressources afin de centraliser le stockage de vos données d'inventaire dans un seul compartiment Amazon Simple Storage Service (Amazon S3). Nous vous recommandons également de configurer la EventBridge surveillance des événements d'inventaire par Amazon. Ces processus facilitent l'affichage et la gestion des données d'inventaire et de la collecte.
**Topics**
+ [Création d’une synchronisation des données de ressources pour l’inventaire](inventory-create-resource-data-sync.md)
+ [Utilisation EventBridge pour surveiller les événements d'inventaire](systems-manager-inventory-setting-up-eventbridge.md)
# Création d’une synchronisation des données de ressources pour l’inventaire
Cette rubrique décrit comment configurer la synchronisation des données de ressource pour l'inventaire AWS Systems Manager . Pour de plus amples informations sur la synchronisation des données de ressource pour Systems Manager Explorer, consultez [Configuration de Systems Manager Explorer de sorte à afficher les données de plusieurs comptes et Régions](Explorer-resource-data-sync.md).
## À propos de la synchronisation des données de ressource
Vous pouvez utiliser la synchronisation des données de ressources Systems Manager pour envoyer les données d'inventaire collectées à partir de toutes vos nœuds gérés vers un même compartiment Amazon Simple Storage Service (Amazon S3). La synchronisation des données de ressource met alors automatiquement à jour les données centralisées lors de la collecte de nouvelles données d'inventaire. Toutes les données d'inventaire étant stockées dans un compartiment Amazon S3 cible, vous pouvez utiliser des services tels qu'Amazon Athena et Amazon Quick pour interroger et analyser les données agrégées.
Par exemple, vous avez configure l'inventaire pour la collecte des données relatives au système d'exploitation (OS) et aux applications qui s'exécutent sur une série de 150 nœuds gérés. Certains de ces nœuds sont localisés dans un centre de données sur site, d'autres sont exécutés dans Amazon Elastic Compute Cloud (Amazon EC2) parmi plusieurs Régions AWS. Si vous n'avez *pas* configuré la synchronisation des données de ressource, vous devez soit rassembler manuellement les données d'inventaire collectées pour chaque nœud géré, soit créer des scripts pour rassembler ces informations. Vous devriez alors transférer les données vers une application afin de pouvoir les interroger et les analyser.
Grâce à la synchronisation des données de ressource, vous pouvez synchroniser toutes les données d'inventaire provenant de toutes vos nœuds gérés en une seule opération. Une fois la synchronisation réalisée avec succès, Systems Manager crée une référence pour toutes les données d'inventaire et les enregistre dans le compartiment Amazon S3 cible. Une fois les nouvelles données d'inventaire collectées, Systems Manager met automatiquement à jour les données dans le compartiment Amazon S3. Vous pouvez ensuite transférer les données rapidement et à moindre coût vers Amazon Athena et Amazon Quick.
Le diagramme 1 montre comment la synchronisation de données de ressources rassemble les données d'inventaire provenant d'Amazon EC2 et d'autres types de machines dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) vers un compartiment Amazon S3 cible. Ce diagramme montre également comment fonctionne la synchronisation des données de ressources avec plusieurs Comptes AWS et Régions AWS.
**Schéma 1 : Synchronisation des données de ressources avec plusieurs Comptes AWS et Régions AWS**
![\[Architecture de la synchronisation de données de ressources Systems Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
Si vous supprimez un nœud géré, la synchronisation des données de ressource conserve le fichier d'inventaire pour le nœud supprimé. Néanmoins, pour les nœuds en cours d'exécution, la synchronisation des données de ressource écrase les anciens fichiers d'inventaire lors de la création et de l'écriture de nouveaux fichiers sur le compartiment Amazon S3. Si vous souhaitez suivre l'évolution des stocks au fil du temps, vous pouvez utiliser le AWS Config service pour suivre le type de `SSM:ManagedInstanceInventory` ressource. Pour plus d'informations, consultez [Getting Started with AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html).
Utilisez les procédures décrites dans cette section pour créer une synchronisation des données de ressources pour Inventory à l'aide d'Amazon S3 et de AWS Systems Manager consoles. Vous pouvez également l'utiliser AWS CloudFormation pour créer ou supprimer une synchronisation des données de ressources. Pour l'utiliser CloudFormation, ajoutez la [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html)ressource à votre CloudFormation modèle. Pour de plus amples informations, consultez l'une des ressources de documentation suivantes :
+ [AWS CloudFormation ressource pour la synchronisation des données des ressources dans AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/) (blog)
+ [Utilisation de modèles AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) dans le *Guide de l'utilisateur AWS CloudFormation *
**Note**
Vous pouvez utiliser AWS Key Management Service (AWS KMS) pour chiffrer les données d'inventaire dans le compartiment Amazon S3. Pour un exemple de création d'une synchronisation chiffrée à l'aide de AWS Command Line Interface (AWS CLI) et d'utilisation des données centralisées dans Amazon Athena et Amazon Quick, consultez. [Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire](inventory-resource-data-sync.md)
## Avant de commencer
Avant de créer une synchronisation des données de ressource, appliquez la procédure suivante pour créer un compartiment Amazon S3 central pour stocker les données d'inventaire agrégées. La procédure décrit comment affecter une politique de compartiment qui permet à Systems Manager d'écrire des données d'inventaire dans le compartiment à partir de plusieurs comptes. Si vous disposez déjà d'un compartiment Amazon S3 que vous souhaitez utiliser pour agréger les données d'inventaire pour la synchronisation des données de ressource, vous devez configurer celui-ci pour qu'il utilise la politique dans la procédure suivante.
**Note**
Systems Manager Inventory ne peut pas ajouter de données à un compartiment Amazon S3 spécifié si celui-ci est configuré pour utiliser Object Lock. Vérifiez que le compartiment Amazon S3 que vous créez ou sélectionnez pour la synchronisation de données de ressources n'est pas configuré pour utiliser Amazon S3 Object Lock. Pour plus d'informations, consultez [Présentation de la fonctionnalité de verrouillage des objets Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html), consultez le *Guide de l'utilisateur d'Amazon Simple Storage Service*.
**Pour créer et configurer un compartiment Amazon S3 pour la synchronisation de données de ressources**
1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Créez un compartiment pour stocker vos données d'inventaire rassemblées. Pour plus d'informations, consultez [Création d'un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Guide de l'utilisateur d'Amazon Simple Storage Service*. Notez le nom du bucket et l' Région AWS endroit où vous l'avez créé.
1. Sélectionnez l'onglet **Autorisations**, puis **Politique de compartiment**.
1. Copiez et collez la politique de compartiment suivante dans l'éditeur de politique. *amzn-s3-demo-bucket*Remplacez-le par le nom du compartiment S3 que vous avez créé. Remplacez *account\$1ID\$1number* par un numéro Compte AWS d'identification valide.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=111122223333/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=444455556666/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=123456789012/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=777788889999/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:111122223333:resource-data-sync/*"
}
}
}
]
}
```
------
1. Enregistrez vos modifications.
## Créer une synchronisation de données de ressources pour Inventory
Utilisez la procédure suivante pour créer une synchronisation de données de ressource pour Systems Manager Inventory avec la console Systems Manager. Pour plus d'informations sur la façon de créer une synchronisation des données de ressources à l'aide du AWS CLI, voir[Utilisation du AWS CLI pour configurer la collecte des données d'inventaire](inventory-collection-cli.md).
**Pour créer une synchronisation de données de ressources**
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 le menu **Account management (Gestion de compte)**, sélectionnez **Resource data sync (Synchronisation de données de ressources)**.
1. Sélectionnez **Create resource data sync (Créer une synchronisation des données de ressource)**.
1. Dans le champ **Sync name (Nom de la synchronisation)**, saisissez un nom pour la configuration de la synchronisation.
1. Dans le champ **Nom du compartiment**, saisissez le nom du compartiment Amazon S3 que vous avez créé selon la procédure **Pour créer et configurer un compartiment Amazon S3 pour la synchronisation de données de ressources**.
1. (Facultatif) Dans le champ **Bucket prefix (Préfixe du compartiment)**, saisissez le nom d'un préfixe de compartiment Amazon S3 (sous-répertoire).
1. Dans le champ **Bucket region (Région du compartiment)**, sélectionnez **This region (Cette région)** si le compartiment Amazon S3 créé est localisé dans la Région AWS actuelle. Si le compartiment est localisé dans une autre Région AWS, sélectionnez **Another region (Autre région)**, et saisissez le nom de la région.
**Note**
Si la synchronisation et le compartiment Amazon S3 cible sont localisés dans des régions différentes, vous pourriez être sujet à une tarification de transfert de données. Pour plus d'informations, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
1. (Facultatif) Dans le champ **KMS Key ARN (ARN de clé KMS)**, saisissez ou collez un ARN de clé KMS pour chiffrer les données d'inventaire dans Amazon S3.
1. Choisissez **Créer**.
Pour synchroniser les données d'inventaire provenant de plusieurs régions Régions AWS, vous devez créer une synchronisation des données de ressources dans *chaque* région. Répétez cette procédure dans chaque Région AWS endroit où vous souhaitez collecter des données d'inventaire et les envoyer au compartiment central Amazon S3. Lorsque vous créez la synchronisation dans chaque région, spécifiez le compartiment Amazon S3 central dans le champ **Bucket name (Nom du compartiment)**. Ensuite, utilisez l'option **Bucket region (Région du compartiment)** pour choisir la région où vous avez créé le compartiment Amazon S3 central, comme illustré dans la capture d'écran suivante. La prochaine fois que l'association s'exécute pour collecter les données d'inventaire, Systems Manager stocke les données dans le compartiment Amazon S3 central.
![\[Synchronisation des données de ressources de Systems Manager à partir de plusieurs Régions AWS\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## Création d'une synchronisation des données des ressources d'inventaire pour les comptes définis dans AWS Organizations
Vous pouvez synchroniser les données d'inventaire Comptes AWS définies dans AWS Organizations un compartiment Amazon S3 central. Après avoir terminé les procédures suivantes, les données d'inventaire sont synchronisées avec des préfixes de clé Amazon S3 *individuels* dans le compartiment central. Chaque préfixe de clé représente un identifiant différent. Compte AWS
**Avant de commencer**
Avant de commencer, vérifiez que vous avez configuré et configuré Comptes AWS dans AWS Organizations. Pour plus d'informations, consultez [ dans le *Guide de l'utilisateur AWS Organizations *](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html).
Sachez également que vous devez créer la synchronisation des données des ressources basée sur l'organisation pour chacune d'elles Région AWS et Compte AWS définie dans. AWS Organizations
### Création d'un compartiment Amazon S3 central
Appliquez la procédure suivante pour créer un compartiment Amazon S3 central pour stocker les données d'inventaire agrégées. La procédure décrit comment affecter une politique de compartiment qui permet à Systems Manager d'écrire des données d'inventaire dans le compartiment à partir de votre ID de compte AWS Organizations . Si vous disposez déjà d'un compartiment Amazon S3 que vous souhaitez utiliser pour agréger les données d'inventaire pour la synchronisation des données de ressource, vous devez configurer celui-ci pour qu'il utilise la politique dans la procédure suivante.
**Pour créer et configurer un compartiment Amazon S3 pour la synchronisation des données de ressources pour plusieurs comptes définis dans AWS Organizations**
1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Créez un compartiment pour stocker vos données d'inventaire agrégées. Pour plus d'informations, consultez [Création d'un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Guide de l'utilisateur d'Amazon Simple Storage Service*. Notez le nom du bucket et l' Région AWS endroit où vous l'avez créé.
1. Sélectionnez l'onglet **Autorisations**, puis **Politique de compartiment**.
1. Copiez et collez la politique de compartiment suivante dans l'éditeur de politique. Remplacez *amzn-s3-demo-bucket * et *organization-id* par le nom du compartiment Amazon S3 que vous avez créé et un identifiant de AWS Organizations compte valide.
Vous pouvez éventuellement le *bucket-prefix* remplacer par le nom d'un préfixe Amazon S3 (sous-répertoire). Si vous n'avez pas créé de préfixe, supprimez*bucket-prefix*/de l'ARN dans la politique suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceOrgID": "organization-id"
}
}
},
{
"Sid": " SSMBucketDeliveryTagging",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObjectTagging",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
]
}
]
}
```
------
### Créez une synchronisation des données des ressources d'inventaire pour les comptes définis dans AWS Organizations
La procédure suivante décrit comment utiliser le AWS CLI pour créer une synchronisation des données de ressources pour les comptes définis dans AWS Organizations. Vous devez utiliser le AWS CLI pour effectuer cette tâche. Vous devez également exécuter cette procédure pour chacun d'entre eux Région AWS et Compte AWS définie dans AWS Organizations.
**Pour créer une synchronisation des données de ressources pour un compte défini dans AWS Organizations (AWS CLI)**
1. 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).
1. Exécutez la commande suivante pour vérifier que vous n’avez pas d’autres synchronisations de données de ressources *basées sur AWS Organizations*. Vous pouvez avoir plusieurs synchronisations standard, y compris plusieurs synchronisations standard et une synchronisation basée sur Organizations. Cependant, vous ne pouvez avoir qu’une seule synchronisation de données de ressources basée sur Organizations.
```
aws ssm list-resource-data-sync
```
Si la commande renvoie d’autres synchronisations de données de ressources basées sur Organizations, vous devez les supprimer ou choisir de ne pas en créer de nouvelles.
1. Exécutez la commande suivante pour créer une synchronisation des données de ressource pour un compte défini dans AWS Organizations. Pour amzn-s3-demo-bucket, indiquez le nom du compartiment Amazon S3 que vous avez créé plus tôt dans cette rubrique. Si vous avez créé un préfixe (sous-répertoire) pour votre compartiment, spécifiez ces informations pour. *prefix-name*
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=Région AWS, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. Répétez les étapes 2 et 3 pour chaque Région AWS Compte AWS endroit où vous souhaitez synchroniser les données avec le compartiment Amazon S3 central.
### Gestion des synchronisations des données de ressource
Chacun Compte AWS peut avoir 5 synchronisations de données de ressources par personne. Région AWS Vous pouvez utiliser la console AWS Systems ManagerFleet Manager pour gérer les synchronisations des données de vos ressources.
**Pour afficher les synchronisations des données de ressource**
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 le menu déroulant **Gestion de compte**, sélectionnez **Synchronisation de données de ressource**.
1. Sélectionnez une synchronisation des données de ressource dans le tableau, puis choisissez **Afficher les détails** pour afficher les informations relatives à la synchronisation de vos données de ressource.
**Pour supprimer une synchronisation de données de ressources**
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 le menu déroulant **Gestion de compte**, sélectionnez **Synchronisation de données de ressource**.
1. Sélectionnez une synchronisation des données de ressource dans le tableau, puis choisissez **Supprimer**.
# Utilisation EventBridge pour surveiller les événements d'inventaire
Vous pouvez configurer une règle dans Amazon EventBridge pour créer un événement en réponse aux modifications de l'état des ressources d' AWS Systems Manager inventaire. EventBridge prend en charge les événements liés aux changements d'état de l'inventaire suivants. Tous les événements sont générés sur la base du meilleur effort.
**Type d'inventaire personnalisé supprimé pour une instance spécifique** : si une règle est configurée pour surveiller cet événement, EventBridge crée un événement lorsqu'un type d'inventaire personnalisé est supprimé pour un gestionnaire spécifique. EventBridgeenvoie un événement par nœud par type d'inventaire personnalisé. Voici un exemple de modèle d'événement.
```
{
"timestampMillis": 1610042981103,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:09:41 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "succeeded",
"action": "delete",
"resource-type": "managed-instance",
"resource-id": "i-12345678",
"action-reason": "",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**Événement de suppression du type d'inventaire personnalisé pour toutes les instances** : si une règle est configurée pour surveiller cet événement, EventBridge crée un événement lorsqu'un type d'inventaire personnalisé pour tous les nœuds gérés est supprimé. Voici un exemple de modèle d'événement.
```
{
"timestampMillis": 1610042904712,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:08:24 PM",
"resources": [
],
"body": {
"action-status": "succeeded",
"action": "delete-summary",
"resource-type": "managed-instance",
"resource-id": "",
"action-reason": "The delete for type name Custom:SomeCustomInventoryType was completed. The deletion summary is: {\"totalCount\":1,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.1\",\"count\":1,\"remainingCount\":0}]}",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)événement d'appel avec ancienne version de schéma** : si une règle est configurée pour surveiller cet événement, EventBridge crée un événement lorsqu'un PutInventory appel utilise une version de schéma inférieure au schéma actuel. Cet événement s'applique à tous les types d'inventaire. Voici un exemple de modèle d'événement.
```
{
"timestampMillis": 1610042629548,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:03:49 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "failed",
"action": "put",
"resource-type": "managed-instance",
"resource-id": "i-01f017c1b2efbe2bc",
"action-reason": "The inventory item with type name Custom:MyCustomInventoryType was sent with a disabled schema verison 1.0. You must send a version greater than 1.0",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
Pour plus d'informations sur la configuration EventBridge de la surveillance de ces événements, consultez[Configuration EventBridge pour les événements de Systems Manager](monitoring-systems-manager-events.md).
# Configuration de la collecte d'inventaire
Cette section décrit comment configurer la collecte AWS Systems Manager d'inventaire sur un ou plusieurs nœuds gérés à l'aide de la console Systems Manager. Pour un exemple de configuration de la collecte d'inventaire à l'aide de AWS Command Line Interface (AWS CLI), consultez[Utilisation du AWS CLI pour configurer la collecte des données d'inventaire](inventory-collection-cli.md).
Lorsque vous configurez la collecte d'inventaire, vous commencez par créer une AWS Systems Manager State Manager association. Systems Manager collecte les données d'inventaire lorsque l'association est exécutée. Si vous ne créez pas d'abord l'association et que vous tentez d'appeler le `aws:softwareInventory` plugin en utilisant, par exemple AWS Systems Manager Run Command, le système renvoie l'erreur suivante : `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**Note**
Vous devez connaître le comportement suivant en cas de création d'associations d'inventaire multiples pour un nœud géré.
Chaque nœud peut se voir attribuer une association d'inventaire qui cible *tous les* nœuds (--targets « Key=InstanceIds, Values=\$1 »).
Chaque nœud peut également se voir attribuer une association spécifique qui utilise des key/value paires de balises ou un groupe de AWS ressources.
Si plusieurs associations d'inventaire sont affectées à un nœud, l'association qui ne s'est pas exécutée présente le statut *Skipped (Ignoré)*. L'association qui s'est exécutée la plus récemment affiche le statut réel de l'association d'inventaire.
Si plusieurs associations d'inventaire sont attribuées à un nœud et que chacune utilise une key/value paire de balises, ces associations d'inventaire ne s'exécutent pas sur le nœud en raison du conflit de balises. L'association fonctionne toujours sur les nœuds qui ne présentent pas de key/value conflit de balises.
**Avant de commencer**
Avant de configurer la collecte d'inventaire, effectuez les tâches suivantes.
+ Mettez à AWS Systems Manager SSM Agent jour les nœuds que vous souhaitez inventorier. En exécutant la dernière version de SSM Agent, vous êtes sûr de collecter les métadonnées de tous les types d'inventaire pris en charge. Pour plus d'informations sur la mise à jour de l'SSM Agent à l'aide de State Manager, consultez [Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI](state-manager-update-ssm-agent-cli.md).
+ Vérifiez que vous avez satisfait la configuration requise pour vos instances Amazon Elastic Compute Cloud (Amazon EC2) et vos machines non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Pour plus d'informations, consultez [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
+ Pour les Windows Server nœuds Microsoft, vérifiez que votre nœud géré est configuré avec Windows PowerShell 3.0 (ou version ultérieure). SSM Agentutilise l'`ConvertTo-Json`applet de commande PowerShell pour convertir les données d'inventaire Windows Update au format requis.
+ (Facultatif) Créez une synchronisation de données de ressources pour stocker les données d'inventaire de façon centralisée dans un compartiment Amazon S3. La synchronisation de données de ressources met alors automatiquement à jour les données centralisées lorsque de nouvelles données d'inventaire sont collectées. Pour de plus amples informations, veuillez consulter [Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire](inventory-resource-data-sync.md).
+ (Facultatif) Créez un fichier JSON pour collecter l'inventaire personnalisé. Pour de plus amples informations, veuillez consulter [Utilisation de l'inventaire personnalisé](inventory-custom.md).
## Répertoriez tous les nœuds gérés de votre Compte AWS
Vous pouvez inventorier tous les nœuds gérés de votre Compte AWS site en créant une association d'inventaire globale. Une association d'inventaire global effectue les actions suivantes :
+ Applique automatiquement la configuration de l'inventaire global (association) à tous les nœuds gérés existants de votre Compte AWS. Les nœuds gérés disposant déjà d'une association d'inventaire sont ignorés lorsque l'association d'inventaire global est appliquée et s'exécute. Lorsqu'un nœud est ignoré, le message de statut détaillé indique `Overridden By Explicit Inventory Association`. Ces nœuds sont ignorés par l'association globale, mais ils continuent de générer des inventaires lorsqu'ils exécutent l'association d'inventaire qui leur est affectée.
+ Ajoute automatiquement les nouveaux nœuds créés dans votre Compte AWS entreprise à l'association d'inventaire globale.
**Note**
Si un nœud géré est configuré pour l'association d'inventaire global et que vous lui affectez une association spécifique, alors Systems Manager Inventory annulera la priorité de l'association globale et appliquera l'association spécifique.
Les associations d'inventaire global sont disponibles dans SSM Agent, version 2.0 790.0 ou version ultérieure. Pour plus d'informations sur la mise à jour de l'SSM Agent sur vos nœuds, consultez [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
### Configuration de la collecte d'inventaire en un clic (console)
Utilisez la procédure suivante pour configurer Systems Manager Inventory pour tous les nœuds gérés de votre Compte AWS et en un seul Région AWS.
**Pour configurer l'ensemble de vos nœuds gérés dans la région actuelle pour Systems Manager Inventory**
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 volet de navigation, sélectionnez **Inventory**.
1. Dans la carte **Managed instances with inventory enabled (Instances gérées avec l'inventaire activé)**, sélectionnez **Click here to enable inventory on all instances (Cliquez ici pour activer l'inventaire sur toutes les instances)**.
![\[Activation de l’inventaire Systems Manager sur tous les nœuds gérés.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-one-click-1.png)
En cas de réussite, la console affiche le message suivant.
![\[Activation de l’inventaire Systems Manager sur tous les nœuds gérés.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-one-click-2.png)
En fonction du nombre de nœuds gérés dans votre compte, l'application de l'association d'inventaire global peut prendre plusieurs minutes. Patientez quelques minutes, puis actualisez la page. Vérifiez que le graphique change pour montrer que l'inventaire est configuré sur l'ensemble de vos nœuds gérés.
### Configuration de la collecte à l'aide de la console
Cette section inclut des informations sur la configuration de Systems Manager Inventory pour qu'il collecte les métadonnées de vos nœuds gérés à l'aide de la console Systems Manager. Vous pouvez collecter rapidement des métadonnées à partir de tous les nœuds d'un compte spécifique Compte AWS (et de tous les futurs nœuds qui pourraient être créés dans ce compte) ou vous pouvez collecter des données d'inventaire de manière sélective à l'aide de balises ou de nœuds IDs.
**Note**
Avant de terminer cette procédure, vérifiez si une association d'inventaire global existe déjà. Si une association d'inventaire global existe déjà, chaque fois que vous lancez une nouvelle instance, l'association lui sera appliquée et la nouvelle instance sera inventoriée.
**Pour configurer la collecte d'inventaire**
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 volet de navigation, sélectionnez **Inventory**.
1. Sélectionnez **Setup Inventory (Configurer l'inventaire)**.
1. Dans la section **Targets (Cibles)**, identifiez les nœuds sur lesquels vous souhaitez exécuter cette opération en choisissant l'un des éléments suivants.
+ **Selecting all managed instances in this account (Sélection de toutes les instances gérées dans ce compte)** : cette option sélectionne tous les nœuds gérés ne disposant d'aucune association d'inventaire existante. Si vous sélectionnez cette option, les nœuds disposant déjà d'associations d'inventaire sont ignorés lors de la collecte d'inventaire, et s'affichent avec un statut **Skipped (Ignoré)** dans les résultats d'inventaire. Pour de plus amples informations, veuillez consulter [Répertoriez tous les nœuds gérés de votre Compte AWS](#inventory-management-inventory-all).
+ **Specifying a tag (Spécification d'une balise)** : utilisez cette option afin de spécifier une balise unique pour identifier les nœuds de votre compte à partir desquels vous souhaitez collecter l'inventaire. Si vous utilisez une balise, tous les nœuds créés ensuite avec la même balise généreront également des rapports d'inventaires. S'il existe déjà une association d'inventaire avec tous les nœuds, l'utilisation d'une balise pour sélectionner des nœuds spécifiques en tant que cible pour un autre inventaire remplace l'appartenance du nœud dans le groupe cible **All managed instances (Toutes les instances gérées)**. Les nœuds gérés avec la balise spécifiée sont ignorées lors des futures collectes d'inventaire à partir de **All managed instances (Toutes les instances gérées)**.
+ **Manually selecting instances (Sélection manuelle des instances)** : utilisez cette option pour choisir des nœuds gérés spécifiques dans votre compte. Choisir explicitement des instances spécifiques à l'aide de cette option remplace les associations d'inventaire sur la cible **All managed instances (Toutes les instances gérées)**. Le nœud est ignoré lors des futures collectes d'inventaire à partir de **All managed instances (Toutes les instances gérées)**.
**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. Dans la section **Schedule (Calendrier)**, sélectionnez la fréquence à laquelle le système doit collecter les métadonnées d'inventaire à partir de vos nœuds.
1. Dans la section **Parameters (Paramètres)**, utilisez les listes pour activer ou désactiver les différents types de collecte d'inventaire. Pour plus d'informations sur la collecte de l'inventaire de fichiers et du registre Windows, consultez [Utilisation de l'inventaire de fichiers et du registre Windows](inventory-file-and-registry.md).
1. Dans la section **Advanced (Avancé)**, sélectionnez **Sync inventory execution logs to an Amazon S3 bucket (Synchroniser les journaux d'exécution d'inventaire de synchronisation sur un compartiment Amazon S3)** si vous souhaitez stocker le statut d'exécution d'association dans un compartiment Amazon S3.
1. Sélectionnez **Setup Inventory (Configurer l'inventaire)**. Systems Manager crée une association State Manager et exécute immédiatement l'inventaire sur les nœuds.
1. Dans le panneau de navigation, sélectionnez **State Manager**. Vérifiez qu'une nouvelle association utilisant le document `AWS-GatherSoftwareInventory` a été créée. La planification de l'association utilise une expression rate. Vérifiez également que le champ **Status (Statut)** affiche la valeur **Success (Réussite)**. Si vous avez choisi l'option **Sync inventory execution logs to an Amazon S3 bucket (Synchroniser les journaux d'exécution d'inventaire sur un compartiment Amazon S3)**, vous pouvez afficher les données des journaux dans Amazon S3 après quelques minutes. Si vous souhaitez afficher les données d'inventaire pour un nœud spécifique, sélectionnez **Managed Instances (Instances gérées)** dans le panneau de navigation.
1. Sélectionnez Manage (Gérer), puis **View details (Afficher les détails)**.
1. Sur la page des détails du nœud, sélectionnez **Inventory (Inventaire)**. Utilisez les listes **Inventory type (Type d'inventaire)** pour filtrer l'inventaire.
# Interrogation des données d'inventaire à partir de plusieurs régions et comptes
AWS Systems Manager Inventory s'intègre à Amazon Athena pour vous aider à interroger les données d'inventaire provenant de plusieurs Régions AWS et. Comptes AWS L'intégration d'Athena utilise la synchronisation des données des ressources afin que vous puissiez consulter les données d'inventaire de tous vos nœuds gérés sur la page d'**affichage détaillé** de la AWS Systems Manager console.
**Important**
Cette fonctionnalité permet AWS Glue d'explorer les données de votre compartiment Amazon Simple Storage Service (Amazon S3), et d'Amazon Athena pour interroger les données. En fonction de la quantité de données analysées et interrogées, l'utilisation de ces services peut vous être facturée. Avec AWS Glue, vous payez un taux horaire, facturé à la seconde, pour les crawlers (découverte de données) et les tâches ETL (traitement et chargement de données). Avec Athena, vous êtes facturé en fonction de la quantité de données analysées par chaque requête. Nous vous incitons à consulter les consignes de tarification de ces services avant d'utiliser l'intégration d'Amazon Athena avec Systems Manager Inventory. Pour en savoir plus, consultez la [tarification Amazon Athena](https://aws.amazon.com/athena/pricing/) et la [tarification AWS Glue](https://aws.amazon.com/glue/pricing/).
Vous pouvez afficher les données d'inventaire sur la page **Detailed View (Vue détaillée)** dans toutes les Régions AWS où Amazon Athena est disponible. Pour obtenir une liste des régions prises en charge, veuillez consulter la rubrique [Points de terminaison de service Amazon Athena](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region) de la *Référence générale d'Amazon Web Services*.
**Avant de commencer**
L'intégration d'Athena utilise la synchronisation de données de ressources. Vous devez installer et configurer la synchronisation de données de ressources pour utiliser cette fonction. Pour de plus amples informations, veuillez consulter [Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire](inventory-resource-data-sync.md).
De plus, sachez que la page **Detailed View (Vue détaillée)** affiche les données d'inventaire pour le *propriétaire* du compartiment Amazon S3 central utilisé par la synchronisation de données de ressources. Si vous n'êtes pas le propriétaire du compartiment Amazon S3 central, vous ne verrez pas les données d'inventaire sur la page **Detailed View (Vue détaillée)**.
## Configuration de l'accès
Avant de pouvoir interroger et afficher des données de plusieurs comptes et régions sur la page **Vue détaillée** dans la console Systems Manager, vous devez configurer votre entité IAM avec l'autorisation d'afficher les données.
Si les données d'inventaire sont stockées dans un compartiment Amazon S3 qui utilise le chiffrement AWS Key Management Service (AWS KMS), vous devez également configurer votre entité IAM et le rôle de `Amazon-GlueServiceRoleForSSM` service pour le AWS KMS chiffrement.
**Topics**
+ [Configuration de votre entité IAM pour accéder à la page Vue détaillée](#systems-manager-inventory-query-iam-user)
+ [(Facultatif) Configurer les autorisations d'affichage des données AWS KMS chiffrées](#systems-manager-inventory-query-kms)
### Configuration de votre entité IAM pour accéder à la page Vue détaillée
Ce qui suit décrit les autorisations minimales requises pour afficher les données d'inventaire sur la page **Affichage détaillé**.
La politique gérée `AWSQuicksightAthenaAccess`
Le `PassRole` suivant et les blocs d'autorisations requis supplémentaires
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlue",
"Effect": "Allow",
"Action": [
"glue:GetCrawler",
"glue:GetCrawlers",
"glue:GetTables",
"glue:StartCrawler",
"glue:CreateCrawler"
],
"Resource": "*"
},
{
"Sid": "iamPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/SSMInventoryGlueRole",
"arn:aws:iam::111122223333:role/SSMInventoryServiceRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "glue.amazonaws.com"
}
}
},
{
"Sid": "iamRoleCreation",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/*"
},
{
"Sid": "iamPolicyCreation",
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": "arn:aws:iam::111122223333:policy/*"
}
]
}
```
------
(Facultatif) Si le compartiment Amazon S3 utilisé pour stocker les données d'inventaire est chiffré à l'aide de cette méthode AWS KMS, vous devez également ajouter le bloc suivant à la politique.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles :
+ Utilisateurs et groupes dans AWS IAM Identity Center :
Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *.
+ Utilisateurs gérés dans IAM par un fournisseur d’identité :
Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*.
+ Utilisateurs IAM :
+ Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
+ (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*.
### (Facultatif) Configurer les autorisations d'affichage des données AWS KMS chiffrées
Si le compartiment Amazon S3 utilisé pour stocker les données d'inventaire est chiffré à l'aide du AWS Key Management Service (AWS KMS), vous devez configurer votre entité IAM et le rôle **GlueServiceRoleForAmazon-SSM** avec `kms:Decrypt` des autorisations pour la AWS KMS clé.
**Avant de commencer**
Pour fournir les `kms:Decrypt` autorisations relatives à la AWS KMS clé, ajoutez le bloc de politique suivant à votre entité IAM :
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Si ce n'est pas déjà fait, suivez cette procédure et ajoutez `kms:Decrypt` des autorisations pour la AWS KMS clé.
Utilisez la procédure suivante pour configurer le rôle **GlueServiceRoleForAmazon-SSM** avec des `kms:Decrypt` autorisations pour la AWS KMS clé.
**Pour configurer le rôle **GlueServiceRoleForAmazon-SSM** avec des autorisations `kms:Decrypt`**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le volet de navigation, choisissez **Roles**, puis utilisez le champ de recherche pour localiser le rôle **GlueServiceRoleForAmazon-SSM**. La page **Récapitulatif** s'ouvre.
1. Utilisez le champ de recherche pour trouver le rôle **GlueServiceRoleForAmazon-SSM**. Sélectionnez le nom de rôle. La page **Récapitulatif** s'ouvre.
1. Sélectionnez le nom de rôle. La page **Récapitulatif** s'ouvre.
1. Sélectionnez **Ajouter une politique en ligne**. La page **Créer une politique** s'ouvre.
1. Sélectionnez l'onglet **JSON**.
1. Supprimez le texte JSON existant dans l'éditeur, puis copiez et collez la politique suivante dans l'éditeur JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. Choisissez **Review policy** (Examiner une politique)
1. Sur la page **Examiner une politique**, entrez un nom dans le champ **Nom**.
1. Sélectionnez **Créer une politique**.
## Interrogation des données sur la page Vue détaillée d'inventaire
Utilisez la procédure suivante pour afficher les données d'inventaire provenant de plusieurs sources Régions AWS et Comptes AWS sur la page de **vue détaillée** de l'inventaire de Systems Manager.
**Important**
La page **Detailed View (Vue détaillée)** est uniquement disponible dans les Régions AWS qui proposent Amazon Athena. Si les onglets suivants ne sont pas affichés sur la page Systems Manager Inventory, cela signifie qu'Athena n'est pas disponible dans la région et que vous ne pouvez pas utiliser la **Detailed View (Vue détaillée)** pour interroger les données.
![\[Affichage du tableau de bord de l'inventaire | Vue détaillée | Onglets Paramètres\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**Pour consulter les données d'inventaire de plusieurs régions et comptes dans la AWS Systems Manager 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 volet de navigation, sélectionnez **Inventory**.
1. Sélectionnez l'onglet **Detailed View (Vue détaillée)**.
![\[Accès à la page de vue détaillée de l' AWS Systems Manager inventaire\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. Sélectionnez la synchronisation de données de ressources pour laquelle vous souhaitez rechercher des données.
![\[Afficher les données d'inventaire dans la AWS Systems Manager console\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-display-data.png)
1. Dans la liste **Inventory Type (Type d'inventaire)**, sélectionnez le type de données d'inventaire que vous souhaitez interroger et appuyez sur Enter.
![\[Choix d'un type d'inventaire dans la AWS Systems Manager console\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-type.png)
1. Pour filtrer les données, sélectionnez la barre de filtre, puis sélectionnez une option de filtre.
![\[Filtrer les données d'inventaire dans la AWS Systems Manager console\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-filter.png)
Vous pouvez utiliser le bouton **Export to CSV (Exporter au format CSV)** pour afficher l'ensemble de requêtes actuel dans un tableur tel que Microsoft Excel. Vous pouvez également utiliser les boutons **Query History (Historique de requête)** et **Run Advanced Queries (Exécuter des requêtes avancées)** pour afficher les détails d'historique et interagir avec vos données dans Amazon Athena.
### Modification du planning du AWS Glue crawler
AWS Glue analyse les données d'inventaire dans le compartiment central Amazon S3 deux fois par jour, par défaut. Si vous modifiez fréquemment les types de données à collecter sur vos nœuds, vous préférerez peut-être analyser les données plus fréquemment, comme cela est décrit dans la procédure suivante.
**Important**
AWS Glue vous facture sur la Compte AWS base d'un taux horaire, facturé à la seconde, pour les robots d'exploration (découverte de données) et les tâches ETL (traitement et chargement de données). Avant de modifier la planification du crawler, consultez la page [Tarification AWS Glue](https://aws.amazon.com/glue/pricing/).
**Pour modifier la planification du crawler de données d'inventaire**
1. Ouvrez la AWS Glue console à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Dans le panneau de navigation, sélectionnez **Crawlers**. (Analyseurs)
1. Dans la liste des crawlers, sélectionnez l'option à côté du crawler de données Systems Manager Inventory. Le nom du crawler utilise le format suivant :
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. Sélectionnez **Action**, puis **Modifier un crawler**.
1. Dans le panneau de navigation, sélectionnez **Planification**.
1. Dans le champ **Expression cron**, spécifiez une nouvelle planification à l'aide d'un format cron. Pour plus d'informations sur le format cron, consultez [Planifications temporelles pour les tâches et les crawlers](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html) dans le *Guide du développeur AWS Glue *.
**Important**
Vous pouvez suspendre le robot d'exploration pour ne plus être débité. AWS Glue Si vous suspendez le crawler ou si vous modifiez la fréquence pour analyser moins souvent les données, la page **Detailed View (Vue détaillée)** d'inventaire peut afficher des données qui ne sont pas à jour.
# Interrogation d'une collecte d'inventaire à l'aide de filtres
Après avoir collecté les données d'inventaire, vous pouvez utiliser les fonctionnalités de filtrage AWS Systems Manager pour interroger une liste de nœuds gérés répondant à certains critères de filtrage.
**Pour interroger des nœuds d'après des filtres d'inventaire**
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 volet de navigation, sélectionnez **Inventory**.
1. Dans la section **Filter by resource groups, tags or inventory types (Filtrer par groupes de ressources, balises ou types d'inventaire)**, sélectionnez la zone de filtre. Une liste de filtres prédéfinis s'affiche.
1. Sélectionnez un attribut sur lequel filtrer. Par exemple, sélectionnez `AWS:Application`. Si vous y êtes invité, sélectionnez un attribut secondaire sur lequel filtrer. Par exemple, sélectionnez `AWS:Application.Name`.
1. Sélectionnez un délimiteur dans la liste. Par exemple, sélectionnez **Begin with**. Une zone de texte s'affiche dans le filtre.
1. Saisissez une valeur dans la zone de texte. Par exemple, saisissez *Amazon* (l'SSM Agent est nommé *Amazon SSM Agent*).
1. Appuyez sur Enter. Le système renvoie une liste de nœuds gérés comprenant un nom d'application qui commence par le terme *Amazon*.
**Note**
Vous pouvez combiner plusieurs filtres pour affiner votre recherche.
# Agrégation des données d'inventaire
Après avoir configuré vos nœuds gérés pour l' AWS Systems Manager inventaire, vous pouvez consulter le nombre agrégé de données d'inventaire. Par exemple, supposons que vous avez configuré des dizaines ou des centaines de nœuds gérés pour collecter le type d'inventaire `AWS:Application`. En utilisant les informations de cette section, vous pouvez voir le décompte exact des nœuds configurés pour collecter ces données.
Vous pouvez également voir des détails d'inventaire spécifiques en effectuant une agrégation sur un type de données. Par exemple, le type d'inventaire `AWS:InstanceInformation` collecte les informations de plateforme de système d'exploitation avec le type de données `Platform`. En agrégeant les données sur le type de données `Platform`, vous pouvez rapidement voir le nombre de nœuds qui exécutent Windows Server, le nombre de nœuds qui exécutent Linux et le nombre de nœuds qui exécutent macOS.
Les procédures décrites dans cette section décrivent comment afficher les dénombrements agrégés de données d'inventaire à l'aide du AWS Command Line Interface (AWS CLI). Vous pouvez également consulter les dénombrements agrégés préconfigurés dans la AWS Systems Manager console sur la page **Inventaire**. Ces tableaux de bord préconfigurés sont appelés *analyses d'inventaire* et ils permettent de remédier en un clic à vos problèmes de configuration d'inventaire.
Notez les détails importants suivants relatifs aux décomptes d'agrégation des données d'inventaire :
+ Si vous résiliez un nœud géré configuré pour collecter des données d'inventaire, Systems Manager conserve les données d'inventaire pendant 30 jours, puis les supprime. Pour les nœuds en cours d'exécution, le système supprime les données d'inventaire antérieures à 30 jours. Si vous devez stocker des données d'inventaire pendant plus de 30 jours, vous pouvez les utiliser AWS Config pour enregistrer l'historique ou demander et télécharger régulièrement les données dans un bucket Amazon Simple Storage Service (Amazon S3).
+ Si un nœud a été préalablement configuré pour signaler un type de données d'inventaire spécifique, par exemple, `AWS:Network`, et que vous modifiez ultérieurement cette configuration pour arrêter la collecte de ce type, les décomptes d'agrégation continuent de montrer les données `AWS:Network` jusqu'à ce que le nœud soit mis hors service et une fois le délai des 30 jours passé.
Pour plus d'informations sur la manière de configurer et de collecter rapidement des données d'inventaire à partir de tous les nœuds d'un compte spécifique Compte AWS (et de tout futur nœud susceptible d'être créé dans ce compte), consultez[Répertoriez tous les nœuds gérés de votre Compte AWS](inventory-collection.md#inventory-management-inventory-all).
**Topics**
+ [Agrégation des données d'inventaire pour afficher les décomptes de nœuds qui collectent des types spécifiques de données](#inventory-aggregate-type)
+ [Agrégation des données d'inventaire avec des groupes pour voir quels nœuds sont ou non configurés pour collecter un type d'inventaire](#inventory-aggregate-groups)
## Agrégation des données d'inventaire pour afficher les décomptes de nœuds qui collectent des types spécifiques de données
Vous pouvez utiliser l'opération AWS Systems Manager [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html)API pour afficher le nombre agrégé de nœuds qui collectent un ou plusieurs types d'inventaire et types de données. Par exemple, le type `AWS:InstanceInformation` d'inventaire vous permet de visualiser un agrégat de systèmes d'exploitation en utilisant l'opération d' GetInventory API avec le type de `AWS:InstanceInformation.PlatformType` données. Voici un exemple de commande AWS CLI et de sortie.
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
Le système retourne des informations telles que les suivantes.
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**Prise en main**
Déterminez les types d'inventaire et les types de données pour lesquels vous souhaitez afficher des décomptes. Vous pouvez consulter la liste des types d'inventaires et des types de données qui prennent en charge l'agrégation en exécutant la commande suivante dans l' AWS CLI.
```
aws ssm get-inventory-schema --aggregator
```
Cette commande renvoie la liste JSON des types d'inventaire et des types de données qui prennent en charge l'agrégation. Le **TypeName**champ indique les types d'inventaire pris en charge. Et le champ **Name** montre chaque type de données. Par exemple, dans la liste suivante, le type d'inventaire `AWS:Application` inclut des types de données pour `Name` et `Version`.
```
{
"Schemas": [
{
"TypeName": "AWS:Application",
"Version": "1.1",
"DisplayName": "Application",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "Version"
}
]
},
{
"TypeName": "AWS:InstanceInformation",
"Version": "1.0",
"DisplayName": "Platform",
"Attributes": [
{
"DataType": "STRING",
"Name": "PlatformName"
},
{
"DataType": "STRING",
"Name": "PlatformType"
},
{
"DataType": "STRING",
"Name": "PlatformVersion"
}
]
},
{
"TypeName": "AWS:ResourceGroup",
"Version": "1.0",
"DisplayName": "ResourceGroup",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
}
]
},
{
"TypeName": "AWS:Service",
"Version": "1.0",
"DisplayName": "Service",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "ServiceType"
},
{
"DataType": "STRING",
"Name": "Status"
},
{
"DataType": "STRING",
"Name": "StartType"
}
]
},
{
"TypeName": "AWS:WindowsRole",
"Version": "1.0",
"DisplayName": "WindowsRole",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "FeatureType"
},
{
"DataType": "STRING",
"Name": "Installed"
}
]
}
]
}
```
Vous pouvez agréger les données pour l'un quelconque des types d'inventaire répertoriés en créant une commande qui utilise la syntaxe suivante.
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
Voici quelques exemples.
**Exemple 1**
Cet exemple agrège un décompte des rôles Windows utilisés par vos nœuds.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**Exemple 2**
Cet exemple agrège un décompte des applications installées sur vos nœuds.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**Combinaison de plusieurs agrégateurs**
Vous pouvez également combiner plusieurs types d'inventaire et types de données en une seule commande pour mieux comprendre les données. Voici quelques exemples.
**Exemple 1**
Cet exemple agrège un décompte des types de système d'exploitation utilisés par vos nœuds. Il renvoie également le nom spécifique de ces systèmes d'exploitation.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**Exemple 2**
Cet exemple agrège un décompte des applications qui s'exécutent sur vos nœuds et de la version spécifique de chaque application.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
Si vous préférez, vous pouvez créer une expression d'agrégation avec un ou plusieurs types d'inventaire et types de données dans un fichier JSON et appeler ce fichier à partir de l' AWS CLI. Le code JSON figurant dans le fichier doit utiliser la syntaxe suivante.
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
Vous devez enregistrer le fichier avec l'extension de fichier .json.
Voici un exemple qui utilise plusieurs types d'inventaire et types de données.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
Utilisez la commande suivante pour appeler le fichier à partir de l' AWS CLI.
```
aws ssm get-inventory --aggregators file://file_name.json
```
La commande renvoie des informations telles que les suivantes.
```
{"Entities":
[
{"Data":
{"AWS:Application":
{"Content":
[
{"Count": "3",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "4",
"PlatformType": "windows",
"Version": "6.2.8",
"Name": "microsoft office"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "1",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "2",
"PlatformType": "linux",
"Version": "6.3",
"Name": "authconfig"}
]
}
},
"ResourceType": "ManagedInstance"}
]
}
```
## Agrégation des données d'inventaire avec des groupes pour voir quels nœuds sont ou non configurés pour collecter un type d'inventaire
Dans Systems Manager Inventory, les groupes vous permettent de voir rapidement un décompte des nœuds gérés qui sont ou ne sont pas configurés pour collecter un ou plusieurs types d'inventaire. Avec les groupes, vous spécifiez un ou plusieurs types d'inventaire et un filtre qui utilise l'opérateur `exists`.
Par exemple, supposons que vous avez quatre nœuds gérés configurés pour collecter les types d'inventaire suivants :
+ Nœud 1 : `AWS:Application`
+ Nœud 2 : `AWS:File`
+ Nœud 3 : `AWS:Application`, `AWS:File`
+ Nœud 4 : `AWS:Network`
Vous pouvez exécuter la commande suivante à partir du AWS CLI pour voir combien de nœuds sont configurés pour collecter à la fois les `AWS:File inventory` types `AWS:Application` et. La réponse renvoie également un décompte des nœuds qui ne sont pas configurés pour collecter ces deux types d'inventaire.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
La réponse de la commande montre qu'un seul nœud géré est configuré pour collecter les deux types d'inventaire `AWS:Application` et `AWS:File`.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**Note**
Les groupes ne renvoient pas de décomptes de type de données. Vous ne pouvez pas non plus accéder aux résultats pour voir quels nœuds sont ou ne sont pas configurés pour collecter le type d'inventaire. IDs
Si vous préférez, vous pouvez créer une expression d'agrégation avec un ou plusieurs types d'inventaire dans un fichier JSON et appeler ce fichier à partir de l' AWS CLI. Le code JSON figurant dans le fichier doit utiliser la syntaxe suivante :
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Vous devez enregistrer le fichier avec l'extension de fichier .json.
Utilisez la commande suivante pour appeler le fichier à partir de l' AWS CLI.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**Exemples supplémentaires**
Les exemples suivants vous montrent comment agréger les données d'inventaire pour voir quels nœuds gérés sont ou non configurés pour collecter les types d'inventaire spécifiés. Ces exemples utilisent l' AWS CLI. Chaque exemple inclut une commande complète avec des filtres que vous pouvez exécuter à partir de la ligne de commande et un exemple de fichier input.json si vous préférez entrer les informations dans un fichier.
**Exemple 1**
Cet exemple regroupe un décompte des nœuds qui sont ou ne sont pas configurés pour collecter le type d'inventaire `AWS:Application` ou `AWS:File`.
Exécutez la commande suivante à partir de l' AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
Si vous préférez utiliser un fichier, copiez et collez l'exemple suivant dans un fichier et enregistrez-le sous le nom input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Exécutez la commande suivante à partir de l' AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
La commande renvoie des informations telles que les suivantes.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**Exemple 2**
Cet exemple regroupe un décompte des nœuds qui sont ou ne sont pas configurés pour collecter les types d'inventaire `AWS:Application`, `AWS:File` et `AWS:Network`.
Exécutez la commande suivante à partir de l' AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=Application,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists}]}, {Name=File,Filters=[{Key=TypeName,Values=[AWS:File],Type=Exists}]}, {Name=Network,Filters=[{Key=TypeName,Values=[AWS:Network],Type=Exists}]}]'
```
Si vous préférez utiliser un fichier, copiez et collez l'exemple suivant dans un fichier et enregistrez-le sous le nom input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Application",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application"
],
"Type":"Exists"
}
]
},
{
"Name":"File",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:File"
],
"Type":"Exists"
}
]
},
{
"Name":"Network",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Network"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Exécutez la commande suivante à partir de l' AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
La commande renvoie des informations telles que les suivantes.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# Utilisation de l'inventaire personnalisé
Vous pouvez attribuer les métadonnées de votre choix à vos nœuds en créant un AWS Systems Manager inventaire *personnalisé d'inventaire*. Par exemple, supposons que vous gériez un grand nombre de serveurs dans des racks dans votre centre de données et que ces serveurs ont été configurés en tant que nœuds gérés par Systems Manager. Vous stockez actuellement des informations sur l'emplacement des racks de serveurs dans une feuille de calcul. Avec un inventaire personnalisé, vous pouvez spécifier l'emplacement des racks de chaque nœud en tant que métadonnées du nœud. Lors de la collecte d'inventaire à l'aide de Systems Manager, ces métadonnées sont collectées avec les autres métadonnées d'inventaire. Vous pouvez ensuite transférer toutes les métadonnées d'inventaire vers un compartiment Amazon S3 central à l'aide de la [synchronisation de données de ressources](inventory-resource-data-sync.html) et interroger les données.
**Note**
Systems Manager prend en charge un maximum de 20 types d'inventaires personnalisés par Compte AWS.
Pour attribuer un inventaire personnalisé à un nœud, vous pouvez utiliser l'opération [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API Systems Manager, comme décrit dans[Attribution de métadonnées d’inventaire personnalisées à un nœud géré](inventory-custom-metadata.md). Sinon, vous pouvez créer un fichier JSON d'inventaire personnalisé et le charger sur le nœud. Cette section explique comment créer le fichier JSON.
L'exemple suivant de fichier JSON avec inventaire personnalisé spécifie les informations sur les racks concernant un serveur sur site. Cet exemple spécifie un type de données d'inventaire personnalisé (`"TypeName": "Custom:RackInformation"`), avec plusieurs entrées sous `Content` qui décrivent les données.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:RackInformation",
"Content": {
"Location": "US-EAST-02.CMH.RACK1",
"InstalledTime": "2016-01-01T01:01:01Z",
"vendor": "DELL",
"Zone" : "BJS12",
"TimeZone": "UTC-8"
}
}
```
Vous pouvez également spécifier des entrées distinctes dans la section `Content`, comme illustré dans l'exemple suivant.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
Le schéma JSON pour l'inventaire personnalisé nécessite les sections `SchemaVersion`, `TypeName` et `Content`, mais vous pouvez définir les informations dans ces sections.
```
{
"SchemaVersion": "user_defined",
"TypeName": "Custom:user_defined",
"Content": {
"user_defined_attribute1": "user_defined_value1",
"user_defined_attribute2": "user_defined_value2",
"user_defined_attribute3": "user_defined_value3",
"user_defined_attribute4": "user_defined_value4"
}
}
```
La valeur de `TypeName` est limitée à 100 caractères. La valeur `TypeName` doit également commencer par le mot `Custom` en majuscule. Par exemple, `Custom:PuppetModuleInfo`. Par conséquent, les exemples suivants entraîneraient une exception : `CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`.
La `Content` section inclut les attributs et*data*. Ces éléments ne sont pas sensibles à la casse. Par contre, si vous définissez un attribut (par exemple: « `Vendor` » : « DELL »), vous devez faire référence à cet attribut de manière cohérente dans vos fichiers d'inventaire personnalisés. Si vous spécifiez « `Vendor` » : « DELL » (avec un « F » majuscule dans `vendor`) dans un fichier, puis « `vendor` » : « DELL » (avec un « f » minuscule dans `vendor`) dans un autre fichier, le système renvoie une erreur.
**Note**
Vous devez enregistrer le fichier avec une extension `.json` et l’inventaire que vous définissez doit être composé uniquement de valeurs de chaîne.
Une fois le fichier créé, vous devez l'enregistrer sur le nœud. Le tableau suivant montre l'emplacement où les fichiers JSON d'inventaires personnalisés doivent être stockés sur le nœud.
****
| Système d'exploitation | Chemin |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventaire/personnalisé |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | % SystemDrive % \$1 ProgramData \$1 Amazon \$1 SSM \$1 \$1 InstanceData *node-id* \$1 inventaire \$1 personnalisé |
Pour obtenir un exemple d'utilisation de l'inventaire personnalisé, consultez [Obtention de l'utilisation des disques de votre flotte à l'aide des types d'inventaires personnalisés EC2 Systems Manager](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/).
## Suppression de l'inventaire personnalisé
Vous pouvez utiliser l'opération [DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html)API pour supprimer un type d'inventaire personnalisé et les données associées à ce type. Vous appelez la commande delete-inventory à l'aide de l' AWS Command Line Interface (AWS CLI) pour supprimer toutes les données d'un type d'inventaire. Vous appelez la commande delete-inventory avec l'option `SchemaDeleteOption` pour supprimer un type d'inventaire personnalisé.
**Note**
Un type d'inventaire est également appelé un schéma d'inventaire.
Le paramètre `SchemaDeleteOption` inclut les options suivantes :
+ **DeleteSchema**: Cette option supprime le type personnalisé spécifié et toutes les données qui lui sont associées. Vous pouvez recréer le schéma plus tard, si vous le souhaitez.
+ **DisableSchema**: Si vous choisissez cette option, le système désactive la version actuelle, supprime toutes les données correspondantes et ignore toutes les nouvelles données si la version est inférieure ou égale à la version désactivée. Vous pouvez autoriser à nouveau ce type d'inventaire en lançant l'[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)action correspondant à une version supérieure à la version désactivée.
**Pour supprimer ou désactiver l'inventaire personnalisé à l'aide du AWS CLI**
1. 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).
1. Exécutez la commande suivante pour utiliser l'option `dry-run` afin de voir quelles données seront supprimées du système. Cette commande ne supprime aucune donnée.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
Le système retourne des informations telles que les suivantes.
```
{
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
Pour plus d'informations sur la synthèse de la suppression d'inventaire, consultez [Comprendre la synthèse de la suppression d'inventaire](#delete-custom-inventory-summary).
1. Exécutez la commande suivante pour supprimer toutes les données d'un type inventaire personnalisé.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**Note**
La sortie de cette commande n'affiche pas la progression de la suppression. Pour cette raison, TotalCount le nombre restant est toujours le même, car le système n'a encore rien supprimé. Vous pouvez utiliser la describe-inventory-deletions commande pour afficher la progression de la suppression, comme décrit plus loin dans cette rubrique.
Le système retourne des informations telles que les suivantes.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"custom_type_name"
}
```
Le système supprime toutes les données du type d'inventaire personnalisé spécifié du service Systems Manager Inventory.
1. Exécutez la commande suivante. La commande effectue les actions suivantes pour la version actuelle du type d'inventaire : elle désactive la version actuelle, supprime toutes les données de celle-ci et ignore toutes les nouvelles données si la version est antérieure ou égale à la version désactivée.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
Le système retourne des informations telles que les suivantes.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
Vous pouvez consulter un type d'inventaire désactivé à l'aide de la commande suivante.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. Exécutez la commande suivante pour supprimer un type d'inventaire.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
Le système supprime le schéma et toutes les données d'inventaire du type personnalisé spécifié.
Le système retourne des informations telles que les suivantes.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
### Affichage du statut de suppression
Vous pouvez vérifier l'état d'une opération de suppression à l'aide de la `describe-inventory-deletions` AWS CLI commande. Vous pouvez spécifier un ID de suppression pour afficher le statut d'une opération de suppression spécifique. Sinon, vous pouvez omettre l'ID de suppression pour afficher la liste de toutes les suppressions exécutées au cours des 30 derniers jours.
****
1. Exécutez la commande suivante pour afficher le statut d'une opération de suppression. Le système a renvoyé l'ID de suppression dans la synthèse de suppression d'inventaire.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
Le système renvoie la statut le plus récent. L'opération de suppression peut ne pas être encore terminée. Le système retourne des informations telles que les suivantes.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 1,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 1,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "InProgress",
"LastStatusMessage": "The Delete is in progress",
"LastStatusUpdateTime": 1521744844,
"TypeName": "Custom:custom_type_name"}
]
}
```
Si l'opération de suppression est réussie, `LastStatusMessage` indique : Deletion is successful (Suppression réussie).
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"}
]
}
```
1. Exécutez la commande suivante pour afficher la liste de toutes les suppressions exécutées au cours des 30 derniers jours.
```
aws ssm describe-inventory-deletions --max-results a number
```
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521682552,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521682852,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521680145,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521680471,
"TypeName": "Custom:custom_type_name"}
],
"NextToken": "next-token"
```
### Comprendre la synthèse de la suppression d'inventaire
Pour vous aider à comprendre le contenu de la synthèse de la suppression d'inventaire, prenez l'exemple suivant. Un utilisateur a assigné un RackSpace inventaire personnalisé à trois nœuds. Les articles d'inventaire 1 et 2 utilisent le type personnalisé version 1.0 (» SchemaVersion « ="1.0"). L'article 3 de l'inventaire utilise le type personnalisé version 2.0 (» SchemaVersion « ="2.0").
RackSpace inventaire personnalisé 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace inventaire personnalisé 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace inventaire personnalisé 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
L'utilisateur exécute la commande suivante pour afficher un aperçu des données qui seront supprimées.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
Le système retourne des informations telles que les suivantes.
```
{
"DeletionId":"1111-2222-333-444-66666",
"DeletionSummary":{
"RemainingCount":3,
"TotalCount":3,
TotalCount and RemainingCount are the number of items that would be deleted if this was not a dry run. These numbers are the same because the system didn't delete anything.
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0. Neither item was deleted.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 1.0. This item was not deleted.
"RemainingCount":1,
"Version":"2.0"
}
],
},
"TypeName":"Custom:RackSpace"
}
```
L'utilisateur exécute la commande suivante pour supprimer le Custom : RackSpace inventory.
**Note**
La sortie de cette commande n'affiche pas la progression de la suppression. C'est pourquoi `TotalCount` et `RemainingCount` restent inchangés, car le système n'a encore rien supprimé. Vous pouvez utiliser la commande `describe-inventory-deletions` pour afficher la progression de la suppression.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
Le système retourne des informations telles que les suivantes.
```
{
"DeletionId":"1111-2222-333-444-7777777",
"DeletionSummary":{
"RemainingCount":3, There are three items to delete
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 2.0.
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"RackSpace"
}
```
### Afficher les actions de suppression de l'inventaire dans EventBridge
Vous pouvez configurer Amazon EventBridge pour créer un événement chaque fois qu'un utilisateur supprime un inventaire personnalisé. EventBridge propose trois types d'événements pour les opérations de suppression d'inventaire personnalisées :
+ **Delete action for an instance (Action de suppression pour une instance)** : événement créé si l'inventaire personnalisé pour un nœud géré spécifique a été correctement supprimé ou non.
+ **Delete action summary (Récapitulatif d'action de suppression)** : récapitulatif de l'action de suppression.
+ **Avertissement en cas de type d'inventaire personnalisé désactivé** : événement d'avertissement si un utilisateur a appelé l'opération d'[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API pour une version de type d'inventaire personnalisé précédemment désactivée.
Vous trouverez ci-dessous des exemples de chaque événement.
**Action de suppression pour une instance**
```
{
"version":"0",
"id":"998c9cde-56c0-b38b-707f-0411b3ff9d11",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:24:34Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0a5feb270fc3f0b97"
],
"detail":{
"action-status":"succeeded",
"action":"delete",
"resource-type":"managed-instance",
"resource-id":"i-0a5feb270fc3f0b97",
"action-reason":"",
"type-name":"Custom:MyInfo"
}
}
```
**Récapitulatif d'action de suppression**
```
{
"version":"0",
"id":"83898300-f576-5181-7a67-fb3e45e4fad4",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:28:25Z",
"region":"us-east-1",
"resources":[
],
"detail":{
"action-status":"succeeded",
"action":"delete-summary",
"resource-type":"managed-instance",
"resource-id":"",
"action-reason":"The delete for type name Custom:MyInfo was completed. The deletion summary is: {\"totalCount\":2,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.0\",\"count\":2,\"remainingCount\":0}]}",
"type-name":"Custom:MyInfo"
}
}
```
**Avertissement pour le type d'inventaire personnalisé désactivé**
```
{
"version":"0",
"id":"49c1855c-9c57-b5d7-8518-b64aeeef5e4a",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:46:58Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0ee2d86a2cfc371f6"
],
"detail":{
"action-status":"failed",
"action":"put",
"resource-type":"managed-instance",
"resource-id":"i-0ee2d86a2cfc371f6",
"action-reason":"The inventory item with type name Custom:MyInfo was sent with a disabled schema version 1.0. You must send a version greater than 1.0",
"type-name":"Custom:MyInfo"
}
}
```
Utilisez la procédure suivante pour créer une EventBridge règle pour les opérations de suppression d'inventaire personnalisées. Cette procédure vous montre comment créer une règle qui envoie des notifications à une rubrique Amazon SNS pour les opérations de suppression d'inventaire personnalisé. Avant de commencer, vérifiez que vous disposez d'une rubrique Amazon SNS, ou créez-en une nouvelle. Pour en savoir plus, consultez [Mise en route](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) dans le *Guide du développeur Amazon Simple Notification Service*.
**Pour configurer les opérations EventBridge de suppression de l'inventaire**
1. Ouvrez la EventBridge console Amazon à l'adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Dans le panneau de navigation, choisissez **Rules**.
1. Choisissez **Créer une règle**.
1. Saisissez un nom et une description pour la règle.
Une règle ne peut pas avoir le même nom qu'une autre règle de la même région et sur le même bus d'événement.
1. Pour **Event bus** (Bus d'événement), sélectionnez le bus d'événement que vous souhaitez associer à cette règle. Si vous souhaitez que cette règle réponde aux événements correspondants qui proviennent des vôtres Compte AWS, sélectionnez **par défaut**. Lorsqu'un événement Service AWS de votre compte est émis, il est toujours redirigé vers le bus d'événements par défaut de votre compte.
1. Pour **Type de règle**, choisissez **Règle avec un modèle d’événement**.
1. Choisissez **Suivant**.
1. Dans **Source de l'événement**, choisissez **AWS des événements ou des événements EventBridge partenaires**.
1. Dans la section **Event pattern** (Modèle d'événement), choisissez **Event pattern form** (Modèle d'événement).
1. Pour **Event source** (Origine de l'événement), choisissez **AWS services** (Services ).
1. Pour le **AWS service** choisissez **Systems Manager**.
1. Pour **Type d'événement**, sélectionnez **Inventory**.
1. Pour **Specific detail type(s)** (Type(s) spécifiques), choisissez **Inventory Resource State Change** (Changements d'état de la ressource Inventaire).
1. Choisissez **Suivant**.
1. Pour **Types de cibles**, choisissez **service AWS **.
1. Pour **Target** (Cible), sélectionnez **SNS topic** (Rubrique SNS), puis sélectionnez votre rubrique depuis la liste **Topic** (Rubrique).
1. Dans la section **Additional settings** (Réglages supplémentaires), pour **Configure target input** (Configurer l'entrée cible), vérifiez que **Matched event** (Événement jumelé) est sélectionné.
1. Choisissez **Suivant**.
1. (Facultatif) Saisissez une ou plusieurs balises pour la règle. Pour plus d'informations, consultez la section [Marquage de vos EventBridge ressources Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) dans le *guide de l' EventBridge utilisateur Amazon*.
1. Choisissez **Suivant**.
1. Consultez les détails de la règle et choisissez **Create rule** (Créer une règle).
# Affichage de l'historique d'inventaire et suivi des modifications
Vous pouvez consulter l'historique de l' AWS Systems Manager inventaire et le suivi des modifications pour tous vos nœuds gérés en utilisant [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/). AWS Config fournit une vue détaillée de la configuration des AWS ressources de votre Compte AWS. Elle indique comment les ressources sont liées entre elles et comment elles ont été configurées dans le passé, pour que vous puissiez observer comment les configurations et les relations changent au fil du temps. Pour afficher l'historique d'inventaire et le suivi des modifications, vous devez activer les ressources suivantes dans AWS Config :
+ SMS : ManagedInstanceInventory
+ SMS : PatchCompliance
+ SMS : AssociationCompliance
+ SMS : FileData
**Note**
Veuillez noter les informations suivantes, qui sont importantes pour l'historique Inventory et le suivi des modifications :
Si vous avez l' AWS Config habitude de suivre les modifications apportées à votre système, vous devez configurer Systems Manager Inventory pour collecter `AWS:File` des métadonnées afin de pouvoir visualiser les modifications apportées aux fichiers dans AWS Config (`SSM:FileData`). Si ce n'est pas le cas, alors AWS Config ne suit pas les modifications apportées aux fichiers sur votre système.
En activant SSM : PatchCompliance et SSM :AssociationCompliance, vous pouvez consulter les Patch Manager correctifs de Systems Manager, l'historique de conformité des State Manager associations de Systems Manager et le suivi des modifications. Pour plus d'informations sur la gestion de la conformité pour ces ressources, consultez [En savoir plus sur la conformité](compliance-about.md).
La procédure suivante décrit comment activer l'historique des stocks et modifier l'enregistrement des pistes à AWS Config l'aide du AWS Command Line Interface ()AWS CLI. Pour plus d'informations sur la manière de choisir et de configurer ces ressources dans AWS Config, consultez la section [Sélection des ressources AWS Config enregistrées](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) dans le *guide du AWS Config développeur*. Pour plus d'informations sur la tarification AWS Config , consultez [Tarification ](https://aws.amazon.com/config/pricing/).
**Avant de commencer**
AWS Config nécessite des autorisations Gestion des identités et des accès AWS (IAM) pour obtenir des informations de configuration sur les ressources de Systems Manager. Dans la procédure suivante, vous devez spécifier un Amazon Resource Name (ARN) pour un rôle IAM qui AWS Config autorise les ressources de Systems Manager. Vous pouvez attacher la politique gérée `AWS_ConfigRole` au rôle IAM que vous attribuez à AWS Config. Pour plus d'informations sur ce rôle, consultez la section [AWS managed policy : AWS\$1 ConfigRole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole) dans le *manuel du AWS Config développeur*. Pour savoir comment créer un rôle IAM et attribuer la politique gérée `AWS_ConfigRole` à ce rôle, reportez-vous à [Création d'un rôle pour déléguer des autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l'utilisateur IAM*.
**Pour activer l'historique des stocks et modifier l'enregistrement des pistes dans AWS Config**
1. 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).
1. Copiez et collez l'exemple JSON suivant dans un fichier texte simple et enregistrez-le sous le nom recordingGroup.json.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. Exécutez la commande suivante pour charger le fichier recordingGroup.json dans AWS Config.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. Exécutez la commande suivante pour commencer l'enregistrement de l'historique d'inventaire et du suivi des modifications.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
Une fois l'historique et le suivi des modifications configurés, vous pouvez explorer en détail l'historique pour rechercher un nœud géré spécifique en sélectionnant le bouton **AWS Config** dans la console Systems Manager. Vous pouvez accéder au bouton **AWS Config** à partir de la page **Managed Instances** (Instances gérées) ou de la page **Inventory** (Inventaire). En fonction de la taille de votre moniteur, vous devrez peut-être faire défiler l'affichage vers le côté droit de la page pour voir le bouton.
# Arrêt de la collecte des données et suppression des données d'inventaire
Si vous ne souhaitez plus utiliser l' AWS Systems Manager inventaire pour afficher les métadonnées relatives à vos AWS ressources, vous pouvez arrêter la collecte de données et supprimer les données déjà collectées. Cette section comprend les informations suivantes.
**Topics**
+ [Arrêt de la collecte des données](#systems-manager-inventory-delete-association)
+ [Suppression d'une synchronisation de données de ressources Inventory](#systems-manager-inventory-delete-RDS)
## Arrêt de la collecte des données
Lorsque System Manager est configuré initialement pour collecter des données d'inventaires, le système crée uneState Manager association définissant la planification ainsi que les ressources à partir desquelles les métadonnées seront collectées. Vous pouvez arrêter la collecte de données en supprimant des associations State Manager qui utilisent le document `AWS-GatherSoftwareInventory`.
**Pour supprimer une association Inventory**
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**.
1. Sélectionnez une association qui utilise le document `AWS-GatherSoftwareInventory`, puis sélectionnez **Supprimer**.
1. Répétez l'étape trois pour toutes les autres associations qui utilisent le document `AWS-GatherSoftwareInventory`.
## Suppression d'une synchronisation de données de ressources Inventory
Si vous ne souhaitez plus utiliser l' AWS Systems Manager inventaire pour afficher les métadonnées relatives à vos AWS ressources, nous vous recommandons également de supprimer les synchronisations des données de ressources utilisées pour la collecte des données d'inventaire.
**Pour supprimer une synchronisation de données de ressources Inventory**
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 volet de navigation, sélectionnez **Inventory**.
1. Sélectionnez **Resource Data Syncs (Synchronisations des données de ressource)**.
1. Dans la liste, sélectionnez une synchronisation.
**Important**
Veillez à bien choisir la synchronisation utilisée pour Inventory. Systems Manager prend en charge la synchronisation de données de ressources pour plusieurs outils. Si vous choisissez la mauvaise synchronisation, vous risquez de perturber l'agrégation des données pour Systems Manager Explorer ou Systems Manager Compliance.
1. Choisissez **Delete** (Supprimer)
1. Répétez ces étapes pour les autres synchronisations de données de ressources à supprimer.
1. Supprimez le compartiment Amazon Simple Storage Service (Amazon S3) dans lequel les données ont été enregistrées. Pour obtenir des informations sur la suppression d'un compartiment Amazon S3, veuillez consulter [Deleting a bucket (Suppression d'un compartiment)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Attribution de métadonnées d’inventaire personnalisées à un nœud géré
La procédure suivante explique comment utiliser l'opération d' AWS Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API pour attribuer des métadonnées d'inventaire personnalisées à un nœud géré. Cet exemple attribue les informations sur les emplacements des racks à un nœud. Pour plus d'informations sur l'inventaire personnalisé, consultez [Utilisation de l'inventaire personnalisé](inventory-custom.md).
**Pour affecter des métadonnées d'inventaire personnalisé à un nœud**
1. 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).
1. Exécutez la commande suivante pour affecter les informations de localisation de rack à un nœud.
**Linux**
```
aws ssm put-inventory --instance-id "ID" --items '[{"CaptureTime": "2016-08-22T10:01:01Z", "TypeName": "Custom:RackInfo", "Content":[{"RackLocation": "Bay B/Row C/Rack D/Shelf E"}], "SchemaVersion": "1.0"}]'
```
**Windows**
```
aws ssm put-inventory --instance-id "ID" --items "TypeName=Custom:RackInfo,SchemaVersion=1.0,CaptureTime=2021-05-22T10:01:01Z,Content=[{RackLocation='Bay B/Row C/Rack D/Shelf F'}]"
```
1. Exécutez la commande suivante pour afficher les entrées de l'inventaire personnalisé de ce nœud.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
Le système répond en renvoyant des informations similaires à celles qui suivent.
```
{
"InstanceId": "ID",
"TypeName": "Custom:RackInfo",
"Entries": [
{
"RackLocation": "Bay B/Row C/Rack D/Shelf E"
}
],
"SchemaVersion": "1.0",
"CaptureTime": "2016-08-22T10:01:01Z"
}
```
1. Exécutez la commande suivante pour afficher le schéma d'inventaire personnalisé.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
Le système répond en renvoyant des informations similaires à celles qui suivent.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# Utilisation du AWS CLI pour configurer la collecte des données d'inventaire
Les procédures suivantes vous guident tout au long du processus de configuration de l'inventaire AWS Systems Manager pour collecter les métadonnées de vos nœuds gérés. Lorsque vous configurez la collecte de données d'inventaire, vous commencez par créer une association Systems Manager State Manager. Systems Manager collecte les données d'inventaire lorsque l'association est exécutée. Si vous ne créez pas l'association en premier et essayez d'appeler le plug-in `aws:softwareInventory` en utilisant, par exemple, la fonctionnalité Systems Manager Run Command, le système renvoie l'erreur suivante :
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**Note**
Un nœud ne peut avoir qu'une association d'inventaire configurée en même temps. Si vous configurez un nœud avec deux associations d'inventaire ou plus, l'association n'est pas exécutée et aucune donnée d'inventaire n'est collectée.
## Configuration rapide de toutes vos nœuds gérés pour l'inventaire (CLI)
Vous pouvez configurer rapidement tous les nœuds gérés de votre région Compte AWS et de la région actuelle pour collecter des données d'inventaire. C'est ce qu'on appelle la création d'une association d'inventaire global. Pour créer une association d'inventaire globale à l' AWS CLI aide de l'option générique pour la `instanceIds` valeur, comme indiqué dans la procédure suivante.
**Pour configurer l'inventaire de tous les nœuds gérés dans votre région Compte AWS et dans la région actuelle (CLI)**
1. 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).
1. Exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=* \
--schedule-expression "rate(1 day)" \
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name AWS-GatherSoftwareInventory ^
--targets Key=InstanceIds,Values=* ^
--schedule-expression "rate(1 day)" ^
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
**Note**
Cette commande n'autorise pas Inventory à collecter des métadonnées pour le registre Windows ou les fichiers. Pour effectuer l'inventaire de ces types de données, utilisez la procédure suivante.
## Configuration manuelle de l'inventaire sur vos nœuds gérés (CLI)
Utilisez la procédure suivante pour configurer manuellement l' AWS Systems Manager inventaire sur vos nœuds gérés à l'aide de nœuds IDs ou de balises.
**Pour configurer manuellement vos nœuds gérés pour l'inventaire (CLI)**
1. 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).
1. Exécutez la commande suivante pour créer une association State Manager qui exécute Systems Manager Inventory sur le nœud. Remplacez chaque *example resource placeholder* par vos propres informations. Cette commande configure le service pour qu'il s'exécute toutes les six heures et qu'il collecte les métadonnées de configuration du réseau, de Windows Update et des applications à partir d'un nœud.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=an_instance_ID" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=an_instance_ID" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
Le système répond en renvoyant des informations similaires à celles qui suivent.
```
{
"AssociationDescription": {
"ScheduleExpression": "rate(240 minutes)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "Test",
"OutputS3BucketName": "Test bucket",
"OutputS3Region": "us-east-2"
}
},
"Name": "The name you specified",
"Parameters": {
"applications": [
"Enabled"
],
"networkConfig": [
"Enabled"
],
"windowsUpdates": [
"Enabled"
]
},
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1480544990.06,
"Date": 1480544990.06,
"Targets": [
{
"Values": [
"i-02573cafcfEXAMPLE"
],
"Key": "InstanceIds"
}
]
}
}
```
Vous pouvez cibler de grands groupes de nœuds en utilisant le paramètre `Targets` avec les balises EC2. Consultez l'exemple suivant.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=tag:Environment,Values=Production" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=tag:Environment,Values=Production" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
Vous pouvez également inventorier des fichiers et des clés de registre Windows sur un nœud Windows Server en utilisant les types d'inventaire `files` et `windowsRegistry` avec des expressions. Pour plus d'informations sur ces types d'inventaire, consultez [Utilisation de l'inventaire de fichiers et du registre Windows](inventory-file-and-registry.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" \
--schedule-expression "rate(240 minutes)" \
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' \
--profile dev-pdx
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" ^
--schedule-expression "rate(240 minutes)" ^
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' ^
--profile dev-pdx
```
------
1. Exécutez la commande suivante pour afficher le statut de l'association.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
Le système répond en renvoyant des informations similaires à celles qui suivent.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire
La procédure pas à pas suivante décrit comment créer une configuration de synchronisation des données de ressources pour AWS Systems Manager Inventory à l'aide de AWS Command Line Interface (AWS CLI). Une synchronisation de données de ressources transfère automatiquement les données d'inventaire collectées depuis tous vos nœuds gérés vers un compartiment Amazon Simple Storage Service (Amazon S3) central. La synchronisation met automatiquement à jour les données dans le compartiment Amazon S3 central lors de la découverte de nouvelles données d'inventaire.
Cette procédure pas à pas décrit également comment utiliser Amazon Athena et Amazon Quick pour interroger et analyser les données agrégées. Pour plus d'informations sur la création d'une synchronisation des données de ressources à l'aide de Systems Manager dans le AWS Management Console, voir[Démonstration : utilisation de la synchronisation de données de ressources pour regrouper les données d’inventaire](#inventory-resource-data-sync). Pour plus d'informations sur l'interrogation de l'inventaire à partir de plusieurs comptes Régions AWS et à l'aide de Systems Manager dans le AWS Management Console, voir[Interrogation des données d'inventaire à partir de plusieurs régions et comptes](systems-manager-inventory-query.md).
**Note**
Cette procédure pas à pas comporte des informations sur la façon de chiffrer la synchronisation avec AWS Key Management Service (AWS KMS). Comme l'inventaire ne collecte aucune donnée spécifique à l'utilisateur, propriétaire ou sensible, le chiffrement est facultatif. Pour plus d'informations à ce sujet AWS KMS, consultez le [Guide AWS Key Management Service du développeur](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Avant de commencer**
Vérifiez ou effectuez les tâches suivantes avant de commencer la démonstration de cette section :
+ Collectez les données d'inventaire de vos nœuds gérés. Dans le cadre des sections Amazon Athena et Amazon Quick de cette procédure pas à pas, nous vous recommandons de collecter les données de l'application. Pour plus d'informations sur la façon de collecter des données d'inventaire, consultez [Configuration de la collecte d'inventaire](inventory-collection.md) ou [Utilisation du AWS CLI pour configurer la collecte des données d'inventaire](inventory-collection-cli.md).
+ (Facultatif) Si les données d'inventaire sont stockées dans un bucket Amazon Simple Storage Service (Amazon S3) qui AWS Key Management Service utilise le chiffrement AWS KMS(), vous devez également configurer votre compte IAM et `Amazon-GlueServiceRoleForSSM` le rôle de service pour le chiffrement. AWS KMS Si vous ne configurez pas votre compte IAM et ce rôle, Systems Manager affiche `Cannot load Glue tables` lorsque vous sélectionnez l'onglet **Vue détaillée** sur la console. Pour de plus amples informations, veuillez consulter [(Facultatif) Configurer les autorisations d'affichage des données AWS KMS chiffrées](systems-manager-inventory-query.md#systems-manager-inventory-query-kms).
+ (Facultatif) Si vous souhaitez chiffrer la synchronisation des données des ressources en utilisant AWS KMS, vous devez soit créer une nouvelle clé incluant la politique suivante, soit mettre à jour une clé existante et y ajouter cette politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ssm-access-policy",
"Statement": [
{
"Sid": "ssm-access-policy-statement",
"Action": [
"kms:GenerateDataKey"
],
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
"Condition": {
"StringLike": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:123456789012:resource-data-sync/*"
}
}
}
]
}
```
------
**Pour créer une synchronisation des données de ressource pour l'inventaire**
1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Créez un compartiment pour stocker vos données d'inventaire agrégées. Pour de plus amples informations, consultez la section [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans le *Guide de l’utilisateur d’Amazon Simple Storage Service*. Notez le nom du bucket et l' Région AWS endroit où vous l'avez créé.
1. Après avoir créé le compartiment, sélectionnez l'onglet **Autorisations**, puis sélectionnez **Politique de compartiment**.
1. Copiez et collez la politique de compartiment suivante dans l'éditeur de politique. Remplacez amzn-s3-demo-bucket par le *account-id* nom du compartiment Amazon S3 que vous avez créé et un identifiant valide. Compte AWS Si vous ajoutez plusieurs comptes, ajoutez une chaîne de conditions et un ARN supplémentaires pour chaque compte. Supprimez les espaces réservés supplémentaires de l'exemple lors de l'ajout d'un compte. Vous pouvez éventuellement le *bucket-prefix* remplacer par le nom d'un préfixe Amazon S3 (sous-répertoire). Si vous n'avez pas créé de préfixe, supprimez-le *bucket-prefix/* de l'ARN dans la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=111122223333/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": [
"111122223333",
"444455556666",
"123456789012",
"777788889999"
]
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:ssm:*:111122223333:resource-data-sync/*",
"arn:aws:ssm:*:444455556666:resource-data-sync/*",
"arn:aws:ssm:*:123456789012:resource-data-sync/*",
"arn:aws:ssm:*:777788889999:resource-data-sync/*"
]
}
}
}
]
}
```
------
1. (Facultatif) Si vous souhaitez chiffrer la synchronisation, vous devez ajouter les conditions suivantes à la politique définie dans l’étape précédente. Ajoutez les dans la section `StringEquals`.
```
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
```
Voici un exemple :
```
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "account-id",
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
}
```
1. 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).
1. (Facultatif) Si vous souhaitez chiffrer la synchronisation, exécutez la commande suivante pour vérifier que la politique de compartiment applique les exigences relatives aux AWS KMS clés. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ \
--sse aws:kms \
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" \
--region region, for example, us-east-2
```
------
#### [ Windows ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ ^
--sse aws:kms ^
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" ^
--region region, for example, us-east-2
```
------
1. Exécutez la commande suivante pour créer une configuration de synchronisation de données de ressource avec le compartiment Amazon S3 que vous avez créé au début de cette procédure. Cette commande crée une synchronisation à partir du compte auquel Région AWS vous êtes connecté.
**Note**
Si la synchronisation et le compartiment Amazon S3 cible sont localisés dans des régions différentes, vous pourriez être sujet à une tarification de transfert de données. Pour plus d'informations, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name a_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name a_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
Vous pouvez utiliser le paramètre `region` pour spécifier l'emplacement dans lequel la configuration de synchronisation doit être créée. Dans l'exemple suivant, les données d'inventaire de la région us-west-1 seront synchronisées dans le compartiment Amazon S3 de la région us-west-2.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name InventoryDataWest \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2"
--region us-west-1
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name InventoryDataWest ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2" ^ --region us-west-1
```
------
(Facultatif) Si vous souhaitez chiffrer la synchronisation à l'aide de AWS KMS, exécutez la commande suivante pour créer la synchronisation. Si vous chiffrez la synchronisation, la AWS KMS clé et le compartiment Amazon S3 doivent se trouver dans la même région.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name sync_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" \
--region region
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name sync_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" ^
--region region
```
------
1. Exécutez la commande suivante pour afficher le statut de la configuration de synchronisation.
```
aws ssm list-resource-data-sync
```
Si vous avez créé la configuration de synchronisation dans une autre région, vous devez spécifier le paramètre `region`, comme illustré dans l'exemple suivant.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. Une fois la configuration de synchronisation créée, examinez le compartiment cible dans Amazon S3. Les données d'inventaire doivent apparaître en quelques minutes.
**Utilisation des données dans Amazon Athena**
La section suivante décrit comment afficher et interroger les données dans Amazon Athena. Avant de commencer, nous vous recommandons de vous familiariser avec Athena. Pour de plus amples informations, consultez [Qu'est-ce que Amazon Athena ?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) et [Utilisation des données](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html) dans le *Guide de l'utilisateur d'Amazon Athena*.
**Pour afficher et interroger les données dans Amazon Athena**
1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).
1. Copiez et collez la déclaration suivante dans l'éditeur de requête, puis sélectionnez **Exécuter la requête**.
```
CREATE DATABASE ssminventory
```
Le système crée une base de données nommée ssminventory.
1. Copiez et collez la déclaration suivante dans l'éditeur de requête, puis sélectionnez **Exécuter la requête**. Remplacez amzn-s3-demo-bucket par le nom et le préfixe *bucket\$1prefix* de la cible Amazon S3.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Application (
Name string,
ResourceId string,
ApplicationType string,
Publisher string,
Version string,
InstalledTime string,
Architecture string,
URL string,
Summary string,
PackageId string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket_prefix/AWS:Application/'
```
1. Copiez et collez la déclaration suivante dans l'éditeur de requête, puis sélectionnez **Exécuter la requête**.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
Le système effectue le partitionnement de la table.
**Note**
Si vous créez des synchronisations de données de ressources à partir de ressources supplémentaires Régions AWS ou Comptes AWS, vous devez exécuter cette commande à nouveau pour mettre à jour les partitions. Il est probable que vous deviez également mettre à jour votre politique de compartiment Amazon S3.
1. Pour prévisualiser vos données, sélectionnez l'icône Aperçu située à côté de la table `AWS_Application`.
![\[L'icône de prévisualisation des données dans Amazon Athena.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. Copiez et collez la déclaration suivante dans l'éditeur de requête, puis sélectionnez **Exécuter la requête**.
```
SELECT a.name, a.version, count( a.version) frequency
from aws_application a where
a.name = 'aws-cfn-bootstrap'
group by a.name, a.version
order by frequency desc
```
La requête renvoie le nombre de versions différentes de`aws-cfn-bootstrap`, qui est une AWS application présente sur les instances Amazon Elastic Compute Cloud (Amazon EC2) pour LinuxmacOS, et. Windows Server
1. **Copiez et collez individuellement les instructions suivantes dans l'éditeur de requêtes, remplacez amzn-s3-demo-bucket par des informations *bucket-prefix* pour Amazon S3, puis choisissez Run Query.** Ces déclarations définissent des tables d'inventaire supplémentaires dans Athena.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_AWSComponent (
`ResourceId` string,
`Name` string,
`ApplicationType` string,
`Publisher` string,
`Version` string,
`InstalledTime` string,
`Architecture` string,
`URL` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:AWSComponent/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_AWSComponent
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_WindowsUpdate (
`ResourceId` string,
`HotFixId` string,
`Description` string,
`InstalledTime` string,
`InstalledBy` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:WindowsUpdate/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_WindowsUpdate
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_InstanceInformation (
`AgentType` string,
`AgentVersion` string,
`ComputerName` string,
`IamRole` string,
`InstanceId` string,
`IpAddress` string,
`PlatformName` string,
`PlatformType` string,
`PlatformVersion` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:InstanceInformation/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_InstanceInformation
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Network (
`ResourceId` string,
`Name` string,
`SubnetMask` string,
`Gateway` string,
`DHCPServer` string,
`DNSServer` string,
`MacAddress` string,
`IPV4` string,
`IPV6` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:Network/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_Network
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_PatchSummary (
`ResourceId` string,
`PatchGroup` string,
`BaselineId` string,
`SnapshotId` string,
`OwnerInformation` string,
`InstalledCount` int,
`InstalledOtherCount` int,
`NotApplicableCount` int,
`MissingCount` int,
`FailedCount` int,
`OperationType` string,
`OperationStartTime` string,
`OperationEndTime` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:PatchSummary/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_PatchSummary
```
**Utilisation des données dans Amazon Quick**
La section suivante fournit une vue d'ensemble avec des liens permettant de créer une visualisation dans Amazon Quick.
**Pour créer une visualisation dans Amazon Quick**
1. Inscrivez-vous à [Amazon Quick](https://quicksight.aws/), puis connectez-vous à la console Quick.
1. Créez un ensemble de données depuis la table `AWS_Application` et toute autre table que vous avez créée. Pour plus d'informations, consultez la section [Création d'un ensemble de données à l'aide des données Amazon Athena](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html) dans le manuel *Amazon Quick User Guide*.
1. Joignez les tables. Par exemple, vous pouvez joindre la colonne `instanceid` depuis `AWS_InstanceInformation` car elle correspond à la colonne `resourceid` dans d'autres tables d'inventaire. Pour plus d'informations sur la jointure de tables, consultez la section [Joindre des données](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html) dans le manuel *Amazon Quick User Guide*.
1. Créez une visualisation. Pour plus d'informations, consultez la section [Analyses et rapports : visualisation des données dans Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html) dans le manuel *Amazon Quick User Guide*.
# Résolution des problèmes liés à Systems Manager Inventory
Cette rubrique contient des informations sur la manière de résoudre les erreurs ou problèmes courants liés à AWS Systems Manager l'inventaire. Si vous avez des difficultés à consulter vos nœuds dans Systems Manager, consultez [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md).
**Topics**
+ [Erreur « Multtiple apply all associations with document '`AWS-GatherSoftwareInventory`' are not supported »](#systems-manager-inventory-troubleshooting-multiple)
+ [Inventory ne quitte jamais le statut d'exécution « En attente »](#inventory-troubleshooting-pending)
+ [Le document `AWS-ListWindowsInventory` ne s'exécute pas](#inventory-troubleshooting-ListWindowsInventory)
+ [La console n'affiche pas les éléments Tableau de bord d'inventaire \$1 Vue détaillée \$1 onglets Paramètres](#inventory-troubleshooting-tabs)
+ [UnsupportedAgent](#inventory-troubleshooting-unsupported-agent)
+ [Ignoré](#inventory-troubleshooting-skipped)
+ [Échec](#inventory-troubleshooting-failed)
+ [Échec de conformité de l'inventaire pour une instance Amazon EC2](#inventory-troubleshooting-ec2-compliance)
+ [L'objet du compartiment S3 contient d'anciennes données](#systems-manager-inventory-troubleshooting-s3)
## Erreur « Multtiple apply all associations with document '`AWS-GatherSoftwareInventory`' are not supported »
L'erreur `Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported` signifie qu'une ou plusieurs Régions AWS dans lesquelles vous tentez de configurer une association Inventory *pour tous les nœuds* sont déjà configurées avec une association Inventory pour tous les nœuds. Si nécessaire, vous pouvez supprimer l'association Inventory existante pour tous les nœuds, puis en créer une nouvelle. Pour consulter les associations Inventory existantes, sélectionnez **State Manager** dans la console Systems Manager, puis recherchez les associations qui utilisent le document SSM `AWS-GatherSoftwareInventory`. Si l'association Inventory existante pour tous les nœuds a été créée dans plusieurs régions et que vous voulez en créer une nouvelle, vous devez supprimer l'association existante dans chaque région où elle est présente.
## Inventory ne quitte jamais le statut d'exécution « En attente »
Deux raisons prévalent au fait que la collecte de données d'inventaire ne quitte jamais le statut `Pending`.
+ Aucun nœud dans la zone sélectionnée Région AWS :
Si vous créez une association Inventory globale avec Systems Manager Quick Setup, le statut de l'association Inventory (document `AWS-GatherSoftwareInventory`) affiche `Pending` s'il n'y a aucun nœud disponible dans la région sélectionnée.****
+ Autorisations insuffisantes :
Une association Inventory affiche `Pending` si un ou plusieurs nœuds n'ont pas l'autorisation d'exécuter Systems Manager Inventory. Vérifiez que le profil d'instance Gestion des identités et des accès AWS (IAM) inclut la politique SSMManaged InstanceCore gérée par **Amazon**. Pour obtenir des informations sur l'ajout de cette politique à un profil d'instance, veuillez consulter [Configuration alternative pour les autorisations d’instance EC2](setup-instance-permissions.md#instance-profile-add-permissions).
Le profil d'instance doit disposer au moins des autorisations IAM suivantes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
]
}
```
------
## Le document `AWS-ListWindowsInventory` ne s'exécute pas
Le document `AWS-ListWindowsInventory` est obsolète. N'utilisez pas ce document pour collecter l'inventaire. Utilisez plutôt l'un des processus décrits dans [Configuration de la collecte d'inventaire](inventory-collection.md).
## La console n'affiche pas les éléments Tableau de bord d'inventaire \$1 Vue détaillée \$1 onglets Paramètres
La page **Detailed View (Vue détaillée)** de l'inventaire est uniquement disponible dans les Régions AWS qui proposent Amazon Athena. Si les onglets suivants ne sont pas affichés sur la page Inventory, cela signifie qu'Athena n'est pas disponible dans la région et que vous ne pouvez pas utiliser la **Detailed View (Vue détaillée)** pour interroger les données.
![\[Affichage du tableau de bord de l'inventaire | Vue détaillée | Onglets Paramètres\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
Si le statut détaillé d'une association d'inventaire s'affiche **UnsupportedAgent**et que le **statut de l'association** indique **Échec**, la version de AWS Systems Manager SSM Agent sur le nœud géré n'est pas correcte. Pour créer une association d'inventaire globale (pour inventorier tous les nœuds de votre Compte AWS), par exemple, vous devez utiliser la SSM Agent version 2.0.790.0 ou ultérieure. Vous pouvez consulter la version de l'agent en cours d'exécution sur chacune de vos nœuds sur la page **Managed Instances (Instances gérées)** dans la colonne **Agent version (Version d'agent)**. Pour plus d'informations sur la mise à jour de l'SSM Agent sur vos nœuds, consultez [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
## Ignoré
Si le statut de l’association d’inventaire pour un nœud indique **Ignoré**, cela signifie qu’une association d’inventaire de priorité supérieure est déjà en cours d’exécution sur ce nœud. Systems Manager suit un ordre de priorité spécifique lorsque plusieurs associations d’inventaire peuvent s’appliquer au même nœud géré.
### Ordre de priorité d’association d’inventaire
Systems Manager applique les associations d’inventaire dans l’ordre de priorité suivant :
1. **Associations d’inventaire Quick Setup** : associations créées avec Quick Setup et la console unifiée. Ces associations ont des noms commençant par `AWS-QuickSetup-SSM-CollectInventory-` et ciblent tous les nœuds gérés.
1. **Associations d’inventaire explicites** : associations qui ciblent des nœuds gérés spécifiques en utilisant :
+ Instance IDs
+ Paires clé-valeur de balise
+ AWS groupes de ressources
1. **Associations d’inventaire globales** : associations qui ciblent tous les nœuds gérés (avec `--targets "Key=InstanceIds,Values=*"`) mais qui n’ont **pas** été créées via Quick Setup.
### Scénarios courants
**Scénario 1 : l’association Quick Setup remplace l’association explicite**
+ Vous avez une association d’inventaire Quick Setup ciblant toutes les instances
+ Vous créez une association manuelle ciblant des nœuds gérés spécifiques par balise
+ Résultat : l’association manuelle affiche `Skipped` avec un statut détaillé `OverriddenByExplicitInventoryAssociation`
+ L’association Quick Setup continue de collecter l’inventaire de toutes les instances
**Scénario 2 : l’association explicite remplace l’association globale**
+ Vous avez une association d’inventaire globale ciblant toutes les instances (non créée par Quick Setup)
+ Vous créez une association ciblant des instances spécifiques
+ Résultat : l’association globale affiche `Skipped` pour les instances spécifiquement ciblées
+ L’association explicite s’exécute sur les instances ciblées
### Étapes de résolution
**Si vous souhaitez utiliser votre propre association d’inventaire au lieu de Quick Setup :**
1. **Identifier les associations Quick Setup** : dans la console Systems Manager, accédez à State Manager et recherchez les associations dont les noms commencent par `AWS-QuickSetup-SSM-CollectInventory-`.
1. **Supprimer la configuration Quick Setup** :
+ Accédez à Quick Setup dans la console Systems Manager.
+ Trouvez votre configuration de collecte d’inventaire.
+ Supprimez la configuration Quick Setup (cela supprime l’association d’inventaire associée).
**Note**
Vous n’avez pas besoin de supprimer manuellement l’association créée par Quick Setup.
1. **Vérifiez que votre association fonctionne** : après avoir supprimé la configuration Quick Setup, votre association d’inventaire explicite devrait commencer à fonctionner correctement.
**Si vous souhaitez modifier un comportement existant :**
+ Pour consulter toutes les associations Inventory existantes, sélectionnez **State Manager** dans la console Systems Manager, puis recherchez les associations qui utilisent le document SSM `AWS-GatherSoftwareInventory`.
+ N’oubliez pas que chaque nœud géré ne peut avoir qu’une seule association d’inventaire active à la fois.
**Important**
Les données d’inventaire sont toujours collectées à partir des nœuds ignorés lorsque l’association d’inventaire qui leur est attribuée (de priorité plus élevée) est exécutée.
Les associations d’inventaire Quick Setup ont priorité sur tous les autres types, même celles dont le ciblage est explicite.
Le message de statut détaillé `OverriddenByExplicitInventoryAssociation` s’affiche lorsqu’une association est remplacée par une association de priorité plus élevée, quel que soit le type d’association.
## Échec
Si le statut de l'association d'inventaire pour un nœud indique **Failed (Échec)**, cela peut signifier que plusieurs plusieurs associations d'inventaire lui sont affectées. Une seule association d'inventaire peut être attribuée à un nœud à la fois. Une association d'inventaire utilise le `AWS-GatherSoftwareInventory` AWS Systems Manager document (document SSM). Vous pouvez exécuter la commande suivante en utilisant le AWS Command Line Interface (AWS CLI) pour afficher la liste des associations associées à un nœud.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Échec de conformité de l'inventaire pour une instance Amazon EC2
L'échec de la conformité de l'inventaire pour une instance Amazon Elastic Compute Cloud (Amazon EC2) est possible si vous attribuez plusieurs associations d'inventaire à l'instance.
Pour résoudre ce problème, passez à la suppression d'une ou plusieurs associations d'inventaire attribuées à l'instance. Pour de plus amples informations, consultez [Création d'une association](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
**Note**
Vous devez connaître le comportement suivant en cas de création d'associations d'inventaire multiples pour un nœud géré.
Chaque nœud peut se voir attribuer une association d'inventaire qui cible *tous les* nœuds (--targets « Key=InstanceIds, Values=\$1 »).
Chaque nœud peut également se voir attribuer une association spécifique qui utilise soit des paires clé-valeur de balise, soit un groupe de AWS ressources.
Si plusieurs associations d'inventaire sont affectées à un nœud, l'association qui ne s'est pas exécutée présente le statut *Skipped (Ignoré)*. L'association qui s'est exécutée la plus récemment affiche le statut réel de l'association d'inventaire.
Si un nœud est doté de plusieurs associations d'inventaire et utilise une paire clé-valeur de balise, le conflit de balises empêche l'exécution de ces associations d'inventaire sur le nœud. L'association s'exécute normalement sur les nœuds exempts du conflit clé-valeur de balise.
## L'objet du compartiment S3 contient d'anciennes données
Les données contenues dans l'objet du compartiment Amazon S3 sont mises à jour lorsque l'association d'inventaire est réussie et que de nouvelles données sont découvertes. L'objet du compartiment Amazon S3 est mis à jour pour chaque nœud lorsque l'association s'exécute et échoue, mais les données contenues dans l'objet ne sont pas mises à jour dans ce cas. Les données contenues dans l'objet du compartiment Amazon S3 ne seront mises à jour que lorsque l'association s'exécutera correctement. Lorsque l'association d'inventaire échoue, vous verrez d'anciennes données dans l'objet du compartiment Amazon S3.
# 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`.
# AWS Systems Manager Run Command
À l'aide Run Command d'un outil AWS Systems Manager, vous pouvez gérer à distance et en toute sécurité la configuration de vos nœuds gérés. Un *nœud géré* est une instance Amazon Elastic Compute Cloud (Amazon EC2) ou une instance non EC2 machine de votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) qui a été configurée pour Systems Manager. Run Commandvous permet d'automatiser les tâches administratives courantes et d'effectuer des modifications de configuration ponctuelles à grande échelle. Vous pouvez utiliser Run Command from the AWS Management Console, AWS Command Line Interface the (AWS CLI) ou le AWS SDKs. AWS Tools for Windows PowerShellRun Commandest offert sans frais supplémentaires. Pour vos premiers pas dans Run Command, ouvrez [Systems Manager console](https://console.aws.amazon.com//systems-manager/run-command). Dans le panneau de navigation, sélectionnez **Run Command**.
Les administrateurs ont recours à la fonctionnalité Run Command pour installer ou amorcer des applications, créer un pipeline de déploiement, capturer des fichiers journaux lorsqu'une instance est mise hors service à partir d'un groupe Auto Scaling, joindre des instances à un domaine Windows et bien plus.
L’API Run Command suit un modèle de cohérence à terme en raison de la nature distribuée du système de support de l’API. Cela signifie que le résultat d’une commande API que vous exécutez et qui affecte vos ressources peut ne pas être immédiatement visible par toutes les commandes ultérieures que vous exécutez. Vous devez garder cela à l’esprit lorsque vous exécutez une commande API qui suit immédiatement une commande API précédente.
**Démarrage**
Le tableau suivant comporte des informations pour vous aider à vous familiariser avec Run Command.
****
| Rubrique | Détails |
| --- | --- |
| [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md) | Vérifiez que vous avez satisfait aux exigences de configuration pour vos instances Amazon Elastic Compute Cloud (Amazon EC2) et celles qui ne sont pas EC2 des machines dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). |
| [Gestion des nœuds dans les environnements hybrides et multicloud avec Systems Manager](systems-manager-hybrid-multicloud.md) | (Facultatif) Enregistrez les serveurs locaux et VMs avec lesquels vous AWS pourrez les gérer à l'aide Run Command de. |
| [Gestion des appareils de périphérie avec Systems Manager](systems-manager-setting-up-edge-devices.md) | (Facultatif) Configurez les appareils de périphérie pour pouvoir les gérer à l'aide de Run Command. |
| [Exécution de commandes sur des nœuds gérés](running-commands.md) | Découvrez comment exécuter une commande ciblant un ou plusieurs nœuds gérés à l'aide de la AWS Management Console. |
| [Procédures Run Command](run-command-walkthroughs.md) | Apprenez à exécuter des commandes à l'aide des outils pour Windows PowerShell ou du AWS CLI. |
**EventBridge soutien**
Cet outil Systems Manager est pris en charge à la fois en tant que type d'*événement* et en tant que type de *cible* dans EventBridge les règles Amazon. Pour plus d’informations, consultez [Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md) et [Référence : modèles et types d' EventBridge événements Amazon pour Systems Manager](reference-eventbridge-events.md).
**Plus d'informations**
+ [À distance Run Command sur une EC2 instance (didacticiel de 10 minutes)](https://aws.amazon.com/getting-started/hands-on/remotely-run-commands-ec2-instance-systems-manager/)
+ [Service Quotas Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#limits_ssm) de la *Référence générale d'Amazon Web Services*
+ [AWS Systems Manager API Reference](https://docs.aws.amazon.com/systems-manager/latest/APIReference/)
**Topics**
+ [Configuration de Run Command](run-command-setting-up.md)
+ [Exécution de commandes sur des nœuds gérés](running-commands.md)
+ [Utilisation des codes de sortie dans les commandes](run-command-handle-exit-status.md)
+ [Comprendre les états des commandes](monitor-commands.md)
+ [Procédures Run Command](run-command-walkthroughs.md)
+ [Résolution des problèmes liés à Run Command de Systems Manager](troubleshooting-remote-commands.md)
# Configuration de Run Command
Avant de pouvoir gérer les nœuds à l'aide Run Command d'un outil AWS Systems Manager, configurez une politique Gestion des identités et des accès AWS (IAM) pour tout utilisateur qui exécutera des commandes. Si vous utilisez des clés de condition globales pour l’action `SendCommand` dans vos politiques IAM, vous devez inclure la clé de condition `aws:ViaAWSService` et définir la valeur booléenne sur `true`. Voici un exemple.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": [
"vpce-1234567890abcdef0"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
Vous devez également configurer vos nœuds pour Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
Nous vous recommandons d'effectuer les tâches de configuration facultatives suivantes afin de minimiser le niveau de sécurité et la day-to-day gestion de vos nœuds gérés.
Surveillez les exécutions de commandes à l'aide d'Amazon EventBridge
Vous pouvez l'utiliser EventBridge pour enregistrer les modifications de l'état d'exécution des commandes. Vous pouvez créer une règle qui s'exécute à chaque changement de statut ou lorsqu'un ou plusieurs statuts spécifiques sont activés. Vous pouvez également spécifier Run Command comme action cible lorsqu'un EventBridge événement se produit. Pour de plus amples informations, veuillez consulter [Configuration EventBridge pour les événements de Systems Manager](monitoring-systems-manager-events.md).
Surveillez les exécutions de commandes à l'aide d'Amazon CloudWatch Logs
Vous pouvez configurer Run Command pour envoyer régulièrement toutes les sorties de commande et tous les journaux d'erreurs à un groupe de CloudWatch journaux Amazon. Vous pouvez surveiller ces journaux de sortie quasiment en temps réel, rechercher des phrases, valeurs ou modèles spécifiques, et créer des alarmes en fonction de la recherche. Pour de plus amples informations, veuillez consulter [Configuration d'Amazon CloudWatch Logs pour Run Command](sysman-rc-setting-up-cwlogs.md).
Restriction de l'accès Run Command à des nœuds gérés spécifiques
Vous pouvez limiter la capacité d'un utilisateur à exécuter des commandes sur des nœuds gérés en utilisant Gestion des identités et des accès AWS (IAM). Plus précisément, vous pouvez créer une politique IAM avec une condition selon laquelle l'utilisateur ne peut exécuter de commandes que sur les nœuds gérés présentant des balises spécifiques. Pour de plus amples informations, veuillez consulter [Restriction de l'accès Run Command en fonction des balises](#tag-based-access).
## Restriction de l'accès Run Command en fonction des balises
Cette section explique comment restreindre la capacité d'un utilisateur à exécuter des commandes sur des nœuds gérés en spécifiant une condition de balise dans une politique IAM. Les nœuds gérés incluent EC2 les instances Amazon et EC2 les non-nœuds d'un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) configurés pour Systems Manager. Bien que les informations ne soient pas présentées de manière explicite, vous pouvez également restreindre l'accès aux AWS IoT Greengrass principaux appareils gérés. Pour commencer, vous devez baliser vos appareils AWS IoT Greengrass . Pour plus d'informations, consultez [Baliser vos ressources AWS IoT Greengrass Version 2](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) dans le *Guide du développeur AWS IoT Greengrass Version 2 *.
Vous pouvez restreindre l'exécution de commandes à des nœuds gérés spécifiques en créant une politique IAM qui comporte une condition selon laquelle l'utilisateur ne peut exécuter de commandes que sur les nœuds comportant des balises spécifiques. Dans l'exemple suivant, l'utilisateur est autorisé à utiliser Run Command (`Effect: Allow, Action: ssm:SendCommand`) en utilisant n'importe quel document SSM (`Resource: arn:aws:ssm:*:*:document/*`) sur n'importe quel nœud (`Resource: arn:aws:ec2:*:*:instance/*`) à condition que le nœud soit un Finance WebServer (`ssm:resourceTag/Finance: WebServer`). Si l'utilisateur envoie une commande à un nœud non balisé ou qui possède une balise autre que `Finance: WebServer`, les résultats d'exécution indiquent `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:*:*:document/*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ec2:*:*:instance/*"
],
"Condition":{
"StringLike":{
"ssm:resourceTag/Finance":[
"WebServers"
]
}
}
}
]
}
```
------
Vous pouvez créer des politiques IAM qui permettent à un utilisateur d'exécuter des commandes sur des nœuds gérés balisés à l'aide de plusieurs balises. La politique suivante permet à l'utilisateur d'exécuter des commandes sur des nœuds gérés dotés de deux balises. Si un utilisateur envoie une commande à un nœud non balisé à l'aide de ces deux balises, les résultats d'exécution indiquent `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
],
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
Vous pouvez également créer des politiques IAM qui permettent à un utilisateur d'exécuter des commandes sur plusieurs groupes de nœuds gérés balisés. L'exemple de politique suivante permet à l'utilisateur d'exécuter des commandes sur un des deux groupes de nœuds balisés, ou les deux.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
Pour plus d'informations sur la création de politiques IAM, consultez [Politiques gérées et politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) dans le *Guide de l'utilisateur IAM*. Pour plus d'informations sur le balisage des nœuds gérés, consultez [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) dans le *Guide de l'utilisateur Groupes de ressources AWS *.
# Exécution de commandes sur des nœuds gérés
Cette section comprend des informations sur le mode d'envoi de commandes depuis la console AWS Systems Manager vers des nœuds gérés. Cette section inclut également des informations sur l'annulation d'une commande.
Notez que si votre nœud est configuré avec l’option de montage `noexec` pour le répertoire var, Run Command ne pourra pas exécuter correctement les commandes.
**Important**
Lorsque vous envoyez une commande à l'aide de Run Command, n'incluez pas d'informations sensibles formatées en texte brut, comme des mots de passe, des données de configuration ou d'autres secrets. Toutes les activités de l'API Systems Manager sur votre compte sont enregistrées dans un compartiment S3 pour les AWS CloudTrail journaux. Cela signifie que tout utilisateur ayant accès à ce compartiment S3 peut consulter les valeurs en texte brut de ces secrets. Pour cette raison, nous vous recommandons de créer et d'utiliser des paramètres `SecureString` pour chiffrer les données sensibles que vous utilisez dans le cadre de vos opérations Systems Manager.
Pour de plus amples informations, veuillez consulter [Restriction de l'accès aux paramètres Parameter Store à l'aide des stratégies IAM](sysman-paramstore-access.md).
**Conservation de l'historique d'exécution**
L'historique de chaque commande est disponible pour une durée maximale de 30 jours. En outre, vous pouvez stocker une copie de tous les fichiers journaux dans Amazon Simple Storage Service ou disposer d’un journal de suivi d’audit de tous les appels d’API dans AWS CloudTrail.
**Informations connexes**
Pour plus d’informations sur l’envoi de commandes avec d’autres outils, consultez les rubriques suivantes :
+ [Procédure pas à pas : utilisez le AWS Tools for Windows PowerShell avec Run Command](walkthrough-powershell.md)ou les exemples présentés dans la [AWS Systems Manager section de la référence des Outils AWS pour PowerShell applets](https://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Systems_Manager_cmdlets.html) de commande.
+ [Procédure pas à pas : utilisez le AWS CLI avec Run Command](walkthrough-cli.md) ou les exemples de la [Référence de la CLI SSM](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
**Topics**
+ [Exécution des commande à partir de la console](running-commands-console.md)
+ [Exécution de commandes à l'aide d'une version de document spécifique](run-command-version.md)
+ [Exécuter des commandes à grande échelle](send-commands-multiple.md)
+ [Annulation d'une commande](cancel-run-command.md)
# Exécution des commande à partir de la console
Vous pouvez utiliser Run Command un outil dans AWS Systems Manager, depuis le AWS Management Console pour configurer les nœuds gérés sans avoir à vous y connecter. Cette rubrique comprend un exemple qui montre comment [mettre à jour SSM Agent](run-command-tutorial-update-software.md#rc-console-agentexample) sur un nœud géré à l'aide de la fonctionnalité Run Command.
**Avant de commencer**
Avant d'envoyer une commande avec Run Command, vérifiez que vos nœuds gérés respectent la [configuration requise](systems-manager-setting-up-nodes.md) de Systems Manager.
**Pour envoyer une commande à l'aide de la fonctionnalité Run Command**
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 **Run Command (Exécuter la commande)**.
1. Dans la liste **Command document (Document de commande)**, sélectionnez un document Systems Manager.
1. Dans la section **Command parameters (Paramètres de la commande)**, indiquez des valeurs pour les paramètres requis.
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
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. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Choisissez une CloudWatch alarme à appliquer à votre commande de surveillance. Pour associer une CloudWatch alarme à votre commande, le principal IAM qui exécute la commande doit être autorisé à effectuer l'`iam:createServiceLinkedRole`action. Pour plus d'informations sur les CloudWatch alarmes, consultez la section [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Notez que l'activation de votre alarme empêche l'exécution des appels de commande en attente.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**Note**
Les autorisations S3 qui permettent d'écrire les données dans un compartiment S3 sont celles du profil d'instance (pour les EC2 instances) ou du rôle de service IAM (machines activées de manière hybride) attribué à l'instance, et non celles de l'utilisateur IAM effectuant 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, assurez-vous 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. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Cliquez sur **Exécuter**.
Pour plus d'informations sur l'annulation d'une commande, consultez [Annulation d'une commande](cancel-run-command.md).
## Réexécution des commandes
Systems Manager comprend deux options pour vous aider à réexécuter une commande à partir de la page **Run Command** (Exécuter la commande) de la console Systems Manager.
+ **Réexécuter** : ce bouton vous permet d'exécuter la même commande sans y apporter de modifications.
+ **Copier vers nouveau** : ce bouton copie les paramètres d'une commande dans une nouvelle commande et vous donne la possibilité de modifier ces paramètres avant de l'exécuter.
**Pour réexécuter une commande**
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 une commande à réexécuter. Vous pouvez réexécuter une commande immédiatement après l'avoir exécutée à partir de la page de détails de la commande. Vous pouvez également choisir une commande que vous avez précédemment exécutée dans l'onglet **Command history (Historique des commandes)**.
1. Sélectionnez **Réexécuter** pour exécuter la même commande sans modifications, ou sélectionnez **Copier vers nouveau** pour modifier les paramètres de la commande avant de l'exécuter.
# Exécution de commandes à l'aide d'une version de document spécifique
Vous pouvez utiliser le paramètre document-version pour spécifier la version d'un document AWS Systems Manager à utiliser lors de l'exécution de la commande. Vous pouvez spécifier l'une des options suivantes pour ce paramètre :
+ \$1DEFAULT
+ \$1LATEST
+ Version number
Appliquez la procédure suivante pour exécuter une commande à l'aide du paramètre document-version.
------
#### [ Linux ]
**Pour exécuter des commandes AWS CLI à l'aide du**
1. 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).
1. Répertorier tous les documents disponibles
Cette commande répertorie tous les documents disponibles pour votre compte en fonction des autorisations Gestion des identités et des accès AWS (IAM).
```
aws ssm list-documents
```
1. Utilisez la commande suivante pour afficher les différentes versions d'un document. Remplacez *document name* par vos propres informations.
```
aws ssm list-document-versions \
--name "document name"
```
1. Exécutez la commande suivante pour exécuter une commande qui utilise une version de document SSM. Remplacez chaque *example resource placeholder* par vos propres informations.
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters commands="echo Hello" \
--instance-ids instance-ID \
--document-version '$LATEST'
```
------
#### [ Windows ]
**Pour exécuter des commandes à l'aide AWS CLI des machines Windows locales**
1. 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).
1. Répertorier tous les documents disponibles
Cette commande répertorie tous les documents disponibles pour votre compte en fonction des autorisations Gestion des identités et des accès AWS (IAM).
```
aws ssm list-documents
```
1. Utilisez la commande suivante pour afficher les différentes versions d'un document. Remplacez *document name* par vos propres informations.
```
aws ssm list-document-versions ^
--name "document name"
```
1. Exécutez la commande suivante pour exécuter une commande qui utilise une version de document SSM. Remplacez chaque *example resource placeholder* par vos propres informations.
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--parameters commands="echo Hello" ^
--instance-ids instance-ID ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
**Pour exécuter des commandes à l'aide des outils pour PowerShell**
1. Installez et configurez les Outils AWS pour PowerShell (Outils pour Windows PowerShell), si ce n'est pas déjà fait.
Pour plus d'informations, consultez [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Répertorier tous les documents disponibles
Cette commande répertorie tous les documents disponibles pour votre compte en fonction des autorisations Gestion des identités et des accès AWS (IAM).
```
Get-SSMDocumentList
```
1. Utilisez la commande suivante pour afficher les différentes versions d'un document. Remplacez *document name* par vos propres informations.
```
Get-SSMDocumentVersionList `
-Name "document name"
```
1. Exécutez la commande suivante pour exécuter une commande qui utilise une version de document SSM. Remplacez chaque *example resource placeholder* par vos propres informations.
```
Send-SSMCommand `
-DocumentName "AWS-RunShellScript" `
-Parameter @{commands = "echo helloWorld"} `
-InstanceIds "instance-ID" `
-DocumentVersion $LATEST
```
------
# Exécuter des commandes à grande échelle
Vous pouvez utiliser Run Command un outil dans AWS Systems Manager, pour exécuter des commandes sur un parc de nœuds gérés en utilisant le`targets`. Le paramètre `targets` accepte une combinaison `Key,Value` basée sur les balises que vous avez spécifiées pour vos nœuds gérés. Lorsque vous exécutez la commande, le système recherche les fichiers et tente d'exécuter la commande sur tous les nœuds gérés qui correspondent aux balises spécifiées. Pour plus d'informations sur le balisage des instances gérées, consultez la section [Marquage de vos AWS ressources dans le Guide de l'utilisateur des AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) *ressources de balisage*. Pour plus d'informations sur le balisage de vos appareils IoT gérés, consultez la section [Marquer vos AWS IoT Greengrass Version 2 ressources](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) dans le *guide du AWS IoT Greengrass Version 2 développeur*.
Vous pouvez également utiliser le `targets` paramètre pour cibler une liste de nœuds gérés spécifiques IDs, comme décrit dans la section suivante.
Pour contrôler l'exécution d'une commande sur des centaines de milliers de nœuds gérés, la fonctionnalité Run Command inclut également des paramètres pour limiter le nombre de nœuds gérés pouvant traiter simultanément une demande et le nombre d'erreurs pouvant être émises par une commande avant que la commande ne prenne fin.
**Topics**
+ [Ciblage de plusieurs nœuds gérés](#send-commands-targeting)
+ [Utilisation des contrôles de taux](#send-commands-rate)
## Ciblage de plusieurs nœuds gérés
Vous pouvez exécuter une commande et cibler les nœuds gérés en spécifiant des balises, AWS des noms de groupes de ressources ou des nœuds gérés IDs.
Les exemples suivants montrent le format de commande lors Run Command de l'utilisation de from the AWS Command Line Interface (AWS CLI ). Remplacez chaque *example resource placeholder* par vos propres informations. Les exemples de commandes de cette section sont tronqués à l'aide de `[...]`.
**Exemple 1 : ciblage de balises**
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:tag-name,Values=tag-value \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:tag-name,Values=tag-value ^
[...]
```
------
**Exemple 2 : Cibler un groupe de AWS ressources par son nom**
Vous pouvez spécifier au maximum un nom de groupe de ressources par commande. Lorsque vous créez un groupe de ressources, nous vous recommandons d'inclure `AWS::SSM:ManagedInstance` et `AWS::EC2::Instance` comme types de ressource dans vos critères de regroupement.
**Note**
Pour envoyer des commandes qui ciblent un groupe de ressources, vous devez avoir obtenu des autorisations Gestion des identités et des accès AWS (IAM) pour répertorier ou afficher les ressources appartenant à ce groupe. Pour plus d'informations, consultez [Configuration d'autorisations](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) dans le *Guide de l'utilisateur Groupes de ressources AWS *.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:Name,Values=resource-group-name \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:Name,Values=resource-group-name ^
[...]
```
------
**Exemple 3 : Cibler un groupe de AWS ressources par type de ressource**
Vous pouvez spécifier au maximum cinq types de groupe de ressources par commande. Lorsque vous créez un groupe de ressources, nous vous recommandons d'inclure `AWS::SSM:ManagedInstance` et `AWS::EC2::Instance` comme types de ressource dans vos critères de regroupement.
**Note**
Pour pouvoir envoyer des commandes qui ciblent un groupe de ressources, vous devez avoir reçu des autorisations IAM pour répertorier, ou afficher, les ressources qui appartiennent à ce groupe. Pour plus d'informations, consultez [Configuration d'autorisations](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) dans le *Guide de l'utilisateur Groupes de ressources AWS *.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 ^
[...]
```
------
**Exemple 4 : instance de ciblage IDs**
Les exemples suivants montrent comment cibler les nœuds gérés à l'aide de la clé `instanceids` avec le paramètre `targets`. Vous pouvez utiliser cette clé pour cibler les AWS IoT Greengrass principaux appareils gérés, car un mi- est attribué à chaque appareil*ID\$1number*. Vous pouvez voir un appareil IDs dansFleet Manager, un outil dans AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 ^
[...]
```
------
Si vous avez balisé des nœuds gérés pour différents environnements à l'aide d'une `Key` nommée `Environment` et des `Values` de `Development`, `Test`, `Pre-production` et `Production`, vous pourrez donc envoyer une commande à tous les nœuds gérés dans *l'un* de ces environnements à l'aide du paramètre `targets` avec la syntaxe suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
------
Vous pouvez cibler des nœuds gérés supplémentaires dans d'autres environnements en ajoutant un élément à la liste `Values`. Séparez les éléments avec des virgules.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development,Test,Pre-production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development,Test,Pre-production ^
[...]
```
------
**Variation** : affiner vos cibles à l'aide de plusieurs critères `Key`
Vous pouvez affiner le nombre de cibles pour votre commande en incluant plusieurs critères `Key`. Si vous incluez plusieurs critères `Key`, le système cible les nœuds gérés qui répondent à *tous* les critères. La commande suivante cible tous les nœuds gérés balisés pour le service financier *et* balisés pour le rôle de serveur de base de données.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database ^
[...]
```
------
**Variation** : utilisation de plusieurs critères `Key` et `Value`
En reprenant l'exemple précédent, vous pouvez cibler plusieurs services et plusieurs rôles de serveur en incluant des éléments supplémentaires dans les critères `Values`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
**Variation** : ciblage de nœuds gérés balisés à l'aide de plusieurs critères `Values`
Si vous avez balisé des nœuds gérés pour différents environnements à l'aide d'une `Key` nommée `Department` et `Values` de `Sales` et `Finance`, vous pouvez envoyer une commande à tous les nœuds gérés dans l'un de ces environnements à l'aide du paramètre `targets` avec la syntaxe suivante.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Sales,Finance \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Sales,Finance ^
[...]
```
------
Vous pouvez spécifier un maximum de cinq clés et cinq valeurs pour chaque clé.
Si une clé de balise (le nom de la balise) ou une valeur de balise inclut des espaces, placez la clé ou la valeur de balise entre guillemets, comme illustré dans les exemples suivants.
**Exemple** : espaces dans la balise `Value`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:OS,Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:OS,Values="Windows Server 2016" ^
[...]
```
------
**Exemple** : espaces dans la clé `tag` et dans `Value`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key="tag:Operating System",Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key="tag:Operating System",Values="Windows Server 2016" ^
[...]
```
------
**Exemple** : espaces dans un élément d'une liste de `Values`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" ^
[...]
```
------
## Utilisation des contrôles de taux
Vous pouvez contrôler le taux d'envoi des commandes aux nœuds gérés d'un groupe à l'aide des* contrôles de concurrence* et des *contrôles d'erreur*.
**Topics**
+ [Utilisation de contrôles d'accès simultanés](#send-commands-velocity)
+ [Utilisation de contrôles d'erreur](#send-commands-maxerrors)
### Utilisation de contrôles d'accès simultanés
Le contrôle de nombre de nœuds gérés exécutant une commande simultanément est possible à l'aide du `max-concurrency` paramètre des options ( **Simultanéité** de la page **Exécuter une commande ** ). Vous pouvez spécifier un nombre absolu de nœuds géré, par exemple, **10**, ou un pourcentage de l'ensemble de la cible, par exemple, **10%**. Le système de mise en file d'attente transmet la commande à un seul nœud et attend jusqu'à ce que le système reconnaisse l'appel initial avant d'envoyer la commande à deux autres nœuds. Le système envoie de façon exponentielle des commandes à plusieurs nœuds jusqu'à ce que la valeur `max-concurrency` soit atteinte. La valeur par défaut de `max-concurrency` est 50. Les exemples suivants vous montrent comment spécifier des valeurs pour le paramètre `max-concurrency` :
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10 \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10% \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10 ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10% ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
### Utilisation de contrôles d'erreur
Vous pouvez également contrôler l'exécution d'une commande sur des centaines ou des milliers de nœuds gérés en définissant une limite d'erreurs à l'aide des paramètres `max-errors` (champ **Error threshold (Seuil d'erreur)** de la page **Exécuter une commande**). Le paramètre spécifie le nombre d'erreurs autorisées avant que le système cesse d'envoyer la commande d'autres nœuds gérés. Vous pouvez spécifier un nombre absolu d'erreurs (par exemple, **10**) ou un pourcentage de l'ensemble de la cible (par exemple, **10%**). Si, par exemple, vous spécifiez **3**, le système cesse d'envoyer la commande à la réception de la quatrième erreur. Si vous spécifiez **0**, le système cesse d'envoyer la commande à des nœuds gérés supplémentaires une fois que le premier résultat d'erreur est renvoyé. Si vous envoyez une commande à 50 nœuds gérés et que vous définissez `max-errors` avec la valeur **10%**, le système arrête d'envoyer la commande aux nœuds gérés supplémentaires à la réception de la sixième erreur.
Les appels qui exécutent déjà une commande lorsque `max-errors` est atteint sont autorisés à se terminer, mais certains de ces appels pourraient également échouer. Si vous devez vous assurer que le nombre d'appels ayant échoué ne dépassera pas la valeur de `max-errors`, définissez `max-concurrency` sur **1** pour que les appels soit exécutés un par un. La valeur par défaut pour max-errors est 0. Les exemples suivants vous montrent comment spécifier des valeurs pour le paramètre `max-errors` :
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-errors 10 \
--targets Key=tag:Database,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-errors 10% \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 1 \
--max-errors 1 \
--targets Key=tag:Environment,Values=Production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10 ^
--targets Key=tag:Database,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10% ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 1 ^
--max-errors 1 ^
--targets Key=tag:Environment,Values=Production ^
[...]
```
------
# Annulation d'une commande
Vous pouvez tenter d'annuler une commande tant que le service est associé à l'état Pending (En attente) ou Executing (En cours d'exécution). Toutefois, même si une commande est encore associée à l'un de ces états, nous ne pouvons pas garantir qu'elle sera annulée et que le processus sous-jacent sera arrêté.
**Pour annuler une commande via la 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 l'appel de commande que vous souhaitez annuler.
1. Sélectionnez **Annuler la commande**.
**Pour annuler une commande à l'aide de l'AWS CLI**
Exécutez la commande suivante. Remplacez chaque *example resource placeholder* (espace réservé pour les ressources) avec vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm cancel-command \
--command-id "command-ID" \
--instance-ids "instance-ID"
```
------
#### [ Windows ]
```
aws ssm cancel-command ^
--command-id "command-ID" ^
--instance-ids "instance-ID"
```
------
Pour de plus amples informations sur le statut d'une commande annulée, veuillez consulter [Comprendre les états des commandes](monitor-commands.md).
# Utilisation des codes de sortie dans les commandes
Dans certains cas, vous devrez peut-être gérer la façon dont vos commandes sont gérées à l'aide de codes de sortie.
## Spécifier les codes de sortie dans les commandes
À l’aide de Run Command, un outil d’AWS Systems Manager, vous pouvez spécifier des codes de sortie pour déterminer la manière dont les commandes sont gérées. Par défaut, le code de sortie de la dernière commande exécutée dans un script est signalé comme le code de sortie pour l'ensemble du script. Par exemple, prenons un script qui contient trois commandes. La première échoue, mais les suivantes sont réalisées avec succès. Compte tenu du succès de la commande finale, l'état de l'exécution est signalé comme `succeeded`.
**Scripts shell**
Pour faire échouer la totalité du script lors du premier échec de la commande, vous pouvez inclure une instruction conditionnelle shell pour quitter le script si une commande précédant la dernière échoue. Utilisez pas l'approche suivante.
```
if [ $? != 0 ]
then
exit
fi
```
Dans l'exemple suivant, la totalité du script échoue si la première commande échoue.
```
cd /test
if [ $? != 0 ]
then
echo "Failed"
exit 1
fi
date
```
**Scripts PowerShell**
PowerShell exige que vous appeliez explicitement `exit` dans vos scripts pour que Run Command capture correctement le code de sortie.
```
if ($?) {}
else {exit }
exit
```
Voici un exemple :
```
cd C:\
if ($?) {echo "Success"}
else {exit 1}
date
```
# Gestion des redémarrages lors de l'exécution de commandes
Si vous utilisez Run Command un outil pour exécuter des AWS Systems Manager scripts qui redémarrent des nœuds gérés, nous vous recommandons de spécifier un code de sortie dans votre script. Si vous essayez de redémarrer un nœud à partir d'un script à l'aide d'un autre mécanisme, l'état d'exécution des scripts peut ne pas être mis à jour correctement, même si le redémarrage est la dernière étape dans votre script. Pour les nœuds gérés Windows, spécifiez `exit 3010` dans votre script. Pour les nœuds gérés Linux et macOS, spécifiez `exit 194`. Le code de sortie indique à AWS Systems Manager l'agent (SSM Agent) de redémarrer le nœud géré, puis de redémarrer le script une fois le redémarrage terminé. Avant de commencer le redémarrage, SSM Agent informe le service Systems Manager dans le cloud que les communications seront interrompues pendant le redémarrage du serveur.
**Note**
Le script de redémarrage ne peut pas faire partie d'un plugin `aws:runDocument`. Si un document contient le script de redémarrage et qu'un autre document tente d'exécuter ce document via le plugin `aws:runDocument`, SSM Agent renvoie une erreur.
**Création de scripts idempotents**
Lorsque vous développez des scripts qui redémarrent les nœuds gérés, rendez les scripts idempotents de sorte que l'exécution du script continue là où elle s'était arrêtée après le redémarrage. Les scripts idempotents gèrent l'état et valident si l'action a été exécutée ou non. Cela permet d'éviter qu'une étape soit exécutée plusieurs fois alors qu'elle est destinée à être exécutée une seule fois.
Voici un exemple de script idempotent qui redémarre le nœud géré plusieurs fois.
```
$name = Get current computer name
If ($name –ne $desiredName)
{
Rename computer
exit 3010
}
$domain = Get current domain name
If ($domain –ne $desiredDomain)
{
Join domain
exit 3010
}
If (desired package not installed)
{
Install package
exit 3010
}
```
**Exemples**
Les échantillons de script suivants utilisent des codes de sortie pour redémarrer les nœuds gérés. L'exemple sur Linux installe les mises à jour de package sur Amazon Linux, puis redémarre le nœud. L’exemple Windows Server installe l’application Telnet-Client au niveau du nœud, puis le redémarre.
------
#### [ Amazon Linux 2 ]
```
#!/bin/bash
yum -y update
needs-restarting -r
if [ $? -eq 1 ]
then
exit 194
else
exit 0
fi
```
------
#### [ Windows ]
```
$telnet = Get-WindowsFeature -Name Telnet-Client
if (-not $telnet.Installed)
{
# Install Telnet and then send a reboot request to SSM Agent.
Install-WindowsFeature -Name "Telnet-Client"
exit 3010
}
```
------
# Comprendre les états des commandes
Run Command, un outil dans AWS Systems Manager, fournit des informations d'état détaillées sur les différents états rencontrés par une commande pendant le traitement et pour chaque nœud géré qui a traité la commande. Vous pouvez surveiller les statuts de commande à l'aide des méthodes suivantes :
+ Cliquez sur l'icône **Refresh** (Actualiser) dans l'onglet **Commands** (Commandes) de l'interface de la console Run Command.
+ Appelez [les commandes de liste](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) ou [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html)utilisez le AWS Command Line Interface ()AWS CLI. Ou appelez [Get- SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) ou [Get- SSMCommand Invocation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html) en utilisant AWS Tools for Windows PowerShell.
+ Configurez Amazon EventBridge pour qu'il réponde à un état ou à un changement de statut.
+ Configurez Amazon Simple Notification Service (Amazon SNS) de sorte à envoyer des notifications pour tous les changements de statut ou pour des statuts spécifiques, comme `Failed` ou `TimedOut`.
## État Run Command
La fonctionnalité Run Command génère des rapports avec des détails de statut pour trois domaines : plug-ins, appels et statut de commande général. Un *plug-in* est un bloc d'exécution de code qui est défini dans le document SSM de votre commande. Pour de plus amples informations sur les plug-ins, consultez [Référence de plug-in de document Command](documents-command-ssm-plugin-reference.md).
Lorsque vous envoyez une commande à plusieurs nœuds gérés en même temps, chaque copie de la commande qui cible chaque nœud correspond à une *invocation de commande*. Par exemple, si vous utilisez le document `AWS-RunShellScript` et que vous envoyez une commande `ifconfig` à 20 instances Linux, cette commande aura 20 appels. Chaque invocation de commande signale le statut individuellement. Les plug-ins d'une invocation de commande donné communiquent aussi le statut individuellement.
Enfin, la fonctionnalité Run Command inclut un statut de commande regroupé pour tous les plug-ins et les appels. Le statut de commande regroupé peut être différent du statut signalé par plug-ins ou appels, comme indiqué dans les tableaux suivants.
**Note**
Si vous exécutez des commandes sur un grand nombre de nœuds gérés à l'aide des paramètres `max-concurrency` ou `max-errors`, le statut de commande reflète les limites imposées par ces paramètres, comme décrit dans les tableaux suivants. Pour obtenir plus d'informations sur ces paramètres, consultez [Exécuter des commandes à grande échelle](send-commands-multiple.md).
**Statut détaillé pour des plug-ins et des appels de commande**
| Statut | Détails |
| --- | --- |
| En attente | La commande n'a pas encore été envoyée au nœud géré ou n'a pas été reçue par l'SSM Agent. Si la commande n'est pas reçue par l'agent avant le délai prévu, qui est égal à la somme du paramètre Timeout (seconds) (Délai d'expiration (secondes)) et le paramètre Execution timeout (Délai d'exécution), le statut passe à Delivery Timed Out. |
| InProgress | Systems Manager tente d'envoyer la commande au nœud géré, ou la commande a été reçue par l'SSM Agent et a commencé à s'exécuter sur l'instance. Selon le résultat de tous les plug-ins de commande, le statut passe à Success, Failed, Delivery Timed Out ou Execution Timed Out. Exception : si l'agent n'est pas en cours d'exécution ou n'est pas disponible sur le nœud, le statut de la commande reste sur In Progress jusqu'à ce que l'agent soit à nouveau disponible ou que la limite du délai d'exécution soit atteinte. Le statut est ensuite remplacé par un état de mise hors service. |
| Delayed (Retardé) | Le système tente d'envoyer la commande au nœud géré, mais n'a pas réussi. Le système réessaie. |
| Réussite | Ce statut est renvoyé dans diverses conditions. Ce statut ne signifie pas que la commande a été effectuée sur le nœud. Par exemple, la commande peut être reçue par SSM Agent le nœud géré et renvoyer un code de sortie égal à zéro si vous PowerShell ExecutionPolicy empêchez l'exécution de la commande. Il s’agit d’un statut de terminal. Les conditions qui font qu’une commande renvoie un statut Success sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/monitor-commands.html) Les mêmes conditions s’appliquent lorsque vous ciblez des groupes de ressources. Pour résoudre les erreurs ou obtenir plus d'informations sur l'exécution des commandes, envoyez une commande qui gère les erreurs ou les exceptions en retournant les codes de sortie appropriés (codes de sortie autre que zéro pour un échec de la commande). |
| DeliveryTimedOut | La commande n'a pas été fournie au nœud géré avant l'expiration du délai total. Les dépassements de délai totaux ne sont pas comptabilisés dans la limite max-errors de la commande parent, mais ils permettent de savoir si l'état de la commande parent est Success, Incomplete ou Delivery Timed Out. Il s’agit d’un statut de terminal. |
| ExecutionTimedOut | L'automatisation de la commande a démarré sur le nœud géré, mais l'exécution de la commande ne s'est pas terminée avant l'expiration du délai d'exécution. Les expirations de délais d'exécution sont considérés comme des échecs, ce qui enverra une réponse nulle et Systems Manager quittera sortira de la tentative d'exécution de l'automatisation des commandes et signalera échec comme état. |
| Échec | La commande n'a pas réussi sur le nœud géré. Pour un plugin, cela signifie que le code de résultat n'était pas zéro. Pour une invocation de commande, cela signifie que le code de résultat pour un ou plusieurs plugins n'était pas zéro. Les échecs d'invocation sont comptabilisés dans la limite max-errors de la commande parent. Il s’agit d’un statut de terminal. |
| Annulée | La commande a été annulée avant de se terminer. Il s'agit d'un état final. |
| Undeliverable (Non livrable) | La commande ne peut pas être délivrée au nœud géré. Le nœud peut ne pas exister ou ne peut pas répondre. Les appels ne pouvant pas être remis ne sont pas comptabilisés dans la limite max-errors de la commande parent, mais ils permettent de déterminer si le statut de la commande parent est Success ou Incomplete. Par exemple, si tous les appels d'une commande ont le statut Undeliverable, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Undeliverable et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s'agit d'un état final. |
| Terminated (Résilié) | La commande parent atteint sa limite max-errors et les appels de commande suivants ont été annulés par le système. Il s’agit d’un statut de terminal. |
| InvalidPlatform | La commande a été envoyée à un nœud géré qui ne correspondait pas aux plateformes requises spécifiées par le document choisi. Invalid Platform ne compte pas dans la limite maximale d'erreurs de la commande parent, mais permet de savoir si le statut de la commande parent est Success (Réussite) ou Failed (Échec). Par exemple, si tous les appels d'une commande ont le statut Invalid Platform, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Invalid Platform et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s’agit d’un statut de terminal. |
| AccessDenied | L'utilisateur ou le rôle Gestion des identités et des accès AWS (IAM) à l'origine de la commande n'a pas accès au nœud géré ciblé. Access Deniedn'est pas prise en compte dans la max-errors limite de la commande parent, mais elle contribue à déterminer si le statut de la commande parent est Success ouFailed. Par exemple, si tous les appels d'une commande ont le statut Access Denied, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Access Denied et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s'agit d'un état final. |
**Statut détaillé d'une commande**
| Statut | Détails |
| --- | --- |
| En attente | La commande n'a pas encore été reçue par un agent sur un nœud géré. |
| InProgress | La commande a été envoyée au moins à un nœud géré, mais n'a pas atteint un état final sur tous les nœuds. |
| Delayed (Retardé) | Le système tente d'envoyer la commande au nœud, mais n'a pas réussi. Le système réessaie. |
| Réussite | La commande a été reçue par SSM Agent sur l'ensemble des nœuds gérés spécifiés ou ciblés et a retourné un code de sortie de zéro. L'ensemble des invocations de commande a atteint un état de mise hors service, et la valeur de max-errors n'a pas été atteinte. Ce statut ne signifie pas que la commande a été effectuée avec succès sur l'ensemble des nœuds gérés spécifiés ou ciblés. Il s'agit d'un état final. Pour résoudre les erreurs ou obtenir plus d'informations sur l'exécution des commandes, envoyez une commande qui gère les erreurs ou les exceptions en retournant les codes de sortie appropriés (codes de sortie autre que zéro pour un échec de la commande). |
| DeliveryTimedOut | La commande n'a pas été fournie au nœud géré avant l'expiration du délai total. La valeur de max-errors ou d'autres appels de commande affichent le statut Delivery Timed Out. Il s'agit d'un état final. |
| Échec | La commande n'a pas réussi sur le nœud géré. La valeur de `max-errors` ou d'autres appels de commande affichent le statut `Failed`. Il s'agit d'un état final. |
| Incomplete (Incomplet) | La commande a été tentée sur tous les nœuds gérés et un ou plusieurs appels n'ont pas la valeur Success. Toutefois, le nombre d'appels en échec n'est pas suffisant pour que le statut soit Failed. Il s’agit d’un statut de terminal. |
| Annulée | La commande a été annulée avant de se terminer. Il s’agit d’un statut de terminal. |
| RateExceeded | Le nombre de nœuds gérés ciblée par la commande a dépassé la quota du compte pour les appels en attente. Le système a annulé la commande avant de l'exécuter sur un nœud. Il s’agit d’un statut de terminal. |
| AccessDenied | L'utilisateur ou le rôle qui initie la commande n'a pas accès au groupe de ressources ciblé. AccessDenied n'est pas pris en compte dans la limite max-errors de la commande parent, mais contribue à déterminer si le statut de la commande parent est Success ou Failed. (Par exemple, si tous les appels d'une commande ont le statut AccessDenied, alors le statut de la commande retourné est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut AccessDenied et 1 renvoie le statut Success, le statut de la commande parent est Success.) Il s'agit d'un état final. |
| No Instances In Tag (Aucune instance dans la balise) | La valeur ou le groupe de ressources de la paire de clés de balise ciblés par la commande ne correspondent à aucun nœud géré. Il s'agit d'un état final. |
## Présentation des valeurs de délai des commandes
Systems Manager applique les valeurs de délai suivantes lors de l'exécution des commandes.
**Total Timeout (Délai total)**
Dans la console Systems Manager, vous spécifiez la valeur du délai d'expiration dans le champ **Timeout (seconds) (Délai d'expiration (secondes))**. Une fois qu'une commande est envoyée, Run Command vérifie si la commande a expiré ou non. Si une commande atteint la limite d'expiration de la commande (délai total), son statut devient `DeliveryTimedOut` pour tous les appels ayant le statut `InProgress`, `Pending` ou `Delayed`.
![\[Champ Timeout (seconds) (Délai d'expiration [secondes]) dans la console Systems Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
Sur un plan plus technique, le délai d'expiration total (**Timeout (seconds) (Délai d'expiration (secondes))**) est une combinaison de deux valeurs de délai d'expiration, comme indiqué ici :
`Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document`
Par exemple, la valeur par défaut de **Timeout (seconds) (Délai d'expiration (secondes))** dans la console Systems Manager est de 600 secondes. Si vous exécutez une commande en utilisant le document SSM `AWS-RunShellScript`, la valeur par défaut de **« timeoutSeconds » : « \$1\$1executionTimeout\$1\$1 »** est de 3600 secondes, comme indiqué dans l'exemple de document suivant :
```
"executionTimeout": {
"type": "String",
"default": "3600",
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"timeoutSeconds": "{{ executionTimeout }}"
```
Cela signifie que la commande s'exécute pendant 4 200 secondes (70 minutes) avant que le système ne définisse l'état de la commande sur `DeliveryTimedOut`.
**Execution Timeout (Délai d'exécution)**
Dans la console Systems Manager, vous spécifiez la valeur du délai d'exécution dans le champ **Execution Timeout (Délai d'exécution)** s'il est disponible. Les documents SSM ne nécessitent pas tous que vous spécifiiez un délai d'exécution. Le champ **Execution Timeout** (Délai d'exécution) n'est affiché que lorsqu'un paramètre d'entrée correspondant a été défini dans le document SSM. Si un délai est spécifié, la commande doit être exécutée dans ce délai.
**Note**
Run Command s'appuie sur la réponse terminale du document SSM Agent pour déterminer si la commande a été remise ou non à l'agent. SSM Agent doit envoyer un signal `ExecutionTimedOut` pour qu'une invocation ou une commande soient marquées comme `ExecutionTimedOut`.
![\[Champ Execution Timeout (Délai d'exécution) de la console Systems Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**Default Execution Timeout (Délai d'exécution par défaut)**
Si un document SSM ne nécessite pas que vous spécifiiez explicitement une valeur de délai d'exécution, Systems Manager applique le délai d'exécution par défaut codé en dur.
**Signalement des délais d'expiration par Systems Manager**
Si Systems Manager reçoit une réponse `execution timeout` de l'SSM Agent sur une cible, Systems Manager marque l'invocation de commande comme `executionTimeout`.
Si Run Command ne reçoit pas de réponse terminale de document en provenance de l'SSM Agent, l'invocation de la commande est marquée comme `deliveryTimeout`.
Afin de déterminer le statut du délai sur une cible, l'SSM Agent combine tous les paramètres et le contenu du document SSM pour calculer `executionTimeout`. Lorsque l'SSM Agent détermine que le délai d'exécution d'une commande a expiré, il envoie `executionTimeout` au service.
La valeur par défaut pour **Timeout (seconds) (Délai d'expiration (secondes))** est de 3 600 secondes. La valeur par défaut pour **Execution timeout (Délai d'exécution)** est également de 3 600 secondes. Par conséquent, le délai d'attente total par défaut pour une commande est de 7 200 secondes.
**Note**
L'SSM Agent traite `executionTimeout` différemment selon le type de document SSM et la version du document.
# Procédures Run Command
Les procédures de cette section vous montrent comment exécuter des commandes avec Run Command, un outil d’AWS Systems Manager, ou AWS Command Line Interface (AWS CLI)/AWS Tools for Windows PowerShell.
**Topics**
+ [Mise à jour du logiciel à l'aide de Run Command](run-command-tutorial-update-software.md)
+ [Procédure pas à pas : utilisez le AWS CLI avec Run Command](walkthrough-cli.md)
+ [Procédure pas à pas : utilisez le AWS Tools for Windows PowerShell avec Run Command](walkthrough-powershell.md)
Vous pouvez également consulter des exemples de commandes dans les références suivantes.
+ [Référence de AWS CLI Systems Manager](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
+ [AWS Tools for Windows PowerShell - AWS Systems Manager](https://docs.aws.amazon.com/powershell/latest/reference/items/SimpleSystemsManagement_cmdlets.html)
# Mise à jour du logiciel à l'aide de Run Command
Les procédures suivantes décrivent comment mettre à jour le logiciel sur vos nœuds gérés.
## Mise à jour de SSM Agent à l'aide de Run Command
La procédure suivante décrit comment mettre à jour l'SSM Agent en cours d'exécution sur vos nœuds gérés. Vous pouvez mettre à jour à l'aide de la dernière version de l'SSM Agent ou d'une version plus ancienne. Lorsque vous exécutez la commande, le système télécharge la version depuis AWS, l'installe, puis désinstalle la version qui existait avant l'exécution de la commande. Si une erreur se produit au cours de ce processus, le système revient à la version du serveur avant l'exécution de la commande et le statut de cette dernière indique qu'elle a échoué.
**Note**
Si une instance exécute macOS version 13.0 (Ventura) ou ultérieure, elle doit disposer de l’SSM Agent version 3.1.941.0 ou supérieure pour exécuter le document AWS-UpdateSSMAgent. Si l'instance exécute une version de l'SSM Agent publiée avant la version 3.1.941.0, vous pouvez mettre à jour votre SSM Agent pour exécuter le document AWS-UpdateSSMAgent en exécutant les commandes `brew update` et `brew upgrade amazon-ssm-agent`.
Pour recevoir des notifications concernant les mises à jour de SSM Agent, 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 mettre à jour l'SSM Agent en utilisant Run Command**
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 **Run Command (Exécuter la commande)**.
1. In the **Command document (Document de commande)**, sélectionnez **`AWS-UpdateSSMAgent`**.
1. Dans la section **Paramètres de la commande**, indiquez des valeurs pour les paramètres suivants, si vous le souhaitez :
1. (Facultatif) Pour **Version**, saisissez la version de l'SSM Agent à installer. Vous pouvez installer des [versions plus anciennes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) de l'agent. Si vous ne spécifiez pas de version, le service installe la dernière version.
1. (Facultatif) Pour **Allow Downgrade (Autoriser le retour à la version précédente)**, sélectionnez **true** pour installer une version antérieure de l'SSM Agent. Si vous sélectionnez cette option, spécifiez le numéro de version [antérieure](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md). Sélectionnez **false** pour installer uniquement la dernière version du service.
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
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. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**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, 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, assurez-vous 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. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Cliquez sur **Exécuter**.
## Mise à jour PowerShell en utilisant Run Command
La procédure suivante décrit comment effectuer une mise à jour PowerShell vers la version 5.1 sur vos nœuds gérés Windows Server 2012 et 2012 R2. Le script fourni dans cette procédure télécharge la mise à jour de Windows Management Framework (WMF) version 5.1 et démarre l'installation de la mise à jour. Le nœud redémarre au cours de ce processus, comme l'exige l'installation de WMF 5.1. Le téléchargement et l'installation de la mise à jour prennent environ cinq minutes.
**Pour effectuer une mise à jour PowerShell avec Run Command**
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 **Run Command (Exécuter la commande)**.
1. In the **Command document (Document de commande)**, sélectionnez **`AWS-RunPowerShellScript`**.
1. Dans la section **Commands (Commandes)**, collez les commandes suivantes pour votre système d'exploitation.
------
#### [ Windows Server 2012 R2 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839516" -OutFile "Win8.1AndW2K12R2-KB3191564-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('Win8.1AndW2K12R2-KB3191564-x64.msu', '/quiet')
```
------
#### [ Windows Server 2012 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839513" -OutFile "W2K12-KB3191565-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('W2K12-KB3191565-x64.msu', '/quiet')
```
------
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
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. Pour **Autres paramètres** :
+ Pour **Comment (Commentaire)**, saisissez des informations à propos de cette commande.
+ Pour **Délai (secondes)**, précisez le nombre de secondes durant lesquelles le système doit attendre avant de mettre en échec l'exécution de la commande globale.
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
1. (Facultatif) Pour **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, cochez la case **Write command output to an S3 bucket (Écrire la sortie de commande vers un compartiment S3)**. Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**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, 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, assurez-vous 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. Dans la section **SNS notifications (Notifications SNS)**, si vous souhaitez envoyer des notifications sur le statut d'exécution des commandes, cochez la case **Enable SNS notifications (Activer les notifications SNS)**.
Pour plus d'informations sur la configuration des notifications Amazon SNS pour Run Command, consultez [Surveillance des changements d'état du Systems Manager à l'aide des notifications Amazon SNS](monitoring-sns-notifications.md).
1. Cliquez sur **Exécuter**.
Une fois que le nœud géré a redémarré et que l'installation de la mise à jour est terminée, connectez-vous à votre nœud pour confirmer que la mise à niveau vers la version 5.1 a été effectuée PowerShell avec succès. Pour vérifier la version de PowerShell sur votre nœud, ouvrez PowerShell et entrez`$PSVersionTable`. La valeur `PSVersion` dans le tableau de sortie affiche 5.1 si la mise à niveau a réussi.
Si la valeur `PSVersion` est différente de 5.1, par exemple 3.0 ou 4.0, consultez les journaux **Setup (Configuration)** dans Event Viewer, sous **Windows Logs (Journaux Windows)**. Ces journaux indiquent la raison de l'échec de la mise à jour.
# Procédure pas à pas : utilisez le AWS CLI avec Run Command
L'exemple de procédure pas à pas suivant vous montre comment utiliser le AWS Command Line Interface (AWS CLI) pour afficher des informations sur les commandes et leurs paramètres, comment exécuter des commandes et comment afficher le statut de ces commandes.
**Important**
Seuls les administrateurs fiables devraient être autorisés à utiliser les documents AWS Systems Manager préconfigurés présentés dans cette rubrique. Les commandes ou scripts spécifiés dans des documents Systems Manager sont exécutés avec des autorisations administratives sur vos nœuds gérés. Si un utilisateur a l'autorisation d'exécuter l'un des documents Systems Manager prédéfinis (tout document qui commence par `AWS-`), cet utilisateur dispose d'un accès administrateur au nœud. Pour tous les autres utilisateurs, vous devez créer des documents restrictifs et les partager avec des utilisateurs spécifiques.
**Topics**
+ [Étape 1 : Démarrage](#walkthrough-cli-settings)
+ [Étape 2 : Exécuter des scripts shell pour afficher les détails des ressources](#walkthrough-cli-run-scripts)
+ [Étape 3 : Envoyer des commandes simples à l'aide du document `AWS-RunShellScript`](#walkthrough-cli-example-1)
+ [Étape 4 : Exécuter un script Python simple en utilisant Run Command](#walkthrough-cli-example-2)
+ [Étape 5 : exécutez un script Bash avec Run Command](#walkthrough-cli-example-3)
## Étape 1 : Démarrage
Vous devez disposer de autorisations administrateur sur les nœuds gérés que vous souhaitez configurer ou vous devez bénéficier de l'autorisation appropriée dans Gestion des identités et des accès AWS (IAM). Notez également que cet exemple utilise la région USA Est (Ohio) (us-east-2). Run Commandest disponible dans les [points de terminaison du service Systems Manager Régions AWS](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) répertoriés dans le *Référence générale d'Amazon Web Services*. Pour de plus amples informations, veuillez consulter [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Pour exécuter des commandes à l'aide du AWS CLI**
1. 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).
1. Répertoriez tous les documents disponibles.
Cette commande répertorie tous les documents disponibles pour votre compte en fonction des autorisations IAM.
```
aws ssm list-documents
```
1. Vérifier qu'un nœud géré est prêt à recevoir les commandes.
La sortie de la commande suivante indique si les nœuds gérés sont en ligne.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--output text --query "InstanceInformationList[*]"
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--output text --query "InstanceInformationList[*]"
```
------
1. Exécutez la commande suivante pour afficher les détails sur un nœud géré spécifique.
**Note**
Pour exécuter les commandes de cette procédure pas à pas, remplacez l'instance et la commande IDs. Pour les appareils AWS IoT Greengrass principaux gérés, utilisez le mi- par *ID\$1number* exemple ID. L'ID de commande est renvoyé en réponse à **send-command**. IDs Les instances sont disponibles auprès Fleet Manager d'un outil dans AWS Systems Manager...
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
## Étape 2 : Exécuter des scripts shell pour afficher les détails des ressources
Run Command et le document `AWS-RunShellScript` vous permettent d'exécuter n'importe quel script ou commande sur un nœud géré comme si vous vous étiez connecté localement.
**Afficher la description et les paramètres disponibles**
Exécutez la commande suivante pour afficher la description du document JSON Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "[Document.Name,Document.Description]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "[Document.Name,Document.Description]"
```
------
Utilisez la commande suivante afin d'afficher les paramètres disponibles et les détails les concernant.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "Document.Parameters[*]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "Document.Parameters[*]"
```
------
## Étape 3 : Envoyer des commandes simples à l'aide du document `AWS-RunShellScript`
Utilisez la commande suivante afin d'obtenir des informations IP pour un nœud géré Linux.
Si vous ciblez un nœud géré Windows Server, remplacez `document-name` par `AWS-RunPowerShellScript` et `command` depuis `ifconfig` par `ipconfig`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "IP config" \
--parameters commands=ifconfig \
--output text
```
------
#### [ Windows ]
```
aws ssm send-command ^
--instance-ids "instance-ID" ^
--document-name "AWS-RunShellScript" ^
--comment "IP config" ^
--parameters commands=ifconfig ^
--output text
```
------
**Obtenir des informations sur la commande avec des données de réponse**
La commande suivante utilise l'ID de commande qui a été retourné par la commande précédente afin d'obtenir les détails et les données de réponse de l'exécution de la commande. Le système renvoie les données de réponse si la commande a été exécutée. Si l'exécution de la commande indique `"Pending"` ou `"InProgress"`, vous devrez l'exécuter à nouveau pour consulter les données de réponse.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id $sh-command-id \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id $sh-command-id ^
--details
```
------
**Identification de l'utilisateur**
La commande suivante affiche l'utilisateur par défaut qui exécute les commandes.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux managed node" \
--parameters commands=whoami \
--output text \
--query "Command.CommandId")
```
------
**Obtenir le statut de la commande**
La commande suivante utilise l'ID de commande afin d'obtenir le statut de l'exécution de la commande sur le nœud géré. Cet exemple utilise l'ID de commande qui a été renvoyé lors de la commande précédente.
------
#### [ Linux & macOS ]
```
aws ssm list-commands \
--command-id "command-ID"
```
------
#### [ Windows ]
```
aws ssm list-commands ^
--command-id "command-ID"
```
------
**Obtenir les détails de la commande**
La commande suivante utilise l'ID de la commande précédente afin d'obtenir le statut de l'exécution de la commande par nœud géré.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id "command-ID" ^
--details
```
------
**Obtention d'informations sur la commande avec des données de réponse pour un nœud géré**
La commande suivante renvoie la sortie de la demande `aws ssm send-command` initiale pour un nœud géré spécifique.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--instance-id instance-ID \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--instance-id instance-ID ^
--command-id "command-ID" ^
--details
```
------
**Afficher la version Python**
La commande suivante retourne la version de Python exécutée sur un nœud.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters commands='python -V' \
--output text --query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Étape 4 : Exécuter un script Python simple en utilisant Run Command
La commande suivante exécute un simple script Python « Hello World » à l'aide de Run Command.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters '{"commands":["#!/usr/bin/python","print \"Hello World from python\""]}' \
--output text \
--query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Étape 5 : exécutez un script Bash avec Run Command
Les exemples de cette section montrent l'exécution du script bash suivant avec Run Command.
Pour obtenir des exemples d'utilisation de Run Command pour exécuter des scripts stockés dans des emplacements distants, consultez [Exécution de scripts à partir d'Amazon S3](integration-s3.md) et [Exécution de scripts depuis GitHub](integration-remote-scripts.md).
```
#!/bin/bash
yum -y update
yum install -y ruby
cd /home/ec2-user
curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install
chmod +x ./install
./install auto
```
Ce script installe l' AWS CodeDeploy agent sur les instances Amazon Linux et Red Hat Enterprise Linux (RHEL), comme décrit dans la section [Créer une instance Amazon EC2 CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-ec2-create.html) pour dans *AWS CodeDeploy le guide de l'*utilisateur.
Le script installe l' CodeDeploy agent à partir d'un compartiment S3 AWS géré dans la région USA Est (Ohio) (us-east-2),. `aws-codedeploy-us-east-2`
**Exécuter un script bash dans une commande AWS CLI **
L'exemple suivant montre comment inclure le script bash dans une commande CLI en utilisant l'option `--parameters`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets '[{"Key":"InstanceIds","Values":["instance-id"]}]' \
--parameters '{"commands":["#!/bin/bash","yum -y update","yum install -y ruby","cd /home/ec2-user","curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install","chmod +x ./install","./install auto"]}'
```
------
**Exécuter un script bash dans un fichier JSON**
Dans l'exemple suivant, le contenu du script bash est stocké dans un fichier JSON, et le fichier est inclus dans la commande en utilisant l'option `--cli-input-json`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=InstanceIds,Values=instance-id" \
--cli-input-json file://installCodeDeployAgent.json
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--cli-input-json file://installCodeDeployAgent.json
```
------
L'exemple suivant montre le contenu du fichier `installCodeDeployAgent.json` référencé.
```
{
"Parameters": {
"commands": [
"#!/bin/bash",
"yum -y update",
"yum install -y ruby",
"cd /home/ec2-user",
"curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install",
"chmod +x ./install",
"./install auto"
]
}
}
```
# Procédure pas à pas : utilisez le AWS Tools for Windows PowerShell avec Run Command
Les exemples suivants montrent comment utiliser le AWS Tools for Windows PowerShell pour afficher des informations sur les commandes et leurs paramètres, comment exécuter des commandes et comment afficher le statut de ces commandes. Cette procédure inclut un exemple pour chaque document AWS Systems Manager prédéfini.
**Important**
Seuls les administrateurs de confiance doivent être autorisés à utiliser les documents préconfigurés Systems Manager illustrés dans cette rubrique. Les commandes ou scripts spécifiés dans des documents Systems Manager sont exécutés avec une autorisation administrative sur vos nœuds gérés. Si un utilisateur est autorisé à exécuter l'un des documents prédéfinis de Systems Manager (tout document commençant par AWS), il dispose également d'un accès administrateur au nœud. Pour tous les autres utilisateurs, vous devez créer des documents restrictifs et les partager avec des utilisateurs spécifiques.
**Topics**
+ [Configuration des paramètres AWS Tools for Windows PowerShell de session](#walkthrough-powershell-settings)
+ [Répertorier tous les documents disponibles](#walkthrough-powershell-all-documents)
+ [Exécuter PowerShell des commandes ou des scripts](#walkthrough-powershell-run-script)
+ [Installer une application en utilisant le document `AWS-InstallApplication`](#walkthrough-powershell-install-application)
+ [Installation d'un PowerShell module à l'aide du document `AWS-InstallPowerShellModule` JSON](#walkthrough-powershell-install-module)
+ [Association d'un nœud géré à un domaine en utilisant le document JSON `AWS-JoinDirectoryServiceDomain`](#walkthrough-powershell-domain-join)
+ [Envoyez les métriques Windows à Amazon CloudWatch Logs à l'aide du `AWS-ConfigureCloudWatch` document](#walkthrough-powershell-windows-metrics)
+ [Activer ou désactiver la mise à jour automatique de Windows en utilisant le document `AWS-ConfigureWindowsUpdate`](#walkthrough-powershell-enable-windows-update)
+ [Gérer les mises à jour Windows à l'aide de la fonctionnalité Run Command](#walkthough-powershell-windows-updates)
## Configuration des paramètres AWS Tools for Windows PowerShell de session
**Spécifier vos informations d'identification**
Ouvrez **Outils pour Windows PowerShell** sur votre ordinateur local et exécutez la commande suivante pour spécifier vos informations d'identification. Vous devez disposer des autorisations d'administrateur sur les nœuds gérés que vous souhaitez configurer ou vous devez avoir obtenu les autorisations appropriées dans Gestion des identités et des accès AWS (IAM). Pour de plus amples informations, veuillez consulter [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
```
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
```
**Définir une valeur par défaut Région AWS**
Exécutez la commande suivante pour définir la région de votre PowerShell session. L'exemple utilise la région USA Est (Ohio) (us-east-2). Run Commandest disponible dans les [points de terminaison du service Systems Manager Régions AWS](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) répertoriés dans le *Référence générale d'Amazon Web Services*.
```
Set-DefaultAWSRegion `
-Region us-east-2
```
## Répertorier tous les documents disponibles
Cette commande répertorie les documents disponibles pour votre compte.
```
Get-SSMDocumentList
```
## Exécuter PowerShell des commandes ou des scripts
Run Command et le document `AWS-RunPowerShell` vous permettent d'exécuter n'importe quel script ou commande sur un nœud géré comme si vous vous étiez connecté localement. Vous pouvez émettre des commandes ou saisir un chemin d'accès à un script local pour exécuter la commande.
**Note**
Pour plus d'informations sur le redémarrage des nœuds gérés lors de l'utilisation de Run Command pour appeler des scripts, consultez [Gestion des redémarrages lors de l'exécution de commandes](send-commands-reboot.md).
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript" | Select -ExpandProperty Parameters
```
### Envoyer une commande en utilisant le document `AWS-RunPowerShellScript`
La commande suivante permet d'afficher le contenu du répertoire `"C:\Users"` et celui du répertoire `"C:\"` sur deux nœuds gérés.
```
$runPSCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1", "instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'=@('dir C:\Users', 'dir C:\')}
```
**Obtenir les détails de la demande de commande**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande sur les deux nœuds gérés. Cet exemple utilise l'`CommandId` qui a été renvoyé lors de la commande précédente.
```
Get-SSMCommand `
-CommandId $runPSCommand.CommandId
```
Dans cet exemple, le statut de la commande peut être Success, Pending ou InProgress.
**Obtention d'informations sur la commande par nœud géré**
La commande suivante utilise l'`CommandId` de la commande précédente afin d'obtenir le statut de l'exécution de la commande par nœud géré.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId
```
**Obtention d'informations sur la commande avec des données de réponse pour un nœud géré**
La commande suivante renvoie la sortie de la commande `Send-SSMCommand` initiale pour un nœud géré spécifique.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Annuler une commande
La commande suivante annule le `Send-SSMCommand` pour le document `AWS-RunPowerShellScript`.
```
$cancelCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1","instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'='Start-Sleep –Seconds 120; dir C:\'}
Stop-SSMCommand -CommandId $cancelCommand.CommandId
```
**Vérifier le statut de commande**
La commande suivante vérifie le statut de la commande `Cancel`.
```
Get-SSMCommand `
-CommandId $cancelCommand.CommandId
```
## Installer une application en utilisant le document `AWS-InstallApplication`
En utilisant Run Command et le document `AWS-InstallApplication`, vous pouvez installer, réparer ou désinstaller des applications sur des nœuds gérés. Cette commande a besoin d'un chemin d'accès ou d'une adresse pour un MSI.
**Note**
Pour plus d'informations sur le redémarrage des nœuds gérés lors de l'utilisation de Run Command pour appeler des scripts, consultez [Gestion des redémarrages lors de l'exécution de commandes](send-commands-reboot.md).
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication" | Select -ExpandProperty Parameters
```
### Envoyer une commande en utilisant le document `AWS-InstallApplication`
La commande suivante installe une version de Python sur votre nœud géré en mode sans surveillance et consigne la sortie dans un fichier texte local sur votre lecteur `C:`.
```
$installAppCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallApplication" `
-Parameter @{'source'='https://www.python.org/ftp/python/2.7.9/python-2.7.9.msi'; 'parameters'='/norestart /quiet /log c:\pythoninstall.txt'}
```
**Obtention d'informations sur la commande par nœud géré**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true
```
**Obtention d'informations sur la commande avec des données de réponse pour un nœud géré**
La commande suivante retourne les résultats de l'installation Python.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
## Installation d'un PowerShell module à l'aide du document `AWS-InstallPowerShellModule` JSON
Vous pouvez l'utiliser Run Command pour installer PowerShell des modules sur des nœuds gérés. Pour plus d'informations sur les PowerShell modules, consultez la section [ PowerShell Modules Windows](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-6).
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule" | Select -ExpandProperty Parameters
```
### Installation d'un PowerShell module
La commande suivante télécharge le fichier EZOut .zip, l'installe, puis exécute une commande supplémentaire pour installer le lecteur XPS. Enfin, la sortie de cette commande est chargée dans un compartiment S3 nommé « amzn-s3-demo-bucket ».
```
$installPSCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallPowerShellModule" `
-Parameter @{'source'='https://gallery.technet.microsoft.com/EZOut-33ae0fb7/file/110351/1/EZOut.zip';'commands'=@('Add-WindowsFeature -name XPS-Viewer -restart')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Obtention d'informations sur la commande par nœud géré**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true
```
**Obtention d'informations sur la commande avec des données de réponse pour le nœud géré**
La commande suivante renvoie la sortie de la commande `Send-SSMCommand` d'origine pour le `CommandId` spécifique.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Association d'un nœud géré à un domaine en utilisant le document JSON `AWS-JoinDirectoryServiceDomain`
En utilisantRun Command, vous pouvez rapidement joindre un nœud géré à un AWS Directory Service domaine. Avant d'exécuter cette commande, [créez un répertoire](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html). Nous vous recommandons également d'en découvrir plus sur l' Directory Service. Pour plus d'informations, consultez le [Guide d'administration AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/).
Vous pouvez uniquement associer un nœud géré à un domaine. Vous ne pouvez pas supprimer de nœud d'un domaine.
**Note**
Pour plus d'informations sur les nœuds gérés lors de l'utilisation de Run Command pour appeler des scripts, consultez [Gestion des redémarrages lors de l'exécution de commandes](send-commands-reboot.md).
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain" | Select -ExpandProperty Parameters
```
### Association d'un nœud géré à un domaine
La commande suivante joint un nœud géré au Directory Service domaine donné et télécharge toute sortie générée dans l'exemple de bucket Amazon Simple Storage Service (Amazon S3).
```
$domainJoinCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-JoinDirectoryServiceDomain" `
-Parameter @{'directoryId'='d-example01'; 'directoryName'='ssm.example.com'; 'dnsIpAddresses'=@('192.168.10.195', '192.168.20.97')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Obtention d'informations sur la commande par nœud géré**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true
```
**Obtention d'informations sur la commande avec des données de réponse pour le nœud géré**
Cette commande renvoie la sortie du `Send-SSMCommand` initial pour le `CommandId` spécifique.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Envoyez les métriques Windows à Amazon CloudWatch Logs à l'aide du `AWS-ConfigureCloudWatch` document
Vous pouvez envoyer Windows Server des messages dans les journaux de l'application, du système, de la sécurité et du suivi des événements pour Windows (ETW) à Amazon CloudWatch Logs. Lorsque vous activez la journalisation pour la première fois, Systems Manager envoie tous les journaux générés en une minute à partir du moment où vous avez commencé à charger les journaux pour les applications, le système, la sécurité et le suivi d'événements. Les journaux générés avant ce moment ne sont pas inclus. Si vous désactivez la journalisation, puis que vous la réactivez, Systems Manager envoie les journaux à partir du moment où la journalisation a été désactivée. Pour tous les fichiers journaux personnalisés et les journaux IIS (Internet Information Services), Systems Manager lit les fichiers journaux depuis le début. En outre, Systems Manager peut également envoyer les données des compteurs de performance à CloudWatch Logs.
Si vous avez précédemment activé CloudWatch l'intégration dans EC2 Config, les paramètres de Systems Manager remplacent tous les paramètres stockés localement sur le nœud géré dans le `C:\Program Files\Amazon\EC2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json` fichier. Pour plus d'informations sur l'utilisation de EC2 Config pour gérer les compteurs de performance et les journaux sur un seul nœud géré, consultez la section [Collecte de métriques et de journaux à partir d'instances Amazon EC2 et de serveurs sur site avec CloudWatch l'agent dans le guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) de l'utilisateur *Amazon CloudWatch *.
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch" | Select -ExpandProperty Parameters
```
### Envoyez les journaux des applications à CloudWatch
La commande suivante configure le nœud géré et déplace les journaux des applications Windows vers CloudWatch.
```
$cloudWatchCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"ApplicationEventLog", "FullName":"AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"LogName":"Application", "Levels":"7"}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch", "Parameters":{"Region":"region", "LogGroup":"my-log-group", "LogStream":"instance-id"}}], "Flows":{"Flows":["ApplicationEventLog,CloudWatch"]}}}'}
```
**Obtention d'informations sur la commande par nœud géré**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true
```
**Obtention d'informations sur la commande avec des données de réponse pour un nœud géré**
La commande suivante renvoie les résultats de la CloudWatch configuration Amazon.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Envoyer des compteurs de performance à CloudWatch l'utilisation du document `AWS-ConfigureCloudWatch`
La commande de démonstration suivante télécharge les compteurs de performance vers. CloudWatch Pour plus d'informations, consultez le *[guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)*.
```
$cloudWatchMetricsCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"PerformanceCounter", "FullName":"AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"CategoryName":"Memory", "CounterName":"Available MBytes", "InstanceName":"", "MetricName":"AvailableMemory", "Unit":"Megabytes","DimensionName":"", "DimensionValue":""}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"AccessKey":"", "SecretKey":"","Region":"region", "NameSpace":"Windows-Default"}}], "Flows":{"Flows":["PerformanceCounter,CloudWatch"]}}}'}
```
## Activer ou désactiver la mise à jour automatique de Windows en utilisant le document `AWS-ConfigureWindowsUpdate`
Run Command et le document `AWS-ConfigureWindowsUpdate` vous permettent d'activer et de désactiver les mises à jour Windows automatiques sur vos nœuds gérés Windows Server. Cette commande configure l'agent de mise à jour Windows pour télécharger et installer les mises à jour Windows à la date et à l'heure que vous spécifiez. Si une mise à jour requiert un redémarrage, le nœud géré redémarre automatiquement 15 minutes après l'installation des mises à jour. Cette commande vous permet également de configurer la mise à jour Windows de façon à rechercher les mises à jour sans les installer. Le document `AWS-ConfigureWindowsUpdate` est officiellement pris en charge sur Windows Server 2012 et versions ultérieures.
**Afficher la description et les paramètres disponibles**
```
Get-SSMDocumentDescription `
–Name "AWS-ConfigureWindowsUpdate"
```
**Afficher des informations supplémentaires sur les paramètres**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureWindowsUpdate" | Select -ExpandProperty Parameters
```
### Activer la mise à jour automatique de Windows
La commande suivante configure les mises à jour Windows de façon à ce qu'elles soient téléchargées et installées automatiquement tous les jours à 22 h.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='InstallUpdatesAutomatically'; 'scheduledInstallDay'='Daily'; 'scheduledInstallTime'='22:00'}
```
**Afficher le statut de la commande afin d'activer les mises à jour automatiques Windows**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande pour activer les mises à jour automatiques Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
### Désactiver la mise à jour automatique de Windows
La commande suivante diminue le niveau de notification des mises à jour Windows afin que le système recherche les mises à jour, mais ne mette pas à jour le nœud géré automatiquement.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='NeverCheckForUpdates'}
```
**Afficher le statut de la commande afin de désactiver les mises à jour automatiques Windows**
La commande suivante utilise l'`CommandId` afin d'obtenir le statut de l'exécution de la commande pour activer les mises à jour automatiques Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
## Gérer les mises à jour Windows à l'aide de la fonctionnalité Run Command
Run Command et le document `AWS-InstallWindowsUpdates` vous permettent de gérer les mises à jour pour les nœuds gérés Windows Server. Cette commande recherche ou installe les mises à jour manquantes sur vos nœuds gérés et, éventuellement, provoque un redémarrage après l'installation. Vous pouvez également spécifier les classifications et les niveaux de sévérité appropriés pour les mises à jour à installer dans votre environnement.
**Note**
Pour plus d'informations sur le redémarrage des nœuds gérés lors de l'utilisation de Run Command pour appeler des scripts, consultez [Gestion des redémarrages lors de l'exécution de commandes](send-commands-reboot.md).
Les exemples suivants décrivent comment exécuter les tâches de gestion des mises à jour Windows spécifiées.
### Rechercher toutes les mises à jour Windows manquantes
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Scan'}
```
### Installer des mises à jour Windows spécifiques
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'IncludeKbs'='kb-ID-1,kb-ID-2,kb-ID-3';'AllowReboot'='True'}
```
### Installer les mises à jour Windows importantes manquantes
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'SeverityLevels'='Important';'AllowReboot'='True'}
```
### Installer les mises à jour Windows manquantes avec des exclusions spécifiques
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'ExcludeKbs'='kb-ID-1,kb-ID-2';'AllowReboot'='True'}
```
# Résolution des problèmes liés à Run Command de Systems Manager
Run Command, un outil dans AWS Systems Manager, fournit des informations sur le statut de chaque exécution de commande. Pour de plus amples informations sur les détails de l'état des commande, veuillez consulter [Comprendre les états des commandes](monitor-commands.md). Vous pouvez également utiliser les informations de cette rubrique pour aider à la résolution les problèmes rencontrés avec la fonctionnalité Run Command.
**Topics**
+ [Certains de mes nœuds gérés sont manquants](#where-are-instances)
+ [Une étape de mon script a échoué, mais l'état global est « réussi »](#ts-exit-codes)
+ [SSM Agent ne fonctionne pas correctement](#ts-ssmagent-linux)
## Certains de mes nœuds gérés sont manquants
Dans la page **Exécuter une commande**, une fois que vous avez choisi un document SSM à exécuter et que vous avez sélectionné **Sélection manuelle des instances** dans la section **Cibles**, la liste des nœuds gérés sur lesquels vous pouvez choisir d'exécuter la commande s'affiche.
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.
Après avoir créé, activé, redémarré ou redémarré un nœud géré, installé Run Command sur un nœud ou attaché un profil d'instance Gestion des identités et des accès AWS (IAM) à un nœud, l'ajout du nœud géré à la liste peut prendre quelques minutes.
## Une étape de mon script a échoué, mais l'état global est « réussi »
Vous pouvez utiliser Run Command pour définir la manière dont les codes de sortie sont gérés par vos scripts. Par défaut, le code de sortie de la dernière commande exécutée dans un script est signalé comme le code de sortie pour l'ensemble du script. Vous pouvez néanmoins inclure une instruction conditionnelle pour quitter le script si une commande précédant la dernière échoue. Pour plus d'informations et d'exemples, consultez [Spécifier les codes de sortie dans les commandes](run-command-handle-exit-status.md#command-exit-codes).
## SSM Agent ne fonctionne pas correctement
Si vous rencontrez des problèmes pour exécuter des commandes avec la fonctionnalité Run Command, cela peut venir de l'SSM Agent. Pour obtenir des informations sur la recherche de problèmes avec SSM Agent, veuillez consulter [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md).
# AWS Systems Manager Session Manager
Session Managerest un AWS Systems Manager outil entièrement géré. Vous pouvez ainsi gérer vos instances Amazon Elastic Compute Cloud (Amazon EC2), vos appareils périphériques, vos serveurs sur site et vos machines virtuelles (). Session Manager VMs Vous pouvez utiliser soit un shell interactif basé sur un navigateur en un clic, soit le AWS Command Line Interface ().AWS CLISession Managerfournit une gestion sécurisée des nœuds sans qu'il soit nécessaire d'ouvrir des ports entrants, de gérer des hôtes bastions ou de gérer des clés SSH. Session Managervous permet également de vous conformer aux politiques d'entreprise qui exigent un accès contrôlé aux nœuds gérés, des pratiques de sécurité strictes et des journaux contenant les détails d'accès aux nœuds, tout en fournissant aux utilisateurs finaux un accès multiplateforme en un clic à vos nœuds gérés. Pour vos premiers pas dans Session Manager, ouvrez [Systems Manager console](https://console.aws.amazon.com/systems-manager/session-manager). Dans le panneau de navigation, sélectionnez **Session Manager**.
## Comment mon organisation peut-elle tirer parti de Session Manager ?
Session Manager offre les avantages suivants :
+ **Contrôle centralisé des accès aux nœuds gérés à l'aide de politiques IAM**
Les administrateurs disposent d'un point central pour accorder et révoquer les accès aux nœuds gérés. En utilisant uniquement des politiques Gestion des identités et des accès AWS (IAM), vous pouvez contrôler quels utilisateurs ou groupes individuels de votre organisation peuvent utiliser Session Manager et à quels nœuds gérés ils peuvent accéder.
+ **Aucun port entrant ouvert et aucune nécessité d'ouvrir des hôtes bastion ou des clés SSH**
En laissant les ports SSH et les ports PowerShell distants ouverts sur vos nœuds gérés, vous augmentez considérablement le risque que des entités y exécutent des commandes malveillantes ou non autorisées. Session Manager vous aide à renforcer votre niveau de sécurité en vous permettant de fermer ces ports entrants, et d'éviter ainsi de gérer les clés SSH et les certificats, les hôtes bastion ainsi que les zones de reroutage.
+ **Accès en un clic aux nœuds gérés depuis la console et la CLI**
À l'aide de la AWS Systems Manager console ou de la console Amazon EC2, vous pouvez démarrer une session en un seul clic. À l'aide du AWS CLI, vous pouvez également démarrer une session qui exécute une seule commande ou une séquence de commandes. Étant donné que les autorisations d'accès aux nœuds gérés sont fournies via des politiques IAM et non des clés SSH ou autres mécanismes, le temps de connexion est considérablement réduit.
+ **Connexion à la fois aux instances Amazon EC2 et aux nœuds gérés non EC2 dans des environnements [hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types)**
Vous pouvez vous connecter à la fois aux instances Amazon Elastic Compute Cloud (Amazon EC2) et aux nœuds non EC2 de votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types).
Pour vous connecter à des nœuds non EC2 à l'aide de Session Manager, activez d'abord le niveau d'instances avancées. **L'utilisation du niveau d'instance avancé est payante.** Cependant, il n'existe aucun frais supplémentaires pour la connexion aux instances EC2 à l'aide de Session Manager. Pour plus d'informations, consultez [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md).
+ **Réacheminement de port**
Redirigez n'importe quel port de votre nœud géré distant vers un port local sur un client. Après cela, connectez-vous au port local et accédez à l'application serveur qui s'exécute sur le nœud.
+ **Prise en charge multiplateforme de Windows, Linux et macOS**
Session Manager prend en charge Windows, Linux et macOS à partir d'un simple outil. Par exemple, vous n'avez pas besoin d'utiliser un client SSH pour les nœuds gérés Linux et macOS, ni une connexion RDP pour les nœuds gérés Windows Server.
+ **Journalisation de l’activité de session**
Pour satisfaire aux exigences opérationnelles ou de sécurité de votre organisation, vous pouvez avoir besoin de fournir un enregistrement des différentes connexions à vos nœuds gérés et des commandes qui y ont été exécutées. Vous pouvez également recevoir des notifications lorsqu'un utilisateur de votre organisation démarre ou termine une activité de session.
Des fonctionnalités de journalisation sont fournies via l’intégration aux Services AWS suivants :
+ **AWS CloudTrail**— AWS CloudTrail capture les informations relatives aux appels d'Session ManagerAPI effectués dans votre compte Compte AWS et les écrit dans des fichiers journaux qui sont stockés dans un bucket Amazon Simple Storage Service (Amazon S3) que vous spécifiez. Un compartiment est utilisé pour tous les CloudTrail journaux de votre compte. Pour de plus amples informations, veuillez consulter [Journalisation des appels d' AWS Systems Manager API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **Amazon Simple Storage Service** : vous pouvez choisir de stocker les données des journaux de session dans le compartiment Amazon S3 de votre choix à des fins de débogage et de résolution des problèmes. Les données des journaux peuvent être envoyées à votre compartiment Amazon S3 avec ou sans chiffrement à l'aide de votre AWS KMS key. Pour de plus amples informations, veuillez consulter [Journalisation des données de session avec Amazon S3 (console)](session-manager-logging-s3.md).
+ **Amazon CloudWatch Logs** — CloudWatch Logs vous permet de surveiller, de stocker et d'accéder à des fichiers journaux provenant de différents sites Services AWS. Vous pouvez envoyer les données du journal de session à un groupe de CloudWatch journaux de journaux à des fins de débogage et de résolution des problèmes. Les données de journal peuvent être envoyées à votre groupe de journaux avec ou sans AWS KMS chiffrement à l'aide de votre clé KMS. Pour de plus amples informations, veuillez consulter [Enregistrement des données de session à l'aide d'Amazon CloudWatch Logs (console)](session-manager-logging-cloudwatch-logs.md).
+ **Amazon EventBridge** et **Amazon Simple Notification Service** : vous EventBridge permettent de définir des règles pour détecter les modifications apportées aux AWS ressources que vous spécifiez. Vous pouvez créer une règle pour détecter le démarrage ou l'arrêt d'une session par un utilisateur de votre organisation, puis recevoir une notification via Amazon SNS (par exemple, un SMS ou un e-mail) à propos de l'événement. Vous pouvez également configurer un CloudWatch événement pour lancer d'autres réponses. Pour de plus amples informations, veuillez consulter [Surveillance de l'activité des sessions à l'aide d'Amazon EventBridge (console)](session-manager-auditing.md#session-manager-auditing-eventbridge-events).
**Note**
La journalisation n'est pas disponible pour les sessions Session Manager qui se connectent via le réacheminement de port ou SSH. Cela est dû au fait que le protocole SSH chiffre toutes les données de session au sein de la connexion TLS sécurisée établie entre les Session Manager points de terminaison AWS CLI et et sert Session Manager uniquement de tunnel pour les connexions SSH.
## À qui est destiné Session Manager ?
+ Tout AWS client qui souhaite améliorer son niveau de sécurité, réduire ses frais opérationnels en centralisant le contrôle d'accès sur les nœuds gérés et réduire l'accès aux nœuds entrants.
+ Les experts en sécurité de l'information qui souhaitent surveiller et suivre l'accès aux nœuds et leur activité, fermer les ports entrants sur les nœuds gérés ou autoriser les connexions à des nœuds gérés sans adresse IP publique.
+ Administrateurs qui souhaitent accorder et révoquer des accès à partir d'un point central, et fournir aux utilisateurs une solution unique pour les nœuds gérés Linux, macOS et Windows Server.
+ Les utilisateurs qui souhaitent se connecter à un nœud géré en un seul clic depuis le navigateur ou AWS CLI sans avoir à fournir de clés SSH.
## Quelles sont les principales fonctionnalités Session Manager ?
+ **Prise en charge de nœuds gérés Windows Server, Linux et macOS**
Session Managervous permet d'établir des connexions sécurisées avec vos instances Amazon Elastic Compute Cloud (EC2), vos appareils périphériques, vos serveurs sur site et vos machines virtuelles (). VMs Pour obtenir une liste des types de systèmes d'exploitation pris en charge, consultez [Configuration de Session Manager](session-manager-getting-started.md).
**Note**
La prise en charge de Session Manager pour les machines sur site est assurée pour le niveau d'instances avancées uniquement. Pour plus d'informations, consultez [Activation du niveau d'instances avancées](fleet-manager-enable-advanced-instances-tier.md).
+ **Accès aux fonctionnalités de Session Manager via la console, l'interface de ligne de commande et le kit SDK**
Vous pouvez utiliser les Session Manager de l'une des façons suivantes :
La **console AWS Systems Manager ** inclut l'accès à toutes les fonctionnalités de Session Manager pour les administrateurs et les utilisateurs finaux. Vous pouvez effectuer n'importe quelle tâche liée à vos sessions via la console Systems Manager.
La console Amazon EC2 permet aux utilisateurs finaux de se connecter aux instances EC2 pour lesquelles des autorisations de session leur ont été accordées.
L'**AWS CLI** inclut l'accès aux fonctionnalités Session Manager pour les utilisateurs finaux. Vous pouvez démarrer une session, consulter la liste des sessions et y mettre fin définitivement en utilisant le AWS CLI.
**Note**
Pour utiliser les commandes AWS CLI d'exécution de session, vous devez utiliser la version 1.16.12 de la CLI (ou ultérieure) et vous devez avoir installé le Session Manager plug-in sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md). Pour afficher le pluginGitHub, voir [session-manager-plugin](https://github.com/aws/session-manager-plugin).
+ **Contrôle d'accès IAM**
Les politiques IAM vous permettent de contrôler quels membres de votre organisation peuvent démarrer des sessions sur les nœuds gérés et à quels nœuds ils peuvent accéder. Vous pouvez également fournir un accès temporaire à vos nœuds gérés. Par exemple, vous pouvez accorder à un ingénieur de garde (ou à un groupe d'ingénieurs de garde) l'accès aux serveurs de production uniquement pendant la durée de leur rotation.
+ **Prise en charge de la journalisation**
Session Manager vous offre des fonctionnalités d’historique de session de journalisation dans votre Compte AWS via l’intégration à d’autres Services AWS. Pour plus d'informations, consultez [Journalisation de l’activité de session](session-manager-auditing.md) et [Activation et désactivation de l’enregistrement de la session](session-manager-logging.md).
+ **Profils de shell configurables**
Session Manager vous propose des options de configuration des préférences de session. Ces profils personnalisables vous permettent de définir des préférences telles que les préférences du shell, les variables d'environnement, les répertoires de travail et l'exécution de plusieurs commandes au démarrage d'une session.
+ **Prise en charge du chiffrement des données clés des clients**
Vous pouvez configurer Session Manager pour chiffrer les journaux de données de session que vous envoyez à un bucket Amazon Simple Storage Service (Amazon S3) ou que vous diffusez vers CloudWatch un groupe de journaux de journaux. Vous pouvez également configurer Session Manager pour chiffrer davantage les données transmises entre les ordinateurs clients et vos nœuds gérés pendant vos sessions. Pour obtenir des informations, consultez [Activation et désactivation de l’enregistrement de la session](session-manager-logging.md) et [Configurer les préférences de session](session-manager-getting-started-configure-preferences.md).
+ **AWS PrivateLink prise en charge des nœuds gérés sans adresses IP publiques**
Vous pouvez également configurer des points de terminaison VPC pour Systems Manager afin de AWS PrivateLink sécuriser davantage vos sessions. AWS PrivateLink limite tout le trafic réseau entre vos nœuds gérés, Systems Manager et Amazon EC2 vers le réseau Amazon. Pour plus d’informations, consultez [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md).
+ **Tunnelisation**
Dans une session, utilisez un document de type session AWS Systems Manager (SSM) pour canaliser le trafic, tel que le protocole HTTP ou un protocole personnalisé, entre un port local sur un ordinateur client et un port distant sur un nœud géré.
+ **Commandes interactives**
Créez un document SSM de type session qui utilise une session pour exécuter de manière interactive une seule commande, ce qui vous permet de gérer les opérations pouvant être effectuées par les utilisateurs sur un nœud géré.
## Qu'est-ce qu'une session ?
Une session est une connexion établie à un nœud géré en utilisant Session Manager. Les sessions sont basées sur un canal de communication bidirectionnel sécurisé entre le client (vous) et l'instance gérée à un nœud géré qui diffuse les entrées et les sorties pour les commandes. Le trafic entre un client et un nœud géré est chiffré via TLS 1.2, et les demandes de création de la connexion sont signées via Sigv4. Cette communication bidirectionnelle permet le bash interactif et PowerShell l'accès aux nœuds gérés. Vous pouvez également utiliser une clé AWS Key Management Service (AWS KMS) pour chiffrer davantage les données au-delà du chiffrement TLS par défaut.
Supposons par exemple que John est un ingénieur de garde dans votre service informatique. Il reçoit la notification d'un problème qui lui exige de se connecter à distance à un nœud géré. Il peut s'agir par exemple d'une panne qui nécessite d'être réparée, ou d'une directive pour modifier une option de configuration simple sur un nœud. À l'aide de la AWS Systems Manager console, de la console Amazon EC2 ou de la AWS CLI, John démarre une session le connectant au nœud géré, exécute des commandes sur le nœud nécessaire pour effectuer la tâche, puis met fin à la session.
Lorsque John envoie la première commande pour démarrer la session, le service Session Manager authentifie son ID, vérifie les autorisations qui lui ont été accordées par une politique IAM, vérifie les paramètres de configuration (par exemple, les limites autorisées pour les sessions), et envoie un message à l'SSM Agent pour ouvrir la connexion bidirectionnelle. Une fois la connexion établie et après que John ait saisi la commande suivante, le résultat de la commande de l'SSM Agent est chargé vers ce canal de communication et renvoyé vers son ordinateur local.
**Topics**
+ [Comment mon organisation peut-elle tirer parti de Session Manager ?](#session-manager-benefits)
+ [À qui est destiné Session Manager ?](#session-manager-who)
+ [Quelles sont les principales fonctionnalités Session Manager ?](#session-manager-features)
+ [Qu'est-ce qu'une session ?](#what-is-a-session)
+ [Configuration de Session Manager](session-manager-getting-started.md)
+ [Utilisation de l’option Session Manager](session-manager-working-with.md)
+ [Journalisation de l’activité de session](session-manager-auditing.md)
+ [Activation et désactivation de l’enregistrement de la session](session-manager-logging.md)
+ [Schéma de document de session](session-manager-schema.md)
+ [Résolution des problèmes de Session Manager](session-manager-troubleshooting.md)
# Configuration de Session Manager
Avant d'utiliser AWS Systems Manager Session Manager pour vous connecter aux nœuds gérés de votre compte, suivez les étapes indiquées dans les rubriques suivantes.
**Topics**
+ [Étape 1 : Exécution des conditions Session Manager prérequises](session-manager-prerequisites.md)
+ [Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager](session-manager-getting-started-instance-profile.md)
+ [Étape 3 : Contrôler les accès de session aux nœuds gérés](session-manager-getting-started-restrict-access.md)
+ [Étape 4 : Configuration des préférences de session](session-manager-getting-started-configure-preferences.md)
+ [Étape 5 (facultative) : Restriction de l'accès aux commandes dans une session](session-manager-restrict-command-access.md)
+ [Étape 6 : (Facultatif) AWS PrivateLink À utiliser pour configurer un point de terminaison VPC pour Session Manager](session-manager-getting-started-privatelink.md)
+ [Étape 7 : (Facultatif) activez ou désactivez les autorisations administratives du compte ssm-user.](session-manager-getting-started-ssm-user-permissions.md)
+ [Étape 8 : (Facultatif) activer et contrôler les autorisations pour les connexions SSH via Session Manager](session-manager-getting-started-enable-ssh-connections.md)
# Étape 1 : Exécution des conditions Session Manager prérequises
Avant d'utiliser Session Manager, vérifiez que votre environnement respecte les conditions requises suivantes.
**conditions préalables requises de l’Session Manager**
| Exigence | Description |
| --- | --- |
| Systèmes d’exploitation pris en charge | Session Manager prend en charge la connexion aux instances Amazon Elastic Compute Cloud (Amazon EC2), ainsi qu'aux machines non EC2 de votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) qui utilisent le niveau d'*instances avancées*. Session Manager prend en charge les versions de système d'exploitation suivantes : Session Manager*prend en charge les instances EC2, les appareils de périphérie, les serveurs sur site et les machines virtuelles (VMs) dans votre environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) qui utilise le niveau d'instances avancées.* Pour de plus amples informations, sur les instances avancées, veuillez consulter [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md). **Linux et **macOS**** Session Managerprend en charge toutes les versions de Linux et macOS qui sont prises en charge par AWS Systems Manager. Pour plus d'informations, consultez [Systèmes d'exploitation et types de machines pris en charge](operating-systems-and-machine-types.md). ** Windows ** Session Manager prend en charge Windows Server 2012 et versions ultérieures. Microsoft Windows Server 2016 Nano n'est pas pris en charge. |
| SSM Agent | Au minimum, AWS Systems Manager SSM Agent la version 2.3.68.0 ou ultérieure doit être installée sur les nœuds gérés auxquels vous souhaitez vous connecter via des sessions. Pour utiliser l'option permettant de chiffrer les données de session à l'aide d'une clé créée dans AWS Key Management Service (AWS KMS), la version 2.3.539.0 ou ultérieure de SSM Agent doit être installée sur le nœud géré. Pour utiliser des profils de shell dans une session, SSM Agent version 3.0.161.0 ou version ultérieure doit être installé sur le nœud géré. Pour démarrer une session de réacheminement de port Session Manager ou SSH, SSM Agent version 3.0.222.0 ou version ultérieure doit être installé sur le nœud géré. Pour diffuser des données de session à l'aide d'Amazon CloudWatch Logs, SSM Agent la version 3.0.284.0 ou ultérieure doit être installée sur le nœud géré. Pour en savoir plus sur la façon de déterminer le numéro de version exécuté sur une instance, consultez [Vérification du numéro de version de l'SSM Agent](ssm-agent-get-version.md). Pour plus d'informations sur l'installation manuelle ou la mise à jour automatique de SSM Agent, veuillez consulter [Utilisation de l’option SSM Agent](ssm-agent.md). À propos du compte ssm-user A partir de la version 2.3.50.0 de SSM Agent, l'agent crée un compte utilisateur sur le nœud géré, avec des autorisations racine ou administrateur, nommé `ssm-user`. (Sur les versions antérieures à 2.3.612.0, le compte est créé lorsque SSM Agent démarre ou redémarre. Sur la version 2.3.612.0, et ultérieure, `ssm-user` est créé la première fois qu'une session démarre sur le nœud géré.) Les sessions sont lancées à l'aide des informations d'identification administratives de ce compte utilisateur. Pour obtenir des informations sur la limitation du contrôle administratif pour ce compte, veuillez consulter [Désactiver ou activer les autorisations administratives du compte ssm-user](session-manager-getting-started-ssm-user-permissions.md). ssm-user sur les contrôleurs de domaine Windows Server Depuis la version 2.3.612.0 de SSM Agent, le compte `ssm-user` n'est plus créé automatiquement sur les nœuds gérés qui sont utilisés en tant que contrôleurs de domaine Windows Server. Pour utiliser Session Manager sur une machine Windows Server fonctionnant comme contrôleur de domaine, vous devez créer le compte `ssm-user` manuellement, s'il n'est pas déjà présent, et affecter des autorisations d'administrateur de domaine à l'utilisateur. Sur Windows Server, SSM Agent définit un nouveau mot de passe pour le compte `ssm-user` chaque fois qu'une session commence, ce qui signifie que vous n'avez pas besoin de spécifier un mot de passe lors de la création du compte. |
| Connectivité aux points de terminaison | Les nœuds gérés que vous connectez doivent également autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/session-manager-prerequisites.html) Pour plus d’informations, consultez les rubriques suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/session-manager-prerequisites.html) Vous pouvez également vous connecter aux points de terminaison requis à l'aide de points de terminaison d'interface. Pour de plus amples informations, veuillez consulter [Étape 6 : (Facultatif) AWS PrivateLink À utiliser pour configurer un point de terminaison VPC pour Session Manager](session-manager-getting-started-privatelink.md). |
| AWS CLI | (Facultatif) Si vous utilisez le AWS Command Line Interface (AWS CLI) pour démarrer vos sessions (au lieu d'utiliser la AWS Systems Manager console ou la console Amazon EC2), la version 1.16.12 ou ultérieure de la CLI doit être installée sur votre machine locale. Vous pouvez appeler `aws --version` pour vérifier la version. Si vous devez installer ou mettre à niveau la CLI, reportez-vous à la section [Installation de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) dans le guide de AWS Command Line Interface l'utilisateur. 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. En outre, pour utiliser la CLI afin de gérer vos nœuds avec Session Manager, vous devez d'abord installer le plugin Session Manager sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md). |
| Activation du niveau d'instances avancées (environnements [hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types)) | Pour vous connecter à des machines non EC2 à l'aide deSession Manager, vous devez activer le niveau d'instances avancées dans Compte AWS et dans Région AWS lequel vous créez des activations hybrides pour enregistrer des machines non EC2 en tant que nœuds gérés. L'utilisation du niveau d'instance avancé est facturée. Pour plus d'informations sur le niveau d'instances avancées, consultez [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md). |
| Vérification des autorisations de fonction du service IAM (environnements [hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types)) | Les nœuds activés par hybride utilisent le rôle de service Gestion des identités et des accès AWS (IAM) spécifié lors de l'activation hybride pour communiquer avec les opérations de l'API Systems Manager. Cette fonction du service doit contenir les autorisations requises pour se connecter à vos machines [hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types) à l'aide de Session Manager. Si votre rôle de service contient la politique AWS gérée`AmazonSSMManagedInstanceCore`, les autorisations requises pour Session Manager sont déjà fournies. Si vous constatez que la fonction de service ne contient pas les autorisations requises, vous devez désenregistrer l'instance gérée et l'enregistrer auprès d'une nouvelle activation hybride utilisant une fonction de service IAM avec les autorisations requises. Pour plus d'informations sur l'annulation de l'enregistrement d'instances gérées, consultez [Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud](fleet-manager-deregister-hybrid-nodes.md). Pour plus d'informations sur la création des politiques IAM avec des autorisations Session Manager, consultez [Étape 2 : Vérification ou ajout d'autorisations d'instance pour Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-instance-profile.html). |
# Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager
Par défaut, AWS Systems Manager n'est pas autorisé à effectuer des actions sur vos instances. Vous pouvez fournir des autorisations d'instance au niveau du compte à l'aide d'un rôle Gestion des identités et des accès AWS (IAM), ou au niveau de l'instance à l'aide d'un profil d'instance. Si votre cas d'utilisation le permet, nous vous recommandons d'accorder l'accès au niveau du compte à l'aide de la configuration de gestion des hôtes par défaut. Si vous avez déjà configuré la configuration de gestion des hôtes par défaut pour votre compte à l'aide de la politique `AmazonSSMManagedEC2InstanceDefaultPolicy`, vous pouvez passer à l'étape suivante. Pour plus d'informations sur la Configuration de gestion des hôtes par défaut, consultez [Gestion automatique des instances EC2 avec la configuration par défaut de la gestion des hôtes](fleet-manager-default-host-management-configuration.md).
Vous pouvez également utiliser des profils d'instance pour fournir les autorisations requises à vos instances. Un profil d'instance transmet un rôle IAM à une instance Amazon EC2. Vous pouvez attacher un profil d'instance IAM à une instance Amazon EC2 lorsque vous la lancez ou à une instance préalablement lancée. Pour plus d'informations, consultez [Utilisation de profils d'instance](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-instanceprofile.html).
Pour les serveurs locaux ou les machines virtuelles (VMs), les autorisations sont fournies par le rôle de service IAM associé à l'activation hybride utilisée pour enregistrer vos serveurs sur site et auprès de Systems VMs Manager. Serveurs sur site et n'utilisez VMs pas de profils d'instance.
Si vous utilisez déjà d’autres outils Systems Manager, comme Run Command ou Parameter Store, il est possible qu’un profil d’instance avec les autorisations de base requises pour Session Manager soit déjà attaché à vos instances Amazon EC2. Si un profil d'instance contenant la politique AWS gérée `AmazonSSMManagedInstanceCore` est déjà attaché à vos instances, les autorisations requises Session Manager sont déjà fournies. Cela est également vrai si la fonction du service IAM utilisée dans votre activation hybride contient la politique gérée `AmazonSSMManagedInstanceCore`.
Toutefois, dans certains cas, vous pouvez avoir besoin de modifier les autorisations attachées à votre profil d'instance. Par exemple, vous souhaitez fournir un ensemble plus restreint d'autorisations d'instance, vous avez créé une politique personnalisée pour votre profil d'instance ou vous souhaitez utiliser le chiffrement Amazon Simple Storage Service (Amazon S3) AWS Key Management Service ou les options de chiffrement AWS KMS() pour sécuriser les données de session. Pour ces cas, effectuez l'une des actions suivantes pour autoriser l'exécution d'actions Session Manager sur vos instances :
+ **Intégration des autorisations pour les actions Session Manager dans un rôle IAM personnalisé**
Pour ajouter des autorisations pour Session Manager des actions à un rôle IAM existant qui ne repose pas sur la politique par défaut AWS fournie`AmazonSSMManagedInstanceCore`, suivez les étapes décrites dans. [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md)
+ **Création d'un rôle IAM personnalisé contenant uniquement des autorisations Session Manager**
Pour créer un rôle IAM qui contient uniquement des autorisations relatives aux actions Session Manager, suivez les étapes décrites sur la page [Création d'un rôle IAM personnalisé pour Session Manager](getting-started-create-iam-instance-profile.md).
+ **Création et utilisation d'un rôle IAM autorisant toutes les actions Systems Manager**
Pour créer un rôle IAM pour les instances gérées par Systems Manager qui utilise une politique par défaut fournie par AWS pour accorder toutes les autorisations de Systems Manager, suivez les étapes décrites dans [Configurer les autorisations d'instance requises pour Systems Manager](setup-instance-permissions.md).
**Topics**
+ [Ajouter des autorisations Session Manager à un rôle IAM existant](getting-started-add-permissions-to-existing-profile.md)
+ [Création d'un rôle IAM personnalisé pour Session Manager](getting-started-create-iam-instance-profile.md)
# Ajouter des autorisations Session Manager à un rôle IAM existant
Utilisez la procédure suivante pour ajouter des autorisations Session Manager à un rôle (IAM) Gestion des identités et des accès AWS existant. En ajoutant des autorisations à un rôle existant, vous pouvez améliorer la sécurité de votre environnement informatique sans avoir à utiliser la AWS `AmazonSSMManagedInstanceCore` politique relative aux autorisations par exemple.
**Note**
Veuillez noter les informations suivantes :
Notez que cette procédure suppose que votre rôle existant comprend déjà d'autres autorisations `ssm` Systems Manager relatives aux actions auxquelles vous souhaitez accorder l'accès. Employée seule, cette politique ne s'avère pas suffisante pour utiliser Session Manager.
L'exemple de politique suivant inclut une action `s3:GetEncryptionConfiguration`. Cette action est requise si vous avez choisi l'option **Appliquer le chiffrement du journal S3** dans les préférences de journalisation de Session Manager.
Si l'`ssmmessages:OpenControlChannel`autorisation est supprimée des politiques associées à votre profil d'instance IAM ou à votre rôle de service IAM, SSM Agent le nœud géré perd la connectivité avec le service Systems Manager dans le cloud. Cependant, la résiliation d'une connexion peut prendre jusqu'à 1 heure après la suppression de l'autorisation. Il s'agit du même comportement que lorsque le rôle d'instance IAM ou le rôle de service IAM est supprimé.
**Pour ajouter des autorisations Session Manager à un rôle existant (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation, choisissez **Rôles**.
1. Choisissez le nom du rôle auquel vous souhaitez ajouter les autorisations.
1. Choisissez l'onglet **Permissions** (Autorisations).
1. Sélectionnez **Ajouter des autorisations**, puis **Créer la politique en ligne**.
1. Sélectionnez l'onglet **JSON**.
1. Remplacez le contenu de politique par défaut par le contenu suivant. *key-name*Remplacez-le par le Amazon Resource Name (ARN) de la AWS Key Management Service clé (AWS KMS key) que vous souhaitez utiliser.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Pour de plus amples informations sur l'utilisation d'une clé CMK pour chiffrer les données de session, consultez [Activer le chiffrement des données de session par clé KMS (console)](session-preferences-enable-encryption.md).
Si vous n'avez pas l'intention d'utiliser le AWS KMS chiffrement pour les données de votre session, vous pouvez supprimer le contenu suivant de la politique.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Choisissez **Suivant : Balises**.
1. (Facultatif) Ajoutez des identifications en choisissant **Add tag** (Ajouter une identification), et en saisissant les identifications préférées de la politique.
1. Choisissez **Suivant : Vérification**.
1. Sur la page **Examiner une politique**, dans le champ **Nom**, saisissez un nom pour la politique en ligne, tel que **SessionManagerPermissions**.
1. (Facultatif) Dans le champ **Description**, saisissez une description pour la politique.
Sélectionnez **Créer une politique**.
Pour de plus amples informations sur les actions `ssmmessages`, consultez [Référence : ec2messages, ssmmessages et autres opérations d'API](systems-manager-setting-up-messageAPIs.md).
# Création d'un rôle IAM personnalisé pour Session Manager
Vous pouvez créer un rôle Gestion des identités et des accès AWS (IAM) qui accorde Session Manager l'autorisation d'effectuer des actions sur vos instances gérées Amazon EC2. Vous pouvez également inclure une politique pour accorder les autorisations nécessaires pour que les journaux de session soient envoyés à Amazon Simple Storage Service (Amazon S3) et Amazon CloudWatch Logs.
Après avoir créé le rôle IAM, pour plus d'informations sur la façon d'attacher le rôle à une instance, voir [Attacher ou remplacer un profil d'instance](https://aws.amazon.com/premiumsupport/knowledge-center/attach-replace-ec2-instance-profile/) sur le AWS re:Post site Web. Pour plus d'informations sur les profils d'instance et les rôles IAM, veuillez consulter les rubriques [Utilisation de profils d'instance](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) dans le *Guide de l'utilisateur IAM* et [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) dans le *Guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux*. Pour plus d’informations sur la création d’un rôle de service IAM pour les ordinateurs sur site, consultez [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-service-role.html).
**Topics**
+ [Création d'un rôle IAM avec les autorisations Session Manager minimales (console)](#create-iam-instance-profile-ssn-only)
+ [Création d'un rôle IAM avec des autorisations pour Session Manager Amazon S3 et CloudWatch Logs (console)](#create-iam-instance-profile-ssn-logging)
## Création d'un rôle IAM avec les autorisations Session Manager minimales (console)
Procédez comme suit pour créer un rôle IAM personnalisé avec une politique qui autorise uniquement des actions Session Manager sur vos instances.
**Création d'un profil d'instance avec des autorisations Session Manager minimales**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation, sélectionnez **Politiques**, puis **Créer une politique**. (Si un bouton **Get Started [Mise en route]** est affiché, sélectionnez-le, puis **Create Policy [Créer une politique]**.)
1. Sélectionnez l'onglet **JSON**.
1. Remplacez le contenu par défaut par la politique suivante. Pour chiffrer les données de session à l'aide de AWS Key Management Service (AWS KMS), *key-name* remplacez-le par le Amazon Resource Name (ARN) de AWS KMS key celui que vous souhaitez utiliser.
**Note**
Si l'`ssmmessages:OpenControlChannel`autorisation est supprimée des politiques associées à votre profil d'instance IAM ou à votre rôle de service IAM, SSM Agent le nœud géré perd la connectivité avec le service Systems Manager dans le cloud. Cependant, la résiliation d'une connexion peut prendre jusqu'à 1 heure après la suppression de l'autorisation. Il s'agit du même comportement que lorsque le rôle d'instance IAM ou le rôle de service IAM est supprimé.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation",
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Pour de plus amples informations sur l'utilisation d'une clé CMK pour chiffrer les données de session, consultez [Activer le chiffrement des données de session par clé KMS (console)](session-preferences-enable-encryption.md).
Si vous n'avez pas l'intention d'utiliser le AWS KMS chiffrement pour les données de votre session, vous pouvez supprimer le contenu suivant de la politique.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Choisissez **Suivant : Balises**.
1. (Facultatif) Ajoutez des identifications en choisissant **Add tag** (Ajouter une identification), et en saisissant les identifications préférées de la politique.
1. Choisissez **Suivant : Vérification**.
1. Sur la page **Examiner une politique**, dans le champ **Nom**, saisissez un nom pour la politique en ligne, tel que **SessionManagerPermissions**.
1. (Facultatif) Dans le champ **Description**, saisissez une description pour la politique.
1. Sélectionnez **Créer une politique**.
1. Dans le volet de navigation, sélectionnez **Rôles**, puis **Créer un rôle**.
1. Sur la page **Créer un rôle**, choisissez **Service AWS **, et pour **Cas d'utilisation**, choisissez **EC2**.
1. Choisissez **Suivant**.
1. Sur la page **Attached permissions policy** (Politique d'autorisations attachée), cochez la case située à gauche du nom de la politique que vous venez de créer, tel que **SessionManagerPermissions**.
1. Choisissez **Suivant**.
1. Sur la page **Review** (Vérifier), pour **Role name** (Nom du rôle), saisissez un nom pour le rôle IAM, tel que **MySessionManagerRole**.
1. (Facultatif) Dans le champ **Description du rôle**, saisissez une description pour le profil d'instance.
1. (Facultatif) Ajoutez des identifications en choisissant **Add tag** (Ajouter une identification), et en saisissant les identifications préférées du rôle.
Choisissez **Créer un rôle**.
Pour de plus amples informations sur les actions `ssmmessages`, veuillez consulter [Référence : ec2messages, ssmmessages et autres opérations d'API](systems-manager-setting-up-messageAPIs.md).
## Création d'un rôle IAM avec des autorisations pour Session Manager Amazon S3 et CloudWatch Logs (console)
Procédez comme suit pour créer un rôle IAM personnalisé avec une politique qui autorise des actions Session Manager sur vos instances. La politique fournit également les autorisations nécessaires pour que les journaux de session soient stockés dans des compartiments Amazon Simple Storage Service (Amazon S3) et des groupes de journaux CloudWatch Amazon Logs.
**Important**
Pour produire les journaux de session dans un compartiment Amazon S3 appartenant à un autre Compte AWS, vous devez ajouter l'autorisation `s3:PutObjectAcl` à la politique de rôle IAM. En outre, vous devez vous assurer que la politique relative aux compartiments accorde un accès intercompte au rôle IAM utilisé par le compte propriétaire pour accorder des autorisations Systems Manager aux instances gérées. Si le compartiment utilise le chiffrement KMS (Key Management Service), la politique KMS du compartiment doit également accorder cet accès intercompte. Pour plus d'informations sur la configuration des autorisations de compartiment intercomptes dans Amazon S3, veuillez consulter la rubrique [Accorder des autorisations intercomptes sur un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) du *Guide de l'utilisateur Amazon Simple Storage Service*. Si les autorisations intercomptes ne sont pas ajoutées, le compte qui possède le compartiment Amazon S3 ne peut pas accéder aux journaux de sortie de la session.
Pour en savoir plus sur la spécification des préférences de stockage des journaux de session, consultez [Activation et désactivation de l’enregistrement de la session](session-manager-logging.md).
**Pour créer un rôle IAM avec des autorisations pour Session Manager Amazon S3 et CloudWatch Logs (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation, sélectionnez **Politiques**, puis **Créer une politique**. (Si un bouton **Get Started [Mise en route]** est affiché, sélectionnez-le, puis **Create Policy [Créer une politique]**.)
1. Sélectionnez l'onglet **JSON**.
1. Remplacez le contenu par défaut par la politique suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/s3-prefix/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
},
{
"Effect": "Allow",
"Action": "kms:GenerateDataKey",
"Resource": "*"
}
]
}
```
------
1. Choisissez **Suivant : Balises**.
1. (Facultatif) Ajoutez des identifications en choisissant **Add tag** (Ajouter une identification), et en saisissant les identifications préférées de la politique.
1. Choisissez **Suivant : Vérification**.
1. Sur la page **Examiner une politique**, dans le champ **Nom**, saisissez un nom pour la politique en ligne, tel que **SessionManagerPermissions**.
1. (Facultatif) Dans le champ **Description**, saisissez une description pour la politique.
1. Sélectionnez **Créer une politique**.
1. Dans le volet de navigation, sélectionnez **Rôles**, puis **Créer un rôle**.
1. Sur la page **Créer un rôle**, choisissez **Service AWS **, et pour **Cas d'utilisation**, choisissez **EC2**.
1. Choisissez **Suivant**.
1. Sur la page **Attached permissions policy** (Politique d'autorisations attachée), cochez la case située à gauche du nom de la politique que vous venez de créer, tel que **SessionManagerPermissions**.
1. Choisissez **Suivant**.
1. Sur la page **Review** (Vérifier), pour **Role name** (Nom du rôle), saisissez un nom pour le rôle IAM, tel que **MySessionManagerRole**.
1. (Facultatif) Dans le champ **Role description** (Description du rôle), saisissez la description du nouveau rôle.
1. (Facultatif) Ajoutez des identifications en choisissant **Add tag** (Ajouter une identification), et en saisissant les identifications préférées du rôle.
1. Choisissez **Créer un rôle**.
# Étape 3 : Contrôler les accès de session aux nœuds gérés
Vous accordez ou révoquez Session Manager l'accès aux nœuds gérés en utilisant des politiques Gestion des identités et des accès AWS (IAM). Vous pouvez créer une politique et l'associer à un utilisateur ou à un groupe IAM qui spécifie les nœuds gérés auxquels l'utilisateur ou le groupe peut se connecter. Vous pouvez également spécifier les opérations d'API Session Manager que l'utilisateur ou les groupes peuvent effectuer sur ces nœuds gérés.
Pour vous aider à démarrer avec les politiques d'autorisations IAM pour Session Manager, nous avons créé des exemples de politiques pour un utilisateur final et un utilisateur administrateur. Vous ne pouvez utiliser ces politiques qu'avec des modifications mineures. Vous pouvez également les utiliser comme guide pour créer des politiques IAM personnalisées. Pour de plus amples informations, veuillez consulter [Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md). Pour obtenir des informations sur la création de politiques IAM et la façon de les attacher à des utilisateurs ou des groupes, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) et [Ajout et suppression de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.
**À propos des formats des ARN d’ID de session**
Lorsque vous créez une politique IAM pour l'accès de Session Manager, vous spécifiez un ID de session dans le cadre d'Amazon Resource Name (ARN). L'ID de session inclut le nom d'utilisateur en tant que variable. Pour illustrer cela, voici le format d'un ARN Session Manager et un exemple :
```
arn:aws:ssm:region-id:account-id:session/session-id
```
Par exemple :
```
arn:aws:ssm:us-east-2:123456789012:session/JohnDoe-1a2b3c4d5eEXAMPLE
```
Pour de plus amples informations sur l'utilisation de variables dans les politiques IAM, consultez [Éléments de politique IAM : Variables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
**Topics**
+ [Démarrer une session shell par défaut en spécifiant le document de session par défaut dans les politiques IAM](getting-started-default-session-document.md)
+ [Démarrer une session avec un document en spécifiant les documents de session dans les politiques IAM](getting-started-specify-session-document.md)
+ [Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md)
+ [Exemples de politiques IAM supplémentaires pour Session Manager](getting-started-restrict-access-examples.md)
# Démarrer une session shell par défaut en spécifiant le document de session par défaut dans les politiques IAM
Lorsque vous configurez Session Manager pour votre session Compte AWS ou lorsque vous modifiez les préférences de session dans la console Systems Manager, le système crée un document de session SSM appelé`SSM-SessionManagerRunShell`. Il s'agit du document de session par défaut. Session Manager utilise ce document pour enregistrer vos préférences de session, qui incluent des informations telles que les suivantes :
+ Emplacement dans lequel vous souhaitez enregistrer les données de session, tel qu'un bucket Amazon Simple Storage Service (Amazon S3) ou un groupe de journaux CloudWatch Amazon Logs.
+ Un identifiant de clé AWS Key Management Service (AWS KMS) pour chiffrer les données de session.
+ Si la prise en charge Run As est autorisée pour vos sessions.
Voici un exemple des informations contenues dans le document des préférences de session `SSM-SessionManagerRunShell`.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyCWLogGroup",
"cloudWatchEncryptionEnabled": false,
"kmsKeyId": "1a2b3c4d",
"runAsEnabled": true,
"runAsDefaultUser": "RunAsUser"
}
}
```
Par défaut, Session Manager utilise le document de session par défaut lorsqu'un utilisateur démarre une session à partir de la AWS Management Console. Cela s'applique Fleet Manager soit Session Manager à la console Systems Manager, soit à EC2 Connect dans la console Amazon EC2. Session Managerutilise également le document de session par défaut lorsqu'un utilisateur démarre une session à l'aide d'une AWS CLI commande comme dans l'exemple suivant :
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
Pour démarrer une session shell par défaut, vous devez spécifier le document de session par défaut dans la politique IAM, comme le montre l’exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"*"
]
}
]
}
```
------
# Démarrer une session avec un document en spécifiant les documents de session dans les politiques IAM
Si vous utilisez la commande AWS CLI [start-session](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en utilisant le document de session par défaut, vous pouvez omettre le nom du document. Le système appelle automatiquement le document de session `SSM-SessionManagerRunShell`.
Dans tous les autres cas, vous devez spécifier une valeur pour le paramètre `document-name`. Lorsqu'un utilisateur indique le nom d'un document de session dans une commande, le système vérifie sa politique IAM pour vérifier qu'il est autorisé à accéder au document. S'il n'est pas autorisé, la demande de connexion échoue. Les exemples suivants incluent le paramètre `document-name` dans le document de session `AWS-StartPortForwardingSession`.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
Pour un exemple de spécification d’un document de session Session Manager dans une politique IAM, consultez [Démarrage rapide - Politiques d'utilisateur final pour Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
**Note**
Pour démarrer une session en utilisant SSH, vous devez effectuer les étapes de configuration sur le nœud géré cible *et* sur l’ordinateur local de l’utilisateur. Pour obtenir des informations, consultez [(Facultatif) Activer et contrôler les autorisations pour les connexions SSH via Session Manager](session-manager-getting-started-enable-ssh-connections.md).
# Exemple de stratégies IAM pour Session Manager
Utilisez les exemples de cette section pour vous aider à créer des politiques Gestion des identités et des accès AWS (IAM) fournissant les autorisations d'Session Manageraccès les plus couramment requises.
**Note**
Vous pouvez également utiliser une AWS KMS key politique pour contrôler les entités IAM (utilisateurs ou rôles) qui Comptes AWS ont accès à votre clé KMS. Pour plus d'informations, consultez la section [Présentation de la gestion de l'accès à vos AWS KMS ressources](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) et de [l'utilisation des politiques clés AWS KMS dans](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) le *guide du AWS Key Management Service développeur*.
**Topics**
+ [Démarrage rapide - Politiques d'utilisateur final pour Session Manager](#restrict-access-quickstart-end-user)
+ [Démarrage rapide - Politique d'administrateur pour Session Manager](#restrict-access-quickstart-admin)
## Démarrage rapide - Politiques d'utilisateur final pour Session Manager
Utilisez les exemples suivants pour créer des politiques d'utilisateur final IAM pour Session Manager.
Vous pouvez créer une politique qui permet aux utilisateurs de démarrer des sessions uniquement à partir de la Session Manager console et AWS Command Line Interface (AWS CLI), uniquement à partir de la console Amazon Elastic Compute Cloud (Amazon EC2), ou à partir des trois.
Ces politiques permettent aux utilisateurs finaux de démarrer une session sur un nœud géré particulier et de mettre fin à leurs propres sessions uniquement. Consultez la page [Exemples de politiques IAM supplémentaires pour Session Manager](getting-started-restrict-access-examples.md) pour obtenir des exemples de personnalisation de la politique.
Dans les exemples de politiques suivants, remplacez chacune *example resource placeholder* par vos propres informations.
Sélectionnez parmi les onglets suivants pour afficher l'exemple de politique pour la plage d'accès aux sessions que vous souhaitez fournir.
------
#### [ Gestionnaire de session and Fleet Manager ]
Utilisez cet exemple de politique pour donner aux utilisateurs la possibilité de démarrer et de reprendre des sessions à partir des consoles Session Manager et Fleet Manager uniquement.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilisez cet exemple de politique pour permettre aux utilisateurs de démarrer des sessions uniquement à partir de la console Amazon EC2. Cette politique ne fournit pas toutes les autorisations nécessaires pour démarrer des sessions à partir de la console Session Manager et de l' AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
------
#### [ AWS CLI ]
Utilisez cet exemple de politique pour donner aux utilisateurs la possibilité de démarrer et de reprendre des sessions à partir de l’ AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
**Note**
`SSM-SessionManagerRunShell` est le nom par défaut du document SSM créé par Session Manager pour stocker vos préférences de configuration de session. Vous pouvez créer un document de session personnalisé et le spécifier dans cette politique à la place. Vous pouvez également spécifier le document `AWS-StartSSHSession` fourni par AWS pour les utilisateurs qui lancent des sessions à l'aide de SSH. Pour obtenir des informations sur les étapes de configuration nécessaires à la prise en charge de sessions en utilisant SSH, consultez [(Facultatif) Activer et contrôler les autorisations pour les connexions SSH à l’aide du Session Manager](session-manager-getting-started-enable-ssh-connections.md).
L'autorisation `kms:GenerateDataKey` permet la création d'une clé de chiffrement des données qui sera utilisé pour chiffrer les données de session. Si vous comptez utiliser le chiffrement AWS Key Management Service (AWS KMS) pour les données de votre session, remplacez-le par *key-name* le nom de ressource Amazon (ARN) de la clé KMS que vous souhaitez utiliser, au format indiqué`arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`. Si vous ne voulez pas utiliser le chiffrement de clé KMS pour vos données de session, supprimez le contenu suivant de la politique.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-name"
}
```
Pour plus d'informations sur l'utilisation AWS KMS pour le chiffrement des données de session, consultez[Activer le chiffrement des données de session par clé KMS (console)](session-preferences-enable-encryption.md).
L’autorisation pour [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) est nécessaire pour les cas où un utilisateur tente de démarrer une session à partir de la console Amazon EC2, mais le SSM Agent doit d’abord être mis à jour vers la version minimale requise pour Session Manager. Run Command est utilisé pour envoyer une commande à l’instance afin de mettre à jour l’agent.
## Démarrage rapide - Politique d'administrateur pour Session Manager
Utilisez les exemples suivants pour créer des politiques d'administrateur IAM pour Session Manager.
Ces politiques autorisent les administrateurs à démarrer une session sur les nœuds gérés qui sont balisées avec `Key=Finance,Value=WebServers`, à créer, mettre à jour et supprimer des préférences, et à mettre fin à leurs propres sessions uniquement. Consultez la page [Exemples de politiques IAM supplémentaires pour Session Manager](getting-started-restrict-access-examples.md) pour obtenir des exemples de personnalisation de la politique.
Vous pouvez créer une politique qui permet aux administrateurs d'effectuer ces tâches uniquement à partir de la Session Manager console et AWS CLI uniquement à partir de la console Amazon EC2, ou à partir des trois.
Dans les exemples de politiques suivants, remplacez chacune *example resource placeholder* par vos propres informations.
Sélectionnez parmi les onglets suivants pour voir l'exemple de politique pour le scénario d'accès que vous souhaitez prendre en charge.
------
#### [ Gestionnaire de session and CLI ]
Utilisez cet exemple de politique pour permettre aux administrateurs d'effectuer les tâches liées à la session uniquement à partir de la console Session Manager et de l' AWS CLI. Cette politique ne fournit pas toutes les autorisations nécessaires pour effectuer les tâches liées à la session à partir de la console Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilisez cet exemple de politique pour permettre aux administrateurs d'effectuer les tâches liées à la session uniquement à partir de la console Amazon EC2. Cette politique ne fournit pas toutes les autorisations nécessaires pour effectuer les tâches liées à la session à partir de la console Session Manager et de l' AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Gestionnaire de session, CLI, and Amazon EC2 ]
Utilisez cet exemple de politique pour permettre aux administrateurs d'effectuer les tâches liées à la session à partir de la console Session Manager, de l' AWS CLI et de la console Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
**Note**
L’autorisation pour [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) est nécessaire dans les cas où un utilisateur tente de démarrer une session à partir de la console Amazon EC2, mais une commande doit d’abord être envoyée pour mettre à jour l’SSM Agent.
# Exemples de politiques IAM supplémentaires pour Session Manager
Les exemples de politiques suivants vous accompagnent dans la création d'une politique Gestion des identités et des accès AWS (IAM) personnalisée pour tous les scénarios d'accès utilisateur à Session Manager que vous souhaitez prendre en charge.
**Topics**
+ [Exemple 1 : octroi d'un accès aux documents depuis la console](#grant-access-documents-console-example)
+ [Exemple 2 : restriction de l'accès à des nœuds gérés spécifiques](#restrict-access-example-instances)
+ [Exemple 3 : restriction de l'accès en fonction des balises](#restrict-access-example-instance-tags)
+ [Exemple 4 : autorisation d'un utilisateur à mettre fin uniquement aux sessions qu'il a démarrées](#restrict-access-example-user-sessions)
+ [Exemple 5 : octroi d'un accès complet (administrateur) à toutes les sessions](#restrict-access-example-full-access)
## Exemple 1 : octroi d'un accès aux documents depuis la console
Vous pouvez autoriser les utilisateurs à spécifier un document personnalisé lorsqu'ils lancent une session à l'aide de la console Session Manager. L'exemple de politique IAM suivant accorde l'autorisation d'accéder à des documents dont le nom commence par **SessionDocument-** dans la Région AWS et sur le Compte AWS spécifiés.
Pour utiliser cette politique, remplacez chacune *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:ListDocuments"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SessionDocument-*"
]
}
]
}
```
------
**Note**
La console Session Manager ne prend en charge que les documents de session dont le `sessionType` et `Standard_Stream` et utilisés pour définir les préférences de session. Pour de plus amples informations, veuillez consulter [Schéma de document de session](session-manager-schema.md).
## Exemple 2 : restriction de l'accès à des nœuds gérés spécifiques
Vous pouvez créer une politique IAM qui définit les nœuds gérés auxquels un utilisateur est autorisé à se connecter à l'aide du gestionnaire de session. Par exemple, la politique suivante accorde à un utilisateur l'autorisation de démarrer, de terminer et de reprendre ses sessions sur trois nœuds spécifiques. La politique interdit à l'utilisateur de se connecter à des nœuds autres que ceux spécifiés.
**Note**
Pour les utilisateurs fédérés, consultez [Exemple 4 : autorisation d'un utilisateur à mettre fin uniquement aux sessions qu'il a démarrées](#restrict-access-example-user-sessions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890EXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-abcdefghijEXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0e9d8c7b6aEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
## Exemple 3 : restriction de l'accès en fonction des balises
Vous pouvez restreindre l'accès à des nœuds gérés en fonction de balises spécifiques. Dans l'exemple suivant, l'utilisateur est autorisé à démarrer et à reprendre des sessions (`Effect: Allow, Action: ssm:StartSession, ssm:ResumeSession`) sur n'importe quel nœud géré (`Resource: arn:aws:ec2:region:987654321098:instance/*`) à condition que le nœud soit un nœud Finance WebServer (`ssm:resourceTag/Finance: WebServer`). Si l'utilisateur envoie une commande à un nœud géré non balisé ou qui possède une balise autre que `Finance: WebServer`, le résultat de la commande affiche `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Vous pouvez créer des politiques IAM qui permettent à un utilisateur de démarrer des sessions sur des nœuds gérés qui contiennent plusieurs balises. La politique suivante permet à l'utilisateur de démarrer des sessions sur des nœuds gérés qui contiennent les balises spécifiées. Si un utilisateur envoie une commande à un nœud géré qui ne contient pas ces balises, le résultat de la commande affiche `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:StartSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag-key1":[
"tag-value1"
],
"ssm:resourceTag/tag-key2":[
"tag-value2"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Pour plus d'informations sur la création de politiques IAM, consultez [Politiques gérées et politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) dans le *Guide de l'utilisateur IAM*. Pour plus d’informations sur le balisage des nœuds gérés, consultez [Balisage de vos ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) dans le *Guide de l’utilisateur Amazon EC2* (le contenu s’applique aux nœuds gérés Windows et Linux). Pour plus d'informations sur le renforcement de votre posture de sécurité vis-à-vis des commandes de niveau racine non autorisées sur vos nœuds gérés, consultez [Limitation de l'accès aux commandes de niveau racine via l'SSM Agent](ssm-agent-restrict-root-level-commands.md).
## Exemple 4 : autorisation d'un utilisateur à mettre fin uniquement aux sessions qu'il a démarrées
Session Managerpropose deux méthodes pour contrôler les sessions auxquelles un utilisateur fédéré de votre entreprise Compte AWS est autorisé à mettre fin.
+ Utilisez la variable `{aws:userid}` dans une politique d'autorisation Gestion des identités et des accès AWS (IAM). Les utilisateurs fédérés ne peuvent terminer que les sessions qu'ils ont démarrées. Pour les utilisateurs non fédérés, utilisez la méthode 1. Pour les utilisateurs fédérés, utilisez la méthode 2.
+ Utilisez les balises fournies par les AWS balises dans une politique d'autorisation IAM. Dans la politique, vous incluez une condition qui permet aux utilisateurs de ne terminer que les sessions marquées avec des balises spécifiques fournies par AWS. Cette méthode fonctionne pour tous les comptes, y compris ceux qui utilisent la fédération IDs pour accorder l'accès à AWS.
### Méthode 1 : octroyer TerminateSession des privilèges à l'aide de la variable `{aws:username}`
La politique IAM suivante permet à un utilisateur de consulter toutes les sessions IDs de votre compte. Toutefois, les utilisateurs ne peuvent interagir avec les nœuds gérés que par le biais des sessions qu'ils ont démarrées. Un utilisateur auquel vous attribuez la politique suivante ne peut pas se connecter ni mettre fin aux sessions des autres utilisateurs. Cette politique utilise la variable `{aws:username}`.
**Note**
Cette méthode ne fonctionne pas pour les comptes qui autorisent l'accès AWS via Federated. IDs
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:DescribeSessions"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"ssm:TerminateSession"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
### Méthode 2 : octroyer TerminateSession des privilèges à l'aide de balises fournies par AWS
Vous pouvez contrôler les sessions qu'un utilisateur peut terminer en utilisant des variables de clé de balise conditionnelle spécifiques dans une politique utilisateur IAM. La condition spécifie que l'utilisateur ne peut terminer que les sessions qui sont marquées avec une ou deux des variables de clé de balise spécifiques et une valeur spécifiée.
Lorsqu'un de vos utilisateurs Compte AWS démarre une session, Session Manager applique deux balises de ressources à la session. La première balise de ressource est `aws:ssmmessages:target-id`, avec laquelle vous spécifiez l'ID de la cible à laquelle l'utilisateur est autorisé à se terminer. L'autre balise de ressource est `aws:ssmmessages:session-id`, avec une valeur au format `role-id:caller-specified-role-name`.
**Note**
Session Manager ne prend pas en charge les balises personnalisées pour cette politique de contrôle d'accès IAM. Vous devez utiliser les balises de ressources fournies par AWS, décrites ci-dessous.
** `aws:ssmmessages:target-id` **
Avec cette clé de balise, vous incluez l'ID de nœud géré comme valeur dans la politique. Dans le bloc de politique suivant, l'instruction de condition permet à un utilisateur de mettre fin uniquement au nœud i-02573cafcfEXAMPLE.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:target-id": [
"i-02573cafcfEXAMPLE"
]
}
}
}
]
}
```
Si l'utilisateur tente de mettre fin à une session pour laquelle il n'a pas obtenu cette autorisation `TerminateSession`, il reçoit une `AccessDeniedException` erreur.
** `aws:ssmmessages:session-id` **
Cette clé de balise inclut une variable pour l'ID de session comme valeur dans la demande de démarrage d'une session.
L'exemple suivant illustre une politique pour les cas où le type d'appelant est `User`. La valeur que vous fournissez pour `aws:ssmmessages:session-id` est l'ID de l'utilisateur. Dans cet exemple, `AIDIODR4TAW7CSEXAMPLE` représente l'ID d'un utilisateur de votre Compte AWS. Pour récupérer l'identifiant d'un utilisateur dans votre Compte AWS, utilisez la commande IAM,`get-user`. Pour plus d'informations, voir [get-user](https://docs.aws.amazon.com/IAM/latest/UserGuide/get-user.html) dans la Gestion des identités et des accès AWS section du guide de l'utilisateur *IAM*.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"AIDIODR4TAW7CSEXAMPLE"
]
}
}
}
]
}
```
L'exemple suivant illustre une politique pour les cas où le type d'appelant est `AssumedRole`. Vous pouvez utiliser la variable `{aws:userid}` pour la valeur que vous attribuez à `aws:ssmmessages:session-id`. Vous pouvez également coder en dur un ID de rôle pour la valeur que vous attribuez à `aws:ssmmessages:session-id`. Si vous codez en dur un ID de rôle, vous devez fournir la valeur au format `role-id:caller-specified-role-name`. Par exemple, `AIDIODR4TAW7CSEXAMPLE:MyRole`.
Pour que les balises système soient appliquées, l'ID de rôle que vous fournissez ne peut contenir que les caractères suivants : Lettres Unicode, 0-9 `_`, espace`.`, `:`, `/`, `=`, `+`, `-`, `@` et `\`.
Pour récupérer l'ID de rôle d'un rôle dans votre Compte AWS, utilisez la `get-caller-identity` commande. Pour plus d'informations, reportez-vous [get-caller-identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html)à la référence des AWS CLI commandes.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}*"
]
}
}
}
]
}
```
Si un utilisateur tente de mettre fin à une session pour laquelle il n'a pas obtenu cette autorisation `TerminateSession`, il reçoit une erreur `AccessDeniedException`.
**`aws:ssmmessages:target-id`** et **`aws:ssmmessages:session-id`**
Vous pouvez également créer des politiques IAM qui permettent à un utilisateur de terminer des sessions marquées avec les deux balises système, comme illustré dans cet exemple.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:TerminateSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/aws:ssmmessages:target-id":[
"i-02573cafcfEXAMPLE"
],
"ssm:resourceTag/aws:ssmmessages:session-id":[
"${aws:userid}*"
]
}
}
}
]
}
```
## Exemple 5 : octroi d'un accès complet (administrateur) à toutes les sessions
La politique IAM suivante permet à un utilisateur d'interagir pleinement avec tous les nœuds gérés et toutes les sessions créées par l'ensemble des utilisateurs des nœuds. Elle doit être accordée uniquement à un administrateur qui nécessite un contrôle total sur les activités Session Manager de votre organisation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:StartSession",
"ssm:TerminateSession",
"ssm:ResumeSession",
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
# Étape 4 : Configuration des préférences de session
Les utilisateurs auxquels des autorisations administratives ont été accordées dans leur politique Gestion des identités et des accès AWS (IAM) peuvent configurer les préférences de session, notamment les suivantes :
+ Activation d'Exécuter en tant que support pour les nœuds gérés Linux. Cela permet de démarrer des sessions en utilisant les informations d'identification d'un utilisateur du système d'exploitation spécifié au lieu des informations d'identification d'un `ssm-user` compte généré par le système qui AWS Systems Manager Session Manager peut être créé sur un nœud géré.
+ Configurez Session Manager pour utiliser AWS KMS key le chiffrement afin de fournir une protection supplémentaire aux données transmises entre les machines clientes et les nœuds gérés.
+ Configurez Session Manager pour créer et envoyer des journaux d'historique de session vers un bucket Amazon Simple Storage Service (Amazon S3) ou un groupe de journaux CloudWatch Amazon Logs. Les données de journaux stockées peuvent ensuite être utilisées en tant que rapports sur les connexions à vos nœuds gérés et les commandes exécutées au cours des sessions.
+ Configurer les délais d'expiration de session. Vous pouvez utiliser ce paramètre pour spécifier quand mettre fin à une session après une période d'inactivité.
+ Configurez Session Manager de sorte à utiliser des profils de shell configurables. Ces profils personnalisables vous permettent de définir des préférences dans les sessions telles que les préférences du shell, les variables d'environnement, les répertoires de travail et l'exécution de plusieurs commandes au démarrage d'une session.
Pour plus d'informations sur les autorisations qui sont nécessaires pour configurer les préférences Session Manager, veuillez consulter la rubrique [Accorder ou révoquer des autorisations utilisateur pour mettre à jour des préférences Session Manager](preference-setting-permissions.md).
**Topics**
+ [Accorder ou révoquer des autorisations utilisateur pour mettre à jour des préférences Session Manager](preference-setting-permissions.md)
+ [Spécifier une valeur de délai d'expiration d'une session inactive](session-preferences-timeout.md)
+ [Spécification de la durée de session maximale](session-preferences-max-timeout.md)
+ [Autoriser les profils de shell configurables](session-preferences-shell-config.md)
+ [Activation de la prise en charge de Run As pour les nœuds gérés Linux et macOS](session-preferences-run-as.md)
+ [Activer le chiffrement des données de session par clé KMS (console)](session-preferences-enable-encryption.md)
+ [Création d'un document de préférences Session Manager (ligne de commande)](getting-started-create-preferences-cli.md)
+ [Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md)
Pour plus d'informations sur l'utilisation de la console Systems Manager pour configurer des options pour la journalisation des données de session, consultez les rubriques suivantes.
+ [Journalisation des données de session avec Amazon S3 (console)](session-manager-logging-s3.md)
+ [Données de session de streaming à l'aide d'Amazon CloudWatch Logs (console)](session-manager-logging-cwl-streaming.md)
+ [Enregistrement des données de session à l'aide d'Amazon CloudWatch Logs (console)](session-manager-logging-cloudwatch-logs.md)
# Accorder ou révoquer des autorisations utilisateur pour mettre à jour des préférences Session Manager
Les préférences de compte sont stockées sous forme de documents AWS Systems Manager (SSM) pour chacun Région AWS. Pour qu'un utilisateur puisse mettre à jour des préférences de session sur votre compte, il doit détenir les autorisations nécessaires pour accéder au type de document SSM sur lequel ces préférences sont stockées. Ces autorisations sont accordées par le biais d'une politique Gestion des identités et des accès AWS (IAM).
**Politique administrateur pour autoriser la création et la mise à jour des préférences**
Un administrateur peut utiliser la politique suivante pour créer et mettre à jour des préférences à tout moment. La politique suivante autorise l'accès et la mise à jour du document `SSM-SessionManagerRunShell` sur le compte us-east-2 123456789012.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
**Politique utilisateur pour interdire la mise à jour des préférences**
Utilisez la politique suivante pour interdire aux utilisateurs finaux de votre compte de mettre à jour ou remplacer des préférences Session Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
# Spécifier une valeur de délai d'expiration d'une session inactive
Session Manager, un outil dans AWS Systems Manager, vous permet de spécifier la durée pendant laquelle un utilisateur doit rester inactif avant que le système ne mette fin à une session. Par défaut, les sessions expirent au bout de 20 minutes d'inactivité. Vous pouvez modifier ce paramètre de sorte à spécifier qu'une session expire entre 1 et 60 minutes d'inactivité. Certaines agences de sécurité informatique professionnelles recommandent de définir des délais d'inactivité de session de 15 minutes maximum.
Le temporisateur d'expiration de la session d'inactivité se réinitialise lorsqu'il Session Manager reçoit des entrées côté client. Ces entrées incluent, sans toutefois s'y limiter :
+ Saisie au clavier dans le terminal
+ Redimensionner les événements du terminal ou de la fenêtre du navigateur
+ Reconnexion de session (ResumeSession), qui peut se produire en raison d'interruptions du réseau, de la gestion des onglets du navigateur ou WebSocket de déconnexions
Étant donné que ces événements réinitialisent le délai d'inactivité, une session peut rester active plus longtemps que le délai d'expiration configuré, même en l'absence de commandes directes du terminal.
Si vos exigences de sécurité imposent des limites de durée de session strictes quelle que soit l'activité, utilisez le paramètre *Durée maximale de session* en plus du délai d'inactivité. Pour de plus amples informations, veuillez consulter [Spécification de la durée de session maximale](session-preferences-max-timeout.md).
**Pour autoriser le délai d'expiration d'une session inactive (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Spécifiez le temps nécessaire à un utilisateur pour passer à l'état inactif avant qu'une session se termine, dans le champ **minutes**, sous **Délai d'expiration d'une session inactive**.
1. Choisissez **Enregistrer**.
# Spécification de la durée de session maximale
Session Manager, un outil dans AWS Systems Manager, vous permet de définir la durée maximale d'une session avant qu'elle ne se termine. Par défaut, les sessions n'ont pas de durée maximale. La valeur que vous spécifiez pour la durée maximale de session doit être comprise entre 1 et 1 440 minutes.
**Pour spécifier la durée de session maximale (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Activez la case à cocher en regard de **Enable maximum session duration (Activer la durée de session maximale)**.
1. Spécifiez la durée maximale de la session avant son terme dans le champ **minutes** sous **Maximum session duration (Durée de session maximale)**.
1. Choisissez **Enregistrer**.
# Autoriser les profils de shell configurables
Par défaut, les sessions sur les instances EC2 pour Linux commencent à utiliser le shell Bourne (sh). Vous préférerez peut-être utiliser un autre shell, bash par exemple. En autorisant les profils de shell configurables, vous pouvez personnaliser des préférences de session, telles que des préférences de shell, des variables d'environnement, des répertoires de travail et l'exécution de plusieurs commandes au démarrage d'une session.
**Important**
Systems Manager ne vérifie pas les commandes ou scripts de votre profil shell pour voir les modifications qu'ils apporteraient à une instance avant leur exécution. Pour limiter la capacité d'un utilisateur à modifier des commandes ou scripts entrés dans son profil shell, nous vous recommandons de procéder comme suit :
Créez un document de type session personnalisé pour vos utilisateurs et rôles Gestion des identités et des accès AWS (IAM). Modifiez ensuite la politique IAM pour ces utilisateurs et rôles de sorte que l'opération d'API `StartSession` puisse seulement utiliser le document de type session que vous avez créé pour ceux-ci. Pour plus d'informations, consultez [Création d'un document de préférences Session Manager (ligne de commande)](getting-started-create-preferences-cli.md) et [Démarrage rapide - Politiques d'utilisateur final pour Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
Modifiez la politique IAM pour vos utilisateurs et rôles IAM afin de refuser l'accès à l'opération d'API `UpdateDocument` pour la ressource de document de type session que vous créez. Vos utilisateurs et rôles sont ainsi autorisés à utiliser le document que vous avez créé pour leurs préférences de session mais pas à en modifier les paramètres.
**Pour activer des profils de shell configurables**
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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Spécifiez les variables d'environnement, les préférences de shell ou les commandes que vous voulez exécuter au démarrage de votre session dans les champs des systèmes d'exploitation applicables.
1. Sélectionnez **Enregistrer**.
Voici quelques exemples des commandes qui peuvent être ajoutées à votre profil de shell.
Sur les instances Linux, passez au shell bash et au répertoire /usr.
```
exec /bin/bash
cd /usr
```
Affichez un horodatage et un message de bienvenue au démarrage d'une session.
------
#### [ Linux & macOS ]
```
timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
user=$(whoami)
echo $timestamp && echo "Welcome $user"'!'
echo "You have logged in to a production instance. Note that all session activity is being logged."
```
------
#### [ Windows ]
```
$timestamp = (Get-Date).ToString("yyyy-MM-ddTH:mm:ssZ")
$splitName = (whoami).Split("\")
$user = $splitName[1]
Write-Host $timestamp
Write-Host "Welcome $user!"
Write-Host "You have logged in to a production instance. Note that all session activity is being logged."
```
------
Affichez l'activité dynamique du système au démarrage d'une session.
------
#### [ Linux & macOS ]
```
top
```
------
#### [ Windows ]
```
while ($true) { Get-Process | Sort-Object -Descending CPU | Select-Object -First 30; `
Start-Sleep -Seconds 2; cls
Write-Host "Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName";
Write-Host "------- ------ ----- ----- ----- ------ -- -----------"}
```
------
# Activation de la prise en charge de Run As pour les nœuds gérés Linux et macOS
Par défaut, Session Manager authentifie les connexions lancées à l'aide des informations d'identification d'un compte `ssm-user` généré par le système qui est créé sur un nœud géré. (Sur les machines Linux et macOS, le compte est ajouté à `/etc/sudoers/`.) Si vous préférez, vous pouvez authentifier les sessions à l’aide des informations d’identification d’un compte utilisateur de système d’exploitation (OS) ou d’un utilisateur de domaine pour les instances jointes à un Active Directory. Dans ce cas, le Gestionnaire de session vérifie que le compte de système d’exploitation (OS) que vous avez spécifié existe sur le nœud, ou dans le domaine, avant de démarrer la session. Si vous essayez de démarrer une session à l’aide d’un compte OS qui n’existe pas sur le nœud ou dans le domaine, la connexion échoue.
**Note**
Le gestionnaire de session ne prend pas en charge l'utilisation d'un compte utilisateur `root` de système d'exploitation pour authentifier les connexions. Pour les sessions authentifiées à l'aide d'un compte utilisateur de système d'exploitation, les politiques au niveau du système d'exploitation et de répertoire du nœud, telles que les restrictions de connexion ou les restrictions d'utilisation des ressources système, peuvent ne pas s'appliquer.
**Comment ça marche**
Si vous activez la prise en charge de Run As pour les sessions, le système vérifie les autorisations d'accès comme suit :
1. Pour l'utilisateur qui démarre la session, son entité IAM (utilisateur ou rôle) a-t-elle été balisée avec `SSMSessionRunAs = os user account name` ?
Si oui, le nom d'utilisateur de système d'exploitation (SE) existe-t-il sur le nœud géré ? Si c'est le cas, démarrer la session. Si ce n'est pas le cas, ne pas autoriser une session à démarrer.
Si l'entité IAM *n'a pas* été balisée avec `SSMSessionRunAs = os user account name`, passez à l'étape 2.
1. Si l'entité IAM n'a pas été taguée`SSMSessionRunAs = os user account name`, un nom d'utilisateur du système d'exploitation a-t-il été spécifié dans les Session Manager préférences Compte AWS de ?
Si oui, le nom d'utilisateur de système d'exploitation (SE) existe-t-il sur le nœud géré ? Si c'est le cas, démarrer la session. Si ce n'est pas le cas, ne pas autoriser une session à démarrer.
**Note**
Lorsque vous activez la prise en charge de l'exécution en tant que, cela empêche le Gestionnaire de session de démarrer des sessions à l'aide du compte `ssm-user` sur un nœud géré. Cela signifie que si Session Manager ne réussit pas la connexion à l'aide du compte utilisateur du système d'exploitation spécifié, il ne reviendra pas à la connexion à l'aide de la méthode par défaut.
Si vous activez l'exécution en tant que sans spécifier de compte de système d'exploitation (SE) ni baliser une entité IAM et que vous n'avez pas spécifié de compte de système d'exploitation (SE) dans les préférences du Gestionnaire de session, les tentatives de connexion à la session échoueront.
**Pour activer Exécuter en tant que support pour les nœuds gérés Linux et 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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Cochez la case en regard de **Activer Exécuter en tant que support des instances Linux**.
1. Effectuez l’une des actions suivantes :
+ **Option 1** : dans le champ **Nom d'utilisateur de système d'exploitation**, saisissez le nom du compte utilisateur de système d'exploitation (SE) que vous souhaitez utiliser pour démarrer les sessions. Avec cette option, toutes les sessions sont exécutées par le même utilisateur du système d'exploitation pour tous les utilisateurs de votre système Compte AWS qui se connectent en utilisantSession Manager.
+ **Option 2** (Recommandé) : choisir le lien **Ouvrir la console IAM**. Dans le panneau de navigation, sélectionnez **Users (Utilisateurs)** ou **Roles (Rôles)**. Sélectionnez l'entité (utilisateur ou rôle) à laquelle ajouter des balises, puis sélectionnez l'onglet **Tags (Balises)**. Entrez `SSMSessionRunAs` pour le nom de la clé. Saisissez le nom d'un compte utilisateur de système d'exploitation (SE) pour la valeur de la clé. Sélectionnez **Enregistrer les modifications**.
Avec cette option, vous pouvez spécifier des utilisateurs de système d'exploitation (SE) uniques pour différentes entités IAM si vous le souhaitez. Pour plus d’informations sur le balisage des entités IAM (utilisateurs ou rôles), consultez la section [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l’utilisateur IAM*.
Voici un exemple.
![\[Capture d'écran de la spécification de balises pour l'autorisation Exécuter en tant que de Session Manager.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/ssn-run-as-tags.png)
1. Choisissez **Enregistrer**.
# Activer le chiffrement des données de session par clé KMS (console)
Utilisez AWS Key Management Service (AWS KMS) pour créer et gérer des clés de chiffrement. Avec AWS KMS, vous pouvez contrôler l'utilisation du chiffrement dans un large éventail d'applications Services AWS et dans celles-ci. Vous pouvez spécifier que les données de session transmises entre vos nœuds gérés et les machines locales des utilisateurs de votre Compte AWS réseau sont chiffrées à l'aide du chiffrement par clé KMS. (Cela s'ajoute au chiffrement TLS 1.2/1.3 AWS déjà fourni par défaut.) Pour chiffrer les données de Session Manager session, créez une clé KMS *symétrique* à l'aide de. AWS KMS
AWS KMS le chiffrement est disponible pour `Standard_Stream``InteractiveCommands`, et les types de `NonInteractiveCommands` session. Pour utiliser l'option permettant de chiffrer les données de session à l'aide d'une clé créée dans AWS KMS, la version 2.3.539.0 ou ultérieure de AWS Systems Manager SSM Agent doit être installée sur le nœud géré.
**Note**
Vous devez autoriser AWS KMS le chiffrement afin de réinitialiser les mots de passe de vos nœuds gérés depuis la AWS Systems Manager console. Pour de plus amples informations, veuillez consulter [Réinitialisation d'un mot de passe sur un nœud géré](fleet-manager-reset-password.md#managed-instance-reset-a-password).
Vous pouvez utiliser une clé que vous avez créée dans votre Compte AWS. Vous pouvez également utiliser une clé qui a été créée dans un Compte AWS différent. Le créateur de la clé dans un autre Compte AWS doit vous fournir les autorisations nécessaires pour utiliser la clé.
Une fois que vous avez activé le chiffrement de clé KMS pour vos données de session, les utilisateurs qui démarrent les sessions et les nœuds gérés auxquels ils se connectent doivent avoir l'autorisation d'utiliser la clé. Vous autorisez l'utilisation de la clé KMS Session Manager via des politiques Gestion des identités et des accès AWS (IAM). Pour plus d’informations, consultez les rubriques suivantes :
+ Ajoutez AWS KMS des autorisations pour les utilisateurs de votre compte :[Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md).
+ Ajoutez AWS KMS des autorisations pour les nœuds gérés dans votre compte :[Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager](session-manager-getting-started-instance-profile.md).
Pour plus d'informations sur la création et la gestion de clés KMS, veuillez consulter le [https://docs.aws.amazon.com/kms/latest/developerguide/](https://docs.aws.amazon.com/kms/latest/developerguide/).
Pour plus d'informations sur l'utilisation du AWS CLI pour activer le chiffrement par clé KMS des données de session de votre compte, consultez [Création d'un document de préférences Session Manager (ligne de commande)](getting-started-create-preferences-cli.md) ou[Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md).
**Note**
L'utilisation de clés KMS entraîne des frais. Pour obtenir des informations, veuillez consulter [Tarification AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
**Pour activer le chiffrement des données de session par clé KMS (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Activez la case à cocher en regard de **Enable KMS encryption (Activer le chiffrement KMS)**.
1. Effectuez l'une des actions suivantes :
+ Cliquez sur le bouton en regard de **Select a KMS key in my current account** (Sélectionner une clé dans mon compte actuel), puis sélectionnez une clé dans la liste.
-ou-
Sélectionnez le bouton en regard de **Entrer un alias de clé KMS ou un ARN de clé KMS**. Saisissez manuellement un alias de clé KMS pour une clé créée dans votre compte actuel, ou saisissez l'Amazon Resource Name (ARN) de clé pour une clé dans un autre compte. Voici quelques exemples :
+ Alias de clé : `alias/my-kms-key-alias`
+ ARN de clé : `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`
-ou-
Sélectionnez **Create new key (Créer une clé)** pour créer une clé KMS dans votre compte. Une fois que vous avez créé la nouvelle clé, revenez à l'onglet **Préférences** et sélectionnez la clé pour chiffrer les données de session dans votre compte.
Pour plus d'informations sur le partage de clés, voir [Autoriser un Comptes AWS utilisateur externe à accéder à une clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-external-accounts) dans le *manuel du AWS Key Management Service développeur*.
1. Choisissez **Enregistrer**.
# Création d'un document de préférences Session Manager (ligne de commande)
Utilisez la procédure suivante pour créer des documents SSM qui définissent vos préférences pour les AWS Systems Manager Session Manager sessions. Vous pouvez utiliser le document pour configurer les options de session, notamment le chiffrement des données, la durée de session et la journalisation. Par exemple, vous pouvez spécifier si vous souhaitez stocker les données du journal de session dans un bucket Amazon Simple Storage Service (Amazon S3) ou dans un groupe de journaux CloudWatch Amazon Logs. Vous pouvez créer des documents qui définissent des préférences générales pour toutes les sessions pour un Compte AWS et Région AWS, ou qui définissent des préférences pour des sessions individuelles.
**Note**
Vous pouvez également configurer les préférences générales de session à l'aide de la console Session Manager.
Les documents utilisés pour définir les préférences de Session Manager doivent comporter un `sessionType` `Standard_Stream`. Pour plus d'informations sur les documents de session, veuillez consulter la rubrique [Schéma de document de session](session-manager-schema.md).
Pour plus d'informations sur l'utilisation de la ligne de commande afin de mettre à jour les préférences Session Manager existantes, veuillez consulter la rubrique [Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md).
Pour un exemple de création de préférences de session en utilisant CloudFormation, consultez le [document Create a Systems Manager pour les Session Manager préférences](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples) dans le *Guide de AWS CloudFormation l'utilisateur*.
**Note**
Cette procédure décrit comment créer des documents pour définir Session Manager les préférences au Compte AWS niveau. Pour créer des documents qui seront utilisés pour définir les préférences au niveau de la session, spécifiez une valeur autre que `SSM-SessionManagerRunShell` pour les entrées de commande liées au nom de fichier.
Pour utiliser votre document afin de définir les préférences des sessions démarrées à partir de l' AWS Command Line Interface (AWS CLI), indiquez le nom du document comme valeur du paramètre `--document-name`. Pour définir les préférences des sessions démarrées depuis la console Session Manager, vous pouvez saisir ou sélectionner le nom de votre document dans une liste.
**Pour créer des préférences Session Manager (ligne de commande)**
1. Créez un fichier JSON sur votre ordinateur local avec un nom tel que `SessionManagerRunShell.json`, puis collez le contenu suivant dans le fichier.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": false,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
Vous pouvez aussi transmettre des valeurs à vos préférences de session en utilisant des paramètres plutôt qu'en codant les valeurs en dur, comme l'illustre l'exemple suivant.
```
{
"schemaVersion":"1.0",
"description":"Session Document Parameter Example JSON Template",
"sessionType":"Standard_Stream",
"parameters":{
"s3BucketName":{
"type":"String",
"default":""
},
"s3KeyPrefix":{
"type":"String",
"default":""
},
"s3EncryptionEnabled":{
"type":"Boolean",
"default":"false"
},
"cloudWatchLogGroupName":{
"type":"String",
"default":""
},
"cloudWatchEncryptionEnabled":{
"type":"Boolean",
"default":"false"
}
},
"inputs":{
"s3BucketName":"{{s3BucketName}}",
"s3KeyPrefix":"{{s3KeyPrefix}}",
"s3EncryptionEnabled":"{{s3EncryptionEnabled}}",
"cloudWatchLogGroupName":"{{cloudWatchLogGroupName}}",
"cloudWatchEncryptionEnabled":"{{cloudWatchEncryptionEnabled}}",
"kmsKeyId":""
}
}
```
1. Spécifiez où vous souhaitez envoyer les données de session. Vous pouvez spécifier un nom de compartiment S3 (avec un préfixe facultatif) ou un nom de groupe de CloudWatch journaux de journaux. Si vous souhaitez continuer à chiffrer des données entre le client local et les nœuds gérés, fournissez la clé KMS à utiliser pour le chiffrement. Voici un exemple.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**Note**
Si vous ne souhaitez pas chiffrer les données de journaux, remplacez `true` par `false` pour `s3EncryptionEnabled`.
Si vous n'envoyez pas de journaux à un compartiment Amazon S3 ou à un groupe de CloudWatch journaux de journaux, si vous ne souhaitez pas chiffrer les données de session actives ou si vous ne souhaitez pas activer le support Run As pour les sessions de votre compte, vous pouvez supprimer les lignes correspondant à ces options. Assurez-vous que la dernière ligne de la section `inputs` ne se termine pas par une virgule.
Si vous ajoutez un ID de clé KMS pour chiffrer vos données de session, les utilisateurs qui démarrent les sessions et les nœuds gérés auxquels ils se connectent doivent avoir l'autorisation d'utiliser la clé. Vous fournissez l'autorisation d'utiliser la clé KMS avec Session Manager via des politiques IAM. Pour plus d’informations, consultez les rubriques suivantes :
Ajoutez AWS KMS des autorisations pour les utilisateurs de votre compte : [Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md)
Ajoutez AWS KMS des autorisations pour les nœuds gérés dans votre compte : [Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager](session-manager-getting-started-instance-profile.md)
1. Enregistrez le fichier.
1. Dans le répertoire où vous avez créé le fichier JSON, exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--name SSM-SessionManagerRunShell \
--content "file://SessionManagerRunShell.json" \
--document-type "Session" \
--document-format JSON
```
------
#### [ Windows ]
```
aws ssm create-document ^
--name SSM-SessionManagerRunShell ^
--content "file://SessionManagerRunShell.json" ^
--document-type "Session" ^
--document-format JSON
```
------
#### [ PowerShell ]
```
New-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentType "Session" `
-DocumentFormat JSON
```
------
Si elle aboutit, la commande renvoie un résultat semblable au suivant :
```
{
"DocumentDescription": {
"Status": "Creating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "1",
"HashType": "Sha256",
"CreatedDate": 1547750660.918,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "1"
}
}
```
# Mettre à jour les préférences Session Manager (ligne de commande)
La procédure suivante décrit comment utiliser votre outil de ligne de commande préféré pour modifier les AWS Systems Manager Session Manager préférences de Compte AWS la zone sélectionnée Région AWS. Utilisez Session Manager les préférences pour spécifier les options de journalisation des données de session dans un bucket Amazon Simple Storage Service (Amazon S3) ou un groupe de journaux CloudWatch Amazon Logs. Vous pouvez également utiliser des préférences Session Manager pour chiffrer vos données de session.
**Pour mettre à jour les préférences Session Manager (ligne de commande)**
1. Créez un fichier JSON sur votre ordinateur local avec un nom tel que `SessionManagerRunShell.json`, puis collez le contenu suivant dans le fichier.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
1. Spécifiez où vous souhaitez envoyer les données de session. Vous pouvez spécifier un nom de compartiment S3 (avec un préfixe facultatif) ou un nom de groupe de CloudWatch journaux de journaux. Si vous souhaitez chiffrer davantage les données entre le client local et les nœuds gérés, fournissez le code AWS KMS key à utiliser pour le chiffrement. Voici un exemple.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**Note**
Si vous ne souhaitez pas chiffrer les données de journaux, remplacez `true` par `false` pour `s3EncryptionEnabled`.
Si vous n'envoyez pas de journaux à un compartiment Amazon S3 ou à un groupe de CloudWatch journaux de journaux, si vous ne souhaitez pas chiffrer les données de session actives ou si vous ne souhaitez pas activer le support Run As pour les sessions de votre compte, vous pouvez supprimer les lignes correspondant à ces options. Assurez-vous que la dernière ligne de la section `inputs` ne se termine pas par une virgule.
Si vous ajoutez un ID de clé KMS pour chiffrer vos données de session, les utilisateurs qui démarrent les sessions et les nœuds gérés auxquels ils se connectent doivent avoir l'autorisation d'utiliser la clé. Vous autorisez l'utilisation de la clé KMS Session Manager via des politiques Gestion des identités et des accès AWS (IAM). Pour plus d’informations, consultez les rubriques suivantes :
Ajoutez AWS KMS des autorisations pour les utilisateurs de votre compte :[Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md).
Ajoutez AWS KMS des autorisations pour les nœuds gérés dans votre compte :[Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager](session-manager-getting-started-instance-profile.md).
1. Enregistrez le fichier.
1. Dans le répertoire où vous avez créé le fichier JSON, exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm update-document \
--name "SSM-SessionManagerRunShell" \
--content "file://SessionManagerRunShell.json" \
--document-version "\$LATEST"
```
------
#### [ Windows ]
```
aws ssm update-document ^
--name "SSM-SessionManagerRunShell" ^
--content "file://SessionManagerRunShell.json" ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
```
Update-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentVersion '$LATEST'
```
------
Si elle aboutit, la commande renvoie un résultat semblable au suivant :
```
{
"DocumentDescription": {
"Status": "Updating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "2",
"HashType": "Sha256",
"CreatedDate": 1537206341.565,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "2"
}
}
```
# Étape 5 (facultative) : Restriction de l'accès aux commandes dans une session
Vous pouvez limiter les commandes qu'un utilisateur peut exécuter dans une AWS Systems Manager Session Manager session en utilisant un document de `Session` type personnalisé AWS Systems Manager (SSM). Dans ce document, vous définissez la commande qui est exécutée lorsque l'utilisateur démarre une session et les paramètres qu'il peut fournir à la commande. Le paramètre `Session` du document `schemaVersion` doit être défini sur 1.0 et le paramètre `sessionType` du document doit être défini sur `InteractiveCommands`. Vous pouvez ensuite créer des politiques Gestion des identités et des accès AWS (IAM) permettant aux utilisateurs d'accéder uniquement aux documents `Session` que vous définissez. Pour de plus amples informations sur l'utilisation des politiques IAM pour restreindre l'accès aux commandes dans une session, consultez [Exemples de politique IAM pour les commandes interactives](#interactive-command-policy-examples).
Les documents marqués du signe `sessionType` de ne `InteractiveCommands` sont pris en charge que pour les sessions démarrées à partir du AWS Command Line Interface (AWS CLI). L'utilisateur fournit le nom du document personnalisé en tant que valeur du paramètre `--document-name` et fournit toutes les valeurs des paramètres de commande à l'aide de l'option `--parameters`. Pour de plus amples informations sur l'exécution des commandes interactives, consultez [Démarrage d'une session (commandes interactives et non interactives)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands).
Mettez en œuvre la procédure suivante pour créer un document SSM personnalisé de type `Session` qui définit la commande qu'un utilisateur est autorisé à exécuter.
## Restreindre l'accès aux commandes dans une session (console)
**Pour restreindre les commandes qu'un utilisateur peut exécuter dans une session Session Manager (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, cliquez sur **Documents**.
1. Sélectionnez **Create command or session (Créer une commande ou une session)**.
1. Pour **Name (Nom)**, saisissez un nom évocateur pour le document.
1. Pour **Document type (Type de document)**, sélectionnez **Session document (Document de session)**.
1. Entrez le contenu de votre document qui définit la commande qu'un utilisateur peut exécuter dans une session Session Manager au format JSON ou YAML, comme illustré dans l'exemple suivant.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Sélectionnez **Créer un document**.
## Restreindre l'accès aux commandes dans une session (ligne de commande)
**Avant de commencer**
Si ce n'est pas déjà fait, installez et configurez le AWS Command Line Interface (AWS CLI) ou le Outils AWS pour PowerShell. Pour plus d'informations, consultez la section [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) et [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
**Pour restreindre les commandes qu'un utilisateur peut exécuter dans une session Session Manager (ligne de commande)**
1. Créez un fichier JSON ou YAML pour le contenu de votre document qui définit la commande qu'un utilisateur peut exécuter dans une session Session Manager, comme illustré dans l'exemple suivant.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Exécutez les commandes suivantes pour créer un document SSM en utilisant votre contenu qui définit la commande qu'un utilisateur peut exécuter dans une session Session Manager.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/documentContent.json \
--name "exampleAllowedSessionDocument" \
--document-type "Session"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\documentContent.json ^
--name "exampleAllowedSessionDocument" ^
--document-type "Session"
```
------
#### [ PowerShell ]
```
$json = Get-Content -Path "C:\path\to\file\documentContent.json" | Out-String
New-SSMDocument `
-Content $json `
-Name "exampleAllowedSessionDocument" `
-DocumentType "Session"
```
------
## Les paramètres de commande interactifs et le AWS CLI
Plusieurs façons permettent de définir des paramètres de commande interactifs lors de l'utilisation de la AWS CLI. En fonction du système d'exploitation (OS) de votre machine cliente que vous utilisez pour vous connecter aux nœuds gérés AWS CLI, la syntaxe que vous fournissez pour les commandes contenant des caractères spéciaux ou d'échappement peut être différente. Les exemples suivants montrent les différentes manières dont vous pouvez fournir des paramètres de commande lorsque vous utilisez le AWS CLI et comment gérer les caractères spéciaux ou d'échappement.
Les paramètres stockés dans Parameter Store peuvent être référencés dans AWS CLI les paramètres de votre commande, comme indiqué dans l'exemple suivant.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
L'exemple suivant montre l'utilisation d'une syntaxe abrégée avec la AWS CLI pour transmettre des paramètres.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters command="ifconfig"
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters command="ipconfig"
```
------
Vous pouvez également fournir des paramètres en JSON, comme illustré dans l'exemple suivant.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["ifconfig"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["ipconfig"]}'
```
------
Les paramètres peuvent également être stockés dans un fichier JSON et fournis au AWS CLI , comme indiqué dans l'exemple suivant. Pour de plus amples informations sur l'utilisation de paramètres de la AWS CLI à partir d'un fichier, consultez [Chargement de paramètres AWS CLI à partir d'un fichier](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-file.html) dans le *Guide de l'utilisateur AWS Command Line Interface *.
```
{
"command": [
"my command"
]
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters file://complete/path/to/file/parameters.json
```
------
Vous pouvez également générer un AWS CLI squelette à partir d'un fichier d'entrée JSON, comme illustré dans l'exemple suivant. *Pour plus d'informations sur la génération de AWS CLI squelettes à partir de fichiers d'entrée JSON, consultez la section [Génération de AWS CLI squelettes et de paramètres d'entrée à partir d'un fichier d'entrée JSON ou YAML](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-skeleton.html) dans le Guide de l'AWS Command Line Interface utilisateur.*
```
{
"Target": "instance-id",
"DocumentName": "MyInteractiveCommandDocument",
"Parameters": {
"command": [
"my command"
]
}
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--cli-input-json file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--cli-input-json file://complete/path/to/file/parameters.json
```
------
Lorsque des caractères d'échappement sont placés entre guillemets, vous devez ajouter des barres obliques inverses supplémentaires aux caractères d'échappement, comme l'illustre l'exemple suivant.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
Pour plus d'informations sur l'utilisation de guillemets avec les paramètres de commande dans la AWS CLI, consultez [Utilisation de guillemets avec des chaînes dans la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-quoting-strings.html) dans le *Guide de l'utilisateur AWS Command Line Interface *.
## Exemples de politique IAM pour les commandes interactives
Vous pouvez créer des politiques IAM permettant aux utilisateurs d'accéder uniquement aux documents `Session` que vous définissez. Les commandes qu'un utilisateur peut exécuter dans une session Session Manager sont ainsi limitées uniquement aux commandes définies dans vos documents SSM personnalisés de type `Session`.
**Autoriser un utilisateur à exécuter une commande interactive sur un seul nœud géré**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Autoriser un utilisateur à exécuter une commande interactive sur tous les nœuds gérés**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Autoriser un utilisateur à exécuter plusieurs commandes interactives sur tous les nœuds gérés**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document-2"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
# Étape 6 : (Facultatif) AWS PrivateLink À utiliser pour configurer un point de terminaison VPC pour Session Manager
Vous pouvez renforcer la sécurité de vos nœuds gérés en configurant AWS Systems Manager pour qu'il utilise un point de terminaison Virtual Private Cloud (VPC) d'interface. Les points de terminaison de l'interface sont alimentés par AWS PrivateLink une technologie qui vous permet d'accéder en privé à Amazon Elastic Compute Cloud (Amazon EC2) et à Systems APIs Manager à l'aide d'adresses IP privées.
AWS PrivateLink restreint tout le trafic réseau entre vos nœuds gérés, Systems Manager et Amazon EC2 vers le réseau Amazon. (Les nœuds gérés n'ont pas accès à Internet). De même, vous n'avez pas besoin d'une passerelle Internet, d'un périphérique NAT ni d'une passerelle réseau privé virtuel.
Pour plus d’informations sur la création d’un point de terminaison d’un VPC, voir [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md).
L'alternative à l'utilisation d'un point de terminaison de VPC est l'activation de l'accès Internet sortant sur vos nœuds gérés. Dans ce cas, les nœuds gérés doivent également autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants :
+ `ec2messages.region.amazonaws.com`
+ `ssm.region.amazonaws.com`
+ `ssmmessages.region.amazonaws.com`
Systems Manager utilise le dernier de ces points de terminaison, `ssmmessages.region.amazonaws.com`, pour appeler le service Session Manager dans le cloud à partir de SSM Agent.
Pour utiliser des fonctionnalités facultatives telles que le chiffrement AWS Key Management Service (AWS KMS), le streaming des CloudWatch journaux vers Amazon CloudWatch Logs (Logs) et l'envoi de journaux vers Amazon Simple Storage Service (Amazon S3), vous devez autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants :
+ `kms.region.amazonaws.com`
+ `logs.region.amazonaws.com`
+ `s3.region.amazonaws.com`
Pour de plus amples informations sur les points de terminaison requis pour Systems Manager, veuillez consulter [Référence : ec2messages, ssmmessages et autres opérations d'API](systems-manager-setting-up-messageAPIs.md).
# Étape 7 : (Facultatif) activez ou désactivez les autorisations administratives du compte ssm-user.
À partir de la version 2.3.50.0 de AWS Systems Manager SSM Agent, l'agent crée un compte utilisateur local appelé `ssm-user` et l'ajoute à `/etc/sudoers` (LinuxetmacOS) ou au groupe Administrateurs (). Windows Sur les versions de l'agent antérieures à 2.3.612.0, le compte est créé la première fois que l'SSM Agent démarre ou redémarre après l'installation. Sur la version 2.3.612.0 et version ultérieure, le compte `ssm-user` est créé la première fois qu'une session est démarrée sur un nœud. Il s'`ssm-user`agit de l'utilisateur du système d'exploitation (OS) par défaut lorsqu'une AWS Systems Manager Session Manager session est démarrée. SSM Agentla version 2.3.612.0 a été publiée le 8 mai 2019.
Si vous souhaitez interdire aux utilisateurs Session Manager d'exécuter des commandes administratives sur un nœud, vous pouvez mettre à jour les autorisations du compte `ssm-user`. Vous pouvez restaurer ces autorisations après qu'elles ont été supprimées.
**Topics**
+ [Gestion des autorisations de compte sudo ssm-user sous Linux et macOS](#ssm-user-permissions-linux)
+ [Gérer les autorisations administrateur de compte ssm-user sur Windows Server](#ssm-user-permissions-windows)
## Gestion des autorisations de compte sudo ssm-user sous Linux et macOS
Utilisez l'une des procédures suivantes pour activer ou désactiver les autorisations de compte sudo ssm-user sur les nœuds gérés Linux et macOS.
**Utiliser Run Command pour modifier les autorisations sudo ssm-user (console)**
+ Exécutez la procédure décrite sur la page [Exécution des commande à partir de la console](running-commands-console.md) en appliquant les valeurs suivantes :
+ Pour **Command document (Document de commande)**, sélectionnez `AWS-RunShellScript`.
+ Pour supprimer un accès sudo, dans la zone **Command parameters (Paramètres de la commande)**, collez la commande suivante dans la zone **Commands (Commandes)** :
```
cd /etc/sudoers.d
echo "#User rules for ssm-user" > ssm-agent-users
```
-ou-
Pour restaurer un accès sudo, dans la zone **Command parameters (Paramètres de la commande)**, collez la commande suivante dans **Commands (Commandes)** :
```
cd /etc/sudoers.d
echo "ssm-user ALL=(ALL) NOPASSWD:ALL" > ssm-agent-users
```
**Utiliser la ligne de commande pour modifier des autorisations sudo ssm-user (AWS CLI)**
1. Connectez-vous au nœud géré et exécutez la commande suivante.
```
sudo -s
```
1. Modifiez le répertoire de travail à l'aide de la commande suivante.
```
cd /etc/sudoers.d
```
1. Ouvrez le fichier nommé `ssm-agent-users` pour le modifier.
1. Pour supprimer l'accès sudo, supprimez la ligne suivante.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
-ou-
Pour restaurer l'accès sudo, ajoutez la ligne suivante.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
1. Enregistrez le fichier.
## Gérer les autorisations administrateur de compte ssm-user sur Windows Server
Utilisez l'une des procédures suivantes pour activer ou désactiver les autorisations administrateur de compte ssm-user sur les nœuds gérés Windows Server.
**Utiliser Run Command pour modifier les autorisations administrateur (console)**
+ Exécutez la procédure décrite sur la page [Exécution des commande à partir de la console](running-commands-console.md) en appliquant les valeurs suivantes :
Pour **Command document (Document de commande)**, sélectionnez `AWS-RunPowerShellScript`.
Pour supprimer un accès administrateur, dans la zone **Command parameters (Paramètres de la commande)**, collez la commande suivante dans la zone **Commands (Commandes)**.
```
net localgroup "Administrators" "ssm-user" /delete
```
-ou-
Pour restaurer un accès administrateur, dans la zone **Command parameters (Paramètres de la commande)**, collez la commande suivante dans la zone **Commands (Commandes)**.
```
net localgroup "Administrators" "ssm-user" /add
```
**Utilisation de la fenêtre d'invite de commande ou PowerShell pour modifier les autorisations administrateur**
1. Connectez-vous au nœud géré et ouvrez PowerShell ou la fenêtre d'invite de commande.
1. Pour supprimer un accès administrateur, exécutez la commande suivante.
```
net localgroup "Administrators" "ssm-user" /delete
```
-ou-
Pour restaurer un accès administrateur, exécutez la commande suivante.
```
net localgroup "Administrators" "ssm-user" /add
```
**Utilisation de la console Windows pour modifier les autorisations administrateur**
1. Connectez-vous au nœud géré et ouvrez PowerShell ou la fenêtre d'invite de commande.
1. À partir de la ligne de commande, exécutez `lusrmgr.msc` pour ouvrir la console **Utilisateurs et groupes locaux**.
1. Ouvrez le répertoire **Utilisateurs**, puis **ssm-user**.
1. Dans l'onglet **Membre de**, effectuez l'une des opérations suivantes :
+ Pour supprimer un accès administrateur, sélectionnez **Administrateurs**, puis **Supprimer**.
-ou-
Pour restaurer un accès administrateur, saisissez **Administrators** dans la zone de texte, puis sélectionnez **Add (Ajouter)**.
1. Sélectionnez **OK**.
# Étape 8 : (Facultatif) activer et contrôler les autorisations pour les connexions SSH via Session Manager
Vous pouvez autoriser les utilisateurs de votre compte Compte AWS à utiliser le AWS Command Line Interface (AWS CLI) pour établir des connexions Secure Shell (SSH) aux nœuds gérés à l'aide AWS Systems Manager Session Manager de. Les utilisateurs qui se connectent à l'aide de SSH peuvent également copier des fichiers entre leurs ordinateurs locaux et les nœuds gérés à l'aide de SCP (Secure Copy Protocol). Vous pouvez utiliser cette fonctionnalité pour vous connecter aux nœuds gérés sans avoir à ouvrir de ports entrants ou à maintenir des hôtes bastions.
Lorsque vous établissez des connexions SSH viaSession Manager, AWS CLI et SSM Agent créez des WebSocket connexions sécurisées via TLS avec des points de terminaison. Session Manager La session SSH s'exécute dans ce tunnel crypté, fournissant une couche de sécurité supplémentaire sans nécessiter l'ouverture de ports entrants sur vos nœuds gérés.
Après avoir autorisé les connexions SSH, vous pouvez utiliser des politiques Gestion des identités et des accès AWS (IAM) pour autoriser ou refuser explicitement aux utilisateurs, aux groupes ou aux rôles d'établir des connexions SSH à l'aide de ceux-ci. Session Manager
**Note**
La journalisation n'est pas disponible pour les sessions Session Manager qui se connectent via le réacheminement de port ou SSH. Cela est dû au fait que le protocole SSH chiffre toutes les données de session au sein de la connexion TLS sécurisée établie entre les Session Manager points de terminaison AWS CLI et et sert Session Manager uniquement de tunnel pour les connexions SSH.
**Topics**
+ [Autorisation des connexions SSH pour Session Manager](#ssh-connections-enable)
+ [Contrôle des autorisations utilisateur pour des connexions SSH en utilisant Session Manager](#ssh-connections-permissions)
## Autorisation des connexions SSH pour Session Manager
Suivez les étapes suivantes pour autoriser les connexions SSH via Session Manager sur un nœud géré.
**Pour autoriser des connexions SSH pour Session Manager**
1. Sur le nœud géré vers lequel vous souhaitez activer les connexions SSH, procédez comme suit :
+ Assurez-vous que SSH s'exécute sur le nœud géré. (Vous pouvez fermer les ports entrants sur le nœud.)
+ Assurez-vous que SSM Agent 2.3.672.0 ou une version ultérieure est installé sur le nœud géré.
Pour plus d'informations sur l'installation ou la mise à jour de SSM Agent sur un nœud géré, consultez les rubriques suivantes :
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Windows Server](manually-install-ssm-agent-windows.md).
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Linux](manually-install-ssm-agent-linux.md)
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour macOS](manually-install-ssm-agent-macos.md)
+ [Comment installer le SSM Agent sur des nœuds Windows hybrides](hybrid-multicloud-ssm-agent-install-windows.md)
+ [Comment installer le SSM Agent sur des nœuds Linux hybrides](hybrid-multicloud-ssm-agent-install-linux.md)
**Note**
Pour l'utiliser Session Manager avec des serveurs locaux, des appareils de périphérie et des machines virtuelles (VMs) que vous avez activés en tant que nœuds gérés, vous devez utiliser le niveau d'instances avancées. Pour de plus amples informations, sur les instances avancées, veuillez consulter [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md).
1. Sur l'ordinateur local à partir duquel vous souhaitez vous connecter à un nœud géré à l'aide de SSH, procédez comme suit :
+ Assurez-vous que la version 1.1.23.0 ou une version ultérieure du plug-in Session Manager est installée.
Pour plus d'informations sur l'installation du plug-in Session Manager, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
+ Mettez à jour le fichier de configuration SSH pour activer l'exécution d'une commande de proxy qui démarre une session Session Manager et transfère toutes les données via la connexion.
**Linux et macOS**
**Astuce**
Le fichier de configuration SSH est généralement situé dans `~/.ssh/config`.
Ajoutez le fichier de configuration suivant sur l'ordinateur local.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
User ec2-user
```
** Windows **
**Astuce**
Le fichier de configuration SSH est généralement situé dans `C:\Users\\.ssh\config`.
Ajoutez le fichier de configuration suivant sur l'ordinateur local.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
```
+ Vérifiez que vous disposez d'un certificat au format PEM (Privacy Enhanced Mail) ou au minimum d'une clé publique, à utiliser lors de l'établissement de connexions avec les nœuds gérés. Il doit s'agir d'une clé déjà associée au nœud géré. Les autorisations de votre fichier de clé privée doivent être configurés afin que vous soyez le ou la seul(e) à pouvoir le lire. Vous pouvez utiliser la commande suivante pour définir les autorisations de votre fichier de clé privée afin que vous soyez le ou la seul(e) à pouvoir le lire.
```
chmod 400 .pem
```
Par exemple, pour une instance Amazon Elastic Compute Cloud (Amazon EC2), le fichier de paire de clés que vous avez créé ou sélectionné lors de la création de l'instance. (Vous spécifiez le chemin d'accès au certificat ou à la clé dans la commande de démarrage de session. Pour plus d'informations sur le démarrage d'une session à l'aide de SSH, consultez [Démarrage d'une session (SSH)](session-manager-working-with-sessions-start.md#sessions-start-ssh).)
## Contrôle des autorisations utilisateur pour des connexions SSH en utilisant Session Manager
Après avoir activé des connexions SSH sur un nœud géré en utilisant Session Manager, vous pouvez utiliser des politiques IAM pour autoriser ou empêcher des utilisateurs, des groupes ou des rôles d'établir des connexions SSH en utilisant Session Manager.
**Pour utiliser une politique IAM afin d'autoriser des connexions SSH en utilisant Session Manager**
+ Utilisez l’une des options suivantes :
+ **Option 1** : ouvrez la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
Dans le panneau de navigation, sélectionnez **Policies (Politiques)**, puis mettez à jour la politique d'autorisations permettant à l'utilisateur ou au rôle de votre choix de démarrer les connexions SSH via Session Manager.
Par exemple, ajoutez l'élément suivant à la politique Quickstart que vous avez créée dans [Démarrage rapide - Politiques d'utilisateur final pour Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user). Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
]
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Option 2** : associez une politique en ligne à une politique utilisateur à l'aide de l'API AWS Management Console AWS CLI, de ou de l' AWS API.
À l'aide de la méthode de votre choix, associez la déclaration de politique de l'**option 1** à la politique d'un AWS utilisateur, d'un groupe ou d'un rôle.
Pour de plus amples informations, veuillez consulter [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.
**Pour utiliser une politique IAM afin de refuser des connexions SSH en utilisant Session Manager**
+ Utilisez l’une des options suivantes :
+ **Option 1** : ouvrez la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. Dans le panneau de navigation, sélectionnez **Policies (Politiques)**, puis mettez à jour la politique d'autorisations pour l'utilisateur ou le rôle afin de bloquer le démarrage des sessions Session Manager.
Par exemple, ajoutez l'élément suivant à la politique Quickstart que vous avez créée dans [Démarrage rapide - Politiques d'utilisateur final pour Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Option 2** : associez une politique en ligne à une politique utilisateur à l'aide de l'API AWS Management Console AWS CLI, de ou de l' AWS API.
À l'aide de la méthode de votre choix, associez la déclaration de politique de l'**option 1** à la politique d'un AWS utilisateur, d'un groupe ou d'un rôle.
Pour de plus amples informations, veuillez consulter [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le *Guide de l'utilisateur IAM*.
# Utilisation de l’option Session Manager
Vous pouvez utiliser la console AWS Systems Manager, la console Amazon Elastic Compute Cloud (Amazon EC2) ou la AWS Command Line Interface (AWS CLI) pour démarrer des sessions qui vous connectent aux nœuds gérés auxquels votre administrateur système vous a octroyé l'accès à l'aide de politiques Gestion des identités et des accès AWS (IAM). Selon vos autorisations, vous pouvez également afficher des informations sur les sessions, reprendre des sessions inactives qui n'ont pas expiré, et mettre fin à des sessions. Une fois qu'une session est établie, elle n'est pas affectée par la durée de la session de rôle IAM. Pour plus d'informations sur la limitation de la durée de la session avec Session Manager, consultez [Spécifier une valeur de délai d'expiration d'une session inactive](session-preferences-timeout.md) et [Spécification de la durée de session maximale](session-preferences-max-timeout.md).
Pour de plus amples informations sur les sessions, veuillez consulter la page [Qu'est-ce qu'une session ?](session-manager.md#what-is-a-session).
**Topics**
+ [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md)
+ [Démarrer une session](session-manager-working-with-sessions-start.md)
+ [Résilier une session](session-manager-working-with-sessions-end.md)
+ [Afficher l'historique de session](session-manager-working-with-view-history.md)
# Installez le Session Manager plugin pour AWS CLI
Pour lancer des sessions Session Manager avec vos nœuds gérés en utilisant la AWS Command Line Interface (AWS CLI), vous devez d'abord installer le *plug-in Session Manager* sur votre machine locale. Vous pouvez installer le plug-in sur les versions prises en charge de Microsoft Windows Server, macOS, Linux et Ubuntu Server.
**Note**
Pour utiliser le Session Manager plugin, la AWS CLI version 1.16.12 ou ultérieure doit être installée sur votre machine locale. Pour plus d'informations, consultez [Installation ou mise à jour de la version la plus récente de l' AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Topics**
+ [Dernière version et historique des versions du plugin Session Manager](plugin-version-history.md)
+ [Installer le plugin Session Manager sur Windows](install-plugin-windows.md)
+ [Installer le plugin Session Manager sur macOS](install-plugin-macos-overview.md)
+ [Installer le plug-in Session Manager sous Linux](install-plugin-linux-overview.md)
+ [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md)
+ [Plugin Session Manager sur GitHub](plugin-github.md)
+ [(Facultatif) Activer la journalisation du plugin Session Manager](install-plugin-configure-logs.md)
# Dernière version et historique des versions du plugin Session Manager
Votre ordinateur local doit exécuter une version prise en charge du plugin Session Manager. La version minimale actuellement prise en charge est 1.1.17.0. Si vous exécutez une version antérieure, vos opérations Session Manager peuvent échouer.
Pour vérifier que vous disposez bien de la dernière version, exécutez la commande suivante dans l' AWS CLI.
**Note**
La commande renvoie un résultat uniquement si le plug-in est situé dans le répertoire d'installation par défaut de votre type de système d'exploitation. Vous pouvez également vérifier la version dans le contenu du fichier `VERSION`, dans le répertoire où vous avez installé le plug-in.
```
session-manager-plugin --version
```
Le tableau suivant répertorie toutes les versions du plugin Session Manager, ainsi que les fonctionnalités et les améliorations incluses dans chaque version.
**Important**
Nous vous recommandons de toujours utiliser la dernière version. La dernière version comprend des améliorations de l’expérience d’utilisation du plugin.
| Version | Date de publication | Détails |
| --- | --- | --- |
| 1,2,792,0 | 17 mars 2026 | **Correction** de bogue : ajout de la prise en charge du clavier international pour Windows. |
| 1,2,779,0 | 12 février 2026 | **Amélioration** : mise à jour de la version Go vers la version 1.25 dans Dockerfile. **Correction** de bogue : ajout de lignes Shebang aux scripts d'empaquetage Debian. |
| 1,2.764.0 | 19 novembre 2025 | **Amélioration** : Ajout du support pour les OpenDataChannel demandes de signature. **Correction de bogue** : corrigez les problèmes de style de vérification pour prendre en charge la nouvelle version de Go. |
| 1,2.707.0 | 6 février 2025 | **Amélioration** : mise à niveau de Go vers la version 1.23 dans le Dockerfile. Mise à jour de l’étape de configuration de version dans le fichier README. |
| 1,2,694,0 | 20 novembre 2024 | **Correction** de bogue : modification annulée qui ajoutait des informations d'identification aux OpenDataChannel demandes. |
| 1,2,688,0 | 6 novembre 2024 | **Cette version a été rendue obsolète le 20 novembre 2024.** **Améliorations** :[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/plugin-version-history.html) |
| 1,2.677,0 | 10 octobre 2024 | **Amélioration** : Ajout de la prise en charge de la transmission de la version du plugin avec des OpenDataChannel requêtes. |
| 1,2.650,0 | 2 juillet 2024 | **Amélioration : mise** à niveau aws-sdk-go vers la version 1.54.10.**Correction de bogue** : reformulation des commentaires pour la vérification de gofmt. |
| 1,2.633.0 | 30 mai 2024 | Amélioration : mise à jour du fichier Docker pour utiliser une image Amazon Elastic Container Registry (Amazon ECR). |
| 1,2,553.0 | 10 janvier 2024 | Amélioration : packages Golang améliorés aws-sdk-go et dépendants. |
| 1,2.536,0 | 4 décembre 2023 | Amélioration : Ajout de la prise en charge de la transmission d'une réponse d'[StartSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html)API en tant que variable d'environnement à session-manager-plugin. |
| 1,2,497,0 | 1er août 2023 | Amélioration : mise à niveau du kit SDK Go vers la version 1.44.302. |
| 1,2,463,0 | 15 mars 2023 | Amélioration : ajout de la prise en charge de Mac with Apple silicon pour Apple Mac (M1) dans le programme d’installation de bundle macOS et le programme d’installation signé. |
| 1,2,398,0 | 14 octobre 2022 | Amélioration : prise en charge de la version 1.17 de golang. Mettez à jour le session-manager-plugin lanceur par défaut pour macOS afin d'utiliser python3. Mettez à jour le chemin d'importation de SSMCLI vers. session-manager-plugin |
| 1,2,339,0 | 16 juin 2022 | Correctif de bogue : correction du délai d'expiration de la session inactive pour les sessions de port. |
| 1,2.331.0 | 27 mai 2022 | Correctif de bogue : correction des sessions de port se fermant prématurément lorsque le serveur local ne se connecte pas avant le délai d'attente. |
| 1,2.323.0 | 19 mai 2022 | Correctif de bogue: Désactivation de la fonctionnalité smux keep alive pour utiliser la fonctionnalité idle session timeout. |
| 1,2,312,0 | 31 mars 2022 | Amélioration : prend en charge plus de types de charges utiles de messages de sortie. |
| 1,2.295,0 | 12 janvier 2022 | Bug fix (Correction de bogue) : sessions bloquées en raison du renvoi des données de flux par le client lorsque l'agent devient inactif, et des journaux incorrects pour les messages start\$1publication et pause\$1publication. |
| 1,2,279,0 | 27 octobre 2021 | Amélioration : emballage zip pour la plateforme Windows. |
| 1.2.245.0 | 19 août 2021 | Amélioration : mettez aws-sdk-go à la dernière version (v1.40.17) pour prendre en charge AWS IAM Identity Center. |
| 1.2.234.0 | 26 juillet 2021 | Correction de bogue : une session Handle a brusquement interrompu le scénario dans un type de session interactive. |
| 1.2.205.0 | 10 juin 2021 | Amélioration : ajout de la prise en charge du programme d'installation macOS signé. |
| 1.2.54.0 | 29 janvier 2021 | Amélioration : Ajout de la prise en charge de l'exécution de sessions en mode NonInteractiveCommands exécution. |
| 1,2,30,0 | 24 novembre 2020 | **Amélioration** : (sessions de réacheminement de port uniquement) Amélioration de la performance globale. |
| 1.2.7.0 | 15 octobre 2020 | **Amélioration** : (sessions de réacheminement de port uniquement) réduction de la latence et amélioration de la performance globale. |
| 1.1.61.0 | 17 avril 2020 | **Amélioration** : ajout de la prise en charge ARM pour Linux et Ubuntu Server. |
| 1.1.54.0 | 6 janvier 2020 | **Correction de bogue** : gérer le scénario de condition de course des paquets abandonnés lorsque le plugin Session Manager n'est pas prêt. |
| 1.1.50.0 | 19 novembre 2019 | **Amélioration**: Ajout du support pour le transfert d'un port vers un socket unix local. |
| 1.1.35.0 | 7 novembre 2019 | **Amélioration** : (sessions de transfert de port uniquement) Envoyez une TerminateSession commande SSM Agent lorsque l'utilisateur local appuie sur`Ctrl+C`. |
| 1.1.33.0 | 26 septembre 2019 | Amélioration : (sessions de réacheminement de port uniquement) Envoie d'un signal de déconnexion au serveur lorsque le client abandonne la connexion TCP. |
| 1.1.31.0 | 6 septembre 2019 | Amélioration : mise à jour pour maintenir la session de réacheminement de port ouverte jusqu'à ce que le serveur distant ferme la connexion. |
| 1.1.26.0 | 30 juillet 2019 | **Amélioration** : mise à jour pour limiter le taux de transfert de données au cours d'une session. |
| 1.1.23.0 | 9 juillet 2019 | **Amélioration** : ajout de la prise en charge de l'exécution de sessions SSH à l'aide de Session Manager. |
| 1.1.17.0 | 4 avril 2019 | **Amélioration** : ajout de la prise en charge d'autres données de chiffrement de session avec AWS Key Management Service (AWS KMS). |
| 1.0.37.0 | 20 septembre 2018 | **Amélioration** : correction de bogue pour la version Windows. |
| 1.0.0.0 | 11 septembre 2018 | Version initiale du plugin Session Manager. |
# Installer le plugin Session Manager sur Windows
Vous pouvez installer le plug-in Session Manager sur Windows Vista ou une version ultérieure à l'aide du programme d'installation autonome.
Lorsque des mises à jour sont publiées, vous devez relancer le processus d'installation pour obtenir la version la plus récente du plugin Session Manager.
**Note**
Notez les informations suivantes.
Le programme d’installation du plug-in Session Manager doit disposer des droits d’administrateur pour installer le plug-in.
Pour obtenir de meilleurs résultats, nous vous recommandons de démarrer des sessions sur les clients Windows à l'aide de Windows PowerShell version 5 ou ultérieure. Vous pouvez également utiliser le shell Command sur Windows 10. Le plug-in Session Manager prend uniquement en charge PowerShell et le shell Command. Les outils de ligne de commande tiers peuvent ne pas être compatibles avec le plugin.
**Pour installer le plugin Session Manager à l'aide du programme d'installation EXE**
1. Téléchargez le programme d'installation à l'URL suivante.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe
```
Vous pouvez également télécharger une version zippée du programme d'installation à l'aide de l'URL suivante.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPlugin.zip
```
1. Exécutez le programme d'installation que vous avez téléchargé et suivez les instructions à l'écran. Si vous avez téléchargé la version zippée du programme d'installation, vous devez d'abord décompresser le programme d'installation.
Laissez vide la zone Emplacement d'installation pour installer le plugin dans le répertoire par défaut.
+ `%PROGRAMFILES%\Amazon\SessionManagerPlugin\bin\`
1. Vérifiez que l'installation a réussi. Pour plus d'informations, consultez [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md).
**Note**
Si Windows ne parvient pas à localiser le fichier exécutable, vous devrez peut-être rouvrir l'invite de commande ou ajouter manuellement le répertoire d'installation à votre variable d'environnement `PATH`. Pour en savoir plus, consultez la rubrique de dépannage [Plug-in Session Manager pas ajouté automatiquement au chemin de la ligne de commande (Windows)](session-manager-troubleshooting.md#windows-plugin-env-var-not-set).
# Installer le plugin Session Manager sur macOS
Sélectionnez l’une des rubriques suivantes pour installer le plug-in Session Manager sur macOS.
**Note**
Le programme d’installation signé est un fichier `.pkg` signé. Le programme d’installation fourni utilise un fichier `.zip`. Une fois le fichier décompressé, vous pouvez installer le plug-in à l’aide du binaire.
## Installer le plugin Session Manager sur macOS avec le programme d'installation signé
Cette section explique comment installer le plug-in Session Manager sur macOS en utilisant le programme d'installation signé.
**Pour installer le plugin Session Manager en utilisant le programme d'installation signé (macOS)**
1. Téléchargez le programme d'installation signé.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
#### [ Mac avec silicium Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
1. Exécutez les commandes d'installation. Si la commande échoue, vérifiez que le dossier `/usr/local/bin` existe. Si ce n’est pas le cas, créez-le et réexécutez la commande.
```
sudo installer -pkg session-manager-plugin.pkg -target /
sudo ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin
```
1. Vérifiez que l'installation a réussi. Pour plus d'informations, consultez [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md).
## Installer le plugin Session Manager sur macOS
Cette section explique comment installer le plug-in Session Manager sur macOS en utilisant le programme d'installation fourni.
**Important**
Notez les informations importantes suivantes.
Par défaut, le programme d’installation nécessite un accès sudo pour s’exécuter, car le script installe le plugin dans le répertoire système `/usr/local/sessionmanagerplugin`. Si vous ne voulez pas installer le plugin en utilisant sudo, mettez à jour manuellement le script d’installation pour installer le plugin dans un répertoire qui ne nécessite pas d’accès sudo.
Le programme d’installation fourni ne prend pas en charge l’installation dans des chemins contenant des espaces.
**Pour installer le plugin Session Manager à l'aide du programme d'installation fourni (macOS)**
1. Téléchargez le programme d'installation.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
#### [ Mac avec silicium Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
1. Décompressez le package.
```
unzip sessionmanager-bundle.zip
```
1. Exécutez la commande d'installation.
```
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
**Note**
Le plugin nécessite Python 3.10 ou version ultérieure. Par défaut, le script d’installation s’exécute sous la version système par défaut de Python. Si vous avez installé une autre version de Python et souhaitez l'utiliser pour installer le plugin Session Manager, exécutez le script d'installation avec cette version dans le chemin d'accès absolu au fichier exécutable Python. Voici un exemple.
```
sudo /usr/local/bin/python3.11 sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
Le programme d'installation installe le plugin Session Manager sous `/usr/local/sessionmanagerplugin` et crée le lien symbolique `session-manager-plugin` dans le répertoire `/usr/local/bin`. Cela permet d'éviter de devoir spécifier le répertoire d'installation dans la variable utilisateur `$PATH`.
Pour afficher une description des options `-i` et `-b`, utilisez l'option `-h`.
```
./sessionmanager-bundle/install -h
```
1. Vérifiez que l'installation a réussi. Pour plus d'informations, consultez [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md).
**Note**
Pour désinstaller le plug-in, exécutez les deux commandes suivantes dans l'ordre indiqué :
```
sudo rm -rf /usr/local/sessionmanagerplugin
```
```
sudo rm /usr/local/bin/session-manager-plugin
```
# Installer le plug-in Session Manager sous Linux
Cette section contient des informations sur la vérification de la signature du package d’installation du plug-in Session Manager et sur l’installation du plug-in sur les distributions Linux suivantes :
+ Amazon Linux 2
+ AL2023
+ RHEL
+ Debian Server
+ Ubuntu Server
**Topics**
+ [Vérifier la signature du plug-in Session Manager](install-plugin-linux-verify-signature.md)
+ [Installer le plugin Session Manager sur Amazon Linux 2, Amazon Linux 2023 et les distributions Red Hat Enterprise Linux](install-plugin-linux.md)
+ [Installer le plugin Session Manager sur Debian Server et Ubuntu Server](install-plugin-debian-and-ubuntu.md)
# Vérifier la signature du plug-in Session Manager
Les packages RPM et Debian du plug-in Session Manager pour les instances Linux sont signés cryptographiquement. Vous pouvez utiliser une clé publique pour vérifier que le binaire et le package du plug-in sont les originaux non modifiés. En cas de dommage ou d’altération des fichiers, la vérification échoue. Vous pouvez vérifier la signature du package d’installation avec l’outil GNU Privacy Guard (GPG). Les informations suivantes sont pour les versions 1.2.707.0 ou ultérieures du plug-in Session Manager.
Procédez comme suit pour vérifier la signature du package d’installation du plug-in Session Manager.
**Topics**
+ [Étape 1 : téléchargez et installez le programme d’installation du plug-in Session Manager.](#install-plugin-linux-verify-signature-installer-packages)
+ [Étape 2 : télécharger le fichier de signature associé](#install-plugin-linux-verify-signature-packages)
+ [Étape 3 : Installation de l’outil GPG](#install-plugin-linux-verify-signature-packages-gpg)
+ [Étape 4 : vérifier le package d’installation du plug-in Session Manager sur un serveur Linux](#install-plugin-linux-verify-signature-packages)
## Étape 1 : téléchargez et installez le programme d’installation du plug-in Session Manager.
Téléchargez le package d’installation du plug-in Session Manager que vous souhaitez vérifier.
**Packages Amazon Linux 2 et RHEL RPM AL2023**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm"
```
------
**Packages Deb Debian Server et Ubuntu Server**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb"
```
------
## Étape 2 : télécharger le fichier de signature associé
Après avoir téléchargé le package d’installation, téléchargez le fichier de signature associé pour la vérification du package. Pour fournir un niveau de protection supplémentaire contre la copie ou l'utilisation non autorisées du fichier session-manager-plugin binaire contenu dans le package, nous proposons également des signatures binaires, que vous pouvez utiliser pour valider des fichiers binaires individuels. Vous pouvez choisir d’utiliser ces signatures binaires en fonction de vos besoins de sécurité.
**Amazon Linux 2 AL2023 et packages de RHEL signature**
------
#### [ x86\$164 ]
Package :
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm.sig"
```
Binaire :
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Package :
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm.sig"
```
Binaire :
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.sig"
```
------
**Packages de signature Deb Debian Server et Ubuntu Server**
------
#### [ x86\$164 ]
Package :
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb.sig"
```
Binaire :
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Package :
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb.sig"
```
Binaire :
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.sig"
```
------
## Étape 3 : Installation de l’outil GPG
Pour vérifier la signature du plug-in Session Manager, l’outil GNU Privacy Guard (GPG) doit être installé sur votre système. Le processus de vérification nécessite GPG version 2.1 ou ultérieure. Vous pouvez vérifier votre version de GPG en exécutant la commande suivante :
```
gpg --version
```
Si votre version de GPG est antérieure à la version 2.1, mettez-la à jour avant de procéder au processus de vérification. Pour la plupart des systèmes, vous pouvez mettre à jour l’outil GPG à l’aide de votre gestionnaire de packages. Par exemple, sur des versions prises en charge d’Amazon Linux et de RHEL, vous pouvez utiliser les commandes suivantes :
```
sudo yum update
sudo yum install gnupg2
```
Sur les systèmes Ubuntu Server et Debian Server pris en charge, vous pouvez utiliser les commandes suivantes :
```
sudo apt-get update
sudo apt-get install gnupg2
```
Assurez-vous de disposer de la version requise de GPG avant de poursuivre le processus de vérification.
## Étape 4 : vérifier le package d’installation du plug-in Session Manager sur un serveur Linux
Utilisez la procédure suivante pour vérifier le package d’installation du plug-in Session Manager sur un serveur Linux.
**Note**
Amazon Linux 2 ne prend pas en charge la GPG version 2.1 ou ultérieure. Si la procédure suivante ne fonctionne pas sur vos instances Amazon Linux 2, vérifiez la signature sur une autre plateforme avant de l’installer sur vos instances Amazon Linux 2.
1. Copiez la clé publique suivante et enregistrez-la dans un fichier nommé session-manager-plugin .gpg.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mFIEZ5ERQxMIKoZIzj0DAQcCAwQjuZy+IjFoYg57sLTGhF3aZLBaGpzB+gY6j7Ix
P7NqbpXyjVj8a+dy79gSd64OEaMxUb7vw/jug+CfRXwVGRMNtIBBV1MgU1NNIFNl
c3Npb24gTWFuYWdlciA8c2Vzc2lvbi1tYW5hZ2VyLXBsdWdpbi1zaWduZXJAYW1h
em9uLmNvbT4gKEFXUyBTeXN0ZW1zIE1hbmFnZXIgU2Vzc2lvbiBNYW5hZ2VyIFBs
dWdpbiBMaW51eCBTaWduZXIgS2V5KYkBAAQQEwgAqAUCZ5ERQ4EcQVdTIFNTTSBT
ZXNzaW9uIE1hbmFnZXIgPHNlc3Npb24tbWFuYWdlci1wbHVnaW4tc2lnbmVyQGFt
YXpvbi5jb20+IChBV1MgU3lzdGVtcyBNYW5hZ2VyIFNlc3Npb24gTWFuYWdlciBQ
bHVnaW4gTGludXggU2lnbmVyIEtleSkWIQR5WWNxJM4JOtUB1HosTUr/b2dX7gIe
AwIbAwIVCAAKCRAsTUr/b2dX7rO1AQCa1kig3lQ78W/QHGU76uHx3XAyv0tfpE9U
oQBCIwFLSgEA3PDHt3lZ+s6m9JLGJsy+Cp5ZFzpiF6RgluR/2gA861M=
=2DQm
-----END PGP PUBLIC KEY BLOCK-----
```
1. Importez la clé publique dans votre porte-clés. La valeur de la clé renvoyée doit être `2C4D4AFF6F6757EE`.
```
$ gpg --import session-manager-plugin.gpg
gpg: key 2C4D4AFF6F6757EE: public key "AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" imported
gpg: Total number processed: 1
gpg: imported: 1
```
1. Vérifiez l’empreinte digitale en exécutant la commande suivante.
```
gpg --fingerprint 2C4D4AFF6F6757EE
```
L’empreinte digitale de la sortie de commande doit correspondre à ce qui suit.
```
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
```
pub nistp256 2025-01-22 [SC]
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
uid [ unknown] AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)
```
Si l’empreinte digitale ne correspond pas, n’installez pas le plug-in. Contacter AWS Support.
1. Vérifiez la signature du package d'installation. Remplacez le *signature-filename* et *downloaded-plugin-filename* par les valeurs que vous avez spécifiées lors du téléchargement du fichier de signature et session-manager-plugin, comme indiqué dans le tableau ci-dessus dans cette rubrique.
```
gpg --verify signature-filename downloaded-plugin-filename
```
Par exemple, pour l’architecture x86\$164 sur Amazon Linux 2, la commande est la suivante :
```
gpg --verify session-manager-plugin.rpm.sig session-manager-plugin.rpm
```
La sortie générée lors de l'exécution de cette commande est semblable à ce qui suit.
```
gpg: Signature made Mon Feb 3 20:08:32 2025 UTC gpg: using ECDSA key 2C4D4AFF6F6757EE
gpg: Good signature from "AWS Systems Manager Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
Si le résultat inclut l’expression `BAD signature`, vérifiez si vous avez effectué la procédure correctement. Si vous continuez à recevoir cette réponse, contactez le package AWS Support et ne l'installez pas. Le message d'avertissement relatif à l'approbation ne signifie pas que la signature n'est pas valide, mais seulement que vous n'avez pas vérifié la clé publique. Une clé est uniquement approuvée si vous ou une personne de confiance l'a signée. Si la sortie inclut la phrase `Can't check signature: No public key`, vérifiez que vous avez téléchargé la version 1.2.707.0 du plug-in Session Manager ou une version ultérieure.
# Installer le plugin Session Manager sur Amazon Linux 2, Amazon Linux 2023 et les distributions Red Hat Enterprise Linux
Utilisez la procédure suivante pour installer le Session Manager plug-in sur Amazon Linux 2, Amazon Linux 2023 (AL2023) et les RHEL distributions.
1. Téléchargez et installez le package RPM du plug-in Session Manager.
------
#### [ x86\$164 ]
Sur Amazon Linux 2 et RHEL 7, exécutez la commande suivante :
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
Les RHEL 8 AL2023 et 9, exécutez la commande suivante :
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
------
#### [ ARM64 ]
Sur Amazon Linux 2 et RHEL 7, exécutez la commande suivante :
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
Les RHEL 8 AL2023 et 9, exécutez la commande suivante :
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
------
1. Vérifiez que l'installation a réussi. Pour plus d'informations, consultez [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md).
**Note**
Si vous souhaitez désinstaller le plug-in, exécutez `sudo yum erase session-manager-plugin -y`
# Installer le plugin Session Manager sur Debian Server et Ubuntu Server
1. Téléchargez le package deb du plugin Session Manager.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
1. Exécutez la commande d'installation.
```
sudo dpkg -i session-manager-plugin.deb
```
1. Vérifiez que l'installation a réussi. Pour plus d'informations, consultez [Vérifier l'Installation du plugin Session Manager](install-plugin-verify.md).
**Note**
Si vous souhaitez désinstaller le plug-in, exécutez `sudo dpkg -r session-manager-plugin`
# Vérifier l'Installation du plugin Session Manager
Exécutez les commandes suivantes pour vérifier que le plugin Session Manager a bien été installé.
```
session-manager-plugin
```
Si l'installation a réussi, vous obtenez le message suivant.
```
The Session Manager plugin is installed successfully. Use the AWS CLI to start a session.
```
Vous pouvez également tester l’installation en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) dans la console [AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI). Dans la commande suivante, remplacez *instance-id* par vos propres informations.
```
aws ssm start-session --target instance-id
```
Cette commande ne fonctionnera que si vous avez installé et configuré le AWS CLI, et si votre Session Manager administrateur vous a accordé les autorisations IAM nécessaires pour accéder au nœud géré cible à l'aide Session Manager de.
# Plugin Session Manager sur GitHub
Le code source du plugin Session Manager est disponible sur [https://github.com/aws/session-manager-plugin](https://github.com/aws/session-manager-plugin) afin de vous permettre d’adapter ce plugin à vos besoins. Nous vous conseillons d'envoyer des [requêtes d'extraction](https://github.com/aws/session-manager-plugin/blob/mainline/CONTRIBUTING.md) pour les modifications que vous souhaitez inclure. Toutefois, Amazon Web Services ne fournit pas de support pour l'exécution de copies modifiées de ce logiciel.
# (Facultatif) Activer la journalisation du plugin Session Manager
Le plugin Session Manager inclut une option permettant d'activer la journalisation pour les sessions que vous exécutez. Par défaut, la journalisation est désactivée.
Si vous activez la journalisation, le plugin Session Manager crée des fichiers journaux relatifs à l'activité de l'application (`session-manager-plugin.log`) et aux erreurs (`errors.log`) sur votre ordinateur local.
**Topics**
+ [Activation de la journalisation pour le plug-in Session Manager (Windows)](#configure-logs-windows)
+ [Activation de la journalisation pour le plug-in Session Manager (Linux et macOS)](#configure-logs-linux)
## Activation de la journalisation pour le plug-in Session Manager (Windows)
1. Recherchez le fichier `seelog.xml.template` du plug-in.
L'emplacement par défaut est `C:\Program Files\Amazon\SessionManagerPlugin\seelog.xml.template`.
1. Remplacez le nom du fichier par `seelog.xml`.
1. Ouvrez le fichier et remplacez `minlevel="off"` par `minlevel="info"` ou `minlevel="debug"`.
**Note**
Par défaut, les entrées de journaux sur l'ouverture d'un canal de données et les reconnexions aux sessions sont enregistrées au niveau **INFO**. Les entrées de flux de données (paquets et accusé de réception) sont enregistrées au niveau **DEBUG**.
1. Modifiez les autres options de configuration que vous souhaitez modifier. Vous pouvez modifier les options suivantes :
+ **Niveau de débogage** : vous pouvez remplacer le niveau de débogage de `formatid="fmtinfo"` par `formatid="fmtdebug"`.
+ **Options des fichiers journaux** : vous pouvez modifier les options des fichiers journaux, y compris l'emplacement de stockage des journaux, à l'exception des noms des fichiers journaux.
**Important**
Ne modifiez pas les noms de fichier, la journalisation ne fonctionnerait pas correctement.
```
```
1. Enregistrez le fichier.
## Activation de la journalisation pour le plug-in Session Manager (Linux et macOS)
1. Recherchez le fichier `seelog.xml.template` du plug-in.
L'emplacement par défaut est `/usr/local/sessionmanagerplugin/seelog.xml.template`.
1. Remplacez le nom du fichier par `seelog.xml`.
1. Ouvrez le fichier et remplacez `minlevel="off"` par `minlevel="info"` ou `minlevel="debug"`.
**Note**
Par défaut, les entrées de journaux sur l'ouverture de canaux de données et les reconnexions aux sessions sont enregistrées au niveau **INFO**. Les entrées de flux de données (paquets et accusé de réception) sont enregistrées au niveau **DEBUG**.
1. Modifiez les autres options de configuration que vous souhaitez modifier. Vous pouvez modifier les options suivantes :
+ **Niveau de débogage** : vous pouvez remplacer le niveau de débogage de `formatid="fmtinfo"` par `outputs formatid="fmtdebug"`.
+ **Options des fichiers journaux** : vous pouvez modifier les options des fichiers journaux, y compris l'emplacement de stockage des journaux, à l'exception des noms des fichiers journaux.
**Important**
Ne modifiez pas les noms de fichier, la journalisation ne fonctionnerait pas correctement.
```
```
**Important**
Si vous utilisez le répertoire par défaut spécifié pour le stockage des journaux, vous devez exécuter des commandes de session à l'aide de la commande **sudo** ou accorder au répertoire dans lequel le plug-in est installé, des autorisations complètes de lecture et d'écriture. Pour contourner ces restrictions, modifiez l'emplacement de stockage des journaux.
1. Enregistrez le fichier.
# Démarrer une session
Vous pouvez utiliser la AWS Systems Manager console, la console Amazon Elastic Compute Cloud (Amazon EC2), AWS Command Line Interface le AWS CLI() ou SSH pour démarrer une session.
**Topics**
+ [Démarrage d'une session (console Systems Manager)](#start-sys-console)
+ [Démarrage d'une session (console Amazon EC2)](#start-ec2-console)
+ [Démarrage d'une session (AWS CLI)](#sessions-start-cli)
+ [Démarrage d'une session (SSH)](#sessions-start-ssh)
+ [Démarrage d'une session (réacheminement de port)](#sessions-start-port-forwarding)
+ [Démarrage d'une session (réacheminement de port vers un hôte distant)](#sessions-remote-port-forwarding)
+ [Démarrage d'une session (commandes interactives et non interactives)](#sessions-start-interactive-commands)
## Démarrage d'une session (console Systems Manager)
Vous pouvez utiliser la AWS Systems Manager console pour démarrer une session avec un nœud géré dans votre compte.
**Note**
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
**Pour démarrer une session (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 **Session Manager**.
1. Sélectionnez **Start session (Démarrer une session)**.
1. (Facultatif) Saisissez une description de session dans le champ **Raison de la session**.
1. Dans la liste **Instances cibles**, sélectionnez la case d'option située à gauche du nœud géré auquel vous souhaitez vous connecter.
Si le nœud que vous souhaitez ne figure pas dans la liste, ou si vous sélectionnez un nœud et recevez une erreur de configuration, veuillez consulter [Nœud géré non disponible ou non configuré pour Session Manager](session-manager-troubleshooting.md#session-manager-troubleshooting-instances) pour connaître les étapes de résolution du problème.
1. Choisissez **Démarrer la session** pour lancer la session immédiatement.
-ou-
Choisissez **Suivant** pour connaître les options de session.
1. (Facultatif) Dans **Document de session**, sélectionnez le document que vous souhaitez exécuter au démarrage de la session. Si votre document prend en charge les paramètres d'exécution, vous pouvez saisir une ou plusieurs valeurs séparées par des virgules dans chaque champ de paramètre.
1. Choisissez **Suivant**.
1. Sélectionnez **Start session (Démarrer une session)**.
Une fois la connexion effectuée, vous pouvez exécuter des commandes bash (Linux et macOS) ou des commandes PowerShell (Windows) comme vous le feriez via n'importe quel autre type de connexion.
**Important**
Si vous souhaitez autoriser les utilisateurs à spécifier un document lorsqu'ils démarrent des sessions dans la console Session Manager, tenez compte des points suivants :
Vous devez accorder aux utilisateurs les autorisations `ssm:GetDocument` et `ssm:ListDocuments` dans leur politique IAM. Pour de plus amples informations, veuillez consulter [Octroi de l'accès aux documents de session personnalisés dans la console](getting-started-restrict-access-examples.md#grant-access-documents-console-example).
La console prend uniquement en charge les documents de session dont le `sessionType` est défini sur `Standard_Stream`. Pour de plus amples informations, veuillez consulter [Schéma de document de session](session-manager-schema.md).
## Démarrage d'une session (console Amazon EC2)
Vous pouvez utiliser la console Amazon Elastic Compute Cloud (Amazon EC2) pour démarrer une session avec une instance dans votre compte.
**Note**
Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à exécuter une ou plusieurs actions Systems Manager (`ssm:command-name`), vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni vos informations de connexion. Demandez à cette personne de mettre à jour vos politiques afin de vous autoriser à démarrer des sessions à partir de la console Amazon EC2. Si vous êtes administrateur, consultez [Exemple de stratégies IAM pour Session Manager](getting-started-restrict-access-quickstart.md) pour plus d'informations.
**Pour démarrer une session (console Amazon EC2)**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, choisissez **Instances**.
1. Sélectionnez l'instance, puis sélectionnez **Connect (Connexion)**.
1. Pour **Méthode de connexion**, sélectionnez **Session Manager**.
1. Sélectionnez **Connexion**.
Une fois la connexion effectuée, vous pouvez exécuter des commandes bash (Linux et macOS) ou des commandes PowerShell (Windows) comme vous le feriez via n'importe quel autre type de connexion.
## Démarrage d'une session (AWS CLI)
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).
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
Pour utiliser les commandes AWS CLI d'exécution de session, le Session Manager plugin doit également être installé sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
Pour démarrer une session à l'aide de AWS CLI, exécutez la commande suivante en *instance-id* remplaçant par vos propres informations.
```
aws ssm start-session \
--target instance-id
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **start-session** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
## Démarrage d'une session (SSH)
Pour démarrer une session SSH Session Manager, SSM Agent version 2.3.672.0 ou version ultérieure doit être installé sur le nœud géré.
**Conditions préalables pour une connexion SSH**
Prenez note des exigences et des limites suivantes pour les connexions de session utilisant SSH via Session Manager :
+ Votre nœud géré cible doit être configurée pour prendre en charge les connexions SSH. Pour de plus amples informations, consultez la section [(Optional) Allow and control permissions for SSH connections through Session Manager](session-manager-getting-started-enable-ssh-connections.md).
+ Vous devez vous connecter en utilisant le compte du nœud géré associé au certificat PEM (Privacy Enhanced Mail), et non le compte `ssm-user` utilisé pour d'autres types de connexions de session. Par exemple, sur les instances EC2 pour Linux et macOS, l'utilisateur par défaut est `ec2-user`. Pour obtenir des informations sur l’identification de l’utilisateur par défaut pour chaque type d’instance, consultez la section [Get Information About Your Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-get-info-about-instance) du *guide de l’utilisateur Amazon EC2*.
+ La journalisation n'est pas disponible pour les sessions Session Manager qui se connectent via le réacheminement de port ou SSH. Cela est dû au fait que le protocole SSH chiffre toutes les données de session au sein de la connexion TLS sécurisée établie entre les Session Manager points de terminaison AWS CLI et et sert Session Manager uniquement de tunnel pour les connexions SSH.
**Note**
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
Pour démarrer une session à l'aide de SSH, exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
```
ssh -i /path/my-key-pair.pem username@instance-id
```
**Astuce**
Lorsque vous démarrez une session à l'aide de SSH, vous pouvez copier des fichiers locaux sur le nœud géré cible en utilisant le format de commande suivant.
```
scp -i /path/my-key-pair.pem /path/ExampleFile.txt username@instance-id:~
```
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **start-session** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
## Démarrage d'une session (réacheminement de port)
Pour démarrer une session de réacheminement de port Session Manager, SSM Agent version 2.3.672.0 ou ultérieure doit être installé sur le nœud géré.
**Note**
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
Pour utiliser les commandes AWS CLI d'exécution de session, vous devez installer le Session Manager plugin sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
Selon votre système d'exploitation et votre outil de ligne de commande, le placement des guillemets peut différer et des caractères d'échappement peuvent être nécessaires.
Pour démarrer une session de réacheminement de port, exécutez la commande suivante à partir de la CLI. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSession ^
--parameters portNumber="3389",localPortNumber="56789"
```
------
`portNumber` est le port distant sur le nœud géré vers lequel vous souhaitez que le trafic de session soit redirigé. Vous pouvez par exemple spécifier le port `3389` pour la connexion à un nœud Windows via le protocole RDP (Remote Desktop Protocol). Si vous ne spécifiez pas le paramètre `portNumber`, Session Manager utilise `80` comme valeur par défaut.
`localPortNumber` est le port sur votre ordinateur local où le trafic commence, par exemple `56789`. Cette valeur est celle que vous saisissez lors de la connexion à un nœud géré en utilisant un client. Par exemple, **localhost:56789**.
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **start-session** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
Pour de plus amples informations sur les sessions de réacheminement de port, veuillez consulter [réacheminement de port avec AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) dans le *Blog d'actualitéAWS *.
## Démarrage d'une session (réacheminement de port vers un hôte distant)
Pour démarrer une session de transfert de port Session Manager vers un hôte distant, la version 3.1.1374.0 ou ultérieure de SSM Agent doit être installée sur le nœud géré. L'hôte distant ne doit pas nécessairement être géré par Systems Manager.
**Note**
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
Pour utiliser les commandes AWS CLI d'exécution de session, vous devez installer le Session Manager plugin sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
Selon votre système d'exploitation et votre outil de ligne de commande, le placement des guillemets peut différer et des caractères d'échappement peuvent être nécessaires.
Pour démarrer une session de réacheminement de port, exécutez la commande suivante à partir de l’ AWS CLI. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["mydb.example.us-east-2.rds.amazonaws.com"],"portNumber":["3306"], "localPortNumber":["3306"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="mydb.example.us-east-2.rds.amazonaws.com",portNumber="3306",localPortNumber="3306"
```
------
La valeur `host` représente le nom d'hôte ou l'adresse IP de l'hôte distant auquel vous souhaitez vous connecter. Les exigences générales de connectivité et de résolution de noms entre le nœud géré et l'hôte distant s'appliquent toujours.
`portNumber` est le port distant sur le nœud géré vers lequel vous souhaitez que le trafic de session soit redirigé. Vous pouvez par exemple spécifier le port `3389` pour la connexion à un nœud Windows via le protocole RDP (Remote Desktop Protocol). Si vous ne spécifiez pas le paramètre `portNumber`, Session Manager utilise `80` comme valeur par défaut.
`localPortNumber` est le port sur votre ordinateur local où le trafic commence, par exemple `56789`. Cette valeur est celle que vous saisissez lors de la connexion à un nœud géré en utilisant un client. Par exemple, **localhost:56789**.
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **start-session** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
### Démarrer une session avec une tâche Amazon ECS
Session Manager prend en charge le démarrage d’une session de réacheminement de port avec une tâche au sein d’un cluster Amazon Elastic Container Service (Amazon ECS). Pour ce faire, activez ECS Exec. Pour plus d’informations, consultez [Surveiller les conteneurs Amazon Elastic Container Service avec ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) dans le *Guide du développeur Amazon Elastic Container Service*.
Vous devez également mettre à jour le rôle de tâche dans IAM afin d’inclure les autorisations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
Pour démarrer une session de réacheminement de port avec une tâche Amazon ECS, exécutez la commande suivante à partir de l’ AWS CLI. Remplacez chaque *example resource placeholder* par vos propres informations.
**Note**
Supprimez les symboles < and > à partir du paramètre `target`. Ces symboles ne sont fournis qu’à titre de clarification pour le lecteur.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target ecs:__ \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["URL"],"portNumber":["port_number"], "localPortNumber":["port_number"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target ecs:__ ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="URL",portNumber="port_number",localPortNumber="port_number"
```
------
## Démarrage d'une session (commandes interactives et non interactives)
Avant de démarrer une session, vérifiez que vous bien effectué les étapes de configuration pour Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
Pour utiliser les commandes AWS CLI d'exécution de session, le Session Manager plugin doit également être installé sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
Pour démarrer une session de commande interactive, exécutez la commande suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name CustomCommandSessionDocument \
--parameters '{"logpath":["/var/log/amazon/ssm/amazon-ssm-agent.log"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name CustomCommandSessionDocument ^
--parameters logpath="/var/log/amazon/ssm/amazon-ssm-agent.log"
```
------
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **start-session** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
**Plus d'informations**
+ [Use port forwarding in AWS Systems Manager Session Manager to connect to remote hosts](https://aws.amazon.com/blogs/mt/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts/)
+ [Redirection de port d'instance Amazon EC2 avec AWS Systems Manager](https://aws.amazon.com/blogs/mt/amazon-ec2-instance-port-forwarding-with-aws-systems-manager/)
+ [Gérez les ressources Microsoft AD AWS gérées avec la redirection de Session Manager port](https://aws.amazon.com/blogs/mt/manage-aws-managed-microsoft-ad-resources-with-session-manager-port-forwarding/)
+ [Port Forwarding Using AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) sur *AWS News Blog*.
# Résilier une session
Vous pouvez utiliser la console AWS Systems Manager ou l’AWS Command Line Interface (AWS CLI) pour mettre fin à une session que vous avez démarrée dans votre compte. Lorsque vous cliquez sur le bouton **Résilier** pour une session dans la console ou si vous appelez l’action d’API [TerminateSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TerminateSession.html) à l’aide de l’AWS CLI, Session Manager met définitivement fin à la session et ferme la connexion de données entre le client Session Manager et SSM Agent sur le nœud géré. Vous ne pouvez pas redémarrer une session résiliée.
S’il n’y a aucune activité utilisateur dans une session ouverte pendant 20 minutes, cela dépasse le délai d’inactivité admis. Session Manager n’appelle pas `TerminateSession`, mais ferme le canal sous‑jacent. Vous ne pouvez pas redémarrer une session fermée en raison d’un dépassement du délai d’inactivité.
Nous recommandons de toujours mettre fin explicitement à une session à l’aide de la commande `terminate-session`, lorsque vous utilisez la AWS CLI, ou du bouton **Terminer** lorsque vous utilisez la console. (Les boutons **Terminer** se trouvent à la fois dans la fenêtre de session et sur la page principale de la console Session Manager.) Si vous fermez uniquement une fenêtre de navigateur ou de commande, la session reste répertoriée comme **Active** dans la console pendant 30 jours. Si vous ne mettez pas fin explicitement à une session, ou lorsqu’une session expire, tous les processus qui étaient en cours d’exécution sur le nœud géré à ce moment-là continueront de s’exécuter.
**Topics**
+ [Terminer une session (console)](#stop-sys-console)
+ [Résiliation d'une session (AWS CLI)](#stop-cli)
## Terminer une session (console)
Vous pouvez utiliser la console AWS Systems Manager pour démarrer une session de votre compte.
**Pour terminer une session (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 **Session Manager**.
1. Pour **Sessions**, sélectionnez le bouton d'option situé à gauche de la session que vous souhaitez résilier.
1. Sélectionnez **Terminer**.
## Résiliation d'une session (AWS CLI)
Pour terminer une session à l'aide de l'AWS CLI, exécutez la commande suivante. Remplacez *session-id* avec vos propres informations.
```
aws ssm terminate-session \
--session-id session-id
```
Pour de plus amples informations sur la commande **terminate-session**, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html) dans la section AWS Systems Manager de la Référence des commandes de la AWS CLI.
# Afficher l'historique de session
Vous pouvez utiliser la AWS Systems Manager console ou le AWS Command Line Interface (AWS CLI) pour consulter les informations relatives aux sessions de votre compte. Dans la console, vous pouvez par exemple afficher les informations suivantes :
+ L'ID de la session
+ Quel utilisateur s'est connecté à un nœud géré au cours de la session
+ ID du nœud géré
+ Le début et la fin de la session
+ Le statut de la session
+ L'emplacement spécifié pour le stockage des journaux de session (si activé)
À l'aide de AWS CLI, vous pouvez consulter la liste des sessions de votre compte, mais pas les informations supplémentaires disponibles dans la console.
Pour en savoir plus sur les détails de l'historique des sessions de journalisation, consultez la page [Activation et désactivation de l’enregistrement de la session](session-manager-logging.md).
**Topics**
+ [Afficher l'historique de session (console)](#view-console)
+ [Affichage de l'historique de session (AWS CLI)](#view-history-cli)
## Afficher l'historique de session (console)
Vous pouvez utiliser la AWS Systems Manager console pour consulter les détails des sessions de votre compte.
**Afficher l'historique de session (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 **Session Manager**.
1. Sélectionnez l'onglet **Session history (Historique de session)**.
-ou-
Si la page d'accueil de Session Manager s'ouvre en premier, choisissez **Configurer les préférences**, puis l'onglet **Historique des sessions**.
## Affichage de l'historique de session (AWS CLI)
Pour afficher la liste des sessions de votre compte à l'aide de AWS CLI, exécutez la commande suivante.
```
aws ssm describe-sessions \
--state History
```
**Note**
Cette commande renvoie uniquement les résultats pour les connexions à des cibles initiées à l'aide de Session Manager. Il ne répertorie pas les connexions effectuées par d'autres moyens, tels que le protocole RDP (Remote Desktop Protocol) ou le protocole SSH (Secure Shell Protocol).
Pour plus d'informations sur les autres options que vous pouvez utiliser avec la **describe-sessions** commande, reportez-vous [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html)à la AWS Systems Manager section de la référence des AWS CLI commandes.
# Journalisation de l’activité de session
En plus de fournir des informations sur les sessions actuelles et terminées dans la console Systems Manager, Session Manager vous offre la possibilité d’enregistrer l’activité de votre compte Compte AWS à l’aide de AWS CloudTrail.
CloudTrail capture les appels d'API de session via la console Systems Manager, le AWS Command Line Interface (AWS CLI) et le SDK Systems Manager. Vous pouvez consulter les informations sur la CloudTrail console ou les stocker dans un compartiment Amazon Simple Storage Service (Amazon S3) spécifique. Un compartiment Amazon S3 est utilisé pour tous les CloudTrail journaux de votre compte. Pour de plus amples informations, veuillez consulter [Journalisation des appels d' AWS Systems Manager API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
**Note**
Pour une analyse analytique récurrente et historique de vos fichiers journaux, pensez à interroger les CloudTrail journaux à l'aide de [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) ou d'une table que vous gérez. Pour plus d'informations, consultez la section [Interrogation des AWS CloudTrail journaux](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html) dans le *guide de AWS CloudTrail l'utilisateur*.
## Surveillance de l'activité des sessions à l'aide d'Amazon EventBridge (console)
Avec EventBridge, vous pouvez définir des règles pour détecter les modifications apportées aux AWS ressources. Vous pouvez créer une règle pour détecter lorsqu'un utilisateur de votre organisation démarre ou met fin à une session puis, par exemple, recevoir une notification via Amazon SNS vous informant de l'événement.
EventBridge le support de Session Manager repose sur les enregistrements des opérations d'API enregistrés par CloudTrail. (Vous pouvez utiliser CloudTrail l'intégration avec EventBridge pour répondre à la plupart des AWS Systems Manager événements.) Les actions effectuées au cours d'une session, telles qu'une `exit` commande, qui n'effectuent pas d'appel d'API ne sont pas détectées par EventBridge.
Les étapes suivantes expliquent comment lancer des notifications via Amazon Simple Notification Service (Amazon SNS) lorsqu'un événement d'API Session Manager se produit, tel que **StartSession**.
**Pour surveiller l'activité des sessions à l'aide d'Amazon EventBridge (console)**
1. Créez une rubrique Amazon SNS à utiliser pour envoyer des notifications lorsque l'événement Session Manager que vous souhaitez suivre se produit.
Pour en savoir plus, consultez [Création d'une rubrique](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) dans le *Manuel du développeur d'Amazon Simple Notification Service*.
1. Créez une EventBridge règle pour appeler la cible Amazon SNS pour le type d'Session Managerévénement que vous souhaitez suivre.
Pour plus d'informations sur la création de la règle, consultez la section [Création de EventBridge règles Amazon qui réagissent aux événements](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) dans le *guide de EventBridge l'utilisateur Amazon*.
Tout au long de la création de votre règle, sélectionnez les éléments suivants :
+ Pour le **AWS service** choisissez **Systems Manager**.
+ Pour **Type d'événement**, choisissez **AWS API Call through CloudTrail**.
+ Sélectionnez **Specific operation(s) (Opérations spécifiques)**, puis saisissez la ou les commandes Session Manager (l'une après l'autre) pour lesquelles vous souhaitez recevoir des notifications. Vous pouvez choisir **StartSession****ResumeSession**, et**TerminateSession**. (EventBridge ne prend pas en charge `Describe*` les commandes `Get*`` List*`, et.)
+ Pour **Sélectionner une cible**, choisissez **Rubrique SNS**. Pour **Topic (Rubrique)**, sélectionnez le nom de la rubrique Amazon SNS que vous avez créée à l'étape 1.
Pour plus d'informations, consultez le *[guide de EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* *[et le guide de démarrage d'Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/gsg/)*.
# Activation et désactivation de l’enregistrement de la session
L’enregistrement des sessions enregistre des informations sur les sessions en cours et terminées dans la console Systems Manager. Vous pouvez également enregistrer les détails des commandes exécutées pendant les sessions dans votre Compte AWS. L’enregistrement de la session vous permet d’effectuer les tâches suivantes :
+ Créer et stocker des journaux de session à des fins d'archivage.
+ Générer un rapport affichant les détails de chaque connexion à vos nœuds gérés via Session Manager au cours des 30 derniers jours.
+ Générez des notifications pour la connexion à votre session Compte AWS, telles que les notifications Amazon Simple Notification Service (Amazon SNS).
+ Lancez automatiquement une autre action sur une AWS ressource à la suite d'actions effectuées au cours d'une session, telles que l'exécution d'une AWS Lambda fonction, le démarrage d'un AWS CodePipeline pipeline ou l'exécution d'un AWS Systems Manager Run Command document.
**Important**
Prenez note des exigences et limitations suivantes pour Session Manager :
Session Manager journalise les commandes que vous saisissez, et leur sortie, durant une session, en fonction de vos préférences de session. Pour empêcher l'affichage de données sensibles, telles que les mots de passe, dans vos journaux de session, nous vous recommandons d'utiliser les commandes suivantes lors de la saisie de données sensibles durant une session.
```
stty -echo; read passwd; stty echo;
```
```
$Passwd = Read-Host -AsSecureString
```
Si vous utilisez Windows Server 2012 ou version antérieure, les données contenues dans vos journaux peuvent ne pas être formatées de manière optimale. Nous vous recommandons d'utiliser Windows Server 2012 R2 et versions ultérieures pour optimiser vos formats de journaux.
Si vous utilisez des nœuds gérés Linux ou macOS, assurez-vous que l'utilitaire d'écran est installé. Si ce n'est pas le cas, il se peut que vos données de journaux soient tronquées. Sur Amazon Linux 2, AL2 023 et 8Ubuntu Server, l'utilitaire d'écran est installé par défaut. Pour installer l'écran manuellement, selon votre version de Linux, exécutez `sudo yum install screen` ou `sudo apt-get install screen`.
La journalisation n'est pas disponible pour les sessions Session Manager qui se connectent via le réacheminement de port ou SSH. Cela est dû au fait que le protocole SSH chiffre toutes les données de session au sein de la connexion TLS sécurisée établie entre les Session Manager points de terminaison AWS CLI et et sert Session Manager uniquement de tunnel pour les connexions SSH.
Pour plus d'informations sur les autorisations requises pour utiliser Amazon S3 ou Amazon CloudWatch Logs pour la journalisation des données de session, consultez[Création d'un rôle IAM avec des autorisations pour Session Manager Amazon S3 et CloudWatch Logs (console)](getting-started-create-iam-instance-profile.md#create-iam-instance-profile-ssn-logging).
Pour de plus amples informations sur les options de journalisation pour Session Manager, veuillez consulter les rubriques suivantes.
**Topics**
+ [Données de session de streaming à l'aide d'Amazon CloudWatch Logs (console)](session-manager-logging-cwl-streaming.md)
+ [Journalisation des données de session avec Amazon S3 (console)](session-manager-logging-s3.md)
+ [Enregistrement des données de session à l'aide d'Amazon CloudWatch Logs (console)](session-manager-logging-cloudwatch-logs.md)
+ [Configuration de l’enregistrement des sessions sur le disque](session-manager-logging-disk.md)
+ [Régler la durée pendant laquelle le fichier journal temporaire Session Manager est stocké sur le disque](session-manager-logging-disk-retention.md)
+ [Désactivation de la Session Manager connexion dans CloudWatch Logs et Amazon S3](session-manager-enable-and-disable-logging.md)
# Données de session de streaming à l'aide d'Amazon CloudWatch Logs (console)
Vous pouvez envoyer un flux continu de journaux de données de session à Amazon CloudWatch Logs. Les détails essentiels, tels que les commandes qu'un utilisateur a exécutées dans une session, l'ID de l'utilisateur qui a exécuté les commandes et les horodatages indiquant le moment où les données de session sont diffusées vers CloudWatch Logs, sont inclus lors de la diffusion en continu des données de session. Lors du streaming de données de session, les journaux sont au format JSON afin de faciliter l'intégration à vos solutions de journalisation existantes. Le streaming de données de session n'est pas pris en charge pour les commandes interactives
**Note**
Le streaming de données de session à partir de nœuds gérés Windows Server implique que PowerShell 5.1 ou version ultérieure soit installé. Par défaut, la version PowerShell requise est installée sur Windows Server 2016 et versions ultérieures. Cependant, Windows Server 2012 et 2012 R2 n'ont pas la version PowerShell requise installée par défaut. Si vous n'avez pas encore mis à jour PowerShell sur vos nœuds gérés Windows Server 2012 ou 2012 R2, vous pouvez le faire en utilisant Run Command. Pour plus d'informations sur la mise à jour de PowerShell à l'aide de Run Command, veuillez consulter la rubrique [Mise à jour PowerShell en utilisant Run Command](run-command-tutorial-update-software.md#rc-console-pwshexample).
**Important**
Si le paramètre de politique de **PowerShell transcription** est configuré sur vos nœuds Windows Server gérés, vous ne pourrez pas diffuser les données de session.
**Pour diffuser des données de session à l'aide d'Amazon CloudWatch Logs (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Cochez la case à côté de **Activer** dans le cadre de la **CloudWatch journalisation**.
1. Sélectionnez l'option **Streaming de journaux de session**.
1. (Recommandé) Cochez la case à côté de **Autoriser uniquement les groupes de CloudWatch journaux chiffrés**. Une fois cette option activée, les données de journaux sont chiffrées à l'aide du chiffrement côté serveur des clés spécifiées pour le groupe de journaux. Si vous ne souhaitez pas chiffrer les données du journal envoyées à CloudWatch Logs, décochez la case. Vous devez également décocher la case si le chiffrement n'est pas autorisé sur le groupe de journaux.
1. Pour les **CloudWatch journaux**, pour spécifier le groupe de CloudWatch journaux Logs existant dans le répertoire Compte AWS auquel vous souhaitez télécharger les journaux de session, sélectionnez l'une des options suivantes :
+ Saisissez le nom d'un groupe de journaux dans la zone de texte qui a déjà été créé dans votre compte pour stocker les données de journal de session.
+ **Browse log groups (Rechercher des groupes de journaux)** : sélectionnez un groupe de journaux qui a déjà été créé dans votre compte pour stocker les données de journaux de session.
1. Choisissez **Enregistrer**.
# Journalisation des données de session avec Amazon S3 (console)
Vous pouvez choisir de stocker les données des journaux de session dans un compartiment Amazon Simple Storage Service (Amazon S3) de votre choix à des fins de débogage et de résolution des problèmes. L'option par défaut est pour les journaux à envoyer à un compartiment Amazon S3 chiffré. Le chiffrement est effectué à l'aide de la clé spécifiée pour le compartiment, qu'il s' AWS KMS key agisse d'une clé de chiffrement côté serveur (SSE) Amazon S3 (AES-256).
**Important**
Lorsque vous utilisez des compartiments d'hébergement virtuel avec SSL (Secure Sockets Layer), le certificat générique SSL correspond uniquement aux compartiments qui ne contiennent pas de points. Pour contourner ce problème, utilisez HTTP ou écrivez votre propre logique de vérification de certificat. Il est recommandé de ne pas utiliser de point (".") dans les noms de compartiment lors de l'utilisation de compartiments d'hébergement virtuel.
**Chiffrement de compartiment Amazon S3**
Pour envoyer les journaux vers votre compartiment Amazon S3 via le chiffrement, le chiffrement doit être autorisé sur le compartiment. Pour de plus amples informations sur le chiffrement des compartiments Amazon S3, consultez la section [Chiffrement par défaut Amazon S3 pour les compartiments S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
**Clé gérée par le client**
Si vous utilisez une clé KMS que vous gérez vous-même pour chiffrer votre compartiment, alors le profil d'instance IAM attaché à vos instances doit disposer des autorisations explicites pour lire la clé. Si vous utilisez un Clé gérée par AWS, l'instance n'a pas besoin de cette autorisation explicite. Pour de plus amples informations sur l'octroi d'une autorisation d'utilisation d'une clé à un profil d'instance, veuillez consulter [Autorise les utilisateurs de clé à utiliser la clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) dans le *Guide du développeur AWS Key Management Service *.
Suivez ces étapes pour configurer Session Manager afin de stocker les journaux de session dans un compartiment Amazon S3.
**Note**
Vous pouvez également utiliser le AWS CLI pour spécifier ou modifier le compartiment Amazon S3 auquel les données de session sont envoyées. Pour plus d'informations, consultez [Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md).
**Pour journaliser les données de session avec Amazon S3 (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Cochez la case en regard de **Activer**, sous **Journalisation S3**.
1. (Recommandé) Cochez la case en regard de **Allow only encrypted S3 buckets (Autoriser uniquement les compartiments S3 chiffrés)**. Lorsque cette option est activée, les données de journaux sont chiffrées à l'aide de la clé de chiffrement côté serveur spécifiée pour le compartiment. Si vous ne voulez pas chiffrer les données de journaux qui sont envoyées vers Amazon S3, décochez la case. Vous devez également décocher la case si le chiffrement n'est pas autorisé sur le compartiment S3.
1. Pour **S3 bucket name (Nom du compartiment S3)**, sélectionnez l'une des opérations suivantes :
**Note**
Il est recommandé de ne pas utiliser de point (".") dans les noms de compartiment lors de l'utilisation de compartiments d'hébergement virtuel. Pour de plus amples informations sur les conventions de dénomination des compartiments Amazon S3, veuillez consulter [Limites et restrictions applicables aux compartiments](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
+ **Choose a bucket name from the list (Choisir un nom de compartiment dans la liste)** : sélectionnez un compartiment Amazon S3 qui a déjà été créé dans votre compte pour stocker les données de journaux de session.
+ **Saisissez le nom du compartiment dans la zone de texte** : saisissez le nom d'un compartiment Amazon S3 qui a déjà été créé dans votre compte pour stocker les données de journal de session.
1. (Facultatif) Pour **S3 key prefix (Préfixe de clé S3)**, saisissez le nom d'un dossier existant ou d'un nouveau dossier pour stocker les journaux dans le compartiment sélectionné.
1. Sélectionnez **Enregistrer**.
Pour plus d'informations sur l'utilisation d'Amazon S3 et des compartiments Amazon S3, veuillez consulter le *[Guide de l'utilisateur Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)* et le *[Guide de l'utilisateur Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)*.
# Enregistrement des données de session à l'aide d'Amazon CloudWatch Logs (console)
Avec Amazon CloudWatch Logs, vous pouvez surveiller, stocker et accéder à des fichiers journaux provenant de différents sites Services AWS. Vous pouvez envoyer les données du journal de session à un groupe de CloudWatch journaux de journaux à des fins de débogage et de résolution des problèmes. L'option par défaut est que les données de journaux soient envoyées avec chiffrement à l'aide de votre clé KMS, mais vous pouvez envoyer les données à votre groupe de journaux avec ou sans chiffrement.
Suivez ces étapes AWS Systems Manager Session Manager pour configurer l'envoi des données du journal de session à un groupe de CloudWatch journaux de journaux à la fin de vos sessions.
**Note**
Vous pouvez également utiliser le AWS CLI pour spécifier ou modifier le groupe de CloudWatch journaux des journaux auquel les données de session sont envoyées. Pour plus d'informations, consultez [Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md).
**Pour enregistrer les données de session à l'aide d'Amazon CloudWatch Logs (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Cochez la case à côté de **Activer** dans le cadre de la **CloudWatch journalisation**.
1. Sélectionnez l'option **Chargement de journaux de session**.
1. (Recommandé) Cochez la case à côté de **Autoriser uniquement les groupes de CloudWatch journaux chiffrés**. Une fois cette option activée, les données de journaux sont chiffrées à l'aide du chiffrement côté serveur des clés spécifiées pour le groupe de journaux. Si vous ne souhaitez pas chiffrer les données du journal envoyées à CloudWatch Logs, décochez la case. Vous devez également décocher la case si le chiffrement n'est pas autorisé sur le groupe de journaux.
1. Pour les **CloudWatch journaux**, pour spécifier le groupe de CloudWatch journaux Logs existant dans le répertoire Compte AWS auquel vous souhaitez télécharger les journaux de session, sélectionnez l'une des options suivantes :
+ **Choose a log group from the list (Choisir un groupe de journaux dans la liste)** : utilisez un groupe de journaux qui a déjà été créé dans votre compte pour stocker les données de journaux de session.
+ **Saisissez un nom de groupe de journaux dans la zone de texte** : entrez le nom d'un groupe de journaux qui a déjà été créé dans votre compte pour stocker les données de journal de session.
1. Choisissez **Enregistrer**.
Pour plus d'informations sur l'utilisation des CloudWatch journaux, consultez le *[guide de l'utilisateur Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*.
# Configuration de l’enregistrement des sessions sur le disque
Une fois que vous avez activé la Session Manager connexion à Amazon S3 CloudWatch ou Amazon S3, toutes les commandes exécutées au cours d'une session (et le résultat de ces commandes) sont enregistrées dans un fichier temporaire sur le disque de l'instance cible. Le fichier temporaire est nommé `ipcTempFile.log`.
Le `ipcTempFile.log` est contrôlé par le paramètre `SessionLogsDestination` du fichier de configuration SSM Agent. Ce paramètre accepte les valeurs suivantes :
+ **disque** : si vous spécifiez ce paramètre et que la journalisation de session sur Amazon S3 CloudWatch ou sur Amazon S3 *est activée*, SSM Agent crée le fichier journal `ipcTempFile.log` temporaire, enregistre les commandes de session et les affiche sur le disque. Session Managertélécharge ce journal sur S3 CloudWatch ou sur S3 pendant ou après la session, selon la configuration de journalisation. Le journal est ensuite supprimé selon la durée spécifiée pour le paramètre de configuration SSM Agent `SessionLogsRetentionDurationHours`.
Si vous spécifiez ce paramètre et que la journalisation de session sur Amazon S3 CloudWatch et Amazon S3 sont *désactivées*, l'historique des commandes et les résultats sont SSM Agent toujours enregistrés dans le `ipcTempFile.log` fichier. Le fichier sera supprimé selon la durée spécifiée pour le paramètre de configuration SSM Agent `SessionLogsRetentionDurationHours`.
+ **none** : si vous spécifiez ce paramètre et que la journalisation de session sur Amazon S3 CloudWatch ou Amazon S3 est *activée*, la journalisation sur disque fonctionne exactement comme si vous aviez spécifié le `disk` paramètre. SSM Agentnécessite le fichier temporaire lorsque la journalisation de session sur Amazon S3 CloudWatch ou Amazon S3 est activée.
Si vous spécifiez ce paramètre et que la journalisation de session sur Amazon S3 CloudWatch ou Amazon S3 *est désactivée*, le `ipcTempFile.log` fichier SSM Agent ne sera pas créé.
Utilisez la procédure suivante pour activer ou désactiver la création du fichier journal temporaire `ipcTempFile.log` sur le disque lors du démarrage d’une session.
**Pour activer ou désactiver la création du fichier journal temporaire Session Manager sur le disque**
1. Installez SSM Agent sur votre instance ou effectuez une mise à niveau vers la version 3.2.2086 ou supérieure. Pour plus d’informations sur la vérification du numéro de version de l’agent, veuillez consulter [Vérification du numéro de version de l'SSM Agent](ssm-agent-get-version.md). Pour plus d’informations sur l’installation manuelle de l’agent, repérez la procédure qui correspond à votre système d’exploitation dans les sections suivantes :
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Linux](manually-install-ssm-agent-linux.md)
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour macOS](manually-install-ssm-agent-macos.md)
+ [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Windows Server](manually-install-ssm-agent-windows.md)
1. Connectez-vous à votre instance et localisez le fichier `amazon-ssm-agent.json` à l’emplacement suivant.
+ **Linux** :/etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Si le fichier `amazon-ssm-agent.json` n’existe pas, copiez le contenu de `amazon-ssm-agent.json.template` dans un nouveau fichier dans le même répertoire. Nommez le nouveau fichier `amazon-ssm-agent.json`.
1. Spécifiez `none` ou `disk` pour le paramètre `SessionLogsDestination`. Enregistrez vos modifications.
1. [Redémarrez](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
Si vous avez spécifié `disk` pour le paramètre `SessionLogsDestination`, vous pouvez vérifier que SSM Agent crée le fichier journal temporaire en démarrant une nouvelle session, puis en localisant le `ipcTempFile.log` à l’emplacement suivant :
+ **Linux** ://var/lib/amazon/ssm*target ID*/session/orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **macOS**://opt/aws/ssm/data*target ID*/session/orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **Windows Server**: C : \$1 \$1 Amazon ProgramData \$1 SSM \$1 \$1 session InstanceData \$1 orchestration *target ID* \$1 \$1 Standard\$1Stream *session ID* \$1 .log ipcTempFile
**Note**
Par défaut, le fichier journal temporaire est enregistré sur l’instance pendant 14 jours.
Si vous souhaitez mettre à jour le paramètre `SessionLogsDestination` sur plusieurs instances, nous vous recommandons de créer un document SSM qui spécifie la nouvelle configuration. Vous pouvez ensuite utiliser Run Command de Systems Manager pour implémenter le changement sur vos instances. Pour plus d'informations, voir [Rédaction de vos propres AWS Systems Manager documents (blog)](https://aws.amazon.com/blogs/mt/writing-your-own-aws-systems-manager-documents/) et[Exécution de commandes sur des nœuds gérés](running-commands.md).
# Régler la durée pendant laquelle le fichier journal temporaire Session Manager est stocké sur le disque
Une fois que vous avez activé la Session Manager connexion à Amazon S3 CloudWatch ou Amazon S3, toutes les commandes exécutées au cours d'une session (et le résultat de ces commandes) sont enregistrées dans un fichier temporaire sur le disque de l'instance cible. Le fichier temporaire est nommé `ipcTempFile.log`. Au cours d'une session, ou une fois celle-ci terminée, Session Manager télécharge ce journal temporaire vers S3 CloudWatch ou vers S3. Le journal temporaire est ensuite supprimé selon la durée spécifiée pour le paramètre SSM Agent `SessionLogsRetentionDurationHours` de configuration. Par défaut, le fichier journal temporaire est enregistré sur l’instance pendant 14 jours à l’emplacement suivant :
+ **Linux** ://var/lib/amazon/ssm*target ID*/session/orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **macOS**://opt/aws/ssm/data*target ID*/session/orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **Windows Server**: C : \$1 \$1 Amazon ProgramData \$1 SSM \$1 \$1 session InstanceData \$1 orchestration *target ID* \$1 \$1 Standard\$1Stream *session ID* \$1 .log ipcTempFile
Utilisez la procédure suivante pour régler la durée pendant laquelle le fichier journal temporaire Session Manager est stocké sur le disque.
**Pour régler la durée pendant laquelle le fichier `ipcTempFile.log` est stocké sur le disque**
1. Connectez-vous à votre instance et localisez le fichier `amazon-ssm-agent.json` à l’emplacement suivant.
+ **Linux** :/etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Si le fichier `amazon-ssm-agent.json` n’existe pas, copiez le contenu de `amazon-ssm-agent.json.template` dans un nouveau fichier dans le même répertoire. Nommez le nouveau fichier `amazon-ssm-agent.json`.
1. Modifiez la valeur de `SessionLogsRetentionDurationHours` au nombre d’heures souhaité. Si `SessionLogsRetentionDurationHours` est défini sur 0, le fichier journal temporaire est créé pendant la session et supprimé lorsque la session est terminée. Ce paramètre doit garantir que le fichier journal ne sera pas conservé après la fin de la session.
1. Enregistrez vos modifications.
1. [Redémarrez](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
# Désactivation de la Session Manager connexion dans CloudWatch Logs et Amazon S3
Vous pouvez utiliser la console Systems Manager ou désactiver AWS CLI la journalisation des sessions dans votre compte.
**Pour désactiver l’enregistrement de session (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 **Session Manager**.
1. Sélectionnez l'onglet **Préférences**, puis **Modifier**.
1. Pour désactiver la CloudWatch journalisation, dans la section de **CloudWatch journalisation**, décochez la case **Activer**.
1. Pour désactiver la **journalisation S3**, décochez la case **Activer** dans la section Journalisation S3.
1. Choisissez **Enregistrer**.
**Pour désactiver l’enregistrement de session (AWS CLI)**
Pour désactiver la journalisation des sessions à l'aide du AWS CLI, suivez les instructions figurant dans[Mettre à jour les préférences Session Manager (ligne de commande)](getting-started-configure-preferences-cli.md).
Dans votre fichier JSON, assurez-vous que les entrées `s3BucketName` et `cloudWatchLogGroupName` ne contiennent aucune valeur. Par exemple :
```
"inputs": {
"s3BucketName": "",
...
"cloudWatchLogGroupName": "",
...
}
```
Alternativement, pour désactiver l’enregistrement, vous pouvez supprimer toutes les entrées `S3*` et `cloudWatch*` de votre fichier JSON.
**Note**
En fonction de votre configuration, après la désactivation CloudWatch de S3, un fichier journal temporaire peut toujours être généré sur le disque parSSM Agent. Pour plus d’informations sur la façon de désactiver l’enregistrement sur disque, consultez [Configuration de l’enregistrement des sessions sur le disque](session-manager-logging-disk.md).
# Schéma de document de session
Les informations suivantes décrivent les éléments de schéma d'un document de session. AWS Systems Manager Session Manager utilise des documents de session pour déterminer le type de session à démarrer, par exemple, une session standard, une session de réacheminement de port ou une session d'exécution de commande interactive.
[schemaVersion](#version)
Version de schéma du document de session. Les documents de session prennent uniquement en charge la version 1.0.
Type : String
Obligatoire : oui
[description](#descript)
Description que vous spécifiez pour le document de session. Par exemple, « Document pour démarrer la session de réacheminement de port avec Session Manager ».
Type : chaîne
Obligatoire : non
[sessionType](#type)
Type de session établie en utilisant le document de session.
Type : String
Obligatoire : oui
Valeurs valides : `InteractiveCommands` \$1 `NonInteractiveCommands` \$1 `Port` \$1 `Standard_Stream`
[inputs](#in)
Préférences de session à utiliser pour les sessions établies en utilisant ce document de session. Cet élément est nécessaire pour les documents de session utilisés pour créer des sessions `Standard_Stream`.
Type : StringMap
Obligatoire : non
[s3BucketName](#bucket)
Le compartiment Amazon Simple Storage Service (Amazon S3) vers lequel vous voulez envoyer des journaux de session au terme de vos sessions.
Type : chaîne
Obligatoire : non
[s3KeyPrefix](#prefix)
Préfixe à utiliser lors de l'envoi de journaux au compartiment Amazon S3 que vous avez spécifié dans l'entrée `s3BucketName`. Pour de plus amples informations sur l'utilisation d'un préfixe partagé avec des objets stockés dans Amazon S3, veuillez consulter [Utilisation d'un compartiment S3](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html) dans le *Guide de l'utilisateur Amazon Simple Storage*.
Type : chaîne
Obligatoire : non
[s3EncryptionEnabled](#s3Encrypt)
Si l'entrée est définie sur `true`, le compartiment Amazon S3 que vous avez spécifié dans l'entrée `s3BucketName` doit être chiffré.
Type : booléen
Obligatoire : oui
[cloudWatchLogGroupName](#logGroup)
Nom du groupe Amazon CloudWatch Logs (CloudWatch Logs) auquel vous souhaitez envoyer des journaux de session au terme de vos sessions.
Type : chaîne
Obligatoire : non
[cloudWatchEncryptionEnabled](#cwEncrypt)
Si l'entrée est définie sur `true`, le groupe de journaux que vous avez spécifié dans l'entrée `cloudWatchLogGroupName` doit être chiffré.
Type : booléen
Obligatoire : oui
[cloudWatchStreamingEnabled](#cwStream)
Si l'entrée est définie sur `true`, un flux continu de journaux de données de session est envoyé au groupe de journaux que vous avez spécifié dans l'entrée `cloudWatchLogGroupName`. Si l'entrée est définie sur `false`, les journaux de session sont envoyés au groupe de journaux que vous avez spécifié dans l'entrée `cloudWatchLogGroupName` à la fin de vos sessions.
Type : booléen
Obligatoire : oui
[kmsKeyId](#kms)
ID de la AWS KMS key à utiliser pour renforcer le chiffrement des données entre vos machines client locales et les nœuds gérés Amazon Elastic Compute Cloud (Amazon EC2) auxquels vous êtes connecté.
Type : chaîne
Obligatoire : non
[runAsEnabled](#run)
Si l'entrée est définie sur `true`, vous devez spécifier un compte utilisateur existant sur les nœuds gérés auxquels vous vous connecterez dans l'entrée `runAsDefaultUser`. Sinon, les sessions ne démarreront pas. Par défaut, les sessions sont démarrées en utilisant le compte `ssm-user` créé par l'SSM Agent AWS Systems Manager. La fonction Exécuter en tant que n’est prise en charge que pour la connexion aux nœuds gérés Linux et macOS.
Type : booléen
Obligatoire : oui
[runAsDefaultUser](#runUser)
Nom du compte utilisateur avec lequel démarrer les sessions sur les nœuds gérés Linux et macOS lorsque l’entrée `runAsEnabled` est définie sur `true`. Le compte utilisateur que vous spécifiez pour cette entrée doit exister sur les nœuds gérés auxquels vous vous connecterez ; sinon, les sessions ne démarreront pas.
Type : chaîne
Obligatoire : non
[idleSessionTimeout](#timeout)
Durée d'inactivité que vous voulez autoriser avant la fin d'une session. Cette entrée est mesurée en minutes.
Type : String
Valeurs valides : 1-60
Obligatoire : non
[maxSessionDuration](#maxDuration)
Durée maximale que vous voulez autoriser avant la fin d'une session. Cette entrée est mesurée en minutes.
Type : String
Valeurs valides : 1 à 1 440
Obligatoire : non
[shellProfile](#shell)
Préférences que vous spécifiez par système d'exploitation, et qui sont à appliquer dans les sessions, telles que les préférences de shell, les variables d'environnement, les répertoires de travail et l'exécution de plusieurs commandes au démarrage d'une session.
Type : StringMap
Obligatoire : non
[windows](#win)
Préférences de shell, variables d'environnement, répertoires de travail et commandes que vous spécifiez pour les sessions sur les nœuds gérés Windows Server.
Type : chaîne
Obligatoire : non
[linux](#lin)
Préférences de shell, variables d’environnement, répertoires de travail et commandes que vous spécifiez pour les sessions sur les nœuds gérés Linux et macOS.
Type : chaîne
Obligatoire : non
[parameters](#param)
Objet qui définit les paramètres acceptés par le document. Pour plus d'informations sur la définition des paramètres de document, consultez **Paramètres** dans le [Éléments de données niveau supérieur](documents-syntax-data-elements-parameters.md#top-level). Pour les paramètres que vous référencez souvent, nous vous recommandons de les stocker dans Parameter Store de Systems Manager, puis de les référencer. Vous pouvez référencer les paramètres Parameter Store `String` et `StringList` dans cette section d'un document. Vous pouvez référencer les paramètres Parameter Store `SecureString` dans cette section d'un document. Vous pouvez référencer un paramètre Parameter Store en utilisant le format suivant.
```
{{ssm:parameter-name}}
```
Pour plus d’informations sur Parameter Store, consultez [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md).
Type : StringMap
Obligatoire : non
[properties](#props)
Objet dont les valeurs que vous spécifiez sont utilisées dans l'opération d'API `StartSession`.
Pour les documents de session utilisés pour des sessions `InteractiveCommands`, l'objet Propriétés inclut les commandes à exécuter sur les systèmes d'exploitation que vous spécifiez. Vous pouvez également déterminer si les commandes sont exécutées en tant que `root` à l'aide de la propriété booléenne `runAsElevated`. Pour de plus amples informations, consultez [Restreindre l'accès aux commandes dans une session](session-manager-restrict-command-access.md).
Pour les documents de session utilisés pour des sessions `Port`, l'objet Propriétés contient le numéro de port vers lequel le trafic doit être redirigé. Pour obtenir un exemple, veuillez consulter l'exemple de document de session de type `Port` plus loin dans cette rubrique.
Type : StringMap
Obligatoire : non
Exemple de document de session de type `Standard_Stream`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to hold regional settings for Session Manager
sessionType: Standard_Stream
inputs:
s3BucketName: ''
s3KeyPrefix: ''
s3EncryptionEnabled: true
cloudWatchLogGroupName: ''
cloudWatchEncryptionEnabled: true
cloudWatchStreamingEnabled: true
kmsKeyId: ''
runAsEnabled: true
runAsDefaultUser: ''
idleSessionTimeout: '20'
maxSessionDuration: '60'
shellProfile:
windows: ''
linux: ''
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": true,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
------
Exemple de document de session de type `InteractiveCommands`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
Exemple de document de session de type `Port`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to open given port connection over Session Manager
sessionType: Port
parameters:
paramExample:
type: string
description: document parameter
properties:
portNumber: anyPortNumber
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to open given port connection over Session Manager",
"sessionType": "Port",
"parameters": {
"paramExample": {
"type": "string",
"description": "document parameter"
}
},
"properties": {
"portNumber": "anyPortNumber"
}
}
```
------
Exemple de document de session avec caractères spéciaux
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Example document with quotation marks
sessionType: InteractiveCommands
parameters:
Test:
type: String
description: Test Input
maxChars: 32
properties:
windows:
commands: |
$Test = '{{ Test }}'
$myVariable = \"Computer name is $env:COMPUTERNAME\"
Write-Host "Test variable: $myVariable`.`nInput parameter: $Test"
runAsElevated: false
```
------
#### [ JSON ]
```
{
"schemaVersion":"1.0",
"description":"Test document with quotation marks",
"sessionType":"InteractiveCommands",
"parameters":{
"Test":{
"type":"String",
"description":"Test Input",
"maxChars":32
}
},
"properties":{
"windows":{
"commands":[
"$Test = '{{ Test }}'",
"$myVariable = \\\"Computer name is $env:COMPUTERNAME\\\"",
"Write-Host \"Test variable: $myVariable`.`nInput parameter: $Test\""
],
"runAsElevated":false
}
}
}
```
------
# Résolution des problèmes de Session Manager
Consultez les informations suivantes pour tenter de résoudre les problèmes liés à AWS Systems Manager Session Manager.
**Topics**
+ [AccessDeniedException lors de l'appel de l' TerminateSession opération](#session-manager-troubleshooting-access-denied-exception)
+ [Processus de documentation échoué de façon inattendue : le gestionnaire de documents a expiré](#session-manager-troubleshooting-document-worker-timed-out)
+ [Session Manager ne peut pas se connecter à partir de la console Amazon EC2](#session-manager-troubleshooting-EC2-console)
+ [Je n'ai pas le droit de démarrer une session](#session-manager-troubleshooting-start-permissions)
+ [SSM Agent pas en ligne](#session-manager-troubleshooting-agent-not-online)
+ [Je n'ai pas le droit de modifier les préférences de session](#session-manager-troubleshooting-preferences-permissions)
+ [Nœud géré non disponible ou non configuré pour Session Manager](#session-manager-troubleshooting-instances)
+ [Plugin Session Manager introuvable](#plugin-not-found)
+ [Plug-in Session Manager pas ajouté automatiquement au chemin de la ligne de commande (Windows)](#windows-plugin-env-var-not-set)
+ [Le plugin Session Manager ne répond pas](#plugin-unresponsive)
+ [TargetNotConnected](#ssh-target-not-connected)
+ [Affichage d'un écran vide après le démarrage d'une session](#session-manager-troubleshooting-start-blank-screen)
+ [Le nœud géré cesse de répondre lorsque les sessions durent longtemps](#session-manager-troubleshooting-log-retention)
+ [Une erreur s'est produite (InvalidDocument) lors de l'appel de l' StartSession opération](#session-manager-troubleshooting-invalid-document)
## AccessDeniedException lors de l'appel de l' TerminateSession opération
**Problème** : lors de la tentative d’arrêt d’une session, Systems Manager renvoie le message d’erreur suivant :
```
An error occurred (AccessDeniedException) when calling the TerminateSession operation:
User: is not authorized to perform: ssm:TerminateSession on resource:
because no identity-based policy allows the ssm:TerminateSession action.
```
**Solution A : vérifiez que la [dernière version du plug-in Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/plugin-version-history.html) est installée sur le nœud**
Saisissez la commande suivante dans le terminal et appuyez sur Entrée.
```
session-manager-plugin --version
```
**Solution B : installez ou réinstallez la dernière version du plug-in**
Pour de plus amples informations, veuillez consulter [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
**Solution C : tentez de rétablir une connexion au nœud**
Vérifiez que le nœud répond aux demandes. Essayez de rétablir la session. Ou, si nécessaire, ouvrez la console Amazon EC2 et vérifiez que le statut de l’instance est En cours d’exécution.
## Processus de documentation échoué de façon inattendue : le gestionnaire de documents a expiré
**Problème** : lors du démarrage d’une session sur un hôte Linux, Systems Manager renvoie le message d’erreur suivant :
```
document process failed unexpectedly: document worker timed out,
check [ssm-document-worker]/[ssm-session-worker] log for crash reason
```
Si vous avez configuré l’enregistrement SSM Agent, comme décrit dans [Affichage des journaux SSM Agent](ssm-agent-logs.md), vous pouvez voir plus de détails dans le journal de débogage. Pour ce problème, Session Manager affiche l’entrée de journal suivante :
```
failed to create channel: too many open files
```
Cette erreur indique généralement qu’il y a trop de processus de travail Session Manager en cours d’exécution et que le système d’exploitation sous-jacent a atteint une limite. Vous avez deux options à votre disposition pour résoudre ce problème.
**Solution A : augmenter la limite de notification des fichiers du système d’exploitation**
Vous pouvez augmenter la limite en exécutant la commande suivante depuis un hôte Linux distinct. Cette commande utilise Run Command de Systems Manager. La valeur spécifiée augmente `max_user_instances` à 8192. Cette valeur est considérablement supérieure à la valeur par défaut de 128, mais elle ne sollicitera pas les ressources de l’hôte :
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
"commands=sudo sysctl fs.inotify.max_user_instances=8192"
```
**Solution B : diminuer le nombre de notifications de fichiers utilisées par Session Manager l’hôte cible**
Exécutez la commande suivante depuis un hôte Linux distinct pour répertorier les sessions exécutées sur l’hôte cible :
```
aws ssm describe-sessions --state Active --filters key=Target,value=i-02573cafcfEXAMPLE
```
Passez en revue le résultat de la commande pour identifier les sessions dont vous n’avez plus besoin. Vous pouvez mettre fin à ces sessions en exécutant la commande suivante depuis un hôte Linux distinct :
```
aws ssm terminate-session —session-id session ID
```
Optionnellement, une fois qu’il n’y a plus de sessions en cours d’exécution sur le serveur distant, vous pouvez libérer des ressources supplémentaires en exécutant la commande suivante à partir d’un hôte Linux séparé. Cette commande met fin à tous les processus Session Manager exécutés sur l’hôte distant et, par conséquent, à toutes les sessions sur l’hôte distant. Avant d’exécuter cette commande, vérifiez qu’il n’y a aucune session en cours que vous souhaitez conserver :
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
'{"commands":["sudo kill $(ps aux | grep ssm-session-worker | grep -v grep | awk '"'"'{print $2}'"'"')"]}'
```
## Session Manager ne peut pas se connecter à partir de la console Amazon EC2
**Problème** : après avoir créé une nouvelle instance, l’onglet **Session Manager** (après avoir cliqué sur le bouton **Se connecter**) de la console Amazon Elastic Compute Cloud (Amazon EC2) ne vous donne pas la possibilité de vous connecter.
**Solution A : créer un profil d'instance** : si vous ne l'avez pas déjà fait (comme indiqué dans les informations figurant dans l'onglet **Gestionnaire de session** de la console EC2), créez un profil d'instance Gestion des identités et des accès AWS (IAM) en utilisant. Quick Setup Quick Setupest un outil dans AWS Systems Manager.
Session Manager nécessite un profil d'instance IAM pour se connecter à votre instance. Vous pouvez créer un profil d'instance et l'attribuer à votre instance en créant une [configuration de gestion des hôtes](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) avec Quick Setup. Une *configuration de gestion des hôtes* crée un profil d'instance avec les autorisations requises et l'attribue à votre instance. Une configuration de gestion des hôtes active également d’autres outils de Systems Manager et crée des rôles IAM pour exécuter ces outils. L’utilisation de Quick Setup ou des outils activés par la configuration de gestion des hôtes est gratuite. [Ouvrez Quick Setup et créez une configuration de gestion des hôtes](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt).
**Important**
Une fois que vous avez créé la configuration de gestion des hôtes, Amazon EC2 peut prendre plusieurs minutes pour enregistrer la modification et actualiser l'onglet **Gestionnaire de session**. Si, au bout de deux minutes, l’onglet n’affiche pas un bouton **Se connecter**, redémarrez votre instance. Après le redémarrage, si vous ne voyez toujours pas l’option de connexion, ouvrez [Configuration rapide](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt) et vérifiez que vous n’avez qu’une seule configuration de gestion d’hôte. S'il y en a deux, supprimez la configuration la plus ancienne et patientez quelques minutes.
Si vous ne parvenez toujours pas à vous connecter après avoir créé une configuration de gestion des hôtes, ou si vous recevez un message d'erreur, notamment un message d'erreur concernant SSM Agent, consultez l'une des solutions suivantes :
+ [Solution B : aucune erreur, mais impossible de se connecter](#session-manager-troubleshooting-EC2-console-no-error)
+ [Solution C : erreur concernant l'absence de l'SSM Agent](#session-manager-troubleshooting-EC2-console-no-agent)
### Solution B : aucune erreur, mais impossible de se connecter
Si vous avez créé la configuration de gestion des hôtes, que vous avez attendu plusieurs minutes avant d'essayer de vous connecter et que vous ne parvenez toujours pas à vous connecter, il se peut que vous deviez appliquer manuellement la configuration de gestion des hôtes à votre instance. Utilisez la procédure suivante pour mettre à jour une configuration de gestion des hôtes Quick Setup et appliquer des modifications à une instance.
**Pour mettre à jour une configuration de gestion d'hôtes en utilisant Quick Setup**
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 **Quick Setup**.
1. Dans la liste **Configurations**, choisissez la configuration de **Gestion des hôtes** que vous avez créée.
1. Choisissez **Actions**, puis **Enregistrer la configuration**.
1. Au bas de la section **Cibles**, sous **Choisissez la manière dont vous souhaitez cibler les instances**, sélectionnez **Manuel**.
1. Dans la section **Instances**, choisissez l'instance que vous avez créée.
1. Choisissez **Mettre à jour**.
Attendez quelques minutes pour qu'EC2 actualise l'onglet **Session Manager**. Si vous ne parvenez toujours pas à vous connecter ou si vous recevez un message d'erreur, consultez les autres solutions à ce problème.
### Solution C : erreur concernant l'absence de l'SSM Agent
Si vous n'avez pas pu créer de configuration de gestion d'hôte à l'aide deQuick Setup, ou si vous avez reçu un message d'erreur indiquant que vous n'avez SSM Agent pas été installé, vous devrez peut-être procéder à l'installation manuellement SSM Agent sur votre instance. SSM Agentest un logiciel Amazon qui permet à Systems Manager de se connecter à votre instance en utilisantSession Manager. SSM Agentest installé par défaut sur la plupart des Amazon Machine Images (AMIs). Si votre instance a été créée à partir d'une AMI non standard ou d'une ancienne AMI, vous devrez peut-être installer l'agent manuellement. Pour la procédure d'installation de SSM Agent, consultez la rubrique suivante qui correspond au système d'exploitation de votre instance.
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
+ [AlmaLinux](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-alma.html)
+ [Amazon Linux 2 et AL2023](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-al2.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html)
Pour les problèmes liés à SSM Agent, consultez [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md).
## Je n'ai pas le droit de démarrer une session
**Problème** : vous essayez de démarrer une session, mais le système vous indique que vous ne disposez pas des autorisations nécessaires.
+ **Solution** : aucun administrateur système ne vous a accordé Gestion des identités et des accès AWS (IAM) d'autorisations de politique pour démarrer des Session Manager sessions. Pour obtenir des informations, veuillez consulter [Contrôler les accès de session utilisateur aux instances](session-manager-getting-started-restrict-access.md).
## SSM Agent pas en ligne
**Problème** : un message s’affiche sur l’onglet **Session Manager** de l’instance Amazon EC2 indiquant : « SSM Agent n’est pas en ligne. Le SSM Agent n’a pas pu se connecter à un point de terminaison du gestionnaire de systèmes pour s’enregistrer avec le service. »
**Solution** : SSM Agent est un logiciel Amazon qui s’exécute sur des instances Amazon EC2 pour permettre à Session Manager de s’y connecter. Si cette erreur s’affiche, cela signifie que SSM Agent ne peut pas établir une connexion avec le point de terminaison Systems Manager. Le problème peut être dû à des restrictions de pare-feu, à des problèmes de routage ou à un manque de connectivité Internet. Pour résoudre ce problème, étudiez les problèmes de connectivité réseau. Pour plus d’informations, consultez [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md) et [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md). Pour plus d’informations sur les points de terminaison Systems Manager, veuillez consulter [Points de terminaison et quotas AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html) dans la référence générale AWS .
## Je n'ai pas le droit de modifier les préférences de session
**Problème** : vous essayez de mettre à jour des préférences de session globales pour votre organisation, mais le système vous indique que vous ne disposez pas des autorisations nécessaires.
+ **Solution** : un administrateur système ne vous a pas accordé les autorisations de politique IAM pour configurer des préférences Session Manager. Pour plus d'informations, consultez [Accorder ou révoquer des autorisations utilisateur pour mettre à jour des préférences Session Manager](preference-setting-permissions.md).
## Nœud géré non disponible ou non configuré pour Session Manager
**Problème 1** : vous souhaitez démarrer une session sur la page de la console **Start a session (Démarrer une session)**, mais le nœud géré ne figure pas dans la liste.
+ **Solution A** : Le nœud géré auquel vous souhaitez vous connecter n'a peut-être pas été configuré AWS Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).
**Note**
S'il AWS Systems Manager SSM Agent est déjà exécuté sur un nœud géré lorsque vous attachez le profil d'instance IAM, vous devrez peut-être redémarrer l'agent avant que l'instance ne soit répertoriée sur la page de console **Démarrer une session**.
+ **Solution B** : la configuration de proxy que vous avez appliquée à l'SSM Agent sur votre nœud géré peut être incorrecte. Si la configuration du proxy est incorrecte, le nœud géré ne sera pas en mesure d'atteindre les points de terminaison de service nécessaires, ou le nœud pourra signaler un système d'exploitation différent à Systems Manager. Pour plus d’informations, consultez [Configuration de SSM Agent pour l’utilisation d’un proxy sur les nœuds Linux](configure-proxy-ssm-agent.md) et [Configurer l'SSM Agent pour utiliser un proxy pour les instances Windows Server](configure-proxy-ssm-agent-windows.md).
**Problème 2** : un nœud géré auquel vous souhaitez vous connecter figure dans la liste sur la page de la console **Start a session (Démarrer une session)**, mais la page indique que « L'instance que vous avez sélectionnée n'est pas configurée pour utiliser Session Manager ».
+ **Solution A** : le nœud géré a été configuré pour une utilisation avec le service Systems Manager, mais le profil d’instance IAM attaché au nœud n’inclut peut-être pas les autorisations relatives à l’outil Session Manager. Pour en savoir plus, consultez la page [Vérifier ou créer un profil d'instance IAM avec des autorisations Session Manager](session-manager-getting-started-instance-profile.md).
+ **Solution B** : le nœud géré n'exécute pas une version de l'SSM Agent qui prend en charge Session Manager. Mettez à jour l'SSM Agent du nœud vers la version 2.3.68.0 ou ultérieure.
Mettez manuellement à jour l'SSM Agent sur un nœud géré en suivant la procédure décrite sur les pages [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Windows Server](manually-install-ssm-agent-windows.md), [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Linux](manually-install-ssm-agent-linux.md) ou [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour macOS](manually-install-ssm-agent-macos.md), selon votre système d'exploitation.
Vous pouvez également utiliser le document Run Command `AWS-UpdateSSMAgent` pour mettre à jour la version de l'agent sur un ou plusieurs nœuds gérés à la fois. Pour plus d'informations, consultez [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
**Astuce**
Pour garder constamment votre agent à jour, nous vous recommandons de configurer la mise à jour automatique de l'SSM Agent vers la dernière version, tel qu'expliqué ci-dessous :
Exécutez `AWS-UpdateSSMAgent` dans le cadre d'une association State Manager. Pour plus d'informations, consultez [Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI](state-manager-update-ssm-agent-cli.md).
Exécutez `AWS-UpdateSSMAgent` dans le cadre d'une fenêtre de maintenance. Pour de plus amples informations sur l'utilisation des fenêtres de maintenance, veuillez consulter [Création et gestion de fenêtres de maintenance à l’aide de la console](sysman-maintenance-working.md) et [Tutoriel : Création et configuration d'une fenêtre de maintenance à l'aide du AWS CLI](maintenance-windows-cli-tutorials-create.md).
+ **Solution C** : le nœud géré ne peut pas atteindre les points de terminaison de service nécessaires. Vous pouvez améliorer le niveau de sécurité de vos nœuds gérés en utilisant des points de terminaison d'interface optimisés AWS PrivateLink pour vous connecter aux points de terminaison Systems Manager. L'alternative à l'utilisation de points de terminaison d'interface consiste à activer l'accès Internet sortant sur vos nœuds gérés. Pour plus d'informations, consultez [Utiliser PrivateLink pour configurer un point de terminaison VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html) pour. Session Manager
+ **Solution D** : le nœud géré dispose de ressources d'UC ou de mémoire limitées. Même si votre nœud géré est fonctionnel, s'il ne dispose pas de ressources suffisantes, vous ne pouvez pas établir de session. Pour de plus amples informations, veuillez consulter [Résolution d'un problème d'instance inaccessible](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html).
## Plugin Session Manager introuvable
Pour utiliser les commandes AWS CLI d'exécution de session, le Session Manager plugin doit également être installé sur votre machine locale. Pour plus d'informations, consultez [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
## Plug-in Session Manager pas ajouté automatiquement au chemin de la ligne de commande (Windows)
Lorsque vous installez le plug-in Session Manager sur Windows, le fichier exécutable `session-manager-plugin` doit être ajouté automatiquement à la variable d'environnement `PATH` de votre système d'exploitation. Si la commande échoue après l'avoir exécutée pour vérifier si le plugin Session Manager était correctement installé (`aws ssm start-session --target instance-id`), vous devrez peut-être effectuer cet ajout manuellement à l'aide de la procédure suivante.
**Pour modifier votre variable PATH (Windows)**
1. Appuyez sur la touche Windows et saisissez **environment variables**.
1. Sélectionnez **Modifier les variables d'environnement pour votre compte**.
1. Sélectionnez **PATH**, puis **Modifier**.
1. Ajoutez des chemins d'accès dans le champ **Variable value (Valeur de la variable)**, en les séparant par des points virgules, tel qu'illustré dans l'exemple : *`C:\existing\path`*;*`C:\new\path`*
*`C:\existing\path`* représente la valeur déjà dans le champ. *`C:\new\path`* représente le chemin que vous souhaitez ajouter, comme indiqué dans l’exemple suivant.
+ **machines 64 bits** : `C:\Program Files\Amazon\SessionManagerPlugin\bin\`
1. Sélectionnez **OK** deux fois pour appliquer les nouveaux paramètres.
1. Fermez toute invite de commande en cours d'exécution et rouvrez.
## Le plugin Session Manager ne répond pas
Durant une session de réacheminement de port, si un logiciel antivirus est installé sur votre ordinateur local, le réacheminement du trafic peut s'arrêter. Dans certains cas, l'interférence d'un logiciel antivirus avec le plugin Session Manager provoque des deadlocks. Pour résoudre ce problème, autorisez ou excluez le plugin Session Manager dans le logiciel antivirus. Pour obtenir des informations sur le chemin d'installation par défaut pour le plugin Session Manager, veuillez consulter [Installez le Session Manager plugin pour AWS CLI](session-manager-working-with-install-plugin.md).
## TargetNotConnected
**Problème** : vous essayez de démarrer une session, mais le système renvoie le message d'erreur « Une erreur s'est produite (TargetNotConnected) lors de l'appel de l' StartSession opération : *InstanceID* n'est pas connecté ».
+ **Solution A** : cette erreur est renvoyée lorsque le nœud géré cible spécifié pour la session n'est pas entièrement configuré pour être utilisé avec Session Manager. Pour plus d'informations, consultez [Configuration de Session Manager](session-manager-getting-started.md).
+ **Solution B** : Cette erreur est également renvoyée si vous tentez de démarrer une session sur un nœud géré situé dans un autre Compte AWS ou Région AWS.
## Affichage d'un écran vide après le démarrage d'une session
**Problème**: vous démarrez une session et Session Manager affiche un écran vide.
+ **Solution A** : ce problème peut se produire lorsque le volume racine du nœud géré est plein. En raison du manque d'espace disque, l'SSM Agent sur le nœud géré cesse de fonctionner. Pour résoudre ce problème, utilisez Amazon CloudWatch pour collecter des métriques et des journaux à partir des systèmes d'exploitation. Pour plus d'informations, consultez la section [Collecter des métriques, des journaux et des traces avec l' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
+ **Solution B** : un écran vide peut s'afficher si vous avez accédé à la console à l'aide d'un lien qui inclut un point de terminaison et une paire de régions non appariées. Par exemple, dans l'URL de la console suivante, `us-west-2` est le point de terminaison spécifié, mais `us-west-1` est la Région AWS spécifiée :
```
https://us-west-2.console.aws.amazon.com/systems-manager/session-manager/sessions?region=us-west-1
```
+ **Solution C** : Le nœud géré se connecte à Systems Manager via des points de terminaison VPC, et vos Session Manager préférences écrivent le résultat de la session dans un compartiment Amazon S3 ou un groupe de CloudWatch journaux Amazon Logs, mais aucun point de terminaison de `s3` passerelle ou d'`logs`interface n'existe dans le VPC. Un point de terminaison `s3` au format **`com.amazonaws.region.s3`** est requis si vos nœuds gérés se connectent à Systems Manager à l'aide de points de terminaison de VPC et que vos préférences Session Manager écrivent la sortie de session dans un compartiment Amazon S3. Un `logs` point de terminaison au format **`com.amazonaws.region.logs`**est également requis si vos nœuds gérés se connectent à Systems Manager à l'aide de points de terminaison VPC et si vos Session Manager préférences écrivent le résultat de la session dans un groupe de CloudWatch journaux Logs. Pour de plus amples informations, veuillez consulter [Création de points de terminaison de VPC pour Systems Manager](setup-create-vpc.md#create-vpc-endpoints).
+ **Solution D** : le groupe de journaux ou le compartiment Amazon S3 que vous avez spécifié dans vos préférences de session a été supprimé. Pour résoudre ce problème, mettez à jour vos préférences de session avec un groupe de journaux ou un compartiment S3 valide.
+ **Solution E** : le groupe de journaux ou le compartiment Amazon S3 que vous avez spécifié dans vos préférences de session n'est pas chiffré, mais vous avez défini l'entrée `cloudWatchEncryptionEnabled` ou `s3EncryptionEnabled` sur `true`. Pour résoudre ce problème, mettez à jour vos préférences de session avec un groupe de journaux ou un compartiment Amazon S3 chiffré, ou définissez l'entrée `cloudWatchEncryptionEnabled` ou `s3EncryptionEnabled` sur `false`. Ce scénario s'applique uniquement aux clients qui créent des préférences de session avec les outils de ligne de commande.
## Le nœud géré cesse de répondre lorsque les sessions durent longtemps
**Problème** : votre nœud géré ne répond plus ou se bloque lorsqu'une session dure longtemps.
**Solution** : réduisez la durée de conservation des journaux de l'SSM Agent pour Session Manager.
**Pour réduire la durée de conservation des journaux de l'SSM Agent pour les sessions**
1. Localisez le `amazon-ssm-agent.json.template` dans le répertoire `/etc/amazon/ssm/` pour Linux, ou `C:\Program Files\Amazon\SSM` pour Windows.
1. Copiez le contenu du `amazon-ssm-agent.json.template` dans un nouveau fichier nommé `amazon-ssm-agent.json`, dans le même répertoire.
1. Réduisez la valeur par défaut de la valeur `SessionLogsRetentionDurationHours` dans la propriété `SSM` et enregistrez le fichier.
1. Redémarrez SSM Agent.
## Une erreur s'est produite (InvalidDocument) lors de l'appel de l' StartSession opération
**Problème** : Le message d'erreur suivant s'affiche lorsque vous démarrez une session à l'aide de AWS CLI.
```
An error occurred (InvalidDocument) when calling the StartSession operation: Document type: 'Command' is not supported. Only type: 'Session' is supported for Session Manager.
```
**Solution** : Le document SSM que vous avez spécifié pour le paramètre `--document-name` n'est pas un document de *Session*. Utilisez la procédure suivante pour afficher la liste des documents de session dans la AWS Management Console.
**Pour afficher la liste des documents de session**
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, cliquez sur **Documents**.
1. Dans la liste des **Catégories**, sélectionnez **Documents de session**.
# AWS Systems Manager State Manager
State Manager, un outil de AWS Systems Manager, est un service de gestion de configuration sécurisé et évolutif qui automatise le processus de maintien de vos nœuds gérés et autres AWS ressources dans un état que vous définissez. Pour vos premiers pas dans State Manager, ouvrez [Systems Manager console](https://console.aws.amazon.com//systems-manager/state-manager). Dans le panneau de navigation, sélectionnez **State Manager**.
**Note**
State Manager et Maintenance Windows peuvent effectuer certains types de mises à jour similaires sur vos nœuds gérés. Votre choix dépend de la nécessité d'automatiser la conformité du système ou d'effectuer des tâches hautement prioritaires et sensibles au temps pendant les périodes que vous spécifiez.
Pour de plus amples informations, veuillez consulter [Choisir entre State Manager et Maintenance Windows](state-manager-vs-maintenance-windows.md).
## Comment mon organisation peut-elle tirer parti de State Manager ?
En utilisant des documents Systems Manager préconfigurés (documents SSM), State Manager offre les avantages suivants pour la gestion de vos nœuds :
+ Amorcer les nœuds avec un logiciel spécifique au démarrage.
+ Télécharger et mettre à jour les agents selon un programme défini, y compris l'SSM Agent.
+ Configurer les paramètres réseau.
+ Associer des nœuds à un domaine Microsoft Active Directory.
+ Exécuter les scripts sur les nœuds gérés Linux, macOS et Windows Server tout au long de leur cycle de vie.
Pour gérer la dérive de configuration entre d'autres AWS ressources, vous pouvez utiliser Automation, un outil de Systems Manager, State Manager pour effectuer les types de tâches suivants :
+ Attachez un rôle Systems Manager à des instances Amazon Elastic Compute Cloud (Amazon EC2) pour en faire des *nœuds gérés*.
+ Appliquer les règles d'entrée et de sortie souhaitées pour un groupe de sécurité.
+ Créez ou supprimez des sauvegardes Amazon DynamoDB.
+ Créez ou supprimez des instantanés Amazon Elastic Block Store (Amazon EBS).
+ Désactivez les autorisations de lecture et d'écriture sur des compartiments Amazon Simple Storage Service (Amazon S3).
+ Démarrez, redémarrez ou arrêtez des nœuds gérés et des nœuds Amazon Relational Database Service (Amazon RDS).
+ Appliquez des correctifs à des AMIs Linux, macOS et Windows.
Pour plus d'informations sur l'utilisation de State Manager avec des runbooks Automation, consultez [Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
## À qui est destiné State Manager ?
State Managerconvient à tous les AWS clients qui souhaitent améliorer la gestion et la gouvernance de leurs AWS ressources et réduire la dérive des configurations.
## Quelles sont les fonctions d'State Manager ?
Les principales fonctionnalités de State Manager sont décrites ci-après.
+
**Associations dans State Manager**
Une State Manager *association* est une configuration que vous attribuez à vos AWS ressources. La configuration définit le statut que vous souhaitez conserver sur vos ressources. Par exemple, une association peut spécifier qu'un logiciel antivirus doit être installé et s'exécuter sur un nœud géré, ou que certains ports doivent être fermés.
Une association spécifie une planification indiquant quand appliquer la configuration et quelles sont les cibles de l'association. Par exemple, une association pour un logiciel antivirus peut s'exécuter une fois par jour sur tous les nœuds gérés d'un Compte AWS. Si le logiciel n'est pas installé sur un nœud, l'association pourrait demander à State Manager de l'installer. Si le logiciel est installé, mais que le service ne s'exécute pas, l'association pourrait demander à State Manager de démarrer le service.
+
**Options de planification flexibles**
State Manager offre les options suivantes de planification lorsqu'une association s'exécute :
+ **Traitement immédiat ou retardé**
Lorsque vous créez une association, par défaut, le système l'exécute immédiatement sur les ressources spécifiées. Après l'exécution initiale, l'association s'exécute à des intervalles selon la planification que vous définissez.
Vous pouvez demander à State Manager de ne pas exécuter immédiatement une association en utilisant l'option **Apply association only at the next specified Cron interval** (Appliquer l'association uniquement à l'intervalle Cron spécifié suivant) dans la console ou le paramètre `ApplyOnlyAtCronInterval` de la ligne de commande.
+ **Expressions cron et rate**
Lorsque vous créez une association, vous spécifiez le moment où State Manager applique la configuration. State Manager prend en charge la plupart des expressions cron et rate standard pour la planification lorsqu'une association s'exécute. State Manager prend également en charge les expressions cron qui incluent un jour de la semaine et le signe numérique (\$1) pour désigner le *n*ième jour d'un mois pour exécuter une association et le signe (L) indiquant le dernier *X* jour du mois.
**Note**
State Manager ne prend actuellement pas en charge la spécification de mois dans les expressions cron pour les associations.
Pour contrôler davantage l'exécution d'une association, par exemple si vous souhaitez exécuter une association deux jours après le correctif mardi, vous pouvez spécifier un décalage. Un *offset* (décalage) définit le nombre de jours d'attente après le jour prévu pour exécuter une association.
Pour plus d'informations sur la génération d'expressions cron et rate, reportez-vous à [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
+
**Options de ciblage multiple**
Une association spécifie également les cibles de l'association. State Managerprend en charge le ciblage AWS des ressources en utilisant des balises Groupes de ressources AWS IDs, un nœud individuel ou tous les nœuds gérés dans le Région AWS et Compte AWS.
+
**Prise en charge d'Amazon S3**
Stockez les sorties de commandes des exécutions d'association dans le compartiment Amazon S3 de votre choix. Pour de plus amples informations, veuillez consulter [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
+
**EventBridge soutien**
Cet outil Systems Manager est pris en charge à la fois en tant que type d'*événement* et en tant que type de *cible* dans EventBridge les règles Amazon. Pour plus d'informations, consultez [Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md) et [Référence : modèles et types d' EventBridge événements Amazon pour Systems Manager](reference-eventbridge-events.md).
## L'utilisation d'State Manager entraîne-t-elle des frais ?
State Manager est disponible sans frais supplémentaires.
**Topics**
+ [Comment mon organisation peut-elle tirer parti de State Manager ?](#state-manager-benefits)
+ [À qui est destiné State Manager ?](#state-manager-who)
+ [Quelles sont les fonctions d'State Manager ?](#state-manager-features)
+ [L'utilisation d'State Manager entraîne-t-elle des frais ?](#state-manager-cost)
+ [Comprendre le fonctionnement d’State Manager](state-manager-about.md)
+ [Utilisation d'associations dans Systems Manager](state-manager-associations.md)
+ [Création d'associations qui exécutent des fichiers MOF](systems-manager-state-manager-using-mof-file.md)
+ [Création d’associations exécutant des playbooks Ansible](systems-manager-state-manager-ansible.md)
+ [Création d’associations qui exécutent des recettes Chef](systems-manager-state-manager-chef.md)
+ [Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI](state-manager-update-ssm-agent-cli.md)
+ [Guide détaillé : mise à jour automatique des pilotes PV sur les instances EC2 pour Windows Server](state-manager-update-pv-drivers.md)
**Plus d'informations**
+ [Lutter contre la dérive de configuration à l'aide d'Amazon EC2 Systems Manager et PowerShell de Windows DSC](https://aws.amazon.com/blogs/mt/combating-configuration-drift-using-amazon-ec2-systems-manager-and-windows-powershell-dsc/)
+ [Configurer les instances Amazon EC2 dans un groupe Auto Scaling à l'aide de State Manager](https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/)
# Comprendre le fonctionnement d’State Manager
State Manager, un outil de AWS Systems Manager, est un service sécurisé et évolutif qui automatise le processus de maintien des nœuds gérés dans une infrastructure [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) dans un état que vous définissez.
Voici comment State Manager fonctionne :
**1. Déterminez l'état que vous souhaitez appliquer à vos AWS ressources.**
Souhaitez‑vous garantir que vos nœuds gérés sont configurés avec des applications spécifiques, comme des anti‑virus ou des applications anti‑programme malveillant ? Voulez-vous automatiser le processus de mise à jour de l'SSM Agent ou d'autres packages AWS comme `AWSPVDriver` ? Devez-vous vous assurer que des ports spécifiques sont fermés ou ouverts ? Pour commencerState Manager, déterminez l'état que vous souhaitez appliquer à vos AWS ressources. L'état que vous voulez appliquer détermine le document SSM que vous utilisez pour créer une association State Manager.
Une State Manager *association* est une configuration que vous attribuez à vos AWS ressources. La configuration définit le statut que vous souhaitez conserver sur vos ressources. Par exemple, une association peut spécifier qu'un logiciel antivirus doit être installé et s'exécuter sur un nœud géré, ou que certains ports doivent être fermés.
Une association spécifie une planification indiquant quand appliquer la configuration et quelles sont les cibles de l'association. Par exemple, une association pour un logiciel antivirus peut s'exécuter une fois par jour sur tous les nœuds gérés d'un Compte AWS. Si le logiciel n'est pas installé sur un nœud, l'association pourrait demander à State Manager de l'installer. Si le logiciel est installé, mais que le service ne s'exécute pas, l'association pourrait demander à State Manager de démarrer le service.
**2. Déterminez si un document SSM préconfiguré peut vous aider à créer l'état souhaité sur vos AWS ressources.**
Systems Manager inclut des douzaines de documents SSM préconfigurés que vous pouvez utiliser pour créer une association. Les documents préconfigurés sont prêts à effectuer des tâches courantes telles que l'installation d'applications, la configuration d'Amazon CloudWatch, l'exécution d' AWS Systems Manager automatismes, l'exécution de scripts Shell PowerShell et l'association de nœuds gérés à un domaine de service d'annuaire pour Active Directory.
Vous pouvez afficher tous les documents SSM dans la [console Systems Manager](https://console.aws.amazon.com/systems-manager/documents). Sélectionnez le nom d'un document pour en savoir plus sur celui-ci. Voici deux exemples : [https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description](https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description) et [https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description](https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description).
**3. Créer une association.**
Vous pouvez créer une association à l'aide de la console Systems Manager, de l'API AWS Command Line Interface AWS Tools for Windows PowerShell (AWS CLI), (Tools for Windows PowerShell) ou de l'API Systems Manager. Lorsque vous créez une association, vous spécifiez les informations suivantes :
+ Un nom pour l'application.
+ Les paramètres pour le document de commande SSM (par exemple, le chemin d'accès à l'application à installer ou le script à exécuter sur les nœuds).
+ Des cibles pour l'association. Vous pouvez cibler les nœuds gérés en spécifiant des balises, en choisissant un nœud IDs individuel ou en choisissant un groupe dans Groupes de ressources AWS. Vous pouvez également cibler *tous les* nœuds gérés dans les versions actuelles Région AWS et Compte AWS. Si vos cibles incluent plus de 1 000 nœuds, le système utilise un mécanisme de limitation horaire. Cela signifie que vous pourriez constater des inexactitudes dans votre décompte d’agrégation de statuts, étant donné que le processus d’agrégation s’exécute toutes les heures et uniquement lorsque le statut d’exécution d’un nœud change.
+ Rôle utilisé par l'association pour prendre des mesures en votre nom. Le State Manager assumera ce rôle et l'appel requis APIs lors de l'envoi de configurations aux nœuds. Pour plus d'informations sur la configuration du rôle personnalisé, consultez[Configurer les rôles pour `AssociationDispatchAssumeRole`](#setup-assume-role). Si aucun rôle n'est fourni, le [rôle lié au service sera utilisé pour Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/using-service-linked-roles.html).
**Note**
Il est recommandé de définir un rôle IAM personnalisé afin de contrôler totalement les autorisations dont dispose le State Manager lorsqu'il prend des mesures en votre nom.
Le soutien aux rôles lié au service dans State Manager est progressivement supprimé. Les associations qui s'appuient sur un rôle lié à un service peuvent avoir besoin de mises à jour à l'avenir pour continuer à fonctionner correctement.
Pour plus d'informations sur la gestion de l'utilisation des rôles fournis sur mesure, consultez[Gérez l'utilisation AssociationDispatchAssumeRole de `ssm:AssociationDispatchAssumeRole`](#context-key-assume-role).
+ Un programme définissant quand et à quelle fréquence appliquer l'état. Vous pouvez spécifier une expression cron ou de fréquence. Pour plus d'informations sur la création de programmes à l'aide d'expressions cron et de fréquence (rate), consultez [Expressions cron et rate pour les associations](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
**Note**
State Manager ne prend actuellement pas en charge la spécification de mois dans les expressions cron pour les associations.
Lorsque vous exécutez la commande pour créer l'association, Systems Manager lie les informations que vous avez spécifiées (planification, cibles, documents SSM et paramètres) aux ressources ciblées. Le statut de l'association affiche initialement « Pending » (En suspens) pendant que système tente d'atteindre toutes les cibles et d'appliquer *immédiatement* l'état spécifié dans l'association.
Si vous avez créé une nouvelle association qui est prévue pendant qu'une association précédente est encore en cours d'exécution, l'association précédente prend fin et la nouvelle association est exécutée.
Systems Manager signale le statut de la demande de création d'associations sur les ressources. Vous pouvez consulter les détails du statut dans la console ou (pour les nœuds gérés) à l'aide de l'opération [DescribeInstanceAssociationsStatus](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceAssociationsStatus.html)API. Si vous choisissez d'écrire la sortie de la commande dans Amazon Simple Storage Service (Amazon S3) lorsque vous créez une association, vous pouvez également afficher la sortie dans le compartiment Amazon Simple Storage Service (Amazon S3) spécifié.
Pour de plus amples informations, veuillez consulter [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
Les opérations d'API initiées par le document SSM lors d'une exécution d'association ne sont pas journalisées dans AWS CloudTrail.
**4. Surveillez et mettez à jour.**
Une fois que vous avez créé l'association, State Manager réapplique la configuration selon le programme que vous avez défini dans l'association. Vous pouvez afficher le statut de vos associations sur la [page State Manager](https://console.aws.amazon.com/systems-manager/state-manager) dans la console ou en appelant directement l'ID d'association généré par Systems Manager lors de la création de l'association. Pour de plus amples informations, veuillez consulter [Affichage des historiques des associations](state-manager-associations-history.md). Vous pouvez mettre à jour vos documents d'association et les réappliquer si nécessaire. Vous pouvez également créer plusieurs versions d'une association. Pour de plus amples informations, veuillez consulter [Modification et création de la nouvelle version d'une association](state-manager-associations-edit.md).
## Comprendre quand les associations sont appliquées aux ressources
Lorsque vous créez une association, vous spécifiez un document SSM qui définit la configuration, une liste des ressources cibles et un calendrier pour l'application de la configuration. Par défaut, State Manager exécute l'association lorsque vous la créez, puis selon votre calendrier. State Manager tente également d'exécuter l'association dans les situations suivantes :
+ **Modification de l'association** : State Manager exécute l'association après qu'un utilisateur a modifié et enregistré ses modifications dans l'un des champs d'association suivants : `DOCUMENT_VERSION`, `PARAMETERS`, `SCHEDULE_EXPRESSION`, `OUTPUT_S3_LOCATION`.
+ **Modification du document** : State Manager exécute l'association après qu'un utilisateur a modifié et enregistré les modifications apportées au document SSM qui définit l'état de configuration de l'association. Plus précisément, l'association s'exécute une fois que les modifications suivantes ont été apportées au document :
+ Un utilisateur spécifie une nouvelle version de document `$DEFAULT` et l’association a été créée à l’aide de la version `$DEFAULT`.
+ Un utilisateur met à jour un document et l’association a été créée à l’aide de la version `$LATEST`.
+ Un utilisateur supprime le document qui a été spécifié lors de la création de l'association.
+ **Démarrage manuel** : State Manager exécute l'association lorsque l'utilisateur la lance à partir de la console Systems Manager ou par programmation.
+ **Modifications de cible** : State Manager exécute l’association après que l’une des activités suivantes se produit sur un nœud cible :
+ Un nœud géré est mis en ligne pour la première fois.
+ Un nœud est mis en ligne après avoir manqué une exécution d’association planifiée.
+ Un nœud est mis en ligne après avoir été arrêté pendant plus de 30 jours.
**Note**
State Manager ne surveille pas les documents ou les packages utilisés dans les associations à travers les Comptes AWS. Si vous mettez à jour un document ou un package dans un compte, la mise à jour n’entraînera pas l’exécution de l’association dans le second compte. Vous devez exécuter manuellement l’association dans le second compte.
**Empêcher les associations de s’exécuter lorsqu’une cible change**
Dans certains cas, il se peut que vous ne souhaitiez pas qu’une association s’exécute lorsqu’une cible composée de nœuds gérés change, mais uniquement selon le calendrier spécifié.
**Note**
L’exécution d’un dossier d’exploitation Automation entraîne un coût. Si une association avec un dossier d’exploitation Automation cible toutes les instances de votre compte et que vous lancez régulièrement un grand nombre d’instances, le dossier d’exploitation est exécuté sur chacune des instances lors de son lancement. Cela peut entraîner une hausse des frais d’automatisation.
Pour empêcher l’exécution d’une association lorsque les cibles de cette association changent, cochez la case **Appliquer l’association uniquement au prochain intervalle cron spécifié**. Cette case se trouve dans la zone **Spécifier le calendrier** des pages **Créer une association** et **Modifier une association**.
Cette option s’applique aux associations qui intègrent un dossier d’exploitation Automation ou un document SSM.
## À propos des mises à jour de cibles avec les dossiers d’exploitation Automation
Pour que les associations créées avec les dossiers d’exploitation Automation soient appliquées lorsque de nouveaux nœuds cibles sont détectés, les conditions suivantes doivent être remplies :
+ L’association doit avoir été créée par une configuration [Quick Setup](systems-manager-quick-setup.md). Quick Setup est un outil d’ AWS Systems Manager. Les associations créées par d’autres processus ne sont pas prises en charge actuellement.
+ Le dossier d’exploitation Automation doit cibler explicitement le type de ressource `AWS::EC2::Instance` ou `AWS::SSM::ManagedInstance`.
+ L’association doit spécifier les paramètres et les cibles.
Dans la console, les champs **Paramètre** et **Cibles** s’affichent lorsque vous choisissez une exécution de contrôle de débit.
![\[Les options de paramètre et de cible sont présentées dans la console pour les exécutions de contrôle de débit\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/sm_Rate_control_execution_options.png)
Lorsque vous utilisez les actions d’API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html) ou [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html), vous pouvez spécifier ces valeurs à l’aide des entrées `AutomationTargetParameterName` et `Targets`. Dans chacune de ces actions d’API, vous pouvez également empêcher l’association de s’exécuter chaque fois qu’une cible change en définissant le paramètre `ApplyOnlyAtCronInterval` sur `true`.
Pour plus d’informations sur l’utilisation de la console pour contrôler le moment où les associations sont exécutées, notamment des informations sur la manière d’éviter des coûts inattendus lors des exécutions automatisées, consultez [Comprendre quand les associations sont appliquées aux ressources](#state-manager-about-scheduling).
## Configurer les rôles pour `AssociationDispatchAssumeRole`
Pour configurer une distribution personnalisée, assumez des rôles que le State Manager est censé effectuer des actions en votre nom. Les rôles doivent être fiables `ssm.amazonaws.com` et disposer de l'autorisation requise pour appeler `ssm:SendCommand` ou en `ssm:StartAutomationExecution` fonction de cas d'utilisation d'associations.
Exemple de politique de confiance :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Gérez l'utilisation AssociationDispatchAssumeRole de `ssm:AssociationDispatchAssumeRole`
Pour gérer l'utilisation de l'expédition personnalisée, assumez des rôles que le State Manager assume pour effectuer des actions en votre nom, utilisez la clé de `ssm:AssociationDispatchAssumeRole` condition. Cette condition détermine si les associations peuvent être créées ou mises à jour sans spécifier un rôle d'expédition personnalisé.
Dans l'exemple de politique suivant, l'`"Allow"`instruction accorde les autorisations de création et de mise à jour d'associations APIs uniquement lorsque le `AssociationDispatchAssumeRole` paramètre est spécifié. Sans ce paramètre dans les demandes d'API, la politique n'autorise pas la création ou la mise à jour d'associations :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateAssociation",
"ssm:UpdateAssociation",
"ssm:CreateAssociationBatch"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:AssociationDispatchAssumeRole": "*"
}
}
}
]
}
```
# Utilisation d'associations dans Systems Manager
Cette section décrit comment créer et gérer des associations State Manager en utilisant la console AWS Systems Manager, l'AWS Command Line Interface (AWS CLI), et Outils AWS pour PowerShell.
**Topics**
+ [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md)
+ [Création d'associations](state-manager-associations-creating.md)
+ [Modification et création de la nouvelle version d'une association](state-manager-associations-edit.md)
+ [Suppression d'associations](systems-manager-state-manager-delete-association.md)
+ [Exécution de groupes Auto Scaling avec des associations](systems-manager-state-manager-asg.md)
+ [Affichage des historiques des associations](state-manager-associations-history.md)
+ [Utilisation d'associations avec IAM](systems-manager-state-manager-iam.md)
# Comprendre les cibles et les contrôles du taux dans les associations State Manager
Cette section décrit les fonctionnalités State Manager qui vous aident à déployer une association sur des dizaines ou des centaines de nœuds, tout en contrôlant le nombre de nœuds qui exécutent l’association à l’heure prévue. State Manager est un outil d’ AWS Systems Manager.
## À l’aide de cibles
Lorsque vous créez une association State Manager, vous sélectionnez les nœuds à configurer avec cette association dans la section **Targets** (Cibles) de la console Systems Manager, comme illustré ici.
![\[Différentes options de ciblage des nœuds lors de la création d'une association State Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-targets.png)
Si vous créez une association à l'aide d'un outil de ligne de commande tel que l' AWS Command Line Interface (AWS CLI), vous spécifiez le paramètre `targets`. Le ciblage des nœuds vous permet de configurer des dizaines, des centaines ou des milliers de nœuds avec une association sans avoir à spécifier ou à choisir un nœud individuel IDs.
Chaque nœud géré peut être ciblé par un maximum de 20 associations.
La fonctionnalité State Manager inclut les options cibles suivantes lors de la création d'une association.
**Spécifier des identifications**
Utilisez cette option pour spécifier une clé d'identification et (éventuellement) une valeur d'identification affectée à vos nœuds. Lorsque vous exécutez la demande, le système recherche et tente de créer l'association sur tous les nœuds qui correspondent à la clé et à la valeur d'identification spécifiées. Si vous avez spécifié plusieurs valeurs d'identification, l'association cible tous les nœuds contenant au moins une de ces valeurs d'identification. Lorsque le système crée l'association, il l'exécute. Après cette première exécution, le système exécute l'association selon la planification que vous avez spécifiée.
Si vous créez des nœuds et affectez la clé d'identification et la valeur spécifiées à ces derniers, le système applique automatiquement l'association, l'exécute immédiatement, puis l'exécute conformément à la planification. Cela s'applique lorsque l'association utilise un document Command ou Policy, mais pas lorsque l'association utilise un runbook Automation. Si vous supprimez les identifications spécifiées d'un nœud, le système n'exécute plus l'association sur ces nœuds.
**Note**
Si vous utilisez des runbooks d'automatisation State Manager et que la limitation du balisage vous empêche d'atteindre un objectif spécifique, envisagez d'utiliser des runbooks d'automatisation avec Amazon. EventBridge Pour de plus amples informations, veuillez consulter [Exécutez des automatisations en fonction des événements EventBridge](running-automations-event-bridge.md). Pour plus d'informations sur l'utilisation de runbooks avec State Manager reportez-vous à [Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
Il est recommandé d'utiliser des balises lors de la création d'associations qui utilisent un document de commande ou de politique. Nous vous recommandons également d'utiliser des balises lors de la création d'associations pour exécuter des groupes Auto Scaling. Pour de plus amples informations, veuillez consulter [Exécution de groupes Auto Scaling avec des associations](systems-manager-state-manager-asg.md).
**Note**
Notez les informations suivantes.
Lorsque vous créez une association dans le AWS Management Console qui cible des nœuds à l'aide de balises, vous ne pouvez spécifier qu'une seule clé de balise pour une association d'automatisation et cinq clés de balise pour une association de commande. *Toutes* les clés de balise spécifiées dans l’association doivent être actuellement attribuées au nœud. Si elles ne le sont pas, State Manager ne parvient pas à cibler le nœud pour une association.
Si vous souhaitez utiliser la console *et* cibler vos nœuds en utilisant plusieurs clés de balise pour une association d'automatisation et cinq clés de balise pour une association de commandes, attribuez les clés de balise à un Groupes de ressources AWS groupe et ajoutez-y les nœuds. Vous pouvez ensuite choisir l'option **Groupe de ressources** dans la liste des **cibles** lorsque vous créez l'association State Manager.
Vous pouvez spécifier un maximum de cinq clés de balise en utilisant la AWS CLI. Si vous utilisez le AWS CLI, *toutes les* clés de balise spécifiées dans la `create-association` commande doivent être actuellement attribuées au nœud. Si elles ne le sont pas, State Manager ne parvient pas à cibler le nœud pour une association.
**Choix manuel des nœuds**
Utilisez cette option pour sélectionner manuellement les nœuds dans lesquelles vous souhaitez créer l'association. Le volet **Instances** affiche tous les nœuds gérés par Systems Manager dans les versions actuelles Compte AWS et Région AWS. Vous pouvez sélectionner manuellement autant de nœuds que vous le souhaitez. Lorsque le système crée l'association, il l'exécute. Après cette première exécution, le système exécute l'association selon la planification que vous avez spécifiée.
**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.
**Pour choisir un groupe de ressources**
Utilisez cette option pour créer une association sur tous les nœuds renvoyés par une requête Groupes de ressources AWS basée sur des balises ou des AWS CloudFormation piles.
Vous trouverez ci-dessous des informations détaillées sur le ciblage des groupes de ressources pour une association.
+ Si vous ajoutez de nouveaux nœuds à un groupe, le système mappe automatiquement les nœuds à l'association qui cible le groupe de ressources. Le système applique l'association aux nœuds lorsqu'il détecte la modification. Après cette première exécution, le système exécute l'association selon la planification que vous avez spécifiée.
+ Si vous créez une association qui cible un groupe de ressources et que le type de `AWS::SSM::ManagedInstance` ressource a été spécifié pour ce groupe, l'association est conçue pour fonctionner à la fois sur des instances Amazon Elastic Compute Cloud (Amazon EC2) et sur des EC2 non-nœuds dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types).
L’inverse est également vrai. Si vous créez une association qui cible un groupe de ressources et que le type de `AWS::EC2::Instance` ressource a été spécifié pour ce groupe, l'association est conçue pour fonctionner à la fois sur des EC2 non-nœuds dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) et sur des instances (Amazon EC2).
+ Si vous créez une association qui cible un groupe de ressources, ce groupe ne doit pas disposer de plus de cinq clés de balises affectées à celui-ci ou plus de cinq valeurs spécifiées pour une clé de balises. Si l'une de ces conditions s'applique aux balises et aux clés attribuées à votre groupe de ressources, l'association ne s'exécutera pas et renverra une erreur `InvalidTarget`.
+ Si vous créez une association qui cible un groupe de ressources à l’aide de balises, vous ne pouvez pas choisir l’option **(valeur vide)** pour la valeur de balise.
+ Si vous supprimez un groupe de ressources, toutes les instances de ce groupe n'exécutent plus l'association. Il est recommandé de supprimer les associations ciblant le groupe.
+ Vous ne pouvez cibler qu'un seul groupe de ressources pour une association. Les groupes multiples ou imbriqués ne sont pas pris en charge.
+ Après avoir créé une association, State Manager met à jour périodiquement l'association avec des informations sur les ressources du groupe de ressources. Si vous ajoutez de nouvelles ressources à un groupe de ressources, la planification du moment où le système applique l'association aux nouvelles ressources dépend de plusieurs facteurs. Vous pouvez déterminer le statut de l'association sur la page State Manager de la console Systems Manager.
**Avertissement**
Un utilisateur, un groupe ou un rôle Gestion des identités et des accès AWS (IAM) autorisé à créer une association qui cible un groupe de ressources d' EC2 instances Amazon contrôle automatiquement au niveau racine toutes les instances du groupe. Seuls les administrateurs approuvés doivent être autorisés à créer des associations.
Pour de plus amples informations sur Resource Groups, consultez [Qu'est-ce que Groupes de ressources AWS ?](https://docs.aws.amazon.com/ARG/latest/userguide/) dans le *Guide de l'utilisateur Groupes de ressources AWS *.
**Choisir tous les nœuds**
Utilisez cette option pour cibler tous les nœuds du Compte AWS et actuel Région AWS. Lorsque vous exécutez la demande, le système localise et tente de créer l'association sur tous les nœuds du Compte AWS et Région AWS actuel. Lorsque le système crée l'association, il l'exécute. Après cette première exécution, le système exécute l'association selon la planification que vous avez spécifiée. Si vous créez des nœuds, le système applique automatiquement l'association, l'exécute immédiatement, puis l'exécute conformément à la planification.
## Utilisation des contrôles de taux
Vous pouvez contrôler l'exécution d'une association sur vos nœuds en spécifiant une valeur de simultanéité et un seuil d'erreur. La valeur de simultanéité spécifie le nombre de nœuds autorisés à exécuter l'association simultanément. Un seuil d'erreur spécifie le nombre d'exécutions d'associations qui peuvent échouer avant que Systems Manager n'envoie une commande à chaque nœud configuré avec cette association pour qu'il cesse de l'exécuter. La commande arrête l'exécution de l'association jusqu'à la prochaine exécution planifiée. Les fonctions de simultanéité et de seuil d'erreurs sont appelées collectivement *contrôles du débit*.
![\[Différentes options de contrôle du débit lors de la création d'une association State Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-rate-controls.png)
**Concurrency**
La simultanéité permet de limiter l'impact sur vos nœuds en vous permettant de spécifier que seul un certain nombre de nœuds peuvent traiter une association à la fois. Vous pouvez spécifier soit un nombre absolu de nœuds, par exemple 20, soit un pourcentage de l'ensemble cible de nœuds, par exemple 10 %.
La simultanéité State Manager comporte les restrictions et limitations suivantes :
+ Si vous choisissez de créer une association à l'aide de cibles, mais que vous ne spécifiez pas de valeur de simultanéité, State Manager applique automatiquement une simultanéité maximale de 50 nœuds.
+ Si de nouveaux nœuds correspondant aux critères cibles sont mis en ligne pendant qu'une association utilisant la simultanéité s'exécute, les nouveaux nœuds exécutent l'association si la valeur de simultanéité n'est pas dépassée. Si la valeur de la concurrence est dépassée, les nœuds sont ignorés pendant l'intervalle d'exécution de l'association en cours. Les nœuds exécutent l'association lors du prochain intervalle programmé tout en se conformant aux exigences de simultanéité.
+ Si vous mettez à jour une association qui utilise la simultanéité, et qu'un ou plusieurs nœuds traitent cette association lorsque celle-ci est mise à jour, tout nœud qui exécute l'association sera autorisé à se terminer. Les associations qui n'ont pas commencé sont abandonnées. Une fois que les associations en cours d'exécution sont terminées, tous les nœuds cibles ré-exécutent immédiatement l'association, car celle-ci a été mise à jour. Lorsque l'association s'exécute à nouveau, la valeur de simultanéité est appliquée.
**Seuils d'erreurs**
Un seuil d'erreur spécifie le nombre d'exécutions d'associations qui peuvent échouer avant que Systems Manager n'envoie une commande à chaque nœuds configuré avec cette association. La commande arrête l'exécution de l'association jusqu'à la prochaine exécution planifiée. Vous pouvez spécifier un nombre absolu d'erreurs, par exemple 10, ou un pourcentage de l'ensemble de la cible, par exemple 10 %.
Par exemple, si vous spécifiez un nombre absolu de trois erreurs, State Manager envoie la commande d'arrêt lorsque la quatrième erreur est renvoyée. Si vous spécifiez 0, State Manager envoie la commande d'arrêt dès que le premier résultat d'erreur est renvoyé.
Si vous spécifiez un seuil d'erreurs de 10 % pour 50 associations, State Manager envoie la commande d'arrêt lorsque la sixième erreur est renvoyée. Les associations qui s'exécutent déjà quand un seuil d'erreurs est atteint sont autorisées à se terminer, mais certaines de ces associations peuvent échouer. Pour vous assurer qu'il n'y pas plus d'erreurs que le nombre spécifié pour le seuil d'erreurs, définissez la valeur de **Concurrency (Simultanéité)** sur 1 afin que les associations s'exécutent une par une.
Les seuils d'erreurs State Manager comportent les limites et restrictions suivantes :
+ Les seuils d'erreurs sont appliqués pour l'intervalle actuel.
+ Des informations sur chaque erreur, y compris des détails au niveau des étapes, sont enregistrées dans l'historique d'association.
+ Si vous choisissez de créer une association à l'aide de cibles, mais que vous ne spécifiez pas de seuil d'erreurs, State Manager applique automatiquement un seuil de 100 échecs.
# Création d'associations
State Manager, un outil dans AWS Systems Manager, vous aide à maintenir vos AWS ressources dans un état défini et à réduire la dérive de configuration. Pour ce faire, State Manager utilise des associations. Une *association* est une configuration que vous affectez à vos ressources AWS . La configuration définit le statut que vous souhaitez conserver sur vos ressources. Par exemple, une association peut spécifier qu'un logiciel antivirus doit être installé et s'exécuter sur un nœud géré, ou que certains ports doivent être fermés.
Une association spécifie une planification indiquant quand appliquer la configuration et quelles sont les cibles de l'association. Par exemple, une association pour un logiciel antivirus peut s'exécuter une fois par jour sur tous les nœuds gérés d'un Compte AWS. Si le logiciel n'est pas installé sur un nœud, l'association pourrait demander à State Manager de l'installer. Si le logiciel est installé, mais que le service ne s'exécute pas, l'association pourrait demander à State Manager de démarrer le service.
**Avertissement**
Lorsque vous créez une association, vous pouvez choisir un groupe de AWS ressources de nœuds gérés comme cible pour l'association. Si un utilisateur, un groupe ou un rôle Gestion des identités et des accès AWS (IAM) est autorisé à créer une association qui cible un groupe de ressources de nœuds gérés, cet utilisateur, ce groupe ou ce rôle contrôle automatiquement au niveau racine tous les nœuds du groupe. Seuls les administrateurs approuvés doivent être autorisés à créer des associations.
**Objectifs des associations et contrôles du débit**
Une association spécifie également quels nœuds gérés, ou cibles, doivent recevoir l'association. State Manager inclut plusieurs fonctions pour vous aider à cibler vos nœuds gérés et à contrôler la façon dont l'association est déployée sur ces cibles. Pour de plus amples informations sur les cibles et les contrôles du 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).
**Balisage d’associations**
Vous pouvez attribuer des balises à une association lorsque vous la créez à l'aide d'un outil de ligne de commande tel que le AWS CLI ou Outils AWS pour PowerShell. L'ajout de balises à une association à l'aide de la console Systems Manager n'est pas pris en charge.
**Exécuter les associations**
Par défaut, State Manager exécute une association immédiatement après sa création, puis selon le calendrier que vous avez défini.
Le système exécute également les associations selon les règles suivantes :
+ State Manager tente d'exécuter l'association sur tous les nœuds spécifiés ou ciblés au cours d'un intervalle.
+ Si une association n'est pas exécutée au cours d'un intervalle (par exemple, parce qu'une valeur de simultanéité a limité par le nombre de nœuds pouvant traiter l'association simultanément), State Manager tente d'exécuter l'association lors du prochain intervalle.
+ State Manager exécute l'association après avoir modifié la configuration, les nœuds cibles, les documents ou les paramètres de l'association. Pour de plus amples informations, consultez [Comprendre quand les associations sont appliquées aux ressources](state-manager-about.md#state-manager-about-scheduling).
+ State Manager enregistre un historique pour tous les intervalles ignorés. Vous pouvez consulter l'historique dans l'onglet **Execution History (Historique d'exécution)**.
## Planifier les associations
Vous pouvez planifier des associations pour qu'elles s'exécutent à des intervalles de base, par exemple *toutes les 10 heures*, ou vous pouvez créer des planifications plus avancées à l'aide d'expressions cron et rate personnalisées. Vous pouvez également empêcher les associations de s'exécuter lorsque vous les créez pour la première fois.
**Utiliser les expressions cron et rate pour planifier les exécutions des associations**
Outre les expressions cron ou rate standard, State Manager prend également en charge les expressions cron qui incluent un jour de la semaine et le signe numérique (\$1) pour désigner le *n*e jour d'un mois pour exécuter une association. Voici un exemple qui exécute une planification cron le troisième mardi de chaque mois à 23 h 30 UTC :
`cron(30 23 ? * TUE#3 *)`
Voici un exemple qui se déroule le deuxième jeudi de chaque mois à minuit UTC :
`cron(0 0 ? * THU#2 *)`
State Manager prend également en charge le signe (L) pour indiquer le dernier *X* jour du mois. Voici un exemple qui exécute une planification cron le dernier mardi de chaque mois à 23 h 30 UTC :
`cron(0 0 ? * 3L *)`
Pour contrôler davantage l'exécution d'une association, par exemple si vous souhaitez exécuter une association deux jours après le correctif mardi, vous pouvez spécifier un décalage. Un *offset* (décalage) définit le nombre de jours d'attente après le jour prévu pour exécuter une association. Par exemple, si vous avez spécifié une planification cron de `cron(0 0 ? * THU#2 *)`, vous pouvez spécifier le numéro 3 dans le champ **Schedule offset** (Décalage de planification) pour exécuter l'association tous les dimanches après le deuxième jeudi du mois.
**Note**
Pour utiliser des décalages, vous devez sélectionner **Appliquer l'association uniquement à l'intervalle Cron spécifié suivant** dans la console ou vous devez spécifier le paramètre `ApplyOnlyAtCronInterval` dans la ligne de commande. Lorsque l'une de ces options est activée, State Manager n'exécute pas d'association immédiatement après sa création.
Pour plus d'informations sur les expressions de type cron et rate, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
## Créer une association (console)
La procédure suivante décrit comment utiliser la console Systems Manager pour créer une association State Manager.
**Note**
Notez les informations suivantes.
Cette procédure décrit comment créer une association qui utilise une `Command` ou un document `Policy` pour cibler les nœuds gérés. Pour plus d'informations sur la création d'une association qui utilise un runbook Automation vers des nœuds cibles ou d'autres types de ressources AWS , consultez [Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
Lorsque vous créez une association, vous pouvez spécifier un maximum de cinq clés de balise en utilisant la AWS Management Console. *Toutes* les clés de balise spécifiées pour l’association doivent être actuellement attribuées au nœud. Si elles ne le sont pas, State Manager ne parvient pas à cibler le nœud pour l’association.
**Pour créer une association State 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 **State Manager**.
1. Sélectionnez **Créer une association**.
1. Dans le champ **Nom**, spécifiez un nom.
1. Dans la liste **Document**, sélectionnez l'option en regard du nom d'un document. Notez le type de document. Cette procédure s'applique aux documents `Policy` et `Command`. Pour plus d'informations sur la création d'une association qui utilise un runbook Automation, consultez [Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
**Important**
State Manager ne prend pas en charge l'exécution d'associations utilisant une nouvelle version d'un document si ce document est partagé à partir d'un autre compte. State Manager exécute toujours la version `default` d'un document s'il est partagé depuis un autre compte, même si la console Systems Manager indique qu'une nouvelle version a été traitée. Si vous souhaitez exécuter une association à l’aide d’une nouvelle version d’un document partagé à partir d’un autre compte, vous devez définir la version du document sur `default`.
1. Pour **Parameters (Paramètres)**, spécifiez les paramètres d'entrée requis.
1. (Facultatif) Pour **Association Dispatch Assume** Role, sélectionnez un rôle dans le menu déroulant. Le State Manager prendra des mesures en utilisant ce rôle en votre nom. Pour plus d'informations sur la configuration du rôle personnalisé, voir [Configurer les rôles pour `AssociationDispatchAssumeRole`](state-manager-about.md#setup-assume-role)
**Note**
Il est recommandé de définir un rôle IAM personnalisé afin de contrôler totalement les autorisations dont dispose le State Manager lorsqu'il prend des mesures en votre nom.
Le soutien aux rôles lié au service dans State Manager est progressivement supprimé. Les associations qui s'appuient sur un rôle lié à un service peuvent avoir besoin de mises à jour à l'avenir pour continuer à fonctionner correctement.
Pour plus d'informations sur la gestion de l'utilisation des rôles fournis sur mesure, consultez[Gérez l'utilisation AssociationDispatchAssumeRole de `ssm:AssociationDispatchAssumeRole`](state-manager-about.md#context-key-assume-role).
1. (Facultatif) Choisissez une CloudWatch alarme à appliquer à votre association à des fins de surveillance.
**Note**
Notez les informations suivantes concernant ce passage.
La liste des alarmes affiche 100 alarmes maximum. Si votre alarme ne figure pas dans la liste, utilisez le AWS Command Line Interface pour créer l'association. Pour de plus amples informations, veuillez consulter [Créer une association (ligne de commande)](#create-state-manager-association-commandline).
Pour associer une CloudWatch alarme à votre commande, le principal IAM qui crée l'association doit être autorisé à effectuer l'`iam:createServiceLinkedRole`action. Pour plus d'informations sur les CloudWatch alarmes, consultez la section [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Si votre alarme se déclenche, toute invocation ou automatisme de commande en attente ne s’exécute pas.
1. Pour **Targets (Cibles)**, sélectionnez une option. Pour plus d'informations sur l'utilisation des cibles, consultez [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
**Note**
Pour que les associations créées avec les dossiers d’exploitation Automation soient appliquées lorsque de nouveaux nœuds cibles sont détectés, certaines conditions doivent être remplies. Pour plus d'informations, consultez [À propos des mises à jour de cibles avec les dossiers d’exploitation Automation](state-manager-about.md#runbook-target-updates).
1. Dans la section **Specify schedule (Spécifier le programme)**, sélectionnez **On Schedule (Selon le calendrier)** ou **No schedule (Pas de calendrier)**. Si vous sélectionnez **On Schedule (Selon planification)**, utilisez les boutons fournis pour créer une planification de type cron ou rate pour l'association.
Si vous ne souhaitez pas que l'association s'exécute immédiatement après sa création, sélectionnez **Appliquer l'association uniquement à l'intervalle Cron spécifié suivant**.
1. (Facultatif) Dans le **Schedule offset** (Décalage de planification), spécifiez un nombre compris entre 1 et 6.
1. Dans la section **Options avancées** utilisez **Compliance severity (Sévérité de la conformité)** pour choisir un niveau de sévérité pour l'association, et utilisez **Change Calendriers (Calendriers de modifications)** pour choisir un calendrier des modifications pour l'association.
Les rapports de conformité indiquent si l'état de l'association est conforme ou non conforme, ainsi que le niveau de sévérité que vous spécifiez ici. Pour de plus amples informations, veuillez consulter [A propos de la conformité des associations State Manager](compliance-about.md#compliance-about-association).
Le calendrier des modifications détermine l'instant d'exécution de l'association. Si le calendrier est fermé, l'association n'est pas appliquée. Si le calendrier est ouvert, l'association s'exécute en conséquence. Pour de plus amples informations, veuillez consulter [AWS Systems Manager Change Calendar](systems-manager-change-calendar.md).
1. Dans la section **Rate control** (Contrôle du rythme), sélectionnez les options permettant de contrôler la façon dont l'association s'exécute sur plusieurs nœuds gérés. 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).
Dans la section **Simultanéité**, sélectionnez une option :
+ Sélectionnez **targets (cibles)** pour entrer un nombre absolu de cibles pouvant exécuter l'association simultanément.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage de l'ensemble de cibles pouvant exécuter l'association simultanément.
Dans la section **Error threshold (Seuil d'erreurs)**, sélectionnez une option :
+ Sélectionnez **errors (erreurs)** pour saisir un nombre absolu d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
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.
Voici les autorisations minimales requises pour activer la sortie Amazon S3 pour une association. Vous pouvez restreindre davantage l'accès en attachant des politiques IAM à des utilisateurs ou à des rôles au sein d'un compte. Au minimum, un profil d'instance Amazon EC2 doit disposer d'un rôle IAM avec la politique gérée `AmazonSSMManagedInstanceCore` et la politique en ligne suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
Pour des autorisations minimales, le compartiment Amazon S3 vers lequel s'effectue l'exportation doit disposer des paramètres par défaut définis par la console Amazon S3. Pour plus d'informations sur la création de compartiments Amazon S3, consultez [Création d'un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans le *Guide de l'utilisateur Amazon S3*.
**Note**
Les opérations d'API initiées par le document SSM lors d'une exécution d'association ne sont pas journalisées dans AWS CloudTrail.
1. Sélectionnez **Create Association (Créer une association)**.
**Note**
Si vous supprimez l'association que vous avez créée, celle-ci ne s'exécute plus sur aucune cible de cette association.
## Créer une association (ligne de commande)
La procédure suivante décrit comment utiliser AWS CLI (sous Linux ouWindows Server) ou les outils PowerShell pour créer une State Manager association. Cette section présente plusieurs exemples qui montrent comment utiliser les cibles et les contrôles du débit. Les cibles et les contrôles du rythme vous permettent d'affecter une association à des dizaines ou des centaines de nœuds, tout en contrôlant l'exécution de ces associations. Pour de plus amples informations sur les cibles et les contrôles du 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).
**Important**
Cette procédure décrit comment créer une association qui utilise une `Command` ou un document `Policy` pour cibler les nœuds gérés. Pour plus d'informations sur la création d'une association utilisant un runbook d'automatisation pour cibler des nœuds ou d'autres types de AWS ressources, consultez[Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
**Avant de commencer**
Le paramètre `targets` est un tableau de critères de recherche qui cible les instances en utilisant une combinaison `Key`,`Value` (Clé-Valeur) que vous spécifiez. Si vous prévoyez de créer une association sur des dizaines ou des centaines de nœuds à l'aide du paramètre `targets`, passez en revue les options de ciblage suivantes avant de commencer la procédure.
Ciblez des nœuds spécifiques en spécifiant IDs
```
--targets Key=InstanceIds,Values=instance-id-1,instance-id-2,instance-id-3
```
```
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE,i-07782c72faEXAMPLE
```
Cibler les instances à l'aide de balises
```
--targets Key=tag:tag-key,Values=tag-value-1,tag-value-2,tag-value-3
```
```
--targets Key=tag:Environment,Values=Development,Test,Pre-production
```
Ciblez des nœuds en utilisant Groupes de ressources AWS
```
--targets Key=resource-groups:Name,Values=resource-group-name
```
```
--targets Key=resource-groups:Name,Values=WindowsInstancesGroup
```
Ciblez toutes les instances actuelles Compte AWS et Région AWS
```
--targets Key=InstanceIds,Values=*
```
**Note**
Notez les informations suivantes.
State Manager ne prend pas en charge l'exécution d'associations utilisant une nouvelle version d'un document si ce document est partagé à partir d'un autre compte. State Manager exécute toujours la version `default` d'un document s'il est partagé depuis un autre compte, même si la console Systems Manager indique qu'une nouvelle version a été traitée. Si vous souhaitez exécuter une association à l'aide d'une nouvelle version d'un document partagé à partir d'un autre compte, vous devez définir la version du document sur `default`.
State Managerne prend pas en charge les `TargetLocationAlarmConfiguration` paramètres `IncludeChildOrganizationUnits` `ExcludeAccounts` `TargetsMaxErrors``TargetsMaxConcurrency`,`Targets`,,, pour [TargetLocation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TargetLocation.html).
Vous pouvez spécifier un maximum de cinq clés de balise en utilisant la AWS CLI. Si vous utilisez le AWS CLI, *toutes les* clés de balise spécifiées dans la `create-association` commande doivent être actuellement attribuées au nœud. Si elles ne le sont pas, State Manager ne parvient pas à cibler le nœud pour une association.
Lorsque vous créez une association, vous spécifiez à quel moment le programme s'exécute. Spécifiez le programme à l'aide d'une expression de type cron ou rate. Pour plus d'informations sur les expressions de type cron et rate, consultez [Expressions cron et rate pour les associations](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
Pour que les associations créées avec les dossiers d’exploitation Automation soient appliquées lorsque de nouveaux nœuds cibles sont détectés, certaines conditions doivent être remplies. Pour plus d'informations, consultez [À propos des mises à jour de cibles avec les dossiers d’exploitation Automation](state-manager-about.md#runbook-target-updates).
**Créer une association**
1. Installez et configurez le AWS CLI ou le Outils AWS pour PowerShell, si ce n'est pas déjà fait.
Pour plus d'informations, consultez la section [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) et [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Utilisez le format suivant pour créer une commande qui crée une association State Manager. Remplacez chaque *example resource placeholder* par vos propres informations.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--apply-only-at-cron-interval required_parameter_for_schedule_offsets \
--schedule-offset number_between_1_and_6 \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account \
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--apply-only-at-cron-interval required_parameter_for_schedule_offsets ^
--schedule-offset number_between_1_and_6 ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account ^
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ApplyOnlyAtCronInterval required_parameter_for_schedule_offsets `
-ScheduleOffSet number_between_1_and_6 `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account `
-Tags "Key=tag_key,Value=tag_value"
```
------
L'exemple suivant crée une association sur des nœuds labélisés avec `"Environment,Linux"`. L'association utilise le document `AWS-UpdateSSMAgent` pour mettre à jour SSM Agent sur les nœuds ciblés à 2 h (UTC) chaque dimanche matin. Cette association s'exécute simultanément sur 10 nœuds maximum à un moment donné. En outre, cette association cesse d'être exécutée sur des nœuds supplémentaires pour un intervalle d'exécution particulier si le nombre d'erreurs dépasse 5. Pour les rapports de conformité, cette association se voit attribuer un niveau de sévérité Medium (Moyenne).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=tag:Environment,Values=Linux \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=tag:Environment,Values=Linux ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:Environment"
"Values"="Linux"
} `
-ComplianceSeverity MEDIUM `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5
```
------
L'exemple suivant cible le nœud IDs en spécifiant une valeur générique (\$1). Cela permet à Systems Manager de créer une association sur *tous les* nœuds de l'actuel Compte AWS et Région AWS. Cette association s'exécute simultanément sur 10 nœuds maximum à un moment donné. En outre, cette association cesse d'être exécutée sur des nœuds supplémentaires pour un intervalle d'exécution particulier si le nombre d'erreurs dépasse 5. Pour les rapports de conformité, cette association se voit attribuer un niveau de sévérité Medium (Moyenne). Cette association utilise un décalage de planification, ce qui signifie qu'elle s'exécute deux jours après la planification cron spécifiée. Elle inclut également le paramètre `ApplyOnlyAtCronInterval`, qui est requis pour utiliser le décalage de planification, ce qui signifie que l'association ne sera pas exécutée immédiatement après sa création.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--name "AWS-UpdateSSMAgent" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--targets "Key=instanceids,Values=*" \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN#2 *)" \
--apply-only-at-cron-interval \
--schedule-offset 2 \
--max-errors "5" \
--max-concurrency "10" \
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--name "AWS-UpdateSSMAgent" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--targets "Key=instanceids,Values=*" ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN#2 *)" ^
--apply-only-at-cron-interval ^
--schedule-offset 2 ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_All `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="InstanceIds"
"Values"="*"
} `
-ScheduleExpression "cron(0 2 ? * SUN#2 *)" `
-ApplyOnlyAtCronInterval `
-ScheduleOffset 2 `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
L'exemple suivant crée une association sur des nœuds dans des groupes de ressources. Le groupe est nommé « HR-Department ». L'association utilise le document `AWS-UpdateSSMAgent` pour mettre à jour SSM Agent sur les nœuds ciblés à 2 h (UTC) chaque dimanche matin. Cette association s'exécute simultanément sur 10 nœuds maximum à un moment donné. En outre, cette association cesse d'être exécutée sur des nœuds supplémentaires pour un intervalle d'exécution particulier si le nombre d'erreurs dépasse 5. Pour les rapports de conformité, cette association se voit attribuer un niveau de sévérité Medium (Moyenne). Cette association s'exécute selon la planification Cron spécifiée. Il ne s'exécute pas immédiatement après la création de l'association.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=resource-groups:Name,Values=HR-Department \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10" \
--apply-only-at-cron-interval
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=resource-groups:Name,Values=HR-Department ^
--name AWS-UpdateSSMAgent ^
-association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="resource-groups:Name"
"Values"="HR-Department"
} `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
L'exemple suivant crée une association qui s'exécute sur des nœuds balisés avec un ID de nœud spécifique. L'association utilise le document SSM Agent pour mettre à jour l'SSM Agent sur les nœuds ciblés une fois, lorsque le calendrier des modifications est ouvert. L'association vérifie l'état du calendrier lorsqu'elle s'exécute. Si le calendrier est fermé au moment du lancement et que l'association ne s'exécute qu'une seule fois, elle ne s'exécutera plus car la fenêtre d'exécution de l'association est passée. Si le calendrier est ouvert, l'association s'exécute en conséquence.
**Note**
Si vous ajoutez de nouveaux nœuds aux identifications ou aux groupes de ressources sur lesquels une association agit lorsque le calendrier des modifications est fermé, l'association est appliquée à ces nœuds une fois que le calendrier des modifications s'ouvre.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name CalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" \
--schedule-expression "rate(1day)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name CalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" ^
--schedule-expression "rate(1day)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName CalendarAssociation `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" `
-ScheduleExpression "rate(1day)"
```
------
L'exemple suivant crée une association qui s'exécute sur des nœuds balisés avec un ID de nœud spécifique. L'association utilise le document SSM Agent pour mettre à jour SSM Agent sur les nœuds ciblés à 2 h chaque dimanche matin. Cette association s'exécute uniquement selon la planification cron spécifiée lorsque le calendrier des modifications est ouvert. Lorsque l'association est créée, elle vérifie l'état du calendrier. Si le calendrier est fermé, l'association n'est pas appliquée. Lorsque l'intervalle d'application de l'association commence à 2h00 le dimanche, l'association vérifie si le calendrier est ouvert. Si le calendrier est ouvert, l'association s'exécute en conséquence.
**Note**
Si vous ajoutez de nouveaux nœuds aux identifications ou aux groupes de ressources sur lesquels une association agit lorsque le calendrier des modifications est fermé, l'association est appliquée à ces nœuds une fois que le calendrier des modifications s'ouvre.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name MultiCalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name MultiCalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName MultiCalendarAssociation `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" `
-ScheduleExpression "cron(0 2 ? * SUN *)"
```
------
**Note**
Si vous supprimez l'association que vous avez créée, celle-ci ne s'exécute plus sur aucune cible de cette association. En outre, si vous avez spécifié le paramètre `apply-only-at-cron-interval`, vous pouvez réinitialiser cette option. Pour ce faire, spécifiez le paramètre `no-apply-only-at-cron-interval` lorsque vous mettez à jour l'association à partir de la ligne de commande. Ce paramètre force l'association à s'exécuter immédiatement après la mise à jour de l'association et selon l'intervalle spécifié.
# Modification et création de la nouvelle version d'une association
Vous pouvez modifier une association State Manager pour spécifier un nouveau nom, un programme, un niveau de sévérité, des cibles ou d’autres valeurs. Pour les associations basées sur des documents de type SSM Command, vous pouvez également choisir d’écrire la sortie de la commande dans un compartiment Amazon Simple Storage Service (Amazon S3). Après avoir modifié une association, State Manager crée une nouvelle version. Vous pouvez afficher différentes versions après modification, comme décrit dans les procédures suivantes.
**Note**
Pour que les associations créées avec les dossiers d’exploitation Automation soient appliquées lorsque de nouveaux nœuds cibles sont détectés, certaines conditions doivent être remplies. Pour plus d'informations, consultez [À propos des mises à jour de cibles avec les dossiers d’exploitation Automation](state-manager-about.md#runbook-target-updates).
Les procédures suivantes décrivent comment modifier et créer une nouvelle version d'une association à l'aide de la console Systems Manager, AWS Command Line Interface (AWS CLI) et Outils AWS pour PowerShell (Tools for PowerShell).
**Important**
State Manager ne prend pas en charge l'exécution d'associations utilisant une nouvelle version d'un document si ce document est partagé à partir d'un autre compte. State Manager exécute toujours la version `default` d'un document s'il est partagé à partir d'un autre compte, même si la console Systems Manager indique qu'une nouvelle version a été traitée. Si vous souhaitez exécuter une association à l'aide d'une nouvelle version d'un document partagé à partir d'un autre compte, vous devez définir la version du document sur `default`.
## Modifier une association (console)
La procédure suivante décrit comment utiliser la console Systems Manager pour modifier et créer une nouvelle version d'une association.
**Note**
Pour les associations qui utilisent des documents SSM Command et non des dossiers d’exploitation Automation, cette procédure requiert que vous disposiez d’un accès en écriture à un compartiment Amazon S3 existant. Si vous n'avez encore jamais utilisé d'Amazon S3, sachez que des frais s'appliquer à son utilisation. Pour plus d'informations sur la création d'un compartiment, consultez [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html).
**Pour modifier une association State 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 **State Manager**.
1. Sélectionnez une association existante, puis choisissez **Modifier**.
1. Reconfigurez l’association en fonction de vos besoins actuels.
Pour plus d’informations sur les options d’association avec des documents `Command` et `Policy`, consultez la section [Création d'associations](state-manager-associations-creating.md). Pour plus d’informations sur les options d’association avec des dossiers d’exploitation Automation, consultez la section [Exécution des automatisations avec les associations State Manager](scheduling-automations-state-manager-associations.md).
1. Choisissez **Save Changes (Enregistrer les modifications)**.
1. (Facultatif) Pour afficher des informations d’association, sélectionnez le nom de l’association que vous avez modifiée dans la page **Associations**, puis l’onglet **Versions**. Le système liste chaque version de l'association que vous avez créée et modifiée.
1. (Facultatif) Afin d’afficher le résultat pour les associations basées sur des documents `Command` SSM, procédez comme suit :
1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment Simple Storage Service (Amazon S3) que vous avez spécifié pour le stockage de la sortie de commande, puis choisissez le dossier dont le nom est l'ID du nœud qui a exécuté l'association. (Si vous avez choisi de stocker la sortie dans un dossier du compartiment, ouvrez-le en premier.)
1. Explorez sur plusieurs niveaux dans le dossier `awsrunPowerShell` vers le fichier `stdout`.
1. Sélectionnez **Open** ou **Download** pour afficher le nom d'hôte.
## Modifier une association (ligne de commande)
La procédure suivante décrit comment utiliser AWS CLI (sous Linux ouWindows Server) ou comment Outils AWS pour PowerShell modifier et créer une nouvelle version d'une association.
**Pour modifier une association State Manager**
1. Installez et configurez le AWS CLI ou le Outils AWS pour PowerShell, si ce n'est pas déjà fait.
Pour plus d'informations, consultez la section [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) et [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Utilisez le format suivant pour créer une commande permettant de modifier et de créer une nouvelle version d'une association State Manager existante. Remplacez chaque *example resource placeholder* par vos propres informations.
**Important**
Lorsque vous appelez `[https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html)`, le système supprime tous les paramètres facultatifs de la demande et remplace l'association par des valeurs null pour ces paramètres. Ce comportement est intégré à la conception. Vous devez spécifier tous les paramètres facultatifs dans l'appel, même si vous ne modifiez pas les paramètres. Cela inclut le paramètre `--name`. Avant d’appeler cette action, nous vous recommandons d’appeler l’opération `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html)` et de noter tous les paramètres facultatifs requis pour votre appel `update-association`.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--schedule-offset "number_between_1_and_6" \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account
```
------
#### [ Windows ]
```
aws ssm update-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--schedule-offset "number_between_1_and_6" ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ScheduleOffset "number_between_1_and_6" `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account
```
------
L'exemple suivant met à jour une association existante en remplaçant le nom par `TestHostnameAssociation2`. La nouvelle version d'association s'exécute toutes les heures et écrit la sortie des commandes dans le compartiment Amazon S3 spécifié.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name TestHostnameAssociation2 \
--parameters commands="echo Association" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name TestHostnameAssociation2 ^
--parameters commands="echo Association" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName TestHostnameAssociation2 `
-Parameter @{"commands"="echo Association"} `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-S3Location_OutputS3KeyPrefix logs `
-S3Location_OutputS3Region us-east-1 `
-ScheduleExpression "cron(0 */1 * * ? *)"
```
------
L'exemple suivant met à jour une association existante en remplaçant le nom par `CalendarAssociation`. La nouvelle association s'exécute lorsque le calendrier est ouvert, et elle écrit la sortie de la commande dans le compartiment Amazon S3 spécifié.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name CalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name CalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName CalendarAssociation `
-AssociationName OneTimeAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
L'exemple suivant met à jour une association existante en remplaçant le nom par `MultiCalendarAssociation`. La nouvelle association s'exécute lorsque les calendriers sont ouverts, et elle écrit la sortie de la commande dans le compartiment Amazon S3 spécifié.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name MultiCalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name MultiCalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName MultiCalendarAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
1. Pour afficher la nouvelle version de l'association, exécutez la commande suivante.
------
#### [ Linux & macOS ]
```
aws ssm describe-association \
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ Windows ]
```
aws ssm describe-association ^
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ PowerShell ]
```
Get-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE | Select-Object *
```
------
Le système retourne des informations telles que les suivantes.
------
#### [ Linux & macOS ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ Windows ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ PowerShell ]
```
AssociationId : b85ccafe-9f02-4812-9b81-01234EXAMPLE
AssociationName : TestHostnameAssociation2
AssociationVersion : 2
AutomationTargetParameterName :
ComplianceSeverity :
Date : 5/31/2019 2:47:18 PM
DocumentVersion : $DEFAULT
InstanceId :
LastExecutionDate : 5/31/2019 3:26:40 PM
LastSuccessfulExecutionDate : 5/31/2019 3:26:40 PM
LastUpdateAssociationDate : 5/31/2019 3:26:29 PM
MaxConcurrency :
MaxErrors :
Name : AWS-RunPowerShellScript
OutputLocation : Amazon.SimpleSystemsManagement.Model.InstanceAssociationOutputLocation
Overview : Amazon.SimpleSystemsManagement.Model.AssociationOverview
Parameters : {[commands, Amazon.Runtime.Internal.Util.AlwaysSendList`1[System.String]]}
ScheduleExpression : cron(0 */1 * * ? *)
Status :
Targets : {tag:Environment}
```
------
# Suppression d'associations
Utilisez la procédure suivante pour supprimer une association à l'aide de la console AWS Systems Manager .
**Pour supprimer une association**
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**.
1. Sélectionnez une association, puis **Supprimer**.
Vous pouvez supprimer plusieurs associations en une seule opération en exécutant une automatisation depuis la AWS Systems Manager console. Lorsque vous sélectionnez plusieurs associations à supprimer, State Manager lance la page de démarrage du runbook d'automatisation avec l'association IDs saisie sous forme de valeurs de paramètres d'entrée.
**Pour supprimer plusieurs associations en une seule opération**
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**.
1. Sélectionnez chaque association que vous souhaitez supprimer, puis choisissez **Supprimer**.
1. (Facultatif) Dans la zone **Paramètres d'entrée supplémentaires**, sélectionnez l'Amazon Resource Name (ARN) du *rôle de responsable* que vous souhaitez que l'automatisation utilise pendant l'exécution. Pour créer un nouveau rôle de responsable, choisissez **Créer**.
1. Sélectionnez **Soumettre**.
# Exécution de groupes Auto Scaling avec des associations
Une bonne pratique lors de l'utilisation d'associations pour exécuter des groupes Auto Scaling consiste à utiliser des cibles de balises. Si vous n'utilisez pas de balises, vous atteindrez peut-être la limite d'une association.
Si tous les nœuds sont labélisés avec la même clé et la même valeur, une seule association suffit pour exécuter votre groupe Auto Scaling. La procédure suivante décrit comment créer une telle association.
**Pour créer une association qui exécute des groupes Auto Scaling**
1. Vérifiez que tous les nœuds du groupe Auto Scaling sont bien labélisés avec la même clé et la même valeur. Pour obtenir des instructions sur l'étiquetage des nœuds, veuillez consulter [Étiquetage de nœuds et de groupes Auto Scaling](https://docs.aws.amazon.com//autoscaling/ec2/userguide/autoscaling-tagging.html) dans le *Guide de l'utilisateur AWS Auto Scaling *.
1. Créez une association à l'aide de la procédure dans [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
Si vous utilisez la console, sélectionnez **Specify instance tags (Spécifier des balises d'instance)** dans le champ **Targets (Cibles)**. Pour **Instance tags (Balises d'instances)**, saisissez la clé **Tag (Balise)** et la valeur pour votre groupe Auto Scaling.
Si vous utilisez le AWS Command Line Interface (AWS CLI), spécifiez `--targets Key=tag:tag-key,Values=tag-value` où la clé et la valeur correspondent à ce que vous avez étiqueté vos nœuds.
# Affichage des historiques des associations
Vous pouvez afficher toutes les exécutions pour un ID d'association spécifique à l'aide de l'opération [DescribeAssociationExecutions](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutions.html)API. Utilisez cette opération pour afficher le statut, le statut détaillé, les résultats, l’heure de la dernière exécution, et d’autres informations relatives à une association State Manager. State Manager est un outil d’ AWS Systems Manager. Cette opération d'API inclut également des filtres pour vous aider à trouver les associations correspondant aux critères que vous spécifiez. Par exemple, vous pouvez spécifier une date et une heure précises, et utiliser un filtre GREATER\$1THAN pour afficher les exécutions qui ont été traitées après la date et l'heure spécifiées.
Si, par exemple, l'exécution d'une association a échoué, vous pouvez approfondir les détails d'une exécution spécifique à l'aide de l'opération [DescribeAssociationExecutionTargets](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutionTargets.html)d'API. Cette opération vous montre les ressources, telles que le nœud IDs, sur lesquelles l'association s'est exécutée et les différents statuts de l'association. Vous pouvez ensuite constater quel nœud ou quelle ressource n'est pas parvenu à exécuter une association. Vous pouvez utiliser l'ID de ressource pour afficher les détails de l'exécution d'une commande et identifier ainsi l'étape de la commande qui a échoué.
Les exemples de cette section incluent également des informations sur l'utilisation de l'opération [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API pour exécuter une association une fois au moment de sa création. Vous pouvez utiliser cette opération d'API lorsque vous examinez les exécutions d'associations qui ont échoué. Si vous constatez qu'une association a échoué, vous pouvez effectuer une modification sur la ressource, puis exécuter immédiatement cette association pour déterminer si la modification effectuée sur la ressource permet à l'association de s'exécuter correctement.
**Note**
Les opérations d'API initiées par le document SSM lors d'une exécution d'association ne sont pas journalisées dans AWS CloudTrail.
## Affichage des historiques des associations (console)
Utilisez la procédure suivante pour afficher l'historique d'association correspondant à un ID d'association spécifique et afficher ensuite les détails de l'exécution pour une ou plusieurs ressources.
**Pour afficher l'historique d'exécution correspondant à un ID d'association spécifique**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Sélectionnez **State Manager**.
1. Dans le champ **ID d'association**, sélectionnez l'association dont vous souhaitez afficher l'historique.
1. Sélectionnez le bouton **Afficher les détails**.
1. Sélectionnez l'onglet **Historique d'exécution**.
1. Sélectionnez une association dont vous souhaitez afficher les détails d'exécution au niveau des ressources. Par exemple, sélectionnez une association qui indique le statut **Échec**. Vous pouvez ensuite consulter les détails d'exécution pour les nœuds qui n'ont pas réussi à exécuter l'association.
Utilisez les filtres de la zone de recherche pour rechercher l'exécution dont vous souhaitez afficher les détails.
![\[Filtrage de la liste des exécutions d'associations State Manager.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/sysman-state-executions-filter.png)
1. Sélectionnez un ID d'exécution. La page **Association execution targets (Cibles d'exécution de l'association)** s'ouvre. Cette page affiche toutes les ressources qui ont exécuté l'association.
1. Sélectionnez un ID de ressource pour afficher les informations spécifiques relatives à cette ressource.
Utilisez les filtres de la zone de recherche pour rechercher la ressource dont vous souhaitez afficher les détails.
![\[Filtrage de la liste des cibles d'exécution d'associations State Manager.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/sysman-state-executions-targets-filter.png)
1. Si vous effectuez une recherche sur une association dont l'exécution a échoué, vous pouvez utiliser le bouton **Appliquer l'association maintenant** pour exécuter une association une seule fois lors de sa création. Une fois que vous avez modifié la ressource sur laquelle l'exécution de l'association a échoué, sélectionnez le lien **ID d'association** dans le chemin de navigation.
1. Sélectionnez le bouton **Appliquer l'association maintenant**. Une fois l'exécution terminée, vérifiez que l'exécution de l'association a réussi.
## Affichage des historiques d'associations (ligne de commande)
La procédure suivante décrit comment utiliser le AWS Command Line Interface (AWS CLI) (sous Linux ouWindows Server) ou Outils AWS pour PowerShell pour afficher l'historique d'exécution d'un ID d'association spécifique. Ensuite, la procédure décrit comment afficher les détails d'exécution d'une ou de plusieurs ressources.
**Pour afficher l'historique d'exécution correspondant à un ID d'association spécifique**
1. Installez et configurez le AWS CLI ou le Outils AWS pour PowerShell, si ce n'est pas déjà fait.
Pour plus d'informations, consultez la section [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) et [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Exécutez la commande suivante pour afficher la liste des exécutions correspondant à un ID d'association spécifique.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**Note**
Cette commande inclut un filtre pour limiter les résultats aux exécutions qui se sont produites après une date et une heure spécifiques. Pour afficher toutes les exécutions correspondant à un ID d'association spécifique, supprimez le paramètre `--filters` et la valeur ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**Note**
Cette commande inclut un filtre pour limiter les résultats aux exécutions qui se sont produites après une date et une heure spécifiques. Pour afficher toutes les exécutions correspondant à un ID d'association spécifique, supprimez le paramètre `--filters` et la valeur ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId ID `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}
```
**Note**
Cette commande inclut un filtre pour limiter les résultats aux exécutions qui se sont produites après une date et une heure spécifiques. Pour afficher toutes les exécutions correspondant à un ID d'association spécifique, supprimez le paramètre `-Filter` et la valeur ` @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}`.
------
Le système retourne des informations telles que les suivantes.
------
#### [ Linux & macOS ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ Windows ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ PowerShell ]
```
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/18/2019 2:00:50 AM
DetailedStatus : Success
ExecutionId : 76a5a04f-caf6-490c-b448-92c02EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/11/2019 2:00:54 AM
DetailedStatus : Success
ExecutionId : 791b72e0-f0da-4021-8b35-f95dfEXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/4/2019 2:01:00 AM
DetailedStatus : Success
ExecutionId : ecec60fa-6bb0-4d26-98c7-140308EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
```
------
Vous pouvez limiter les résultats en utilisant un ou plusieurs filtres. L'exemple suivant renvoie toutes les associations qui ont été exécutées avant une date et une heure spécifiques.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="LESS_THAN"}
```
------
L'exemple suivant renvoie toutes les associations qui ont été exécutées *correctement* après une date et une heure spécifiques.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{
"Key"="CreatedTime";
"Value"="2019-06-01T19:15:38.372Z";
"Type"="GREATER_THAN"
},
@{
"Key"="Status";
"Value"="Success";
"Type"="EQUAL"
}
```
------
1. Exécutez la commande suivante pour afficher toutes les cibles sur lesquelles l'exécution spécifique a eu lieu.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE
```
------
Vous pouvez limiter les résultats en utilisant un ou plusieurs filtres. L'exemple suivant renvoie les informations relatives à toutes les cibles sur lesquelles l'exécution de l'association spécifique a échoué.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value="Failed"
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value="Failed"
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Failed"
}
```
------
L'exemple suivant renvoie les informations relatives à un nœud géré spécifique sur lequel l'exécution d'une association a échoué.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Success"
},
@{
"Key"="ResourceId";
"Value"="i-02573cafcfEXAMPLE"
},
@{
"Key"="ResourceType";
"Value"="ManagedInstance"
}
```
------
1. Si vous étudiez une association qui n'a pas pu s'exécuter, vous pouvez utiliser l'opération d'[StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API pour exécuter une association immédiatement et une seule fois. Lorsque vous modifiez la ressource sur laquelle l'exécution de l'association a échoué, utilisez la commande suivante pour exécuter l'association immédiatement et une seule fois.
------
#### [ Linux & macOS ]
```
aws ssm start-associations-once \
--association-id ID
```
------
#### [ Windows ]
```
aws ssm start-associations-once ^
--association-id ID
```
------
#### [ PowerShell ]
```
Start-SSMAssociationsOnce `
-AssociationId ID
```
------
# Utilisation d'associations avec IAM
State Manager, un outil dans AWS Systems Manager, utilise des [cibles](systems-manager-state-manager-targets-and-rate-controls.md#systems-manager-state-manager-targets-and-rate-controls-about-targets) pour choisir les instances avec lesquelles vous configurez vos associations. À l'origine, les associations étaient créées en spécifiant un nom de document (`Name`) et un ID d'instance (`InstanceId`). Une association était ainsi créée entre un document et une instance ou un nœud géré. Auparavant, les associations étaient identifiées par ces paramètres. Bien que ces paramètres soient aujourd'hui obsolètes, ils sont toujours pris en charge. Les ressources `instance` et `managed-instance` ont été ajoutées en tant que ressources à des actions avec `Name` et `InstanceId`.
Gestion des identités et des accès AWS Le comportement d'application des politiques (IAM) dépend du type de ressource spécifié. Les ressources pour des opérations State Manager sont appliquées uniquement sur la base de la demande transmise. State Manager ne vérifie pas en profondeur les propriétés des ressources de votre compte. Une demande n'est validée par rapport aux ressources de politique que si le paramètre de la demande contient les ressources de politique spécifiées. Par exemple, si vous spécifiez une instance dans le bloc de ressources, la politique est appliquée si la demande utilise le paramètre `InstanceId`. Pour chaque ressource du compte, le paramètre `InstanceId` n'est pas vérifié dans le paramètre `Targets`.
Voici quelques cas de comportement confus :
+ [DescribeAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DescribeActivations.html), [DeleteAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DeleteAssociation.html), et [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)use `instance``managed-instance`, et `document` ressources pour spécifier la manière déconseillée de faire référence aux associations. Cela inclut toutes les associations créées avec le paramètre `InstanceId` obsolète.
+ [CreateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociation.html), [CreateAssociationBatch](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociationBatch.html), ainsi que [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)l'utilisation `instance` et `managed-instance` les ressources pour spécifier la manière déconseillée de faire référence aux associations. Cela inclut toutes les associations créées avec le paramètre `InstanceId` obsolète. Le type de ressource `document` fait partie de la manière obsolète de faire référence aux associations. C'est une propriété réelle d'une association. Autrement dit, vous pouvez créer des politiques IAM avec des autorisations `Allow` ou `Deny` pour les actions `Create` et `Update` en fonction du nom du document.
Pour de plus amples informations sur l'utilisation de politiques IAM avec Systems Manager, veuillez consulter [Gestion des identités et des accès pour AWS Systems Manager](security-iam.md) ou [Actions, ressources et clés de condition pour AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html) dans la *Référence des autorisations de service*.
# Création d'associations qui exécutent des fichiers MOF
Vous pouvez exécuter des fichiers MOF (Managed Object Format) pour appliquer un état cible aux nœuds Windows Server gérés à l'aide State Manager d'un outil AWS Systems Manager, en utilisant le document `AWS-ApplyDSCMofs` SSM. Le document `AWS-ApplyDSCMofs` a deux modes d'exécution. Avec le premier mode, vous pouvez configurer l'association pour analyser et indiquer si les nœuds gérés sont dans l'état souhaité défini dans les fichiers MOF spécifiés. Dans le second mode, vous pouvez exécuter les fichiers MOF et modifier la configuration de vos nœuds basés sur les ressources et leurs valeurs définies dans les fichiers MOF. Le document `AWS-ApplyDSCMofs` vous permet de télécharger et d'exécuter des fichiers de configuration MOF à partir d'Amazon Simple Storage Service (Amazon S3), d'un partage local ou d'un site web sécurisé avec un domaine HTTPS.
State Manager journalise et signale le statut de chaque exécution de fichier MOF au cours de chaque exécution d'association. State Manager signale également la sortie de chaque exécution de fichier MOF en tant qu'événement de conformité que vous pouvez afficher sur la page de [conformitéAWS Systems Manager](https://console.aws.amazon.com/systems-manager/compliance).
L'exécution des fichiers MOF repose sur la configuration d'état PowerShell souhaitée (PowerShell DSC) de Windows. PowerShell DSC est une plate-forme déclarative utilisée pour la configuration, le déploiement et la gestion des systèmes Windows. PowerShell DSC permet aux administrateurs de décrire, dans de simples documents texte appelés configurations DSC, comment ils souhaitent qu'un serveur soit configuré. Une configuration PowerShell DSC est un PowerShell script spécialisé qui indique ce qu'il faut faire, mais pas comment le faire. L'exécution de la configuration génère un fichier MOF. Le fichier MOF peut être appliqué à un ou plusieurs serveurs afin d'obtenir la configuration souhaitée pour ces serveurs. PowerShell Les ressources DSC se chargent réellement de l'application de la configuration. Pour plus d'informations, consultez la section [Présentation de la configuration de l'état PowerShell souhaité de Windows](https://download.microsoft.com/download/4/3/1/43113F44-548B-4DEA-B471-0C2C8578FBF8/Quick_Reference_DSC_WS12R2.pdf).
**Topics**
+ [Utilisation d'Amazon S3 pour stocker les artefacts](#systems-manager-state-manager-using-mof-file-S3-storage)
+ [Résolution des informations d'identification dans les fichiers MOF](#systems-manager-state-manager-using-mof-file-credentials)
+ [Utilisation de jetons dans les fichiers MOF](#systems-manager-state-manager-using-mof-file-tokens)
+ [Conditions préalables à la création d’associations qui exécutent des fichiers MOF](#systems-manager-state-manager-using-mof-file-prereqs)
+ [Création d'une association qui exécute des fichiers MOF](#systems-manager-state-manager-using-mof-file-creating)
+ [Résolution des problèmes lors de la création d’associations qui exécutent des fichiers MOF](#systems-manager-state-manager-using-mof-file-troubleshooting)
+ [Affichage des détails de conformité des ressources DSC](#systems-manager-state-manager-viewing-mof-file-compliance)
## Utilisation d'Amazon S3 pour stocker les artefacts
Si vous utilisez Amazon S3 pour stocker des PowerShell modules, des fichiers MOF, des rapports de conformité ou des rapports d'état, le rôle Gestion des identités et des accès AWS (IAM) utilisé par AWS Systems Manager SSM Agent doit avoir `GetObject` des `ListBucket` autorisations sur le compartiment. Si vous ne fournissez pas ces autorisations, le système renvoie une erreur *Accès refusé*. Voici des informations importantes sur le stockage d'artefacts dans Amazon S3.
+ Si le compartiment se trouve dans un autre compartiment Compte AWS, créez une politique de ressources du compartiment qui accorde le compte (ou le rôle IAM) `GetObject` et `ListBucket` les autorisations.
+ Si vous voulez utiliser des ressources DSC personnalisées, vous pouvez les télécharger à partir d'un compartiment Amazon S3. Vous pouvez également les installer automatiquement depuis la PowerShell galerie.
+ Si vous utilisez Amazon S3 comme source de module, téléchargez le module sous forme de fichier Zip au format majuscules/minuscules suivant : *ModuleName* \$1 *ModuleVersion* .zip. Par exemple : MyModule \$11.0.0.zip.
+ Tous les fichiers doivent se trouver dans le compartiment racine. Les structures de dossier ne sont pas prises en charge.
## Résolution des informations d'identification dans les fichiers MOF
Les informations d'identification sont résolues en utilisant [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) ou [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md). Cela vous permet de configurer la rotation automatique des informations d'identification. Cela permet également à DSC de propager automatiquement les informations d'identification à vos serveurs sans les redéployer. MOFs
Pour utiliser un AWS Secrets Manager secret dans une configuration, créez un PSCredential objet dont le nom d'utilisateur est le secret SecretId ou le SecretArn du secret contenant les informations d'identification. Vous pouvez spécifier n'importe quelle valeur pour le mot de passe. La valeur est ignorée. Voici un exemple.
```
Configuration MyConfig
{
$ss = ConvertTo-SecureString -String 'a_string' -AsPlaintext -Force
$credential = New-Object PSCredential('a_secret_or_ARN', $ss)
Node localhost
{
File file_name
{
DestinationPath = 'C:\MyFile.txt'
SourcePath = '\\FileServer\Share\MyFile.txt'
Credential = $credential
}
}
}
```
Compilez votre MOF en utilisant les PsAllowPlaintextPassword paramètres des données de configuration. Cette opération ne pose pas de problème, car les informations d'identification contiennent uniquement une étiquette.
Dans Secrets Manager, assurez-vous que le nœud dispose d'un GetSecretValue accès dans le cadre d'une politique gérée par IAM, et éventuellement dans la politique de ressources secrètes s'il en existe une. Pour fonctionner avec DSC, le secret doit être au format suivant.
```
{ 'Username': 'a_name', 'Password': 'a_password' }
```
Le secret peut avoir d'autres propriétés (par exemple, des propriétés utilisées pour la rotation), mais il doit comporter au moins le nom d'utilisateur et le mot de passe.
Nous vous recommandons d'utiliser une méthode de rotation multi-utilisateurs, dans laquelle vous avez deux noms d'utilisateur et mots de passe différents, et la AWS Lambda fonction de rotation alterne entre eux. Cette méthode vous permet d'avoir plusieurs comptes actifs tout en éliminant le risque de bloquer un utilisateur pendant la rotation.
## Utilisation de jetons dans les fichiers MOF
Les jetons vous permettent de modifier des valeurs de propriété de ressource *après* que le fichier MOF a été compilé. Cela vous permet de réutiliser des fichiers MOF courants sur plusieurs serveurs qui nécessitent des configurations similaires.
La substitution de jeton ne fonctionne que pour les propriétés de ressource de type `String`. Toutefois, si votre ressource comporte une propriété de nœud CIM imbriquée, elle résout également les jetons CIM à partir des propriétés `String` dans ce nœud CIM. Vous ne pouvez pas utiliser la substitution de jeton pour des nombres ou des tableaux.
Par exemple, imaginez un scénario dans lequel vous utilisez la xComputerManagement ressource et souhaitez renommer l'ordinateur à l'aide de DSC. Normalement, vous avez besoin d'un fichier MOF dédié pour cette machine. Cependant, avec la prise en charge des jetons, vous pouvez créer un seul fichier MOF et l'appliquer à tous vos nœuds. Dans la propriété `ComputerName`, au lieu de coder en dur le nom d'ordinateur dans le fichier MOF, vous pouvez utiliser un jeton de type balise (Tag) d'instance. La valeur est résolue lors de l'analyse du fichier MOF. Consultez l'exemple suivant.
```
Configuration MyConfig
{
xComputer Computer
{
ComputerName = '{tag:ComputerName}'
}
}
```
Vous définissez ensuite une identification sur le nœud géré dans la console Systems Manager, ou une identification Amazon Elastic Compute Cloud (Amazon EC2) dans la console Amazon EC2. Lorsque vous exécutez le document, le script remplace le jeton \$1tag :ComputerName\$1 par la valeur de la balise d'instance.
Vous pouvez également combiner plusieurs balises dans une seule propriété, tel qu'illustré dans l'exemple suivant :
```
Configuration MyConfig
{
File MyFile
{
DestinationPath = '{env:TMP}\{tag:ComputerName}'
Type = 'Directory'
}
}
```
Vous pouvez utiliser cinq types de jetons différents :
+ **identification** : identifications Amazon EC2 ou de nœud géré.
+ **tagb64** : Identique à tag, mais le système utilise base64 pour décoder la valeur. Cela vous permet d'utiliser des caractères spéciaux dans des valeurs de balise.
+ **env** : Résout des variables d'environnement.
+ **ssm** : valeurs Parameter Store. Seuls les types String et Secure String sont pris en charge.
+ **tagssm** : identique à tag, mais si l'identification n'est pas définie sur le nœud, le système tente de résoudre la valeur à partir d'un paramètre Systems Manager avec le même nom. Cela s'avère utile dans des situations où vous souhaitez disposer d'une « valeur globale par défaut », mais pouvoir la remplacer sur un seul nœud (par exemple, pour des déploiements « one-box »).
Voici un exemple Parameter Store qui utilise le type de jeton `ssm`.
```
File MyFile
{
DestinationPath = "C:\ProgramData\ConnectionData.txt"
Content = "{ssm:%servicePath%/ConnectionData}"
}
```
Les jetons jouent un rôle important pour la réduction du code redondant en rendant les fichiers MOF génériques et réutilisables. Si vous pouvez éviter les fichiers MOF spécifiques à un serveur, vous n'avez pas besoin d'un service de génération de fichier MOF. Un service de création MOF augmente les coûts, ralentit le temps de provisionnement et augmente le risque de dérive de configuration entre les nœuds groupés en raison des différentes versions des modules installées sur le serveur de compilation lors de leur compilation MOFs .
## Conditions préalables à la création d’associations qui exécutent des fichiers MOF
Avant de créer une association qui exécute des fichiers MOF, vérifiez que vos nœuds gérés ont les prérequis suivants installés :
+ Windows PowerShell version 5.0 ou ultérieure. Pour plus d'informations, consultez la section [Configuration PowerShell système requise pour Windows](https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-6) sur Microsoft.com.
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) version 3.3.261.0 ou ultérieure.
+ SSM Agent version 2.2 ou une version ultérieure.
## Création d'une association qui exécute des fichiers MOF
**Pour créer une association qui exécute des fichiers MOF**
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**.
1. Sélectionnez **State Manager**, puis **Create association (Créer une association)**.
1. Dans le champ **Nom**, spécifiez un nom. Cette action est facultative, mais recommandée. Un nom peut vous aider à comprendre quel était l'objectif de l'association quand vous avez créée celle-ci. Les espaces ne sont pas autorisés dans le nom.
1. Dans la liste **Document**, sélectionnez **`AWS-ApplyDSCMofs`**.
1. Dans la section **Parameters (Paramètres)**, spécifiez vos choix pour les paramètres d'entrée obligatoires et facultatifs.
1. **Mofs To Apply (Fichiers MOF à appliquer)** : spécifiez un ou plusieurs fichiers MOF à exécuter lors de l'exécution de cette association. Utilisez des virgules pour séparer les fichiers MOF dans une liste. Systems Manager parcourt la liste des fichiers MOF et les exécute dans l’ordre indiqué par la liste séparée par des virgules.
+ Nom de compartiment Amazon S3. Les noms de compartiment doivent utiliser des lettres minuscules. Spécifiez cette information à l'aide du format suivant.
```
s3:amzn-s3-demo-bucket:MOF_file_name.mof
```
Si vous souhaitez spécifier un Région AWS, utilisez le format suivant.
```
s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof
```
+ Un site web sécurisé. Spécifiez cette information à l'aide du format suivant.
```
https://domain_name/MOF_file_name.mof
```
Voici un exemple.
```
https://www.example.com/TestMOF.mof
```
+ Un système de fichiers sur un partage local. Spécifiez cette information à l'aide du format suivant.
```
\server_name\shared_folder_name\MOF_file_name.mof
```
Voici un exemple.
```
\StateManagerAssociationsBox\MOFs_folder\MyMof.mof
```
1. **Service Path (Chemin d'accès au service)** : (Facultatif) Un chemin d'accès au service est un préfixe d'un compartiment Amazon S3 dans lequel vous voulez écrire des rapports et des informations de statut. Ou, un chemin d'accès au service est un chemin pour des balises basées sur des paramètres Parameter Store. Lors de la résolution de balises basées sur des paramètres, le système utilise \$1ssm : %ServicePath%/*parameter\$1name*\$1 pour injecter la valeur ServicePath dans le nom du paramètre. Par exemple, si le chemin de votre service est «WebServers/Production" then the systems resolves the parameter as: WebServers/Production/»*parameter\$1name*. Cela s'avère utile lorsque vous exécutez plusieurs environnements dans le même compte.
1. **Report Bucket Name (Nom du compartiment des rapports)** : (Facultatif) Saisissez le nom d'un compartiment Amazon S3 dans lequel vous voulez écrire les données de conformité. Les rapports sont enregistrés dans ce compartiment au format JSON.
**Note**
Vous pouvez préfixer le nom de compartiment avec une région dans laquelle se trouve le compartiment. Voici un exemple : MOFBucket US-West-2:My. Si vous utilisez un proxy pour les points de terminaison Amazon S3 dans une région spécifique qui n'inclut pas us-east-1, vous devez préfixer le nom de compartiment avec une région. Si le nom du compartiment n'est pas préfixé, la région du compartiment sera automatiquement découverte à l'aide du point de terminaison us-east-1.
1. **Mof Operation Mode (Mode d'opération MOF)** : sélectionnez le comportement State Manager lors de l'exécution de l'association **`AWS-ApplyDSCMofs`** :
+ **Apply (Appliquer)** : corriger les configurations de nœuds qui ne sont pas conformes.
+ **ReportOnly**: ne corrigez pas les configurations des nœuds, mais enregistrez toutes les données de conformité et signalez les nœuds non conformes.
1. **Status Bucket Name (Statut du compartiment des rapports)** : (Facultatif) Entrez le nom d'un compartiment Amazon S3 dans lequel vous voulez écrire les informations de statut d'exécution de fichier MOF. Ces rapports de statut sont des résumés de singleton de la dernière exécution de conformité d'un nœud. Cela signifie que le rapport est remplacé la fois suivante où l'association exécute des fichiers MOF.
**Note**
Vous pouvez préfixer le nom de compartiment avec une région dans laquelle se trouve le compartiment. Voici un exemple : `us-west-2:amzn-s3-demo-bucket` Si vous utilisez un proxy pour les points de terminaison Amazon S3 dans une région spécifique qui n'inclut pas us-east-1, vous devez préfixer le nom de compartiment avec une région. Si le nom du compartiment n'est pas préfixé, la région du compartiment sera automatiquement découverte à l'aide du point de terminaison us-east-1.
1. **Nom du compartiment source du module** : (Facultatif) Entrez le nom d'un compartiment Amazon S3 contenant les fichiers PowerShell du module. Si vous spécifiez **None (Aucun)**, sélectionnez **True (Vrai)** pour l'option suivante, **Allow PS Gallery Module Source (Autoriser la galerie PS comme source de module)**.
**Note**
Vous pouvez préfixer le nom de compartiment avec une région dans laquelle se trouve le compartiment. Voici un exemple : `us-west-2:amzn-s3-demo-bucket` Si vous utilisez un proxy pour les points de terminaison Amazon S3 dans une région spécifique qui n'inclut pas us-east-1, vous devez préfixer le nom de compartiment avec une région. Si le nom du compartiment n'est pas préfixé, la région du compartiment sera automatiquement découverte à l'aide du point de terminaison us-east-1.
1. **Autoriser la source du module PS Gallery** : (Facultatif) Choisissez **True** pour télécharger PowerShell les modules depuis [https://www.powershellgallery.com/](https://www.powershellgallery.com/). Si vous choisissez **False**, spécifiez une source pour l'option précédente, **ModuleSourceBucketName**.
1. **Proxy Uri (URI du proxy)** : (Facultatif) Utilisez cette option pour télécharger les fichiers MOF à partir d'un serveur proxy.
1. **Reboot Behavior (Comportement de redémarrage)** : (Facultatif) Spécifiez l'un des comportements de redémarrage suivants si votre exécution de fichier MOF nécessite un redémarrage :
+ **AfterMof**: Redémarre le nœud une fois toutes les exécutions MOF terminées. Même si plusieurs exécutions de fichier MOF demandent un redémarrage, le système attend que toutes les exécutions de fichier MOF soient terminées pour redémarrer.
+ **Immediately (Immédiatement)** : redémarre le nœud chaque fois qu'une exécution de fichier MOF le demande. Lors de l'exécution de plusieurs fichiers MOF demandant un redémarrage, le nœud est redémarré plusieurs fois.
+ **Never (Jamais)** : les nœuds ne sont pas redémarrés, même si l'exécution de fichier MOF demande explicitement un redémarrage.
1. **Use Computer Name For Reporting (Utiliser le nom de l'ordinateur pour les rapports)** : (facultatif) activez cette option pour utiliser le nom de l'ordinateur lors de la génération des informations des rapports de conformité. La valeur par défaut est **false** (faux), qui signifie que le système utilise l'ID de nœud lors de la création des rapports de conformité.
1. **Enable Verbose Logging (Activer la journalisation détaillée)** : (facultatif) nous vous recommandons d'activer la journalisation détaillée lors du déploiement de fichiers MOF pour la première fois.
**Important**
Lorsqu'elle est activée, la journalisation détaillée écrit plus de données dans votre compartiment Amazon S3 que la journalisation d'exécution d'association standard. Cela peut entraîner un ralentissement des performances et des frais de stockage plus élevés pour Amazon S3. Pour éviter les problèmes de taille de stockage, nous vous recommandons d'activer des politiques de cycle de vie sur le compartiment Amazon S3. Pour de plus amples informations, consultez [ Comment créer une politique de cycle de vie pour un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
1. **Enable Debug Logging (Activer la journalisation de débogage)** : (facultatif) nous vous recommandons d'activer la journalisation de débogage pour résoudre les échecs de fichier MOF. Nous vous recommandons également de désactiver cette option pour une utilisation normale.
**Important**
Lorsqu'elle est activée, la journalisation de débogage écrit plus de données dans votre compartiment Amazon S3 que la journalisation d'exécution d'association standard. Cela peut entraîner un ralentissement des performances et des frais de stockage plus élevés pour Amazon S3. Pour éviter les problèmes de taille de stockage, nous vous recommandons d'activer des politiques de cycle de vie sur le compartiment Amazon S3. Pour de plus amples informations, consultez [ Comment créer une politique de cycle de vie pour un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
1. **Compliance Type (Type de conformité)** : (Facultatif) Spécifiez le type de conformité à utiliser pour la génération des rapports d'informations de conformité. Le type de conformité par défaut est **Custom:DSC**. Si vous créez plusieurs associations qui exécutent des fichiers MOF, assurez-vous de spécifier un type de conformité différent pour chaque association. Sinon, chaque association supplémentaire qui utilise **Custom:DSC** écrase les données de conformité existantes.
1. **Pre Reboot Script (Script préalable au redémarrage)** : (Facultatif) Spécifiez un script à exécuter si la configuration a indiqué qu'un redémarrage était nécessaire. Le script s'exécute avant le redémarrage. Le script doit tenir sur une seule ligne. Séparez les lignes supplémentaires par des points-virgules.
1. Dans la section **Targets (Cibles)**, sélectionnez **Specifying tags (Spécification de balises)** ou **Manually Selecting Instance (Sélection manuelle des instances)**. Si vous choisissez de cibler des ressources à l'aide de balises, entrez une clé de balise et une valeur de balise dans les champs fournis. Pour plus d'informations sur l'utilisation des cibles, 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. Dans la section **Specify schedule (Spécifier le programme)**, sélectionnez **On Schedule (Selon le calendrier)** ou **No schedule (Pas de calendrier)**. Si vous sélectionnez **On Schedule (Selon le calendrier)**, utilisez les boutons fournis pour créer un calendrier de type cron ou rate pour l'association.
1. Dans la section **Advanced options (Options avancées)** :
+ Dans **Compliance severity (Sévérité de conformité)**, sélectionnez un niveau de sévérité pour l'association. Les rapports de conformité indiquent si l'état de l'association est conforme ou non conforme, ainsi que le niveau de sévérité que vous spécifiez ici. Pour de plus amples informations, veuillez consulter [A propos de la conformité des associations State Manager](compliance-about.md#compliance-about-association).
1. Dans la section **Rate control** (Contrôle de taux), configurez des options pour l'exécution d'associations State Manager dans un parc de nœuds gérés. Pour plus d'informations sur ces options, consultez [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
Dans la section **Simultanéité**, sélectionnez une option :
+ Sélectionnez **targets (cibles)** pour entrer un nombre absolu de cibles pouvant exécuter l'association simultanément.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage de l'ensemble de cibles pouvant exécuter l'association simultanément.
Dans la section **Error threshold (Seuil d'erreurs)**, sélectionnez une option :
+ Sélectionnez **errors (erreurs)** pour saisir un nombre absolu d'erreurs autorisées avant que State Manager cesse de d'exécuter des associations sur des cibles supplémentaires.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage d'erreurs autorisées avant que State Manager cesse de d'exécuter des associations sur des cibles supplémentaires.
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)**.
State Manager crée et exécute immédiatement l'association sur les cibles spécifiées. Après l'exécution initiale, l'association s'exécute à des intervalles selon le programme que vous avez défini et les règles suivantes :
+ State Manager exécute des associations sur les nœuds qui sont en ligne lorsque l'intervalle commence, et ignore les nœuds hors ligne.
+ State Manager tente d'exécuter l'association sur tous les nœuds configurés au cours d'un intervalle.
+ Si une association n'est pas exécutée au cours d'un intervalle (par exemple, parce qu'une valeur de simultanéité a limité par le nombre de nœuds pouvant traiter l'association simultanément), State Manager tente d'exécuter l'association lors du prochain intervalle.
+ State Manager enregistre un historique pour tous les intervalles ignorés. Vous pouvez consulter l'historique dans l'onglet **Execution History (Historique d'exécution)**.
**Note**
Le `AWS-ApplyDSCMofs` est un document Command de Systems Manager. Cela signifie que vous pouvez également exécuter ce document en utilisant Run Command, un outil d’ AWS Systems Manager. Pour de plus amples informations, veuillez consulter [AWS Systems Manager Run Command](run-command.md).
## Résolution des problèmes lors de la création d’associations qui exécutent des fichiers MOF
Cette section comprend des informations qui vous aideront à résoudre les problèmes liés à la création d'associations qui exécutent des fichiers MOF.
**Activation de la journalisation améliorée**
Comme première étape du dépannage, activez la journalisation améliorée. Plus précisément, procédez comme suit :
1. Vérifiez que l'association est configurée pour écrire la sortie de commande dans Amazon S3 ou Amazon CloudWatch Logs (CloudWatch).
1. Définissez le paramètre **Enable Verbose Logging (Activer la journalisation détaillée)** sur True.
1. Définissez le paramètre **Enable Debug Logging (Activer la journalisation de débogage)** sur True.
Avec la journalisation détaillée et de débogage activée, le fichier de sortie **Stdout** comprend plus de détails sur l'exécution du script. Ce fichier de sortie peut vous aider à identifier l'endroit où le script a échoué. Le fichier de sortie **Stderr** contient les erreurs qui se sont produites au cours de l'exécution du script.
**Problèmes courants lors de la création d’associations qui exécutent des fichiers MOF**
Cette section inclut des informations sur les problèmes courants qui peuvent se produire lorsque vous créez des associations qui exécutent des fichiers MOF. Il comprend également les étapes permettant de résoudre ces problèmes.
**Mon fichier MOF n'a pas été appliqué**
Si State Manager n'a pas pu appliquer l'association à vos nœuds, commencez par vérifier fichier de sortie **Stderr**. Ce fichier peut vous aider à comprendre la cause première du problème. Vérifiez également que les points suivants :
+ Le nœud comporte les autorisations d'accès requises à tous les compartiments Simple Storage Service (Amazon S3) liés aux fichiers MOF. En particulier :
+ **s3 : GetObject autorisations** : cela est obligatoire pour les fichiers MOF dans les compartiments Amazon S3 privés et les modules personnalisés dans les compartiments Amazon S3.
+ **s3 : PutObject autorisation** : cela est nécessaire pour écrire des rapports de conformité et l'état de conformité dans les compartiments Amazon S3.
+ Si vous utilisez des identifications, assurez-vous que le nœud dispose des politiques IAM requises. L'utilisation de balises nécessite que le rôle IAM d'instance dispose d'une politique autorisant les actions `ec2:DescribeInstances` et `ssm:ListTagsForResource`.
+ Assurez-vous que le nœud dispose des identifications attendues ou des paramètres SSM attribués.
+ Assurez-vous que les balises ou les paramètres SSM sont correctement orthographiés.
+ Essayez d'appliquer le fichier MOF localement sur le nœud pour vous assurer que le problème n'est pas lié au fichier MOF lui-même.
**Mon fichier MOF semble avoir échoué, mais l'exécution Systems Manager a réussi**
Si le document `AWS-ApplyDSCMofs` s'est exécuté avec succès, le statut d'exécution Systems Manager affiche **Success (Réussite)**. Ce statut ne reflète pas le statut de conformité de votre nœud par rapport aux exigences de configuration figurant dans le fichier MOF. Pour voir le statut de conformité de vos nœuds, consultez les rapports de conformité. Vous pouvez afficher un rapport JSON dans le compartiment des rapports Amazon S3. Cela s'applique aux exécutions Run Command et State Manager. En outre, pour State Manager, vous pouvez afficher les détails de conformité sur la page de conformité Systems Manager.
**Stderr spécifie : « Name resolution failure attempting to reach service » (Échec de résolution de nom lors d'une tentative d'accès au service)**
Cette erreur indique que le script ne peut pas atteindre un service distant. Il est vraisemblable que le script ne peut pas atteindre Amazon S3. Ce problème se produit le plus souvent lorsque le script tente d'écrire des rapports de conformité ou un statut de conformité dans le compartiment Amazon S3 fourni dans les paramètres du document. En général, cette erreur a lieu lorsqu'un environnement informatique utilise un pare-feu ou un proxy transparent qui inclut une liste d'autorisations. Pour résoudre ce problème :
+ Utilisez la syntaxe de compartiment spécifique à la région pour tous les paramètres de compartiment Amazon S3. Par exemple, le paramètre **Mofs To Apply (Fichiers MOF à appliquer)** doit être formaté comme suit :
s3 : *bucket-region* *amzn-s3-demo-bucket* : *mof-file-name* .mof.
Voici un exemple :` s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof`
Les noms des compartiments de rapport, de statut et de source de module doivent être formatés comme suit :
*bucket-region*:*amzn-s3-demo-bucket*. Voici un exemple : `us-west-1:amzn-s3-demo-bucket;`
+ Si la syntaxe spécifique à la Région ne permet pas de résoudre le problème, assurez-vous que le ou les nœuds ciblés peuvent accéder à Simple Storage Service (Amazon S3) dans la Région souhaitée. Pour vérifier ceci :
1. Recherchez le nom du point de terminaison pour Amazon S3 dans la région Amazon S3 appropriée. Pour plus d'informations, veuillez consulter la rubrique [Points de terminaison de service Amazon S3](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region) dans la *Référence générale d'Amazon Web Services*.
1. Connectez-vous au nœud cible et exécutez la commande ping suivante.
```
ping s3.s3-region.amazonaws.com
```
Si le ping échoue, cela signifie qu'Amazon S3 est en panne, qu'un firewall/transparent proxy bloque l'accès à la région Amazon S3 ou que le nœud ne peut pas accéder à Internet.
## Affichage des détails de conformité des ressources DSC
Systems Manager capture les informations de conformité sur les défaillances de ressources DSC dans le **Status Bucket (Compartiment de statut)** Amazon S3 que vous avez spécifié lorsque vous avez exécuté le document `AWS-ApplyDSCMofs`. La recherche d'informations sur les défaillances de ressources DSC dans un compartiment Amazon S3 peut prendre du temps. Au lieu de cela, vous pouvez consulter ces informations sur la page **Compliance (Conformité)** de Systems Manager.
La section **Récapitulatif des ressources de conformité** affiche le nombre de ressources qui ont échoué. Dans l'exemple suivant, il **ComplianceType**s'agit de **Custom:DSC** et une ressource n'est pas conforme.
**Note**
Custom:DSC est la **ComplianceType**valeur par défaut du document. `AWS-ApplyDSCMofs` Cette valeur est personnalisable.
![\[Affichage de comptages dans la section Compliance resources summary (Récapitulatif des ressources de conformité) de la page Compliance (Conformité).\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-3.png)
La section **Vue d'ensemble détaillée des ressources** affiche des informations sur la AWS ressource contenant la ressource DSC non conforme. Cette section inclut également le nom MOF, les étapes d'exécution du script et (le cas échéant) un lien **View output (Afficher la sortie)** pour consulter des informations de statut détaillées.
![\[Affichage des détails de conformité pour une défaillance de ressource d'exécution MOF\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-1.png)
Le lien **Afficher la sortie** affiche les 4 000 derniers caractères du statut détaillé. Systems Manager utilise l'exception comme premier élément, puis analyse les messages détaillés à rebours, et en ajoute le plus possible jusqu'au quota de 4 000 caractères. Ce processus affiche les messages de journal qui ont été générés avant que l'exception soit déclenchée, qui sont les plus pertinents pour la résolution.
![\[Affichage de la sortie détaillée pour un problème de conformité de ressource MOF\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-2.png)
Pour de plus amples informations sur la façon d'afficher les informations de conformité, consultez [Conformité d'AWS Systems Manager](systems-manager-compliance.md).
**Situations qui affectent les rapports de conformité**
Si l'association State Manager échoue, aucune donnée de conformité n'est présentée. Plus spécifiquement, si un MOF ne peut pas être traité, Systems Manager ne signale aucun élément de conformité, car les associations échouent. Par exemple, si Systems Manager tente de télécharger un MOF à partir d'un compartiment Simple Storage Service (Amazon S3) auquel le nœud n'est pas autorisé à accéder, l'association échoue et aucune donnée de conformité n'est présentée.
Si une ressource dans un deuxième MOF échoue, Systems Manager *génère* des donnée de conformité. Par exemple, si un MOF tente de créer un fichier sur un lecteur qui n'existe pas, Systems Manager signale la conformité, car le document `AWS-ApplyDSCMofs` peut être traité complètement, ce qui signifie que l'association s'exécute avec succès.
# Création d’associations exécutant des playbooks Ansible
Vous pouvez créer des associations State Manager qui exécutent des playbooks Ansible à l’aide du document SSM `AWS-ApplyAnsiblePlaybooks`. State Manager est un outil d’ AWS Systems Manager. Ce document offre les avantages suivants pour l'exécution de manuels stratégiques :
+ Prise en charge de l'exécution de manuels stratégiques complexes
+ Prise en charge du téléchargement de playbooks à partir de GitHub et d’Amazon Simple Storage Service (Amazon S3)
+ Prise en charge de la structure de manuel stratégique compressé
+ Journalisation améliorée
+ Possibilité de spécifier le manuel stratégique à exécuter lorsque les manuels stratégiques sont regroupés
**Note**
Systems Manager inclut deux documents SSM qui vous permettent de créer des associations State Manager exécutant des playbooks Ansible : `AWS-RunAnsiblePlaybook` et `AWS-ApplyAnsiblePlaybooks`. Le document `AWS-RunAnsiblePlaybook` est obsolète. Il reste disponible dans Systems Manager à des fins de conservation. Nous vous recommandons d'utiliser le document `AWS-ApplyAnsiblePlaybooks` en raison des améliorations décrites ici.
Les associations exécutant des playbooks Ansible ne sont pas prises en charge sur macOS.
**Prise en charge de l'exécution de manuels stratégiques complexes**
Le document `AWS-ApplyAnsiblePlaybooks` prend en charge les manuels stratégiques complexes et groupés, car il copie toute la structure de fichiers dans un répertoire local avant d'exécuter le manuel stratégique principal spécifié. Vous pouvez fournir des manuels stratégiques source dans des fichiers Zip ou dans une structure de répertoires. Le fichier .zip ou le répertoire peut être stocké dans GitHub ou Amazon S3.
**Prise en charge du téléchargement de manuels stratégiques à partir de GitHub**
Le document `AWS-ApplyAnsiblePlaybooks` utilise le plug-in `aws:downloadContent` pour télécharger les fichiers du manuel stratégique. Les fichiers peuvent être stockés dans GitHub dans un fichier unique ou sous la forme d’un ensemble combiné de fichiers de playbook. Pour télécharger du contenu à partir de GitHub, spécifiez les informations relatives à votre référentiel GitHub au format JSON. Voici un exemple.
```
{
"owner":"TestUser",
"repository":"GitHubTest",
"path":"scripts/python/test-script",
"getOptions":"branch:master",
"tokenInfo":"{{ssm-secure:secure-string-token}}"
}
```
**Prise en charge du téléchargement de playbooks à partir d'Amazon S3**
Vous pouvez également stocker et télécharger les playbooks Ansible dans Amazon S3 sous la forme d’un fichier .zip unique ou d’une structure de répertoires. Pour télécharger du contenu depuis Amazon S3, vous devez spécifier le chemin d'accès au fichier. Voici deux exemples :
**Exemple 1 : Télécharger un fichier de manuel stratégique spécifique**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml"
}
```
**Exemple 2 : Télécharger le contenu d'un répertoire**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/ansible/webservers/"
}
```
**Important**
Si vous spécifiez Amazon S3, le profil d'instance Gestion des identités et des accès AWS (IAM) sur vos nœuds gérés doit inclure les autorisations pour le compartiment S3. Pour plus d’informations, consultez la section [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
**Prise en charge de la structure de manuel stratégique compressé**
Le document `AWS-ApplyAnsiblePlaybooks` vous permet d'exécuter des fichiers .zip compressés dans le bundle téléchargé. Le document vérifie si les fichiers téléchargés contiennent un fichier compressé au format .zip. Si un fichier .zip est trouvé, le document décompresse automatiquement le fichier, puis exécute l’automatisation Ansible spécifiée.
**Journalisation améliorée**
Le document `AWS-ApplyAnsiblePlaybooks` inclut un paramètre facultatif pour spécifier différents niveaux de journalisation. Spécifiez -v pour une journalisation avec un niveau de détail faible, -vv ou -vvv pour une journalisation avec un niveau de détail moyen et -vvvv pour une journalisation avec u niveau de débogage. Ces options mappent directement sur les options de niveau de détail Ansible.
**Possibilité de spécifier le manuel stratégique à exécuter lorsque les manuels stratégiques sont regroupés**
Le document `AWS-ApplyAnsiblePlaybooks` inclut un paramètre obligatoire pour spécifier le manuel stratégique à exécuter lorsque plusieurs manuels sont regroupés. Cette option offre une flexibilité pour exécuter des manuels stratégiques afin de prendre en charge différents cas d'utilisation.
## Comprendre les dépendances installées
Si vous spécifiez **True** pour le **InstallDependencies**paramètre, Systems Manager vérifie que les dépendances suivantes sont installées sur vos nœuds :
+ **Ubuntu Server/Debian Server** : Apt-get (gestion de package), Python 3, Ansible, Unzip
+ Versions prises en charge d’**Amazon Linux** : Ansible
+ **RHEL** : Python 3, Ansible, Unzip
Si une ou plusieurs de ces dépendances sont introuvables, Systems Manager les installe automatiquement.
## Création d’une association exécutant des playbooks Ansible (console)
La procédure suivante décrit comment utiliser la console Systems Manager pour créer une association State Manager qui exécute les playbooks Ansible à l’aide du document `AWS-ApplyAnsiblePlaybooks`.
**Pour créer une association qui exécute les playbooks Ansible (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 **State Manager**.
1. Sélectionnez **State Manager**, puis **Create association (Créer une association)**.
1. Pour **Name (Nom)**, spécifiez un nom qui vous aide à mémoriser l'objectif de l'association.
1. Dans la liste **Document**, sélectionnez **`AWS-ApplyAnsiblePlaybooks`**.
1. Dans la section **Paramètres**, pour **Type de source**, choisissez **S3 **GitHub**ou S3**.
**GitHub**
Si vous sélectionnez **GitHub**, saisissez les informations de référentiel au format suivant.
```
{
"owner":"user_name",
"repository":"name",
"path":"path_to_directory_or_playbook_to_download",
"getOptions":"branch:branch_name",
"tokenInfo":"{{(Optional)_token_information}}"
}
```
**S3**
Si vous sélectionnez **S3**, saisissez les informations de chemin au format suivant.
```
{
"path":"https://s3.amazonaws.com/path_to_directory_or_playbook_to_download"
}
```
1. Pour **Install Dependencies (Installer des dépendances)**, sélectionnez une option.
1. (Facultatif) Pour **Playbook File (Fichier de manuel stratégique)**, entrez un nom de fichier. Si le playbook est contenu dans un fichier .zip, spécifiez un chemin d'accès relatif au fichier .zip.
1. (Facultatif) Pour **Variables supplémentaires**, entrez les variables que vous souhaitez que State Manager envoie à Ansible lors de l’exécution.
1. (Facultatif) Pour **Check (Vérifier)**, sélectionnez une option.
1. (Facultatif) Pour **Verbose (Détails)**, sélectionnez une option.
1. Pour **Targets (Cibles)**, sélectionnez une option. Pour plus d'informations sur l'utilisation des cibles, 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. Dans la section **Specify schedule (Spécifier une planification)**, sélectionnez **On Schedule (Selon planification)** ou **No schedule (Pas de planification)**. Si vous sélectionnez **On Schedule (Selon planification)**, utilisez les boutons fournis pour créer une planification de type cron ou rate pour l'association.
1. Dans la section **Advanced options (Options avancées)**, pour **Compliance severity (Sévérité de conformité)**, sélectionnez un niveau de sévérité pour l'association. Les rapports de conformité indiquent si l'état de l'association est conforme ou non conforme, ainsi que le niveau de sévérité que vous spécifiez ici. Pour de plus amples informations, veuillez consulter [A propos de la conformité des associations State Manager](compliance-about.md#compliance-about-association).
1. Dans la section **Rate control** (Contrôle du débit), configurez des options pour l'exécution d'associations State Manager dans un parc de nœuds gérés. Pour plus d'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).
Dans la section **Simultanéité**, sélectionnez une option :
+ Sélectionnez **targets (cibles)** pour entrer un nombre absolu de cibles pouvant exécuter l'association simultanément.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage de l'ensemble de cibles pouvant exécuter l'association simultanément.
Dans la section **Error threshold (Seuil d'erreurs)**, sélectionnez une option :
+ Sélectionnez **errors (erreurs)** pour saisir un nombre absolu d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
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)**.
**Note**
Si vous utilisez des identifications pour créer une association sur un ou plusieurs nœuds cibles, puis que vous supprimez les identifications d'un nœud, ce nœud n'exécute plus l'association. Le nœud est dissocié du document State Manager.
## Création d’une association exécutant les playbooks Ansible (interface de ligne de commande)
La procédure suivante décrit comment utiliser le AWS Command Line Interface (AWS CLI) pour créer une State Manager association qui exécute des Ansible playbooks à l'aide du `AWS-ApplyAnsiblePlaybooks` document.
**Pour créer une association qui exécute les playbooks Ansible (interface de ligne de commande)**
1. 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).
1. Exécutez l’une des commandes suivantes pour créer une association qui exécute des playbooks Ansible en ciblant des nœuds à l’aide de balises. Remplacez chaque *example resource placeholder* par vos propres informations. La commande (A) spécifie GitHub comme type de source. La commande (B) spécifie Amazon S3 comme type de source.
**(A) GitHub source**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"],"TimeoutSeconds":["3600"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"], "TimeoutSeconds":["3600"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Voici un exemple.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ansibleDocumentTest\", \"repository\": \"Ansible\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True"],"PlaybookFile":["hello-world-playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**Source S3 (B)**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Voici un exemple.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml\"}"],"InstallDependencies":["True"],"PlaybookFile":["playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**Note**
Les associations State Manager ne prennent pas en charge toutes les expressions cron et rate. Pour plus d'informations sur la création d'expressions cron et rate pour des associations, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
Le système tente de créer l'association sur les nœuds et applique immédiatement l'état.
1. Exécutez la commande suivante pour afficher le statut mis à jour de l'association que vous venez de créer.
```
aws ssm describe-association --association-id "ID"
```
# Création d’associations qui exécutent des recettes Chef
Vous pouvez créer des associations State Manager qui exécutent des recettes Chef à l’aide du document SSM `AWS-ApplyChefRecipes`. State Manager est un outil d’ AWS Systems Manager. Vous pouvez cibler des nœuds gérés par Systems Manager basés sur Linux avec le document SSM `AWS-ApplyChefRecipes`. Ce document offre les avantages suivants pour l’exécution de recettes Chef :
+ Il prend en charge plusieurs versions de Chef (de Chef 11 à Chef 18).
+ Il installe automatiquement le logiciel client Chef sur les nœuds cibles.
+ Il exécute éventuellement des [contrôles de conformité Systems Manager](systems-manager-compliance.md) sur les nœuds cibles et stocke les résultats des contrôles de conformité dans un compartiment Amazon Simple Storage Service (Amazon S3).
+ Il exécute plusieurs livres de cuisine et recettes en une seule fois du document.
+ Il peut exécuter des recettes en mode `why-run`, pour afficher lesquelles changeront sur les nœuds cibles sans y apporter de modifications.
+ Il peut appliquer des attributs JSON personnalisés aux exécutions `chef-client`.
+ Applique éventuellement des attributs JSON personnalisés à partir d'un fichier source stocké à l'emplacement spécifié.
Vous pouvez utiliser des compartiments [Git](#state-manager-chef-git), [GitHub](#state-manager-chef-github), [HTTP](#state-manager-chef-http) ou [Amazon S3](#state-manager-chef-s3) comme sources de téléchargement pour les livres de recettes et les recettes Chef que vous spécifiez dans un document `AWS-ApplyChefRecipes`.
**Note**
Les associations exécutant des recettes Chef ne sont pas prises en charge sur macOS.
## Prise en main
Avant de créer un document `AWS-ApplyChefRecipes`, préparez votre référentiel de livres de recettes et de recettes Chef. Si vous n'avez pas encore de Chef livre de recettes que vous souhaitez utiliser, vous pouvez commencer par utiliser un `HelloWorld` livre de recettes de test préparé pour vous. AWS Le document `AWS-ApplyChefRecipes` pointe déjà vers ce livre de recettes par défaut. Vos livres de recettes doivent être configurés de la même manière que la structure de répertoire suivante. Dans l’exemple suivant, `jenkins` et `nginx` sont des exemples de livres de recettes Chef disponibles dans le [https://supermarket.chef.io/](https://supermarket.chef.io/) sur le site Web de Chef.
Bien que les livres de cuisine ne AWS puissent pas être officiellement pris en charge sur le [https://supermarket.chef.io/](https://supermarket.chef.io/)site Web, beaucoup d'entre eux fonctionnent avec le `AWS-ApplyChefRecipes` document. Voici des exemples de critères à déterminer lorsque vous testez un livre de recette de la communauté :
+ Le livre de recettes doit prendre en charge les systèmes d'exploitation basés sur Linux des nœuds gérés par Systems Manager que vous ciblez.
+ Le livre de recettes doit être valide pour la version client de Chef que vous utilisez (de Chef 11 à Chef 18).
+ Le livre de recettes est compatible avec Chef Infra Client et ne nécessite pas de serveur Chef.
Vérifiez que vous pouvez accéder au site web `Chef.io`, afin que tous les livres de recettes que vous spécifiez dans votre liste d’exécution puissent être installés lors de l’exécution du document Systems Manager (document SSM). L'utilisation d'un fichier `cookbooks` imbriqué est prise en charge, mais pas obligatoire ; vous pouvez stocker des livres de recettes directement dans le niveau racine.
```
└── cookbooks (optional level)
├── jenkins
│ ├── metadata.rb
│ └── recipes
└── nginx
├── metadata.rb
└── recipes
```
**Important**
Avant de créer une association State Manager qui exécute des recettes Chef, sachez que l’exécution du document installe le logiciel client Chef sur vos nœuds gérés Systems Manager, sauf si vous définissez la valeur de la **version du client Chef** sur `None`. Cette opération utilise un script d’installation de Chef pour installer les composants Chef en votre nom. Avant d’exécuter un document `AWS-ApplyChefRecipes`, assurez‑vous que votre entreprise peut se conformer à toutes les exigences légales en vigueur, y compris les conditions de licence applicables à l’utilisation du logiciel Chef. Pour plus d’informations, consultez le [site web Chef](https://www.chef.io/).
Systems Manager peut fournir des rapports de conformité à un compartiment S3, à la console Systems Manager ou rendre les résultats de conformité disponibles en réponse aux commandes d'API Systems Manager. Pour exécuter des rapports de conformité Systems Manager, le profil d'instance attaché aux nœuds gérés par Systems Manager doit disposer des autorisations d'écriture dans le compartiment S3. Le profil d'instance doit être autorisé à utiliser l'API Systems Manager `PutComplianceItem`. Pour de plus amples informations sur Systems Manager, consultez [Conformité d'AWS Systems Manager](systems-manager-compliance.md).
### Journalisation de l'exécution du document
Lorsque vous exécutez un document Systems Manager (document SSM) à l'aide d'une State Manager association, vous pouvez configurer l'association pour choisir la sortie du document à exécuter, et vous pouvez envoyer la sortie à Amazon S3 ou Amazon CloudWatch Logs (CloudWatch Logs). Pour faciliter le dépannage lorsqu'une association est terminée, vérifiez que l'association est configurée pour écrire la sortie de commande dans un compartiment Amazon S3 ou dans CloudWatch des journaux. Pour de plus amples informations, veuillez consulter [Utilisation d'associations dans Systems Manager](state-manager-associations.md).
## Appliquer des attributs JSON aux cibles lors de l'exécution d'une recette
Vous pouvez spécifier des attributs JSON que votre client Chef doit appliquer aux nœuds cibles lors de l’exécution d’une association. Lors de la configuration de l'association, vous pouvez fournir du code JSON brut ou indiquer le chemin d'accès à un fichier JSON stocké dans Amazon S3.
Utilisez les attributs JSON lorsque vous souhaitez personnaliser le mode d'exécution de la recette sans avoir à modifier la recette elle-même, par exemple :
+ **Remplacer un petit nombre d'attributs**
Utilisez JSON personnalisé pour éviter d'avoir à gérer plusieurs versions d'une recette pour tenir compte de différences mineures.
+ **Fournir des valeurs variables**
Utilisez le JSON personnalisé pour spécifier les valeurs susceptibles de changer par rapport à run-to-run. Par exemple, si vos livres de recettes Chef configurent une application tierce qui accepte les paiements, vous pouvez utiliser un JSON personnalisé pour spécifier l’URL du point de terminaison de paiement.
**Spécifier des attributs en JSON brut**
Voici un exemple du format que vous pouvez utiliser pour spécifier des attributs JSON personnalisés pour votre recette Chef.
```
{"filepath":"/tmp/example.txt", "content":"Hello, World!"}
```
**Spécifier un chemin d'accès à un fichier JSON**
Voici un exemple du format que vous pouvez utiliser pour spécifier le chemin d’accès aux attributs JSON personnalisés pour votre recette Chef.
```
{"sourceType":"s3", "sourceInfo":"someS3URL1"}, {"sourceType":"s3", "sourceInfo":"someS3URL2"}
```
## Utiliser Git comme source de livre de recettes
Le document `AWS-ApplyChefRecipes` utilise le plug‑in [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) pour télécharger les livres de recettes Chef. Pour télécharger du contenu à partir de Git, spécifiez les informations relatives à votre référentiel Git au format JSON, comme dans l'exemple suivant. Remplacez chaque *example-resource-placeholder* par vos propres informations.
```
{
"repository":"GitCookbookRepository",
"privateSSHKey":"{{ssm-secure:ssh-key-secure-string-parameter}}",
"skipHostKeyChecking":"false",
"getOptions":"branch:refs/head/main",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Utiliser GitHub comme source de livre de recettes
Le document `AWS-ApplyChefRecipes` utilise le plug‑in [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) pour télécharger les livres de recettes. Pour télécharger du contenu à partir de GitHub, spécifiez les informations relatives à votre référentiel GitHub au format JSON, comme dans l’exemple suivant. Remplacez chaque *example-resource-placeholder* par vos propres informations.
```
{
"owner":"TestUser",
"repository":"GitHubCookbookRepository",
"path":"cookbooks/HelloWorld",
"getOptions":"branch:refs/head/main",
"tokenInfo":"{{ssm-secure:token-secure-string-parameter}}"
}
```
## Utiliser HTTP comme source de livre de recettes
Vous pouvez stocker les livres de recettes Chef dans un emplacement HTTP personnalisé sous la forme d’un fichier individuel `.zip` ou `tar.gz`, ou d’une structure de répertoires. Pour télécharger du contenu depuis HTTP, spécifiez le chemin d'accès au fichier ou au répertoire au format JSON comme dans l'exemple suivant. Remplacez chaque *example-resource-placeholder* par vos propres informations.
```
{
"url":"https://my.website.com/chef-cookbooks/HelloWorld.zip",
"allowInsecureDownload":"false",
"authMethod":"Basic",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Utiliser Amazon S3 comme source de livre de recettes
Vous pouvez également stocker et télécharger des livres de recettes Chef dans Amazon S3 sous la forme d’un fichier individuel `.zip` ou `tar.gz`, ou d’une structure de répertoires. Pour télécharger du contenu depuis Amazon S3, spécifiez le chemin d'accès au fichier au format JSON comme dans les exemples suivants. Remplacez chaque *example-resource-placeholder* par vos propres informations.
**Exemple 1 : Télécharger un livre de recettes spécifique**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks/HelloWorld.zip"
}
```
**Exemple 2 : Télécharger le contenu d'un répertoire**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks-test/HelloWorld"
}
```
**Important**
Si vous spécifiez Amazon S3, le profil d'instance Gestion des identités et des accès AWS (IAM) sur vos nœuds gérés doit être configuré avec la `AmazonS3ReadOnlyAccess` politique. Pour plus d’informations, consultez la section [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
## Création d’une association qui exécute les recettes Chef (console)
La procédure suivante décrit comment utiliser la console Systems Manager pour créer une association State Manager qui exécute les livres de recettes Chef à l’aide du document `AWS-ApplyChefRecipes`.
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**.
1. Sélectionnez **State Manager**, puis **Create association (Créer une association)**.
1. Pour **Name (Nom)**, saisissez un nom qui vous aide à mémoriser l'objectif de l'association.
1. Dans la liste **Document**, sélectionnez **`AWS-ApplyChefRecipes`**.
1. Dans **Paramètres**, pour **Type de source**, sélectionnez **Git**, **GitHub**, **HTTP** ou **S3**.
1. Pour **Informations sur la source**, entrez les informations sur la source du livre de recettes en utilisant le format approprié pour le **Type de source** que vous avez sélectionné à l'étape 6. Pour plus d’informations, consultez les rubriques suivantes :
+ [Utiliser Git comme source de livre de recettes](#state-manager-chef-git)
+ [Utiliser GitHub comme source de livre de recettes](#state-manager-chef-github)
+ [Utiliser HTTP comme source de livre de recettes](#state-manager-chef-http)
+ [Utiliser Amazon S3 comme source de livre de recettes](#state-manager-chef-s3)
1. Dans la **Run list (Liste d'exécution)**, listez les recettes que vous souhaitez exécuter au format suivant, en séparant chaque recette par une virgule comme indiqué. N'ajoutez pas d'espace après la virgule. Remplacez chaque *example-resource-placeholder* par vos propres informations.
```
recipe[cookbook-name1::recipe-name],recipe[cookbook-name2::recipe-name]
```
1. (Facultatif) Spécifiez les attributs JSON personnalisés que vous souhaitez que le client Chef transmette à vos nœuds cibles.
1. Dans **Contenu des attributs JSON**, ajoutez tous les attributs que vous souhaitez que le client Chef transmette à vos nœuds cibles.
1. Dans **Sources d’attributs JSON**, ajoutez les chemins d’accès à tous les attributs que vous souhaitez que le client Chef transmette à vos nœuds cibles.
Pour de plus amples informations, veuillez consulter [Appliquer des attributs JSON aux cibles lors de l'exécution d'une recette](#apply-custom-json-attributes).
1. Pour **Version du client Chef**, spécifiez une version de Chef. Les valeurs valides vont de `11` à `18` ou `None`. Si vous spécifiez un nombre compris entre `11` et `18` (inclus), Systems Manager installe la version du client Chef correspondante sur vos nœuds cibles. Si vous spécifiez `None`, Systems Manager n’installe pas le client Chef sur les nœuds cibles avant d’exécuter les recettes du document.
1. (Facultatif) Pour **Arguments du client Chef**, spécifiez des arguments supplémentaires pris en charge pour la version de Chef que vous utilisez. Pour en savoir plus sur les arguments pris en charge, exécutez `chef-client -h` sur un nœud qui exécute le client Chef.
1. (Facultatif) Activez **Why-run** pour afficher les modifications qui seront apportées aux nœuds cibles si les recettes sont exécutées, sans modifier réellement les nœuds cibles.
1. Pour **Compliance severity (Sévérité de conformité)**, sélectionnez la sévérité des résultats de conformité de la configuration Systems Manager que vous voulez rapportés. Les rapports de conformité indiquent si l'état de l'association est conforme ou non conforme, ainsi que le niveau de sévérité que vous spécifiez. Les rapports de conformité de la configuration sont stockés dans un comp)artiment S3 que vous spécifiez comme valeur du paramètre de **Compliance report bucket (Compartiment de rapport de conformité** (étape 14). Pour de plus amples informations sur la conformité, consultez [En savoir plus sur la conformité](compliance-about.md) dans ce guide.
Les analyses de conformité mesurent la dérive entre la configuration spécifiée dans vos recettes Chef et les ressources de nœud. Les valeurs valables sont `Critical`, `High`, `Medium`, `Low` `Informational` `Unspecified` ou `None`. Pour ignorer les rapports de conformité, sélectionnez `None`.
1. Pour **Compliance type (Type de conformité)**, spécifiez le type de conformité pour lequel vous souhaitez que les résultats soient rapportés. Les valeurs valides `Association` concernent State Manager les associations ou `Custom:`*custom-type*. La valeur par défaut est `Custom:Chef`.
1. Pour **Compartiment de rapport de conformité**, saisissez le nom d’un compartiment S3 dans lequel stocker des informations sur chaque Chef exécuté par ce document, y compris la configuration des ressources et les résultats de conformité.
1. Dans **Rate control** (Contrôle du débit), configurez des options pour l'exécution d'associations State Manager dans un parc de nœuds gérés. Pour plus d'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).
Dans **Concurrency (Simultanéité)**, sélectionnez une option :
+ Sélectionnez **targets (cibles)** pour entrer un nombre absolu de cibles pouvant exécuter l'association simultanément.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage de l'ensemble de cibles pouvant exécuter l'association simultanément.
Dans **Error threshold (Seuil d'erreur)**, sélectionnez une option :
+ Sélectionnez **errors (erreurs)** pour saisir un nombre absolu d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
+ Sélectionnez **percentage (pourcentage)** pour saisir un pourcentage d'erreurs autorisées avant que State Manager ne cesse d'exécuter des associations sur des cibles supplémentaires.
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)**.
## Création d’une association qui exécute des recettes Chef (CLI)
La procédure suivante décrit comment utiliser le AWS Command Line Interface (AWS CLI) pour créer une State Manager association qui exécute les livres de recettes Chef à l'aide du `AWS-ApplyChefRecipes` document.
1. 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).
1. Exécutez l’une des commandes suivantes pour créer une association qui exécute des livres de recettes Chef sur les nœuds cibles disposant des balises spécifiées. Utilisez la commande adaptée au type de source de votre livre de cuisine et à votre système d'exploitation. Remplacez chaque *example-resource-placeholder* par vos propres informations.
1. **Source Git**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **GitHub source**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
Voici un exemple.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:OS,Values=Linux \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "MyChefAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:OS,Values=Linux ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "MyChefAssociation" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
1. **Source HTTP**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **Source Amazon S3**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
Voici un exemple.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets "Key=tag:OS,Values= Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "name" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets "Key=tag:OS,Values= Linux" ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "name" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Le système crée l'association et, à moins que votre expression cron ou rate spécifiée ne l'empêche, le système exécute l'association sur les nœuds cibles.
**Note**
Les associations State Manager ne prennent pas en charge toutes les expressions cron et rate. Pour plus d'informations sur la création d'expressions cron et rate pour des associations, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
1. Exécutez la commande suivante pour afficher le statut de l'association que vous venez de créer.
```
aws ssm describe-association --association-id "ID"
```
## Affichage des détails de conformité des ressources Chef
Systems Manager capture les informations de conformité sur les ressources gérées par Chef dans la valeur de **compartiment de rapport de conformité** Amazon S3 que vous avez spécifiées lors de l’exécution du document `AWS-ApplyChefRecipes`. La recherche d’informations sur les défaillances de ressources Chef dans un compartiment S3 peut prendre un certain temps. Au lieu de cela, vous pouvez consulter ces informations sur la page **Compliance (Conformité)** de Systems Manager.
Une analyse de conformité Systems Manager collecte des informations sur les ressources de vos nœuds gérés qui ont été créées ou vérifiées lors de la dernière exécution de Chef. Les ressources peuvent inclure des fichiers, des répertoires, des services `systemd`, des packages `yum`, des fichiers modélisés, des packages `gem` et des livres de recettes dépendants, entre autres.
La section **Récapitulatif des ressources de conformité** affiche le nombre de ressources qui ont échoué. Dans l'exemple suivant, il **ComplianceType**s'agit de **Custom : Chef** et une ressource n'est pas conforme.
**Note**
`Custom:Chef`est la **ComplianceType**valeur par défaut du `AWS-ApplyChefRecipes` document. Cette valeur est personnalisable.
![\[Affichage de comptages dans la section Compliance resources summary (Récapitulatif des ressources de conformité) de la page Compliance (Conformité).\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-chef-compliance-summary.png)
La section **Présentation détaillée des ressources** contient des informations sur la AWS ressource qui n'est pas conforme. Cette section inclut également le type de ressource Chef sur lequel l’analyse de conformité a été exécutée, la sévérité du problème, le statut de conformité ainsi que des liens pour en savoir plus, le cas échéant.
![\[Affichage des détails de conformité pour une défaillance de ressource gérée par Chef\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/state-manager-chef-compliance-details.png)
Le lien **Afficher la sortie** affiche les 4 000 derniers caractères du statut détaillé. Systems Manager commence par l'exception comme premier élément, recherche les messages détaillés et les affiche jusqu'à ce qu'il atteigne le quota de 4 000 caractères. Ce processus affiche les messages de journal qui ont été générés avant que l'exception soit déclenchée, qui sont les plus pertinents pour la résolution.
Pour de plus amples informations sur la façon d'afficher les informations de conformité, consultez [Conformité d'AWS Systems Manager](systems-manager-compliance.md).
**Important**
Si l'association State Manager échoue, aucune donnée de conformité n'est présentée. Par exemple, si Systems Manager tente de télécharger un livre de recettes Chef à partir d’un compartiment S3 auquel le nœud n’est pas autorisé à accéder, l’association échoue et aucune donnée de conformité n’est rapportée par Systems Manager.
# Procédure pas à pas : mise à jour automatique SSM Agent avec AWS CLI
La procédure suivante vous guide au cours du processus de création d'une association State Manager à l'aide de l' AWS Command Line Interface. L'association met automatiquement à jour SSM Agent selon une planification que vous spécifiez. Pour plus d'informations sur SSM Agent, consultez [Utilisation de l’option SSM Agent](ssm-agent.md). Pour personnaliser le calendrier des mises à jour pour SSM Agent en utilisant la console, consultez [Mise à jour automatique de l'SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
Pour recevoir des notifications concernant les mises à jour de SSM Agent, inscrivez‑vous sur la page [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/master/RELEASENOTES.md) du site Web de GitHub.
**Avant de commencer**
Avant de réaliser la procédure suivante, veillez à avoir au moins une instance Amazon Elastic Compute Cloud (Amazon EC2) en cours d'exécution pour Linux, macOS ou Windows Server configurée pour Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
Si vous créez une association en utilisant le AWS CLI ou AWS Tools for Windows PowerShell, utilisez le `--Targets` paramètre pour cibler les instances, comme illustré dans l'exemple suivant. N'utilisez pas le paramètre `--InstanceID`. Le paramètre `--InstanceID` est un paramètre hérité.
**Pour créer une association afin de mettre à jour automatiquement SSM Agent**
1. 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).
1. Exécutez la commande suivante pour créer une association en ciblant les instances avec des balises Amazon Elastic Compute Cloud (Amazon EC2). Remplacez chaque *example resource placeholder* par vos propres informations. Le paramètre `Schedule` définit une planification pour exécuter l'association tous les dimanches matin à 2 h 00 (UTC).
Les associations State Manager ne prennent pas en charge toutes les expressions cron et rate. Pour plus d'informations sur la création d'expressions cron et rate pour des associations, consultez [Référence : Expressions Cron et Rate pour Systems Manager](reference-cron-and-rate-expressions.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=tag:tag_key,Values=tag_value \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=tag:tag_key,Values=tag_value ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Vous pouvez cibler plusieurs instances en les spécifiant IDs dans une liste séparée par des virgules.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Vous pouvez spécifier la version de l'SSM Agent à laquelle vous voulez faire la mise à jour.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)" \
--parameters version=ssm_agent_version_number
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--parameters version=ssm_agent_version_number
```
------
Le système retourne des informations telles que les suivantes.
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 2 ? * SUN *)",
"Name": "AWS-UpdateSSMAgent",
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "123..............",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1504034257.98,
"Date": 1504034257.98,
"AssociationVersion": "1",
"Targets": [
{
"Values": [
"TagValue"
],
"Key": "tag:TagKey"
}
]
}
}
```
Le système tente de créer l'association sur les instances et applique l'état la création d'état suivante. Le statut de l'association indique `Pending`.
1. Exécutez la commande suivante pour afficher le statut mis à jour de l'association que vous avez créé.
```
aws ssm list-associations
```
Si vos instances *n'exécutent pas* la version la plus récente de SSM Agent pour l'instant, l'état indique `Failed`. Lors de la publication d'une nouvelle version d'SSM Agent, l'association installe automatiquement le nouvel agent et le statut indique `Success`.
# Guide détaillé : mise à jour automatique des pilotes PV sur les instances EC2 pour Windows Server
Les Amazon Machine Images Windows Server (AMIs) contiennent un jeu de pilotes permettant d’accéder au matériel virtualisé. Ces pilotes sont utilisés par Amazon Elastic Compute Cloud (Amazon EC2) pour mapper les volumes de stockage d'instance et Amazon Elastic Block Store (Amazon EBS) à leurs périphériques. Nous vous recommandons d'installer les derniers pilotes pour améliorer la stabilité et les performances des instances EC2 pour Windows Server. Pour plus d'informations sur les pilotes PV, consultez [Pilotes PV AWS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/xen-drivers-overview.html#xen-driver-awspv).
La procédure pas à pas suivante explique comment configurer une State Manager association pour télécharger et installer automatiquement de nouveaux pilotes AWS PV lorsque les pilotes sont disponibles. State Managerest un outil dans AWS Systems Manager.
**Avant de commencer**
Avant d'exécuter la procédure suivante, veillez à avoir au moins une instance Amazon EC2 pour Windows Server en cours d'exécution et configurée pour Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de nœuds gérés pour AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Pour créer une association State Manager qui met automatiquement à jour les pilotes PV**
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**.
1. Sélectionnez **Créer une association**.
1. In the **Name** field, enter a descriptive name for the association.
1. Dans la liste **Document**, sélectionnez `AWS-ConfigureAWSPackage`.
1. Dans la section **Paramètres**, procédez comme suit :
+ Pour **Actions**, sélectionnez **Installer**.
+ Pour **Installation type (Type d’installation)**, sélectionnez **Uninstall and reinstall (Désinstaller et réinstaller)**.
**Note**
Les mises à niveau sur place ne sont pas prises en charge pour ce package. Il doit être désinstallé et réinstallé.
+ Pour **Nom**, saisissez **AWSPVDriver**.
Il n’est pas nécessaire de saisir une valeur pour **Version** et **Arguments supplémentaires**.
1. Dans la section **Targets (Cibles)**, sélectionnez les nœuds gérés sur lesquels vous souhaitez exécuter cette opération en spécifiant des balises, en sélectionnant des instances ou des appareils de périphérie manuellement ou en spécifiant un groupe de ressources.
**Astuce**
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.
**Note**
Si vous choisissez de cibler les instances à l’aide de balises, et que vous spécifiez des balises qui correspondent à des instances Linux, l’association réussit sur l’instance Windows Server, mais échoue sur les instances Linux. Le statut global de l’association indique **Failed**.
1. Dans **Spécifier le programme**, choisissez d’exécuter l’association selon un programme que vous configurez ou une seule fois. Comme des pilotes PV mis à jour sont seulement publiés quelques fois par an, vous pouvez planifier l'association pour qu'elle s'exécute une fois par mois, si vous le désirez.
1. Dans **Options avancées**, pour **Gravité de conformité**, choisissez un niveau de gravité pour l’association. Les rapports de conformité indiquent si l'état de l'association est conforme ou non conforme, ainsi que le niveau de sévérité que vous spécifiez ici. Pour de plus amples informations, veuillez consulter [A propos de la conformité des associations State Manager](compliance-about.md#compliance-about-association).
1. Pour **Rate control (Contrôle de débit)** :
+ Dans **Concurrency (Simultanéité)**, spécifiez un nombre ou un pourcentage de nœuds gérés sur lesquels exécuter simultanément la commande.
**Note**
Si vous avez sélectionné des cibles en spécifiant des balises appliquées aux nœuds gérés ou en spécifiant AWS des groupes de ressources, et que vous n'êtes pas certain du nombre de nœuds gérés ciblés, limitez le nombre de cibles pouvant exécuter le document en même temps en spécifiant un pourcentage.
+ Dans **Error threshold (Seuil d'erreur)**, indiquez quand arrêter l'exécution de la commande sur les autres nœuds gérés après l'échec de celle-ci sur un certain nombre ou un certain pourcentage de nœuds. Si, par exemple, vous spécifiez trois erreurs, Systems Manager cesse d'envoyer la commande à la réception de la quatrième erreur. Les nœuds gérés sur lesquels la commande est toujours en cours de traitement peuvent également envoyer des erreurs.
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. (Facultatif) Dans la section **CloudWatch Alarme**, pour **Nom de l'alarme**, choisissez une CloudWatch alarme à appliquer à votre association à des fins de surveillance.
**Note**
Notez les informations suivantes concernant ce passage.
La liste des alarmes affiche 100 alarmes maximum. Si votre alarme ne figure pas dans la liste, utilisez le AWS Command Line Interface pour créer l'association. Pour de plus amples informations, veuillez consulter [Créer une association (ligne de commande)](state-manager-associations-creating.md#create-state-manager-association-commandline).
Pour associer une CloudWatch alarme à votre commande, le principal IAM qui crée l'association doit être autorisé à effectuer l'`iam:createServiceLinkedRole`action. Pour plus d'informations sur les CloudWatch alarmes, consultez la section [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Si votre alarme se déclenche, toute invocation ou automatisme de commande en attente ne s’exécute pas.
1. Sélectionnez **Create association (Créer une association)**, puis **Close (Fermer)**. Le système tente de créer l'association sur les instances et applique immédiatement l'état.
Si vous avez créé l'association sur une ou plusieurs instances Amazon EC2 pour Windows Server, le statut se change en **Success** (Succès). Si vos instances ne sont pas correctement configurées pour Systems Manager ou si vous avez malencontreusement ciblé des instances Linux, le statut indique **Failed (Échec)**.
Si le statut est **Failed** (Échec), sélectionnez l'ID de l'association, puis l'onglet **Resources** (Ressources) et vérifiez que l'association a été correctement créée sur vos instances EC2 pour Windows Server. Si les instances EC2 Windows Server affichent le statut **Failed**, vérifiez qu'elles SSM Agent sont en cours d'exécution sur l'instance et vérifiez que l'instance est configurée avec un rôle Gestion des identités et des accès AWS (IAM) pour Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).