ABAC désigne le contrôle d’accès par attributs (Attribute-Based Access Control). Là où les rôles répondent à la question « cet utilisateur peut-il faire cela, tout court ? », les politiques ABAC ajoutent des conditions liées au contexte : « cet utilisateur peut-il faire cela dans les circonstances du moment ? »
Par exemple, un rôle peut accorder « approuver les bons de commande ». Une politique peut affiner cela en « approuver les bons de commande de moins de 2 000 000 DA seulement, et seulement si l’utilisateur n’a pas rédigé la commande lui-même ».
Les politiques sont la deuxième couche du contrôle d’accès de Beelocity — elles se posent sur les rôles et ajoutent une logique conditionnelle sans vous obliger à créer des dizaines de rôles très spécifiques.
Quand utiliser des politiques
Les politiques sont entièrement facultatives — beaucoup d’organisations fonctionnent très bien avec les seuls rôles. Envisagez d’en ajouter lorsque vous avez besoin de règles qui dépendent du contexte, et non de la seule identité :
| Besoin | Exemple de politique |
|---|---|
| Seuils de montant | Le personnel débutant ne peut approuver que les bons de commande de moins de 500 000 DA |
| Séparation des tâches | Un utilisateur ne peut pas approuver ses propres demandes d’achat (le « principe des quatre yeux ») |
| Restriction par dépôt | Les utilisateurs ne peuvent régulariser le stock que dans les dépôts qui leur sont affectés |
| Restriction horaire | Certaines opérations ne sont permises que pendant les heures ouvrables (dimanche-jeudi, 8h00-17h00) |
| Règles sur l’adresse IP | Les actions financières sensibles réservées à un accès depuis le réseau de l’entreprise |
Si rien de tout cela ne vous concerne, laissez les politiques de côté et revenez-y plus tard si le besoin se présente.
La structure d’une politique
Chaque politique se définit par cinq champs essentiels :
| Champ | Ce qu’il fait |
|---|---|
| Nom | Un libellé lisible qui explique l’objet de la politique (par exemple « Plafond d’approbation des bons de commande — 2 000 000 DA »). De bons noms rendent la liste des politiques compréhensible d’elle-même. |
| Cible | L’autorisation, le module, la ressource ou l’action à laquelle cette politique s’applique. Une politique ne s’évalue que lorsque l’utilisateur tente quelque chose qui correspond à sa cible. |
| Condition | Une expression logique qui doit valoir vrai pour que l’effet de la politique s’applique. C’est là que vous définissez le « quand » — les circonstances dans lesquelles la règle se déclenche. |
| Effet | Autoriser ou Refuser. La plupart des politiques sont des refus (« refuser l’approbation si le montant dépasse le seuil »), mais les autorisations sont utiles pour accorder des exceptions. |
| Priorité | Un nombre qui fixe l’ordre d’évaluation. Les politiques de priorité plus élevée sont évaluées en premier. Servez-vous-en pour garantir qu’un refus critique est examiné avant une autorisation moins importante. |
La logique d’évaluation
Lorsqu’un utilisateur tente une action, Beelocity évalue toutes les politiques actives qui correspondent :
- Trouver les politiques correspondantes — toutes celles dont la cible correspond à l’action tentée.
- Évaluer les conditions — la condition de chaque politique correspondante est confrontée au contexte du moment (qui fait quoi, sur quoi, quand, et d’où).
- Appliquer la primauté du refus :
- Si une seule politique correspondante refuse l’action, l’accès est refusé — quoi que disent les autres. Le refus l’emporte toujours.
- Si au moins une politique autorise et qu’aucune ne refuse, l’accès est accordé.
- Si aucune politique ne correspond, la décision retombe sur les autorisations des rôles. L’ABAC n’est qu’un affinage facultatif — il ne remplace pas les rôles.
Cette primauté du refus vous permet d’ajouter des politiques d’autorisation en toute confiance, sans craindre d’écraser par accident une règle de sécurité critique.
Les attributs des conditions
Les conditions sont des expressions qui font référence à des attributs. Ces attributs sont les briques de vos règles :
| Catégorie | Disponible aujourd’hui | Ce qu’elle apporte | Attributs |
|---|---|---|---|
| Utilisateur (sujet) | Oui | Qui accomplit l’action | subject.id, subject.roles, subject.organization_id, subject.is_org_admin |
| Action | Oui | Quelle opération est tentée | action.permission, action.method |
| Environnement | Oui | Quand la demande a lieu | env.timestamp, env.hour, env.day_of_week (1 = lundi) |
| Ressource | Pas encore | L’enregistrement sur lequel on agit | — |
Les attributs de ressource ne sont pas encore disponibles. Une politique qui mentionne quoi que ce soit en
resource.est refusée à l’enregistrement, avec une explication. C’est délibéré : le système ne sait pas encore consulter l’enregistrement sur lequel on agit pendant qu’il décide des autorisations, si bien qu’une telle politique resterait dans la liste avec l’air d’être active sans jamais rien faire. La refuser d’emblée est plus sûr que de vous laisser compter sur une règle qui ne fonctionne pas. Construisez les règles dont vous avez besoin à partir des attributs d’utilisateur, d’action et d’environnement.
Les opérateurs
L’éditeur de condition a deux vues. La vue Simple bâtit la condition à partir de règles — un attribut, un opérateur et une valeur — avec Règles à satisfaire réglé sur Toutes ou Au moins une. L’opérateur se choisit dans une liste, et chacun d’eux est un mot :
| Opérateur | Ce qu’il vérifie | Exemple |
|---|---|---|
| est égal à, n’est pas égal à | une correspondance exacte | action.method est égal à DELETE |
| est supérieur à, est au moins, est inférieur à, est au plus | un nombre face à une borne | env.hour est au moins 8 |
| fait partie de | la valeur figure dans une liste que vous donnez | action.method fait partie de POST, PUT |
| contient | un attribut qui porte plusieurs valeurs comprend celle-ci | subject.roles contient Warehouse Manager |
| est compris entre | un nombre dans un intervalle, bornes comprises | env.hour est compris entre 8 et 17 |
| correspond à | du texte face à un motif | action.permission correspond à ^PROCUREMENT_ |
Ce sont des mots, jamais des signes de comparaison, et dans toutes les langues. Un signe comme ≥ change de sens quand la page se lit de droite à gauche : un écran en arabe montrerait le contraire de la règle que vous avez enregistrée, en silence, sans rien à l’écran qui le trahisse.
La vue Avancé est la seconde, pour les conditions que la première ne sait pas dessiner — un groupe
dans un groupe, ou une négation. Elle accepte les mêmes opérateurs écrits en codes courts, listés sous
la zone de saisie, plus and, or et not pour les relier. Quelle que soit la vue où vous la
bâtissez, la condition vous est relue sous forme de phrase dans votre langue, sur la page de la
politique comme dans la liste.
Si une condition ne peut pas être évaluée — elle nomme un attribut que la demande ne portait pas, ou elle comporte une faute de frappe dans un opérateur — elle compte comme non remplie, et la politique ne se déclenche donc ni dans un sens ni dans l’autre. Les fautes de frappe et les attributs inconnus sont détectés à l’enregistrement de la politique, si bien que cela ne devrait pas arriver en pratique.
Créer une politique
- Allez dans Paramètres → Politiques et cliquez sur Ajouter.
- Fixez la cible — choisissez l’autorisation, ou la combinaison module / ressource / action, sur laquelle cette politique doit s’évaluer.
- Définissez la condition — décrivez quand cette politique doit prendre effet.
- Choisissez l’effet — Autoriser ou Refuser.
- Fixez la priorité — les nombres les plus élevés sont évalués en premier. Servez-vous-en pour maîtriser l’ordre d’évaluation quand plusieurs politiques peuvent s’appliquer à la même action.
- Enregistrez.
La liste Politiques se restreint depuis son bouton de filtre par Effet, Actif, une plage de Priorité, ou par le Module, la Ressource ou l’Action exacte de la cible — tous les refus d’un module tiennent en deux clics (Utiliser les listes).
Conseils
- Commencez par des refus — le cas le plus courant est de restreindre ce que les rôles autorisent déjà. « Refuser l’approbation au-delà de tel montant » ou « Refuser si l’utilisateur a créé l’enregistrement » sont des premières politiques typiques.
- Nommez les politiques de façon parlante — quand vous en avez 10 ou 20, des noms clairs comme « Plafond d’approbation des bons de commande — personnel débutant — 500 000 DA » sont bien plus faciles à tenir que « Politique 7 ».
- Testez avec un utilisateur peu doté — après avoir créé une politique, vérifiez qu’elle fonctionne en regardant ce qui se passe quand l’utilisateur concerné tente l’action restreinte.
- Maniez la priorité avec discernement — dans la plupart des cas, la priorité par défaut convient. Ne l’ajustez que si plusieurs politiques portent sur la même cible et que vous devez décider laquelle est évaluée en premier.