

AWS Systems Manager Incident Manager n'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez [AWS Systems Manager Incident Manager la section Modification de la disponibilité](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.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.

# Identity and Access Management pour AWS Systems Manager Incident Manager
<a name="security-iam"></a>





Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources d'Incident Manager. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.

**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment AWS Systems Manager Incident Manager fonctionne avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager](security_iam_id-based-policy-examples.md)
+ [Exemples de politiques basées sur les ressources pour AWS Systems Manager Incident Manager](security_iam_resource-based-policy-examples.md)
+ [Prévention de la confusion entre les services par les adjoints dans Incident Manager](cross-service-confused-deputy-prevention.md)
+ [Utilisation de rôles liés à un service pour Incident Manager](using-service-linked-roles.md)
+ [AWS politiques gérées pour AWS Systems Manager Incident Manager](security-iam-awsmanpol.md)
+ [Résolution des problèmes AWS Systems Manager Incident Manager d'identité et d'accès](security_iam_troubleshoot.md)

## Public ciblé
<a name="security_iam_audience"></a>

La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes AWS Systems Manager Incident Manager d'identité et d'accès](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment AWS Systems Manager Incident Manager fonctionne avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager](security_iam_id-based-policy-examples.md))

## Authentification par des identités
<a name="security_iam_authentication"></a>

L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS

Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.

Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.

### Compte AWS utilisateur root
<a name="security_iam_authentication-rootuser"></a>

 Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*. 

### Identité fédérée
<a name="security_iam_authentication-federated"></a>

Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.

Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.

Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.

### Utilisateurs et groupes IAM
<a name="security_iam_authentication-iamuser"></a>

Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.

