Políticas de redacción en lenguaje natural
Policy in AgentCore seleccionará automáticamente la región óptima dentro de su zona geográfica 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 únicamente en la región en la que se originó la solicitud; sin embargo, es posible que las solicitudes de entrada y los resultados de salida se procesen 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á sus solicitudes de inferencia de forma segura a los recursos informáticos disponibles en el área geográfica en la que se originó la solicitud, de la siguiente manera:
-
Las solicitudes de inferencia que se originen en la Unión Europea se procesarán dentro de la Unión Europea.
-
Las solicitudes de inferencia que se originen en los Estados Unidos se procesarán en los Estados Unidos.
-
Las solicitudes de inferencia que se originen en APAC se procesarán dentro de APAC.
Temas
Descripción general de
Cedar proporciona un control de acceso preciso, pero requiere aprender la sintaxis formal. NL2Cedar le permite:
-
Redactar los requisitos de autorización en lenguaje natural
-
Convierta automáticamente a la sintaxis de Cedar
-
Compruebe que las políticas generadas se ajustan a sus requisitos
nota
La generación de políticas en lenguaje natural requiere una AgentCore puerta de enlace y un motor de políticas implementados. El servicio utiliza el esquema AgentCore Gateway para generar políticas de Cedar válidas. Consulte Introducción a la política en AgentCore para obtener instrucciones de configuración.
nota
El lenguaje natural es flexible, pero la precisión es esencial para la seguridad. Las políticas deben ser claras e inequívocas.
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 «refund-agent» procese los reembolsos cuando el importe del reembolso sea inferior a 500$.
Se convierte a 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 de la política
Las políticas de autorización tienen dos posibles efectos: permitir y prohibir.
Políticas de permisos
Las políticas de permisos especifican lo que pueden hacer los usuarios:
-
«Permitir que el agente de reembolsos del usuario procese los reembolsos»
-
«Permitir que los usuarios con funciones de director aprueben sus decisiones»
-
«Autoriza a los usuarios con scope admin:write a actualizar la cobertura»
Prohibir políticas
Las políticas de prohibición especifican lo que los usuarios no pueden hacer:
-
«Impedir que los usuarios accedan a modelos de alta sensibilidad»
-
«Impedir que los aseguradores junior aprueben las decisiones»
-
«Prohíba a los usuarios procesar reembolsos cuando la validación del riesgo esté pendiente»
Semántica de autorización
Comprender cómo Cedar evalúa las políticas es crucial para redactar reglas de autorización efectivas. Cedar sigue tres principios fundamentales:
-
De forma predeterminada, todo está denegado: si ninguna política permite una acción de forma explícita, se bloquea automáticamente
-
Prohibir siempre gana: si alguna política de prohibición coincide, se deniega el acceso incluso si las políticas de permisos también coinciden
-
Se requiere al menos un permiso: para que se conceda el acceso, debe coincidir al menos una política de permisos y ninguna política de prohibición puede coincidir
¿Por qué utilizar políticas de prohibición si todo está denegado de forma predeterminada?
Las políticas de prohibición garantizan que no se permitan acciones específicas por error. Incluso si alguien redacta una política de permisos más amplia, la política de prohibición prevalece y bloquea el acceso.
Ejemplo de escenario:
// 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 (siempre que se permita), pero los resultados de alta sensibilidad siempre están bloqueados (está prohibido ganar).
Utilice políticas de prohibición para:
-
Restricciones de seguridad explícitas que nunca deben anularse
-
Requisitos de conformidad
-
Cierres de emergencia
-
Crear excepciones a políticas de permisos más amplias
Elementos de una política
Las políticas de autorización requieren tres elementos clave:
-
Quién: qué usuarios o roles pueden realizar la acción
-
Qué: qué operaciones o herramientas pueden usar
-
Cuándo y bajo qué condiciones o restricciones
Especificación principal
La principal identifica a qué usuarios, roles o grupos se aplica la política.
Expresiones flexibles:
-
«Permita que el agente de reembolso del usuario...»
-
«Permita a los usuarios con el nombre de usuario del agente de reembolso...»
-
«Los usuarios con el rol de agente de seguros pueden...»
-
«Cualquier persona con el alcance de reembols:write está autorizada a...»
-
«Todos los usuarios pueden...»
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:
-
«Permitir a los usuarios procesar los reembolsos»
-
«Permitir el procesamiento de reembolsos»
-
«Los usuarios pueden crear aplicaciones»
-
«Autorizar la visualización de los registros de auditoría»
Sea específico acerca de la herramienta:
Vague: ❌ «Permitir a los usuarios acceder a los modelos»
Claro: ✓ «Permita que el equipo de ciencia de datos acceda al modelo de análisis»
Especificación de condición
El «cuándo» especifica en qué circunstancias se aplica la política.
Expresiones condicionales flexibles:
-
«... cuando la cantidad es inferior a 500$»
-
«... si la región es EE. UU., CA o Reino Unido»
-
«... solo cuando el estado de aprobación lo apruebe el gerente»
-
«... siempre que se haya presentado la puntuación de riesgo»
Sea preciso con las condiciones:
Vago: ❌ «Permitir transferencias cuando el importe 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.
Temas
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:
-
Quién: agente de reembolso del usuario
-
Qué: procesar reembolsos
-
Cuándo: el importe es inferior a 500$
Ejemplo 2: Role-Based con múltiples 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:
-
Quién: usuarios con el rol de agente de seguros
-
Qué: actualizar la cobertura
-
Cuándo: el tipo de cobertura es de responsabilidad civil o colisión Y la póliza está activa
Ejemplo 3: Scope-Based Acceso
Permita a los usuarios de Scope travel:book crear reservas de vuelos cuando la región no sea de la UE y el producto cumpla los requisitos.
Elementos:
-
Quién: usuarios con Scope travel:book
-
Qué: crear reservas de vuelos
-
Cuándo: la región no es de la UE Y el producto es apto
Ejemplo 4: Todas las personas con limitaciones
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 una puntuación de riesgo.
Elementos:
-
Quién: todos los usuarios
-
Qué: ver los resultados del modelo
-
Cuándo: la sensibilidad de los datos es baja o media Y el tipo de resultado es una puntuación de riesgo
Sintaxis de condiciones
En las condiciones, las políticas suelen volverse ambiguas. A continuación, te explicamos cómo escribir condiciones claras y comprobables.
Comparaciones numéricas
Buenos ejemplos:
-
«cuando el importe sea inferior a 500$»
-
«cuando el importe de la cobertura sea inferior a 5 millones»
-
«cuando la reclamación supere los 10 000 000$»
-
«cuando el número de pasajeros es exactamente de 2»
Evite los términos vagos:
-
❌ «cuando la cantidad es pequeña»
-
❌ «cuando la cobertura es alta»
Coincidencia de cadenas
Coincidencia exacta:
-
«cuando la región es EE. UU.»
-
«cuando el método de pago es con tarjeta de crédito»
-
«cuando se apruebe el estado»
Múltiples opciones:
-
«cuando la región es EE. UU., CA o Reino Unido»
-
«cuando el tipo de decisión es aprobar o remitir»
Coincidencia de patrones:
-
«cuando el correo electrónico contiene @example .com»
-
«cuando el ámbito contiene admin:write»
Negación:
-
«cuando la región no es de la UE»
-
«cuando la clasificación no esté restringida»
Condiciones booleanas
Controles directos:
-
«cuando el producto es apto»
-
«cuando se presente la puntuación de riesgo»
-
«cuando se solicita el envío exprés»
Negación:
-
«cuando el producto no es apto»
-
«cuando no se presenta la puntuación de riesgo»
Existencia en el campo
Campos obligatorios:
-
«cuando se proporciona un motivo»
-
«cuando existe un identificador de solicitud»
-
«cuando se especifique la fecha de devolución»
Condiciones de combinación
Las políticas reales suelen necesitar múltiples condiciones. Utilice conectores lógicos claros.
Y lógica (todo debe ser cierto)
Usa palabras como: «y», «también», «adicionalmente», «mientras», «con»
Ejemplo:
Permita las solicitudes cuando la región sea de EE. UU. y 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»
Ejemplo:
Permita la aprobación cuando la reclamación supere los 10 000 000$ o cuando 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 etapa del flujo de trabajo se haya revisado, completado o aprobado, se haya superado el estado de conformidad y la autoridad sea el gerente o el director.
Errores comunes
Evite estos errores comunes al escribir políticas de lenguaje natural para asegurarse de que se convierten correctamente a la sintaxis de Cedar.
Temas
Error 1: principios vagos
Malo: «Permitir el acceso a la herramienta de reembolso»
Bueno: «Permitir que el agente de reembolsos del usuario acceda a la herramienta de reembolso»
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 el importe sea razonable»
Bueno: «Permitir transferencias cuando el importe sea inferior a 10 000$»
Error 4: Faltan condiciones
Malo: «Permitir a los usuarios con scope admin:write actualizar la cobertura»
Bueno: «Permite a los usuarios con el alcance admin:write actualizar la cobertura cuando la póliza esté activa y el tipo de cobertura sea de responsabilidad civil o de colisión»
Error 5: Lógica poco clara
Malo: «Permitir cuando A o B y C»
Bueno: «Permitir cuando (A o B) y C» o «Permitir cuando A o (B y C)»
