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_ONLYLe 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 suivantLOG_ONLY. Une fois que vous avez confiance dans les résultats, faites-en la promotion auprès deACTIVE.

Fonctionnement du mode LOG_ONLY

Chaque politique d'un moteur de politiques possède un mode d'application correspondant à l'un ACTIVE ou à l'autreLOG_ONLY. Par défautACTIVE, 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

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

Une demande est évaluée en deux étapes :

ACTIVEet 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 casACTIVE. 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 promueACTIVE). 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 surLOG_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) etLOG_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) etLOG_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.

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 etUpdatePolicy), et il est renvoyé par GetPolicy etListPolicies.

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.

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.

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 :

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.

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 surACTIVE. 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 politiqueLOG_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_ONLYle 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_ONLYles 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_ONLYles 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.