[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.

### Rôles IAM
<a name="security_iam_authentication-iamrole"></a>

Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération AWS CLI ou AWS API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.

Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.

## Gestion de l’accès à l’aide de politiques
<a name="security_iam_access-manage"></a>

Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.

À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.

Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.

### Politiques basées sur l’identité
<a name="security_iam_access-manage-id-based-policies"></a>

Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.

Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.

### Politiques basées sur les ressources
<a name="security_iam_access-manage-resource-based-policies"></a>

Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.

Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.

### Autres types de politique
<a name="security_iam_access-manage-other-policies"></a>

AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.

### Plusieurs types de politique
<a name="security_iam_access-manage-multiple-policies"></a>

Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.

# Comment AWS Systems Manager Incident Manager fonctionne avec IAM
<a name="security_iam_service-with-iam"></a>

Avant d'utiliser IAM pour gérer l'accès à Incident Manager, découvrez quelles fonctionnalités IAM peuvent être utilisées avec Incident Manager.






**Fonctionnalités IAM que vous pouvez utiliser avec AWS Systems Manager Incident Manager**  

| Fonctionnalité IAM | Assistance pour le gestionnaire d'incidents | 
| --- | --- | 
|  [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies)  |   Oui  | 
|  [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies)  |   Oui  | 
|  [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions)  |   Oui  | 
|  [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources)  |   Oui  | 
|  [Clés de condition d’une politique](#security_iam_service-with-iam-id-based-policies-conditionkeys)  |   Non   | 
|  [ACLs](#security_iam_service-with-iam-acls)  |   Non   | 
|  [ABAC (étiquettes dans les politiques)](#security_iam_service-with-iam-tags)  |   Non   | 
|  [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds)  |   Oui  | 
|  [Autorisations de principal](#security_iam_service-with-iam-principal-permissions)  |   Oui  | 
|  [Rôles de service](#security_iam_service-with-iam-roles-service)  |   Oui  | 
|  [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked)  |   Oui  | 

Pour obtenir une vue d'ensemble de la façon dont Incident Manager et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, consultez les [AWS services compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le guide de l'utilisateur *IAM*.

Incident Manager ne prend pas en charge les politiques qui refusent l'accès aux ressources partagées à l'aide AWS RAM.

## Politiques basées sur l'identité pour Incident Manager
<a name="security_iam_service-with-iam-id-based-policies"></a>

**Prend en charge les politiques basées sur l’identité :** oui

Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.

Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.

### Exemples de politiques basées sur l'identité pour Incident Manager
<a name="security_iam_service-with-iam-id-based-policies-examples"></a>



Pour consulter des exemples de politiques basées sur l'identité d'Incident Manager, consultez. [Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager](security_iam_id-based-policy-examples.md)

## Politiques basées sur les ressources dans Incident Manager
<a name="security_iam_service-with-iam-resource-based-policies"></a>

**Prend en charge les politiques basées sur les ressources** : oui

Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS

Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.

Le service Incident Manager ne prend en charge que deux types de politiques basées sur les ressources, appelées à l'aide de la AWS RAM console ou de l' PutResourcePolicy action, qui est attachée à un plan de réponse ou à un contact. Cette politique définit quels principaux peuvent effectuer des actions sur les plans de réponse, les contacts, les plans d'escalade et les incidents. Incident Manager utilise des politiques basées sur les ressources pour partager les ressources entre les comptes.

Incident Manager ne prend pas en charge les politiques qui refusent l'accès aux ressources partagées à l'aide AWS RAM.

Pour savoir comment associer une politique basée sur les ressources à un plan d'intervention ou à un contact, voir. [Gestion des incidents par région Comptes AWS et par région dans Incident Manager](incident-manager-cross-account-cross-region.md)

### Exemples de politiques basées sur les ressources dans Incident Manager
<a name="security_iam_service-with-iam-resource-based-policies-examples"></a>



Pour consulter des exemples de politiques basées sur les ressources d'Incident Manager, consultez. [Exemples de politiques basées sur les ressources pour AWS Systems Manager Incident Manager](security_iam_resource-based-policy-examples.md)

## Actions politiques pour Incident Manager
<a name="security_iam_service-with-iam-id-based-policies-actions"></a>

**Prend en charge les actions de politique :** oui

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.



Pour consulter la liste des actions d'Incident Manager, voir [Actions définies par AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanager.html#awssystemsmanagerincidentmanager-actions-as-permissions) dans la *référence d'autorisation de service*.

Les actions de politique dans Incident Manager utilisent les préfixes suivants avant l'action :

```
ssm-incidents
ssm-contacts
```

Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.

```
"Action": [
      "ssm-incidents:GetResponsePlan",
      "ssm-contacts:GetContact"
         ]
```





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

```
"Action": "ssm-incidents:Get*"
```

Pour consulter des exemples de politiques basées sur l'identité d'Incident Manager, consultez. [Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager](security_iam_id-based-policy-examples.md)

Incident Manager utilise des actions dans deux espaces de noms différents, ssm-incidents et ssm-contacts. Lorsque vous créez des politiques pour Incident Manager, veillez à utiliser l'espace de noms correspondant à l'action. Le SSM-Incidents est utilisé pour le plan de réponse et les actions liées aux incidents. SSM-Contacts est utilisé pour les actions liées aux contacts et à l'engagement des contacts. Par exemple :
+ `ssm-contacts:GetContact`
+ `ssm-incidents:GetResponsePlan`

## Ressources relatives aux politiques pour Incident Manager
<a name="security_iam_service-with-iam-id-based-policies-resources"></a>

**Prend en charge les ressources de politique :** oui

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)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.

```
"Resource": "*"
```

Pour consulter la liste des types de ressources Incident Manager et leurs caractéristiques ARNs, consultez la section [Ressources définies par AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanager.html#awssystemsmanagerincidentmanager-resources-for-iam-policies) 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 Incident Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanager.html#awssystemsmanagerincidentmanager-actions-as-permissions).





Pour consulter des exemples de politiques basées sur l'identité d'Incident Manager, consultez. [Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager](security_iam_id-based-policy-examples.md)

Les ressources du gestionnaire d'incidents sont utilisées pour créer des incidents, collaborer sur les canaux de discussion, résoudre les incidents et impliquer les intervenants. Si un utilisateur a accès à un plan de réponse, il a accès à tous les incidents créés à partir de celui-ci. Si un utilisateur a accès à un contact ou à un plan d'escalade, il peut faire participer le ou les contacts au plan d'escalade.

## Clés de conditions de politique pour Incident Manager
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**Prend en charge les clés de condition de politique spécifiques au service :** non 

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 s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.

## Listes de contrôle d'accès (ACLs) dans Incident Manager
<a name="security_iam_service-with-iam-acls"></a>

**Supports ACLs :** Non 

Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.

## Contrôle d'accès basé sur les attributs (ABAC) avec Incident Manager
<a name="security_iam_service-with-iam-tags"></a>

**Prise en charge d’ABAC (balises dans les politiques) :** non 

Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.

Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.

Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.

Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.

## Utilisation d'informations d'identification temporaires avec Incident Manager
<a name="security_iam_service-with-iam-roles-tempcreds"></a>

**Prend en charge les informations d’identification temporaires :** oui

Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.

## Autorisations principales interservices pour Incident Manager
<a name="security_iam_service-with-iam-principal-permissions"></a>

**Prend en charge les sessions d’accès direct (FAS) :** oui

 Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). 

## Rôles de service pour Incident Manager
<a name="security_iam_service-with-iam-roles-service"></a>

**Prend en charge les rôles de service :** oui

 Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*. 

**Avertissement**  
La modification des autorisations associées à un rôle de service peut perturber les fonctionnalités d'Incident Manager. Modifiez les rôles de service uniquement lorsque Incident Manager fournit des instructions à cet effet.

### Choix d'un rôle IAM dans Incident Manager
<a name="security_iam_service-with-iam-roles-choose"></a>

Lorsque vous créez une ressource de plan de réponse dans Incident Manager, vous devez choisir un rôle pour permettre à Incident Manager d'exécuter un document d'automatisation de Systems Manager en votre nom. Si vous avez déjà créé un rôle de service ou un rôle lié à un service, Incident Manager vous fournit une liste de rôles parmi lesquels choisir. Il est important de choisir un rôle qui autorise l'accès à l'exécution de vos instances de documents automatisés. Pour de plus amples informations, veuillez consulter [Intégration des runbooks d'automatisation de Systems Manager dans Incident Manager pour la résolution des incidents](runbooks.md). Lorsque vous créez un canal de discussion Amazon Q Developer dans les applications de chat à utiliser lors d'un incident, vous pouvez sélectionner un rôle de service qui vous permet d'utiliser des commandes directement depuis le chat. Pour en savoir plus sur la création de canaux de discussion pour la collaboration en cas d'incident, consultez[Création et intégration de canaux de discussion pour les intervenants dans Incident Manager](chat.md). Pour en savoir plus sur les politiques IAM dans Amazon Q Developer dans les applications de chat, consultez la section [Gestion des autorisations pour exécuter des commandes à l'aide d'Amazon Q Developer dans les applications de chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/chatbot-cli-commands.html#iam-policies-for-slack-channels-cli-support) dans le *guide d'administration d'Amazon Q Developer dans les applications de chat*.

## Rôles liés à un service pour Incident Manager
<a name="security_iam_service-with-iam-roles-service-linked"></a>

**Prend en charge les rôles liés à un service :** oui

 Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service. 

Pour plus d'informations sur la création ou la gestion des rôles liés au service Incident Manager, consultez. [Utilisation de rôles liés à un service pour Incident Manager](using-service-linked-roles.md)

# Exemples de politiques basées sur l'identité pour AWS Systems Manager Incident Manager
<a name="security_iam_id-based-policy-examples"></a>

Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources Incident Manager. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.

Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.

Pour plus de détails sur les actions et les types de ressources définis par Incident Manager, y compris le format de chaque type de ressource, voir [Actions, ressources et clés de condition AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanager.html) dans la *référence d'autorisation de service*. ARNs 

**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Incident Manager](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Accès à un plan de réponse](#security_iam_id-based-policy-examples-access-response-plan)

## Bonnes pratiques en matière de politiques
<a name="security_iam_service-with-iam-policy-best-practices"></a>

Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources Incident Manager dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.

## Utilisation de la console Incident Manager
<a name="security_iam_id-based-policy-examples-console"></a>

Pour accéder à la AWS Systems Manager Incident Manager console, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et de consulter les détails des ressources du gestionnaire d'incidents de votre Compte AWS. Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.

Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.

Pour garantir que les utilisateurs et les rôles peuvent résoudre les incidents à l'aide de la console Incident Manager, associez également la politique `IncidentManagerResolverAccess` AWS gérée par Incident Manager aux entités. Pour plus d’informations, consultez [Ajout d’autorisations à un utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.

```
IncidentManagerResolverAccess
```

## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

## Accès à un plan de réponse
<a name="security_iam_id-based-policy-examples-access-response-plan"></a>

Dans cet exemple, vous souhaitez accorder à un utilisateur IAM de votre compte Amazon Web Services l'accès à l'un de vos plans de réponse Incident Manager. `exampleplan` Vous souhaitez également autoriser l'utilisateur à ajouter, mettre à jour et supprimer le plan de réponse.

La politique accorde les `ssm-incident:ListResponsePlan` autorisations `ssm-incidents:ListResponsePlans``ssm-incidents:GetResponsePlan`, `ssm-incidents:UpdateResponsePlan` et à l'utilisateur.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"ListResponsePlans",
         "Effect":"Allow",
         "Action":[
            "ssm-incidents:ListResponsePlans"
         ],
         "Resource":"arn:aws:ssm-incidents:::*"
      },
      {
         "Sid":"ViewSpecificResponsePlanInfo",
         "Effect":"Allow",
         "Action":[
            "ssm-incidents:GetResponsePlan"
         ],
         "Resource":"arn:aws:ssm-incidents:*:111122223333:response-plan/exampleplan"
      },
      {
         "Sid":"ManageResponsePlan",
         "Effect":"Allow",
         "Action":[
            "ssm-incidents:UpdateResponsePlan"
         ],
         "Resource":"arn:aws:ssm-incidents:*:111122223333:response-plan/exampleplan/*"
      }
   ]
}
```

------







# Exemples de politiques basées sur les ressources pour AWS Systems Manager Incident Manager
<a name="security_iam_resource-based-policy-examples"></a>

AWS Systems Manager Incident Manager prend en charge les politiques d'autorisation basées sur les ressources pour les plans de réponse et les contacts d'Incident Manager.

Incident Manager ne prend pas en charge les politiques basées sur les ressources qui refusent l'accès aux ressources partagées à l'aide de celles-ci. AWS RAM

Pour savoir comment créer un plan d'intervention ou un contact, consultez [Création et configuration de plans de réponse dans Incident Manager](response-plans.md) et[Création et configuration de contacts dans Incident Manager](contacts.md).

## Restreindre l'accès au plan de réponse d'Incident Manager par l'organisation
<a name="security_iam_resource-based-policy-examples-restrict-response-plan-by-org"></a>

L'exemple suivant accorde des autorisations aux utilisateurs de l'organisation dotés de l'identifiant de l'organisation : `o-abc123def45` pour répondre aux incidents créés à l'aide du plan de réponse`myplan`.

Le `Condition` bloc utilise les `StringEquals` conditions et la clé de `aws:PrincipalOrgID` condition, qui est une clé de condition AWS Organizations spécifique. Pour plus d'informations sur ces clés de condition, consultez la section [Spécification de conditions dans une politique](https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon-s3-policy-keys.html). 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "OrganizationAccess",
            "Effect": "Allow",
            "Principal": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-abc123def45"
                }
            },
            "Action": [
                "ssm-incidents:GetResponsePlan",
                "ssm-incidents:StartIncident",
                "ssm-incidents:UpdateIncidentRecord",
                "ssm-incidents:GetIncidentRecord",
                "ssm-incidents:CreateTimelineEvent",
                "ssm-incidents:UpdateTimelineEvent",
                "ssm-incidents:GetTimelineEvent",
                "ssm-incidents:ListTimelineEvents",
                "ssm-incidents:UpdateRelatedItems",
                "ssm-incidents:ListRelatedItems"
            ],
            "Resource": [
                "arn:aws:ssm-incidents:*:111122223333:response-plan/myplan",
                "arn:aws:ssm-incidents:*:111122223333:incident-record/myplan/*"
            ]
        }
    ]
}
```

------

## Fournir un accès de contact au responsable des incidents à un mandant
<a name="security_iam_resource-based-policy-examples-provide-contact-access-to-principal"></a>

L'exemple suivant autorise le principal doté de l'ARN `arn:aws:iam::999988887777:root` à créer des engagements avec le contact`mycontact`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "PrincipalAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::999988887777:root"
            },
            "Action": [
                "ssm-contacts:GetContact",
                "ssm-contacts:StartEngagement",
                "ssm-contacts:DescribeEngagement",
                "ssm-contacts:ListPagesByContact"
            ],
            "Resource": [
                "arn:aws:ssm-contacts:*:111122223333:contact/mycontact",
                "arn:aws:ssm-contacts:*:111122223333:engagement/mycontact/*"
            ]
        }
    ]
}
```

------

# Prévention de la confusion entre les services par les adjoints dans Incident Manager
<a name="cross-service-confused-deputy-prevention"></a>

Le problème des adjoints confus est un problème de sécurité de l'information qui se produit lorsqu'une entité non autorisée à effectuer une action appelle une entité plus privilégiée pour effectuer l'action. Cela peut permettre à des acteurs malveillants d'exécuter des commandes ou de modifier des ressources qu'ils n'auraient pas l'autorisation d'exécuter ou d'accéder autrement.

Dans AWS, l'usurpation d'identité interservices peut mener à un scénario d'adjoint confus. L'usurpation d'identité interservices se produit lorsqu'un service (le *service appelant*) appelle un autre service (le service *appelé*). Un acteur malveillant peut utiliser le service d'appel pour modifier les ressources d'un autre service en utilisant des autorisations qu'il n'aurait pas normalement obtenues.

AWS fournit aux responsables du service un accès géré aux ressources de votre compte afin de vous aider à protéger la sécurité de vos ressources. Nous vous recommandons d'utiliser les clés de contexte de condition [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)et les clés contextuelles dans vos politiques de ressources. Ces clés limitent les autorisations qui fournissent AWS Systems Manager Incident Manager un autre service à cette ressource. Si vous utilisez les deux clés contextuelles de condition globale, la `aws:SourceAccount` valeur et le compte référencés dans la `aws:SourceArn` valeur doivent utiliser le même identifiant de compte lorsqu'ils sont utilisés dans la même déclaration de politique.

La valeur de `aws:SourceArn` doit être l'ARN de l'enregistrement d'incident concerné. Si vous ne connaissez pas l'ARN complet de la ressource, ou si vous spécifiez plusieurs ressources, utilisez la clé de condition de contexte `aws:SourceArn` global avec le `*` caractère générique pour les parties inconnues de l'ARN. Par exemple, vous pouvez `aws:SourceArn` définir sur`arn:aws:ssm-incidents::111122223333:*`. 

Dans l'exemple de politique de confiance suivant, nous utilisons la clé de `aws:SourceArn` condition pour restreindre l'accès au rôle de service en fonction de l'ARN de l'enregistrement de l'incident. Seuls les enregistrements d'incidents créés à partir du plan `myresponseplan` d'intervention peuvent utiliser ce rôle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": { "Service": "ssm-incidents.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}
```

