Ejemplos de políticas

Esta sección proporciona ejemplos completos de pólizas de autorización de Cedar para un sistema de administración de seguros. Estos ejemplos muestran varias características del lenguaje Cedar y patrones de autorización que puede adaptar a sus propias aplicaciones.

Herramientas disponibles

La API de seguros proporciona cinco herramientas para gestionar las pólizas de seguro y las reclamaciones:

Políticas de autorización

Las siguientes políticas muestran varias características y patrones de autorización del lenguaje Cedar. Cada política incluye una descripción en lenguaje natural, el código de Cedar y una explicación detallada.

Política 1: Multi-action permiso

Esta política demuestra cómo conceder acceso a múltiples acciones relacionadas mediante una única declaración de política.

Lenguaje natural: permita que todos los directores obtengan una póliza y obtengan el estado de las reclamaciones.

Política de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action in [
    AgentCore::Action::"InsuranceAPI___get_policy",
    AgentCore::Action::"InsuranceAPI___get_claim_status"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
);

Explicación: Esta política demuestra los permisos de acción múltiple que utilizan el in operador. En lugar de escribir políticas independientes para cada operación de lectura, una sola política permite el acceso a múltiples acciones relacionadas. Esto resulta útil para agrupar operaciones similares que comparten los mismos requisitos de autorización.

Política 2: autorización Scope-based

Esta política muestra cómo usar los ámbitos de OAuth para controlar el acceso a operaciones específicas.

Lenguaje natural: permite que las entidades principales cuyo ámbito contenga la expresión «seguro: reclamación» presenten reclamaciones.

Póliza de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("scope") &&
  principal.getTag("scope") like "*insurance:claim*"
};

Explicación: Esta política demuestra la validación del ámbito de OAuth mediante etiquetas. El hasTag método comprueba si la etiqueta existe y getTag recupera su valor. El like operador con caracteres comodín (*) realiza la coincidencia de patrones, lo que permite formatos de ámbito flexibles como «insurance:claim», «insurance:claim:write» o «admin insurance:claim».

Política 3: autorización con menos Role-based

Esta política demuestra el uso de la unless cláusula para crear excepciones a las restricciones.

Lenguaje natural: impide que los directores actualicen la cobertura, a menos que el director desempeñe la función de «ajustador sénior» o «gerente».

Política de cedro:

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  principal.hasTag("role") &&
  (principal.getTag("role") == "senior-adjuster" || principal.getTag("role") == "manager")
};

Explicación: Esta política demuestra la unless cláusula, que invierte la lógica de la condición. La prohibición se aplica a menos que el usuario tenga uno de los roles especificados. Esto resulta útil para crear excepciones a las restricciones. La política también muestra la lógica OR para comprobar varios valores aceptables.

Política 4: Igualdad de cadenas con la lógica OR

Esta política muestra cómo validar los parámetros de entrada y utilizar la lógica OR para varios valores aceptables.

Lenguaje natural: permita que los directores presenten reclamaciones cuando el tipo de reclamación sea de salud, propiedad o automóvil.

Política de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has claimType &&
  (context.input.claimType == "health" ||
   context.input.claimType == "property" ||
   context.input.claimType == "auto")
};

Explicación: Esta política demuestra el acceso a los parámetros de entrada de la herramienta mediante comprobaciones de igualdad de cadenas context.input y mediante la lógica OR. El has operador primero verifica que el campo existe antes de acceder a él, lo que evita errores cuando faltan campos opcionales.

Política 5: Verificación de la existencia del campo

Esta política demuestra cómo hacer cumplir las normas empresariales mediante la exigencia de campos opcionales.

Lenguaje natural: impide que los directores presenten reclamaciones a menos que se proporcione una descripción.

Política de cedro:

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  context.input has description
};

