RBAC：角色和權限管理

1） RBAC的宗旨和原則

目標：使訪問具有可管理性，可驗證性，並且數量最少，以保護金錢/PII和合規性（GDPR/AML/PCI/ISO）。
原則：Least Privilege· Need-to-Know· Duties Separation （SoD）· Zero Trust· Revocability（快速召回）·Auditability（可證明性）。

2）權利和角色的分類法

• 數據：「READ」，「WRITE」，「EXPORT」，「DELETE」，「MASKED_READ」（PII的默認值）。
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• 集成：「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`.
• 系統/人員：'devops_admin'、'dba_admin'、'service_account_'、'read_only_prod'。
• 特權（通過PAM/JIT）：「break_glass_admin」，「prod_db_jit_editor」。

3）角色設計（角色工程）

1.資源清單：系統/表/內聯網、數據類（Public/Internal/Confidential/Restricted/Highly Restricted）。
2.用戶故事按功能：誰在做什麼和為什麼（purpose）。
3.Mapping Task → permissions：每個功能的最低設置。
4.角色分組：一個角色=一個責任域；避免「超級角色」。
5.SoD測試：不兼容性檢查（例如，「payments_ops」 ≠ 「fraud_rule_admin」）。

6.飛行員和測量： 給臨時限制組,收集審計跟蹤.

7.轉化：每個角色的變化都是通過CAB與changelog。

4）RBAC ↔ ABAC ↔ SoD相互作用

RBAC響應「原則上誰可以」，ABAC響應「在什麼條件下」（環境，地理，設備/MDM，時間，KYC級別，「purpose」）。
SoD禁止危險的角色組合，並且需要4眼才能采取關鍵行動。
實踐：默認情況下，角色為PII提供了MASKED_READ；未掩蓋的訪問需要「purpose」+JIT屬性和積極的ABAC策略解決方案。

5）多重性和地理背景

Tenant-scope：角色與租賃/品牌/司法管轄區相關（'role：payments_ops@EEA'）。
Geo-keys：個別加密密鑰和按區域訪問段（EC/UK/……）。
粒度：通過「region_code」（RLS）列和玩家管轄權進行過濾。

6）Row/Column-Level安全性和掩飾

• RLS（行）：僅訪問其國家/品牌/團隊的記錄。
• CLS（列）：敏感字段可偽裝訪問；沒有掩飾-僅具有「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：tiket的臨時特權角色（15-120分鐘）；自我評估；全面審計。
破玻璃：使用MFA+第二次確認和會議記錄進行緊急訪問；Security+DPO後續評論。
PAM：保密存儲，會話代理，密碼/密鑰輪換。

8）角色生命周期（SOP）

SOP-1： 創建/更改角色

1.域所有者的請求→任務列表→ mapping permissions → SoD支票→飛行員→ CAB →版本+文檔。

SOP-2： 請求和準入

1.申請（IDM/ITSM）具有「purpose」和→ SoD/司法管轄區的自動驗證 →數據所有者批準+Security（對於Restricted+）→簽發（通常是JIT）→註冊。

SOP-3： 召回/離岸公司

觸發因素：解雇，角色變更，不活動>30/60天，JIT到期。
自動召回和日誌。

SOP-4： 重新認證

每季度，所有者確認仍然需要用戶角色；該系統消除了「懸掛」權利。

9）角色矩陣示例（片段）

10）工具與實現（模式）

角色目錄為代碼：存儲庫+CI驗證器changelog中的YAML/JSON。
中央IdP/SSO：SCIM-provigening，「group → role」組映射。
策略決策點：具有上下文屬性的策略引擎（ABAC）。
Secrets/KMS： 按鍵隔離環境/區域/tenant。
數據網關：用於DWH/BI/導出的單個掩蔽/審核層。
SIEM/SOAR：相關性「ROLE_UPDATE」/「READ_PII」/「EXPORT_DATA」，自動滴答。

11）審核和日誌

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.

要求：WORM副本、散列鏈、數據包簽名、每個事件中的「purpose」/「ticket_id」、超時同步。

12）度量標準和KPI/KRI

覆蓋：RBAC下的系統百分比≥ 95％。
SoD violations: = 0;嘗試分配不兼容的角色-自動塊。
JIT利率：≥ 80%的漲幅與JIT一樣。
離開TTR：召回權利≤ 15分鐘。
Masked reads ratio： ≥ 95%的PII轉診是偽裝的。
Recertification：100%的角色每季度確認一次。
簽名：100%帶簽名/日誌的出口。

13）RACI（集合）

14）支票單

在創建角色之前

• 描述用戶故事和「purpose」
• 資源和數據類別列表
• Mapping minimum permissions
• SoD驗證/沖突
• 屏蔽策略和RLS/CLS
• 重新認證計劃和所有者

在授予訪問權限之前

• 固定「purpose」和期限
• SoD/司法管轄區/MDM/MFA執行
• 默認掩碼,JIT升級時
• 日刊和修訂日期包括在內

15）頻繁的錯誤和反模式

「Superroli」具有廣泛的權利而不是小型域名。
無需掩蓋即可直接訪問PII和「purpose」。
「PAYMENT_APPROVE」/「KYC_APPROVE」缺少SoD/第四只眼睛。
延長臨時權利「永遠」。
在dev/stage中復制prod數據。
無簽名和日誌的不透明出口。

16）實施路線圖

第1至第2周：資源清單/數據分類；草稿角色矩陣；SoD表。
3-4周：RBAC作為代碼（存儲庫），IdP 組/SCIM，ABAC引擎（基本屬性：環境/地理/MDM/時間），JIT/PAM，DWH/BI的掩蔽層。
第2個月：重新認證，離岸自動化，RBAC/SoD/ABAC違規的SOAR-Alerta，出口日誌/WORM。
月3+：屬性擴展（設備風險，KYC級別），可用性bias審計，成本優化和常規的平板操作。

TL;DR

強大RBAC=小域角色+屬性條件（ABAC）+SoD和JIT/PAM+掩蔽以及RLS/CLS+嚴格的審核和重新認證。這減少了泄漏/濫用的風險，加快了審計，並使平臺保持在隱私和合規要求的範圍內。