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.

Politiques temporelles

La politique d'Amazon Bedrock AgentCore prend en charge les politiques temporelles  : des politiques dont les décisions dépendent de l'historique des actions d'un agent au cours d'une session, et pas uniquement de la demande en cours. Grâce à eux, vous pouvez appliquer des règles qui couvrent plusieurs actions, telles que le fait d'exiger une approbation avant une action, de limiter le nombre de fois qu'une action est exécutée dans un laps de temps ou de maintenir un total cumulé en dessous d'un seuil.

Une politique temporelle est une forbid règle permit ou qui contient un ou plusieurs opérateurs temporels. Chaque condition correspond à un événement antérieur enregistré pour la session par son action, son principal et les champs d'entrée ou de sortie de l'action, et ne prend en compte que les événements compris dans une fenêtre temporelle requise. Une condition peut corréler un événement correspondant à la demande en cours. Ainsi, une règle peut exiger, par exemple, que la demande en cours agisse sur une ressource déjà approuvée par une action précédente. Le moteur de politiques enregistre les événements de chaque session et évalue ces conditions à chaque demande. Vous pouvez donc exprimer les règles relatives aux sessions sous forme de politique au lieu de suivre les événements dans le code de votre agent ou de votre outil.

Les politiques temporelles sont écrites en Dogwood, qui est compatible avec Cedar et prend en charge toutes les politiques Cedar existantes. Les politiques de Standard Cedar sont apatrides et ne prennent en compte que la demande en cours. Les politiques temporelles suivent le même modèle de refus par défaut : une demande n'est autorisée que si un permit s'applique et aucun forbid ne la remplace. Les conditions temporelles sont distinctes des conditions temporelles, qui limitent l'accès en fonction de l'heure de l'horloge murale (context.system.now) plutôt que de l'historique des sessions. Vous pouvez également exécuter une politique temporelle en LOG_ONLY mode pour observer ce qu'elle déciderait avant de la promouvoir ENFORCE ; voir Modes d'application des politiques.

Concepts clés

Les politiques temporelles s'appuient sur deux éléments : le langage de politique Dogwood, qui exprime des règles tenant compte des sessions, et la session de politique, qui décrit l'historique qu'une règle peut consulter.

Le langage politique de Dogwood

Les politiques temporelles sont écrites en Dogwood, un langage de politique open source que Policy AgentCore utilise pour les autorisations tenant compte des sessions. Dogwood s'appuie sur Cedar et utilise le même modèle d'autorisation : vous écrivez permit et forbid régissez un principal, une action et une ressource, et une demande n'est autorisée que si un permit s'applique et que personne ne la forbid remplace. Dogwood est compatible avec Cedar et prend en charge toutes les politiques Cedar existantes, de sorte que chaque police Cedar valide est également une politique Dogwood valide. Vos politiques ponctuelles existantes continuent de fonctionner sans modification, et vous ajoutez des conditions temporelles uniquement lorsqu'une règle doit prendre en compte plus que la demande en cours.

Avec Dogwood, vous exprimez les règles relatives aux sessions de manière déclarative sous forme de politique au lieu d'implémenter une logique de suivi des événements dans le code de votre agent ou de votre outil. Le moteur de politiques enregistre les événements pertinents et évalue l'état de chaque demande. Par exemple, la politique suivante n'autorise une vente que lorsqu'une approbation correspondante a eu lieu au cours de l'heure précédente :

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 fournit des opérateurs temporels pour les modèles courants : formerly within (un événement correspondant s'est produit plus tôt dans la fenêtre), since within (une condition est maintenue depuis un événement d'ancrage), et les agrégations count et sum les événements correspondants dans la fenêtre.

Pour la syntaxe temporelle complète, consultez le guide linguistique Dogwood sur le site Web de Dogwood Policy.

Sessions de politique et ID de session

Les politiques temporelles sont évaluées par rapport à une session de politique  : une séquence d'appels Gateway connexes regroupés sous un ID de session. L'historique temporel étant limité à la session, une condition ne prend en compte que les événements enregistrés pour la même session que celle à laquelle la demande est autorisée. Vous générez l'identifiant de session et vous l'envoyez à chaque demande dans l'x-amzn-bedrock-agentcore-policy-session-iden-tête, en commençant par votre première demande. La passerelle ne génère pas d'identifiant de session en votre nom. Si vous omettez l'en-tête ou si vous envoyez une valeur vide, la passerelle n'établit pas de session. Si le moteur de politique associé contient une politique temporelle, les demandes sans identifiant de session échouent avec une erreur de validation.

Pour plus de détails sur la transmission de l'ID de session, le cycle de vie de la session et la manière dont l'identité se propage lors d'appels à sauts multiples, consultez Sessions de politique et propagation d'identité.

Invalidation de session

Une politique temporelle décide d'autoriser ou non une action en examinant ce qui s'est passé plus tôt dans la même session. Cet historique n'a de sens que par rapport aux politiques temporelles qui étaient en vigueur au début de la session. Si vous modifiez les politiques temporelles du moteur alors qu'une session est ouverte, l'historique enregistré ne correspond plus aux règles actuelles. Le service met donc fin à la session au lieu de prendre une décision concernant des données incohérentes.

L'ajout ou la mise à jour d'une politique temporelle sur le moteur invalide les sessions de politique temporelle actives du moteur. Après une telle modification, la requête suivante qui réutilise une session invalidée échoue avec un HTTP 409ConflictException.

Pour récupérer, démarrez une nouvelle session et envoyez de nouveau la demande. La nouvelle session commence avec un historique vide et est évaluée par rapport à vos politiques mises à jour.

