Fonctionnement d’AWS Systems Manager avec IAM - AWS Systems Manager
Systems ManagerPolitiques basées sur l'identité Systems ManagerPolitiques basées sur les ressources Autorisation basée sur les balises Systems ManagerRôles IAM Systems Manager

AWS Systems ManagerChange Managern'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez AWS Systems ManagerChange Managerla section Modification de la disponibilité.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fonctionnement d’AWS Systems Manager avec IAM

Avant d'utiliser AWS Identity and Access Management (IAM) pour gérer l'accès à AWS Systems Manager, vous devez comprendre quelles fonctionnalités IAM sont disponibles. Systems Manager Pour obtenir une vue d'ensemble de la manière dont vous Services AWS travaillez avec IAM Systems Manager et des autres méthodes utilisées, consultez Services AWS le guide de l'utilisateur d'IAM consacré à l'utilisation d'IAM.

Systems ManagerPolitiques basées sur l'identité

Avec les politiques basées sur l'identité IAM, vous pouvez spécifier les actions et les ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Systems Manager prend en charge des actions, des ressources et des clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez Références des éléments de politique JSON IAM dans le Guide de l'utilisateur IAM.

Actions

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel principal peut effectuer des actions sur quelles ressources et dans quelles conditions.

L’élément Action d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.

Les actions de politique dans Systems Manager utilisent le préfixe suivant avant l'action : ssm:. Par exemple, pour accorder à une personne l'autorisation de créer un paramètre Systems Manager (paramètre SSM) à l'aide de l'opération d'API Systems Manager PutParameter, vous incluez l'action ssm:PutParameter dans sa politique. Les déclarations de politique doivent inclure un élément Action ou NotAction. Systems Manager définit son propre ensemble d'actions qui décrivent les tâches que vous pouvez effectuer avec ce service.

Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit :

"Action": [
      "ssm:action1",
      "ssm:action2"
]
Note

Les outils suivants AWS Systems Manager utilisent des préfixes différents avant les actions.

  • AWS AppConfig utilise le préfixe appconfig: avant les actions.

  • Incident Manager utilise le préfixe ssm-incidents: ou ssm-contacts: avant les actions.

  • Systems Manager GUI Connect utilise le préfixe ssm-guiconnect: avant les actions.

  • Quick Setup utilise le préfixe ssm-quicksetup: avant les actions.

Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (*). Par exemple, pour spécifier toutes les actions qui commencent par le mot Describe, incluez l'action suivante :

"Action": "ssm:Describe*"

Pour afficher la liste des actions Systems Manager, consultez Actions définies par AWS Systems Manager dans la Référence de l'autorisation de service.

Ressources

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel principal peut effectuer des actions sur quelles ressources et dans quelles conditions.

L’élément de politique JSON Resource indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son Amazon Resource Name (ARN). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (*) afin d’indiquer que l’instruction s’applique à toutes les ressources.

"Resource": "*"

Par exemple, la ressource de fenêtre de maintenance Systems Manager a le format ARN suivant.

arn:aws:ssm:region:account-id:maintenancewindow/window-id

Pour spécifier les fenêtres de maintenance mw-0c50858d01EXAMPLE dans votre déclaration dans la Région USA Est (Ohio), vous utiliserez un ARN similaire au suivant.

"Resource": "arn:aws:ssm:us-east-2:123456789012:maintenancewindow/mw-0c50858d01EXAMPLE"

Pour spécifier toutes les fenêtres de maintenance appartenant à un compte spécifique, utilisez le caractère générique (*).

"Resource": "arn:aws:ssm:region:123456789012:maintenancewindow/*"

Pour les opérations d'Parameter StoreAPI, vous pouvez fournir ou restreindre l'accès à tous les paramètres d'un niveau d'une hiérarchie en utilisant des noms hiérarchiques et des politiques AWS Identity and Access Management (IAM) comme suit.

"Resource": "arn:aws:ssm:region:123456789012:parameter/Dev/ERP/Oracle/*"

Certaines actions Systems Manager, telles que la création de ressources, ne peuvent pas être exécutées sur une ressource spécifique. Dans ces cas-là, vous devez utiliser le caractère générique (*).

