Politiques de rédaction 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 permet d'optimiser les ressources informatiques disponibles, la disponibilité des modèles et d'offrir la meilleure expérience client. Vos données resteront stockées uniquement dans la région d'origine de la demande. Toutefois, 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 de manière sécurisée vos demandes d'inférence vers les ressources informatiques disponibles dans la zone géographique d'origine de la demande, comme suit :

Présentation de

Cedar fournit un contrôle d'accès précis, mais nécessite l'apprentissage d'une 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 mandant ayant le nom d'utilisateur « 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 des politiques

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

Politiques relatives aux permis

Les politiques d'autorisation précisent 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

Comprendre comment Cedar évalue les politiques est essentiel 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 visualiser les résultats de sensibilité faible ou moyenne (autorisation applicable), 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 de moins de 500$ »

Terminé : ✓ « Autoriser l'agent de remboursement à traiter les remboursements de moins de 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 : ✓ « Permettre à l'équipe de science des données d'accéder au modèle d'analyse »

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 transferts lorsque le montant est inférieur à 10 000$ »

Exemples de politiques

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

Exemple 1 : User-Based Politique simple

Autoriser 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

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

Éléments :

Exemple 3 : Scope-Based Accès

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

Éléments :

Exemple 4 : Tout le monde soumis à des contraintes

Permettez à tous les utilisateurs de visualiser les résultats du modèle lorsque la sensibilité des données est faible ou moyenne et que le type de résultat est un 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 testables.

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 :

Combinaison de conditions

Les politiques réelles 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 outre », « tandis que », « avec »

Exemple :

Autorisez les demandes lorsque la région est les É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 :

Autoriser 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 :

Autorisez 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 lorsque vous rédigez des politiques de 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 »

Bon : « 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 »

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

Erreur 3 : conditions subjectives

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

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

Erreur 4 : conditions manquantes

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

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

Erreur 5 : Logique peu claire

Mauvais : « Autoriser quand A ou B et C »

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