Exemples de politiques

Cette section fournit des exemples complets de politiques d'autorisation de Cedar pour un système de gestion des assurances. Ces exemples illustrent les différentes fonctionnalités du langage Cedar et les modèles d'autorisation que vous pouvez adapter à vos propres applications.

Outils disponibles

L'API Insurance fournit cinq outils pour gérer les polices d'assurance et les réclamations :

Politiques d'autorisation

Les politiques suivantes présentent les différentes fonctionnalités linguistiques et modèles d'autorisation de Cedar. Chaque politique inclut une description en langage naturel, un code Cedar et une explication détaillée.

Politique 1 : Multi-action permis

Cette politique explique comment accorder l'accès à plusieurs actions connexes à l'aide d'une seule déclaration de politique.

Langage naturel : Permettez à tous les principaux d'obtenir la police d'assurance et le statut de la réclamation.

Politique sur le cèdre :

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"
);

Explication : Cette politique illustre les autorisations à actions multiples utilisant l'inopérateur. Au lieu d'écrire des politiques distinctes pour chaque opération de lecture, une seule politique donne accès à plusieurs actions connexes. Cela est utile pour regrouper des opérations similaires qui partagent les mêmes exigences d'autorisation.

Politique 2 : Scope-based autorisation

Cette politique indique comment utiliser les étendues OAuth pour contrôler l'accès à des opérations spécifiques.

Langage naturel : autorisez les mandants dont le champ d'application contient « insurance:claim » à déposer des réclamations.

Politique sur le cèdre :

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*"
};

Explication : Cette politique illustre la validation de la portée OAuth à l'aide de balises. La hasTag méthode vérifie si la balise existe et getTag récupère sa valeur. L'likeopérateur utilisant des caractères génériques (*) effectue une correspondance de modèles, autorisant des formats de portée flexibles tels que « insurance:claim », « insurance:claim:write » ou « admin insurance:claim ».

Politique 3 : Role-based autorisation avec sauf

Cette politique illustre l'utilisation de la unless clause pour créer des exceptions aux restrictions.

Langage naturel : Empêchez le directeur de mettre à jour la couverture, sauf si le directeur a le rôle d' « expert principal » ou de « directeur ».

Politique sur le cèdre :

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")
};

Explication : Cette politique illustre la unless clause, qui inverse la logique des conditions. L'interdiction s'applique sauf si l'utilisateur possède l'un des rôles spécifiés. Cela est utile pour créer des exceptions aux restrictions. La politique indique également la logique OR pour vérifier plusieurs valeurs acceptables.

Politique 4 : Égalité des chaînes avec la logique OR

Cette politique indique comment valider les paramètres d'entrée et utiliser la logique OR pour plusieurs valeurs acceptables.

Langage naturel : autorisez les mandants à déposer des réclamations lorsque le type de réclamation est lié à la santé, aux biens ou à l'auto.

Politique sur le cèdre :

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")
};

Explication : Cette politique explique l'accès aux paramètres d'entrée des outils via la logique OR context.input et les contrôles d'égalité des chaînes avec la logique OR. L'hasopérateur vérifie d'abord que le champ existe avant d'y accéder, afin d'éviter les erreurs lorsque des champs facultatifs sont manquants.

Politique 5 : Vérification de l'existence des champs

Cette politique explique comment appliquer les règles commerciales en exigeant des champs facultatifs.

Langage naturel : Empêchez les mandants de déposer des réclamations à moins qu'une description ne soit fournie.

Politique sur le cèdre :

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
};

Explication : Cette politique montre comment appliquer les champs obligatoires pour les paramètres facultatifs. Le champ de description est facultatif dans le schéma de l'outil, mais cette politique le rend obligatoire en interdisant les demandes qui ne l'incluent pas. Cela montre comment les politiques peuvent ajouter des règles métier au-delà de la validation du schéma.

Politique 6 : Username-based autorisation

Cette politique indique comment accorder l'accès en fonction d'identités utilisateur spécifiques.

Langage naturel : autorisez les principaux dont le nom d'utilisateur est « Clare » à mettre à jour leur couverture.

Politique sur le cèdre :

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"
};

Explication : Cette politique illustre l'autorisation basée sur le nom d'utilisateur en utilisant une correspondance de chaînes exacte. Combiné à la politique 3, cela crée une autorisation en deux parties : les utilisateurs doivent avoir le nom d'utilisateur « agent d'assurance » ET avoir le rôle « expert en sinistres » ou « directeur » pour mettre à jour la couverture.

Politique 7 : Correspondance des modèles avec des likes

Cette politique illustre une correspondance flexible des modèles à l'aide de caractères génériques pour le contrôle d'accès basé sur les catégories.

Langage naturel : autorisez les mandants à calculer la prime lorsque le type de couverture contient « auto ».

Politique sur le cèdre :

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*"
};

Explication : Cette politique illustre une correspondance flexible avec l'likeopérateur. Le joker * correspond à tous les caractères, donc « auto », « responsabilité automatique », « automatique complète » ou « collision automatique » correspondraient tous. Cela est utile lorsque vous souhaitez faire correspondre une catégorie de valeurs plutôt que des chaînes exactes.

Politique 8 : Conditions combinées avec AND

Cette politique montre comment combiner plusieurs conditions pour créer des règles d'autorisation complexes.

Langage naturel : autorisez les mandants à mettre à jour la couverture lorsque le type de couverture est la responsabilité civile ou la collision et qu'une nouvelle limite est fournie.

