# Comprendre les politiques de Cedar
<a name="policy-understanding-cedar"></a>

Policy in AgentCore utilise les politiques de Cedar pour contrôler l'accès aux outils AgentCore Gateway. Cette section explique la structure des politiques de Cedar, la sémantique d'évaluation et les concepts clés.

**Topics**
+ [Exemple de stratégie](#policy-example)
+ [Structure d’une politique](#policy-structure)
+ [Effets des politiques](#policy-effects)
+ [Refus par défaut](#policy-default-deny)
+ [Évaluation de l'autorisation](#policy-authorization-evaluation)
+ [Indépendance des politiques](#policy-independence)
+ [Algorithme d'évaluation des politiques](#policy-evaluation-algorithm)

## Exemple de stratégie
<a name="policy-example"></a>

Envisagez un outil de traitement des remboursements répondant aux exigences suivantes :
+ Seul l'utilisateur « John » peut traiter les remboursements
+ Les remboursements sont limités à 500$ ou moins

La politique de Cedar qui applique ces exigences :

```
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:your-region:your-account-id:gateway/refund-gateway"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "John" &&
  context.input.amount < 500
};
```

Cette politique autorise le traitement des remboursements uniquement lorsque l'utilisateur est « John » et que le montant du remboursement est inférieur à 500$.

## Structure d’une politique
<a name="policy-structure"></a>

Les politiques de Cedar se composent de trois éléments principaux :

1.  **Effet** - Détermine s'il faut autoriser ou refuser l'accès (`permit`ou`forbid`)

1.  **Champ d'application** - Spécifie le principal, l'action et la ressource auxquels la politique s'applique

1.  **Condition** : définit une logique supplémentaire qui doit être satisfaite (`when`ou`unless`) et qui peut faire référence aux paramètres de l'outil (via le contexte) et au jeton OAuth (via les balises)

## Effets des politiques
<a name="policy-effects"></a>

Les politiques de Cedar utilisent deux effets pour contrôler l'accès :
+  `permit`- Permet à l'action de se poursuivre
+  `forbid`- Refuse l'action

## Refus par défaut
<a name="policy-default-deny"></a>

Toutes les actions sont refusées par défaut. Si aucune politique ne correspond à une demande, Cedar renvoie DENY. Vous devez rédiger des politiques d'autorisation explicites pour autoriser les actions.

## Évaluation de l'autorisation
<a name="policy-authorization-evaluation"></a>

Cedar utilise un modèle d'évaluation des dérogations interdites et des permis :

1. Cedar évalue toutes les politiques qui s'appliquent à la demande

1. Si une politique d'interdiction correspond, le résultat est DENY

1. Si au moins une politique d'autorisation correspond et qu'aucune politique d'interdiction ne correspond, le résultat est ALLOW

1. Si aucune politique ne correspond, le résultat est DENY (refus par défaut)

## Indépendance des politiques
<a name="policy-independence"></a>

Chaque politique de Cedar est évaluée indépendamment. L'évaluation d'une politique dépend uniquement des éléments suivants :
+ Le champ d'application (principal, action, ressource)
+ Le contexte et les balises

Les politiques ne font pas référence à d'autres politiques et ne dépendent pas de celles-ci.

## Algorithme d'évaluation des politiques
<a name="policy-evaluation-algorithm"></a>

Lorsqu'une demande est évaluée, le moteur de politique détermine la décision d'autorisation à l'aide de l'algorithme suivant :

1. Si une `forbid` politique correspond à la demande, la décision est DENY.

1. Si aucune `forbid` politique ne correspond à la demande et qu'au moins une `permit` politique correspond, la décision est ALLOW.

1. Si ni `permit` les politiques `forbid` ni les politiques ne correspondent à la demande, la décision est REFUSÉE.

Ce modèle d'évaluation applique une posture de **refus par défaut**.

Une `forbid` politique ne peut jamais aboutir à une décision ALLOW. La `unless` clause d'une `forbid` politique précise les conditions dans lesquelles cette `forbid` politique ne s'applique pas ; elle n'accorde **pas** d'autorisation et ne remplace pas une `permit` politique correspondante.