RBAC: managing roles and permissions

1) RBAC objectives and principles

Purpose: Make access manageable, verifiable, and minimal in volume to protect money/PII and compliance (GDPR/AML/PCI/ISO).
Principles: Least Privilege· Need-to-Know· Separation of Duties (SoD)· Zero Trust· Revocability (quick recall)· Auditability (provability).

2) Taxonomy of rights and roles

• Data: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED _ READ' (default for PII).
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• Integrations: 'API _ CALL:', 'WEBHOOK _ SIGN', 'SERVICE _ CONFIG _ UPDATE'.

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

3) Role engineering

1. Inventory of resources: systems/tables/endpoints, data classes (Public/Internal/Confidential/Restricted/Highly Restricted).
2. User stories by functions: who does what and why (purpose).
3. Task mapping → permissions - minimum set per function.

4. Grouping in role: one role = one responsibility domain; avoid "super roles."

5. SoD testing: checking for incompatibilities (e.g. 'payments _ ops' ≠ 'fraud _ rule _ admin').
6. Pilot and measurement: we issue a temporarily limited group, collect an audit trail.
7. Versioning: Each role change is via CAB with changelog.

4) RBAC ↔ ABAC ↔ SoD interaction

RBAC answers "who in principle can," ABAC - "in what conditions" (environment, geo, device/MDM, time, KYC level, 'purpose').
SoD prohibits dangerous role combinations and requires 4-eyes for critical actions.
Practice: by default, roles give MASKED_READ to PII; unmasked access requires a 'purpose' + JIT attribute and a positive ABAC policy decision.

5) Multi-tenancy and geo-context

Tenant-scope: Roles are tied to a lease/brand/jurisdiction ('role: payments _ ops @ EEA').
Geo-keys: individual encryption keys and access segments per region (EC/UK/...).
Granularity: filtering by 'region _ code' column (RLS) and by player jurisdiction.

6) Row/Column-Level Security and Masking

• RLS (strings): Access only to your country/brand/team records.
• CLS (columns): sensitive fields are available masked; unmasked - only with the privilege 'pii _ unmask' + 'purpose'.

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: temporary privileged role (15-120 min) under ticket; auto-feedback; full audit.
Break-glass: emergency access with MFA + second confirmation and session recording; post-review with Security + DPO.
PAM: secret store, session proxy, password/key rotation.

8) Role Lifecycle (SOP)

SOP-1: Create/Modify Role

1. Inquiry of the owner of the domain → list of tasks → mapping of permissions → SoD-check → pilot → CAB → release + documentation.

SOP-2: Request and Grant Access

1. Application (IDM/ITSM) with 'purpose' and deadline → SoD/jurisdiction auto-verification → data owner approval + Security (for Restricted +) → issuance (often JIT) → registry entry.

SOP-3: Feedback/Offboarding

Triggers: Termination, role change, inactivity> 30/60 days, JIT expired.
Automatic recall and log.

SOP-4: Re-certification

Quarterly, owners confirm that user roles are still needed; system removes "hanging" rights.

9) Role matrix example (fragment)

10) Tools and implementation (patterns)

Role catalog as code: YAML/JSON in the repository + CI validators, changelog.
Central IdP/SSO: SCIM provisioning, group mappings' group → role '.
Policy decision point: policy engine (ABAC) with context attributes.
Secrets/KMS: key isolation per environment/region/tenant.
Data gateway: a single layer of masking/auditing for DWH/BI/exports.
SIEM/SOAR: correlation'ROLE _ UPDATE '/' READ _ PII '/' EXPORT _ DATA', auto-tickets.

11) Audit and Logging

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.
Requirements: WORM copy, hash chains, packet signature, 'purpose '/' ticket _ id' in each event, time synchronization.

12) Metrics and KPI/KRI

Coverage:% of systems under RBAC ≥ 95%.
SoD violations: = 0; attempts to assign incompatible roles - auto-block.
JIT rate: ≥ 80% of increases are JIT.
Offboarding TTR: revocation of rights ≤ 15 min.
Masked reads ratio: ≥ 95% of calls to PII are masked.
Recertification: 100% roles confirmed quarterly.
Exports signed: 100% of exports with signature/log.

13) RACI (enlarged)

14) Checklists

Before creating a role

• Described user-stories and 'purpose'
• List of resources and data classes
• Minimum permissions mapping
• SoD check/conflicts
• Masking and RLS/CLS Policy
• Re-certification plan and owners

Before granting access

• Fixed 'purpose' and date
• SoD/jurisdictions/MDM/MFA completed
• Default masking, JIT on promotion
• Journal and revision date included

15) Frequent errors and anti-patterns

"Super roles" with wide rights instead of small domain ones.
Direct access to PII without masking and 'purpose'.
No SoD/fourth eyes for 'PAYMENT _ APPROVE '/' KYC _ APPROVE'.

Extension of temporary rights "forever."

Copy prod data to dev/stage.
Opaque exports without signature and log.

16) Implementation Roadmap

Weeks 1-2: asset inventory/data classification; a draft matrix of roles; SoD table.
Weeks 3-4: RBAC as code (repository), IdP groups/SCIM, ABAC engine (basic attributes: environment/geo/MDM/time), JIT/PAM, masking layer for DWH/BI.
Month 2: re-certification, offboarding automation, SOAR alerts for RBAC/SoD/ABAC violations, export logs/WORM.
Month 3 +: attribute extension (device risk, KYC level), access bias audits, cost optimization and regular tabletop exercises.

TL; DR

Strong RBAC = small domain roles + attribute conditions (ABAC) + SoD and JIT/PAM + masking and RLS/CLS + hard auditing and re-certification. This reduces the risk of leaks/abuse, speeds up auditing and keeps the platform within the boundaries of privacy and compliance requirements.