Politique sur le cèdre :

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")
};

Explication : Cette politique illustre la combinaison de plusieurs conditions avec la logique AND. Les trois conditions doivent être vraies : coverageType doit exister, newLimit doit exister et coverageType doit être soit « responsabilité », soit « collision ». Cela fonctionne avec la Politique 6 pour créer des autorisations à plusieurs niveaux : qui peut mettre à jour (Politique 6) et ce qu'ils peuvent mettre à jour (Politique 8).

Comprendre la sémantique des autorisations

Ces politiques illustrent la sémantique clé des autorisations de Cedar :

Refus par défaut

Si aucune politique n'autorise explicitement une action, celle-ci est refusée. Par exemple, un utilisateur n'ayant pas le champ « insurance:claim » ne peut pas déposer de réclamation même si aucune politique ne l'interdit explicitement.

Interdire les victoires

Si une politique d'interdiction correspond, la demande est refusée même si les politiques d'autorisation correspondent également. La politique 5 (interdire sans description) remplace la politique 2 (autorisation avec champ d'application) lorsque la description est absente.

Superposition des politiques

Plusieurs politiques peuvent s'appliquer à la même demande :

Pour qu'une demande soit acceptée, elle doit satisfaire aux trois critères suivants : être agent d'assurance (police 6), avoir un rôle d'expert principal ou de gestionnaire (politique 3) et mettre à jour la responsabilité en cas de collision (police 8).

Scénarios de test

Les scénarios suivants montrent comment les politiques fonctionnent ensemble dans la pratique :

IAM-based exemples d'autorisation

Lorsque votre AgentCore passerelle utilise l'authentification AWS_IAM au lieu d'OAuth, le principal dans les politiques de Cedar est représenté par. AgentCore::IamEntity Pour les appelants qui s'authentifient via des rôles assumés, l'identifiant d'entité Cedar utilise le formatarn:aws:sts::<account>:assumed-role/<role-name>, permettant une principal == correspondance stable et une correspondance de principal.id modèles.

Permis d'entité IAM de base

Cette politique permet à tout IAM-authenticated appelant d'utiliser un outil spécifique :

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"
);

Explication : Il s'agit de la forme la plus simple de politique IAM. Il permet à tout appelant authentifié via AWS_IAM d'appeler l'outil get_order. Utilisez-le uniquement lorsque vous devez vérifier que les appelants ne sont IAM-authenticated pas soumis à des restrictions supplémentaires.

Role-based restriction avec correspondance principale exacte

Limitez l'accès à l'outil aux appelants utilisant un rôle IAM spécifique en utilisant : 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"
);

Explication : L'ID d'entité Cedar pour les rôles assumés estarn:aws:sts::<account>:assumed-role/<role-name>. Cela permet une principal == correspondance stable quel que soit le nom de session utilisé lors de l'authentification.

Role-based restriction avec correspondance de modèles

Vous pouvez également utiliser principal.id like pour des modèles de correspondance plus larges :

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"
};

Explication : Cela permet d'obtenir le même résultat que, principal == mais en utilisant une when clause. La correspondance de modèles est utile lorsque vous avez besoin d'une correspondance plus large, par exemple pour faire correspondre n'importe quel rôle dans un compte (principal.id like "arn:aws:sts::111122223333:assumed-role/*").

Account-based restriction

Limitez l'accès à l'outil aux appelants provenant de AWS comptes spécifiques :

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:*"
};

Explication : Le modèle *:111122223333 : * correspond à n'importe quel ARN contenant cet ID de compte. Cela restreint l'accès aux appelants à partir du AWS compte spécifié uniquement.

Multi-agent fédération

Lorsque plusieurs agents dotés de rôles IAM différents accèdent à la même passerelle, créez des politiques distinctes pour contrôler les outils que chaque agent peut utiliser :

// 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"
);

Explication : Ce modèle est utile pour les architectures multi-agents dans lesquelles les différents agents ont des rôles IAM différents et doivent avoir différents niveaux d'accès aux outils. Chaque politique est utilisée principal == avec l'ID d'entité du rôle spécifique. La tools/list réponse de chaque agent inclut uniquement les outils qu'il est autorisé à utiliser.

IAM avec validation des entrées

Combinez la correspondance principale IAM avec la validation des entrées d'outils :

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
};

Explication : Cette politique combine la correspondance exacte des principaux avec la validation des entrées. Seuls les appelants utilisant le RefundProcessorRole compte indiqué peuvent traiter les remboursements, et uniquement lorsque le montant du remboursement est inférieur à 1 000$.

Interdire certains comptes

Empêchez les appelants de AWS comptes spécifiques d'accéder à des outils sensibles :

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:*"
};

Explication : Cette politique d'interdiction empêche tous les appelants provenant d'un compte fournisseur tiers (444455556666) d'effectuer des suppressions administratives. En raison de la sémantique prohibid-wins, cela a priorité sur toutes les politiques d'autorisation.

Interdire les rôles spécifiques aux opérations sensibles

Empêchez les appelants utilisant des rôles en lecture seule d'effectuer des opérations d'écriture :

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"
);

Explication : Cette politique d'interdiction empêche les appelants utilisant le d'effectuer ReadOnlyAgentRole des opérations d'écriture, quelles que soient les politiques d'autorisation qui pourraient autrement les autoriser.