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 :

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 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-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. 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.

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

L'infrastructure de soutien peut inclure :

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 :

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 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'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...

Lors de la modification d'un espace d'agent

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

Meilleures pratiques en matière de politiques personnalisées