------

# Utilisation de rôles liés à un service pour Incident Manager
<a name="using-service-linked-roles"></a>

AWS Systems Manager Incident Manager utilise des Gestion des identités et des accès AWS rôles liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié à Incident Manager. Les rôles liés au service sont prédéfinis par Incident Manager et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom. 

Un rôle lié à un service facilite la configuration d'Incident Manager, car vous n'avez pas à ajouter manuellement les autorisations nécessaires. Incident Manager définit les autorisations associées à ses rôles liés aux services et, sauf indication contraire, seul le gestionnaire d'incidents peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.

Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Cela protège les ressources de votre gestionnaire d'incidents, car vous ne pouvez pas supprimer par inadvertance l'autorisation d'accès aux ressources.

Pour plus d’informations sur les autres services qui prennent en charge les rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services avec un **Oui ** dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.

## Autorisations de rôle liées au service pour Incident Manager
<a name="slr-permissions"></a>

Incident Manager utilise le rôle lié au service nommé. **AWSServiceRoleforIncidentManager** Ce rôle permet au gestionnaire d'incidents de gérer les dossiers d'incidents du gestionnaire d'incidents et les ressources associées en votre nom.

Le rôle AWSService RoleforIncidentManager lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `ssm-incidents.amazonaws.com`

