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.

Ejemplos de políticas

Esta sección proporciona ejemplos completos de las políticas 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 para sus propias aplicaciones.

Herramientas disponibles

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

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, un código 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 a todos los directores obtener la póliza y conocer el estado de la reclamación.

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 que se permite realizar múltiples acciones utilizando el in operador. En lugar de escribir políticas independientes para cada operación de lectura, una sola política otorga acceso a varias acciones relacionadas. Esto es ú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 a los directores cuyo alcance incluya «seguro:reclamación» presentar reclamaciones.

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 {
  principal.hasTag("scope") &&
  principal.getTag("scope") like "*insurance:claim*"
};

Explicación: Esta política demuestra la validación del alcance 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 alcance flexibles como «insurance:claim», «insurance:claim:write» o «admin insurance:claim».

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

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

Lenguaje natural: Impida que los directores actualicen la cobertura, a menos que el director desempeñe la función de «ajustador principal» 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 muestra la unless cláusula, que invierte la lógica de las condiciones. La prohibición se aplica a menos que el usuario tenga una de las funciones especificadas. Esto es ú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 usar la lógica OR para varios valores aceptables.

Lenguaje natural: permita a los directores presentar 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 cómo acceder a los parámetros de entrada de la herramienta mediante comprobaciones de igualdad de cadenas context.input y cadenas con la lógica OR. El has operador primero verifica la existencia del campo antes de acceder a él, lo que evita errores cuando faltan campos opcionales.

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

Esta política demuestra cómo hacer cumplir las reglas empresariales exigiendo campos opcionales.

Lenguaje natural: Impida 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 cómo hacer cumplir 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. Aquí se 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: permita a los directores con el nombre de usuario «Clare» actualizar 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 la coincidencia exacta de cadenas. En combinación con la póliza 3, esto crea una autorización en dos partes: los usuarios deben tener el nombre de usuario «agente de seguros» Y tener la función de «ajustador sénior» o «administrador» para actualizar la cobertura.

Póliza 7: Coincidencia de patrones con valores similares

Esta política demuestra la flexibilidad de la coincidencia de patrones mediante caracteres comodín para el control de acceso por categorías.

Lenguaje natural: permita a los directores calcular la prima cuando el tipo de cobertura contenga la palabra «automática».

Política 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 flexible de patrones con el like operador. El comodín * coincide con cualquier carácter, por lo que «automático», «responsabilidad automática», «automático integral» o «colisión automática» serían todos iguales. 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: permita a los directores actualizar la cobertura cuando el tipo de cobertura sea de responsabilidad civil o colisión y se proporcione un nuevo límite.

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 {
  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 escalonada: quién puede actualizar (Política 6) y qué puede actualizar (Política 8).

Comprender la semántica de las autorizaciones

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

Denegación predeterminada

Si ninguna política permite explícitamente una acción, se deniega. Por ejemplo, un usuario que no tenga el alcance «seguro:reclamación» no puede presentar reclamaciones aunque ninguna póliza lo prohíba explícitamente.

Prohibir triunfos

Si alguna de las políticas de prohibición coincide, la solicitud se denegará aunque las políticas de autorización también coincidan. La política 5 (prohibir sin descripción) prevalece sobre la política 2 (permitir con alcance) cuando falta la descripción.

Estratificació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 siguientes: ser agente de seguros (póliza 6), tener la función de ajustador sénior o gerente (póliza 3) y actualizar la responsabilidad en caso de colisión (póliza 8).

Escenarios de prueba

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

IAM-based ejemplos de autorización

Cuando su AgentCore Gateway usa la autenticación AWS_IAM en lugar de OAuth, el principal en las políticas de Cedar se representa como. AgentCore::IamEntity En el caso de las personas que llaman mediante funciones asumidas, el identificador de entidad de Cedar utiliza el formatoarn:aws:sts::<account>:assumed-role/<role-name>, lo que permite realizar coincidencias y patrones estables. 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. Úsala cuando solo necesites verificar que las personas que llaman no tienen restricciones adicionales. IAM-authenticated

Role-based restricción con una coincidencia exacta del principal

Restrinja el acceso a la herramienta a las personas que llamen 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 identificador 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 la coincidencia de patrones

También se 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 una when cláusulaprincipal ==, pero se utiliza. La coincidencia de patrones es útil cuando necesitas una coincidencia más amplia, como hacer coincidir 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 el identificador de esa 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 qué herramientas puede usar 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 diferentes agentes tienen diferentes funciones de IAM y deben tener diferentes niveles de acceso a las herramientas. Cada política se usa 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 comparación de los principales de IAM con la validación de las entradas de la herramienta:

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 suponiendo que provienen RefundProcessorRole de la cuenta especificada pueden procesar los reembolsos y solo cuando el importe del reembolso sea inferior a 1000$.

Prohibir cuentas específicas

Impide 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 prohíbe que todas las personas que llamen desde una cuenta de un proveedor externo (444455556666) realicen eliminaciones administrativas. Debido a la semántica en la que se prohíbe ganar, esta política prevalece sobre cualquier política de permisos.

Prohíba funciones específicas en operaciones delicadas

Impida que las personas que llamen utilizando 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 prohíbe que las personas que llamen utilicen el realicen operaciones de escritura, independientemente ReadOnlyAgentRole de las políticas de permisos que, de otro modo, podrían permitirlas.