Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Probar una política en modo LOG_ONLY

Si utilizas el modo de aplicación a nivel de política, puedes alternar ACTIVE y responder LOG_ONLY a la pregunta: «¿Qué afectaría esta política a mi tráfico si se aplicara?» LOG_ONLYEl modo por política te permite probar una política en tráfico real sin afectar a las decisiones de autorización. La política evalúa cada solicitud como si se hubiera aplicado, pero solo escribe los resultados en los registros. No se bloquea ni se permite nada como resultado de una política cuyo modo de aplicación esLOG_ONLY. Una vez que confíes en los resultados, promuévelo tambiénACTIVE.

Cómo funciona el modo LOG_ONLY

Cada política de un motor de políticas tiene un modo de aplicación de oACTIVE. LOG_ONLY El valor predeterminado es ACTIVE que las políticas existentes y cualquier política nueva que cree sin especificar el campo seguirán aplicándose como antes. Cuando el motor de políticas evalúa una solicitud, evalúa sus ACTIVE políticas y sus LOG_ONLY políticas en paralelo, pero solo las aplica a sus políticas. ACTIVE

ACTIVElas políticas determinan la decisión que se devuelve al AgentCore Gateway y se aplica. El motor de políticas aplica la semántica de «denegar por defecto» y «prohibir gana», lo que significa que una solicitud solo se permite si una política lo permite y una sola prohibición de cualquier política activa la rechaza.

LOG_ONLYlas políticas se evalúan en función de la misma solicitud, pero sus resultados se mantienen separados. Se registran en forma de rastreo y se emiten como CloudWatch métricas de Amazon. Nunca se combinan en la decisión ejecutada.

Una solicitud se evalúa en dos etapas:

ACTIVEy LOG_ONLY se tratan como dos conjuntos aislados; una LOG_ONLY política nunca puede cambiar la experiencia de las personas que llaman. La decisión que recibe una solicitud no se ve afectada por ninguna LOG_ONLY política.

Además de registrar las LOG_ONLY políticas que coinciden en una solicitud, el motor de políticas informa cuáles de esas políticas habrían cambiado la decisión si lo hubieran hechoACTIVE. Esta es una señal clave para evaluar la eficacia y la seguridad de una política (es decir, si es posible promoverlaACTIVE). Por ejemplo, una LOG_ONLY política que coincide con frecuencia y que aparece en la lista de políticas que cambian las decisiones habría bloqueado el tráfico durante el período de observación. Cada LOG_ONLY política se evalúa de forma independiente de todas las demás LOG_ONLY políticas para determinar el conjunto de políticas que cambian la toma de decisiones. Sin embargo, cada evaluación LOG_ONLY de políticas considera todas las políticas actualesACTIVE.

Políticas LOG_ONLY y motores de políticas LOG_ONLY

Policy in AgentCore tiene dos controles independientes y ambos usan el valor LOG_ONLY. Operan en diferentes capas y responden a diferentes preguntas, por lo que es importante entender cuál se está configurando.

Modo de aplicación del motor de políticas: controla el comportamiento general del motor. Cuando se establece enLOG_ONLY, no se aplica ninguna política del motor, independientemente de su modo de política individual. Se registran todas las decisiones. Esto se establece mediante el mode campo policyEngineConfiguration Cuando se asocia un motor de políticas a una puerta de enlace mediante las UpdateGateway operaciones CreateGateway o. Los dos valores que se mode aceptan son ENFORCE (predeterminado) yLOG_ONLY.

El modo de política controla el comportamiento de una sola política dentro de un motor de aplicación. Cuando se establece en LOG_ONLY, esa política se sigue evaluando, pero su decisión se registra en lugar de aplicarse. Todas ACTIVE las demás políticas del motor siguen aplicándose con normalidad. Los dos valores que se enforcementMode aceptan son ACTIVE (predeterminado) yLOG_ONLY.

Utilice LOG_ONLY, a nivel de política, para realizar pruebas paralelas de una nueva barrera en producción sin afectar al tráfico. Utilice LOG_ONLY a nivel del motor para observar el comportamiento de todas las políticas antes de permitir su aplicación.

Establezca el modo de aplicación de una política

Puede establecer el enforcementMode campo en una política al crear o actualizar la política (es decir, CreatePolicy yUpdatePolicy) y lo devuelve GetPolicy yListPolicies.

Crear una política en LOG_ONLY modo Cree una política en LOG_ONLY modo enforcementMode configurándola LOG_ONLY en la CreatePolicy solicitud. El siguiente ejemplo crea una política restrictiva que prohíbe el contenido violento por encima de un umbral de confianza, pero solo lo respeta. Para obtener más información sobre las barreras en las políticas, consulte las barreras en las políticas. Barreras en las políticas

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 respuesta se hace eco de la política con «enforcementMode»: «LOG_ONLY». La política comienza a evaluarse en función del tráfico y, a partir de ese momento, sus coincidencias aparecen en los registros y CloudWatch las métricas, sin afectar a ninguna decisión.

Enumera las políticas y sus modos de aplicación

ListPolicies aparece enforcementMode en cada resumen de política, para que puedas ver de un vistazo qué políticas se están cumpliendo y cuáles se están aplicando.

aws bedrock-agentcore-control list-policies \
--policy-engine-id my-policy-engine-id \
--query 'policies[].{name:name,enforcementMode:enforcementMode,status:status}'

respuesta