Explicación: Esta política demuestra la aplicación de los campos obligatorios para los parámetros opcionales. El campo de descripción es opcional en el esquema de la herramienta, pero esta política lo hace obligatorio al prohibir las solicitudes que no lo incluyan. Esto muestra cómo las políticas pueden añadir reglas empresariales más allá de la validación del esquema.

Política 6: Username-based autorización

Esta política muestra cómo conceder el acceso en función de las identidades de usuario específicas.

Lenguaje natural: permite que los directores con el nombre de usuario «Clare» actualicen la cobertura.

Política de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "Clare"
};

Explicación: Esta política demuestra la autorización basada en el nombre de usuario mediante una coincidencia exacta de cadenas. En combinación con la Política 3, se crea una autorización en dos partes: los usuarios deben tener el nombre de usuario «agente de seguros» y tener el rol de «perito superior» o «gerente» para actualizar la cobertura.

Política 7: Patrón que coincide con un patrón similar

Esta política demuestra la coincidencia flexible de patrones mediante el uso de caracteres comodín para el control de acceso basado en categorías.

Lenguaje natural: permite que los directores calculen la prima cuando el tipo de cobertura contenga «auto».

Póliza de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___calculate_premium",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input.coverageType like "*auto*"
};

Explicación: Esta política demuestra una coincidencia de patrones flexible con el like operador. El comodín * coincide con cualquier carácter, por lo que «auto», «responsabilidad automática», «auto integral» o «colisión automática» coincidirían todos. Esto resulta útil cuando se quiere hacer coincidir una categoría de valores en lugar de cadenas exactas.

Política 8: Condiciones combinadas con AND

Esta política muestra cómo combinar varias condiciones para crear reglas de autorización complejas.

Lenguaje natural: permite a los directores actualizar la cobertura cuando el tipo de cobertura sea de responsabilidad civil o colisión y se establezca un nuevo límite.

Póliza de cedro:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input has newLimit &&
  (context.input.coverageType == "liability" || context.input.coverageType == "collision")
};

Explicación: Esta política demuestra la combinación de varias condiciones con la lógica AND. Las tres condiciones deben cumplirse: CoverageType debe existir, NewLimit debe existir y CoverageType debe ser «responsabilidad» o «colisión». Esto funciona con la Política 6 para crear una autorización por niveles: quién puede actualizar (Política 6) y qué puede actualizar (Política 8).

Entender la semántica de la autorización

Estas políticas demuestran la semántica clave de autorización de Cedar:

Denegación predeterminada

Si ninguna política permite una acción de forma explícita, se deniega. Por ejemplo, un usuario que no esté incluido en el ámbito de «seguro: reclamación» no puede presentar reclamaciones aunque ninguna póliza lo prohíba explícitamente.

Forbid gana

Si alguna política de prohibición coincide, la solicitud se deniega incluso si las políticas de permisos también coinciden. La política 5 (prohibir sin descripción) anula la política 2 (permiso con alcance) cuando falta una descripción.

Nivelación de políticas

Se pueden aplicar varias políticas a la misma solicitud:

Para que una solicitud tenga éxito, debe cumplir con los tres requisitos: ser agente de seguros (póliza 6), ocupar un puesto de perito o gerente (política 3) y actualizar la responsabilidad o colisión (política 8).

Escenarios de prueba

Los siguientes escenarios demuestran cómo las pólizas funcionan juntas en la práctica:

IAM-based ejemplos de autorización

Cuando su AgentCore Gateway utiliza la autenticación AWS_IAM en lugar de OAuth, el principio de las políticas de Cedar se representa como. AgentCore::IamEntity Para las personas que llaman y se autentican mediante funciones falsas, el ID de la entidad de Cedar utiliza el formato, lo que permite una coincidencia estable y una coincidencia de arn:aws:sts::<account>:assumed-role/<role-name> patrones. principal == principal.id

Permiso básico de entidad de IAM

Esta política permite a cualquier IAM-authenticated persona que llame utilizar una herramienta específica:

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

