Modelo de seguridad y permisos para instancias de tiempo de ejecución

Cuando aloja agentes en el tipo de procesamiento de instancias, los agentes se ejecutan en las instancias de Amazon EC2 de su propia AWS cuenta. Esto cambia el modelo de responsabilidad compartida en comparación con el tipo de procesamiento de microVM sin servidor: las instancias se ejecutan en su cuenta y en la VPC, los agentes se ejecutan con los permisos del rol de ejecución en tiempo de ejecución y los datos que contienen permanecen en su cuenta. En este tema se describe el modelo de seguridad de las instancias, los permisos involucrados y las prácticas que debes seguir para las implementaciones con varios inquilinos.

Este tema complementa la Runtime-wide guía de las prácticas recomendadas de seguridad para AgentCore Runtime. Estas prácticas (privilegios mínimos de IAM, autenticación, cifrado, seguridad de red y auditoría) también se aplican a las instancias. Para saber cómo se cifran los volúmenes de EBS adjuntos a sus sesiones, consulte Encryption at rest for Runtime Instances.

Modelo seguridad

• La instancia está en su cuenta: las instancias EC2 lanzadas por un proveedor de capacidad se ejecutan en su cuenta y en su VPC como instancias administradas por Amazon EC2. Puede inspeccionarlas, aplicar sus propios controles y auditar su actividad mediante CloudTrail los registros de flujo de VPC de su cuenta.

• Los agentes de una instancia no están aislados unos de otros: varios agentes pueden ejecutarse en la misma instancia y compartir su sistema de archivos. Los agentes se ejecutan en la instancia en contenedores o, en el caso de los agentes que se despliegan directamente, como procesos directamente en la instancia; ninguno de los dos proporciona un límite de seguridad entre las cargas de trabajo de la misma instancia. Todos los agentes que comparten una instancia deben contar con la confianza mutua.

• La sesión es la unidad de aislamiento: una sesión, identificada mediante la combinación del proveedor de capacidad y el ID de sesión, se asigna a una instancia EC2 (1:1). El mismo ID de sesión en dos proveedores de capacidad diferentes hace referencia a dos sesiones diferentes en dos instancias diferentes. Los agentes que pretendas mantener aislados unos de otros no deben compartir una sesión.

• Venta de credenciales: envía las credenciales AgentCore de las funciones de ejecución a los agentes que se ejecutan en la instancia y las actualiza periódicamente. Cualquier código que se ejecute en la instancia puede leer las credenciales disponibles en ella. Limite la función de ejecución de cada tiempo de ejecución al mínimo privilegio que requiera su agente. Para obtener más información, consulte Administración de credenciales.

• Se aplican los controles de tu cuenta: dado que las instancias se ejecutan en tu cuenta, las políticas de control de servicios (SCP), los límites de permisos y los controles de VPC de tu AWS organización rigen las acciones que se realizan en tu cuenta. AgentCore actúa a través del rol de infraestructura que tú asignes o apruebes; limítalo según las condiciones de IAM (por ejemplo, a VPC, subredes o tipos de instancias específicos). La excepción es la función AgentCore vinculada a un servicio que se utiliza para eliminar y limpiar los recursos, que no está restringida por los SCP, de acuerdo con la forma en que se tratan las funciones vinculadas a servicios en general. AWS

• Residencia de datos: los agentes se ejecutan en la VPC, las subredes, la cuenta y la región que especifique, y los datos de sesión y los volúmenes de EBS permanecen en su cuenta.

Permisos necesarios

Alojar agentes en instancias implica las siguientes funciones, además de la función de ejecución del agente en tiempo de ejecución, que otorga al código del agente sus permisos de ejecución.

• Perfil de instancia: adjunto a la instancia EC2. AgentCore lo usa para recopilar los registros del sistema de la instancia; no otorga permisos al código del agente (sí lo hace la función de ejecución del agente en tiempo de ejecución).

• Función de infraestructura: AgentCore asume esta función para aprovisionar y administrar las instancias EC2 de su cuenta en su nombre y lanzar, etiquetar y configurar las redes para las instancias y sus interfaces de red. Dado que esta función otorga el AgentCore permiso para administrar el procesamiento de tu cuenta, asignarle el menor número de privilegios que requieran tus cargas de trabajo y usar las condiciones de IAM para restringirla a VPC, subredes o tipos de instancias específicos, según corresponda.

