Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 et modèles d'autorisation du langage Cedar que vous pouvez adapter à vos propres applications.

Outils disponibles

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

Politiques d'autorisation

Les politiques suivantes présentent les différentes fonctionnalités et modèles d'autorisation du langage Cedar. Chaque politique comprend 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 directeurs d'obtenir une police d'assurance et de connaître l'état de la réclamation.

Politique en matière de 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 décrit 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. Ceci est utile pour regrouper des opérations similaires qui partagent les mêmes exigences d'autorisation.

Politique 2 : Scope-based autorisation

Cette politique explique 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 en matière de 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 avec des caractères génériques (*) effectue une correspondance de modèles, permettant ainsi des formats de portée flexibles tels que « insurance:claim », « insurance:claim:write » ou « admin insurance:claim ».

Politique 3 : Role-based autorisation à moins que

Cette politique montre comment utiliser la unless clause pour créer des exceptions aux restrictions.

Langage naturel : Empêcher les directeurs d'école de mettre à jour la couverture, sauf si le rôle du directeur est « ajusteur principal » ou « directeur ».

Politique en matière de 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 affiche également une logique OR pour vérifier plusieurs valeurs acceptables.

Règle 4 : Égalité des chaînes avec la logique OR

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

Langage naturel : autorisez les directeurs à déposer des réclamations lorsque le type de réclamation concerne la santé, les biens ou l'automobile.

Politique en matière de 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 de l'outil via context.input des 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, évitant ainsi les erreurs lorsque des champs facultatifs sont manquants.

Politique 5 : Vérification de l'existence sur le terrain

Cette politique explique comment appliquer les règles métier en exigeant des champs facultatifs.

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

Politique en matière de 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 explique l'application des 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 requêtes qui ne l'incluent pas. Cela montre comment les politiques peuvent ajouter des règles métier au-delà de la validation des schémas.

Politique 6 : Username-based autorisation

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

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

Politique en matière de 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 décrit l'autorisation basée sur le nom d'utilisateur en utilisant une correspondance de chaîne 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 « ajusteur principal » ou « responsable » pour mettre à jour la couverture.

Règle 7 : Correspondance entre un motif et un similaire

Cette politique met en œuvre une correspondance flexible des modèles à l'aide de caractères génériques pour le contrôle d'accès par catégorie.

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

Politique en matière de 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 démontre une correspondance flexible des modèles avec l'likeopérateur. Le caractère générique * correspond à tous les caractères, donc « auto », « auto-liability », « comprehensive-auto » ou « auto-collision » correspondraient tous. Ceci 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 explique comment combiner plusieurs conditions pour créer des règles d'autorisation complexes.

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

Politique en matière de 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 montre 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 « responsabilité » ou « collision ». Cela fonctionne avec la Politique 6 pour créer une autorisation à plusieurs niveaux : qui peut mettre à jour (Politique 6) et ce qu'il peut mettre à jour (Politique 8).

Comprendre la sémantique des autorisations

Ces politiques présentent la sémantique d'autorisation clé de Cedar :

Refus par défaut

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

Interdire les victoires

Si l'une des politiques 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 manquante.

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 (police 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 supposés, l'ID d'entité Cedar utilise ce formatarn:aws:sts::<account>:assumed-role/<role-name>, ce qui permet 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 lorsque vous devez uniquement vérifier que les appelants ne sont IAM-authenticated pas soumis à des restrictions supplémentaires.

Role-based restriction avec correspondance principale exacte

Restreignez l'accès aux outils 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 motifs

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 utilise une when clause. La correspondance des 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

Restreignez l'accès à l'outil aux appelants depuis des 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 identifiant de compte. Cela limite 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 différents agents ont des rôles IAM différents et devraient avoir différents niveaux d'accès aux outils. Chaque politique utilise principal == 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 supposant que le compte indiqué RefundProcessorRole provient du compte spécifié peuvent traiter les remboursements, et uniquement lorsque le montant du remboursement est inférieur à 1 000$.

Interdire des comptes spécifiques

Empêchez les appelants provenant 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 des gains interdits, cela a priorité sur toutes les politiques d'autorisation.

Interdire des rôles spécifiques à des 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.