Contrôle d'accès et RBAC dans l'API

1) Pourquoi le contrôle d'accès à l'API

L'autorisation est la réponse à la question "Cet acteur peut-il effectuer cette action sur cette ressource maintenant ? ». Les erreurs entraînent des fuites BOLA/IDOR, une escalade des droits et une violation des exigences réglementaires. L'objectif est de construire un modèle à plusieurs niveaux : périmètre → service mash → règles commerciales, avec des politiques explicites et des vérifications au niveau objet.

2) Modèles d'autorisation : Quand choisir quoi

RBAC (Role-Based Access Control) - rôles de résolution →. Simple, stable, mais enclin à « l'explosion des rôles ».
ABAC (Attribute-Based) est une solution pour les attributs du sujet/objet/contexte (pays, niveau KYC, propriétaire de la ressource, risque).
ReBAC (Relationship-Based) est un graphe de relation (propriétaire, membre de l'équipe, « gestionnaire de projet ») ; décide des hiérarchies complexes.
Scopes (OAuth) est un contrat entre un client et un serveur de ressources sur une « zone d'accès » (par exemple, « payments : write »).
Pratique : RBAC pour la matrice de base, ABAC pour le contexte et les contraintes, ReBAC pour les hiérarchies complexes (dossiers, organisations, limites et sous-accounts).

3) Taxonomie des ressources et des actions

Hiérarchies : 'org → project → wallet → transaction'. Hériter des droits de haut en bas avec des « limiteurs » possibles.
Actions : CRUD + domaine spécifique ('approve', 'refund', 'settle').
Propriétés des ressources : propriétaire, région, statut, tags de risque (AML/KYC), limites.
Multiplicité : toutes les solutions contiennent "tenant _ id' ; l'interdiction des requêtes croisées par défaut (deny-by-default).

4) Architecture : où la décision est prise

PEP (Policy Enforcement Point) est le lieu de validation : le gateway passerelle/API, le mash sidecar, le service lui-même.
PDP (Policy Decision Point) est un moteur de politique : centralisé (OPA-service, Cedar-moteur) ou intégré à la bibliothèque.
PIP (Policy Information Point) - sources d'attributs : répertoire des utilisateurs/rôles, profil du tenant, CUS/risque, carte de propriété des ressources.
PAP (Policy Administration Point) - Gestion des versions des politiques, publication, audit.

Recommandation : PDP + cache de solution local centralisé dans PEP ; les vérifications complexes d'objets dans le service en présence d'invariants de domaine.

5) Tokens, marques et identité

OIDC/OAuth2 : 'sub' (identifiant du sujet), 'aud' (service cible),' scope '/' roles ',' tenant ',' kyc _ level ',' risk _ tier '.
JWT : Signature RS/ES, courte « bou », transfert par refresh. Ne mettez pas de PII ; utilisez 'jti' pour rappeler/vérifier la piste.
mTLS/HMAC : service-k-service et partenaires ; Les marques sont tirées du répertoire par 'client _ id'.
Device/Context : IP/ASN, geo, heure de la journée - connexion à la solution ABAC (par exemple, interdiction d'écrire en dehors des heures de travail).

6) Autorisation de niveau objet (BOLA-first)

Chaque opération doit répondre à "le sujet est-il propriétaire/a-t-il droit à cette" ressource _ id' ? ".

Contrôle de propriété : 'resource. owner_id == subject. id 'ou l'appartenance à' org 'avec un rôle.
Filtrage des échantillons : toujours superposer 'WHERE resource. tenant_id =:tenant AND...` (row-level security).
Pour les opérations de référence (ID dans le chemin/corps) - normaliser et valider jusqu'à la logique d'entreprise.

7) Conception de RBAC : rôles, autorisations, ensembles

