RBAC : Gestion des rôles et des autorisations

1) Objectifs et principes de la RBAC

Objectif : rendre l'accès gérable, vérifiable et d'une portée minimale pour la protection de l'argent/PII et la conformité (GDPR/AML/PCI/ISO).
Principes : Least Privilège· Need-to-Know· Séparation des Duthies (SoD)· Zero Trust· Revocability (rappel rapide)· Auditabilité (probabilité).

2) Taxonomie des droits et du rôle

• Données : 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED _ READ' (par défaut pour PII).
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• Intégrations : 'API _ CALL :', 'WEBHOOK _ IGN', 'SERVICE _ BOU _ UPDATE'.

• Core (сквозные): `employee_basic`, `viewer_internal`, `auditor_privacy`.
• Доменные: `support_agent`, `vip_manager`, `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `rg_specialist`, `bi_analyst`.
• Système/ceux : 'devops _ admin', 'dba _ admin', 'service _ account _', 'read _ only _ prod'.
• Privilégiés (via PAM/JIT) : 'break _ glass _ admin', 'prod _ db _ jit _ editor'.

3) Conception des rôles (role engineering)

1. Inventaire des ressources : systèmes/tables/endpoints, classes de données (Public/Internal/Confidentiel/Restricted/Highly Restricted).
2. Stories utilisateur par fonction : qui fait quoi et pourquoi (purpose).
3. Mapping des tâches → permissions : ensemble minimum pour chaque fonction.
4. Regroupement dans un rôle : un rôle = un domaine de responsabilité ; éviter les « super roles ».
5. Test SoD : vérifie les incompatibilités (par exemple, 'payments _ ops' ≠' fraud _ rule _ admin ').
6. Pilote et mesure : nous délivrons temporairement à un groupe limité, nous recueillons la piste d'audit.
7. Versioning : chaque changement de rôle se fait par l'intermédiaire de l'ACR avec changelog.

4) Interaction RBAC ↔ ABAC ↔ SoD

Le RBAC répond « qui peut en principe », l'ABAC « dans quelles conditions » (environnement, géo, appareil/MDM, heure, niveau KYC, « purpose »).
SoD interdit les combinaisons dangereuses de rôles et exige 4-eyes pour les actions critiques.
Pratique : par défaut, les rôles donnent des MASKED_READ à l'IPI ; l'accès non masqué nécessite l'attribut 'purpos' + JIT et une décision de politique ABAC positive.

5) Polyvalence et géo-contexte

Tenant-scope : les rôles sont liés à la location/marque/juridiction ('role : payments _ ops @ EEA').
Geo-keys : clés de chiffrement individuelles et segments d'accès par région (EC/UK/...).
Granularité : filtrage par la colonne 'region _ code' (RLS) et par la juridiction du joueur.

6) Row/Column-Level Sécurité et masquage

• RLS (lignes) : accès uniquement aux enregistrements de votre pays/marque/équipe.
• CLS (colonnes) : les champs sensibles sont disponibles masqués ; non masqué - avec le privilège 'pii _ unmask' + 'purpose' seulement.

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, break-glass и PAM в RBAC

JIT : rôle privilégié temporaire (15-120 min) sous tiquet ; automobile ; un audit complet.
Break-glass : accès d'urgence avec MFA + deuxième confirmation et enregistrement de session ; post-revue avec Security + DPO.
PAM : stockage secret, proxy de session, rotation des mots de passe/clés.

8) Cycle de vie des rôles (SOP)

SOP-1 : Création/changement de rôle

1. Demande du propriétaire du domaine → la liste des tâches → → mapping permissions → chèque SoD → pilote de l'ACR → version + documentation.

SOP-2 : Demande et délivrance d'accès

1. La demande (IDM/ITSM) avec « purpose » et la période de → auto-vérification SoD/juridiction → l'approbation du propriétaire des données + Sécurité (pour Restricted +) → l'émission (souvent JIT) → une entrée dans le registre.

SOP-3 : Avis/Offboard

Déclencheurs : licenciement, changement de rôle, manque d'activité> 30/60 jours, JIT expiré.
Retour automatique et journal.

SOP-4 : Re-certification

Tous les trimestres, les propriétaires confirment que les rôles des utilisateurs sont encore nécessaires ; le système supprime les droits « suspendus ».

9) Exemple de matrice de rôle (fragment)

10) Outils et réalisation (modèles)

Répertoire des rôles en tant que code : YAML/JSON dans le référentiel + validateurs CI, changelog.
Central IdP/SSO : SCIM-provisionnement, mappings de groupe 'group → role'.
Point de décision politique : Moteur de stratégie (ABAC) avec attributs de contexte.
Secrets/KMS : isolation des clés par environnement/région/tenant.
Data gateway : une seule couche de masquage/audit pour DWH/BI/Export.
SIEM/SOAR : corrélation 'ROLE _ UPDATE '/' READ _ PII '/' EXPORT _ DATA', auto-tickets.

11) Audit et journalisation

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.
Exigences : copie WORM, chaînes de hachage, signature de paquet, 'purpose '/' ticket _ id'dans chaque événement, synchronisation temporelle.

12) Métriques et KPI/KRI

Coverage :% des systèmes sous RBAC ≥ 95 %.
SoD violations: = 0; les tentatives d'attribution de rôles incompatibles sont auto-block.
Taux JIT : ≥ 80 % des augmentations vont comme JIT.
Offboarding TTR : révocation des droits ≤ 15 min.
Masked reads ratio : ≥ 95 % des appels à PII sont masqués.
Reconnaissance : 100 % des rôles sont confirmés trimestriellement.
Les exportations signées : 100 % des exportations avec signature/journal.

13) RACI (agrandi)

14) Chèques-feuilles

Avant de créer un rôle

• Décrit par user-stories et 'purpose'
• Liste des ressources et des classes de données
• Mapping minimum permissions
• Vérification SoD/conflits
• Politique de masquage et RLS/CLS
• Plan de re-certification et propriétaires

Avant d'accorder l'accès

• Fixe 'purpose' et terme
• SoD/juridictions/MDM/MFA exécutées
• Masquage par défaut, JIT lors de la promotion
• Journal et date de révision inclus

15) Erreurs fréquentes et anti-modèles

« Superroli » avec des droits étendus au lieu de petits domaines.
Accès direct au PII sans masquage et « purpose ».
Absence de SoD/quatrièmes yeux pour 'PAYMENT _ APPROVE '/' KYC _ APPROVE'.
Extension des droits temporaires « pour toujours ».
Copie des données prod dans dev/stage.
Exportations opaques sans signature ni journal.

16) Feuille de route pour la mise en œuvre

Semaines 1 à 2 : inventaire des ressources/classification des données ; Matrice de rôle brouillon ; Table SoD.
Semaines 3-4 : RBAC en tant que code (référentiel), groupes IdP/SCIM, moteur ABAC (attributs de base : environnement/géo/MDM/temps), JIT/PAM, couche de masquage pour DWH/BI.
Mois 2 : ré-certification, automatisation offboarding, alertes SOAR pour les infractions RBAC/SoD/ABAC, journaux d'exportation/WORM.
Mois 3 + : extension des attributs (risque de l'appareil, niveau KYC), audits d'accès bias, optimisation des coûts et exercices de tabletop réguliers.

TL; DR

Fort RBAC = petits rôles de domaine + conditions d'attribut (ABAC) + SoD et JIT/PAM + masquage et RLS/CLS + audit rigoureux et re-certification. Cela réduit le risque de fuites/abus, accélère l'audit et maintient la plate-forme dans les limites des exigences de confidentialité et de conformité.