"Resource": "*"

Certaines opérations d'API Systems Manager acceptent plusieurs ressources. Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules comme suit.

"Resource": [
      "resource1",
      "resource2"
Note

La plupart Services AWS considèrent les deux points (:)) ou les barres obliques (/) comme le même caractère dans ARNs. Cependant, Systems Manager nécessite une correspondance exacte dans les règles et les modèles de ressources. Lors de la création de modèles d'événements, veillez à utiliser les caractères ARN corrects afin qu'ils correspondent à l'ARN de la ressource.

Le tableau ci-dessous décrit les formats ARN des types de ressources pris en charge par Systems Manager.

Note

Notez les exceptions suivantes relatives aux formats ARN.

  • Les outils suivants AWS Systems Manager utilisent des préfixes différents avant les actions.

    • AWS AppConfig utilise le préfixe appconfig: avant les actions.

    • Incident Manager utilise le préfixe ssm-incidents: ou ssm-contacts: avant les actions.

    • Systems Manager GUI Connect utilise le préfixe ssm-guiconnect avant les actions.

  • Les documents et les ressources de définition d'automatisation détenus par Amazon, ainsi que les paramètres publics fournis par Amazon et par des sources tierces, n'incluent pas le compte IDs dans leurs formats ARN. Par exemple :

    • Le document SSM AWS-RunPatchBaseline :

      arn:aws:ssm:us-east-2::document/AWS-RunPatchBaseline

    • Le dossier d’exploitation d’automatisation AWS-ConfigureMaintenanceWindows :

      arn:aws:ssm:us-east-2::automation-definition/AWS-ConfigureMaintenanceWindows

    • Le paramètre public /aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/1.13.4/image_version :

      arn:aws:ssm:us-east-2::parameter/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/1.13.4/image_version

    Pour plus d’informations sur ces trois types de ressources, voir les sujets suivants :

  • Quick Setup utilise le préfixe ssm-quicksetup: avant les actions.

Type de ressource Format ARN
Application (AWS AppConfig) arn:aws:appconfig : ::application/ region account-id application-id
Association arn:aws:ssm : :association/ region account-id association-id
Exécution d'Automation arn:aws:ssm : :automation-execution/ region account-id automation-execution-id
Définition d'Automation (avec sous-ressource de version)

arn:aws:ssm : :automation-definition/ : 1 region account-id automation-definition-id version-id
Profil de configuration (AWS AppConfig) arn:aws:appconfig : :application/ /configurationprofile/ region account-id application-id configurationprofile-id
Contact (Incident Manager)

arn:aws:ssm-contacts : :contact/ region account-id contact-alias
Politique de déploiement (AWS AppConfig) arn:aws:appconfig : ::deploymentstrategy/ region account-id deploymentstrategy-id
Document

arn:aws:ssm : ::document/ region account-id document-name
Environnement (AWS AppConfig) arn:aws:appconfig : :application/ /environnement/ region account-id application-id environment-id
Incident

arn:aws:ssm-incidents : ::incident-record//regionaccount-idresponse-plan-nameincident-id
Fenêtre de maintenance

arn:aws:ssm : :maintenancewindow/ region account-id window-id
Nœud géré

arn:aws:ssm : :managed-instance/ region account-id managed-node-id
Inventaire des nœuds gérés arn:aws:ssm : : :/regionaccount-idmanaged-instance-inventorymanaged-node-id
OpsItem arn:aws:ssm : ::opsitem/ region account-id OpsItem-id
Paramètre

Un paramètre de premier niveau :

  • arn:aws:ssm : :paramètre//regionaccount-idparameter-name

Un paramètre nommé avec une construction hiérarchique :

  • arn:aws:ssm : region account-id :paramètre/////2 parameter-name-root level-2 level-3 level-4 level-5
Référentiel de correctifs

arn:aws:ssm : :patchbaseline/ region account-id patch-baseline-id

Plan de réponse

arn:aws:ssm-incidents : ::response-plan/ region account-id response-plan-name
Session

arn:aws:ssm : :session/ 3 region account-id session-id

