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.

Rédaction de politiques en langage naturel

Policy in AgentCore sélectionnera automatiquement la région optimale de votre zone géographique pour traiter vos demandes d'inférence effectuées via le service de création de politiques. Cela maximise les ressources de calcul disponibles, la disponibilité des modèles et offre la meilleure expérience client. Vos données ne seront stockées que dans la région d'origine de la demande, mais les demandes de saisie et les résultats de sortie peuvent être traités en dehors de cette région. Toutes les données sont transmises chiffrées sur l’ensemble du réseau sécurisé d’Amazon.

Policy in AgentCore acheminera en toute sécurité vos demandes d'inférence vers les ressources de calcul disponibles dans la zone géographique d'origine de la demande, comme suit :

Vue d’ensemble

Cedar fournit un contrôle d'accès précis, mais nécessite l'apprentissage de la syntaxe formelle. NL2Cedar vous permet de :

Exemple

La politique de remboursement de la section précédente peut être exprimée en langage naturel :

Langage naturel :

Autoriser le principal dont le nom d'utilisateur est « agent de remboursement » à traiter les remboursements lorsque le montant du remboursement est inférieur à 500$.

Se transforme en cèdre :

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

Effets politiques

Les politiques d'autorisation ont deux effets possibles : autoriser et interdire.

Politiques relatives aux permis

Les politiques d'autorisation spécifient ce que les utilisateurs peuvent faire :

Politiques d'interdiction

Les politiques d'interdiction spécifient ce que les utilisateurs ne peuvent pas faire :

Sémantique des autorisations

Il est essentiel de comprendre comment Cedar évalue les politiques pour rédiger des règles d'autorisation efficaces. Le cèdre suit trois principes fondamentaux :

Pourquoi utiliser des politiques d'interdiction si tout est refusé par défaut ?

Les politiques d'interdiction garantissent que des actions spécifiques ne peuvent pas être autorisées par erreur. Même si quelqu'un rédige une politique d'autorisation plus large, la politique d'interdiction prévaut et bloque l'accès.

Exemple de scénario :

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

Résultat : les utilisateurs peuvent afficher les résultats de sensibilité faible et moyenne (l'autorisation s'applique), mais les résultats de sensibilité élevée sont toujours bloqués (interdiction de gagner).

Utilisez des politiques d'interdiction pour :

Éléments de stratégie

Les politiques d'autorisation nécessitent trois éléments clés :

Spécification principale

Le principal identifie les utilisateurs, les rôles ou les groupes auxquels la politique s'applique.

Expressions flexibles :

Soyez précis en ce qui concerne l'identité :

Incomplet : ❌ « Autoriser le traitement des remboursements inférieurs à 500$ »

Complet : ✓ « Autoriser l'agent de remboursement à traiter les remboursements inférieurs à 500$ »

Spécification de l'action

Le « quoi » identifie les opérations, les outils ou les actions contrôlés par la politique.

Verbes d'action flexibles :

Soyez précis à propos de l'outil :

Vague : ❌ « Autoriser les utilisateurs à accéder aux modèles »

Effacer : ✓ « Autoriser l'équipe chargée de la science des données à accéder au modèle analytique »

Spécification de l'état

Le « quand » indique dans quelles circonstances la politique s'applique.

Expressions conditionnelles flexibles :

Soyez précis en ce qui concerne les conditions :

Vague : ❌ « Autoriser les virements lorsque le montant est raisonnable »

Précis : ✓ « Autoriser les virements lorsque le montant est inférieur à 10 000$ »

Exemples de politiques

Les exemples suivants montrent comment structurer des politiques en matière de langage naturel avec des principes, des actions et des conditions clairs.

Exemple 1 : User-Based politique simple

Autorisez l'agent de remboursement de l'utilisateur à traiter les remboursements lorsque le montant est inférieur à 500$.

Éléments :

Exemple 2 : Role-Based avec plusieurs conditions

Autorisez les utilisateurs ayant le rôle d'agent d'assurance à mettre à jour la couverture lorsque le type de couverture est responsabilité ou collision et que la police est active.

Éléments :

Exemple 3 : Scope-Based Accès

Autorisez les utilisateurs de scope travel:book à créer des réservations de vol lorsque la région n'est pas l'UE et que le produit est éligible.

Éléments :

Exemple 4 : Toutes les personnes soumises à des contraintes

Autorisez tous les utilisateurs à consulter les résultats du modèle lorsque la sensibilité des données est faible ou moyenne et que le type de résultat est le score de risque.

Éléments :

Syntaxe des conditions

C'est dans ces conditions que les politiques deviennent souvent ambiguës. Voici comment rédiger des conditions claires et vérifiables.

Comparaisons numériques

De bons exemples :

Évitez les termes vagues :

Correspondance de chaînes

Correspondance exacte :

Plusieurs options :

Correspondance des motifs :

Négation :

Conditions booléennes

Contrôles directs :

Négation :

Existence sur le terrain

Champs obligatoires :

Combiner les conditions

Les véritables politiques nécessitent souvent de multiples conditions. Utilisez des connecteurs logiques clairs.

ET logique (tout doit être vrai)

Utilisez des mots tels que : « et », « également », « en plus », « pendant », « avec »

Exemple :

Autorisez les candidatures lorsque la région est située aux États-Unis, que le produit est éligible et que le territoire est actif.

OU Logique (au moins une doit être vraie)

Utilisez des mots tels que : « ou », « alternativement », « soit »

Exemple :

Autorisez l'approbation lorsque la réclamation dépasse 10 000 000$ ou que le niveau de risque est élevé ou critique.

Logique complexe

Pour les conditions complexes, utilisez une structure claire :

Exemple :

Autoriser la finalisation lorsque l'étape du flux de travail est terminée ou approuvée, que le statut de conformité est passé et que l'autorité est le responsable ou le directeur.

Pièges courants

Évitez ces erreurs courantes lors de la rédaction de politiques en langage naturel afin de vous assurer qu'elles sont correctement converties en syntaxe Cedar.

Erreur 1 : principes vagues

Mauvais : « Autoriser l'accès à l'outil de remboursement »

Bien : « Autoriser l'agent de remboursement de l'utilisateur à accéder à l'outil de remboursement »

Erreur 2 : actions ambiguës

Mauvais : « Autoriser les utilisateurs à accéder aux données »

Bien : « Autoriser les utilisateurs à consulter les dossiers des patients »

Erreur 3 : conditions subjectives

Mauvais : « Autoriser les transferts lorsque le montant est raisonnable »

Bien : « Autoriser les virements lorsque le montant est inférieur à 10 000$ »

Erreur 4 : Conditions manquantes

Mauvais : « Autoriser les utilisateurs avec scope admin:write à mettre à jour la couverture »

Bien : « Autoriser les utilisateurs ayant scope admin:write à mettre à jour la couverture lorsque la police est active et que le type de couverture est responsabilité ou collision »

Erreur 5 : logique peu claire

Mauvais : « Autoriser quand A ou B et C »

Bien : « Autoriser quand (A ou B) et C » ou « Autoriser quand A ou (B et C) »