La politique d'autorisation des rôles [`AWSIncidentManagerServiceRolePolicy`](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSServiceRoleforIncidentManagerPolicy)permet à Incident Manager d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `ssm-incidents:ListIncidentRecords` sur toutes les ressources liées à l'action.
+ Action : `ssm-incidents:CreateTimelineEvent` sur toutes les ressources liées à l'action.
+ Action : `ssm:CreateOpsItem` sur toutes les ressources liées à l'action.
+ Action : `ssm:AssociateOpsItemRelatedItem` sur `all resources related to the action.`
+ Action : `ssm-contacts:StartEngagement` sur toutes les ressources liées à l'action.
+ Action : `cloudwatch:PutMetricData` sur les CloudWatch métriques à l'intérieur des espaces de `AWS/Usage` noms `AWS/IncidentManager` et

Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour en savoir plus, consultez [Service-Linked Role Permissions (autorisations du rôle lié à un service)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.

## Création d'un rôle lié à un service pour Incident Manager
<a name="create-slr"></a>

Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un ensemble de réplication dans l'API AWS Management Console AWS CLI, le ou l' AWS API, Incident Manager crée le rôle lié au service pour vous. 

Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un ensemble de réplication, Incident Manager crée à nouveau le rôle lié au service pour vous. 

## Modification d'un rôle lié à un service pour Incident Manager
<a name="edit-slr"></a>

Incident Manager ne vous permet pas de modifier le rôle AWSService RoleforIncidentManager lié au service. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence au rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour en savoir plus, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.

## Supprimer un rôle lié à un service pour Incident Manager
<a name="delete-slr"></a>

Si vous n’avez plus besoin d’utiliser une fonction ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, aucune entité inutilisée n'est surveillée ou gérée activement. Cependant, vous devez nettoyer les ressources de votre rôle lié à un service avant de pouvoir les supprimer manuellement.

Pour supprimer le rôle lié à un service, vous devez d'abord supprimer le jeu de réplication. La suppression du jeu de réplication entraîne la suppression de toutes les données créées et stockées dans Incident Manager, y compris les plans de réponse, les contacts et les plans d'escalade. Vous perdrez également tous les incidents créés précédemment. Les alarmes et EventBridge les règles pointant vers des plans d'intervention supprimés ne créeront plus d'incident en cas d'alarme ou de correspondance des règles. Pour supprimer le jeu de réplication, vous devez supprimer toutes les régions du jeu.

**Note**  
Si le service Incident Manager utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.

**Pour supprimer les régions du jeu de réplication utilisé par le AWSService RoleforIncidentManager**

1. Ouvrez la [console Incident Manager](https://console.aws.amazon.com/systems-manager/incidents/home) et choisissez **Paramètres dans** le menu de navigation de gauche.

1. Sélectionnez une région dans le **jeu de réplication**. 

1. Sélectionnez **Delete (Supprimer)**.

1. Pour confirmer la suppression de la région, entrez le nom de la région et choisissez **Supprimer**.

1. Répétez ces étapes jusqu'à ce que vous ayez supprimé toutes les régions de votre jeu de réplication. Lorsque vous supprimez la région finale, la console vous informe qu'elle supprime le jeu de réplication qui l'accompagne.

**Pour supprimer manuellement le rôle lié au service à l’aide d’IAM**

Utilisez la console IAM, le AWS CLI, ou l' AWS API pour supprimer le rôle lié au AWSService RoleforIncidentManager service. Pour en savoir plus, consultez [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.

## Régions prises en charge pour les rôles liés au service Incident Manager
<a name="slr-regions"></a>

Incident Manager prend en charge l'utilisation de rôles liés au service dans toutes les régions où le service est disponible. Pour plus d’informations, consultez [AWS Régions et points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html).

# AWS politiques gérées pour AWS Systems Manager Incident Manager
<a name="security-iam-awsmanpol"></a>



Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.

N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.

Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.

Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.









## AWS politique gérée : AWSIncident ManagerIncidentAccessServiceRolePolicy
<a name="security-iam-awsmanpol-AWSIncidentManagerIncidentAccessServiceRolePolicy"></a>





Vous pouvez attacher `AWSIncidentManagerIncidentAccessServiceRolePolicy` à vos entités IAM. Le gestionnaire d'incidents associe également cette politique à un rôle de gestionnaire d'incidents qui permet au gestionnaire d'incidents d'effectuer des actions en votre nom. 



Cette politique accorde des autorisations de lecture seule qui permettent à Incident Manager de lire les ressources de certains autres Services AWS services afin d'identifier les résultats liés aux incidents survenus dans ces services.



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `cloudformation`— Permet aux principes de décrire les CloudFormation piles. Cela est nécessaire pour que le gestionnaire d'incidents puisse identifier les CloudFormation événements et les ressources liés à un incident.
+ `codedeploy`— Permet aux principaux de lire les AWS CodeDeploy déploiements. Cela est nécessaire pour qu'Incident Manager identifie les CodeDeploy déploiements et les cibles liés à un incident.
+ `autoscaling`— Permet aux principaux de déterminer si une instance Amazon Elastic Compute Cloud (EC2) fait partie d'un groupe Auto Scaling. Cela est nécessaire pour qu'Incident Manager puisse fournir des résultats pour les instances EC2 faisant partie des groupes Auto Scaling.



Pour plus de détails sur cette politique, y compris la dernière version du document sur la politique JSON, consultez [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerIncidentAccessServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerIncidentAccessServiceRolePolicy.html) dans le *Guide de référence de la politique gérée par AWS *.

## AWS politique gérée : `AWSIncidentManagerServiceRolePolicy`
<a name="security-iam-awsmanpol-AWSServiceRoleforIncidentManagerPolicy"></a>



Vous ne pouvez pas joindre de `AWSIncidentManagerServiceRolePolicy` à vos entités IAM. Cette politique est associée à un rôle lié à un service qui permet à Incident Manager d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Utilisation de rôles liés à un service pour Incident Manager](using-service-linked-roles.md).



Cette politique autorise le gestionnaire d'incidents à répertorier les incidents, à créer des événements chronologiques, à créer des éléments connexes OpsItems, à y associer des éléments connexes OpsItems, à démarrer des engagements et à publier CloudWatch des statistiques relatives à un incident.



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `ssm-incidents`— Permet aux directeurs de répertorier les incidents et de créer des événements chronologiques. Cela est nécessaire pour que les intervenants puissent collaborer lors d'un incident sur le tableau de bord des incidents.
+ `ssm`— Permet aux directeurs de créer OpsItems et d'associer des éléments connexes. Cela est nécessaire pour créer un parent au OpsItem début d'un incident.
+ `ssm-contacts`— Permet aux directeurs d'entamer des engagements. Cela est nécessaire pour que le gestionnaire d'incidents puisse engager des contacts lors d'un incident.
+ `cloudwatch`— Permet aux directeurs de publier des CloudWatch métriques. Cela est nécessaire pour qu'Incident Manager publie des métriques relatives à un incident et des métriques d'utilisation.



Pour plus de détails sur cette politique, y compris la dernière version du document sur la politique JSON, consultez [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerServiceRolePolicy.html) dans le *Guide de référence de la politique gérée par AWS *.

## AWS politique gérée : `AWSIncidentManagerResolverAccess`
<a name="security-iam-awsmanpol-AWSIncidentManagerResolverAccess"></a>



Vous pouvez les associer `AWSIncidentManagerResolverAccess` à vos entités IAM pour leur permettre de démarrer, de visualiser et de mettre à jour des incidents. Cela leur permet également de créer des événements chronologiques pour les clients et des éléments connexes dans le tableau de bord des incidents. Vous pouvez également associer cette politique au rôle de développeur Amazon Q dans le service des applications de chat ou directement à votre rôle géré par le client associé à n'importe quel canal de discussion utilisé pour la collaboration en cas d'incident. Pour en savoir plus sur les politiques IAM dans Amazon Q Developer dans les applications de chat, consultez la section [Gestion des autorisations pour exécuter des commandes à l'aide d'Amazon Q Developer dans les applications de chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/chatbot-cli-commands.html#iam-policies-for-slack-channels-cli-support) dans le *Guide de l'administrateur d'Amazon Q Developer dans les applications de chat*.

**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `ssm-incidents`— Permet aux directeurs de démarrer des incidents, de répertorier les plans de réponse, de répertorier les incidents, de mettre à jour les incidents, de répertorier les événements chronologiques, de créer des événements chronologiques personnalisés, de mettre à jour des événements chronologiques personnalisés, de supprimer des événements chronologiques personnalisés, de répertorier les éléments connexes, de créer des éléments connexes et de mettre à jour les éléments connexes.
+ `ssm-contacts`— Permet aux directeurs d'engager des contacts lors de la création de l'incident.



Pour plus de détails sur cette politique, y compris la dernière version du document sur la politique JSON, consultez [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerResolverAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSIncidentManagerResolverAccess.html) dans le *Guide de référence de la politique gérée par AWS *.





## Mises à jour des politiques AWS gérées par Incident Manager
<a name="security-iam-awsmanpol-updates"></a>



Consultez les détails des mises à jour des politiques AWS gérées pour Incident Manager depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la page d'historique des documents d'Incident Manager.




| Modifier | Description | Date | 
| --- | --- | --- | 
|  [`AWSIncidentManagerResolverAccess`](#security-iam-awsmanpol-AWSIncidentManagerResolverAccess)— Mise à jour de la politique  |  Incident Manager a ajouté l'autorisation de démarrer des interactions avec des contacts.  | 20 novembre 2025 | 
|  [`AWSIncidentManagerServiceRolePolicy`](#security-iam-awsmanpol-AWSServiceRoleforIncidentManagerPolicy)— Mise à jour de la politique  |  Incident Manager a ajouté une nouvelle autorisation qui permet à Incident Manager de publier des métriques au sein de l'`AWS/Usage`espace de noms sur votre compte.  | 27 janvier 2025 | 
| [AWSIncidentManagerIncidentAccessServiceRolePolicy](#security-iam-awsmanpol-AWSIncidentManagerIncidentAccessServiceRolePolicy) — Mise à jour de la politique | Incident Manager a ajouté une nouvelle autorisationAWSIncidentManagerIncidentAccessServiceRolePolicy, à l'appui de la fonctionnalité Findings, qui lui permet de vérifier si une instance EC2 fait partie d'un groupe Auto Scaling. | 20 février 2024 | 
|  [`AWSIncidentManagerIncidentAccessServiceRolePolicy`](#security-iam-awsmanpol-AWSIncidentManagerIncidentAccessServiceRolePolicy) : nouvelle politique  |  Incident Manager a ajouté une nouvelle politique qui accorde à Incident Manager l'autorisation d'appeler d'autres Services AWS personnes dans le cadre de la gestion d'un incident.  | 17 novembre 2023 | 
|  [`AWSIncidentManagerServiceRolePolicy`](#security-iam-awsmanpol-AWSServiceRoleforIncidentManagerPolicy)— Mise à jour de la politique  |  Incident Manager a ajouté une nouvelle autorisation qui permet à Incident Manager de publier des statistiques sur votre compte.  | 16 déc. 2022 | 
|  [`AWSIncidentManagerResolverAccess`](#security-iam-awsmanpol-AWSIncidentManagerResolverAccess) : nouvelle politique  |  Incident Manager a ajouté une nouvelle politique pour vous permettre de démarrer des incidents, de répertorier les plans de réponse, de répertorier les incidents, de mettre à jour les incidents, de répertorier les événements chronologiques, de créer des événements chronologiques personnalisés, de mettre à jour des événements chronologiques personnalisés, de répertorier les éléments connexes, de créer des éléments connexes et de mettre à jour des éléments connexes.  | 26 avril 2021 | 
|  [`AWSIncidentManagerServiceRolePolicy`](#security-iam-awsmanpol-AWSServiceRoleforIncidentManagerPolicy) : nouvelle politique  |  Incident Manager a ajouté une nouvelle politique pour accorder à Incident Manager l'autorisation de répertorier les incidents, de créer des événements OpsItems chronologiques, de créer OpsItems, d'associer des éléments connexes et de démarrer des engagements liés à un incident.  | 26 avril 2021 | 
|  Incident Manager a commencé à suivre les modifications  |  Incident Manager a commencé à suivre les modifications apportées AWS à ses politiques gérées.  | 26 avril 2021 | 

# Résolution des problèmes AWS Systems Manager Incident Manager d'identité et d'accès
<a name="security_iam_troubleshoot"></a>

Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lors de l'utilisation d'Incident Manager et d'IAM.

**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Incident Manager](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à mon compte Amazon Web Services à accéder à mes ressources Incident Manager](#security_iam_troubleshoot-cross-account-access)

## Je ne suis pas autorisé à effectuer une action dans Incident Manager
<a name="security_iam_troubleshoot-no-permissions"></a>

Si vous recevez une erreur qui indique que vous n’êtes pas autorisé à effectuer une action, vos politiques doivent être mises à jour afin de vous permettre d’effectuer l’action.

L’exemple d’erreur suivant se produit quand l’utilisateur IAM `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `ssm-incidents:GetWidget` fictives.

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: ssm-incidents:GetWidget on resource: my-example-widget
```

Dans ce cas, la politique qui s’applique à l’utilisateur `mateojackson` doit être mise à jour pour autoriser l’accès à la ressource `my-example-widget` à l’aide de l’action `ssm-incidents:GetWidget`.

Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.

## Je ne suis pas autorisé à effectuer iam : PassRole
<a name="security_iam_troubleshoot-passrole"></a>

Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Incident Manager.

Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.

L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans Incident Manager. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.

Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.

## Je souhaite autoriser des personnes extérieures à mon compte Amazon Web Services à accéder à mes ressources Incident Manager
<a name="security_iam_troubleshoot-cross-account-access"></a>

Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.

Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Incident Manager prend en charge ces fonctionnalités, consultez[Comment AWS Systems Manager Incident Manager fonctionne avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.