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.
Un rôle dans une condition
subject.roles porte les rôles de la personne qui fait la demande, chacun sous le nom sous lequel il
est enregistré. Un rôle que vous avez créé est enregistré sous le nom que vous lui avez donné. Un rôle
livré avec l’application est enregistré sous un nom anglais fixe, quelle que soit la langue de vos
écrans, alors que l’écran Rôles le nomme dans la vôtre — le nom que vous y lisez n’est donc pas
celui qu’attend une condition :
| Sur l’écran Rôles | Dans une condition |
|---|---|
| Propriétaire de l’organisation | Organization Owner |
| Trésorier | Treasurer |
| Caissier | Cashier |
| Responsable des ventes | Sales Manager |
| Assistant commercial | Sales Clerk |
| Responsable des achats | Procurement Manager |
| Assistant achats | Procurement Clerk |
Ce tableau vous servira rarement. Dans la vue Simple, une règle sur subject.roles ne vous fait
rien taper : sa valeur se choisit dans la liste des rôles de votre organisation, nommés comme l’écran
Rôles les nomme, et la politique garde derrière votre choix le nom qu’il faut. Une règle qui nomme
un rôle que votre organisation n’a pas — tapée dans la vue Avancé, ou enregistrée avant que cette
liste existe — le signale sous la règle, car elle ne vise personne, et un Refuser qui ne vise
personne ne refuse rien. La phrase qui relit la condition, comme la vue Avancé, montre le nom que
la politique garde.
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. Une fois le module choisi, les ressources proposées sont les siennes, et les actions celles de la ressource.
- 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.
- Une politique qui finit par « (PAYROLL) » est une copie faite par Beelocity. Quand la paie a reçu sa propre rubrique, une politique que vous aviez visée sur les Ressources humaines aurait cessé de couvrir les autorisations de la Paie. Chacune de celles qui couvraient la paie a donc été copiée, visant la Paie, avec « (PAYROLL) » après son nom. Modifiez ou supprimez la copie comme n’importe laquelle de vos politiques.