Toutes les ressources Systems Manager

arn:aws:ssm:*

Toutes les Systems Manager ressources détenues par les personnes spécifiées Compte AWS dans les Région AWS

arn:aws:ssm : : : * region account-id

1 Pour les définitions d’automatisation, Systems Manager prend en charge une ressource de deuxième niveau, l’ID de version. Dans AWS, ces ressources de deuxième niveau sont appelées sous-ressources. La spécification d'une sous-ressource de version pour une ressource de définition de l'automatisation vous permet de fournir l'accès à certaines versions d'une définition de l'automatisation. Par exemple, il se peut que vous souhaitiez veiller à ce que seule la dernière version de la définition de l'automatisation soit utilisée dans votre gestion des nœuds.

2 Pour organiser et gérer des paramètres, vous pouvez créer des noms pour les paramètres à l'aide d'une construction hiérarchique. Grâce à une construction hiérarchique, un nom de paramètre peut inclure un chemin que vous définissez en utilisant des barres obliques. Vous pouvez nommer une ressource de paramètre avec quinze niveaux maximum. Nous vous suggérons de créer des hiérarchies qui reflètent une structure hiérarchique existante dans votre environnement. Pour de plus amples informations, veuillez consulter Création de paramètres Parameter Store dans Systems Manager.

3 Dans la plupart des cas, l’ID de session est construit avec l’ID d’utilisateur de compte qui a démarré la session, auquel est ajouté un suffixe alphanumérique. Par exemple :

arn:aws:us-east-2:111122223333:session/JohnDoe-1a2b3c4sEXAMPLE

Toutefois, si l'ID utilisateur n'est pas disponible, l'ARN est construit plutôt de la façon suivante :

arn:aws:us-east-2:111122223333:session/session-1a2b3c4sEXAMPLE

Pour plus d'informations sur le format de ARNs, consultez Amazon Resource Names (ARNs) dans le Référence générale d'Amazon Web Services.

Pour une liste des types de Systems Manager ressources et de leurs ARNs caractéristiques, voir Ressources définies par AWS Systems Manager dans la référence d'autorisation de service. Pour savoir grâce à quelles actions vous pouvez spécifier l'ARN de chaque ressource, consultez Actions définies par AWS Systems Manager.

Clés de condition pour Systems Manager

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel principal peut effectuer des actions sur quelles ressources et dans quelles conditions.

L’élément Condition indique à quel moment les instructions sont exécutées en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des opérateurs de condition, tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de contexte de condition AWS globales dans le guide de l'utilisateur IAM.

Pour afficher la liste des clés de condition Systems Manager, consultez Clés de condition pour AWS Systems Manager dans la Référence de l'autorisation de service. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez Actions définies par AWS Systems Manager.

Pour obtenir des informations sur l'utilisation de la clé de condition ssm:resourceTag/*, consultez les rubriques suivantes :

Pour obtenir des informations sur l’utilisation des clés de condition ssm:Recursive, ssm:Policies et ssm:Overwrite, consultez Empêcher l’accès aux opérations d’API Parameter Store.

Exemples

Pour voir des exemples de politiques Systems Manager basées sur l'identité, consultez Exemples de politiques basées sur l’identité AWS Systems Manager.

Systems ManagerPolitiques basées sur les ressources

D'autres Services AWS, comme Amazon Simple Storage Service (Amazon S3), prennent en charge les politiques d'autorisation basées sur les ressources. Par exemple, vous pouvez attacher une politique d'autorisation à un compartiment S3 pour gérer les autorisations d'accès à ce compartiment.

Systems Manager ne prend pas en charge les politiques basées sur une ressource.

Autorisation basée sur les balises Systems Manager

Vous pouvez attacher des balises aux ressources de Systems Manager, ou transmettre des balises dans une demande à Systems Manager. Pour contrôler l'accès basé sur des balises, vous devez fournir les informations de balise dans l'élément de condition d'une politique utilisant les clés de condition ssm:resourceTag/key-name, aws:ResourceTag/key-name, aws:RequestTag/key-name ou aws:TagKeys. Vous pouvez ajouter des balises aux types de ressources suivants lorsque vous les créez ou les mettez à jour :

  • Document

  • Nœud géré

  • Fenêtre de maintenance

  • Paramètre

  • Référentiel de correctifs

  • OpsItem

