chore: add fr content (#40)

Author: gao-sun

astro.config.mjs

@@ -12,6 +12,7 @@ export const locales = Object.freeze({
   ar: 'ar',
   en: 'en',
   es: 'es',
+  fr: 'fr',
   ko: 'ko',
   ja: 'ja',
   nl: 'nl',

src/content/terms/fr/abac.mdx

@@ -0,0 +1,113 @@
+---
+title: Contrôle d'accès basé sur les attributs (Atrribute-based access control, ABAC)
+tags: [authorization]
+description: Le contrôle d'accès basé sur les attributs (ABAC) est un modèle de contrôle d'accès qui utilise des attributs (tels que les rôles d'utilisateur, les propriétés des ressources et les conditions environnementales) pour prendre des décisions de contrôle d'accès. C'est une manière flexible et dynamique de gérer l'accès aux ressources protégées.
+---
+
+## Qu'est-ce que le contrôle d'accès basé sur les attributs (ABAC) ?
+
+ABAC est un modèle de <Ref slug="access-control" /> qui utilise des attributs pour prendre des décisions de contrôle d'accès. Ces attributs peuvent inclure divers facteurs, tels que :
+
+- Attributs utilisateur : par exemple, rôles, département, localisation, etc.
+- Attributs de ressource : par exemple, niveau de sensibilité, propriétaire, type, etc.
+- Attributs environnementaux : par exemple, heure d'accès, localisation, appareil, etc.
+
+En évaluant ces attributs et en les passant à travers un ensemble de règles, l'ABAC peut déterminer si un sujet (par exemple, utilisateur, service) doit se voir accorder l'accès à une ressource. Cette approche permet un contrôle d'accès fin et une application dynamique des politiques en fonction du contexte.
+
+## Comment fonctionne l'ABAC ?
+
+L'ABAC utilise une approche basée sur des politiques pour le contrôle d'accès. Une politique ABAC typique se compose de :
+
+- **Sujet** : L'entité demandant l'accès (par exemple, utilisateur, service, appareil).
+- **Action** : L'opération effectuée sur la ressource (par exemple, lire, écrire, supprimer).
+- **Ressource** : L'entité à laquelle on accède (par exemple, fichier, base de données, API).
+- **Environnement** : Le contexte dans lequel l'accès est demandé (par exemple, heure, localisation, appareil).
+- **Attributs** : Les propriétés du sujet, de la ressource et de l'environnement qui sont évaluées pour prendre des décisions d'accès.
+- **Politiques** : Un ensemble de règles qui définissent les conditions sous lesquelles l'accès est accordé ou refusé.
+
+Les politiques ABAC sont plus complexes que les modèles traditionnels de contrôle d'accès comme le <Ref slug="rbac" />. En revanche, l'ABAC offre plus de flexibilité et de granularité dans les décisions de contrôle d'accès.
+
+### Exemple de politiques ABAC
+
+Par exemple, un système a plusieurs politiques ABAC :
+
+1. **Politique 1** : Autoriser l'accès si :
+
+    - (Sujet) Le rôle du sujet est `manager`.
+    - (Attribut) Le niveau de sensibilité de la ressource est `high`.
+    - (Environnement) La localisation est `internal`.
+    - (Action) Toute action.
+    - (Environnement) L'heure est entre 9h et 17h (heures de bureau).
+
+2. **Politique 2** : Refuser l'accès si :
+
+    - (Sujet) Le rôle du sujet n'est pas `manager`.
+    - (Attribut) Le niveau de sensibilité de la ressource est `high`.
+    - (Environnement) Toute localisation.
+    - (Action) Toute action.
+    - (Environnement) Toute heure.
+
+3. **Politique 3** : Autoriser l'accès si :
+
+    - (Sujet) Le rôle du sujet est `employee` ou `manager`.
+    - (Attribut) Le niveau de sensibilité de la ressource est `low`.
+    - (Environnement) Toute localisation.
+    - (Action) Action `read`.
+    - (Environnement) Toute heure.
+
+Le moteur d'évaluation des politiques vérifiera ces politiques dans l'ordre, et la première politique qui correspondra aux conditions déterminera la décision d'accès. Pendant ce temps, une politique par défaut de refus est appliquée si aucune autre politique ne correspond.
+
+Passons en revue quelques scénarios pour comprendre comment fonctionne l'ABAC :
+
+> **Scénario 1**. Un utilisateur souhaite accéder (effectuer l'action `read`) à un document (ressource) de niveau de sensibilité élevé en dehors du bureau (environnement). Le rôle de l'utilisateur est `manager` enregistré dans le système.
+  
+**Décision** : L'accès est refusé car l'utilisateur est en dehors du bureau (la localisation n'est pas `internal`).
+
+> **Scénario 2**. Un utilisateur souhaite accéder (effectuer l'action `read`) à un document (ressource) de niveau de sensibilité élevé pendant les heures de bureau (environnement) dans le réseau bureautique (localisation=`internal`). Le rôle de l'utilisateur est `manager`.
+
+**Décision** : L'accès est accordé car toutes les conditions de la Politique 1 sont remplies.
+
+> **Scénario 3**. Toutes les conditions du scénario 2 sont les mêmes, mais le rôle de l'utilisateur est `employee` au lieu de `manager`.
+
+**Décision** : L'accès est refusé car le rôle de l'utilisateur ne correspond pas aux conditions de la Politique 1.
+
+> **Scénario 4**. Un utilisateur souhaite accéder (effectuer l'action `read`) à un document (ressource) de niveau de sensibilité faible. Le rôle de l'utilisateur est `employee`.
+
+**Décision** : L'accès est accordé car toutes les conditions de la Politique 3 sont remplies.
+
+> **Scénario 5**. Un utilisateur souhaite supprimer (effectuer l'action `delete`) un document (ressource) de niveau de sensibilité faible. Le rôle de l'utilisateur est `employee`.
+
+**Décision** : L'accès est refusé car il n'existe aucune politique qui autorise l'action `delete` sur les documents de niveau de sensibilité faible.
+
+Vous remarquerez que tous les attributs ne sont pas nécessaires dans chaque politique. Cette flexibilité permet un mécanisme de contrôle d'accès plus dynamique et sensible au contexte.
+
+## Considérations d'implémentation
+
+Bien que l'ABAC offre une manière puissante de gérer le contrôle d'accès, il comporte également certaines considérations d'implémentation :
+
+- Complexité du système : Les politiques ABAC peuvent devenir complexes à mesure que le nombre d'attributs et de règles augmente. Une gestion et un test appropriés des politiques prennent plus de temps que les modèles de contrôle d'accès simples.
+- Performance : L'évaluation de politiques ABAC complexes peut avoir un impact sur la performance du système. Les techniques de mise en cache et d'optimisation peuvent aider à atténuer ce problème.
+- Conflits de politique : Les politiques conflictuelles peuvent entraîner des décisions d'accès imprévisibles. Un examen régulier des politiques et la résolution des conflits devraient faire partie du processus de gestion des politiques.
+
+## ABAC vs. RBAC
+
+Comparer l'ABAC avec le <Ref slug="rbac" /> peut vous aider à comprendre les différences entre les deux modèles :
+
+|                       | RBAC                               | ABAC                                     |
+|-----------------------|------------------------------------|------------------------------------------|
+| Politique de contrôle d'accès | Basée sur des rôles                  | Basée sur des attributs                  |
+| Granularité           | Grossière                          | Fine-grained                             |
+| Flexibilité           | Limitée                            | Très flexible                            |
+| Complexité            | Plus simple                        | Plus complexe                            |
+| Impact sur la performance | Minimal                            | Peut être significatif                   |
+| Gestion des accès     | Gestion des rôles                  | Gestion des politiques                   |
+| Idéal pour            | Structures de permission bien définies | Contrôle d'accès dynamique et sensible au contexte |
+
+<SeeAlso slugs={["access-control", "rbac", "authorization"]} />
+
+<Resources
+  urls={[
+    "https://blog.logto.io/rbac-and-abac",
+    "https://csrc.nist.gov/publications/detail/sp/800-162/final",
+  ]}
+/>

src/content/terms/fr/access-control.mdx

@@ -0,0 +1,88 @@
+---
+title: Contrôle d'accès
+tags: [authorization]
+description: Le contrôle d'accès est la restriction de qui peut effectuer quelles actions sur certaines ressources dans un système. C'est un mécanisme de sécurité fondamental pour définir et appliquer les politiques d'accès.
+---
+
+## Qu'est-ce que le contrôle d'accès (access control) ?
+
+Le contrôle d'accès (access control) implique trois composants principaux :
+
+- **Sujet** : Une entité qui effectue des actions sur les ressources. Les sujets peuvent être des utilisateurs, des services ou des appareils.
+- **Ressource** : Une entité protégée par le contrôle d'accès. Les ressources peuvent être des fichiers, des bases de données, des APIs ou tout autre actif numérique.
+- **Action** : Une opération qu'un sujet peut effectuer sur une ressource. Les actions peuvent être lire, écrire, exécuter ou toute autre opération.
+
+```mermaid
+graph LR
+    A(Sujet) -->|Effectue des actions sur| B(Ressource)
+```
+
+> Le contrôle d'accès (access control) définit la restriction sélective de l'accès aux **ressources** en fonction du **sujet** et de l'**action**.
+
+Voici quelques exemples concrets de contrôle d'accès :
+
+- Un utilisateur (sujet) **peut** lire (action) ses commandes (ressource) dans un système de commerce électronique.
+- Un utilisateur (sujet) **ne peut pas** supprimer (action) le profil d'un autre utilisateur (ressource) dans un réseau social.
+- Un service (sujet) **peut** écrire (action) des données dans une base de données (ressource) dans une architecture de microservices.
+
+Parfois, la ressource est ignorée dans les implémentations techniques et le contrôle d'accès est défini comme la restriction de qui (sujet) peut effectuer quelles actions. Par exemple, le cadre de base d'OAuth 2.0 spécifie uniquement les actions en utilisant des scopes (permissions) et ne définit pas les ressources.
+
+Le support pour le contrôle d'accès peut varier en fonction du <Ref slug="authorization-server" /> ou du <Ref slug="identity-provider" />. Certains systèmes peuvent prendre en charge les [Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707), une extension d'OAuth 2.0 qui permet aux clients de spécifier les ressources auxquelles ils souhaitent accéder.
+
+## Modèles de contrôle d'accès (access control) ||access-control-models||
+
+Décider des restrictions entre quelques sujets et ressources est simple, mais pas évolutif. Ainsi, l'industrie a développé de nombreux modèles de contrôle d'accès pour les gérer efficacement. Dans le contexte de <Ref slug="iam" />, voici quelques modèles de contrôle d'accès courants :
+
+- <Ref slug="rbac" /> : Un modèle qui attribue des permissions à des rôles, puis attribue des rôles à des sujets. Par exemple, un rôle d'administrateur pourrait avoir accès à toutes les ressources, tandis qu'un rôle d'utilisateur pourrait avoir accès à des ressources limitées.
+- <Ref slug="abac" /> : Un modèle qui utilise des attributs (propriétés) du sujet, de la ressource et de l'environnement pour prendre des décisions de contrôle d'accès. Par exemple, un utilisateur avec l'attribut "département=ingénierie" pourrait avoir accès aux ressources d'ingénierie.
+
+Il existe également d'autres modèles de contrôle d'accès tels que [policy-based access control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control). Chaque modèle a ses propres forces et faiblesses, et le choix du modèle dépend de votre cas d'utilisation et de vos exigences.
+
+## Contrôle d'accès (access control) dans OAuth 2.0
+
+Dans le contexte d'OAuth 2.0, le contrôle d'accès est généralement mis en œuvre à l'aide de <Ref slug="scope">scopes</Ref>. Habituellement, la valeur d'un scope est une chaîne qui combine la ressource et l'action. Par exemple, `read:orders` ou `write:profile`.
+
+> [!Note]
+> Le terme "scopes" est interchangeable avec "permissions" dans la plupart des cas.
+
+Il convient de noter qu'OAuth 2.0 ne définit pas la structure et la signification des scopes. L'interprétation des scopes est laissée au <Ref slug="resource-server" />, et l'émission des scopes est laissée au <Ref slug="authorization-server" />.
+
+Par exemple, un utilisateur (sujet) a besoin d'accéder à ses commandes (ressource) dans un système de commerce électronique. En exploitant OAuth 2.0, vous pouvez définir un scope `read:orders` et une application web (client) demandera ce scope au serveur d'autorisation. Voici un flux simplifié :
+
+```mermaid
+sequenceDiagram
+    participant Utilisateur
+    participant Client
+    participant Serveur d'autorisation
+    participant Serveur de ressources
+
+    Utilisateur->>Client: Accéder à la page "Mes commandes"
+    Client->>Serveur d'autorisation: Demander un access token avec le scope `read:orders`
+    Serveur d'autorisation->>Client: Émettre un access token
+    Client->>Serveur de ressources: Accéder aux commandes avec un access token
+    Serveur de ressources->>Client: Envoyer les commandes
+    Client->>Utilisateur: Afficher les commandes
+```
+
+Dans ce flux, en fonction de l'architecture technique, le serveur de ressources peut être un service API ou le client (application web) lui-même tant qu'il a la capacité d'accéder à la ressource (commandes).
+
+### Le paramètre d'indicateur de ressource
+
+Bien que les gens définissent souvent des scopes avec la ressource et l'action (par exemple, `read:orders`, où `orders` est la ressource et `read` est l'action), l'évolutivité de cette approche est limitée lorsque le nombre de ressources et d'actions augmente. RFC 8707 introduit le paramètre `resource` (c'est-à-dire <Ref slug="resource-indicator">resource indicators</Ref>) dans OAuth 2.0, qui permet aux clients de spécifier les ressources auxquelles ils veulent accéder.
+
+Le RFC spécifie que le paramètre `resource` doit être un URI représentant la ressource. Par exemple, au lieu d'utiliser simplement `orders`, vous pourriez utiliser `https://api.example.com/orders`. Cette méthode aide à prévenir les conflits de nommage et améliore la précision de la correspondance des ressources en permettant l'utilisation de l'URL réelle de la ressource.
+
+### Support du serveur d'autorisation
+
+OAuth 2.0 ne définit pas comment le serveur d'autorisation doit effectuer le contrôle d'accès. Il laisse les détails d'implémentation à la discrétion du serveur d'autorisation. Ainsi, le choix du serveur d'autorisation peut grandement affecter le mécanisme de contrôle d'accès. Par exemple, certains serveurs d'autorisation peuvent prendre en charge les resource indicators, tandis que d'autres peuvent ne pas le faire. Il est important de décider quel modèle de contrôle d'accès utiliser en fonction de vos exigences professionnelles, puis de choisir un serveur d'autorisation qui prend en charge ce modèle. Si vous n'êtes pas sûr du modèle de contrôle d'accès, <Ref slug="rbac" /> est suffisant pour la plupart des cas.
+
+<SeeAlso slugs={["rbac", "abac", "resource-indicator", "authorization"]} />
+
+<Resources
+  urls={[
+    "https://blog.logto.io/mastering-rbac",
+    "https://blog.logto.io/rbac-and-abac",
+    "https://datatracker.ietf.org/doc/html/rfc8707",
+    "https://blog.logto.io/organization-and-role-based-access-control",
+  ]}
+/>