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

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-idintestazione 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 includereeventResource: 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 scriveresessionId: 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, concomparison 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 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 soloeventPrincipal,,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_paymentsenza approvazione preventiva	DENY
approve_claimper un reclamo, quindi disburse_payment per lo stesso reclamo	PERMETTI
approve_claimper 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_claimprima di qualsiasi ricerca completata	DENY
la ricerca viene completata, quindi approve_claim all'interno della finestra	PERMETTI
approve_claimdopo 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.

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

Limite massimo per un totale contingente

Obiettivo: consentire gli esborsi fino a raggiungere un totale di 3.000,00€ entro cinque minuti, quindi interromperli.

sumaggiunge 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 strumentointeger, ed è questo che fa funzionare questa politica. L'sumaggregazione 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.

Rendi ogni approvazione valida per un solo utilizzo

Scopo: consentire un esborso per approvazione. Dopo un pagamento, richiedi una nuova approvazione.

L'sinceoperatore 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 nuovaapprove_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 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».

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_paymentprima di qualsiasi approvazione	DENY
approve_claim, quindi disburse_payment	PERMETTI
get_claim_statussi verifica, quindi disburse_payment	DENY
una nuovaapprove_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

countconta 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 guardraildescription, 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.