# Tester une politique en mode LOG\_ONLY En utilisant le mode d'application au niveau de la politique, vous pouvez passer de l'une `LOG_ONLY` à l'autre ou répondre à la question suivante : « Quel serait l'effet de cette politique sur mon trafic si elle était appliquée ? » `ACTIVE` `LOG_ONLY`Le mode par stratégie vous permet de tester une politique sur le trafic réel sans affecter les décisions d'autorisation. La politique évalue chaque demande comme si elle était appliquée, mais enregistre uniquement les résultats dans les journaux. Rien n'est bloqué ou autorisé en raison d'une politique dont le mode d'application est le suivant`LOG_ONLY`. Une fois que vous avez confiance dans les résultats, faites-en la promotion auprès de`ACTIVE`. **Topics** + [Fonctionnement du mode LOG\_ONLY](#how-log-only-mode-works) + [Politiques LOG\_ONLY et moteurs de politiques LOG\_ONLY](#log-only-policies-and-log-only-policy-engines) + [Définir le mode d'application d'une politique](#set-the-enforcement-mode-of-a-policy) + [Observez les résultats LOG\_ONLY](#observe-log-only-results) + [Promouvoir une politique en vue de son application](#promote-a-policy-to-enforcement) + [Choix d'un seuil avec le mode LOG\_ONLY](#choosing-a-threshold-with-log-only-mode) + [Considérations et restrictions](#policy-log-only-considerations-and-limitations) ## Fonctionnement du mode LOG\_ONLY Chaque politique d'un moteur de politiques possède un mode d'application correspondant à l'un `ACTIVE` ou à l'autre`LOG_ONLY`. Par défaut`ACTIVE`, les politiques existantes, ainsi que toute nouvelle politique que vous créez sans spécifier le champ, continuent de s'appliquer comme avant. Lorsque le moteur de politiques évalue une demande, il évalue vos `ACTIVE` politiques et vos `LOG_ONLY` politiques côte à côte, mais applique uniquement vos politiques. `ACTIVE` `ACTIVE`les politiques déterminent la décision qui est renvoyée à la AgentCore passerelle et appliquée. Le moteur de politiques applique les sémantiques « default-deny » et « prohibid-wins », ce qui signifie qu'une demande n'est autorisée que si une politique l'autorise, et qu'une seule interdiction émanant d'une politique active la refuse. `LOG_ONLY`les politiques sont évaluées en fonction de la même demande, mais leurs résultats sont séparés. Ils sont signalés sous forme de traces et émis sous forme de CloudWatch métriques Amazon. Ils ne sont jamais combinés dans la décision forcée. | Mode d'application | Evalué à chaque demande ? | Cela a-t-il une incidence sur la décision renvoyée ? | | --- | --- | --- | | `ACTIVE` (par défaut) | Oui | Oui | | `LOG_ONLY` | Oui | Non | Une demande est évaluée en deux étapes : 1. Le moteur de politiques calcule une décision. Seules `ACTIVE` les politiques y contribuent. `LOG_ONLY`les politiques sont évaluées et présentées séparément, mais ne sont jamais prises en compte. 1. Si le moteur est associé à une passerelle en `ENFORCE` mode, la passerelle autorise ou refuse l'action en fonction de la décision du moteur de politiques. Si le moteur est associé à une passerelle en `LOG_ONLY` mode, la passerelle n'agit pas ; la décision est enregistrée mais n'est pas appliquée. `ACTIVE`et `LOG_ONLY` sont traités comme deux ensembles isolés ; une `LOG_ONLY` politique ne peut jamais changer l'expérience de vos appelants. La décision qu'une demande reçoit n'est affectée par aucune `LOG_ONLY` politique. En plus d'enregistrer les `LOG_ONLY` politiques qui correspondaient à une demande, le moteur de politiques indique lesquelles de ces politiques auraient modifié la décision si c'était le cas`ACTIVE`. Il s'agit d'un signal clé à utiliser pour évaluer l'efficacité et la sécurité d'une politique (c'est-à-dire pour savoir si elle peut être promue`ACTIVE`). Par exemple, une `LOG_ONLY` politique qui correspond fréquemment et qui apparaît dans le set de basculement des décisions aurait bloqué votre trafic pendant la fenêtre d'observation. Chaque `LOG_ONLY` politique est évaluée indépendamment de toutes les autres `LOG_ONLY` politiques afin de déterminer l'ensemble des politiques de renversement des décisions. Cependant, chaque évaluation `LOG_ONLY` des politiques prend en compte toutes les `ACTIVE` politiques actuelles. ## Politiques LOG\_ONLY et moteurs de politiques LOG\_ONLY Policy in AgentCore comporte deux contrôles distincts qui utilisent tous deux la valeur LOG\_ONLY. Ils fonctionnent à différents niveaux et répondent à différentes questions. Il est donc important de comprendre laquelle vous définissez. **Mode d'application du moteur de politiques :** contrôle le comportement général du moteur. Lorsque ce paramètre est défini sur`LOG_ONLY`, aucune politique du moteur n'est appliquée, quel que soit son mode de stratégie individuel. Toutes les décisions sont enregistrées. Ceci est défini à l'aide du `mode` champ du `policyEngineConfiguration` lorsque vous associez un moteur de politiques à une passerelle à l'aide `UpdateGateway` des opérations `CreateGateway` or. Les deux valeurs `mode` acceptées sont `ENFORCE` (par défaut) et`LOG_ONLY`. Le mode politique contrôle le comportement d'une seule politique au sein d'un moteur d'application. Lorsqu'elle est définie sur LOG\_ONLY, cette politique est toujours évaluée, mais sa décision est consignée au lieu d'être appliquée. Toutes les autres `ACTIVE` politiques du moteur continuent de s'appliquer normalement. Les deux valeurs `enforcementMode` acceptées sont `ACTIVE` (par défaut) et`LOG_ONLY`. Utilisez LOG\_ONLY au niveau de la politique pour tester un nouveau garde-corps en production sans affecter le trafic. Utilisez LOG\_ONLY au niveau du moteur pour observer le comportement de toutes les politiques avant d'activer leur application.
Mode d'application des politiques
ACTIVE LOG_ONLY
Mode d'application du moteur de politiques ENFORCE Évalué et appliqué. Peut bloquer ou modifier les demandes.Évalué mais non appliqué. Les décisions sont enregistrées uniquement ; ACTIVE les autres politiques du moteur continuent de s'appliquer.
LOG_ONLY Évalué mais non appliqué. La décision est enregistrée uniquement.Évalué mais non appliqué. La décision est enregistrée uniquement.
**Note** Le mode d'application du moteur de politiques est prioritaire. Lorsqu'un moteur de politiques est associé en mode LOG\_ONLY, aucune politique ne peut refuser une action de passerelle, pas même une politique en mode d'`ACTIVE`application, car la passerelle n'agit pas du tout sur la décision du moteur de politiques. Le moteur calcule toujours la décision et vous recevez toujours des données `LOG_ONLY` télémétriques ; la décision n'est tout simplement pas appliquée. ## Définir le mode d'application d'une politique Vous pouvez définir le `enforcementMode` champ d'une politique lorsque vous créez ou mettez à jour la politique (c'est-à-dire `CreatePolicy` et`UpdatePolicy`), et il est renvoyé par `GetPolicy` et`ListPolicies`. **Créez une politique en `LOG_ONLY` mode** Créez une politique en `LOG_ONLY` mode en définissant `enforcementMode` sur `LOG_ONLY` dans la `CreatePolicy` demande. L'exemple suivant crée un garde-fou dans une politique qui interdit le contenu violent au-delà d'un seuil de confiance, mais qui ne fait que le respecter. Pour plus d'informations sur les barrières de sécurité dans les politiques, voir les barres de [sécurité dans les politiques.](policy-guardrails-in-policies.md) ``` aws bedrock-agentcore-control create-policy \ --policy-engine-id my-policy-engine-id \ --name "LogOnlyViolenceFilter" \ --enforcement-mode LOG_ONLY \ --validation-mode IGNORE_ALL_FINDINGS \ --definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.7\")) };"}}' ``` La réponse fait écho à la politique avec « EnforcementMode » : « LOG\_ONLY ». La politique commence à évaluer le trafic et, à partir de ce moment, ses correspondances apparaissent dans les traces et CloudWatch les métriques, sans affecter aucune décision. **Répertorier les politiques et leurs modes d'application** ListPolicies apparaît `enforcementMode` dans le résumé de chaque politique, afin que vous puissiez voir en un coup d'œil quelles politiques sont respectées et lesquelles sont appliquées. ``` aws bedrock-agentcore-control list-policies \ --policy-engine-id my-policy-engine-id \ --query 'policies[].{name:name,enforcementMode:enforcementMode,status:status}' ``` **réponse** ``` [ { "name": "LogOnlyViolenceFilter", "enforcementMode": "LOG_ONLY", "status": "ACTIVE" }, { "name": "RefundLimit", "enforcementMode": "ACTIVE", "status": "ACTIVE" } ] ``` ## Observez les résultats LOG\_ONLY Lorsqu'un appelant fait une tools/call demande via la AgentCore passerelle, celle-ci évalue toutes les politiques, y compris `LOG_ONLY` les politiques, avant de renvoyer la réponse MCP à l'appelant. La réponse de l'appelant n'est jamais affectée par les `LOG_ONLY` politiques ; ces résultats sont présentés uniquement par le biais de l'observabilité. Vous observez le comportement `LOG_ONLY` politique à l'aide de traces et de CloudWatch statistiques Amazon : **Traces et intervalles :** lorsque vous activez le suivi sur votre passerelle, les intervalles d'évaluation des politiques incluent des informations de `LOG_ONLY` correspondance. Vous pouvez inspecter ces intervalles dans la console d' AgentCore observabilité pour voir quelles `LOG_ONLY` politiques ont été déclenchées à la suite d'une demande donnée et si elles auraient annulé la décision. Pour plus d'informations, consultez [Observez vos applications d'agent sur Amazon Bedrock AgentCore Observability](observability.md). **CloudWatch metrics :** Policy in AgentCore émet des métriques sous l'espace de AWS/Bedrock-AgentCore noms. Les indicateurs suivants sont spécifiques à `LOG_ONLY` l'évaluation : | Métrique | Ce que cela vous dit | | --- | --- | | `ConfidenceScore`(avec PolicyEnforcementMode =`LOG_ONLY`) | Le score de confiance que le garde-corps a obtenu pour une politique correspondante`LOG_ONLY`. Utilisez-le pour comprendre la distribution des scores de votre trafic lorsque vous choisissez un seuil. | | `ConfidenceThreshold` (avec `PolicyEnforcementMode=LOG_ONLY`) | Le seuil configuré dans la `LOG_ONLY` politique. Utile pour comparer le score par rapport au seuil entre les politiques. | | `LogOnlyMatches` | Le nombre de demandes pour lesquelles une `LOG_ONLY` politique a été déclenchée. Émis par politique et sous forme de cumul de groupe sur toutes les `LOG_ONLY` politiques du moteur. | | `LogOnlyDecisionFlips` | Nombre de demandes pour lesquelles une `LOG_ONLY` politique aurait modifié la décision si elle avait été promue. Il s'agit du principal signal de promotion : un zéro soutenu signifie que la promotion de la politique ne bloquera pas le trafic actuel. | | `LogOnlyEvalIncomplete` | Émis lorsque `LOG_ONLY` l'évaluation était partielle. Utilisez-le pour signaler un taux soutenu d'évaluations incomplètes. | Toutes les métriques incluent PolicyEngine des OperationName dimensions pour le filtrage. Per-policy les métriques incluent en outre une dimension de politique avec l'ID de politique. Pour plus d'informations sur l'affichage des métriques de vos AgentCore ressources, consultez les données d'[observabilité AgentCore générées par Bedrock](observability.md). ## Promouvoir une politique en vue de son application Lorsque vous avez confiance en une `LOG_ONLY` politique, faites-la appliquer en la `UpdatePolicy` réglant `enforcementMode` sur`ACTIVE`. Aucune autre modification n'est requise et la politique conserve son identifiant, son nom et sa définition. ``` aws bedrock-agentcore-control update-policy \ --policy-engine-id my-policy-engine-id \ --policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \ --enforcement-mode ACTIVE ``` L'inverse est également possible : vous pouvez replacer une `ACTIVE` politique pour la `LOG_ONLY` mettre hors d'application tout en la maintenant en place et en continuant à la respecter. Un cycle de vie typique consiste donc à créer une politique`LOG_ONLY`, à observer le trafic et les indicateurs, puis à `ACTIVE` la promouvoir et, si nécessaire, à la rétrograder `LOG_ONLY` sans supprimer ni recréer la politique. ## Choix d'un seuil avec le mode LOG\_ONLY `LOG_ONLY`le mode est particulièrement utile pour les politiques de protection, dans lesquelles vous devez sélectionner un seuil de confiance qui équilibre la sécurité et l'interruption du trafic légitime. Un seuil trop bas bloque les demandes légitimes ; un seuil trop élevé peut laisser passer les menaces. **Le flux de travail recommandé :** Déployez le garde-corps en `LOG_ONLY` mode avec un seuil que vous jugez raisonnable (par exemple, 0,7). La politique évalue chaque demande et attribue un score de confiance aux CloudWatch indicateurs, mais ne bloque jamais le trafic. Accumulez des données sur une période représentative : des jours ou des semaines de trafic de production réel. La ConfidenceScore métrique (avec PolicyEnforcementMode =LOG\_ONLY) vous donne la distribution des scores produits par votre trafic. Analysez les scores par rapport à Ground Truth. Si vous disposez d'un ensemble de tests étiqueté (messages marqués comme bénins ou malveillants), vous pouvez calculer la précision et le rappeler à chaque valeur de seuil et sélectionner celui qui répond le mieux à vos objectifs. Si vous ne disposez pas de données étiquetées, prélevez des échantillons provenant de la plage des scores les plus élevés (par exemple, 0,8 à 1,0), de la plage des scores les plus faibles (0 à 0,2) et de la zone médiane ambiguë (0,4 à 0,7), puis classez chaque échantillon pour renforcer la confiance dans votre choix de seuil. Mettez à jour la politique avec le seuil que vous avez choisi et promouvez-la pour `ACTIVE` : ``` aws bedrock-agentcore-control update-policy \ --policy-engine-id my-policy-engine-id \ --policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \ --enforcement-mode ACTIVE \ --definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.65\")) };"}}' ``` Ce flux de travail garantit que le seuil reflète vos modèles de trafic réels plutôt qu'une valeur par défaut générique. ## Considérations et restrictions `LOG_ONLY`les politiques n'influent jamais sur les décisions. Une `LOG_ONLY` politique ne peut pas autoriser ou refuser une action. La décision qu'une demande reçoit est identique à la décision qu'elle recevrait si la `LOG_ONLY` politique n'existait pas. Il s'agit de la garantie fondamentale de cette fonctionnalité. Les changements sont finalement cohérents. La création, la mise à jour ou la promotion d'une politique sont appliquées au parcours d'évaluation en quelques secondes. Planifiez vos fenêtres d'observation et vos étapes de promotion en conséquence plutôt que de vous attendre à un changement instantané. Les listes de résultats sont délimitées. `LOG_ONLY`les listes de correspondance et de retournement de décision sont chacune plafonnées à 1 000 entrées par demande. Pour les moteurs dotés d'un très grand nombre de `LOG_ONLY` politiques, fiez-vous aux CloudWatch indicateurs pour obtenir des comptes agrégés complets. L'évaluation peut être partielle. Lorsque `LOG_ONLY` l'évaluation d'une demande est incomplète, il se peut que des entrées soient manquantes dans les `LOG_ONLY` signaux correspondant à cette demande. La décision exécutée n'est jamais affectée.