[
  { "name": "LogOnlyViolenceFilter", "enforcementMode": "LOG_ONLY", "status": "ACTIVE" },
  { "name": "RefundLimit",           "enforcementMode": "ACTIVE",   "status": "ACTIVE" }
]

Observe los resultados de LOG_ONLY

Cuando una persona que llama hace una tools/call solicitud a través de la AgentCore pasarela, la puerta de enlace evalúa todas las políticas, incluidas las políticas, antes de devolver la LOG_ONLY respuesta del MCP a la persona que llama. La respuesta de la persona que llama nunca se ve afectada por LOG_ONLY las políticas; esos resultados se publican únicamente a través de la observabilidad.

El comportamiento de las LOG_ONLY políticas se observa mediante los seguimientos y las métricas de Amazon CloudWatch :

Trazos e intervalos: cuando habilitas el rastreo en tu pasarela, los períodos de evaluación de las políticas incluyen información sobre las LOG_ONLY coincidencias. Puedes inspeccionar estos intervalos en la consola de AgentCore Observability para ver qué LOG_ONLY políticas se activaron en una solicitud determinada y si habrían invertido la decisión. Para obtener más información, consulte Observe las solicitudes de sus agentes en Amazon Bedrock Observability. AgentCore

CloudWatch métricas: La política in AgentCore emite métricas en el espacio de nombres. AWS/Bedrock-AgentCore Las siguientes métricas son específicas de la evaluación: LOG_ONLY

Todas las métricas incluyen PolicyEngine OperationName dimensiones para el filtrado. Per-policy Las métricas incluyen además una dimensión de política con el identificador de la política.

Para obtener más información sobre la visualización de las métricas de sus AgentCore recursos, consulte los datos de observabilidad AgentCore generados por Bedrock.

Promueva una política para su cumplimiento

Cuando confíe en una LOG_ONLY política, promuévala para que se haga cumplir conUpdatePolicy, enforcementMode configurándola enACTIVE. No se requiere ningún otro cambio y la política conserva su identificador, nombre y definición.

aws bedrock-agentcore-control update-policy \
--policy-engine-id my-policy-engine-id \
--policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \
--enforcement-mode ACTIVE

También se admite lo contrario: puede cambiar una ACTIVE política a otro lugar LOG_ONLY para que deje de aplicarse y, al mismo tiempo, mantenerla en vigor y seguir respetándola.

Por lo tanto, un ciclo de vida típico consiste en crear una políticaLOG_ONLY, observar el tráfico y las métricas y, a ACTIVE continuación, promoverla y, si es necesario, volver a degradarla LOG_ONLY sin eliminar y volver a crear la política.

Elegir un umbral con el modo LOG_ONLY

LOG_ONLYeste modo resulta especialmente útil para las políticas de protección, en las que es necesario seleccionar un umbral de confianza que equilibre la seguridad con la interrupción del tráfico legítimo. Un umbral demasiado bajo bloquea las solicitudes legítimas; uno demasiado alto puede dejar pasar las amenazas.

El flujo de trabajo recomendado: Implemente la barandilla en un LOG_ONLY modo con un umbral que considere razonable (por ejemplo, 0.7). La política evalúa cada solicitud y emite una puntuación de confianza a CloudWatch las métricas, pero nunca bloquea el tráfico.

Acumule datos en un período representativo: días o semanas de tráfico de producción real. La ConfidenceScore métrica (con PolicyEnforcementMode =LOG_ONLY) muestra la distribución de las puntuaciones que produce tu tráfico.

Analiza las puntuaciones comparándolas con la verdad básica. Si tiene un conjunto de pruebas etiquetado (indicaciones marcadas como benignas o maliciosas), puede calcular la precisión y la recuperación de cada valor umbral y seleccionar el que mejor se adapte a sus objetivos. Si no tiene datos etiquetados, muestree las solicitudes del rango de puntuación más alta (por ejemplo, de 0,8 a 1,0), del rango de puntuación más baja (de 0 a 0,2) y de la zona media ambigua (de 0,4 a 0,7) y, a continuación, clasifique cada muestra para aumentar la confianza en su elección de umbral. Actualiza la política con el umbral que hayas elegido y promuévela para: 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\")) };"}}'

Este flujo de trabajo garantiza que el umbral refleje tus patrones de tráfico reales y no un valor predeterminado genérico.

Consideraciones y limitaciones

LOG_ONLYlas políticas nunca afectan a las decisiones. Una LOG_ONLY política no puede hacer que se permita o rechace una acción. La decisión que recibe una solicitud es idéntica a la decisión que recibiría si la LOG_ONLY política no existiera. Esta es la garantía principal de la función.

Los cambios son, en última instancia, consistentes. La creación, actualización o promoción de una política se aplica a la ruta de evaluación en unos segundos. Planifique sus períodos de observación y las etapas de ascenso en consecuencia, en lugar de esperar un cambio instantáneo.

Las listas de resultados son limitadas. LOG_ONLYcada una de las listas de coincidencias y de intercambio de decisiones tiene un límite de 1000 entradas por solicitud. En el caso de los motores con un gran número de LOG_ONLY políticas, confíe en las CloudWatch métricas para obtener recuentos agregados completos.

La evaluación puede ser parcial. Cuando LOG_ONLY la evaluación de una solicitud está incompleta, es posible que falten entradas en LOG_ONLY las señales de esa solicitud. La decisión ejecutada nunca se ve afectada.