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à.

Politiche temporali

Le politiche di Amazon Bedrock AgentCore supportano le politiche temporali: politiche le cui decisioni dipendono dalla cronologia delle azioni di un agente all'interno di una sessione, non solo dalla richiesta corrente. Con esse puoi applicare regole che comprendono più azioni, ad esempio richiedere un'approvazione prima di un'azione, limitare il numero di volte in cui un'azione viene eseguita in una finestra temporale o mantenere il totale corrente al di sotto di una soglia.

Una politica temporale è una forbid regola permit o che contiene uno o più operatori temporali. Ogni condizione corrisponde a un evento precedente registrato per la sessione dai relativi campi action, principal e input o output dell'azione e considera solo gli eventi all'interno di una finestra temporale richiesta. Una condizione può correlare un evento corrispondente alla richiesta corrente, quindi una regola può richiedere, ad esempio, che la richiesta corrente agisca su una risorsa già approvata da un'azione precedente. Il motore delle policy registra gli eventi di ogni sessione e valuta queste condizioni su ogni richiesta, in modo da esprimere le regole relative alla sessione come policy invece di tenere traccia degli eventi nel codice dell'agente o dello strumento.

Le politiche temporali sono scritte in Dogwood, che è compatibile con Cedar e supporta tutte le politiche Cedar esistenti. Le politiche standard di Cedar sono apolidi e considerano solo la richiesta corrente. Le politiche temporali seguono lo stesso modello deny-by-default: una richiesta è consentita solo quando a si applica e non la sovrascrive. permit forbid Le condizioni temporali sono diverse dalle condizioni basate sul tempo, che limitano l'accesso in base all'ora legale () anziché alla cronologia delle sessioni. context.system.now Puoi anche eseguire una politica temporale in LOG_ONLY modalità per osservare cosa deciderebbe prima di promuoverlaENFORCE; vedi Modalità di applicazione delle politiche. Modalità di applicazione delle politiche

Concetti chiave

Le politiche temporali si basano su due elementi: il linguaggio politico Dogwood, che esprime regole basate sulla sessione, e la sessione politica, che definisce l'ambito della cronologia che una regola può visualizzare.

Il linguaggio politico di Dogwood

Le politiche temporali sono scritte in Dogwood, un linguaggio di policy open source AgentCore utilizzato da Policy in per l'autorizzazione in base alla sessione. Dogwood si basa su Cedar e utilizza lo stesso modello di autorizzazione: si scrive permit e si forbid governa su un principio, un'azione e una risorsa e una richiesta è consentita solo quando a si applica e non la sovrascrive. permit forbid Dogwood è compatibile con Cedar e supporta tutte le politiche Cedar esistenti, quindi ogni politica Cedar valida è anche una politica Dogwood valida. Le tue politiche temporali esistenti continuano a funzionare senza modifiche e aggiungi condizioni temporali solo laddove una regola deve considerare più della richiesta corrente.

Con Dogwood, esprimi le regole relative alla sessione in modo dichiarativo come policy invece di implementare la logica di tracciamento degli eventi nel codice dell'agente o dello strumento. Il policy engine registra gli eventi rilevanti e valuta la condizione di ogni richiesta. Ad esempio, la seguente politica consente una vendita solo se è avvenuta un'approvazione corrispondente entro l'ora precedente:

permit (
    principal,
    action == AgentCore::Action::"TradingTarget___SellShares",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"TradingTarget___ApproveSale"::response{
        eventResource:   resource,
        input.stock:     context.input.stock,
        input.shares:    context.input.shares,
        output.approved: true
    }
};

Dogwood fornisce operatori temporali per i modelli più comuni: formerly within (un evento di corrispondenza si è verificato in precedenza nella finestra), since within (una condizione è valida dopo un evento di ancoraggio) e le aggregazioni count e sum gli eventi corrispondenti nella finestra.

Per la sintassi temporale completa, consulta la guida in lingua Dogwood sul sito web di Dogwood Policy.

Sessioni relative alle policy e ID della sessione

Le politiche temporali vengono valutate rispetto a una sessione di policy: una sequenza di chiamate Gateway correlate raggruppate in un unico ID di sessione. La cronologia temporale è limitata alla sessione, quindi una condizione considera autorizzati solo gli eventi registrati per la stessa sessione. L'ID di sessione viene generato e inviato per ogni richiesta nell'x-amzn-bedrock-agentcore-policy-session-idintestazione, a partire dalla prima richiesta. Il Gateway non genera un ID di sessione per conto dell'utente. Se ometti l'intestazione o invii un valore vuoto, il Gateway non stabilisce una sessione. Se il motore di policy associato contiene una policy temporale, le richieste senza un ID di sessione hanno esito negativo e viene generato un errore di convalida.

Per dettagli sul passaggio dell'ID di sessione, sul ciclo di vita della sessione e su come l'identità si propaga tra chiamate multi-hop, vedi Sessioni di policy e propagazione dell'identità.

Invalidazione della sessione

Una politica temporale decide se consentire un'azione esaminando ciò che è accaduto all'inizio della stessa sessione. Tale cronologia è significativa solo rispetto alle politiche temporali in vigore all'inizio della sessione. Se modifichi le politiche temporali del motore mentre una sessione è aperta, la cronologia registrata non corrisponde più alle regole correnti, quindi il servizio termina la sessione invece di prendere una decisione sulla base di dati incoerenti.

L'aggiunta o l'aggiornamento di una politica temporale sul motore invalida le sessioni di policy temporali attive del motore. Dopo tale modifica, la richiesta successiva che riutilizza una sessione non validata ha esito negativo con un HTTP 409. ConflictException

