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.
Crear un rol de IAM para el agente de seguridad de AWS
El agente de seguridad de AWS utiliza las funciones de IAM de tres maneras:
-
Función de aplicación: se utiliza al crear la aplicación AWS Security Agent. En los casos de uso del centro de identidad de IAM y del enlace de acceso de administrador, el servicio asume esta función para conceder a WebApp los usuarios permisos para interactuar con las API de AWS Security Agent.
-
Función del servicio de pruebas de penetración: se especifica al crear espacios de agentes como una lista de funciones disponibles. Más adelante, WebApp los usuarios seleccionan uno de estos roles al crear una prueba de penetración. El servicio AWS Security Agent asume esta función para acceder a los recursos de AWS durante las pruebas.
-
Función de actor: se utiliza para autenticar y autorizar las solicitudes a la aplicación web de destino (por ejemplo, las API API Gateway de AWS). Estas funciones se proporcionan durante la creación del espacio de agentes. El agente de seguridad de AWS asume funciones de actor para interactuar con la aplicación de destino.
Rol de aplicación
El rol de aplicación se utiliza al crear la aplicación AWS Security Agent en el servicio. En los escenarios de autenticación del centro de identidad de IAM y del enlace de acceso de administrador, el servicio AWS Security Agent asume esta función para conceder a WebApp los usuarios los permisos necesarios para interactuar con las API de AWS Security Agent.
Permisos necesarios
Este rol necesita permisos para:
-
Invoque las operaciones de la API de AWS Security Agent
-
Lea y escriba los datos de configuración de la aplicación
-
Acceda a la información de la sesión del usuario
-
Administre los tokens de autenticación para WebApp los usuarios
Política de confianza
La política de confianza debe permitir que el servicio AWS Security Agent asuma esta función:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Política de permisos
El rol debe incluir permisos para:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "securityagent:GetApplication", "securityagent:UpdateApplication", "securityagent:ListAgentInstances", "securityagent:CreatePentestSession" ], "Resource": "arn:aws:securityagent:*:*:application/*" } ] }
nota
Personalice los permisos en función de los requisitos específicos de su aplicación y del principio de privilegio mínimo.
Función del servicio de pruebas de penetración
El rol del servicio de pruebas de penetración se especifica al crear espacios de agentes como una lista de roles disponibles. Cuando WebApp los usuarios crean una prueba de penetración, seleccionan uno de estos roles. A continuación, el servicio AWS Security Agent asume esta función para acceder a los recursos de AWS y probarlos.
Permisos necesarios
Este rol necesita permisos para acceder a sus recursos de AWS y analizarlos durante las pruebas de penetración:
-
Lea y describa las configuraciones de VPC y la topología de red
-
Inspeccione las instancias, los grupos de seguridad y las ACL de red de EC2
-
Analice las políticas de IAM y los permisos de recursos
-
Lea CloudWatch los registros y las métricas
-
Acceda a las configuraciones de servicios de AWS relevantes para las pruebas de seguridad
Política de confianza
La política de confianza debe permitir que el servicio AWS Security Agent asuma esta función en las operaciones de pruebas de penetración:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "your-external-id" } } } ] }
nota
Utilice un ID externo como medida de seguridad adicional cuando permita el acceso entre cuentas o servicios.
Política de permisos
El rol debe incluir acceso de solo lectura a sus recursos de AWS. Considere la posibilidad de utilizar estas políticas administradas:
-
SecurityAudit- Política gestionada por AWS para la auditoría de seguridad -
ViewOnlyAccess- Read-only acceso a la mayoría de los servicios de AWS
O cree una política personalizada con permisos específicos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:Describe*", "vpc:Describe*", "iam:Get*", "iam:List*", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "cloudwatch:Describe*", "cloudwatch:Get*", "cloudwatch:List*", "s3:GetObject", "s3:ListBucket" ], "Resource": "*" } ] }
importante
Concede solo los permisos mínimos necesarios para el alcance de tus pruebas de penetración. Revise y ajuste los permisos en función de los servicios de AWS que desee incluir en las pruebas de seguridad.
Rol de actor
El rol de actor se utiliza para autenticar y autorizar las solicitudes a la aplicación web de destino durante las pruebas de penetración. Estas funciones se proporcionan durante la creación del espacio de agentes y el agente de AWS Security Agent las asume para interactuar con los puntos de enlace de la aplicación de destino (como las API de API Gateway de AWS, las URL de funciones de Lambda u AWS-hosted otras aplicaciones).
Permisos necesarios
Este rol necesita permisos para:
-
Invocar puntos finales de API Gateway
-
Ejecute funciones Lambda
-
Acceda a los recursos de AWS específicos de cada aplicación
-
Autentíquese con los mecanismos de autenticación de la aplicación de destino
-
Realice operaciones HTTP en los puntos finales de su aplicación
Política de confianza
La política de confianza debe permitir que el servicio de agentes de AWS Security Agent asuma esta función:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "your-external-id" } } } ] }
Política de permisos
Los permisos dependen de la arquitectura de la aplicación de destino. A continuación, se muestran ejemplos de escenarios comunes:
Para aplicaciones API Gateway
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": "arn:aws:execute-api:us-east-1:*:your-api-id/*" } ] }
Para las direcciones URL de funciones Lambda
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:InvokeFunctionUrl", "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:us-east-1:*:function:your-function-name" } ] }
Para Application Load Balancer con Autenticación de Cognito
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cognito-idp:InitiateAuth", "cognito-idp:RespondToAuthChallenge" ], "Resource": "arn:aws:cognito-idp:us-east-1:*:userpool/your-user-pool-id" } ] }
importante
Configure los permisos de Actor Role para que coincidan con los requisitos de autenticación y autorización de la aplicación de destino. El rol debe tener el mismo nivel de acceso que los usuarios o servicios que el agente de seguridad simulará durante las pruebas de penetración.