Pris en charge AWS Régions

Les politiques temporelles sont disponibles dans les AWS régions indiquées dans le tableau suivant.

Considérations

Cross-account et demandes interrégionales

Les sessions de politique temporelle ne prennent pas en charge la propagation entre régions ou entre comptes. Les politiques temporelles ne contrôlent pas les requêtes entre les AgentCore passerelles et leurs cibles d'exécution lorsque ces ressources résident dans différents comptes ou différentes AWS régions. Pour que les politiques temporelles contrôlent les actions de votre agent, la passerelle et toutes ses cibles doivent résider dans le même AWS compte et la même AWS région.

Les politiques temporelles imposent l'accès uniquement lorsque le jeton d'accès à la charge de travail (WAT) traverse la chaîne de demandes (voir Sessions de politiques et propagation d'identité). Lorsque votre chaîne de requêtes est entièrement composée de composants AgentCore Gateway et Runtime, l'en-tête WAT AgentCore se propage automatiquement d'un saut à l'autre. Cette propagation se produit au sein d'une seule AWS région et d'un seul compte. Les politiques temporelles s'appliquent tout au long de la chaîne. Une chaîne telle que Gateway to Runtime to Gateway to Runtime transporte le jeton de bout en bout sans aucun travail supplémentaire de votre part.

Les chaînes qui incluent des composants autres que Gateway ou Runtime se comportent différemment. Une demande peut passer par une infrastructure que vous gérez vous-même, telle qu'une passerelle API tierce ou un cluster Kubernetes. Ce composant doit transmettre l'en-tête WAT et vous devez ajouter une logique personnalisée pour propager le WAT via ces sauts. L'emplacement physique de ces éléments non AgentCore constitutifs n'a aucune incidence sur la portée de la région et du compte. Ils peuvent être exécutés n'importe où, à condition que les AgentCore composants de chaque côté retournent au même AWS compte et à la même AWS région où les politiques temporelles s'appliquent.

Autorisations IAM requises

Les politiques temporelles comportent également une condition préalable à l'IAM. Le rôle IAM configuré pour la passerelle doit autoriser l'bedrock-agentcore:GetWorkloadAccessTokenaction. Cette exigence est valable même lorsque vous utilisez IAM pour votre autorisation sortante. Le WAT permet aux politiques temporelles de corréler les actions d'un agent au cours d'une session. La passerelle doit être en mesure d'obtenir le WAT, quelle que soit la manière dont vous authentifiez les appels sortants. Si le rôle ne dispose pas de cette autorisation, l'application de la politique temporelle échoue. Accordez bedrock-agentcore:GetWorkloadAccessToken au rôle de passerelle lorsque vous configurez des politiques temporelles. Pour la politique d'autorisation complète, y compris les ARN des ressources et la portée du répertoire d'identité de la charge de travail, voir Autorisations IAM pour les politiques temporelles.

Self-referential les conditions incluent la demande en cours

Lorsqu'une condition temporelle fait référence à la même action qui est autorisée, l'événement propre à la demande en cours est inclus dans l'évaluation. Par exemple, une condition qui compte le nombre de fois qu'une action s'est produite dans une fenêtre compte également l'invocation en cours.

Une action antérieure doit pouvoir être enregistrée en tant que réponse

L'historique des sessions enregistre chaque action comme un événement dont le type reflète le résultat : une action autorisée qui se termine est enregistrée comme un response événement, et une action refusée par une politique est enregistrée comme un error événement. Une condition temporelle correspond uniquement aux événements du type qu'elle nomme. Ainsi, une condition qui correspond à un response événement ne prend en compte que les actions antérieures autorisées. Assurez-vous que l'action préalable sur laquelle repose une politique temporelle est elle-même autorisée par une politique ; si elle est refusée, elle est enregistrée comme un error plutôt que comme unresponse, et aucune response condition ne correspond jamais à celle-ci.

Séquencement des actions qui dépendent d'une réponse antérieure

L'historique des sessions enregistre l'responseévénement de chaque action une fois l'action terminée. Lorsqu'une politique dépend de la réponse d'une action précédente au cours de la même session, telle qu'un champ de sortie ou une since condition, émettez la demande dépendante après avoir reçu la réponse de l'action précédente. En effectuant chaque action avant de commencer celle qui en dépend, la séquence de votre flux de travail reste alignée sur l'historique évalué par la politique.

Quotas

Les quotas suivants s'appliquent aux politiques temporelles :

Observabilité

Amazon Bedrock AgentCore publie des mesures et des données d'étendue qui vous permettent d'observer l'évaluation des politiques temporelles. Les métriques sont publiées dans l'espace de AWS/Bedrock-AgentCore CloudWatch noms par défaut. Les données Span deviennent disponibles une fois que vous avez activé les traces pour la ressource AgentCore Gateway attachée et peuvent être trouvées dans le groupe de CloudWatch aws/spans journaux.

Les signaux suivants sont spécifiques aux politiques temporelles :

Pour obtenir la liste complète des mesures, des dimensions et des attributs de portée des politiques, et pour savoir comment activer l'observabilité, voir Politique en matière de AgentCore données d'observabilité.

Considérations sur la sécurité

La limitation du débit avec des politiques temporelles s'applique au cours d'une seule session. Étant donné que l'historique temporel est limité à une session et que l'identifiant de session est fourni par l'appelant, une limite count basée sur « au plus N appels par session » ne compte que les événements enregistrés pour cette session. Le démarrage d'une nouvelle session entraîne un nouveau décompte. Par conséquent, une limite de débit temporelle limite l'activité au sein d'une session plutôt que sur l'ensemble des sessions de l'appelant.