Explicación: Esta es la forma más sencilla de política de IAM. Permite a cualquier persona que llame autenticada mediante AWS_IAM llamar a la herramienta get_order. Úselo cuando solo necesite verificar que las personas que llaman no tengan restricciones adicionales. IAM-authenticated

Role-based restricción con una coincidencia exacta de los principales

Restrinja el acceso a la herramienta a las personas que llaman utilizando una función de IAM específica mediante: principal ==

permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/MyServiceRole",
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

Explicación: El ID de entidad de Cedar para los roles asumidos es. arn:aws:sts::<account>:assumed-role/<role-name> Esto permite una principal == coincidencia estable independientemente del nombre de sesión utilizado durante la autenticación.

Role-based restricción con coincidencia de patrones

También puede utilizar principal.id like para patrones de coincidencia más amplios:

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "arn:aws:sts::111122223333:assumed-role/MyServiceRole"
};

Explicación: con esto se obtiene el mismo resultado que con una when cláusulaprincipal ==, pero se utiliza. La coincidencia de patrones es útil cuando se necesita una coincidencia más amplia, como la coincidencia de cualquier rol en una cuenta (principal.id like "arn:aws:sts::111122223333:assumed-role/*").

Account-based restricción

Restrinja el acceso a la herramienta a las personas que llaman desde AWS cuentas específicas:

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "*:111122223333:*"
};

Explicación: El patrón *:111122223333: * coincide con cualquier ARN que contenga ese ID de cuenta. Esto restringe el acceso únicamente a las personas que llaman desde la cuenta especificada. AWS

Multi-agent federación

Cuando varios agentes con diferentes funciones de IAM accedan a la misma puerta de enlace, cree políticas independientes para controlar las herramientas que puede utilizar cada agente:

// Agent A can only read orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentA-Role",
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

// Agent B can read and process orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentB-Role",
  action in [
    AgentCore::Action::"OrderAPI___get_order",
    AgentCore::Action::"OrderAPI___process_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

Explicación: Este patrón es útil para arquitecturas con varios agentes, en las que distintos agentes tienen distintas funciones de IAM y deben tener distintos niveles de acceso a las herramientas. Cada política se utiliza principal == con el ID de entidad del rol específico. La tools/list respuesta de cada agente solo incluye las herramientas que están autorizados a usar.

IAM con validación de entradas

Combine la coincidencia principal de IAM con la validación de las entradas de las herramientas:

permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/RefundProcessorRole",
  action == AgentCore::Action::"RefundAPI___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  context.input has amount &&
  context.input.amount < 1000
};

Explicación: Esta política combina la coincidencia exacta de los principales con la validación de las entradas. Solo las personas que llamen RefundProcessorRole desde la cuenta especificada pueden procesar los reembolsos y solo cuando el importe del reembolso sea inferior a 1000$.

Prohíbe cuentas específicas

Impida que las personas que llaman desde AWS cuentas específicas accedan a herramientas confidenciales:

forbid(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"AdminAPI___delete_resource",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/admin-gateway"
)
when {
  principal.id like "*:444455556666:*"
};

Explicación: Esta política de prohibición impide que todas las personas que llaman desde una cuenta de un proveedor externo (444455556666) realicen eliminaciones administrativas. Debido a la semántica de «no ganar», esta política prevalece sobre cualquier política de permisos.

Prohíba funciones específicas en operaciones delicadas

Impida que las personas que llaman con funciones de solo lectura realicen operaciones de escritura:

forbid(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/ReadOnlyAgentRole",
  action in [
    AgentCore::Action::"OrderAPI___process_order",
    AgentCore::Action::"OrderAPI___cancel_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

Explicación: Esta política de prohibición impide que las personas que llaman a través de ella realicen operaciones ReadOnlyAgentRole de escritura, independientemente de las políticas de permisos que, de otro modo, podrían permitirlas.