Per eseguire il ripristino, avvia una nuova sessione e invia nuovamente la richiesta. La nuova sessione inizia con una cronologia vuota e viene valutata in base alle politiche aggiornate.

Supportata AWS Regioni

Le politiche temporali sono disponibili nelle AWS regioni contrassegnate nella tabella seguente.

Considerazioni

Cross-account e richieste interregionali

Le sessioni temporali relative alle politiche non supportano la propagazione tra aree geografiche o tra account. Le politiche temporali non controllano le richieste tra i AgentCore Gateway e le relative destinazioni Runtime quando tali risorse risiedono in account diversi o regioni diverse. AWS Affinché le politiche temporali controllino le azioni dell'agente, il gateway e tutti i suoi obiettivi devono risiedere nello stesso account e nella stessa regione. AWS AWS

Le policy temporali impongono l'accesso solo quando il Workload Access Token (WAT) attraversa la catena di richieste (vedi Sessioni delle policy e propagazione delle identità). Quando la catena di richieste è costituita interamente da componenti AgentCore Gateway e Runtime, AgentCore propaga automaticamente l'intestazione WAT da un hop all'altro. Questa propagazione avviene all'interno di una singola AWS regione e account. Le politiche temporali si applicano a tutta la catena. Una catena come Gateway to Runtime to Gateway to Runtime trasporta il token dall'inizio alla fine senza alcun intervento aggiuntivo da parte dell'utente.

Le catene che includono componenti non Gateway o Runtime si comportano diversamente. Una richiesta potrebbe passare attraverso l'infrastruttura che gestisci tu stesso, come un gateway API di terze parti o un cluster Kubernetes. Tale componente deve inoltrare l'intestazione WAT ed è necessario aggiungere una logica personalizzata per propagare il WAT attraverso tali hop. L'ubicazione fisica di questi non AgentCore componenti non influisce sull'ambito regionale e dell'account. Possono essere eseguiti ovunque, a condizione che i AgentCore componenti su entrambi i lati ritornino allo stesso AWS account e alla stessa AWS regione in cui si applicano le politiche temporali.

Autorizzazioni IAM richieste

Le politiche temporali comportano anche un prerequisito IAM. Il ruolo IAM configurato per il Gateway deve consentire l'azionebedrock-agentcore:GetWorkloadAccessToken. Questo requisito è valido anche quando utilizzi IAM per l'autorizzazione in uscita. Il WAT consente alle politiche temporali di correlare le azioni di un agente in una sessione. Il Gateway deve essere in grado di ottenere il WAT indipendentemente dalla modalità di autenticazione delle chiamate in uscita. Se al ruolo manca questa autorizzazione, l'applicazione delle politiche temporali non riesce. Concedi bedrock-agentcore:GetWorkloadAccessToken al ruolo Gateway quando configuri le politiche temporali. Per la politica di autorizzazione completa, inclusi gli ARN delle risorse e lo scoping delle directory workload-identity, vedi Autorizzazioni IAM per le politiche temporali. Autorizzazioni IAM per le politiche temporali

Self-referential le condizioni includono la richiesta corrente

Quando una condizione temporale fa riferimento alla stessa azione che viene autorizzata, l'evento proprio della richiesta corrente viene incluso nella valutazione. Ad esempio, una condizione che conta quante volte si è verificata un'azione all'interno di una finestra conta anche la chiamata corrente.

È necessario consentire la registrazione di un'azione precedente come risposta

La cronologia delle sessioni registra ogni azione come un evento il cui tipo riflette il risultato: un'azione consentita che viene completata viene registrata come response evento e un'azione negata da una policy viene registrata come evento. error Una condizione temporale corrisponde solo agli eventi del tipo che nomina, quindi una condizione che corrisponde a un response evento considera solo le azioni precedenti consentite. Assicurati che l'azione precedente su cui si basa una politica temporale sia essa stessa consentita da una politica; se viene negata, viene registrata come una error anziché come una e una response response condizione non corrisponde mai.

Sequenziamento delle azioni che dipendono da una risposta precedente

La cronologia della sessione registra l'responseevento di ogni azione una volta completata. Quando una policy dipende dalla risposta di un'azione precedente nella stessa sessione, ad esempio un campo di output o una since condizione, invia la richiesta dipendente dopo aver ricevuto la risposta dell'azione precedente. Il completamento di ogni azione prima di iniziare quella che si basa su di essa mantiene la sequenza del flusso di lavoro allineata alla cronologia valutata dalla policy.

Quote

Le seguenti quote si applicano alle politiche temporali:

Osservabilità

Amazon Bedrock AgentCore pubblica metriche e dati spaziali che consentono di osservare la valutazione temporale delle politiche. Per impostazione predefinita, le metriche vengono pubblicate nel namespace. AWS/Bedrock-AgentCore CloudWatch I dati Span diventano disponibili dopo aver abilitato le tracce per la risorsa AgentCore Gateway collegata e possono essere trovati nel gruppo di log. CloudWatch aws/spans

I seguenti segnali sono specifici delle politiche temporali:

Per l'elenco completo delle metriche delle policy, delle dimensioni e degli attributi span e per sapere come abilitare l'osservabilità, vedi Policy in observability data. AgentCore

Considerazioni relative alla sicurezza

La limitazione della frequenza con politiche temporali si applica all'interno di una singola sessione. Poiché la cronologia temporale è limitata a una sessione e l'ID della sessione è fornito dal chiamante, un limite count basato come «al massimo N chiamate per sessione» conta solo gli eventi registrati per quella sessione. L'avvio di una nuova sessione comporta un nuovo conteggio, pertanto un limite di frequenza temporale limita l'attività all'interno di una sessione anziché in tutte le sessioni del chiamante.