Les permissions sont des droits atomiques : 'wallet. read`, `wallet. write`, `payment. refund`.
Rôles - jeux d'autorisations nommés : 'admin', 'support. read`, `cashier`, `fraud. analyst`.
Scopes est un contrat externe pour les clients (mapping scope→permissions).

• rôles de base + « compléments » (packs de permission),
• restrictions ABAC (pays/région/tenant),
• « augmentations temporaires » (accès Just-In-Time, expiration).

8) AWAS/contraintes contextuelles

Géo/juridiction : interdiction de write des pays interdits (sanctions/réglementation).
Temps/risque : 'risk _ score <threshold'pour les opérations majeures.
CUS/limites : 'kyc _ level> = 2' pour les conclusions> X ; contrôle du « refroidissement » entre les transactions.
« Dispositifs de confiance » : exiger mTLS pour les partenaires sur les itinéraires dangereux.

9) ReBAC et graphe des droits

Utile pour les structures d'affaires complexes (groupes, équipes, marques, filiales).

Relation : 'membre', 'admin', 'owner', 'viewer'.
Droits dérivés : 'viewer' de la ressource est hérité du 'membre' du projet qui appartient à 'org'.
Stockage du graphe : OBD avec matrice de relations, service spécialisé (dans l'esprit de l'approche Zanzibar). Mettez en cache les réponses 'check (subject, relation, object)'.

10) Cache des solutions et performances

Le cache PDP de la couche PEP (par exemple dans la passerelle) est la clé de : "sub 'tenant' ressource 'action' policy _ version '.
TTL court (secondes-minutes) + handicap par événement : changement de rôle/relation/tenante.
Vérifications Batch (bulk authz) pour les listes : réduisent les charges PDP.
Mesurer les solutions de latitude ; en cas de dégradation - graceful-degradation uniquement pour la lecture (jamais pour write/money).

11) Exemples de politiques

11. 1 marques JWT → PEP grossier (pseudo-gateway)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Limitation de compétence (politique deny-list)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Politique ReBAC (pseudo)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Gestion des politiques et des versions

Versioning des stratégies ('policy _ version') et Canaries pour les modifications dangereuses.
« Courses sèches » (dry-run/shadow decisions) - Nous logeons 'allow/deny' sans impact.
Catalogue des politiques et des migrations : qui, quand et pourquoi a changé ; comparaison avec les incidents.
Tests de scénarios négatifs (cas interdits) - obligatoire dans CI.

13) Observation et audit

Logs de décision : 'trace _ id', 'subject', 'tenant', 'action', 'resource _ id', 'result', 'policy _ version', cause du refus.
Métriques : 'authz _ decision _ latency', 'authz _ denied _ total {action}', part des tentatives BOLA, cache-hit-rate.
Dashboards : top refus sur les actions/tenants, tendances après les sorties politiques.

14) Sécurité et durabilité

Deny-by-default : absence de résolution explicite = interdiction.
Fail-closed : en cas d'indisponibilité des PDP, les writes critiques → l'interdiction (ou la dégradation vers un « ensemble minimum » de rôles rigoureusement validés).
Les « vérifications de garde » locales dans les services pour les invariants critiques (par exemple, 'tenant '/' owner').
Minimiser les marques dans JWT ; Appliquer les attributs sensibles via PIP via un canal sécurisé.

15) Spécificités iGaming/Finance

Rôles : 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Restrictions : les opérations de paiement dépendent de 'kyc _ level', des limites de paiement responsables, du statut AML/sanctions.
Registres de verrouillage : 'org/brand/device/payment _ instrument' - filtres ABAC sur write.
Les journaux d'audit sont inchangés pour les actions KYC/AML/conclusions ; stockage selon les délais réglementaires.
API partenaires : mTLS + contrats 'scopes' par itinéraire, filtres géo/ASN sur le périmètre.

16) Test et vérification

Matrice negative : énumérez les cas « interdits » explicites et fixez-les par des tests.
Fuzz autorisation : remplacement de 'tenant _ id', 'owner _ id', contournement des filtres lors de la pagination/tri.
Test de charge PDP : vérifiez la latence et le comportement des caches à p95/p99.
Politique de sortie : dry-run + canary + chantier automobile avec deny/allow attendu.
Incidents : repli des demandes sur le stand avec la version exacte des politiques.

17) Anti-modèles

Ne compter que sur 'scope'sans vérification d'objet (BOLA).
Mélanger la logique d'entreprise et les contrôles de droits dans chaque handler sans modèle centralisé.
Hardcoding rôles dans l'IU et faire confiance aux solutions client.
Aucun filtre 'tenant '/' owner' dans les requêtes de la base de données (leaky reads).
Il n'y a pas d'invalidité des solutions cache lors du changement de rôle/relation.
JWT à longue durée de vie sans rappel/rotation.

18) Chèque-liste prod-prêt

• Les ressources/actions, les hiérarchies et la pluralité sont définies.
• Matrice RBAC de base + limiteurs ABAC, où vous voulez - ReBAC.
• Les PDP/PEP sont conçus ; il y a un cache local de solutions et son handicap.
• Les politiques sont versionées, les tests de scénarios négatifs dans les IC.
• Vérification BOLA dans chaque write/read sur un 'resource _ id'spécifique.
• JWT avec un minimum de stigmates, court « bou » ; audit/rappel par 'jti'.
• Métriques/logs de solutions, dashboards, alertes par deny/latency.
• Fail-closed pour write critique ; le mode fallback est documenté.
• Documentation pour les clients : 'scopes', codes d'erreur (401/403/404/409), exemples.

19) TL; DR

Construire une autorisation BOLA-first : PDP central + cache de solutions, RBAC comme base, ABAC pour le contexte, ReBAC pour les relations. Toutes les requêtes sont dans le contexte de 'tenant' et de 'resource _ id'spécifique ; deny-by-default, JWT courts, filtres d'objet dans la base de données. Versez et testez les stratégies, mesurez latency/deny, reproduisez les incidents avec un relais. Pour iGaming, des rôles distincts (KYC/AML/caisse), des limiteurs ABAC rigides et un audit immuable.