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.

# Limiter l'accès des agents à un AWS compte
<a name="aws-devops-agent-security-limiting-agent-access-in-an-aws-account"></a>

AWS DevOps L'agent utilise les rôles IAM pour découvrir et décrire les AWS ressources lors des enquêtes sur les incidents et des évaluations préventives. Vous pouvez contrôler le niveau d'accès de l'agent en configurant les politiques IAM associées à ces rôles. La topologie de l'application ne montre pas tout ce à quoi l'agent a accès. Les politiques IAM sont le seul moyen de réellement limiter les AWS services APIs et les ressources auxquels l'agent peut accéder.

## Comprendre les rôles IAM pour l'agent AWS DevOps
<a name="understanding-iam-roles-for-aws-devops-agent"></a>

AWS DevOps L'agent utilise les rôles IAM pour accéder aux ressources de deux types de comptes :
+ **Rôle du compte principal** — Permet à l'agent d'accéder aux ressources du AWS compte sur lequel vous créez l'espace agent.
+ **Rôles de compte secondaires** — Permet à l'agent d'accéder aux ressources des AWS comptes supplémentaires que vous connectez à l'espace agent.

Quel que soit le type de compte, vous pouvez restreindre les AWS services auxquels l'agent peut accéder, limiter l'accès à des ressources spécifiques au sein de ces services et contrôler les régions dans lesquelles l'agent peut opérer.

## Choix des limites de vos ressources
<a name="choosing-your-resource-boundaries"></a>

Lorsque vous limitez l'accès aux ressources, vous devez inclure suffisamment d'autorisations pour que l'agent puisse enquêter avec succès sur les incidents liés aux applications. Cela inclut notamment les éléments suivants :
+ Toutes les ressources pour les applications concernées que l'agent doit surveiller et étudier
+ Toute l'infrastructure de support dont dépendent ces applications

L'infrastructure de soutien peut inclure :
+ Composants réseau (sous-réseauxVPCs, équilibreurs de charge, passerelles d'API)
+ Magasins de données (bases de données, caches, stockage d'objets)
+ Ressources de calcul (instances EC2, fonctions Lambda, conteneurs)
+ Services de surveillance et de journalisation (CloudWatch, CloudTrail)
+ Ressources de gestion des identités et des accès nécessaires pour comprendre les autorisations

Si vous limitez trop étroitement l'accès, l'agent risque de ne pas être en mesure d'identifier les causes profondes liées au soutien de l'infrastructure en dehors des limites que vous avez définies.

## Restreindre l'accès aux services
<a name="restricting-service-access"></a>

Vous pouvez limiter les AWS services auxquels l'agent peut accéder en modifiant les politiques IAM associées aux rôles de l'agent. Lorsque vous créez des politiques personnalisées, suivez les meilleures pratiques suivantes :
+ **Accordez uniquement des autorisations en lecture seule** : l'agent doit lire les configurations des ressources, les métriques et les journaux pendant les enquêtes. Évitez d'accorder des autorisations permettant à l'agent de modifier ou de supprimer des ressources.
+ **Limiter les services nécessaires** — N'incluez que les AWS services contenant des ressources pertinentes pour vos applications. Par exemple, si votre application n'utilise pas Amazon RDS, n'incluez pas les autorisations RDS dans la politique.
+ **Utilisez des actions spécifiques plutôt que des caractères génériques** : au lieu d'accorder des `service:*` autorisations, spécifiez des actions individuelles telles que `cloudwatch:GetMetricData` ou`ec2:DescribeInstances`.

Exemple de politique limitée à des services spécifiques :

```
json

{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:DescribeAlarms",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "ec2:DescribeInstances",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "*"
    }
  ]
}
```

## Restreindre l'accès aux ressources
<a name="restricting-resource-access"></a>

Pour limiter l'agent à des ressources spécifiques au sein d'un service, utilisez les autorisations au niveau des ressources dans vos politiques IAM. Cela vous permet de n'accorder l'accès qu'aux ressources qui correspondent à des modèles spécifiques.

**À l'aide de modèles d'ARN de ressources :**

```
{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:*:*:function:production-*"
    }
  ]
}
```

Cet exemple limite l'agent à accéder uniquement aux fonctions Lambda dont le nom commence par « production- ».

**Utilisation de restrictions basées sur des balises :**

```
{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}
```

Cet exemple limite l'agent à accéder uniquement aux instances EC2 étiquetées avec`Environment=production`.

## Restreindre l'accès régional
<a name="restricting-regional-access"></a>

Pour limiter AWS les régions auxquelles l'agent peut accéder, utilisez la clé de `aws:RequestedRegion` condition dans vos politiques IAM :

```
{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "lambda:Get*",
        "cloudwatch:Get*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}
```

Cet exemple limite l'agent à accéder aux ressources uniquement dans les régions us-east-1 et us-west-2.

## Création de politiques IAM personnalisées
<a name="creating-custom-iam-policies"></a>

Lorsque vous créez un espace agent ou que vous ajoutez des comptes secondaires, vous avez la possibilité de créer un rôle IAM personnalisé à l'aide d'un modèle de politique. Cela vous permet de mettre en œuvre le principe du moindre privilège.

**Lors de la création d'un espace d'agent**

Depuis la console de DevOps l'agent dans la console AWS de gestion...
+ Choisissez **Créer un nouveau rôle d' DevOps agent à l'aide d'un document de politique** et suivez les instructions

**Lors de la modification d'un espace d'agent**

Depuis la console de DevOps l'agent dans la console AWS de gestion...
+ Sélectionnez l'onglet **Fonctionnalités**
+ Sélectionnez le compte secondaire que vous souhaitez modifier dans la section **Cloud** et cliquez sur Modifier
+ Choisissez **Créer une nouvelle politique d' DevOps agent à l'aide d'un modèle** et suivez les instructions

## Bonnes pratiques en matière de politiques personnalisées
<a name="custom-policy-best-practices"></a>
+ **Accorder uniquement des autorisations en lecture seule** : évitez les autorisations qui autorisent la modification ou la suppression de ressources
+ **Utilisez des autorisations au niveau des ressources lorsque cela est possible** : limitez l'accès à des ressources spécifiques à l'aide de modèles ou de balises ARN
+ Vérifiez **et auditez régulièrement les autorisations** : passez régulièrement en revue les politiques IAM de l'agent pour vous assurer qu'elles sont toujours conformes à vos exigences de sécurité