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 conformidad de AWS DevOps Agent. Utilice esta información para comprender cómo se ha diseñado AWS DevOps Agent para cumplir sus requisitos de seguridad y conformidad.
Seguridad multicapa
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. Por ejemplo, si un cliente añade una política completa de IAM de acceso a Amazon S3 a la función de IAM del agente, el AWS DevOps agente se asegurará de que solo se lean los registros posteriores al AWSLogs prefijo para solucionar problemas.
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 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 Agent Spaces mantienen un aislamiento estricto para garantizar la seguridad y evitar el acceso no deseado a través de diferentes entornos o equipos.
Procesamiento regional y flujo de datos
AWS DevOps El agente 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 en el espacio de agente configurado. Esta recopilación de datos entre cuentas multirregionales 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 entre regiones
AWS DevOps El agente seleccionará automáticamente la región óptima dentro de su zona geográfica para procesar sus solicitudes de inferencia. Esto maximiza los recursos informáticos disponibles, la disponibilidad del modelo y ofrece la mejor experiencia al cliente. Sus datos permanecerán almacenados únicamente en la región en la que se creó su espacio de agente; sin embargo, es posible que las solicitudes de entrada y los resultados de salida se procesen fuera de esa región, como se describe en la siguiente lista. Todos los datos se transmitirán cifrados a través de la red segura de Amazon.
AWS DevOps El agente dirigirá sus solicitudes de inferencia de forma segura a los recursos informáticos disponibles en el á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 cliente de las Políticas de Control de Servicios (SCPs) o de la Torre de Control, que restringen el contenido de los clientes a regiones específicas
Bedrock puede utilizar 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
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 AWS DevOps Agent Space:
AWS Integración con Identity Center: el método de autenticación principal utiliza la OAuth versión 2.0 y la autenticación basada en sesiones mediante cookies exclusivas de HTTP. AWS Identity Center puede federarse con proveedores de identidad externos a través de los protocolos OIDC y SAML estándar, incluidos proveedores como Okta, Ping Identity y Microsoft Entra ID. Este método admite la autenticación multifactorial a través de su proveedor de identidad. AWS Identity Center establece de forma predeterminada una duración de sesión 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 tokens basados en JWT derivados de una sesión de la consola de administración existente. AWS Esta opción es útil para evaluar el AWS DevOps agente antes de implementar la integración completa de Identity Center, así como para obtener acceso administrativo si la aplicación web del AWS DevOps agente deja de ser accesible mediante la autenticación basada en 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 creó el espacio de agentes, así como acceso a las funciones de la cuenta secundaria.
Funciones de cuenta secundarias: otorga al agente acceso a los recursos de AWS cuentas adicionales conectadas al espacio de agentes.
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 y 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, métricas, elementos de conocimiento, metadatos de los tickets y otros datos recuperados se cifran en 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 inferencias puede realizarse dentro de 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 las recomendaciones o las respuestas al chat. Se recomienda redactar los datos de PII antes de almacenarlos en los registros de observabilidad.
Registro de auditoría y diario del agente
Diario del agente
Tanto las funciones de investigación como de prevención de incidentes mantienen diarios detallados que:
Registre cada paso de razonamiento y cada acción realizada
Cree una transparencia total en los procesos de toma de decisiones de los agentes
Los agentes no pueden modificarlos una vez registrados, lo que minimiza los ataques, como la inyección rápida, 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ó
Protección de inyección rápida
Un ataque de inyección rápida se produce cuando un atacante inserta instrucciones maliciosas en datos externos, como una página web o un documento, que posteriormente procesará un sistema de IA generativa. AWS DevOps El agente consume muchas fuentes de datos de forma nativa como parte de sus operaciones normales, incluidos los registros, las etiquetas de recursos y otros datos operativos. AWS DevOps Agent 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.
Garantías de inyección rápida:
Capacidades de escritura limitadas: las herramientas de las que dispone el agente no pueden modificar los recursos, con la excepción de abrir tickets y casos de soporte. Esto evita que instrucciones malintencionadas modifiquen la infraestructura o las aplicaciones.
Control de los límites de la cuenta: el AWS DevOps agente solo opera dentro de los límites permitidos por las funciones asignadas al agente en la cuenta principal y en la AWS cuenta secundaria conectada. El agente no puede acceder a los recursos ni modificarlos fuera del ámbito configurado.
Protecciones de seguridad mediante IA: el AWS DevOps agente utiliza modelos con protecciones de nivel 3 de seguridad mediante IA (ASL-3). Estas protecciones incluyen clasificadores que detectan y previenen los ataques de inyección inmediata antes de que puedan afectar al comportamiento del agente.
Registro de auditoría inmutable: el diario del agente registra cada paso de razonamiento y cada acción realizada. El agente no puede modificar las entradas del diario una vez registradas, lo que evita que los ataques de inyección inmediata oculten las acciones maliciosas.
Si bien AWS DevOps Agent ofrece varios niveles de protección contra los ataques de inyección inmediata, algunas configuraciones pueden aumentar el riesgo:
Herramientas de servidor MCP personalizadas: la función bring-your-own MCP permite introducir herramientas personalizadas en el agente, lo que puede ofrecer oportunidades adicionales para una rápida inyección. Es posible que las herramientas personalizadas no tengan los mismos controles de seguridad que las herramientas de AWS DevOps agente nativas, y las instrucciones malintencionadas podrían aprovechar estas herramientas de forma no deseada. 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. Es posible que estos usuarios puedan modificar las fuentes de datos que consume el agente, como registros o etiquetas de recursos, lo que facilita la incrustación de instrucciones maliciosas que el agente procesará.
Para mitigar estos riesgos:
Revise y pruebe detenidamente los servidores MCP personalizados antes de implementarlos en Agent Spaces.
Asegúrese de que solo se les permita 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 el MCP se basan en la relación de confianza implícita que se establece entre estos usuarios de la herramienta y el agente AWS DevOps
Aplique el principio del privilegio mínimo al conceder a los usuarios el acceso a los sistemas que proporcionan datos al agente
Audite periódicamente qué servidores MCP están conectados a sus Agent Spaces
Dado que cualquier contenido recuperado de una lista de permitidos URLs podría intentar manipular el comportamiento del agente, incluya únicamente fuentes confiables en su lista de 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: integraciones integradas que pueden enviar datos al agente y recibir actualizaciones del agente. Utiliza los métodos de autenticación del proveedor
Servidores MCP: servidores del protocolo de contexto de modelo remoto que utilizan flujos de autenticación OAuth 2.0 y claves de API para comunicarse de forma segura con sistemas externos.
Activadores de webhook: activadores de investigación desde servicios remotos, como tickets o sistemas de observabilidad. Los webhooks utilizan un código de autenticación de mensajes basado en hash (HMAC) por motivos de seguridad.
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 agentes de la cuenta. Al registrar estas herramientas, se autentica una vez a nivel de cuenta y, a continuación, cada Agent Space 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 OAuth flujo para la autenticación. Tras registrarse GitHub a nivel de cuenta, cada espacio de agente puede conectarse a repositorios específicos de su GitHub organización.
Dynatrace: utiliza OAuth la autenticación mediante token. Tras registrar Dynatrace a nivel de cuenta, cada espacio de agente puede conectarse a entornos o configuraciones de monitoreo específicos de Dynatrace.
Slack: utiliza la autenticación mediante token. 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 flow para la autenticación. OAuth Tras 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 mediante clave de API. Tras registrar New Relic a nivel de cuenta, cada espacio de agente puede conectarse a configuraciones de monitoreo específicas de New Relic.
Splunk: utiliza la autenticación mediante token 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 mediante token de acceso. Tras registrarse GitLab a nivel de cuenta, cada espacio de agente puede conectarse a GitLab repositorios específicos.
ServiceNow— Utiliza la key/token autenticación OAuth del cliente. 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 accesibles al público en general: utilice el OAuth flujo 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 del AWS DevOps agente a sus sistemas
AWS DevOps El agente inicia las conexiones salientes a los sistemas de terceros y a los 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 se puede acceder a sus herramientas desde una AWS VPC, puede AWS DevOps usar las conexiones privadas del agente para mantener el tráfico aislado AWS de las redes y fuera de la Internet pública. Para obtener más información, consulte Conexión a herramientas alojadas de forma privada.
Herramientas alojadas públicamente: si se puede acceder a sus herramientas a través de la Internet pública y utilizan reglas de firewall o listas de IP permitidas, debe 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.102
Asia-Pacífico (Tokio) (ap-northeast-1)
13.192.12.23335.74.181.23057.183.50.158
Europa (Fráncfort) (eu-central-1)
18.158.110.14052.57.96.16052.59.55.56
Europa (Irlanda) (eu-west-1)
34.251.85.2452.30.157.15752.51.192.222
Este de EE. UU. (Norte de Virginia) (us-east-1)
34.228.181.12844.219.176.18754.226.244.221
Oeste de EE. UU. (Oregón) (us-west-2)
34.212.16.13352.89.67.21254.187.135.61
Tráfico saliente de su AWS DevOps VPC al agente
Para el tráfico saliente de la AWS VPC AWS DevOps al agente (por ejemplo, Invocar al DevOps agente a través de Webhook mediante), puede utilizar 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 de confianza a los sistemas externos que proporcionan información al agente, como los servicios y recursos que generan registros, CloudTrail eventos, tickets y más, que pueden utilizarse para intentar realizar una inyección rápida maliciosa.
Asegúrese de que todas las fuentes de datos conectadas tengan datos confiables que probablemente no se utilicen para intentar ataques de inyección rápida
Garantizar que las integraciones de servidores bring-your-own MCP funcionen de forma segura
Garantizar que las funciones de IAM asignadas al agente tengan el alcance adecuado
Redactar los datos de PII antes de almacenarlos en los registros de observabilidad y otras fuentes de datos de los agentes
Seguir la práctica recomendada de conceder únicamente permisos de solo lectura a las fuentes de datos conectadas, incluidos los servidores MCP bring-your-own
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. El espacio de AWS DevOps agentes utiliza los comentarios de los clientes sobre el producto para mejorar las respuestas y las investigaciones del agente, pero AWS no los utiliza para mejorar el servicio en sí.
Conformidad
En la versión preliminar, AWS DevOps Agent no cumple con estándares como SOC 2, PCI-DSS, ISO 27001 o FedRAMP. AWS anunciará qué certificaciones de conformidad estarán disponibles más adelante.
