Moteur de rôle

1) Modèles d'autorisation

RBAC (Role-Based Access Control) : le sujet reçoit des rôles, les rôles sont liés aux droits (permissions). Simple à gérer, bon pour les responsabilités types.
ABAC (Attribute-Based Access Control) : la solution dépend des attributs du sujet, de la ressource, de l'action et de l'environnement (temps, IP, région, risque). Flexible et adaptable aux règles complexes.
L'hybride RBAC + ABAC : les rôles donnent une capacité « de base », les attributs la limitent (conditions).
(Facultatif) ReBAC/Relations basées : graphique de relation (propriétaire, membre de l'équipe, délégué), utile pour les structures documentaires et orgues.

2) Architecture : PDP/PEP et flux

PEP (Policy Enforcement Point) : lieu d'application de la solution (API Gateway, backend methode, SQL intercalaire, UI).
PDP (Policy Decision Point) : service/bibliothèque qui calcule 'ALLOW/DENY' par stratégie et attributs.
PIP (Policy Information Point) : sources d'attributs (IdP/profil, métadonnées de ressources, risque-score, géo).
PAP (Policy Administration Point) : interface administrative/référentiel de stratégies (versions, brouillons, publication).

Flux : La requête → PEP crée un contexte → PDP tire les attributs manquants (via PIP) → calcule la solution → PEP applique (autoriser/interdire/couper les champs) → audit.

3) Modèle de données

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'Ressource 'avec le type et les attributs :' type ',' owner _ id ',' tenant _ id ',' classification '(public/confidentiel),' région ',' tags '.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• « roles (id, tenant_id, name, inherits []) » - supportez les hiérarchies et les modèles.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• « assignments (subject_id, role_id, scope) » - scope : global/par projet/par objet.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Principes décisionnels

Deny-overrides : les interdictions explicites sont plus prioritaires que les autorisations.
Least Privilège (PoLP) : donnez le minimum d'accès nécessaire, étendez-le à travers les conditions.
Séparation de Duthies (SoD) : Interdire les combinaisons de rôles/actions (par exemple, « créé un paiement » ≠ « effacé »).
Context-aware : renforcer les exigences en cas de risque accru (pas de MFA, IP suspecte).
Determinisme : même contexte → même réponse ; Enregistrez la version de la stratégie dans le journal.

5) Modèles de réalisation

5. 1 Hybride de RBAC→ABAC (conditionnement)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Row/Field-Level Security

Au niveau OBD : Stratégies RLS (par 'tenant _ id', 'owner _ id').
Au niveau API : filtrez les collections et masquez les champs, sinon allow : read_sensitive_fields'.

5. 3 Solutions « step-up »

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Tolérances temporaires

Subventions avec TTL : 'assignment. expires_at', « fenêtres » d'accès (pendant les heures de travail de la région de la ressource).

6) Performances et mise en cache

Cache de décision par clé '(subject_hash, resource_key, action, policy_version)' avec TTL court.
Le cache Edge des attributs du sujet (claims dans le token) + les attributs lazy-fetch de la ressource.
Invalidation incrémentale : invalidité par événement (changement de rôle, changement de politique, transfert d'une ressource à « confidentiel »).
Vérifications de batch : pour les listes - évaluez avec un « filtre » (policy-predicate pushdown) afin de ne pas pousser le PDP de manière structurelle.

7) Polyvalence (Multi-tenant)

Dans chaque table, "tenant _ id' ; les stratégies par défaut limitent l'accès à l'intérieur du bail.
Les administrateurs de location gèrent uniquement les rôles/droits de leur location.
Accès à la location croisée - uniquement par des invitations explicites/shearing avec un dény-override explicite.

8) Administration et cycle de vie des politiques

Versioning : 'policy. version 'dans la réponse du PDP, conserver dans l'audit.
Environnements : draft → canary (parties du trafic/mode shadow) → prod.
Test matrix : tables de vérité par rôles/attributs clés (tests contractuels).
Change management : merj-rekvesty sur la politique avec l'analyse de la sécurité/komplaensa.

9) Audit et observabilité

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Métriques : QPS PDP, latence p95, cache hit-rate, proportion deny, fréquence step-up, incidents SoD.
Traces : span pour appeler PDP ; corrélation avec la requête API.
Replay : possibilité de « rejouer » les décisions historiques sur la nouvelle version de la politique (contrôle de sécurité).

10) Intégration avec authentification et tokens

L'identité provient de l'IdP (OIDC/SAML). Les tokens portent un minimum d'attributs : 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
Pour ABAC, tirez sur les signes « lourds » du côté serveur (PIP) pour ne pas gonfler le jeton.
Les tokens de ressources signés (capability/invitations) sont pour des délégations strictement limitées.

11) Pseudo-code PDP (simplifié)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-modèles

« Rôle = page » (des centaines de petits rôles sans modèle de domaine).
Stockez les stratégies uniquement dans le code sans version/audit.
L'absence deny-override et SoD → l'aggravation du risque de la fraude.
Les listes dures 'user _ id'dans les règles (au lieu des attributs/relations).
Absence de filtrage au niveau des données (RLS) en présence d'un filtre uniquement dans l'UI.
Synchronise les rôles à l'aide de scripts manuels sans événements ni handicaps de cache.

13) Mallettes et recettes

13. 1 Masquage de niveau :

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Exportation de données uniquement avec MFA :

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Délégation (token limité) :

Le token capability contient' resource _ id', 'actions = [ » read »]', 'expires _ at', 'aud'. La PPE vérifie la signature et le délai.

14) Tests

Tests unitaires des politiques : tables de vérité par combinaisons de base.
Property-based : génération d'attributs aléatoires pour la recherche de « trous ».
Golden-tests : fixation d'un ensemble de solutions pour les endpoints critiques.
Canary/Shadow : évaluation parallèle de l'ancienne et de la nouvelle versions des politiques avec logigation des écarts.

15) Capacités connexes de la section Architecture et protocoles

Authentification et autorisation (OIDC/OAuth2)

Gestion des consentements

Tokenization et gestion des clés

Observabilité : logs, métriques, tracés

Géo-routage et localisation

Cryptage At Rest/In Transit

16) Chèque de l'architecte

1. Les rôles de fond et leurs hiérarchies ont-ils été identifiés ?
2. Existe-t-il un modèle hybride : rôles + conditions sur les attributs ?
3. Implémenté PDP avec deny-overrides, SoD et step-up ?
4. Où est la PPE ? (passerelle, backend, OBD, UI) - est-il uniforme partout ?
5. Vous avez mis en place des caches de solutions et un handicap par événement ?
6. Les politiciens sont-ils versionnés, testés, répartis selon le processus ?
7. Audits de solutions, métriques et traçabilité inclus ?
8. Prise en charge de la polyvalence et du RLS/field-masking ?
9. Y a-t-il un runbook sur les incidents et la régression des politiques ?

Conclusion

RBAC assure la maniabilité, ABAC - contexte et précision. En combinant les rôles avec les conditions d'attribut, en partageant PDP/PEP, en introduisant la mise en cache, l'audit et le test des politiques, vous construisez l'autorisation comme une capacité de plateforme : prévisible, vérifiable et évolutive pour les exigences des produits et de la réglementation.