Pour visualiser un exemple de politique basée sur l'identité permettant de limiter l'accès à une ressource en fonction des balises de cette ressource, consultez Affichage de documents Systems Manager basés sur des balises.

Rôles IAM Systems Manager

Un rôle IAM est une entité au sein de vous Compte AWS qui possède des autorisations spécifiques.

Utilisation des informations d'identification temporaires avec Systems Manager

Vous pouvez utiliser des informations d’identification temporaires pour vous connecter à l’aide de la fédération, endosser un rôle IAM ou encore pour endosser un rôle intercompte. Vous obtenez des informations d'identification de sécurité temporaires en appelant AWS Security Token Service (AWS STS) des opérations d'API telles que AssumeRoleou GetFederationToken.

Systems Manager prend en charge l'utilisation des informations d'identification temporaires.

Rôles liés à un service

Les rôles liés à un service permettent Services AWS d'accéder aux ressources d'autres services pour effectuer une action en votre nom. Les rôles liés à un service s'affichent dans votre compte IAM et sont la propriété du service. Un administrateur peut consulter, mais ne peut pas modifier les autorisations concernant les rôles liés à un service.

Systems Manager prend en charge les rôles liés à un service. Pour plus d'informations sur la création ou la gestion des rôles liés à un service Systems Manager, consultez Utilisation des rôles liés aux services pour Systems Manager.

Rôles du service

Cette fonction permet à un service d’endosser une fonction du service en votre nom. Ce rôle autorise le service à accéder à des ressources d'autres services pour effectuer une action en votre nom. Les rôles de service s'affichent dans votre compte IAM et sont la propriété du compte. Cela signifie qu'un administrateur peut modifier les autorisations associées à ce rôle. Toutefois, une telle action peut perturber le bon fonctionnement du service.

Systems Manager prend en charge les rôles de service.

Choix d'un rôle IAM dans Systems Manager

Pour que Systems Manager interagisse avec vos nœuds gérés, vous devez choisir un rôle autorisant Systems Manager à accéder aux nœuds en votre nom. Si vous avez déjà créé un rôle de service ou un rôle lié à un service, Systems Manager vous fournit une liste de rôles dans laquelle effectuer votre choix. Il est important de choisir un rôle qui permet d'accéder au démarrage et à l'arrêt des nœuds gérés.

Pour accéder aux EC2 instances, vous devez configurer les autorisations des instances. Pour plus d’informations, consultez la section Configurer des autorisations d’instance requises pour Systems Manager.

Pour accéder à des EC2 non-nœuds dans un cloud hybride et multicloud, le rôle Compte AWS dont vous avez besoin est un rôle de service IAM. Pour plus d’informations, voir Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud.

Un flux de travail Automation peut être lancé dans le contexte d'un rôle de service (ou rôle de responsable). Cela permet au service d'effectuer des actions en votre nom. Si vous ne spécifiez pas de rôle de responsable, Automation utilise le contexte de l'utilisateur qui a appelé l'exécution. Cependant, certaines situations exigent que vous spécifiiez un rôle de service pour Automation. Pour de plus amples informations, veuillez consulter Configuration d'un accès à un rôle de service (rôle de responsable) pour les automatisations.

Politiques gérées par AWS Systems Manager

AWS répond à de nombreux cas d'utilisation courants en fournissant des politiques IAM autonomes créées et administrées par. AWS Ces politiques gérées AWS octroient les autorisations requises dans les cas d'utilisation courants, ce qui vous évite d'avoir à vous en soucier. (Vous pouvez également créer vos propres politiques IAM personnalisées afin d'accorder des autorisations pour les actions et les ressources Systems Manager.)

Pour plus d’informations sur les politiques gérées pour Systems Manager, consultez AWS politiques gérées pour AWS Systems Manager

Pour plus d’informations sur les politiques gérées, consultez Stratégie gérées AWS dans le Guide de l’utilisateur IAM.