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 forma de limitar realmente a qué API y recursos de AWS servicio 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 en dos tipos de cuentas:
+ **Función de cuenta principal**: otorga al agente acceso a los recursos de la AWS cuenta en la que se crea el espacio de agentes.
+ **Funciones de cuenta secundarias**: otorga al agente acceso a los recursos de AWS las cuentas adicionales que usted conecte al espacio de agentes.
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.
## Cómo entender los límites de los 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, independientemente de los permisos que concedas en el rol de IAM.
### Funcionamiento
Cuando el agente asume su función de IAM, aprueba una [política de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) que limita los permisos efectivos para esa sesión. Los permisos efectivos son la intersección de:
1. **Sus políticas de función de IAM**: la política gestionada y cualquier política integrada que asocie a la función.
1. **La barrera de permisos: una política de** sesión que aplica el AWS DevOps agente al asumir su función.
Para que surta efecto, debe haber un permiso en ambas capas. Si añade un permiso a su función que no esté incluido en la barrera, el agente no podrá usarlo.
### Permisos predeterminados
La política `AIDevOpsAgentAccessPolicy` gestionada proporciona el conjunto predeterminado de permisos de solo lectura que el agente utiliza 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 lo predeterminado
AWS DevOps El agente admite un conjunto seleccionado de permisos adicionales además de la política administrada predeterminada. Estos permisos están incluidos en la barandilla, pero no están habilitados de forma predeterminada. Para utilizarlos, añada los permisos específicos a su función como política integrada.
Por ejemplo, para permitir que el agente lea los objetos de sus depósitos de S3 durante las investigaciones, añada una política integrada a su 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/*"
]
}
]
}
```
Esta política en `s3:ListBucket` línea entra en vigor porque `s3:GetObject` está incluida en la barrera de protección. Puede seleccionar los dos grupos específicos `Resource` para seguir el principio del mínimo privilegio.
### Se admiten permisos adicionales
Los siguientes permisos están incluidos en la barandilla y se pueden habilitar agregándolos a su rol como una política integrada. Estos no se conceden de forma predeterminada, por lo que debes activarlos de forma explícita.
| Servicio | Acciones | Caso de uso |
| --- | --- | --- |
| Amazon S3 | s3:GetObject, s3:ListBucket | Lea los datos, los registros o la configuración de la aplicación almacenados en S3 |
| AWS Direct Connect | directconnect:DescribeConnections, directconnect:DescribeDirectConnectGatewayAssociations, directconnect:DescribeDirectConnectGateways, directconnect:DescribeLags, directconnect:DescribeVirtualInterfaces | Investigue los problemas de conectividad de red |
**Nota:** Esta lista puede ampliarse con el tiempo a medida que se agreguen nuevas capacidades al AWS DevOps agente. La barrera bloquea los permisos que no figuran aquí ni en la política `AIDevOpsAgentAccessPolicy` gestionada.
### Permisos bloqueados por la barandilla
Si agrega un permiso a su función que no esté en la barrera de protección, el agente no podrá usarlo. Esto se debe a su diseño: la barrera impide que el agente lleve a cabo acciones fuera del alcance previsto, incluso si la función lo permitiera de otro modo.
Por ejemplo, escriba operaciones como `s3:PutObject``ec2:TerminateInstances`, o no `dynamodb:DeleteItem` estén incluidas en la barandilla. Incluso si su rol otorga estos permisos, el agente no puede realizar estas acciones.
### Resumen
| Capa | ¿Quién lo controla | Finalidad |
| --- | --- | --- |
| Políticas de funciones de IAM | You | Defina lo que pretende que pueda hacer el agente |
| Barandilla de permisos | AWS DevOps ¿Agente | Define lo máximo que el agente puede hacer |
| Permisos efectivos | Intersección de ambos | ¿Qué es lo que realmente puede hacer el agente |
Este modelo garantiza que el agente funcione dentro de un límite de seguridad bien definido y, al mismo tiempo, le brinda flexibilidad para ampliar sus capacidades para su caso de uso específico.
## Elegir los límites de sus recursos
Al limitar el acceso a los recursos, debe incluir permisos suficientes para que el agente investigue correctamente los incidentes de las aplicaciones. Esto incluye:
+ Todos los recursos para las aplicaciones incluidas en el ámbito de aplicación que el agente debe supervisar e investigar
+ Toda la infraestructura de soporte de la que dependen esas aplicaciones
La infraestructura de soporte puede incluir:
+ Componentes de red (VPC, subredes, balanceadores de carga, pasarelas de API)
+ Almacenes de datos (bases de datos, cachés, almacenamiento de objetos)
+ Recursos informáticos (instancias EC2, funciones Lambda, contenedores)
+ Servicios de supervisión y registro (CloudWatch,) CloudTrail
+ Recursos de administración de identidad y acceso necesarios para comprender los permisos
Si restringe el acceso de forma demasiado restringida, es posible que el agente no pueda identificar las causas fundamentales que se originan en la infraestructura de soporte que está 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:
+ **Otorgue únicamente permisos de solo lectura**: el agente debe leer las configuraciones, las métricas y los registros de los recursos durante las investigaciones. Evite conceder permisos que permitan al agente modificar o eliminar recursos.
+ **Limite a los servicios necesarios**: incluya solo los AWS servicios que contienen los recursos relevantes para sus aplicaciones. Por ejemplo, si su aplicación no usa Amazon RDS, no incluya los permisos de RDS en la política.
+ **Utilice acciones específicas en lugar de caracteres comodín**: en lugar de conceder `service:*` permisos, especifique acciones individuales como o. `cloudwatch:GetMetricData` `ec2:DescribeInstances`
Ejemplo de política que se 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 dentro de un servicio, utilice los permisos a nivel de recurso en sus políticas de IAM. Esto le permite conceder acceso únicamente 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-*"
}
]
}
```
Este ejemplo 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"
}
}
}
]
}
```
Este ejemplo limita al agente a acceder únicamente a las instancias de EC2 etiquetadas con. `Environment=production`
## Restringir el acceso regional
Para limitar AWS las regiones a las que puede acceder el agente, utilice la clave de `aws:RequestedRegion` condición de sus 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"
]
}
}
}
]
}
```
Este ejemplo 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 privilegios mínimos.
**Al crear un espacio de agente**
Desde la consola del DevOps agente en la consola AWS de administración...
+ Elija **Crear un nuevo rol de DevOps agente mediante un documento de política** y siga las instrucciones
**Al editar un espacio de agente**
Desde la consola del DevOps agente a la consola AWS de administración...
+ Seleccione la pestaña **Capacidades**
+ Seleccione la cuenta secundaria que desee editar en la sección **Cloud** y haga clic en Editar
+ Elige **Crear una nueva política de DevOps agente mediante una plantilla** y sigue las instrucciones
## Mejores prácticas en materia de políticas personalizadas
+ **Otorgue únicamente permisos de solo lectura**: evite los permisos que permiten la modificación o eliminación de recursos
+ **Utilice permisos a nivel de recursos siempre que sea posible**: restrinja el acceso a recursos específicos mediante patrones o etiquetas ARN
+ **Revise y audite los permisos con regularidad**: revise periódicamente las políticas de IAM del agente para asegurarse de que siguen ajustándose a sus requisitos de seguridad