Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Exemples de politiques temporelles Les politiques décrites dans cette section se basent sur ce qui s'est déjà passé plus tôt au cours de la même session. Ils vous permettent d'exiger une approbation avant un versement, d'expirer une autorisation périmée, de plafonner un total cumulé ou de bloquer une action après un échec. Aucune demande ne contient suffisamment d'informations pour décider de l'une ou l'autre de ces questions. Chaque exemple autorise la passerelle de référence décrite dans [Configuration des ressources pour les exemples](example-policies-reference.md). Pour le schéma des événements temporels, les opérateurs, les identifiants de session, les quotas et la disponibilité des régions, voir [Politiques temporelles](policy-temporal.md) et [Création de politiques temporelles](policy-temporal-authoring.md). ## Avant d'utiliser ces exemples Quatre facteurs déterminent si une politique temporelle se comporte comme vous le souhaitez. **Un identifiant de session est requis** L'historique temporel est limité à une session que vous nommez. Envoyez un identifiant de session dans l'`x-amzn-bedrock-agentcore-policy-session-id`en-tête de chaque demande, en commençant par la première. La passerelle n'en génère pas pour vous, et si le moteur contient une politique temporelle, une demande sans ID de session échoue à la validation. **Seules les actions autorisées deviennent `response` des événements** Une action enregistre un `response` événement uniquement si une politique l'a autorisé et s'il est terminé. Une action refusée enregistre plutôt un `error` événement. Chacun des exemples suivants nécessite donc également un clair `permit` pour l'action préalable, sinon la condition préalable est refusée, jamais enregistrée en tant que a`response`, et la condition temporelle ne pourra jamais correspondre. Chaque exemple indique ce qui permet de le coupler avec. **`eventResource: resource`est obligatoire** Chaque prédicat doit inclure`eventResource: resource`, ce qui lie l'événement correspondant à la ressource comprise dans le champ d'application de la politique. Son omission est rejetée avec`temporal predicates do not constrain the matched event to the current request’s resource`. Vous n'avez pas besoin d'écrire `sessionId` : le schéma d'événement étend déjà chaque prédicat à la session en cours. **Les comparaisons ordonnées ont besoin d'entiers ; l'égalité n'en a pas** À l'intérieur d'un `temporal { }` bloc, les deux types de comparaison acceptent des types différents. + La **commande** —`<`,`⇐`,`>`, `>=` — nécessite un `integer` recto verso. A `decimal` ou a `string` est rejeté lorsque vous créez la politique, avec`comparison requires numeric operands on both sides`. + **L'égalité** — `==` et `!=` — fonctionne sur tous les types, à condition que les deux parties soient du même type. C'est ce qu'utilise la corrélation : la mise en correspondance `input.claimId` `context.input.claimId` compare deux chaînes, ce qui est pris en charge. Modélisez donc toute valeur d'une politique temporelle par rapport à un **total ou à un seuil** en tant que`integer`. C'est pourquoi la passerelle de référence indique la monnaie en unités mineures entières sur les outils que ces exemples regroupent. La sommation a la même exigence et son propre message : `sum` nécessite une `integer` sommation. Pour plus d'informations, consultez la section [Types de paramètres dans les conditions](example-policies-reference.md#example-policies-types). ## Exiger une approbation préalable pour la même réclamation **Intention :** autoriser le versement d'un paiement uniquement pour une réclamation approuvée plus tôt au cours de la session, afin que l'agent ne puisse pas effectuer le versement contre un numéro de réclamation qu'il a inventé. Le `::response` prédicat correspond à un terminé`approve_claim`. C'`context.input.claimId`est en le corrélant `output.claimId` avec la demande actuelle que le versement est lié à cette approbation spécifique. En l'absence de corrélation, toute approbation au cours de la session autoriserait le paiement d'une réclamation. ``` 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 } }; ``` **Important** `output.*`les champs n'existent sur un `response` événement que lorsque la cible déclare un schéma de sortie pour l'outil. De nombreuses cibles ne le font pas. Une cible Lambda, par exemple, déclare généralement uniquement les entrées, puis l'événement ne contient que`eventPrincipal`, `eventResource` `input.*``requestId`, et. `sessionId` Si vous nommez un champ que l'événement ne déclare pas, le service rejette la politique et l'erreur indique ce qui **est** disponible : ``` 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) ``` Utilisez cette liste pour voir sur quoi vous pouvez établir une corrélation. Lorsqu'aucun champ de sortie n'existe, établissez une corrélation sur un champ de **saisie** partagé : `input.claimId: context.input.claimId` associez les deux appels à la même réclamation sans avoir besoin de l'outil précédent pour renvoyer quoi que ce soit. Les deux ne sont pas équivalents, alors choisissez délibérément. Une corrélation d'entrée correspond à ce que l'appel précédent **a demandé** ; une corrélation de sortie correspond à ce qu'il **a renvoyé**. Si votre règle dépend d'une valeur produite par l'outil précédent (un ID d'approbation, un montant calculé), seule une corrélation de sortie l'applique, ce qui oblige la cible à déclarer un schéma de sortie. Associez-le à un simple permis pour que les approbations soient autorisées et enregistrées : ``` permit ( principal, action == AgentCore::Action::"InsuranceAPI___approve_claim", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5" ); ``` | Séquence de demandes dans une session | Décision | | --- | --- | | `disburse_payment`sans approbation préalable | REJETER | | `approve_claim`pour une réclamation, puis `disburse_payment` pour la même réclamation | AUTORISER | | `approve_claim`pour une demande, puis `disburse_payment` pour une autre | REJETER | ## Exiger une action préalable **Intention :** autoriser l'approbation d'une réclamation uniquement après que quelqu'un a consulté son statut au cours de la session. L'appariement `::request` signifie que la condition préalable doit seulement avoir été **essayée**, pas avoir réussi. À associer avec un permis pour`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 } }; ``` ## Exiger un **réussi** prérequis, récemment **Intention :** autoriser l'approbation uniquement si une recherche de statut s'est **terminée** au cours des cinq dernières minutes, de sorte qu'une recherche périmée cesse de conférer une autorisation. Le seul changement par rapport à l'exemple précédent est `::response` à la place de`::request`, et il s'agit de la différence entre « tentative » et « réussite ». La longueur de la fenêtre indique à quel point ce succès doit être récent ; une fois qu'il est passé, l'autorisation expire jusqu'à ce que le prérequis soit à nouveau exécuté. ``` 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 } }; ``` | Séquence de demandes dans une session | Décision | | --- | --- | | `approve_claim`avant toute recherche terminée | REJETER | | la recherche se termine, puis `approve_claim` dans la fenêtre | AUTORISER | | `approve_claim`une fois la fenêtre écoulée | REJETER | ## Limitez le nombre de fois qu'une action est exécutée **Objectif :** Permettre au maximum trois décaissements par session de cinq minutes. `count`compte les événements correspondants dans la fenêtre, y compris la demande autorisée, de sorte que le quatrième appel dans une fenêtre est le premier à être refusé. Le `exists (n: Long)` classeur capture le nombre afin que le `n > 3` filtre puisse le tester ; l'agrégat a besoin de parenthèses à gauche de`==`. Couplez avec un permis pour `disburse_payment` que les appels soient autorisés jusqu'à la 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 }; ``` **Important** Il ne s'agit pas d'un contrôle de sécurité. L'appelant fournit l'identifiant de session, afin de pouvoir réinitialiser le décompte en démarrant une nouvelle session. Utilisez-le pour façonner le comportement au sein d'une session coopérative (pour arrêter un agent en boucle, par exemple) et non pour imposer une limite à un appelant qui contrôle son propre identifiant de session. Pour plus d'informations, consultez la section [Considérations relatives à la sécurité](policy-temporal.md#policy-temporal-security). ## Plafonner un total cumulé **Intention :** Autoriser les versements jusqu'à ce qu'ils atteignent un total de 3 000 dollars dans les cinq minutes, puis arrêter. `sum`ajoute le champ de saisie nommé à travers les événements correspondants, y compris la demande en cours, de sorte qu'une demande qui franchirait le seuil soit celle refusée. Avec un plafond de 300 000 cents et des décaissements de 100 000 dollars, les deux premiers sont autorisés et le troisième est refusé. ``` 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 }; ``` Le domaine à deux variables est obligatoire : `for (amt: Long), (t: Timepoint)` est-ce que la valeur `amt` est additionnée et `t` distingue les points temporels, de sorte que deux décaissements du même montant sont comptés deux fois plutôt que dédupliqués en un seul. **Note** `amountCents`est un schéma `integer` intégré à l'outil, et c'est ce qui permet à cette politique de fonctionner. L'`sum`agrégation nécessite une somme d'entiers, et la comparaison d'ordre `total` nécessite un entier des deux côtés. Un champ déclaré par votre schéma `number` ne peut donc pas être plafonné comme celui-ci. Pour connaître les règles de type dont dépendent ces exemples, voir [Avant d'utiliser ces exemples](#example-policies-temporal-before). ## Faites en sorte que chaque approbation soit valable pour un usage unique **Intention :** Permettre un versement par approbation. Après un paiement, demandez une nouvelle approbation. L'`since`opérateur maintient la position lorsque l'ancre à sa droite est apparue dans la fenêtre et que la situation à sa gauche est restée inchangée depuis lors. Ici, cela se lit comme suit : une approbation a été effectuée au cours de la dernière heure, et aucun versement n'a été effectué depuis. Le premier versement après une approbation le consomme. ``` 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 } }; ``` Il est essentiel de faire correspondre `::response` le côté négatif. La demande autorisée n'a pas encore produit de réponse, elle ne se bloque donc pas d'elle-même. Si vous `::request` y répondez, chaque versement serait refusé. | Séquence de demandes dans une session | Décision | | --- | --- | | `approve_claim`, puis `disburse_payment` | AUTORISER | | une seconde `disburse_payment` sans nouvelle approbation | REJETER | | un nouveau`approve_claim`, puis `disburse_payment` | AUTORISER | **Note** Un `response` événement est enregistré peu après la fin de l'appel. Attendez le retour de l'approbation avant d'effectuer le versement plutôt que de les renvoyer dos à dos. Pour plus d'informations, consultez la section [Séquençage des actions qui dépendent d'une réponse antérieure](policy-temporal.md#policy-temporal-response-delay). ## Imposez un temps de refroidissement **Intention :** Empêcher la même action de se répéter dans la minute qui suit son exécution. Cette condition fait référence à la même action qu'elle autorise. `::response`c'est ce qui le rend sûr : la demande en cours n'a pas encore de réponse, elle ne correspond donc pas à elle-même. Rédigée avec`::request`, la demande en cours correspondrait à son propre événement et l'action serait définitivement interdite. Pour plus d'informations, voir [Self-referential les conditions incluent la demande en cours](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 } }; ``` ## Exiger une condition préalable qui n'a pas été invalidée **Intention :** Autoriser le décaissement tant qu'une approbation est en cours et retirer l'autorisation si la demande est rouverte pour examen du statut par la suite. Cela a la même forme que l'approbation à usage unique, mais l'action annulée est différente de l'action autorisée, qui transforme « consommer l'approbation » en « invalider l'approbation ». Accordez des permis pour les deux `approve_claim` et`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 } }; ``` | Séquence de demandes dans une session | Décision | | --- | --- | | `disburse_payment`avant toute approbation | REJETER | | `approve_claim`, puis `disburse_payment` | AUTORISER | | `get_claim_status`se produit, puis `disburse_payment` | REJETER | | un nouveau`approve_claim`, puis `disburse_payment` | AUTORISER | ## Exiger une chaîne d'actions dans l'ordre **Intention :** Exiger la recherche de l'état de la séquence, puis l'approbation, puis le décaissement. Une politique par maillon, et la chaîne émerge de leur composition. Accordez un simple permis pour la première action afin que la chaîne puisse démarrer. Une étape désordonnée est refusée tant que la condition préalable requise n'est pas terminée. ``` // 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 } }; ``` ## Exiger deux prérequis dans n'importe quel ordre **Intention :** Autoriser le versement uniquement une fois la recherche du statut et l'approbation terminées, dans l'un ou l'autre ordre. Deux `formerly` conditions associées `&&` nécessitent les deux, et aucune ne limite la commande. Cela utilise deux des trois opérateurs temporels qu'une seule politique peut contenir. ``` 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 } }; ``` ## Rendre deux actions incompatibles **Intention :** Dans les deux minutes, autorisez le versement ou la suppression d'une réclamation, mais pas les deux. L'exclusion nécessite deux politiques symétriques, une par direction ; une seule ne `forbid` bloquerait qu'une seule commande. Faire correspondre `::request` signifie simplement **tenter** une action pour bloquer l'autre, sans attendre qu'elle soit terminée. ``` // 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 } }; ``` ## Exiger un nombre seuil d'événements **Intention :** Permettre la suppression d'une réclamation uniquement après qu'au moins deux décaissements ont été effectués à son encontre. La corrélation `input.claimId` avec la réclamation de la demande en cours permet d'évaluer le montant de cette réclamation plutôt que de compter tous les décaissements effectués au cours de la session. ``` 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 }; ``` **Note** `count`compte les événements, pas les appelants distincts. Il ne peut pas exprimer « approuvé par deux personnes différentes », car rien n'empêche un directeur de produire tous les événements correspondants. Pour une approbation multipartite, établissez une corrélation avec une politique extérieure de distinction `eventPrincipal` ou appliquez-la. ## Bloquer une action après un refus antérieur **Intention :** empêcher le déboursement d'une session après le refus de toute tentative d'approbation. Un `error` événement enregistre une demande qui a été refusée ou qui a échoué, tout `::error` comme la façon dont une politique réagit à un échec antérieur. Associez-le à un permis ordinaire pour `disburse_payment` qu'il soit autorisé dans des conditions normales. ``` 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 } }; ``` Il s'agit d'un modèle de confinement utile : un agent qui recherche des autorisations dont il ne dispose pas est privé de l'action sensible au lieu d'être autorisé à continuer d'essayer. ## Combinez les conditions temporelles, de garde-corps et de demande **Intention :** Permettre à un appelant de déposer des réclamations, à condition que la session ait reçu moins de trois demandes au cours des dernières 24 heures, que la description de la réclamation ne comporte aucune information bancaire et que le rôle de l'appelant ne soit pas restreint. Les trois types de conditions sont regroupés dans une seule politique, et chaque clause doit être valide pour `permit` qu'elle s'applique. Le `temporal` bloc applique le plafond, le `when` bloc filtre le contenu et le `unless` bloc exclut un rôle. Chacun est évalué de manière indépendante. ``` 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" }; ``` Les écrans de garde-corps`description`, qui sont le seul paramètre de texte libre pris en compte. `file_claim` Pointez un garde-fou contenant des informations sensibles sur un champ qui pourrait vraisemblablement contenir les données que vous recherchez. Si vous la pointez sur un identifiant ou un numéro, elle n'a rien à détecter et la clause passe silencieusement. `description`est facultatif, donc une demande qui l'omet ne donne aucun texte au garde-corps et la clause est maintenue. ## Qu'est-ce qui change lorsque vous modifiez une politique temporelle L'ajout ou la mise à jour d'une politique temporelle sur un moteur invalide les sessions temporelles ouvertes de ce moteur, car l'historique enregistré ne correspond plus aux règles qui lui sont appliquées. La demande suivante qui réutilise une session invalidée échoue avec le protocole HTTP 409`ConflictException`. Démarrez une nouvelle session et réessayez ; la nouvelle session commence avec un historique vide et est évaluée par rapport aux politiques mises à jour. **Important** Prévoyez cela lorsque vous déployez un changement de politique temporel. Les clients doivent traiter a `409` comme « démarrer une nouvelle session ». Tout flux de travail en plusieurs étapes redémarre plutôt que de reprendre.