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.

Ejemplos de políticas basadas en identidades para Agentes de Amazon Bedrock

Seleccione un tema para ver ejemplos de políticas de IAM que pueda asociar a un rol de IAM para otorgar permisos para acciones en Automatización de las tareas en la aplicación mediante agentes de IA.

Permisos necesarios para Agentes de Amazon Bedrock

Para que una identidad de IAM utilice Agentes de Amazon Bedrock, debe configurarla con los permisos necesarios. Puede adjuntar la AmazonBedrockFullAccesspolítica para conceder los permisos adecuados al rol.

Para restringir los permisos solo a las acciones que se utilizan en Agentes para Amazon Bedrock, asocie la siguiente política basada en identidades a un rol de IAM:

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AgentPermissions",
            "Effect": "Allow",
            "Action": [  
                "bedrock:ListFoundationModels",
                "bedrock:GetFoundationModel",
                "bedrock:TagResource", 
                "bedrock:UntagResource", 
                "bedrock:ListTagsForResource", 
                "bedrock:CreateAgent", 
                "bedrock:UpdateAgent", 
                "bedrock:GetAgent", 
                "bedrock:ListAgents", 
                "bedrock:DeleteAgent",
                "bedrock:CreateAgentActionGroup", 
                "bedrock:UpdateAgentActionGroup", 
                "bedrock:GetAgentActionGroup", 
                "bedrock:ListAgentActionGroups", 
                "bedrock:DeleteAgentActionGroup",
                "bedrock:GetAgentVersion",
                "bedrock:ListAgentVersions", 
                "bedrock:DeleteAgentVersion",
                "bedrock:CreateAgentAlias", 
                "bedrock:UpdateAgentAlias",               
                "bedrock:GetAgentAlias",
                "bedrock:ListAgentAliases",
                "bedrock:DeleteAgentAlias",
                "bedrock:AssociateAgentKnowledgeBase",
                "bedrock:DisassociateAgentKnowledgeBase",
                "bedrock:ListAgentKnowledgeBases",
                "bedrock:GetKnowledgeBase",
                "bedrock:ListKnowledgeBases",
                "bedrock:PrepareAgent",
                "bedrock:InvokeAgent",
                "bedrock:AssociateAgentCollaborator",
                "bedrock:DisassociateAgentCollaborator",
                "bedrock:GetAgentCollaborator",
                "bedrock:ListAgentCollaborators",
                "bedrock:UpdateAgentCollaborator"
            ],
            "Resource": "*"
        }
    ]   
}

Puede restringir aún más los permisos omitiendo acciones o especificando recursos y claves de condición. Una identidad de IAM puede llamar a las operaciones de la API en recursos específicos. Por ejemplo, la operación UpdateAgent solo se puede usar en los recursos del agente y la operación InvokeAgent solo se puede usar en los recursos de alias. Para las operaciones de la API que no se utilizan en un tipo de recurso específico (por ejemplo, CreateAgent), especifique * como Resource. Si especifica una operación de la API que no se puede utilizar en el recurso especificado en la política, Amazon Bedrock devuelve un error.

Permiso para que los usuarios vean información sobre un agente e invocarlo

El siguiente es un ejemplo de política que puede adjuntar a un rol de IAM para que pueda ver información sobre un agente con el ID o editarlo AGENT12345 e interactuar con su alias con el IDALIAS12345. Por ejemplo, puede asociar esta política a un rol para el que desee que solo tenga permisos para solucionar problemas de un agente y actualizarlo.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "GetAndUpdateAgent",
            "Effect": "Allow",
            "Action": [
                "bedrock:GetAgent",
                "bedrock:UpdateAgent"
            ],
            "Resource": "arn:aws:bedrock:us-east-1:123456789012:agent/AgentId"
        },
        {
            "Sid": "InvokeAgent",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeAgent"
            ],
            "Resource": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/AgentId/AgentAliasId"
        }
    ]
}

Controle el acceso a los niveles de servicio

Los niveles de servicio de Amazon Bedrock proporcionan diferentes niveles de prioridad de procesamiento y precios para las solicitudes de inferencia. De forma predeterminada, todos los niveles de servicio (prioritario, predeterminado y flexible) están disponibles para los usuarios con los permisos de Bedrock adecuados, siguiendo un enfoque de lista de permitidos en el que se concede el acceso a menos que se restrinja explícitamente.

Sin embargo, es posible que las organizaciones deseen controlar a qué niveles de servicio pueden acceder sus usuarios para gestionar los costes o hacer cumplir las políticas de uso. Puede implementar restricciones de acceso mediante políticas de IAM con la clave de bedrock:ServiceTier condición para denegar el acceso a niveles de servicio específicos. Este enfoque le permite mantener un control pormenorizado sobre qué miembros del equipo pueden utilizar los niveles de servicio premium, como el «prioritario», o los niveles con costes optimizados, como el «flexible».

El siguiente ejemplo muestra una política basada en la identidad que deniega el acceso a todos los niveles de servicio. Este tipo de política resulta útil cuando se quiere impedir que los usuarios especifiquen un nivel de servicio y obligarlos a utilizar el comportamiento predeterminado del sistema:

{
    "Version": "2012-10-17", 		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "bedrock:InvokeModel",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "bedrock:ServiceTier": ["reserved", "priority", "default", "flex"]
                }
            }
        }
    ]
}

Puede personalizar esta política para denegar el acceso únicamente a niveles de servicio específicos modificando los valores de bedrock:ServiceTier condición. Por ejemplo, para denegar únicamente el nivel premium de «prioridad» y permitir los niveles «predeterminado» y «flexible», especificaría únicamente ["priority"] esa condición. Este enfoque flexible le permite implementar políticas de uso que se ajusten a los requisitos operativos y de administración de costos de su organización. Para obtener más información sobre los niveles de servicio, consulteNiveles de servicio para optimizar el rendimiento y los costes.