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 dans un AWS Compte
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 n'indique pas tout ce à quoi l'agent a accès. Les politiques IAM sont le seul moyen de réellement limiter les API de AWS service et les ressources auxquelles l'agent peut accéder.
## Comprendre les rôles IAM pour AWS DevOps Agent
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 des comptes secondaires ** : permet à l'agent d'accéder aux ressources AWS des 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.
## Comprendre les barrières d'autorisation
AWS DevOps L'agent applique une barrière d'autorisation à chaque session qu'il crée lors de l'accès à vos AWS ressources. Ce garde-fou agit comme un plafond : il définit l'ensemble maximum d'autorisations que l'agent peut utiliser, quelles que soient les autorisations que vous accordez au rôle IAM.
### Comment ça marche
Lorsque l'agent assume votre rôle IAM, il transmet une politique de [ session ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) qui limite les autorisations effectives pour cette session. Les autorisations effectives se situent à l'intersection des éléments suivants :
1. **Vos politiques de rôle IAM ** : la politique gérée et toutes les politiques en ligne que vous associez au rôle.
1. **Le garde-fou en matière d'autorisations ** : politique de session appliquée par l' AWS DevOps agent au moment de l'attribution du rôle.
Une autorisation doit être présente dans les deux couches pour prendre effet. Si vous ajoutez une autorisation à votre rôle qui n'est pas incluse dans le garde-corps, l'agent ne peut pas l'utiliser.
### Autorisations par défaut
La politique `AIDevOpsAgentAccessPolicy` gérée fournit l'ensemble par défaut d'autorisations en lecture seule que l'agent utilise pour les enquêtes. Ces autorisations sont incluses dans le garde-corps, elles fonctionnent donc sans configuration supplémentaire.
### Étendre les autorisations au-delà des autorisations par défaut
La politique `AIDevOpsAgentAccessPolicy` gérée par défaut n'accorde qu'un sous-ensemble de ce que permet le garde-corps. Le garde-fou autorise également toutes les actions de la politique `ReadOnlyAccess` AWS gérée, ainsi que quelques autorisations supplémentaires. Pour utiliser une autorisation que le garde-fou autorise mais que la politique par défaut n'accorde pas, ajoutez-la à votre rôle en tant que politique en ligne.
Par exemple, pour permettre à l'agent de lire les objets de vos compartiments S3 pendant les investigations, ajoutez une politique en ligne à votre rôle :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-application-bucket",
"arn:aws:s3:::my-application-bucket/*"
]
}
]
}
```
Parce que `s3:GetObject` et `s3:ListBucket` sont inclus dans le garde-corps, cette politique en ligne entre en vigueur. Vous pouvez définir deux compartiments spécifiques `Resource` afin de respecter le principe du moindre privilège.
### Autorisations supplémentaires prises en charge
Vous pouvez activer n'importe quelle autorisation prise en charge par le garde-fou en l'ajoutant à votre rôle en tant que politique en ligne. Ils ne sont pas accordés par défaut. Vous devez vous y inscrire de manière explicite.
Nous avons entièrement testé et vérifié que seules les autorisations de la politique `AIDevOpsAgentAccessPolicy` gérée peuvent être utilisées en toute sécurité avec l'agent. Les autres autorisations prises en charge par le garde-corps n'ont pas été testées avec l'agent. Les habiliter s'inscrit dans le modèle de responsabilité [AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/). Il vous incombe d'évaluer si ces actions sont appropriées pour que l'agent puisse les exécuter sur vos ressources. Délimitez-les pour qu'ils suivent le principe du moindre privilège.
Le tableau suivant répertorie les autorisations supplémentaires prises en charge par le garde-fou au-delà de la politique `ReadOnlyAccess` gérée.
| Service | Actions | Cas d’utilisation |
| --- | --- | --- |
| Amazon Athena | athena:StartQueryExecution, athena:StopQueryExecution | Exécutez des requêtes Athena sur votre catalogue de données |
| AWS KMS | kms:Decrypt | Déchiffrez les ressources chiffrées telles que les objets S3 |
**Remarque : ** Cette liste peut s'allonger au fil du temps à mesure que de nouvelles fonctionnalités sont ajoutées à AWS DevOps l'Agent. Le garde-fou bloque toutes les autorisations non répertoriées ici ou dans `AIDevOpsAgentAccessPolicy` les politiques `ReadOnlyAccess` gérées.
### Autorisations bloquées par le garde-corps
Si vous ajoutez une autorisation à votre rôle qui ne figure pas dans le garde-corps, l'agent ne peut pas l'utiliser. Cela est dû à sa conception : le garde-fou empêche l'agent d'effectuer des actions dépassant le cadre prévu, même si son rôle le lui permettrait autrement.
Par exemple, les opérations d'écriture telles que `s3:PutObject``ec2:TerminateInstances`, ou ne `dynamodb:DeleteItem` sont pas incluses dans le garde-corps. Même si votre rôle accorde ces autorisations, l'agent ne peut pas effectuer ces actions.
### Résumé
| Couche | Qui le contrôle | Objectif |
| --- | --- | --- |
| Politiques relatives aux rôles IAM | Vous | Définissez ce que vous voulez que l'agent soit capable de faire |
| Garde-corps d'autorisation | AWS DevOps Agent | Définit le maximum que l'agent peut faire |
| Autorisations en vigueur | Intersection des deux | Ce que l'agent peut réellement faire |
Ce modèle garantit que l'agent fonctionne dans une limite de sécurité bien définie tout en vous offrant la flexibilité nécessaire pour étendre ses fonctionnalités en fonction de votre cas d'utilisation spécifique.
## Choisir les limites de vos ressources
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 examiner
+ Toutes les infrastructures de support dont dépendent ces applications
L'infrastructure de soutien peut inclure :
+ Composants réseau (VPC, sous-réseaux, équilibreurs de charge, passerelles 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 d'enregistrement (CloudWatch, CloudTrail)
+ Ressources de gestion des identités et des accès nécessaires pour comprendre les autorisations
Si vous limitez l'accès de manière trop étroite, l'agent risque de ne pas être en mesure d'identifier les causes profondes liées à la prise en charge de l'infrastructure en dehors de vos limites définies.
## Restreindre l'accès aux services
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 bonnes 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 aux services nécessaires ** — Incluez uniquement les AWS services qui contiennent 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 se limitant à 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
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 d'accorder l'accès uniquement 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'accès de l'agent aux seules fonctions Lambda dont le nom commence par « production- ».
**Utilisation de restrictions basées sur les balises : **
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
}
]
}
```
Cet exemple limite l'accès de l'agent aux seules instances EC2 marquées avec`Environment=production`.
## Restreindre l'accès régional
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'accès de l'agent aux ressources uniquement dans les régions us-east-1 et us-west-2.
## Création de politiques IAM personnalisées
Lorsque vous créez un espace d'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 l' DevOps 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 l' DevOps agent dans la console AWS de gestion...
+ Sélectionnez l'**onglet ** Capacités
+ Sélectionnez le compte secondaire que vous souhaitez modifier dans la ** section ** Cloud et choisissez Modifier
+ Choisissez ** Créer une nouvelle politique d' DevOps agent à l'aide d'un modèle ** et suivez les instructions
## Meilleures pratiques en matière de politiques personnalisées
+ **Accorder des autorisations en lecture seule ** : évitez les autorisations qui autorisent la modification ou la suppression de ressources
+ **Utilisez les autorisations au niveau des ressources lorsque cela est possible ** — Restreignez l'accès à des ressources spécifiques à l'aide de modèles ou de balises ARN
+ **Passez régulièrement en revue et auditez 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é