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 politiche temporali Le politiche di questa sezione decidono in base a ciò che è già accaduto in precedenza nella stessa sessione. Ti consentono di richiedere un'approvazione prima di un pagamento, di far scadere un'autorizzazione che non è più valida, di fissare un limite massimo per un totale residuo o di bloccare un'azione dopo un errore. Nessuna richiesta contiene informazioni sufficienti per decidere una di queste situazioni. Ogni esempio autorizza il gateway di riferimento descritto nella [configurazione delle risorse, a titolo di esempio](example-policies-reference.md). [Per lo schema degli eventi temporali, gli operatori, gli ID di sessione, le quote e la disponibilità delle regioni, vedi Politiche temporali e Creazione [di politiche temporali](policy-temporal.md).](policy-temporal-authoring.md) ## Prima di utilizzare questi esempi Quattro fattori determinano se una politica temporale si comporta come previsto. **È richiesto un ID di sessione** La cronologia temporale è limitata a una sessione a cui dai un nome. Invia un ID di sessione nell'`x-amzn-bedrock-agentcore-policy-session-id`intestazione per ogni richiesta, a partire dalla prima. Il gateway non ne genera uno automaticamente e, se il motore utilizza una politica temporale, una richiesta senza ID di sessione non viene convalidata. **Solo le azioni consentite diventano eventi `response`** Un'azione registra un `response` evento solo se una politica lo ha consentito e se è stato completato. Un'azione negata registra invece un `error` evento. Quindi ognuno degli esempi seguenti necessita anche di un semplice `permit` per l'azione preliminare, altrimenti il prerequisito viene negato, non viene mai registrato come un `response` prerequisito e la condizione temporale non può mai corrispondere. Ogni esempio indica a chi è consentito abbinarlo. **`eventResource: resource`è obbligatorio** Ogni predicato deve includere`eventResource: resource`, il che collega l'evento corrispondente alla risorsa nell'ambito della policy. L'omissione viene rifiutata con. `temporal predicates do not constrain the matched event to the current request’s resource` Non è necessario scrivere`sessionId`: lo schema degli eventi assegna già ogni predicato alla sessione corrente. **I confronti ordinati richiedono numeri interi, mentre l'uguaglianza no** All'interno di un `temporal { }` blocco i due tipi di confronto accettano tipi diversi. + **Per ordinare** —`<`,, `⇐``>`, `>=` — è necessario un messaggio `integer` su entrambi i lati. A `decimal` o a `string` viene rifiutato quando si crea la politica, con`comparison requires numeric operands on both sides`. + **L'uguaglianza** - `==` e `!=` - funziona su qualsiasi tipo, purché entrambe le parti siano dello stesso tipo. Questo è ciò che utilizza la correlazione: il matching `input.claimId` against `context.input.claimId` confronta due stringhe, il che è supportato. Quindi modella qualsiasi valore che una politica temporale deve avere come **totale o** soglia come un. `integer` Questo è il motivo per cui il gateway di riferimento indica il denaro in unità minori intere sugli strumenti aggregati in questi esempi. Summing ha lo stesso requisito e il suo messaggio: ha `sum` bisogno di un summand. `integer` Per ulteriori informazioni, consulta [Tipi di parametri](example-policies-reference.md#example-policies-types) nelle condizioni. ## Richiedi un'approvazione preventiva per lo stesso reclamo **Scopo:** consentire l'erogazione di un pagamento solo per un reclamo approvato in precedenza nella sessione, in modo che l'agente non possa effettuare il pagamento sulla base di un codice identificativo del reclamo da lui stesso inventato. Il `::response` pronostico corrisponde a un risultato completato. `approve_claim` La correlazione `output.claimId` con la richiesta corrente `context.input.claimId` è ciò che lega l'esborso a quella specifica approvazione: in assenza di tale correlazione, qualsiasi approvazione nella sessione autorizzerebbe il pagamento di qualsiasi reclamo. ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource, output.claimId: context.input.claimId } }; ``` **Importante** `output.*`i campi esistono su un `response` evento solo quando il target dichiara uno schema di output per lo strumento. Molti target non lo fanno: un target Lambda, ad esempio, di solito dichiara solo gli input e quindi l'evento riporta solo`eventPrincipal`,,`eventResource`, `input.*` e. `requestId` `sessionId` **Se assegnate un nome a un campo che l'evento non dichiara, il servizio rifiuta la policy e l'errore elenca ciò che è disponibile:** ``` predicate `AgentCore::Action::"MyTarget___verify_purchase"::response` mentions field `output.orderId`, which is not declared on that event (declared fields: eventPrincipal, eventResource, input.orderId, requestId, sessionId) ``` Usa quell'elenco per vedere a cosa puoi correlarti. Se non esiste alcun campo di output, esegui la correlazione su un campo di **input** condiviso: `input.claimId: context.input.claimId` collega le due chiamate alla stessa affermazione senza che lo strumento precedente restituisca nulla. Le due cose non sono equivalenti, quindi scegli deliberatamente. **Una correlazione di input corrisponde a quella **richiesta** dalla chiamata precedente; una correlazione di output corrisponde a quella restituita.** Se la regola dipende da un valore prodotto dallo strumento precedente, un ID di approvazione, un importo calcolato, solo una correlazione di output la applica e ciò richiede che il target dichiari uno schema di output. Abbinalo a un semplice permesso in modo che le approvazioni siano consentite e registrate: ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ); ``` | Sequenza di richieste in una sessione | Decisione | | --- | --- | | `disburse_payment`senza approvazione preventiva | DENY | | `approve_claim`per un reclamo, quindi `disburse_payment` per lo stesso reclamo | PERMETTI | | `approve_claim`per un reclamo, poi `disburse_payment` per un altro reclamo | DENY | ## Richiede un'azione preliminare **Intento:** consentire l'approvazione di un reclamo solo dopo che qualcuno ne ha verificato lo stato durante la sessione. L'abbinamento `::request` significa che è sufficiente che il prerequisito sia stato **tentato**, non che abbia avuto successo. Abbinalo a un permesso per. `get_claim_status` ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::request{ eventResource: resource } }; ``` ## Richiedi un **di successo** prerequisito, recentemente **Intento:** consente l'approvazione solo se una ricerca dello stato è **stata completata** negli ultimi cinque minuti, in modo che una ricerca non aggiornata interrompa il conferimento dell'autorizzazione. L'unica modifica rispetto all'esempio precedente riguarda il `::response` posto di`::request`, ed è la differenza tra «tentativo effettuato» e «successo». La lunghezza della finestra stabilisce quanto deve essere attuale tale successo; una volta superato, l'autorizzazione decade fino alla ripetizione del prerequisito. ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource } }; ``` | Sequenza di richieste in una sessione | Decisione | | --- | --- | | `approve_claim`prima di qualsiasi ricerca completata | DENY | | la ricerca viene completata, quindi `approve_claim` all'interno della finestra | PERMETTI | | `approve_claim`dopo che la finestra è scaduta | DENY | ## Limita quante volte viene eseguita un'azione **Scopo:** consentire al massimo tre esborsi in ogni periodo di cinque minuti di una sessione. `count`conta gli eventi corrispondenti nella finestra, inclusa la richiesta autorizzata, quindi la quarta chiamata in una finestra è la prima a essere negata. Il `exists (n: Long)` raccoglitore acquisisce il conteggio in modo che il `n > 3` filtro possa testarlo; l'aggregato necessita di parentesi a sinistra di. `==` In coppia con un permesso, le chiamate sono consentite `disburse_payment` fino al limite. ``` forbid ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { exists (n: Long). (count for (t: Timepoint). where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource } && tp(t)))) == n && n > 3 }; ``` **Importante** Non si tratta di un controllo di sicurezza. Il chiamante fornisce l'ID di sessione, in modo da poter reimpostare il conteggio avviando una nuova sessione. Usalo per modellare il comportamento all'interno di una sessione cooperativa, ad esempio per interrompere un agente che effettua ripetizioni continue, non per imporre un limite a un chiamante che controlla il proprio ID di sessione. [Per ulteriori informazioni, consulta Considerazioni sulla sicurezza.](policy-temporal.md#policy-temporal-security) ## Limite massimo per un totale contingente **Obiettivo:** consentire gli esborsi fino a raggiungere un totale di 3.000,00€ entro cinque minuti, quindi interromperli. `sum`aggiunge il campo di input denominato tra gli eventi corrispondenti, inclusa la richiesta corrente, in modo che una richiesta che superi la soglia venga rifiutata. Con un limite di 30.000 centesimi e 100.000 esborsi, i primi due sono consentiti e il terzo è negato. ``` forbid ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { exists (total: Long). (sum amt for (amt: Long), (t: Timepoint). where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource, input.amountCents: amt } && tp(t)))) == total && total >= 300000 }; ``` Il dominio a due variabili,`for (amt: Long), (t: Timepoint)`, è obbligatorio: `amt` è il valore da sommare e `t` distingue i punti temporali, quindi due esborsi dello stesso importo vengono contati due volte anziché deduplicati in uno solo. **Nota** `amountCents`è uno schema dello strumento`integer`, ed è questo che fa funzionare questa politica. L'`sum`aggregazione richiede un sommatorio intero e il confronto degli ordinamenti `total` richiede un numero intero su entrambi i lati, quindi un campo dichiarato dallo schema `number` non può generare un limite come questo. [Per le regole di tipo da cui dipendono questi esempi, vedi Prima di utilizzare questi esempi.](#example-policies-temporal-before) ## Rendi ogni approvazione valida per un solo utilizzo **Scopo:** consentire un esborso per approvazione. Dopo un pagamento, richiedi una nuova approvazione. L'`since`operatore resta fermo quando l'ancoraggio alla sua destra si trovava all'interno della finestra e la condizione alla sua sinistra si è mantenuta ininterrottamente da allora. Qui si legge: un'approvazione completata nell'ultima ora e da allora nessun esborso è stato completato. Il primo pagamento dopo un'approvazione lo consuma. ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { !AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource } since within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource } }; ``` L'abbinamento `::response` sul lato negativo è essenziale. La richiesta autorizzata non ha ancora prodotto una risposta, quindi non si blocca da sola: l'abbinamento `::request` comporterebbe la negazione di ogni esborso. | Sequenza di richieste in una sessione | Decisione | | --- | --- | | `approve_claim`, quindi `disburse_payment` | PERMETTI | | un secondo `disburse_payment` senza nuova approvazione | DENY | | una nuova`approve_claim`, quindi `disburse_payment` | PERMETTI | **Nota** Un `response` evento viene registrato poco dopo il completamento della chiamata. Attendi la restituzione dell'approvazione prima di emettere l'esborso anziché rispedirli uno dopo l'altro. Per ulteriori informazioni, consulta [Sequenziamento delle azioni che dipendono da](policy-temporal.md#policy-temporal-response-delay) una risposta precedente. ## Implementa un raffreddamento **Scopo: Evita** che la stessa azione si ripeta entro un minuto dal completamento. Questa condizione si riferisce alla stessa azione che autorizza. `::response`è ciò che lo rende sicuro: la richiesta corrente non ha ancora ricevuto risposta, quindi non corrisponde a se stessa. Se scritta con`::request`, la richiesta corrente corrisponderebbe al relativo evento e l'azione sarebbe proibita in modo permanente. Per ulteriori informazioni, consulta la sezione «[Le Self-referential condizioni includono la richiesta corrente](policy-temporal.md#policy-temporal-self-referential)». ``` forbid ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 1m AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource } }; ``` ## Richiede una condizione preliminare che non sia stata invalidata **Scopo:** consentire il pagamento finché è in corso l'approvazione e revocare l'autorizzazione se la richiesta viene riaperta per la verifica dello stato in seguito. Questa procedura ha la stessa forma dell'approvazione una tantum, ma l'azione negata è diversa dall'azione autorizzata, che trasforma «consumare l'approvazione» in «annullare l'approvazione». Concedi permessi per entrambi e. `approve_claim` `get_claim_status` ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { !AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource } since within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource } }; ``` | Sequenza di richieste in una sessione | Decisione | | --- | --- | | `disburse_payment`prima di qualsiasi approvazione | DENY | | `approve_claim`, quindi `disburse_payment` | PERMETTI | | `get_claim_status`si verifica, quindi `disburse_payment` | DENY | | una nuova`approve_claim`, quindi `disburse_payment` | PERMETTI | ## Richiede una catena di azioni in ordine **Intento:** richiedi la ricerca dello stato della sequenza, quindi l'approvazione e quindi l'esborso. Una politica per anello e la catena emerge dalla loro composizione. Concedi un permesso semplice per la prima azione in modo che la catena possa iniziare. Un passaggio tentato di non funzionare viene negato fino al completamento del relativo prerequisito. ``` // Link 1: approve only after a completed status lookup permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource } }; // Link 2: disburse only after a completed approval permit ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource } }; ``` ## Richiede due prerequisiti in qualsiasi ordine **Obiettivo:** consentire il pagamento solo dopo il completamento della ricerca dello stato e dell'approvazione, in entrambi gli ordini. La combinazione di due `formerly` condizioni `&&` richiede entrambe le condizioni e nessuna delle due limita l'ordine. Questo utilizza due dei tre operatori temporali che una singola policy può contenere. ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 1h AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource } && formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource } }; ``` ## Fai in modo che due azioni si escludano a vicenda **Intento:** entro due minuti, consenti l'esborso o l'eliminazione di un reclamo, ma non entrambe. L'esclusione richiede due politiche simmetriche, una per direzione; una sola bloccherebbe un solo `forbid` ordine. La corrispondenza `::request` significa che il semplice **tentativo di** un'azione blocca l'altra, senza attendere che venga completata. ``` // Forbid deletion if a disbursement was requested within 2m forbid ( principal, action == AgentCore::Action::"InsuranceAPI___delete_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 2m AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource } }; // Forbid disbursement if a deletion was requested within 2m forbid ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 2m AgentCore::Action::"InsuranceAPI___delete_claim"::request{ eventResource: resource } }; ``` ## Richiede una soglia di numero di eventi **Scopo:** consentire l'eliminazione di un reclamo solo dopo aver completato almeno due esborsi a suo carico. La correlazione `input.claimId` con il reclamo della richiesta corrente determina il conteggio relativo a tale reclamo anziché il conteggio di tutti gli esborsi della sessione. ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___delete_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { exists (n: Long). (count for (t: Timepoint). where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource, input.claimId: context.input.claimId } && tp(t)))) == n && n >= 2 }; ``` **Nota** `count`conta gli eventi, non i chiamanti distinti. Non può esprimere «approvato da due persone diverse», perché nulla impedisce a un preside di produrre tutti gli eventi corrispondenti. Per l'approvazione multipartitica, metti in correlazione `eventPrincipal` o applica la distinzione al di fuori della politica. ## Blocca un'azione dopo un rifiuto precedente **Scopo: impedire l'**erogazione di una sessione dopo che un tentativo di approvazione in essa contenuto è stato negato. Un `error` evento registra una richiesta che è stata rifiutata o che non è andata a buon fine, `::error` ovvero il modo in cui una policy reagisce a un precedente errore. Abbinalo a un permesso semplice in `disburse_payment` modo che sia consentito in condizioni normali. ``` forbid ( principal, action == AgentCore::Action::"InsuranceAPI___disburse_payment", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { formerly within 3m AgentCore::Action::"InsuranceAPI___approve_claim"::error{ eventResource: resource } }; ``` Si tratta di un modello di contenimento utile: un agente che cerca i permessi di cui non dispone viene escluso dall'azione delicata invece di continuare a provare. ## Combina condizioni temporali, guardrail e di richiesta **Intento:** consenti a un chiamante di presentare reclami, a condizione che la sessione abbia avuto meno di tre richieste nelle ultime 24 ore, che la descrizione del reclamo non contenga dati bancari e che il chiamante non abbia un ruolo limitato. Tutti e tre i tipi di condizioni rientrano in un'unica politica e tutte le clausole devono essere valide perché siano applicabili. `permit` Il `temporal` blocco impone il limite, il `when` blocco visualizza il contenuto e il `unless` blocco esclude un ruolo. Ciascuno viene valutato in modo indipendente. ``` permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"InsuranceAPI___file_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ) when temporal { exists (n: Long). (count for (t: Timepoint). where (formerly within 24h (AgentCore::Action::"InsuranceAPI___file_claim"::request{ eventResource: resource } && tp(t)))) == n && n <= 3 } when { BedrockGuardrails::SensitiveInformation(["US_BANK_ACCOUNT_NUMBER"], [context.input.description]).count() == 0 } unless { principal.hasTag("role") && principal.getTag("role") == "restricted" }; ``` Le schermate del guardrail`description`, che è l'unico parametro a testo libero utilizzato. `file_claim` Punta un guardrail contenente informazioni sensibili su un campo che potrebbe contenere, in modo plausibile, i dati che stai cercando. Se lo punti verso un identificatore o un numero, non ha nulla da rilevare e la clausola passa silenziosamente. `description`è facoltativo, quindi una richiesta che lo omette non fornisce alcun testo al guardrail e la clausola è valida. ## Cosa cambia quando si modifica una politica temporale L'aggiunta o l'aggiornamento di una politica temporale su un motore invalida le sessioni temporali aperte di quel motore, poiché la cronologia registrata non corrisponde più alle regole applicate. La richiesta successiva che riutilizza una sessione non convalidata ha esito negativo con HTTP 409. `ConflictException` Avvia una nuova sessione e riprova; la nuova sessione inizia con una cronologia vuota e viene valutata in base alle politiche aggiornate. **Importante** Pianificate questa operazione quando introdurrete una modifica temporale delle politiche. I clienti devono considerare un messaggio `409` come «iniziare una nuova sessione». Qualsiasi flusso di lavoro in corso in più fasi viene riavviato anziché ripreso.