Probar una política en el modo LOG_ONLY

Con el modo de aplicación a nivel de política, puede alternar entre 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 le permite probar una política en el tráfico real sin que ello afecte 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 seaLOG_ONLY. Una vez que confíes en los resultados, promuévelo aACTIVE.

Cómo funciona el modo LOG_ONLY

Cada política de un motor de políticas tiene un modo de aplicación de uno u ACTIVE otro. LOG_ONLY El valor predeterminado esACTIVE, por lo 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. ACTIVE

ACTIVElas políticas determinan la decisión que se devuelve al AgentCore Gateway y se hace cumplir. El motor de políticas aplica las semánticas «por defecto, se deniega» y «se prohíbe, 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 deniega.

LOG_ONLYlas políticas se evalúan en función de la misma solicitud, pero sus resultados se mantienen separados. Se registran en trazas 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 coincidieron en una solicitud, el motor de políticas informa cuáles de esas políticas habrían cambiado la decisión si lo hubieran sidoACTIVE. Esta es una señal clave que se debe utilizar al evaluar la eficacia y la seguridad de una política (es decir, si se puede promover su aprobaciónACTIVE). Por ejemplo, una LOG_ONLY política que coincide con frecuencia y que aparece en el conjunto de opciones de cambio de 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 de cambio 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

La política in AgentCore tiene dos controles independientes y ambos utilizan el valor LOG_ONLY. Funcionan en distintos niveles y responden a distintas preguntas, por lo que es importante entender cuál 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 en el motor, independientemente de su modo de política individual. Se registran todas las decisiones. Se establece mediante el mode campo de 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. Si 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 se siguen aplicando 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 barandilla en producción sin que ello afecte al tráfico. Utilice LOG_ONLY a nivel de motor para observar el comportamiento de todas las políticas antes de permitir su aplicación.

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

Puede configurar el enforcementMode campo de una política al crear o actualizar la política (es decir, CreatePolicy yUpdatePolicy), y se devuelve mediante GetPolicy yListPolicies.

Cree una política en LOG_ONLY el modo Cree una política en LOG_ONLY el modo enforcementMode configurándolo LOG_ONLY en la CreatePolicy solicitud. El siguiente ejemplo crea una barrera en la política 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 de protección en la política, consulte las barreras de protección 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 evaluando en función del tráfico y, a partir de ese momento, las coincidencias aparecen en los registros y CloudWatch las métricas, sin que ello afecte a la decisión.

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

ListPolicies aparece enforcementMode en el resumen de cada política, para que pueda ver de un vistazo qué políticas se cumplen 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 puerta de AgentCore enlace, la puerta de enlace evalúa todas las políticas, incluidas las políticas, antes de devolver la respuesta LOG_ONLY 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 informan únicamente a través de la observabilidad.

Se observa el comportamiento LOG_ONLY de las políticas a través de los rastreos y CloudWatch las métricas de Amazon:

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

CloudWatch métricas: Policy 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 también incluyen una dimensión de política con el ID 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 optando porACTIVE. No se requiere ningún otro cambio y la política conserva su ID, 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: se puede volver a colocar una ACTIVE política LOG_ONLY para dejar de aplicarla 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, luego, promocionarla ACTIVE y, si es necesario, volver a degradarla LOG_ONLY sin eliminarla ni volver a crearla.

Elegir un umbral con el modo LOG_ONLY

LOG_ONLYeste modo es 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: despliegue la barandilla en un LOG_ONLY modo con un umbral que considere razonable (por ejemplo, 0,7). La política evalúa todas las solicitudes y emite una puntuación de confianza según 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) te proporciona la distribución de las puntuaciones que genera tu tráfico.

Analiza las puntuaciones comparándolas con la realidad básica. Si tiene un conjunto de pruebas etiquetado (las instrucciones están marcadas como benignas o maliciosas), puede calcular la precisión y la memoria en cada valor umbral y seleccionar el que mejor se adapte a sus objetivos. Si no tiene datos etiquetados, muestree las indicaciones del rango de puntuación alta (por ejemplo, 0,8 a 1,0), el rango de puntuación baja (0 a 0,2) y la zona media ambigua (0,4 a 0,7) y, a continuación, clasifique cada muestra para generar confianza en la elección del umbral. Actualice la política con el umbral que haya elegido y promuévala 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 provocar que se permita o deniegue 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 principal garantía de la función.

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

Las listas de resultados están acotadas. LOG_ONLYLas listas de coincidencias y de cambio de decisiones tienen un límite máximo de 1000 entradas por solicitud. En el caso de 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 las LOG_ONLY señales de esa solicitud. La decisión ejecutada nunca se ve afectada.