• 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.
# Exécution de tâches de gestion des nœuds avec AWS Systems Manager
Exécuter des tâches de gestion des nœuds
Les rubriques suivantes décrivent comment effectuer des tâches de nœud courantes à l'aide de la AWS Systems Manager console unifiée pour une AWS Organizations organisation et un individu Comptes AWS.
**Topics**
+ [
# Analyse des informations sur les nœuds
](review-node-insights.md)
+ [
# Exploration des nœuds
](view-aggregated-node-details.md)
+ [
# Just-in-time accès aux nœuds à l'aide de Systems Manager
](systems-manager-just-in-time-node-access.md)
+ [
# Diagnostiquer et remédier
](diagnose-and-remediate.md)
+ [
# Réglage des paramètres de Systems Manager
](settings-overview.md)
# Analyse des informations sur les nœuds
Vous pouvez obtenir des informations sur l'état général des nœuds gérés et des EC2 instances non gérées de votre organisation ou de votre compte en utilisant la console unifiée Systems Manager.
Systems Manager fournit un aperçu visuel de vos nœuds et EC2 instances gérés qui ne sont pas encore gérés par 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). Pour plus d’informations sur les types de machines pris en charge, voir [Types de machines pris en charge dans les environnements hybrides et multicloud](operating-systems-and-machine-types.md#supported-machine-types)).
Cette vue d’ensemble est fournie par le biais de boîtes de rapport individuelles, appelées *widget*, qui présentent des diagrammes circulaires interactifs et d’autres graphiques.
**Avant de commencer**
Afin d’examiner les informations sur les nœuds, vous devez d’abord intégrer votre organisation ou votre compte à la console unifiée Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de AWS Systems Manager](systems-manager-setting-up-console.md).
Après l’intégration, ouvrez la [console Systems Manager](https://console.aws.amazon.com/systems-manager/explorer) et sélectionnez **Examiner les informations sur les nœuds**.
L’image suivante montre certaines boîtes de rapport individuelles, appelées *widget*, qui sont disponibles sur la page **Examiner les informations sur les nœuds**.
![\[Les données sur les nœuds sont affichées sur la page Examiner les informations sur les nœuds de Systems Manager\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/SYS2-Dashboard-Nodes.png)
L’écran prend en charge les widgets qui fournissent les informations suivantes.
**Récapitulatif des nœuds**
Indique combien d' EC2 instances de votre organisation ou de votre compte ne sont pas des nœuds gérés actuellement, et combien de nœuds gérés se trouvent dans le parc de votre organisation ou de votre compte.
**Qu’est-ce qu’une instance non gérée ?**
Lorsque vous arrêtez une EC2 instance gérée, elle est signalée comme « Non gérée » dans la console Systems Manager. Ce comportement est attendu, car SSM Agent n’a pas de connexion active au service.
Cela est différent de la façon dont une instance est AWS Config définie comme non gérée. Si une instance est actuellement arrêtée, AWS Config indique son état lors de la dernière connexion « heartbeat » établie entre l'instance et SSM Agent le service Systems Manager.
Lorsque l’instance redémarre, elle se reconnecte automatiquement au service Systems Manager, et son statut dans la console unifiée est rétabli sur « Gérée » dans les cinq minutes. Aucune intervention manuelle n'est requise et toutes les configurations de Systems Manager pour l'instance sont préservées pendant le Stop/Start cycle.
Toutefois, si l’instance n’est toujours pas signalée comme « gérée » plusieurs minutes après son démarrage, elle n’est probablement pas correctement configurée pour la gestion de Systems Manager. Dans ce cas, nous vous recommandons d’exécuter un diagnostic pour déterminer pourquoi l’instance reste dans un état non géré. Pour de plus amples informations, veuillez consulter [Diagnostiquer et corriger des instances Amazon EC2 non gérées dans Systems Manager](remediating-unmanaged-instances.md).
Si l'analyse diagnostique ne permet pas de déterminer le problème, consultez les rubriques suivantes pour SSM Agent vérifier que les exigences relatives aux rôles Gestion des identités et des accès AWS (IAM) et aux prérequis de Systems Manager sont toutes remplies :
+ [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md)
+ [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md)
+ [Résolution des problèmes de disponibilité des nœuds gérés](fleet-manager-troubleshooting-managed-nodes.md)
**Types de nœuds gérés**
Indique le nombre de nœuds gérés de votre parc qui sont des EC2 instances et combien sont d'autres types de serveurs, y compris les serveurs sur site (serveurs sur site), les appareils AWS IoT Greengrass principaux, AWS IoT les appareils non AWS périphériques et les machines virtuelles (VMs), y compris VMs dans d'autres environnements cloud. Vous pouvez survoler le graphique des **Types de nœuds** pour accéder à des liens vers plus de détails sur la page **Explorer les nœuds**.
Pour plus d'informations sur la AWS prise en charge des environnements hybrides et multicloud, consultez la section [AWS Solutions pour les environnements hybrides et multicloud](https://aws.amazon.com/hybrid-multicloud/).
**Versions SSM Agent**
Fournit des informations sur les installations d' AWS Systems Manager Agent (SSM Agent) dans votre flotte. SSM Agentest un logiciel Amazon qui s'exécute sur vos nœuds gérés. SSM Agentpermet à Systems Manager de mettre à jour, de gérer et de configurer ces ressources. L'agent traite les demandes du service Systems Manager dans le AWS Cloud, puis les exécute comme indiqué dans la demande.
Pour les nœuds gérés de votre flotte, ce widget indique les versions SSM Agent de votre flotte, de la plus récente à la plus ancienne. Vous pouvez survoler le graphique des **Versions SSM Agent** pour accéder à des liens vers plus de détails sur la page **Explorer les nœuds**.
Pour plus d’informations sur SSM Agent, consultez [Utilisation de l’option SSM Agent](ssm-agent.md).
**Systèmes d’exploitation de nœuds gérés**
Fournit une répartition du pourcentage de chaque système d’exploitation sur les nœuds gérés de votre flotte. Vous pouvez survoler le graphique des **Systèmes d’exploitation de nœuds gérés** pour accéder à des liens vers plus de détails sur la page **Explorer les nœuds**.
Vous pouvez personnaliser la disposition des widgets sur la page d'**informations du nœud de révision** en utilisant une drag-and-drop fonctionnalité, en supprimant et en ajoutant des widgets à l'affichage.
Utilisez les informations des rubriques suivantes pour travailler avec les widgets d’informations sur les nœuds de Systems Manager.
**Topics**
+ [
# Ajouter ou supprimer des widgets de la page **Examiner les informations des nœuds**
](review-node-insights-add-and-remove-widgets.md)
+ [
# Réorganisation des widgets dans la page **Examiner les informations sur les nœuds**
](review-node-insights-rearrange-widgets.md)
# Ajouter ou supprimer des widgets de la page **Examiner les informations des nœuds**
Ajouter ou supprimer des widgets
Vous pouvez personnaliser la mise en page sur la page **Examiner les informations des nœuds** de Systems Manager en ajoutant et en supprimant des widgets.
**Note**
Par défaut, la page affiche tous les widgets disponibles.
**Pour ajouter ou supprimer des widgets de la page **Examiner les informations des nœuds****
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 **Examiner les informations sur les nœuds**.
1. Pour supprimer un widget de l’affichage, procédez comme suit :
1. Choisissez le menu Plus d’options (![\[The More options menu\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/more-options-menu-widgets.png)) pour le widget.
1. Choisissez **Remove widget (Supprimer le widget)**.
1. Pour ajouter un widget à l’affichage, procédez comme suit :
1. Sélectionnez **Ajouter widgets**.
1. Dans le volet **Ajouter widgets**, cliquez et maintenez la poignée de déplacement (![\[The drag handle\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) du widget à ajouter à l’affichage.
1. Faites glisser le widget et déposez-le dans le volet principal.
# Réorganisation des widgets dans la page **Examiner les informations sur les nœuds**
Réorganisation des widgets
Vous pouvez personnaliser la mise en page de la page **Examiner les informations sur les nœuds** en réorganisant les widgets.
**Pour réorganiser les widgets dans la page **Examiner les informations sur les nœuds****
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 **Examiner les informations sur les nœuds**.
1. Pour personnaliser la mise en page du widget, sélectionnez un widget à déplacer. Cliquez et maintenez la poignée de déplacement (![\[The drag handle\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) du widget, puis faites-le glisser vers son nouvel emplacement.
1. Répétez ce processus pour chaque widget que vous souhaitez repositionner.
Si vous décidez que vous n’aimez pas la nouvelle disposition, sélectionnez **Réinitialiser à la mise en page par défaut** pour déplacer tous les widgets à leur emplacement d’origine.
# Exploration des nœuds
Exploration des nœuds
Vous pouvez utiliser la page **Explorer les nœuds** de Systems Manager pour consulter les détails des nœuds gérés dans votre organisation ou votre compte en fonction des critères que vous spécifiez dans les filtres. Vous pouvez également utiliser l’intégration de Systems Manager à Amazon Q Developer (Amazon Q), une solution d’IA générative AWS, pour effectuer des recherches à l’aide d’invites textuelles.
**Avant de commencer**
Afin de bénéficier de la fonctionnalité **Explorer les nœuds**, vous devez d’abord effectuer l’intégration de votre organisation ou de votre compte à la console unifiée Systems Manager. Pour de plus amples informations, consultez [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).
Après l’intégration, ouvrez la [console Systems Manager](https://console.aws.amazon.com/systems-manager/) et choisissez **Explorer les nœuds**.
**Note**
Si vous avez créé un index agrégateur pour l’Explorateur de ressources dans une région différente de votre région d’origine, Systems Manager rétrograde l’index actuel. Systems Manager fait ensuite la promotion de l’index local dans votre région d’origine en tant que nouvel index agrégateur. Pendant ce temps, seuls les nœuds de votre région d’origine sont affichés. Ce processus peut prendre jusqu’à 24 heures.
**Topics**
+ [
# Exploration des nœuds à l’aide des filtres de console
](view-aggregated-node-details-console.md)
+ [
# Exploration des nœuds à l’aide d’invites textuelles dans Amazon Q
](view-aggregated-node-details-Q.md)
+ [
# Afficher les détails d’un nœud individuel et prendre des mesures sur un nœud
](node-detail-actions.md)
+ [
# Téléchargement ou exportation d’un rapport sur un nœud géré
](explore-nodes-download-report.md)
+ [
# Gestion du contenu et de l’apparence des rapports sur les nœuds
](explore-nodes-manage-report-display.md)
# Exploration des nœuds à l’aide des filtres de console
Dans la console Systems Manager, vous pouvez ensuite regrouper vos nœuds gérés selon les vues suivantes :
------
#### [ All nodes (No filter) ]
Affiche la liste de tous les nœuds gérés dans votre organisation ou votre compte.
![\[Une liste des nœuds gérés dans la page Explorer les nœuds\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/2-explore-nodes-managed-nodes.png)
------
#### [ Node types ]
Fournit des onglets permettant d'afficher les données séparément pour les instances Amazon Elastic Compute Cloud (Amazon EC2) et les autres types de machines, y compris les serveurs sur site (serveurs sur site) AWS IoT Greengrass , les appareils principaux AWS IoT , les appareils non AWS périphériques et les machines virtuelles VMs (), VMs y compris dans d'autres environnements cloud.
![\[Liste les nœuds gérés sur des onglets de type de nœud\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/2-explore-nodes-node-types.png)
------
#### [ Operating systems ]
Fournit un onglet pour chaque type de système d’exploitation de votre organisation ou de votre compte, tel qu’**Amazon Linux** et **Microsoft Windows Server 2022 Datacenter**. Sur chaque onglet, vous pouvez filtrer davantage la liste en sélectionnant uniquement des versions spécifiques des systèmes d’exploitation, comme *Amazon Linux 2* et *Amazon Linux 2023* par exemple.
![\[Liste les nœuds gérés sur des onglets de système d’exploitation\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/2-explore-nodes-operating-system.png)
------
#### [ SSM Agent versions ]
Fournit un onglet pour chaque version de SSM Agent installée sur les nœuds gérés de votre flotte. Sur chaque onglet, vous pouvez filtrer davantage la liste en sélectionnant uniquement des systèmes d’exploitation spécifiques, tels qu’**Amazon Linux** et **Microsoft Windows Server 2022 Datacenter**.
![\[Liste les nœuds gérés sur des onglets d’agent\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/2-explore-nodes-agent-versions.png)
------
En outre, pour chacune de ces vues, vous pouvez affiner davantage la liste des nœuds répertoriés en choisissant de n’afficher que les nœuds correspondant à une certaine propriété, telle que le statut de nœud, l’ID d’ Compte AWS , l’ID d’unité organisationnelle, etc.
Vous pouvez personnaliser l’affichage du rapport en choisissant les colonnes de données disponibles à afficher dans la page **Explorer les nœuds**. Vous pouvez également télécharger des rapports au format `CSV` ou `JSON`, ou les exporter vers Amazon S3 au format `CSV`.
**Topics**
+ [
# Choix d’une vue de filtre pour les récapitulatifs des nœuds gérés
](explore-nodes-filter-view.md)
# Choix d’une vue de filtre pour les récapitulatifs des nœuds gérés
La page **Explorer les nœuds** de Systems Manager vous permet d’afficher des données agrégées sur votre flotte en fonction d’un certain nombre de vues de filtre disponibles.
**Pour choisir une vue de filtre pour les récapitulatifs des 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 **Explorer les nœuds**.
1. Pour **Filtrer la vue**, sélectionnez l’une des options de filtrage et affinez éventuellement le rapport :
+ **Nœuds gérés** – Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), vous pouvez sélectionner une propriété et un délimiteur, par exemple `Node type = Managed EC2 instances`.
+ **Systèmes d’exploitation** – Dans la liste **Filtrer les versions du système d’exploitation**, vous pouvez sélectionner un numéro de version du système d’exploitation. Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), vous pouvez sélectionner une propriété et un délimiteur, tel que `Node type = Managed EC2 instances`.
+ **Versions de SSM Agent** – Dans la liste **Filtrer les systèmes d’exploitation**, vous pouvez sélectionner un nom de système d’exploitation. Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), vous pouvez sélectionner une propriété et un délimiteur, tel que `Node type = Managed EC2 instances`.
+ **Types de nœuds** – Dans la liste **Filtrer les systèmes d’exploitation**, vous pouvez sélectionner un nom de système d’exploitation. Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), vous pouvez sélectionner une propriété et un délimiteur, tel que `Node type = Managed EC2 instances`.
Après avoir optionnellement filtré la liste, vous pouvez afficher les détails d’un nœud géré spécifique en choisissant son ID dans la colonne **ID de nœud**. À partir de cette vue détaillée, vous pouvez effectuer un certain nombre d’actions sur le nœud.
# Exploration des nœuds à l’aide d’invites textuelles dans Amazon Q
Grâce à l’intégration de Systems Manager à Amazon Q Developer, vous pouvez utiliser des invites textuelles pour consulter les informations créées par l’IA générative concernant vos nœuds gérés.
Amazon Q Developer est un assistant conversationnel génératif alimenté par l'IA qui peut vous aider à comprendre, créer, étendre et exploiter des applications. AWS Pour accélérer votre développement AWS, le modèle sur lequel repose Amazon Q est complété par AWS du contenu de haute qualité afin de produire des réponses plus complètes, exploitables et référencées. Pour plus d’informations, consultez la section [What is Amazon Q Developer?](https://docs.aws.amazon.com/amazonq/latest/aws-builder-use-ug/what-is.html) du *guide de l’utilisateur Amazon Q Developer*.
L'intégration entre Systems Manager et Amazon Q vous permet d'obtenir rapidement de la visibilité et du contrôle sur de vastes environnements distribués dans plusieurs Comptes AWS régions. Vous pouvez utiliser les requêtes en langage naturel pour rechercher les données des nœuds, identifier les problèmes et prendre des mesures plus rapidement.
Lorsque vous posez une question en langage naturel sur les nœuds gérés ou les instances gérées, Amazon Q utilise l’action `ListNodes` Systems Manager et crée des filtres basés sur votre saisie textuelle pour récupérer les résultats.
Par exemple, supposons que vous transmettiez à Amazon Q l’invite suivante :
**List my managed nodes running Red Hat Enterprise Linux 9.2**
Amazon Q détermine les filtres à inclure dans une demande, puis exécute une requête similaire à la suivante :
```
aws ssm list-nodes \
--filters Key=PlatformName,Values='Red Hat Enterprise Linux',Type=Equal Key=PlatformVersion,Values=9.2,Type=Equal
```
Amazon Q génère ensuite un rapport sur Red Hat Enterprise Linux les instances de votre compte, répertoriant des informations telles que le nombre d'instances IDs, leurs régions et leurs régions.
Vous pouvez également consulter un résumé JSON des détails de chaque instance et ouvrir un lien pour afficher la liste complète des instances EC2 ou des nœuds gérés sur la page **Explorer les nœuds** de Systems Manager. La page **Explorer les nœuds** affichent les résultats correspondant aux critères de filtre que vous avez inclus dans votre invite. À partir de là, vous pouvez modifier ou affiner les filtres pour votre demande, comme décrit dans la section [Exploration des nœuds](view-aggregated-node-details.md).
**Topics**
+ [
# Comment élaborer des invites efficaces pour interroger Amazon Q sur votre flotte
](view-aggregated-node-details-Q-prompts.md)
+ [
# Exploration des nœuds gérés en utilisant Amazon Q
](explore-managed-nodes-using-Q.md)
# Comment élaborer des invites efficaces pour interroger Amazon Q sur votre flotte
Plus la question ou l’invite que vous soumettez à Amazon Q est de qualité, meilleur est le résultat obtenu.
**Conseils pour les invites de requêtes**
Tenez compte des conseils suivants lorsque vous interrogez Amazon Q à propos de votre flotte :
1. Pour améliorer la précision de vos résultats, utilisez les termes « nœuds gérés » et « instances gérées » dans vos invites au lieu de simplement « nœuds » et « instances ».
1. Pour demander des résultats sur plusieurs comptes faisant partie d'une *organisation*, tels que configurés dans AWS Organizations, vous devez être connecté au compte d'administrateur délégué dans la région d'origine désignée.
1. Dans le compte d’administrateur délégué, utilisez des termes pour aider Amazon Q à comprendre que vous posez des questions sur les nœuds et les instances au sein de l’organisation en utilisant spécifiquement des termes tels que « dans mon organisation » ou « dans mon compte 123456789012 ».
**Topics**
+ [
## Exemples de questions pour Amazon Q
](#sample-questions-Q)
+ [
## Noms et versions des systèmes d’exploitation pris en charge pour les invites
](#supported-os-names-Q)
## Exemples de questions pour Amazon Q
Dans le tableau suivant, nous proposons des exemples de questions qui montrent comment créer des requêtes à Amazon Q afin d’obtenir de meilleurs résultats.
Nous fournissons également des exemples des filtres qu'Amazon Q appliquera lors de l'exécution de la [ListNodes](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListNodes.html)commande, qui sont générés à partir du contenu de votre invite.
| Exemple de question en langage naturel | Amazon Q a appliqué les filtres |
| --- | --- |
| Show me my Windows managed nodes. | PlatformType = Windows
|
| List my managed instances in account 123456789012. | AccountId = 123456789012
|
| Show me all managed nodes running Amazon Linux 2 across my organization. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| Show me all managed instances running Microsoft Windows Server 2019 Datacenter in my organization. | PlatformName = Microsoft Windows Server 2019 Datacenter
|
| Can you show me all managed nodes with SSM Agent version 3.3.1142.0? | AgentType = amazon-ssm-agent
AgentVersion = 3.3.1142.0
|
| List all Amazon Linux 2 managed instances in account 123456789012 that have SSM Agent version 3.3.1230.0. | PlatformName = Amazon Linux
PlatformVersion = 2
AccountId = 123456789012
AgentType = amazon-ssm-agent
AgentVersion = 3.3.1230.0
|
| What Microsoft Windows Server 2012 R2 Enterprise managed nodes are running in the eu-central-1 region across my entire organization? | PlatformName = Microsoft Windows Server 2012 R2 Enterprise
Region = eu-central-1
|
| Show me all managed instances running Red Hat Linux 7 in ou-d6ty-gxdma6vm. | PlatformName = RHEL Linux
PlatformVersion = 7
OrganizationalUnitId = ou-d6ty-gxdma6vm
|
| What Ubuntu managed instances are in account 123456789012? | PlatformName = Ubuntu
AccountId = 123456789012
|
| List my Linux managed instances. | PlatformType = Linux
|
| Find my macOS managed nodes. | PlatformType = macOS
|
| Show me all versions of Amazon Linux managed nodes in my org. | PlatformName = Amazon Linux
|
| List managed nodes running Amazon Linux 2. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| List the managed nodes with Ubuntu 16.04 in account 123456789012. | PlatformName = Ubuntu
PlatformVersion = 16.04
AccountId = 123456789012
|
| Find all managed nodes that have an SSM Agent version that is not 3.3.987.0. | AgentType = amazon-ssm-agent
AgentVersion != 3.3.987.0
|
| List all managed instances that are not running a Linux operating system. | PlatformType != Linux
|
## Noms et versions des systèmes d’exploitation pris en charge pour les invites
Lorsque vous interrogez Amazon Q concernant les nœuds gérés de votre compte, il est utile de fournir le nom d’un système d’exploitation tel qu’il est étiqueté dans Systems Manager. Vous pouvez également fournir des numéros de version pour affiner vos résultats. Par exemple, comme indiqué dans les tableaux suivants, vous pouvez demander des résultats portant spécifiquement sur **macOS 14.5**, **Microsoft Windows Server 2019 Datacenter** et **AlmaLinux 9.2 through 9.4**, pour ne citer que quelques exemples.
Ces listes peuvent ne pas être exhaustives et ne sont proposées qu’à titre d’exemple.
**macOS**
| Nom de la plateforme | Numéros de version |
| --- | --- |
| macOS | 13.2, 13.4, 13.7, 14.1, 14.5, 14.6.1, 15.0 |
**Windows**
| Versions | Numéros de version |
| --- | --- |
| Microsoft Windows Server 2012 R2 Datacenter | 6,3,9600 |
| Microsoft Windows Server 2012 R2 Standard | 6,3,9600 |
| Microsoft Windows Server 2012 Standard | 6,2,9200 |
| Microsoft Windows Server 2016 Datacenter | S/O |
| Microsoft Windows Server 2016 Standard | 10,0,14393 |
| Microsoft Windows Server 2019 Datacenter | S/O |
| Microsoft Windows Server 2019 Standard | S/O |
| Microsoft Windows Server 2022 Datacenter | S/O |
| Microsoft Windows Server 2022 Standard | 10,0.20348 |
**Linux**
| Noms des plateformes | Numéros de version |
| --- | --- |
| AlmaLinux | 8.10, 9.2, 9.3, 9.4 |
| Amazon Linux 2 | 2.0 et versions ultérieures |
| Amazon Linux 2023 | 2023.0.20230315.0 et versions ultérieures |
| BottleRocket | 1.14.3, 1.16.1, 1.18.0, 1.19.1, 1.19.2, 1.19.5, 1.20.0, 1.20.1, 1.20.2, 1.20.3, 1.20.5, 1.21.1, 1.23.0, 1.24.0, 1.24.1, 1.25.0, 1.26.1, |
| CentOS Stream | 9 |
| Debian GNU/Linux | 11-12 |
| Oracle Linux Server | 7.8, 8.2, 8.3, 8.8, 8.9, 8.10, 9.4 |
| Red Hat Enterprise Linux | 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9, 8.10, 9.2, 9.3, 9.4 |
| Serveur Red Hat Enterprise Linux | 17.3, 7.6, 7.7, 7.8, 7.9 |
| Rocky Linux | 8.6, 8.7, 8.8, 8.9, 8.10, 9.1, 9.2, 9.3, 9.4 |
| Ubuntu Server | 16.04, 18.04, 20.04, 22.04, 24.04 |
# Exploration des nœuds gérés en utilisant Amazon Q
L'intégration de Systems Manager à Amazon Q Developer vous permet de poser des questions sur les nœuds gérés de votre parc depuis n'importe quel AWS Management Console endroit où l'interface Amazon Q est disponible.
Pour plus d’informations sur l’interaction avec Amazon Q, consultez [Conversation avec Amazon Q Developer à propos d’ AWS](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html) dans le *Guide de l’utilisateur Amazon Q Developer*.
**Pour explorer les nœuds gérés en utilisant Amazon Q**
1. Où que vous soyez dans le AWS Management Console, choisissez l'icône Amazon Q (![\[The Amazon Q icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/q-icon-white.png)).
1. Dans le champ d’invite situé en bas du volet Amazon Q, posez une question sur les nœuds gérés dans votre compte ou votre organisation.
**Astuce**
Pour obtenir des conseils sur la création d’invites efficaces, consultez les informations dans [Comment élaborer des invites efficaces pour interroger Amazon Q sur votre flotte](view-aggregated-node-details-Q-prompts.md).
1. Examinez les informations relatives à des nœuds spécifiques ou choisissez **Ouvrir la console AWS Systems Manager ** pour poursuivre l’exploration.
# Afficher les détails d’un nœud individuel et prendre des mesures sur un nœud
À partir d’une liste dans la page **Explorer les nœuds** de Systems Manager, vous pouvez sélectionner un nœud individuel afin d’afficher des détails complets sur l’ordinateur ou d’effectuer une variété d’actions sur le nœud. La page **Général** de la page de détails présente des informations complètes sur le nœud.
**Pour afficher les détails d’un nœud individuel et effectuer une action sur celui-ci**
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 **Explorer les nœuds**.
1. (Facultatif) Suivez les étapes indiquées dans [Choix d’une vue de filtre pour les récapitulatifs des nœuds gérés](explore-nodes-filter-view.md) pour affiner la liste des nœuds gérés affichés pour votre organisation ou votre compte.
1. Dans la colonne **ID de nœud**, sélectionnez l’ID lié d’un nœud.
1. Pour afficher plus de détails sur le nœud, dans la navigation de gauche, dans la liste **Propriétés**, choisissez une propriété sur laquelle afficher plus d’informations :
+ **Balises** – Pour afficher la liste des balises appliquées au nœud. Vous pouvez également ajouter ou supprimer des balises.
+ **Inventaire** – Pour choisir un type d’inventaire, tel que **AWS:Application** ou **AWS:Network**, afin d’afficher les détails de l’inventaire pour le nœud.
+ **Associations** – Pour afficher les détails de toutes les associations State Manager appliquées au nœud, y compris des détails tels que le statut et le nom du document SSM associé.
+ **Correctifs** – Pour afficher des informations récapitulatives sur les correctifs et leur statut pour le nœud.
+ **Conformité de la configuration** – Pour afficher les détails de conformité du nœud, tels que le statut de conformité et la sévérité du problème de conformité.
Pour plus d’informations sur les détails des onglets, consultez [Qu’est-ce que la console unifiée ?](systems-manager-unified-console.md).
1. Pour effectuer des actions sur le nœud, utilisez les options suivantes du menu **Actions du nœud** :
**Note**
Ces actions ne sont disponibles que pour les nœuds gérés dans le Compte AWS et la région où vous travaillez actuellement. Pour les nœuds gérés auxquels vous pourriez avoir accès dans d’autres comptes ou régions, vous pouvez accéder à une liste **Propriétés**.
+ **Se connecter, démarrer une session de terminal** – Pour se connecter au nœud à l’aide de [AWS Systems Manager Session Manager](session-manager.md).
+ **Outils**
+ **Afficher le système de fichiers** – Pour parcourir le contenu de la structure de répertoires du nœud. Ajouter, renommer et supprimer des répertoires. Couper ou copier-coller des fichiers.
+ **Afficher les compteurs de performances** – Pour afficher des informations sur les performances du nœud, telles que l’utilisation de l’unité centrale, le trafic réseau et d’autres types d’utilisation.
+ **Processus gérés** – Pour afficher des informations sur l’utilisation des ressources sur le nœud. Démarrer ou arrêter des processus sur le nœud.
+ **Gérer les utilisateurs et les groupes** – Pour afficher, ajouter ou supprimer des comptes d’utilisateurs et des groupes d’utilisateurs sur le nœud.
+ **Exécuter la commande run** : [AWS Systems Manager Run Command](run-command.md) à utiliser pour gérer la configuration du nœud. Run Commandutilise [les documents Systems Manager](documents.md) pour effectuer des modifications à la demande, telles que la mise à jour d'applications ou l'exécution de scripts shell Linux et de PowerShell commandes Windows.
+ **Corriger les nœuds** – Utiliser la fonctionnalité **Corriger maintenant** dans [AWS Systems Manager Patch Manager](patch-manager.md) pour exécuter une opération de correctifs à la demande sur le nœud à partir de la console.
**Note**
Les tâches précédentes peuvent également être lancées à partir du menu **Outils** dans la navigation de gauche.
+ **Paramètres du nœud**
+ **Ajouter des balises** – Appliquer des paires clé-valeur de balise supplémentaires au nœud.
+ **Réinitialiser le mot de passe de l’utilisateur du nœud** – Définir un nouveau mot de passe pour un utilisateur spécifié sur le nœud.
+ **Modifier le rôle IAM** – Modifier le rôle IAM associé au nœud. Créer un nouveau rôle IAM à associer au nœud.
# Téléchargement ou exportation d’un rapport sur un nœud géré
Vous pouvez utiliser la fonctionnalité **Explore nodes** de Systems Manager pour afficher des listes filtrées ou non filtrées de nœuds gérés pour votre AWS organisation ou votre compte dans la console Systems Manager. Pour les cas où vous voulez consulter les données hors ligne ou les traiter dans une autre application, vous pouvez enregistrer le rapport sous forme de fichier `CSV` ou `JSON`.
Selon la taille du rapport, vous êtes invité à télécharger le rapport sur votre ordinateur local ou à l’exporter vers un compartiment Amazon S3. Les rapports sont enregistrés dans des compartiments S3 au format `CSV` uniquement.
**Pour télécharger ou exporter un rapport sur un nœud géré**
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 **Explorer les nœuds**.
1. (Facultatif) Suivez les étapes indiquées dans [Choix d’une vue de filtre pour les récapitulatifs des nœuds gérés](explore-nodes-filter-view.md) pour affiner la liste des nœuds gérés affichés pour votre organisation ou votre compte.
1. Choisissez **Rapport** (![\[The download report icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/download-arrow-icon.png)).
1. Si la boîte de dialogue **Télécharger le rapport** s’affiche, procédez comme suit :
1. Pour **Nom du fichier**, saisissez un nom pour le fichier. Nous vous recommandons de spécifier un nom qui représente la portée du rapport, tel que `all-organization-nodes` ou `ec2-instances-out-of-date-agent`.
1. Pour **Colonnes incluses**, indiquez si vous souhaitez inclure des colonnes pour tous les détails de nœuds disponibles ou uniquement pour ceux que vous avez sélectionnés pour l’affichage actuel.
**Astuce**
Pour plus d’informations sur la gestion des colonnes dans l’affichage de votre rapport, consultez [Gestion du contenu et de l’apparence des rapports sur les nœuds](explore-nodes-manage-report-display.md).
1. Pour **Format de fichier**, sélectionnez **CSV** ou **JSON**, en fonction de l’utilisation que vous ferez du fichier.
1. Pour **En-tête de feuille de calcul**, pour inclure une ligne d’en-têtes de colonnes dans un fichier `CSV`, sélectionnez **Inclure une ligne de noms de colonnes**.
1. Choisissez **Téléchargement**.
Le rapport est enregistré à l’emplacement de téléchargement par défaut en fonction des paramètres de votre navigateur.
1. Si la boîte de dialogue **Exporter vers Amazon S3** s’affiche, procédez comme suit :
1. Pour **URI S3**, saisissez l’URI du compartiment vers lequel exporter le rapport.
**Astuce**
Pour afficher une liste de vos compartiments dans la console Amazon S3, sélectionnez **Afficher**. Pour effectuer une sélection dans une liste de compartiments S3 de votre compte, choisissez **Parcourir S3**.
1. Pour **Méthode d’autorisation**, spécifiez le rôle de service à utiliser pour fournir des autorisations pour l’exportation du rapport vers le compartiment.
Si vous choisissez de laisser Systems Manager créer le rôle pour vous, il fournit toutes les autorisations et instructions d’approbation nécessaires pour l’opération.
Si vous voulez utiliser ou créer votre propre rôle, celui-ci doit inclure les autorisations et les instructions d’approbation requises. Pour en savoir plus sur la création de ce rôle, consultez [Création d’un rôle de service personnalisé pour exporter des rapports de diagnostic vers S3](create-s3-export-role.md).
1. Sélectionnez **Soumettre**.
# Création d’un rôle de service personnalisé pour exporter des rapports de diagnostic vers S3
Lorsque vous consultez des listes filtrées ou non filtrées de nœuds gérés pour votre organisation ou compte AWS dans la page **Explorer les nœuds** de Systems Manager, vous pouvez exporter la liste sous forme de rapport vers un compartiment Amazon S3 en tant que fichier `CSV`.
Pour ce faire, vous devez spécifier un rôle de service avec les autorisations et la politique d’approbation nécessaires pour l’opération. Vous pouvez choisir que Systems Manager crée le rôle pour vous pendant le processus de téléchargement du rapport. Vous pouvez également créer vous-même le rôle et la politique requise.
**Pour créer un rôle de service personnalisé afin d’exporter des rapports de diagnostic vers S3**
1. Suivez les étapes de la section [Création de politiques en utilisant l’éditeur JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) dans le *Guide de l’utilisateur IAM*.
+ Utilisez ce qui suit pour le contenu de la politique, en veillant à le *placeholder values* remplacer par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketAcl",
"s3:ListBucket",
"s3:PutLifecycleConfiguration",
"s3:GetLifecycleConfiguration"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:ListNodes"
],
"Resource": "*"
}
]
}
```
------
+ Donnez un nom à la politique pour vous aider à la reconnaître facilement lors de l’étape suivante.
1. Suivez les étapes de la section [Création d’un rôle IAM en utilisant une politique d’approbation personnalisée (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) dans le *Guide de l’utilisateur IAM*.
+ Pour l'étape 4, entrez la politique de confiance suivante, en veillant à la *placeholder values* remplacer par vos propres informations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
1. Pour l’étape 10, choisissez **Étape 2 : ajouter des autorisations** et sélectionnez le nom de la politique que vous avez créée à l’étape précédente.
Après avoir créé le rôle, vous pouvez le sélectionner en suivant les étapes de [Téléchargement ou exportation d’un rapport sur un nœud géré](explore-nodes-download-report.md).
# Gestion du contenu et de l’apparence des rapports sur les nœuds
Vous pouvez utiliser la fonctionnalité **Explore nodes** de Systems Manager pour afficher des listes filtrées ou non filtrées de nœuds gérés pour votre AWS organisation ou votre compte dans la console Systems Manager. Vous pouvez choisir parmi plus d’une douzaine de champs à inclure dans vos listes de nœuds, tels que **ID de nœud**, **Nom du système d’exploitation**, **Région**, etc. Vous pouvez également réorganiser les colonnes de vos listes et rapports et modifier l’affichage de la liste dans la console.
**Pour gérer le contenu et l’apparence des rapports sur les nœuds**
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 **Explorer les nœuds**.
1. Dans la zone **Nœuds**, cliquez sur l’icône d’engrenage des préférences (![\[The preferences gear icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/preferences-icon.png)).
1. Dans la boîte de dialogue **Préférences**, procédez comme suit :
1. Pour **Taille de la page**, choisissez le nombre de lignes incluses dans chaque affichage de la console (**10**, **25** ou **50**).
1. Pour **Renvoyer le texte à la ligne**, cochez la case pour afficher tout le contenu d’une cellule dans la largeur de colonne disponible.
1. Pour **Lignes agrégées par bandes**, cochez la case pour afficher des lignes alternant des fonds clairs et des fonds ombrés.
1. Pour **Sélectionner le contenu visible**, procédez comme suit :
+ Activez ou désactivez des colonnes individuelles pour l’affichage de vos listes et vos rapports.
+ Pour modifier l’ordre des colonnes, cliquez sur la poignée de glissement (![\[The drag handle\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) d’un nom de colonne et maintenez-la enfoncée, puis faites-la glisser vers le haut ou vers le bas dans la liste.
1. Choisissez **Confirmer**.
# Just-in-time accès aux nœuds à l'aide de Systems Manager
Systems Manager vous aide à améliorer la sécurité de vos nœuds en facilitant *just-in-time*l'accès. Just-in-timel'accès aux nœuds permet aux utilisateurs de demander un accès temporaire limité dans le temps aux nœuds, que vous ne pouvez approuver que lorsque l'accès est réellement nécessaire. Il n'est donc plus nécessaire de fournir un accès permanent aux nœuds gérés par des politiques IAM. En outre, Systems Manager fournit un enregistrement de session pour les sessions RDP aux Windows Server nœuds afin de vous aider à répondre aux exigences de conformité, à effectuer une analyse des causes premières, etc. Pour utiliser l'accès aux just-in-time nœuds, vous devez configurer la console unifiée Systems Manager.
Avec l'accès aux just-in-time nœuds, vous créez des politiques IAM granulaires pour garantir que seuls les utilisateurs autorisés peuvent soumettre des demandes d'accès à vos nœuds. Vous créez ensuite des *politiques d’approbation* qui définissent les approbations requises pour vous connecter à vos nœuds. Pour l'accès aux just-in-time nœuds, il existe des politiques *d'approbation automatique* et des politiques *d'approbation manuelle*. Une politique d’approbation automatique définit les nœuds auxquels les utilisateurs peuvent se connecter automatiquement. Les politiques d’approbation manuelle définissent le nombre et les niveaux d’approbations manuelles qui doivent être fournis pour accéder aux nœuds que vous spécifiez. Vous pouvez également créer une politique de *refus d’accès*. Une politique de refus d’accès empêche explicitement l’approbation automatique des demandes d’accès aux nœuds que vous spécifiez. Une politique de refus d'accès s'applique à tous les comptes d'une AWS Organizations organisation. Les politiques d'approbation automatique et d'approbation manuelle s'appliquent uniquement au Régions AWS lieu Comptes AWS et à l'endroit où elles ont été créées.
Lorsqu’un utilisateur tente de se connecter à un nœud, il est invité à saisir le motif de son accès au nœud. Vos politiques d’approbation sont ensuite évaluées. Selon vos politiques, les utilisateurs se connectent automatiquement au nœud cible, ou Systems Manager crée automatiquement une demande d’approbation manuelle au nom du demandeur. Les approbateurs spécifiés dans la politique d’approbation manuelle qui s’applique au nœud sont ensuite informés de la demande d’accès et peuvent approuver ou refuser la demande. Les approbateurs et demandeurs peuvent être avertis par e-mail ou via Amazon Q Developer dans le cadre de l’intégration des applications de chat à Slack ou Microsoft Teams. Systems Manager n’accorde l’accès aux nœuds demandés que lorsque les approbateurs spécifiés fournissent toutes les approbations requises. Une fois que toutes les approbations requises ont été reçues, l’utilisateur peut démarrer autant de sessions sur le nœud que nécessaire pendant la durée de la fenêtre d’accès spécifiée dans la politique d’approbation. Systems Manager ne met pas automatiquement fin aux sessions d'accès aux just-in-time nœuds. Il est recommandé de spécifier des valeurs pour la *durée maximale de session* et les préférences de *délai d’inactivité des sessions*. Ces préférences empêchent les utilisateurs de rester connectés aux nœuds au-delà de leur fenêtre d’accès approuvée.
Nous vous recommandons d’utiliser une combinaison de politiques d’approbation pour vous aider à sécuriser les nœuds contenant des données plus critiques tout en permettant aux utilisateurs de se connecter à des nœuds moins critiques sans intervention. Par exemple, vous pouvez exiger des approbations manuelles pour les demandes d’accès aux nœuds de base de données et approuver automatiquement les sessions pour les nœuds de niveau présentation non persistants.
Systems Manager prend en charge l'accès aux just-in-time nœuds pour les utilisateurs fédérés avec IAM Identity Center ou IAM. Lorsqu’un utilisateur fédéré soumet une demande d’accès, il indique le nœud cible et la raison pour laquelle il doit se connecter au nœud. Systems Manager compare l’identité de l’utilisateur aux paramètres définis dans les politiques d’approbation de votre organisation. Lorsque les conditions de la politique d’approbation automatique sont remplies ou que les approbateurs fournissent manuellement des approbateurs, le demandeur peut se connecter au nœud cible. Lorsqu’un utilisateur tente de se connecter à un nœud approuvé, Systems Manager crée et utilise un jeton temporaire pour établir la session.
Étant donné que le service Systems Manager gère l’authentification des demandes d’accès et l’établissement des sessions, vous n’avez pas besoin d’utiliser les politiques IAM pour gérer l’accès à vos nœuds. En utilisant l'accès aux just-in-time nœuds, Systems Manager aide votre entreprise à se rapprocher de l'absence de privilèges permanents, car il vous suffit d'autoriser les utilisateurs à créer des demandes d'accès au lieu de les autoriser à démarrer des sessions avec des autorisations permanentes sur vos nœuds. Pour vous aider à répondre aux exigences de conformité, Systems Manager conserve toutes les demandes d’accès pendant un an. Systems Manager émet également des EventBridge événements pour l'accès aux just-in-time nœuds en cas d'échec des demandes d'accès et des mises à jour du statut des demandes d'accès pour des approbations manuelles. Pour plus d'informations, voir,[Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md).
**Topics**
+ [
# Configuration de just-in-time l'accès avec Systems Manager
](systems-manager-just-in-time-node-access-setting-up.md)
+ [
# Démarrer une session d'accès aux just-in-time nœuds
](systems-manager-just-in-time-node-access-start-session.md)
+ [
# Gestion des demandes just-in-time d'accès
](systems-manager-just-in-time-node-access-manage-requests.md)
+ [
# Passage à l'accès aux just-in-time nœuds depuis Session Manager
](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [
# Désactivation de just-in-time l'accès avec Systems Manager
](systems-manager-just-in-time-node-access-disable.md)
+ [
# Just-in-time questions fréquemment posées sur l'accès aux nœuds
](just-in-time-node-access-faq.md)
# Configuration de just-in-time l'accès avec Systems Manager
La configuration de l'accès aux just-in-time nœuds avec Systems Manager impliquait plusieurs étapes. Vous devez d'abord choisir les *cibles* pour lesquelles vous souhaitez configurer l'accès aux just-in-time nœuds. Les cibles comprennent les unités AWS Organizations organisationnelles (OUs) et Régions AWS. Par défaut, les mêmes cibles que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Vous pouvez choisir de configurer l'accès aux just-in-time nœuds pour toutes les mêmes cibles ou pour un sous-ensemble des cibles que vous avez spécifiées lors de la configuration de la console unifiée Systems Manager. L'ajout de nouvelles cibles qui n'ont pas été sélectionnées lors de la configuration de la console unifiée Systems Manager n'est pas pris en charge.
Vous allez ensuite créer des *politiques d’approbation* pour déterminer quand les connexions aux nœuds nécessitent une approbation manuelle et sont automatiquement approuvées. Les politiques d’approbation sont gérées par chaque compte de votre organisation. Vous pouvez également partager une politique depuis le compte d’administrateur délégué pour refuser explicitement l’approbation automatique des connexions à des nœuds spécifiques.
**Note**
La configuration de l'accès aux just-in-time nœuds n'affecte pas les politiques ou préférences IAM existantes pour Session Manager lesquelles vous avez configuré. Vous devez supprimer l'autorisation d'effectuer l'action d'`StartSession`API dans vos politiques IAM afin de garantir que seul l'accès aux just-in-time nœuds est utilisé lorsque les utilisateurs tentent de se connecter à vos nœuds. Après avoir configuré l'accès aux just-in-time nœuds, nous vous recommandons de tester vos politiques d'approbation auprès d'un sous-ensemble d'utilisateurs et de nœuds afin de vérifier que vos politiques fonctionnent comme vous le souhaitez avant de supprimer les autorisations deSession Manager.
**Prise en charge de l'authentification**
Notez les informations suivantes concernant la prise en charge de l'authentification utilisée pour l'accès aux just-in-time nœuds :
+ Just-in-time l'accès aux nœuds ne prend pas en charge le type d'authentification unique lors de la connexion à des Windows Server instances avec Remote Desktop.
+ Seules AWS Security Token Service (AWS STS) les informations d'identification de sécurité `AssumeRole` temporaires sont prises en charge. Pour plus d’informations, consultez les rubriques suivantes dans le *Guide de l’utilisateur IAM* :
+
+ [Informations d'identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Comparaison des AWS STS informations d'identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [Demande d'informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
Les politiques IAM suivantes décrivent les autorisations nécessaires pour administrer et permettre aux utilisateurs de créer des demandes d'accès aux just-in-time nœuds avec Systems Manager. Après avoir vérifié que vous disposez des autorisations requises pour utiliser l'accès aux just-in-time nœuds avec Systems Manager, vous pouvez poursuivre le processus de configuration. Remplacez chaque *example resource placeholder* par vos propres informations.
## Politique IAM pour permettre l' just-in-timeaccès aux nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:CreateConfigurationManager",
"ssm-quicksetup:DeleteConfigurationManager",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:GetServiceSettings",
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:ListTagsForResource",
"ssm-quicksetup:TagResource",
"ssm-quicksetup:UntagResource",
"ssm-quicksetup:UpdateConfigurationDefinition",
"ssm-quicksetup:UpdateConfigurationManager",
"ssm-quicksetup:UpdateServiceSettings"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStackSetOperation",
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackResources",
"cloudformation:ListStackSetOperations",
"cloudformation:ListStackInstances",
"cloudformation:DescribeStackSet",
"cloudformation:ListStackSets",
"cloudformation:DescribeStackInstance",
"cloudformation:DescribeOrganizationsAccess",
"cloudformation:ActivateOrganizationsAccess",
"cloudformation:GetTemplate",
"cloudformation:ListStackSetOperationResults",
"cloudformation:DescribeStackEvents",
"cloudformation:UntagResource",
"ssm:DescribeAutomationExecutions",
"ssm:GetAutomationExecution",
"ssm:ListAssociations",
"ssm:DescribeAssociation",
"ssm:GetDocument",
"ssm:ListDocuments",
"ssm:DescribeDocument",
"ssm:GetOpsSummary",
"organizations:DeregisterDelegatedAdministrator",
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators",
"organizations:ListRoots",
"organizations:ListParents",
"organizations:ListOrganizationalUnitsForParent",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAWSServiceAccessForOrganization",
"iam:ListRoles",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:CreatePolicy",
"cloudformation:TagResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:RollbackStack",
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack"
],
"Resource": [
"arn:aws:cloudformation:*:*:stack/StackSet-AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:stack/AWS-QuickSetup-*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stack/StackSet-SSMQuickSetup"
]
},
{
"Sid": "StackSetOperations",
"Effect": "Allow",
"Action": [
"cloudformation:CreateStackSet",
"cloudformation:UpdateStackSet",
"cloudformation:DeleteStackSet",
"cloudformation:DeleteStackInstances",
"cloudformation:CreateStackInstances",
"cloudformation:StopStackSetOperation"
],
"Resource": [
"arn:aws:cloudformation:*:*:stackset/AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stackset-target/AWS-QuickSetup-JITNA*:*"
]
},
{
"Sid": "IamRolesMgmt",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRolePolicy",
"iam:ListRolePolicies"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
]
},
{
"Sid": "IamPassRole",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "SSMAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/AWS-EnableExplorer",
"arn:aws:ssm:us-east-1:111122223333:automation-execution/*"
]
},
{
"Sid": "SSMAssociationPermissions",
"Effect": "Allow",
"Action": [
"ssm:DeleteAssociation",
"ssm:CreateAssociation",
"ssm:StartAssociationsOnce"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:association/*"
},
{
"Sid": "SSMResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:CreateResourceDataSync",
"ssm:UpdateResourceDataSync"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:resource-data-sync/AWS-QuickSetup-*"
},
{
"Sid": "ListResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:ListResourceDataSync"
],
"Resource": "*"
},
{
"Sid": "CreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"accountdiscovery.ssm.amazonaws.com",
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"stacksets.cloudformation.amazonaws.com"
]
}
},
"Resource": "*"
},
{
"Sid": "CreateStackSetsServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-JustInTimeAccessDenyAccessOrgPolicy"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "IdentityCenterPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour configurer l'accès aux just-in-time nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/SSM-JustInTimeAccessTokenRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"justintimeaccess.ssm.amazonaws.com"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerPreferencesOperation",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "Session"
}
}
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:TerminateSession"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:UpdateConnectionRecordingPreferences",
"ssm-guiconnect:GetConnectionRecordingPreferences",
"ssm-guiconnect:DeleteConnectionRecordingPreferences"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingKmsOperation",
"Effect": "Allow",
"Action": [
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"StringLike": {
"kms:ViaService": "ssm-guiconnect.*.amazonaws.com"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
},
{
"Sid": "AllowFleetManagerOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
},
{
"Sid": "SNSTopicManagement",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": [
"arn:aws:sns:us-east-1:111122223333:SSM-JITNA*"
]
},
{
"Sid": "SNSListTopics",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "EventBridgeRuleManagement",
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets"
],
"Resource": [
"arn:aws:events:us-east-1::rule/SSM-JITNA*"
]
},
{
"Sid": "ChatbotSlackManagement",
"Effect": "Allow",
"Action": [
"chatbot:CreateSlackChannelConfiguration",
"chatbot:UpdateSlackChannelConfiguration",
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:DescribeSlackWorkspaces",
"chatbot:DeleteSlackChannelConfiguration",
"chatbot:RedeemSlackOauthCode",
"chatbot:DeleteSlackWorkspaceAuthorization",
"chatbot:GetSlackOauthParameters"
],
"Resource": "*"
},
{
"Sid": "ChatbotTeamsManagement",
"Effect": "Allow",
"Action": [
"chatbot:ListMicrosoftTeamsChannelConfigurations",
"chatbot:CreateMicrosoftTeamsChannelConfiguration",
"chatbot:UpdateMicrosoftTeamsChannelConfiguration",
"chatbot:ListMicrosoftTeamsConfiguredTeams",
"chatbot:DeleteMicrosoftTeamsChannelConfiguration",
"chatbot:RedeemMicrosoftTeamsOauthCode",
"chatbot:DeleteMicrosoftTeamsConfiguredTeam",
"chatbot:GetMicrosoftTeamsOauthParameters",
"chatbot:TagResource"
],
"Resource": "*"
},
{
"Sid": "SSMEmailSettings",
"Effect": "Allow",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:GetServiceSetting"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/email-role-mapping",
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/enabled-email-notifications"
]
},
{
"Sid": "AllowViewingJitnaCloudWatchMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/SSM/JustInTimeAccess"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "ManualPolicy",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"ssm:GetServiceSetting",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "SessionPreference",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "AllowIamListForKMS",
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": "arn:aws:iam::111122223333:user/*"
},
{
"Sid": "KMSPermission",
"Effect": "Allow",
"Action": [
"kms:TagResource",
"kms:ListAliases",
"kms:CreateAlias"
],
"Resource": "*"
},
{
"Sid": "KMSCreateKey",
"Effect": "Allow",
"Action": [
"kms:CreateKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"SystemsManagerJustInTimeNodeAccessManaged"
]
}
}
},
{
"Sid": "AllowIamRoleForChatbotAction",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/role name",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"chatbot.amazonaws.com"
]
}
}
},
{
"Sid": "AllowIamServiceRoleForChat",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/management.chatbot.amazonaws.com/AWSServiceRoleForAWSChatbot"
},
{
"Sid": "CloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:111122223333:log-group::log-stream:"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"sso-directory:SearchUsers",
"sso-directory:SearchGroups",
"identitystore:DescribeGroup",
"identitystore:DescribeUser"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour les approbateurs de demandes d’accès
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessRequestDescriptions",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowGetSpecificAccessRequest",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:opsitem/*"
},
{
"Sid": "AllowApprovalRejectionSignal",
"Effect": "Allow",
"Action": [
"ssm:SendAutomationSignal"
],
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "IDCPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## Politique IAM pour les utilisateurs d'accès aux just-in-time nœuds
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowJITNAOperations",
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken"
],
"Resource": "*"
},
{
"Sid": "AllowOpsItemCreationAndRetrieval",
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem",
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:*:*:opsitem/*"
},
{
"Sid": "AllowListAccessRequests",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents",
"ssm:DescribeSessions"
],
"Resource": "*"
},
{
"Sid": "RequestManualApprovals",
"Action": "ssm:StartAutomationExecution",
"Effect": "Allow",
"Resource": "arn:aws:ssm:*:*:document/*",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "ManualApprovalPolicy"
}
}
},
{
"Sid": "StartManualApprovalsAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*"
},
{
"Sid": "CancelAccessRequestManualApproval",
"Effect": "Allow",
"Action": "ssm:StopAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "DescribeEC2Instances",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "AllowListSSMManagedNodesAndTags",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceInformation",
"ssm:ListTagsForResource"
],
"Resource": "*"
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "AllowRDPOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:ListConnections",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesReadOnly",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:*:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "ExploreNodes",
"Effect": "Allow",
"Action": [
"ssm:ListNodesSummary",
"ssm:ListNodes",
"ssm:DescribeInstanceProperties"
],
"Resource": "*"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup"
],
"Resource": "*"
}
]
}
```
------
**Note**
Pour restreindre l’accès aux opérations d’API qui créent, mettent à jour ou suppriment des politiques d’approbation, utilisez la clé de condition `ssm:DocumentType` pour les types de document `AutoApprovalPolicy` et `ManualApprovalPolicy `. Les opérations d’API `StartAccessRequest` et `GetAccessToken` ne prennent pas en charge les clés de contexte globales suivantes :
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Pour plus d’informations sur les clés de contexte de condition pour Systems Manager, consultez la section [Clés de condition pour AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) dans la *Référence de l’autorisation de service*.
La procédure suivante décrit comment effectuer la première étape de configuration pour l'accès aux just-in-time nœuds.
**Pour configurer l'accès aux just-in-time nœuds**
1. Connectez-vous au compte d’administrateur délégué de Systems Manager pour votre organisation.
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 **l'accès aux Just-in-time nœuds** dans le volet de navigation.
1. Sélectionnez **Activer la console unifiée**.
1. Choisissez les régions dans lesquelles vous souhaitez activer l'accès aux just-in-time nœuds. Par défaut, les mêmes régions que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Le choix de nouvelles régions qui n’étaient pas sélectionnées lors de la configuration de la console unifiée Systems Manager n’est pas pris en charge.
1. Sélectionnez **Activer l'accès aux just-in-time nœuds**.
L'utilisation de l'accès aux just-in-time nœuds pendant 30 jours après l'activation de la fonctionnalité est gratuite. Après la période d'essai de 30 jours, l'utilisation de l'accès aux just-in-time nœuds est payante. Pour plus d’informations, consultez [Tarification d’AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
# Créer des politiques d’approbation pour vos nœuds
Les politiques d’approbation définissent les approbations dont les utilisateurs ont besoin pour accéder à un nœud. Étant donné que l'accès aux just-in-time nœuds élimine le besoin d'autorisations de longue durée sur les nœuds par le biais de politiques IAM, vous devez créer des politiques d'approbation pour autoriser l'accès à vos nœuds. Si aucune politique d’approbation ne s’applique à un nœud, les utilisateurs ne peuvent pas demander l’accès au nœud.
Dans le just-in-time domaine de l'accès aux nœuds, il existe trois types de politiques. Ces types de politique sont l’*approbation automatique*, le *refus d’accès* et l’*approbation manuelle*.
**Just-in-time types de politiques d'accès aux nœuds**
+ Une politique d’approbation automatique définit les nœuds auxquels les utilisateurs peuvent se connecter automatiquement.
+ Les politiques d’approbation manuelle définissent le nombre et les niveaux d’approbations manuelles qui doivent être fournis pour accéder aux nœuds que vous spécifiez.
+ Une politique de refus d’accès empêche explicitement l’approbation automatique des demandes d’accès aux nœuds que vous spécifiez.
Une politique de refus d'accès s'applique à tous les comptes d'une AWS Organizations organisation. Par exemple, vous pouvez refuser explicitement les approbations automatiques du groupe `Intern` aux nœuds marqués par la clé `Production`. Les politiques d'approbation automatique et d'approbation manuelle s'appliquent uniquement au Régions AWS lieu Comptes AWS et à l'endroit où elles ont été créées. Chaque compte membre de votre organisation gère sa propre politique d’approbation. Les politiques d’approbation sont évaluées dans l’ordre suivant :
1. Refuser l’accès
1. Approbation automatique
1. Manuelle
Bien que vous ne puissiez avoir qu’une seule politique de refus d’accès par organisation et une seule politique d’approbation automatique par compte et par région, vous aurez probablement plusieurs politiques d’approbation manuelle dans un compte. Lors de l'évaluation des politiques d'approbation manuelle, l'accès au just-in-time nœud privilégie toujours la politique la plus spécifique à un nœud. Les stratégies d’approbation manuelle sont évaluées dans l’ordre suivant :
1. Balise cible spécifique
1. Tous les nœuds à cibler
Par exemple, supposons que vous avez un nœud balisé avec la clé `Demo`. Dans le même compte, vous disposez d’une politique d’approbation manuelle qui cible tous les nœuds et nécessite une approbation d’un niveau. Vous avec également d’une politique d’approbation manuelle qui exige deux approbations à deux niveaux pour les nœuds balisés avec la clé `Demo`. Systems Manager applique la politique qui cible la balise `Demo` au nœud, car elle est plus spécifique que la politique qui cible tous les nœuds. Cela vous permet de créer une politique générale pour tous les nœuds de votre compte, afin que les utilisateurs puissent soumettre des demandes d’accès tout en vous permettant de créer des politiques plus détaillées selon les besoins.
En fonction de votre organisation, plusieurs balises peuvent être appliquées à vos nœuds. Dans ce scénario, si plusieurs politiques d’approbation manuelle s’appliquent à un nœud, les demandes d’accès échouent. Par exemple, supposons qu’un nœud est balisé avec les clés `Production` et `Database`. Dans le même compte, vous disposez d’une politique d’approbation manuelle qui s’applique aux nœuds balisés par la clé `Production` et d’une autre politique d’approbation manuelle qui s’applique aux nœuds balisés par la clé `Database`. Cela entraîne un conflit pour le nœud balisé avec les deux clés, et les demandes d’accès échouent. Systems Manager redirige l’utilisateur vers la demande qui a échoué. Il peut y consulter les détails des politiques et des balises en conflit afin de pouvoir effectuer les ajustements nécessaires s’il dispose des autorisations requises. Dans le cas contraire, il peut demander à un collègue de son organisation disposant des autorisations requises de modifier les politiques. Les conflits de politiques qui se traduisent par l'échec des demandes d'accès EventBridge génèrent des événements qui vous permettent de créer vos propres flux de travail de réponse en toute flexibilité. En outre, Systems Manager envoie des notifications par e-mail en cas de conflit de politique entraînant l’échec des demandes d’accès aux destinataires que vous spécifiez. Pour plus d’informations sur la configuration des notifications par e-mail pour les conflits de politique, consultez [Configuration des notifications pour les demandes just-in-time d'accès](systems-manager-just-in-time-node-access-notifications.md).
Dans une politique de *refus d'accès*, vous utilisez le langage de politique Cedar pour définir les nœuds auxquels les utilisateurs ne peuvent explicitement pas se connecter automatiquement dans votre organisation. Cette politique est créée et partagée à partir du compte d'administrateur délégué de votre organisation. La politique de refus d'accès remplace toutes les politiques d'approbation automatique. Vous ne pouvez avoir qu'une seule politique de refus d'accès par organisation.
Dans une politique d'*approbation automatique*, vous utilisez le langage de politique Cedar pour définir quels utilisateurs peuvent se connecter automatiquement aux nœuds spécifiés sans approbation manuelle. La durée d’accès pour une demande d’accès approuvée automatiquement est de 1 heure. Cette valeur ne peut pas être modifiée. Vous ne pouvez avoir qu'une seule politique d'approbation automatique par compte et par région.
Dans une politique *d'approbation manuelle*, vous spécifiez la durée d'accès, le nombre de niveaux d'approbation requis, le nombre d'approbateurs requis par niveau et les nœuds auxquels ils peuvent approuver les demandes just-in-time d'accès. La durée d’accès pour une politique d’approbation manuelle doit être comprise entre 1 et 336 heures. Si vous spécifiez plusieurs niveaux d’approbation, les approbations pour la demande d’accès sont traitées un niveau à la fois. Cela signifie que toutes les approbations dont vous avez besoin pour un niveau doivent être fournies avant que le processus d’approbation passe aux niveaux suivants. Si vous spécifiez plusieurs balises dans une politique d’approbation manuelle, elles sont évaluées comme des instructions `or` et non comme des instructions `and`. Par exemple, si vous créez une politique d’approbation manuelle qui inclut les balises `Application`, `Web` et `Test`, la politique s’applique à tout nœud balisé avec l’une de ces clés. La politique ne s’applique pas uniquement aux nœuds balisés avec les trois clés.
Nous vous recommandons d’utiliser une combinaison de politiques manuelles avec votre politique d’approbation automatique pour vous aider à sécuriser les nœuds contenant des données plus critiques tout en permettant aux utilisateurs de se connecter aux nœuds moins critiques sans intervention. Par exemple, vous pouvez exiger des approbations manuelles pour les demandes d’accès aux nœuds de base de données et approuver automatiquement les sessions pour les nœuds de niveau présentation non persistants.
Les procédures suivantes décrivent comment créer des politiques d'approbation pour l'accès aux just-in-time nœuds.
**Topics**
+ [
# Créez des politiques d'approbation manuelle pour l'accès aux just-in-time nœuds
](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [
# Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès
](auto-approval-deny-access-policy-statement-structure.md)
+ [
# Création d'une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds
](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [
# Création d'une politique de refus d'accès pour just-in-time l'accès aux nœuds
](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [
# Créez des politiques d'approbation pour l'accès aux just-in-time nœuds avec Amazon Q
](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# Créez des politiques d'approbation manuelle pour l'accès aux just-in-time nœuds
La procédure suivante indique comment créer des politiques d’approbation manuelles. Systems Manager vous permet de créer jusqu'à 50 politiques d'approbation manuelle par Compte AWS utilisateur Région AWS.
**Créer une politique d’approbation manuelle**
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 **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans la section **Détails de la politique** de l’étape **Créer une politique d’approbation manuelle**, entrez le nom et la description de la politique d’approbation.
1. Entrez une valeur pour **Durée de l’accès**. Il s’agit de la durée maximale pendant laquelle un utilisateur peut démarrer des sessions sur un nœud après l’approbation d’une demande d’accès. La valeur doit être comprise entre 1 et 336 heures.
1. Dans la section **Nœuds cibles**, entrez les paires clé-valeur de balise associées aux nœuds auxquels vous souhaitez que la politique s’applique. Si aucune des balises spécifiées dans la politique n’est associée à un nœud, la stratégie n’est pas appliquée au nœud.
1. Dans la section **Approbateurs de demandes d’accès**, entrez les utilisateurs ou les groupes que vous souhaitez autoriser à approuver les demandes d’accès aux nœuds cibles de la politique. Les approbateurs de demandes d’accès peuvent être des utilisateurs et groupes IAM Identity Center ou des rôles IAM. Vous pouvez spécifier jusqu’à 5 approbateurs par niveau et jusqu’à 5 niveaux d’approbateurs.
1. Sélectionnez **Créer une politique d’approbation manuelle**.
# Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès
Le tableau suivant montre la structure des politiques d’approbation automatique et de refus d’accès.
| Composant | Syntaxe |
| --- | --- |
| effet | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| clause de condition | when {
principal or resource has attribute name
}; |
## Composants de politique
Une politique d’approbation automatique ou de refus d’accès contient les composants suivants :
+ **Effet** : `permit` (autoriser) ou `forbid` (refuser) l’accès.
+ **Portée** : les principaux, actions et ressources auxquels s’applique l’effet. Vous pouvez laisser le champ de portée indéfini dans Cedar en n’identifiant pas de principaux, d’actions ou de ressources spécifiques. Dans ce cas, la politique s’applique à tous les principaux, actions et ressources possibles. Pour l'accès aux just-in-time nœuds, `action` c'est toujours le cas`AWS::SSM::Action::"getTokenForInstanceAccess"`.
+ **Clause de condition** : le contexte dans lequel l’effet s’applique.
## Commentaires
Vous pouvez inclure des commentaires dans vos politiques. Les commentaires sont définis comme une ligne commençant par `//` et se terminant par un caractère de nouvelle ligne.
L’exemple suivant illustre les commentaires dans une politique.
```
// Allows users in the Engineering group from the Platform org to automatically connect to nodes tagged with Engineering and Production keys.
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
```
## Clauses multiples
Vous pouvez utiliser plusieurs clauses de condition dans une déclaration de politique à l’aide de l’opérateur `&&`.
```
// Allow access if node has tag where the tag key is Environment
// & tag value is Development
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Development"
};
```
## Caractères réservés
L’exemple suivant montre comment écrire une politique si une propriété de contexte utilise un `:` (point-virgule), qui est un caractère réservé dans le langage de politique.
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
Pour accéder à des exemples supplémentaires, consultez [Exemples de déclarations de politique](#policy-statement-examples).
## Just-in-time schéma d'accès aux nœuds
Voici le schéma Cedar pour l'accès aux just-in-time nœuds.
```
namespace AWS::EC2 {
entity Instance tags String;
}
namespace AWS::IdentityStore {
entity Group;
entity User in [Group] {
employeeNumber?: String,
costCenter?: String,
organization?: String,
division?: String,
};
}
namespace AWS::IAM {
entity Role;
type AuthorizationContext = {
principalTags: PrincipalTags,
};
entity PrincipalTags tags String;
}
namespace AWS::SSM {
entity ManagedInstance tags String;
action "getTokenForInstanceAccess" appliesTo {
principal: [AWS::IdentityStore::User],
resource: [AWS::EC2::Instance, AWS::SSM::ManagedInstance],
context: {
"iam": AWS::IAM::AuthorizationContext
}
};
}
```
## Opérateurs intégrés
Lorsque vous créez le contexte d’une politique d’approbation automatique ou de refus d’accès utilisant différentes conditions, vous pouvez utiliser l’opérateur `&&` pour ajouter des conditions supplémentaires. Il existe également de nombreux autres opérateurs intégrés que vous pouvez utiliser pour ajouter un pouvoir d’expression supplémentaire à vos conditions de politique. Le tableau suivant contient tous les opérateurs intégrés à titre de référence.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## Exemples de déclarations de politique
Voici des exemples de déclaration de politique.
```
// Users assuming IAM roles with a principal tag of "Elevated" can automatically access nodes tagged with the "Environment" key when the value equals "prod"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify IAM role principal tag
context.iam.principalTags.getTag("AccessLevel") == "Elevated" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "prod"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "prod"
};
```
```
// Identity Center users in the "Contractor" division can automatically access nodes tagged with the "Environment" key when the value equals "dev"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify that the user is part of the "Contractor" division
principal.division == "Contractor" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "dev"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "dev"
};
```
```
// Identity Center users in a specified group can automatically access nodes tagged with the "Environment" key when the value equals "Production"
permit(principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::getTokenForInstanceAccess,
resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Production"
};
```
# Création d'une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds
Les politiques d’approbation automatique utilisent le langage de politique Cedar pour définir quels utilisateurs peuvent se connecter automatiquement aux nœuds spécifiés sans approbation manuelle. Une politique d’approbation automatique contient plusieurs déclarations `permit` spécifiant le `principal` et la `resource`. Chaque déclaration inclut une clause `when` définissant les conditions d’approbation automatique.
Voici un exemple de politique d’approbation automatique.
```
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has costCenter && resource.hasTag("CostCenter") && principal.costCenter == resource.getTag("CostCenter")
};
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
};
```
La procédure suivante explique comment créer une politique d'approbation automatique pour l' just-in-timeaccès aux nœuds. La durée d’accès pour une demande d’accès approuvée automatiquement est de 1 heure. Cette valeur ne peut pas être modifiée. Vous ne pouvez avoir qu'une seule politique d'approbation automatique par Compte AWS et Région AWS. Pour plus d’informations sur l’élaboration de déclarations de politique, consultez [Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès](auto-approval-deny-access-policy-statement-structure.md).
**Créer une politique d’approbation automatique**
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 **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans l’onglet **Politiques d’approbation**, sélectionnez **Créer une politique d’approbation automatique**.
1. Saisissez votre déclaration de politique pour la politique d’approbation automatique dans la section **Déclaration de politique**. Vous pouvez utiliser les **exemples de déclarations** fournis pour vous aider à créer votre politique.
1. Sélectionnez **Créer une politique d’approbation automatique**.
# Création d'une politique de refus d'accès pour just-in-time l'accès aux nœuds
Les politiques de refus d’accès utilisent le langage de politique Cedar pour définir les nœuds auxquels les utilisateurs ne peuvent pas se connecter automatiquement sans approbation manuelle. Une politique de refus d’accès contient plusieurs instructions `forbid` spécifiant le `principal` et la `resource`. Chaque déclaration inclut une clause `when` définissant les conditions du refus explicite de l’approbation automatique.
Voici un exemple de stratégie de refus d’accès :
```
forbid (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") && resource.getTag("Environment") == "Production"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has division && principal.division != "Finance" && resource.hasTag("DataClassification") && resource.getTag("DataClassification") == "Financial"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "TEMP-*" && resource.hasTag("Criticality") && resource.getTag("Criticality") == "High"
};
```
La procédure suivante décrit comment créer une politique de refus d'accès pour l'accès aux just-in-time nœuds. Pour plus d’informations sur l’élaboration d’une stratégie de cycle de vie, consultez [Structure de déclaration et opérateurs intégrés pour les politiques d’approbation automatique et de refus d’accès](auto-approval-deny-access-policy-statement-structure.md).
**Note**
Notez les informations suivantes.
Vous pouvez créer des politiques de refus d’accès lorsque vous êtes connecté au compte de gestion AWS ou au compte administrateur délégué. Votre organisation AWS Organizations ne peut avoir qu’une seule politique de refus d’accès.
Just-in-time node access uses AWS Resource Access Manager (AWS RAM) pour partager votre politique de refus d'accès avec les comptes membres de votre organisation. Si vous souhaitez partager votre politique de refus d’accès avec les comptes membres de votre organisation, le partage des ressources doit être activé depuis le compte de gestion de votre organisation. Pour de plus amples informations, veuillez consulter [Activer le partage de ressources dans AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) dans le *Guide de l’utilisateur AWS RAM *.
**Créer une politique de refus d’accè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. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Dans l’onglet **Politiques d’approbation**, sélectionnez **Créer une politique de refus d’accès**.
1. Entrez votre déclaration de politique pour la politique de refus d’accès dans la section **Déclaration de politique**. Vous pouvez utiliser les **exemples de déclarations** fournis pour vous aider à créer votre politique.
1. Sélectionnez **Créer une politique de refus d’accès**.
# Créez des politiques d'approbation pour l'accès aux just-in-time nœuds avec Amazon Q
L’utilisation d’Amazon Q Developer pour la ligne de commande fournit des conseils et une assistance sur les différents aspects du développement logiciel. Pour l'accès aux just-in-time nœuds, Amazon Q vous aide à créer des politiques d'approbation en générant et en mettant à jour le code des politiques, en analysant les déclarations de politique, etc. Les informations suivantes décrivent comment créer des politiques d’approbation à l’aide d’Amazon Q pour la ligne de commande.
## Identifier votre cas d'utilisation
La première étape de la création de politiques d’approbation consiste à définir clairement votre cas d’utilisation. Par exemple, dans votre organisation, vous souhaiterez peut-être approuver automatiquement les demandes d’accès aux nœuds dotés d’une balise `Environment:Testing`. Vous pouvez également refuser explicitement les approbations automatiques aux nœuds dotés d’une balise `Environment:Production` si l’ID d’un employé commence par `TEMP`. Pour les nœuds dotés d’une balise `Tier:Database`, vous pouvez avoir besoin de deux niveaux d’approbations manuelles.
Dans un scénario donné, vous pourriez préférer une politique ou une condition à une autre. Nous vous recommandons donc de définir clairement les comportements de politique à adopter afin de déterminer les déclarations les mieux adaptées à votre cas d’utilisation et à vos préférences.
## Configurer votre environnement de développement.
Installez Amazon Q pour la ligne de commande où vous souhaitez développer vos politiques d’approbation. Pour plus d’informations sur l’installation d’Amazon Q pour ligne de commande, consultez la section [Installer Amazon Q pour la ligne de commande](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html) dans le *Guide de l’utilisateur Amazon Q Developer*.
Nous vous recommandons également d'installer le serveur MCP pour la AWS documentation. Ce serveur MCP connecte Amazon Q pour ligne de commande aux ressources de documentation les plus récentes. Pour plus d’informations sur l’utilisation de MCP avec Amazon Q pour ligne de commande, consultez la section [Utiliser MCP avec Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html) dans le *Guide de l’utilisateur Amazon Q*.
Pour plus d'informations sur le serveur de AWS documentation MCP, consultez la section Serveur de [AWS documentation MCP.](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/)
Installez et configurez le AWS CLI, si ce n'est pas déjà fait. Pour plus d'informations, voir [Installation ou mise à jour de la dernière version du AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
## Élaborer le contenu de la politique d’approbation
Une fois votre cas d’utilisation identifié et votre environnement configuré, vous pouvez développer le contenu de vos politiques. Votre cas d’utilisation et vos préférences dicteront en grande partie les types de politiques d’approbation et de déclarations à utiliser.
Si vous ne savez pas comment utiliser une politique particulière ou si vous avez besoin de plus d’informations sur le schéma d’une stratégie, consultez [Créer des politiques d’approbation pour vos nœuds](systems-manager-just-in-time-node-access-approval-policies.md) et les rubriques suivantes. Ces rubriques expliquent en détail comment les politiques sont évaluées, et fournissent des exemples pratiques de déclarations.
La procédure suivante décrit comment créer des politiques d’approbation avec Amazon Q pour ligne de commande.
**Note**
Amazon Q Developer utilise l’IA générative. Vous devrez peut-être vérifier les réponses. Consultez la [politique AWS en matière d’IA responsable](https://aws.amazon.com/ai/responsible-ai/policy/).
**Pour créer une politique d’approbation à l’aide d’Amazon Q pour ligne de commande**
1. Ouvrez votre terminal et démarrez une session avec Amazon Q.
```
$ q chat
```
1. Saisissez une invite et décrivez le type de déclaration de politique que vous souhaitez créer. Par exemple, en utilisant le scénario précédent pour une politique d’approbation, vous pourriez saisir l’invite suivante :
```
Create a Cedar policy statement that allows a principal to use the “getTokenForInstanceAccess" action for a resource
that has a tag key “Environment” and tag value of “Testing”. Use the following example statement for reference to verify the syntax.
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
The Cedar policy statement you create must be valid. Validate the Cedar statement using the AWS documentation provided for just-in-time node access policy statement structure and make sure you abide by the schema.
```
1. La saisie de cet exemple d’invite produit le résultat suivant :
```
Based on the AWS documentation for Cedar policy statements and the examples provided, I'll create a valid Cedar policy
statement that allows a principal to use the "getTokenForInstanceAccess" action for resources with the tag key "Environment" and tag value "Testing".
Here's the Cedar policy statement:
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Testing"
};
This policy statement:
1. Uses the permit effect to allow access
2. Applies to any principal (since no specific principal is defined)
3. Specifically targets the "getTokenForInstanceAccess" action
4. Applies to resources that have a tag with key "Environment" and value "Testing"
5. Uses the proper syntax for the condition clause with the hasTag() and getTag() operators
The statement follows the Cedar policy language structure as documented in the AWS Systems Manager documentation for just-in-time node access policies.
```
1. Collez la déclaration de politique dans un nouveau fichier Cedar pour valider sa syntaxe. Vous pouvez également valider la déclaration en utilisant le [terrain de jeu Cedar](https://www.cedarpolicy.com/en/playground).
1. Après avoir validé la déclaration, enregistrez le fichier Cedar.
1. Depuis votre terminal, exécutez la AWS CLI commande suivante pour créer un document SSM en utilisant le contenu de votre politique. Avant d'utiliser des politiques d'approbation dans un environnement de production, testez vos politiques d'approbation avec un sous-ensemble d'identités et de nœuds dans un Compte AWS et Région AWS.
**Note**
Pour une politique d’approbation automatique, le nom du document doit être `SSM-JustInTimeAccessAutoApprovalPolicy`. Il ne peut y avoir qu'une seule politique d'approbation automatique par Compte AWS et Région AWS. Pour une politique de refus d’accès, le nom du document doit être `SSM-JustInTimeAccessDenyAccessOrgPolicy`. Il ne peut y avoir qu'une seule politique de refus d'accès par AWS Organizations organisation, et la politique doit être créée dans le compte d'administrateur délégué de Systems Manager. Les contraintes de dénomination pour les politiques d’approbation manuelle sont les mêmes que celles des autres documents SSM. Pour de plus amples informations, veuillez consulter [CreateDocument](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html#systemsmanager-CreateDocument-request-Name).
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/policyContent.cedar \
--name "SSM-JustInTimeAccessAutoApprovalPolicy" \
--document-type "AutoApproval"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\policyContent.cedar ^
--name "SSM-JustInTimeAccessAutoApprovalPolicy" ^
--document-type "AutoApproval"
```
------
#### [ PowerShell ]
```
$cedar = Get-Content -Path "C:\path\to\file\policyContent.cedar" | Out-String
New-SSMDocument `
-Content $cedar `
-Name "SSM-JustInTimeAccessAutoApprovalPolicy" `
-DocumentType "AutoApproval"
```
------
# Mettre à jour les préférences de session d'accès aux just-in-time nœuds
Avec l'accès aux just-in-time nœuds, vous pouvez définir les préférences générales de session et de journalisation dans chaque nœud Compte AWS et Région AWS dans votre organisation. Vous pouvez également CloudFormation StackSets créer un document de préférences de session dans plusieurs comptes et régions pour vous aider à avoir des préférences de session cohérentes. Pour plus d’informations sur le schéma des documents de préférences de session, consultez [Schéma de document de session](session-manager-schema.md).
À des fins de journalisation, nous vous recommandons d'utiliser l'option de streaming avec Amazon CloudWatch Logs. Cette fonctionnalité vous permet d'envoyer un flux continu de journaux de données de session à 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.
Systems Manager ne met pas automatiquement fin aux sessions d'accès aux just-in-time nœuds. Il est recommandé de spécifier des valeurs pour la *durée maximale de session* et les paramètres de *délai d’inactivité des sessions*. L’utilisation de ces paramètres vous permet d’empêcher un utilisateur de rester connecté à un nœud plus longtemps que le délai approuvé dans une demande d’accès. La procédure suivante décrit comment mettre à jour les préférences de session pour l'accès aux just-in-time nœuds.
**Important**
Vous devez étiqueter les AWS KMS clés utilisées pour le Session Manager chiffrement et l'enregistrement RDP lors de l'accès aux just-in-time nœuds avec la clé de balise `SystemsManagerJustInTimeNodeAccessManaged` et la valeur de la `true` balise.
Pour plus d’informations sur le balisage des clés KMS, veuillez consulter la rubrique [Tags dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) dans le *Guide du développeur AWS Key Management Service *.
**Mettre à jour les préférences 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. Sélectionnez **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Préférences de session**, sélectionnez **Modifier**.
1. Mettez à jour vos préférences générales et de journalisation selon vos besoins, puis sélectionnez **Enregistrer**.
# Configuration des notifications pour les demandes just-in-time d'accès
Vous pouvez configurer Systems Manager pour envoyer des notifications lorsqu'un utilisateur crée une demande d'accès aux just-in-time nœuds aux adresses e-mail, ou au client de chat, pour les approbateurs et le demandeur. La notification contient le motif de la demande d'accès fournie par le demandeur Compte AWS Région AWS, le statut de la demande et l'ID du nœud cible. Actuellement, Systems Manager prend en charge les clients Slack et Microsoft Teams grâce à l’intégration avec Amazon Q Developer dans les applications de chat. Lorsque vous utilisez des notifications via des clients de chat, les approbateurs de demandes d’accès peuvent interagir directement avec les demandes d’accès. Il n’est donc plus nécessaire de se connecter à la console pour répondre aux demandes d’accès.
**Avant de commencer**
Avant de configurer un client de chat pour les notifications d'accès aux just-in-time nœuds, tenez compte des exigences suivantes :
+ Si vous utilisez des rôles IAM pour gérer les identités des utilisateurs dans votre compte, vous devez associer manuellement les adresses e-mail des approbateurs ou demandeurs auxquels vous souhaitez envoyer des notifications au rôle associé. Dans le cas contraire, les destinataires prévus ne pourront pas être informés par e-mail.
Les procédures suivantes décrivent comment configurer les notifications pour les demandes d'accès aux just-in-time nœuds.
**Pour configurer un client de chat pour les notifications d'accès aux just-in-time nœuds**
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 **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Chat**, sélectionnez **Configurer un nouveau client**.
1. Dans le menu déroulant **Sélectionner le type de client**, choisissez le type de client de chat que vous souhaitez configurer, puis sélectionnez **Suivant**.
1. Vous êtes invité à autoriser Amazon Q Developer dans les applications de chat à accéder à votre client de chat. Sélectionnez **Autoriser**.
1. Dans la section **Configurer le canal**, saisissez les informations de votre canal client de chat et sélectionnez les types de notifications que vous souhaitez recevoir.
1. Si vous configurez les notifications Slack, invitez « @Amazon Q » à accéder à chaque canal Slack dans lequel les notifications sont configurées.
1. Sélectionnez **Configurer le canal**.
**Note**
Pour autoriser les demandes d' approving/rejecting accès directement depuis un canal Slack, assurez-vous que le rôle IAM configuré avec le canal Slack dispose d'`ssm:SendAutomationSignal`autorisations et d'une politique de confiance incluant le chatbot :
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**Pour configurer les notifications par e-mail pour les notifications d'accès aux just-in-time nœuds**
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 **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **E-mail**, sélectionnez **Modifier**.
1. Sélectionnez **Ajouter des e-mails**, puis choisissez le **rôle IAM** auquel vous souhaitez associer manuellement les adresses e-mail.
1. Dans le champ **Adresse e-mail**, saisissez une adresse e-mail. Chaque fois qu’une demande d’accès créée nécessite l’approbation du rôle IAM que vous avez spécifié, les adresses e-mail que vous associez au rôle sont notifiées.
1. Sélectionnez **Ajouter une adresse e-mail**.
# Enregistrement des connexions RDP
Just-in-time l'accès aux nœuds inclut la possibilité d'enregistrer les connexions RDP établies avec vos Windows Server nœuds. L’enregistrement des connexions RDP nécessite un compartiment S3 et une clé gérée par le client AWS Key Management Service (AWS KMS). Le AWS KMS key est utilisé pour chiffrer temporairement les données d'enregistrement pendant qu'elles sont générées et stockées sur les ressources de Systems Manager. La clé gérée par le client doit être une clé symétrique utilisant les fonctions de clé de chiffrement et de déchiffrement. Vous pouvez soit utiliser une clé multirégionale pour votre organisation, soit créer une clé gérée par le client dans chaque région où vous avez activé l'accès aux just-in-time nœuds.
Si vous avez activé le chiffrement KMS sur le compartiment S3 dans lequel vous stockez les enregistrements, vous devez fournir au principal de service `ssm-guiconnect` l’accès à la clé gérée par le client utilisée pour le chiffrement du compartiment. Cette clé gérée par le client peut être différente de celle que vous spécifiez dans les paramètres d’enregistrement, qui doivent inclure les éléments pour lesquels l’autorisation `kms:CreateGrant` est requise pour établir des connexions.
## Configuration du chiffrement de compartiment S3 pour les enregistrements RDP
Vos enregistrements de connexion sont stockés dans le compartiment S3 que vous spécifiez lorsque vous activez l’enregistrement RDP.
Si vous utilisez une clé KMS comme mécanisme de chiffrement par défaut pour le compartiment S3 (SSE-KMS), vous devez autoriser le principal de service `ssm-guiconnect` à accéder à l’action `kms:GenerateDataKey` sur la clé. Nous recommandons d’utiliser une clé gérée par le client lors de l’utilisation du chiffrement SSE-KMS avec un compartiment S3. En effet, vous pouvez mettre à jour la stratégie de clé associée à une clé gérée par le client. Vous ne pouvez pas mettre à jour les principales politiques pour Clés gérées par AWS.
**Important**
Vous devez étiqueter les AWS KMS clés utilisées pour le Session Manager chiffrement et l'enregistrement RDP lors de l'accès aux just-in-time nœuds avec la clé de balise `SystemsManagerJustInTimeNodeAccessManaged` et la valeur de la `true` balise.
Pour plus d’informations sur le balisage des clés KMS, veuillez consulter la rubrique [Tags dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html) dans le *Guide du développeur AWS Key Management Service *.
Utilisez la stratégie de clé gérée par le client suivante pour autoriser le service `ssm-guiconnect` à accéder à la clé KMS pour le stockage S3. Pour plus d’informations sur la mise à jour d’une clé gérée par le client, consultez [Modifier une politique de clés](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) dans le *Guide du développeur AWS Key Management Service *.
Remplacez chacune *example resource placeholder* par vos propres informations :
+ *account-id*représente l'ID de celui Compte AWS qui initie la connexion.
+ *region*représente l' Région AWS emplacement du compartiment S3. (Vous pouvez utiliser `*` si le compartiment doit recevoir des enregistrements provenant de plusieurs régions. Exemple :`s3.*.amazonaws.com`.)
**Note**
Vous pouvez utiliser `aws:SourceOrgID` dans la stratégie plutôt que `aws:SourceAccount` si le compte appartient à une organisation dans AWS Organizations.
```
{
"Sid": "Allow the GUI Connect service principal to access S3",
"Effect": "Allow",
"Principal": {
"Service": "ssm-guiconnect.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account-id"
},
"StringLike": {
"kms:ViaService": "s3.region.amazonaws.com"
}
}
}
```
## Configuration des autorisations IAM pour l’enregistrement des connexions RDP
Outre les autorisations IAM requises pour l'accès aux just-in-time nœuds, l'utilisateur ou le rôle que vous utilisez doit disposer des autorisations suivantes en fonction de la tâche que vous devez effectuer.
**Autorisations pour configurer l’enregistrement des connexions**
Pour configurer l’enregistrement de connexion RDP, les autorisations suivantes sont requises :
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**Autorisations pour l’établissement de connexions**
Pour établir des connexions RDP avec accès aux just-in-time nœuds, les autorisations suivantes sont requises :
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**Avant de commencer**
Pour stocker vos enregistrements de connexion, vous devez d’abord créer un compartiment S3 et ajouter la stratégie de compartiment suivante. Remplacez chaque *example resource placeholder* par vos propres informations.
(Pour plus d’informations sur l’ajout d’une stratégie de compartiment, consultez [Ajout d’une stratégie de compartiment à l’aide de la console Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) dans le *Guide de l’utilisateur Amazon S3*.)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConnectionRecording",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm-guiconnect.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition":{
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
## Activer et configurer l’enregistrement des connexions RDP
La procédure suivante décrit comment activer et configurer l’enregistrement de connexion RDP.
**Activer et configurer l’enregistrement des connexions RDP**
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 **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Enregistrement RDP**, sélectionnez **Activer l’enregistrement RDP**.
1. Choisissez le compartiment S3 dans lequel vous souhaitez charger les enregistrements de session.
1. Choisissez la clé gérée par le client que vous souhaitez utiliser pour chiffrer temporairement les données d’enregistrement pendant qu’elles sont générées et stockées sur les ressources de Systems Manager. (Il peut s’agir d’une clé gérée par le client différente de celle que vous utilisez pour chiffrer le compartiment.)
1. Cliquez sur **Enregistrer**.
## Valeurs de statut d’enregistrement de connexion RDP
Les valeurs de statut valides pour les enregistrements de connexion RDP sont les suivantes :
+ `Recording` : la connexion est en cours d’enregistrement
+ `Processing` : la vidéo est en cours de traitement une fois la connexion interrompue.
+ `Finished` : état du terminal réussi, la vidéo d’enregistrement de connexion a été traitée avec succès et chargée dans le compartiment spécifié.
+ `Failed` : échec de l’état du terminal. La connexion n’a pas été enregistrée correctement.
+ `ProcessingError`- Un ou plusieurs intermédiaires failures/errors se sont produits pendant le traitement vidéo. Les causes potentielles incluent des défaillances de dépendance au service ou des autorisations manquantes en raison d’une mauvaise configuration du compartiment S3 spécifié pour le stockage des enregistrements. Le service continue de tenter le traitement lorsque l’enregistrement est dans cet état.
**Note**
`ProcessingError` peut survenir si le principal de service `ssm-guiconnect` n’est pas autorisé à charger des objets dans le compartiment S3 une fois la connexion établie. Une autre cause potentielle est l’absence d’autorisations KMS sur la clé KMS utilisée pour le chiffrement du compartiment S3.
# Modification des cibles
Lorsque vous configurez l'accès aux just-in-time nœuds, vous choisissez les *cibles* sur lesquelles vous souhaitez configurer l'accès aux just-in-time nœuds. Les cibles comprennent les unités AWS Organizations organisationnelles (OUs) et Régions AWS. Par défaut, les mêmes cibles que celles que vous avez choisies lors de la configuration de la console unifiée Systems Manager sont sélectionnées pour l'accès aux just-in-time nœuds. Vous pouvez choisir de configurer l'accès aux just-in-time nœuds pour toutes les mêmes cibles ou pour un sous-ensemble des cibles que vous avez spécifiées lors de la configuration de la console unifiée Systems Manager. L'ajout de nouvelles cibles qui n'ont pas été sélectionnées lors de la configuration de la console unifiée Systems Manager n'est pas pris en charge. Vous pouvez modifier les cibles que vous avez sélectionnées après avoir configuré l'accès aux just-in-time nœuds.
La procédure suivante décrit comment modifier les cibles pour l'accès aux just-in-time nœuds.
**Modifier les cibles**
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 **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Cibles**, sélectionnez **Modifier**.
1. Sélectionnez les **unités organisationnelles** et **les régions dans** lesquelles vous souhaitez utiliser l'accès aux just-in-time nœuds.
1. Cliquez sur **Enregistrer**.
# Changer de fournisseurs d’identité
Par défaut, l'accès aux just-in-time nœuds utilise IAM comme fournisseur d'identité. Après avoir activé l'accès aux just-in-time nœuds, les clients utilisant la console unifiée avec une organisation peuvent modifier ce paramètre pour utiliser IAM Identity Center. Just-in-timel'accès aux nœuds ne prend pas en charge IAM Identity Center en tant que fournisseur d'identité lorsqu'il est configuré pour un seul compte et une seule région.
La procédure suivante décrit comment modifier le fournisseur d'identité pour l'accès aux just-in-time nœuds.
**Modifier les fournisseurs d’identité**
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 **Paramètres** dans le volet de navigation.
1. Sélectionnez l'onglet **Accès au Just-in-time nœud**.
1. Dans la section **Identité utilisateur**, sélectionnez **Modifier**.
1. Choisissez **AWS IAM Identity Center**.
1. Sélectionnez **Save**.
# Démarrer une session d'accès aux just-in-time nœuds
Après avoir activé et configuré l'accès aux just-in-time nœuds, et configuré les préférences de session et de notification, les utilisateurs sont prêts à démarrer des sessions d'accès aux just-in-time nœuds. Vous pouvez démarrer des sessions en utilisant l'accès aux just-in-time nœuds depuis la console Systems Manager ou depuis le AWS Command Line Interface Session Manager plugin. Just-in-timeles sessions d'accès aux nœuds peuvent être démarrées sur les nœuds du même compte et de la même région. Les procédures suivantes décrivent comment démarrer des sessions avec un accès aux just-in-time nœuds.
**Note**
Si vos utilisateurs se connectaient auparavant Session Manager à des nœuds, vous devez supprimer les Session Manager autorisations, par exemple`ssm:StartSession`, de leurs politiques IAM pour démarrer des sessions en utilisant l'accès aux just-in-time nœuds. Sinon, lors de la connexion aux nœuds, ils continueront à utiliser Session Manager.
**Pour démarrer une session avec accès aux just-in-time nœuds à 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 **Explorer les nœuds**.
1. Sélectionnez le nœud auquel vous souhaitez vous connecter.
1. Dans le menu déroulant **Actions**, sélectionnez **Connexion**.
Si les politiques d’approbation de votre organisation ne vous permettent pas de vous connecter automatiquement au nœud, vous êtes invité à soumettre une demande d’accès. Une fois que vous aurez rempli les informations demandées et soumis la demande d’accès, vous pourrez démarrer des sessions sur le nœud une fois que toutes les approbations requises auront été reçues.
**Pour démarrer une session avec accès aux just-in-time nœuds à l'aide du AWS CLI**
1. Exécutez la commande suivante pour démarrer le flux de travail des demandes d'accès, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
Selon les politiques d’approbation de votre organisation, vous serez automatiquement connecté au nœud, ou le processus d’approbation manuelle sera lancé. Pour les demandes qui nécessitent des approbations manuelles, notez l’ID de la demande d’accès renvoyé dans la réponse.
1. Attendez que toutes les approbations requises soient fournies.
1. Une fois que toutes les approbations requises ont été fournies, exécutez la commande suivante pour obtenir un jeton d’accès contenant des informations d’identification temporaires. Remplacez les *placeholder values* par vos propres informations.
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
Notez le jeton d’accès de la réponse.
1. Exécutez la commande suivante pour utiliser les informations d'identification temporaires contenues dans le AWS CLI, en veillant à les *placeholder values* remplacer par vos propres informations.
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. Exécutez la commande suivante pour démarrer une session sur le nœud, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# Gestion des demandes just-in-time d'accès
Pour une visibilité accrue au sein de votre organisation, Systems Manager réplique les demandes d’accès vers le compte d’administrateur délégué de votre organisation. Pour vous aider à répondre aux exigences de conformité, Systems Manager conserve toutes les demandes d’accès pendant un an. Les rubriques suivantes décrivent comment gérer les demandes d'accès aux just-in-time nœuds. Ces informations sont destinées aux approbateurs de demandes d’accès. Avant de commencer, nous vous recommandons de revoir vos politiques IAM et de vous assurer que vous disposez des autorisations requises pour administrer l'accès aux just-in-time nœuds. Pour plus d'informations, voir,[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
**Topics**
+ [
# Approuver et refuser les demandes d'accès aux just-in-time nœuds
](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# Approuver et refuser les demandes d'accès aux just-in-time nœuds
Les approbateurs de demandes d'accès peuvent approuver ou refuser les demandes d'accès aux just-in-time nœuds depuis la console unifiée Systems Manager ou à l'aide de votre outil de ligne de commande préféré. Ces informations sont destinées aux approbateurs de demandes d’accès. Si vous ne disposez pas des autorisations requises pour approuver ou rejeter les demandes d’accès, contactez votre administrateur. Les procédures suivantes décrivent comment approuver ou refuser les demandes d'accès aux just-in-time nœuds.
**Pour approuver ou refuser les demandes d'accès aux just-in-time nœuds à 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. Sélectionnez **Gérer l’accès aux nœuds** dans le volet de navigation.
1. Sélectionnez l’onglet **Demandes d’accès**.
1. Sélectionnez l’option **Demandes pour moi**.
1. Cochez la demande d’accès que vous souhaitez approuver ou rejeter.
1. Sélectionnez **Approuver** ou **Rejeter**.
Après avoir approuvé une demande d’accès, vous pouvez révoquer votre approbation à tout moment en sélectionnant **Révoquer**.
**Pour approuver ou refuser les demandes d'accès aux just-in-time nœuds à l'aide de la ligne de commande**
1. Notez l’ID de demande d’accès à partir de la notification. Par exemple, *oi-12345abcdef*.
1. Exécutez la commande suivante pour renvoyer des informations sur le flux de travail d'approbation des demandes d'accès, en veillant à les *placeholder values* remplacer par vos propres informations.
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
Notez la valeur `automationExecutionId` dans le champ `/aws/accessrequest` pour `OperationalData`. Par exemple, *9231944f-61c6-40be-8bce-8ee2bEXAMPLE*.
1. Exécutez la commande suivante pour approuver ou rejeter la demande d’accès. Utilisez le type de signal `Approve` pour approuver la demande et `Deny` pour la refuser. Veillez à remplacer les *placeholder values* par vos propres informations.
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Passage à l'accès aux just-in-time nœuds depuis Session Manager
Lorsque vous activez l'accès aux just-in-time nœuds, Systems Manager n'apporte aucune modification à vos ressources existantes pourSession Manager. Cela garantit que votre environnement existant n’est pas perturbé et que les utilisateurs peuvent continuer à démarrer des sessions pendant que vous créez et validez des politiques d’approbation. Une fois que vous êtes prêt à tester vos politiques d'approbation, vous devez modifier vos politiques IAM existantes pour terminer la transition vers l'accès aux just-in-time nœuds. Cela inclut l'ajout des autorisations requises pour l'accès des just-in-time nœuds aux identités et la suppression des autorisations pour le fonctionnement de l'`StartSession`API pourSession Manager. Nous vous recommandons de tester les politiques d'approbation avec un sous-ensemble d'identités et de nœuds dans un Compte AWS et Région AWS.
Pour plus d'informations sur les autorisations requises pour accéder aux just-in-time nœuds, consultez[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
Pour plus d’informations sur la modification des autorisations IAM d’une identité, consultez la rubrique [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*.
La section suivante décrit une méthode détaillée permettant de passer à l'accès aux just-in-time nœuds à partir deSession Manager.
Le passage du gestionnaire de session à l'accès aux just-in-time nœuds nécessite une planification et des tests minutieux afin de garantir une transition fluide sans perturber vos opérations. Les sections suivantes décrivent la façon dont vous pouvez procéder.
## Conditions préalables
Avant de commencer, assurez-vous que vous avez terminé les tâches suivantes :
+ Configurez la console unifiée Systems Manager.
+ Vérifié que vous avez l’autorisation de modifier les politiques IAM de votre compte.
+ Identifié toutes les politiques et tous les rôles IAM qui accordent actuellement des autorisations Session Manager.
+ Documenté votre configuration Session Manager actuelle, y compris les préférences de session et les paramètres de journalisation.
## Évaluation
Évaluez votre environnement actuel et définissez les comportements d’approbation souhaités en effectuant les tâches suivantes :
1. **Faites l’inventaire de vos nœuds** : identifiez tous les nœuds auxquels les utilisateurs accèdent actuellement via Session Manager.
1. **Identifiez les modèles d’accès des utilisateurs** : documentez quels utilisateurs ou rôles ont besoin d’accéder à quels nœuds et dans quelles circonstances.
1. **Mappez les flux de travail d’approbation** : déterminez qui doit approuver les demandes d’accès pour les différents types de nœuds.
1. **Passez en revue la stratégie de balisage** : assurez-vous que vos nœuds sont correctement balisés pour prendre en charge vos politiques d’approbation planifiées.
1. **Auditez les politiques IAM existantes** : identifiez toutes les politiques qui incluent des autorisations Session Manager.
## Planification
### Stratégie en phases
Lorsque vous passez de Session Manager l'accès aux just-in-time nœuds, nous vous recommandons d'utiliser une approche progressive telle que la suivante :
1. **Phase 1 : Installation et configuration** - Activez l'accès aux just-in-time nœuds sans modifier les Session Manager autorisations existantes.
1. **Phase 2 : élaboration de politiques** - Créez et testez des politiques d’approbation pour vos nœuds.
1. **Phase 3 : migration pilote** - Modifiez un petit groupe de nœuds et d'utilisateurs ou de rôles non critiques pour passer de l'accès Session Manager aux just-in-time nœuds.
1. **Phase 4 : migration complète** - Migrez progressivement tous les nœuds et utilisateurs ou rôles restants.
### Considérations chronologiques
Tenez compte des facteurs suivants lors de la création de votre chronologie pour passer de l'accès aux just-in-time nœuds Session Manager à l'accès aux nœuds :
+ Prévoyez du temps pour la formation des utilisateurs et l’adaptation au nouveau flux de travail d’approbation.
+ Planifiez les migrations pendant les périodes de faible activité opérationnelle.
+ Prévoyez du temps pour les éventuelles opérations de dépannage et d’ajustement.
+ Prévoyez une période d’exploitation parallèle pendant laquelle les deux systèmes seront disponibles.
## Étapes d’implémentation
### Phase 1 : installation et configuration
1. Activez l'accès aux just-in-time nœuds dans la console Systems Manager. Pour obtenir des instructions complètes, consultez [Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
1. Configurez les préférences de session pour l'accès aux just-in-time nœuds en fonction de vos Session Manager paramètres actuels. Pour de plus amples informations, veuillez consulter [Mettre à jour les préférences de session d'accès aux just-in-time nœuds](systems-manager-just-in-time-node-access-session-preferences.md).
1. Configurez les préférences de notification relatives aux demandes d’accès. Pour de plus amples informations, veuillez consulter [Configuration des notifications pour les demandes just-in-time d'accès](systems-manager-just-in-time-node-access-notifications.md).
1. Si vous utilisez des connexions RDP aux nœuds Windows Server, configurez l’enregistrement RDP. Pour de plus amples informations, veuillez consulter [Enregistrement des connexions RDP](systems-manager-just-in-time-node-access-rdp-recording.md).
### Phase 2 : élaboration de politiques
1. Créez des politiques IAM pour les administrateurs et les utilisateurs d'accès aux just-in-time nœuds.
1. Développez des politiques d’approbation en fonction de vos exigences de sécurité et de votre cas d’utilisation.
1. Testez vos politiques dans un environnement hors production afin de vous assurer qu’elles fonctionnent comme prévu.
### Phase 3 : migration pilote
1. Sélectionnez un petit groupe d’utilisateurs et de nœuds non critiques pour le projet pilote.
1. Créez de nouvelles politiques IAM pour les utilisateurs pilotes qui incluent des autorisations d'accès aux just-in-time nœuds.
1. Supprimez les autorisations Session Manager (`ssm:StartSession`) des politiques IAM des utilisateurs pilotes.
1. Formez les utilisateurs pilotes au nouveau flux de travail de demande d’accès.
1. Surveillez le pilote pour détecter les problèmes, et recueillez les commentaires.
1. Ajustez les politiques et procédures en fonction des résultats du projet pilote.
**Exemple de modification de politique IAM pour les utilisateurs pilotes**
Politique initiale avec autorisations Session Manager :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
Politique modifiée pour l'accès aux just-in-time nœuds :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### Phase 4 : migration complète
Élaborez un calendrier pour la migration par lots des utilisateurs et nœuds restants.
## Méthodologie de test
Tout au long du processus de migration, effectuez les tests suivants :
+ **Validation des politiques** : vérifiez que les politiques d’approbation s’appliquent correctement aux nœuds et utilisateurs prévus.
+ **Flux de travail des demandes d’accès** : testez l’ensemble du flux de travail, de la demande d’accès à l’établissement de la session, à la fois pour les scénarios d’approbation automatique et d’approbation manuelle.
+ **Notifications** : vérifiez que les approbateurs reçoivent les notifications via les canaux configurés (e-mail, Slack, Microsoft Teams).
+ **Journalisation et surveillance** : vérifiez que les journaux de session et les demandes d’accès sont correctement capturés et stockés.
## Bonnes pratiques pour une migration réussie
+ **Communiquez tôt et souvent** : informez les utilisateurs du calendrier de migration et des avantages de l'accès aux just-in-time nœuds.
+ **Commencez par les systèmes non critiques** : commencez la migration par les environnements de développement ou de test avant de passer à la production.
+ **Documentez tout** : conservez des enregistrements détaillés de vos politiques d’approbation, des modifications des politiques IAM et des paramètres de configuration.
+ **Surveillez et ajustez** : surveillez en permanence les demandes d’accès et les flux de travail d’approbation, en ajustant les politiques selon les besoins.
+ **Établissez une gouvernance** : créez un processus permettant de revoir et de mettre à jour régulièrement les politiques d’approbation en fonction de l’évolution de votre environnement.
# Désactivation de just-in-time l'accès avec Systems Manager
La procédure suivante décrit comment désactiver l'accès aux just-in-time nœuds. Après avoir désactivé l'accès aux just-in-time nœuds, les utilisateurs de votre organisation peuvent ne pas être en mesure de se connecter à vos nœuds, sauf si vous avez déjà implémenté d'autres méthodes de connexion.
**Pour désactiver l'accès aux just-in-time nœuds**
1. Connectez-vous au compte d’administrateur délégué de Systems Manager pour votre organisation.
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 **Paramètres** dans le volet de navigation.
1. Dans l'onglet **Accès au Just-in-time nœud**, sélectionnez **Désactiver**.
# Just-in-time questions fréquemment posées sur l'accès aux nœuds
FAQ
## Comment passer de l'accès Session Manager aux just-in-time nœuds ?
Après avoir configuré la console unifiée et activé l'accès aux just-in-time nœuds, vous devez modifier vos politiques IAM existantes pour terminer le passage à l'accès aux just-in-time nœuds. Cela inclut l'ajout des autorisations requises pour l'accès aux just-in-time nœuds et la suppression des autorisations pour le fonctionnement de l'`StartSession`API pourSession Manager. Pour plus d'informations sur les politiques IAM relatives à l'accès aux just-in-time nœuds, consultez[Configuration de just-in-time l'accès avec Systems Manager](systems-manager-just-in-time-node-access-setting-up.md).
## Dois-je configurer la console unifiée pour utiliser l'accès aux just-in-time nœuds ?
Oui, la configuration de la console unifiée est une condition préalable à l'accès aux just-in-time nœuds. Cependant, une fois que vous avez configuré la console unifiée et activé l'accès aux just-in-time nœuds, il existe plusieurs méthodes pour vous connecter à vos nœuds. Par exemple, vous pouvez démarrer des sessions d'accès aux just-in-time nœuds depuis la console Amazon EC2 et le. AWS CLI Pour plus d’informations sur la configuration de la console unifiée, consultez [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).
## Y a-t-il un coût associé à l'accès aux just-in-time nœuds ?
Systems Manager propose un essai gratuit de 30 jours pour accéder aux just-in-time nœuds. Après la période d'essai, l'accès aux just-in-time nœuds entraîne des coûts. Pour plus d’informations, consultez [Tarification d’AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Quelle est la priorité des politiques d'approbation d'accès aux just-in-time nœuds ?
Les politiques d’approbation sont évaluées dans l’ordre suivant :
1. Refuser l’accès
1. Approbation automatique
1. Manuelle
## Comment les politiques d’approbation manuelle sont-elles évaluées ?
Just-in-time l'accès aux nœuds privilégie toujours la politique plus spécifique à un nœud. Les stratégies d’approbation manuelle sont évaluées dans l’ordre suivant :
1. Balise cible spécifique
1. Tous les nœuds à cibler
## Que se passe-t-il si aucune politique d’approbation ne s’applique à un nœud ?
Pour se connecter à un just-in-time nœud en utilisant l'accès au nœud, une politique d'approbation doit s'appliquer au nœud. Si aucune politique d’approbation ne s’applique à un nœud, les utilisateurs ne peuvent pas demander l’accès au nœud.
## Plusieurs politiques d’approbation peuvent-elles cibler une balise ?
Une balise ne peut être ciblée qu’une seule fois dans vos politiques d’approbation.
## Que se passe-t-il si plusieurs politiques d’approbation manuelle s’appliquent à un nœud en raison d’un chevauchement de balises ?
Lorsque plusieurs politiques d’approbation manuelle s’appliquent à un nœud, cela entraîne un conflit et les utilisateurs ne peuvent pas demander l’accès au nœud. Gardez cela à l’esprit lorsque vous créez vos politiques d’approbation manuelle, car certaines instances peuvent comporter plusieurs balises selon le cas.
## Puis-je utiliser l'accès aux just-in-time nœuds pour demander l'accès et démarrer des sessions sur les nœuds de différents comptes et régions ?
Just-in-time l'accès aux nœuds prend en charge les demandes d'accès et le démarrage de sessions sur les nœuds du même compte et de la même région que le demandeur.
## Puis-je utiliser l'accès aux just-in-time nœuds pour demander l'accès et démarrer des sessions sur les nœuds enregistrés avec une activation hybride ?
Oui, l'accès aux just-in-time nœuds prend en charge les demandes d'accès et le démarrage de sessions sur les nœuds enregistrés avec une activation hybride. Le nœud doit être enregistré dans le même compte et la même région que le demandeur.
# Diagnostiquer et remédier
Diagnostiquer et remédier
Grâce à la console Systems Manager unifiée, vous pouvez identifier les problèmes de l’ensemble de votre flotte en une seule opération de diagnostic. Pour les organisations, vous pouvez ensuite tenter une remédiation sur toutes les cibles ou seulement sur certaines d’entre elles à l’aide d’une seule opération d’automatisation. Pour une organisation, en tant qu’administrateur de compte délégué, vous pouvez sélectionner des cibles dans tous les comptes et toutes les régions. Si vous travaillez avec un seul compte, vous pouvez sélectionner des cibles dans une seule région à la fois.
Systems Manager peut diagnostiquer et vous aider à résoudre différents types de problèmes de déploiement et de configurations ayant dérivé. Systems Manager peut également identifier les instances Amazon Elastic Compute Cloud (Amazon EC2) de votre compte ou organisation que Systems Manager n’est pas en mesure de traiter comme un *nœud géré*. Le processus de diagnostic des instances EC2 permet d’identifier les problèmes liés à des erreurs de configuration au sein d’un cloud privé virtuel (VPC), d’un paramètre DNS (Domain Name Service) ou d’un groupe de sécurité Amazon Elastic Compute Cloud (Amazon EC2).
**Note**
Systems Manager prend en charge à la fois les instances EC2 et d’autres types d’ordinateurs dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) en tant que *nœuds gérés*. Pour être un nœud géré, l’agent AWS Systems Manager (SSM Agent) doit être installé sur l’ordinateur, et Systems Manager doit avoir l’autorisation d’effectuer des actions sur l’ordinateur.
Pour les instances EC2, cette autorisation peut être fournie 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. Pour de plus amples informations, consultez [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).
Pour les ordinateurs non EC2, cette autorisation est fournie à l’aide d’un rôle de service IAM. Pour de plus amples informations, consultez [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md).
**Avant de commencer**
Afin d’utiliser la fonctionnalité **Diagnostiquer et remédier** pour détecter les instances EC2 non gérées, vous devez d’abord intégrer votre organisation ou votre compte à la console Systems Manager unifiée. Au cours de ce processus, vous devez choisir l’option de création des rôles IAM et des politiques IAM gérées nécessaires à ces opérations. Pour de plus amples informations, consultez [Configuration de la console unifiée Systems Manager pour une organisation](systems-manager-setting-up-organizations.md).
Utilisez les rubriques suivantes pour vous aider à identifier et à réparer certains types courants de déploiements échoués, de configurations dérivées et d’instances EC2 non gérées.
**Topics**
+ [
# Diagnostic et correction des déploiements échoués
](remediating-deployment-issues.md)
+ [
# Diagnostic et correction des configurations dérivées
](remediating-configuration-drift.md)
+ [
# Diagnostiquer et corriger des instances Amazon EC2 non gérées dans Systems Manager
](remediating-unmanaged-instances.md)
+ [
# Les mesures correctives ont un impact sur les types d’actions du dossier d’exploitation
](remediation-impact-type.md)
+ [
# Affichage de la progression et de l’historique de l’exécution des mesures correctives dans Systems Manager
](diagnose-and-remediate-execution-history.md)
# Diagnostic et correction des déploiements échoués
Systems Manager peut diagnostiquer puis vous aider à corriger les types de déploiements échoués suivants :
+ Configuration de base des comptes des membres de l’organisation
+ Configuration de base du compte d’administrateur délégué
+ Configuration de base de votre compte
Utilisez la procédure suivante pour tenter de corriger ces types de problèmes.
**Pour diagnostiquer et corriger les déploiements échoué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 **Diagnostiquer et remédier**.
1. Sélectionnez l’onglet **Problèmes de déploiement**.
1. Dans la section **Déploiements échoués**, consultez la liste des résultats des déploiements ayant échoué.
1. Dans la colonne **Étape de configuration**, sélectionnez le nom d’un résultat pour consulter des informations supplémentaires sur le problème. Par exemple : **Configuration de base des comptes des membres de l’organisation**.
1. Sur la page détaillée de ce déploiement échoué, vous pouvez consulter la liste des comptes et le nombre de régions de chaque région qui ont connu des déploiements échoués.
1. Sélectionnez un identifiant de compte pour afficher les informations relatives à la raison des échecs de ce compte.
1. Dans la zone **Régions échouées**, examinez les informations fournies pour la **Raison du statut**. Ces informations peuvent indiquer la raison du déploiement échoué, ce qui peut fournir un aperçu des modifications de configuration à apporter.
1. Si vous souhaitez réessayer le déploiement sans apporter de modifications à la configuration, choisissez **Redéployer**.
# Diagnostic et correction des configurations dérivées
Systems Manager peut diagnostiquer puis vous aider à corriger les types de configurations dérivées suivants :
+ Configuration de base des comptes des membres de l’organisation
+ Configuration de base du compte d’administrateur délégué
+ Configuration de base de votre compte
Utilisez la procédure suivante pour tenter de corriger ces types de configurations dérivées.
**Pour diagnostiquer et corriger des configurations dérivé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 **Diagnostiquer et remédier**.
1. Sélectionnez l’onglet **Problèmes de déploiement**.
1. Dans la section **Déploiements dérivés**, consultez la liste des résultats des déploiements ayant échoué.
-ou-
Pour exécuter un nouveau diagnostic, sélectionnez **Détecter la dérive**.
1. Dans la colonne **Étape de configuration**, sélectionnez le nom d’un résultat pour consulter des informations supplémentaires sur le problème. Par exemple : **Configuration de base des comptes des membres de l’organisation**.
1. Sur la page détaillée de ce déploiement échoué, vous pouvez consulter la liste des comptes et le nombre de régions de chaque région qui ont connu des variations de configuration.
1. Sélectionnez un identifiant de compte pour afficher les informations relatives à la raison des variations de configuration de ce compte.
1. Dans la zone **Ressources dérivées**, la colonne **Ressource** indique les noms des ressources qui ont subi une dérive. La colonne **Type de dérive** indique si la ressource a été modifiée ou supprimée.
1. Pour redéployer la configuration souhaitée, choisissez **Redéployer**.
# Diagnostiquer et corriger des instances Amazon EC2 non gérées dans Systems Manager
Diagnostiquer et corriger des instances Amazon EC2 non gérées
Pour vous aider à gérer vos instances Amazon Elastic Compute Cloud (Amazon EC2) avec Systems Manager, vous pouvez utiliser la console Systems Manager unifiée pour effectuer les opérations suivantes :
1. Exécutez un processus de diagnostic manuel ou planifié pour identifier les instances EC2 de votre compte ou organisation qui ne sont pas gérées par Systems Manager.
1. Identifiez les problèmes de réseau ou autres qui empêchent Systems Manager de prendre en charge la gestion des instances.
1. Effectuez une exécution automatique pour résoudre automatiquement le problème ou accédez aux informations qui vous aideront à le résoudre manuellement.
Utilisez les informations contenues dans les rubriques suivantes pour vous aider à diagnostiquer et à corriger les problèmes qui empêchent Systems Manager de gérer vos instances EC2.
## Comment Systems Manager compte les nœuds concernés dans la liste des « Problèmes liés aux instances EC2 non gérées »
Le nombre de nœuds signalés comme non gérés dans l’onglet **Problèmes liés aux instances EC2 non gérées** représente le nombre total d’instances présentant l’une des valeurs de statut suivantes au moment de l’analyse de diagnostic :
+ `Running`
+ `Stopped`
+ `Stopping`
Ce numéro est indiqué sous la rubrique « **Nœuds concernés** » dans la zone **Résumé du problème**. Dans l’image suivante, le nombre de nœuds concernés qui ne sont pas actuellement gérés par Systems Manager est de `40`.
![\[La zone « Résumé du problème » présentant les 40 nœuds concernés à la page Diagnostiquer et corriger\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)
Contrairement au rapport sur les instances EC2 non gérées sur la page **Examiner les informations des nœuds**, ce nombre d’instances EC2 n’est pas dynamique. Il représente les résultats obtenus lors de la dernière analyse diagnostique signalée, sous la forme de la valeur du **Temps d’examen**. Nous recommandons donc d’exécuter régulièrement un examen diagnostique des instances EC2 non gérées afin de maintenir à jour le nombre déclaré de nœuds concernés.
Pour plus d’informations sur le nombre d’instances non gérées sur la page **Examiner les informations sur les nœuds**, consultez [Qu’est-ce qu’une instance non gérée ?](review-node-insights.md#unmanaged-instance-definition) dans la rubrique [Analyse des informations sur les nœuds](review-node-insights.md).
**Topics**
+ [
## Comment Systems Manager compte les nœuds concernés dans la liste des « Problèmes liés aux instances EC2 non gérées »
](#unmanaged-instance-scan-count)
+ [
# Catégories de problèmes qui peuvent être diagnostiqués sur les instances EC2 non gérées
](diagnosing-ec2-category-types.md)
+ [
# Exécuter un diagnostique et une correction facultative pour les instances EC2 non gérées
](running-diagnosis-execution-ec2.md)
+ [
# Planifier une analyse récurrent pour les instances EC2 non gérées
](schedule-recurring-ec2-diagnosis.md)
# Catégories de problèmes qui peuvent être diagnostiqués sur les instances EC2 non gérées
Cette rubrique répertorie les principales catégories de problèmes de gestion EC2, ainsi que les problèmes spécifiques de chaque catégorie, que Systems Manager peut vous aider à diagnostiquer et à résoudre. Notez que pour certains des problèmes, Systems Manager peut identifier le problème, mais ne fournit pas de remédiation automatique. Dans ce cas, la console Systems Manager vous dirige vers des informations qui vous aideront à résoudre manuellement le problème.
Le processus de diagnostic examine chaque groupe d’instances EC2 à la fois en fonction du cloud privé virtuel (VPC) auquel elles appartiennent.
**Topics**
+ [
## Catégorie de problème : configuration du groupe de sécurité et communications HTTPS
](#unmanaged-ec2-issue-security-groups)
+ [
## Catégorie de problème : configuration du DNS ou du nom d’hôte DNS
](#unmanaged-ec2-issue-dns-configuration)
+ [
## Catégorie de problème : configuration des points de terminaison d’un VPC
](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [
## Catégorie de problème : Configuration de l'ACL réseau
](#unmanaged-ec2-issue-nacl-configuration)
## Catégorie de problème : configuration du groupe de sécurité et communications HTTPS
Une opération de diagnostic peut découvrir que SSM Agent n’est pas en mesure de communiquer avec le service Systems Manager via HTTPS. Dans ce cas, vous pouvez choisir d’exécuter un dossier d’exploitation d’automatisation qui tente de mettre à jour les groupes de sécurité attachés aux instances.
**Note**
Il peut arriver que Systems Manager ne soit pas en mesure de remédier automatiquement à ces problèmes, mais vous pouvez modifier manuellement les groupes de sécurité concernés.
**Types de problèmes pris en charge**
+ **Groupe de sécurité de l’instance** : le trafic sortant n’est pas autorisé sur le port 443
+ **Groupe de sécurité du point de terminaison d’un VPC `ssm`** : le trafic entrant n’est pas autorisé sur le port 443
+ **Groupe de sécurité du point de terminaison d’un VPC `ssmmessages`** : trafic entrant non autorisé sur le port 443
+ **Groupe de sécurité du point de terminaison d’un VPC `ec2messages`** : trafic entrant non autorisé sur le port 443
Pour plus d’informations, consultez [Vérification des règles d’entrée sur les groupes de sécurité de point de terminaison](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules) dans la rubrique [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md).
## Catégorie de problème : configuration du DNS ou du nom d’hôte DNS
Une opération de diagnostic peut révéler que le système de noms de domaine (DNS) ou les noms d’hôtes DNS ne sont pas correctement configurés pour le VPC. Dans ces cas, vous pouvez choisir d’exécuter un dossier d’exploitation d’automatisation qui tente d’activer les attributs `enableDnsSupport` et `enableDnsHostnames` du VPC affecté.
**Types de problèmes pris en charge**
+ La prise en charge du DNS est désactivée dans un VPC.
+ Un nom d’hôte DNS est désactivé dans un VPC.
Pour plus d’informations, consultez [Vérification des attributs liés au DNS de votre VPC](troubleshooting-ssm-agent.md#agent-ts-dns-attributes) dans la rubrique [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md).
## Catégorie de problème : configuration des points de terminaison d’un VPC
Une opération de diagnostic peut révéler que les points terminaison d’un VPC ne sont pas correctement configurés pour le VPC.
Si les points de terminaison d’un VPC requis par SSM Agent n’existent pas, Systems Manager tente d’exécuter un dossier d’exploitation d’automatisation pour créer les points de terminaison d’un VPC et les associer à un sous-réseau dans chaque zone de disponibilité (AZ) régionale concernée. Si les points terminaison d’un VPC requis existent mais ne sont pas associés à un sous-réseau dans lequel le problème est détecté, le dossier d’exploitation associe les points terminaison d’un VPC au sous-réseau concerné.
**Note**
Systems Manager ne permet pas de remédier à tous les points de terminaison d’un VPC mal configurés. Dans ces cas, Systems Manager vous oriente vers des instructions de remédiation manuelles au lieu d’exécuter un dossier d’exploitation d’automatisation.
**Types de problèmes pris en charge**
+ Aucun `ssm.region.amazonaws.com` point de terminaison pour n' PrivateLink a été trouvé.
+ Aucun `ssmmessages.region.amazonaws.com` point de terminaison pour n' PrivateLink a été trouvé.
+ Aucun `ec2messages.region.amazonaws.com` point de terminaison pour n' PrivateLink a été trouvé.
**Types de problèmes pouvant être diagnostiqués**
Systems Manager peut diagnostiquer les types de problèmes suivants, mais aucun dossier d’exploitation n’est actuellement disponible pour y remédier. Vous pouvez modifier votre configuration manuellement pour ces problèmes.
+ Le sous-réseau d’une instance n’est pas attaché à un point de terminaison `ssm.region.amazonaws.com`.
+ Le sous-réseau d’une instance n’est pas attaché à un point de terminaison `ssmmessages.region.amazonaws.com`.
+ Le sous-réseau d’une instance n’est pas attaché à un point de terminaison `ec2messages.region.amazonaws.com`.
Pour plus d’informations, consultez [Vérification de votre configuration VPC](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration) dans la rubrique [Résolution des problèmes de SSM Agent](troubleshooting-ssm-agent.md).
## Catégorie de problème : Configuration de l'ACL réseau
Une opération de diagnostic peut détecter que les listes de contrôle d'accès réseau (NACLs) ne sont pas correctement configurées pour le VPC, bloquant ainsi le trafic nécessaire à la communication avec Systems Manager. NACLs sont apatrides, de sorte que les règles sortantes et entrantes doivent autoriser le trafic de Systems Manager.
Systems Manager peut identifier les problèmes de configuration de la NACL et fournir des conseils pour les corriger manuellement.
**Types de problèmes pris en charge**
+ **Sous-réseau d'instance NACL** : le trafic sortant n'est pas autorisé sur le port 443 vers les points de terminaison Systems Manager
+ **Sous-réseau d'instance NACL** : le trafic entrant n'est pas autorisé sur les ports éphémères (1024-65535) pour les réponses de Systems Manager
**Types de problèmes pouvant être diagnostiqués**
Systems Manager peut diagnostiquer les problèmes de configuration NACL suivants, mais une correction manuelle est nécessaire :
+ La NACL du sous-réseau d'une instance bloque le trafic HTTPS sortant (port 443) vers les points de terminaison de Systems Manager
+ La NACL du sous-réseau d'une instance bloque le trafic portuaire éphémère entrant (1024-65535) requis pour les réponses de Systems Manager
Pour plus d'informations, consultez les sections [Résolution des problèmes liés à l'agent SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html) et [Réseau personnalisé ACLs pour votre VPC.](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports)
# Exécuter un diagnostique et une correction facultative pour les instances EC2 non gérées
Utilisez la procédure suivante pour diagnostiquer les problèmes liés au réseau et au VPC susceptibles d’empêcher Systems Manager de gérer vos instances EC2.
L’opération de diagnostic permet de détecter et de regrouper les problèmes suivants :
+ **Problèmes de configuration réseau** : types de problèmes réseau susceptibles d’empêcher les instances EC2 de communiquer avec le service Systems Manager dans le cloud. Des opérations correctives peuvent être disponibles pour ces problèmes. Pour plus d’informations sur les problèmes de configuration réseau, consultez [Catégories de problèmes qui peuvent être diagnostiqués sur les instances EC2 non gérées](diagnosing-ec2-category-types.md).
+ **Problèmes non identifiés** : une liste des constatations pour les cas où l’opération de diagnostic n’a pas permis de déterminer pourquoi les instances EC2 ne sont pas en mesure de communiquer avec le service gestionnaire de systèmes dans le cloud.
**Pour exécuter un diagnostique et une correction pour les instances EC2 non géré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 **Diagnostiquer et remédier**.
1. Sélectionnez l’onglet **Problème relatif aux instances EC2 non gérées**.
1. Dans la section **Résumé du problème**, sélectionnez **Exécuter un nouveau diagnostic**.
-ou-
Si c’est la première fois que vous diagnostiquez des problèmes EC2 non gérés, dans la section **Diagnostiquer les instances EC2 non gérées**, sélectionnez **Exécuter**.
**Astuce**
Lors de l’exécution du diagnostic, sélectionnez **Afficher la progression** ou **Afficher les exécutions** pour surveiller l’état actuel de l’exécution. Pour de plus amples informations, veuillez consulter [Affichage de la progression et de l’historique de l’exécution des mesures correctives dans Systems Manager](diagnose-and-remediate-execution-history.md).
1. Une fois que le diagnostic est terminé, procédez comme suit :
+ Pour tout problème signalé dans la section **Problèmes non identifiés**, sélectionnez le lien **En savoir plus** pour obtenir des informations sur la résolution du problème.
+ Pour les problèmes signalés dans la section **Problèmes de configuration réseau**, passez à l’étape suivante.
1. Dans la liste des types de recherche, dans la colonne **Recommandations**, pour un problème particulier, sélectionnez le lien, par exemple **2 recommandations**.
1. Dans le volet **Recommandations** qui s’ouvre, sélectionnez parmi les mesures d’atténuation disponibles :
+ **En savoir plus** : ouvrez une rubrique contenant des informations sur la manière de résoudre un problème manuellement.
+ **Afficher le dossier d’exploitation** : ouvrez un volet contenant des informations sur le dossier d’exploitation d’automatisation que vous pouvez exécuter pour résoudre le problème lié à vos instances EC2, ainsi que des options permettant de générer un *aperçu* des actions que le dossier d’exploitation doit effectuer. Procédez avec l’étape suivante.
1. Dans le volet dossier d’exploitation, procédez de la façon suivante :
1. Pour **Description du document**, consultez le contenu, qui fournit une vue d’ensemble des actions que le dossier d’exploitation peut entreprendre pour résoudre les problèmes liés à vos instances EC2 non gérées. Sélectionnez **Afficher les étapes** pour prévisualiser les actions individuelles que le dossier d’exploitation doit effectuer.
1. Pour **Targets (Cibles)**, procédez comme suit :
+ Si vous gérez des mesures correctives pour une organisation, pour **Comptes**, spécifiez si ce dossier d’exploitation ciblera tous les comptes ou uniquement un sous-ensemble de comptes de votre choix.
+ Pour **les régions**, précisez si ce runbook ciblera tous les membres Régions AWS de votre compte ou de votre organisation, ou uniquement un sous-ensemble des régions de votre choix.
1. Pour **Aperçu du dossier d’exploitation**, lisez attentivement les informations. Ces informations expliquent la portée et l’impact que vous pourriez avoir si vous choisissiez d’exécuter le dossier d’exploitation.
**Note**
Choisir d’exécuter le dossier d’exploitation entraînerait des frais. Vérifiez attentivement les informations de l’aperçu avant de décider si vous souhaitez continuer.
Le contenu de l’**Aperçu du dossier d’exploitation** fournit les informations suivantes :
+ Dans combien de régions l’opération dossier d’exploitation aurait lieu.
+ (Organisations uniquement) Combien d'unités organisationnelles (OUs) l'opération serait exécutée.
+ Les types de mesures qui seraient prises et le nombre de chacune d’entre elles.
Les types d’actions sont les suivants :
+ **Mutant** : l’étape du dossier d’exploitation modifierait les cibles par le biais d’actions qui créent, modifient ou suppriment des ressources.
+ **Non mutant** : l’étape du dossier d’exploitation récupérerait des données sur les ressources, mais de les modifierait pas. Cette catégorie inclut généralement `Describe*`, `List*`, `Get*` et les actions d’API similaires en lecture seule.
+ **Indéterminé** : une étape indéterminée invoque des exécutions effectuées par un autre service d'orchestration tel que AWS Lambda AWS Step Functions, ou Run Command. AWS Systems Manager Une étape indéterminée peut également appeler une API tierce. Systems Manager Automation ne connaît pas le résultat des processus d’orchestration ou des exécutions d’API tierces. Les résultats des étapes sont donc indéterminés.
1. À ce stade, vous pouvez sélectionner l’une des actions suivantes :
+ Arrêter et ne pas exécuter le dossier d’exploitation.
+ Sélectionner **Exécuter** pour exécuter le dossier d’exploitation avec les options que vous avez déjà sélectionnées.
Si vous choisissez d’exécuter l’opération, sélectionnez **Afficher la progression** ou **Afficher les exécutions** pour surveiller l’état actuel de l’exécution. Pour de plus amples informations, veuillez consulter [Affichage de la progression et de l’historique de l’exécution des mesures correctives dans Systems Manager](diagnose-and-remediate-execution-history.md).
# Planifier une analyse récurrent pour les instances EC2 non gérées
Vous pouvez exécuter une analyse à la demande pour les instances Amazon EC2 de votre compte ou de votre organisation que Systems Manager n’est pas en mesure de gérer en raison de divers problèmes de configuration. Vous pouvez également planifier cette analyse pour qu’elle s’exécute régulièrement de façon automatique.
**Pour planifier un scan récurrent pour les instances EC2 non géré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 **Diagnostiquer et remédier**.
1. Sélectionnez l’onglet **Problème relatif aux instances EC2 non gérées**.
1. Dans la section **Diagnostiquer les instances EC2 non gérées**, activez **Planifier un diagnostic récurrent**.
1. Pour **Fréquence du diagnostic**, indiquez si vous souhaitez exécuter le diagnostic une fois par jour ou une fois par semaine.
1. (Facultatif) Pour **Heure de début**, saisissez l’heure (au format 24 heures) à laquelle vous souhaitez que le diagnostic débute. Par exemple, pour 20 h 15, saisissez **20:15**.
L’heure que vous saisissez correspond à votre fuseau horaire local actuel.
Si vous ne spécifiez pas d’heure, l’analyse diagnostique s’exécute immédiatement. Systems Manager programme également l’analyse de sorte que les futures exécutions débutent à l’heure actuelle. Si vous spécifiez une heure, Systems Manager attend l’heure spécifiée pour exécuter l’analyse diagnostique.
1. Sélectionnez **Execute (Exécuter)**. Le diagnostic s’exécute immédiatement, mais il sera également exécuté selon le calendrier que vous avez spécifié.
# Les mesures correctives ont un impact sur les types d’actions du dossier d’exploitation
Systems Manager peut exécuter des opérations de diagnostic qui découvrent certains types de déploiements ayant échoué et des configurations dérivées, ainsi que certains types de problèmes de configuration qui empêchent Systems Manager de gérer les instances EC2. Les résultats du diagnostic peuvent inclure des recommandations pour les dossiers d’exploitation d’automatisation que vous pouvez exécuter pour tenter de résoudre un problème. Pour plus d’informations sur ces opérations de diagnostic, consultez les sujets suivants :
+ [Diagnostic et correction des déploiements échoués](remediating-deployment-issues.md)
+ [Diagnostic et correction des configurations dérivées](remediating-configuration-drift.md)
+ [Diagnostiquer et corriger des instances Amazon EC2 non gérées dans Systems Manager](remediating-unmanaged-instances.md)
Lorsque Systems Manager identifie un problème susceptible d’être résolu en exécutant un dossier d’exploitation d’automatisation sur les ressources concernées, il vous fournit un *aperçu d’exécution*. L’aperçu d’exécution fournit des informations sur les *types* de modifications que l’exécution du dossier d’exploitation apporterait à vos cibles. Ces informations incluent le nombre de changements identifiés par le diagnostic pour chacun des trois types.
Ces types de modifications sont les suivants :
+ `Mutating`: Une étape de dossier d’exploitation modifierait les cibles par le biais d’actions qui créent, modifient ou suppriment des ressources.
+ `Non-Mutating`: Une étape de dossier d’exploitation récupérerait des données sur les ressources mais ne les modifierait pas. Cette catégorie inclut généralement `Describe*`, `List*`, `Get*` et les actions d’API similaires en lecture seule.
+ `Undetermined`: Une étape indéterminée invoque des exécutions effectuées par un autre service d'orchestration AWS Lambda, tel que, ou AWS Step FunctionsRun Command, un outil dans. AWS Systems Manager Une étape indéterminée peut également appeler une API tierce ou exécuter un Python ou un PowerShell script. Systems Manager Automation ne peut pas détecter le résultat des processus d’orchestration ou des exécutions d’API tierces, et ne peut donc pas les évaluer. Les résultats de ces étapes devraient être examinés manuellement pour en déterminer l’impact.
Consultez le tableau suivant pour plus d’informations sur le type d’impact des actions d’automatisation prises en charge.
## Types d’impact des actions correctives prises en charge
Le tableau présente le type d’impact (mutant, non mutant et indéterminé) des différentes actions qui peuvent être incluses dans un dossier d’exploitation correctif.
| Action¹ | Type d'impact |
| --- | --- |
| aws:approve | Non mutant |
| lois : assertAwsResource Propriété | Non mutant |
| aws:branch | Non mutant |
| lois : changeInstanceState | Mutant |
| aws:copyImage | Mutant |
| aws:createImage | Mutant |
| aws:createStack | Mutant |
| aws:createTags | Mutant |
| aws:deleteImage | Mutant |
| aws:deleteStack | Mutant |
| aws:executeAutomation | Indéterminé |
| lois : executeAwsApi | Indéterminé |
| aws:executeScript | Indéterminé |
| lois : executeStateMachine | Indéterminé |
| lois : invokeLambdaFunction | Indéterminé |
| aws:invokeWebhook | Indéterminé |
| aws:loop | Variable. Cela dépend des actions dans la boucle. |
| aws:pause | Non mutant |
| aws:runCommand | Indéterminé |
| aws:runInstances | Mutant |
| aws:sleep | Non mutant |
| aws:updateVariable | Mutant |
| lois : waitForAws ResourceProperty | Non mutant |
¹ Pour de plus amples informations sur les actions d’automatisation, consulter [Référence sur les actions Systems Manager Automation](automation-actions.md).
# Affichage de la progression et de l’historique de l’exécution des mesures correctives dans Systems Manager
Affichage des détails de l’historique d’exécution des mesures correctives
Vous pouvez répertorier toutes les opérations de remédiation en cours et terminées effectuées à l’aide de la fonctionnalité **Diagnostiquer et remédier** de Systems Manager.
Les données répertoriées dans la liste de l’historique des exécutions rapportent les types d’informations suivants :
+ Le type d’exécution, `Diagnosis` ou `Remediation`.
+ Le statut de l’exécution, tel que `Success` ou `Failed`.
+ Les heures de début et de fin de l’exécution.
**Pour afficher la progression de l’exécution et l’historique des mesures correctives**
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 **Diagnostiquer et remédier**.
1. Sélectionnez **Afficher les exécutions**.
**Astuce**
Lorsqu’une exécution est en cours, vous pouvez également sélectionner **Afficher la progression** pour ouvrir la page **Historique de l’exécution**.
1. (Facultatif) Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), saisissez une phrase pour aider à réduire la liste des exécutions, telle que **EC2** ou **VPC**.
1. (Facultatif) Pour afficher des informations supplémentaires sur une exécution, dans la colonne **Nom de l'exécution**, choisissez un nom d'opération, tel que **AWS- DiagnoseUnmanaged EC2 NetworkIssues**.
Dans le volet des détails, vous pouvez consulter des informations sur toutes les étapes tentées au cours de l’opération, ainsi que sur toutes les entrées et sorties de l’exécution.
# Réglage des paramètres de Systems Manager
Les options des pages **Paramètres** activent et configurent les fonctionnalités dans la console unifiée Systems Manager. Les options affichées dépendent du compte auquel vous avez établi une connexion, et si vous avez déjà configuré Systems Manager ou non.
**Note**
Les options de la page **Paramètres** n’affectent pas les outils Systems Manager (anciennement nommés fonctionnalités).
## Paramètres de configuration de compte
Si Systems Manager est activé, et si vous avez établi une connexion à un compte qui n’est pas membre d’Organizations ou si l’administrateur délégué n’a pas ajouté votre compte Organizations à Systems Manager, la page **Configuration de compte** affiche l’option permettant de **désactiver Systems Manager**. La désactivation de Systems Manager signifie que Systems Manager n’affiche pas la console unifiée. Tous les outils Systems Manager fonctionnent toujours.
## Paramètres de configuration organisationnelle
Dans l'onglet **Configuration organisationnelle**, la section **Région d'origine** affiche la région Région AWS choisie comme région d'origine lors de la configuration. Dans les environnements multicomptes et multirégionaux qui l'utilisent AWS Organizations, Systems Manager agrège automatiquement les données des nœuds de tous les comptes et régions vers la région d'origine. De cette manière, l’agrégation des données vous permet de visualiser en un seul endroit les données des nœuds de divers comptes et régions.
**Note**
Si vous souhaitez modifier la région d’origine, vous devez désactiver Systems Manager, puis le réactiver. Pour désactiver Systems Manager, choisissez **Désactiver**.
La section **Configuration organisationnelle** affiche les unités AWS organisationnelles Régions AWS choisies lors de la configuration. Pour modifier les unités organisationnelles et les régions qui affichent les données de nœuds dans Systems Manager, choisissez **Modifier**. Pour plus d’informations sur la configuration de Systems Manager pour Organizations, consultez la section [Configuration de AWS Systems Manager](systems-manager-setting-up-console.md).
## Configurations des fonctionnalités
La section **Configurations des fonctionnalités** vous permet d’activer et de configurer les fonctionnalités clés de Systems Manager qui améliorent la gestion des nœuds au sein de votre organisation. Ces fonctionnalités travaillent ensemble pour fournir une gestion automatisée, une surveillance de la conformité et une maintenance de vos nœuds gérés.
Vous pouvez configurer ces fonctionnalités lors de la configuration initiale de Systems Manager, ou les modifier ultérieurement via la page Paramètres. Chaque fonctionnalité peut être activée ou désactivée indépendamment, en fonction des besoins de votre organisation.
### Configuration de gestion des hôtes par défaut
La configuration DHMC (configuration de gestion d’hôte par défaut) configure automatiquement les instances Amazon Elastic Compute Cloud (Amazon EC2) de votre organisation pour qu’elles soient gérées par Systems Manager. Lorsqu'elle est activée, DHMC garantit que les instances EC2 nouvelles et existantes disposent des autorisations Gestion des identités et des accès AWS (IAM) et des configurations nécessaires pour communiquer avec les services Systems Manager.
DHMC offre les avantages suivants :
+ **Attribution automatique des rôles IAM** : garantit que les instances EC2 disposent des rôles et politiques IAM requis pour fonctionner en tant que nœuds gérés
+ **Correction de la dérive** : corrige automatiquement les dérives de configuration lorsque les instances perdent leur statut de nœud géré
+ **Intégration simplifiée** : réduit les étapes de configuration manuelle pour les nouvelles instances
+ **Configuration cohérente** : maintient des paramètres uniformes sur l’ensemble de votre flotte EC2
#### Configuration de la fréquence de correction des dérives
La correction des dérives détecte et corrige automatiquement les instances EC2 lorsqu’elles perdent leur configuration de nœud géré. Vous pouvez configurer la fréquence à laquelle Systems Manager vérifie et corrige les dérives de configuration.
**Configurer la configuration de gestion des hôtes 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 **Settings** (Paramètres).
1. Dans la section **Configurations des fonctionnalités**, recherchez **Configuration de gestion d’hôte par défaut**.
1. Pour activer DHMC, activez la bascule.
1. Pour **Fréquence de correction des dérives**, choisissez la fréquence à laquelle vous souhaitez que Systems Manager vérifie et corrige les dérives de configuration :
+ **Tous les jours** : vérifie et corrige les dérives une fois par jour
+ **Hebdomadaire** : vérifie et corrige les dérives une fois par semaine
+ **Mensuelle** : vérifie et corrige les dérives une fois par mois
1. Choisissez **Enregistrer**.
**Note**
Lorsque vous activez DHMC, Systems Manager crée les rôles et politiques IAM nécessaires dans votre compte. Ces rôles permettent aux instances EC2 de communiquer avec les services Systems Manager. Pour plus d’informations sur les rôles IAM créés par DHMC, consultez [Gestion des instances EC2 avec Systems Manager](systems-manager-setting-up-ec2.md).
### Collecte des métadonnées d’inventaire
La collecte de métadonnées d’inventaire rassemble automatiquement des informations détaillées sur vos nœuds gérés, notamment les applications installées, les configurations réseau, les mises à jour du système et les autres métadonnées du système. Ces informations vous aident à maintenir la conformité, effectuer des analyses de sécurité et comprendre la composition de votre infrastructure.
La collecte d’inventaire offre les avantages suivants :
+ **Surveillance de la conformité** : suivez les logiciels installés et les configurations pour les rapports de conformité
+ **Analyse de sécurité** : identifiez les logiciels obsolètes et les vulnérabilités de sécurité potentielles
+ **Gestion des actifs** - Tenez un up-to-date inventaire de votre infrastructure
+ **Capacités de requête** : utilisez les données collectées avec Amazon Q Developer pour les requêtes en langage naturel
#### Types de données d’inventaire collectés
Lorsque la collecte des métadonnées d’inventaire est activée, Systems Manager collecte les types d’informations suivants auprès de vos nœuds gérés :
+ **Applications** : packages logiciels et applications installés
+ **Configurations réseau** : interfaces réseau, adresses IP et paramètres réseau
+ **Mises à jour du système** : correctifs installés et mises à jour disponibles
+ **Propriétés du système** : spécifications matérielles, détails du système d’exploitation et configurations du système
+ **Services** : services en cours d’exécution et leurs configurations
#### Configuration de la fréquence de collecte d’inventaire
Vous pouvez configurer la fréquence à laquelle Systems Manager collecte les métadonnées d’inventaire à partir de vos nœuds gérés. Une collecte plus fréquente fournit plus d' up-to-dateinformations mais peut augmenter l'utilisation du AWS service.
**Configurer une collecte de métadonnées 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 panneau de navigation, sélectionnez **Settings** (Paramètres).
1. Dans la section **Configurations des fonctionnalités**, recherchez **Collecte des métadonnées d’inventaire**.
1. Pour activer la collecte d’inventaire, activez la bascule.
1. Pour **Fréquence de collecte**, choisissez la fréquence à laquelle vous souhaitez que Systems Manager collecte les données d’inventaire :
+ **Quotidienne** : collecte les données d’inventaire une fois par jour
+ **Hebdomadaire** : collecte les données d’inventaire une fois par semaine
+ **Mensuelle** : collecte les données d’inventaire une fois par mois
1. Choisissez **Enregistrer**.
**Important**
La collecte d’inventaire nécessite que les nœuds gérés disposent des autorisations nécessaires pour collecter les informations du système. Assurez-vous que vos nœuds gérés ont les rôles et stratégies IAM appropriés. Pour plus d’informations sur les autorisations requises, consultez [AWS Systems Manager Inventory](systems-manager-inventory.md).
### Mises à jour d'SSM Agent
Les mises à jour automatiques de SSM Agent garantissent que vos nœuds gérés exécutent la dernière version de SSM Agent. Le fait de conserver l'agent up-to-date permet d'accéder aux dernières fonctionnalités, aux améliorations de sécurité et aux corrections de bogues.
Les mises à jour automatiques de SSM Agent offrent les avantages suivants :
+ **Dernières fonctionnalités** : accès aux nouvelles fonctionnalités et améliorations de Systems Manager
+ **Mises à jour de sécurité** : installation automatique des correctifs de sécurité
+ **Fiabilité améliorée** : corrections de bogues et améliorations de la stabilité
+ **Maintenance réduite** : élimine le besoin de mise à jour manuelle des agents
#### Configuration des mises à jour automatiques de l’agent
Vous pouvez configurer la fréquence à laquelle Systems Manager vérifie et installe les mises à jour de SSM Agent sur vos nœuds gérés. Des mises à jour régulières permettent de garantir des performances et une sécurité optimales.
**Configurer les mises à jour de SSM Agent**
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 **Settings** (Paramètres).
1. Dans la section **Configurations des fonctionnalités**, recherchez **Mises à jour de SSM Agent**.
1. Pour activer les mises à jour automatiques, activez la bascule.
1. Pour **Fréquence des mises à jour**, choisissez la fréquence à laquelle vous souhaitez que Systems Manager vérifie et installe les mises à jour des agents :
+ **Quotidien** : vérifie les mises à jour une fois par jour
+ **Hebdomadaire** : vérifie les mises à jour une fois par semaine
+ **Mensuel** : vérifie les mises à jour une fois par mois
1. Choisissez **Enregistrer**.
## Diagnostic et résolution des problèmes
Les paramètres de **diagnostic et de résolution des problèmes** déterminent si Systems Manager analyse automatiquement vos nœuds pour s’assurer qu’ils peuvent communiquer avec Systems Manager. Si la fonctionnalité est activée, elle s’exécute automatiquement selon le programme que vous définissez. Cette fonctionnalité identifie les nœuds qui ne peuvent pas se connecter à Systems Manager ainsi que la cause sous‑jacente. Cette fonctionnalité fournit également des dossiers d’exploitation recommandés pour résoudre divers problèmes, en particulier les problèmes de réseau, qui bloquent la configuration des nœuds en tant que nœuds gérés.
### Planification d’une analyse diagnostique récurrente
Systems Manager peut diagnostiquer et vous aider à résoudre différents types de problèmes de déploiement et de configurations ayant dérivé. Systems Manager peut également identifier les instances Amazon Elastic Compute Cloud (Amazon EC2) de votre compte ou organisation que Systems Manager n’est pas en mesure de traiter comme un *nœud géré*. Le processus de diagnostic des instances EC2 permet d’identifier les problèmes liés à des erreurs de configuration au sein d’un cloud privé virtuel (VPC), d’un paramètre DNS (Domain Name Service) ou d’un groupe de sécurité Amazon Elastic Compute Cloud (Amazon EC2).
Pour simplifier la tâche d’identification des nœuds qui ne peuvent pas se connecter à Systems Manager, la fonctionnalité **Planifier un diagnostic récurrent** vous permet d’automatiser une analyse diagnostique récurrente. Les analyses permettent d’identifier les nœuds qui ne peuvent pas se connecter à Systems Manager ainsi que la cause sous‑jacente. Utilisez la procédure suivante pour activer et configurer une analyse diagnostique récurrente de vos nœuds.
**Pour planifier une analyse diagnostique récurrente**
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, choisissez **Paramètres**, puis sélectionnez l’onglet **Diagnostiquer et corriger**.
1. Activez l’option **Planifier un diagnostic récurrent**.
1. Pour **Période d’analyse**, choisissez la fréquence à laquelle vous souhaitez exécuter l’analyse.
1. (Facultatif) Pour **Heure de début**, saisissez l’heure (au format 24 heures) à laquelle vous souhaitez que le diagnostic débute. Par exemple, pour 20 h 15, saisissez **20:15**.
L’heure que vous saisissez correspond à votre fuseau horaire local actuel.
Si vous ne spécifiez pas d’heure, l’analyse diagnostique s’exécute immédiatement. Systems Manager programme également l’analyse de sorte que les futures exécutions débutent à l’heure actuelle. Si vous spécifiez une heure, Systems Manager attend l’heure spécifiée pour exécuter l’analyse diagnostique.
1. Choisissez **Enregistrer**.
1. Une fois l’analyse terminée, consultez les détails en choisissant **Diagnostiquer et corriger** dans le menu de navigation de gauche.
Pour plus d’informations sur la fonctionnalité **Diagnostiquer et corriger**, consultez la section [Diagnostiquer et remédier](diagnose-and-remediate.md).
### Mise à jour du chiffrement du compartiment S3
Lorsque vous intégrez Systems Manager, Quick Setup crée un bucket Amazon Simple Storage Service (Amazon S3) dans le compte AWS Organizations administrateur délégué pour les configurations. Pour les configurations de compte individuel, le compartiment est stocké dans le compte en cours de configuration. Ce compartiment est utilisé pour stocker les métadonnées générées lors des analyses diagnostiques.
Pour plus d’informations sur la configuration de la console unifiée Systems Manager, consultez [Configuration de AWS Systems Manager](systems-manager-setting-up-console.md).
Par défaut, les données du compartiment sont chiffrées à l'aide d'une clé AWS Key Management Service (AWS KMS) qui vous AWS appartient et qui est gérée pour vous.
Vous pouvez choisir d'utiliser une autre AWS KMS clé pour le chiffrement de votre compartiment. Vous pouvez également utiliser le chiffrement côté serveur avec AWS KMS keys (SSE-KMS) à l'aide d'une clé gérée par le client (CMK). Pour plus d'informations, consultez [Utilisation des compartiments Amazon S3 et des politiques de compartiment pour Systems Manager](systems-manager-diagnosis-metadata-bucket.md).
**Pour utiliser une autre AWS KMS clé pour le chiffrement du compartiment S3**
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, choisissez **Paramètres**, puis sélectionnez l’onglet **Diagnostiquer et corriger**.
1. Dans la zone **Mettre à jour le chiffrement du compartiment S3**, choisissez **Modifier**.
1. Cochez la case **Personnaliser les paramètres de chiffrement (avancé)**.
1. Pour **Choisir une AWS KMS clé**, choisissez ou entrez le nom de ressource Amazon (ARN) de la clé.
**Astuce**
Pour créer une nouvelle clé, choisissez **Créer une clé AWS KMS **.
1. Choisissez **Enregistrer**.
# Utilisation des compartiments Amazon S3 et des politiques de compartiment pour Systems Manager
Au cours du [processus d'intégration](systems-manager-setting-up-console.md) de AWS Systems Manager, Quick Setup crée un compartiment Amazon Simple Storage Service (Amazon S3) dans le compte d'administrateur délégué pour les configurations de l'organisation. Pour les configurations de compte individuel, le compartiment est stocké dans le compte en cours de configuration.
Vous pouvez utiliser Systems Manager pour exécuter des opérations de diagnostic sur votre flotte afin d’identifier les échecs de déploiements et les configurations ayant dérivé. Systems Manager peut également détecter les cas où des problèmes de configuration empêchent Systems Manager de gérer les instances EC2 de votre compte ou organisation. Les résultats de ces opérations de diagnostic sont stockés dans ce compartiment Amazon S3, qui est protégé par une méthode de chiffrement et une politique de compartiment S3. Pour plus d’informations sur les opérations de diagnostic qui génèrent des données vers ce compartiment, consultez la section [Diagnostiquer et remédier](diagnose-and-remediate.md).
**Modification de la méthode de chiffrement du compartiment**
Par défaut, le compartiment S3 utilise le chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3).
Vous pouvez plutôt utiliser le chiffrement côté serveur avec AWS KMS keys (SSE-KMS) à l'aide d'une clé gérée par le client (CMK) comme alternative aux clés gérées par Amazon S3, comme expliqué dans. [Passage à une clé gérée par le AWS KMS client pour chiffrer les ressources S3](remediate-s3-bucket-encryption.md)
**Contenu de la politique de compartiment**
La politique de compartiment empêche les comptes membres d’une organisation de se découvrir les uns les autres. Les autorisations de lecture et d’écriture sur le compartiment ne sont autorisées que pour les rôles de diagnostic et de résolution des problèmes créés pour Systems Manager. Le contenu de ces politiques générées par le système est présenté dans la section [Stratégies de compartiment S3 pour la console unifiée Systems Manager](remediate-s3-bucket-policies.md).
**Avertissement**
La modification de la politique de compartiment par défaut peut permettre aux comptes membres d’une organisation de se découvrir les uns les autres ou de lire les sorties de diagnostic des instances d’un autre compte. Nous vous recommandons de faire preuve d’une extrême prudence si vous choisissez de modifier cette politique.
**Topics**
+ [
# Passage à une clé gérée par le AWS KMS client pour chiffrer les ressources S3
](remediate-s3-bucket-encryption.md)
+ [
# Stratégies de compartiment S3 pour la console unifiée Systems Manager
](remediate-s3-bucket-policies.md)
# Passage à une clé gérée par le AWS KMS client pour chiffrer les ressources S3
Au cours du processus d’intégration à la console unifiée Systems Manager, Quick Setup crée un compartiment Amazon Simple Storage Service (Amazon S3) dans le compte administrateur délégué. Ce compartiment est utilisé pour stocker les données de sortie de diagnostic générées lors des exécutions de dossier d’exploitation de réparation. Par défaut, le compartiment utilise le chiffrement côté serveur avec des clés gérées par Amazon S3 (SSE-S3).
Vous pouvez consulter le contenu de ces politique dans [Stratégies de compartiment S3 pour la console unifiée Systems Manager](remediate-s3-bucket-policies.md).
Cependant, vous pouvez plutôt utiliser le chiffrement côté serveur avec AWS KMS keys (SSE-KMS) à l'aide d'une clé gérée par le client (CMK) comme alternative à un. AWS KMS key
Effectuez les tâches suivantes afin de configurer Systems Manager pour qu’il utilise votre clé CMK.
## Tâche 1 : ajouter une balise à une clé CMK existante
AWS Systems Manager utilise votre clé CMK uniquement si elle est étiquetée avec la paire clé-valeur suivante :
+ Clé : `SystemsManagerManaged`
+ Valeur : `true`
Utilisez la procédure suivante pour fournir un accès permettant de chiffrer le compartiment S3 avec votre clé CMK.
**Pour ajouter une balise à votre clé CMK existante**
1. Ouvrez la AWS KMS console à l'adresse [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Dans le volet de navigation de gauche, choisissez **Clés gérées par le client**.
1. Sélectionnez le AWS KMS key à utiliser avec AWS Systems Manager.
1. Choisissez l’onglet **Balises**, et ensuite **Modifier**.
1. Choisissez **Ajouter une balise**.
1. Procédez comme suit :
1. Pour le champ **Tag key (Clé de balise)**, entrez **SystemsManagerManaged**.
1. Pour **Valeur de la balise**, saisissez **true**.
1. Choisissez **Enregistrer**.
## Tâche 2 : modifier une stratégie de clé CMK existante
Utilisez la procédure suivante pour mettre à jour la [politique de clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) de votre clé CMK afin de permettre aux AWS Systems Manager rôles de chiffrer le compartiment S3 en votre nom.
**Pour modifier une stratégie de clé CMK existante**
1. Ouvrez la AWS KMS console à l'adresse [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms)
1. Dans le volet de navigation de gauche, choisissez **Clés gérées par le client**.
1. Sélectionnez le AWS KMS key à utiliser avec AWS Systems Manager.
1. Dans l'onglet **Stratégie de clé** choisissez **Modifier**.
1. Ajoutez l'instruction JSON suivante au `Statement` champ et remplacez-la *placeholder values* par vos propres informations.
Assurez-vous d'ajouter sur le Compte AWS IDs terrain tout ce qui est intégré dans votre organisation. AWS Systems Manager `Principal`
Pour trouver le nom du compartiment correct dans la console Amazon S3, dans le compte d’administrateur délégué, localisez le compartiment au format `do-not-delete-ssm-operational-account-id-home-region-disambiguator`.
```
{
"Sid": "EncryptionForSystemsManagerS3Bucket",
"Effect": "Allow",
"Principal": {
"AWS": [
"account-id-1",
"account-id-2",
...
]
},
"Action": ["kms:Decrypt", "kms:GenerateDataKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/AWS-SSM-*"
}
}
}
```
**Astuce**
Vous pouvez également mettre à jour la politique relative aux clés CMK à l'aide de la clé de condition [aws : PrincipalOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) pour autoriser l' AWS Systems Manager accès à votre clé CMK.
## Tâche 3 : spécifier le CMK dans les paramètres de Systems Manager
Après avoir effectué les deux tâches précédentes, suivez la procédure suivante pour modifier le chiffrement du compartiment S3. Cette modification garantit que le processus de configuration Quick Setup associé peut ajouter des autorisations permettant à Systems Manager d’accepter votre clé CMK.
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 **Settings** (Paramètres).
1. Dans l’onglet **Diagnostiquer et corriger**, dans la section **Mettre à jour le chiffrement du compartiment S3**, sélectionnez **Modifier**.
1. Cochez la case **Personnaliser les paramètres de chiffrement (avancé)**.
1. Dans la zone de recherche (![\[The search icon\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/search-icon.png)), sélectionnez l’ID d’une clé existante ou collez l’ARN d’une clé existante.
1. Choisissez **Enregistrer**.
# Stratégies de compartiment S3 pour la console unifiée Systems Manager
Cette rubrique inclut les politiques relatives aux compartiments Amazon S3 créées par Systems Manager lorsque vous intégrez une organisation ou un compte unique à la console unifiée Systems Manager.
**Avertissement**
La modification de la politique de compartiment par défaut peut permettre aux comptes membres d’une organisation de se découvrir les uns les autres ou de lire les sorties de diagnostic des instances d’un autre compte. Nous vous recommandons de faire preuve d’une extrême prudence si vous choisissez de modifier cette politique.
## Stratégie de compartiment Amazon S3 pour une organisation
Le compartiment de diagnostic est créé avec la politique de compartiment par défaut suivante lors de l’intégration d’une organisation à Systems Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
},
{
"Sid": "AllowAccessLog",
"Effect": "Allow",
"Principal": {
"Service": "logging.s3.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/access-logs/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "000000000000"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
},
{
"Sid": "AllowCrossAccountRead",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
},
{
"Sid": "AllowCrossAccountWrite",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/AWS-SSM-DiagnosisExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-DiagnosisAdminRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationAdminRole-operational-123456789012-home-region"
]
}
}
},
{
"Sid": "AllowCrossAccountListUnderAccountOwnPrefix",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"StringLike": {
"s3:prefix": "*/${aws:PrincipalAccount}/*"
}
}
},
{
"Sid": "AllowCrossAccountGetConfigWithinOrganization",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetEncryptionConfiguration",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
}
]
}
```
------
## Stratégie de compartiment Amazon S3 pour un seul compte
Le compartiment de diagnostic est créé avec la politique de compartiment par défaut suivante lors de l’intégration d’un seul compte à Systems Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
}
]
}
```
------