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.
AWS DevOps Seguridad del agente
Este documento proporciona información sobre las consideraciones de seguridad, la protección de datos, los controles de acceso y las capacidades de cumplimiento del AWS DevOps agente. Utilice esta información para comprender cómo se ha diseñado AWS DevOps Agent para cumplir con sus requisitos de seguridad y cumplimiento.
Multi-layered seguridad
AWS DevOps El agente implementa la seguridad en varios niveles. Incluso si se conceden permisos más amplios a la función de IAM del agente, el agente aplica sus propios controles de acceso internos para limitar el alcance de sus acciones.
Recomendamos seguir el principio de privilegios mínimos al configurar los permisos de IAM para el AWS DevOps agente e implementar la seguridad en varios niveles. Una defensa exhaustiva garantiza que ningún error de configuración por sí solo pueda comprometer la seguridad de su entorno.
Espacios para agentes
Los espacios de agente sirven como límite de seguridad principal en AWS DevOps Agent. Cada espacio de agente:
Funciona de forma independiente con sus propias configuraciones y permisos
Define a qué AWS cuentas y recursos puede acceder el agente
Establece conexiones con plataformas de terceros
Los espacios de agente mantienen un aislamiento estricto para garantizar la seguridad y evitar el acceso no deseado en diferentes entornos o equipos.
Procesamiento regional y flujo de datos
AWS DevOps Agent opera a nivel mundial con capacidades de procesamiento regionales. El agente recupera los datos operativos de AWS las regiones de todas las AWS cuentas a las que se ha concedido acceso dentro del espacio de agente configurado. Esta recopilación de datos multirregionales entre cuentas garantiza un análisis exhaustivo de los incidentes y, al mismo tiempo, respeta los límites geográficos para el procesamiento de las inferencias.
Uso de Amazon Bedrock e inferencia interregional
AWS DevOps El agente seleccionará automáticamente la región óptima dentro de su geografía para procesar sus solicitudes de inferencia. Esto maximiza los recursos informáticos disponibles, la disponibilidad de los modelos y ofrece la mejor experiencia al cliente. Sus datos permanecerán almacenados solo en la región en la que se haya creado su espacio de agente; sin embargo, las solicitudes de entrada y los resultados de salida se pueden procesar fuera de esa región, tal como se describe en la lista siguiente. Todos los datos se transmitirán cifrados a través de la red segura de Amazon.
AWS DevOps El agente dirigirá de forma segura sus solicitudes de inferencia a los recursos informáticos disponibles dentro del área geográfica en la que se originó la solicitud, de la siguiente manera:
Las solicitudes de inferencia que se originen en la Unión Europea se procesarán dentro de la Unión Europea.
Las solicitudes de inferencia que se originen en los Estados Unidos se procesarán en los Estados Unidos.
Las solicitudes de inferencia que se originen en Australia se procesarán en Australia.
Las solicitudes de inferencia que se originen en Japón se procesarán en Japón.
Si una solicitud de inferencia se origina en un área que no figura en la lista, se procesará de forma predeterminada en los Estados Unidos.
DevOps Agent y Bedrock no se ven afectados por las políticas de clientes incluidas en las Políticas de Control de Servicio (SCP) o Control Tower, que restringen el contenido de los clientes a regiones específicas
Bedrock puede usar regiones distintas de la región de origen dentro de su geografía para realizar inferencias sin estado a fin de optimizar el rendimiento y la disponibilidad
Inferencia global entre regiones para regiones específicas
Para las siguientes regiones, no se aplica el enrutamiento basado en la geografía descrito anteriormente. En su lugar, el AWS DevOps agente seleccionará automáticamente la región óptima a nivel mundial para procesar sus solicitudes de inferencia.
Asia Pacífico (Singapur) –
ap-southeast-1Asia-Pacífico (Bombay) –
ap-south-1América del Sur (São Paulo) –
sa-east-1
Identity and Access Management
Métodos de autenticación
AWS DevOps El agente proporciona dos métodos de autenticación para iniciar sesión en la aplicación web de AWS DevOps Agent Space:
AWS Integración con el centro de identidad: el método de autenticación principal utiliza OAuth 2.0 y la autenticación basada en sesiones mediante cookies. HTTP-only AWS Identity Center puede federarse con proveedores de identidad externos mediante los protocolos OIDC y SAML estándar, incluidos proveedores como Okta, Ping Identity y Microsoft Entra ID. Este método admite la autenticación multifactor a través de su proveedor de identidad. AWS La duración predeterminada de las sesiones de Identity Center es de hasta 12 horas y se puede configurar según la duración deseada.
Enlace de autenticación de IAM: un método alternativo proporciona acceso directo a la aplicación web desde la consola de AWS administración mediante JWT-based tokens derivados de una sesión de consola de AWS administración existente. Esta opción es útil para evaluar al AWS DevOps agente antes de implementar la integración total con el Identity Center, así como para obtener acceso administrativo en caso de que no se pueda acceder a la aplicación web del AWS DevOps agente mediante la autenticación basada en el Identity Center. Las sesiones están limitadas a 10 minutos.
Roles de IAM
AWS DevOps El agente usa las funciones de IAM para definir los permisos de acceso:
Función de cuenta principal: otorga al agente acceso a los recursos de la AWS cuenta en la que se crea el espacio de agente.
Funciones de cuenta secundarias: otorga al agente acceso a los recursos de AWS cuentas adicionales conectadas al espacio de agente.
Función de aplicación web: otorga a los usuarios acceso a los datos y hallazgos de la investigación del AWS DevOps agente en la aplicación web.
Estas funciones deben configurarse siguiendo el principio de privilegios mínimos, concediendo solo los permisos de solo lectura necesarios para las investigaciones.
Protección de datos
Cifrado de datos
AWS DevOps El agente cifra todos los datos de los clientes:
Cifrado en reposo: todos los datos se cifran con claves AWS administradas.
Cifrado en tránsito: todos los registros, las métricas, los elementos de conocimiento, los metadatos de los tickets y otros datos recuperados se cifran durante su tránsito dentro de la red privada del agente y hacia redes externas.
Almacenamiento y retención de datos
Los datos se almacenan en la región en la que se creó su espacio de agente, mientras que el procesamiento de las inferencias puede producirse en su zona geográfica, tal y como se describe en la sección anterior sobre el uso de Amazon Bedrock.
Información de identificación personal (PII)
AWS DevOps El agente no filtra la información de identificación personal al resumir los datos recopilados durante las investigaciones, las evaluaciones de recomendaciones o las respuestas a los chats. Se recomienda redactar los datos de PII antes de almacenarlos en los registros de observabilidad.
El diario del agente y el registro de auditoría
Diario del agente
Tanto la capacidad de investigación como la de prevención de incidentes mantienen diarios detallados que:
Registra cada razonamiento, cada paso y cada acción tomada
Cree una transparencia total en los procesos de toma de decisiones de los agentes
Los agentes no pueden modificarlos una vez registrados, lo que reduce al mínimo los ataques, como la inyección inmediata, al ocultar acciones importantes
Incluye todos los mensajes de chat de la página de investigación
AWS CloudTrail integración
Todas las llamadas a la API del AWS DevOps agente se capturan automáticamente AWS CloudTrail en la AWS cuenta de alojamiento. Con la información recopilada por CloudTrail, puede determinar:
La solicitud que se hizo al agente
La dirección IP desde la que se realizó la solicitud
Quién realizó la solicitud
Cuando se realizó
En el caso de las conexiones a servidores remotos MCP y A2A, puede revisar AuthenticateAccessToken los eventos que el AWS DevOps agente registra CloudTrail cada vez que autentica un token de acceso, incluidas las autenticaciones fallidas. Para obtener más información sobre los campos de eventos y la correlación de las autenticaciones con las acciones posteriores, consulte Trazabilidad en los servidores remotos de Connect to Agent. DevOps
Protección contra inyecciones rápidas
Un ataque de inyección rápida se produce cuando un atacante incrusta instrucciones malintencionadas en datos externos, como una página web o un documento, que un sistema de IA generativa procesará más adelante. AWS DevOps El agente consume de forma nativa muchas fuentes de datos como parte de sus operaciones normales, incluidos los registros, las etiquetas de recursos y otros datos operativos. AWS DevOps El agente protege contra los ataques de inyección inmediata mediante las siguientes medidas de seguridad, pero es importante garantizar que todas las fuentes de datos conectadas y el acceso de los usuarios a esas fuentes de datos sean confiables. Consulte la sección sobre el modelo de responsabilidad compartida para obtener más información.
Medidas de seguridad para una inyección inmediata:
Capacidades de escritura limitadas: las herramientas de las que dispone el agente no permiten modificar los recursos, con la excepción de las solicitudes de apertura y los casos de soporte. Esto evita que las instrucciones malintencionadas modifiquen la infraestructura o las aplicaciones.
Aplicación de los límites de las cuentas: el AWS DevOps agente solo opera dentro de los límites permitidos por las funciones asignadas al agente en las AWS cuentas principales y secundarias conectadas. El agente no puede acceder a los recursos ni modificarlos fuera de su ámbito configurado.
Protecciones de seguridad de la IA: el AWS DevOps agente usa modelos con protecciones de nivel 3 (ASL-3) de seguridad de la IA, que incluyen clasificadores integrados que detectan y resisten los intentos de inyección inmediata. El agente también utiliza el filtro de ataque rápido Amazon Bedrock Guardrails para detectar y bloquear los intentos de inyección y jailbreak rápidos antes de que puedan afectar al comportamiento del agente.
Registro de auditoría inmutable: el diario del agente registra cada paso del razonamiento y cada acción emprendida. El agente no puede modificar las entradas del diario una vez grabadas, lo que evita que los ataques de inyección inmediata oculten acciones malintencionadas.
Si bien el AWS DevOps agente proporciona varios niveles de protección contra los ataques de inyección inmediata, determinadas configuraciones pueden aumentar el riesgo:
Herramientas de servidor MCP personalizadas: la función «traiga su propio MCP» le permite introducir herramientas personalizadas en el agente, lo que puede ofrecer oportunidades adicionales de inyección inmediata. Es posible que las herramientas personalizadas no tengan los mismos controles de seguridad que las herramientas nativas del AWS DevOps agente, y las instrucciones malintencionadas podrían utilizarlas de forma no intencionada. Consulte la sección sobre el modelo de responsabilidad compartida para obtener más información.
Ataques de usuarios autorizados: los usuarios que están autorizados a operar dentro del límite de la AWS cuenta o de las herramientas conectadas tienen más probabilidades de intentar atacar al agente. Estos usuarios pueden modificar las fuentes de datos que consume el agente, como los registros o las etiquetas de recursos, lo que facilita la incorporación de instrucciones malintencionadas que el agente procesará.
Para mitigar estos riesgos:
Revise y pruebe cuidadosamente los servidores MCP personalizados antes de implementarlos en Agent Spaces.
Asegúrese de que solo puedan realizar acciones de solo lectura
Compruebe que los usuarios de las herramientas externas a las que acceden los servidores MCP sean entidades de confianza, ya que AWS DevOps los agentes que interactúan con MCP se basan en la relación de confianza implícita que se establece entre los usuarios de las herramientas y el agente AWS DevOps
Aplique el principio de privilegios mínimos al conceder a los usuarios acceso a los sistemas que proporcionan datos al agente
Audite periódicamente qué servidores MCP están conectados a sus espacios de agente
Dado que cualquier contenido que se recupere de las URL incluidas en la lista de sitios permitidos podría intentar manipular el comportamiento del agente, incluya únicamente fuentes confiables en su lista de sitios permitidos.
Seguridad de integración
AWS DevOps El agente admite varios tipos de integración, cada uno con su propio modelo de seguridad:
Integraciones bidireccionales nativas: Built-in integraciones que pueden enviar datos al agente y recibir actualizaciones del agente. Esto utiliza los métodos de autenticación del proveedor
Servidores MCP: servidores del protocolo de contexto modelo remoto que utilizan los flujos de autenticación de OAuth 2.0 y las claves de API para comunicarse de forma segura con sistemas externos.
Activadores de webhooks: la investigación se desencadena desde servicios remotos, como los tickets o los sistemas de observabilidad. Por motivos de seguridad, los webhooks utilizan firmas del código de autenticación de Hash-based mensajes (HMAC) o una clave API (token portador).
Comunicación saliente: las integraciones como Slack y los sistemas de venta de entradas reciben actualizaciones del agente, pero aún no admiten la comunicación bidireccional.
Proveedores de registro
Algunas herramientas externas se autentican a nivel de cuenta y se comparten entre todos los espacios de agente de la cuenta. Al registrar estas herramientas, se autentica una vez a nivel de cuenta y, a continuación, cada espacio de agente puede conectarse a recursos específicos dentro de esa conexión registrada.
Las siguientes herramientas utilizan el registro a nivel de cuenta:
GitHub— Utiliza el flujo de OAuth para la autenticación. Tras registrarse GitHub a nivel de cuenta, cada espacio de agente puede conectarse a repositorios específicos de su organización. GitHub
Dynatrace: utiliza la autenticación mediante token de OAuth. Tras registrar Dynatrace a nivel de cuenta, cada Agent Space puede conectarse a entornos o configuraciones de monitorización específicos de Dynatrace.
Slack: usa la autenticación mediante el token de OAuth. Tras registrar Slack a nivel de cuenta, cada espacio de agente puede conectarse a canales y canales específicos de Slack.
Datadog: usa MCP con el flujo de OAuth para la autenticación. Después de registrar Datadog a nivel de cuenta, cada espacio de agente puede conectarse a recursos de monitoreo específicos de Datadog.
New Relic: utiliza la autenticación con claves de API. Tras registrar New Relic a nivel de cuenta, cada Agent Space puede conectarse a configuraciones de monitoreo específicas de New Relic.
Splunk: usa la autenticación con el token del portador. Tras registrar Splunk a nivel de cuenta, cada espacio de agente puede conectarse a fuentes de datos específicas de Splunk.
GitLab— Utiliza la autenticación con token de acceso. Tras registrarse GitLab a nivel de cuenta, cada espacio de agente puede conectarse a GitLab repositorios específicos.
ServiceNow— Utiliza la autenticación de clientes de OAuth. key/token Tras registrarse ServiceNow a nivel de cuenta, cada espacio de agente puede conectarse a ServiceNow instancias o colas de tickets específicas.
Servidores MCP remotos de acceso público en general: utilice el flujo de OAuth para la autenticación. Tras registrar un servidor MCP remoto a nivel de cuenta, cada espacio de agente puede conectarse a los recursos específicos expuestos por ese servidor.
Conectividad de red
AWS DevOps El agente se conecta a los sistemas de terceros y a los servidores MCP remotos para realizar investigaciones y otras operaciones.
Tráfico entrante desde AWS DevOps Agente a sus sistemas
AWS DevOps El agente inicia las conexiones salientes a sus sistemas de terceros y servidores MCP remotos, que llegan como tráfico entrante a su infraestructura. La forma de proteger este tráfico depende de cómo estén alojadas las herramientas:
Herramientas alojadas de forma privada: si puedes acceder a tus herramientas desde una AWS VPC, puedes usar las conexiones privadas de los AWS DevOps agentes para mantener el tráfico aislado de AWS las redes y alejado de la Internet pública. Para obtener más información, consulte Conexión a herramientas alojadas de forma privada.
Herramientas alojadas de forma pública: si puedes acceder a tus herramientas a través de una red pública de Internet y utilizan reglas de firewall o listas de direcciones IP permitidas, debes permitir el tráfico entrante desde las siguientes AWS DevOps direcciones IP de origen del agente:
Asia-Pacífico (Sídney) (ap-southeast-2)
13.237.95.19713.238.84.10252.64.174.24213.211.249.1315.134.235.543.107.145.226
Asia-Pacífico (Tokio) (ap-northeast-1)
13.192.12.23335.74.181.23057.183.50.15813.114.228.8954.150.140.2846.51.224.121
Europa (Fráncfort) (eu-central-1)
18.158.110.14052.57.96.16052.59.55.5663.183.67.11163.184.95.13263.184.36.38
Europa (Irlanda) (eu-west-1)
34.251.85.2452.30.157.15752.51.192.22299.81.41.5254.246.170.10352.212.224.65
Este de EE. UU. (Norte de Virginia) (us-east-1)
34.228.181.12844.219.176.18754.226.244.221100.56.22.593.234.39.444.215.92.10
Oeste de EE. UU. (Oregón) (us-west-2)
34.212.16.13352.89.67.21254.187.135.6134.209.115.8944.224.219.8654.201.89.243
América del Sur (São Paulo) (sa-east-1)
54.207.222.1454.232.201.24254.94.247.21354.94.50.3654.20.8.10652.67.155.119
Asia-Pacífico (Mumbai) (ap-south-1)
13.126.209.19913.234.6.2435.154.102.21613.200.172.21713.235.168.2113.206.231.7
Asia-Pacífico (Singapur) (ap-southeast-1)
18.139.13.12547.130.240.21554.179.238.17354.169.147.21152.77.189.9652.77.31.188
Canadá (centro) (ca-central-1)
3.96.5.293.99.39.1299.79.90.22116.52.252.1116.52.242.4915.157.224.32
Europa (Londres) (eu-west-2)
13.42.228.6616.60.62.5835.176.240.1016.60.67.1273.9.91.24835.179.253.69
El tráfico saliente de su VPC a AWS DevOps Agente
Para el tráfico saliente de tu AWS VPC al AWS DevOps agente (por ejemplo, usandoInvocar al DevOps agente a través de Webhook), puedes usar los puntos de enlace de la VPC para mantener este tráfico de red aislado de las redes. AWS Para obtener más información, consulte Puntos de enlace de la VPC (AWS PrivateLink).
Modelo de responsabilidad compartida
AWS responsabilidades
AWS es responsable de:
Mantener la seguridad de los datos recuperados por el agente
Proteger las herramientas nativas disponibles para que las utilice el agente
Proteger la infraestructura en la que se ejecuta el AWS DevOps Agente
Responsabilidades del cliente
Los clientes son responsables de:
Administrar el acceso de los usuarios al espacio de agentes
Limitar el acceso a los usuarios confiables de sistemas externos que proporcionan información al agente, como los servicios y recursos que generan registros, CloudTrail eventos, tickets, etc., que pueden usarse para intentar introducir información de forma inmediata con fines malintencionados.
Asegúrese de que todas las fuentes de datos conectadas tengan datos confiables que no puedan usarse para intentar ataques de inyección inmediata
Asegúrese de que las integraciones de servidores MCP con la opción de traer su propio servidor MCP funcionen de forma segura
Garantizar que las funciones de IAM asignadas al agente tengan el alcance correcto
Redactar los datos de PII antes de almacenarlos en los registros de observabilidad y otras fuentes de datos del agente
Seguir la práctica recomendada de conceder únicamente permisos de solo lectura a las fuentes de datos conectadas, incluidos los servidores MCP personalizados
Uso de datos
AWS no utiliza los datos de los agentes, los mensajes de chat ni los datos de fuentes de datos integradas para entrenar modelos o mejorar el producto. The AWS DevOps Agent Space utiliza los comentarios de los clientes sobre el producto para mejorar las respuestas e investigaciones del agente, pero AWS no los utiliza para mejorar el servicio en sí.
Para prestar el servicio y evaluar su rendimiento, es posible que recopilemos señales operativas sobre su uso del gestor de versiones del AWS DevOps agente, como estadísticas basadas en sus comentarios sobre la revisión del estado de preparación del lanzamiento (por ejemplo, si ha corregido un problema marcado, ha accedido a solucionarlo más adelante, no está de acuerdo con él o ha implementado un cambio de código sugerido).
