Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Esempi di policy basate su identità per Agent per Amazon Bedrock

Seleziona un argomento per visualizzare esempi di policy IAM che puoi collegare a un ruolo IAM per allocare autorizzazioni per azioni in Automazione delle attività nella propria applicazione utilizzando agenti IA.

Autorizzazioni richieste per Agent per Amazon Bedrock

Affinché un’identità IAM utilizzi Agent per Amazon Bedrock, devi configurarla con le autorizzazioni necessarie. È possibile allegare la AmazonBedrockFullAccesspolitica per concedere le autorizzazioni appropriate al ruolo.

Per limitare le autorizzazioni alle sole azioni utilizzate in Agent per Amazon Bedrock, collega la seguente policy basata sull’identità a un ruolo 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": "*"
        }
    ]   
}

Puoi limitare ulteriormente le autorizzazioni omettendo azioni o specificando risorse e chiavi di condizione. Un’identità IAM può chiamare operazioni API su risorse specifiche. Ad esempio, l’operazione UpdateAgent può essere utilizzata solo su risorse dell’agente e l’operazione InvokeAgent può essere utilizzata solo su risorse dell’alias. Per le operazioni API che non vengono utilizzate su un tipo di risorsa specifico (ad esempio CreateAgent), specifica * come Resource. Se specifichi un’operazione API che non può essere utilizzata sulla risorsa indicata nella policy, Amazon Bedrock restituisce un errore.

Consentire agli utenti di visualizzare informazioni su un agente e invocarlo

Di seguito è riportato un esempio di policy che puoi allegare a un ruolo IAM per consentirgli di visualizzare o modificare informazioni su un agente con l'ID AGENT12345 e di interagire con il relativo alias con l'ID. ALIAS12345 Ad esempio, puoi collegare questa policy a un ruolo per il quale desideri disporre solo delle autorizzazioni per la risoluzione dei problemi di un agente e per il suo aggiornamento.

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"
        }
    ]
}

Controlla l'accesso ai livelli di servizio

I livelli di servizio di Amazon Bedrock offrono diversi livelli di priorità di elaborazione e prezzi per le richieste di inferenza. Per impostazione predefinita, tutti i livelli di servizio (priority, default e flex) sono disponibili per gli utenti con le autorizzazioni Bedrock appropriate, secondo un approccio di tipo allowlist in cui l'accesso è concesso a meno che non sia esplicitamente limitato.

Tuttavia, le organizzazioni potrebbero voler controllare a quali livelli di servizio possono accedere i propri utenti per gestire i costi o applicare le politiche di utilizzo. Puoi implementare restrizioni di accesso utilizzando le policy IAM con la chiave di bedrock:ServiceTier condizione per negare l'accesso a livelli di servizio specifici. Questo approccio consente di mantenere un controllo granulare su quali membri del team possono utilizzare livelli di servizio premium come «priority» o livelli ottimizzati in termini di costi come «flex».

L'esempio seguente mostra una politica basata sull'identità che nega l'accesso a tutti i livelli di servizio. Questo tipo di policy è utile quando si desidera impedire agli utenti di specificare qualsiasi livello di servizio, obbligandoli a utilizzare il comportamento predefinito del sistema:

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

È possibile personalizzare questa politica per negare l'accesso solo a livelli di servizio specifici modificando i valori delle condizioni. bedrock:ServiceTier Ad esempio, per negare solo il livello premium «prioritario» e consentire al contempo «default» e «flex», è necessario specificare solo nella condizione. ["priority"] Questo approccio flessibile consente di implementare politiche di utilizzo in linea con i requisiti operativi e di gestione dei costi dell'organizzazione. Per ulteriori informazioni sui livelli di servizio, consulta. Livelli di servizio per l'ottimizzazione delle prestazioni e dei costi