Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Limitar el acceso de los agentes en un AWS Cuenta

AWS DevOps El agente utiliza las funciones de IAM para descubrir y describir AWS los recursos durante las investigaciones de incidentes y las evaluaciones preventivas. Puede controlar el nivel de acceso del agente configurando las políticas de IAM asociadas a estas funciones. La topología de la aplicación no muestra todo a lo que tiene acceso el agente; las políticas de IAM son la única manera de limitar realmente los recursos y las API de AWS servicio a los que puede acceder el agente.

Comprender las funciones de IAM para AWS DevOps ¿Agente

AWS DevOps El agente usa las funciones de IAM para acceder a los recursos de dos tipos de cuentas:

Para cualquier tipo de cuenta, puede restringir AWS los servicios a los que puede acceder el agente, limitar el acceso a recursos específicos dentro de esos servicios y controlar en qué regiones puede operar el agente.

Entender las barreras de protección de permisos

AWS DevOps El agente aplica una barrera de protección de permisos a cada sesión que crea al acceder a sus recursos. AWS Esta barrera actúa como límite: define el conjunto máximo de permisos que el agente puede utilizar en cualquier momento, independientemente de los permisos que se concedan en el rol de IAM.

Funcionamiento

Cuando el agente asume tu función de IAM, aprueba una política de sesión que limita los permisos efectivos para esa sesión. Los permisos vigentes son la intersección de:

El permiso debe estar presente en ambas capas para que surta efecto. Si agrega un permiso a su rol que no está incluido en la barrera, el agente no podrá usarlo.

Permisos predeterminados

La política AIDevOpsAgentAccessPolicy administrada proporciona el conjunto predeterminado de permisos de solo lectura que el agente usa para las investigaciones. Estos permisos están incluidos en la barandilla, por lo que funcionan sin necesidad de configuración adicional.

Ampliar los permisos más allá de los predeterminados

La política AIDevOpsAgentAccessPolicy administrada predeterminada otorga solo un subconjunto de lo que permite la barandilla. La barandilla también permite todas las acciones de la política ReadOnlyAccess AWS gestionada, además de algunos permisos adicionales. Para usar un permiso que la barrera permite pero la política predeterminada no lo otorga, agréguelo a su función como política integrada.

Por ejemplo, para permitir que el agente lea los objetos de tus buckets de S3 durante las investigaciones, agrega una política integrada a tu función:

{
  "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/*"
      ]
    }
  ]
}

Debido a que s3:GetObject s3:ListBucket están incluidos en la barandilla, esta política interna entra en vigor. Puedes ampliarlos Resource a grupos específicos para seguir el principio del mínimo privilegio.

Permisos adicionales admitidos

Puedes habilitar cualquier permiso que admita la barandilla agregándolo a tu rol como política integrada. Estos no se conceden de forma predeterminada; debes darte de alta de forma explícita.

Hemos probado y verificado exhaustivamente que solo los permisos de la política AIDevOpsAgentAccessPolicy gestionada son seguros para su uso con el agente. Los demás permisos que admite la barandilla no se han probado con el agente. Permitirlos se encuadra en el modelo de responsabilidad AWS compartida. Usted es responsable de evaluar si esas acciones son apropiadas para que el agente las lleve a cabo en función de sus recursos. Amplícalas para que sigan el principio del mínimo privilegio.

En la siguiente tabla se enumeran los permisos adicionales que admite la barandilla además de la política ReadOnlyAccess gestionada.

Permisos bloqueados por la barandilla

Si agrega un permiso a su rol que no está en la barrera, el agente no podrá usarlo. Esto ocurre por diseño: la barrera impide que el agente lleve a cabo acciones fuera del alcance previsto, incluso si el rol lo permitiera de otro modo.

Por ejemplo, operaciones de escritura como s3:PutObjectec2:TerminateInstances, o no dynamodb:DeleteItem están incluidas en la barandilla. Aunque su función conceda estos permisos, el agente no puede realizar estas acciones.

Resumen

Este modelo garantiza que el agente funcione dentro de un límite de seguridad bien definido y, al mismo tiempo, le brinda la flexibilidad de ampliar sus capacidades para su caso de uso específico.

Cómo elegir los límites de sus recursos

Al limitar el acceso a los recursos, debe incluir suficientes permisos para que el agente investigue correctamente los incidentes de las aplicaciones. Esto incluye:

La infraestructura de soporte puede incluir:

Si restringe el acceso de forma demasiado estricta, es posible que el agente no pueda identificar las causas principales que se originan en la infraestructura de soporte fuera de los límites definidos.

Restricción del acceso al servicio

Puede limitar AWS los servicios a los que puede acceder el agente modificando las políticas de IAM asociadas a las funciones del agente. Al crear políticas personalizadas, siga estas prácticas recomendadas:

Ejemplo de política que restringe a servicios específicos:

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": "*"
    }
  ]
}

Limitar el acceso a los recursos

Para limitar el agente a recursos específicos de un servicio, usa los permisos a nivel de recursos en tus políticas de IAM. Esto te permite conceder acceso solo a los recursos que coincidan con patrones específicos.

Uso de patrones de ARN de recursos:

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

En este ejemplo, se limita al agente a acceder únicamente a las funciones de Lambda con nombres que comiencen por «production-».

Uso de restricciones basadas en etiquetas:

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

En este ejemplo, se limita al agente a acceder únicamente a las instancias EC2 etiquetadas con. Environment=production

Restringir el acceso regional

Para limitar AWS las regiones a las que puede acceder el agente, usa la clave de aws:RequestedRegion condición en tus políticas de 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"
          ]
        }
      }
    }
  ]
}

En este ejemplo, se limita al agente a acceder a los recursos únicamente en las regiones us-east-1 y us-west-2.

Creación de políticas de IAM personalizadas

Al crear un espacio de agente o añadir cuentas secundarias, tiene la opción de crear un rol de IAM personalizado mediante una plantilla de políticas. Esto le permite implementar el principio de privilegio mínimo.

Al crear un espacio de agente

Desde la consola del DevOps agente en la consola AWS de administración...

Al editar un espacio de agente

Desde la consola del DevOps agente en la consola AWS de administración...

Mejores prácticas en materia de políticas personalizadas