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 aux 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 ne montre 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 :

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 en matière d'autorisations

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 sur le rôle IAM.

Comment ça marche

Lorsque l'agent assume votre rôle IAM, il adopte une politique de session qui limite les autorisations effectives pour cette session. Les autorisations effectives se situent à l'intersection des éléments suivants :

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-fou, 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

AWS DevOps L'agent prend en charge un ensemble organisé d'autorisations supplémentaires au-delà de la politique gérée par défaut. Ces autorisations sont incluses dans le garde-corps mais ne sont pas activées par défaut. Pour les utiliser, ajoutez les autorisations spécifiques à votre rôle sous forme de politique intégrée.

Par exemple, pour permettre à l'agent de lire les objets de vos compartiments S3 pendant les investigations, ajoutez une politique intégrée à 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 intégrée entre en vigueur. Vous pouvez définir les Resource deux compartiments spécifiques afin de respecter le principe du moindre privilège.

Autorisations supplémentaires prises en charge

Les autorisations suivantes sont incluses dans le garde-fou et peuvent être activées en les ajoutant à votre rôle en tant que politique intégrée. Ils ne sont pas accordés par défaut ; vous devez vous y inscrire explicitement.

Autorisations bloquées par le garde-corps

Si vous ajoutez une autorisation à votre rôle qui ne figure pas dans le garde-fou, l'agent ne peut pas l'utiliser. Cela est intentionnel : le garde-corps empêche l'agent d'effectuer des actions hors du cadre prévu, même si le rôle le permettrait autrement.

Par exemple, les opérations d'écriture telles que s3:PutObjectec2: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é

Ce modèle garantit que l'agent fonctionne dans des limites de sécurité bien définies tout en vous donnant la flexibilité d'étendre ses fonctionnalités en fonction de votre cas d'utilisation spécifique.

Choix des 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 :

L'infrastructure de soutien peut inclure :

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

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 :

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

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.

Utilisation 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 avecEnvironment=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'agent à accéder 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 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...

Lors de la modification d'un espace d'agent

Depuis la console de DevOps l'agent dans la console AWS de gestion...

Bonnes pratiques en matière de politiques personnalisées