Para ver los pasos de configuración de las funciones, consulta Cómo empezar con las instancias.

Enrutamiento de sesiones y aislamiento de múltiples inquilinos

AgentCore Runtime autoriza las invocaciones contra el ARN del recurso de tiempo de ejecución del agente, no contra sesiones individuales.

Cuando invocas a un agente, proporcionas un identificador de sesión y AgentCore validas su formatoruntimeSessionId, pero no compruebas que pertenezca a la identidad que realiza la llamada. Esto tiene una consecuencia importante para las implementaciones con varios inquilinos:

importante

En las implementaciones en las que un único principal de IAM invoca en nombre de varios usuarios finales, la plataforma no exige que sessionId a pertenezca al usuario que llama. Usted es responsable de garantizar que su backend apruebe la cantidad correcta por usuario. sessionId

Si varios usuarios finales comparten el mismo principio de IAM (por ejemplo, un único rol de ejecución en el backend que requiere a InvokeAgentRuntime todos los usuarios) y tu backend no vincula las sesiones a los usuarios, un usuario autenticado puede proporcionar el ID de sesión de otro usuario y dirigir una solicitud a la sesión de ese usuario. Las siguientes prácticas mitigan este problema.

Aplica la vinculación entre sesión y usuario en tu backend

Implemente la vinculación entre sesión y usuario a nivel de aplicación en su backend. Mantén el mapeo entre cada usuario final y sus ID de sesión en tu aplicación, y asegúrate de que nunca se pueda emitir una solicitud para un usuario con la de otro usuario. runtimeSessionId Trátelo runtimeSessionId como un valor del lado del servidor derivado del usuario final autenticado; nunca lo acepte directamente desde una entrada de un cliente que no sea de confianza. En el caso de las implementaciones con varios arrendatarios y con un principal compartido, la vinculación a nivel de aplicación en el backend es el control que impide que un usuario dirija una solicitud a la sesión de otro usuario.

Utilice principios de IAM distintos para las implementaciones multiusuario de alta seguridad

Para las implementaciones multiusuario de alta seguridad, utilice distintos principios de IAM por usuario final (o por grupo de inquilinos) para invocar a los agentes, en lugar de usar un único principal compartido. Cuando cada usuario o inquilino invoca a través de su propio principal, el propio IAM impone el alcance de la sesión: un principal solo puede invocar los tiempos de ejecución permitidos por su política, lo que elimina el riesgo de enrutamiento de sesiones de la clase de principal compartido. Este es el control más sólido y se recomienda siempre que la implementación pueda admitir directores por usuario o por inquilino.

Auditoría y supervisión

Utilice la auditoría para detectar el reconocimiento del enrutamiento de las sesiones y el acceso anómalo:

• Correlacione el principal y el ID de sesión: AWS CloudTrail registra tanto el principal autenticado como el objetivo en el mismo evento. sessionId InvokeAgentRuntime Úselo para detectar una ruta principal a una sesión que fue creada por un principal diferente.

• Aplique las prácticas de Runtime-wide auditoría: habilite los registros de flujo CloudTrail y haga una VPC, correlacione los registros mediante los ID de solicitud y configure los filtros métricos y las alarmas, tal y como se describe en Auditoría y supervisión.

Prácticas recomendadas

• Separe las cargas de trabajo por nivel de confianza: utilice sesiones diferentes para cargas de trabajo que no sean de confianza mutua. No ubique conjuntamente agentes que no sean de confianza en la misma sesión.

• Conceda los privilegios mínimos a cada rol: limite el rol de ejecución del agente en tiempo de ejecución y el rol de infraestructura únicamente a las acciones y los recursos que cada uno necesita.

• Vincula las sesiones a los usuarios de tu backend: en cualquier implementación en la que un usuario principal sirva a varios usuarios finales, aplica la vinculación entre sesión y usuario en la capa de aplicación.

• Prefiera los directores por usuario o por inquilino: cuando sea posible, invoque a través de distintos directores de IAM para que IAM aplique el alcance de la sesión.

• Supervise el enrutamiento entre principales: utilícelo CloudTrail para detectar anomalías en el enrutamiento, como el enrutamiento de un principal a una sesión creada por un principal diferente.

Para obtener Runtime-wide información sobre seguridad que también se aplica a las instancias, consulta las prácticas recomendadas de seguridad para Runtime. AgentCore