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.

Redacción de políticas en lenguaje natural

Policy in AgentCore seleccionará automáticamente la región óptima dentro de su geografía para procesar las solicitudes de inferencia realizadas a través del servicio de creación de políticas. Esto maximiza los recursos informáticos disponibles, la disponibilidad del modelo y ofrece la mejor experiencia al cliente. Sus datos permanecerán almacenados solo en la región en la que se originó la solicitud; sin embargo, las solicitudes de entrada y los resultados de salida se pueden procesar fuera de esa región. Todos los datos se transmitirán cifrados a través de la red segura de Amazon.

Policy in AgentCore dirigirá de forma segura tus solicitudes de inferencia a los recursos informáticos disponibles dentro del área geográfica en la que se originó la solicitud, de la siguiente manera:

Descripción general de

Cedar proporciona un control de acceso preciso, pero requiere aprender la sintaxis formal. NL2Cedar le permite:

Ejemplo

La política de reembolso de la sección anterior se puede expresar en lenguaje natural:

Lenguaje natural:

Permita que el director con el nombre de usuario «agente de reembolso» procese los reembolsos cuando el importe del reembolso sea inferior a 500 dólares.

Se convierte en cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "refund-agent" &&
  context.input.amount < 500
};

Efectos en las políticas

Las políticas de autorización tienen dos efectos posibles: permitir y prohibir.

Políticas de permisos

Las políticas de permisos especifican lo que pueden hacer los usuarios:

Prohibir políticas

Las políticas de prohibición especifican lo que los usuarios no pueden hacer:

Semántica de autorización

Comprender cómo Cedar evalúa las políticas es crucial para redactar reglas de autorización eficaces. Cedar sigue tres principios fundamentales:

¿Por qué usar políticas de prohibición si todo está denegado de forma predeterminada?

Las políticas de prohibición garantizan que no se puedan permitir por error acciones específicas. Incluso si alguien redacta una política de permisos más amplia, la política de prohibición tiene prioridad y bloquea el acceso.

Escenario de ejemplo:

// Broad permit policy - allows all users to view model results
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
);

// Forbid policy - blocks access to high-sensitivity results
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
)
when {
  context.input.sensitivity == "high"
};

Resultado: los usuarios pueden ver los resultados de sensibilidad baja y media (se aplica el permiso), pero los resultados de alta sensibilidad siempre están bloqueados (no se permite ganar).

Usa las políticas de prohibición para:

Elementos de una política

Las políticas de autorización requieren tres elementos clave:

Especificación principal

El principal identifica a qué usuarios, roles o grupos se aplica la política.

Expresiones flexibles:

Sea específico en cuanto a la identidad:

Incompleto: ❌ «Permitir procesar reembolsos de menos de 500$»

Completo: ✓ «Permitir que el agente de reembolsos procese reembolsos de menos de 500$»

Especificación de la acción

El «qué» identifica qué operaciones, herramientas o acciones controla la política.

Verbos de acción flexibles:

Sea específico con respecto a la herramienta:

Vago: ❌ «Permitir a los usuarios acceder a los modelos»

Claro: ✓ «Permitir que el equipo de ciencia de datos acceda al modelo de análisis»

Especificación de la condición

El «cuándo» especifica en qué circunstancias se aplica la política.

Expresiones condicionales flexibles:

Sea preciso con las condiciones:

Impreciso: ❌ «Permitir transferencias cuando la cantidad sea razonable»

Preciso: ✓ «Permitir transferencias cuando el importe sea inferior a 10 000$»

Ejemplos de políticas

Los siguientes ejemplos demuestran cómo estructurar las políticas de lenguaje natural con principios, acciones y condiciones claros.

Ejemplo 1: Política simple User-Based

Permita que el agente de reembolsos del usuario procese los reembolsos cuando el importe sea inferior a 500$.

Elementos:

Ejemplo 2: Role-Based con varias condiciones

Permita a los usuarios con el rol de agente de seguros actualizar la cobertura cuando el tipo de cobertura sea de responsabilidad civil o colisión y la póliza esté activa.

Elementos:

Ejemplo 3: Scope-Based Acceso

Permite a los usuarios con el objetivo travel:book crear reservas de vuelos cuando la región no sea de la UE y el producto cumpla los requisitos.

Elementos:

Ejemplo 4: Todas las personas con restricciones

Permita que todos los usuarios vean los resultados del modelo cuando la sensibilidad de los datos sea baja o media y el tipo de resultado sea la puntuación de riesgo.

Elementos:

Sintaxis de condiciones

Las condiciones son aquellas en las que las políticas suelen volverse ambiguas. A continuación, te explicamos cómo redactar condiciones claras y comprobables.

Comparaciones numéricas

Buenos ejemplos:

Evite los términos vagos:

Coincidencia de cadenas

Coincidencia exacta:

Múltiples opciones:

Coincidencia de patrones:

Negación:

Condiciones booleanas

Controles directos:

Negación:

Existencia de campo

Campos obligatorios:

Combinación de condiciones

Las políticas reales a menudo necesitan múltiples condiciones. Utilice conectores lógicos claros.

Y la lógica (todo debe ser cierto)

Usa palabras como: «y», «también», «adicionalmente», «mientras», «con»

Ejemplo:

Permita las solicitudes cuando la región sea EE. UU., el producto cumpla los requisitos y el territorio esté activo.

O lógica (al menos una debe ser verdadera)

Usa palabras como: «o», «alternativamente», «cualquiera de las dos»

Ejemplo:

Permita la aprobación cuando la reclamación supere los 10 000 000$ o el nivel de riesgo sea alto o crítico.

Lógica compleja

Para condiciones complejas, utilice una estructura clara:

Ejemplo:

Permita la finalización cuando la fase del flujo de trabajo esté finalizada o aprobada, el estado de cumplimiento haya pasado y la autoridad recaiga en el gerente o el director.

Dificultades comunes

Evite estos errores comunes al escribir políticas de lenguaje natural para asegurarse de que se convierten correctamente a la sintaxis de Cedar.

Error 1: Principios vagos

Malo: «Permitir el acceso a la herramienta de reembolsos»

Bueno: «Permite al agente de reembolso del usuario acceder a la herramienta de reembolsos»

Error 2: Acciones ambiguas

Malo: «Permitir a los usuarios acceder a los datos»

Bueno: «Permitir a los usuarios ver los registros de los pacientes»

Error 3: condiciones subjetivas

Malo: «Permitir transferencias cuando la cantidad sea razonable»

Bueno: «Permitir transferencias cuando el importe sea inferior a 10 000$»

Error 4: Faltan condiciones

Malo: «Permitir a los usuarios con el alcance admin:write actualizar la cobertura»

Bueno: «Permite a los usuarios con scope admin:write actualizar la cobertura cuando la póliza esté activa y el tipo de cobertura sea de responsabilidad civil o colisión»

Error 5: Lógica poco clara

Malo: «Permitir cuando sea A o B y C»

Bueno: «Permitir cuando (A o B) y C» o «Permitir cuando A o (B y C)»