As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Exemplos de políticas temporais As políticas desta seção decidem com base no que já aconteceu anteriormente na mesma sessão. Eles permitem que você exija uma aprovação antes de um pagamento, expire uma permissão obsoleta, limite um total contínuo ou bloqueie uma ação após uma falha. Nenhuma solicitação contém informações suficientes para decidir qualquer uma delas. Cada exemplo autoriza o gateway de referência descrito em [Configuração de recursos para obter exemplos](example-policies-reference.md). Para o esquema de eventos temporais, os operadores, os IDs de sessão, as cotas e a disponibilidade da região, consulte [Políticas temporais e [Criação](policy-temporal-authoring.md) de políticas temporais](policy-temporal.md). ## Antes de usar esses exemplos Quatro coisas determinam se uma política temporal se comporta da maneira que você espera. **É necessário um ID de sessão** O histórico temporal tem como escopo uma sessão que você nomeia. Envie uma ID de sessão no `x-amzn-bedrock-agentcore-policy-session-id` cabeçalho em cada solicitação, começando pela primeira. O gateway não gera uma para você e, se o mecanismo tiver uma política temporal, uma solicitação sem ID de sessão falhará na validação. **Somente ações permitidas se tornam `response` eventos** Uma ação registra um `response` evento somente se uma política permitir e for concluída. Em vez disso, uma ação negada registra um `error` evento. Portanto, cada um dos exemplos a seguir também precisa de um plano `permit` para a ação de pré-requisito — caso contrário, o pré-requisito será negado, nunca registrado como um `response` e a condição temporal nunca poderá corresponder. Cada exemplo indica o que permite emparelhá-lo com. **`eventResource: resource`é obrigatório** Cada predicado deve incluir`eventResource: resource`, o que vincula o evento correspondente ao recurso no escopo da política. Omiti-lo é rejeitado com. `temporal predicates do not constrain the matched event to the current request’s resource` Você não precisa escrever `sessionId` — o esquema do evento já define o escopo de cada predicado até a sessão atual. **As comparações ordenadas precisam de números inteiros; a igualdade não** Dentro de um `temporal { }` bloco, os dois tipos de comparação aceitam tipos diferentes. + **Pedir** —`<`,, `⇐``>`, `>=` — requer um `integer` em ambos os lados. A `decimal` ou a `string` é rejeitado quando você cria a política, com`comparison requires numeric operands on both sides`. + **A igualdade** — `==` e `!=` — funciona em qualquer tipo, desde que os dois lados sejam do mesmo tipo. Isso é o que a correlação usa: a correspondência com `input.claimId` `context.input.claimId` compara duas strings, o que é suportado. Portanto, modele qualquer valor que uma política temporal tenha para **totalizar ou limitar** como um`integer`. É por isso que o gateway de referência indica dinheiro em unidades inteiras menores nas ferramentas que esses exemplos agregam. A soma tem o mesmo requisito e sua própria mensagem: `sum` precisa de uma `integer` convocação. Para obter mais informações, consulte [Tipos de parâmetros em condições](example-policies-reference.md#example-policies-types). ## Exigir uma aprovação prévia para a mesma reclamação **Intenção:** permitir que um pagamento seja desembolsado somente para uma reclamação que foi aprovada no início da sessão, para que o agente não possa desembolsar com base em um ID de reclamação que ele inventou. O `::response` predicado corresponde a um preenchido`approve_claim`. Correlacioná-la `output.claimId` com a solicitação atual `context.input.claimId` é o que vincula o desembolso a essa aprovação específica — sem a correlação, qualquer aprovação na sessão autorizaria o pagamento de qualquer reclamação. ``` 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.*`os campos existem em um `response` evento somente quando o destino declara um esquema de saída para a ferramenta. Muitos destinos não o fazem — um alvo Lambda, por exemplo, geralmente declara somente entradas e, em seguida, o evento carrega apenas`eventPrincipal`,,`eventResource`, e. `input.*` `requestId` `sessionId` Se você nomear um campo que o evento não declara, o serviço rejeitará a política e o erro listará o que **está** disponível: ``` 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) ``` Use essa lista para ver o que você pode correlacionar. Quando não houver campo de saída, correlacione em um campo **de entrada** compartilhado — `input.claimId: context.input.claimId` vincule as duas chamadas à mesma declaração sem precisar que a ferramenta anterior retorne nada. Os dois não são equivalentes, então escolha deliberadamente. **Uma correlação de entrada corresponde ao que a chamada anterior **solicitou**; uma correlação de saída corresponde ao que ela retornou.** Se sua regra depender de um valor produzido pela ferramenta anterior — um ID de aprovação, um valor calculado — somente uma correlação de saída a aplica, e isso exige que o alvo declare um esquema de saída. Combine isso com uma licença simples para que as aprovações sejam permitidas e registradas: ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ); ``` | Sequência de solicitações em uma sessão | Decisão | | --- | --- | | `disburse_payment`sem aprovação prévia | DENY | | `approve_claim`para uma reclamação e, em seguida, `disburse_payment` para a mesma reclamação | PERMISSÃO | | `approve_claim`para uma reivindicação e, em seguida, `disburse_payment` para uma reivindicação diferente | DENY | ## Exigir uma ação de pré-requisito **Intenção:** permitir que uma reivindicação seja aprovada somente depois que alguém consultou seu status na sessão. Combinação `::request` significa que o pré-requisito só precisa ter sido **tentado**, não ter sido bem-sucedido. Combine com uma licença para`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 } }; ``` ## Exigir um **bem-sucedida** pré-requisito, recentemente **Intenção:** permitir aprovação somente se uma pesquisa de status for **concluída** nos últimos cinco minutos, para que uma pesquisa obsoleta pare de conferir permissão. A única alteração em relação ao exemplo anterior está `::response` no lugar de`::request`, e é a diferença entre “foi tentada” e “foi bem-sucedida”. O tamanho da janela define o quão recente esse sucesso deve ser; uma vez aprovado, a permissão expira até que o pré-requisito seja executado novamente. ``` 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 } }; ``` | Sequência de solicitações em uma sessão | Decisão | | --- | --- | | `approve_claim`antes de qualquer pesquisa concluída | DENY | | a pesquisa é concluída e, em seguida, `approve_claim` dentro da janela | PERMISSÃO | | `approve_claim`depois que a janela passar | DENY | ## Limite quantas vezes uma ação é executada **Intenção:** permitir no máximo três desembolsos em qualquer período de cinco minutos de uma sessão. `count`conta os eventos correspondentes na janela, incluindo a solicitação que está sendo autorizada, então a quarta chamada em uma janela é a primeira a ser negada. O `exists (n: Long)` fichário captura a contagem para que o `n > 3` filtro possa testá-la; o agregado precisa de parênteses à esquerda de. `==` Emparelhe com uma permissão `disburse_payment` para que as chamadas sejam permitidas até o 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** Isso não é um controle de segurança. O chamador fornece o ID da sessão, para que ele possa redefinir a contagem iniciando uma nova sessão. Use-o para moldar o comportamento em uma sessão cooperativa — para interromper um agente em loop, por exemplo — e não para impor um limite a um chamador que controla sua própria ID de sessão. Para obter mais informações, consulte [Considerações de segurança](policy-temporal.md#policy-temporal-security). ## Limite um total contínuo **Intenção:** permita os desembolsos até que totalizem 3.000,00 em cinco minutos e, em seguida, pare. `sum`adiciona o campo de entrada nomeado nos eventos correspondentes, incluindo a solicitação atual, para que uma solicitação que ultrapasse o limite seja negada. Com um limite de 300.000 centavos e desembolsos de 100.000, os dois primeiros são permitidos e o terceiro é negado. ``` 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 }; ``` O domínio de duas variáveis,`for (amt: Long), (t: Timepoint)`, é obrigatório: é o valor que `amt` está sendo somado e `t` distingue os pontos de tempo; portanto, dois desembolsos do mesmo valor são contados duas vezes em vez de serem desduplicados em um. **nota** `amountCents`está `integer` no esquema da ferramenta, e é isso que faz essa política funcionar. A `sum` agregação precisa de uma soma de números inteiros, e a comparação de ordenação `total` precisa de um número inteiro em ambos os lados. Portanto, um campo que seu esquema declara como não pode gerar um `number` limite como esse. Para as regras de tipo das quais esses exemplos dependem, consulte [Antes de usar esses exemplos](#example-policies-temporal-before). ## Faça com que cada aprovação seja válida para um uso **Intenção:** permitir um desembolso por aprovação. Depois de um pagamento, exija uma nova aprovação. O `since` operador segura quando a âncora à sua direita ocorreu dentro da janela e a condição à sua esquerda se manteve continuamente desde então. Aqui está escrito: uma aprovação foi concluída na última hora e nenhum desembolso foi concluído desde então. O primeiro pagamento após uma aprovação o consome. ``` 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 } }; ``` Combinar `::response` no lado negativo é essencial. A solicitação que está sendo autorizada ainda não produziu uma resposta, então ela não se bloqueia. Combinar isso faria com `::request` que cada desembolso se negasse. | Sequência de solicitações em uma sessão | Decisão | | --- | --- | | `approve_claim`, então `disburse_payment` | PERMISSÃO | | um segundo `disburse_payment` sem nova aprovação | DENY | | um novo`approve_claim`, então `disburse_payment` | PERMISSÃO | **nota** Um `response` evento é gravado logo após a conclusão da chamada. Aguarde a devolução da aprovação antes de emitir o desembolso, em vez de enviá-la consecutivamente. Para obter mais informações, consulte [Ações de sequenciamento que dependem de uma resposta anterior](policy-temporal.md#policy-temporal-response-delay). ## Imponha um resfriamento **Intenção:** evitar que a mesma ação se repita dentro de um minuto após a conclusão. Essa condição se refere à mesma ação que ela autoriza. `::response`é o que torna isso seguro: a solicitação atual ainda não tem resposta, então ela não corresponde a si mesma. Escrita com`::request`, a solicitação atual corresponderia ao seu próprio evento e a ação seria proibida permanentemente. Para obter mais informações, consulte [Self-referential as condições, incluindo a solicitação atual](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 } }; ``` ## Exigir uma condição prévia que não tenha sido invalidada **Intenção:** permitir o desembolso enquanto a aprovação estiver em vigor e retirar a permissão se a solicitação for reaberta para análise de status posteriormente. Ela tem o mesmo formato da aprovação de uso único, mas a ação negada é diferente da ação que está sendo autorizada, o que transforma “consumir a aprovação” em “invalidar a aprovação”. Conceda licenças para ambos `approve_claim` e. `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 } }; ``` | Sequência de solicitações em uma sessão | Decisão | | --- | --- | | `disburse_payment`antes de qualquer aprovação | DENY | | `approve_claim`, então `disburse_payment` | PERMISSÃO | | `get_claim_status`ocorre, então `disburse_payment` | DENY | | um novo`approve_claim`, então `disburse_payment` | PERMISSÃO | ## Exigir uma cadeia de ações em ordem **Intenção:** Exija a pesquisa do status da sequência, depois a aprovação e, em seguida, o desembolso. Uma política por link, e a cadeia emerge de sua composição. Conceda uma permissão simples para a primeira ação para que a cadeia possa começar. Uma tentativa de falha na etapa é negada até que seu pré-requisito seja concluído. ``` // 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 } }; ``` ## Exija dois pré-requisitos em qualquer ordem **Intenção:** permitir o desembolso somente após a conclusão da pesquisa de status e da aprovação, em qualquer ordem. Duas `formerly` condições unidas `&&` exigem ambas e nenhuma restringe a ordem. Isso usa dois dos três operadores temporais que uma única política pode conter. ``` 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 } }; ``` ## Faça duas ações mutuamente exclusivas **Intenção:** em dois minutos, permita o desembolso ou a exclusão de uma reclamação, mas não ambas. A exclusão precisa de duas políticas simétricas, uma por direção; uma única `forbid` bloquearia apenas um pedido. Combinar `::request` significa simplesmente **tentar** uma ação para bloquear a outra, sem esperar que ela seja concluída. ``` // 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 } }; ``` ## Exigir um número limite de eventos **Intenção:** permitir que uma reclamação seja excluída somente após pelo menos dois desembolsos concluídos contra ela. A correlação `input.claimId` com a reivindicação da solicitação atual define o escopo da contagem dessa solicitação em vez de contar cada desembolso na sessão. ``` 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 eventos, não chamadores distintos. Não pode expressar “aprovado por duas pessoas diferentes”, porque nada impede que um diretor produza todos os eventos correspondentes. Para aprovação multipartidária, correlacione `eventPrincipal` ou imponha a distinção fora da política. ## Bloquear uma ação após uma negação anterior **Intenção:** interromper o desembolso de uma sessão depois que qualquer tentativa de aprovação for negada. Um `error` evento registra uma solicitação que foi negada ou que falhou, assim `::error` como uma política reage a uma falha anterior. Combine isso com uma licença simples `disburse_payment` para que seja permitido em condições normais. ``` 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 } }; ``` Esse é um padrão de contenção útil: um agente que está investigando as permissões que não tem é excluído da ação confidencial em vez de poder continuar tentando. ## Combine condições temporais, de proteção e de solicitação **Intenção:** permitir que um chamador registre reivindicações, desde que a sessão tenha menos de três registros nas últimas 24 horas, a descrição da reclamação não contenha detalhes bancários e o chamador não tenha uma função restrita. Todos os três tipos de condições se compõem em uma política, e cada cláusula deve ser válida para que a `permit` seja aplicada. O `temporal` bloco impõe o limite, o `when` bloco filtra o conteúdo e o `unless` bloco exclui uma função. Cada um é avaliado de forma independente. ``` 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" }; ``` As telas de proteção`description`, que são o único parâmetro de texto livre usado. `file_claim` Aponte uma grade de proteção de informações confidenciais para um campo que possa conter de forma plausível os dados que você está examinando. Se você apontar para um identificador ou número, não há nada para detectar e a cláusula será aprovada silenciosamente. `description`é opcional, portanto, uma solicitação que a omite não fornece texto à grade de proteção e a cláusula é válida. ## O que muda quando você edita uma política temporal Adicionar ou atualizar uma política temporal em um mecanismo invalida as sessões temporais abertas desse mecanismo, porque o histórico registrado não corresponde mais às regras que estão sendo aplicadas a ele. A próxima solicitação que reutiliza uma sessão invalidada falha com HTTP 409. `ConflictException` Inicie uma nova sessão e tente novamente; a nova sessão começa com um histórico vazio e é avaliada em relação às políticas atualizadas. **Importante** Planeje isso ao implementar uma mudança temporal na política. Os clientes precisam tratar a `409` como “iniciar uma nova sessão”. Qualquer fluxo de trabalho em várias etapas em andamento é reiniciado em vez de ser retomado.